IPv6-Prefix-Delegatioun iwwer eng Site-zu-Site-VPN: Checklist
Kontrollen fir e delegéierten IPv6-Prefix iwwer eng Site-zu-Site-VPN ze routeren: Prefixkaart, Traffic-Selectoren, Forwarding, MTU, Réckwee an Ëmnummeréierung.
Den Tunnel opzebauen ass déi einfach Halschent. Ech hunn eng Site-zu-Site-Verbindung gesinn, déi Deeg laang opgebaut bliwwen ass, wärend all Host am wäiten LAN just Stille zeréckkrut, well de delegéierte Prefix hannert deem Gateway op engem Interface konfiguréiert war, awer ni an den Tunnel geroutet gouf. D'Tunneladressen hunn déi ganz Zäit op Pings geäntwert, an genau dofir huet kee no dem Prefix gekuckt. Hei ass d'Reiefolleg, déi ech kontrolléieren, wann en delegéierten IPv6-Prefix iwwer eng Site-VPN muss: d'Prefixkaart, d'Traffic-Selectoren, Forwarding a Firewall, an dann de Réckwee.
Schreif d'Prefixkaart, ier s den Tunnel beréierst
D'Prefix-Delegatioun gëtt enger Block un de Router, deen en ugefrot huet. Si installéiert keng Route um Peer, verlängert dee Block net on-link, an seet dem wäite Gateway net, wat hannert dem ufroende Router läit. Déi dräi Saachen musst du konfiguréieren, an se gehéieren an en Adressplang, ier eng Konfiguratiounsdatei sech ännert.
Fir all Site notéier déi delegéiert Prefix, den /64 deen tatsächlech am LAN benotzt gëtt, d'Tunneladressen an den Besëtzer vun all Route. De Provider delegéiert 2001:db8:a1::/56 un de Site A, deen 2001:db8:a1:10::/64 op sengem LAN zerwéiert; de Site B behält 2001:db8:b2::/64. Wann de Site A nëmmen deen een /64 zerwéiert, sollten béid Enner 2001:db8:a1:10::/64 nennen an net de ganze /56.
Zwee Feeler erschéngen bal ëmmer. Ee ass, de wäite Prefix als on-link ze behandelen, en ze bridgen oder op den Tunnelinterface ze setzen, sou datt de Gateway op Noper-Ufroe fir Hosten äntwert, déi en net erreeche kann. Dee aneren ass, de ganze /56 uzekënnegen, wann nëmmen een /64 konfiguréiert ass: d'Routentabelle behaapt, de Block wier erreechbar, an déi meescht Adressen Enn am schwaarze Lach.
Passt d'Traffic-Selectoren vun béide Enner un d'Routen un
IKEv2 a WireGuard refuséieren allebéid net passend Traffic, duerch genuch Rou, datt den Tunnel nach ëmmer gesond ausgesäit.
Am strongSwan sinn d'Selectoren explizit. Um Site 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=startD'conn vum Site B spigelt déi zwee Subnetzer. Wa se sech net eens sinn, refuséiert de Responder de CHILD_SA mat TS_UNACCEPTABLE, sou datt de child SA ni opkënnt, obwuel den IKE_SA et gemaach huet. Op béide Säiten muss de konfiguréierte Subnetz deem entspriechen, wat de lokale Kernel Richtung Tunnel routet.
WireGuard dréit déi selwecht Informatioun an AllowedIPs, mat engem Trick: AllowedIPs ass e Quellfilter beim Empfang an eng Route beim Senden. Wann den Peer-Andrag vum Site B fir de Site A 2001:db8:a1:10::/64 vergësst, kommen d'Pakete vum Site A op engem gültegen Handshake un a ginn als net erlaabt verworfen. Dat gëtt dat bekannt Muster vun engem Handshake, dee sech ëmmer erëm erneiert, wärend keng Äntwert je erausgeet. Vergläicht béid Enner mat wg show wg0 allowed-ips. Iwwerpréift déi Lëscht all Kéier, wann d'Delegatioun sech ännert; en ale /64 hält d'Sessioun um Liewen an den neie Prefix onerreechbar.
Schléisst Forwarding, Firewall an MTU fir d'éischt aus
Ier s du nach eng Logzeil lies, confirméier, datt d'Gateways iwwerhaapt forwarden. sysctl net.ipv6.conf.all.forwarding muss 1 op béide zréckginn, och op den Tunnel- an LAN-Interfacen ugewend. Eng Fal kënnt mat: soubal Forwarding un ass, hält en Interface mat accept_ra=1 op, Routerannoncen vum Provider ze akzeptéieren, sou datt d'Maschinn hir Upstream-Defaultroute ka verléieren, och wann se am Tunnel perfekt routet. Setz accept_ra=2, wou nach eng Provider-RA gebraucht gëtt.
D'Firewallregele mussen dann de Prefix a béid Richtungen erlaben, an ICMPv6 muss iwwerliewen: Noperentdeckung, packet-too-big an destination-unreachable sinn net optional. Wann s du se fale léisst, geet d'Path-MTU-Entdeckung futti, an s du kréis Verbindungen, déi sech opmaachen an dann bei der éischter grousser Äntwert stoppen. E minimale Regelpaar gesäit sou aus:
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 } acceptD'MTU steet hannert deem. En Tunnel verklengert déi notzbar MTU ënner 1500, an IPv6 verlaangt, datt all Link op d'mannst 1280 dréit. Kleng Pings kommen duerch, eng SSH-Sessioun fréiert bei engem groussen Burst, an /proc/net/snmp6 weist packet-too-big-Meldungen, déi ni zréckkommen. Setz d'Tunnel-MTU explizit, oder klammt d'TCP-MSS an der mangle-Tabelle, a loosst den ICMPv6, dee méi kleng MTU mellt, zréckkommen.
Test de Réckwee, net d'Tunneladress
De Feeler, deen am meeschten Zäit kascht, ass ee-wee Routing. All Gateway routet de wäite Prefix an den Tunnel, awer d'Hoste äntwerten duerch hire eigenen Default-Gateway, well do hiren /64 läit. E Paket bis un d'Zil ze bréngen ass just d'Halschent vum Wee.
| What you see | Likely cause | First check |
|---|---|---|
| Tunnel up, every host silent | remote prefix not routed into the tunnel | ip -6 route get on both gateways |
| Handshake renews, no replies | source prefix missing from selectors or AllowedIPs | ipsec statusall, wg show allowed-ips |
| Small pings pass, transfers stall | MTU or ICMPv6 packet-too-big filtered | /proc/net/snmp6 counters |
| Old prefix still works | stale /64 left in routes or selectors | delegation lease and route table |
Zwee Kommandoen reegelen de gréissten Deel. Um Site A weist ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5, wéi en Interface eng Äntwert vun där Quell géif benotzen; maach déi gespigelt Kontroll um Site B. Dann generéier Traffic vun engem Host an net vum Gateway, a vergläich d'Zieler op béide Enner.
Wann Noper-Ufroe fir de wäite Prefix um Tunnel erschéngt, ass dee Prefix iergendwou on-link, wou en net sollt sinn; fixéier dat, ier s d'Routen upasst. Proxy NDP deckt d'Fäll of, wou Bridging wierklech néideg ass, an net als Ersatz fir eng Route.
Plang domat, datt de Prefix sech ënner dir ännert
D'Prefix-Delegatioun ass e Lease tëscht dem delegéierenden an dem ufroende Router, an eng Erneierung kann en anere Block zréckginn: en aneren /56 no enger Provider-Migratioun, oder e méi kuerze Lease wéi den Tunnel scho besteet. All Plaz, déi de ale Prefix nennt, gëtt op eemol al: Routen, Selectoren, AllowedIPs, Firewallregele, DNS-Andräg an all Iwwerwaachung, déi literar Adressen hardcodéiert. De Message-Flow ass an RFC 8415.
Wou de Prefix sech wuel beweegt, hal en internen Adressplang, deen net dovun ofhänkt, a iwwersetz um Rand. NPTv6 ass déi stateless Optioun a hält déi intern Politik liesbar, awer et ass Prefix-Iwwersetzung, keng magesch Schicht: /64-Grenze mussen iwwerenee passen, Checksumme ginn ugepasst, an Applikatiounen, déi literar Adressen integréieren, briechen nach ëmmer. Wann s du Provideradressen Enn zu Enn behält, notéier d'Lease-Verhalen an eng Ännerungsprozedur am Adressplang.
Schléiss mat engem Test of, deen d'Zäit iwwersteet: en erlaabten Host op all LAN erreecht e Service um aneren LAN, d'Äntwert kënnt duerch den Tunnel zréck, an dat selwecht Paar funktionéiert nach no engem Tunnelrestart an enger Delegatiouns-Erneierung. Wann den leschten Deel feelt, hänkt den Design vun engem Zoustand of, deen d'Woch net iwwersteet.