Un reset TCP ne prouve pas que votre VPN est bloqué

« Connexion réinitialisée, redémarrage » apparaît dans le journal du client, et la conclusion arrive avant la preuve. Quelqu’un décide que le réseau bloque le VPN, ou que le certificat est faux, ou qu’un pays précis s’en mêle. Un reset est un paquet TCP qui met fin à une connexion, et la ligne de journal note que votre client en a reçu un. Elle ne nomme ni l’appareil qui l’a envoyé ni la raison.

Un reset est un paquet, pas un verdict

TCP définit le traitement du reset : un segment portant le drapeau RST met fin à la connexion immédiatement. Le récepteur ne négocie pas, ne réessaie pas et ne demande pas pourquoi. Il signale le reset et continue.

C’est tout ce que le client sait. Le RST a pu venir du serveur, d’un proxy, d’un pare-feu ou d’un répartiteur de charge qui a perdu son état.

L’attribution est un exercice distinct. Une adresse source apparente dans une capture ne prouve pas l’origine physique et ne dit rien de la décision de politique derrière. Les boîtiers intermédiaires peuvent usurper des adresses, et les équipements à état peuvent réinitialiser sur expiration plutôt que par intention. Traiter le reset comme un verdict saute la partie où l’on découvre la vérité.

Confirmez quelle connexion a été réinitialisée

Vérifiez d’abord que le profil actif utilise réellement TCP. Un reset sur un tunnel UDP n’a pas de sens, et un journal de proxy HTTP peut concerner une autre jambe TCP que le VPN lui-même.

Notez la destination, le port, l’heure de la tentative et l’étape atteinte par le client.

L’étape est le champ le plus utile. Un reset pendant la poignée de main TLS désigne un ensemble de suspects ; un reset après l’authentification en désigne un autre. Sans l’étape, toutes les théories conviennent.

Comparez les deux extrémités du chemin

Si vous administrez le serveur, comparez ses événements pour la même tentative. A-t-il accepté la connexion ? L’a-t-il fermée délibérément ? Une réponse a-t-elle quitté une frontière sans jamais atteindre la suivante ?

Capturez chez le client et chez le serveur si vous le pouvez. Un reset qui apparaît chez le client mais pas chez le serveur ne vient pas du serveur.

Surveillez les segments RST dans les deux sens :

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

Restreignez par une comparaison contrôlée

Un second réseau approuvé peut vous dire si la panne suit le client ou le chemin. Si le même profil fonctionne ailleurs, la configuration du client est probablement correcte et le chemin est la variable.

Cela n’identifie toujours pas un boîtier intermédiaire précis. Cela réduit la portée à une route, ce qui est un résultat utile et honnête.

Gardez la distinction entre « ce chemin échoue » et « cet acteur nommé l’a causé ». La première est testable ; la seconde ne l’est généralement pas depuis un seul client.

Vérifiez le correctif sans changer les réglages de confiance

Ne désactivez pas la vérification TLS, ne régénérez pas les identifiants et n’annoncez pas une politique de blocage à partir d’une seule ligne de reset. Chacun de ces changements modifie le système testé et rend la comparaison suivante dénuée de sens.

Corrigez le composant identifié via son propriétaire, puis répétez le même profil et la même observation :

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

Le résultat utile est une panne mieux localisée, pas un récit plus assuré. Si le reset disparaît après un correctif de proxy, vous avez une cause. S’il se déplace vers une autre étape, vous avez appris quelque chose sur le chemin. Dans tous les cas, la preuve devrait survivre à la lecture d’une seconde personne. Notez ce que vous avez observé, pas ce que vous avez conclu.