IPv6 IPv4 VPN-serveri kaudu vajab ikkagi IPv6 väljapääsu

Tunnel tõuseb, klient saab poolist IPv6-aadressi ja ikkagi läheb iga IPv6-sihtkoht aeguma. Tunnelis ei ole midagi katki: IPv6 sõidab IPv4-transpordi sees täiesti hästi ja see ei olnud kunagi raske osa. Aadress, mille sa välja andsid, on lubadus, mida server ei suuda täita, sest väljapääsul ei ole IPv6 upstreami, kuhu seda saata. Parandus kuulub väljapääsu juurde, mitte kliendi profiili.

Sümptom: aadress ja mitte ühtegi teed

Kliendipoolne kontroll näitab tunnelseadmel globaalsena näivat IPv6-aadressi ja sinna osutavat marsruuti, mistõttu loetakse seda ekslikult kliendi veaks. Liiklus siseneb tunnelisse, server dekapsuleerib selle ja siis maandub pakett hostil, mille marsruutimistabelis ei ole IPv6 vaikemarsruuti ühessegi päris kohta. Sõltuvalt virnast saad kas kohese kättesaamatuse või vaikse kõrvaleheitmise ja mõlemal juhul näeb klient ajalõppu, mis näeb välja täpselt nagu tulemüür.

Loe serveri enda marsruutimistabelit enne, kui klienti puutud, sest just seal elab tee puuduv pool. Server, millel on üks IPv4 vaikemarsruut, on sulle juba vastuse andnud.

Jälgi paketti pärast dekapsuleerimist

Tunneli sees on pakett tavaline IPv6 ja selle allikas on kliendi aadress. Server eemaldab transpordi kapselduse ja hoiab siis natiivset IPv6-paketti, mis tuleb edasi saata järgmisele IPv6-hüppele. IPv4 vaikemarsruut ei suuda seda kanda ja selle IPv4-ks tõlkimine on teine funktsioon, mida keegi ei juurutanud. See ongi kogu rike ja sellel ei ole mingit pistmist sellega, kas VPN-kuulaja vastas IPv4 kaudu.

IPv6 üle IPv4 kapseldamise mehaanikat kirjeldatakse RFC 4213-s ja sealne oluline detail on see, et otspunktid vajavad endiselt tõelist IPv6-ühendust teisel pool tunnelit. Päise mähkimine ei tekita upstreami eikusagilt.

Kaks tunnelikihti, kaks sõltumatut kontrolli

Kontrolli iga kihti eraldi, sest töötav välimine tunnel varjab katkist sisemist. Kontrolli välimist teed IPv4 pingiga kliendist serverini ja kinnita port, mida kasutad. Seejärel kontrolli sisemist teed serveris, kus ip -6 route peab näitama vaikemarsruuti või konkreetset marsruuti, mis on õpitud tõeliselt upstreamilt, ja ip -6 addr peab näitama lähteprefiksit, mille upstream vastu võtab. Kõik vähem on liidese peal lihtsalt ehteks.

Unikaalne-lokaalne aadress või globaalsena näiv prefiks, kuhu miski tagasi ei marsruudi, ilmub rõõmsalt liidesele ja ei lähe kuhugi. Avaliku kättesaadavuse annab upstream, mitte aadressi kuju.

Sama kehtib kliendi puhul: ip -6 route get 2001:4860:4860::8888 peaks nimetama tunnelseadet ja kui see nimetab füüsilist, ei kasuta klient VPN-i IPv6 jaoks üldse.

Lähteprefiks, suurus ja ICMPv6

Küsi upstreamilt, milliseid lähteprefikseid see edastamiseks aktsepteerib, ja kasuta üht neist kliendipooli jaoks. Teenusepakkuja, kes annab sulle serveri enda liidese jaoks /64, ei marsruudi sulle tingimata teist /64 ega suuremat plokki, ja vahe on üks pärastlõuna silumist, mille tugipilet lahendab ühe küsimusega. Küsi kirjalikult ja hoia vastust konfiguratsiooni juures.

Arvesta lisakapseldusega, mida sinu virn tegelikult kasutab, ja hoia ICMPv6 töös, sealhulgas Packet Too Big. Teine päis kitsendab kasutatavat kandevõimet, nii et väikestele pingidele vastav tee võib failiedastusel ikkagi ebaõnnestuda, ja tulemüür, mis viskab kogu ICMPv6 kõrvale, muudab parandatava suuruseprobleemi mustaks auguks. Testi enne teenuse kuulutamist üht suurt edastust.

Mis on hoopis teine probleem

Jõudmine ainult IPv4 rakenduseni ainult IPv6 kliendist on tõlkimine, mitte tunnelimine, ja vajab midagi taolist nagu teadlikult juurutatud NAT64 lahendus. Sihtkoht ei hakka lisatunnelipäist mõistma ainult sellepärast, et sa selle lisasid. Ajaloolised üleminekuteenused väärivad sama hoolt: RFC 7526 tunnistas 6to4 anycast-relay mudeli kehtetuks, seega selle ümber kirjutatud juhend kirjeldab midagi, millel ei ole enam hooldatud avalikku releed.

Kui serveril ei ole kasutatavat IPv6 upstreami, on valikud toetatud upstream, teine väljapääs või dokumenteeritud otsus, et IPv6 jääb tunnelist väljapoole. Vastuvõetamatu on öelda klientidele, et IPv6-teenus on olemas, samal ajal kui nende tavaline IPv6-ühendus möödub VPN-ist vaikselt.