Dividir su /64 no enruta IPv6 hacia los clientes VPN

El cliente muestra una dirección IPv6 global, el handshake se completó y nada vuelve desde internet. El ajuste del grupo parece correcto porque lo es; la dirección es válida y el túnel la transporta. Lo que falla es la entrega, y la entrega depende de una decisión tomada más arriba del servidor VPN que ninguna configuración del lado del cliente puede influir.

El mito: una parte de su /64 ya es alcanzable

La historia es atractiva: el servidor tiene un /64 público, córtelo por la mitad, entregue la otra mitad al grupo de VPN y esos clientes ya están en internet. Dividir el prefijo sí asigna direcciones sin colisiones. No cambia cómo la red upstream decide adónde debe ir un paquete destinado a una de esas direcciones.

IPv6 no tiene una capa de traducción predeterminada a la que recurrir, así que la ruta de vuelta tiene que existir como enrutamiento o como entrega a nivel de enlace. Un paquete dirigido a la dirección de túnel de un cliente llega al router upstream, y ese router toma una decisión de reenvío a partir de su propia tabla. Si la tabla apunta al enlace físico, el paquete va allí sin importar lo que crea su servidor VPN.

Ese es todo el fallo: la dirección de ida funciona porque su servidor la envía, y la dirección de vuelta muere a un salto de distancia porque el upstream nunca supo que el cliente existe.

Qué requiere realmente la entrega en el enlace

Cuando el upstream considera que todo el /64 está en el enlace físico, resuelve cada dirección de destino con descubrimiento de vecinos. Envía una solicitud en ese enlace y espera que el propietario de la dirección responda. Un cliente VPN detrás de un túnel no está en ese enlace y no puede responder, así que la solicitud queda sin respuesta y el paquete se descarta.

Recortar un /65 no cambia esa expectativa. El upstream sigue tratando el rango como si estuviera en el enlace, porque lo único que le haría cambiar de opinión es una ruta o un proxy que responda en nombre del cliente. Ninguno de los dos aparece porque usted editó una configuración de VPN. Esa brecha explica por qué un grupo puede funcionar perfectamente entre sus propios clientes y aun así ser inalcanzable desde cualquier otro lugar.

El descubrimiento de vecinos por proxy es el mecanismo que puede tender un puente entre los dos mundos. La puerta de enlace responde a las solicitudes de las direcciones de cliente concretas que posee y reenvía el tráfico al túnel. Funciona, y debe acotarse exactamente a esas direcciones con un ciclo de vida que siga al grupo, porque responder por una dirección que ya no atiende convierte el tráfico de otro en un agujero negro. Algunos upstreams no aceptarán respuestas de proxy que no esperaban, así que este diseño también necesita el acuerdo del proveedor.

Qué requiere la entrega enrutada

El diseño más limpio es una asignación que el upstream enrute realmente hacia su puerta de enlace. Puede ser un prefijo delegado o una ruta estática para un bloque más pequeño, y el requisito es el mismo en ambos casos: la tabla del upstream debe apuntar a su servidor para el rango de clientes. Entonces el tráfico de vuelta llega a la puerta de enlace y la puerta de enlace lo reenvía al túnel.

La entrega enrutada elimina por completo la cuestión del descubrimiento de vecinos, y por eso vale la pena pedírselo al proveedor antes de construir algo ingenioso. Pida la ruta por escrito y confirme que el siguiente salto es la dirección que el upstream puede alcanzar realmente.

Ambos diseños siguen necesitando el reenvío de IPv6 habilitado en la puerta de enlace y reglas de cortafuegos que permitan el flujo reenviado en ambas direcciones. La entrega es un requisito previo, no un sustituto, para el resto del camino. Una ruta que funciona con el reenvío desactivado produce exactamente el mismo silencio que una ruta ausente, así que compruebe ambas cosas antes de rediseñar nada.

Dos rutas independientes que acertar

El prefijo del grupo y la ruta predeterminada del propio cliente son ajustes separados, y confundirlos produce conectividad parcial que parece un túnel roto. El grupo le dice al servidor qué direcciones repartir. Las rutas del cliente deciden a qué destinos el cliente envía tráfico al túnel, si es que envía alguno.

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

El prefijo anterior es espacio de documentación, y la redirección se aplica solo a IPv6, que es exactamente lo que a menudo quiere un despliegue de doble pila mientras la entrega de IPv6 todavía se está arreglando. Una redirección de IPv4 no establece cobertura de IPv6, y ninguna de las dos opciones implica la otra.

Mantenga funcionando el tráfico de control del que depende IPv6 bajo cualquier política que aplique. Los mensajes Packet Too Big son la víctima clásica de un cortafuegos que solo permite TCP y UDP, y descartarlos produce conexiones que se establecen y luego se atascan en transferencias grandes.

Los anuncios de router son la tercera pieza móvil. Si la puerta de enlace empieza a anunciar en el enlace ascendente, puede cambiar lo que los clientes y los vecinos creen sobre los prefijos en el enlace, lo que puede deshacer silenciosamente el diseño que acaba de documentar.

Registre el diseño para que una reconstrucción lo reproduzca

Anote tres objetos por separado: la asignación del cliente, la ruta de destino del cliente y el método de entrega del upstream para la asignación. Un lector que tenga los tres puede reconstruir el despliegue; un lector que solo tenga el ajuste del grupo reproducirá el error original.

Luego pruebe explícitamente la dirección de vuelta, con un paquete que tenga que volver desde fuera. El manual de openvpn(8) cubre las opciones server-ipv6 y redirect, y la confirmación de enrutamiento de su proveedor cubre la mitad que el manual no puede.