IPv6-prefiksdelegering over en nettsted-til-nettsted-VPN: sjekkliste

Å få tunnelen opp er den lette halvdelen. Jeg har sett en nettsted-til-nettsted-forbindelse stå etablert i dager mens hver vert på det fjerne LAN-et bare fikk stillhet tilbake, fordi det delegerte prefikset bak den gatewayen var konfigurert på et grensesnitt, men aldri rutet inn i tunnelen. Tunneleadressene svarte på ping hele tiden, og nettopp derfor så ingen på prefikset. Her er rekkefølgen jeg kontrollerer når et delegert IPv6-prefiks må krysse en nettsted-VPN: prefikskartet, trafikkvelgerne, videresending og brannmur, og deretter returveien.

Skriv prefikskartet før du rører tunnelen

Prefiksdelegering gir en blokk til ruteren som ba om den. Den installerer ikke en rute på motparten, utvider ikke blokken on-link, og forteller ikke den fjerne gatewayen hva som ligger bak den forespørrende ruteren. Disse tre tingene må du konfigurere selv, og de hører hjemme i en adresseplan før noen konfigurasjonsfil endres.

For hvert nettsted, noter det delegerte prefikset, /64-en som faktisk brukes på LAN-et, tunneleadressene og eieren av hver rute. Leverandøren delegerer 2001:db8:a1::/56 til nettsted A, som betjener 2001:db8:a1:10::/64 på LAN-et sitt; nettsted B beholder 2001:db8:b2::/64. Hvis nettsted A bare betjener den ene /64-en, bør begge ender oppgi 2001:db8:a1:10::/64 i stedet for hele /56-en.

To feil dukker nesten alltid opp. Den ene er å behandle det fjerne prefikset som on-link, bro det eller sette det på tunnegrensesnittet slik at gatewayen svarer på nabohenvendelser for verter den ikke kan nå. Den andre er å annonsere hele /56-en når bare én /64 er konfigurert: rutetabellen hevder at blokken er tilgjengelig, og de fleste adressene faller i svart hull.

Tilpass trafikkvelgerne i begge ender til rutene

IKEv2 og WireGuard avviser begge trafikk som ikke stemmer, stille nok til at tunnelen fortsatt ser sunn ut.

I strongSwan er velgerne eksplisitte. På nettsted 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-oppføringen for nettsted B speiler de to subnettene. Når de er uenige, avviser responderen CHILD_SA med TS_UNACCEPTABLE, så child SA kommer aldri opp selv om IKE_SA gjorde det. På begge sider må subnettet som er konfigurert, være likt det den lokale kjernen ruter mot tunnelen.

WireGuard bærer den samme informasjonen i AllowedIPs, med en vri: AllowedIPs er et kildefilter ved mottak og en rute ved sending. Hvis peer-oppføringen for nettsted B mot nettsted A utelater 2001:db8:a1:10::/64, kommer pakker fra nettsted A inn på et gyldig handshake og blir droppet som ikke tillatt. Det gir det kjente mønsteret med et handshake som stadig fornyes mens ingen svar noen gang går ut. Sammenlign begge ender med wg show wg0 allowed-ips. Sjekk listen på nytt hver gang delegeringen endres; en utdatert /64 holder sesjonen oppe og det nye prefikset utilgjengelig.

Utelukk videresending, brannmur og MTU først

Før du leser enda en logglinje, bekreft at gatewayene videresender i det hele tatt. sysctl net.ipv6.conf.all.forwarding må returnere 1 på begge, også brukt på tunne- og LAN-grensesnittene. En felle følger med: når videresending er slått på, slutter et grensesnitt med accept_ra=1 å godta ruterannonser fra leverandøren, så maskinen kan miste den oppstrøms standardruten selv om den ruter perfekt inne i tunnelen. Sett accept_ra=2 der en leverandør-RA fortsatt trengs.

Brannmurreglene må så tillate prefikset i begge retninger, og ICMPv6 må overleve: naboaktivering, packet-too-big og destination-unreachable er ikke valgfrie. Dropper du dem, bryter MTU-oppdagelsen for stien sammen, og du får forbindelser som åpnes og deretter stopper på det første store svaret. Et minimalt regelpar ser slik ut:

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 ligger bak dette. En tunnel krymper den brukbare MTU-en under 1500, og IPv6 krever at hver lenke bærer minst 1280. Små ping går gjennom, en SSH-økt fryser på en stor byge, og /proc/net/snmp6 viser packet-too-big-meldinger som aldri kommer tilbake. Sett tunnelens MTU eksplisitt, eller klem TCP MSS i mangle-tabellen, og la ICMPv6 som melder om mindre MTU komme tilbake.

Test returveien, ikke tunneleadressen

Feilen som koster mest tid, er enveis ruting. Hver gateway ruter det fjerne prefikset inn i tunnelen, men verter svarer gjennom sin egen standardgateway fordi det er der /64-en deres bor. Å få en pakke til målet er halve veien.

To kommandoer ordner det meste. På nettsted A viser ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 hvilket grensesnitt et svar fra den kilden ville bruke; kjør speilkontrollen på nettsted B. Generer deretter trafikk fra en vert i stedet for gatewayen, og sammenlign tellerne i begge ender.

Hvis nabohenvendelsen for det fjerne prefikset dukker opp på tunnelen, er det prefikset on-link et sted det ikke skal være; fiks det før du justerer ruter. Proxy NDP dekker tilfeller der broing faktisk er nødvendig, ikke en erstatning for en rute.

Planlegg for at prefikset endres under deg

Prefiksdelegering er en leieavtale mellom den delegerende og den forespørrende ruteren, og en fornyelse kan gi en annen blokk: en annen /56 etter en leverandørmigrering, eller en kortere leie enn tunnelen har vært oppe. Hvert sted som navngir det gamle prefikset blir utdatert samtidig: ruter, velgere, AllowedIPs, brannmurregler, DNS-oppføringer og all overvåking som hardkoder litterære adresser. Meldingsflyten er i RFC 8415.

Der prefikset forventes å flytte seg, hold en intern adresseplan som ikke avhenger av det, og oversett ved grensen. NPTv6 er det tilstandsløse alternativet og holder den interne policyen lesbar, men det er prefiksoversettelse, ikke et magisk lag: /64-grenser må stemme, sjekksummer justeres, og applikasjoner som bygger inn litterære adresser bryter fortsatt. Hvis du beholder leverandøradresser ende til ende, noter leieatferden og en endringsprosedyre i adresseplanen.

Avslutt med en test som tåler tid: en tillatt vert på hvert LAN når en tjeneste på det andre LAN-et, svaret kommer tilbake gjennom tunnelen, og det samme paret fungerer fortsatt etter en tunnelomstart og en delegeringsfornyelse. Hvis den siste delen feiler, avhenger designet av tilstand som ikke overlever uken.