IPv6 melalui pelayan VPN IPv4 masih memerlukan laluan keluar IPv6

Terowong naik, klien menerima alamat IPv6 daripada pool, namun setiap destinasi IPv6 tetap tamat masa. Tiada apa yang rosak di dalam terowong: IPv6 bergerak dengan baik di dalam pengangkutan IPv4, dan itu tidak pernah menjadi bahagian yang sukar. Alamat yang anda berikan ialah janji yang pelayan tidak dapat tunaikan, kerana laluan keluar tiada upstream IPv6 untuk menghantarnya. Pembaikan terletak pada laluan keluar, bukan pada profil klien.

Gejalanya: alamat ada, laluan tiada

Pemeriksaan di sebelah klien menunjukkan alamat IPv6 yang kelihatan global pada peranti terowong dan laluan yang menunjuk ke dalamnya, sebab itulah ini disalahtafsirkan sebagai pepijat klien. Trafik masuk ke dalam terowong, pelayan menyahkapsulnya, dan kemudian paket mendarat pada hos yang jadual penghalaannya tiada laluan lalai IPv6 ke mana-mana tempat sebenar. Bergantung pada stak, anda mendapat ketidakcapaian segera atau pembuangan senyap, dan dalam kedua-dua kes klien melihat tamat masa yang kelihatan sama seperti tembok api.

Baca jadual penghalaan pelayan itu sendiri sebelum menyentuh klien, kerana di situlah separuh laluan yang hilang berada. Pelayan dengan satu laluan lalai IPv4 sudah memberi anda jawapannya.

Ikut paket selepas nyahkapsulan

Di dalam terowong paket itu IPv6 biasa dan sumbernya ialah alamat klien. Pelayan menanggalkan kapsulan pengangkutan dan kemudian memegang paket IPv6 asli yang mesti dimajukan ke hop IPv6 seterusnya. Laluan lalai IPv4 tidak dapat membawanya, dan menterjemahkannya ke IPv4 ialah fungsi lain yang tiada siapa melaksanakannya. Itulah keseluruhan kegagalan, dan ia tidak ada kaitan dengan sama ada pendengar VPN menjawab melalui IPv4.

Mekanik kapsulan IPv6 di atas IPv4 diterangkan dalam RFC 4213, dan butiran penting di sana ialah hujung-hujung masih memerlukan sambungan IPv6 sebenar di sebelah sana terowong. Membalut pengepala tidak mencipta upstream.

Dua lapisan terowong, dua pemeriksaan bebas

Sahkan setiap lapisan secara berasingan, kerana terowong luar yang berfungsi menyembunyikan terowong dalam yang rosak. Periksa laluan luar dengan ping IPv4 dari klien ke pelayan dan sahkan port yang anda gunakan. Kemudian periksa laluan dalam pada pelayan, di mana ip -6 route mesti menunjukkan laluan lalai atau laluan khusus yang dipelajari daripada upstream sebenar, dan ip -6 addr mesti menunjukkan awalan sumber yang diterima oleh upstream. Apa-apa yang kurang daripada itu hanyalah hiasan pada antara muka.

Alamat unik-tempatan, atau awalan yang kelihatan global yang tiada apa menghala balik kepadanya, akan muncul dengan gembira pada antara muka dan tidak pergi ke mana-mana. Ketercapaian awam diberikan oleh upstream, bukan oleh bentuk alamat.

Perkara yang sama berlaku pada klien: ip -6 route get 2001:4860:4860::8888 sepatutnya menamakan peranti terowong, dan jika ia menamakan peranti fizikal, klien tidak menggunakan VPN untuk IPv6 sama sekali.

Awalan sumber, saiz dan ICMPv6

Tanya upstream awalan sumber mana yang akan diterimanya untuk pemajuan, dan gunakan salah satunya untuk pool klien. Penyedia yang memberi anda /64 untuk antara muka pelayan itu sendiri tidak semestinya menghala ke arah anda /64 kedua atau blok yang lebih besar, dan perbezaannya ialah satu petang penyahpepijatan yang diselesaikan oleh tiket sokongan dengan satu soalan. Tanya secara bertulis dan simpan jawapannya bersama konfigurasi.

Belanjakan untuk kapsulan tambahan yang stak anda benar-benar gunakan, dan kekalkan ICMPv6 berfungsi, termasuk Packet Too Big. Pengepala kedua mengecilkan muatan berguna, jadi laluan yang menjawab ping kecil masih boleh gagal pada pemindahan fail, dan tembok api yang membuang semua ICMPv6 menjadikan masalah saiz yang boleh dipulihkan sebagai lohong hitam. Uji satu pemindahan besar sebelum mengumumkan perkhidmatan.

Apa yang merupakan masalah yang sama sekali berbeza

Mencapai aplikasi yang hanya IPv4 daripada klien yang hanya IPv6 ialah terjemahan, bukan terowong, dan memerlukan sesuatu seperti NAT64 yang sengaja dilaksanakan. Destinasi tidak akan memahami pengepala terowong tambahan hanya kerana anda menambahnya. Perkhidmatan peralihan sejarah juga memerlukan penjagaan yang sama: RFC 7526 telah menghentikan model geganti anycast 6to4, jadi panduan yang ditulis mengenainya menerangkan sesuatu yang tidak lagi mempunyai geganti awam yang diselenggara.

Jika pelayan tiada upstream IPv6 yang boleh digunakan, pilihannya ialah upstream yang disokong, laluan keluar lain, atau keputusan berdokumen bahawa IPv6 kekal di luar terowong. Yang tidak boleh diterima ialah memberitahu klien bahawa perkhidmatan IPv6 wujud sedangkan sambungan IPv6 biasa mereka memintas VPN secara senyap.