DS-Lite blokira dohodno gostovanje IPv4, ne odhodni VPN
Stanje prevajanja sledi strani, ki začne povezavo. Sledite odhodni zahtevi skozi B4 in AFTR, nato poglejte, zakaj gostovanje ne uspe.
DS-Lite je način, kako stranki dati povezljivost IPv4 prek dostopovnega omrežja, ki prenaša samo IPv6. Domači usmerjevalnik nima lastnega namenskega javnega naslova IPv4, in to eno dejstvo prepriča ljudi, da VPN IPv4 ne more delovati s te povezave. V odhodni smeri običajno deluje dobro. Povezavo prevede ponudnik, oddaljena stran pa vidi običajnega odjemalca IPv4. Kar se zlomi, je nasprotna smer: gostovanje nečesa, kar pričakuje nezahtevan dohodni IPv4. Razlika je v tem, katera stran začne pogovor.
Katera stran začne povezavo
Odjemalec, ki začne povezavo, sproti ustvarja stanje prevajanja. Prevajalnik ponudnika vidi prvi paket, dodeli preslikavo in ga posreduje naprej. Povratni promet se ujema s to preslikavo, ker preslikava že obstaja.
Strežnik, ki čaka na povezave, nima takega stanja za ustvarjanje. Nekdo od zunaj mora doseči naslov in vrata, za katera se ponudnik ni strinjal s preslikavo, in to je povsem druga zahteva.
Sledite odhodni zahtevi
Arhitektura v RFC 6333 imenuje oba konca. Element na strani odjemalca je B4, ki zapakira IPv4 v IPv6. Element na strani ponudnika je AFTR, ki izvede prevajanje naslova in posreduje paket kot IPv4.
Client's IPv4 VPN packet
→ Customer B4
→ IPv4 carried over the provider's IPv6 network
→ AFTR address translation
→ IPv4 VPN server
Strežnik VPN prejme običajno povezavo IPv4 s prevedenega naslova ponudnika. Ne potrebuje načina DS-Lite, posebnih vrat ali vedenja, da je dostopovno omrežje odjemalca samo IPv6. To je del, ki ga ljudje spregledajo: oddaljena stran tega ne more prepoznati.
Konfiguracija odjemalca je prav tako običajna. Potrebuje delujočo pot IPv4 do strežnika, ki jo zagotavljata B4 in AFTR, in potrebuje, da se ime gostitelja strežnika razreši v naslov IPv4.
Zakaj je dohodno gostovanje primer, ki ne uspe
Izvajanje strežnika VPN IPv4 doma je zasnova, ki trči ob skupno naslavljanje ponudnika. Prevajalnik ponudnika ima v lasti javni naslov in preslikovalno tabelo, in nima razloga ustvariti trajne dohodne preslikave za enega naročnika.
Pravilo posredovanja vrat na domačem usmerjevalniku ne more konfigurirati AFTR. Pravilo je na lokalni napravi resnično in pravilno in višje ne spremeni ničesar, zato je simptom videti kot težava požarnega zidu, ki ne izgine.
Tu se tudi prevajanje na ravni operaterja razlikuje od enega javnega naslova: tudi pravilno lokalno posredovanje lahko pristane na naslovu, ki si ga deli veliko naročnikov.
Diagnosticirajte, preden spremenite načrt dostopa
Najprej potrdite zagotovljeni način. Izvorni dvojni sklad, DS-Lite in omrežje samo z IPv6, ki uporablja drug mehanizem prevajanja, so tri različne ureditve, in tržna imena ponudnika se ne ujemajo vedno s tehničnim.
Nato določite štiri opažanja za odhodno napako. Ali odjemalec razreši ime gostitelja VPN v cilj IPv4? Ali deluje preprosta povezljivost IPv4, namesto zahteve brskalnika, ki je morda tiho uporabila IPv6? Kateri transport in vrata preizkusi odjemalec, in ali dnevniki končne točke ta poskus sploh vidijo? Ali se napaka zgodi med začetno izmenjavo, po obdobju nedejavnosti ali le pri večjih prenosih?
Ti štirje odgovori kažejo na filtriranje, potek stanja prevajanja, napačno končno točko ali obravnavo velikosti paketa. Nobenega od tega ne dokaže pogled na DS-Lite na strani računa.
Pozorno berite spremembe ponudnika
Sprememba računa lahko sovpada z delujočo povezavo, hkrati pa spremeni več lastnosti. Zapišite, katera lastnost se je spremenila, ker novo ime paketa ni tehnična razlaga.
Navodilo za vklop dvojnega sklada je dvoumno, dokler nekdo ne potrdi, kaj ponudnik dejansko zagotavlja. Če ga obravnavate kot univerzalno zahtevo za odjemalce VPN IPv4, domnevo spremenite v politiko.
Če je resnična zahteva dohodno gostovanje IPv4, se s ponudnikom pogovorite o podprti dohodni ureditvi, izvornem naslavljanju ali drugi zasnovi dostopa. Če je zahteva prenosnik, ki doseže oddaljeni strežnik, raje vprašajte o točno tem odhodnem toku. Vrstni red dela: poimenujte smer, potrdite zagotovljeni način, preizkusite preprost IPv4 in en transport, in spremenite načrt dostopa le, če smer to res zahteva.