IPv6 melalui server VPN IPv4 tetap butuh jalan keluar IPv6

Terowongan naik, klien menerima alamat IPv6 dari pool, dan setiap tujuan IPv6 tetap kehabisan waktu. Tidak ada yang rusak di dalam terowongan: IPv6 berjalan sangat baik di dalam transport IPv4, dan itu tidak pernah menjadi bagian yang sulit. Alamat yang kamu berikan adalah janji yang tidak bisa ditepati server, karena jalur keluar tidak punya upstream IPv6 untuk mengirimkannya. Perbaikannya ada di jalur keluar, bukan di profil klien.

Gejalanya: ada alamat, tidak ada jalur

Pemeriksaan di sisi klien menunjukkan alamat IPv6 yang tampak global pada perangkat terowongan dan rute yang menunjuk ke dalamnya, sehingga ini salah dibaca sebagai bug klien. Lalu lintas masuk ke terowongan, server mendekapsulasinya, lalu paket mendarat di host yang tabel ruternya tidak punya rute default IPv6 ke tempat nyata mana pun. Bergantung pada stack, kamu mendapat ketidakcapaian langsung atau pembuangan senyap, dan pada kedua kasus klien melihat batas waktu yang tampak identik dengan tembok api.

Baca tabel rute server itu sendiri sebelum menyentuh klien, karena di situlah separuh jalur yang hilang berada. Server dengan satu rute default IPv4 sudah memberimu jawabannya.

Ikuti paket setelah dekapsulasi

Di dalam terowongan paket adalah IPv6 biasa dan sumbernya adalah alamat klien. Server melepas enkapsulasi transport lalu memegang paket IPv6 asli yang harus diteruskan ke hop IPv6 berikutnya. Rute default IPv4 tidak bisa membawanya, dan menerjemahkannya ke IPv4 adalah fungsi lain yang tidak pernah diterapkan siapa pun. Itulah keseluruhan kegagalannya, dan tidak ada hubungannya dengan apakah pendengar VPN menjawab lewat IPv4.

Mekanika enkapsulasi IPv6 di atas IPv4 dijelaskan dalam RFC 4213, dan detail penting di sana adalah bahwa kedua ujung tetap butuh konektivitas IPv6 nyata di sisi lain terowongan. Membungkus kepala paket tidak menciptakan upstream.

Dua lapisan terowongan, dua pemeriksaan independen

Verifikasi tiap lapisan secara terpisah, karena terowongan luar yang bekerja menyembunyikan terowongan dalam yang rusak. Periksa jalur luar dengan ping IPv4 dari klien ke server dan pastikan port yang kamu pakai. Lalu periksa jalur dalam di server, tempat ip -6 route harus menunjukkan rute default atau rute khusus yang dipelajari dari upstream sungguhan, dan ip -6 addr harus menunjukkan prefiks sumber yang diterima upstream. Apa pun yang kurang dari itu hanyalah hiasan pada antarmuka.

Alamat unik-lokal, atau prefiks yang tampak global yang tidak dirutekan balik oleh apa pun, akan dengan senang hati muncul di antarmuka dan tidak ke mana-mana. Keterjangkauan publik diberikan oleh upstream, bukan oleh bentuk alamatnya.

Hal yang sama berlaku pada klien: ip -6 route get 2001:4860:4860::8888 seharusnya menyebut perangkat terowongan, dan jika ia menyebut perangkat fisik, klien sama sekali tidak memakai VPN untuk IPv6.

Prefiks sumber, ukuran, dan ICMPv6

Tanyakan kepada upstream prefiks sumber mana yang akan diterimanya untuk penerusan, dan pakai salah satunya untuk pool klien. Penyedia yang memberimu /64 untuk antarmuka server sendiri belum tentu merutekan /64 kedua atau blok yang lebih besar kepadamu, dan selisihnya adalah satu sore debugging yang diselesaikan tiket dukungan dengan satu pertanyaan. Tanyakan secara tertulis dan simpan jawabannya bersama konfigurasi.

Anggarkan enkapsulasi tambahan yang benar-benar dipakai stack-mu, dan jaga ICMPv6 tetap bekerja, termasuk Packet Too Big. Header kedua memperkecil muatan berguna, sehingga jalur yang menjawab ping kecil bisa tetap gagal saat transfer berkas, dan tembok api yang membuang semua ICMPv6 mengubah masalah ukuran yang bisa dipulihkan menjadi lubang hitam. Uji satu transfer besar sebelum mengumumkan layanan.

Apa yang merupakan masalah yang sama sekali berbeda

Menjangkau aplikasi yang hanya IPv4 dari klien yang hanya IPv6 adalah penerjemahan, bukan terowongan, dan butuh sesuatu seperti NAT64 yang sengaja diterapkan. Tujuan tidak akan memahami header terowongan tambahan hanya karena kamu menambahkannya. Layanan transisi historis pantas mendapat perhatian yang sama: RFC 7526 menghentikan model relai anycast 6to4, jadi panduan yang ditulis di sekitarnya menjelaskan sesuatu yang tidak lagi punya relai publik terawat.

Jika server tidak punya upstream IPv6 yang bisa dipakai, pilihannya adalah upstream yang didukung, jalur keluar lain, atau keputusan terdokumentasi bahwa IPv6 tetap di luar terowongan. Yang tidak bisa diterima adalah memberi tahu klien bahwa layanan IPv6 ada sementara koneksi IPv6 biasa mereka diam-diam melewati VPN.