IPv6 cez IPv4 VPN server stále potrebuje skutočný IPv6 výstup

Tunel sa zdvihne, klient dostane IPv6 adresu z poolu, a napriek tomu každý cieľ IPv6 vyprší. V tuneli nič nie je pokazené: IPv6 sa vezie úplne dobre vnútri IPv4 transportu a to nikdy nebola tá ťažká časť. Adresa, ktorú si pridelil, je sľub, ktorý server nedokáže splniť, pretože výstup nemá žiadny IPv6 upstream, kam by ju poslal. Oprava patrí na výstup, nie do profilu klienta.

Príznak: adresa a žiadna cesta

Kontrola na strane klienta ukáže na tunelovom zariadení IPv6 adresu, ktorá vyzerá globálne, a trasu, ktorá do nej ukazuje, a preto sa to mylne číta ako chyba klienta. Premávka vstúpi do tunela, server ju dekapsuluje a potom paket pristane na hostiteľovi, ktorého smerovacia tabuľka nemá predvolenú trasu IPv6 nikam do skutočného sveta. Podľa zásobníka dostaneš okamžitú nedostupnosť alebo tiché zahodenie, a v oboch prípadoch klient vidí časový limit, ktorý vyzerá rovnako ako firewall.

Prečítaj si vlastnú smerovaciu tabuľku servera, skôr než sa dotkneš klienta, pretože práve tam žije chýbajúca polovica cesty. Server s jednou predvolenou trasou IPv4 ti už odpoveď povedal.

Sleduj paket po dekapsulácii

Vnútri tunela je paket obyčajný IPv6 a jeho zdrojom je adresa klienta. Server stiahne transportné zapuzdrenie a potom drží natívny paket IPv6, ktorý sa musí odovzdať ďalšiemu hopu IPv6. Predvolená trasa IPv4 ho nemôže uniesť a prevod do IPv4 je iná funkcia, ktorú nikto nenasadil. To je celá porucha a nemá nič spoločné s tým, či VPN listener odpovedal cez IPv4.

Mechanika zapuzdrenia IPv6 do IPv4 je opísaná v RFC 4213 a dôležitý detail tam je, že koncové body stále potrebujú skutočnú konektivitu IPv6 na druhej strane tunela. Obalenie hlavičky nevytvorí upstream z ničoho.

Dve vrstvy tunela, dve nezávislé kontroly

Over každú vrstvu zvlášť, pretože fungujúci vonkajší tunel skrýva pokazený vnútorný. Skontroluj vonkajšiu cestu pingom IPv4 z klienta na server a potvrď port, ktorý používaš. Potom skontroluj vnútornú cestu na serveri, kde ip -6 route musí ukázať predvolenú alebo konkrétnu trasu naučenú od skutočného upstreamu, a ip -6 addr musí ukázať zdrojový prefix, ktorý upstream prijíma. Čokoľvek menej je len ozdoba na rozhraní.

Jedinečná lokálna adresa alebo prefix, ktorý vyzerá globálne a nič k nemu nesmeruje späť, sa pokojne objaví na rozhraní a nikam nepôjde. Verejnú dosiahnuteľnosť dáva upstream, nie tvar adresy.

To isté platí u klienta: ip -6 route get 2001:4860:4860::8888 malo by uviesť tunelové zariadenie, a ak uvádza to fyzické, klient VPN pre IPv6 vôbec nepoužíva.

Zdrojový prefix, veľkosť a ICMPv6

Opýtaj sa upstreamu, ktoré zdrojové prefixy prijme na preposielanie, a jeden z nich použi pre pool klientov. Poskytovateľ, ktorý ti dá /64 pre vlastné rozhranie servera, ti nemusí smerovať druhý /64 ani väčší blok, a rozdiel je jedno popoludnie ladenia, ktoré support ticket vyrieši jednou otázkou. Pýtaj sa písomne a odpoveď si nechaj pri konfigurácii.

Naplánuj rezervu na dodatočné zapuzdrenie, ktoré tvoj zásobník skutočne používa, a udržuj ICMPv6 funkčný, vrátane Packet Too Big. Druhá hlavička zmenšuje použiteľný payload, takže cesta, ktorá odpovedá na malé pingy, môže napriek tomu zlyhať pri prenose súboru, a firewall, ktorý zahadzuje všetok ICMPv6, mení opraviteľný problém s veľkosťou na čiernu dieru. Pred ohlásením služby otestuj jeden veľký prenos.

Čo je úplne iný problém

Dostať sa z klienta, ktorý vie len IPv6, k aplikácii, ktorá vie len IPv4, je preklad, nie tunelovanie, a potrebuje niečo ako zámerne nasadené riešenie NAT64. Cieľ neporozumie ďalšej tunelovej hlavičke len preto, že si ju pridal. Historické prechodové služby si zaslúžia rovnakú starostlivosť: RFC 7526 zrušil model anycast relay 6to4, takže návod napísaný okolo neho opisuje niečo, čo už nemá udržiavaný verejný relay.

Ak server nemá použiteľný IPv6 upstream, možnosti sú podporovaný upstream, iný výstup alebo dokumentované rozhodnutie, že IPv6 zostane mimo tunela. Neprijateľné je tvrdiť klientom, že služba IPv6 existuje, zatiaľ čo ich bežné pripojenie IPv6 potichu obchádza VPN.