Docker : plus aucun pool d’adresses prédéfini pendant une session VPN

La panne est précise : Docker ne trouve pas de sous-réseau automatique acceptable pour un nouveau réseau pont. Cela ne signifie pas que la machine est à court d’adresses, ni que le VPN est cassé. Deux questions décident du diagnostic : quels blocs candidats le démon peut voir, et lesquels son allocateur exclut dans cet environnement. Traitez-les dans cet ordre, car la seconde question n’a aucun sens tant que la première n’a pas de réponse.

Confirmez ce qui a échoué avant de changer quoi que ce soit

Exécutez les étapes ci-dessous depuis l’hôte qui fait tourner le démon. Un shell qui parle à un contexte distant décrit une autre machine, et cette seule erreur peut coûter une heure.

Notez en même temps la version d’Engine dans le ticket. Chaque heuristique du reste de ce guide dépend de la version, et une affirmation sans version est une rumeur.

Comptez les allocations que vous avez déjà

Listez les réseaux, puis inspectez ceux qui comptent : docker network ls suivi de docker network inspect NETWORK_NAME. Lisez leurs sous-réseaux IPAM et les conteneurs attachés à chacun. Plusieurs projets Compose consomment plus de blocs que leur nombre de conteneurs ne le suggère, car chaque projet a tendance à créer son propre réseau par défaut. Un conteneur arrêté ne libère pas l’allocation de son réseau.

Vérifiez aussi la configuration du pool, car un pool par défaut possède une plage de base et une taille de préfixe par réseau. Les allocations importantes par réseau épuisent plus vite les blocs disponibles, et c’est un fait de capacité, pas un problème de routage.

Notez le compte. C’est la ligne de base qui vous dit si le changement suivant a aidé.

Comparez la vision que le démon a des routes

Un VPN peut influencer la sélection des candidats, mais l’implémentation exacte décide comment. Dans Moby 28.2.2 sous Linux, InferReservedNetworks collecte les adresses des serveurs de noms et certaines routes IPv4 on-link, et il ne réserve pas simplement chaque route de chaque table. Les routes de liaison collectées excluent aussi une adresse de destination non spécifiée, donc une seule route 0.0.0.0/1 ne réserve pas toutes les adresses. Un autre préfixe on-link large, tel que 128.0.0.0/1, peut recouper les plages candidates habituelles 172 et 192.

Comparez ip -4 route show table all avant et après la connexion du VPN, sur l’hôte du démon. Le delta est la preuve, et la version est la portée de l’affirmation.

Ne généralisez pas les heuristiques d’une version à toutes les versions. C’est ainsi qu’une réponse de forum devient un changement de politique.

Choisissez la plus petite correction qui fonctionne

Si un réseau inutilisé confirmé détient un bloc dont vous avez besoin, planifiez son retrait ciblé avec le propriétaire au lieu d’élaguer largement. Pour un nouveau réseau, un sous-réseau inutilisé explicitement vérifié évite totalement de dépendre de la sélection automatique. Ce sous-réseau doit encore éviter les destinations réelles de Docker, du LAN et du VPN requis, car privé ne veut pas dire sûr. Router un vrai préfixe distant échangerait l’erreur d’allocation contre un accès cassé.

Changer default-address-pools est une politique plus large sur les allocations futures. Choisissez une base sans conflit et une taille allouée adaptée, fusionnez-la avec les paramètres existants du démon et planifiez l’impact documenté du redémarrage. Les réseaux existants ne sont pas renumérotés en silence.

Ne désactivez pas la poussée des routes de l’entreprise pour faire réussir l’allocation. Un plan d’adressage explicite résout généralement le problème local sans affaiblir une politique obligatoire.

Acceptez l’allocation et le routage séparément

Après le changement, inspectez le sous-réseau que Docker a réellement créé et testez les dépendances VPN et locales de l’application. Une allocation réussie et un routage correct à l’exécution sont deux contrôles d’acceptation différents, et réussir le premier n’est pas une preuve pour le second. Si l’application n’atteint pas une ressource derrière le tunnel, vous avez un problème de routage que l’erreur du pool masquait. Consignez les deux résultats dans le ticket.

Conservez le delta de routes et le compte du pool avec l’enregistrement du changement, car la prochaine mise à jour du client VPN peut modifier le premier sans toucher à Docker.

Le guide est complet quand quelqu’un d’autre peut répéter ces deux contrôles et obtenir la même réponse.