Por qué la administración del router deja de responder tras un cambio de VPN

Cambiaste una ruta o una regla de cortafuegos para probar un túnel en el router, y ahora la página de administración no responde desde el portátil que funcionaba bien hace diez minutos. El reflejo es culpar a la VPN. La mayoría de las veces el túnel está sano y se ha roto una de otras tres cosas: no hay ruta de vuelta a la dirección propia del router, una política de entrada descarta la petición, o un servicio web no escucha en la dirección a la que llamas. Las tres se ven igual en el navegador, por eso la gente reinicia el túnel durante una hora y no aprende nada.

Aquí está el mito que conviene matar primero: un túnel que funciona no es una vía para volver a entrar. Es un nuevo enganche de red con sus propias preguntas de confianza, y puede eliminar en silencio tu antigua ruta de gestión mientras abre una nueva que nadie revisó.

El túnel nunca fue la ruta de administración

El reenvío y la entrada son trabajos distintos. «¿Puede un cliente llegar al NAS a través del túnel?» es una pregunta de reenvío sobre paquetes que pasan por el router. «¿Puedo abrir el puerto SSH del router?» es una pregunta de entrada sobre paquetes dirigidos al propio router. Una regla de paso escrita para tráfico reenviado no hace nada por la segunda, y esa es la razón más común por la que un túnel que transporta tráfico perfectamente sigue rechazando tu sesión de administración.

El error contrario es confiar en un nombre de interfaz. Un túnel se cifra hacia el par, no hacia cada servicio que hay detrás, y la palabra VPN en una etiqueta de interfaz no dice nada sobre qué orígenes deberían poder iniciar sesión.

Nivel uno: ¿hay una ruta a la dirección propia del router?

Empieza en el cliente y pregunta al núcleo adónde irá el paquete. En Linux, ip route get 10.6.0.1 imprime la ruta elegida, la interfaz de salida y la dirección de origen. Si informa de la ruta por defecto hacia tu proveedor, el paquete nunca entra en el túnel, y ninguna regla del router puede salvarlo.

El lado del túnel tiene su propia versión de la pregunta. WireGuard trata AllowedIPs como una tabla de enrutamiento de claves criptográficas: en cada extremo declara qué direcciones de origen puede usar un par y qué destinos se envían a ese par. Si la entrada del cliente no incluye la dirección de túnel del router, el cliente no tiene ruta hacia ella. Si la entrada del servidor para ese cliente no cubre la dirección de túnel del cliente, el servidor descarta el paquete antes de consultar ninguna regla del cortafuegos.

Confirma la dirección exacta que esperas alcanzar antes de depurar la política. Un registro DNS obsoleto o una entrada de vecino en caché de antes del cambio te llevan a una dirección que el router nunca poseyó.

Nivel dos: la política de entrada, no la política de reenvío

Los cortafuegos evalúan reglas en la interfaz donde llega el paquete. En pfSense y OPNsense, la pestaña de interfaz y el orden de las reglas deciden si se permite el tráfico hacia los servicios propios del cortafuegos; una regla que deja salir a los clientes LAN a internet no es una regla que permita a un par del túnel abrir la interfaz web. En OpenWrt con firewall4, cada zona lleva una política de entrada, option input 'ACCEPT' o 'REJECT', y una interfaz de túnel en una zona con entrada REJECT rechazará las conexiones de gestión mientras sigue reenviando tráfico si se permite el reenvío.

No desactives la regla anti-bloqueo para que funcione la nueva ruta. Esa regla evita que una regla mala bloquee el acceso a la dirección de gestión LAN; protege la subred LAN, no la subred del túnel que acabas de crear. Añade una regla estrecha para el origen del administrador y deja la red de seguridad en paz. La documentación de pfSense sobre el acceso de administración explica dónde viven esos controles.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Nivel tres: ¿hay algo escuchando en esa dirección?

