Il VPN si connette ma non raggiunge i dispositivi della LAN: cosa controllare

Il traffico entra nel tunnel, il gateway risponde sul proprio indirizzo e nulla dietro di esso risponde. Questo schema è comune e non è una contraddizione: una risposta dal gateway dimostra che il tunnel è terminato, e non dimostra nulla su ciò che accade a un pacchetto indirizzato oltre. I due test esercitano percorsi di codice diversi sulla stessa macchina.

Da ora in poi prova qualcosa dall’altra parte del gateway. L’indirizzo del gateway continuerà a rispondere, per quanto rotto sia l’inoltro.

Il gateway risponde dal proprio stack

Un pacchetto indirizzato al gateway viene consegnato al suo percorso di input locale, dove il kernel decide se un socket in ascolto lo accetta. Un pacchetto indirizzato a un host dietro il gateway viene invece consegnato al percorso di inoltro, dove si applica un altro insieme di controlli. L’inoltro può essere completamente disattivato, oppure attivato dal kernel e poi rifiutato da una regola di filtro che non menziona mai il tunnel. Nulla di tutto ciò influisce sulla risposta del gateway stesso, ed è per questo che il sintomo inganna con tanta affidabilità.

Anche le pagine di amministrazione raggiunte attraverso il tunnel appartengono alla prima categoria. Sono prove sul tunnel, non sulla rete dietro di esso.

Segui il flusso fino al primo confine che lo scarta

Parti dal client e conferma la rotta e l’indirizzo di origine che il flusso userà. Poi osserva il gateway per l’arrivo di quello esatto flusso, e di nuovo per lo stesso flusso in uscita verso la LAN. Se non arriva mai, il problema è sul lato client o nei prefissi consentiti del tunnel. Se arriva e non esce mai, il problema è nell’inoltro o in un filtro del percorso in avanti, e la cattura ha già detto quale dei due.

Eseguire lo stesso test dal gateway nasconde la metà interessante, perché un pacchetto originato dal gateway ha un’altra origine e un altro requisito di ritorno. Usa il flusso del client, con il suo indirizzo di origine, a ogni passo. Una cattura presa sull’interfaccia sbagliata produce assurdità con molta sicurezza.

Le rotte di ritorno e i firewall degli host falliscono separatamente

Una volta che il pacchetto raggiunge l’host, devono valere altre tre cose. Il servizio deve essere in ascolto sull’indirizzo a cui è stato inviato il pacchetto, il firewall dell’host deve accettarlo, e la risposta deve avere una rotta di ritorno verso il pool di client. Quest’ultima fallisce spesso, perché la rotta predefinita dell’host punta a un router che non ha mai sentito parlare dell’intervallo del tunnel. Il risultato è una connessione che si stabilisce dal punto di vista dell’host e muore in silenzio nell’altra direzione.

Prova deliberatamente il percorso di ritorno inviando dal client e osservando il ritorno. Una cattura unidirezionale risolve in secondi ciò che un’ora di speculazione non risolverà.

Conferma ogni salto con l’indirizzo di origine del client

Esegui i controlli in ordine e conserva ogni output, perché il valore sta nel confronto e non in una singola riga. I comandi qui sotto fissano l’indirizzo di origine, mostrano la rotta scelta e catturano entrambi i lati dell’inoltro. Sostituisci il tuo host LAN e la tua interfaccia del tunnel.

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

La query di rotta mostra se il client invierebbe persino quel pacchetto nel tunnel, e il ping mostra se è tornato qualcosa dall’host. Confrontare le due catture separa l’arrivo dall’uscita, poiché un frame sull’interfaccia del tunnel senza controparte sull’interfaccia LAN è una decisione di inoltro e non un guasto del servizio. Quando entrambe le catture mostrano la richiesta e solo una mostra la risposta, la rotta di ritorno è il sospetto rimasto.

Annota quale indirizzo ha risposto e quale destinazione inoltrata ha fallito. Quella frase rende il rapporto attuabile invece di un’affermazione che il server è irraggiungibile.