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 [...]
