Por que a administración do router deixa de responder tras un cambio de VPN

Cambiaches unha ruta ou unha regra de cortalumes para probar un túnel no router, e agora a páxina de administración non responde desde o portátil que funcionaba ben hai dez minutos. O reflexo é culpar a VPN. A maioría das veces o túnel está san e rompeu unha de tres outras cousas: non hai ruta de volta ao enderezo propio do router, unha política de entrada descarta a petición, ou un servizo web non escoita no enderezo ao que chamas. As tres ven igual no navegador, por iso a xente reinicia o túnel durante unha hora e non aprende nada.

Velaquí o mito que paga a pena matar primeiro: un túnel que funciona non é unha vía para volver entrar. É unha nova conexión de rede coas súas propias preguntas de confianza, e pode eliminar en silencio o teu antigo camiño de xestión mentres abre un novo que ninguén revisou.

O túnel nunca foi o camiño de administración

O reenvío e a entrada son traballos distintos. «Pode un cliente chegar ao NAS a través do túnel?» é unha pregunta de reenvío sobre paquetes que pasan polo router. «Podo abrir o porto SSH do router?» é unha pregunta de entrada sobre paquetes dirixidos ao propio router. Unha regra de paso escrita para tráfico reenviado non fai nada pola segunda, e esa é a razón máis común pola que un túnel que transporta tráfico perfectamente segue rexeitando a túa sesión de administración.

O erro contrario é confiar nun nome de interface. Un túnel cifrase cara ao par, non cara a cada servizo que hai detrás, e a palabra VPN nunha etiqueta de interface non di nada sobre que orixes deberían poder iniciar sesión.

Nivel un: hai unha ruta ao enderezo propio do router?

Comeza no cliente e pregunta ao núcleo por onde irá o paquete. En Linux, ip route get 10.6.0.1 imprime a ruta escollida, a interface de saída e o enderezo de orixe. Se informa da ruta por defecto cara ao teu provedor, o paquete nunca entra no túnel, e ningunha regra do router pode salvalo.

O lado do túnel ten a súa propia versión da pregunta. WireGuard trata AllowedIPs como unha táboa de encamiñamento de claves criptográficas: en cada extremo declara que enderezos de orixe pode usar un par e que destinos se envían a ese par. Se a entrada do cliente non inclúe o enderezo de túnel do router, o cliente non ten ningunha ruta cara a ese enderezo. Se a entrada do servidor para ese cliente non cobre o enderezo de túnel do cliente, o servidor descarta o paquete antes de consultar ningunha regra de cortalumes.

Confirma o enderezo exacto que esperas alcanzar antes de depurar a política. Un rexistro DNS obsoleto ou unha entrada de veciño en caché de antes do cambio lévanche a un enderezo que o router nunca posuíu.

Nivel dous: a política de entrada, non a política de reenvío

Os cortalumes avalían regras na interface onde chega o paquete. En pfSense e OPNsense, a lapela de interface e a orde das regras deciden se se permite o tráfico cara aos servizos propios do cortalumes; unha regra que deixa saír os clientes LAN a internet non é unha regra que permita a un par do túnel abrir a interface web. En OpenWrt con firewall4, cada zona leva unha política de entrada, option input 'ACCEPT' ou 'REJECT', e unha interface de túnel nunha zona con entrada REJECT rexeitará as conexións de xestión mentres aínda reenvía tráfico se se permite o reenvío.

Non desactives a regra anti-bloqueo para que funcione o novo camiño. Esa regra evita que unha regra mala bloquee o acceso ao enderezo de xestión LAN; protexe a subrede LAN, non a subrede do túnel que acabas de crear. Engade unha regra estreita para a orixe do administrador e deixa a rede de seguridade en paz. A documentación de pfSense sobre o acceso de administración explica onde viven eses controis.

# 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: hai algo escoitando nese enderezo?

