OpenVPN si connette ma non passa nulla: trovate il livello in cui cade il pacchetto

OpenVPN dice connesso e nessun traffico si muove, una frase che copre almeno cinque guasti non correlati. Modificare le regole del firewall prima di sapere quale livello fallisce moltiplica le incognite e lascia un disastro all’ingegnere successivo. Lavorate invece dal processo verso l’esterno, perché ogni passo qui sotto o libera uno stadio o restringe dove muore il pacchetto. L’ordine conta qui: una cattura presa prima di sapere quale indirizzo è associato dimostrerà qualcosa, ma non ciò che vi serve.

Il socket è associato o non lo è

Un servizio che si dichiara attivo può ancora essere associato a un indirizzo o a un trasporto che non avete mai previsto. Interrogate il socket stesso: ss -lunp elenca gli ascoltatori UDP e ss -ltnp quelli TCP, e la colonna che vale la pena leggere è l’indirizzo locale, non lo stato.

Una risposta vuota di solito significa una di tre cose: il processo è uscito dopo l’avvio, ha caricato un altro file di configurazione, oppure ascolta su un indirizzo diverso da quello chiamato.

ss -lunp | grep 1194
ss -ltnp | grep 1194

Una direttiva local fissa l’ascoltatore su un solo indirizzo, quindi un client diretto altrove sullo stesso host viene rifiutato mentre il servizio dall’esterno sembra ancora sano. Un nome di istanza può anche puntare a un file che non avete mai modificato, cosa che accade su host che eseguono due profili affiancati.

Catturate il pacchetto esterno, non il tunnel

Filtrate sull’interfaccia fisica e sulla porta reale, con la vostra interfaccia sostituita: tcpdump -ni eth0 udp port 1194. I pacchetti in uscita senza nulla che torni indicano ciò che sta a monte: filtraggio del provider, un dispositivo NAT o un indirizzo remoto che non è quello che pensate. Il silenzio in entrambe le direzioni indica l’instradamento del client o un firewall locale. Le risposte che arrivano senza progresso del tunnel indicano il canale di controllo, cioè una discrepanza di chiave o cifratura, non il filtraggio.

Catturate entrambe le direzioni e tenete il file breve. Una cattura lunga seppellisce i tre secondi interessanti, e la risposta si trova quasi sempre nel primo scambio.

Prima i contatori, traccia solo quando mentono

Iniziate dai contatori, perché non costano nulla. O nft list ruleset o iptables -L -n -v risponde all’unica domanda che conta qui: la regola ha corrisposto? L’ordine decide il risultato, perché la prima corrispondenza vince, per questo un DROP ampio prima di un ACCEPT successivo lascia quell’ACCEPT morto e per questo aggiungere una regola riesce così di rado a riparare qualcosa.

Anche la proprietà fa inciampare. Il kernel attribuisce i pacchetti generati localmente al processo che ha aperto il socket, e OpenVPN gira normalmente come root, quindi una regola legata a un ID utente ordinario non vede mai il traffico del tunnel stesso. Controllate l’UID proprietario prima di decidere che la regola è sbagliata.

Solo quando i contatori restano ambigui un log vale il rumore, e anche allora solo per una fetta stretta: una regola iptables che limita la velocità e antepone un prefisso alle sue righe, o una regola nftables che porta meta nftrace set 1 mentre nft monitor trace è in esecuzione. Una traccia nomina la catena e la regola che ha accettato o scartato il pacchetto. Rimuovete entrambe dopo e tenete la registrazione del carico fuori.

Controllate anche il trasporto. Un servizio firewall limitato a TCP non dice nulla di un ascoltatore UDP su quel numero, quindi una regola letta correttamente può ancora scartare ogni pacchetto.

Instradamento e via di ritorno

Un pacchetto accettato che scompare comunque richiede l’esame del suo percorso di destinazione. ip route get riporta la rotta scelta per un indirizzo, e il filtraggio del percorso inverso può scartare una risposta che arriva su un’interfaccia che la tabella principale non sceglierebbe mai. Il sintomo sembra esattamente uno scarto del firewall, per questo questo controllo viene prima di un’altra regola NAT.

Su un gateway, ispezionate l’inoltro e la catena forward invece della catena input. Poi confermate che il lato remoto sappia come raggiungere l’indirizzo sorgente, perché un percorso in uscita che funziona senza nulla che torni è silenzio in entrambi i casi.

Cosa deve dire la nota

Per ogni modifica, annotate lo stadio testato, la prova letta e il valore del contatore su entrambi i lati. È quella nota che fa sopravvivere « adesso funziona » alla revisione successiva.

Due scorciatoie tengono onesta la nota. Un pacchetto che non ha mai lasciato l’host non può essere stato scartato da una regola altrove, per convincente che sembri la configurazione del lato remoto. Un pacchetto che è partito ed è tornato sposta la domanda sopra il livello di rete, dove i contatori del firewall non hanno più nulla da dirvi.