Memecah /64 Anda tidak merutekan IPv6 ke klien VPN

Klien menampilkan alamat IPv6 global, jabat tangan selesai, dan tidak ada yang kembali dari internet. Pengaturan kumpulan terlihat benar karena memang benar; alamatnya valid dan terowongan membawanya. Yang gagal adalah pengiriman, dan pengiriman bergantung pada keputusan yang diambil di atas server VPN yang tidak dapat dipengaruhi konfigurasi sisi klien mana pun.

Mitos: sebagian /64 Anda sudah dapat dijangkau

Kisahnya menarik: server memiliki /64 publik, belah menjadi dua, berikan separuh lainnya ke kumpulan VPN, dan klien tersebut kini di internet. Memecah prefiks memang mengalokasikan alamat tanpa tabrakan. Namun itu tidak mengubah cara jaringan upstream memutuskan ke mana paket untuk salah satu alamat itu harus pergi.

IPv6 tidak memiliki lapisan terjemahan bawaan untuk diandalkan, jadi jalur balik harus ada sebagai perutean atau sebagai pengiriman tingkat tautan. Paket yang dialamatkan ke alamat terowongan klien tiba di router upstream, dan router itu mengambil keputusan penerusan dari tabelnya sendiri. Jika tabel menunjuk ke tautan fisik, paket pergi ke sana terlepas dari apa yang diyakini server VPN Anda.

Itulah seluruh kegagalannya: arah maju bekerja karena server Anda mengirimkannya, dan arah balik mati satu hop jauhnya karena upstream tidak pernah tahu bahwa klien itu ada.

Apa yang sebenarnya dibutuhkan pengiriman di tautan

Ketika upstream menganggap seluruh /64 berada di tautan fisik, ia menyelesaikan setiap alamat tujuan dengan penemuan tetangga. Ia mengirim permintaan di tautan itu dan mengharapkan pemilik alamat menjawab. Klien VPN di belakang terowongan tidak berada di tautan itu dan tidak dapat menjawab, sehingga permintaan tetap tidak terjawab dan paket dibuang.

Memotong /65 tidak mengubah harapan itu. Upstream tetap memperlakukan rentang itu sebagai berada di tautan, karena satu-satunya hal yang akan mengubah pikirannya adalah rute atau proxy yang menjawab atas nama klien. Keduanya tidak muncul karena Anda menyunting konfigurasi VPN. Celah itulah sebabnya kumpulan dapat bekerja sempurna di antara kliennya sendiri dan tetap tidak dapat dijangkau dari tempat lain.

Penemuan tetangga proksi adalah mekanisme yang dapat menjembatani dua dunia. Gateway menjawab permintaan untuk alamat klien tertentu yang dimilikinya dan meneruskan lalu lintas ke terowongan. Ini bekerja, dan harus dibatasi tepat pada alamat tersebut dengan siklus hidup yang mengikuti kumpulan, karena menjawab untuk alamat yang tidak lagi Anda layani mengubah lalu lintas orang lain menjadi lubang hitam. Beberapa upstream tidak akan menerima jawaban proksi yang tidak mereka duga, jadi desain ini juga memerlukan persetujuan penyedia.

Apa yang dibutuhkan pengiriman terutekan

Desain yang lebih bersih adalah alokasi yang benar-benar dirutekan upstream ke gateway Anda. Itu bisa berupa prefiks yang didelegasikan atau rute statis untuk blok yang lebih kecil, dan persyaratannya sama dalam kedua kasus: tabel upstream harus menunjuk ke server Anda untuk rentang klien. Kemudian lalu lintas balik tiba di gateway dan gateway meneruskannya ke terowongan.

Pengiriman terutekan menghilangkan pertanyaan penemuan tetangga sepenuhnya, itulah sebabnya ada baiknya memintanya kepada penyedia sebelum membangun apa pun yang cerdik. Mintalah rute secara tertulis, dan pastikan hop berikutnya adalah alamat yang benar-benar dapat dijangkau upstream.

Kedua desain tetap memerlukan penerusan IPv6 diaktifkan di gateway dan aturan firewall yang mengizinkan aliran diteruskan di kedua arah. Pengiriman adalah prasyarat, bukan pengganti, untuk sisa jalur. Rute yang berfungsi dengan penerusan dimatikan menghasilkan kesunyian yang persis sama dengan rute yang hilang, jadi periksa keduanya sebelum merancang ulang apa pun.

Dua rute independen yang harus benar

Prefiks kumpulan dan rute default klien sendiri adalah pengaturan terpisah, dan mencampuradukkannya menghasilkan konektivitas sebagian yang tampak seperti terowongan rusak. Kumpulan memberi tahu server alamat mana yang harus dibagikan. Rute klien menentukan tujuan mana yang benar-benar dikirim klien ke terowongan.

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

Prefiks di atas adalah ruang dokumentasi, dan pengalihan hanya berlaku untuk IPv6, yang justru sering diinginkan penerapan tumpukan ganda selama pengiriman IPv6 masih diperbaiki. Pengalihan IPv4 tidak membangun cakupan IPv6, dan tidak ada pengaturan yang menyiratkan yang lain.

Jaga agar lalu lintas kontrol yang menjadi sandaran IPv6 tetap berfungsi di bawah kebijakan apa pun yang Anda terapkan. Pesan Packet Too Big adalah korban klasik firewall yang hanya mengizinkan TCP dan UDP, dan membuangnya menghasilkan koneksi yang terbentuk lalu macet pada transfer lebih besar.

Pengumuman router adalah bagian bergerak ketiga. Jika gateway mulai mengumumkan di uplink, itu dapat mengubah apa yang klien dan tetangga yakini tentang prefiks di tautan, yang dapat diam-diam membatalkan desain yang baru saja Anda dokumentasikan.

Catat desainnya agar pembangunan ulang mereproduksinya

Tuliskan tiga objek secara terpisah: alokasi klien, rute tujuan klien, dan metode pengiriman alokasi dari upstream. Pembaca yang memiliki ketiganya dapat membangun ulang penerapan; pembaca yang hanya memiliki pengaturan kumpulan akan mereproduksi bug aslinya.

Lalu uji arah balik secara eksplisit, dengan paket yang harus kembali dari luar. Manual openvpn(8) mencakup opsi server-ipv6 dan redirect, dan konfirmasi perutean dari penyedia Anda mencakup separuh yang tidak dapat dilakukan manual.