Le serveur proxy ne répond pas… d’après Internet Explorer

Voici un scénario classique, un message, à priori explicite, une cause toute trouvée et pourtant… ce diagnostic va vous montrer qu’une fois de plus, on ne peut se fier à rien, sauf à une vraie analyse !

Introduction : tout s’annonce plutôt simple

Le message que l’utilisateur remonte fièrement (il y a de quoi, pour une fois, vous savez qui, quand, quoi et comment !) est un classique d’Internet Explorer 11 : « Le serveur proxy ne répond pas »… « Vérifiez vos paramètres… ».

Oui, mais c’est seulement intermittent. On réessaye et ça marche. Ce serait trop simple.

Alors qu’en penser ? Le proxy est-il bien configuré ? A-t-il réellement des bouffées de chaleur ? Le réseau bagote-t-il ?

Nul doute que chacun a son idée, si possible dans le périmètre de responsabilité du collègue. Et dans ce cas, l’équipe réseau ou infra est toute désignée. Non ?

Ceux qui nous connaissent le savent déjà, chez ISIS Performance, on vous dit qu’il ne faut jamais présumer des causes… mais il faut bien impliquer quelqu’un. Ici, ça tombe bien, dans l’équipe réseau, il y a un bel outil : Truview de Fluke Networks. Et en prime, Nexthink, impressionnant outil d’analytics des PC est disponible également.

C’est donc une belle analyse combinée réseau + poste que l’on peut mener.

Etape 1 : Vérifier qu’on cherche au bon endroit

Notre VIP a rencontré le problème en visitant plusquelinfo.com entre 8h et 8h10. Avec Nexthink, une simple recherche sur son nom nous donne en 2 clics toute l’activité de son poste, ciblée sur 8h00-8h10 :

On voit parfaitement que l’activité réelle avec www.new.plusquelinfo.com passe par le Proxy 10.xxx.xxx.231 port 8000.

La configuration est bien normale ; il faut donc trouver des données sur cette activité pour découvrir une cause racine.

Etape 2 : Aller chercher de la donnée de diagnostic

Puisqu’on sait avec certitude qui, quand et quoi, ça commence facilement : Truview nous offre tous les filtres pour converger sur le trafic avec le proxy de l’utilisateur et au bon moment. Ca ressemble à ça :

Truview nous permet de récupérer les 6,68 Mo de paquets ciblés sur l’utilisateur avec le proxy au moment visé.

Etape 3 : Analyse au microscope

Avec des données aussi ciblées, une fois n’est pas coutume, on n’a peur de rien, on ouvre ça avec Wireshark !

Note pour les lecteurs non avertis : sauf rares exceptions, quand on ouvre Wireshark… c’est qu’on a du temps à perdre.

Jusqu’à 8h05 :31, les données commencent à affluer depuis www.new.plusquelinfo.com via le Proxy en .231.

[Snip]

Mais très très vite, le PC (Windows en fait) signale au Proxy qu’il n’en peut plus et que le Proxy doit arrêter de lui envoyer des données. C’est le message TCP Zero Window qui l’indique.

Le Proxy demande un statut toutes les 5 secondes (TCP Zero Window Probe), mais le PC lui répond toujours d’attendre.

Au bout de 3 demandes et 20 secondes, le Proxy perd patience et RESET de force la connexion à 8h05 :51 donc.

Internet Explorer voyant sa connexion se fermer brutalement, informe l’utilisateur que le Proxy ne répond plus. Ce qu’il ne dit pas (IE ne le sait pas) c’est que c’est à cause de l’asphyxie de Windows que TCP ne pouvait plus recevoir de données du Proxy qui a tout fermé.

On voit ensuite que l’utilisateur réouvre la connexion à 8h06 :42 s. et là ça se passe normalement dans la suite de la trace.

Pourquoi Windows était-il asphyxié ? Retour à Nexthink.

Etape 4 : Remise en contexte

L’activité du PC vue par Nexthink (à seulement 1 clic de l’écran précédent !) donne la chronologie suivante :

8h00 :44s Boot du PC en 15 s.

8h02 :20s Logon user

8h02 :24 Démarrage de Lync et l’activité réseau augmente fort

8h05 :06s à 36s : on voit un Warning “High CPU usage” du process hfnetchk.exe (Shavlik Patch Assessment) CQFD !

8h06 :31s on voit l’impression d’écran du message d’erreur qui a été remonté !

Conclusions

Le message d’erreur du 9/09 8h05 (et 51 sec.) est assurément dû à une cause locale au poste.

Root cause probable : forte charge CPU liée au process hfnetchk.exe (Shavlik Patch Assessment)

Action recommandée : Voir avec l’équipe Poste de travail comment limiter ou décaler certaines activités IT du poste pour ne pas pénaliser les utilisateurs (au moins les VIP !).

C’est une double analyse Réseau avec Truview +Wireshark et Nexthink qui permet de conclure assurément que, contre toute attente à la vue du message, la cause est une surcharge du poste et aucunement liée au proxy ou au réseau.