Il client OpenVPN raggiunge il server ma non gli host della LAN: lista di controllo

Il client dice connesso, l’indirizzo del tunnel risponde al ping e nulla sulla LAN dell’ufficio risponde. Lo vedo dopo quasi ogni aggiornamento del client, e il primo istinto è aprire il firewall, che di solito è la mossa sbagliata: il tunnel è a posto e la rottura è su uno dei tre salti che il pacchetto deve attraversare. Percorrete il percorso nell’ordine in cui lo segue il pacchetto, prima la rotta del client, poi l’inoltro sul server, poi il viaggio di ritorno, e troverete il responsabile del guasto in un paio di minuti.

Primo passo: osservate la decisione di routing del client

Prima di toccare il server, dimostrate che il client invia il pacchetto nel tunnel. Chiedete al kernel quale interfaccia userebbe per un host LAN specifico, invece di leggere tutta la tabella:

ip route get 192.168.50.10

Se la risposta nomina il vostro adattatore fisico e il gateway dell’ufficio, nessuna modifica lato server può aiutare. OpenVPN distribuisce rotte solo quando il server le spinge, quindi cercate push "route 192.168.50.0 255.255.255.0" nella configurazione del server e poi ricollegate il client. La maggior parte dei client applica le rotte spinte alla connessione, non quando ricaricate il profilo.

Su Windows la stessa domanda ha un altro comando. Find-NetRoute -RemoteIPAddress 192.168.50.10 stampa l’interfaccia e il salto successivo che lo stack sceglierebbe, e route print -4 mostra se il prefisso spinto esiste addirittura.

Secondo passo: confermate che il server inoltrerà il pacchetto

Se la rotta del client è corretta, il pacchetto raggiunge il server e il server deve accettare di inoltrarlo. L’interruttore del kernel è la prima porta, e sysctl net.ipv4.ip_forward deve restituire 1. Impostarlo con echo 1 > /proc/sys/net/ipv4/ip_forward funziona fino al riavvio successivo, ed è esattamente per questo che la stessa lamentela torna settimane dopo.

Annotatelo in un luogo che sopravvive a un riavvio:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

La seconda porta è la tabella dei filtri. Un host con Docker installato porta spesso una politica FORWARD impostata su DROP, e il tunnel eredita quella decisione. iptables -L FORWARD -v -n mostra sia la politica sia i contatori dei pacchetti; se la politica è DROP, l’inoltro richiede un’autorizzazione esplicita per la direzione dal tunnel alla LAN e una per la risposta.

Terzo passo: seguite il pacchetto fino alla LAN e cercate la risposta

Sorvegliate entrambi i lati del server contemporaneamente. Catturate sul tunnel e sull’interfaccia LAN, filtrando su un client e un host perché l’output resti leggibile:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Le richieste che compaiono su tun0 e di nuovo su eth0 con origine 10.8.0.x, seguite dal silenzio, significano che il pacchetto è arrivato e la risposta è andata altrove. L’host della LAN risponde al suo gateway predefinito, quel gateway non ha una rotta per il pool VPN e la risposta muore sul router della LAN. Fare ping all’host della LAN dal server non dimostra nulla su questo percorso, perché quel traffico non attraversa mai il tunnel.

Quarto passo: scegliete tra traduzione e una rotta di ritorno

Due riparazioni chiudono il buco, e la scelta ha conseguenze oltre al fatto che il ping funzioni. La traduzione della sorgente rende il server il mittente apparente:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Limitate la regola al pool e all’interfaccia LAN, poi rendetela permanente, altrimenti il successivo ricaricamento del firewall rimuove in silenzio la vostra correzione. Il costo è l’identità: ogni client appare come il server VPN nei log della LAN e nelle regole di accesso, e per-client policy becomes guesswork.

Una rotta statica per 10.8.0.0/24 sul router della LAN, che punta al server VPN, mantiene visibili gli indirizzi dei client ed è la risposta migliore a lungo termine quando quel router è vostro. Molti siti fanno funzionare entrambe per un po’, NAT per la riparazione immediata e la rotta una volta scritta la politica del firewall. Se il server è un peer site-to-site invece di un pool, anche il lato server ha bisogno di un iroute per la sottorete remota, altrimenti la rotta del peer esiste ma il traffico dei client non vi è mai associato.

Quinto passo: verificate dal client e annotate cosa è cambiato

Chiudete il ciclo dal client, non dal server. Connettetevi a un servizio reale sull’host della LAN, poi confermate che i contatori della traduzione si sono mossi con iptables -t nat -L POSTROUTING -v -n, perché una regola senza pacchetti è una regola che non ha mai corrisposto. conntrack -L -s 10.8.0.5 mostra il flusso e il suo stato quando vi serve la prova che la direzione di ritorno è tracciata.

Lasciate una nota nella configurazione del server: quale sottorete, quale interfaccia, quale regola e se il router della LAN porta una rotta di ritorno. La prossima volta che un aggiornamento del client cancella una rotta spinta, quella nota trasforma una sessione di spegnimento incendi in una correzione di una riga.