Proksi perusahaan dan aplikasi Windows — merapikan resolusi proksi di WinINET, WinHTTP, dan .NET

«Peramban membuka situs eksternal, tetapi hanya aplikasi bisnis yang tidak mencapai API eksternal.» «Berjalan di mesin pengembangan, tetapi kehabisan waktu di jaringan pelanggan.» «Berkomunikasi ketika saya jalankan secara manual, dan gagal begitu saya jadikan layanan Windows.» — Ketika Anda menjalankan aplikasi bisnis di lingkungan dengan proksi perusahaan, konsultasi semacam ini termasuk yang paling umum.

Dalam kebanyakan kasus penyebabnya bukan pemadaman server proksi maupun bug aplikasi. Windows punya beberapa keluarga terpisah dari apa yang orang sebut «pengaturan proksi», dan pengaturan mana yang siapa baca berbeda menurut aplikasi (menurut tumpukan HTTP yang dipakai) dan menurut akun yang menjalankan — ketidaksesuaian itu. Pengaturan yang dibaca peramban, yang dibaca layanan, dan yang dibaca HttpClient .NET masing-masing bisa menjadi hal yang berbeda. Begitu struktur itu ada di kepala, mengisolasi «berjalan di peramban, tetapi…» menjadi cepat secara mengejutkan.

Artikel ini ditujukan untuk staf TI perusahaan kecil dan menengah serta pengembang aplikasi Windows. Artikel ini mengikat, dalam satu gambar, tiga keluarga pengaturan proksi — WinINET, WinHTTP, dan variabel lingkungan — konfigurasi otomatis PAC dan WPAD, perbedaan resolusi proksi antara .NET Framework dan .NET (Core dan seterusnya), proksi berautentikasi (407), inspeksi TLS, dan prosedur isolasi praktis. Pola pembuatan HttpClient dan desain batas waktu sendiri dibahas di «Jangan bungkus HttpClient dalam using», jadi artikel ini berfokus pada resolusi proksi.

1. Kesimpulan dulu

• Pengaturan proksi Windows bukan satu hal; ada setidaknya tiga keluarga. (1) Pengaturan WinINET per pengguna (halaman «Proksi» di aplikasi Pengaturan = Opsi Internet lama), (2) pengaturan mesin WinHTTP (netsh winhttp), dan (3) variabel lingkungan HTTP_PROXY / HTTPS_PROXY. Mana yang dibaca diputuskan di sisi aplikasi.¹²
• «Proksi» yang Anda lihat di aplikasi Pengaturan adalah pengaturan per pengguna WinINET. Peramban dan aplikasi interaktif membacanya; layanan Windows tidak. WinINET tidak didukung untuk dipakai di layanan; pemakaian layanan adalah pekerjaan WinHTTP.¹³
• Penyebab paling umum «berjalan secara manual tetapi tidak sebagai layanan» adalah perbedaan akun yang menjalankan. LocalSystem dan akun layanan tidak bisa melihat proksi per pengguna yang dikonfigurasi administrator di layarnya sendiri.³⁴
• netsh winhttp set proxy adalah pengaturan statis; tidak menangani PAC, deteksi otomatis, atau autentikasi proksi. Jika Anda ingin mengonfigurasi PAC atau WPAD per mesin, Anda butuh sisi netsh winhttp set advproxy.⁴²
• Hasil PAC berubah per URL. Fungsi FindProxyForURL berkas PAC menerima URL dan host lalu mengembalikan daftar proksi atau koneksi langsung (DIRECT). «Situs itu berjalan, tetapi hanya API ini yang tidak» bisa jadi cabang PAC.⁵⁶
• HttpClient pada .NET (Core dan seterusnya) menginisialisasi proksi bawaan dalam urutan variabel lingkungan → pengaturan proksi pengguna Windows. Jika salah satu dari HTTP_PROXY, HTTPS_PROXY, atau ALL_PROXY didefinisikan, itu unggul atas pengaturan OS, jadi kecelakaan «seseorang meninggalkan variabel lingkungan» bisa terjadi.⁷
• Bawaan .NET Framework adalah Opsi Internet akun yang menjalankan, dan bisa ditimpa dengan defaultProxy di app.config. Pengaturan berkas konfigurasi unggul atas pengaturan sistem.⁸⁹
• 407 adalah kesalahan autentikasi proksi; itu lain dari 401 (autentikasi server). Skema mencakup Negotiate, NTLM, dan Basic, dan di .NET Anda mengirim kredensial dengan DefaultProxyCredentials atau WebProxy.UseDefaultCredentials. Perhatikan bahwa di bawah akun layanan isi «kredensial bawaan» berubah.¹⁰¹¹¹²
• Proksi inspeksi TLS hanya bertahan sebagai satu set dengan distribusi sertifikat CA internal. Mesin dan runtime yang belum menerimanya mendapat kesalahan validasi sertifikat. Selesaikan dengan distribusi ke penyimpanan sertifikat, bukan dengan menonaktifkan validasi di aplikasi.¹³⁴

Dalam satu kalimat: setiap kali Anda bilang «saya sudah periksa pengaturan proksi», selalu bisa bilang keluarga mana dari tiga yang Anda periksa, dan dari akun mana — itulah subjek artikel ini.

2. Windows punya tiga keluarga «pengaturan proksi»

Dulu, peta keseluruhan. Jalur yang dipakai aplikasi Windows untuk menemukan proksi perusahaan jatuh ke tiga keluarga ini.

(1) adalah apa yang orang umumnya kenali sebagai «pengaturan proksi Windows»; substansinya adalah konfigurasi WinINET. Secara historis itu Opsi Internet Internet Explorer, dan secara bawaan disimpan per pengguna.⁴

(2) adalah bawaan per-mesin untuk konteks seperti layanan di mana «tidak ada pengguna yang masuk». (3) terutama adalah konvensi alat yang datang dari dunia lintas platform; di Windows, .NET (Core dan seterusnya) dan curl serta sejenisnya juga membacanya.⁷

Poin penting adalah bahwa keluarga mana yang dibaca diputuskan di sisi aplikasi, bukan di sisi pengaturan. Jika aplikasi memakai WinINET secara internal ia membaca (1); jika WinHTTP, (2) (atau penimpaan khusus aplikasi); jika .NET (Core dan seterusnya), (3) lalu (1). Jadi biasanya bukan «pengaturan proksi benar tetapi tetap tidak tersambung»; kenyataannya «keluarga yang dibaca aplikasi adalah keluarga berbeda dari yang Anda periksa».

