DNAT num contêiner VPN: encaminhamento, não INPUT

O pedido chega endereçado ao IP do túnel e sai do mesmo contêiner endereçado a um serviço vizinho. Entre esses dois momentos, o DNAT reescreveu o destino, e o pacote deixou de ser entrada para o contêiner VPN. Agora é tráfego encaminhado, julgado por outra regra. Essa mudança explica por que uma regra de firewall que parece correta para o endereço do túnel não tem efeito sobre a conexão traduzida.

Siga o pacote após a tradução

Considere um conjunto de clientes 10.90.0.0/24 e um endereço de túnel 10.90.0.1. Dois contêineres ficam numa mesma bridge: 192.0.2.2 executa a VPN e 192.0.2.3 executa a aplicação. Um cliente se conecta a 10.90.0.1:8080, e a regra DNAT no namespace do contêiner VPN reescreve isso para o endereço e a porta reais da aplicação. Depois, uma rota envia o pacote pela bridge. Esses endereços são ilustrativos, não uma receita de implantação.

A porta em que a aplicação realmente escuta pode diferir de qualquer porta publicada no host. Leia o ouvinte dentro do contêiner em vez de supor que os dois números coincidem.

A permissão pertence ao caminho de encaminhamento

O contêiner VPN precisa de encaminhamento de IP e de uma decisão de encaminhamento limitada ao conjunto de clientes, ao endereço da aplicação e à porta pretendida. As respostas estabelecidas precisam da sua própria permissão. Uma regra que corresponde ao endereço original do túnel não corresponderá após o DNAT, porque o destino já mudou. Uma permissão INPUT é o gancho errado para tráfego que já não é endereçado a este host.

Mantenha o escopo estreito: um intervalo de origem, um destino, um serviço. Uma regra de encaminhamento permissiva é mais fácil de escrever e muito mais difícil de defender depois.

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 cadeias do Docker não são as cadeias do seu contêiner

As regras dentro do namespace do contêiner não são as regras do host Docker. Quando o tráfego atravessa da interface do túnel para a bridge, o firewall da bridge no host pode tomar outra decisão. Com o backend iptables do Docker, as cadeias de encaminhamento documentadas e os pontos de correspondência após o DNAT são onde essa decisão aparece.

A referência de firewall do Docker descreve essas cadeias e a correspondência após o DNAT. Não corrija uma aceitação ausente desativando a gestão do firewall do Docker ou tornando cada cadeia permissiva, porque isso remove o limite que você está tentando usar.

Faça do caminho de retorno uma escolha deliberada

Se o endereço de origem for preservado, a aplicação vê 10.90.0.x e tem de encaminhar as respostas de volta através do contêiner VPN. Caso contrário, o seu gateway Docker habitual as enviará ao host, que não possui o túnel. A alternativa é uma tradução de origem estreitamente limitada no contêiner VPN, que simplifica a resposta mas esconde o cliente da aplicação. Escolha de propósito e registre qual escolheu.

Teste uma nova conexão permitida a partir de um cliente comum e depois confirme que as portas não relacionadas permanecem fechadas. Quando um pacote desaparece, inspecione o namespace da VPN, o da aplicação e o registro da própria aplicação. Um ping ao gateway da bridge não é um teste de aceitação do serviço.

Mantenha as regras na configuração de inicialização suportada do contêiner, porque as edições interativas desaparecem quando ele é recriado. A publicação de uma porta no host é outra via de exposição e não é necessária só porque o serviço é alcançável através do túnel.