Rozdělení vašeho /64 nevede IPv6 k VPN klientům

Klient zobrazuje globální adresu IPv6, handshake je dokončen a z internetu se nic nevrací. Nastavení poolu vypadá správně, protože správné je; adresa je platná a tunel ji přenáší. Selhává doručení a doručení závisí na rozhodnutí učiněném výše než VPN server, které žádná konfigurace na straně klienta nemůže ovlivnit.

Mýtus: část vašeho /64 je už dostupná

Příběh je lákavý: server má veřejný /64, rozpulte ho, druhou polovinu dejte poolu VPN a tito klienti jsou najednou na internetu. Rozdělení prefixu skutečně přiděluje adresy bez kolizí. Nemění však to, jak se upstream síť rozhoduje, kam má paket pro jednu z těchto adres jít.

IPv6 nemá výchozí překladovou vrstvu, o kterou by se opřela, takže zpětná cesta musí existovat jako směrování nebo jako doručení na linkové úrovni. Paket adresovaný tunelové adrese klienta dorazí na upstream router a ten router učiní rozhodnutí o předání z vlastní tabulky. Pokud tabulka ukazuje na fyzický spoj, paket tam jde bez ohledu na to, co si váš VPN server myslí.

To je celé selhání: dopředný směr funguje, protože ho váš server odesílá, a zpětný směr umírá jeden hop daleko, protože upstream se nikdy nedozvěděl, že klient existuje.

Co doručení na spoji skutečně vyžaduje

Když upstream považuje celý /64 za součást fyzického spoje, řeší každou cílovou adresu pomocí objevování sousedů. Pošle na tento spoj žádost a očekává, že vlastník adresy odpoví. VPN klient za tunelem na tomto spoji není a nemůže odpovědět, takže žádost zůstane bez odpovědi a paket se zahodí.

Vyčlenění /65 tuto představu nemění. Upstream stále považuje rozsah za součást spoje, protože jediné, co by ho přimělo změnit názor, je trasa nebo proxy, která odpovídá jménem klienta. Ani jedno se neobjeví, protože jste upravili konfiguraci VPN. Právě tato mezera vysvětluje, proč pool může dokonale fungovat mezi vlastními klienty a přesto být z jiného místa nedostupný.

Proxy objevování sousedů je mechanismus, který může oba světy propojit. Brána odpovídá na žádosti pro konkrétní klientské adresy, které vlastní, a předává provoz do tunelu. Funguje to a musí být omezeno přesně na tyto adresy s životním cyklem, který sleduje pool, protože odpovídat za adresu, kterou už neobsluhujete, mění cizí provoz na černou díru. Některé upstreamy nepřijmou proxy odpovědi, které nečekaly, takže tento návrh potřebuje i souhlas poskytovatele.

Co vyžaduje směrované doručení

Čistší návrh je přidělení, které upstream skutečně směruje na vaši bránu. Může to být delegovaný prefix nebo statická trasa pro menší blok a požadavek je v obou případech stejný: tabulka upstreamu musí pro rozsah klientů ukazovat na váš server. Pak zpětný provoz dorazí na bránu a brána ho předá do tunelu.

Směrované doručení zcela odstraňuje otázku objevování sousedů, a proto stojí za to o ně požádat poskytovatele dříve, než postavíte něco chytrého. Požádejte o trasu písemně a potvrďte, že další hop je adresa, kterou upstream skutečně dokáže dosáhnout.

Oba návrhy stále potřebují zapnuté předávání IPv6 na bráně a pravidla firewallu, která povolují předávaný tok v obou směrech. Doručení je předpoklad, ne náhrada, pro zbytek cesty. Fungující trasa s vypnutým předáváním vytváří přesně stejné ticho jako chybějící trasa, takže před jakýmkoli přepracováním zkontrolujte obojí.

Dvě nezávislé trasy, které je třeba nastavit

Prefix poolu a vlastní výchozí trasa klienta jsou samostatná nastavení a jejich záměna vytváří částečnou konektivitu, která vypadá jako rozbitý tunel. Pool říká serveru, které adresy má vydávat. Trasy klienta rozhodují, do kterých cílů klient vůbec posílá provoz do tunelu.

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

Prefix výše je dokumentační prostor a přesměrování se vztahuje pouze na IPv6, což je přesně to, co duální nasazení často chce, dokud se doručení IPv6 ještě opravuje. Přesměrování IPv4 nenavazuje pokrytí IPv6 a žádné z nastavení neimplikuje to druhé.

Udržujte řídicí provoz, na kterém IPv6 závisí, funkční při jakékoli politice, kterou uplatníte. Zprávy Packet Too Big jsou klasickou obětí firewallu, který povoluje jen TCP a UDP, a jejich zahození vytváří spojení, která se navážou a potom se zaseknou při větších přenosech.

Oznámení routeru jsou třetí pohyblivou částí. Pokud brána začne inzerovat na uplinku, může to změnit, co si klienti a sousedé myslí o prefixech na spoji, což může tiše zrušit návrh, který jste právě zdokumentovali.

Zaznamenejte návrh, aby ho přestavba reprodukovala

Zapište tři objekty odděleně: přidělení klienta, cílovou trasu klienta a způsob doručení přidělení ze strany upstreamu. Čtenář, který má všechny tři, může nasazení přestavět; čtenář, který má jen nastavení poolu, reprodukuje původní chybu.

Poté explicitně otestujte zpětný směr, a to paketem, který se musí vrátit zvenčí. Manuál openvpn(8) pokrývá volby server-ipv6 a redirect a potvrzení směrování od vašeho poskytovatele pokrývá tu polovinu, kterou manuál nemůže.