flowchart TB
    accTitle: Tiga keluarga pengaturan proksi Windows
    accDescr: WinINET adalah Pengaturan dan Opsi Internet per pengguna, WinHTTP adalah bawaan mesin lewat netsh, dan variabel lingkungan berlingkup proses. Keluarga mana yang dibaca diputuskan aplikasi, bukan sisi pengaturan
    fam{"Keluarga mana?"}
    fam --> wininet["Pengaturan WinINET per pengguna"]
    fam --> winhttp["Pengaturan mesin WinHTTP"]
    fam --> env["HTTP_PROXY dan teman-temannya"]
    wininet -.-> r1["Peramban dan aplikasi desktop"]
    winhttp -.-> r2["Layanan dan bagian OS"]
    env -.-> r3[".NET Core+ dan curl"]

Gambar 1: Tiga keluarga berdampingan. Aplikasi memilih mana yang dibaca.

Jika Anda mengaktifkan Kebijakan Grup «Jadikan pengaturan proksi per-mesin (bukan per-pengguna)», Anda bisa mengalihkan (1) menjadi per-mesin dan menerapkan pengaturan yang sama ke setiap pengguna. Dengan MDM (Intune dan sejenisnya) Anda bisa mengonfigurasinya per perangkat dengan NetworkProxy CSP.⁴

3. WinINET dan WinHTTP — untuk aplikasi interaktif dan untuk layanan

3.1. Perbedaan peran

WinINET dan WinHTTP keduanya tumpukan klien HTTP inbox Windows, tetapi mengasumsikan pemakaian berbeda.

• WinINET: ditujukan untuk aplikasi desktop interaktif. Secara otomatis mewarisi Opsi Internet pengguna (proksi, cookie, cache kredensial) dan bahkan bisa menampilkan UI entri kredensial jika perlu. Pemakaian di layanan atau proses mirip layanan tidak didukung.¹
• WinHTTP: ditujukan untuk layanan dan sisi server. Mendukung berjalan di bawah akun layanan, peniruan utas, dan isolasi sesi; sebagai gantinya tidak berbagi pengaturan peramban pengguna, cookie, atau kredensial. Juga tidak menampilkan UI.³

Panduan Microsoft sendiri sama jelasnya: «pakai WinINET kecuali Anda berjalan di dalam layanan, atau di proses mirip layanan yang butuh isolasi sesi dan peniruan» — dengan kata lain, jika itu layanan, pakai WinHTTP.¹

flowchart TB
    accTitle: WinINET untuk aplikasi interaktif, WinHTTP untuk layanan
    accDescr: WinINET mewarisi Opsi Internet pengguna yang masuk dan tidak didukung di layanan. WinHTTP berjalan di bawah akun layanan tanpa UI dan tidak berbagi pengaturan peramban pengguna
    q{"Aplikasi desktop interaktif?"}
    q -->|"Ya"| ie["WinINET"]
    q -->|"Layanan atau mirip layanan"| wh["WinHTTP"]
    ie -.-> ieNote["Membaca Opsi Internet pengguna"]
    wh -.-> whNote["Pengaturan mesin, tanpa UI"]

Gambar 2: Aplikasi interaktif memakai WinINET. Layanan memakai WinHTTP.

3.2. Operasi dasar netsh winhttp

Proksi bawaan mesin WinHTTP dioperasikan dengan netsh.²

:: Display the current WinHTTP proxy settings
netsh winhttp show proxy

:: Set a static proxy (with a bypass list)
netsh winhttp set proxy proxy-server="proxy.example.co.jp:8080" bypass-list="*.example.co.jp;<local>"

:: Import the Internet Options (WinINET) settings
netsh winhttp import proxy source=ie

:: Return to the default (DIRECT)
netsh winhttp reset proxy

Dua batasan yang perlu diingat di sini.

1. netsh winhttp set proxy adalah pengaturan statis. Tidak menangani deteksi otomatis proksi, maupun menentukan URL PAC, maupun autentikasi proksi.⁴
2. import proxy source=ie hanya menyalin pengaturan statis pada saat itu; tidak mengikuti perubahan kemudian di sisi Opsi Internet. Ketika Anda butuh konfigurasi per-mesin yang mencakup PAC atau deteksi otomatis, konfigurasikan pengaturan terperinci bentuk JSON (Proxy, ProxyBypass, AutoconfigUrl, AutoDetect) dengan netsh winhttp set advproxy.²

3.3. Jebakan paling umum: layanan tidak membaca pengaturan IE pengguna

Pola yang paling sering dilihat di lapangan, dalam urutan waktu, tampak seperti ini.

1. Pengembang menjalankan alat di PC-nya → pengaturan proksi per pengguna (1) berlaku dan berjalan
2. Di produksi dibiarkan menetap sebagai layanan Windows (Cara membangun dan mengoperasikan layanan Windows) di bawah LocalSystem
3. Pengaturan yang terlihat dari LocalSystem adalah hal lain (pengaturan per pengguna tidak terlihat, dan pengaturan mesin WinHTTP tidak dikonfigurasi = DIRECT) → mencoba koneksi langsung ke API eksternal dan kehabisan waktu

Bukan «tidak berjalan padahal mesin yang sama»; bahkan di mesin yang sama, akun yang menjalankan berbeda berarti kumpulan pengaturan proksi yang terlihat berbeda. Untuk proses yang berkomunikasi bahkan ketika tidak ada pengguna yang masuk, pendekatan yang benar adalah menyiapkan pengaturan per-mesin dalam bentuk yang benar-benar dibaca tumpukan HTTP proses itu. Untuk aplikasi native atau komponen Windows yang memakai WinHTTP, pengaturan WinHTTP netsh berlaku.⁴ HttpClient pada .NET (Core dan seterusnya), sebaliknya, tidak membaca pengaturan mesin WinHTTP (lihat Bab 5), jadi untuk layanan .NET Anda mengatur variabel lingkungan sistem (HTTPS_PROXY dan sejenisnya) atau menentukan HttpClientHandler.Proxy secara eksplisit dari pengaturan aplikasi.

