Proxy debug menjadi buta saat VPN kantor tersambung

Alat perekam bekerja sepanjang pagi, tunnel tersambung, lalu ia diam. Putuskan dan ia mulai lagi. Naluri pertama adalah VPN merusak proxy, padahal konfigurasi proxy tidak berubah. Yang berubah adalah konfigurasi mana yang kini dibaca aplikasi: entri tunnel bisa membawa pengaturan proxy sendiri, profil terkelola bisa mengaktifkan lagi konfigurasi otomatis, dan sebagian runtime hanya membaca sebagian dari yang disediakan sistem operasi. Baca nilai per koneksi sebelum menyentuh nilai global.

Windows menyimpan proxy per koneksi

Di Opsi Internet ada dua lapisan yang tampak sama di dialog. Setelan jaringan lokal berlaku untuk koneksi lokal biasa, sedangkan entri dial-up atau VPN menyimpan salinannya sendiri di HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections, disimpan sebagai nilai biner. Menulis nilai registri global yang biasa tidak memperbarui salinan itu.

Persis seperti itulah sebuah alat berperilaku benar sebelum tersambung dan salah sesudahnya, tanpa perubahan yang terlihat di pengaturannya. Dialog yang Anda tatap adalah panel jaringan lokal. Itu benar, dan itu tidak relevan. Entri yang sebenarnya dipakai Windows adalah entri yang dibuat untuk tunnel.

Cara yang didukung untuk mengubah satu entri adalah API opsi koneksi WinINET: isi INTERNET_PER_CONN_OPTION_LIST dengan nama koneksi, flag, server proxy, dan daftar pengecualian, terapkan, lalu segarkan. Untuk pemeriksaan cepat, buka dialog pengaturan entri tunnel itu sendiri dan bandingkan panel proxinya dengan panel jaringan lokal; perbedaannya biasanya jelas begitu Anda tahu ke mana harus melihat.

PAC terkelola bisa menyalakan dirinya lagi

Di macOS, skrip konfigurasi proxy otomatis dan penemuan otomatis proxy adalah properti sebuah layanan jaringan, bukan properti mesin. Profil konfigurasi bisa mewajibkannya, sehingga keduanya muncul lagi setelah Anda menghapus centangnya, dan setiap permintaan lalu dikirim ke proxy yang dipilih skrip.

Periksa dan, jika Anda berwenang, matikan kedua sakelar itu untuk layanan yang membawa lalu lintas:

networksetup -setautoproxystate "Wi-Fi" off
networksetup -setproxyautodiscovery "Wi-Fi" off
scutil --proxy

Gunakan nama layanan yang sebenarnya, bukan tebakan. Laptop dengan Wi-Fi dan adaptor Ethernet USB sekaligus punya dua layanan seperti itu, dan hanya satu yang membawa lalu lintas Anda. scutil --proxy mencetak nilai untuk layanan utama saat ini. Bandingkan keluaran itu dengan yang Anda sunting sebelum menyimpulkan profil menang.

Arahkan alat ke hulu yang sebenarnya

Jika skrip memuat proxy kantor, bacalah dan masukkan alamat yang sama sebagai proxy eksternal di dalam alat perekam. Alat itu lalu meneruskan ke hulu yang sebenarnya, yang memang diharapkan proxy kantor, dan ia tetap berada di jalur permintaan alih-alih berkelahi dengan kebijakan.

Inilah langkah yang membuat Anda tetap men-debug alih-alih mengonfigurasi ulang.

Dorong proxy ke dalam tunnel

Klien berbasis OpenVPN dapat menerima opsi proxy yang berlaku setelah tunnel berdiri, yang praktis ketika klien memiliki rutenya:

dhcp-option HTTPPROXY 127.0.0.1:8888
dhcp-option HTTPSPROXY 127.0.0.1:8888

Hanya klien yang menghormati opsi itu yang akan memakainya, dan opsi itu menuliskan port pendengar Anda secara keras ke dalam profil. Perlakukan itu sebagai kemudahan laboratorium, bukan standar penerapan, karena pengiriman profil berikutnya akan menghapusnya.

Sebagian klien tidak pernah membaca proxy sistem

Firefox menyimpan pengaturan proxinya sendiri, karena itu kadang ia tetap merekam ketika peramban yang memakai proxy sistem sudah tidak. Klien .NET lama yang tidak memahami konfigurasi otomatis tersambung langsung di mana pun ia berjalan, sehingga halaman yang dimuat lewat entri tunnel bisa tetap gagal di dalam aplikasi.

Alat jaringan juga punya penyebabnya sendiri. Sesi FTP yang menggantung lewat tunnel atau tethering ponsel sering kali merupakan masalah mode aktif versus pasif yang dinegosiasikan klien, dan tidak ada pengaturan proxy yang mengubahnya.

Baca konfigurasinya, bukan sakelarnya

Bekerjalah dengan urutan ini: nilai proxy milik entri tunnel, status PAC dan penemuan otomatis per layanan, lalu penanganan proxy milik aplikasi itu sendiri. Berhenti pada yang pertama yang berbeda dari dugaan Anda.

Setiap kasus di sini adalah masalah prioritas konfigurasi. Tidak ada yang merupakan tunnel yang merusak alat Anda.