Version courte: un ordinateur Windows Server 2012 de mon réseau reçoit des TCP RST persistants mais intermittents lors de la connexion à certains sites Web. Je ne sais pas d'où ils viennent. Consultez le journal WireShark pour mon analyse et mes questions.
Version longue:
Nous utilisons un proxy Web de mise en cache sur l'un de nos serveurs pour desservir notre petit bureau. Un collègue a signalé de nombreuses erreurs de «réinitialisation de la connexion» ou «Impossible d'afficher la page» lors de la connexion à certains sites, mais cette actualisation le résout généralement.
J'ai vérifié le comportement du navigateur, puis plus directement en essayant un navigateur sans proxy sur le serveur lui-même. Mais les pings et les traceroutes vers des sites gênants ne montrent aucun problème, les problèmes semblaient se limiter aux connexions TCP.
J'ai ensuite fait un script pour tester les sites affectés en leur envoyant des requêtes HTTP HEAD directement via cURL et en vérifiant la fréquence à laquelle elles réussissent. Un test typique ressemble à ceci: (ceci est non sollicité et s'exécute directement sur le mauvais serveur)
C:\sdk\Apache24\htdocs>php rhTest.php
Sending HTTP HEAD requests to "http://www.washingtonpost.com/":
20:21:42: Length: 0 Response Code: NULL (0%)
20:22:02: Length: 0 Response Code: NULL (0%)
20:22:22: Length: 0 Response Code: NULL (0%)
20:22:42: Length: 0 Response Code: NULL (0%)
20:23:02: Length: 3173 Response Code: HTTP/1.1 302 Moved Temporarily (20%)
20:23:22: Length: 3174 Response Code: HTTP/1.1 302 Moved Temporarily (33.33%)
20:23:43: Length: 0 Response Code: NULL (28.57%)
20:24:03: Length: 3171 Response Code: HTTP/1.1 302 Moved Temporarily (37.5%)
20:24:23: Length: 3173 Response Code: HTTP/1.1 302 Moved Temporarily (44.44%)
20:24:43: Length: 3172 Response Code: HTTP/1.1 302 Moved Temporarily (50%)
20:25:03: Length: 0 Response Code: NULL (45.45%)
Sur le long terme, seules environ 60% des demandes aboutissent, les autres réponses ne retournant rien, avec un code d'erreur curl de: "erreur cURL (56): échec lors de la réception de données de la part de l'homologue" Le mauvais comportement est le même pour les sites Web I test (aucun site n'a jamais été 'amélioré') et il est assez persistant, je dépanne depuis une semaine maintenant, et des collègues rapportent que le problème existe depuis des mois, apparemment.
J'ai testé le script de requête HEAD sur d'autres machines de notre réseau: pas de problème, toutes les connexions passent par tous les sites de ma liste de test. Ensuite, je configure un proxy sur mon bureau personnel et, lorsque j'exécute les requêtes HEAD provenant du serveur problématique, toutes les connexions passent. Donc quel que soit le problème, il est très spécifique à ce serveur.
Ensuite, j'ai essayé d'isoler les sites Web présentant le comportement de réinitialisation de connexion:
- Aucun de nos sites intranet (192.168.xx) ne supprime de connexions.
- Aucun site ipv6, j'ai testé des connexions de gouttes. (Nous sommes double pile)
- Seule une petite minorité de sites Internet ipv4 abandonnent les connexions.
- Tous les sites qui utilisent cloudflare en tant que CDN (que j'ai testé) abandonnent les connexions. (mais le problème ne semble pas être exclusif aux sites cloudflare)
Cet angle ne s'est pas transformé en quelque chose de vraiment utile, alors j'ai ensuite installé Une demande HEAD ayant échoué ressemble à ceci: (capture d'écran plus grande ici: http://imgur.com/TNfRUtX )
127 48.709776000 192.168.1.142 192.33.31.56 TCP 66 52667 > http [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=8960 WS=256 SACK_PERM=1
128 48.728207000 192.33.31.56 192.168.1.142 TCP 66 http > 52667 [SYN, ACK, ECN] Seq=0 Ack=1 Win=42340 Len=0 MSS=1460 SACK_PERM=1 WS=128
129 48.728255000 192.168.1.142 192.33.31.56 TCP 54 52667 > http [ACK] Seq=1 Ack=1 Win=65536 Len=0
130 48.739371000 192.168.1.142 192.33.31.56 HTTP 234 HEAD / HTTP/1.1
131 48.740917000 192.33.31.56 192.168.1.142 TCP 60 http > 52667 [RST] Seq=1 Win=0 Len=0
132 48.757766000 192.33.31.56 192.168.1.142 TCP 60 http > 52667 [ACK] Seq=1 Ack=181 Win=42240 Len=0
133 48.770314000 192.33.31.56 192.168.1.142 TCP 951 [TCP segment of a reassembled PDU]
134 48.807831000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
135 48.859592000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
138 49.400675000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
139 50.121655000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
141 51.564009000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
143 54.452561000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
La façon dont je lis ceci (corrigez-moi si je me trompe, ce n'est pas vraiment mon domaine) est la suivante:
- Nous ouvrons une connexion TCP au serveur Web
- serveur web ACK
- La requête HTTP HEAD est envoyée
- Il existe un paquet RST, marqué à partir de l'adresse IP du serveur Web, qui tue la connexion.
- Le serveur Web envoie un ACK
- Le serveur Web (tente) de répondre à la demande HEAD avec des données HTTP valides (la réponse de 951 octets contient l'en-tête HTTP approprié)
- Le serveur Web retransmet (plusieurs fois en plusieurs secondes) la réponse HTTP valide, mais ne peut pas aboutir car la connexion a été RST.
Donc, si le serveur Web a envoyé une TVD valide, pourquoi continue-t-il à essayer de répondre à la demande? Et si le serveur Web n'a pas généré la TVD, qu'est-ce qu'il a fait?
Ce que j'ai essayé n'a eu aucun effet:
- Désactiver le regroupement de cartes réseau
- Remplacement de la carte réseau (la carte réseau de remplacement fonctionnait)
- Assigner une adresse IP statique.
- Désactiver ipv6.
- Désactiver les trames jumbo.
- Brancher le serveur directement dans notre modem une nuit, en contournant nos commutateurs et notre routeur.
- Désactiver le pare-feu Windows.
- Réinitialisation des paramètres TCP via netsh
- Désactiver pratiquement tous les autres services sur le serveur. (Nous l'utilisons principalement comme serveur de fichiers, mais il y a apache et quelques bases de données)
- Frapper la tête sur le bureau (à plusieurs reprises)
Je soupçonne que quelque chose sur le serveur génère les paquets RST, mais je ne le trouve pas pour la vie. Je me sens comme si je savais: pourquoi est-ce juste ce serveur? OU pourquoi seulement quelques sites? ça aiderait beaucoup. Alors que je suis toujours curieux, je suis de plus en plus enclin à abandonner l'orbite en orbite.
Idées / Suggestions?
-Merci
Réponses:
Votre capture de paquet avait quelque chose d'inhabituel: les bits ECN ont été définis dans le paquet SYN sortant.
La notification explicite de congestion est une extension du protocole IP qui permet aux hôtes de réagir plus rapidement à la congestion du réseau. Il a été introduit pour la première fois sur Internet il y a 15 ans, mais de graves problèmes ont été constatés lors de son déploiement. Le plus grave d'entre eux était que de nombreux pare-feu rejetteraient des paquets ou renverraient un RST lors de la réception d'un paquet SYN avec les bits ECN définis.
En conséquence, la plupart des systèmes d'exploitation ont désactivé ECN par défaut, du moins pour les connexions sortantes. En conséquence, je soupçonne qu'un grand nombre de sites (et de fournisseurs de pare-feu!) N'ont tout simplement jamais corrigé leur pare-feu .
Jusqu'à la publication de Windows Server 2012. Microsoft a activé l’ ECN par défaut à partir de cette version du système d’exploitation.
Malheureusement, personne n'a récemment testé de manière significative les réponses des sites Internet à ECN. Il est donc difficile de savoir si les problèmes du début des années 2000 sont toujours d'actualité, mais je soupçonne fortement qu'ils le sont et que votre trafic est, du moins de temps en temps, en passant par un tel équipement.
Après avoir activé ECN sur mon bureau, puis activé Wireshark, quelques secondes se sont écoulées avant que je ne découvre un exemple d’hôte à partir duquel j’ai reçu une RST pour un paquet avec SYN et ECN défini, bien que la plupart des hôtes semblent fonctionner correctement. Je vais peut-être aller scanner Internet moi-même ...
Vous pouvez essayer de désactiver ECN sur votre serveur pour voir si le problème disparaît. Cela vous empêchera également d'utiliser DCTCP, mais dans un petit bureau, il est fort peu probable que vous l'utilisiez ou que vous ayez besoin de le faire.
la source