Le trafic passe-t-il vraiment par le VPN ? Comment le vérifier

Deux pannes se ressemblent depuis l'icône de la zone de notification : le trafic qui entre dans le tunnel et celui qui le contourne silencieusement. Le client affiche Connected dans les deux cas, car Connected signifie seulement que l'interface du tunnel existe et que le client a installé les routes qu'il voulait. Savoir si un paquet d'une application a utilisé ces routes est une autre question, à laquelle on répond ailleurs dans la pile. Quatre mesures règlent l'essentiel — la consultation de route, le premier saut, une capture sur l'adaptateur physique et une observation depuis l'extérieur — et la vue de session sur le serveur couvre le reste.

Commencez par la route que le paquet va prendre

La table de routage est la décision, demandez-lui donc une destination au lieu de la lire en entier et de deviner. Sous Linux, ip route get nomme l'interface et l'adresse source choisies par le noyau :

ip route get 203.0.113.10
ip route get 10.20.5.7

Sous Windows, Find-NetRoute -RemoteIPAddress 203.0.113.10 est plus utile que route print -4 pour la même raison : il indique la route qui l'a emporté, pas toutes celles qui existent. Lisez quand même la table une fois pour sa ligne 0.0.0.0. Une paire /1 y signifie qu'un client tunnel complet a réécrit la route par défaut : l'option redirect-gateway def1 d'OpenVPN installe 0.0.0.0/1 et 128.0.0.0/1 via le tunnel, ce qui bat la 0.0.0.0/0 existante à la correspondance de préfixe la plus longue sans supprimer la route par défaut physique. C'est pourquoi deux routes par défaut peuvent coexister alors que tout passe quand même par le tunnel.

Deux détails rendent la table menteuse. D'abord, regardez le préfixe qui a correspondu et non le nombre de routes par défaut, car une métrique d'interface ou une paire /1 décide du gagnant. Ensuite, une connexion déjà établie conserve le chemin avec lequel elle a été établie ; après la montée du tunnel, une session ouverte peut continuer d'utiliser l'ancienne route jusqu'à sa réinitialisation, et c'est pourquoi se reconnecter semble corriger un problème de routage. Un client en cours d'exécution — ps ax | grep openvpn — prouve seulement que le processus a démarré.

Suivez un nom interne et un nom public

La consultation de route montre l'intention ; le chemin montre la livraison. Suivez un nom qui doit être interne et un nom qui ne doit pas l'être, pendant que vous êtes connecté, puis comparez le premier saut :

traceroute intranet.corp.example
traceroute 1.1.1.1

Le même premier saut pour les deux signifie que le nom interne n'est jamais entré dans le tunnel et que la panne se situe au-dessus, généralement un nom qui se résout en adresse publique ou une route qui n'a jamais été installée. Si le trafic interne sort par 10.8.0.1 tandis que le trafic public sort par 192.168.1.1, le tunnel divisé fait exactement ce pour quoi il a été configuré. Une trace qui atteint la passerelle VPN puis ne renvoie que des expirations est généralement un problème de chemin de retour ou de pare-feu serveur, pas une route de transfert manquante.

Un ICMP filtré rend ce contrôle menteur : des étoiles sur les deux traces ressemblent à un tunnel mort et il s'agit généralement d'un pare-feu. Testez un port TCP là où vous pouvez — traceroute -T -p 443 sous Linux — et rappelez-vous que la trace ne dit rien du résolveur qui a répondu : un nom peut se résoudre localement et rester joignable par le tunnel.

Capturez sur l'adaptateur physique, pas sur le tunnel

Le lien physique est le seul endroit qui montre ce que le réseau voit réellement. Tunnel monté, une session vers le bureau devrait apparaître comme une charge chiffrée adressée au serveur VPN, et non comme une connexion vers 10.20.5.7 :

sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5

Le premier filtre attrape la résolution de noms qui sort localement, la fuite la plus courante et la plus discrète — la page se charge quand même, le résolveur a seulement vu la requête. Le second attrape le trafic simple vers une adresse interne qui ne devrait exister que dans le tunnel. Sous Windows, pktmon fait le même travail sans pilote : pktmon filter add -p 53, puis pktmon start --capture --pkt-size 128, puis pktmon stop et pktmon format pktmon.etl -o capture.txt. Ces options varient un peu selon les versions de Windows, vérifiez donc pktmon filter add /? avant de faire confiance à la syntaxe.