Kecelakaan juga terjadi ke arah lain. Jika Anda membakar proksi statis ke laptop yang berpindah antara jaringan perusahaan dan luar dengan netsh winhttp set proxy, proksi itu tidak terjangkau di luar perusahaan dan komunikasi mati total. Perlakukan pengaturan statis mesin sebagai sarana yang ditujukan ke server yang konfigurasi jaringannya tidak berubah.⁴

flowchart TB
    accTitle: Mengapa layanan tidak melihat pengaturan IE pengguna
    accDescr: Jalankan pengembang membaca pengaturan WinINET per pengguna dan berhasil. Sebagai LocalSystem pengaturan itu tidak terlihat. Aplikasi WinHTTP native lalu mengikuti pengaturan mesin yang tidak dikonfigurasi (DIRECT). Layanan .NET Core+ masih memakai variabel lingkungan atau handler.Proxy eksplisit dan tidak beralih ke netsh winhttp
    dev["Jalankan manual sebagai pengguna"] --> ok["Pengaturan WinINET per pengguna berlaku"]
    svc["Layanan Windows sebagai LocalSystem"] --> miss["Pengaturan per pengguna tidak terlihat"]
    miss --> stack{"Tumpukan HTTP mana?"}
    stack -->|"WinHTTP"| direct["WinHTTP tidak dikonfigurasi = DIRECT"]
    stack -->|".NET Core+"| env["Variabel lingkungan atau handler.Proxy"]
    direct --> fail["API eksternal kehabisan waktu"]

Gambar 3: Mesin yang sama, akun berbeda, kumpulan pengaturan proksi yang terlihat berbeda.

4. PAC dan WPAD — apa «konfigurasi otomatis» sebenarnya

4.1. Berkas PAC dan FindProxyForURL

Berkas PAC (Proxy Auto-Configuration) adalah JavaScript (ECMAScript) yang menghitung «proksi mana yang dipakai untuk URL ini», dan selalu berisi fungsi bernama FindProxyForURL(url, host). Fungsi mengembalikan daftar proksi yang harus dipakai, atau nilai kembali khusus (DIRECT) yang berarti boleh tersambung langsung tanpa proksi.⁵

function FindProxyForURL(url, host) {
    // Internal domains and private addresses go direct
    if (dnsDomainIs(host, ".example.co.jp") ||
        isInNet(host, "10.0.0.0", "255.0.0.0")) {
        return "DIRECT";
    }
    // Everything else goes through a proxy. Fall back to the next if the first is unavailable
    return "PROXY proxy1.example.co.jp:8080; PROXY proxy2.example.co.jp:8080; DIRECT";
}

Dua konsekuensi praktis mengikuti.

• Resolusi proksi harus dilakukan per URL. Karena PAC bisa mengembalikan proksi berbeda atau koneksi langsung tergantung URL (host), fitur proksi otomatis WinHTTP juga dirancang untuk meneruskan URL permintaan dan menanyakan setiap kali.⁶ «Peramban melihat situs lain» bukan bukti bahwa API bermasalah menempuh jalur yang sama.
• DIRECT adalah instruksi «pergi tanpa proksi». Jika lalu lintas yang seharusnya internal tidak pernah muncul di log proksi, curigai dulu bahwa PAC mengembalikan DIRECT (atau cocok dengan daftar bypass).

4.2. Deteksi otomatis lewat WPAD

Nyalakan «Deteksi pengaturan secara otomatis» dan mesin mencari lokasi berkas PAC dengan protokol WPAD (Web Proxy Auto-Discovery). Dalam konfigurasi tipikal, DHCP menyerahkan URL PAC, atau DNS dipakai untuk mencari host bernama wpad dan PAC diunduh dari URL seperti http://wpad/wpad.dat.¹⁴

Dengan kata lain, «deteksi otomatis» bukan sihir; itu mekanisme yang hanya bekerja di jaringan yang sudah menyiapkan pengaturan WPAD di DHCP/DNS. Menyalakan deteksi otomatis saja di jaringan tanpa pengaturan itu hanya menambah waktu menunggu kegagalan deteksi.

flowchart TB
    accTitle: PAC meresolusi proksi per URL, WPAD hanya menemukan PAC
    accDescr: FindProxyForURL menerima URL dan host lalu mengembalikan daftar proksi atau DIRECT. WPAD hanya menemukan PAC lewat DHCP atau DNS. Klien yang tidak bisa mengevaluasi PAC jatuh ke proksi statis atau variabel lingkungan
    url["URL permintaan"] --> pac["FindProxyForURL"]
    pac -->|"daftar proksi"| via["Lewat proksi"]
    pac -->|"DIRECT"| dir["Sambung tanpa proksi"]
    wpad["WPAD lewat DHCP atau DNS"] -.-> pac
    nopac["Klien tidak bisa mengevaluasi PAC"] -.-> fb["Pengaturan statis atau variabel lingkungan"]

Gambar 4: PAC memutuskan per URL. WPAD hanya menemukan berkas PAC.

4.3. Bagaimana klien yang tidak bisa mengevaluasi PAC berperilaku

Tidak setiap klien bisa mengevaluasi PAC.

• Pengaturan statis netsh winhttp set proxy tidak mengevaluasi PAC.⁴
• Alat yang memakai gaya variabel lingkungan HTTP_PROXY pada umumnya hanya bisa menulis URL proksi tetap (tidak ada tempat menulis URL PAC).⁷
• Untuk aplikasi native yang memakai WinHTTP langsung, tergantung bagaimana sesi dibuka. Aplikasi yang dibuka dengan WinHttpOpen di Windows 8.1 dan seterusnya dengan WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY membuat WinHTTP meresolusi secara otomatis pengaturan proksi sistem/pengguna (termasuk WPAD/PAC) per permintaan.¹⁵ Jika dibuka dengan WINHTTP_ACCESS_TYPE_DEFAULT_PROXY yang lebih lama (usang sejak 8.1) atau sejenisnya, proksi otomatis tidak terintegrasi ke tumpukan HTTP, dan aplikasi harus memanggil sendiri WinHttpGetProxyForUrl lalu menerapkan hasilnya ke permintaan. Dengan kata lain, pada implementasi yang lebih lama, PAC bisa ada dan tetap tidak dipakai.⁵

