Docker: não restam pools de endereços predefinidos durante uma sessão de VPN

A falha é específica: o Docker não encontra uma sub-rede automática aceitável para uma nova rede de ponte. Isso não significa que a máquina ficou sem endereços, nem que a VPN está avariada. Duas perguntas decidem o diagnóstico: quais blocos candidatos o daemon consegue ver e quais deles o seu alocador exclui neste ambiente. Percorra-as nessa ordem, porque a segunda pergunta não faz sentido enquanto a primeira não tiver resposta.

Confirme o que falhou antes de alterar seja o que for

Execute os passos abaixo a partir do anfitrião que executa o daemon. Uma shell a falar com um contexto remoto está a descrever outra máquina, e esse erro sozinho pode desperdiçar uma hora.

Registe ao mesmo tempo a versão do Engine no ticket. Cada heurística no resto deste guia depende da versão, e uma afirmação sem versão é um rumor.

Conte as atribuições que já tem

Liste as redes e depois inspecione as que importam: docker network ls seguido de docker network inspect NETWORK_NAME. Leia as respetivas sub-redes IPAM e os contentores ligados a cada uma. Vários projetos Compose consomem mais blocos do que os seus números de contentores sugerem, porque cada projeto tende a criar a sua própria rede predefinida. Um contentor parado não liberta a atribuição da sua rede.

Verifique também a configuração do pool, porque um pool predefinido tem um intervalo base e um tamanho de prefixo por rede. Atribuições grandes por rede esgotam os blocos disponíveis mais depressa, e isso é um facto de capacidade, não um problema de encaminhamento.

Anote o número. É a linha de base que lhe diz se a alteração seguinte ajudou.

Compare a visão que o daemon tem das rotas

Uma VPN pode influenciar a seleção de candidatos, mas a implementação exata decide como. Em Moby 28.2.2 em Linux, o InferReservedNetworks recolhe endereços de servidores de nomes e certas rotas IPv4 on-link, e não reserva simplesmente cada rota de cada tabela. As rotas de ligação recolhidas também excluem um endereço de destino não especificado, pelo que uma única rota 0.0.0.0/1 não reserva todos os endereços. Outro prefixo on-link amplo, como 128.0.0.0/1, pode intersetar os intervalos candidatos habituais 172 e 192.

Compare o ip -4 route show table all antes e depois de a VPN ligar, no anfitrião do daemon. O delta é a prova, e a versão é o âmbito da afirmação.

Não generalize as heurísticas de uma versão a todas as versões. É assim que uma resposta de fórum se torna uma alteração de política.

Escolha a correção mais pequena que funciona

Se uma rede não utilizada confirmada detiver um bloco de que precisa, planeie a sua retirada dirigida com o proprietário em vez de podar de forma ampla. Para uma rede nova, uma sub-rede não utilizada revista explicitamente evita por completo depender da seleção automática. Essa sub-rede ainda tem de evitar destinos reais de Docker, LAN e VPN obrigatórios, porque privado não significa seguro. Encaminhar um prefixo remoto real trocaria o erro de atribuição por um acesso quebrado.

Alterar default-address-pools é uma política mais ampla sobre atribuições futuras. Escolha uma base sem conflitos e um tamanho atribuído adequado, funda-a com as definições existentes do daemon e planeie o impacto documentado do reinício. As redes existentes não são renumeradas em silêncio.

Não desative os envios de rotas da empresa para que a atribuição tenha sucesso. Um plano de endereços explícito resolve normalmente o problema local sem enfraquecer uma política obrigatória.

Aceite a atribuição e o encaminhamento em separado

Após a alteração, inspecione a sub-rede que o Docker realmente criou e teste as dependências de VPN e locais da aplicação. Uma atribuição bem-sucedida e um encaminhamento correto em execução são duas verificações de aceitação diferentes, e passar a primeira não é prova para a segunda. Se a aplicação não alcançar um recurso atrás do túnel, tem um problema de encaminhamento que o erro do pool escondia. Registe os dois resultados no ticket.

Guarde o delta das rotas e a contagem do pool com o registo da alteração, porque a próxima atualização do cliente VPN pode alterar o primeiro sem tocar no Docker.

O guia está completo quando outra pessoa consegue repetir essas duas verificações e obter a mesma resposta.