VPN dual-stack: klien yang memilih keluarga alamat, bukan Anda

Tunnel aktif, situs IPv4 dimuat, dan satu nama host kehabisan waktu. Kesimpulan langsungnya adalah VPN rusak atau kredensial salah, dan biasanya keduanya tidak benar. Nama tersebut mengembalikan alamat IPv4 dan IPv6, aplikasi memilih salah satunya, dan hanya satu dari kandidat itu yang memiliki jalur berfungsi. Klienlah yang mengambil keputusan pemilihan; tunnel sekadar tidak mencakup apa yang dipilihnya.

Pemilihan bukan janji cakupan

Pemilihan alamat default, yang dijelaskan dalam RFC 6724, menentukan pasangan sumber dan tujuan mana yang lebih disukai host ketika tersedia beberapa. Happy Eyeballs menambahkan strategi koneksi di atasnya: ia memulai percobaan pada kedua keluarga dan mempertahankan yang menjawab lebih dulu, agar pengguna tidak menunggu keluarga yang rusak kehabisan waktu.

Tidak ada mekanisme yang membuat rute. Jika tunnel Anda hanya membawa IPv4, kandidat AAAA tetap tujuan sah yang mungkin dicoba klien, dan kegagalannya muncul sebagai pemuatan lambat, bukan galat, karena peramban mundur. Pengguna melaporkan situs lambat, bukan rusak, dan tiket dukungan mewarisi ketidakjelasan itu. Reproduksikan dengan keluarga tetap dan laporan menjadi spesifik.

Kemunduran itulah sebabnya gejalanya tidak konsisten antar aplikasi. Peramban menyembunyikan penundaan; klien baris perintah dengan keluarga tetap menunjukkan kegagalan sebenarnya seketika.

Temukan keluarga yang benar-benar dipakai permintaan

Mulai dari nama, bukan tunnel. Kueri kedua jenis rekaman dan catat apa yang kembali:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

Jika permintaan v4 berhasil dan permintaan v6 gagal, Anda telah mereproduksi masalah dalam bentuk yang bisa di-debug. Jika keduanya berhasil dari shell dan peramban tetap gagal, periksa resolver milik aplikasi atau jawaban yang di-cache sebelum menyentuh tunnel.

Simpan keluarga dan tujuan dalam catatan Anda. Tiket yang mengatakan situs tidak termuat lewat VPN tidak dapat diperiksa siapa pun, sedangkan tiket yang mengatakan AAAA gagal dan A berfungsi menunjuk rute tertentu.

Periksa rute untuk keluarga itu

Untuk keluarga yang gagal, tanyakan kepada kernel jalur apa yang akan dipakainya dan bandingkan dengan alamat tunnel yang dikonfigurasi. Di Linux, ip -6 route get untuk tujuan tersebut menampilkan antarmuka dan sumber yang akan dipilih.

Lalu periksa tunnel itu sendiri. Peer WireGuard membawa daftar IP yang diizinkan, dan entri untuk 0.0.0.0/0 tidak mengatakan apa pun tentang IPv6. Jika daftar peer tidak memiliki prefiks IPv6, klien tidak punya alasan mengirim lalu lintas AAAA ke tunnel, dan paket keluar melalui apa yang akan dilakukan host sebaliknya.

Aturan firewall dan kebijakan NAT layak mendapat pemeriksaan yang sama per keluarga. Aturan yang ditulis untuk IPv4 tidak mencakup IPv6 di platform mana pun, dan inilah alasan paling umum satu keluarga berfungsi sementara yang lain tidak.

Jangan nonaktifkan IPv6 agar tangkapan layar sederhana

Mematikan IPv6 di seluruh sistem akan membuat gejala hilang dan meninggalkan Anda tanpa diagnosis. Itu juga merusak tujuan apa pun yang hanya IPv6, dan menyembunyikan bug yang sama untuk aplikasi berikutnya. Jika sebuah mesin memang seharusnya tidak memakai IPv6, itu kebijakan yang disengaja dengan pemilik dan uji. Mematikannya saat insiden bukan keduanya.

Putuskan apa yang harus dilakukan klien dengan keluarga itu dan konfigurasikan secara eksplisit: bawa melalui tunnel, atau blokir dengan cara yang didukung agar pemilihan tidak pernah menawarkan kandidat yang tak terjangkau. Keduanya adalah desain yang sah. Penonaktifan global bukan keduanya, karena itu sama sekali bukan desain.

Apa yang harus ditulis di tiket

Catat empat hal: nama host, keluarga yang gagal, rute yang dipilih kernel, dan hasil permintaan khusus keluarga. Kumpulan itu cukup bagi orang lain untuk mereproduksi kegagalan tanpa menebak jalur mana dari dua itu yang Anda maksud.

Aturan pemilihan alamat RFC 6724 menjelaskan mengapa klien lebih menyukai kandidat yang dipilihnya, dan RFC 8305 menjelaskan perilaku balapan yang menyembunyikan penundaan. Keduanya tidak akan merutekan paket untuk Anda, dan itulah bagian yang harus dilakukan tunnel.