IPv6 a través d’un servidor VPN IPv4 encara necessita una sortida IPv6

El túnel s’aixeca, el client rep una adreça IPv6 del pool i, tot i així, cada destinació IPv6 acaba sense resposta. Dins del túnel no hi ha res trencat: IPv6 viatja perfectament bé dins del transport IPv4, i això mai no va ser la part difícil. L’adreça que has lliurat és una promesa que el servidor no pot complir, perquè la sortida no té cap upstream IPv6 on enviar-la. La reparació correspon a la sortida, no al perfil del client.

El símptoma: una adreça i cap camí

Una comprovació al costat del client mostra una adreça IPv6 d’aspecte global al dispositiu de túnel i una ruta que hi apunta, i per això això es llegeix malament com un error del client. El trànsit entra al túnel, el servidor el desencapsula i després el paquet acaba en un host la taula d’encaminament del qual no té cap ruta per defecte IPv6 cap a cap lloc real. Segons la pila obtens una inaccessibilitat immediata o una descàrrega silenciosa, i en tots dos casos el client veu un temps d’espera que sembla idèntic a un tallafoc.

Llegeix la taula d’encaminament del propi servidor abans de tocar el client, perquè és allà on viu la meitat que falta del camí. Un servidor amb una sola ruta per defecte IPv4 ja t’ha donat la resposta.

Segueix el paquet després de la desencapsulació

Dins del túnel el paquet és IPv6 corrent amb l’adreça del client com a origen. El servidor treu l’encapsulació de transport i llavors té un paquet IPv6 nadiu que s’ha de reenviar a un següent salt IPv6. Una ruta per defecte IPv4 no el pot portar, i traduir-lo a IPv4 és una funció diferent que ningú no ha desplegat. Aquesta és tota la fallada, i no té res a veure amb si l’oient de VPN va respondre per IPv4.

La mecànica d’encapsulació d’IPv6 sobre IPv4 es descriu a l’RFC 4213, i el detall important d’allà és que els extrems encara necessiten connectivitat IPv6 real a l’altra banda del túnel. Embolcallar una capçalera no fa aparèixer cap upstream.

Dues capes de túnel, dues comprovacions independents

Verifica cada capa per separat, perquè un túnel exterior que funciona amaga un túnel interior trencat. Comprova el camí exterior amb un ping IPv4 del client al servidor i confirma el port que uses. Després comprova el camí interior al servidor, on ip -6 route ha de mostrar una ruta per defecte o una ruta concreta apresa d’un upstream real, i ip -6 addr ha de mostrar un prefix d’origen que l’upstream accepti. Qualsevol cosa menys que això és decoració a la interfície.

Una adreça únic-local, o un prefix d’aspecte global al qual res no encamina de tornada, apareixerà ben contenta en una interfície i no anirà enlloc. L’abast públic el concedeix l’upstream, no la forma de l’adreça.

El mateix passa al client: ip -6 route get 2001:4860:4860::8888 hauria de nomenar el dispositiu de túnel, i si nomena el físic, el client no fa servir gens la VPN per a IPv6.

Prefix d’origen, mida i ICMPv6

Pregunta a l’upstream quins prefixos d’origen acceptarà per reenviar, i usa’n un per al pool de clients. Un proveïdor que et dona un /64 per a la interfície pròpia del servidor no necessàriament t’encamina un segon /64 ni un bloc més gran, i la diferència és una tarda de depuració que un tiquet de suport resol amb una pregunta. Pregunta-ho per escrit i desa la resposta amb la configuració.

Preveu marge per a l’encapsulació extra que la teva pila realment fa servir, i mantingues ICMPv6 funcionant, inclòs Packet Too Big. Una segona capçalera redueix la càrrega útil, així que un camí que respon a pings petits encara pot fallar en una transferència de fitxer, i un tallafoc que descarta tot l’ICMPv6 converteix un problema de mida recuperable en un forat negre. Prova una transferència gran abans d’anunciar el servei.

Què és un problema completament diferent

Arribar a una aplicació només IPv4 des d’un client només IPv6 és traducció, no tunelització, i necessita una cosa com un desplegament deliberat de NAT64. La destinació no entendrà una capçalera de túnel extra només perquè n’hi has afegit una. Els serveis de transició històrics mereixen la mateixa cura: l’RFC 7526 va retirar el model de relé anycast 6to4, així que un tutorial escrit al seu voltant descriu una cosa que ja no té cap relé públic mantingut.

Si el servidor no té cap upstream IPv6 utilitzable, les opcions són un upstream suportat, una altra sortida o una decisió documentada que IPv6 es quedi fora del túnel. El que no és acceptable és dir als clients que existeix un servei IPv6 mentre la seva connexió IPv6 corrent esquiva la VPN en silenci.