Ethernet et ARP

Pourquoi

La leçon 1 a enveloppé la requête GET /sante de Camille dans un segment TCP, puis dans un paquet IP adressé à 203.0.113.10. Il reste à la faire sortir de l'ordinateur. Et là, une difficulté apparaît : la carte réseau ne sait rien des adresses IP. Elle parle Ethernet (ou Wi-Fi), et sur ce réseau local, on ne désigne pas une machine par son adresse IP mais par son adresse MAC, un identifiant matériel de 48 bits.

Le poste de Camille doit donc répondre à une question avant d'émettre quoi que ce soit : « à quelle adresse MAC dois-je envoyer cette trame ? » Ce n'est pas celle de 203.0.113.10, qui est à des centaines de kilomètres, mais celle de la box, le premier routeur sur le chemin. Et pour connaître l'adresse MAC de la box, dont il ne connaît que l'adresse IP (192.168.1.1), il utilise un protocole de 1982, toujours là, présent sur chaque réseau IPv4 du monde : ARP.

Comprendre ce niveau sert tous les jours, sans que l'on s'en rende compte :

• un serveur dont on a changé la carte réseau, ou une machine virtuelle recréée avec la même adresse IP, est injoignable pendant quelques minutes, puis « revient tout seul » : c'est un cache ARP périmé ;
• deux machines configurées avec la même adresse IP se volent le trafic l'une de l'autre, de façon intermittente ;
• une bascule d'adresse IP entre deux serveurs (Keepalived, Pacemaker) fonctionne dans la salle machine de l'entreprise, mais pas chez un fournisseur de cloud ;
• une machine compromise sur un réseau local peut intercepter le trafic de ses voisines.

Les concepts

Ethernet en deux paragraphes d'histoire

Ethernet est né en 1973 chez Xerox PARC, sous la plume de Robert Metcalfe : un câble coaxial partagé, où chaque machine émet quand le câble est libre et réessaie plus tard en cas de collision. Digital, Intel et Xerox en publient une version commune au début des années 1980 (Ethernet II, ou DIX), et l'IEEE la normalise sous le nom 802.3 en 1983. Le débit est alors de 10 Mbit/s.

Quarante ans plus tard, presque tout a changé : les câbles sont des paires torsadées ou des fibres, chaque machine a son propre lien vers un commutateur, les échanges se font dans les deux sens en même temps, et les débits vont de 1 à 400 Gbit/s. Les collisions ont disparu. Ce qui est resté, c'est le format de la trame et les adresses MAC : c'est ce que le reste de la pile voit, et c'est ce qui nous intéresse.

La trame Ethernet

Une trame Ethernet II, telle que la pile réseau la construit, se compose ainsi :

Sur le câble, la trame est précédée d'un préambule de 8 octets qui permet au récepteur de se synchroniser, et suivie d'un silence obligatoire de 12 octets. Les en-têtes du noyau Linux donnent ces tailles : ETH_ALEN 6 pour une adresse, ETH_HLEN 14 pour l'en-tête, ETH_DATA_LEN 1500 pour la charge maximale, ETH_ZLEN 60 pour la taille minimale d'une trame sans FCS. Une trame trop courte est complétée par des octets de bourrage jusqu'à 60 octets (64 avec la FCS).

Quelques remarques importantes :

• Destination d'abord. L'adresse de destination est en tête de trame, pour qu'un équipement puisse décider très tôt de la transmettre ou de l'ignorer.
• L'EtherType est le lien avec la couche du dessus. Les valeurs sont enregistrées par l'IEEE et recensées par l'IANA. Une valeur inférieure ou égale à 1500 (0x05DC) n'est pas un type mais une longueur : c'est le format IEEE 802.3 d'origine, encore utilisé par quelques protocoles de gestion des commutateurs.
• La FCS ne fait que détecter. Une trame dont la somme ne correspond pas est jetée sans un mot, par la carte elle-même. Ethernet ne retransmet rien : si la trame contenait un segment TCP, c'est TCP, aux extrémités, qui s'apercevra de la perte (principe de bout en bout, leçon 1). Les compteurs d'erreurs de la carte (ip -s link) sont le seul témoin.

Les adresses MAC

Une adresse MAC (Media Access Control) fait 48 bits, écrits en six octets hexadécimaux : 00:00:5e:00:53:01. Elle est en principe gravée dans la carte par le constructeur. Elle se lit ainsi :

