Dove osservare il traffico di un client OpenVPN sul gateway

Volete sapere quali destinazioni raggiunge un client connesso, quindi aprite una shell sul server VPN e digitate ss. Non compare nulla di utile, e la conclusione che il tunnel sia rotto arriva un po' troppo facilmente. Un gateway OpenVPN instradato inoltra i pacchetti del client; non termina le sue connessioni TCP e non possiede socket per esse. La prova vive altrove, e questo altrove dipende da come viene trattato il traffico una volta uscito dal tunnel.

Decidete quale disposizione state guardando

Due forme comuni producono prove del tutto diverse. Un gateway che instrada decapsula, inoltra ed eventualmente applica NAT di origine, così la connessione del client continua a esistere da un capo all'altro senza socket locale.

Un proxy termina il traffico: accetta la connessione, poi apre la propria connessione a monte. In quella disposizione ci sono due connessioni per una richiesta, e l'associazione tra loro esiste solo nei registri del proxy stesso. Sapere quale delle due avete distribuito decide se dovete leggere lo stato dei flussi del kernel o i log dell'applicazione.

La maggior parte della confusione nasce dalle congetture. Confermate la forma prima di scegliere lo strumento. Leggete prima la configurazione del server cercando una direttiva proxy, perché la sua presenza cambia ogni passo successivo. Senza di essa il percorso dei pacchetti è instradamento e lo stato dei flussi del kernel è la vostra prova.

Legate prima l'indirizzo a una sessione

Partite dallo stato delle sessioni del server e identificate l'indirizzo interno attuale del client. Gli indirizzi del pool vengono riciclati, quindi un indirizzo da solo è un noleggio, non una persona.

Annotate insieme l'ora e l'identità autenticata, e notate se un'intera LAN si nasconde dietro quel client. Se l'estremità remota instrada una sottorete, gli indirizzi interni che vedete possono essere host originali o tradotti.

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

Quella coppia risponde a due domande insieme: quale prefisso serve l'interfaccia del tunnel e quale sessione era attiva nell'intervallo che vi interessa. Fatelo prima di interpretare qualsiasi voce di flusso, perché una tupla convincente legata alla sessione sbagliata è peggio di nessuna prova.

Leggete la tabella dei flussi su un gateway che instrada

Stabiliti indirizzo e intervallo, un elenco in sola lettura delle connessioni tracciate mostra cosa il gateway inoltra per essa. Filtrate sull'origine originale per non leggere tutta la tabella.

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

Ogni voce contiene due tuple, originale e risposta, che sono le due direzioni di un solo flusso e non due applicazioni. Su un percorso con NAT di origine la tupla originale conserva l'indirizzo del tunnel mentre il lato risposta mostra l'indirizzo tradotto del gateway, ed è esattamente questo che fa sembrare l'output sbagliato a prima vista.

Trattate l'elenco come stato vivo e non come cronologia. I flussi brevi possono essere già scaduti, il traffico non tracciato non compare mai, e un altro spazio dei nomi di rete mostra un'altra tabella. La documentazione di conntrack descrive i filtri e l'output nelle due direzioni.

Una cattura limitata per confermare la lettura

Se l'interfaccia del tunnel è visibile dove state guardando, una sola cattura limitata stabilisce se i pacchetti che avete identificato sono quelli sul filo. Tenete il filtro stretto e il limite di pacchetti piccolo.

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

Confrontate timestamp, protocollo e porte con la voce di flusso e con la richiesta che avete fatto come test. Una cattura presa dopo il NAT mostra solo l'indirizzo pubblico del gateway, mentre il lato tunnel può ancora mostrare quello del client, e questa differenza è informazione e non incoerenza.

Se l'interfaccia non vede nulla, controllate il percorso dei dati prima di concludere che il client sia inattivo: il traffico da client a client e alcuni percorsi di offload non attraversano mai il punto che state osservando.

Log del proxy e i limiti di ciò che avete visto

Quando un proxy sta sul percorso, i suoi socket a monte sono visibili nella tabella dei socket ma non corrispondono uno a uno ai client VPN, soprattutto con pooling o multiplexing. Usate il registro delle transazioni configurato del proxy per correlare identità del client, destinazione, timestamp e qualsiasi identificatore di richiesta che registra.

Controllate la configurazione di logging della versione distribuita invece di dare per scontato che ogni richiesta venga registrata per impostazione predefinita.

Infine, siate precisi sull'ambito. Un indirizzo di destinazione e una porta sono metadati, non un URL e non il contenuto di una pagina, perché la sessione HTTPS interna conserva la propria protezione indipendentemente dal tunnel. Riportate ciò che avete osservato, da quale punto di osservazione e a che ora.