mitmproxy, DevTools, Gradle: tiga lapisan di sebalik VPN

VPN bersambung, dan tiga alat tidak berkaitan gagal dalam tiga cara berbeza pada petang yang sama. mitmproxy berhenti melihat permintaan, Chrome menolak penyahpepijat, dan Gradle melontar BindException semasa mengikat soket tempatan. Syak bersama ialah terowong menyekat localhost. Ia tidak boleh: 127.0.0.1 dikendalikan di dalam kernel dan tidak pernah sampai ke penyesuai, apatah lagi get laluan.

Tiga lapisan, tiga kerosakan berbeza

Apa yang berubah dengan klien bukanlah laluan ke loopback. Ia ialah proksi tempatan, stor kepercayaan mesin dan penapis paket, dan setiap satu memecahkan bahagian berbeza aliran kerja pembangun. Meletakkan gejala pada baris yang betul ialah sebahagian besar diagnosis:

Hampir setiap laporan seperti ini bermula pada baris terakhir dan bergerak ke atas, yang terbalik. Terowong ialah satu-satunya lapisan yang terbukti tidak dapat melihat trafik loopback, jadi ia patut paling kurang disyaki. Mulakan dengan apa yang diikat oleh proses, kemudian tanya sijil mana yang dipercayainya, dan hanya selepas itu lihat dasar pada mesin.

Mulakan dengan pendengar, bukan terowong

Apabila proksi pada 127.0.0.1:8080 berhenti menerima trafik, salah satu daripada tiga perkara berlaku: ia tidak pernah bermula, ia mengikat port lain, atau penapis menggugurkan sambungan loopback. Menyenaraikan soket yang mendengar menjawabnya dengan satu arahan, dan juga menunjukkan proses mana yang memiliki port apabila dua alat tidak bersetuju siapa yang dahulu.

Alamat tempatan dalam carian laluan mengesahkan perkara yang sama dari arah lain. ip route get terhadap destinasi loopback melaporkan peranti loopback, tidak pernah terowong, yang merupakan ayat berguna untuk disediakan apabila seseorang mencadangkan perubahan penghalaan sebagai penyelesaian.

Lapisan proksi: persekitaran bukan konfigurasi

Banyak klien korporat menjalankan proksi HTTP dan menjangka aplikasi menggunakannya. Menetapkan HTTPS_PROXY dalam shell membaiki alat baris arahan yang mematuhinya, dan tidak melakukan apa-apa untuk alat yang membaca fail tetapannya sendiri. Gradle, Selenium dan gRPC masing-masing merujuk konfigurasinya sendiri, dan proksi yang dieksport dalam satu terminal tidak kelihatan kepada daemon yang dimulakan oleh IDE.

Alat kontena ialah tempat biasa perkara ini menjadi kelihatan. Loopback kontena adalah miliknya sendiri, jadi 127.0.0.1 di dalam kontena tidak pernah bermaksud proksi hos; alamat hos atau tetapan rangkaian hos diperlukan. Pembetulan yang berfungsi dalam shell dan gagal dalam build biasanya baris ini, bukan terowong.

Lapisan kepercayaan: alat membaca stor lain

Pemintasan ialah perubahan kedua, dan ia menghasilkan ralat paling mengelirukan. Klien membentangkan sijilnya sendiri untuk sambungan yang diperiksa, jadi pelayar yang mempercayai akar korporat berjaya manakala alat dengan stor CA terbina gagal. requests Python melalui certifi ialah kes klasik: stor sistem pengendalian boleh betul dan permintaan tetap gagal, kerana runtime itu tidak pernah membacanya. Teks ralat jarang menyebut pemintasan, sebab itulah baris ini salah didiagnosis sebagai titik hujung yang rosak.

Bandingkan apa yang sebenarnya dibentangkan oleh titik hujung dengan apa yang disahkan oleh alat. openssl s_client menunjukkan rantaian yang dihantar oleh pelayan; output pengesahan alat itu sendiri menunjukkan apa yang diputuskannya. Apabila kedua-duanya tidak sepadan, REQUESTS_CA_BUNDLE atau SSL_CERT_FILE ialah tuas untuk runtime itu, dan akar korporat sepatutnya berada dalam stor yang dibaca oleh runtime itu, bukan di lokasi global yang hanya dihormati oleh sesetengah alat.

Perubahan versi yang membaiki ralat SSL ialah bukti tentang dasar kepercayaan dan sifer, bukan tentang VPN. Penurunan versi Python yang membuat klien SOAP berfungsi mengubah stor CA terbina dan tetapan TLS lalai; laluan rangkaian tidak bergerak.

Lapisan penapis: ia juga boleh menggugurkan loopback

Perubahan ketiga ialah penapis paket, dan sesetengah produk memasang peraturan yang menggugurkan trafik yang tidak masuk ke terowong. Pendengar tempatan boleh disertakan. Itu menjadikan soket yang berfungsi sebagai sambungan yang ditolak atau tamat masa, dan ralat yang terhasil kelihatan seperti pepijat dalam aplikasi, bukan dasar pada mesin.

Pemilikan port ialah separuh lagi lapisan ini. BindException bermaksud soket tidak dapat dibuka, yang merupakan kegagalan berbeza daripada sambungan yang ditolak. Semak sama ada proses lain sudah memegang port sebelum menyalahkan penapis, kemudian cari peraturan yang menggugurkan trafik tempatan dan tambah kebenaran paling sempit yang disokong oleh produk. Dua alat yang bersaing untuk port nyahpepijat yang sama menghasilkan mesej yang sama seperti sekatan dasar, dan hanya satu daripadanya dibaiki oleh perubahan tembok api.

Port nyahpepijat Chrome gagal dalam keluarga yang sama. Pelayar bermula, pemacu tidak dapat mencapai titik hujung DevTools, dan mesej menamakan DevTools bukan rangkaian. Bendera pelancaran tambahan dan pengurus pemacu berlebihan mengubah proses mana yang memiliki port, sebab itulah membuangnya kadang-kadang kelihatan membaiki VPN.

Baiki lapisan yang gagal

Baiki lapisan yang gagal, bukan terowong. Pendengar loopback yang tidak dapat dicapai perlu dibetulkan pendengar atau portnya. Sijil yang tidak dipercayai memerlukan akar korporat dipasang di tempat runtime tertentu itu melihat, dengan pengecualian dijaga sempit. Penapis yang menggugurkan trafik tempatan memerlukan peraturan kebenaran khusus bukan penapis yang dilumpuhkan, kerana melumpuhkannya juga membuka semula semua yang lain yang dilindunginya.

Menyambung semula VPN tidak menguji mana-mana lapisan ini. Ia hanya menjalankan semula perubahan yang merosakkannya, sebab itulah tiga kegagalan yang sama kembali selepas setiap sambungan semula dan hilang selepas setiap but semula yang membiarkan klien tidak aktif.