IPv6 per IPv4 VPN serverį vis tiek reikia tikros IPv6 išėjimo

Tunelis pakyla, klientas gauna IPv6 adresą iš telkinio, ir vis tiek kiekvienas IPv6 taikinys baigiasi skirtuoju laiku. Tunele niekas nesugedę: IPv6 puikiai keliauja IPv4 transporte, ir tai niekada nebuvo sunki dalis. Adresas, kurį išdavei, yra pažadas, kurio serveris negali tesėti, nes išėjimas neturi IPv6 upstream, kur jį siųstų. Taisymas priklauso išėjimui, o ne kliento profiliui.

Simptomas: adresas yra, kelio nėra

Kliento pusės patikra rodo globaliai atrodantį IPv6 adresą tunelio įrenginyje ir į jį vedantį maršrutą, todėl tai klaidingai perskaitoma kaip kliento klaida. Srautas patenka į tunelį, serveris jį dekapsuliuoja, o tada paketas atsiduria mazge, kurio maršrutizavimo lentelėje nėra IPv6 numatytojo maršruto į jokią realią vietą. Priklausomai nuo steko gauni nedelsiant nepasiekiamumą arba tylų numetimą, ir abiem atvejais klientas mato laiko limitą, kuris atrodo lygiai kaip užkarda.

Prieš liesdamas klientą, perskaityk paties serverio maršrutizavimo lentelę, nes ten gyvena trūkstama kelio pusė. Serveris su vienu IPv4 numatytuoju maršrutu jau davė tau atsakymą.

Sek paketą po dekapsuliavimo

Tunelio viduje paketas yra paprastas IPv6, o jo šaltinis yra kliento adresas. Serveris nuima transporto inkapsuliavimą ir tada laiko vietinį IPv6 paketą, kurį reikia perduoti kitam IPv6 šuoliui. IPv4 numatytasis maršrutas jo negali pernešti, o jo vertimas į IPv4 yra kita funkcija, kurios niekas nesudiegu. Tai ir yra visas gedimas, ir jis neturi nieko bendra su tuo, ar VPN klausytojas atsakė per IPv4.

IPv6 per IPv4 inkapsuliavimo mechanika aprašyta RFC 4213, ir ten svarbi detalė yra ta, kad galiniams taškams vis dar reikia tikro IPv6 ryšio kitoje tunelio pusėje. Antraštės apvyniojimas nesukuria upstream iš nieko.

Du tunelio sluoksniai, dvi nepriklausomos patikros

Tikrink kiekvieną sluoksnį atskirai, nes veikiantis išorinis tunelis slepia sugedusį vidinį. Patikrink išorinį kelią IPv4 ping iš kliento į serverį ir patvirtink naudojamą portą. Tada patikrink vidinį kelią serveryje, kur ip -6 route turi rodyti numatytąjį arba konkretų maršrutą, išmoktą iš tikro upstream, ir ip -6 addr turi rodyti šaltinio prefiksą, kurį upstream priima. Viskas mažiau nei tai yra papuošimas sąsajoje.

Unikalus vietinis adresas arba globaliai atrodantis prefiksas, į kurį niekas nesiunčia atgal, mielai pasirodys sąsajoje ir niekur nenueis. Viešą pasiekiamumą suteikia upstream, o ne adreso forma.

Tas pats galioja kliente: ip -6 route get 2001:4860:4860::8888 turėtų nurodyti tunelio įrenginį, o jei nurodo fizinį, klientas apskritai nenaudoja VPN IPv6.

Šaltinio prefiksas, dydis ir ICMPv6

Paklausk upstream, kokius šaltinio prefiksus jis priims persiuntimui, ir naudok vieną jų klientų telkiniui. Teikėjas, kuris duoda tau /64 serverio pačio sąsajai, nebūtinai maršrutizuoja tau antrą /64 ar didesnį bloką, ir skirtumas yra popietė derinimo, kurią palaikymo bilietas išsprendžia vienu klausimu. Klausk raštu ir laikyk atsakymą kartu su konfigūracija.

Numatyk biudžetą papildomam inkapsuliavimui, kurį tavo stekas iš tikrųjų naudoja, ir palaikyk veikiantį ICMPv6, įskaitant Packet Too Big. Antra antraštė sumažina naudingąją apkrovą, todėl kelias, kuris atsako į mažus ping, vis tiek gali nepavykti perduodant failą, o užkarda, kuri išmeta visą ICMPv6, paverčia pataisomą dydžio problemą juoda skyle. Prieš skelbdamas paslaugą, išbandyk vieną didelį perdavimą.

Kas yra visiškai kita problema

Pasiekti tik IPv4 programą iš tik IPv6 kliento yra vertimas, o ne tuneliavimas, ir tam reikia kažko panašaus į sąmoningai įdiegtą NAT64 sprendimą. Paskirties vieta nesupras papildomos tunelio antraštės vien todėl, kad ją pridėjai. Istorinės perėjimo paslaugos nusipelno tokio pat rūpesčio: RFC 7526 panaikino 6to4 anycast relės modelį, todėl aplink jį parašytas vadovas aprašo tai, kas nebeturi prižiūrimos viešos relės.

Jei serveris neturi tinkamo IPv6 upstream, pasirinkimai yra palaikomas upstream, kitas išėjimas arba dokumentuotas sprendimas, kad IPv6 lieka už tunelio. Nepriimtina yra sakyti klientams, kad IPv6 paslauga egzistuoja, tuo metu kai jų įprastas IPv6 ryšys tyliai apeina VPN.