L'erreur de chevauchement de pools de Docker n'est pas un problème de route VPN

Docker refuse de créer un réseau avec le message que le pool chevauche un autre dans cet espace d'adresses, et quelqu'un décide que la route VPN doit en être la cause. Elle ne peut pas l'être. Cette erreur est produite pendant l'allocation d'un pool, avant qu'un seul paquet existe, et une route manuelle du noyau n'a aucune influence dessus. Le VPN compte un cran plus tard, quand un conteneur qui possède déjà une adresse cesse d'être joignable après l'apparition d'une route. Deux problèmes, deux ensembles de preuves, et les mélanger produit un changement qui n'en corrige aucun.

Deux erreurs qui se ressemblent

L'erreur d'allocation est arithmétique. Docker compare le sous-réseau demandé avec les sous-réseaux qu'il gère déjà, trouve une intersection et refuse. Rien ne tourne encore, donc il n'y a ni route, ni conteneur, ni trafic à inspecter.

Le symptôme d'exécution est une question d'accessibilité. Un conteneur qui répondait hier ne répond plus, et quelque chose a changé dans la table de routage de l'hôte. Le conteneur conserve toujours son adresse ; la question est de savoir quel chemin cette adresse emprunte.

Les deux sont des problèmes de plan d'adressage. Un seul est un problème Docker.

Lisez d'abord les pools alloués

Listez les réseaux et inspectez ceux qui pourraient se recouper. Le sous-réseau vit dans la configuration IPAM, et les conteneurs attachés sont listés séparément :

docker network ls
docker network inspect EXISTING_NETWORK

Comparez ce sous-réseau au pool que demande le nouveau réseau, et souvenez-vous que Compose crée son propre réseau par défaut pour chaque projet. Un conflit avec un projet oublié ressemble exactement à un conflit avec le démon.

Une ipv4_address statique sur un service est l'adresse d'un conteneur, pas la définition du pool. La changer ne supprime pas un chevauchement, car le chevauchement est entre sous-réseaux de réseau et non entre conteneurs. La référence network-create de Docker exige des sous-réseaux non chevauchants pour l'allocation ordinaire en pont et documente comment en choisir un explicitement.

Choisissez un préfixe qui survit au VPN

Le conflit immédiat et la future route sont décidés par le même choix, alors faites-le une fois. Comparez la plage candidate au LAN, à chaque destination VPN que l'hôte peut atteindre et à tout autre overlay en usage.

Un préfixe qui satisfait Docker et entre en collision avec le réseau distant vous donne un conteneur qui démarre proprement et devient injoignable dès que le tunnel est monté. C'est la deuxième erreur de cet article, et elle est bien plus difficile à diagnostiquer plus tard qu'à éviter maintenant.

Notez les plages choisies quelque part où le prochain projet pourra les lire. Un registre d'une ligne des préfixes alloués coûte moins cher qu'une semaine de délais d'attente inexpliqués.

Retirez ou modifiez un réseau délibérément

Pour un nouveau réseau Compose, définissez le préfixe inutilisé dans la configuration IPAM du réseau. Pour un projet existant, planifiez la renumérotation : les adresses fixes, les services dépendants et l'étape de recréation du réseau doivent tous être pris en compte, car éditer du YAML ne renumérote pas un réseau en cours d'exécution.

Si un réseau obsolète possède l'allocation conflictuelle, inspectez qui y est attaché avant de le supprimer. docker network rm refuse tant que des points de terminaison actifs existent, et docker stop prend des noms ou des ID de conteneurs plutôt qu'un nom de réseau. Arrêter un conteneur ne supprime pas non plus la définition de réseau qui détient le pool.

Un prune large n'est pas un outil de diagnostic. Il atteint des projets sans rapport et détruit les preuves que vous alliez recueillir.

Les pools par défaut n'aident que la prochaine allocation

Le réglage du pool d'adresses par défaut du démon améliore les allocations automatiques futures en les gardant hors des plages que vous réservez. Il ne réattribue pas rétroactivement les réseaux qui existent déjà, et il ne résout pas un sous-réseau explicite qui chevauche un autre sous-réseau explicite.

Traitez ce réglage comme un changement séparé et planifié avec son propre redémarrage, pas comme une partie de la réparation d'un projet. Mélanger les deux signifie qu'un redémarrage du démon tombe au milieu d'une enquête sans rapport. Planifiez-le dans sa propre fenêtre. Confirmez ensuite qu'une nouvelle allocation automatique atterrit réellement hors des plages que vous avez réservées.

Une fois la création réussie, vérifiez le sous-réseau réellement en cours d'exécution, puis faites une vraie requête applicative avec le VPN dans son état prévu. Si le pool est valide et que l'accès échoue encore, le travail restant est la sélection de route, le filtrage et le chemin de retour. C'est une enquête d'exécution, et elle ne rend pas l'erreur d'allocation rétroactivement dénuée de sens.

Ordre du travail : lisez les pools alloués, choisissez un préfixe qui évite à la fois Docker et les destinations VPN, recréez le réseau délibérément, puis testez une requête avec le tunnel monté.