Per què l'accés d'administració del router deixa de respondre després d'un canvi de VPN

Heu canviat una ruta o una regla de tallafocs per provar un túnel al router, i ara la pàgina d'administració no respon des de l'ordinador portàtil que funcionava bé fa deu minuts. El reflex és culpar la VPN. La majoria de les vegades el túnel és sa i s'ha trencat una de tres altres coses: no hi ha ruta de tornada a l'adreça pròpia del router, una política d'entrada descarta la petició, o un servei web no està escoltant a l'adreça que truqueu. Les tres es veuen igual al navegador, i per això la gent reinicia el túnel durant una hora i no aprèn res.

Aquí teniu el mite que val la pena matar primer: un túnel que funciona no és una via per tornar a entrar. És un nou enllaç de xarxa amb les seves pròpies preguntes de confiança, i pot eliminar en silenci el vostre camí de gestió antic mentre n'obre un de nou que ningú no ha revisat.

El túnel mai no va ser el camí de gestió

El reenviament i l'entrada són feines diferents. "Pot un client arribar al NAS a través del túnel?" és una pregunta de reenviament sobre paquets que passen pel router. "Puc obrir el port SSH del router?" és una pregunta d'entrada sobre paquets adreçats al router mateix. Una regla de pas escrita per al trànsit reenviat no fa res per a la segona, i aquesta és la raó més habitual per la qual un túnel que porta trànsit perfectament encara refusa la vostra sessió d'administració.

L'error contrari és confiar en un nom d'interfície. Un túnel s'encripta amb el par, no amb cada servei que hi ha darrere, i la paraula VPN en una etiqueta d'interfície no diu res sobre quines fonts haurien de poder iniciar sessió.

Primer nivell: hi ha una ruta a l'adreça pròpia del router?

Comenceu al client i pregunteu al nucli on anirà el paquet. A Linux, ip route get 10.6.0.1 imprimeix la ruta triada, la interfície de sortida i l'adreça d'origen. Si informa de la ruta per defecte cap al vostre proveïdor, el paquet no entra mai al túnel, i cap regla del router no el pot salvar.

El costat del túnel té la seva pròpia versió de la pregunta. WireGuard tracta AllowedIPs com una taula d'encaminament de claus criptogràfiques: a cada extrem declara quines adreces d'origen pot fer servir un par i quins destins s'envien a aquell par. Si l'entrada del client no inclou l'adreça del túnel del router, el client no té cap ruta cap a ella. Si l'entrada del servidor per a aquell client no cobreix l'adreça del túnel del client, el servidor descarta el paquet abans que es consulti cap regla de tallafocs.

Confirmeu l'adreça exacta que espereu assolir abans de depurar la política. Un registre DNS obsolet o una entrada de veí en memòria cau d'abans del canvi us porta a una adreça que el router mai no va posseir.

Segon nivell: la política d'entrada, no la política de reenviament

Els tallafocs avaluen les regles a la interfície on arriba el paquet. A pfSense i OPNsense, la pestanya d'interfície i l'ordre de les regles decideixen si el trànsit cap als serveis propis del tallafocs està permès; una regla que deixa sortir els clients LAN a internet no és una regla que permeti a un par del túnel obrir la interfície web. A OpenWrt amb firewall4, cada zona porta una política d'entrada, option input 'ACCEPT' o 'REJECT', i una interfície de túnel en una zona amb entrada REJECT refusarà les connexions de gestió mentre encara reenvia trànsit si el reenviament està permès.

No desactiveu la regla anti-bloqueig per fer funcionar el camí nou. Aquesta regla evita que una regla dolenta bloquegi l'adreça de gestió LAN; protegeix la subxarxa LAN, no la subxarxa del túnel que acabeu de crear. Afegiu una regla estreta per a la font de l'administrador i deixeu la xarxa de seguretat tranquil·la. La documentació de pfSense sobre l'accés d'administració explica on viuen aquests controls.

# 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

Tercer nivell: hi ha res escoltant en aquesta adreça?

