L'error de solapament de pools de Docker no és un problema de ruta VPN

Docker es nega a crear una xarxa amb el missatge que el pool se solapa amb un altre en aquest espai d'adreces, i algú decideix que la ruta VPN ha de ser la causa. No pot ser. Aquest error es produeix mentre s'assigna un pool, abans que existeixi un sol paquet, i una ruta manual del nucli no hi té cap influència. La VPN importa un pas més enllà, quan un contenidor que ja té una adreça deixa de ser accessible després que aparegui una ruta. Dos problemes, dos conjunts de proves, i barrejar-los produeix un canvi que no arregla cap dels dos.

Dos errors que semblen iguals

L'error d'assignació és aritmètic. Docker compara la subxarxa que has demanat amb les subxarxes que ja gestiona, troba una intersecció i es nega. Encara no hi ha res en marxa, així que no hi ha ruta, ni contenidor, ni trànsit per inspeccionar.

El símptoma en temps d'execució és una qüestió d'abastabilitat. Un contenidor que ahir responia ara no respon, i alguna cosa ha canviat a la taula d'encaminament de l'amfitrió. El contenidor encara conserva la seva adreça; la qüestió és quin camí pren aquesta adreça.

Tots dos són problemes de pla d'adreces. Només un d'ells és un problema de Docker.

Llegeix primer els pools assignats

Llista les xarxes i inspecciona les que podrien intersectar-se. La subxarxa viu a la configuració IPAM, i els contenidors connectats es llisten per separat:

docker network ls
docker network inspect EXISTING_NETWORK

Compara aquesta subxarxa amb el pool que demana la nova xarxa, i recorda que Compose crea la seva pròpia xarxa per defecte per projecte. Un conflicte amb un projecte que has oblidat sembla exactament un conflicte amb el dimoni.

Una ipv4_address estàtica en un servei és l'adreça d'un contenidor, no la definició del pool. Canviar-la no elimina un solapament, perquè el solapament és entre subxarxes de xarxa i no entre contenidors. La referència de network-create de Docker exigeix subxarxes que no se solapin per a l'assignació ordinària de bridge i documenta com seleccionar-ne una explícitament.

Tria un prefix que sobrevisqui a la VPN

El conflicte immediat i la ruta futura es decideixen amb la mateixa tria, així que fes-la una vegada. Compara el rang candidat amb la LAN, amb cada destinació VPN que l'amfitrió pugui assolir i amb qualsevol altre overlay en ús.

Un prefix que satisfà Docker i xoca amb la xarxa remota et dona un contenidor que arrenca net i es torna inabastable en el moment que el túnel puja. Aquest és el segon error d'aquest article, i és molt més difícil de diagnosticar després que d'evitar ara.

Anota els rangs triats en un lloc on el proper projecte els pugui llegir. Un registre d'una línia dels prefixes assignats és més barat que una setmana de temps d'espera sense explicació.

Retira o canvia una xarxa deliberadament

Per a una xarxa Compose nova, defineix el prefix no utilitzat a la configuració IPAM de la xarxa. Per a un projecte existent, planifica la renumeració: les adreces fixes, els serveis dependents i el pas de recreació de la xarxa s'han de tenir tots en compte, perquè editar YAML no renumerarà una xarxa en funcionament.

Si una xarxa obsoleta posseeix l'assignació conflictiva, inspecciona qui hi està connectat abans de treure-la. docker network rm es nega mentre existeixin punts finals actius, i docker stop pren noms o ID de contenidors en lloc del nom d'una xarxa. Aturar un contenidor tampoc no elimina la definició de xarxa que guarda el pool.

Una prune àmplia no és una eina de diagnòstic. Arriba a projectes no relacionats i destrueix les proves que estaves a punt de recollir.

Els pools per defecte només ajuden la propera assignació

El paràmetre de pool d'adreces per defecte del dimoni millora les assignacions automàtiques futures mantenint-les fora dels rangs que reserves. No readreça retroactivament les xarxes que ja existeixen, i no resol una subxarxa explícita que se solapa amb una altra subxarxa explícita.

Tracta aquest paràmetre com un canvi separat i planificat amb el seu propi reinici, no com a part de reparar un projecte. Barrejar les dues coses fa que un reinici del dimoni caigui al mig d'una investigació no relacionada. Programa'l en la seva pròpia finestra. Després confirma que una assignació automàtica nova cau realment fora dels rangs que vas reservar.

Quan la creació reeixi, verifica la subxarxa que realment s'executa i fes una petició real d'aplicació amb la VPN en el seu estat previst. Si el pool és vàlid i l'accés encara falla, la feina restant és la selecció de ruta, el filtratge i el camí de tornada. Això és una investigació en temps d'execució, i no fa que l'error d'assignació sigui retroactivament irrellevant.

Ordre de treball: llegeix els pools assignats, tria un prefix que esquivi tant Docker com les destinacions VPN, recrea la xarxa deliberadament i després prova una petició amb el túnel aixecat.