Router in modalità client VPN: perché i dispositivi LAN scompaiono

Credere che la modalità client di per sé uccida l'accesso alla LAN porta le persone nel menu delle impostazioni sbagliato, e le cause reali sono di solito due. Il tunnel non rimuove il bridge LAN né impedisce ai client cablati e wireless di raggiungersi. Ciò che rompe l'accesso locale è una funzione di ispezione nel percorso di inoltro del router o un intervallo di indirizzi LAN che si è spostato quando lo ha fatto il firmware. Entrambi producono la stessa lamentela, e nessuno dei due si risolve reinstallando il profilo VPN.

Il mito e cosa cambia davvero la modalità client

La modalità client aggiunge un'interfaccia tunnel e una rotta predefinita che vi passa attraverso, poi inoltra il traffico LAN in quel tunnel. Il bridge tra le porte cablate e le radio wireless resta intatto, così come la commutazione locale. Ciò che cambia è la politica: quale traffico viene inoltrato, dove viene tradotto e quale resolver ricevono i client.

Questa distinzione conta perché una LAN rotta di solito significa che una di quelle tre politiche è cambiata, non che il router abbia smesso di essere uno switch. Un router che risponde ancora alla propria pagina di amministrazione è la prova che l'interfaccia LAN è viva. Un router che non risponde a nulla ha un altro problema, come un indirizzo LAN cambiato o un client sulla sottorete sbagliata.

Quindi la prima mossa utile è scoprire quale strato si è rotto, non cambiare quello che sospetti.

Prova tre obiettivi prima di toccare un'impostazione

Da un client cablato, prova tre obiettivi separatamente e annota ogni risultato: l'indirizzo LAN del router stesso, un altro dispositivo sullo stesso switch per IP e qualcosa raggiungibile solo tramite il tunnel. Fallo in quest'ordine, perché ogni risultato esclude uno strato diverso. Usa gli indirizzi invece dei nomi al primo passaggio, perché un errore di nome mescola il DNS a una questione di connettività.

Il modello delle risposte è la diagnosi. Un router che risponde mentre i dispositivi locali non lo fanno indica la commutazione locale o una funzione di filtraggio, non l'instradamento. I dispositivi locali che rispondono mentre il lato tunnel non lo fa indicano la rotta del tunnel o il firewall remoto. Tutto risponde per indirizzo mentre i nomi falliscono è una questione di resolver, e nessuna modifica delle rotte lo risolverà.

Tieni la tabella accanto ai risultati dei test. Trasforma una lamentela vaga in una riga su cui puoi agire.

Lo strato di sicurezza dentro il percorso di inoltro

I router consumer includono sempre più spesso una funzione di ispezione che sorveglia il traffico inoltrato, e questa gira nello stesso percorso che trasporta i pacchetti dalla LAN al tunnel. Quando quell'ispezione non riesce a classificare il traffico del tunnel, l'inoltro può bloccarsi mentre il tunnel stesso resta attivo e il router segnala una connessione sana. Niente nel registro VPN lo mostra, perché la VPN si è effettivamente connessa.

La diagnosi è un esperimento controllato, non una modifica permanente. Annota l'impostazione attuale, disattiva la funzione per la durata di un test, riattiva il tunnel e prova un singolo host locale per indirizzo. L'inoltro che ritorna è la prova che ti serviva, e il compromesso diventa allora una decisione invece di una supposizione. Se non cambia nulla, riattivala subito e passa alla causa degli indirizzi.

Lasciare disattivata una funzione di sicurezza a pagamento perché il tunnel continui a funzionare è un compromesso da fare deliberatamente e da annotare. Vale anche la pena chiedersi se il tunnel appartenga a un altro dispositivo, perché un router che deve ispezionare tutto e un router che deve inoltrare tutto sono due lavori diversi.

La seconda causa: l'intervallo LAN si è spostato

Gli aggiornamenti del firmware riportano regolarmente l'indirizzo LAN al valore predefinito del produttore, e alcuni router hanno un interruttore di modalità esplicito che decide se la LAN mantiene un intervallo privato o ne eredita uno dal dispositivo a monte. Un client che si aspetta 192.168.8.x può finire su 10.64.0.x, e allora una sessione SSH verso un host scade anche se il tunnel è perfettamente sano.

ipconfig /all
ip addr show
ip route get 192.168.8.20

Leggi il prefisso e il gateway dal lease prima di aprire la pagina del router. I primi due comandi mostrano ciò che il client ha realmente ricevuto, e il terzo mostra quale interfaccia il client userebbe per un indirizzo locale, ed è così che una rotta residua o una sottorete obsoleta si rivelano. Poi confrontalo con la pagina LAN e la modalità in cui si trova il router.

Se l'intervallo non può tornare, aggiorna ogni oggetto che lo nomina: prenotazioni DHCP, qualsiasi rotta statica verso la vecchia sottorete e ogni regola del firewall che porta il prefisso precedente. Un intervallo che collide con la sottorete remota del tunnel è la variante peggiore, perché i dispositivi locali restano raggiungibili mentre le destinazioni remote vengono silenziosamente instradate male verso la LAN.

Riconnetti e ripeti i test in ordine di pacchetto

Dopo uno dei due cambiamenti, riconnetti il tunnel e ripeti i test in ordine di pacchetto: router, host locale, host remoto, poi nomi, poi l'applicazione. Testare l'applicazione per prima nasconde quale strato è ancora rotto, e un nuovo tentativo del browser su un nome in cache può sembrare un errore di instradamento.

Annota la versione del firmware, il prefisso LAN e lo stato della funzione di ispezione accanto al profilo VPN. Tutti e tre sono configurazione che il prossimo aggiornamento può sovrascrivere, e due righe di note risparmiano l'ora appena trascorsa.