Bagaimana terowongan terpisah memutuskan lalu lintas mana yang memakai VPN

Terowongan terpisah adalah kebijakan perutean yang dinyatakan sebagai sekumpulan aturan, dan klien hanyalah hal yang memasang aturan itu. Pemisahan terjadi di dua tempat: aturan pencocokan yang memilih jalur untuk setiap paket, dan pengikatan yang menahan aplikasi pada satu antarmuka apa pun kata tabel. Mekanisme mana yang diandalkan klien Anda menjelaskan sebagian besar kejutan yang dilaporkan orang.

Kebijakan yang dapat Anda nyatakan dalam satu baris dapat diuji. Kebijakan yang digambarkan sebagai penjelajahan lebih cepat tidak demikian, dan tidak akan memberi tahu Anda aturan mana yang harus diubah ketika permintaan menempuh arah yang salah.

Klien memasang aturan, kernel membuat pilihan

Saat terowongan naik, klien menambahkan rute dan sering kali aturan kebijakan ke tabel yang sama yang dipakai antarmuka lain Anda. Setiap paket lalu mencapai pencarian yang membandingkan tujuannya dengan setiap prefiks kandidat dan menyimpan kecocokan paling spesifik, sementara prioritas menyelesaikan seri antara aturan yang menunjuk ke tabel berbeda. Tidak ada apa pun dalam pencarian itu yang tahu bahwa paket datang dari tab peramban dan bukan dari tugas pencadangan. Aturan yang menang adalah yang menetapkan jalur, dan Anda dapat membacanya sebelum dan sesudah perubahan.

Itulah sebabnya terowongan terpisah bisa tampak sewenang-wenang. Dua tujuan dalam satu aplikasi dapat menempuh jalur berbeda hanya karena satu prefiks lebih sempit daripada yang lain.

Pilihan yang sama ada di setiap platform, meski namanya berubah. Windows mendorong keputusan ke platform filternya, Android mengekspos daftar izin per aplikasi melalui layanan VPN-nya, dan macOS melampirkan terowongan ke perangkat yang masih mematuhi tabel perutean. Catatan perutean Microsoft layak dibaca untuk kasus Windows, dan panduan yang ditulis untuk satu platform jarang berpindah tanpa perubahan ke platform lain.

Pengikatan per aplikasi dan prefiks tujuan adalah alat yang berbeda

Kebijakan tujuan menanyakan ke mana paket pergi dan berkonsultasi dengan tabel rute atau aturan kebijakan. Kebijakan per aplikasi menanyakan program mana yang membuka soket, dan platform menahan program itu pada antarmuka terowongan bahkan ketika rute yang lebih spesifik menunjuk ke tempat lain. Yang kedua lebih kuat karena bertahan terhadap perubahan tabel, tetapi hanya mencakup proses yang dapat diatribusikan platform. Proses pembantu, peramban tertanam, atau layanan yang membuka koneksinya sendiri mungkin tidak mewarisi pengikatan yang Anda asumsikan.

Tidak satu pun pendekatan bertahan terhadap kebijakan berbasis nama tanpa bantuan. Alamat situs besar berputar di antara jaringan konten, sehingga memaku nama host ke beberapa prefiks menghasilkan aturan yang diam-diam berhenti cocok. Kebijakan yang harus mengikuti nama memerlukan komponen yang sadar resolver alih-alih rute statis.

DNS dan sakelar pengaman mengikuti aturannya sendiri

Resolusi nama adalah keputusan terpisah dari perutean paket, dan terowongan terpisah biasanya menginginkan dua resolver: milik perusahaan untuk nama internal, yang lokal untuk semua hal lain. Klien dapat memasang pengaturan DNS per antarmuka, menyerahkan kueri ke resolver perantara, atau membiarkan bawaan sistem tak tersentuh. Peramban dengan resolver terenkripsi sendiri melewati ketiga pengaturan itu. Uji pencarian alih-alih menganggap resolver mengikuti rute.

Sakelar pengaman menambahkan filter di atasnya, dan filter itu tidak selalu membedakan pengecualian yang disengaja dari kebocoran tak sengaja. Beberapa klien memblokir semua di luar terowongan sementara yang lain mengizinkan pengecualian yang dinyatakan kebijakan, jadi bacalah perilaku mana yang diterapkan milik Anda sebelum mengandalkan salah satunya.

Periksa pemisahan dari kedua sisi

Uji jalur yang disertakan dan jalur yang dikecualikan secara terpisah, dan nilai hasilnya dari nama antarmuka, bukan dari alamat publik. Perintah ini mengasumsikan host Linux dengan perangkat terowongan sudah naik. Ganti 203.0.113.10 dengan tujuan yang dirutekan kebijakan Anda ke dalam, dan 198.51.100.25 dengan tujuan yang dikirimkannya ke luar.

ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'

Baca dua jawaban pertama bersama-sama, karena antarmuka yang disebut di masing-masing menunjukkan apakah pemisahan menempatkan tujuan itu pada terowongan. Kueri resolver menunjukkan server mana yang menjawab nama internal, dan perintah terakhir membuktikan perangkat terowongan setidaknya dapat membawa permintaan. Kegagalan pada baris kedua sementara baris pertama berhasil berarti kebijakan melakukan tepat apa yang diperintahkan.

Ulangi rangkaian ini setelah menyambung ulang dan setelah perubahan jaringan. Pembaruan sewa dan gejolak antarmuka adalah tempat pemisahan berhenti cocok dengan maksud pembuatannya, dan keluaran tersimpan dari setiap jalan membuat penyimpangan itu jelas.