Où observer le trafic d'un client OpenVPN sur la passerelle

Vous voulez savoir quelles destinations atteint un client connecté, alors vous ouvrez un shell sur le serveur VPN et tapez ss. Rien d'utile n'apparaît, et la conclusion que le tunnel est cassé suit un peu trop facilement. Une passerelle OpenVPN routée transfère les paquets du client ; elle ne termine pas ses connexions TCP et ne possède pas de sockets pour elles. La preuve vit ailleurs, et cet ailleurs dépend de la façon dont le trafic est traité une fois sorti du tunnel.

Déterminez quelle disposition vous regardez

Deux formes courantes produisent des preuves complètement différentes. Une passerelle routante décapsule, transfère et éventuellement applique un NAT de source, si bien que la connexion du client continue d'exister de bout en bout sans socket local.

Un proxy termine le trafic : il accepte la connexion, puis ouvre sa propre connexion amont. Dans cette disposition, il y a deux connexions pour une requête, et l'association entre elles n'existe que dans les propres enregistrements du proxy. Savoir laquelle des deux vous avez déployée décide si vous devez lire l'état de flux du noyau ou les journaux de l'application.

L'essentiel de la confusion vient des suppositions. Confirmez la forme avant de choisir l'outil. Lisez d'abord la configuration du serveur pour y chercher une directive de proxy, car sa présence change chaque étape suivante. Sans elle, le chemin des paquets est du routage et l'état de flux du noyau est votre preuve.

Liez d'abord l'adresse à une session

Partez de l'état des sessions du serveur et identifiez l'adresse interne actuelle du client. Les adresses du pool sont recyclées, donc une adresse seule est un bail, pas une personne.

Notez l'heure et l'identité authentifiée ensemble, et repérez si tout un réseau local se cache derrière ce client. Si l'extrémité distante route un sous-réseau, les adresses internes que vous voyez peuvent être des hôtes d'origine ou des adresses traduites.

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

Cette paire répond à deux questions à la fois : quel préfixe sert l'interface du tunnel et quelle session était active pendant l'intervalle qui vous intéresse. Faites-le avant d'interpréter la moindre entrée de flux, car un tuple convaincant attaché à la mauvaise session est pire qu'aucune preuve.

Lisez la table de flux sur une passerelle routante

Une fois l'adresse et l'intervalle établis, une liste en lecture seule des connexions suivies montre ce que la passerelle transfère pour elle. Filtrez sur la source d'origine pour ne pas lire toute la table.

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

Chaque entrée contient deux tuples, l'original et la réponse, qui sont les deux directions d'un même flux et non deux applications. Sur un chemin avec NAT de source, le tuple original conserve l'adresse du tunnel tandis que le côté réponse montre l'adresse traduite de la passerelle, et c'est exactement ce qui fait paraître la sortie fausse au premier regard.

Traitez la liste comme un état vivant et non comme un historique. Les flux courts ont peut-être déjà expiré, le trafic non suivi n'apparaît jamais, et un autre espace de noms réseau montre une autre table. La référence conntrack documente les filtres et la sortie dans les deux sens.

Une capture bornée pour confirmer la lecture

Si l'interface du tunnel est visible là où vous regardez, une seule capture bornée tranche la question de savoir si les paquets que vous avez identifiés sont ceux sur le fil. Gardez le filtre étroit et la limite de paquets faible.

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

Comparez horodatages, protocole et ports avec l'entrée de flux et avec la requête que vous avez faite comme test. Une capture prise après le NAT ne montre que l'adresse publique de la passerelle, tandis que le côté tunnel peut encore montrer celle du client, et cette différence est une information et non une incohérence.

Si l'interface ne voit rien, vérifiez le chemin des données avant de conclure que le client est inactif : le trafic de client à client et certains chemins de délestage ne traversent jamais le point que vous surveillez.

Journaux du proxy et les limites de ce que vous avez vu

Quand un proxy se trouve sur le chemin, ses sockets amont sont visibles dans la table des sockets mais ne correspondent pas un pour un aux clients VPN, surtout avec la mise en commun ou le multiplexage. Utilisez le journal de transactions configuré du proxy pour corréler l'identité du client, la destination, l'horodatage et tout identifiant de requête qu'il enregistre.

Vérifiez la configuration de journalisation de la version déployée au lieu de supposer que chaque requête est journalisée par défaut.

Enfin, soyez précis sur la portée. Une adresse de destination et un port sont des métadonnées, ni une URL ni le contenu d'une page, car la session HTTPS interne conserve sa propre protection quel que soit le tunnel. Rapportez ce que vous avez observé, depuis quel point d'observation et à quelle heure.