Túnel completo de WireGuard: AllowedIPs 0.0.0.0/0 no basta

Poner 0.0.0.0/0, ::/0 en los AllowedIPs de un par es el paso que todo el mundo recuerda, y solo decide qué tráfico se permite transportar al par. Esos prefijos no crean rutas, no reenvían nada en el otro extremo y dejan el resolutor de cada aplicación exactamente donde estaba. Cuatro cosas separadas tienen que cumplirse a la vez para que un túnel completo sea completo, y lo mejor es comprobarlas en el orden de abajo, porque una comprobación posterior no puede rescatar una anterior. Cada comprobación de abajo es un hecho que se puede leer de una máquina, no un ajuste que esperas que se haya aplicado.

Qué selecciona el prefijo del par y qué no

AllowedIPs es a la vez un selector y una autorización. Dice al lado local qué destinos pueden enviarse a este par, y dice al lado receptor qué direcciones de origen puede presentar este par. Ese es todo el trabajo. Nada en esa descripción crea una ruta en el host, activa el reenvío en el lado remoto ni toca la resolución de nombres.

Por eso una configuración puede parecer completa y comportarse como un túnel dividido. El prefijo dice que el par aceptaría todo; la tabla de rutas del host decide qué llega realmente allí, y la puerta de enlace decide si sale algo. Ninguna de esas tres decisiones vive en la estrofa del par.

Enrutar al cliente, no solo la lista de pares

Gestores como wg-quick programan la tabla de rutas del host por ti, y por eso dos archivos de configuración idénticos se comportan distinto según cómo haya subido la interfaz. Un perfil mínimo es lo bastante corto para leerlo de una vez:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Dos detalles llevan el trabajo. El campo Address es un único prefijo de host en lugar de una subred que el cliente cree poseer, y es el gestor el que convierte los AllowedIPs por defecto en una ruta por defecto real. Levanta el mismo archivo con ip link y wg setconf y no aparecerá ninguna ruta, lo que parece un túnel roto y en realidad es uno sano con el paso de enrutamiento omitido. El manual de wg-quick documenta el enrutamiento y el Table comportamiento que añaden esos gestores.

Lee el resultado en lugar del archivo: ip route get 1.1.1.1 debería nombrar la interfaz del túnel, y wg show debería informar de un handshake reciente con un contador de transferencia que se mueve. Un handshake sin ruta significa que el gestor nunca se ejecutó, y editar el perfil otra vez no lo arreglará. Arranca la interfaz como lo hará el usuario, o la prueba mide tu shell en lugar del despliegue.

Mantener el extremo fuera del túnel

Un túnel completo captura cada destino, incluido aquel con el que debe hablar para existir. Los gestores lo resuelven añadiendo una ruta de host para el extremo a través de la puerta de enlace original, y por eso una configuración correcta casi siempre contiene una excepción deliberada. Aplicar la mitad de la configuración con un gestor y la otra mitad a mano es la forma habitual de que esa excepción se pierda.

Si el extremo es un nombre de host que resuelve a varias direcciones, o a una familia que no transportas, la excepción envejece mal y el túnel puede fallar tras una reconexión que parecía rutinaria. Fija el extremo a una dirección que controles, o confirma que el gestor la reevalúa, y vuelve a leer la ruta de host después de cada cambio de red.

El mismo mecanismo explica por qué un túnel completo y un portal cautivo se pelean. El portal espera interceptar el tráfico que ahora captura tu túnel, así que en redes de hotel y aeropuerto levantas el túnel después del inicio de sesión del portal, nunca antes.

Reenvío y camino de vuelta en la puerta de enlace

En la puerta de enlace, activa el reenvío para la familia que transportas, permite la cadena forward en ambos sentidos cuando traduces, y confirma el camino de vuelta con una consulta específica de origen. Nada de eso se deduce de un handshake correcto, porque un handshake solo demuestra que los dos pares pueden intercambiar UDP. No dice nada sobre qué pasa después con el paquete desencapsulado.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

La consulta se ejecuta en la puerta de enlace y no en el cliente, o leerás otra tabla de rutas. Si nombra la interfaz equivocada, o informa de que no hay ruta, entonces ningún cambio del lado del cliente producirá una salida a internet. Cuando la puerta de enlace traduce las direcciones de los clientes a la salida, la respuesta depende de ese estado de traducción, así que la regla tiene que existir para los dos sentidos del flujo y no solo para el saliente.

DNS y el estado de fallo, probados por separado

El protocolo en sí no configura el resolutor de ninguna aplicación. wg-quick aplica la línea DNS a través de la integración del resolutor de la distribución, los contenedores y los navegadores con sus propias pilas pueden ignorarla, y por eso un nombre puede fallar mientras el túnel lleva paquetes perfectamente. Prueba con un nombre de host en lugar de una dirección, y anota qué servidor respondió en lugar de suponer que lo hizo el del perfil.

Las familias de direcciones son una prueba aparte con una respuesta aparte. Una ruta por defecto v4 no dice nada sobre lo que hará la conexión v6 de una aplicación, y un túnel que filtra en silencio la segunda familia es peor que uno que falla ruidosamente. Consulta un nombre por cada familia, lee la interfaz que usó cada petición, y comprueba los contadores de traducción antes y después, porque una regla que no coincide con nada se ve idéntica a una regla que falta.

Por último, prueba el estado que quieres cuando el túnel se detiene. Un túnel completo debería fallar cerrado para el tráfico que reclama: si la interfaz cae y las aplicaciones siguen en silencio por el enlace físico, el diseño es un túnel dividido con pasos extra. Escribe el comportamiento de fallo previsto, compruébalo a propósito, y termina registrando las cuatro respuestas — qué gestor levanta la interfaz, qué ruta lleva la predeterminada, quién reenvía y traduce en la puerta de enlace, y qué resolutor responde.