IPv6-præfiksdelegering på tværs af en site-to-site-VPN: tjekliste

At rejse tunnelen er den nemme halvdel. Jeg har set et site-to-site-link forblive etableret i dage, mens hver vært på det fjerne LAN fik tavshed tilbage, fordi det delegerede præfiks bag den gateway var konfigureret på en grænseflade, men aldrig blevet routet ind i tunnelen. Tunneladresserne svarede på ping hele tiden, og netop derfor kiggede ingen på præfikset. Her er den rækkefølge, jeg kontrollerer, når et delegeret IPv6-præfiks skal krydse en site-VPN: præfiksmap, trafikvælgere, videresendelse og firewall, derefter returvejen.

Skriv præfiksmapet, før du rører tunnelen

Præfiksdelegering giver en blok til den router, der bad om den. Den installerer ikke en rute på peer'en, udvider ikke blokken on-link og fortæller ikke den fjerne gateway, hvad der ligger bag den anmodende router. De tre ting er dit arbejde, og de hører i en adresseplan, før nogen konfigurationsfil ændres.

For hvert site skal du notere det delegerede præfiks, den /64, der faktisk bruges på LAN'et, tunneladresserne og ejeren af hver rute. Udbyderen delegerer 2001:db8:a1::/56 til site A, som betjener 2001:db8:a1:10::/64 på sit LAN; site B beholder 2001:db8:b2::/64. Hvis site A kun betjener den ene /64, bør begge ender nævne 2001:db8:a1:10::/64 i stedet for hele /56.

To fejl dukker næsten hver gang op. Den ene er at behandle det fjerne præfiks som on-link, bro det eller sætte det på tunnelgrænsefladen, så gatewayen svarer på nabo-solicitering for værter, den ikke kan nå. Den anden er at annoncere hele /56, når kun én /64 er konfigureret: rutetabellen hævder, at blokken er nåelig, og de fleste adresser falder i et sort hul.

Få begge enders trafikvælgere til at matche ruterne

IKEv2 og WireGuard afviser begge trafik, der ikke passer, stilfærdigt nok til at tunnelen stadig ser sund ud.

I strongSwan er vælgerne eksplicitte. På 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=start

Site B's conn spejler de to subnets. Når de er uenige, afviser responderen CHILD_SA'en med TS_UNACCEPTABLE, så den underordnede SA aldrig kommer op, selvom IKE_SA'en gjorde. På begge sider skal det konfigurerede subnet svare til det, den lokale kerne router mod tunnelen.

WireGuard bærer den samme information i AllowedIPs, med et twist: AllowedIPs er et kildefilter ved modtagelse såvel som en rute ved afsendelse. Hvis site B's peer-post for site A udelader 2001:db8:a1:10::/64, ankommer pakker fra site A på et gyldigt handshake og droppes som ikke tilladte. Det giver det velkendte mønster med et handshake, der hele tiden fornyes, mens der aldrig forlader et svar. Sammenlign begge ender med wg show wg0 allowed-ips. Tjek listen igen, hver gang delegeringen ændres; en forældet /64 holder sessionen oppe og det nye præfiks unåeligt.

Udeluk videresendelse, firewall og MTU først

Før du læser endnu en loglinje, skal du bekræfte, at gatewayerne overhovedet videresender. sysctl net.ipv6.conf.all.forwarding skal returnere 1 på begge, også anvendt på tunnel- og LAN-grænsefladerne. Der følger en fælde med: når videresendelse er slået til, holder en grænseflade med accept_ra=1 op med at acceptere routerannoncer fra udbyderen, så boksen kan miste sin opstrøms standardrute, mens den router perfekt inde i tunnelen. Sæt accept_ra=2, hvor der stadig er brug for en RA fra udbyderen.

Derefter skal firewallreglerne tillade præfikset i begge retninger, og ICMPv6 skal overleve: nabo-opdagelse, pakke-for-stor og uopnåelig destination er ikke valgfrie. Dropper du dem, bryder path MTU-opdagelsen, og du får forbindelser, der åbner og derefter går i stå på det første store svar. Et minimalt par regler ser sådan ud:

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'en ligger bag det. En tunnel krymper den brugbare MTU under 1500, og IPv6 kræver, at hvert link bærer mindst 1280. Små pings går igennem, en SSH-session fryser på en stor byge, og /proc/net/snmp6 viser pakke-for-stor-beskeder, der aldrig kommer tilbage. Sæt tunnelens MTU eksplicit, eller clamp TCP MSS i mangle-tabellen, og lad den ICMPv6, der rapporterer den mindre MTU, vende tilbage.

Test returvejen, ikke tunneladressen

Det svigt, der koster mest tid, er envejsrouting. Hver gateway router det fjerne præfiks ind i tunnelen, men værterne svarer gennem deres egen standardgateway, fordi det er der, deres /64 bor. At få en pakke frem til destinationen er kun halve vejen.

To kommandoer afgør det meste. På site A viser ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5, hvilken grænseflade et svar fra den kilde ville bruge; kør spejlkontrollen på site B. Generér derefter trafik fra en vært i stedet for gatewayen, og sammenlign tællere i begge ender.

Hvis nabo-solicitering for det fjerne præfiks dukker op på tunnelen, er det præfiks on-link et sted, hvor det ikke burde være; ret det, før du justerer ruter. Proxy NDP dækker tilfælde, hvor broing reelt er nødvendig, og er ikke en erstatning for en rute.

Planlæg, at præfikset skifter under dig

Præfiksdelegering er en lejeaftale mellem den delegerende og den anmodende router, og en fornyelse kan give en anden blok: et andet /56 efter en udbyderflytning eller en kortere leje, end tunnelen har været oppe. Hvert sted, der nævner det gamle præfiks, bliver forældet på én gang: ruter, vælgere, AllowedIPs, firewallregler, DNS-poster og enhver overvågning, der hardcoder bogstavelige adresser. Meddelelsesflowet er i RFC 8415.

Hvor præfikset forventes at flytte sig, skal du holde en intern adresseplan, der ikke afhænger af det, og oversætte ved grænsen. NPTv6 er den statsløse mulighed og holder intern politik læsbar, men det er præfiksoversættelse, ikke et magisk lag: /64-grænser skal passe sammen, kontrolsummer justeres, og applikationer, der indlejrer bogstavelige adresser, går stadig i stykker. Hvis du beholder udbyderadresser fra ende til ende, skal du notere lejeadfærden og en ændringsprocedure i adresseplanen.

Slut af med en test, der overlever tid: en tilladt vært på hvert LAN når en tjeneste på det andet LAN, svaret vender tilbage gennem tunnelen, og det samme par virker stadig efter en genstart af tunnelen og en fornyelse af delegeringen. Hvis den sidste del fejler, afhænger designet af tilstand, der ikke overlever ugen.