At dele dit /64 ruter ikke IPv6 til VPN-klienter

Klienten viser en global IPv6-adresse, håndtrykket er fuldført, og intet kommer tilbage fra internettet. Puljeindstillingen ser korrekt ud, fordi den er korrekt; adressen er gyldig, og tunnelen bærer den. Det, der fejler, er levering, og levering afhænger af en beslutning taget oven over VPN-serveren, som ingen konfiguration på klientsiden kan påvirke.

Myten: en del af dit /64 er allerede nåbar

Historien er tiltalende: serveren har et offentligt /64, skær det over på midten, giv den anden halvdel til VPN-puljen, og de klienter er nu på internettet. At dele præfikset tildeler faktisk adresser uden kollisioner. Det ændrer ikke, hvordan upstream-netværket beslutter, hvor en pakke til en af disse adresser skal hen.

IPv6 har ikke et standardoversættelseslag at falde tilbage på, så returvejen skal eksistere som routing eller som levering på linkniveau. En pakke, der er adresseret til en klients tunneladresse, ankommer til upstream-routeren, og den router træffer en videresendelsesbeslutning ud fra sin egen tabel. Hvis tabellen peger på det fysiske link, går pakken der, uanset hvad din VPN-server tror.

Det er hele fejlen: retningen frem virker, fordi din server sender den, og returretningen dør én hop væk, fordi upstream aldrig lærte, at klienten findes.

Hvad levering på linket egentlig kræver

Når upstream betragter hele /64 som værende på det fysiske link, opløser den hver destinationsadresse med naboopdagelse. Den sender en anmodning på det link og forventer, at ejeren af adressen svarer. En VPN-klient bag en tunnel er ikke på det link og kan ikke svare, så anmodningen forbliver ubesvaret, og pakken kasseres.

At udskære et /65 ændrer ikke den forventning. Upstream behandler stadig området som på linket, fordi det eneste, der ville få den til at skifte mening, er en rute eller en proxy, der svarer på klientens vegne. Ingen af dem dukker op, fordi du redigerede en VPN-konfiguration. Netop det gab er grunden til, at en pulje kan fungere perfekt mellem sine egne klienter og alligevel være utilgængelig fra alle andre steder.

Proxy-naboopdagelse er mekanismen, der kan bygge bro mellem de to verdener. Gatewayen svarer på anmodninger for de specifikke klientadresser, den ejer, og videresender trafikken ind i tunnelen. Det virker, og det skal afgrænses præcis til de adresser med en livscyklus, der følger puljen, fordi at svare for en adresse, du ikke længere betjener, gør andres trafik til et sort hul. Nogle upstreams accepterer ikke proxy-svar, de ikke forventede, så dette design kræver også udbyderens accept.

Hvad rutet levering kræver

Det renere design er en tildeling, som upstream faktisk ruter til din gateway. Det kan være et delegeret præfiks eller en statisk rute for en mindre blok, og kravet er det samme i begge tilfælde: upstreams tabel skal pege på din server for klientområdet. Så ankommer returtrafikken til gatewayen, og gatewayen videresender den ind i tunnelen.

Rutet levering fjerner spørgsmålet om naboopdagelse helt, og derfor er det værd at bede udbyderen om det, før du bygger noget smart. Bed om ruten skriftligt, og bekræft, at næste hop er den adresse, som upstream faktisk kan nå.

Begge design kræver stadig IPv6-videresendelse aktiveret på gatewayen og firewallregler, der tillader den videresendte strøm i begge retninger. Levering er en forudsætning, ikke en erstatning, for resten af vejen. En fungerende rute med videresendelse deaktiveret giver præcis samme stilhed som en manglende rute, så kontroller begge, før du redesigner noget.

To uafhængige ruter at få styr på

Puljepræfikset og klientens egen standardrute er separate indstillinger, og at forveksle dem giver delvis forbindelse, der ligner en brudt tunnel. Puljen fortæller serveren, hvilke adresser der skal uddeles. Klientens ruter afgør, hvilke destinationer klienten overhovedet sender ind i tunnelen.

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

Præfikset ovenfor er dokumentationsplads, og omdirigeringen gælder kun for IPv6, hvilket er præcis, hvad en dobbeltstak-udrulning ofte vil, mens IPv6-levering stadig rettes. En IPv4-omdirigering etablerer ikke IPv6-dækning, og ingen af indstillingerne forudsætter den anden.

Hold den kontroltrafik, som IPv6 afhænger af, kørende under hvilken politik du end anvender. Packet Too Big-beskeder er det klassiske offer for en firewall, der kun tillader TCP og UDP, og at kassere dem giver forbindelser, der etableres og derefter går i stå ved større overførsler.

Routerannonceringer er den tredje bevægelige del. Hvis gatewayen begynder at annoncere på uplinket, kan det ændre, hvad klienter og naboer tror om præfikser på linket, hvilket stille kan underminere det design, du netop har dokumenteret.

Dokumentér designet, så en genopbygning gengiver det

Skriv tre objekter ned hver for sig: klienttildelingen, klientens destinationsrute og upstreams leveringsmetode for tildelingen. En læser, der har alle tre, kan genopbygge udrulningen; en læser, der kun har puljeindstillingen, vil genskabe den oprindelige fejl.

Test derefter returretningen eksplicit med en pakke, der skal komme tilbage udefra. openvpn(8)-manualen dækker indstillingerne server-ipv6 og redirect, og din udbyders routingbekræftelse dækker den halvdel, manualen ikke kan.