«Peramban pergi ke proksi yang tepat lewat PAC, tetapi aplikasi bisnis tidak membaca PAC dan mencoba koneksi langsung lalu gagal» — ini ketidaksesuaian klasik lain. Di jaringan yang dioperasikan PAC Anda perlu memutuskan cadangan — pengaturan statis atau variabel lingkungan — untuk klien yang tidak bisa membaca PAC.

5. Resolusi proksi .NET — Framework dan Core dan seterusnya adalah hal berbeda

Pengaturan proksi mana yang dibaca aplikasi .NET berbeda secara bawaan antara .NET Framework dan .NET (Core dan seterusnya). Campur keduanya dan Anda akan menyelidiki aplikasi .NET 8 dengan pengetahuan era Framework lalu melewatkannya.

5.1. .NET Framework — bawaan adalah Opsi Internet, ditimpa dengan defaultProxy

Di .NET Framework, HttpWebRequest dan HttpClient yang duduk di atasnya memakai proksi bawaan kecuali Anda menentukan Proxy secara eksplisit. Proksi bawaan diputuskan oleh kombinasi pengaturan Internet sistem (pengaturan WinINET akun yang menjalankan) dan berkas konfigurasi, dan pengaturan berkas konfigurasi unggul.⁸

Anda bisa mengontrol bawaan ini dengan elemen system.net/defaultProxy di app.config (atau machine.config).⁹

<configuration>
  <system.net>
    <!-- useDefaultCredentials: whether to send default credentials to an authenticating proxy -->
    <defaultProxy enabled="true" useDefaultCredentials="true">
      <proxy usesystemdefault="true"
             proxyaddress="http://proxy.example.co.jp:8080"
             bypassonlocal="true" />
      <bypasslist>
        <add address="[a-z]+\.example\.co\.jp$" />
      </bypasslist>
    </defaultProxy>
  </system.net>
</configuration>

Biarkan elemen defaultProxy kosong dan pengaturan sistem (Opsi Internet) dipakai; tulis proxyaddress dan sejenisnya dan itu unggul. Dari program Anda bisa mengganti bawaan yang sama dengan WebRequest.DefaultWebProxy.⁹⁸

Jebakan Bab 3.3 berlaku di sini juga. Karena bawaannya «Opsi Internet akun yang menjalankan», aplikasi .NET Framework yang berjalan di bawah akun layanan membaca kumpulan pengaturan berbeda (biasanya kosong) dari yang terlihat di desktop administrator.

5.2. .NET (Core dan seterusnya) — variabel lingkungan dulu, lalu pengaturan pengguna OS

HttpClient pada .NET (Core dan seterusnya) punya properti statis HttpClient.DefaultProxy. Kecuali handler menentukan proksi secara eksplisit, setiap instans HttpClient memakainya. Aturan inisialisasi di Windows adalah «baca variabel lingkungan, dan jika tidak didefinisikan, baca pengaturan proksi pengguna».⁷

Variabel lingkungan yang dipakai adalah sebagai berikut.⁷

Tiga hal yang perlu diperhatikan.

• Jika salah satu dari HTTP_PROXY, HTTPS_PROXY, atau ALL_PROXY didefinisikan, itu unggul atas pengaturan proksi sisi OS. Mendefinisikan hanya NO_PROXY tidak mengonfigurasi proksi dari variabel lingkungan, dan di Windows pengaturan proksi pengguna OS terus dipakai. «Pengaturan tak terlihat» seperti meninggalkan HTTPS_PROXY sebagai variabel lingkungan sistem setelah percobaan lama, atau templat CI/CD yang menyuntikkannya, adalah lahan subur kecelakaan.
• NO_PROXY tidak mendukung wildcard (*). Untuk mencocokkan subdomain, taruh titik di depan (.example.com cocok dengan www.example.com tetapi tidak dengan example.com sendiri).⁷
• Di luar Windows (kontainer Linux dan sejenisnya), jika variabel lingkungan tidak didefinisikan diinisialisasi tanpa proksi. Perubahan perilaku bawaan aplikasi yang sama antara Windows dan Linux adalah hal yang perlu dikonfirmasi saat migrasi kontainer.⁷

5.3. Penentuan eksplisit — HttpClientHandler.Proxy dan UseProxy

Di runtime mana pun, prioritas tertinggi adalah penentuan eksplisit pada handler. Menentukan HttpClientHandler.Proxy unggul atas pengaturan OS dan berkas konfigurasi, dan UseProxy = false tidak memakai proksi sama sekali.¹⁴

using System.Net;

// Use a proxy read from app settings explicitly
var handler = new HttpClientHandler
{
    Proxy = new WebProxy("http://proxy.example.co.jp:8080")
    {
        BypassProxyOnLocal = true,
        BypassList = new[] { @"^intra\.example\.co\.jp$" },
        UseDefaultCredentials = true // On an authenticating proxy, respond with the running account's credentials
    },
    UseProxy = true
};
var client = new HttpClient(handler);

// A client that never uses a proxy (for direct internal APIs)
var directHandler = new HttpClientHandler { UseProxy = false };
var directClient = new HttpClient(directHandler);

Ketika tidak ada penentuan eksplisit dan pengaturan OS diikuti, bypass otomatis tujuan lokal punya aturan. Nama datar tanpa titik, alamat loopback, tujuan yang cocok dengan akhiran domain mesin sendiri, dan sejenisnya bisa diperlakukan sebagai «lokal».¹⁴ Gejala seperti «perilaku berubah jika saya tentukan alamat IP» atau «tiba-tiba mulai lewat proksi ketika saya memakai FQDN» bisa disebabkan penilaian ini.

Urutan prioritas adalah sebagai berikut.

flowchart TB
    accTitle: Resolusi proksi bawaan di Framework versus Core dan seterusnya
    accDescr: HttpClientHandler.Proxy eksplisit selalu menang. Framework lalu memakai app.config defaultProxy dan Opsi Internet akun yang menjalankan. Core dan seterusnya memakai penugasan ke HttpClient.DefaultProxy, lalu variabel lingkungan, lalu pengaturan proksi pengguna Windows
    expl["handler.Proxy eksplisit"] --> done["Proksi itu dipakai"]
    noexpl["Tidak ada Proxy eksplisit"] --> fw{"Runtime mana?"}
    fw -->|"Framework"| cfg["app.config defaultProxy"]
    cfg --> ie["Opsi Internet akun yang menjalankan"]
    fw -->|"Core dan seterusnya"| dp["HttpClient.DefaultProxy"]
    dp --> ev["HTTP_PROXY dan teman-temannya"]
    ev --> user["Pengaturan proksi pengguna Windows"]

