Rete locale irraggiungibile con la VPN connessa? Quattro controlli

Il tunnel si alza, l’intranet appare e la stampante smette di rispondere. Nulla sulla LAN si è guastato; il client ha cambiato il percorso che usa per gli indirizzi che non considera più locali. Esegui i quattro controlli qui sotto in ordine e fermati quando uno produce una discrepanza concreta, perché lo stesso sintomo ha quattro cause comuni e solo una di esse si risolve modificando la VPN.

Primo: guarda la tabella di routing installata dal client

Apri la tabella di routing del client mentre la VPN è connessa. Su Linux usa ip route, su Windows usa route print o Get-NetRoute, e su macOS usa netstat -rn. Stai cercando una default attraverso il tunnel e che cosa è successo alla default fisica.

Un client full-tunnel aggiunge spesso due rotte semi-default, 0.0.0.0/1 e 128.0.0.0/1, invece di sostituire 0.0.0.0/0. La default originale resta visibile ma perde ogni lookup, ed è per questo che la tabella può sembrare intatta mentre tutto il traffico fuori dalla subnet si sposta. Se il client VPN offre un’opzione split tunnel e la policy lo consente, quella è la riparazione più pulita.

Se il tunnel deve restare la default, fissa invece la subnet locale. Su Linux la rotta nomina l’interfaccia fisica e il gateway; su Windows aggiungi -p per renderla persistente e leggi il numero di interfaccia da route print invece di indovinarlo:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

Una rotta fissata regge solo finché l’indirizzo che nomina resta lo stesso. Un portatile che rinumera la scheda Wi-Fi a ogni connessione infrangerà di nuovo la regola, quindi controlla l’indirizzo dell’interfaccia prima di concludere che la correzione è fallita.

Secondo: conferma che l’indirizzo fosse locale fin dall’inizio

Se la destinazione si trova dentro la subnet connessa, la default del tunnel non si applica mai e la VPN non è la causa. Una stampante a 192.168.1.40 su un client con 192.168.1.0/24 usa la rotta connessa; se quell’indirizzo fallisce, guarda al dispositivo, allo switch o al firewall del client invece che alla VPN.

Il caso che inganna è un indirizzo pubblico per un server locale. Dall’interno della LAN, raggiungere l’indirizzo WAN del router e tornare indietro richiede hairpin NAT, e molti router semplicemente non lo implementano per i port forward. Prova l’indirizzo privato accanto a quello pubblico. Se il privato funziona e il pubblico no, la VPN ha solo messo in luce un limite NAT che c’era già.

Un nome host peggiora le cose. Se il nome locale ora risolve all’indirizzo pubblico, il client continuerà a provare il percorso che non può tornare indietro. Usa l’indirizzo privato per il test, poi correggi il nome invece di aggiungere un altro port forward.

Terzo: guarda chi risponde ai nomi adesso

Un resolver aziendale conosce l’intranet e di solito non sa nulla di un nome host NAS, del nome Bonjour di una stampante o di un alias locale del router. Quando la VPN spinge i suoi server DNS, quei nomi smettono di risolvere anche se i loro indirizzi sono ancora raggiungibili. Interroga il nome direttamente e confronta la risposta con l’indirizzo che sai essere del dispositivo.

Su Linux, resolvectl query nas.local mostra quale resolver ha risposto. Su Windows, nslookup nas.local nomina il server, e ipconfig /all mostra l’ordine dei resolver. Se il suffisso locale ora è gestito dal resolver aziendale, riporta quel suffisso al resolver locale oppure usa l’indirizzo IP per il dispositivo.

La scoperta è un livello separato. mDNS e broadcast non attraversano un tunnel instradato, quindi un dispositivo può essere raggiungibile per indirizzo mentre il suo nome resta invisibile. Un reflector o una voce DNS locale risolvono il problema; una rotta no.

Quarto: verifica se anche l’altra macchina è su una VPN

Quando la macchina che vuoi raggiungere esegue a sua volta un client VPN, la tua sessione può arrivare mentre la sua risposta esce dall’altro tunnel. Ne nasce una connessione che si stabilisce e poi si blocca, oppure un tentativo RDP e SSH che va in timeout senza errori dalla tua parte. Controlla la tabella di routing dell’altro host e il suo percorso di default prima di dare la colpa al tuo client.

Controlla anche l’indirizzo su cui il servizio ascolta. Un listener legato solo all’indirizzo del tunnel accetta connessioni dalla VPN e le rifiuta dalla LAN, anche quando il routing è perfetto. È una configurazione del servizio, non un percorso di rete, ed è comune sulle interfacce di gestione chiuse all’indirizzo VPN.

Mantieni un percorso di gestione che non dipenda dal tunnel: una rotta statica che nomina la tua rete di origine, un’altra interfaccia collegata alla LAN, o una console che aggira del tutto il tunnel. Progettare quel percorso dopo che la sessione cade è molto più difficile che aggiungerlo prima della prossima connessione.

Applica la correzione che corrisponde al controllo fallito

Se la tabella di routing ha mostrato una cattura semi-default, scegli lo split tunnel quando la policy lo permette e una rotta locale fissata quando non lo permette. Se l’indirizzo si è rivelato pubblico, passa il test e il nome all’indirizzo privato. Se il resolver è cambiato di mano, limita il suffisso locale o usa l’indirizzo. Se l’altro host è in tunnel, correggi il suo percorso di ritorno o il binding del listener.

Cambia una cosa, poi ripeti lo stesso controllo. Una rotta aggiunta per la subnet sbagliata, un suffisso del resolver con un refuso e una rotta fissata su un’interfaccia che rinumera sembrano tutti il guasto originale. La ripetizione è ciò che distingue una correzione da una coincidenza.

Annota la rotta, l’indirizzo e il resolver che funzionavano mentre la VPN era connessa. La prossima riconnessione cambierà almeno uno di essi, e la nota trasforma il prossimo disservizio in un breve confronto invece che in una nuova indagine.