Connesso a OpenVPN ma non si carica nulla: un percorso dal client

La finestra del client dice Connected, l'indirizzo del tunnel c'è, e il browser continua a girare. Questa combinazione è normale, perché un handshake riuscito dimostra solo che il tunnel è stato costruito; non dice nulla se il server inoltrerà i tuoi pacchetti, ne riscriverà l'origine o risponderà alle tue query DNS. L'errore che fanno quasi tutti è aprire prima la configurazione del server. Lavora invece dal client verso l'esterno, perché ogni passo qui sotto ti dice se il successivo valga la pena di essere controllato.

Inizia dal client e lavora verso l'esterno

Esegui tre test in questo ordine e annota dove fallisce il primo. Fai ping all'indirizzo del tunnel del server, il che dimostra che il tunnel stesso trasporta traffico. Fai ping a un indirizzo pubblico per numero, il che dimostra inoltro e traduzione senza coinvolgere la risoluzione dei nomi. Poi prova a risolvere un nome host, che è l'unico test che usa il DNS. Ogni risultato elimina un intero strato dai sospetti.

Non saltare al terzo test perché il browser sembra più veloce. Un caricamento di pagina fallito copre tutti e tre gli strati insieme, ed è da lì che la gente inizia e poi ricostruisce un tunnel che funzionava. Una pagina che fallisce non ti dice quale dei tre si è rotto.

Due catture mostrano dove si fermano i pacchetti

Con un ping verso un indirizzo pubblico in corso dal client, fai una cattura sull'interfaccia del tunnel e una sul collegamento a monte che dovrebbe raggiungere internet. Eseguile insieme, così le marche temporali coincidono.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

Se le richieste compaiono sul tunnel e mai sul collegamento a monte, il server le ha scartate tra il tunnel e il cavo, e la causa è l'inoltro o la politica del firewall per l'inoltro, non il NAT. Se compaiono su entrambi, il server ha fatto la sua parte e la risposta manca più in là, il che punta alla traduzione, a un filtro a monte o a una restrizione del provider.

Prendi il nome del collegamento a monte dalla tabella di routing, non da un tutorial. Le immagini cloud e gli adattatori rinominati raramente corrispondono all'interfaccia di esempio di una guida, e una cattura fatta sul dispositivo sbagliato sembra esattamente un server che non inoltra:

ip -4 route get 9.9.9.9

Il campo dev di quell'output è il nome che la regola NAT servirà più avanti, quindi conservalo.

L'inoltro è un interruttore del kernel e una politica del firewall

Il kernel deve prima accettare di inoltrare. Leggi il valore attuale, poi rendi permanente l'impostazione invece di scriverla solo nel kernel in esecuzione:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

L'inoltro è solo metà. Su un host con UFW la politica di inoltro si imposta in /etc/default/ufw e deve essere ACCEPT prima che un ricaricamento abbia effetto. Un blocco predefinito sul percorso di inoltro lascia l'handshake perfettamente sano mentre scarta in silenzio ogni pacchetto che cerca di uscire dal tunnel, ed è esattamente il sintomo con cui hai iniziato.

Gli host che gestiscono nftables direttamente hanno la stessa domanda in un'altra sintassi. Guarda i contatori sulla catena di inoltro mentre gira un test dal client, perché una catena consultata e una catena che scarta sembrano identiche in un file di configurazione.

Nomina la vera interfaccia di uscita nella regola NAT

La traduzione di origine appartiene all'interfaccia che esce davvero dall'host, con il pool che il server distribuisce. Entrambe le metà di quella regola devono descrivere la realtà, e nessuna delle due è facoltativa.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

Il guasto classico è una regola copiata da una guida che dice -o eth0 su una macchina il cui adattatore si chiama diversamente. La regola si installa senza avvisi, non corrisponde a nulla, e il client resta senza internet. Il pool è l'altra metà dello stesso errore: se il server distribuisce 10.44.0.0/24 e la regola copre 10.8.0.0/24, nulla corrisponderà mai.

Guarda i contatori invece di fidarti del testo della regola. L'elenco riporta i pacchetti per regola, e una regola che non corrisponde mai resta a zero per quanto sembri corretta. Dagli un minuto di traffico reale del client prima di leggere qualcosa in quel numero:

iptables -t nat -L POSTROUTING -v -n

Un conteggio di pacchetti zero dopo un vero test dal client significa che la corrispondenza è sbagliata, non che il tunnel sia rotto. Una volta che corrisponde, salva il set di regole perché sopravviva a un riavvio; una correzione che vive solo nella cronologia della tua shell sparisce al primo riavvio.

Se il server è anche un'istanza NAT cloud, anche la piattaforma ha voce in capitolo. Un'istanza che traduce indirizzi di solito richiede il controllo di origine e destinazione disattivato dove il provider offre quell'impostazione, e la porta VPN stessa deve essere raggiungibile dall'esterno.

Il DNS è il secondo guasto dietro il primo

Il ping per indirizzo che funziona mentre i nomi falliscono è un problema del resolver, e ha una causa propria. Un client che mantiene il suo resolver locale manda quelle query in un tunnel completo e aspetta una risposta che non arriva mai, perché il resolver locale ora è dalla parte sbagliata della rotta.

Spingi un resolver dal server perché il client sappia dove chiedere. Due voci danno al client un ripiego se la prima non è raggiungibile, e entrambe dovrebbero essere resolver che il tunnel permette davvero.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

I client Windows possono poi ricadere comunque sul resolver locale, ed è esattamente ciò che block-outside-dns esiste per impedire, al prezzo di perdere nomi che solo la rete locale può risolvere. I client Linux con systemd-resolved spesso ignorano un resolver spinto a meno che uno script non lo installi, quindi controlla resolvectl status per il dispositivo del tunnel prima di concludere che il push è stato ignorato.

Chiudi il percorso come lo vive un utente. Carica una pagina reale dal client, conferma l'indirizzo da cui esce, riavvia il server, riconnettiti e ripeti i tre test. Solo quel secondo passaggio dimostra che le regole salvate, la politica del firewall e il resolver spinto sono sopravvissuti tutti insieme.