Gambar 5: Penentuan eksplisit selalu menang. Jalur bawaan berbeda menurut runtime.

6. Proksi berautentikasi — 407 adalah kesalahan autentikasi proksi

6.1. Jangan campur 407 dengan 401

Ketika Anda mencoba melewati proksi yang menuntut autentikasi, proksi mengembalikan kode status 407 (Proxy Authentication Required) dan header Proxy-Authenticate yang mencantumkan skema yang tersedia. Itu lain dari tuntutan autentikasi server tujuan (401 dan WWW-Authenticate); pihak yang Anda serahi kredensial dan tempat Anda mengonfigurasinya keduanya berbeda.¹⁰

flowchart TB
    accTitle: 407 adalah proksi, 401 adalah server tujuan
    accDescr: 407 dan Proxy-Authenticate datang dari proksi. 401 dan WWW-Authenticate datang dari server tujuan. Kredensial dan tempat mengonfigurasinya berbeda
    req["Permintaan keluar"] --> who{"Siapa yang menuntut autentikasi?"}
    who -->|"Proksi"| e407["407 + Proxy-Authenticate"]
    who -->|"Tujuan"| e401["401 + WWW-Authenticate"]
    e407 -.-> cred["DefaultProxyCredentials"]

Gambar 6: 407 adalah autentikasi proksi. 401 adalah autentikasi server.

Skema mencakup Basic, yang mengirim nama pengguna dan kata sandi apa adanya, dan skema tantangan/respons seperti Negotiate (Kerberos/NTLM). Dalam skema tantangan/respons kata sandi sendiri tidak berjalan di jaringan, dan autentikasi selesai dalam beberapa pertukaran.¹⁰ Mekanisme skema ke mana ia «jatuh» dibahas lebih rinci di «NTLM dan Kerberos dijelaskan dengan diagram».

6.2. Cara mengirim kredensial di .NET

Ketika Anda ingin memakai proksi bawaan yang datang dari pengaturan OS dan hanya meneruskan autentikasi, pakai HttpClientHandler.DefaultProxyCredentials. Ini kredensial yang dikirim ke proksi bawaan itu ketika UseProxy = true dan Proxy = null (= proksi bawaan sistem).¹¹

using System.Net;

var handler = new HttpClientHandler
{
    UseProxy = true,   // The default. Combined with a null Proxy, this uses the system-default proxy
    Proxy = null,
    // Respond to 407 with the credentials of the running account (signed-in user or service account)
    DefaultProxyCredentials = CredentialCache.DefaultCredentials
};
var client = new HttpClient(handler);

Ketika Anda menentukan proksi secara eksplisit, taruh kredensial di sisi WebProxy. Dalam banyak skenario klien rekomendasinya memakai kredensial bawaan pengguna yang masuk daripada nama pengguna dan kata sandi individu, dan WebProxy.UseDefaultCredentials = true adalah itu.¹²

6.3. Masalah 407 akun layanan

Akun yang menjalankan penting di sini juga. «Kredensial bawaan» berarti kredensial akun yang menjalankan proses itu. Jalankan sebagai pengguna interaktif dan autentikasi ke proksi adalah sebagai pengguna itu; jalankan sebagai layanan LocalSystem dan itu sebagai akun komputer.

• Jika proksi mengautentikasi pengguna lewat Active Directory, ia tidak bisa mengautentikasi akun komputer atau akun lokal, dan 407 berlanjut begitu Anda jadikan aplikasi sebagai layanan
• Sebaliknya, beberapa lingkungan punya pengecualian autentikasi di sisi proksi untuk layanan (menurut IP sumber atau menurut akun)

Jadi penyelidikan 407 tidak tertutup pada «pengaturan aplikasi» saja; itu satu set dengan pemeriksaan desain di sisi infrastruktur: bisakah proksi mengautentikasi akun yang menjalankan. Untuk aplikasi yang akan Anda jadikan layanan, Anda harus memutuskan pada saat desain salah satu dari: menjalankannya di bawah akun layanan domain (gMSA dan sejenisnya), menaruh pengecualian autentikasi di sisi proksi, atau mendirikan proksi relai internal yang tidak memerlukan autentikasi.

Ada juga gaya yang menyematkan kredensial di variabel lingkungan, seperti HTTP_PROXY=http://user:pass@proxy:8080⁷, tetapi kata sandi teks-jelas lalu terpapar di variabel lingkungan (= informasi proses), jadi tidak disarankan untuk operasi tetap.

7. HTTPS dan proksi — terowongan CONNECT dan inspeksi TLS

7.1. HTTPS melewati proksi sebagai «terowongan»

Ketika Anda memakai proksi untuk HTTPS, klien dulu mengirim ke proksi permintaan CONNECT destination-host:443, dan proksi membuka terowongan TCP. Jika berhasil proksi mengembalikan 200, dan setelah itu klien dan server tujuan melakukan jabat tangan TLS di dalam terowongan itu. Jika terowongan tidak terbuka, proksi mengembalikan 407 (autentikasi diperlukan), 502, atau sejenisnya.¹⁶

Dalam model ini proksi tidak bisa membaca isi terowongan (HTTPS terenkripsi). Yang tersisa di log proksi adalah nama host tujuan dan apakah koneksi berhasil; jalur URL tidak terlihat — itu perilaku proksi «pass-through».

flowchart TB
    accTitle: HTTPS lewat proksi adalah terowongan CONNECT
    accDescr: Klien mengirim CONNECT ke proksi, proksi membuka terowongan TCP dan mengembalikan 200, lalu klien dan tujuan melakukan jabat tangan TLS di dalam terowongan. Log proksi melihat host, bukan jalur URL
    cli["Klien"] -->|"CONNECT host:443"| px["Proksi"]
    px -->|"200 dan terowongan TCP"| dest["Tujuan"]
    dest -->|"TLS di dalam terowongan"| cli
    px -.-> log["Log: host dan keberhasilan saja"]

