Delegasi Prefiks IPv6 Merentas VPN Tapak-ke-Tapak: Senarai Semak

Menaikkan terowong ialah separuh yang mudah. Saya pernah melihat pautan tapak-ke-tapak kekal terjalin berhari-hari sementara setiap hos di LAN jauh hanya menerima kesenyapan, kerana prefiks yang didelegasikan di belakang gateway itu dikonfigurasikan pada antara muka tetapi tidak pernah dihalakan ke dalam terowong. Alamat terowong menjawab ping sepanjang masa, dan itulah sebabnya tiada siapa memeriksa prefiks. Berikut urutan yang saya periksa apabila prefiks IPv6 yang didelegasikan perlu merentas VPN tapak-ke-tapak: peta prefiks, pemilih trafik, pemajuan dan firewall, kemudian laluan balik.

Tulis peta prefiks sebelum menyentuh terowong

Delegasi prefiks memberikan satu blok kepada penghala yang memintanya. Ia tidak memasang laluan pada rakan, tidak melanjutkan blok itu secara on-link, dan tidak memberitahu gateway jauh apa yang berada di belakang penghala peminta. Ketiga-tiganya perlu anda konfigurasikan sendiri, dan ia tergolong dalam pelan pengalamatan sebelum mana-mana fail konfigurasi berubah.

Bagi setiap tapak, catat prefiks yang didelegasikan, /64 yang sebenarnya digunakan pada LAN, alamat terowong dan pemilik setiap laluan. Penyedia mendelegasikan 2001:db8:a1::/56 kepada tapak A, yang menyediakan 2001:db8:a1:10::/64 pada LAN-nya; tapak B mengekalkan 2001:db8:b2::/64. Jika tapak A hanya menyediakan satu /64 itu, kedua-dua hujung patut menamakan 2001:db8:a1:10::/64 dan bukan keseluruhan /56.

Dua kesilapan hampir selalu muncul. Satu ialah menganggap prefiks jauh sebagai on-link, menjambatannya atau meletakkannya pada antara muka terowong sehingga gateway menjawab permintaan jiran bagi hos yang tidak dapat dicapainya. Satu lagi ialah mengiklankan keseluruhan /56 apabila hanya satu /64 dikonfigurasikan: jadual laluan mendakwa blok itu boleh dicapai dan kebanyakan alamat jatuh ke lubang hitam.

Selaraskan pemilih trafik kedua-dua hujung dengan laluan

IKEv2 dan WireGuard kedua-duanya menolak trafik yang tidak sepadan, cukup senyap sehingga terowong masih kelihatan sihat.

Dalam strongSwan pemilihnya eksplisit. Pada tapak 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 tapak B mencerminkan kedua-dua subnet. Apabila ia tidak bersetuju, responden menolak CHILD_SA dengan TS_UNACCEPTABLE, jadi child SA tidak pernah naik walaupun IKE_SA sudah naik. Pada kedua-dua belah, subnet yang dikonfigurasikan mesti sama dengan apa yang dihalakan kernel setempat ke arah terowong.

WireGuard membawa maklumat yang sama dalam AllowedIPs, dengan satu kelainan: AllowedIPs ialah penapis sumber semasa menerima dan juga laluan semasa menghantar. Jika entri peer tapak B untuk tapak A tertinggal 2001:db8:a1:10::/64, paket dari tapak A tiba dengan handshake yang sah dan digugurkan sebagai tidak dibenarkan. Itu menghasilkan corak biasa handshake yang terus diperbaharui sementara tiada balasan keluar. Bandingkan kedua-dua hujung dengan wg show wg0 allowed-ips. Semak semula senarai itu setiap kali delegasi berubah; /64 yang lapuk mengekalkan sesi dan menjadikan prefiks baharu tidak dapat dicapai.

Singkirkan pemajuan, firewall dan MTU dahulu

