Il VPN blocca la LAN locale su Windows: route o policy del client?

Una stampante, un NAS o una macchina di sviluppo sulla propria scrivania smettono di rispondere nel momento in cui si connette il VPN di lavoro. A volte un comando route lo sistema in pochi secondi; a volte la stessa route è corretta e i pacchetti spariscono comunque, il che significa che si sta guardando un altro problema con un sintomo simile. La decisione si riduce a tre domande, e porle nell'ordine sbagliato è il motivo per cui le persone passano una serata intera a cancellare e riaggiungere route.

Tre domande prima di qualsiasi comando

Primo: esiste una voce per il prefisso locale, e punta all'adattatore fisico? Secondo: il client riceve dal gateway un permesso o un diniego per la rete locale al momento della connessione? Terzo: serve solo un accesso in uscita alla LAN, o qualcosa su internet deve raggiungere anche un servizio in esecuzione sulla vostra macchina?

La prima domanda separa un guasto di routing da un guasto di filtraggio. La seconda dice se una correzione di route è autorizzata a funzionare. La terza cambia la riparazione: una route corregge il traffico in uscita, mentre un servizio in entrata irraggiungibile è di solito un problema di binding del listener e di percorso di ritorno che una route peggiora.

Domanda uno: route, filtro o nome

Leggete la tabella prima di aggiungerci qualcosa. L'indice dell'interfaccia conta, perché ogni comando route qui sotto è ancorato a esso:

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

Una sottorete collegata direttamente di solito conserva una route on-link anche con il tunnel attivo, quindi una voce può esistere e il traffico può comunque fallire. Quella combinazione è la firma di un filtro che gira dopo il routing, ed è il caso in cui una seconda route più specifica non cambia assolutamente nulla.

Provate separatamente per indirizzo e per nome. Se ping 192.168.1.50 risponde e net view 192.168.1.50 no, la tabella di routing non è mai stata il problema: il tunnel ha cambiato il resolver e il nome locale non si risolve più. Aggiungere una route per questo è lavoro sprecato.

Domanda due: il gateway consente l'accesso alla LAN locale?

Un client commerciale installa più che route. Riceve una policy al momento della connessione, e quella policy può includere un permesso esplicito per la rete locale. Nelle installazioni Cisco IPsec la policy di gruppo porta l'impostazione di split tunneling e un flag separato per l'accesso alla LAN locale; la casella di controllo nel client è una richiesta che il gateway può rifiutare. In AnyConnect il profilo controlla gli elenchi di inclusione ed esclusione dello split e lo stesso permesso. Su Windows RRAS gli equivalenti sono l'opzione gateway predefinito nel profilo più le route statiche assegnate dal server.

Quando il flag è disattivato, il comportamento documentato è che il client blocca il traffico verso la sottorete collegata direttamente anche se esiste una route valida e più specifica. È anche per questo che le route non possedute dal client possono sparire secondi dopo averle aggiunte: il client sta ricostruendo lo stato che gli è stato detto di costruire, non sta combattendo contro di voi.

Il log del client registra la decisione al momento della connessione, e leggerlo è più veloce di qualsiasi esperimento sulla macchina. Se il log dice che l'accesso locale è bloccato, fermatevi: nessuna correzione da riga di comando sopravvive a questo, e restano solo un cambio di policy, il raggiungimento della risorsa attraverso il tunnel, o il confinamento del client in una macchina virtuale lasciando l'host sulla rete locale.

Domanda tre: quale direzione vi serve?

Il traffico in uscita verso un dispositivo vicino è una questione di routing. Puntate il prefisso della LAN al gateway locale con una metrica abbastanza bassa da battere la route predefinita del tunnel:

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

La seconda forma fissa un solo dispositivo, che è ciò che volete quando un indirizzo è tutto il requisito. L'equivalente netsh registra la stessa decisione per nome dell'interfaccia invece che per indice:

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

I comandi route falliscono con Il parametro non è corretto quando indirizzo e maschera non concordano, per esempio un indirizzo host con maschera /24. Usate l'indirizzo di rete per una route di sottorete e una maschera host per un singolo host.

L'entrante è diverso. Un server VNC o SSH sulla stessa macchina diventa irraggiungibile quando le risposte a una connessione in entrata escono dal gateway VPN e non tornano mai. Controllate su cosa ascolta il servizio prima di toccare le route:

netstat -ano | findstr :5900

Un listener legato a un indirizzo specifico non risponderà sull'altra interfaccia. Legarlo a tutte le interfacce è una decisione deliberata, presa insieme a una regola del firewall limitata alla rete di cui vi fidate. Solo dopo la riparazione della route ripristina il percorso di ritorno.

Applicate il cambiamento più piccolo che corrisponde

L'altra mossa comune è deselezionare «Usa gateway predefinito sulla rete remota» nelle proprietà avanzate di IPv4. Mantiene locale il traffico internet, ma fa due cose insieme: il VPN smette di essere il percorso predefinito, e il client smette di ricevere route per la rete remota, incluso multicast. Deselezionatelo e la LAN remota sparisce, a meno che il server non spinga i prefissi remoti specifici che ogni client richiede.

Quell'asimmetria decide l'ordine del lavoro. Se il lato remoto deve restare pienamente raggiungibile, spingete le sottoreti remote dal server e lasciate in pace la predefinita locale. Se non potete cambiare il server, aggiungete una route persistente al prefisso remoto attraverso l'indirizzo assegnato dal tunnel, e verificate con route print che il prefisso punti all'interfaccia VPN mentre la predefinita punta ancora al gateway fisico.

Poi confermate che la riparazione sopravvive a una riconnessione, perché le route non persistenti muoiono con l'adattatore e uno script che gira dopo ogni connessione è il posto onesto per loro. Provate un dispositivo locale e una risorsa remota nella stessa sessione, disconnettete, riconnettete e provate di nuovo. Se il dispositivo locale continua a fallire mentre la route sembra corretta, tornate alla domanda due: il client sta filtrando, e la risposta è un cambio di policy e non una seconda route concorrente.