Gambar 7: Proksi pass-through melihat host, bukan jalur terenkripsi.

7.2. Proksi inspeksi TLS dan kesalahan sertifikat

Proksi produk keamanan, sebaliknya, mencakup jenis inspeksi TLS (dekripsi SSL, pecah dan periksa) yang mengakhiri TLS, memeriksa isi, dan mengenkripsi ulang sebelum meneruskan. Dalam skema ini sertifikat server yang disajikan ke klien bukan yang asli; diganti dengan sertifikat yang ditandatangani ulang oleh CA proksi sendiri.¹³

Premis yang membuat konfigurasi ini bertahan adalah «sertifikat CA proksi telah didistribusikan ke akar tepercaya setiap klien». Di mesin yang belum menerimanya, atau di runtime yang tidak melihat penyimpanan sertifikat Windows (alat dengan penyimpanan kepercayaan sendiri), Anda mendapat kesalahan validasi sertifikat. Di .NET biasanya muncul sebagai HttpRequestException yang membungkus AuthenticationException (pesan semacam «the remote certificate is invalid»).

Prinsip perbaikannya sebagai berikut.

• Distribusikan sertifikat CA internal ke penyimpanan «Otoritas Sertifikasi Akar Tepercaya» komputer lokal. Pemisahan penyimpanan pengguna dan penyimpanan komputer dibahas di «Penyimpanan sertifikat Windows dalam praktik».
• Jangan nonaktifkan validasi sertifikat di kode. Solusi yang selalu mengembalikan true dari ServerCertificateCustomValidationCallback menjadi aplikasi rentan yang tidak bisa mendeteksi man-in-the-middle begitu keluar ke jaringan luar.
• Lalu lintas dengan pinning sertifikat tidak bisa diinspeksi sejak awal. Koneksi yang memverifikasi sertifikat Microsoft tertentu, seperti yang dilakukan beberapa komponen Windows, gagal begitu proksi menukar sertifikat, dan tidak ada solusi selain pengecualian.⁴ Untuk lalu lintas menuju SaaS seperti Microsoft 365, Microsoft sendiri merekomendasikan mengecualikannya dari dekripsi dan inspeksi di lapisan jaringan.¹³

Gejala «setiap situs internal terlihat, tetapi hanya layanan cloud tertentu yang menghasilkan kesalahan sertifikat di aplikasi» harus membuat Anda curiga dulu pada kombinasi daftar pengecualian inspeksi TLS dan pinning.

flowchart TB
    accTitle: Proksi inspeksi TLS menandatangani ulang sertifikat
    accDescr: Proksi mengakhiri TLS, memeriksa isi, dan menyajikan sertifikat yang ditandatangani ulang oleh CA-nya. Validasi bertahan hanya jika CA itu ada di akar tepercaya. Jangan nonaktifkan validasi di kode
    real["Sertifikat server asli"] --> px["Proksi inspeksi TLS"]
    px --> fake["Ditandatangani ulang oleh CA proksi"]
    fake --> client["Validasi klien"]
    client -->|"CA di akar tepercaya"| ok["Berhasil"]
    client -->|"CA hilang"| err["Kesalahan sertifikat"]
    err -.-> fix["Distribusikan CA ke penyimpanan"]

Gambar 8: Inspeksi hanya bekerja sebagai satu set dengan mendistribusikan CA internal.

8. Prosedur isolasi — lima langkah untuk mengidentifikasi pelaku

Selidiki «tidak bisa tersambung» secara mekanis dalam urutan ini.

Anda bisa mengumpulkan (2) sekaligus dengan PowerShell.

# (1) Per-user (WinINET) settings — note that this reads HKCU of the running account
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
    Select-Object ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL

# (2) Machine (WinHTTP) settings
netsh winhttp show proxy

# (3) Environment variables
Get-ChildItem env: | Where-Object Name -match 'proxy'

Beberapa kiat praktis.

• Dalam uji reproduksi (1), sadari keluarga pengaturan mana yang dibaca alat. curl.exe inbox Windows bisa menentukan proksi secara eksplisit dengan -x http://proxy:8080, dan untuk validasi TLS biasanya memakai penyimpanan sertifikat OS (Schannel). Invoke-WebRequest Windows PowerShell 5.1 mengikuti sisi .NET Framework (Opsi Internet secara bawaan); PowerShell 7 mengikuti sisi .NET (variabel lingkungan dulu). «curl berjalan tetapi aplikasi tidak» sendiri adalah petunjuk ketidaksesuaian antar keluarga konfigurasi.
• Jika target di (3) adalah layanan, periksa ulang (1) dan (2) di bawah akun yang sama dengan layanan. Pemeriksaan di sesi administrator sendiri bukan bukti apa yang dilihat LocalSystem.
• Dalam klasifikasi kesalahan (4), ambil Bab 6 (autentikasi) sebagai kandidat pertama untuk 407, Bab 7 (inspeksi TLS) untuk kesalahan sertifikat, dan «tidak mencapai proksi» (jalur, resolusi nama, firewall) untuk kehabisan waktu. Pola di mana penyebabnya adalah aturan masuk Firewall Windows daripada proksi dibahas di «Firewall Windows dan aplikasi bisnis».
• Jika Anda sampai (5) dan masih tidak ada jejak di log proksi, lalu lintas tidak pernah mencapai proksi. Curigai keputusan DIRECT PAC, daftar bypass, atau variabel lingkungan yang tertinggal, dan jika perlu konfirmasi tujuan sebenarnya dengan tangkapan paket («Tangkapan paket di Windows dalam praktik — memilih di antara pktmon, netsh trace, dan Wireshark»).

flowchart TB
    accTitle: Lima langkah untuk mengisolasi kegagalan proksi
    accDescr: Reproduksi di bawah akun yang sama, kumpulkan tiga keluarga pengaturan, identifikasi akun yang menjalankan, klasifikasikan kesalahan, lalu periksa log proksi
    s1["Reproduksi dengan curl"] --> s2["Kumpulkan tiga keluarga"]
    s2 --> s3["Identifikasi akun"]
    s3 --> s4["Klasifikasikan kesalahan"]
    s4 --> s5["Periksa log proksi"]
    s4 -.-> e407["407: autentikasi"]
    s4 -.-> ecert["Kesalahan sertifikat: inspeksi"]
    s4 -.-> eto["Kehabisan waktu: tidak pernah mencapai"]

