IPv6 skozi strežnik VPN IPv4 še vedno potrebuje pravi izhod IPv6

Tunel se dvigne, odjemalec prejme naslov IPv6 iz poola, in vendar vsak cilj IPv6 poteče. V tunelu ni nič pokvarjeno: IPv6 se pelje povsem dobro znotraj prevoza IPv4, in to nikoli ni bil težji del. Naslov, ki si ga izdal, je obljuba, ki je strežnik ne more držati, ker izhod nima nobenega upstreama IPv6, kamor bi ga poslal. Popravilo spada na izhod, ne v profil odjemalca.

Simptom: naslov in nobena pot

Preverjanje na strani odjemalca pokaže naslov IPv6, ki je videti globalen, na tunelski napravi in pot, ki kaže vanj, zato se to napačno bere kot napaka odjemalca. Promet vstopi v tunel, strežnik ga dekapsulira, nato pa paket pristane na gostitelju, katerega usmerjevalna tabela nima privzete poti IPv6 nikamor v resnični svet. Glede na sklad dobiš takojšnjo nedosegljivost ali tiho zavrženje, in v obeh primerih odjemalec vidi časovno omejitev, ki je videti enako kot požarni zid.

Preberi lastno usmerjevalno tabelo strežnika, preden se dotakneš odjemalca, ker tam živi manjkajoča polovica poti. Strežnik z eno privzeto potjo IPv4 ti je odgovor že povedal.

Sledi paketu po dekapsulaciji

Znotraj tunela je paket navaden IPv6, njegov vir pa je naslov odjemalca. Strežnik sname transportno kapsuliranje in nato drži izvorni paket IPv6, ki ga je treba posredovati naslednjemu skoku IPv6. Privzeta pot IPv4 ga ne more nositi, pretvorba v IPv4 pa je druga funkcija, ki je nihče ni uvedel. To je celotna okvara in nima nobene zveze s tem, ali je poslušalec VPN odgovoril prek IPv4.

Mehanika kapsuliranja IPv6 čez IPv4 je opisana v RFC 4213, in pomembna podrobnost tam je, da končne točke še vedno potrebujejo pravo povezljivost IPv6 na drugi strani tunela. Ovijanje glave ne ustvari upstreama iz ničesar.

Dve plasti tunela, dve neodvisni preverjanji

Preveri vsako plast posebej, ker delujoč zunanji tunel skriva pokvarjenega notranjega. Preveri zunanjo pot s pingom IPv4 od odjemalca do strežnika in potrdi vrata, ki jih uporabljaš. Nato preveri notranjo pot na strežniku, kjer ip -6 route mora pokazati privzeto ali določeno pot, naučeno od pravega upstreama, in ip -6 addr mora pokazati predpono vira, ki jo upstream sprejme. Vse manj je le okras na vmesniku.

Edinstveno-lokalni naslov ali predpona, ki je videti globalna in h kateri nič ne usmerja nazaj, se bo z veseljem pojavil na vmesniku in ne bo šel nikamor. Javno dosegljivost daje upstream, ne oblika naslova.

Enako velja pri odjemalcu: ip -6 route get 2001:4860:4860::8888 bi moralo navesti tunelsko napravo, in če navaja fizično, odjemalec VPN za IPv6 sploh ne uporablja.

Predpona vira, velikost in ICMPv6

Vprašaj upstream, katere predpone vira bo sprejel za posredovanje, in eno od njih uporabi za pool odjemalcev. Ponudnik, ki ti da /64 za lastni vmesnik strežnika, ti ne usmerja nujno drugega /64 ali večjega bloka, in razlika je eno popoldne razhroščevanja, ki ga support ticket reši z enim vprašanjem. Vprašaj pisno in odgovor hrani pri konfiguraciji.

Predvidi rezervo za dodatno kapsuliranje, ki ga tvoj sklad dejansko uporablja, in ohrani ICMPv6 delujoč, vključno s Packet Too Big. Druga glava zmanjša uporabno koristno obremenitev, zato pot, ki odgovarja na majhne ping, lahko vseeno odpove pri prenosu datoteke, požarni zid, ki zavrže ves ICMPv6, pa spremeni popravljiv problem velikosti v črno luknjo. Pred napovedjo storitve preizkusi en velik prenos.

Kaj je povsem drug problem

Doseči aplikacijo, ki je samo IPv4, z odjemalca, ki je samo IPv6, je prevajanje, ne tuneliranje, in potrebuje nekaj kot namerno nameščen NAT64. Cilj ne bo razumel dodatne tunelske glave samo zato, ker si jo dodal. Zgodovinske storitve prehoda si zaslužijo enako skrb: RFC 7526 je ukinil model anycast releja 6to4, zato priročnik, napisan okoli njega, opisuje nekaj, kar nima več vzdrževanega javnega releja.

Če strežnik nima uporabnega upstreama IPv6, so možnosti podprt upstream, drug izhod ali dokumentirana odločitev, da IPv6 ostane zunaj tunela. Nesprejemljivo je odjemalcem govoriti, da storitev IPv6 obstaja, medtem ko njihova običajna povezava IPv6 tiho obide VPN.