• Les trois premiers octets forment l'OUI (Organizationally Unique Identifier), attribué par l'IEEE à un constructeur. Les trois suivants sont choisis par ce constructeur pour chaque carte. Des sites et des outils (dont la base oui.txt publiée par l'IEEE) retrouvent le constructeur à partir de l'OUI.
• Dans le premier octet, deux bits ont un sens particulier, comme le rappelle la RFC 9542 :
  • le bit de poids le plus faible est le bit de groupe (I/G) : 0 pour une adresse individuelle (unicast), 1 pour une adresse de groupe (multicast) ;
  • le bit suivant est le bit local (U/L) : 0 pour une adresse universelle attribuée par un constructeur, 1 pour une adresse administrée localement, choisie par un logiciel.
• L'adresse ff:ff:ff:ff:ff:ff (tous les bits à 1) est l'adresse de diffusion (broadcast) : la trame est pour tout le monde sur le réseau local.

Lisons deux exemples. 00:00:5e:00:53:01 : premier octet 00, soit 0000 0000 en binaire, adresse individuelle et universelle ; l'OUI 00:00:5e appartient à l'IANA, et la RFC 9542 réserve la plage 00:00:5e:00:53:00 à 00:00:5e:00:53:ff aux exemples de documentation, d'où son emploi dans ce cours. 02:42:ac:11:00:02 : premier octet 02, soit 0000 0010, bit local à 1 : adresse générée par un logiciel. C'est le cas des interfaces virtuelles des conteneurs et des machines virtuelles, et des cartes Wi-Fi des téléphones récents, qui présentent une adresse aléatoire différente à chaque réseau pour éviter d'être pistées.

Le commutateur et le domaine de diffusion

Sur un réseau local moderne, toutes les machines sont reliées à un commutateur (switch). Son travail est simple et entièrement automatique :

1. Il apprend. Pour chaque trame reçue, il note l'adresse MAC source et le port par lequel elle est arrivée, dans sa table d'adresses (la table MAC, ou CAM table). Une entrée non rafraîchie expire, au bout de 300 secondes par défaut selon la norme IEEE 802.1D.
2. Il aiguille. Pour la MAC destination, il consulte sa table : si elle est connue, il envoie la trame uniquement sur le port correspondant.
3. Il inonde ce qu'il ne connaît pas. Si la destination est inconnue, ou si c'est l'adresse de diffusion ou une adresse de groupe, il envoie la trame sur tous les ports sauf celui d'arrivée.

Son ancêtre, le concentrateur (hub), répétait chaque trame sur tous les ports, sans rien apprendre : chaque machine voyait le trafic de toutes les autres. Le commutateur l'a remplacé partout, pour le débit d'abord, et pour la discrétion ensuite.

L'ensemble des machines qu'atteint une trame de diffusion forme un domaine de diffusion : en pratique, un réseau local, avec ses commutateurs. Un routeur ne transmet pas les diffusions : il marque la frontière du domaine. C'est une notion clé : deux machines du même domaine de diffusion se parlent directement, de MAC à MAC ; deux machines de domaines différents passent obligatoirement par un routeur (leçon 5). Un domaine de diffusion correspond en général à un sous-réseau IP (leçon 4).

Les VLAN

Un commutateur d'entreprise relie souvent des machines qui ne devraient pas se voir : les postes des employés, les serveurs, les caméras, le Wi-Fi des invités. Plutôt qu'acheter un commutateur par usage, on découpe un même commutateur en plusieurs réseaux logiques, les VLAN (Virtual LAN), définis par la norme IEEE 802.1Q. Chaque VLAN est un domaine de diffusion séparé : une diffusion du VLAN 10 n'atteint pas le VLAN 20, et passer de l'un à l'autre exige un routeur, donc un point où l'on peut filtrer.

Entre deux commutateurs, ou vers un serveur qui doit appartenir à plusieurs VLAN, les trames portent une étiquette de 4 octets insérée après les adresses MAC : l'EtherType spécial 0x8100, suivi d'un champ de 16 bits dont 12 donnent le numéro de VLAN (de 1 à 4094 en pratique). Linux sait créer une interface pour un VLAN avec ip link add link ens2 name ens2.10 type vlan id 10.

ARP : d'une adresse IP à une adresse MAC

Revenons au poste de Camille. Il veut envoyer un paquet à 203.0.113.10. Sa table de routage (leçon 5) lui dit que cette adresse n'est pas sur son réseau local, et qu'il faut passer par la box, 192.168.1.1. Il faut donc construire une trame Ethernet dont la destination est l'adresse MAC de la box. Le protocole ARP (Address Resolution Protocol), décrit en novembre 1982 par David Plummer dans la RFC 826, la lui fournit :

    sequenceDiagram
  participant C as Poste de Camille<br/>192.168.1.23<br/>00:00:5e:00:53:01
  participant R as Autres machines<br/>du réseau local
  participant B as Box<br/>192.168.1.1<br/>00:00:5e:00:53:fe
  C->>R: Diffusion (ff:ff:ff:ff:ff:ff) : qui a 192.168.1.1 ? Répondez à 192.168.1.23
  C->>B: (la même trame de diffusion)
  B->>C: Réponse directe : 192.168.1.1 est à 00:00:5e:00:53:fe
  Note over C: Mémorise la correspondance dans son cache
  C->>B: Trame vers 00:00:5e:00:53:fe contenant le paquet IP pour 203.0.113.10
  

1. Le poste émet une requête ARP en diffusion : « Qui a l'adresse 192.168.1.1 ? Répondez à 192.168.1.23, adresse MAC 00:00:5e:00:53:01. »
2. Toutes les machines du domaine de diffusion la reçoivent. Seule celle qui possède 192.168.1.1 répond, par une réponse ARP envoyée directement (unicast) au demandeur : « 192.168.1.1 est à 00:00:5e:00:53:fe. »
3. Le poste range la correspondance dans son cache ARP et envoie enfin sa trame.

Un message ARP est transporté directement dans une trame Ethernet (EtherType 0x0806), sans IP. Il contient neuf champs : le type de matériel (Ethernet), le type de protocole (IPv4), les longueurs des deux adresses (6 et 4), le code d'opération (requête ou réponse), puis les adresses MAC et IP de l'expéditeur et de la cible.

Un détail de la RFC 826 a des conséquences pratiques : à la réception d'une requête qui le concerne, une machine enregistre la correspondance de l'expéditeur avant même de regarder s'il s'agit d'une question, en se disant que si A veut parler à B, B voudra bientôt répondre à A. La box connaît donc l'adresse MAC de Camille sans avoir eu à la demander.

Point essentiel : ARP ne sert qu'à atteindre un voisin, une machine du même réseau local. Le poste de Camille ne connaîtra jamais l'adresse MAC de sig-app-1 : il ne connaît que celle de la box. À chaque traversée de routeur, la trame est reconstruite avec de nouvelles adresses MAC, alors que les adresses IP du paquet, elles, restent les mêmes de bout en bout (sauf traduction d'adresses, leçon 7). Les adresses MAC disent « d'ici au prochain saut », les adresses IP disent « d'ici à la destination finale ».

En IPv6, ARP n'existe pas : son rôle est tenu par le protocole de découverte des voisins (NDP), qui utilise des messages ICMPv6 en multidiffusion plutôt qu'une diffusion générale. La leçon 8 le présente.

Le cache des voisins sous Linux

Linux ne garde pas les réponses ARP éternellement. Il gère une table des voisins (neighbour table), commune à ARP et à NDP, où chaque entrée a un état. Les principaux, d'après ip-neighbour(8) :

Une entrée passe de REACHABLE à STALE au bout d'un temps tiré au hasard autour de base_reachable_time_ms, 30 secondes par défaut (arp(7)). Le hasard évite que toutes les machines d'un réseau revérifient leurs voisins au même instant. La confirmation peut venir d'une nouvelle réponse ARP, mais aussi des couches supérieures : un accusé de réception TCP prouve que le voisin est vivant, sans qu'il soit besoin de l'interroger. Une entrée inutilisée depuis gc_stale_time (60 secondes par défaut) devient candidate au ramasse-miettes, qui la supprime quand la table grossit.

Annoncer une adresse, et la déplacer

Une machine qui prend une adresse IP peut l'annoncer d'elle-même, sans qu'on lui demande rien. La RFC 5227 de Stuart Cheshire (2008) définit deux messages :

• la sonde ARP (ARP Probe) : une requête dont l'adresse IP de l'expéditeur vaut 0.0.0.0 et dont la cible est l'adresse convoitée, pour demander « quelqu'un utilise-t-il déjà cette adresse ? » avant de la prendre ;
• l'annonce ARP (ARP Announcement) : une requête dont l'adresse de l'expéditeur et celle de la cible sont toutes deux l'adresse prise, pour dire « c'est désormais moi qui ai cette adresse ».

L'annonce est l'héritière de ce que l'on appelle depuis longtemps l'ARP gratuit (gratuitous ARP). Elle sert aux bascules : quand un service de haute disponibilité comme Keepalived déplace une adresse IP virtuelle d'un serveur tombé vers un serveur de secours, ce dernier émet une annonce ; les voisins et les commutateurs mettent à jour leurs tables, et le trafic suit en une fraction de seconde au lieu d'attendre l'expiration des caches.

Sous Linux, plusieurs réglages du noyau encadrent ces messages (documentation ip-sysctl) : arp_accept décide si une annonce reçue peut créer une entrée (non, par défaut : elle ne fait que mettre à jour une entrée existante) ; arp_notify fait émettre une annonce quand une interface démarre ou change d'adresse MAC (désactivé par défaut) ; arp_ignore règle à quelles requêtes la machine répond.

Et dans le cloud ?

Le réseau privé d'un fournisseur de cloud n'est pas un câble et un commutateur : c'est un réseau virtuel, construit par logiciel au-dessus du réseau physique du centre de données. Il émule plus ou moins fidèlement un réseau local. Chez Scaleway, un réseau privé se présente comme un segment de niveau 2 à l'échelle d'une région, comme l'a montré le cours Le cloud : les fondamentaux : sig-app-1 et sig-app-2 y obtiennent leurs adresses par DHCP et se joignent directement. Mais l'émulation a des limites qui varient d'un fournisseur à l'autre. Ivan Pepelnjak, spécialiste reconnu des réseaux, résume ainsi la situation chez AWS : les astuces de niveau 2 ne fonctionnent pas, les protocoles de redondance de passerelle non plus, et les grappes qui déplacent une adresse IP de service par ARP gratuit non plus. Dans le cloud, on déplace une adresse par l'API du fournisseur (une IP flexible que l'on réattache, une route que l'on modifie), pas par une annonce ARP.

En pratique

Les commandes suivantes sont en lecture seule et ne demandent pas de droits particuliers, sauf mention. Les sorties ont été produites sur le poste Ubuntu 24.04 de Camille, relié en Wi-Fi à une box ; adresses IP et MAC ont été remplacées par des adresses de documentation.

Les interfaces et leur adresse MAC

$ ip link show wlo1
2: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
    link/ether 00:00:5e:00:53:01 brd ff:ff:ff:ff:ff:ff
    altname wlp0s20f3

Lisons la ligne :

• 2: est l'index de l'interface dans le noyau, wlo1 son nom (Wi-Fi intégré à la carte mère). Sur un serveur, vous verrez plutôt ens2, enp1s0 ou eth0. altname donne un autre nom, ici celui qui dérive de son emplacement sur le bus PCI.
• Entre chevrons, les drapeaux : BROADCAST (le lien sait diffuser), MULTICAST, UP (l'interface a été activée par l'administrateur) et LOWER_UP (le lien physique est établi : câble branché, ou association Wi-Fi faite). UP sans LOWER_UP, c'est une interface activée mais sans câble, le premier diagnostic à faire.
• mtu 1500 : la charge maximale d'une trame, celle d'Ethernet.
• state UP : l'état opérationnel. mode DORMANT est propre au Wi-Fi : l'interface attend que l'authentification auprès du point d'accès soit terminée avant de passer en service.
• link/ether : le type de lien, Ethernet, suivi de l'adresse MAC de l'interface, puis de l'adresse de diffusion (brd).

Une interface Wi-Fi est présentée par Linux comme une interface Ethernet : le pilote et la pile Wi-Fi du noyau convertissent les trames 802.11 de l'air en trames Ethernet pour le reste de la pile.

La forme abrégée ip -br link donne une ligne par interface, avec la MAC et les drapeaux. L'interface lo y apparaît avec l'adresse 00:00:00:00:00:00 et l'état UNKNOWN : elle n'a pas de vrai lien, elle se contente de renvoyer les paquets à la machine.

Le cache des voisins

$ ip -4 neigh show dev wlo1
192.168.1.1 lladdr 00:00:5e:00:53:fe REACHABLE

Le poste connaît un seul voisin IPv4 sur ce réseau : la box, dont l'entrée est REACHABLE, confirmée récemment. lladdr (link-layer address) est l'adresse MAC. Sans -4, la commande montre aussi les voisins IPv6, découverts par NDP. Pour des statistiques sur chaque entrée (nombre de références, temps depuis la dernière utilisation et la dernière confirmation, nombre de sondes), ajoutez -s : ip -s -4 neigh show dev wlo1.

L'ancienne interface est toujours lisible dans /proc/net/arp, une table à colonnes fixes (adresse IP, type de matériel 0x1 pour Ethernet, drapeaux, adresse MAC, interface).

Provoquer un échange ARP

Sur une machine de laboratoire où vous avez les droits sudo, vous pouvez vider le cache et observer sa reconstruction. Les commandes suivantes ne sont pas accompagnées de sortie, parce qu'elles dépendent de votre réseau :

$ sudo ip neigh flush dev ens2       # vide les entrées dynamiques de l'interface
$ ip neigh show dev ens2             # la passerelle n'y est plus, ou en FAILED/INCOMPLETE
$ ping -c 1 172.16.20.1              # un paquet vers la passerelle déclenche une requête ARP
$ ip neigh show dev ens2             # l'entrée réapparaît en REACHABLE

Pour voir les trames ARP passer, il faut une capture, qui demande aussi des droits :

$ sudo tcpdump -n -e -i ens2 arp

• -n : ne pas traduire les adresses en noms ;
• -e : afficher les adresses MAC de chaque trame, ce qui est tout l'intérêt ici ;
• arp : un filtre qui ne garde que les trames d'EtherType 0x0806.

Vous verrez une requête who-has 172.16.20.1 tell 172.16.20.11 adressée à ff:ff:ff:ff:ff:ff, puis une réponse is-at adressée directement à l'adresse MAC de sig-app-1. La leçon 12 détaille tcpdump.

Envoyer une annonce

Le programme arping (paquet iputils-arping sur Ubuntu) envoie des requêtes ARP à la main. Avec l'option -U, il envoie des annonces non sollicitées, ce que fait un service de bascule :

$ sudo arping -c 2 -U -I ens2 172.16.20.50

C'est l'occasion de vérifier, sur votre réseau de laboratoire, si les voisins mettent à jour leur cache (ip neigh sur une autre machine). Ne faites pas cela sur un réseau que vous ne maîtrisez pas : annoncer une adresse qui ne vous appartient pas est précisément une attaque (voir Sécurité).

Sous le capot

La table des voisins est la colle entre IP et Ethernet. Quand la couche IP du noyau a choisi une route (leçon 5), elle connaît l'adresse IP du prochain saut : la destination elle-même si elle est sur le réseau local, la passerelle sinon. Elle confie alors le paquet au sous-système de voisinage, qui cherche l'adresse MAC correspondante. Si l'entrée existe, la trame part immédiatement. Sinon, le paquet est mis en attente dans une petite file associée à l'entrée INCOMPLETE, une requête ARP est émise, et la file est vidée quand la réponse arrive. Si personne ne répond (trois tentatives par défaut, mcast_solicit), l'entrée passe en FAILED et le paquet est abandonné ; l'application reçoit alors une erreur No route to host (EHOSTUNREACH), qui, malgré son nom, signale souvent un voisin muet plutôt qu'une route absente.

Pourquoi l'état STALE existe. Interroger un voisin avant chaque paquet serait ruineux, et ne jamais l'interroger serait dangereux (une machine remplacée garderait l'ancienne MAC). Le compromis de Linux, repris de la découverte des voisins d'IPv6 : une entrée périmée continue d'être utilisée, mais son premier usage déclenche une vérification. Si une confirmation arrive des couches supérieures dans les 5 secondes (delay_first_probe_time, par exemple un accusé de réception TCP), aucune requête n'est émise ; sinon, le noyau interroge le voisin directement, en unicast, avant de recourir à la diffusion.

Le commutateur ne lit pas l'en-tête IP. Pour lui, une trame ARP, une trame IPv4 et une trame IPv6 sont toutes des trames : il n'examine que les adresses MAC. C'est pour cela qu'on dit qu'il travaille « en couche 2 ». Les commutateurs modernes savent aussi lire plus haut (commutateurs « de niveau 3 », inspection ARP), mais c'est une fonction ajoutée.

Pièges courants

Une machine remplacée, injoignable quelques minutes. Vous recréez une machine virtuelle avec la même adresse IP mais une nouvelle MAC. Les voisins utilisent l'ancienne entrée, en STALE, jusqu'à ce que la vérification échoue, puis interrogent à nouveau. Selon les équipements (un pare-feu ou un routeur peut garder ses entrées plusieurs minutes, voire quatre heures sur certains équipements réseau), l'attente peut être longue. Parade : une annonce ARP au démarrage (arp_notify=1, ou arping -U), ou vider le cache du routeur.

Deux machines avec la même adresse IP. Les symptômes sont intermittents et déroutants : les connexions marchent, puis cassent, puis remarchent, au gré des réponses ARP de l'une ou de l'autre. Le diagnostic : une même adresse IP associée à deux MAC différentes au fil du temps (ip neigh à plusieurs reprises, ou tcpdump -e arp). La RFC 5227 décrit précisément la détection de ce conflit ; arping -D l'applique.

UP mais pas LOWER_UP. L'interface est activée, mais le lien n'est pas établi : câble débranché, port de commutateur désactivé, mauvaise vitesse négociée, ou, pour une interface virtuelle, autre extrémité absente. Inutile de chercher plus haut.

Une bascule par ARP gratuit qui ne marche pas dans le cloud. Voir Et dans le cloud ? : chez beaucoup de fournisseurs, le réseau virtuel ignore ces annonces. Utilisez le mécanisme du fournisseur (IP flexible déplacée par l'API, répartiteur de charge avec vérification de santé).

Croire qu'un réseau Wi-Fi se comporte comme un câble. Les points d'accès isolent souvent les clients les uns des autres (isolation des clients sur les réseaux invités), filtrent certaines diffusions, ou répondent eux-mêmes aux requêtes ARP. Une expérience de couche 2 se fait de préférence sur un réseau filaire ou virtuel que vous contrôlez.

Sécurité

ARP date d'une époque où tous les ordinateurs d'un réseau se faisaient confiance. Il n'a aucune authentification : n'importe quelle machine peut répondre à n'importe quelle requête, ou envoyer des réponses que personne n'a demandées. Plusieurs attaques en découlent :

• L'usurpation ARP (ARP spoofing, ou empoisonnement du cache). Une machine malveillante annonce à la victime « 192.168.1.1 est à mon adresse MAC », et à la box « 192.168.1.23 est à mon adresse MAC ». Tout le trafic entre les deux passe désormais par elle : c'est une attaque de l'homme du milieu, réalisable avec des outils grand public, sans aucun privilège sur la victime. Le simple fait d'être branché sur le même réseau local suffit.
• La saturation de la table MAC (MAC flooding). L'attaquant envoie des milliers de trames avec des adresses MAC source aléatoires. La table du commutateur se remplit ; incapable d'apprendre, il se met à inonder toutes les trames vers tous les ports, comme un vieux concentrateur, et l'attaquant voit passer le trafic des autres.
• Le saut de VLAN (VLAN hopping) exploite des configurations de ports mal réglées pour envoyer des trames dans un VLAN auquel on ne devrait pas avoir accès.

Les parades existent, à plusieurs niveaux :

• Sur le commutateur : limiter le nombre d'adresses MAC par port (port security), vérifier les réponses ARP contre la table des baux DHCP (inspection ARP dynamique), authentifier les machines avant de leur ouvrir le port (802.1X), désactiver les ports inutilisés.
• Sur les machines critiques : des entrées ARP statiques (ip neigh add ... nud permanent) pour la passerelle, au prix d'une maintenance manuelle.
• Surtout, de bout en bout : un attaquant qui détourne le trafic ne peut ni lire ni modifier une connexion TLS ou SSH correctement vérifiée. Le réseau local n'est pas une zone de confiance ; c'est l'argument de bout en bout de la leçon 1, appliqué à la sécurité.

Dans le cloud, le réseau virtuel du fournisseur ne livre en général les trames qu'aux adresses qu'il a lui-même attribuées, ce qui rend ces attaques beaucoup plus difficiles entre clients. À l'intérieur de votre propre réseau privé, en revanche, une de vos machines compromise reste une voisine : on ne place pas sur le même réseau privé des machines de niveaux de confiance très différents.

En production

• Gardez les domaines de diffusion petits. Une diffusion réveille toutes les machines du domaine ; à plusieurs milliers de machines, ARP, DHCP et les découvertes de services représentent un bruit de fond notable, et une boucle entre commutateurs (une tempête de diffusion) paralyse tout le domaine. On découpe en VLAN et en sous-réseaux de quelques centaines de machines au plus.
• Surveillez les compteurs des interfaces. ip -s link show dev ens2 donne, pour chaque sens, les octets, paquets, erreurs et pertes. Des erreurs qui augmentent (FCS invalides) trahissent un câble, un connecteur ou une carte défaillants ; les pertes (dropped) signalent souvent une file de réception saturée.
• Annoncez-vous au démarrage. Sur les machines dont l'adresse peut changer de MAC (bascules, machines recréées), activez arp_notify ou faites émettre une annonce par l'outil de bascule.
• Dans le cloud, faites confiance à l'API, pas à la couche 2. Les mécanismes de redondance se configurent chez le fournisseur : IP flexibles, répartiteurs de charge, routes. Le cours cloud les met en place pour Signalements.

Exercices

1. Lire des adresses MAC (niveau 100). Pour chacune de ces adresses, dites si elle est individuelle ou de groupe, universelle ou locale : (a) 00:00:5e:00:53:2a ; (b) 01:00:5e:00:00:fb ; (c) 3a:f2:10:9c:44:01 ; (d) ff:ff:ff:ff:ff:ff.

2. Suivre les adresses (niveau 100). La requête de Camille part de son poste (192.168.1.23, MAC 00:00:5e:00:53:01), passe par la box (côté local 192.168.1.1, MAC 00:00:5e:00:53:fe), traverse Internet, puis atteint le répartiteur 203.0.113.10. Sur le premier lien (poste vers box), quelles sont les adresses MAC source et destination de la trame, et les adresses IP source et destination du paquet ? Lesquelles changeront au prochain saut ?

3. Le serveur remplacé (niveau 100). L'équipe recrée sig-app-2 à l'identique : même adresse privée 172.16.20.12, nouvelle machine virtuelle. Pendant quelques dizaines de secondes, sig-app-1 ne parvient pas à la joindre, puis tout rentre dans l'ordre. Expliquez avec les états du cache des voisins, et proposez deux moyens d'éviter cette attente.

4. Repérer une usurpation (niveau 200). Sur un réseau de laboratoire, vous observez avec ip neigh que l'adresse de la passerelle est associée tantôt à une MAC, tantôt à une autre, et que la seconde MAC est aussi celle d'une autre machine du réseau. Que se passe-t-il probablement, quelles vérifications faites-vous, et quelles mesures proposez-vous ?

Récapitulatif

• Une trame Ethernet porte les adresses MAC de destination et de source, un EtherType (0x0800 IPv4, 0x86DD IPv6, 0x0806 ARP, 0x8100 VLAN), 46 à 1 500 octets de données et une FCS qui détecte les erreurs sans les corriger.
• Une adresse MAC fait 48 bits : un OUI de constructeur, un bit de groupe et un bit local dans le premier octet ; ff:ff:ff:ff:ff:ff est la diffusion. Elle n'est ni secrète ni fiable.
• Le commutateur apprend les MAC source, aiguille selon les MAC destination, inonde l'inconnu. Un domaine de diffusion s'arrête aux routeurs ; les VLAN (802.1Q) découpent un commutateur en plusieurs domaines.
• ARP traduit l'adresse IP d'un voisin en adresse MAC : requête en diffusion, réponse directe, cache. Les adresses MAC changent à chaque saut, les adresses IP restent.
• Sous Linux, ip neigh montre la table des voisins et ses états (REACHABLE, STALE, FAILED...) ; ip link montre les interfaces, leurs drapeaux (UP, LOWER_UP) et leur MTU.
• L'annonce ARP (RFC 5227) sert aux bascules d'adresse, mais pas chez la plupart des fournisseurs de cloud, où l'on passe par l'API.
• ARP n'a aucune authentification : usurpation et saturation sont faciles sur un réseau local, d'où les protections des commutateurs et, surtout, le chiffrement de bout en bout.

Pour aller plus loin

• La RFC 826, courte et lisible, et la RFC 5227, qui raconte avec précision les pièges de la détection de conflits d'adresses.
• TCP/IP Illustrated, Volume 1, chapitres 3 (la couche lien) et 4 (ARP).
• La page de manuel arp(7), pour tous les réglages du cache des voisins sous Linux.
• La leçon suivante, qui s'intéresse enfin aux adresses IP elles-mêmes.