Matikan IPv6 untuk memperbaiki kebocoran VPN? Tentukan saja kebijakannya

Sebuah alamat dari rentang IPv6 muncul di halaman uji, terowongan jelas tidak membawanya, dan saran paling populer di internet adalah mematikan IPv6 di mana-mana. Perintah itu memang membuat panel menjadi sunyi. Perintah itu juga menghapus protokol yang mungkin diandalkan jaringan akses, dan meninggalkan Anda tanpa tahu apakah alamat itu kebocoran nyata, alamat antarmuka link-local, atau resolver yang menjalankan tugasnya. Tiga kondisi menentukan kendali yang tepat, dan hanya satu di antaranya berujung pada pemblokiran.

Kenali apa yang sebenarnya diukur alat tersebut

Alarm palsu yang paling umum adalah alamat link-local, yang dimulai dengan fe80: dan ada di setiap antarmuka berkemampuan IPv6, terlepas dari apakah mesin dapat menjangkau internet melalui IPv6 atau tidak. Alamat itu muncul di daftar antarmuka dan di beberapa diagnostik aplikasi, dan tidak mengatakan apa pun tentang jalur lalu lintas Anda.

Alarm palsu kedua adalah alamat lokal unik dalam fc00::/7, yaitu rentang privat yang dipakai di dalam jaringan. Alat yang mencetak setiap alamat milik host akan dengan senang hati mencantumkannya di samping alamat publik. Siapa pun yang membaca cepat menyebutnya kebocoran, lalu menghabiskan satu jam pada masalah yang tidak ada.

Yang ketiga sama sekali bukan alarm palsu. Alamat global yang mencapai internet di luar terowongan adalah kebocoran sebenarnya, dan itu layak diukur sebelum memutuskan apa pun:

ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co

Jika perintah pertama mencetak alamat global dan yang ketiga mengembalikan alamat IPv6 publik yang bukan milik terowongan, Anda punya jalur nyata di luar terowongan. Jika yang pertama tidak mencetak apa pun selain entri link-local, tidak pernah ada kebocoran untuk diperbaiki.

Tiga kondisi menentukan kendali

Keputusannya bukan "IPv6 baik" atau "IPv6 buruk". Keputusannya adalah situasi mana dari tiga yang Anda alami, dan masing-masing punya jawaban benar berbeda dengan biaya berbeda jika Anda salah.

Baris pertama adalah yang biasanya dimaksud orang, dan itu sah. Klien yang ujung keluarnya tidak mendukung IPv6 tidak boleh diam-diam membiarkan lalu lintas IPv6 asli host keluar, karena itulah kebocoran tumpukan ganda yang terdokumentasi. Intinya adalah memblokirnya sebagai kebijakan yang dinyatakan, bukan mematikan protokol di kernel. Hasil yang terlihat sama dan hanya satu di antaranya yang bisa ditinjau nanti.

Baris ketiga adalah tempat saran menyeluruh menjadi benar-benar berbahaya. Operator seluler dan sebagian sambungan rumah menjalankan jaringan IPv6-only dengan penerjemahan untuk tujuan IPv4. Hapus IPv6 di sana dan Anda menghapus satu-satunya transportasi yang ditawarkan jaringan, yang menghasilkan pemadaman jauh lebih buruk daripada yang sedang Anda debug.

Jika ujung keluar tidak punya IPv6, blokir dengan sengaja

Utamakan mekanisme klien itu sendiri, karena mekanisme itu berlaku tepat selama terowongan aktif dan kembali saat terowongan jatuh. OpenVPN punya opsi untuk ini, dan iptables punya aturan setara untuk klien lain:

block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachable

Direktif berada di profil; aturan berada di firewall yang bisa Anda tinjau dan hapus. Keduanya gagal tertutup, yang memang Anda inginkan, dan keduanya terlihat dalam diff konfigurasi, yang tidak berlaku bagi sysctl kernel yang terkubur dalam skrip startup.

Catat mengapa aturan itu ada. Aturan pemblokiran tanpa komentar akan dihapus oleh orang berikutnya yang membutuhkan IPv6 untuk hal lain, lalu kebocoran itu kembali diam-diam.

Jika ujung keluar membawa IPv6, rutekan dan uji kedua keluarga

Membawa IPv6 adalah jawaban yang lebih baik ketika server mendukungnya, dan tidak jauh lebih sulit. Syaratnya adalah antarmuka terowongan punya alamat dalam keluarga itu dan rute default-nya mengarah ke dalam terowongan, bukan keluar dari antarmuka fisik:

ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.co

Pencarian rute adalah uji yang menentukan: jika ia menyebut antarmuka terowongan, lalu lintas IPv6 sedang dibawa. Dua panggilan curl kemudian memastikan apa yang dilihat setiap keluarga, dan membandingkannya adalah cara membuktikan bahwa kedua jalur sekarang keluar melalui ujung keluar yang sama.

Jangan berhenti pada koneksi yang berhasil. Sambungkan ulang terowongan dan periksa lagi, karena rute IPv6 yang didorong bisa hilang saat pembentukan ulang jika server hanya mengirimnya pada konfigurasi awal. Lalu periksa satu tujuan yang dikecualikan, karena aturan split-tunnel adalah tempat kedua keluarga paling sering berbeda.

Jika jaringan akses hanya IPv6, biarkan saja

Sebagian jaringan hanya menyediakan IPv6 dan mengharapkan perangkat menjangkau layanan IPv4 melalui mekanisme penerjemahan di sisi operator. Mematikan IPv6 pada mesin seperti itu bukan peningkatan keamanan; itu menghapus satu-satunya rute ke apa pun. Itu pemadaman yang Anda timbulkan sendiri demi hasil uji yang tidak dibutuhkan siapa pun.

Gejala kesalahan ini khas dan tidak menyenangkan: terowongan tampak terbentuk, resolusi nama bekerja, dan tidak ada yang termuat. Jika Anda melihatnya setelah perubahan IPv6, pulihkan pengaturan segera dan lanjutkan diagnosis di tempat lain.

Apa pun pilihan Anda, pertahankan keputusan itu eksplisit di profil atau firewall, ikat pada apa yang benar-benar didukung ujung keluar, dan catat perilaku tumpukan ganda yang dijelaskan diskusi tumpukan ganda RFC 7359 . Pemblokiran yang dinyatakan adalah kebijakan. Protokol yang dimatikan adalah jalan pintas yang tidak bisa diaudit siapa pun, dan dari halaman uji keduanya tampak identik.