IPv6 a través dun servidor VPN IPv4 segue a necesitar unha saída IPv6

O túnel levanta, o cliente recibe un enderezo IPv6 do pool e, aínda así, todos os destinos IPv6 esgotan o tempo. Dentro do túnel non hai nada roto: IPv6 viaxa perfectamente dentro do transporte IPv4, e iso nunca foi a parte difícil. O enderezo que entregaches é unha promesa que o servidor non pode cumprir, porque a saída non ten ningún upstream IPv6 ao que envialo. A reparación corresponde á saída, non ao perfil do cliente.

O síntoma: un enderezo e ningún camiño

Unha comprobación no lado do cliente mostra un enderezo IPv6 de aspecto global no dispositivo de túnel e unha ruta que apunta cara a el, e por iso isto se le mal como un fallo do cliente. O tráfico entra no túnel, o servidor desencapsúlao e despois o paquete aterra nun host cuxa táboa de encamiñamento non ten ningunha ruta por defecto IPv6 cara a ningún lugar real. Segundo a pila, obtés un inalcanzábel inmediato ou un descarte silencioso, e en ambos os casos o cliente ve un tempo de espera que parece idéntico a un cortalumes.

Le a propia táboa de encamiñamento do servidor antes de tocar o cliente, porque é alí onde vive a metade que falta do camiño. Un servidor cunha soa ruta por defecto IPv4 xa che deu a resposta.

Segue o paquete despois da desencapsulación

Dentro do túnel o paquete é IPv6 corrente e a súa orixe é o enderezo do cliente. O servidor retira a encapsulación de transporte e entón sostén un paquete IPv6 nativo que debe reenviarse a un seguinte salto IPv6. Unha ruta por defecto IPv4 non pode levalo, e traducilo a IPv4 é outra función que ninguén despregou. Ese é todo o fallo, e non ten nada que ver con se o oínte de VPN respondeu por IPv4.

A mecánica da encapsulación de IPv6 sobre IPv4 descríbese no RFC 4213, e o detalle importante alí é que os extremos seguen a necesitar conectividade IPv6 real na outra beira do túnel. Envolver unha cabeceira non fai aparecer un upstream.

Dúas capas de túnel, dúas comprobacións independentes

Verifica cada capa por separado, porque un túnel exterior que funciona agocha un interior roto. Comproba o camiño exterior cun ping IPv4 do cliente ao servidor e confirma o porto que usas. Despois comproba o camiño interior no servidor, onde ip -6 route debe mostrar unha ruta por defecto ou unha ruta concreta aprendida dun upstream real, e ip -6 addr debe mostrar un prefixo de orixe que o upstream acepte. Calquera cousa menos ca iso é decoración na interface.

Un enderezo único-local, ou un prefixo de aspecto global ao que nada encamiña de volta, aparecerá ben contento nunha interface e non irá a ningures. A alcanzabilidade pública concédea o upstream, non a forma do enderezo.

O mesmo se aplica no cliente: ip -6 route get 2001:4860:4860::8888 debería nomear o dispositivo de túnel, e se nomea o físico, o cliente non está a usar a VPN para IPv6 en absoluto.

Prefixo de orixe, tamaño e ICMPv6

Pregunta ao upstream que prefixos de orixe aceptará para reenviar, e usa un deles para o pool de clientes. Un provedor que che dá un /64 para a interface propia do servidor non necesariamente che encamiña un segundo /64 nin un bloque maior, e a diferenza é unha tarde de depuración que un ticket de soporte resolve cunha pregunta. Pregúntao por escrito e garda a resposta xunto á configuración.

Orzamenta a encapsulación extra que a túa pila realmente usa, e mantén ICMPv6 funcionando, incluído Packet Too Big. Unha segunda cabeceira reduce a carga útil, así que un camiño que responde a pings pequenos pode fallar igualmente nunha transferencia de ficheiro, e un cortalumes que descarta todo ICMPv6 converte un problema de tamaño recuperábel nun burato negro. Proba unha transferencia grande antes de anunciar o servizo.

Que é un problema completamente distinto

Chegar a unha aplicación só IPv4 desde un cliente só IPv6 é tradución, non tunelización, e necesita algo como un despregamento deliberado de NAT64. O destino non entenderá unha cabeceira de túnel extra só porque engadiches unha. Os servizos de transición históricos merecen o mesmo coidado: o RFC 7526 retirou o modelo de retransmisión anycast 6to4, así que un titorial escrito ao seu redor describe algo que xa non ten un retransmisor público mantido.

Se o servidor non ten ningún upstream IPv6 utilizábel, as opcións son un upstream soportado, unha saída distinta ou unha decisión documentada de que IPv6 quede fóra do túnel. O que non é aceptábel é dicir aos clientes que existe un servizo IPv6 mentres a súa conexión IPv6 corrente evita a VPN en silencio.