Lalu lintas IPv6 yang melewati VPN: temukan rute yang bocor

Dua halaman uji tidak sepakat: yang satu melaporkan alamat penyedia melalui terowongan, yang kedua melaporkan prefiks rumah Anda, dan kesimpulan yang jelas adalah VPN bocor. Kesimpulan itu melewati satu langkah, karena kedua laporan menjalankan dua keputusan perutean yang berbeda dan hanya satu di antaranya yang seharusnya masuk terowongan. Celahnya biasanya nyata, dan itu masalah cakupan, bukan terowongan rusak. Tiga pertanyaan menyelesaikannya: aliran mana yang benar-benar keluar, rute mana yang dipilih kernel untuknya, dan perilaku mana yang dimaksudkan klien.

Bekerjalah dalam urutan itu. Menjawabnya tidak berurutan menghasilkan perdebatan panjang tentang apakah klien cacat, padahal jawaban sebenarnya adalah tidak pernah ada rute IPv6 yang dipasang.

Aliran mana yang benar-benar keluar, dan pada adaptor mana

Mulailah dengan uji yang menyebutkan keluarga yang dipakainya, lalu catat aplikasi, jaringan akses, profil yang berlaku, dan apakah koneksi menawarkan IPv6 sama sekali. Keempat fakta itulah yang membuat dua eksekusi dapat dibandingkan, dan yang keempat sering dilupakan orang: jaringan tanpa prefiks v6 tidak dapat membocorkan v6, dan jaringan yang menambahkannya belakangan mengubah jawabannya.

Kirim satu permintaan per keluarga alih-alih memuat halaman dan membaca hasilnya. Satu halaman dapat mencampur sumber daya v6 dan v4, proses latar belakang dapat berperilaku berbeda dari tab di depan Anda, dan jawaban dari cache dapat bertahan lebih lama daripada perubahan jaringan yang ingin Anda uji. Tetapkan tujuan yang Anda uji dan catat, agar eksekusi ulang mengukur hal yang sama.

Membaca rute yang dipilih kernel

Tabel rute menjawab pertanyaan yang tidak bisa dijawab peramban. Tanyakan kepada sistem ke mana tujuan tertentu akan pergi, dan sertakan aturan kebijakan maupun rute bawaan yang terlihat, karena keduanya dapat menimpanya:

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

Prefiks yang lebih spesifik adalah alasan biasa satu tujuan berada di luar terowongan sementara semua yang lain tetap di dalam, dan aturan kebijakan dapat melakukan hal yang sama dengan prioritas lebih tinggi daripada rute mana pun. Baca juga metriknya, karena dua entri untuk prefiks yang sama diputuskan oleh metrik, bukan oleh urutannya di layar. Di Windows daftar yang setara adalah Get-NetRoute -AddressFamily IPv6, diurutkan menurut metrik agar sesuai dengan urutan keputusan. Aturan yang tampak benar di tabel tetap bisa kalah dari aturan kebijakan bernomor lebih rendah, karena itu daftar aturan berada dalam satu tarikan napas dengan daftar rute.

Dari mana kebijakan IPv6 klien berasal

Klien dapat dibangun untuk membawa v6 melalui terowongan, untuk menolaknya, atau untuk mengizinkan pengecualian bernama, dan ketiga niat itu menghasilkan tiga hasil benar yang berbeda. Bacalah profil dan dokumentasi klien itu sendiri sebelum menyebut sebuah pengamatan sebagai kebocoran, karena klien yang memblokir v6 sementara sistem operasi masih mengirim penemuan tetangga pada tautan fisik berperilaku sebagaimana dirancang.

Aplikasi yang sengaja dikecualikan dari terowongan adalah kasus berbeda dari keluarga yang tidak pernah dibawa terowongan. Yang pertama adalah keputusan tentang satu program, yang kedua adalah celah dalam cakupan, dan perbaikannya berbeda sesuai itu. Baca daftar program yang dikecualikan klien sebelum mencari rute yang seharusnya tidak pernah ada.

Pengamatan sempit, ketika tabel tidak sepakat

Ketika pencarian rute ambigu, satu pengamatan antarmuka di host dapat menyelesaikannya, tetapi hanya jika diarahkan pada pertanyaannya. Lalu lintas ke titik akhir VPN itu sendiri akan melewati adaptor fisik menurut rancangan; yang penting adalah apakah aliran aplikasi, yang dialamatkan ke tempat lain sepenuhnya, juga muncul di sana. Saring tangkapan ke tujuan yang Anda uji alih-alih mengumpulkan semuanya.

Tangkapan yang lebar memaparkan jauh lebih banyak lalu lintas pribadi daripada yang dibutuhkan satu pertanyaan itu. Ia juga menjawab pertanyaan dengan kurang jelas, karena aliran yang Anda pedulikan tiba terkubur dalam arus koneksi tak bertalian. Saring ke tujuan yang diuji, berhenti setelah beberapa paket, dan hapus tangkapan itu.

Tiga cara menutup celah

Bawa keluarga itu melalui terowongan, blokir di klien ketika terowongan tidak dapat membawanya, atau catat pengecualian yang disengaja dengan pemilik dan tanggal tinjauan. Masing-masing dapat dipertahankan, dan satu hal yang tidak dapat dipertahankan adalah membiarkan pilihan itu implisit, karena pilihan implisit justru adalah kebocorannya. Jika terowongan sama sekali tidak punya jalan keluar v6, menolak v6 di klien sekaligus jujur dan dapat diuji. Yang penting adalah pilihan itu tertulis di tempat orang berikutnya akan menemukannya, bukan disimpulkan dari perilaku enam bulan kemudian.

Ulangi pemeriksaan setelah menyambung ulang dan setelah berpindah antarjaringan, karena rute yang dipasang untuk tautan sebelumnya dapat bertahan melewati perubahan. Lalu catat tujuan, rute yang dipilih, kebijakan klien, dan keluarga yang dipakai uji, agar orang berikutnya membaca keputusan alih-alih menurunkannya lagi. RFC 7359 mendokumentasikan kebocoran tumpukan ganda sebagai masalah rancangan, bukan bug, dan itulah rujukan yang dikutip ketika seseorang mengklaim terowongan v4 yang berfungsi mencakup semuanya.