Un servicio puede estar en marcha y aun así ser inalcanzable porque se ha ligado a una sola dirección. El uhttpd de OpenWrt mantiene entradas de escucha explícitas en /etc/config/uhttpd, por ejemplo list listen_http '0.0.0.0:80'; una compilación que solo se liga a la dirección LAN no acepta nada en la dirección del túnel, y los productos que exponen un ajuste de interfaz de escucha se comportan igual. Los comandos de escucha de arriba responden a esto directamente.

Luego separa el rechazo del silencio. nc -vz 10.6.0.1 443 que devuelve una conexión rechazada significa que el paquete llegó al router y algo lo rechazó, ya sea un puerto cerrado o una regla explícita de rechazo. Quedarse colgado hasta el tiempo de espera significa que el paquete se descartó o nunca se enrutó. Esa distinción te dice qué nivel inspeccionar después, y cuesta cinco segundos.

Una interfaz VPN es una frontera, no una vía de recuperación

El cifrado protege el cable; no dice nada sobre quién puede abrir la página de administración. Una vez que el túnel funciona, resiste el impulso de resolver el acceso permitiendo todo en la interfaz del túnel. Da a los administradores una regla ligada a su propia dirección de túnel o un túnel separado solo para administradores, y mantén a los usuarios normales, el NAS, las cámaras y los portátiles de la familia lejos del puerto de gestión. Un par que necesita compartir archivos no debería estar a una regla del inicio de sesión del router.

El papel del router cambia la respuesta. Un router que termina el túnel puede aceptar legítimamente administradores desde él, mientras que un router que solo usa el túnel como salida a internet normalmente no debería. En ambos casos el permiso de subred no es el inicio de sesión, así que mantén activadas la autenticación de cuenta y la seguridad del transporte.

El movimiento compensatorio que hace la gente tras un bloqueo es peor: activar la administración por WAN o reenviar un puerto a la interfaz web. Eso convierte una interrupción breve en una exposición permanente, y la página de inicio de sesión queda entonces al alcance de cualquier escáner de internet. Prueba también el lado denegado, no solo el permitido, para que un par que no debería tener acceso de administración reciba un tiempo de espera o un rechazo en lugar de una petición de inicio de sesión.

Prueba también con una conexión nueva. Un cortafuegos con estado mantiene los flujos existentes en su tabla de estados, así que la sesión SSH que ya tienes abierta puede sobrevivir a un cambio que bloquea todas las conexiones nuevas. Así es como un bloqueo permanece invisible hasta el próximo reinicio o la próxima suspensión del portátil.

Prepara el camino de vuelta antes de tocar la política

Apunta cuatro cosas antes del primer cambio: cómo llegarás al dispositivo si el túnel muere, como una consola serie, una consola del proveedor o una máquina en la LAN; dónde se exporta la configuración actual; qué única regla o ruta vas a modificar; y cómo revertirás exactamente ese elemento. En OpenWrt, sysupgrade -b /tmp/backup.tar.gz captura la configuración, y las ediciones quedan pendientes hasta uci commit, lo que te da un deshacer barato si te das cuenta a tiempo. pfSense guarda un historial de configuración, y AutoConfigBackup solo ayuda si ya estaba activado. Si el router ejecuta un conjunto de reglas fail-closed, confirma que el camino de mantenimiento que planeaste no está dentro del tráfico que bloquea esa regla, y recuerda que un reinicio vuelve a aplicar las reglas persistentes en lugar de borrarlas.

Cambia una frontera por intento y luego prueba desde una conexión nueva en vez de la shell que mantienes abierta. Si la prueba falla, revierte ese único cambio antes de tocar el siguiente nivel. El túnel puede quedarse arriba todo el tiempo, pero su icono verde de estado no es prueba de que aún puedas entrar.

Comprobación rápida antes de irte:

• ¿Puedes llegar al router desde un origen que no depende de la regla que acabas de editar?
• ¿La política de entrada en la interfaz del túnel permite solo el origen del administrador?
• ¿El servicio de gestión está ligado a una dirección que existe en el túnel?
• ¿Has probado un par denegado y una sesión nueva?
• ¿La superficie de administración por WAN sigue cerrada?