Une adresse IPv4 est un identifiant numérique de 32 bits, affiché en notation décimale pointée (quatre octets séparés par des points). Avec un espace limité à quelques milliards de combinaisons possibles, chaque erreur de configuration gaspille des ressources rares et peut couper la communication entre plusieurs machines d’un réseau. Trois catégories d’erreurs reviennent dans la majorité des incidents : le chevauchement de plages, l’attribution statique mal documentée et les conflits liés au serveur DHCP.
Chevauchement de plages IPv4 dans les architectures cloud et VPC
Les erreurs de plage réseau ne se limitent plus aux réseaux locaux physiques. Dans les environnements cloud managés, la documentation Google Cloud signale des règles de validation strictes sur les sous-réseaux IPv4 : interdiction de créer un sous-réseau qui chevauche certaines plages réservées comme 169.254.0.0/16 ou 192.0.0.0/24, et interdiction de mélanger une plage RFC 1918 avec des adresses publiques dans un même sous-réseau.
A voir aussi : Comment se connecter à webmail Nantes sans erreur de mot de passe ?
Le piège concret survient lors des migrations. Basculer un sous-réseau IPv4-only en dual-stack peut introduire des plages incohérentes si la planification d’adressage n’a pas été revue au préalable. Google Cloud documente la possibilité de convertir un sous-réseau IPv4 en sous-réseau double pile (IPv4 + IPv6), ce qui multiplie les risques de chevauchement silencieux.
Une plage comme 10.128.0.0/9, déjà utilisée par défaut chez certains fournisseurs cloud, provoque un conflit immédiat si elle est réattribuée manuellement à un autre VPC. Le message d’erreur renvoyé n’est pas toujours explicite, ce qui retarde le diagnostic.
A voir aussi : Les vraies raisons derrière les mises à jour fréquentes de votre PC
Conflits d’adresses IP entre attribution statique et serveur DHCP
Un conflit d’adresse IP se produit quand deux nœuds du réseau utilisent le même identifiant. Le scénario le plus courant : un administrateur attribue manuellement une adresse IP à un serveur, sans exclure cette adresse de la plage DHCP. Le serveur DHCP finit par distribuer cette même adresse à un autre appareil.
Sur Windows, les deux machines cessent de communiquer dès qu’elles détectent le doublon. Sur d’autres systèmes d’exploitation, le comportement est plus pernicieux : l’un des deux hôtes continue de fonctionner avec des paquets mal acheminés, ce qui produit des erreurs réseau intermittentes difficiles à tracer.
Vérifications à appliquer sur la plage DHCP
- Exclure systématiquement de la plage DHCP toutes les adresses attribuées en statique (imprimantes réseau, serveurs, points d’accès Wi-Fi)
- Documenter chaque réservation dans un registre centralisé, même pour un réseau de petite taille
- Réduire la durée du bail DHCP sur les réseaux où les appareils se connectent et se déconnectent souvent, afin de libérer plus vite les adresses inutilisées
- Vérifier que le serveur DHCP envoie un ping ARP avant d’attribuer une adresse, pour détecter un éventuel conflit avant qu’il ne se produise
Erreurs silencieuses en double pile IPv4 et IPv6
Depuis quelques années, la généralisation des architectures double pile (dual-stack) ajoute une couche de complexité. Un hôte configuré en IPv4 et IPv6 simultanément peut masquer une erreur de configuration IPv4 si le trafic sort par IPv6 sans que l’administrateur s’en aperçoive.
Le cas inverse existe aussi : une application qui ne supporte que l’IPv4 tourne sur un hôte dual-stack dont la configuration IPv4 est incorrecte. L’application échoue, mais les outils de diagnostic réseau classiques (ping, traceroute) fonctionnent en IPv6 et ne révèlent rien d’anormal.
Isoler le problème sur la bonne couche
Pour diagnostiquer ce type d’erreur, il faut forcer le test sur la pile IPv4 seule. Sous Linux, la commande ping -4 cible explicitement IPv4. Tester séparément chaque pile réseau évite les faux positifs lors du diagnostic.
Dans un contexte cloud, vérifier que le sous-réseau n’a pas été basculé en dual-stack sans mise à jour des règles de pare-feu IPv4 associées. Une règle de filtrage qui référence une plage IPv4 devient inopérante si le trafic emprunte la pile IPv6.
Usurpation d’adresse IPv4 et protection du réseau
L’usurpation d’adresse IP (IP spoofing) consiste pour un attaquant à falsifier l’adresse source d’un paquet pour se faire passer pour un hôte légitime. En IPv4, le protocole ne vérifie pas nativement l’authenticité de l’adresse source, ce qui rend cette attaque techniquement simple.
Les conséquences vont du détournement de données à l’amplification d’attaques par déni de service. Un attaquant envoie des requêtes avec l’adresse IP de la victime comme source, et les serveurs ciblés répondent massivement vers cette victime.
Mesures concrètes contre le spoofing IPv4
- Activer le filtrage d’entrée (ingress filtering, BCP 38) sur les routeurs de bordure pour rejeter les paquets dont l’adresse source n’appartient pas au réseau d’origine
- Utiliser un VPN pour chiffrer le trafic et masquer l’adresse IP réelle lors de la navigation sur des réseaux non maîtrisés
- Configurer des enregistrements SPF sur les serveurs de messagerie pour empêcher l’usurpation d’adresse dans les en-têtes d’email
Le filtrage BCP 38 reste sous-déployé, alors qu’il bloquerait une part significative des attaques par usurpation. Chaque opérateur qui ne filtre pas ses paquets sortants facilite les attaques contre d’autres réseaux.
Planification d’adressage IPv4 : l’outil qui manque souvent
La plupart des erreurs décrites ici partagent une cause commune : l’absence de registre d’adressage à jour. Un simple tableur suffit pour un réseau de dix machines. Au-delà, un outil dédié de gestion des adresses IP (IPAM) devient nécessaire pour suivre les attributions, détecter les conflits et documenter les plages réservées.
Un bon registre d’adressage contient au minimum la plage réseau, le masque de sous-réseau, l’identifiant de l’hôte, le type d’attribution (statique ou DHCP) et la date de dernière vérification. Mettre à jour ce registre à chaque changement réseau coûte quelques minutes et évite des heures de diagnostic.
La raréfaction des adresses IPv4 disponibles, documentée par l’ARCEP dans son suivi de l’épuisement des blocs attribués par le RIPE-NCC, rend chaque erreur d’adressage plus coûteuse qu’il y a dix ans. Une adresse gaspillée par un conflit ou un chevauchement de plage ne sera pas facilement remplacée.
