Rozdelenie vášho /64 nesmeruje IPv6 ku klientom VPN

Klient zobrazuje globálnu adresu IPv6, handshake sa dokončil a z internetu sa nič nevracia. Nastavenie fondu vyzerá správne, pretože správne je; adresa je platná a tunel ju prenáša. Zlyháva doručenie a doručenie závisí od rozhodnutia prijatého vyššie ako server VPN, ktoré žiadna konfigurácia na strane klienta nemôže ovplyvniť.

Mýtus: časť vášho /64 je už dostupná

Príbeh je lákavý: server má verejný /64, rozdeľte ho na dve polovice, druhú polovicu dajte fondu VPN a tí klienti sú teraz na internete. Rozdelenie prefixu skutočne prideľuje adresy bez kolízií. Nemení však to, ako sa sieť upstream rozhoduje, kam má paket pre jednu z týchto adries ísť.

IPv6 nemá predvolenú prekladovú vrstvu, o ktorú by sa oprel, preto spätná cesta musí existovať ako smerovanie alebo ako doručenie na úrovni spoja. Paket adresovaný tunelovej adrese klienta dorazí na upstream router a ten router urobí rozhodnutie o preposlaní z vlastnej tabuľky. Ak tabuľka ukazuje na fyzický spoj, paket tam ide bez ohľadu na to, čo si myslí váš server VPN.

To je celé zlyhanie: smer dopredu funguje, pretože ho odosiela váš server, a spätný smer umiera o jeden skok ďalej, pretože upstream sa nikdy nedozvedel, že klient existuje.

Čo doručenie na spoji skutočne vyžaduje

Keď upstream považuje celý /64 za nachádzajúci sa na fyzickom spoji, rieši každú cieľovú adresu objavovaním susedov. Pošle požiadavku na tento spoj a očakáva, že vlastník adresy odpovie. Klient VPN za tunelom na tomto spoji nie je a nemôže odpovedať, takže požiadavka zostane bez odpovede a paket sa zahodí.

Vyrezať /65 túto predstavu nemení. Upstream stále považuje rozsah za nachádzajúci sa na spoji, pretože jediné, čo by ho prinútilo zmeniť názor, je trasa alebo proxy, ktorá odpovedá v mene klienta. Ani jedno sa neobjaví, pretože ste upravili konfiguráciu VPN. Práve táto medzera vysvetľuje, prečo fond môže dokonale fungovať medzi svojimi vlastnými klientmi a napriek tomu byť nedostupný z akéhokoľvek iného miesta.

Objavovanie susedov cez proxy je mechanizmus, ktorý môže spojiť oba svety. Brána odpovedá na požiadavky pre konkrétne klientske adresy, ktoré vlastní, a preposiela prevádzku do tunela. Funguje to a musí byť obmedzené presne na tieto adresy so životným cyklom, ktorý sleduje fond, pretože odpovedať za adresu, ktorú už neobsluhujete, mení cudziu prevádzku na čiernu dieru. Niektoré upstreamy neprijmú proxy odpovede, ktoré nečakali, preto tento návrh potrebuje aj súhlas poskytovateľa.

Čo vyžaduje smerované doručenie

Čistejší návrh je pridelenie, ktoré upstream skutočne smeruje na vašu bránu. Môže to byť delegovaný prefix alebo statická trasa pre menší blok, a požiadavka je v oboch prípadoch rovnaká: tabuľka upstreamu musí pre rozsah klientov ukazovať na váš server. Potom spätná prevádzka dorazí na bránu a brána ju prepošle do tunela.

Smerované doručenie úplne odstraňuje otázku objavovania susedov, a preto sa ho oplatí požiadať poskytovateľa skôr, než postavíte niečo dômyselné. Požiadajte o trasu písomne a potvrďte, že ďalší skok je adresa, ktorú upstream skutočne dokáže dosiahnuť.

Oba návrhy stále potrebujú zapnuté preposielanie IPv6 na bráne a pravidlá firewallu, ktoré povoľujú preposielaný tok v oboch smeroch. Doručenie je predpoklad, nie náhrada, pre zvyšok cesty. Fungujúca trasa s vypnutým preposielaním vytvára presne to isté ticho ako chýbajúca trasa, preto pred akýmkoľvek prepracovaním skontrolujte obe.

Dve nezávislé trasy, ktoré treba nastaviť správne

Prefix fondu a vlastná predvolená trasa klienta sú samostatné nastavenia a ich zámena vytvára čiastočnú konektivitu, ktorá vyzerá ako pokazený tunel. Fond hovorí serveru, ktoré adresy prideľovať. Trasy klienta rozhodujú, do ktorých cieľov klient vôbec posiela prevádzku do tunela.

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

Prefix vyššie je dokumentačný priestor a presmerovanie sa vzťahuje len na IPv6, čo je presne to, čo dvojité nasadenie často chce, kým sa doručenie IPv6 ešte opravuje. Presmerovanie IPv4 neustanovuje pokrytie IPv6 a žiadne z nastavení neimplikuje to druhé.

Udržujte riadiacu prevádzku, od ktorej IPv6 závisí, funkčnú pri akejkoľvek politike, ktorú uplatníte. Správy Packet Too Big sú klasickou obeťou firewallu, ktorý povoľuje iba TCP a UDP, a ich zahodenie vytvára spojenia, ktoré sa nadviažu a potom sa zaseknú pri väčších prenosoch.

Oznámenia routera sú tretia pohyblivá časť. Ak brána začne inzerovať na uplinku, môže to zmeniť, čo si klienti a susedia myslia o prefixoch na spoji, čo môže potichu zrušiť návrh, ktorý ste práve zdokumentovali.

Zaznamenajte návrh, aby ho prestavba reprodukovala

Zapíšte tri objekty oddelene: pridelenie klienta, cieľovú trasu klienta a spôsob doručenia pridelenia zo strany upstreamu. Čitateľ, ktorý má všetky tri, môže nasadenie prestavať; čitateľ, ktorý má iba nastavenie fondu, reprodukuje pôvodnú chybu.

Potom explicitne otestujte spätný smer paketom, ktorý sa musí vrátiť zvonku. Manuál openvpn(8) pokrýva voľby server-ipv6 a redirect a potvrdenie smerovania od vášho poskytovateľa pokrýva tú polovicu, ktorú manuál nemôže.