IPv6-prefiksdelegering over ein nettstad-til-nettstad-VPN: sjekkliste

Å få tunnelen opp er den lette halvdelen. Eg har sett ei nettstad-til-nettstad-samband stå etablert i dagar medan kvar vert på det fjerne LAN-et berre fekk stille att, fordi det delegerte prefikset bak den gatewayen var konfigurert på eit grensesnitt, men aldri ruta inn i tunnelen. Tunneleadressene svara på ping heile tida, og nettopp difor såg ingen på prefikset. Her er rekkjefølgja eg kontrollerer når eit delegert IPv6-prefiks må krysse ein nettstad-VPN: prefikskartet, trafikkveljarane, videresending og brannmur, og deretter returvegen.

Skriv prefikskartet før du rører tunnelen

Prefiksdelegering gir ei blokk til rutaren som bad om ho. Ho installerer ikkje ei rute på motparten, utvidar ikkje blokka on-link, og fortel ikkje den fjerne gatewayen kva som ligg bak den førespurnadsrutaren. Desse tre tinga må du konfigurere sjølv, og dei høyrer heime i ein adresseplan før noka konfigurasjonsfil vert endra.

For kvar nettstad, noter det delegerte prefikset, /64-en som faktisk vert brukt på LAN-et, tunneleadressene og eigaren av kvar rute. Leverandøren delegerer 2001:db8:a1::/56 til nettstad A, som tenar 2001:db8:a1:10::/64 på LAN-et sitt; nettstad B held 2001:db8:b2::/64. Viss nettstad A berre tenar den eine /64-en, bør båe endar nemne 2001:db8:a1:10::/64 i staden for heile /56-en.

To feil dukkar nesten alltid opp. Den eine er å handsame det fjerne prefikset som on-link, bru det eller setje det på tunnegrensesnittet slik at gatewayen svarar på nabohenvendingar for vertar han ikkje kan nå. Den andre er å annonsere heile /56-en når berre éin /64 er konfigurert: rutetabellen hevdar at blokka er tilgjengeleg, og dei fleste adressene fell i svart hól.

Tilpass trafikkveljarane i båe endar til rutene

IKEv2 og WireGuard avviser båe trafikk som ikkje stemmer, stille nok til at tunnelen framleis ser sunn ut.

I strongSwan er veljarane eksplisitte. På nettstad 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øringa for nettstad B speglar dei to subnetta. Når dei er usamde, avviser svararen CHILD_SA med TS_UNACCEPTABLE, så child SA kjem aldri opp sjølv om IKE_SA gjorde det. På båe sider må subnettet som er konfigurert, vere likt det den lokale kjernen ruter mot tunnelen.

WireGuard ber den same informasjonen i AllowedIPs, med ein vri: AllowedIPs er eit kjeldefilter ved mottak og ei rute ved sending. Viss peer-oppføringa for nettstad B mot nettstad A utelèt 2001:db8:a1:10::/64, kjem pakkar frå nettstad A inn på eit gyldig handshake og vert droppade som ikkje tillatne. Det gir det kjende mønsteret med eit handshake som stadig vert fornya medan ingen svar nokon gong går ut. Samanlikn båe endar med wg show wg0 allowed-ips. Sjekk lista på nytt kvar gong delegeringa endrar seg; ein utdatert /64 held sesjonen oppe og det nye prefikset utilgjengeleg.

Utelukk videresending, brannmur og MTU fyrst

Før du les endå ei logglinje, stadfest at gatewayane videresender i det heile. sysctl net.ipv6.conf.all.forwarding må returnere 1 på båe, òg brukt på tunne- og LAN-grensesnitta. Ei felle følgjer med: når videresending er slått på, sluttar eit grensesnitt med accept_ra=1 å godta ruterannonsar frå leverandøren, så maskinen kan miste den oppstraums standardruta sjølv om han ruter perfekt inne i tunnelen. Set accept_ra=2 der ein leverandør-RA framleis trengst.

Brannmurreglane må så tillate prefikset i båe retningar, og ICMPv6 må overleve: naboaktivering, packet-too-big og destination-unreachable er ikkje valfrie. Droppar du dei, bryt MTU-oppdaginga for stien saman, og du får samband som opnar seg og deretter stoppar på det fyrste store svaret. Eit 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 ligg bak dette. Ein tunnel krympar den brukande MTU-en under 1500, og IPv6 krev at kvar lenkje ber minst 1280. Små ping går gjennom, ei SSH-økt frys på ein stor byge, og /proc/net/snmp6 viser packet-too-big-meldingar som aldri kjem tilbake. Set tunnelens MTU eksplisitt, eller klem TCP MSS i mangle-tabellen, og la ICMPv6 som melder om mindre MTU kome tilbake.

Test returvegen, ikkje tunneleadressa

Feilen som kostar mest tid, er einvegs ruting. Kvar gateway ruter det fjerne prefikset inn i tunnelen, men vertar svarar gjennom sin eigen standardgateway fordi det er der /64-en deira bur. Å få ein pakke til målet er halve vegen.

To kommandoar ordnar det meste. På nettstad A viser ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 kva grensesnitt eit svar frå den kjelda ville bruke; køyr spegelkontrollen på nettstad B. Generer deretter trafikk frå ein vert i staden for gatewayen, og samanlikn teljarane i båe endar.

Viss nabohenvendinga for det fjerne prefikset dukkar opp på tunnelen, er det prefikset on-link ein stad det ikkje skal vere; fiks det før du justerer ruter. Proxy NDP dekkjer tilfelle der broing faktisk er nødvendig, ikkje ei erstatning for ei rute.

Planlegg for at prefikset endrar seg under deg

Prefiksdelegering er ein leigeavtale mellom den delegerande og den førespurnadsrutaren, og ei fornying kan gi ei anna blokk: ein annan /56 etter ein leverandørmigrasjon, eller ei kortare leige enn tunnelen har vore oppe. Kvar stad som nemner det gamle prefikset vert utdatert samstundes: ruter, veljarar, AllowedIPs, brannmurreglar, DNS-oppføringar og all overvaking som hardkodar litterære adresser. Meldingsflyten er i RFC 8415.

Der prefikset er venta å flytte seg, hald ein intern adresseplan som ikkje avheng av det, og omset ved grensa. NPTv6 er det tilstandslause alternativet og held den interne policyen lesbar, men det er prefiksomsetjing, ikkje eit magisk lag: /64-grenser må stemme, sjekksummar vert justerte, og applikasjonar som byggjer inn litterære adresser bryt framleis. Viss du held leverandøradresser ende til ende, noter leigeåtferda og ein endringsprosedyre i adresseplanen.

Avslutt med ein test som toler tid: ein tillaten vert på kvart LAN når ein teneste på det andre LAN-et, svaret kjem tilbake gjennom tunnelen, og det same paret fungerer framleis etter ein tunnelomstart og ei delegeringsfornying. Viss den siste delen feilar, avheng designet av tilstand som ikkje overlever veka.