Un servei pot estar en marxa i tot i així ser inabastable perquè s'ha lligat a una adreça. L'uhttpd d'OpenWrt manté entrades d'escolta explícites a /etc/config/uhttpd, per exemple list listen_http '0.0.0.0:80'; una compilació que només s'enllaça a l'adreça LAN no accepta res a l'adreça del túnel, i els productes que exposen un paràmetre d'interfície d'escolta es comporten igual. Les ordres d'escolta de dalt responen això directament.

Després separeu el refús del silenci. nc -vz 10.6.0.1 443 que retorna una connexió refusada vol dir que el paquet va arribar al router i alguna cosa el va rebutjar, o bé un port tancat o bé una regla de rebuig explícita. Un penjament fins al temps d'espera vol dir que el paquet es va descartar o mai no es va encaminar. Aquesta distinció us diu quin nivell cal inspeccionar després, i costa cinc segons.

Una interfície VPN és una frontera, no un camí de recuperació

L'encriptació protegeix el cable; no diu res sobre qui pot obrir la pàgina d'administració. Un cop el túnel funciona, resistiu l'impuls de resoldre l'abastabilitat permetent-ho tot a la interfície del túnel. Doneu als administradors una regla lligada a la seva pròpia adreça de túnel o un túnel separat només per a administradors, i manteniu els usuaris normals, el NAS, les càmeres i els portàtils de la família lluny del port de gestió. Un par que necessita un recurs compartit no ha d'estar a una regla de distància de l'inici de sessió del router.

El paper del router canvia la resposta. Un router que acaba el túnel pot acceptar legítimament administradors des d'ell, mentre que un router que només fa servir el túnel com a sortida a internet normalment no hauria de fer-ho. En tots dos casos el permís de subxarxa no és l'inici de sessió, així que manteniu activades l'autenticació del compte i la seguretat del transport.

El moviment compensatori que fa la gent després d'un bloqueig és pitjor: activar l'administració per WAN o reenviar un port a la interfície web. Això converteix una interrupció curta en una exposició permanent, i la pàgina d'inici de sessió queda llavors a l'abast de qualsevol escàner d'internet. Proveu també el costat denegat, no només el costat permès, perquè un par que no hauria de tenir accés d'administració rebi un temps d'espera o un refús en lloc d'una petició d'inici de sessió.

Proveu també amb una connexió nova. Un tallafocs amb estat manté els fluxos existents a la seva taula d'estats, així que la sessió SSH que ja teniu oberta pot sobreviure a un canvi que bloqueja totes les connexions noves. Així és com un bloqueig resta invisible fins al proper reinici o la propera dormida de l'ordinador.

Prepareu el camí de tornada abans de tocar la política

Anoteu quatre coses abans del primer canvi: com arribareu al dispositiu si el túnel mor, com ara una consola sèrie, una consola del proveïdor o una màquina a la LAN; on s'exporta la configuració actual; quina única regla o ruta esteu a punt de modificar; i com revertireu exactament aquell element. A OpenWrt, sysupgrade -b /tmp/backup.tar.gz captura la configuració, i les edicions queden pendents fins a uci commit, cosa que us dona una desfer barata si us n'adoneu a temps. pfSense manté un historial de configuració, i AutoConfigBackup només ajuda si ja estava activat. Si el router fa servir un conjunt de regles fail-closed, confirmeu que el camí de manteniment que heu planificat no és dins del trànsit que aquesta regla bloqueja, i recordeu que un reinici torna a aplicar les regles persistents en lloc d'esborrar-les.

Canvieu una frontera per intent, i després proveu des d'una connexió nova en lloc de la shell que manteniu oberta. Si la prova falla, revertiu aquell únic canvi abans de tocar el nivell següent. El túnel pot quedar aixecat tot el temps, però la seva icona verda d'estat no és prova que encara hi pugueu entrar.

Comprovació ràpida abans de marxar:

• Podeu arribar al router des d'una font que no depèn de la regla que acabeu d'editar?
• La política d'entrada a la interfície del túnel només permet la font de l'administrador?
• El servei de gestió està lligat a una adreça que existeix al túnel?
• Heu provat un par denegat i una sessió nova?
• La superfície d'administració per WAN encara està tancada?