O erro de sobreposição de pools do Docker não é um problema de rota VPN

O Docker recusa-se a criar uma rede com a mensagem de que o pool se sobrepõe a outro neste espaço de endereços, e alguém decide que a rota VPN deve ser a causa. Não pode ser. Esse erro é produzido enquanto um pool está a ser alocado, antes de existir um único pacote, e uma rota manual do kernel não tem qualquer influência sobre ele. A VPN conta um passo mais tarde, quando um contêiner que já tem um endereço deixa de ser acessível depois de aparecer uma rota. Dois problemas, dois conjuntos de provas, e misturá-los produz uma mudança que não corrige nenhum dos dois.

Dois erros que se parecem

O erro de alocação é aritmético. O Docker compara a sub-rede que pediu com as sub-redes que já gere, encontra uma interseção e recusa. Ainda não está nada a correr, por isso não há rota, nem contêiner, nem tráfego para inspecionar.

O sintoma em tempo de execução é uma questão de acessibilidade. Um contêiner que respondia ontem não responde agora, e algo mudou na tabela de encaminhamento do host. O contêiner continua a deter o seu endereço; a questão é que caminho esse endereço toma.

Ambos são problemas de plano de endereços. Apenas um deles é um problema do Docker.

Leia primeiro os pools alocados

Liste as redes e inspecione as que possam intersetar-se. A sub-rede vive na configuração IPAM, e os contêineres ligados são listados separadamente:

docker network ls
docker network inspect EXISTING_NETWORK

Compare essa sub-rede com o pool que a nova rede pede, e lembre-se de que o Compose cria a sua própria rede predefinida por projeto. Um conflito com um projeto esquecido parece exatamente um conflito com o daemon.

Um ipv4_address estático num serviço é o endereço de um contêiner, não a definição do pool. Alterá-lo não remove uma sobreposição, porque a sobreposição é entre sub-redes de rede e não entre contêineres. A referência network-create do Docker exige sub-redes não sobrepostas para a alocação comum em ponte e documenta como selecionar uma explicitamente.

Escolha um prefixo que sobreviva à VPN

O conflito imediato e a rota futura são decididos pela mesma escolha, por isso faça-a uma vez. Compare o intervalo candidato com a LAN, com cada destino VPN que o host possa alcançar e com qualquer outro overlay em uso.

Um prefixo que satisfaz o Docker e colide com a rede remota dá-lhe um contêiner que arranca limpo e se torna inalcançável no momento em que o túnel está em cima. Esse é o segundo erro deste artigo, e é muito mais difícil de diagnosticar mais tarde do que de evitar agora.

Anote os intervalos escolhidos num lugar onde o próximo projeto os possa ler. Um registo de uma linha de prefixos alocados é mais barato do que uma semana de tempos limite sem explicação.

Retire ou altere uma rede deliberadamente

Para uma nova rede Compose, defina o prefixo não utilizado na configuração IPAM da rede. Para um projeto existente, planeie a renumeração: os endereços fixos, os serviços dependentes e o passo de recriação da rede têm todos de ser tidos em conta, porque editar YAML não renumera uma rede em funcionamento.

Se uma rede obsoleta detém a alocação conflituosa, inspecione quem está ligado antes de a remover. O docker network rm recusa enquanto existirem endpoints ativos, e o docker stop aceita nomes ou ID de contêineres em vez de um nome de rede. Parar um contêiner também não remove a definição de rede que detém o pool.

Um prune amplo não é uma ferramenta de diagnóstico. Alcança projetos não relacionados e destrói as provas que estava prestes a recolher.

Os pools predefinidos só ajudam à próxima alocação

A definição do pool de endereços predefinido do daemon melhora as alocações automáticas futuras ao mantê-las fora dos intervalos que reserva. Não reatribui retroativamente as redes que já existem, e não resolve uma sub-rede explícita que se sobrepõe a outra sub-rede explícita.

Trate essa definição como uma alteração separada e planeada com o seu próprio reinício, não como parte da reparação de um projeto. Misturar as duas coisas significa que um reinício do daemon cai no meio de uma investigação não relacionada. Agende-o na sua própria janela. Depois confirme que uma nova alocação automática cai realmente fora dos intervalos que reservou.

Quando a criação tiver êxito, verifique a sub-rede que está realmente a correr e faça então um pedido real da aplicação com a VPN no estado previsto. Se o pool é válido e o acesso continua a falhar, o trabalho restante é a seleção de rota, a filtragem e o caminho de regresso. Isso é uma investigação em tempo de execução, e não torna o erro de alocação retroativamente sem sentido.

Ordem de trabalho: leia os pools alocados, escolha um prefixo que evite tanto o Docker como os destinos VPN, recrie a rede deliberadamente e teste então um pedido com o túnel em cima.