¿Debe el tráfico IPv6 pasar por la VPN o directamente?

El mes pasado dos personas me pidieron resultados opuestos: una quería que la VPN cubriera IPv6 y la otra quería que la impresora de la oficina siguiera funcionando. Una sola ruta ::/0 no puede entregar ambas cosas por sí misma. Que esa ruta pertenezca dentro del túnel depende de tres condiciones, y la primera la descarta para la mayoría de las salidas comerciales. Si la salida no transporta IPv6, enrutar la ruta por defecto hacia ella esconde tu tráfico en un túnel que no tiene a dónde enviarlo.

Tres condiciones deciden la respuesta

La ruta por defecto es una línea, ::/0, y coincide con cualquier destino IPv6 sin una ruta más específica (RFC 4291). Instalarla es fácil. Decidir si deberías hacerlo se reduce a tres condiciones.

Condición uno: la salida a la que te conectas tiene IPv6 funcionando y está dispuesta a reenviarlo. Condición dos: tu cliente puede mantener un camino hacia el extremo del túnel, que normalmente está dentro del rango que vas a enrutar. Condición tres: puedes nombrar los destinos IPv6 locales que deben quedarse fuera del túnel.

Cada condición falla a su manera, y por eso adivinar cuesta una noche entera. Una condición uno fallida te da silencio y una tabla de rutas que parece correcta. Una condición dos fallida mata el saludo unos segundos después de empezar. Una condición tres fallida deja un túnel funcionando y a un compañero descontento en la impresora.

¿La salida transporta realmente IPv6?

Una interfaz de túnel con una dirección IPv6 no demuestra nada sobre el otro lado. Muchos perfiles comerciales son solo IPv4 por dentro: el servidor te da una dirección v4 y descarta todo lo demás. Instala encima una ruta por defecto desde AllowedIPs y el núcleo enviará encantado IPv6 hacia una interfaz cuyo par nunca lo ve.

Prueba desde el cliente mientras el túnel está activo. ping -6 -c 3 2001:4860:4860::8888 y ip -6 route get 2001:4860:4860::8888 responden preguntas distintas: si vuelve una respuesta y qué dispositivo eligió el núcleo. Cuando el segundo nombra tu túnel y el primero no devuelve nada, el problema es la salida, no la ruta.

Si tú mismo gestionas la salida, la prueba del cliente puede pasar y el camino aun así terminar en un callejón sin salida. Confirma net.ipv6.conf.all.forwarding=1 en la puerta de enlace y que su cortafuegos acepta paquetes reenviados fuera del túnel. Un paquete correctamente enrutado hacia una salida que se niega a retransmitir parece exactamente un fallo de enrutamiento desde el lado del cliente.

¿Puede el cliente mantener su camino hasta el extremo?

Este es el caso que me atrapó en un portátil con un extremo de WireGuard solo IPv6. La dirección del extremo es una dirección global corriente, así que cae dentro de ::/0. Enruta todo el prefijo hacia la interfaz y los paquetes de saludo se perseguirán a sí mismos dentro del túnel que aún intentan construir. El túnel nunca sube, y nada en la salida del cliente dice por qué.

wg-quick se encarga de esto en Linux. Deriva rutas de AllowedIPs, las instala en su propia tabla y añade una regla de política para que el tráfico al extremo se resuelva primero por la tabla principal: la regla suppress_prefixlength 0 que encuentras en ip -6 rule. Por eso wg-quick up tiene éxito donde una ip -6 route add default dev wg0 escrita a mano te deja fuera.

Comprueba ambos estados con ip -6 route get <endpoint-v6>, antes y después de levantar el túnel. Si la respuesta cambia a tu dispositivo de túnel, has eliminado el camino que el túnel necesita. Cuando escribas las rutas tú mismo, añade una ruta de host hacia el extremo por la puerta de enlace original, o conéctate al extremo por IPv4 y deja IPv6 para la carga útil.

¿Qué debe quedarse fuera del túnel?

Las rutas más específicas vencen a la ruta por defecto, así que un prefijo en el enlace o un rango ULA con ruta propia sigue funcionando sin esfuerzo extra. Esa es la razón silenciosa por la que sobreviven tantas configuraciones IPv4 de túnel completo: los prefijos de la LAN son más específicos que el de defecto y nunca entran en el túnel.

Se rompe cuando un dispositivo local es alcanzable por una dirección global, algo normal en una impresora a la que el mismo router dio un prefijo público, un NAS o un televisor. Esas direcciones coinciden con ::/0 y con nada más, así que se mudan al túnel con todo lo demás y desaparecen.

Decide por destino, no por protocolo. Si importan dos o tres equipos locales, da a sus prefijos una ruta por la interfaz física, o quítalos del conjunto negociado. Si la lista no deja de crecer, la respuesta honesta es túnel dividido para IPv6 con una lista de excepciones escrita, no una ruta por defecto que parcheas sin parar.

Si la respuesta es no, bloquéalo

Dejar IPv6 sin enrutar no es lo mismo que dejarlo en paz. Un equipo con una ruta por defecto IPv6 funcionando sigue usándola mientras el túnel transporta IPv4, así que el tráfico sale al lado de la VPN y cada servicio que prefiere IPv6 ve tu dirección real. Eso es una fuga, no un túnel dividido.

Elige una y anota cuál elegiste. Enruta la ruta por defecto y acepta los compromisos anteriores, o desactiva IPv6 mientras dure el túnel. Omitir el prefijo de AllowedIPs no basta por sí solo, porque el sistema operativo mantiene su propia ruta por defecto. En Linux la versión contundente es sysctl -w net.ipv6.conf.all.disable_ipv6=1; la versión fina deja caer IPv6 fuera del túnel con una regla de cortafuegos. Los clientes de teléfono incluyen un interruptor explícito de bloqueo de IPv6 que hace el mismo trabajo.

Verifícalo como una fuga

Levanta el túnel y lee el estado en lugar de confiar en el interruptor. ip -6 route show default debería mostrar una sola ruta por defecto, y ip -6 route get para un destino fuera de tu LAN debería nombrar el dispositivo de túnel. Repite ambos tras una desconexión: una ruta por defecto que sobrevive al túnel es el fallo que buscabas.

Luego prueba la otra dirección. Desde un equipo de la red local, llega al cliente por su dirección IPv6 local. Si eso deja de funcionar, la condición tres nunca se cumplió, dijera lo que dijera la tabla de rutas en ese momento.

Escribe el resultado donde lo encuentre la siguiente persona: qué prefijos se quedan locales, por qué y qué hace el cliente tras una desconexión. Dos líneas en un runbook ahorran al siguiente ingeniero redescubrir el bucle del extremo a medianoche.