Mengapa aturan split tunnel Anda berhenti cocok dengan sebuah layanan

Split tunneling biasanya gagal dengan salah satu dari dua cara. Entah lalu lintas yang seharusnya berada di dalam terowongan justru memutarinya, atau lalu lintas yang seharusnya tetap di luar malah ditarik masuk. Kegagalan aturan usang adalah jenis pertama, dan itulah yang lebih membingungkan, karena aturan dijalankan persis seperti tertulis. Yang berubah adalah tujuan: layanan kini menjawab pada alamat yang tidak pernah disebut aturan, dan tidak ada yang salah di dalam terowongan.

Apa yang ditetapkan aturan dan apa yang dikembalikan DNS

Aturan split tunnel adalah pernyataan statis tentang tujuan, biasanya dinyatakan sebagai prefiks, rute, atau daftar alamat. Aturan itu dievaluasi terhadap tujuan paket pada saat pengiriman. Nama host adalah pencarian yang mengembalikan sekumpulan alamat dengan masa hidup dan cache, dan jawabannya bisa berbeda menurut resolver, jenis kueri, dan menit.

Kedua objek itu tidak pernah bernegosiasi satu sama lain. Aturan terus mencocokkan prefiks yang diberikan, layanan terus mengganti alamat yang dibagikannya, dan celah di antara keduanya melebar diam-diam. Itulah sebabnya gejalanya muncul setelah migrasi penyedia atau pembaruan sertifikat, bukan setelah perubahan konfigurasi. Tidak ada yang menyunting terowongan, jadi tidak ada yang melihat terowongan, dan diagnosis bergeser ke aplikasi alih-alih kebijakan.

Tiga cara kecocokan rusak

Kasus yang jelas adalah layanan yang berpindah: operator memberinya alamat baru, DNS mengikuti, dan pengecualiannya tidak. Yang kedua adalah keluarga alamat yang tidak pernah dicakup aturan, yang terjadi ketika sebuah nama mulai mengembalikan catatan AAAA yang diabaikan pengecualian khusus IPv4. Yang ketiga adalah perbedaan resolver: tampilan internal dan tampilan publik bisa mengembalikan alamat berbeda untuk nama yang sama, sehingga alamat yang dipakai aplikasi Anda bukan yang Anda uji.

Koneksi yang di-cache adalah varian keempat dan mudah terlewat. Aplikasi mungkin masih berbicara dengan alamat yang diresolusinya satu jam lalu, yang berarti pencarian baru Anda dan soket terbukanya tidak sepakat tentang di mana layanan itu berada.

Baca tujuan yang benar-benar dipakai aplikasi

Tanyakan pada sistem operasi dan tabel soket, bukan tab peramban. Pencarian menjawab ke apa nama itu diresolusikan sekarang, dan tabel soket menunjukkan alamat tempat proses terhubung, yang bisa lebih lama. Jalankan keduanya sebelum membentuk teori, karena perbedaan di antaranya sendiri adalah jawabannya pada kira-kira separuh kasus.

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

Lalu bandingkan dengan apa yang dicakup aturan. Jika alamat saat ini berada di luar pengecualian dan permintaan tetap gagal, Anda telah menemukan penyebabnya tanpa menyentuh konfigurasi terowongan. Jika aplikasi terhubung ke alamat yang cocok dengan aturan dan permintaan tetap gagal, masalahnya ada di balik terowongan dan ini penyelidikan yang salah.

Perbaiki mekanismenya, bukan gejalanya

Jika produk mendukung pengarahan berbasis domain yang terpelihara, gunakan itu dan ikuti perilaku penyegaran dan cakupannya yang terdokumentasi. Itu menggantikan tebakan statis dengan jawaban yang terpelihara, dengan biaya bergantung pada fitur yang bekerja seperti terdokumentasi.

Jika desainnya bergantung pada daftar statis, beri daftar itu pemilik dan rencana pembaruan. Rencana itu harus menyebutkan bagaimana alamat ditemukan, siapa yang menyetujui perubahan, dan seberapa cepat daftar diharapkan mengikuti migrasi penyedia. Daftar tanpa pemilik adalah gangguan di masa depan dengan penyebab yang diketahui.

Jangan memperlebar pengecualian ke jaringan tetangga yang besar hanya untuk menangkap setiap alamat yang Anda lihat selama uji singkat. Itu bukan perbaikan; itu perubahan permanen pada batas keamanan, dan diam-diam akan membiarkan layanan tak terkait melewati terowongan selama aturan itu ada.

Verifikasi kedua bagian maksud

Desain split tunnel punya dua maksud, dan perbaikan harus mempertahankan keduanya. Layanan yang dilindungi harus melewati terowongan, dan kategori yang dikecualikan harus terus memutarinya. Uji koneksi baru ke tujuan yang diperbaiki, lalu uji sesuatu yang seharusnya tetap 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 baru, mekanisme yang Anda pilih, dan tanggalnya. Catatan itulah yang mencegah orang berikutnya menyimpulkan bahwa VPN mengabaikan konfigurasinya sendiri secara acak.