O erro de solapamento de pools de Docker non é un problema de ruta VPN

Docker négase a crear unha rede coa mensaxe de que o pool se solapa con outro neste espazo de enderezos, e alguén decide que a ruta VPN debe ser a causa. Non pode ser. Ese erro prodúcese mentres se asigna un pool, antes de que exista un só paquete, e unha ruta manual do núcleo non ten ningunha influencia nel. A VPN importa un paso máis tarde, cando un contedor que xa ten un enderezo deixa de ser accesible despois de que apareza unha ruta. Dous problemas, dous conxuntos de probas, e mesturalos produce un cambio que non arranxa ningún dos dous.

Dous erros que se parecen

O erro de asignación é aritmético. Docker compara a subrede que pediches coas subredes que xa xestiona, atopa unha intersección e négase. Aínda non hai nada en marcha, así que non hai ruta, nin contedor, nin tráfico que inspeccionar.

O síntoma en tempo de execución é unha cuestión de accesibilidade. Un contedor que onte respondía agora non responde, e algo cambiou na táboa de encamiñamento do host. O contedor segue conservando o seu enderezo; a cuestión é que camiño toma ese enderezo.

Ambos son problemas de plan de enderezos. Só un deles é un problema de Docker.

Le primeiro os pools asignados

Enumera as redes e inspecciona as que poderían intersectarse. A subrede vive na configuración IPAM, e os contedores conectados enuméranse por separado:

docker network ls
docker network inspect EXISTING_NETWORK

Compara esa subrede co pool que solicita a nova rede, e lembra que Compose crea a súa propia rede por defecto para cada proxecto. Un conflito cun proxecto que esqueciches parece exactamente un conflito co demonio.

Unha ipv4_address estática nun servizo é o enderezo dun contedor, non a definición do pool. Cambiala non elimina un solapamento, porque o solapamento é entre subredes de rede e non entre contedores. A referencia de network-create de Docker esixe subredes que non se solapen para a asignación ordinaria por ponte e documenta como seleccionar unha explicitamente.

Escolle un prefixo que sobreviva á VPN

O conflito inmediato e a ruta futura decídense coa mesma escolla, así que fána unha vez. Compara o rango candidato coa LAN, con cada destino VPN que o host poida alcanzar e con calquera outro overlay en uso.

Un prefixo que satisface Docker e choca coa rede remota dache un contedor que arranca limpo e vólvese inalcanzable no momento en que o túnel está arriba. Ese é o segundo erro deste artigo, e é moito máis difícil de diagnosticar despois que de evitar agora.

Anota os rangos escollidos nalgún lugar onde o próximo proxecto poida lelos. Un rexistro dunha liña de prefixos asignados é máis barato que unha semana de tempos de espera sen explicación.

Retira ou cambia unha rede deliberadamente

Para unha rede Compose nova, define o prefixo sen usar na configuración IPAM da rede. Para un proxecto existente, planifica a renumeración: os enderezos fixos, os servizos dependentes e o paso de recreación da rede teñen que terse todos en conta, porque editar YAML non renumera unha rede en funcionamento.

Se unha rede obsoleta posúe a asignación conflitiva, inspecciona quen está conectado antes de eliminála. docker network rm négase mentres existan puntos finais activos, e docker stop toma nomes ou ID de contedores en lugar do nome dunha rede. Deter un contedor tampouco elimina a definición de rede que garda o pool.

Un prune amplo non é unha ferramenta de diagnóstico. Chega a proxectos non relacionados e destrúe as probas que estabas a piques de recoller.

Os pools por defecto só axudan á seguinte asignación

O axuste de pool de enderezos por defecto do demonio mellora as asignacións automáticas futuras manténdoas fóra dos rangos que reservas. Non reasigna retroactivamente as redes que xa existen, e non resolve unha subrede explícita que se solape con outra subrede explícita.

Trata ese axuste como un cambio separado e planificado co seu propio reinicio, non como parte de reparar un proxecto. Mesturar os dous significa que un reinicio do demonio cae no medio dunha investigación non relacionada. Prográmao na súa propia xanela. Despois confirma que unha nova asignación automática cae realmente fóra dos rangos que reservaches.

Cando a creación teña éxito, verifica a subrede que realmente se está executando e despois fai unha petición real de aplicación coa VPN no seu estado previsto. Se o pool é válido e o acceso segue fallando, o traballo restante é a selección de ruta, o filtrado e o camiño de volta. Iso é unha investigación en tempo de execución, e non fai que o erro de asignación sexa retroactivamente irrelevante.

Orde de traballo: le os pools asignados, escolle un prefixo que evite tanto Docker como os destinos VPN, recrea a rede deliberadamente e despois proba unha petición co túnel levantado.