Prefiks cabang IPv6: iroute-ipv6 atau route-ipv6 di server?

Dua direktif dengan nama hampir sama muncul di setiap contoh yang berfungsi, dan menyalin salah satunya tanpa yang lain menghasilkan terowongan yang tampak benar tetapi diam-diam membuang prefiks cabang. Keduanya melakukan pekerjaan berbeda di dua sisi batas yang sama: satu mengajarkan kernel server di mana sebuah prefiks berada, yang lain mengajarkan OpenVPN klien terautentikasi mana yang membawanya. Jika keduanya benar, prefiks akan mengalir; jika hanya satu benar, paket punya rute tetapi tidak punya pemilik.

Dua direktif, dua pekerjaan berbeda

route-ipv6 adalah pemasangan rute biasa: server menambahkan rute kernel yang mengarahkan prefiks ke antarmuka terowongannya. iroute-ipv6 termasuk konteks khusus klien dan menyatakan kepemilikan internal, sehingga daemon tahu bahwa lalu lintas untuk prefiks itu harus dikirim ke klien tertentu alih-alih ke peer mana pun yang kebetulan dinamai oleh rute kernel.

Yang satu soal tabel penerusan kernel, yang lain soal model perutean internal daemon. Memisahkan keduanya menjelaskan mengapa konfigurasi yang tampak lengkap tetap bisa membuang prefiks. Itu juga menjelaskan mengapa jaringan yang sama muncul dua kali di setiap contoh yang berfungsi. Tidak ada baris yang berlebihan.

Dalam penyiapan ruang pengguna tradisional keduanya diperlukan dan saling melengkapi. Rute kernel saja membuat daemon tidak bisa memilih peer. iroute saja membuat kernel tanpa jalur ke terowongan. Dari sinilah sebagian besar kebingungan tentang berkas per klien berasal: berkas itu bukan entri tabel rute, dan entri rute bukan pernyataan kepemilikan.

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

Tempat masing-masing

Rute masuk ke konfigurasi terkelola server, tempat ia berlaku untuk proses server itu. iroute masuk ke berkas khusus klien yang dinamai menurut identitas terautentikasi perangkat cabang.

Nama berkas yang tidak cocok dengan identitas efektif tidak pernah dibaca, dan gejalanya sama persis dengan iroute yang hilang. Periksa identitas yang diautentikasi server, lalu periksa nama berkas karakter demi karakter.

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

Jaga agar kumpulan alamat dan prefiks cabang tetap terpisah, karena tumpang tindihnya menciptakan teka-teki yang tidak bisa dipecahkan direktif mana pun.

Apa yang dibutuhkan klien lain

Klien kedua yang harus mencapai cabang itu membutuhkan pengumuman, bukan kepemilikan. Dorong prefiks ke klien yang Anda maksudkan, dalam konteks klien atau grup yang sesuai dengan konfigurasi Anda.

Jangan kirimkan ke cabang itu sendiri, karena perangkat tersebut sudah memiliki prefiks sebagai jaringan terhubung.

Mengirimkannya ke semua orang adalah pilihan dengan konsekuensi: setiap klien lalu percaya bahwa cabang dapat dijangkau melalui terowongan, termasuk klien yang tidak pernah Anda maksudkan diberi akses itu. Pengumuman pada praktiknya adalah keputusan akses, meskipun direktifnya tampak seperti pekerjaan pipa. referensi opsi server mendokumentasikan iroute-ipv6 sebagai kepemilikan khusus klien, dan itulah pembedaan yang layak dipertahankan.

Jalur balik pada perangkat cabang

Kepemilikan hanya membantu jika cabang meneruskan paket dan LAN-nya tahu cara menjawab. Aktifkan penerusan IPv6 pada perangkat cabang, dan pastikan host di LAN-nya mengirim lalu lintas untuk kumpulan VPN kembali ke arah cabang, bukan ke rute default yang tidak mengenal kumpulan itu.

Jalur balik itu adalah padanan IPv6 dari masalah rute hilang yang dialami orang dengan IPv4.

Periksa dari host LAN dengan pencarian alamat kumpulan VPN, bukan dari cabang itu sendiri. Pencarian yang dilakukan di router menjawab pertanyaan yang berbeda dari yang diajukan pengguna Anda, dan keduanya cukup sering tidak sepakat sehingga perintah tambahan itu sepadan.

Ketika pasangan itu masih belum cukup

Beberapa penerapan tidak memakai jalur ini sama sekali. Jalur data kernel dan server yang dikelola produk memiliki penanganan rute sendiri yang didukung, dan contoh ruang pengguna mungkin tidak langsung dapat diterjemahkan.

Pastikan jalur data mana yang dipakai build Anda sebelum menyalin direktif dari tutorial yang ditulis untuk yang lain.

Akhirnya, ingat cakupan alamat: prefiks lokal unik seperti fd00:7a::/64 bersifat privat secara desain dan tidak mengatakan apa pun tentang keterjangkauan IPv6 publik. Perlakukan sebagai akses internal, dan pertahankan egress internet sebagai pertanyaan terpisah dengan kebijakannya sendiri.