Perché l'amministrazione del router smette di rispondere dopo un cambio VPN

Hai modificato una rotta o una regola del firewall per provare un tunnel sul router, e ora la pagina di amministrazione non risponde più dal portatile che funzionava bene dieci minuti fa. Il riflesso è dare la colpa alla VPN. Il più delle volte il tunnel è sano e si è rotto uno di altri tre elementi: nessuna rotta di ritorno all'indirizzo del router stesso, una policy d'ingresso che scarta la richiesta, oppure un servizio web che non ascolta sull'indirizzo che chiami. Tutti e tre sembrano identici nel browser, per questo le persone riavviano il tunnel per un'ora senza imparare nulla.

Ecco il mito che vale la pena uccidere per primo: un tunnel funzionante non è una via per rientrare. È un nuovo attacco di rete con le sue domande di fiducia, e può rimuovere in silenzio il vecchio percorso di gestione mentre ne apre uno nuovo che nessuno ha esaminato.

Il tunnel non è mai stato il percorso di gestione

Inoltro e ingresso sono lavori diversi. «Un client può raggiungere il NAS attraverso il tunnel?» è una domanda di inoltro sui pacchetti che attraversano il router. «Posso aprire la porta SSH del router?» è una domanda d'ingresso sui pacchetti indirizzati al router stesso. Una regola di passaggio scritta per il traffico inoltrato non fa nulla per la seconda, ed è il motivo più comune per cui un tunnel che trasporta traffico perfettamente rifiuta comunque la tua sessione di amministrazione.

L'errore opposto è fidarsi del nome di un'interfaccia. Un tunnel è cifrato verso il peer, non verso ogni servizio dietro di esso, e la parola VPN in un'etichetta di interfaccia non dice nulla su quali origini dovrebbero poter accedere.

Primo livello: esiste una rotta verso l'indirizzo del router stesso?

Parti dal client e chiedi al kernel dove andrà il pacchetto. Su Linux, ip route get 10.6.0.1 stampa la rotta scelta, l'interfaccia di uscita e l'indirizzo di origine. Se riporta la rotta predefinita verso il tuo provider, il pacchetto non entra mai nel tunnel, e nessuna regola sul router può salvarlo.

Il lato tunnel ha la sua versione della domanda. WireGuard tratta AllowedIPs come una tabella di routing a chiave crittografica: a ogni estremità dichiara quali indirizzi di origine un peer può usare e quali destinazioni vengono inviate a quel peer. Se la voce del client non include l'indirizzo del tunnel del router, il client non ha una rotta verso di esso. Se la voce del server per quel client non copre l'indirizzo del tunnel del client, il server scarta il pacchetto prima che venga consultata qualsiasi regola del firewall.

Conferma l'indirizzo esatto che ti aspetti di raggiungere prima di fare debug della policy. Un record DNS obsoleto o una voce di vicino in cache precedente al cambio ti portano a un indirizzo che il router non ha mai posseduto.

Secondo livello: la policy d'ingresso, non quella di inoltro

I firewall valutano le regole sull'interfaccia su cui arriva il pacchetto. Su pfSense e OPNsense la scheda dell'interfaccia e l'ordine delle regole decidono se il traffico verso i servizi del firewall stesso è consentito; una regola che lascia uscire i client LAN su internet non è una regola che permette a un peer del tunnel di aprire l'interfaccia web. Su OpenWrt con firewall4 ogni zona porta una policy d'ingresso, option input 'ACCEPT' o 'REJECT', e un'interfaccia tunnel in una zona con ingresso REJECT rifiuterà le connessioni di gestione continuando però a inoltrare traffico se l'inoltro è consentito.

Non disattivare la regola anti-lockout per far funzionare il nuovo percorso. Quella regola impedisce a una regola sbagliata di bloccare l'indirizzo di gestione LAN; protegge la sottorete LAN, non la sottorete del tunnel che hai appena creato. Aggiungi una regola stretta per l'origine dell'amministratore e lascia in pace la rete di sicurezza. La documentazione di pfSense sull'accesso amministrativo spiega dove si trovano quei controlli.

# 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

Terzo livello: c'è qualcosa in ascolto su quell'indirizzo?

