Split tunneling biasanya gagal dalam satu daripada dua cara. Sama ada trafik yang sepatutnya berada di dalam terowong memutarinya, atau trafik yang sepatutnya kekal di luar ditarik masuk. Kegagalan peraturan usang ialah jenis pertama, dan ia lebih mengelirukan, kerana peraturan itu dikuatkuasakan tepat seperti yang ditulis. Apa yang berubah ialah destinasi: perkhidmatan kini menjawab pada alamat yang peraturan itu tidak pernah namakan, dan tiada apa yang salah di dalam terowong.

Apa yang ditetapkan oleh peraturan dan apa yang dikembalikan oleh DNS

Peraturan split tunnel ialah pernyataan statik tentang destinasi, biasanya dinyatakan sebagai prefiks, laluan atau senarai alamat. Ia dinilai terhadap destinasi paket pada masa penghantaran. Nama hos ialah carian yang mengembalikan satu set alamat dengan jangka hayat dan cache, dan jawapannya boleh berbeza mengikut resolver, jenis pertanyaan dan minit.

Kedua-dua objek itu tidak pernah berunding antara satu sama lain. Peraturan terus sepadan dengan prefiks yang diberikan, perkhidmatan terus menukar alamat yang dikeluarkannya, dan jurang antara mereka melebar secara senyap. Itulah sebabnya gejala muncul selepas migrasi penyedia atau pembaharuan sijil dan bukan selepas perubahan konfigurasi. Tiada siapa mengedit terowong, jadi tiada siapa melihat terowong, dan diagnosis hanyut ke arah aplikasi dan bukan dasar.

Tiga cara padanan itu pecah

Kes yang jelas ialah perkhidmatan yang berpindah: pengendali memberinya alamat baharu, DNS mengikut, dan pengecualian tidak. Yang kedua ialah keluarga alamat yang tidak pernah diliputi oleh peraturan, yang berlaku apabila nama mula mengembalikan rekod AAAA yang diabaikan oleh pengecualian khusus IPv4. Yang ketiga ialah perbezaan resolver: paparan dalaman dan paparan awam boleh mengembalikan alamat berbeza untuk nama yang sama, jadi alamat yang digunakan oleh aplikasi anda bukan yang anda uji.

Sambungan yang di-cache ialah varian keempat dan mudah terlepas pandang. Aplikasi mungkin masih bercakap dengan alamat yang diselesaikannya sejam lalu, yang bermaksud carian baharu anda dan socket terbukanya tidak bersetuju tentang di mana perkhidmatan itu berada.

Baca destinasi yang benar-benar digunakan oleh aplikasi

Tanya sistem pengendalian dan jadual socket, bukan tab pelayar. Carian menjawab apa yang diselesaikan oleh nama itu sekarang, dan jadual socket menunjukkan alamat yang disambungkan oleh proses itu, yang mungkin lebih lama. Jalankan kedua-duanya sebelum membentuk teori, kerana perbezaan antara keduanya sendiri ialah jawapan dalam kira-kira separuh kes.

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

Kemudian bandingkan dengan apa yang diliputi oleh peraturan. Jika alamat semasa berada di luar pengecualian dan permintaan masih gagal, anda telah menemui puncanya tanpa menyentuh konfigurasi terowong. Jika aplikasi disambungkan kepada alamat yang sepadan dengan peraturan dan permintaan masih gagal, masalahnya berada di sebalik terowong dan ini ialah penyiasatan yang salah.

Baiki mekanisme, bukan gejala

Jika produk menyokong pengarahan berasaskan domain yang diselenggara, gunakannya dan ikut tingkah laku penyegaran dan skopnya yang didokumenkan. Itu menggantikan tekaan statik dengan jawapan yang diselenggara, dengan kos bergantung pada ciri itu berfungsi seperti didokumenkan.

Jika reka bentuk bergantung pada senarai statik, berikannya pemilik dan pelan kemas kini. Pelan itu harus menyatakan bagaimana alamat ditemui, siapa yang meluluskan perubahan dan betapa pantas senarai itu dijangka mengikut migrasi penyedia. Senarai tanpa pemilik ialah gangguan masa depan dengan punca yang diketahui.

Jangan luaskan pengecualian kepada rangkaian jiran yang besar hanya untuk menangkap setiap alamat yang anda lihat semasa ujian pendek. Itu bukan pembaikan; itu perubahan kekal pada sempadan keselamatan, dan ia akan membenarkan perkhidmatan tidak berkaitan memintas terowong secara senyap selagi peraturan itu wujud.

Sahkan kedua-dua separuh niat

Reka bentuk split tunnel mempunyai dua niat, dan pembaikan harus mengekalkan kedua-duanya. Perkhidmatan yang dilindungi mesti melalui terowong, dan kategori yang dikecualikan mesti terus memutarinya. Uji sambungan baharu ke destinasi yang dibaiki, kemudian uji sesuatu yang sepatutnya kekal di luar.

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

Catat alamat baharu, mekanisme yang anda pilih dan tarikh. Nota itulah yang menghalang orang seterusnya daripada membuat kesimpulan bahawa VPN mengabaikan konfigurasinya sendiri secara rawak.

Artikel berkaitan