Om jou /64 te verdeel roeteer nie IPv6 na VPN-kliënte nie

Die kliënt wys ’n globale IPv6-adres, die handskud is voltooi, en niks kom terug van die internet af nie. Die poelinstelling lyk korrek omdat dit korrek is; die adres is geldig en die tonnel dra dit. Wat faal, is aflewering, en aflewering hang af van ’n besluit stroomop van die VPN-bediener wat geen kliëntekant-konfigurasie kan beïnvloed nie.

Die mite: ’n stuk van jou /64 is reeds bereikbaar

Die verhaal is aanloklik: die bediener het ’n publieke /64, sny dit in die helfte, gee die ander helfte aan die VPN-poel, en daardie kliënte is nou op die internet. Om die voorvoegsel te verdeel ken wel adresse sonder botsings toe. Dit verander nie hoe die upstream-netwerk besluit waarheen ’n pakket vir een van daardie adresse moet gaan nie.

IPv6 het geen verstek-vertaallaag om op terug te val nie, so die terugpad moet as roetering of as skakelvlak-aflewering bestaan. ’n Pakket wat aan ’n kliënt se tonneladres geadresseer is, kom by die upstream-roeteerder aan, en daardie roeteerder neem ’n aanstuur-besluit uit sy eie tabel. As die tabel na die fisiese skakel wys, gaan die pakket daarheen ongeag wat jou VPN-bediener glo.

Dit is die hele faling: die voorwaartse rigting werk omdat jou bediener dit stuur, en die terugwaartse rigting sterf een hop weg omdat die upstream nooit geleer het die kliënt bestaan nie.

Wat on-link-aflewering werklik vereis

Wanneer die upstream die hele /64 as op die fisiese skakel beskou, los dit elke bestemmingsadres met buurontdekking op. Dit stuur ’n versoek op daardie skakel en verwag dat die eienaar van die adres antwoord. ’n VPN-kliënt agter ’n tonnel is nie op daardie skakel nie en kan nie antwoord nie, so die versoek bly onbeantwoord en die pakket word laat val.

Om ’n /65 uit te kerf verander nie daardie verwagting nie. Die upstream behandel die reeks steeds as on-link, want die enigste ding wat sy mening sou verander, is ’n roete of ’n proxy wat namens die kliënt antwoord. Nie een verskyn omdat jy ’n VPN-konfigurasie geredigeer het nie. Daardie gaping is waarom ’n poel volmaak tussen sy eie kliënte kan werk en tog van elders onbereikbaar bly.

Volmag-buurontdekking is die meganisme wat die twee wêrelde kan oorbrug. Die poort beantwoord versoeke vir die spesifieke kliëntadresse wat dit besit en stuur die verkeer in die tonnel in. Dit werk, en dit moet presies op daardie adresse beperk word met ’n lewensiklus wat die poel volg, want om te antwoord vir ’n adres wat jy nie meer bedien nie, maak iemand anders se verkeer dood. Sommige upstreams sal nie volmag-antwoorde aanvaar wat hulle nie verwag het nie, so hierdie ontwerp het ook die verskaffer se instemming nodig.

Wat geroteerde aflewering vereis

Die skoner ontwerp is ’n toewysing wat die upstream werklik na jou poort roeteer. Dit kan ’n gedelegeerde voorvoegsel wees of ’n statiese roete vir ’n kleiner blok, en die vereiste is in beide gevalle dieselfde: die upstream se tabel moet na jou bediener wys vir die kliëntreeks. Dan kom terugkeerverkeer by die poort aan en die poort stuur dit in die tonnel in.

Geroteerde aflewering verwyder die buurontdekkingsvraag heeltemal, en daarom is dit die moeite werd om die verskaffer daarvoor te vra voordat jy iets slim bou. Vra die roete skriftelik, en bevestig dat die volgende hop die adres is wat die upstream werklik kan bereik.

Beide ontwerpe het steeds IPv6-aansturing op die poort nodig, asook firewall-reëls wat die aangestuurde vloei in beide rigtings toelaat. Aflewering is ’n voorvereiste, nie ’n plaasvervanger nie, vir die res van die pad. ’n Werkende roete met aansturing afgeskakel lewer presies dieselfde stilte as ’n ontbrekende roete, so kontroleer albei voordat jy enigiets herontwerp.

Twee onafhanklike roetes om reg te kry

Die poelvoorvoegsel en die kliënt se eie verstekroete is aparte instellings, en om hulle te verwar lewer gedeeltelike verbinding wat soos ’n stukkende tonnel lyk. Die poel sê vir die bediener watter adresse om uit te deel. Die kliënt se roetes bepaal na watter bestemmings die kliënt hoegenaamd in die tonnel stuur.

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

Die voorvoegsel hierbo is dokumentasieruimte, en die herleiding geld slegs vir IPv6, wat presies is wat ’n dubbelstapel-ontplooiing dikwels wil terwyl IPv6-aflewering nog reggemaak word. ’n IPv4-herleiding vestig nie IPv6-dekking nie, en nie een instelling veronderstel die ander nie.

Hou die beheerverkeer waarvan IPv6 afhanklik is werkend onder watter beleid jy ook al toepas. Packet Too Big-boodskappe is die klassieke slagoffer van ’n firewall wat net TCP en UDP toelaat, en om hulle te laat val lewer verbindings wat vestig en dan by groter oordragte vasval.

Roeteerder-advertensies is die derde bewegende deel. As die poort op die uplink begin adverteer, kan dit verander wat kliënte en bure oor on-link-voorvoegsels glo, wat die ontwerp wat jy pas gedokumenteer het, stilweg kan ongedaan maak.

Dokumenteer die ontwerp sodat ’n herbou dit reproduseer

Skryf drie objekte afsonderlik neer: die kliëntetoewysing, die kliënt se bestemmingsroete, en die upstream se afleweringsmetode vir die toewysing. ’n Leser met al drie kan die ontplooiing herbou; ’n leser met net die poelinstelling sal die oorspronklike fout reproduseer.

Toets dan die terugwaartse rigting eksplisiet, met ’n pakket wat van buite moet terugkom. Die openvpn(8)-handleiding dek die server-ipv6- en herleidingsopsies, en jou verskaffer se roeteringsbevestiging dek die helfte wat die handleiding nie kan nie.