Delegasi Prefiks IPv6 Melintasi VPN Situs-ke-Situs: Daftar Periksa

Menaikkan terowongan adalah bagian yang mudah. Saya pernah melihat tautan situs-ke-situs tetap terjaga berhari-hari sementara setiap host di LAN jauh hanya menerima keheningan, karena prefiks yang didelegasikan di belakang gateway itu dikonfigurasi pada antarmuka tetapi tidak pernah dirutekan ke dalam terowongan. Alamat terowongan menjawab ping sepanjang waktu, dan justru itulah sebabnya tidak ada yang memeriksa prefiks. Berikut urutan yang saya periksa ketika prefiks IPv6 yang didelegasikan harus melintasi VPN situs-ke-situs: peta prefiks, pemilih lalu lintas, penerusan dan firewall, lalu jalur balik.

Tulis peta prefiks sebelum menyentuh terowongan

Delegasi prefiks memberikan satu blok kepada router yang memintanya. Ia tidak memasang rute pada peer, tidak memperluas blok itu on-link, dan tidak memberi tahu gateway jauh apa yang ada di belakang router peminta. Ketiga hal itu harus Anda konfigurasi sendiri, dan semuanya termasuk dalam rencana pengalamatan sebelum berkas konfigurasi mana pun berubah.

Untuk setiap situs, catat prefiks yang didelegasikan, /64 yang benar-benar dipakai di LAN, alamat terowongan, dan pemilik setiap rute. Penyedia mendelegasikan 2001:db8:a1::/56 ke situs A, yang melayani 2001:db8:a1:10::/64 di LAN-nya; situs B mempertahankan 2001:db8:b2::/64. Jika situs A hanya melayani satu /64 itu, kedua ujung sebaiknya menyebut 2001:db8:a1:10::/64, bukan seluruh /56.

Dua kesalahan hampir selalu muncul. Pertama, memperlakukan prefiks jauh sebagai on-link, menjembataninya atau menaruhnya di antarmuka terowongan sehingga gateway menjawab solicitation tetangga untuk host yang tidak dapat dijangkau. Kedua, mengiklankan seluruh /56 padahal hanya satu /64 yang dikonfigurasi: tabel rute mengklaim blok itu terjangkau dan sebagian besar alamat berakhir di lubang hitam.

Sesuaikan pemilih lalu lintas kedua ujung dengan rutenya

IKEv2 dan WireGuard sama-sama menolak lalu lintas yang tidak cocok, cukup diam sehingga terowongan tetap terlihat sehat.

Di strongSwan, pemilihnya eksplisit. Di situs A:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

conn situs B mencerminkan kedua subnet. Ketika keduanya tidak sepakat, responder menolak CHILD_SA dengan TS_UNACCEPTABLE, sehingga child SA tidak pernah naik meskipun IKE_SA sudah naik. Di kedua sisi, subnet yang dikonfigurasi harus sama dengan yang dirutekan kernel lokal ke arah terowongan.

WireGuard membawa informasi yang sama di AllowedIPs, dengan satu twist: AllowedIPs adalah filter sumber saat menerima sekaligus rute saat mengirim. Jika entri peer situs B untuk situs A melewatkan 2001:db8:a1:10::/64, paket dari situs A tiba pada handshake yang valid dan dibuang sebagai tidak diizinkan. Itu menghasilkan pola yang familier: handshake terus diperbarui sementara tidak ada balasan yang keluar. Bandingkan kedua ujung dengan wg show wg0 allowed-ips. Periksa ulang daftar itu setiap kali delegasi berubah; /64 yang usang membuat sesi tetap hidup dan prefiks baru tidak terjangkau.

Singkirkan dulu penerusan, firewall, dan MTU

Sebelum membaca baris log lagi, pastikan gateway benar-benar meneruskan. sysctl net.ipv6.conf.all.forwarding harus mengembalikan 1 di keduanya, juga diterapkan pada antarmuka terowongan dan LAN. Ada satu jebakan: setelah penerusan aktif, antarmuka dengan accept_ra=1 berhenti menerima iklan router dari penyedia, sehingga mesin bisa kehilangan rute default hulu meskipun merutekan dengan sempurna di dalam terowongan. Setel accept_ra=2 di tempat yang masih membutuhkan RA penyedia.

Aturan firewall kemudian harus mengizinkan prefiks di kedua arah, dan ICMPv6 harus bertahan: penemuan tetangga, packet-too-big, dan destination-unreachable bukan opsional. Buang semuanya dan penemuan MTU jalur rusak, memberi Anda koneksi yang terbuka lalu macet pada respons besar pertama. Sepasang aturan minimal terlihat seperti ini:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

MTU berada di balik itu. Terowongan mengecilkan MTU yang dapat dipakai di bawah 1500, dan IPv6 mewajibkan setiap tautan membawa setidaknya 1280. Ping kecil lolos, sesi SSH membeku pada ledakan besar, dan /proc/net/snmp6 menunjukkan pesan packet-too-big yang tidak pernah kembali. Setel MTU terowongan secara eksplisit, atau clamp MSS TCP di tabel mangle, dan biarkan ICMPv6 yang melaporkan MTU lebih kecil kembali.

Uji jalur balik, bukan alamat terowongan

Kegagalan yang paling banyak memakan waktu adalah perutean satu arah. Setiap gateway merutekan prefiks jauh ke dalam terowongan, tetapi host membalas melalui gateway default mereka sendiri karena di situlah /64 mereka berada. Mengantarkan paket ke tujuan hanyalah separuh jalur.

Dua perintah menyelesaikan sebagian besar masalah ini. Di situs A, ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 menunjukkan antarmuka mana yang akan dipakai balasan dari sumber itu; jalankan pemeriksaan cermin di situs B. Lalu hasilkan lalu lintas dari host, bukan dari gateway, dan bandingkan penghitung di kedua ujung.

Jika solicitation tetangga untuk prefiks jauh muncul di terowongan, prefiks itu on-link di suatu tempat yang seharusnya tidak; perbaiki itu sebelum menyesuaikan rute. Proxy NDP mencakup kasus yang benar-benar memerlukan jembatan, bukan pengganti rute.

Rencanakan perubahan prefiks di bawah Anda

Delegasi prefiks adalah sewa antara router pendelegasi dan peminta, dan pembaruan dapat mengembalikan blok yang berbeda: /56 lain setelah migrasi penyedia, atau sewa lebih pendek daripada usia terowongan. Setiap tempat yang menyebut prefiks lama langsung menjadi usang: rute, pemilih, AllowedIPs, aturan firewall, catatan DNS, dan pemantauan apa pun yang mengodekan alamat literal. Alur pesannya ada di RFC 8415.

Ketika prefiks diperkirakan bergerak, pertahankan rencana pengalamatan internal yang tidak bergantung padanya dan terjemahkan di perbatasan. NPTv6 adalah opsi tanpa status dan menjaga kebijakan internal tetap terbaca, tetapi itu terjemahan prefiks, bukan lapisan ajaib: batas /64 harus sejajar, checksum disesuaikan, dan aplikasi yang menyematkan alamat literal tetap rusak. Jika Anda mempertahankan alamat penyedia dari ujung ke ujung, catat perilaku sewa dan prosedur perubahan dalam rencana pengalamatan.

Akhiri dengan uji yang bertahan melintasi waktu: host yang diizinkan di setiap LAN mencapai layanan di LAN lain, balasannya kembali melalui terowongan, dan pasangan yang sama masih berfungsi setelah terowongan dimulai ulang dan delegasi diperbarui. Jika bagian terakhir gagal, desainnya bergantung pada status yang tidak akan bertahan seminggu.