DNAT nun contedor VPN: reenvío, non INPUT

A petición chega dirixida ao IP do túnel e sae do mesmo contedor dirixida a un servizo veciño. Entre eses dous momentos, DNAT reescribiu o destino e o paquete deixou de ser entrada para o contedor VPN. Agora é tráfico reenviado, xulgado por outra regra. Ese cambio explica por que unha regra de devasa que parece correcta para o enderezo do túnel non ten efecto sobre a conexión traducida.

Segue o paquete tras a tradución

Tome un grupo de clientes 10.90.0.0/24 e un enderezo de túnel 10.90.0.1. Dous contedores están nunha mesma ponte: 192.0.2.2 executa a VPN e 192.0.2.3 executa a aplicación. Un cliente conéctase a 10.90.0.1:8080, e a regra DNAT do espazo de nomes do contedor VPN reescríbeo ao enderezo e porto reais da aplicación. Despois unha ruta envía o paquete pola ponte. Eses enderezos son ilustrativos, non unha receita de despregamento.

O porto no que a aplicación escoita realmente pode diferir de calquera porto publicado no host. Lea o oínte dentro do contedor en lugar de supoñer que ambos os números coinciden.

O permiso pertence á ruta de reenvío

O contedor VPN necesita reenvío de IP e unha decisión de reenvío limitada ao grupo de clientes, ao enderezo da aplicación e ao porto previsto. As respostas establecidas necesitan o seu propio permiso. Unha regra que coincide co enderezo orixinal do túnel non coincidirá tras o DNAT, porque o destino xa cambiou. Un permiso INPUT é o gancho equivocado para tráfico que xa non se dirixe a este host.

Manteña o alcance estreito: un rango de orixe, un destino, un servizo. Unha regra de reenvío permisiva é máis doada de escribir e moito máis difícil de defender despois.

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

As cadeas de Docker non son as cadeas do seu contedor

As regras dentro do espazo de nomes do contedor non son as regras do host de Docker. Cando o tráfico cruza da interface do túnel á ponte, a devasa da ponte do host pode tomar outra decisión. Co backend iptables de Docker, as cadeas de reenvío documentadas e os puntos de coincidencia posteriores ao DNAT son onde aparece esa decisión.

A referencia de devasa de Docker describe esas cadeas e a coincidencia posterior ao DNAT. Non arranxe unha aceptación ausente desactivando a xestión da devasa de Docker ou facendo permisiva cada cadea, porque iso elimina o límite que intenta usar.

Faga da ruta de retorno unha elección deliberada

Se se conserva o enderezo de orixe, a aplicación ve 10.90.0.x e debe encamiñar as respostas de volta a través do contedor VPN. Doutro xeito, a súa pasarela Docker habitual enviaraas ao host, que non posúe o túnel. A alternativa é unha tradución de orixe estreitamente limitada no contedor VPN, que simplifica a resposta pero oculta o cliente á aplicación. Escolla a propósito e anote cal escolleu.

Probe unha conexión permitida nova desde un cliente corrente e logo confirme que os portos non relacionados seguen pechados. Cando un paquete desaparece, inspeccione o espazo de nomes da VPN, o da aplicación e o rexistro propio da aplicación. Un ping á pasarela da ponte non é unha proba de aceptación do servizo.

Manteña as regras na configuración de inicio admitida do contedor, porque as edicións interactivas desaparecen cando se recrea. A publicación dun porto no host é outra vía de exposición e non é necesaria só porque o servizo sexa alcanzable a través do túnel.