O tráfico dos contedores Docker esquiva a VPN do host: como comprobalo
Unha VPN do host só cobre o espazo de nomes do host. Use estas comprobacións para saber se o tráfico dos contedores na ponte entra no túnel ou sae directamente.
O seu navegador no host mostra o enderezo de saída da VPN, o contedor informa da súa conexión doméstica e alguén o chama fuga. Non se filtrou nada. Un túnel do host é un conxunto de interfaces, rutas e regras que pertencen ao espazo de nomes de rede do host, e un contedor nunha ponte é outro espazo de nomes coa súa propia ruta predeterminada. Estiven nunha pila de Compose onde o cliente VPN levaba semanas conectado e nin un só paquete de contedor entrara nunca nel.
Comprobe o espazo de nomes antes ca icona da bandexa
Os espazos de nomes son todo o argumento. Cando Docker arrinca un contedor nunha rede de ponte, crea un espazo de nomes de rede, conecta un extremo dun par veth dentro del e dálle a ese espazo de nomes un enderezo e unha ruta predeterminada. A interface do túnel, chámese como se chame, vive no espazo de nomes do host. O tráfico dentro do contedor non pode vela, e ningún axuste do cliente cambia iso desde fóra.
Dous movementos admitidos sácanlle do illamento. --network host coloca o contedor dentro do espazo de nomes do host, así que herda as rutas do host e, por tanto, o túnel. --network container:vpn comparte o espazo de nomes doutro contedor, e así é como a maioría dos deseños sidecar envían unha carga de traballo por un contedor VPN. Ambos son opcións explícitas; normalmente só unha delas é o que pretendía a persoa que despregar.
O modo host non é unha mellora gratuíta. O contedor deixa de ter o seu propio enderezo, a publicación de portos deixa de aplicarse, e un proceso que teña NET_ADMIN alí pode reescribir o encamiñamento do host. Aceptalo pode ser a decisión correcta. Supoñer que xa está activo é como a xente pasa unha tarde depurando un túnel que nunca estaba na ruta.
Siga o paquete fóra da ponte
Un contedor da ponte envía o seu paquete á súa porta de enlace predeterminada, que é a interface da ponte no host. O host reenvía entón o paquete e, na configuración predeterminada, traduce o enderezo de orixe polo seu antes de que o paquete saia. Ese paso de tradución é o que derrota a política en silencio.
Cando o paquete chega ao extremo do túnel, leva o enderezo do host. Calquera regra, ruta de política ou decisión de túnel dividido baseada no enderezo orixinal do contedor deixa de coincidir, e dous contedores destinados a saír por saídas distintas non se poden distinguir só pola orixe. Se necesita encamiñamento por contedor, a decisión ten que ocorrer antes da tradución ou dentro dun espazo de nomes que vostede controle.
Docker mantén estas regras por si mesmo, co backend de firewall co que se configurase o daemon. As regras escritas a man fóra do gancho admitido para o tráfico reenviado, DOCKER-USER, poden reordenarse ou eliminarse cando o daemon se reinicia ou o host se actualiza. A documentación de Docker sobre filtrado de paquetes mostra a orde das cadeas; o punto práctico é que cada regra necesita un propietario e unha ruta de recarga que vostede probase de verdade.
Probe os dous sistemas por separado
A evidencia dun espazo de nomes non di nada sobre o outro. Unha petición executada dentro do contedor VPN demostra que o túnel funciona para ese contedor. Non é evidencia sobre o host, e o mesmo comando executado desde un contedor --network host non é evidencia sobre a ponte.
# host namespace
ip route get 1.1.1.1
ip -brief addr show
# a fresh container on the same bridge network
docker run --rm --network appnet alpine sh -c 'ip route; cat /etc/resolv.conf; ip -6 route'Despois repita a proba dentro do contedor real da aplicación en lugar dunha imaxe parecida. A aplicación pode levar unha ruta extra, unha variable de contorno de proxy ou un resolutor distinto, e cada unha desas cousas cambia a resposta. Comprobe a resolución de nomes e a segunda familia de enderezos cada vez: os contedores en pontes definidas polo usuario resólvense a través do resolutor integrado de Docker en 127.0.0.11, e unha ruta predeterminada IPv6 na ponte pode sacar tráfico mentres vostede está ocupado probando un túnel só IPv4.
Lea o patrón antes de tocar credenciais
Cando o host funciona e o contedor non, a causa é estrutural case sempre, e rotar chaves ou reinstalar o cliente desperdicia unha tarde. Ordene primeiro o síntoma e a solución adoita nomearse soa.
| What you see | Usual cause | First check |
|---|---|---|
| Host exits through the VPN, container shows the ISP address | The container never entered the tunnel | Default route inside the container |
| Container works until the daemon restarts, then stops | Rules outside the supported hook, or a changed backend | Daemon's reported firewall backend and DOCKER-USER |
| Container loses internal hosts after the tunnel comes up | VPN prefix overlaps the Docker bridge subnet | ip route on the host, then docker network inspect |
| Small replies arrive, large ones hang | Tunnel MTU or missing MSS clamping | Link MTU on both ends of the tunnel |
| Container falls back to the ISP address when the tunnel drops | Nothing enforces the kill switch for forwarded traffic | Stop the tunnel with a request in flight |
A fila do solapamento merece a súa propia frase. Un perfil de VPN que empurra unha ruta para 172.17.0.0/16, ou para unha 10.0.0.0/8 que casualmente contén o prefixo da súa ponte, fai que o túnel reclame a subrede dos contedores, e as respostas aos enderezos traducidos irán na dirección equivocada ou desaparecerán. Renumerar a rede de Docker adoita ser máis limpo que acumular excepcións.
Faga explícita a cobertura e despois rómpaa a propósito
Dous deseños resisten unha revisión. Comparta o espazo de nomes do contedor VPN e cada carga cuberta usa un só túnel cunha soa fronteira de reinicio, o que é simple ata que un servizo necesita outra saída ou a súa propia ruta DNS. Ou ben encamiñe a rede dos contedores a unha porta de enlace VPN no host: reenvío activado, o prefixo da ponte apuntado ao túnel, o tráfico de retorno tratado explicitamente. Iso compra control por rede e custa un conxunto de regras que manter a través das actualizacións do daemon e do cliente.
En calquera caso, a proba que importa é o caso de fallo. Deteña o túnel cunha petición de contedor en voo e observe onde vai o paquete. Se volve á ruta directa, a cobertura nunca se aplicou, porque un kill switch do cliente goberna o tráfico propio do cliente e non os paquetes reenviados desde unha ponte. Reinicie despois o daemon e o host e confirme o resultado unha segunda vez; ese é o momento en que as regras escritas a man desaparecen.
Antes de dalo por rematado, confirme catro cousas: a interface do túnel está no mesmo espazo de nomes que o tráfico, a proba do contedor executouse dentro do contedor real, comprobáronse a resolución de nomes e as dúas familias de enderezos, e a proba de fallo do túnel segue fallando pechada. Despois anote o backend de firewall, a versión do cliente e o propietario de cada regra. Ese rexistro é o que impide que a seguinte actualización deixe unha mestura non documentada de suposicións antigas.