Proksi nyahpepijat menjadi buta apabila VPN korporat disambung

Alat tangkapan berfungsi sepanjang pagi, terowong disambung, dan ia menjadi senyap. Putuskan sambungan dan ia bermula semula. Naluri pertama ialah VPN merosakkan proksi, tetapi konfigurasi proksi sebenarnya tidak berubah. Yang berubah ialah konfigurasi mana yang dibaca aplikasi sekarang: entri terowong boleh membawa tetapan proksi sendiri, profil terurus boleh menghidupkan semula konfigurasi automatik, dan sesetengah runtime hanya membaca sebahagian daripada apa yang ditawarkan sistem pengendalian. Baca nilai setiap sambungan sebelum menyentuh nilai global.

Windows menyimpan proksi bagi setiap sambungan

Dalam pilihan Internet ada dua lapisan yang kelihatan sama dalam dialog. Tetapan rangkaian tempatan terpakai pada sambungan tempatan biasa, manakala entri dail atau VPN menyimpan salinannya sendiri di bawah HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections, disimpan sebagai nilai binari. Menulis nilai daftar global yang biasa tidak mengemas kini salinan itu.

Begitulah tepatnya alat berkelakuan betul sebelum bersambung dan salah selepasnya, tanpa sebarang perubahan yang kelihatan pada tetapannya. Dialog yang anda tenung ialah panel rangkaian tempatan. Ia betul, dan ia tidak relevan. Entri yang Windows benar-benar gunakan ialah entri yang dicipta untuk terowong itu.

Cara yang disokong untuk menukar satu entri ialah API pilihan sambungan WinINET: isi INTERNET_PER_CONN_OPTION_LIST dengan nama sambungan, bendera, pelayan proksi dan senarai pengecualian, gunakan, kemudian muat semula. Untuk pemeriksaan pantas, buka dialog tetapan entri terowong itu sendiri dan bandingkan panel proksinya dengan panel rangkaian tempatan; perbezaannya biasanya jelas sebaik sahaja anda tahu ke mana perlu dilihat.

PAC terurus boleh menghidupkan dirinya semula

Dalam macOS, skrip konfigurasi proksi automatik dan penemuan automatik proksi ialah sifat sesuatu perkhidmatan rangkaian, bukan sifat mesin. Profil konfigurasi boleh mewajibkannya, jadi ia muncul semula selepas anda nyah tanda, dan setiap permintaan kemudian dihantar kepada proksi yang dipilih oleh skrip.

Periksa dan, jika anda diberi kuasa, matikan kedua-dua suis itu untuk perkhidmatan yang membawa trafik:

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

Gunakan nama perkhidmatan sebenar dan bukan tekaan. Komputer riba yang mempunyai Wi-Fi dan penyesuai Ethernet USB sekali gus mempunyai dua perkhidmatan sedemikian, dan hanya satu membawa trafik anda. scutil --proxy mencetak nilai untuk perkhidmatan utama semasa. Bandingkan output itu dengan apa yang anda sunting sebelum membuat kesimpulan bahawa profil itu menang.

Halakan alat itu ke hulu yang sebenar

Jika skrip mengandungi proksi korporat, bacanya dan masukkan alamat yang sama sebagai proksi luaran di dalam alat tangkapan. Alat itu kemudian memajukan ke hulu yang sebenar, iaitu apa yang dijangka oleh proksi korporat, dan ia kekal dalam laluan permintaan dan bukannya bergaduh dengan dasar.

Itulah langkah yang mengekalkan anda dalam nyahpepijat dan bukan dalam konfigurasi semula.

Tolak proksi ke dalam terowong

Klien berasaskan OpenVPN boleh menerima pilihan proksi yang terpakai sebaik terowong naik, yang memudahkan apabila laluan dimiliki oleh klien:

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

Hanya klien yang menghormati pilihan itu akan menggunakannya, dan ia menulis port pendengaran anda secara keras ke dalam profil. Anggapnya kemudahan makmal dan bukan piawaian penggunaan, kerana penolakan profil seterusnya akan membuangnya.

Sesetengah klien tidak pernah membaca proksi sistem

Firefox menyimpan tetapan proksinya sendiri, sebab itulah kadangkala ia terus menangkap apabila pelayar yang menggunakan proksi sistem sudah tidak. Klien .NET lama yang tidak memahami konfigurasi automatik bersambung terus di mana-mana ia berjalan, jadi halaman yang dimuatkan melalui entri terowong masih boleh gagal di dalam aplikasi.

Alat rangkaian juga mempunyai puncanya sendiri. Sesi FTP yang tergantung melalui terowong atau tethering telefon selalunya masalah mod aktif berbanding pasif yang dirundingkan oleh klien, dan tiada tetapan proksi akan mengubahnya.

Baca konfigurasi, bukan suis

Bekerja dalam urutan ini: nilai proksi entri terowong itu sendiri, keadaan PAC dan penemuan automatik bagi setiap perkhidmatan, kemudian pengendalian proksi aplikasi itu sendiri. Berhenti pada yang pertama yang berbeza daripada andaian anda.

Setiap kes di sini ialah masalah keutamaan konfigurasi. Tiada satu pun terowong yang merosakkan alat anda.