mitmproxy, DevTools, Gradle: tiga lapisan di balik VPN

VPN tersambung, dan tiga alat yang tidak saling terkait gagal dengan tiga cara berbeda pada sore yang sama. mitmproxy berhenti melihat permintaan, Chrome menolak debugger, dan Gradle melempar BindException saat mengikat soket lokal. Dugaan bersama adalah terowongan memblokir localhost. Itu tidak mungkin: 127.0.0.1 ditangani di dalam kernel dan tidak pernah mencapai adaptor, apalagi gateway.

Tiga lapisan, tiga kerusakan berbeda

Yang berubah dengan klien bukan rute ke loopback. Yang berubah adalah proxy lokal, penyimpanan kepercayaan mesin, dan filter paket, dan masing-masing merusak bagian berbeda dari alur kerja pengembang. Menempatkan gejala di baris yang tepat adalah sebagian besar diagnosis:

Hampir setiap laporan seperti ini dimulai dari baris terakhir dan naik ke atas, yang justru terbalik. Terowongan adalah satu-satunya lapisan yang terbukti tidak dapat melihat lalu lintas loopback, jadi paling tidak mencurigakan. Mulailah dari apa yang diikat proses, lalu tanyakan sertifikat apa yang dipercayainya, dan baru setelah itu lihat kebijakan di mesin.

Mulailah dari pendengar, bukan terowongan

Ketika proxy di 127.0.0.1:8080 berhenti menerima lalu lintas, salah satu dari tiga hal terjadi: tidak pernah mulai, mengikat port lain, atau filter menjatuhkan koneksi loopback. Mendaftar soket yang mendengarkan menjawabnya dengan satu perintah, dan juga menunjukkan proses mana yang memiliki port ketika dua alat berbeda pendapat tentang siapa yang lebih dulu.

Alamat lokal dalam pencarian rute menegaskan hal yang sama dari arah lain. ip route get terhadap tujuan loopback melaporkan perangkat loopback, tidak pernah terowongan, yang merupakan kalimat berguna untuk disiapkan ketika seseorang mengusulkan perubahan perutean sebagai solusi.

Lapisan proxy: lingkungan bukan konfigurasi

Banyak klien korporat menjalankan proxy HTTP dan mengharapkan aplikasi memakainya. Menetapkan HTTPS_PROXY di shell memperbaiki alat baris perintah yang mematuhinya, dan tidak melakukan apa pun untuk alat yang membaca berkas pengaturannya sendiri. Gradle, Selenium, dan gRPC masing-masing memeriksa konfigurasinya sendiri, dan proxy yang diekspor di satu terminal tidak terlihat oleh daemon yang dijalankan IDE.

Perkakas kontainer adalah tempat biasa hal ini menjadi terlihat. Loopback kontainer adalah miliknya sendiri, jadi 127.0.0.1 di dalam kontainer tidak pernah berarti proxy host; alamat host atau pengaturan jaringan host diperlukan. Perbaikan yang berhasil di shell dan gagal di build biasanya baris ini, bukan terowongan.

Lapisan kepercayaan: alat membaca penyimpanan lain

Intersepsi adalah perubahan kedua, dan menghasilkan galat paling menyesatkan. Klien menyajikan sertifikatnya sendiri untuk koneksi yang diperiksa, sehingga peramban yang memercayai akar korporat berhasil sementara alat dengan penyimpanan CA bawaan gagal. requests Python melalui certifi adalah kasus klasik: penyimpanan sistem operasi bisa benar dan permintaan tetap gagal, karena runtime itu tidak pernah membacanya. Teks galat jarang menyebut intersepsi, itulah sebabnya baris ini salah didiagnosis sebagai titik akhir yang rusak.

Bandingkan apa yang sebenarnya disajikan titik akhir dengan apa yang divalidasi alat. openssl s_client menunjukkan rantai yang dikirim server; keluaran validasi alat itu sendiri menunjukkan apa yang diputuskannya. Ketika keduanya tidak cocok, REQUESTS_CA_BUNDLE atau SSL_CERT_FILE adalah tuas untuk runtime itu, dan akar korporat seharusnya berada di penyimpanan yang dibaca runtime itu, bukan di lokasi global yang hanya dipatuhi sebagian alat.

Perubahan versi yang memperbaiki galat SSL adalah bukti tentang kebijakan kepercayaan dan sandi, bukan tentang VPN. Penurunan versi Python yang membuat klien SOAP berfungsi mengubah penyimpanan CA bawaan dan pengaturan TLS bawaan; jalur jaringan tidak bergerak.

Lapisan filter: ia juga dapat menjatuhkan loopback

Perubahan ketiga adalah filter paket, dan sebagian produk memasang aturan yang menjatuhkan lalu lintas yang tidak masuk ke terowongan. Pendengar lokal bisa ikut terkena. Itu mengubah soket yang berfungsi menjadi koneksi yang ditolak atau habis waktu, dan galat yang dihasilkan tampak seperti bug di aplikasi, bukan kebijakan di mesin.

Kepemilikan port adalah separuh lain dari lapisan ini. BindException berarti soket tidak dapat dibuka, yang merupakan kegagalan berbeda dari koneksi yang ditolak. Periksa apakah proses lain sudah memegang port sebelum menyalahkan filter, lalu cari aturan yang menjatuhkan lalu lintas lokal dan tambahkan izin tersempit yang didukung produk. Dua alat yang bersaing untuk port debug yang sama menghasilkan pesan yang persis sama dengan pemblokiran kebijakan, dan hanya satu di antaranya diperbaiki oleh perubahan firewall.

Port debug Chrome gagal dalam keluarga yang sama. Peramban mulai, pengandar tidak dapat mencapai titik akhir DevTools, dan pesannya menyebut DevTools, bukan jaringan. Bendera peluncuran tambahan dan manajer pengandar yang berlebihan mengubah proses mana yang memiliki port, itulah sebabnya menghapusnya kadang tampak memperbaiki VPN.

Perbaiki lapisan yang gagal

Perbaiki lapisan yang gagal, bukan terowongan. Pendengar loopback yang tidak terjangkau perlu diperbaiki pendengar atau portnya. Sertifikat yang tidak tepercaya memerlukan akar korporat dipasang di tempat runtime tertentu itu mencari, dengan pengecualian dijaga sempit. Filter yang menjatuhkan lalu lintas lokal memerlukan aturan izin khusus, bukan filter yang dinonaktifkan, karena menonaktifkan juga membuka kembali semua hal lain yang dilindunginya.

Menyambung ulang VPN tidak menguji satu pun dari lapisan ini. Itu hanya menjalankan ulang perubahan yang merusaknya, itulah sebabnya tiga kegagalan yang sama kembali setelah setiap penyambungan ulang dan hilang setelah setiap boot ulang yang membiarkan klien tidak aktif.