Résumé de l’épisode précédente :

Pour diagnostiquer les problèmes de disponibilité de ses applications, on a commencé d’abord par mettre en place une supervision morderne.

Nous analyserons ici les résultats de supervision pour trouver l’origin du problème.

Constat

Commençons par mettre en place les suiveillances suivantes :

Une fois collecté assez d’information dans notre supervision , on peut constater qu’effectivement il y a des problèmes de connectivité :

Vu depuis onlarm :

onlarm vers HT1 On remarquera ici qu’il y a des “trous”, dans les quels la communication avec ht1 est coupé, mais pas avec un ature site internet (ce qui exclu un problème de connectivité locale à onlarm.

Vu depuis ht1 :

onlarm vers HT1 La même chose vue de l’interieure de ht1 : connectivité OK avec les serveurs internes, mais des “trous” avec des google.fr par exemple au mêmes moments.

onlarm vers HT1 En zoomant dans les détails, on peut voir d’ailleurs que les interruptions durent toujours environ 8 minutes, qu’il n’y a pas de pic de CPU/RAM et l’activité réseaux reprennent en pic juste après la coupure (flush de buffer de replication ht1 vers onlarm).

Analyse

Pour l’instant, on a juste confirmé les coupures réseaux, sans en connaitre la cause. Pour aller plus loin, il faut regarder en détail, sur le serveur ht1, les activités réseaux, à l’aide d’un outil Tcpdump disponibile dans toutes les bonnes crèmeries.

Après une capture plus ou moins longue, comportant au moins une copure, nous allons pouvoir l’examinier de plus près : lançons wireshare et regardons de près les statistiques autours des “trous” :

ht1 tcp reset rate

On voit ici un nombre plus élévé de TCP/Reset durant les “trous”. Examinons donc de plus près ces paquets :

ht1 tcp reset rate

D’abord une conversation TCP classique : onlarm ouvre une connexion vers ht1, ht1 lui réponde “IP non autorisée”, puis ferme la connexion.

Remarquons le Time To Live (TTL) observé sur ht1 : 51

Sur onlarm, le TTL par défault est 64, et le nombre de hop est d’environ 13, comme confirmé ici :

onlarm:/tmp# sysctl net.ipv4.ip_default_ttl
net.ipv4.ip_default_ttl = 64


onlarm:/tmp# traceroute -n -p 53 -l  ht1
traceroute to ht1 (89.83.*.*), 30 hops max, 38 byte packets
 1  10.1.20.1  0.837 ms (255)  0.790 ms (255)  0.845 ms (255)
 2  *  *  *
 3  *  *  *
 4  212.47.225.184  1.052 ms (252)  212.47.225.188  1.103 ms (252)  1.260 ms (252)
 5  195.154.1.38  1.470 ms (251)  2.269 ms (251)  1.452 ms (251)
 6  195.154.1.193  2.028 ms (250)  1.388 ms (250)  1.909 ms (250)
 7  *  *  *
 8  212.194.171.146  4.347 ms (247)  4.199 ms (247)  4.290 ms (247)
 9  212.194.171.93  2.412 ms (57)  2.370 ms (57)  2.386 ms (57)
10  89.89.100.173  2.124 ms (247)  2.406 ms (247)  2.383 ms (247)
11  195.36.144.209  24.432 ms (246)  15.330 ms (246)  41.227 ms (246)
12  89.81.158.45  20.767 ms (245)  20.752 ms (245)  20.793 ms (245)
13  *  *  *

Le TTL de 51 observé est donc cohérent.

Regardons maintenant ce qu’il se passe dans un des “trous” :

ht1 tcp reset rate

Le TTL du premier paquet était de 51, comme avant, mais suivi d’un reset avec un TTL de … 64 !

Ce n’est donc pas onlarm qui a envoyé le reset, mais qui ? Réponse dans la capture suivant :

ht1 icmp

Même adresse MAC, même TTL et sur le même segment, pas de doute possible c’est bien Sonicwall (route par défaut de HT1) qui a “coupé” les connexions de HT1 durant les “trous”.