WireGuard funciona con datos móviles pero no en la misma wifi

El túnel se levanta con datos móviles y luego se queda en conectando en casa, con el mismo perfil, la misma clave de par y ningún cambio de configuración entre medias. La diferencia está en el trayecto: una solicitud desde dentro de la LAN hacia la dirección pública del router no es el mismo viaje que una solicitud que llega desde internet. La mayoría de las pasarelas domésticas o no implementan el camino de vuelta o solo lo hacen para ciertos protocolos. Eso hace que el síntoma parezca una clave rota cuando nada de la clave se ha movido. Determine qué camino falló antes de tocar una clave, una redirección de puerto o un perfil de cliente.

Una dirección, dos caminos distintos

Desde fuera, un paquete llega a la dirección pública del router y una regla de redirección de puerto lo entrega al receptor de WireGuard en el host interno. Desde dentro, el cliente marca la misma dirección pública, así que el paquete sale del cliente, llega al router y tiene que girarse de vuelta hacia la LAN. Es en ese giro donde los dos caminos se separan, porque el router debe traducir un flujo que a la vez sale y vuelve a entrar por la misma interfaz. Muchas implementaciones lo descartan en vez de traducirlo, y el cliente espera entonces un saludo que nunca se envió.

El comportamiento suele llamarse NAT loopback o hairpinning, y pertenece al router y no a WireGuard; RFC 4787 expone los casos de traducción en los que una pasarela puede o no admitirlo. WireGuard en sí no opina sobre el camino, porque solo ve paquetes que alcanzan su interfaz. Cuando el router descarta el flujo, el demonio no recibe nada, el cliente informa de un tiempo de espera de saludo y el registro del servidor queda vacío. Un registro vacío es, por tanto, una pista de dónde se detuvo el paquete, no una prueba de que el servidor esté caído. También es la razón por la que reinstalar no cambia nada.

Lo contrario también cuenta: un registro del servidor que muestra un intento de saludo desde la dirección de la LAN demuestra que el paquete llegó y que el camino está bien, lo que traslada la investigación a las claves y las direcciones permitidas. Lea el registro por lo que demuestra y no por lo que esperaba ver.

Reprodúzcalo antes de cambiar nada

Pruebe desde una red externa autorizada con el mismo dispositivo y el mismo perfil, y repita después la prueba dentro de la LAN sin editar nada. Un saludo completado fuera y un cliente que dentro nunca sale del dispositivo reproducen la condición en lugar de adivinarla. Ambos intentos tienen que usar el mismo perfil, o la comparación no demuestra nada.

Después mire a qué resuelve el nombre del punto final para este dispositivo. Los tres comandos siguientes también muestran a qué dirección marcó realmente el cliente:

wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.net

El primer comando informa del punto final que la interfaz está usando ahora, y los otros dos muestran a qué resuelve el nombre en esta máquina. Un cliente que marca una dirección pública mientras está en la misma red que el servidor está ejerciendo el camino de hairpin. Un cliente que marca la dirección de la LAN no lo hace, y un fallo ahí pertenece a otra investigación. Esa distinción decide si la sección siguiente se aplica siquiera.

Formas admitidas de llegar a un servidor cercano

La disposición más limpia es una respuesta de horizonte dividido: el nombre público resuelve a la dirección pública para internet y a la dirección de LAN del servidor para los clientes de dentro. El perfil conserva un solo nombre de punto final y el resolutor elige el camino. Eso exige control de la respuesta DNS interna, que un router doméstico suele ofrecer y una organización puede organizar a propósito. Sin ese control, las opciones que quedan son una función del router o un segundo perfil.

La función del router es la reflexión: la pasarela traduce el flujo de dentro a fuera y lo devuelve hacia dentro. Donde funciona no necesita ningún cambio en el cliente, y donde no funciona ninguna configuración del cliente lo salvará. Pruébela observando el registro del servidor durante un intento interno en vez de leer la lista de funciones del router.

Editar el perfil a una dirección privada es un diagnóstico, no un diseño. Demuestra que el servidor responde en la LAN, y rompe el mismo perfil en el momento en que el portátil sale de casa.

Mantenga el perfil utilizable fuera de casa

Elija el camino que elija, deje en paz la comprobación de identidad. La dirección del punto final no es la identidad del par, y un cambio de dirección nunca justifica aceptar una clave pública ajena que casualmente responda. WireGuard autentica por clave, así que un host equivocado falla el saludo en lugar de conceder acceso a algo inesperado.

Si la dirección pública se mueve, el DNS dinámico es lo que mantiene útil el nombre, y el comportamiento de actualización del cliente decide con qué rapidez llega el cambio. Pruébelo desde fuera tras un cambio de dirección, porque el caso de la LAN no puede validarlo. Esté atento a un resolutor que cachea la respuesta antigua más allá de la vida del registro. Un nombre que aún apunta a la dirección anterior se ve exactamente igual que un servidor que se cayó.

Anote qué nombre usa el perfil y a qué resuelve en cada lado de la frontera. Un perfil que depende de una función del router que nadie registró es una llamada de soporte esperando la próxima actualización de firmware. La nota es también lo que le dice a la siguiente persona si un fallo interno es el caso conocido de hairpin o algo nuevo.