Gambar 9: Jalani lima langkah berurutan. Kelas kesalahan memilih bab berikutnya.

9. Rekomendasi desain — jadikan aplikasi yang bisa «dikonfigurasi proksinya»

Balik prosedur penyelidikan dan itu menjadi pedoman desain di sisi aplikasi. Untuk aplikasi Windows yang akan Anda kirim ke lingkungan dengan proksi perusahaan, berikut disarankan.

1. Jadikan proksi dapat dikonfigurasi dari pengaturan aplikasi. Bawaannya «ikuti pengaturan OS». Di sebagian besar lingkungan bawaan cukup; hanya di lingkungan luar biasa — PAC tidak bisa dibaca, berjalan sebagai layanan, konfigurasi proksi khusus — Anda memungkinkan menentukan URL proksi, daftar bypass, dan «jangan pakai proksi» dari berkas pengaturan. HttpClientHandler.Proxy / UseProxy di Bagian 5.3 adalah titik implementasi.¹⁴
2. Tuliskan bagaimana tujuan internal (API, basis data, server lisensi, dan sejenisnya) diperlakukan sebagai pengecualian proksi. Taruh dalam bentuk yang bisa ditulis ke prosedur penerapan apakah dikecualikan oleh PAC DIRECT, daftar bypass, atau NO_PROXY. Aturan pencocokan NO_PROXY (tanpa wildcard, arti titik di depan) sering disalahpahami, jadi lampirkan contoh.⁷
3. Desain batas waktu dan percobaan ulang dengan asumsi melewati proksi. Jika proksi mati atau macet di autentikasi, implementasi yang menunggu batas waktu bawaan panjang membekukan UI dan operasi. Pisahkan batas waktu sambung yang lebih pendek, dan batasi percobaan ulang pada permintaan idempoten (rincian desain di «Jangan bungkus HttpClient dalam using»).
4. Catat «proksi mana yang dipakai». Jadikan aplikasi sendiri mampu menjawab pertanyaan pertama penyelidikan kegagalan.

Log seperti di (4) sudah efektif jika hanya mencatat hasil resolusi. Intinya menurunkan jalur dari pengaturan (handler) yang benar-benar Anda pakai untuk mengonfigurasi klien. Jika Anda mencatat HttpClient.DefaultProxy langsung, Anda akan mencatat nilai yang tidak cocok dengan jalur sebenarnya ketika handler menentukan Proxy secara eksplisit atau menaruh UseProxy = false.

using System.Net.Http;

// handler is the same instance used to create the HttpClient
// UseProxy=false is always direct. An explicit specification wins; otherwise DefaultProxy is used
var effectiveProxy = handler.UseProxy
    ? handler.Proxy ?? HttpClient.DefaultProxy
    : null;
var target = new Uri("https://api.example.com/v1/orders");
var route = effectiveProxy is null || effectiveProxy.IsBypassed(target)
    ? "DIRECT"
    : effectiveProxy.GetProxy(target)?.ToString() ?? "DIRECT";
logger.LogInformation("HTTP send {Target} route {Route} account {User}",
    target, route, Environment.UserName);

Jika saat mulai Anda sekali mencatat «jalur» dan «akun yang menjalankan» untuk tujuan utama, langkah (1) sampai (3) Bab 8 selesai hanya dengan membaca log. Ketika dikatakan «berjalan di peramban, tetapi…», bisa bilang dari sisi aplikasi «saya memakai pengaturan ini, dan jalur ini» adalah syarat aplikasi yang kuat terhadap masalah proksi.

flowchart TB
    accTitle: Jadikan proksi dapat dikonfigurasi dan catat jalurnya
    accDescr: Secara bawaan ikuti pengaturan OS, izinkan URL proksi eksplisit atau bypass atau tanpa proksi dari pengaturan aplikasi, dan catat rute yang benar-benar dipakai bersama akun yang menjalankan
    def["Bawaan: ikuti pengaturan OS"] --> exc{"Lingkungan luar biasa?"}
    exc -->|"PAC tidak terbaca / layanan / khusus"| cfg["Atur URL, bypass, atau tanpa proksi"]
    exc -->|"Kasus biasa"| os["Pakai bawaan OS"]
    cfg --> log["Catat rute dan akun"]
    os --> log

Gambar 10: Konfigurasikan ketika harus. Selalu catat jalur mana yang dipakai.

10. Ringkasan

• Pengaturan proksi Windows terbagi menjadi tiga keluarga — pengaturan WinINET per pengguna, pengaturan mesin WinHTTP, dan variabel lingkungan — dan mana yang dibaca diputuskan oleh aplikasi (tumpukan HTTP-nya) dan akun yang menjalankan.
• WinINET untuk aplikasi interaktif dan tidak didukung untuk dipakai di layanan; pemakaian layanan adalah pekerjaan WinHTTP (netsh winhttp). Untuk «berjalan secara manual tetapi tidak sebagai layanan», curigai dulu perbedaan akun yang menjalankan.
• netsh winhttp set proxy adalah pengaturan statis dan tidak menangani PAC, deteksi otomatis, atau autentikasi. Di jaringan yang dioperasikan PAC Anda perlu memutuskan bagaimana klien yang tidak bisa membaca PAC akan diperlakukan.
• FindProxyForURL PAC mengembalikan proksi atau DIRECT per URL. WPAD hanya bekerja di jaringan yang punya pengaturan DHCP/DNS.
• Bawaan .NET Framework adalah Opsi Internet akun yang menjalankan (bisa ditimpa dengan defaultProxy); .NET (Core dan seterusnya) adalah variabel lingkungan lalu pengaturan proksi pengguna. Penentuan eksplisit (HttpClientHandler.Proxy) selalu prioritas tertinggi.
• 407 adalah kesalahan autentikasi proksi; di aplikasi yang berjalan di bawah akun layanan penyebab tipikal adalah «kredensial bawaan» menjadi orang lain.
• Proksi inspeksi TLS mengandaikan distribusi sertifikat CA internal, dan jawaban yang benar atas kesalahan sertifikat adalah distribusi ke penyimpanan sertifikat, bukan menonaktifkan validasi. Lalu lintas yang di-pin perlu pengecualian.
• Isolasi secara mekanis dalam urutan «reproduksi → kumpulkan tiga keluarga pengaturan → identifikasi akun yang menjalankan → klasifikasikan kesalahan → log proksi». Di sisi aplikasi, desain yang «bisa mengonfigurasi proksi, dan mencatat jalur yang dipakai» adalah pencegahan terbaik.

