Errore generale durante il ping di un indirizzo LAN con il client VPN attivo
Windows dice di non riuscire a raggiungere alcun adattatore mentre la tabella di routing sembra corretta. Stabilite se il blocco è di routing, di filtro o del client.
Una rotta verso un host, un indirizzo, e il ping fallisce subito con General failure invece di lasciare che la richiesta vada in timeout. Questa distinzione è tutta la diagnosi. Un timeout significa che il pacchetto è uscito e che qualcosa lo ha ignorato. Errore generale significa che Windows non è riuscito a consegnare il pacchetto a nessuna interfaccia fin dall'inizio.
Quindi, quando la tabella di routing sembra perfetta e l'errore è ancora Errore generale, il blocco avviene sotto la decisione di routing, e il client del fornitore è ciò che opera lì.
Leggete l'errore prima della tabella di routing
Windows restituisce quell'errore quando non trova un'interfaccia su cui inviare, e non dice nulla su cosa avrebbe fatto la destinazione con il pacchetto. Raggiungibilità, firewall dall'altra parte e disponibilità del servizio sono tutte domande a valle a cui non siete ancora arrivati.
La configurazione classica per questo caso è una rotta verso un host che punta un singolo indirizzo LAN al gateway fisico perché aggiri il tunnel. route add la accetta, route print la mostra, e il ping fallisce comunque, perché il driver di filtro ha già deciso che il pacchetto non può uscire.
Prima di accettare questa spiegazione, confermate che la rotta venga davvero selezionata: controllate l'indice dell'interfaccia e la metrica, e assicuratevi che la voce non sia obsoleta dopo una riconnessione. Una rotta che punta a un'interfaccia che non esiste più produce un errore simile per un motivo molto meno interessante.
Tre livelli, tre proprietari diversi
Vince il livello che gira per ultimo, e questi tre non sono nell'ordine che la maggior parte delle persone presume.
| Layer | What it decides |
|---|---|
| Routing table | Which interface and next hop should carry the packet |
| Client filter driver | Whether this packet is permitted to leave outside the tunnel at all |
| Client feature | Whether a named feature, such as LAN blocking, is active right now |
Il livello intermedio è il motivo per cui una rotta può essere contemporaneamente corretta e inutile. I client dei fornitori installano un filtro e regole del firewall perché il traffico fuori dal tunnel venga scartato, ed è lo stesso meccanismo che implementa il loro interruttore di emergenza. Nulla nella tabella di routing partecipa a quella decisione.
Il terzo livello spiega un resoconto strano che arriva regolarmente: la sottorete locale è irraggiungibile anche dopo aver disconnesso il client. Il servizio è ancora in esecuzione e il filtro è ancora installato, quindi non essere connessi non è lo stesso che non filtrare. Uscite dal client invece di limitarvi a disconnetterlo prima di concludere qualcosa.
Cosa provare, in ordine
Iniziate rimuovendo le funzioni che costano poco da rimuovere e sono facili da ripristinare. L'individuazione LAN, talvolta chiamata invisibilità sulla LAN, blocca il traffico verso gli intervalli di indirizzi privati perché la macchina resti nascosta ai vicini. Stampanti, server di file locali e il router stesso svaniscono dietro quell'interruttore. Le funzioni di protezione dalle minacce che filtrano il DNS installano i propri ganci e si dice che rompano la raggiungibilità locale più o meno allo stesso modo.
Disattivatele entrambe, uscite completamente dal client, poi provate l'indirizzo. Questa sequenza separa una funzione che blocca il traffico da un tunnel che lo instrada male, e richiede due minuti invece di un pomeriggio di rotte statiche.
ping 192.168.1.50
tracert -d 192.168.1.50
route print -4Se l'indirizzo risponde una volta disattivate le funzioni, avete una decisione di policy e non un guasto: scegliete tra lasciare la funzione disattivata, aggiungere un'eccezione o accettare che la macchina resti invisibile sulla rete locale.
Usate l'eccezione del client, in modo stretto
Quando una funzione deve restare attiva, il tunnel diviso del client stesso è la via d'uscita supportata. Mantenete l'eccezione più piccola che il requisito consente, il che di solito significa un indirizzo host per un server o un prefisso per un solo segmento. Una regola che copre un intero intervallo privato è un buco permanente che nessuno ricorderà di aver aggiunto e che nessuno oserà togliere.
Poi verificate prima per indirizzo e poi per nome. Se l'indirizzo risponde con un primo hop sul gateway fisico, l'eccezione funziona. Se il nome fallisce ancora, siete passati al DNS, perché il resolver del tunnel non conosce la zona locale e nessuna modifica al routing gliela insegnerà.
Conservate la rotta o l'eccezione, non entrambe, più una nota su quale sta facendo il lavoro. Due meccanismi sovrapposti si nascondono a vicenda, e la prossima persona che farà debug di questa macchina ne rimuoverà uno e non vedrà alcun cambiamento.
Quando il client è l'ostacolo
Alcune build filtrano il traffico in modi che né una rotta statica né un'eccezione del client possono battere. Quando è questo il risultato, le opzioni oneste sono aspettare la funzione di aggiramento o collegarsi con un client OpenVPN semplice usando il profilo del fornitore stesso, come raccomandava la risposta dell'assistenza del produttore nel resoconto originale.
Capite lo scambio prima di fare quella sostituzione. Un profilo semplice si comporta come qualsiasi tunnel ordinario: installa le sue rotte e non ristruttura il resto dello stack, quindi una rotta host stretta si comporta ancora come vi aspettate. Ciò che perdete è tutto quello che il client di marca ha implementato attorno al tunnel, compresi l'interruttore di emergenza e il filtro DNS, e va riprodotto di proposito o accettato come assente.
Qualunque cosa scegliate, annotate quale livello possedeva il blocco. Un pacchetto che non ha mai lasciato la macchina è un risultato del filtro, e nessuna modifica al routing può riparare un filtro.