Por que un contedor macvlan non pode responder a un cliente VPN

Imaxine un host Linux que remata unha VPN e ademais executa un contedor nunha rede macvlan. A LAN é 192.168.60.0/24, o contedor ten 192.168.60.210 e os clientes VPN chegan desde 10.95.0.0/24. O cliente chega ao servizo, a resposta nunca volve e todas as regras de cortalumes do host parecen correctas. Dúas restricións separadas producen ese síntoma, e corrixir unha deixa a outra no seu sitio.

Dúas restricións, un síntoma

A primeira restrición é o illamento: o controlador macvlan de Docker non permite que un contedor fale co seu propio host a través da interface pai. O tráfico entre a pila do host e o contedor non ten camiño, por moito que se escriban as rutas do host.

A segunda restrición é o camiño de volta. A pasarela predeterminada do contedor adoita ser o router da LAN, así que unha resposta dirixida a un cliente VPN sae por ese router. Se o router non ten ruta de volta ao grupo de VPN, a resposta descártase nalgún punto intermedio.

Os dous fallos ven idénticos desde o cliente: unha petición que chega e unha resposta que nunca chega. Necesitan reparacións distintas, e unha regra masquerade ampla pode ocultar cal das dúas segue rota. Por iso a primeira proba é unha captura no lado do contedor e non outro cambio de cortalumes. Se a petición nunca aparece alí, a restrición que está en xogo é o illamento.

Construa o shim do host, de forma estreita

Unha segunda interface macvlan no host, conectada ao mesmo pai en modo ponte, dá á pila do host unha identidade propia nese segmento da LAN. Reserve para ela un enderezo fóra do grupo DHCP e fóra do rango do contedor, e encamiñe só o contedor a través dela.

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

O primeiro comando crea a interface en modo ponte, que é o valor predeterminado documentado para este controlador e o modo que se quere para o tráfico entre host e contedor. O segundo asigna un /32 para que o enderezo non choque co prefixo da LAN, e o cuarto envía só o enderezo do contedor a través do shim.

Non redirixa toda a LAN pola interface nova. A ruta conectada ordinaria queda como está, e a ruta do host é deliberadamente estreita para que un contedor gañe un camiño sen que o resto do segmento cambie de comportamento. Unha ruta predeterminada apuntando ao shim sería outro deseño con outras consecuencias. Mantéña específica e o radio de impacto segue a ser pequeno.

Estes comandos cambian a configuración de rede nun host en funcionamento. Nun dispositivo ou unha plataforma xestionada, use o mecanismo de configuración compatible desa plataforma, porque un cambio interactivo nun intérprete de ordes root pode non sobrevivir a unha actualización.

Decida como se conserva a orixe

Co shim no seu sitio, o contedor pode chegar ao host, e a pregunta pasa a ser que enderezo de orixe leva a resposta. Conservar a orixe VPN orixinal é o modelo máis limpo: o contedor ve o enderezo real do cliente e os rexistros e as regras de acceso do servizo poden usalo.

Para que iso funcione, a configuración de rede do contedor debe enviar para este camiño o tráfico de 10.95.0.0/24 a 192.168.60.250 como a súa pasarela. Iso é un axuste de ruta ou de pasarela compatible dentro da propia configuración do contedor, non un truco do lado do host. Confírmao desde dentro do contedor en lugar de supor que o axuste xa surtiu efecto. Unha pasarela predeterminada que aínda apunta ao router da LAN seguirá enviando respostas ao mesmo burato.

Se o deseño aprobado, en cambio, oculta as orixes VPN, limite a tradución de forma estreita: o grupo VPN real, o shim como interface de saída e o contedor e o servizo concretos.

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

Faga coincidir o shim como interface de saída, non o túnel. Unha regra que nomea o túnel como interface de saída non coincidirá cun paquete dirixido cara ao contedor, e ese é o erro que adoita conter este tipo de montaxe. Manteña a regra tan estreita como a frase anterior e revísea cando cambie o grupo.

Verifique desde o cliente, non desde o host

Unha petición do propio host, ligada ao enderezo do shim, demostra que o shim pode chegar ao contedor. Non demostra que o contedor poida devolver tráfico a unha orixe conservada 10.95.0.x, porque o enderezo de orixe nesa proba é o do propio shim.

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

O primeiro comando proba o tramo do host ao contedor, e o segundo mostra que cruza realmente o shim mentres un cliente VPN real fai a petición. Mire o enderezo de orixe na entrada e se aparece unha resposta co mesmo fluxo.

O reenvío debe estar habilitado no host, e o camiño de reenvío necesita un permiso para o grupo VPN cara ao shim no porto do servizo, ademais das respostas establecidas. Unha regra INPUT do host non autoriza o tráfico reenviado, e esa é unha causa habitual de que o paquete se descarte despois de que o encamiñamento pareza correcto.

Executa a aplicación real con credenciais reais e logo comprobe que un segundo servizo non relacionado no mesmo contedor aínda o rexeita. Se a única forma de facelo funcionar era abrir todas as regras de reenvío, o deseño non está rematado. Anote tamén que enderezo de orixe rexistrou o servizo, porque é o que usarán as súas propias regras de acceso de agora en diante.