Membahagi /64 anda tidak menghalakan IPv6 kepada klien VPN

Klien memaparkan alamat IPv6 global, jabat tangan selesai, dan tiada apa yang kembali dari internet. Tetapan kumpulan kelihatan betul kerana ia memang betul; alamat itu sah dan terowong membawanya. Yang gagal ialah penghantaran, dan penghantaran bergantung pada keputusan yang dibuat di atas pelayan VPN yang tidak dapat dipengaruhi oleh mana-mana konfigurasi sisi klien.

Mitos: sebahagian /64 anda sudah boleh dicapai

Ceritanya menarik: pelayan mempunyai /64 awam, potong dua, berikan separuh lagi kepada kumpulan VPN, dan klien itu kini berada di internet. Membahagi prefiks memang memperuntukkan alamat tanpa perlanggaran. Tetapi ia tidak mengubah cara rangkaian upstream memutuskan ke mana paket untuk salah satu alamat itu harus pergi.

IPv6 tiada lapisan terjemahan lalai untuk bergantung padanya, jadi laluan balik mesti wujud sebagai penghalaan atau sebagai penghantaran peringkat pautan. Paket yang dialamatkan ke alamat terowong klien tiba di penghala upstream, dan penghala itu membuat keputusan penghantaran daripada jadualnya sendiri. Jika jadual menunjuk ke pautan fizikal, paket pergi ke sana tanpa mengira apa yang dipercayai oleh pelayan VPN anda.

Itulah keseluruhan kegagalan: arah hadapan berfungsi kerana pelayan anda menghantarnya, dan arah balik mati satu hop jauhnya kerana upstream tidak pernah tahu klien itu wujud.

Apa yang sebenarnya diperlukan oleh penghantaran di pautan

Apabila upstream menganggap seluruh /64 berada di pautan fizikal, ia menyelesaikan setiap alamat destinasi dengan penemuan jiran. Ia menghantar permintaan di pautan itu dan menjangka pemilik alamat akan menjawab. Klien VPN di belakang terowong tidak berada di pautan itu dan tidak dapat menjawab, jadi permintaan itu kekal tanpa jawapan dan paket digugurkan.

Memotong /65 tidak mengubah jangkaan itu. Upstream masih menganggap julat itu berada di pautan, kerana satu-satunya perkara yang akan mengubah fikirannya ialah laluan atau proksi yang menjawab bagi pihak klien. Kedua-duanya tidak muncul kerana anda mengedit konfigurasi VPN. Jurang itulah sebabnya kumpulan boleh berfungsi dengan sempurna antara kliennya sendiri dan masih tidak dapat dicapai dari mana-mana tempat lain.

Penemuan jiran proksi ialah mekanisme yang boleh merapatkan dua dunia. Get laluan menjawab permintaan untuk alamat klien tertentu yang dimilikinya dan menghantar trafik ke dalam terowong. Ia berfungsi, dan ia mesti dihadkan tepat kepada alamat itu dengan kitaran hayat yang mengikut kumpulan, kerana menjawab untuk alamat yang tidak lagi anda layan menjadikan trafik orang lain sebagai lubang hitam. Sesetengah upstream tidak akan menerima jawapan proksi yang tidak mereka jangkakan, jadi reka bentuk ini juga memerlukan persetujuan pembekal.

Apa yang diperlukan oleh penghantaran berhalal

Reka bentuk yang lebih bersih ialah peruntukan yang benar-benar dihalakan oleh upstream ke get laluan anda. Ia boleh menjadi prefiks yang diwakilkan atau laluan statik untuk blok yang lebih kecil, dan keperluannya sama dalam kedua-dua kes: jadual upstream mesti menunjuk ke pelayan anda untuk julat klien. Kemudian trafik balik tiba di get laluan dan get laluan menghantarnya ke dalam terowong.

Penghantaran berhalal menghapuskan persoalan penemuan jiran sepenuhnya, itulah sebabnya ia wajar diminta daripada pembekal sebelum membina sesuatu yang pintar. Minta laluan itu secara bertulis, dan sahkan bahawa hop seterusnya ialah alamat yang benar-benar boleh dicapai oleh upstream.

Kedua-dua reka bentuk masih memerlukan penghantaran IPv6 diaktifkan pada get laluan dan peraturan tembok api yang membenarkan aliran yang dihantar dalam kedua-dua arah. Penghantaran ialah prasyarat, bukan pengganti, untuk baki laluan. Laluan yang berfungsi dengan penghantaran dimatikan menghasilkan kesunyian yang sama seperti laluan yang hilang, jadi periksa kedua-duanya sebelum mereka bentuk semula apa-apa.

Dua laluan bebas yang perlu dielokkan

Prefiks kumpulan dan laluan lalai klien sendiri ialah tetapan berasingan, dan mengelirukannya menghasilkan ketersambungan separa yang kelihatan seperti terowong rosak. Kumpulan memberitahu pelayan alamat mana yang perlu diagihkan. Laluan klien menentukan destinasi mana yang dihantar oleh klien ke dalam terowong.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

Prefiks di atas ialah ruang dokumentasi, dan ubah hala hanya terpakai kepada IPv6, iaitu apa yang sering dikehendaki oleh penggunaan dwi-tindanan semasa penghantaran IPv6 masih diperbaiki. Ubah hala IPv4 tidak menetapkan liputan IPv6, dan tiada tetapan yang menyiratkan yang lain.

Pastikan trafik kawalan yang bergantung pada IPv6 berfungsi di bawah apa-apa dasar yang anda gunakan. Mesej Packet Too Big ialah mangsa klasik tembok api yang hanya membenarkan TCP dan UDP, dan menggugurkannya menghasilkan sambungan yang terbentuk dan kemudian tersekat pada pemindahan lebih besar.

Pengumuman penghala ialah bahagian bergerak ketiga. Jika get laluan mula mengumumkan di pautan atas, ia boleh mengubah apa yang dipercayai oleh klien dan jiran tentang prefiks di pautan, yang boleh membatalkan reka bentuk yang baru anda dokumentasikan secara senyap.

Catat reka bentuk supaya pembinaan semula menghasilkan semulanya

Tulis tiga objek secara berasingan: peruntukan klien, laluan destinasi klien, dan kaedah penghantaran upstream untuk peruntukan itu. Pembaca yang mempunyai ketiga-tiganya boleh membina semula penggunaan; pembaca yang hanya mempunyai tetapan kumpulan akan menghasilkan semula pepijat asal.

Kemudian uji arah balik secara eksplisit, dengan paket yang mesti kembali dari luar. Manual openvpn(8) merangkumi pilihan server-ipv6 dan redirect, dan pengesahan penghalaan daripada pembekal anda merangkumi separuh yang tidak dapat dilakukan oleh manual.