Un servizo pode estar en marcha e aínda así ser inalcanzable porque se ligou a un só enderezo. O uhttpd de OpenWrt mantén entradas de escoita explícitas en /etc/config/uhttpd, por exemplo list listen_http '0.0.0.0:80'; unha compilación que só se liga ao enderezo LAN non acepta nada no enderezo do túnel, e os produtos que expoñen un axuste de interface de escoita compórtanse igual. Os comandos de escoita de arriba responden a isto directamente.

Despois separa o rexeitamento do silencio. nc -vz 10.6.0.1 443 que devolve unha conexión rexeitada significa que o paquete chegou ao router e algo o rexeitou, xa sexa un porto pechado ou unha regra explícita de rexeitamento. Quedar colgado ata o tempo de espera significa que o paquete se descartou ou nunca se encamiñou. Esa distinción diche que nivel inspeccionar despois, e custa cinco segundos.

Unha interface VPN é unha fronteira, non unha vía de recuperación

O cifrado protexe o cable; non di nada sobre quen pode abrir a páxina de administración. Unha vez que o túnel funciona, resiste o impulso de resolver o acceso permitindo todo na interface do túnel. Dá aos administradores unha regra ligada ao seu propio enderezo de túnel ou un túnel separado só para administradores, e mantén os usuarios normais, o NAS, as cámaras e os portátiles da familia lonxe do porto de xestión. Un par que precisa compartir ficheiros non debería estar a unha regra do inicio de sesión do router.

O papel do router cambia a resposta. Un router que termina o túnel pode aceptar lexitimamente administradores desde el, mentres que un router que só usa o túnel como saída a internet normalmente non debería. En ambos os casos o permiso de subrede non é o inicio de sesión, así que mantén activadas a autenticación de conta e a seguridade do transporte.

O movemento compensatorio que fai a xente tras un bloqueo é peor: activar a administración por WAN ou reenviar un porto á interface web. Iso converte unha interrupción breve nunha exposición permanente, e a páxina de inicio de sesión queda entón ao alcance de calquera escáner de internet. Proba tamén o lado denegado, non só o permitido, para que un par que non debería ter acceso de administración reciba un tempo de espera ou un rexeitamento en lugar dunha petición de inicio de sesión.

Proba tamén cunha conexión nova. Un cortalumes con estado mantén os fluxos existentes na súa táboa de estados, así que a sesión SSH que xa tes aberta pode sobrevivir a un cambio que bloquea todas as conexións novas. Así é como un bloqueo permanece invisible ata o próximo reinicio ou a próxima suspensión do portátil.

Prepara o camiño de volta antes de tocar a política

Anota catro cousas antes do primeiro cambio: como chegarás ao dispositivo se o túnel morre, como unha consola serie, unha consola do provedor ou unha máquina na LAN; onde se exporta a configuración actual; que única regra ou ruta vas modificar; e como reverterás exactamente ese elemento. En OpenWrt, sysupgrade -b /tmp/backup.tar.gz captura a configuración, e as edicións quedan pendentes ata uci commit, o que che dá un desfacer barato se te decatas a tempo. pfSense garda un historial de configuración, e AutoConfigBackup só axuda se xa estaba activado. Se o router executa un conxunto de regras fail-closed, confirma que o camiño de mantemento que planificaches non está dentro do tráfico que bloquea esa regra, e lembra que un reinicio volve aplicar as regras persistentes en lugar de borralas.

Cambia unha fronteira por intento e despois proba desde unha conexión nova en vez da shell que mantés aberta. Se a proba falla, reverte ese único cambio antes de tocar o seguinte nivel. O túnel pode quedar arriba todo o tempo, pero a súa icona verde de estado non é proba de que aínda poidas entrar.

Comprobación rápida antes de marchar:

• Podes chegar ao router desde unha orixe que non depende da regra que acabas de editar?
• A política de entrada na interface do túnel permite só a orixe do administrador?
• O servizo de xestión está ligado a un enderezo que existe no túnel?
• Probaches un par denegado e unha sesión nova?
• A superficie de administración por WAN segue pechada?