Å dele opp /64-en din ruter ikke IPv6 til VPN-klienter

Klienten viser en global IPv6-adresse, håndtrykket er fullført, og ingenting kommer tilbake fra internett. Poolinnstillingen ser riktig ut fordi den er riktig; adressen er gyldig, og tunnelen bærer den. Det som svikter, er levering, og levering avhenger av en beslutning tatt over VPN-serveren som ingen konfigurasjon på klientsiden kan påvirke.

Myten: en del av /64-en din er allerede nåbar

Historien er fristende: serveren har en offentlig /64, del den i to, gi den andre halvdelen til VPN-poolen, og de klientene er nå på internett. Å dele prefikset tildeler faktisk adresser uten kollisjoner. Det endrer ikke hvordan upstream-nettverket bestemmer hvor en pakke til en av disse adressene skal gå.

IPv6 har ikke et standard oversettelseslag å falle tilbake på, så returveien må eksistere som ruting eller som levering på lenkenivå. En pakke adressert til en klients tunneladresse ankommer upstream-ruteren, og den ruteren tar en videresendingsbeslutning fra sin egen tabell. Hvis tabellen peker på den fysiske lenken, går pakken dit, uansett hva VPN-serveren din tror.

Det er hele feilen: retningen fremover virker fordi serveren din sender den, og returretningen dør én hopp unna fordi upstream aldri fikk vite at klienten finnes.

Hva levering på lenken egentlig krever

Når upstream betrakter hele /64-en som værende på den fysiske lenken, løser den opp hver måladdresse med nabooppdagelse. Den sender en forespørsel på den lenken og forventer at eieren av adressen svarer. En VPN-klient bak en tunnel er ikke på den lenken og kan ikke svare, så forespørselen forblir ubesvart og pakken forkastes.

Å skjære ut en /65 endrer ikke den forventningen. Upstream behandler fortsatt området som på lenken, fordi det eneste som ville fått den til å endre mening, er en rute eller en proxy som svarer på vegne av klienten. Ingen av dem dukker opp fordi du redigerte en VPN-konfigurasjon. Nettopp dette gapet er grunnen til at en pool kan fungere perfekt mellom sine egne klienter og likevel være utilgjengelig fra alle andre steder.

Proxy-nabooppdagelse er mekanismen som kan bygge bro mellom de to verdenene. Gatewayen svarer på forespørsler for de bestemte klientadressene den eier, og videresender trafikken inn i tunnelen. Det virker, og det må avgrenses nøyaktig til disse adressene med en livssyklus som følger poolen, fordi å svare for en adresse du ikke lenger betjener gjør andres trafikk til et svart hull. Noen upstreams godtar ikke proxy-svar de ikke forventet, så dette designet trenger også leverandørens samtykke.

Hva rutet levering krever

Det renere designet er en tildeling som upstream faktisk ruter til gatewayen din. Det kan være et delegert prefiks eller en statisk rute for en mindre blokk, og kravet er det samme i begge tilfeller: upstreams tabell må peke på serveren din for klientområdet. Da ankommer returtrafikken gatewayen, og gatewayen videresender den inn i tunnelen.

Rutet levering fjerner spørsmålet om nabooppdagelse helt, og derfor er det verdt å be leverandøren om det før du bygger noe smart. Be om ruten skriftlig, og bekreft at neste hopp er adressen upstream faktisk kan nå.

Begge designene trenger fortsatt IPv6-videresending aktivert på gatewayen og brannmurregler som tillater den videresendte strømmen i begge retninger. Levering er en forutsetning, ikke en erstatning, for resten av veien. En fungerende rute med videresending deaktivert gir nøyaktig samme stillhet som en manglende rute, så kontroller begge før du redesigner noe.

To uavhengige ruter å få riktig

Poolprefikset og klientens egen standardrute er separate innstillinger, og å forveksle dem gir delvis tilkobling som ser ut som en ødelagt tunnel. Poolen forteller serveren hvilke adresser som skal deles ut. Klientens ruter avgjør hvilke mål klienten i det hele tatt sender inn i tunnelen.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

Prefikset ovenfor er dokumentasjonsplass, og omdirigeringen gjelder bare IPv6, som er nettopp det en dobbeltstakk-utrulling ofte vil mens IPv6-leveringen fortsatt repareres. En IPv4-omdirigering etablerer ikke IPv6-dekning, og ingen av innstillingene forutsetter den andre.

Hold kontrolltrafikken som IPv6 avhenger av, i gang under hvilken som helst policy du bruker. Packet Too Big-meldinger er det klassiske offeret for en brannmur som bare tillater TCP og UDP, og å forkaste dem gir tilkoblinger som etableres og deretter stopper på større overføringer.

Ruterannonseringer er den tredje bevegelige delen. Hvis gatewayen begynner å annonsere på opplenken, kan det endre hva klienter og naboer tror om prefikser på lenken, noe som stille kan oppheve designet du nettopp dokumenterte.

Dokumenter designet slik at en gjenoppbygging gjenskaper det

Skriv ned tre objekter hver for seg: klienttildelingen, klientens målrute og upstreams leveringsmetode for tildelingen. En leser som har alle tre, kan bygge utrullingen på nytt; en leser som bare har poolinnstillingen, vil gjenskape den opprinnelige feilen.

Test deretter returretningen eksplisitt med en pakke som må komme tilbake utenfra. openvpn(8)-håndboken dekker alternativene server-ipv6 og redirect, og leverandørens rutingsbekreftelse dekker halvparten håndboken ikke kan.