Jaringan hanya-IPv6 mematahkan VPN sebelum terowongan dimulai

Laptop bergabung ke Wi-Fi konferensi yang hanya membagikan IPv6, klien VPN berputar dan gagal, padahal profil yang sama bekerja di hotel satu jam sebelumnya. Tidak ada yang berubah pada kredensial. Yang berubah adalah klien kini harus mencapai tujuan IPv4 melalui jaringan yang hanya membawa IPv6, dan tidak setiap klien tahu cara melakukannya.

Ikuti lima langkah yang sama dengan yang dilalui paket.

Langkah 1: amati pencarian nama

Jika profil memakai nama host, pertanyaan pertama adalah apa yang dikembalikan resolver. dig AAAA vpn.example.com di jaringan hanya-IPv6 mengembalikan catatan AAAA sungguhan, catatan hasil sintesis dari DNS64, atau tidak sama sekali. Jawaban hasil sintesis mengodekan tujuan IPv4 di dalam prefiks terjemahan, dan hanya dengan begitu klien tanpa tujuan IPv6 dapat mencapainya. Profil dengan alamat IPv4 yang dikodekan keras tidak pernah sampai sejauh ini, karena tidak ada nama untuk disintesis.

Perbedaan tunggal itulah yang menjelaskan sebagian besar laporan ‘berhasil di sana, gagal di sini’, dan satu perintah saja cukup untuk melihatnya.

Langkah 2: lihat keluarga mana yang dipanggil klien

Amati soket, bukan bilah kemajuan. Klien yang membuka soket IPv4 ke alamat IPv4 pada tautan hanya-IPv6 tidak punya tempat mengirimnya, dan kegagalan muncul sebagai batas waktu, bukan kesalahan nama. ss -tanp saat klien menyambung menunjukkan alamat jauh dan keluarga yang dicobanya. Bandingkan dengan ip -6 route untuk memastikan bahwa default-nya adalah lompatan IPv6 berikutnya yang sungguhan.

Keluarga alamat di tabel soket adalah faktanya. Bilah kemajuan adalah ringkasan yang ditulis orang lain.

Langkah 3: pisahkan terjemahan dari terowongan

NAT64 dan DNS64 adalah cara jaringan akses mencapai tujuan IPv4, dan keduanya tidak melakukan apa pun untuk terowongan setelah terowongan berdiri. Terowongan yang dibangun di atas jalur terjemahan tetap menegosiasikan pengalamatan internalnya sendiri, dan cakupan IPv4 atau IPv6 internal adalah pertanyaan kebijakan tersendiri. Jika klien tersambung lalu tidak mencapai apa pun, Anda sudah melewati terjemahan dan masuk ke perutean, yang merupakan penyelidikan lain dengan bukti lain.

Kegagalan terjemahan tampak seperti tidak pernah tersambung. Kegagalan cakupan internal tampak seperti tersambung tetapi tidak mencapai apa pun.

Langkah 4: uji profil yang sama di jaringan lain

Bawa profil, versi klien, dan kredensial yang sama ke jaringan tumpuk ganda lalu ulangi. Jika berhasil di sana dan gagal di jalur hanya-IPv6, variabelnya adalah jaringan akses, bukan profil. Catat versi klien dan kondisi jaringan di tiket, karena perbaikan akhirnya adalah pembaruan klien atau tujuan lain.

Laporan yang mengatakan VPN rusak tidak dapat ditindaklanjuti. Laporan yang mengatakan gagal hanya pada akses hanya-IPv6 adalah laporan bug.

Langkah 5: perbaiki jalurnya, bukan pengaturan keamanan

Semua perbaikan yang menggoda justru memperburuk keadaan. Menonaktifkan IPv6 menghapus satu-satunya jalur yang ditawarkan jaringan. Mengarahkan klien ke resolver publik merusak sintesis DNS64, karena sintesis itu harus datang dari resolver di belakang penerjemah. Mematikan verifikasi sertifikat memberi Anda koneksi ke sesuatu yang tidak dapat Anda identifikasi. Tidak satu pun dari itu adalah perbaikan, dan dua di antaranya adalah regresi keamanan yang akan bertahan lebih lama dari insidennya.

Pilihan sebenarnya adalah klien yang mendukung model terjemahan jaringan, atau tujuan dengan alamat IPv6 yang dapat dijangkau. Minta salah satunya.