Capturez l'interface physique pour trouver les fuites ; une capture sur le tunnel contient les paquets dont vous croyez déjà qu'ils sont là, et sur un serveur elle contient des paquets externes illisibles dont la source est la passerelle. Les compteurs d'octets de n'importe quelle interface décrivent des paquets, pas des programmes ; attribuer du trafic à un processus exige un moniteur qui associe les sockets aux processus.

Interrogez un service externe, puis interrogez-le à nouveau par application

Le seul contrôle qui prouve la sortie est une réponse de l'extérieur : un service qui renvoie l'adresse source qu'il a vue. Lancez-le depuis un shell, où vous pouvez choisir l'interface, et lancez-le deux fois :

sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ip

Des réponses différentes vous donnent la preuve des deux chemins et un moyen de tester une application précise : liez-la, ou lancez-la dans un espace de noms réseau avec une seule route, et voyez quelle adresse l'extrémité distante enregistre. Des réponses identiques sont la panne intéressante : soit la liaison n'a pas pris effet, soit quelque chose entre l'hôte et l'extrémité distante réécrit l'adresse source avant son arrivée. Sous Windows, curl --interface veut l'adresse de l'adaptateur plutôt que son nom.

Un navigateur qui rapporte l'adresse du VPN prouve le navigateur. Un client de messagerie, un gestionnaire de paquets, un agent de sauvegarde ou un second profil de navigateur peuvent chacun emprunter un chemin différent, surtout quand un réglage de proxy ou une route de tunnel divisé en couvre un. Un changement d'adresse n'est pas en soi une preuve de fuite : un répartiteur de charge peut répondre différemment selon la sortie qu'il a vue, comparez donc l'adresse source enregistrée, pas la page.

Utilisez la vue serveur pour confirmer le pair

Le serveur répond à une autre question : si un pair est connecté, combien il a transporté et si la session a redémarré. Un pair actif sur le serveur alors que les compteurs du client bougent à peine signifie que le trafic de l'application n'entre pas dans le tunnel, quoi qu'ait dit la table du client. Un pair qui déplace beaucoup de données pour un utilisateur qui signale que rien ne fonctionne est une autre enquête.

Deux pièges se cachent ici. Un tunnel masqué fait apparaître chaque flux comme venant de la passerelle, si bien que les journaux et la comptabilité par client s'effondrent sur une seule adresse. Et un client est traité comme un hôte local, si bien que la question de savoir si quelqu'un copie des fichiers par le VPN se répond par le trafic de partage de fichiers sur le serveur ou par l'audit de l'hôte sur le serveur — surveiller le tunnel donne les extrémités et le volume, pas les noms de fichiers.

Distinguez une décision de conception d'une fuite

Tout ce qui est hors du tunnel n'est pas une fuite. Le trafic de lien local et de diffusion reste local par conception, une imprimante découverte par multicast continue de s'annoncer sur le LAN, et DHCP doit sortir localement. Une application liée à une interface précise contourne la table de routage exprès, et seules une règle de pare-feu, un espace de noms ou une route de politique y changent quelque chose.

IPv6 mérite sa propre ligne dans la liste de contrôle. Un tunnel qui ne transporte que de l'IPv4 laisse un hôte double pile avec un second chemin utilisable, et une destination double pile le préférera — y compris le DNS, si le résolveur est joignable en IPv6. Désactivez IPv6 sur l'adaptateur ou confirmez que le tunnel le transporte avant de considérer un résultat IPv4 comme complet.

Quand les contrôles ne concordent pas, le désaccord nomme généralement la panne :

Un ordre qui fonctionne : enregistrez la table de routage avant et après la connexion, suivez un nom interne et un nom public, capturez le DNS sur l'adaptateur physique, renvoyez l'adresse de sortie depuis le shell pour l'application concernée, puis lisez le serveur pour le volume. Si les quatre premiers concordent, le tunnel transporte bien ce que vous croyez et le problème restant se situe au-dessus. Si deux d'entre eux divergent, la paire qui diverge est la panne, pas l'icône.