Sebelum membaca baris log lagi, pastikan gateway memajukan sama sekali. sysctl net.ipv6.conf.all.forwarding mesti mengembalikan 1 pada kedua-duanya, digunakan juga pada antara muka terowong dan LAN. Satu perangkap menyertainya: apabila pemajuan dihidupkan, antara muka dengan accept_ra=1 berhenti menerima pengiklanan penghala daripada penyedia, jadi mesin boleh kehilangan laluan lalai huluan walaupun menghalakan dengan sempurna di dalam terowong. Tetapkan accept_ra=2 di tempat yang masih memerlukan RA penyedia.

Peraturan firewall kemudian mesti membenarkan prefiks dalam kedua-dua arah, dan ICMPv6 mesti bertahan: penemuan jiran, packet-too-big dan destination-unreachable bukan pilihan. Gugurkannya dan penemuan MTU laluan rosak, memberi anda sambungan yang terbuka lalu tersekat pada respons besar pertama. Sepasang peraturan minimum kelihatan 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 belakang itu. Terowong mengecilkan MTU yang boleh digunakan di bawah 1500, dan IPv6 mewajibkan setiap pautan membawa sekurang-kurangnya 1280. Ping kecil lulus, sesi SSH membeku pada letusan besar, dan /proc/net/snmp6 menunjukkan mesej packet-too-big yang tidak pernah kembali. Tetapkan MTU terowong secara eksplisit, atau ketatkan MSS TCP dalam jadual mangle, dan biarkan ICMPv6 yang melaporkan MTU lebih kecil kembali.

Uji laluan balik, bukan alamat terowong

Kegagalan yang paling banyak memakan masa ialah penghalakan sehala. Setiap gateway menghalakan prefiks jauh ke dalam terowong, tetapi hos membalas melalui gateway lalai mereka sendiri kerana di situlah /64 mereka. Menghantar paket ke destinasinya hanyalah separuh laluan.

Dua arahan menyelesaikan sebahagian besar. Pada tapak A, ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 menunjukkan antara muka mana yang akan digunakan oleh balasan daripada sumber itu; jalankan pemeriksaan cermin pada tapak B. Kemudian jana trafik daripada hos dan bukan gateway, dan bandingkan pembilang pada kedua-dua hujung.

Jika permintaan jiran untuk prefiks jauh muncul pada terowong, prefiks itu on-link di tempat yang sepatutnya tidak; betulkan itu sebelum menyesuaikan laluan. Proxy NDP meliputi kes yang benar-benar memerlukan penjambatan, bukan pengganti laluan.

Rancang perubahan prefiks di bawah anda

Delegasi prefiks ialah pajakan antara penghala pendelegasi dan peminta, dan pembaharuan boleh mengembalikan blok yang berbeza: /56 lain selepas penghijrahan penyedia, atau pajakan lebih pendek daripada tempoh terowong naik. Setiap tempat yang menamakan prefiks lama menjadi lapuk serentak: laluan, pemilih, AllowedIPs, peraturan firewall, rekod DNS dan sebarang pemantauan yang mengodkan alamat literal. Aliran mesej ada dalam RFC 8415.

Di mana prefiks dijangka bergerak, kekalkan pelan pengalamatan dalaman yang tidak bergantung padanya dan terjemahkan di sempadan. NPTv6 ialah pilihan tanpa keadaan dan mengekalkan dasar dalaman boleh dibaca, tetapi ia terjemahan prefiks, bukan lapisan ajaib: sempadan /64 mesti sejajar, checksum diselaraskan, dan aplikasi yang membenamkan alamat literal masih rosak. Jika anda mengekalkan alamat penyedia hujung ke hujung, catat kelakuan pajakan dan prosedur perubahan dalam pelan pengalamatan.

Akhiri dengan ujian yang bertahan sepanjang masa: hos dibenarkan pada setiap LAN mencapai perkhidmatan pada LAN yang lain, balasan kembali melalui terowong, dan pasangan yang sama masih berfungsi selepas terowong dimulakan semula dan delegasi diperbaharui. Jika bahagian terakhir gagal, reka bentuk bergantung pada keadaan yang tidak akan bertahan seminggu.