Lain kali Anda dikonsultasikan dengan «hanya aplikasi bisnis yang tidak tersambung», tanyakan ini dulu.

Di bawah akun siapa aplikasi itu berjalan, dan keluarga mana dari tiga keluarga pengaturan proksi yang dibacanya?

Satu pertanyaan itu mengubah pintu masuk penyelidikan secara besar.

Artikel terkait

• Jangan bungkus HttpClient dalam using — komunikasi HTTP praktis di aplikasi bisnis C# (pola pembuatan, batas waktu, percobaan ulang)
• Tangkapan paket di Windows dalam praktik — memilih di antara pktmon, netsh trace, dan Wireshark
• Firewall Windows dan aplikasi bisnis — daftarkan aturan masuk dari pemasang
• Cara membangun dan mengoperasikan layanan Windows — dari memilih antara Penjadwal Tugas dan layanan hingga menjadikan BackgroundService sebagai layanan Windows
• NTLM dan Kerberos dijelaskan dengan diagram — mengapa autentikasi jatuh ke NTLM
• Penyimpanan sertifikat Windows dalam praktik — pengguna atau komputer, mana yang harus dipakai?

Area konsultasi terkait

KomuraSoft LLC menangani penyelidikan gangguan komunikasi aplikasi Windows di lingkungan proksi perusahaan, proksi berautentikasi, dan inspeksi TLS — «berjalan di mesin pengembangan tetapi tidak berkomunikasi di jaringan pelanggan», «setelah dijadikan layanan tidak lagi mencapai API eksternal» — dan konsultasi tentang desain komunikasi aplikasi bisnis yang mengasumsikan lingkungan proksi (butir pengaturan, batas waktu, desain log). Tidak apa-apa mulai dari merapikan langkah reproduksi dan cara mengumpulkan log.

• Pengembangan aplikasi Windows
• Investigasi bug dan akar masalah
• Konsultasi teknis dan tinjauan desain
• Hubungi kami

Tautan referensi

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Peramban tersambung, tetapi hanya aplikasi bisnis yang tidak melewati proksi perusahaan. Mengapa?

Peramban membaca pengaturan proksi per-pengguna WinINET, tetapi aplikasi bisnis tidak selalu membaca pengaturan yang sama. Aplikasi yang berjalan sebagai layanan Windows, atau di bawah akun lain, meninjau pengaturan yang terlihat dari akun itu, pengaturan mesin WinHTTP, atau variabel lingkungan. Identifikasi dulu akun yang menjalankan, lalu periksa pengaturan proksi yang terlihat dari akun itu baik dengan netsh winhttp show proxy maupun di pengaturan pengguna. Jika Anda bisa mereproduksi dengan curl.exe atau sejenisnya di akun yang sama pada mesin yang sama, Anda bisa memperlakukannya sebagai ketidaksesuaian antar keluarga konfigurasi, bukan masalah khusus aplikasi.

Saya mengatur netsh winhttp set proxy, tetapi lalu lintas aplikasi tidak berubah. Mengapa?

Yang diatur netsh winhttp adalah bawaan mesin WinHTTP. Itu tidak memengaruhi peramban atau aplikasi interaktif yang membaca WinINET, atau HttpClient .NET (Core dan seterusnya), yang lebih mengutamakan variabel lingkungan. netsh winhttp set proxy juga pengaturan statis; tidak menangani konfigurasi otomatis PAC, deteksi otomatis, atau autentikasi proksi. Anda perlu dulu memastikan tumpukan HTTP mana yang dipakai aplikasi target dan dari keluarga konfigurasi mana ia meresolusi proksi.

Pengaturan proksi mana yang dibaca aplikasi .NET?

.NET Framework secara bawaan memakai Opsi Internet (setara WinINET) akun yang menjalankan, dan bisa ditimpa dengan elemen system.net/defaultProxy di app.config. HttpClient pada .NET (Core dan seterusnya) membaca variabel lingkungan seperti HTTP_PROXY, HTTPS_PROXY, dan NO_PROXY lebih dulu, dan jika tidak didefinisikan jatuh ke pengaturan proksi pengguna Windows. Dalam kedua kasus, HttpClientHandler.Proxy eksplisit unggul. Urutan resolusi bawaan berbeda antara Framework dan Core dan seterusnya, jadi perilaku proksi perlu diperiksa ulang saat migrasi.

Apa yang harus diperiksa ketika 407 Proxy Authentication Required dikembalikan?

407 adalah tanda bahwa proksi itu sendiri menuntut autentikasi; itu lain dari kesalahan autentikasi server tujuan (401). Pastikan dulu skema yang diminta proksi (Negotiate, NTLM, Basic) dari header Proxy-Authenticate, dan di .NET kirim kredensial dengan HttpClientHandler.DefaultProxyCredentials atau WebProxy.UseDefaultCredentials. Di aplikasi yang berjalan di bawah akun layanan, «kredensial bawaan» menjadi milik akun layanan itu, jadi insiden tipikal adalah berhasil untuk pengguna interaktif lalu 407 begitu dijadikan layanan. Periksa juga di log sisi proksi sebagai siapa ia mengautentikasi.

Proksi inspeksi TLS menghasilkan kesalahan sertifikat. Bolehkah saya menonaktifkan validasi sertifikat?

Menonaktifkannya tidak disarankan. Proksi inspeksi TLS mendekripsi lalu lintas lalu menyajikan ke klien sertifikat yang ditandatangani ulang oleh CA-nya sendiri, sehingga validasi gagal jika sertifikat CA itu tidak ada di akar tepercaya. Perbaikan yang benar adalah mendistribusikan sertifikat CA internal ke penyimpanan sertifikat Windows (biasanya Otoritas Sertifikasi Akar Tepercaya komputer lokal). Menonaktifkan validasi di kode berarti serangan man-in-the-middle tidak terdeteksi ketika aplikasi dipakai di jaringan luar, dan kerentanan tetap ada.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.