Por que un contedor de Docker non chega aos hosts detrás da VPN

Un contedor que non chega a nada detrás da VPN corporativa adoita vivir nun espazo de nomes de rede distinto ao do túnel. As rutas, os servidores DNS e as marcas do cortafocos do cliente do host pertencen á súa pila; un contedor en rede de ponte ten a súa. Ese único feito explica a maioría dos informes que chegan a un equipo de plataforma, e tamén é a razón pola que «a VPN está rota» e «Docker evita a VPN» poden ser ambas falsas á vez. Dúas configuracións moi distintas agóchanse tras un mesmo síntoma, así que identifique cal ten antes de cambiar calquera axuste.

Averigüe a que espazo de nomes pertence o túnel

En Docker Desktop para macOS ou Windows, os contedores execútanse dentro dunha máquina virtual Linux. Un cliente VPN instalado no escritorio crea un túnel no sistema operativo do escritorio, e a máquina virtual nunca o ve. Ningunha configuración do contedor o arranxa, porque a interface que necesitaría o contedor non existe en absoluto no seu espazo de nomes de rede.

Nun host Linux o túnel vive no espazo de nomes do host, e os contedores en ponte adoitan chegar a el a través da táboa de enrutamento do host con NAT de orixe aplicado á saída. Cando esa ruta falla, a causa adoita ser a política de reenvío, o filtrado de ruta inversa ou unha subrede superposta máis que unha ruta ausente. Confirme en cal dos dous mundos está antes de seguir lendo:

docker info --format '{{.OperatingSystem}}'
docker run --rm --net=host alpine ip route | head -5
docker run --rm alpine ip route | head -5

A diferenza entre esas dúas táboas de enrutamento é todo o problema nunha pantalla. Se a vista do host contén a interface do túnel e a vista da ponte non, está a ver illamento de espazos de nomes, e todo o demais é unha decisión sobre como cruzalos.

A rede do host é unha proba, non un deseño

Executar un contedor coa rede do host, que Docker documenta como compartir o espazo de nomes de rede do host, fai que herde directamente a interface do túnel e as súas rutas. Se a mesma petición entón ten éxito, a teoría das rutas queda confirmada e o fallo é illamento de espazos de nomes, non credenciais, DNS nin unha regra de acceso.

docker run --rm --net=host curl -sS -o /dev/null -w '%{http_code}\n' https://api.internal/health

Manteña como diagnóstico. A rede do host renuncia á publicación de portos e á maior parte do illamento que quería dun contedor, e en Docker Desktop «host» significa a máquina virtual, non o escritorio, así que un éxito ou un fallo alí pode enganalo se esquece a que host se dirixía.

Un dispositivo tun e os privilexios que leva

Un cliente VPN dentro do contedor necesita un dispositivo de túnel e permiso para configuralo. O atallo habitual é --privileged, que concede todos os dispositivos e relaxa a política de seguridade en todo o contedor. Iso é moito máis do que esixe esta tarefa, e custa xustificalo nunha revisión.

sudo modprobe tun
docker run --rm -it --device /dev/net/tun --cap-add NET_ADMIN myvpn-client

A forma máis estreita mapea o único nodo de dispositivo e engade só a capacidade de administración de rede. Cargue primeiro o módulo no host para que o nodo exista. Se o contedor arranca e o cliente informa de que non pode abrir o dispositivo de túnel, revise o mapeo antes de sospeitar do perfil, porque ese erro adoita ser literal.

Este deseño tamén significa que o cliente se executa por contedor. É a resposta correcta cando cada carga de traballo necesita o seu propio túnel, e a incorrecta cando só quería que o túnel do host fose visible, que é o que o equipo de plataforma probablemente supuña que facía.

O NAT da ponte cambia a orixe que ve a VPN

Coa ponte predeterminada, o tráfico saínte do contedor tradúcese ao enderezo do host. Detrás dunha VPN, o lado corporativo ve por tanto o enderezo do túnel do host e non o do contedor, as regras de acceso por orixe compórtanse como se o host fixese a petición, e dous contedores tórnanse indistinguibles para o servidor VPN.

macvlan ou ipvlan entrega ao contedor un enderezo LAN no seu lugar, o que axuda ao descubrimento na LAN e fai que o contedor pareza un par no segmento. Tamén evita por completo o túnel do host, así que ese contedor non alcanzará prefixos só-VPN a non ser que a VPN tamén sexa accesible desde esa LAN.

Ambas as formas son lexítimas; responden a requisitos distintos. Se o requisito é «este contedor debe chegar a un servizo só-VPN», elixe entre enrutar a través do host e terminar o túnel dentro do contedor. Escriba esa elección antes do despregamento, non despois da primeira petición fallida. Elixa o que elixa, anote o enderezo de orixe que verá o extremo remoto, porque é o que mostrarán as súas regras de acceso e os seus rexistros. Un deseño que non pode declarar ese enderezo non está terminado.

O DNS segue o daemon, non o túnel

Un contedor recibe a súa configuración de resolución ao arrancar, copiada do daemon ou da imaxe. Os enderezos que a VPN empurra tras conectarse chegan demasiado tarde para esa copia, e empúrranse ao resolutor do host e non ao contedor.

Defina o resolutor explicitamente para o servizo, ou apúnteo a un resolutor interno accesible a través do túnel. Un contedor que resolve un nome privado a un enderezo público adoita usar un resolutor público, non sofre unha ruta rota, e a corrección corresponde ao ficheiro compose ou á configuración do daemon.

O mesmo razoamento se aplica á cuestión do enderezo de saída. Se cada contedor debe aparecer desde un enderezo VPN distinto, un só túnel do host non pode entregalo porque o NAT os colapsa nunha única orixe. As formas viables son un cliente no espazo de nomes de cada contedor ou un sidecar que posúe o túnel e comparte a súa pila, e ambas cambian como se endereza a aplicación.

Lista de comprobación antes de pechar o ticket: identifique o espazo de nomes que posúe o túnel, demostre a ruta coa rede do host, mapee só o dispositivo tun necesario, lembre o enderezo de orixe tras o NAT, defina o resolutor explicitamente e trate os enderezos de saída por contedor como unha decisión de arquitectura e non como unha bandeira.