O host alcança o par IPsec, o contêiner Docker não

Você faz ping ao host remoto a partir da máquina Linux e ele responde, então o túnel funciona. O contêiner ao lado ainda expira, e o próximo passo natural é reiniciar o Docker. Um contêiner em rede ponte normalmente começa com outro endereço de origem e entra no host por encaminhamento, e não pelo caminho de saída próprio da aplicação no host, então o teste bem-sucedido mediu outro pacote. Para um túnel strongSwan baseado em políticas, uma rota comum até a sub-rede remota não basta quando o pacote encaminhado não corresponde à política IPsec instalada.

O percurso abaixo segue um destino por duas origens, lendo o estado antes de mudar qualquer coisa.

Comece com um destino e duas origens

Escolha primeiro um serviço conhecido por IP, para não estar depurando DNS ao mesmo tempo. Anote três fatos: o prefixo ponte do contêiner, o endereço de origem da requisição do host que funcionou e os seletores de tráfego local e remoto negociados para o túnel. Esses três números explicam quase todos os casos deste sintoma.

Depois repita a requisição falha de dentro do contêiner e capture a origem que ele realmente usa. Se esse endereço não for coberto pelo seletor local, você já sabe o resultado, e nenhuma recriação do contêiner o mudará.

Leia as políticas antes de tocar no Docker

As verificações de host somente leitura cobrem as decisões de encaminhamento, a base de políticas e as regras que escolhem entre elas:

ip rule show
ip route show table all
ip xfrm policy

A listagem de políticas mostra seletores e direção sem precisar de um dump de estado IPsec cheio de material de chave, por isso é seguro colá-la num ticket. Procure um seletor local que cubra o endereço do host mas não o prefixo ponte. Verifique também a sobreposição: uma rota de contêiner que trata o destino remoto como local nunca produzirá o pacote encaminhado esperado, e o túnel leva a culpa. Guarde essa listagem junto ao endereço de origem do contêiner, porque as duas coisas juntas são toda a comparação.

Se faltar o prefixo do contêiner, pare e decida a arquitetura antes de editar qualquer outra coisa. O resto deste percurso assume que vocês concordaram qual endereço de origem deve aparecer no fio.

Verifique filtragem e tradução em ordem

O firewall ponte Linux do Docker pode bloquear o encaminhamento independentemente do IPsec. Com o backend iptables, inspecione o caminho FORWARD e as decisões DOCKER-USER, lembrando que uma regra adicionada após um veredito anterior pode nunca ser executada. O backend nftables integra-se de outra forma, então não crie uma corrente DOCKER-USER só porque um exemplo de iptables a nomeou; verifique qual backend o seu daemon realmente usa.

Depois verifique a tradução de origem. Uma regra MASQUERADE ampla pode transformar um pacote que antes correspondia a um seletor IPsec num que já não corresponde, e a falha parece exatamente um problema de encaminhamento. O guia de encaminhamento do strongSwan documenta a isenção de NAT necessária antes dessa tradução para tráfego que já corresponde a uma política.

Essa isenção não é uma forma de adicionar ao túnel uma origem de contêiner não coberta. Ela só protege tráfego que já se encaixa no desenho, então resolva primeiro as questões de seletor e caminho de volta, e depois faça NAT e filtragem concordarem com a resposta. Se você se pegar ampliando a isenção, o seletor é o que deve mudar, não a regra NAT.

Depois decida roteado ou traduzido

Uma sub-rede de contêiner roteada exige que os dois pares aceitem essa sub-rede e um caminho de volta remoto até ela, o que geralmente significa mudança de seletor nas duas pontas e uma conversa com o dono do lado remoto. Um desenho deliberadamente traduzido precisa, em vez disso, apresentar um endereço coberto pela política no estágio de consulta relevante, o que geralmente significa uma regra estreita e documentada em vez de um MASQUERADE padrão.

Nenhum dos dois arranjos decorre automaticamente do túnel funcional do host, e escolher entre eles é uma decisão de desenho com um responsável. Anote qual você escolheu, porque o próximo engenheiro vai deduzi-la de novo pelos contadores do firewall.

Observe também a falha híbrida: metade do conjunto de regras traduzida e metade não, o que produz sucesso intermitente que depende da porta de destino e não de algo na rede.

Verifique com uma conexão nova, não com um reinício

Use uma conexão nova da aplicação enquanto observa contadores estreitos do firewall e o receptor remoto, para que cada observação tenha uma origem. Um reinício do Docker pode mudar o estado das regras e também vai perturbar cargas de trabalho, o que lhe custa o sinal limpo que você queria obter.

O resultado duradouro são quatro afirmações que você pode mostrar: a origem do contêiner, o caminho protegido correspondente, o encaminhamento permitido e uma resposta que volta. Quando as quatro valem, o contêiner alcança o par pelo mesmo motivo que o host.