wiki:InsiaAdminSysDiagReseau

Sommaire

Administration système - Diagnostic réseau

Ce chapitre se propose de donner quelques recettes et méthodes pour effectuer des diagnostics simples sur les fonctionnalités réseau d'une machine, ou plus largement le réseau auquelle elle est connectée.

1. Voir/compter les paquets

proc et ifconfig

L'interface la plus bas niveau, mais permet de vérifier notamment le taux d'erreur sur une interface particulière. Les erreurs signifient en général un problème au niveau transport (Ethernet) ou physique (câble, switch). Il est pratique de l'afficher en continu toutes les secondes pendant que l'on effectue des opérations, pour savoir par exemple si des paquets sont physiquements émis ou reçus.

Sous Linux:

# cat /proc/net/dev
raq:~# watch -n1 cat /proc/net/dev
Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    lo:    7792      86    0    0    0     0          0         0     7792      86    0    0    0     0       0          0
 teql0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
  eth0:612401301 39861746    0    0    0     0          0         0 1009477767 28904710    0    0    0     0       0          0
  eth1:379357646 20961603    0    0    0     0          0         0 2668669412 30538706    0    0    0     0       0          0

On obtient des compteurs similaires avec la commande ifconfig, ce qui permet de se concentrer sur une interface plus facilement:

# watch -n1 'ifconfig eth0|grep packets'
          RX packets:39866037 errors:0 dropped:0 overruns:0 frame:0
          TX packets:28909170 errors:0 dropped:0 overruns:0 carrier:0

iptables

Il est possible d'obtenir des compteurs globaux du traffic entrant, sortant et relayé à l'aide des compteurs par défaut des chaînes INPUT, OUTPUT et FORWARD:

# watch -n1 'iptables -nvxL|grep packets'
  Chain INPUT (policy ACCEPT 14686505 packets, 12423514774 bytes)
  Chain FORWARD (policy ACCEPT 30822112 packets, 24205814502 bytes)
  Chain OUTPUT (policy ACCEPT 13428923 packets, 9565390420 bytes)

Bien entendu, si vous avez des chaînes particulières, vous pouvez surveiller son compteur spécifiquement en changeant le grep. Il est possible d'utiliser des chaînes de marquage dont le seul but est d'obtenir des compteurs pour un traffic précis. Par exemple pour compter le traffic HTTP sortant de la machine:

# iptables -t mangle -A OUTPUT -p tcp --dport http -j MARK --set-mark 1
# watch -n1 'iptables -t mangle -nvxL OUTPUT'

tcpdump

Cet outil est comparable à une solution type "iptables", sauf qu'elle permet juste de consulter le traffic de manière passive et est disponible sur de nombreuses plateforme différentes. Elle possède son propre dialecte pour désigner un traffic particulier, mais permet aussi de l'analyser et d'afficher avec précision son contenu. La fonction d'enregistrement peut être très utile pour une analyse "à froid".

# tcpdump -nX tcp dst port 80
22:41:46.180077 IP 82.67.65.112.45080 > 209.85.135.99.80: P 1396113930:1396114479(549) ack 2080596307 win 11440
        0x0000:  4500 024d 2957 4000 3f06 23e8 5243 4170  E..M)W@.?.#.RCAp
        0x0010:  d155 8763 b018 0050 5337 020a 7c03 6153  .U.c...PS7..|.aS
        0x0020:  5018 2cb0 47c8 0000 4745 5420 2f73 6561  P.,.G...GET./sea
        0x0030:  7263 683f 686c 3d65 6e26 713d 7465 7374  rch?hl=en&q=test
        0x0040:  2662 746e 473d 476f 6f67 6c65 2b53 6561  &btnG=Google+Sea
        0x0050:  7263                                     rc

Note: il existe des frontends plus graphiques et intuitifs comme Ethereal/Wireshark?.

iptraf

Cet outil est comparable aux mécanismes de tcpdump, mais n'utilise que des filtrage par catégories simple (interface, protcole) et une interface console interactive simple et efficace. Il est très pratique pour effectuer un monitoring instantané et grossier, et permet souvent de répondre à la fameuse question "qui consomme toute la bande passante" ?

strace

