IPv6 přes IPv4 VPN server stále potřebuje IPv6 výstup

Tunel se zvedne, klient dostane IPv6 adresu z poolu, a přesto každý cíl IPv6 vyprší. V tunelu není nic rozbité: IPv6 se veze uvnitř IPv4 transportu úplně v pořádku a to nikdy nebyla ta těžká část. Adresa, kterou jsi přidělil, je slib, který server nemůže splnit, protože výstup nemá žádný IPv6 upstream, kam by ji poslal. Oprava patří na výstup, ne do profilu klienta.

Příznak: adresa a žádná cesta

Kontrola na straně klienta ukáže na tunelovém zařízení IPv6 adresu, která vypadá globálně, a trasu, která do ní ukazuje, a proto se to mylně čte jako chyba klienta. Provoz vstoupí do tunelu, server ho dekapsuluje a pak paket přistane na hostiteli, jehož směrovací tabulka nemá výchozí trasu IPv6 nikam do skutečného světa. Podle zásobníku dostaneš okamžitou nedostupnost, nebo tiché zahození, a v obou případech klient vidí timeout, který vypadá stejně jako firewall.

Přečti si vlastní směrovací tabulku serveru, než se dotkneš klienta, protože právě tam žije chybějící polovina cesty. Server s jednou výchozí trasou IPv4 ti už odpověď řekl.

Sleduj paket po dekapsulaci

Uvnitř tunelu je paket obyčejný IPv6 a jeho zdrojem je adresa klienta. Server strhne transportní zapouzdření a pak drží nativní paket IPv6, který se musí předat dalšímu hopu IPv6. Výchozí trasa IPv4 ho unést nemůže a převod do IPv4 je jiná funkce, kterou nikdo nenasadil. To je celá porucha a nemá nic společného s tím, zda VPN listener odpověděl přes IPv4.

Mechanika zapouzdření IPv6 do IPv4 je popsána v RFC 4213 a důležitý detail tam je, že koncové body stále potřebují skutečnou konektivitu IPv6 na druhé straně tunelu. Obalení hlavičky nevytvoří upstream z ničeho.

Dvě vrstvy tunelu, dvě nezávislé kontroly

Ověř každou vrstvu zvlášť, protože fungující vnější tunel skrývá rozbitý vnitřní. Zkontroluj vnější cestu pingem IPv4 z klienta na server a potvrď port, který používáš. Pak zkontroluj vnitřní cestu na serveru, kde ip -6 route musí ukázat výchozí nebo konkrétní trasu naučenou od skutečného upstreamu, a ip -6 addr musí ukázat zdrojový prefix, který upstream přijímá. Cokoli méně je jen ozdoba na rozhraní.

Unikátní lokální adresa nebo prefix, který vypadá globálně, ale nic k němu nevede zpátky, se na rozhraní klidně objeví a nikam nepůjde. Veřejnou dosažitelnost dává upstream, ne tvar adresy.

Totéž platí u klienta: ip -6 route get 2001:4860:4860::8888 má uvést tunelové zařízení, a pokud uvádí to fyzické, klient VPN pro IPv6 vůbec nepoužívá.

Zdrojový prefix, velikost a ICMPv6

Zeptej se upstreamu, které zdrojové prefixy přijme pro předávání, a jeden z nich použij pro pool klientů. Poskytovatel, který ti dá /64 pro vlastní rozhraní serveru, ti nemusí směrovat druhý /64 ani větší blok, a rozdíl je jedno odpoledne ladění, které support tiket vyřeší jednou otázkou. Ptej se písemně a odpověď si nech u konfigurace.

Naplánuj rezervu na dodatečné zapouzdření, které tvůj zásobník skutečně používá, a udržuj ICMPv6 funkční, včetně Packet Too Big. Druhá hlavička zmenšuje použitelný payload, takže cesta, která odpovídá na malé pingy, může přesto selhat při přenosu souboru, a firewall, který zahazuje všechen ICMPv6, mění opravitelný problém s velikostí v černou díru. Před ohlášením služby otestuj jeden velký přenos.

Co je úplně jiný problém

Dostat se z klienta, který umí jen IPv6, k aplikaci, která umí jen IPv4, je překlad, ne tunelování, a potřebuje něco jako záměrně nasazené řešení NAT64. Cíl neporozumí další tunelové hlavičce jen proto, že jsi ji přidal. Historické přechodové služby si zaslouží stejnou péči: RFC 7526 zrušil model anycast relay 6to4, takže návod napsaný kolem něj popisuje něco, co už nemá udržovaný veřejný relay.

Pokud server nemá použitelný IPv6 upstream, možnosti jsou podporovaný upstream, jiný výstup nebo dokumentované rozhodnutí, že IPv6 zůstane mimo tunel. Nepřijatelné je tvrdit klientům, že služba IPv6 existuje, zatímco jejich běžné IPv6 připojení tiše obchází VPN.