Raggiungere la pagina di amministrazione del router via VPN, non via WAN

La pagina di amministrazione del router si apre in due secondi dal divano e va in timeout da una camera d’albergo, mentre il client VPN segnala di essere connesso per tutto il tempo. Quello che hai è una via d’uscita, non una via di ritorno: il tunnel porta il tuo traffico su internet e si ferma lì. Per raggiungere un dispositivo dentro la tua LAN serve una sessione che termini su qualcosa con una rotta verso di essa. È una decisione di progettazione, non un’impostazione, e determina se il resto del lavoro è possibile.

La distinzione si perde facilmente perché un solo prodotto può svolgere entrambi i compiti. Un client di uscita commerciale e un server di accesso remoto possono parlare lo stesso protocollo sulla stessa porta, e la differenza è quale lato possiede lo spazio di indirizzamento dietro l’endpoint.

Quale lato del tunnel possiede la LAN

Per l’amministrazione l’endpoint deve trovarsi dentro la rete che vuoi raggiungere, o avere un percorso autorizzato al suo interno. Un router che esegue il proprio server VPN soddisfa il requisito; anche un piccolo host sempre acceso con indirizzo fisso e una rotta verso la LAN. Un servizio di uscita gestito da terzi non lo soddisfa, perché il suo endpoint non ha alcuna interfaccia sulla tua LAN né una regola che ne consentirebbe la comparsa. È il controllo da completare prima di toccare qualsiasi altra cosa.

Il firmware raramente etichetta questa differenza, quindi leggi cosa fa la funzione e non quale protocollo nomina. WireGuard, OpenVPN e IKEv2 compaiono su entrambi i lati del mercato: una build invia il traffico domestico verso l’esterno, un’altra accetta il tuo dispositivo remoto. Una build solo client non può essere trasformata in server tramite configurazione, comunque sia formulato il menu.

Far esistere la rotta di ritorno

Un server WireGuard sul router ha un indirizzo di interfaccia come 10.8.0.1/24 e una voce di peer per il portatile. Il client decide quali destinazioni inviare nel tunnel, e un elenco che contiene solo la sottorete del tunnel lascia la LAN invisibile, comunque sia configurato il server. Entrambe le estremità devono essere d’accordo, e di solito se ne modifica una sola.

wg show wg0 allowed-ips
ip route get 192.168.1.1

Il primo comando riporta ciò che ogni peer è autorizzato a inviare dal punto di vista del server; il secondo riporta dove andrebbe davvero un indirizzo della LAN sul client. Una destinazione della LAN che si risolve sull’interfaccia del tunnel è routing che funziona, e quella che esce dalla gateway fisica non arriverà mai, qualunque cosa dica il firewall. Aggiungi il prefisso della LAN all’elenco consentito del client e gli stessi due comandi diventano un passo di verifica invece di una diagnosi.

Lo stesso salto per i gateway IPsec è descritto dalla documentazione di inoltro di strongSwan, dove l’inoltro e una regola di NAT sorgente collegano un client del tunnel a un host interno. L’indirizzamento cambia; il requisito no.

Chi può aprire la pagina di amministrazione

Il controllo degli accessi appartiene al router, non all’intenzione di essere prudenti. Consenti solo l’identità del tunnel autenticata o l’intervallo di origine che necessita della pagina, e leggi la catena di input del router stesso oltre a qualsiasi criterio LAN inoltrato. Una regola che consente alla LAN cablata di raggiungere la pagina di amministrazione non dice nulla su un client che arriva sull’interfaccia del tunnel. Scrivi l’eccezione per un’identità specifica, poi mantieni una seconda identità che deve essere rifiutata.

L’ascoltatore è l’altra metà ed è invisibile nell’output del firewall. ss -ltnp mostra l’indirizzo a cui è legato il server web, e un servizio legato solo all’indirizzo della LAN non risponderà sull’indirizzo del tunnel, per quanto permissive siano le regole. Rilegarlo o aggiungere un indirizzo è una modifica di configurazione sul router, non una modifica del firewall.

Mantieni autenticazione e validazione del trasporto attive nello stesso passaggio. Raggiungibile non significa fidato, e ogni dispositivo dentro un tunnel non diventa per questo un amministratore. Le credenziali del tunnel e l’account del router sono privilegi separati con cicli di vita separati, così la chiave di un portatile smarrito può essere revocata senza reimpostare la password di ogni amministratore.

Testare dall’esterno, non dal divano

Prova da una rete che non controlli. Connettiti tramite il tunnel approvato, apri una nuova sessione di amministrazione e cambia qualcosa di innocuo che vedi riflesso nella pagina. Dal divano dimostri che la LAN funziona, cosa che non è mai stata in dubbio.

Poi prova i rifiuti con la stessa cura. Tenta la pagina senza il tunnel e conferma che fallisce, e conferma che il servizio di amministrazione non è in ascolto sull’indirizzo WAN. Una pagina semplicemente non collegata non è controllo degli accessi, e un ascoltatore sulla WAN che mostra un modulo di accesso è ancora un ascoltatore sulla WAN. Se una password è l’unica cosa tra internet e la console del router, la progettazione è una password.

I servizi domestici meritano uno sguardo mentre sei lì. Stringere le regole di gestione spesso rompe la rete degli ospiti o il resolver usato dai dispositivi di famiglia, e questo emerge giorni dopo come un reclamo non correlato.

Conservare una via di ritorno mentre cambi le cose

Prima di modificare rotte o impostazioni del tunnel da remoto, prepara una via di ritorno indipendente. Una sessione esistente può sopravvivere alla modifica che già blocca le nuove connessioni, ed è esattamente così che le persone si chiudono fuori mentre guardano una sessione che funziona ancora. Le opzioni sono concrete: un riavvio pianificato verso una configurazione nota, l’accesso da console o fisico, un secondo tunnel che non dipende dall’impostazione in modifica, o la gestione fuori banda dove l’hardware la offre. Scegline una e dimostrala prima della finestra di manutenzione, non durante.

Mantieni il registro breve e aggiornato: quale host termina il tunnel, quali identità possono raggiungere la pagina, a quale indirizzo si lega il servizio e come viene revocato un dispositivo smarrito. Quell’elenco vale anche come piano di ripristino, perché dice dove vive ogni dipendenza. Una rotta di ritorno mancante è un problema di routing da riparare, e non è mai un motivo per pubblicare l’amministrazione sulla WAN.