Connexion réinitialisée par le pair via un proxy : identifier l'étape en échec
Utilisez l'étape de connexion et des preuves corroborantes pour analyser une réinitialisation du proxy sans prendre le court message d'erreur du système d'exploitation pour une attribution.
« Connection reset by peer » signale une connexion de transport rompue. Il n'identifie pas le fournisseur d'accès, l'exploitant du proxy ou le site web comme la cause.
| Moment de la réinitialisation | Où enquêter |
|---|---|
| Immédiatement après la connexion TCP | Une incompatibilité de protocole ou un service qui rejette l'échange d'ouverture |
| Après la réussite de CONNECT | Le chemin du tunnel établi |
| Pendant une réponse | Fermeture en amont, politique de durée de vie d'un intermédiaire et chemin de transfert |
Modifiez ensuite une condition pertinente en gardant le proxy et la destination fixes. Comparez une connexion chiffrée client-vers-proxy correctement configurée, lorsqu'elle est prise en charge, ou le même client depuis un autre réseau approuvé. Demandez si l'exploitant peut corréler la tentative dans ses journaux.
Un résultat différent resserre l'analyse sans prouver une cause. Faire passer le trafic par un tunnel peut modifier à la fois le minutage, la charge, la politique et les boîtiers intermédiaires. Son succès seul ne peut pas établir un blocage délibéré sur le chemin d'origine.
Là où des observations de paquets autorisées sont disponibles, comparez-les aux journaux de l'application et du proxy. Même l'adresse source attendue du paquet n'explique pas pourquoi une réinitialisation a été envoyée ni quel système a appliqué une politique.
Conservez l'erreur numérique, l'horodatage, le point de terminaison et la dernière étape achevée. Utilisez ces preuves avant de modifier des identifiants ou des réglages TLS ; le court message de réinitialisation ne fournit à lui seul aucune raison de changer l'un ou l'autre.