IPv6 IPv4 VPN zerbitzari baten bidez igarotzeak IPv6 irteera behar du oraindik

Tunela altxatzen da, bezeroak IPv6 helbide bat jasotzen du poletik, eta hala ere IPv6 helmuga guztiek denbora-muga jotzen dute. Tunelaren barruan ez dago ezer hautsita: IPv6-k primeran bidaiatzen du IPv4 garraioaren barruan, eta hori ez zen inoiz zati zaila izan. Eman duzun helbidea zerbitzariak ezin duen bete, irteerak ez baitu IPv6 upstreamik hara bidaltzeko. Konponketa irteeran dago, ez bezeroaren profilean.

Sintoma: helbide bat eta biderik ez

Bezeroaren aldeko egiaztapen batek itxura globaleko IPv6 helbide bat erakusten du tunel-gailuan eta hara seinalatzen duen bide bat, eta horregatik hau oker irakurtzen da bezeroaren akats gisa. Trafikoa tunelera sartzen da, zerbitzariak deskapsulatu egiten du, eta gero paketea benetako leku baterako IPv6 bide lehenetsirik ez duen ostalari batera iristen da. Pilaren arabera berehalako iristezintasuna edo isilduko jausketa jasoko duzu, eta bi kasuetan bezeroak suebaki baten berdinak dirudien denbora-muga ikusten du.

Irakurri zerbitzariaren beraren bideratze-taula bezeroa ukitu aurretik, bidearen falta den erdia han bizi baita. IPv4 bide lehenetsi bakarra duen zerbitzari batek jada eman dizu erantzuna.

Jarraitu paketeari deskapsulatu ondoren

Tunelaren barruan paketea IPv6 arrunta da eta bezeroaren helbidea du iturburu. Zerbitzariak garraio-kapsulatzea kentzen du eta orduan IPv6 hurrengo jauzira birbidali behar den IPv6 pakete natiboa dauka. IPv4 bide lehenetsi batek ezin du eraman, eta IPv4-ra itzultzea inork inplementatu ez zuen beste funtzio bat da. Hori da hutsegite osoa, eta ez du zerikusirik VPN entzuleak IPv4 bidez erantzun zuen ala ez.

IPv4 gaineko IPv6 kapsulatzearen mekanika RFC 4213-an deskribatzen da, eta han dagoen xehetasun garrantzitsua zera da: muturrek tunelaren bestaldean benetako IPv6 konektibitatea behar dutela oraindik. Goiburua bilduz ez da upstreamik sortzen.

Bi tunel geruza, bi egiaztapen independente

Egiaztatu geruza bakoitza bereiz, kanpoko tunel lanean ari denak barruko hautsia ezkutatzen baitu. Egiaztatu kanpoko bidea IPv4 ping batekin bezerotik zerbitzarira eta berretsi erabiltzen duzun portua. Gero egiaztatu barruko bidea zerbitzarian, non ip -6 route bide lehenetsi bat edo benetako upstream batetik ikasitako bide zehatz bat erakutsi behar duen, eta ip -6 addr upstreamak onartzen duen iturburu-prefixoa erakutsi behar duen. Hori baino gutxiago interfazearen apaingarria besterik ez da.

Helbide bakar-lokala, edo ezer atzera bideratzen ez duen itxura globaleko prefixo bat, pozik agertuko da interfaze batean eta inora ez da joango. Irisgarritasun publikoa upstreamak ematen du, ez helbidearen formak.

Gauza bera gertatzen da bezeroan: ip -6 route get 2001:4860:4860::8888 tunel-gailua izendatu beharko luke, eta fisikoa izendatzen badu, bezeroak ez du VPN-a erabiltzen IPv6-rako batere.

Iturburu-prefixoa, tamaina eta ICMPv6

Galdetu upstreamari zein iturburu-prefixo onartuko dituen birbidaltzeko, eta erabili horietako bat bezero-poolarentzat. Zerbitzariaren beraren interfazerako /64 bat ematen dizun hornitzaileak ez du nahitaez bigarren /64 edo bloke handiago bat bideratzen zuregana, eta aldea arratsalde bateko arazketa da, laguntza-tiket batek galdera batekin konpontzen duena. Galdetu idatziz eta gorde erantzuna konfigurazioarekin.

Aurreikusi zure pilak benetan erabiltzen duen kapsulatze gehigarrirako tartea, eta mantendu ICMPv6 lanean, Packet Too Big barne. Bigarren goiburu batek erabilgarri den karga txikitzen du, beraz ping txikiei erantzuten dien bide batek fitxategi-transferentzian huts egin dezake, eta ICMPv6 osoa botatzen duen suebaki batek konpon daitekeen tamaina-arazoa zulo beltz bihurtzen du. Probatu transferentzia handi bat zerbitzua iragarri aurretik.

Zer da erabat beste arazo bat

IPv4 soilik den aplikazio batera IPv6 soilik den bezero batetik iristea itzulpena da, ez tunelatzea, eta nahita ezarritako NAT64 antolamendu baten antzeko zerbait behar du. Helmugak ez du tunel-goiburu gehigarri bat ulertuko gehitu duzulako soilik. Trantsizioko zerbitzu historikoek arreta bera merezi dute: RFC 7526-k 6to4 anycast errele-eredua indargabetu zuen, beraz haren inguruan idatzitako gida batek mantendutako errele publikorik ez duen zerbait deskribatzen du.

Zerbitzariak erabilgarria den IPv6 upstreamik ez badu, aukerak hauek dira: onartutako upstream bat, beste irteera bat edo IPv6 tunelaz kanpo geratzen dela dioen erabaki dokumentatu bat. Onartezina da bezeroei IPv6 zerbitzua badagoela esatea, eta aldi berean beren IPv6 konexio arruntak VPN-a isilka saihesten du.