Å dela opp /64-en din rutar ikkje IPv6 til VPN-klientar

Klienten viser ei global IPv6-adresse, handtrykket er fullført, og ingenting kjem tilbake frå internett. Poolinnstillinga ser rett ut fordi ho er rett; adressa er gyldig, og tunnelen ber henne. Det som sviktar, er leveringa, og leveringa avheng av ei avgjerd teken over VPN-tenaren som ingen konfigurasjon på klientsida kan påverke.

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

Historia er freistande: tenaren har ein offentleg /64, del henne i to, gje den andre halvdelen til VPN-poolen, og desse klientane er no på internett. Å dela prefikset tildeler faktisk adresser utan kollisjonar. Det endrar ikkje korleis upstream-nettverket avgjer kvar ei pakke til ei av desse adressene skal gå.

IPv6 har ikkje eit standard omsetjingslag å falla tilbake på, så returvegen må finnast som ruting eller som levering på lenkenivå. Ei pakke adressert til tunneladressa til ein klient kjem fram til upstream-rutaren, og den rutaren tek ei vidaresendingsavgjerd frå sin eigen tabell. Viss tabellen peikar på den fysiske lenka, går pakka dit, uansett kva VPN-tenaren din trur.

Det er heile feilen: retninga framover verkar fordi tenaren din sender henne, og returretninga døyr éin hopp unna fordi upstream aldri fekk vita at klienten finst.

Kva levering på lenka eigentleg krev

Når upstream ser heile /64-en som verande på den fysiske lenka, løyser han opp kvar måladdresse med nabooppdaging. Han sender ei førespurnad på den lenka og ventar at eigaren av adressa svarar. Ein VPN-klient bak ein tunnel er ikkje på den lenka og kan ikkje svara, så førespurnaden blir ståande ubesvart og pakka blir kasta.

Å skjera ut ein /65 endrar ikkje den forventninga. Upstream handsamar framleis området som på lenka, fordi det einaste som ville fått han til å endra meining, er ei rute eller ein proxy som svarar på vegner av klienten. Ingen av dei dukkar opp fordi du redigerte ein VPN-konfigurasjon. Nettopp dette gapet er grunnen til at ein pool kan fungera perfekt mellom sine eigne klientar og likevel vera utilgjengeleg frå alle andre stader.

Proxy-nabooppdaging er mekanismen som kan byggja bru mellom dei to verdene. Gatewayen svarar på førespurnader for dei bestemte klientadressene han eig, og vidaresender trafikken inn i tunnelen. Det verkar, og det må avgrensast nøyaktig til desse adressene med ein livssyklus som følgjer poolen, fordi å svara for ei adresse du ikkje lenger tenar gjer trafikken til andre til eit svart hol. Nokre upstreams godtek ikkje proxy-svar dei ikkje venta, så dette designet treng også samtykket til leverandøren.

Kva ruta levering krev

Det reinare designet er ei tildeling som upstream faktisk rutar til gatewayen din. Det kan vera eit delegert prefiks eller ei statisk rute for ein mindre blokk, og kravet er det same i båe tilfelle: tabellen til upstream må peika på tenaren din for klientområdet. Då kjem returtrafikken fram til gatewayen, og gatewayen vidaresender han inn i tunnelen.

Ruta levering fjernar spørsmålet om nabooppdaging heilt, og difor er det verd å be leverandøren om det før du byggjer noko smart. Be om ruta skriftleg, og stadfest at neste hopp er adressa upstream faktisk kan nå.

Båe designa treng framleis IPv6-vidaresending slått på i gatewayen og brannmurreglar som tillèt den vidaresende straumen i båe retningar. Levering er ein føresetnad, ikkje ein erstatning, for resten av vegen. Ei fungerande rute med vidaresending slått av gjev nøyaktig same stilla som ei manglande rute, så kontroller båe før du redesignar noko.

To uavhengige ruter å få rett

Poolprefikset og den eigne standardruta til klienten er separate innstillingar, og å blanda dei gjev delvis tilkopling som ser ut som ein øydelagd tunnel. Poolen fortel tenaren kva adresser som skal delast ut. Rutene til klienten avgjer kva mål klienten i det heile sender inn i tunnelen.

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

Prefikset ovanfor er dokumentasjonsplass, og omdirigeringa gjeld berre IPv6, som er nettopp det ein dobbeltstakk-utrulling ofte vil medan IPv6-leveringa framleis blir reparert. Ei IPv4-omdirigering etablerer ikkje IPv6-dekning, og ingen av innstillingane føreset den andre.

Hald kontrolltrafikken som IPv6 er avhengig av, i gang under kva som helst policy du brukar. Packet Too Big-meldingar er det klassiske offeret for ein brannmur som berre tillèt TCP og UDP, og å kasta dei gjev tilkoplingar som blir etablerte og deretter stoggar på større overføringar.

Rutarannonseringar er den tredje bevegelege delen. Viss gatewayen byrjar å annonsera på opplenka, kan det endra kva klientar og naboar trur om prefiks på lenka, noko som stille kan oppheva designet du nettopp dokumenterte.

Dokumenter designet slik at ein gjenoppbygging gjenskapar det

Skriv ned tre objekt kvar for seg: tildelinga til klienten, målruta til klienten og leveringsmetoden til upstream for tildelinga. Ein lesar som har alle tre, kan byggja utrullinga på nytt; ein lesar som berre har poolinnstillinga, vil gjenskapa den opphavlege feilen.

Test deretter returretninga eksplisitt med ei pakke som må koma tilbake utanfrå. openvpn(8)-handboka dekkjer alternativa server-ipv6 og redirect, og rutingsstadfestinga frå leverandøren din dekkjer halvparten handboka ikkje kan.