Contentores Windows e VPN: porque a rede local se rompe
Um contentor Windows usa a tabela de rotas do anfitrião, por isso uma VPN que bloqueia a sub-rede local leva consigo o prefixo do contentor. O modo Linux segue outro caminho.
Num único portátil, com um único cliente VPN ligado, os contentores Linux continuam a falar entre si e os contentores Windows param. A variável não é a imagem, mas o caminho que os pacotes tomam até ao anfitrião. Os contentores Windows na rede predefinida pedem emprestada a tabela de rotas e a tradução do anfitrião, por isso uma política que muda o encaminhamento do anfitrião muda também os contentores. Confirme isso com uma consulta de rotas antes de reinstalar seja o que for.
Onde os pacotes de um contentor Windows entram no anfitrião
Um contentor na rede predefinida nat obtém um endereço de um prefixo do serviço Host Networking Service, normalmente algures dentro de 172.16.0.0/12, e chega ao anfitrião através de um adaptador virtual. O anfitrião é dono da rota para esse prefixo e traduz o tráfego para o adaptador que estiver ativo. Não há nenhuma máquina virtual separada no meio desse caminho.
É esse desenho que torna a falha mecânica. Quando o contentor envia um pacote, o anfitrião faz uma consulta de rota para o prefixo do contentor. A rota que ganhar é para onde vai o pacote, e o contentor não tem opinião sobre isso.
O que o cliente VPN muda nesse caminho
Um cliente empresarial instala frequentemente um conjunto amplo de rotas e um filtro que nega o acesso à sub-rede local enquanto o túnel está ativo. A intenção é defensiva: uma rede local comprometida não deve chegar a uma máquina protegida. O efeito secundário é que a rota do anfitrião para o prefixo do contentor já não é a rede NAT local.
Em vez disso, a consulta corresponde ao túnel e o pacote é entregue ao gateway, que nunca ouviu falar desse endereço de contentor. O ping falha, a aplicação esgota o tempo e o contentor parece avariado enquanto o ícone da VPN brilha. Olhe para a tabela do anfitrião enquanto está ligado e a rota concorrente fica visível.
| Container mode | Outbound path | Typical result behind the VPN |
|---|---|---|
| Windows, default nat | Host routes and translates container traffic | Container prefix follows the tunnel and fails |
| Windows, transparent | Container sits on the physical link | Depends on the local subnet being allowed |
| Linux engine on Docker Desktop | VM egress proxied by a host process | Often keeps working |
Porque os contentores Linux se comportam de forma diferente
O motor Linux executa os contentores dentro de uma máquina virtual leve, e as ligações de saída dessa máquina são abertas por um proxy do lado do anfitrião em nome do contentor. É o anfitrião que inicia o socket, por isso a regra da VPN sobre o prefixo do contentor não se aplica da mesma forma, e a carga de trabalho continua a chegar à rede.
Essa diferença também explica porque as receitas Linux não se transferem. A um contentor Linux que precisa do seu próprio túnel é dado um dispositivo TUN mais a capacidade NET_ADMIN. Os contentores Windows não expõem nenhuma interface como dispositivo, por isso esse padrão não tem equivalente desse lado.
Prove a rota e depois escolha um desenho
Recolha provas do anfitrião, não do contentor, porque é o anfitrião que faz a consulta:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Execute a saída de rotas uma vez antes de a VPN ligar e uma vez depois. Se na segunda saída o prefixo do contentor apontar para o adaptador do túnel, o diagnóstico está completo e reiniciar os contentores não ajudará.
A primeira opção é uma decisão de política: pergunte ao proprietário da rede se o acesso à LAN local pode ser permitido para este dispositivo. Vários clientes empresariais expõem isso como definição, mas enfraquece uma fronteira deliberada. Peça-o como uma exceção documentada com um proprietário e uma data de revisão. Um interruptor por dispositivo ao qual ninguém volta é a forma como uma política defensiva desaparece em silêncio.
Onde a política tem de se manter, mova a carga de trabalho em vez de lutar contra a rota. Uma rede transparente com uma sub-rede e um gateway explícitos coloca os contentores na ligação local, uma carga de trabalho Linux corre atrás do proxy da máquina virtual, e uma máquina virtual separada com o seu próprio cliente mantém a sua própria política. Escolha uma deliberadamente e teste-a a partir do interior do contentor, porque é aí que o pedido do utilizador nasce.