Parfois on s'interesse uniquement au traffic reçu ou émis par un processus particulier de la machine. Dans ce cas, on peut observer le comportement de ces programme en interceptant ses appels systèmes, en particulier tout ceux afférents aux E/S. Il n'est pas nécessaire d'être root si le programme qu'on veut étudier nous appartient. Exemple avec son navigateur, s'il tourne avec le PID 1234:

$ strace -e read,write -p 1234
read(3, "\1\2\225S\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0"..., 32) = 32
read(3, "n\2\225S\0279\326\326\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32) = 32
write(3, "\222\4\2\0\0\1 \3", 8)        = 8
[...] 

Note: sous Unix on ne peut facilement pas distinguer les fichiers et le réseau car leur API est unifiée.

2. Configuration réseau

Les interfaces

Les interfaces peuvent être dans plusieurs états:

  • Down: l'interface est détectée mais non utilisée, elle ne peut ni recevoir ni émettre
  • Up: l'interface est active, elle peut recevoir et émettre, mais seulement au niveau de la couche de transport (ex: Ethernet)
  • Up et configurée: un protocole de routage est associé (exemple: IP), cette interface peut être utilisée "normalement"

N'oubliez pas que les fichiers de configuration (par ex. /etc/network/interfaces reflètent les intentions de l'administrateur système, alors que les résultats des commandent reflètent ce qui est réellement configuré. En temps normal, ces informations doivent être synchrones.

Sous Linux, on obtient toutes les interface (quel que soit leur état) avec ifconfig -a. Une interface Up est indiquée en tant que tel et fournit des informations propre à la couche de transport (ici Ethernet):

  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

Une interface up et configurée rajoute le nom du protocol et les informations de routage afférentes (ici IP):

  inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0

Le nommage des interfaces est arbitraire et même parfois fantaisiste (sous Linux on trouve eth, wlan, ath, wifi, etc. pour des interfaces WiFi?). Mais surtout l'ordre de détection (eth0, eth1, etc) dépend de nombreux paramètres imprévisibles: position de la carte sur le bus, configuration du BIOS, noyau, etc. Le seul indice constant qui permet de reconnaître une interface est son adresse matérielle (MAC pour Ethernet). Sous Debian GNU/Linux, une règle udev permet d'associer un nom à une interface selon son adresse Mac, évitant ainsi de désagréables surprises:

# cat /etc/udev/rules.d/z25_persistent-net.rules

# PCI device 14e4:4401 (b44)
ACTION=="add", SUBSYSTEM=="net", DRIVERS=="?*", SYSFS{address}=="00:0f:1f:19:34:6b", NAME="eth0"

La table de routage

Celle-ci est en général composée de:

  • 1 route par interface, en général installée automatiquement quand l'interface est configurée (route du sous-réseau local)
  • 1 route par défaut, pour atteindre tous les autres sous-réseau (en général, "Internet")
# route -n
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0
0.0.0.0         192.168.1.253   0.0.0.0         UG    0      0        0 wlan0

Note: la route pour l'interface loopback est souvent absente (mais implicite).

Sur un routeur on peut également définir des règle de routage explicites (souvent appelées "routes statiques") et des routes de "rejet" pour explicitement interdire le relais vers une certaine destination.

3. Utilisation des protocoles

ARP

Ce protocole est souvent ignoré, mais il est toujours présente sur un réseau de type Ethernet transportant des paquets IP, donc la vaste majorité des réseaux. Il permet d'effectuer l'association entre les adresses matérielles (MAC) et logiques (IP). Le noyau maintient une telle table de correspondance:

# arp -nv
Address                  HWtype  HWaddress           Flags Mask            Iface
82.67.65.254             ether   00:07:CB:0B:8C:8C   C                     eth0
192.168.1.1              ether   00:90:96:B8:73:62   C                     eth1

De par la nature de ce protocole, vous ne pourrez "pinger une adresse MAC" que si l'interface visée est configurée au niveau IP (pour recevoir la réponse).

Il est aussi classique de voir sa machine rester invisible pendant quelques minutes à travers un switch, car ces derniers maintiennent une association MAC/IP relativement persistente (cf. spanning tree). On peut forcer la mise à jour du switch en envoyant une requête ARP concernant sa propre IP: elle est normalement inutile, mais dans cas précis elle a la capacité de notifier sa nouvelle adresse (appelée gratuitous ARP).

ICMP

C'est notamment le protocole utilisé par ping pour envoyer un paquet de test et se voir retourner la réponse. Bien que ce soit un test classique, il ne faut pas oublier qu'il teste simultanément de nombreux éléments du réseau:

  • le fonctionnement de la résolution de nom si une adresse numérique n'est pas utilisée
  • la configuration de la table de routage locale
  • la configuration et le fonctionnement de l'interface locale
  • le fonctionnement des équipements intermédiaires, physiques (câbles) comme logiques (modems, routeurs)

Un ping qui fonctionne n'est pas nécessairement signe d'une communication IP parfaite: il peut y avoir des équipements filtrant sur le chemin des paquets (firewall, shaper).

Enfin, un ping qui fonctionne partiellement peut être l'indication de problèmes matériels (mauvais signal WiFi?, câble dégradé) comme d'un routeur congestionné.

IP

Il n'existe pas vraiment d'outils de diagnostique au niveau IP, on repose souvent sur les couches applicatives (SNMP, etc). Mais il existe notamment l'outil traceroute qui permet notamment d'évaluer le nombre d'équipements traversés, et souvent les équipements "invisibles":

traceroute to google.fr (216.239.59.104), 30 hops max, 40 byte packets
 1  raq.home (192.168.1.253)  2.281 ms  10.518 ms  1.301 ms
 2  mutualite-2-82-67-65-254.fbx.proxad.net (82.67.65.254)  46.917 ms  41.309 ms  40.998 ms
 3  grenoble-6k-1-a5.routers.proxad.net (213.228.10.62)  47.527 ms  40.204 ms  40.576 ms
 4  lyon-6k-1-v802.intf.routers.proxad.net (212.27.50.105)  44.089 ms  41.747 ms  41.944 ms
 5  * * lyon-6k-2-po1.intf.routers.proxad.net (212.27.57.122)  43.253 ms
 6  * * *
 7  * * *
 8  * * *
 9  google.freeix.net (213.228.3.136)  50.979 ms  54.760 ms  49.921 ms
10  72.14.232.94 (72.14.232.94)  63.838 ms  62.659 ms  64.753 ms
11  66.249.95.107 (66.249.95.107)  73.292 ms  72.944 ms  73.149 ms
12  72.14.232.241 (72.14.232.241)  73.412 ms  78.914 ms  95.898 ms
13  216.239.49.114 (216.239.49.114)  76.158 ms 216.239.49.126 (216.239.49.126)  75.660 ms  77.912 ms
14  gv-in-f104.google.com (216.239.59.104)  74.412 ms  74.899 ms  73.193 ms

DNS

Très souvent on observe des problèmes réseau qui sont tout simplement dû à un problème de configuration DNS. Cela vient du fait que l'usage naturel d'internet (navigation, mail, etc) repose sur des noms de domaines, et non des adresses numériques. Les outils les plus classiques pour tester le serveur DNS srv sont:

# host google.fr srv
# dig @srv google.fr

Note: pour le mail, un champ particulier (MX) doit être testé.

SNMP

Il s'agit du protocole standard pour interroger des équipements à distance sur à peu près tous les aspects abordés dans ce cours. Il est simple à mettre en place et donne immédiatement l'ensemble des informations de façon hiérarchique. Par contre, la quantité d'information et sa présentation nécessitent souvent des outils de plus haut niveau pour être accessible (ex: MRTG, Cacti, etc).

# snmpwalk -v1 -cpublic equipement
HOST-RESOURCES-MIB::hrDiskStorageCapacity.1536 = INTEGER: 39082680 KBytes
HOST-RESOURCES-MIB::hrDiskStorageCapacity.1538 = INTEGER: 39082680 KBytes
HOST-RESOURCES-MIB::hrDiskStorageCapacity.1552 = INTEGER: 117220824 KBytes
HOST-RESOURCES-MIB::hrDiskStorageCapacity.1568 = INTEGER: 999808 KBytes
HOST-RESOURCES-MIB::hrDiskStorageCapacity.1569 = INTEGER: 999872 KBytes
HOST-RESOURCES-MIB::hrDiskStorageCapacity.1570 = INTEGER: 36082752 KBytes
[...]
Last modified 13 years ago Last modified on Feb 19, 2007, 12:03:17 AM