Un servizio può essere attivo e comunque irraggiungibile perché si è legato a un solo indirizzo. L'uhttpd di OpenWrt mantiene voci di ascolto esplicite in /etc/config/uhttpd, per esempio list listen_http '0.0.0.0:80'; una build che si lega solo all'indirizzo LAN non accetta nulla sull'indirizzo del tunnel, e i prodotti che espongono un'impostazione di interfaccia di ascolto si comportano allo stesso modo. I comandi di ascolto qui sopra rispondono direttamente a questo.

Poi separa il rifiuto dal silenzio. nc -vz 10.6.0.1 443 che restituisce una connessione rifiutata significa che il pacchetto ha raggiunto il router e qualcosa lo ha respinto, o una porta chiusa o una regola di rifiuto esplicita. Un blocco fino al timeout significa che il pacchetto è stato scartato o non è mai stato instradato. Questa distinzione ti dice quale livello ispezionare dopo, e costa cinque secondi.

Un'interfaccia VPN è un confine, non un percorso di ripristino

La cifratura protegge il cavo; non dice nulla su chi può aprire la pagina di amministrazione. Una volta che il tunnel funziona, resisti all'impulso di risolvere la raggiungibilità permettendo tutto sull'interfaccia del tunnel. Dai agli amministratori una regola legata al loro indirizzo di tunnel o un tunnel separato riservato agli amministratori, e tieni gli utenti normali, il NAS, le telecamere e i portatili di famiglia lontani dalla porta di gestione. Un peer che ha bisogno di condividere file non dovrebbe essere a una regola dal login del router.

Il ruolo del router cambia la risposta. Un router che termina il tunnel può legittimamente accettare amministratori da esso, mentre un router che usa il tunnel solo come uscita internet di solito non dovrebbe. In entrambi i casi il permesso di sottorete non è il login, quindi tieni attivi l'autenticazione dell'account e la sicurezza del trasporto.

La mossa compensativa che le persone fanno dopo un blocco è peggiore: abilitare l'amministrazione da WAN o inoltrare una porta all'interfaccia web. Questo trasforma un'interruzione breve in un'esposizione permanente, e la pagina di login diventa raggiungibile da ogni scanner su internet. Prova anche il lato negato, non solo quello consentito, così un peer che non dovrebbe avere accesso amministrativo va in timeout o viene rifiutato invece di ricevere una richiesta di login.

Prova anche con una connessione nuova. Un firewall con stato mantiene i flussi esistenti nella sua tabella degli stati, quindi la sessione SSH che hai già aperta può sopravvivere a un cambio che blocca ogni nuova connessione. È così che un blocco resta invisibile fino al prossimo riavvio o alla prossima sospensione del portatile.

Prepara la via di ritorno prima di toccare la policy

Annota quattro cose prima del primo cambiamento: come raggiungerai il dispositivo se il tunnel muore, ad esempio una console seriale, una console del provider o una macchina in LAN; dove viene esportata la configurazione attuale; quale singola regola o rotta stai per modificare; e come ripristinerai esattamente quell'elemento. Su OpenWrt, sysupgrade -b /tmp/backup.tar.gz cattura la configurazione, e le modifiche restano in sospeso fino a uci commit, il che ti dà un annullamento a basso costo se te ne accorgi in tempo. pfSense tiene uno storico delle configurazioni, e AutoConfigBackup aiuta solo se era già attivo. Se il router esegue un set di regole fail-closed, verifica che il percorso di manutenzione previsto non sia dentro il traffico bloccato da quella regola, e ricorda che un riavvio riapplica le regole persistenti invece di cancellarle.

Cambia un confine per tentativo, poi prova da una connessione nuova invece che dalla shell che tieni aperta. Se il test fallisce, annulla quell'unico cambio prima di toccare il livello successivo. Il tunnel può restare attivo per tutto il tempo, ma la sua icona di stato verde non è prova che riesci ancora a entrare.

Controllo rapido prima di andartene:

• Riesci a raggiungere il router da un'origine che non dipende dalla regola appena modificata?
• La policy d'ingresso sull'interfaccia del tunnel consente solo l'origine dell'amministratore?
• Il servizio di gestione è legato a un indirizzo che esiste sul tunnel?
• Hai provato un peer negato e una sessione nuova?
• La superficie di amministrazione via WAN è ancora chiusa?