El error de solapamiento de pools de Docker no es un problema de ruta VPN

Docker se niega a crear una red con el mensaje de que el pool se solapa con otro en este espacio de direcciones, y alguien decide que la ruta VPN debe ser la causa. No puede serlo. Ese error se produce mientras se asigna un pool, antes de que exista un solo paquete, y una ruta manual del núcleo no tiene ninguna influencia en él. La VPN importa un paso más tarde, cuando un contenedor que ya tiene una dirección deja de ser accesible después de que aparezca una ruta. Dos problemas, dos conjuntos de pruebas, y mezclarlos produce un cambio que no arregla ninguno de los dos.

Dos errores que se parecen

El error de asignación es aritmético. Docker compara la subred que pediste con las subredes que ya gestiona, encuentra una intersección y se niega. Todavía no hay nada en marcha, así que no hay ruta, ni contenedor, ni tráfico que inspeccionar.

El síntoma en tiempo de ejecución es una cuestión de accesibilidad. Un contenedor que ayer respondía ahora no responde, y algo ha cambiado en la tabla de enrutamiento del host. El contenedor sigue conservando su dirección; la cuestión es qué camino toma esa dirección.

Ambos son problemas de plan de direcciones. Solo uno de ellos es un problema de Docker.

Lee primero los pools asignados

Enumera las redes e inspecciona las que podrían intersectarse. La subred vive en la configuración IPAM, y los contenedores conectados se enumeran por separado:

docker network ls
docker network inspect EXISTING_NETWORK

Compara esa subred con el pool que solicita la nueva red, y recuerda que Compose crea su propia red por defecto para cada proyecto. Un conflicto con un proyecto que olvidaste se ve exactamente como un conflicto con el demonio.

Una ipv4_address estática en un servicio es la dirección de un contenedor, no la definición del pool. Cambiarla no elimina un solapamiento, porque el solapamiento es entre subredes de red y no entre contenedores. La referencia de network-create de Docker exige subredes que no se solapen para la asignación ordinaria por puente y documenta cómo seleccionar una explícitamente.

Elige un prefijo que sobreviva a la VPN

El conflicto inmediato y la ruta futura se deciden con la misma elección, así que hazla una vez. Compara el rango candidato con la LAN, con cada destino VPN que el host pueda alcanzar y con cualquier otro overlay en uso.

Un prefijo que satisface a Docker y choca con la red remota te da un contenedor que arranca limpio y se vuelve inalcanzable en el momento en que el túnel está arriba. Ese es el segundo error de este artículo, y es mucho más difícil de diagnosticar después que de evitar ahora.

Anota los rangos elegidos en algún lugar donde el próximo proyecto pueda leerlos. Un registro de una línea de prefijos asignados es más barato que una semana de tiempos de espera sin explicación.

Retira o cambia una red deliberadamente

Para una red Compose nueva, define el prefijo sin usar en la configuración IPAM de la red. Para un proyecto existente, planifica la renumeración: las direcciones fijas, los servicios dependientes y el paso de recreación de la red tienen que tenerse en cuenta, porque editar YAML no renumera una red en funcionamiento.

Si una red obsoleta posee la asignación conflictiva, inspecciona quién está conectado antes de eliminarla. docker network rm se niega mientras existan puntos finales activos, y docker stop toma nombres o ID de contenedores en lugar del nombre de una red. Detener un contenedor tampoco elimina la definición de red que guarda el pool.

Una prune amplia no es una herramienta de diagnóstico. Llega a proyectos no relacionados y destruye las pruebas que estabas a punto de recoger.

Los pools por defecto solo ayudan a la siguiente asignación

El ajuste de pool de direcciones por defecto del demonio mejora las asignaciones automáticas futuras manteniéndolas fuera de los rangos que reservas. No reasigna retroactivamente las redes que ya existen, y no resuelve una subred explícita que se solape con otra subred explícita.

Trata ese ajuste como un cambio separado y planificado con su propio reinicio, no como parte de reparar un proyecto. Mezclar los dos significa que un reinicio del demonio cae en medio de una investigación no relacionada. Prográmalo en su propia ventana. Luego confirma que una nueva asignación automática cae realmente fuera de los rangos que reservaste.

Cuando la creación tenga éxito, verifica la subred que realmente se está ejecutando y luego haz una petición real de aplicación con la VPN en su estado previsto. Si el pool es válido y el acceso sigue fallando, el trabajo restante es la selección de ruta, el filtrado y el camino de vuelta. Eso es una investigación en tiempo de ejecución, y no hace que el error de asignación sea retroactivamente irrelevante.

Orden de trabajo: lee los pools asignados, elige un prefijo que evite tanto Docker como los destinos VPN, recrea la red deliberadamente y luego prueba una petición con el túnel levantado.