IPv6 duerch en IPv4-VPN-Server brauch nach ëmmer en IPv6-Ausgang

Den Tunnel geet erop, de Client kritt eng IPv6-Adress aus dem Pool, an trotzdeem lafe all IPv6-Zil an en Timeout. Am Tunnel ass näischt futti: IPv6 fiert ganz gutt am IPv4-Transport, an dat war ni de schwéieren Deel. D’Adress, déi s du verdeelt hues, ass en Verspriechen, dat de Server net halen kann, well den Ausgang keen IPv6-Upstream huet, an deen en se schécke kéint. D’Reparatur gehéiert an den Ausgang, net an de Clientprofil.

D’Symptom: eng Adress an keen Wee

Eng Kontroll op der Clientssäit weist eng IPv6-Adress, déi global ausgesäit, um Tunnelapparat an eng Route, déi dohinner weist, an dofir gëtt dat falsch als Clientfehler gelies. Den Trafic geet an den Tunnel, de Server dekapsuléiert en, an duerno landt de Pak op engem Host, deem seng Routingtabell keng IPv6-Standardroute op eng richteg Plaz huet. Ofhängeg vum Stack kritt s du eng direkt Onereechbarkeet oder e rouegt Verwerfen, a béide Fäll gesäit de Client en Timeout, deen identesch mat enger Firewall ausgesäit.

Lies dem Server seng eege Routingtabell, ier s de Client ufäss, well do wunnt déi fehlend Halschecht vum Wee. E Server mat enger eenzeger IPv4-Standardroute huet dir d’Äntwert schonn ginn.

Folg dem Pak no der Dekapsulatioun

Am Tunnel ass de Pak gewéinlech IPv6, an d’Adress vum Client ass seng Quell. De Server zitt d’Transportkapselung of an hält dann e native IPv6-Pak, deen un den nächsten IPv6-Hop weidergeleet muss ginn. Eng IPv4-Standardroute kann en net droen, an en op IPv4 ze iwwersetzen ass eng aner Funktioun, déi keen agesat huet. Dat ass de ganze Fehler, an en huet näischt domat ze dinn, ob de VPN-Listener iwwer IPv4 geäntwert huet.

D’Mechanik vun der IPv6-iwwer-IPv4-Kapselung ass an RFC 4213 beschriwwen, an de wichtegen Detail do ass, datt d’Endpunkte weiderhi richteg IPv6-Konnektivitéit op der anerer Säit vum Tunnel brauchen. En Header anzepaken zaubert keen Upstream.

Zwee Tunnelschichten, zwee onofhängeg Kontrollen

Verifizéier all Schicht eenzel, well en funktionéierenden äusseren Tunnel en futti banneschten verstoppt. Kontrolléier den äusseren Wee mat engem IPv4-Ping vum Client zum Server a bestäteg de Port, deen s de benotz. Kontrolléier duerno de banneschten Wee um Server, wou ip -6 route eng Standardroute oder eng konkret Route muss weisen, déi vun engem echten Upstream geléiert gouf, an ip -6 addr e Quellpräfix muss weisen, deen den Upstream akzeptéiert. Alles manner ass Dekoratioun um Interface.

Eng eenzegaarteg-lokal Adress, oder e Präfix deen global ausgesäit an op deen näischt zréckrout, erschéngt frou um Interface a geet néierens hin. D’ëffentlech Erreechbarkeet gëtt vum Upstream ginn, net vun der Form vun der Adress.

Datselwecht gëllt beim Client: ip -6 route get 2001:4860:4860::8888 soll den Tunnelapparat nennen, an wann en de physeschen nennt, benotzt de Client de VPN iwwerhaapt net fir IPv6.

Quellpräfix, Gréisst an ICMPv6

Fro den Upstream, wéi eng Quellpräfixen en fir d’Weiderleede akzeptéiert, a benotz een dovun fir de Clientpool. En Ubieder, deen dir en /64 fir dem Server säin eegenen Interface gëtt, rout net onbedéngt en zweeten /64 oder e gréissere Block op dech, an den Ënnerscheed ass en Nomëtteg Debugging, deen en Supportticket mat enger Fro reegelt. Fro et schrëftlech a behalt d’Äntwert bei der Konfiguratioun.

Rech mat der zousätzlecher Kapselung, déi däi Stack tatsächlech benotzt, a haalt ICMPv6 am Gaang, och Packet Too Big. En zweete Header verklengert d’Nutzlaascht, also kann e Wee, deen op kleng Pinge äntwert, bei enger Dateiübertragung nach ëmmer feelen, an eng Firewall, déi all ICMPv6 verwërft, mécht aus engem reparabele Gréissteproblem e schwaarzt Lach. Test eng grouss Iwwerdroung, ier s de Service ukiinnegst.

Wat en ganz anert Problem ass

Eng Uwendung ereechen, déi just IPv4 ass, vun engem Client, deen just IPv6 ass, ass Iwwersetzung, net Tunneling, an brauch eppes wéi eng bewosst agesat NAT64-Léisung. D’Zil versteet keen zousätzlechen Tunnelheader just well s de een derbäi gesat hues. Historesch Iwwergangsservicer verdéngen déi nämmlecht Suergfalt: RFC 7526 huet den 6to4-Anycast-Relaymodell ofgeschaf, also beschreift eng Uleedung, déi ronderëm geschriwwe gouf, eppes, wat keen ënnerhalene ëffentleche Relay méi huet.

Wann de Server keen benutzbaren IPv6-Upstream huet, sinn d’Méiglechkeeten en ënnerstëtzten Upstream, en aneren Ausgang oder eng dokumentéiert Entscheedung, datt IPv6 baussent dem Tunnel bleift. Net akzeptabel ass, de Cliente ze soen, et géif en IPv6-Service ginn, während hir gewéinlech IPv6-Verbindung de VPN roueg ëmgeet.