Publicação de portas do Docker e origens VPN: duas correspondências que você perde

A regra diz para permitir o endereço do servidor VPN até o serviço publicado, e a conexão ainda cai. Esse resultado é comum e não é um defeito do Docker. Duas correspondências separadas estão erradas: a origem que você escreveu pode não ser a origem que o host recebe, e a porta que você escreveu pode não ser a porta que o filtro vê. Corrigir as duas exige olhar o caminho do pacote em vez do diagrama do serviço.

O mito: libere o servidor VPN e pronto

Uma VPN roteada pode preservar o endereço do túnel do cliente até o host do Docker. Um gateway que faz tradução de origem pode substituir esse endereço pelo seu. Os dois desenhos são legítimos e produzem origens diferentes para a mesma ação do usuário.

Então a frase IP do servidor VPN descreve uma suposição, não uma observação. Até você saber qual dos dois desenhos está diante de você, a regra é um palpite.

Origem: pool de clientes ou gateway traduzido

Verifique quatro coisas em ordem. Primeira, o pool de endereços de clientes, por exemplo 10.90.0.0/24. Segunda, se o gateway traduz esse pool antes de ele chegar ao host. Terceira, a origem que o host realmente observa para uma nova conexão. Quarta, se a autenticação da aplicação distingue usuários individuais, porque um endereço traduzido compartilhado não consegue.

Se o pool for preservado, uma regra que corresponde apenas ao endereço público do gateway perde todos os clientes. Se o gateway traduz de propósito, permitir o endereço traduzido admite todos os usuários atrás dele, o que pode ser aceitável para um serviço com login próprio e inaceitável para qualquer outra coisa.

Porta: o DNAT muda o número que você corresponde

Na publicação comum em ponte Linux com iptables do Docker, um mapeamento do host de 8443 para a porta 443 do contêiner é traduzido antes de o filtro de encaminhamento executar. O pacote chega ao filtro com porta de destino 443. Uma regra que corresponde a 8443 naquele ponto nunca dispara, mesmo que 8443 seja o que o cliente digitou.

A porta publicada ainda existe no rastreamento de conexões, por isso o destino original pode ser correspondido ali quando você realmente precisa.

Decida qual número expressa a intenção. Corresponda à porta do contêiner após o DNAT quando a regra protege o serviço dentro do contêiner. Corresponda ao destino original com a opção conntrack quando a regra deve descrever o que o cliente pediu, e aceite o custo extra de correspondência e o cuidado com a ordem das regras que vêm junto.

Cadeia: DOCKER-USER, não INPUT

O guia de iptables do Docker coloca a política de encaminhamento do usuário na cadeia DOCKER-USER, que é avaliada antes das próprias regras de encaminhamento do Docker. Uma regra copiada de um serviço do host para a cadeia INPUT filtra o tráfego endereçado ao host, não o tráfego encaminhado para um contêiner. Esse erro produz uma regra que parece correta e não tem efeito no caminho do contêiner.

Mantenha o intervalo de origem, a porta de destino efetiva, o protocolo e a interface de entrada juntos na mesma regra. Uma permissão apenas por origem para cada destino encaminhado é mais ampla do que permitir um único serviço publicado.

Verifique com conexões novas

Teste os dois sentidos com conexões novas: um cliente VPN permitido e uma origem que deve continuar negada. O estado de conexão existente pode manter uma sessão viva depois de a política mudar, então uma conexão antiga não prova nada sobre a regra nova. Depois verifique o caminho de resposta, porque o contêiner ainda precisa encaminhar de volta para a origem que vê.

O guia de iptables do Docker documenta a ordem das cadeias e o comportamento de tradução de portas por trás dessas verificações. Leia-o antes de copiar uma receita e confirme qual backend o Docker instalado usa, porque o backend nftables integra a política de forma diferente.