Publicação de portas do Docker versus a VPN: para onde vai a resposta

Um contentor publicado responde a partir do seu próprio endereço antes do NAT inverso. Dois desenhos podem manter essa resposta no caminho público, com custos diferentes.

O anfitrião continua a responder por SSH depois de uma VPN de túnel completo subir, enquanto um serviço publicado pelo Docker na mesma máquina fica em silêncio. Não há nada de errado com o listener: o contentor está a correr, o mapeamento de portas existe e o pacote chega. O contentor está saudável e o pedido realmente o alcança. O que difere é de onde parte a resposta quando o Linux escolhe a sua rota, e essa diferença decide qual dos dois desenhos abaixo precisa.

Siga a tupla através do NAT de destino

Tome um anfitrião em 192.0.2.10 que publica TCP 2222 para um contentor em 172.30.240.5:22. Um pedido de 198.51.100.25 é traduzido antes de chegar ao contentor, e o contentor responde como ele próprio.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

Na decisão de rota do anfitrião a resposta ainda transporta o endereço de origem do contentor. A tradução inversa restaura mais tarde a tupla publicada, e é por isso que o pacote parece errado exatamente no momento em que a rota é escolhida.

Porque é que uma regra só para o anfitrião a perde

Uma regra que seleciona a tabela WAN apenas para pacotes de 192.0.2.10 cobre os próprios daemons do anfitrião e perde completamente esta resposta reencaminhada. O endereço de origem na resposta é 172.30.240.5, não o anfitrião.

A correção excessiva é encaminhar tudo do contentor pela WAN, o que também isenta da VPN as ligações de saída não relacionadas do contentor. É uma política diferente da pedida, e normalmente surpreende alguém mais tarde.

A correspondência pós-DNAT é um hook diferente

A documentação do Docker sobre firewalls observa que a filtragem normal de utilizador vê o destino depois do DNAT, por isso corresponder à porta publicada 2222 numa regra normal não é o mesmo que corresponder à porta 22 do contentor. Se a tupla original importa, use o mecanismo de destino original suportado em vez de adivinhar qual porta está visível.

Esta confusão de hooks produz regras que parecem corretas e nunca correspondem. Verifique os contadores na própria regra antes de reescrever a política. Uma regra sem qualquer acerto diz-lhe que está a ser avaliada num local onde o pacote nunca chega.

Desenho A: transportar a decisão como estado da ligação

Uma marca de ligação pode transportar a decisão de entrada através da tradução, mas tem de ser restaurada no pacote antes da pesquisa de rota que importa. As etapas são:

  1. Reserve um campo de marca e uma prioridade de regra que não colidam com o Docker, a VPN ou outro proprietário de política.
  2. Identifique apenas a nova ligação WAN pretendida num ponto antes do DNAT onde o rastreio de ligações está disponível.
  3. Registe a decisão na marca de ligação, sem forçar o próprio pedido original para a tabela WAN.
  4. No sentido da resposta, restaure apenas os seus próprios bits de marca no pacote antes do encaminhamento.
  5. Selecione uma tabela WAN completa cedo o suficiente para que uma regra da VPN não possa ganhar primeiro.

Essa tabela precisa das rotas ligadas reais e da gateway. Precisa também de um comportamento definido quando a rota falta. Cair em silêncio no túnel é o pior resultado, porque a configuração continua a parecer funcionar. Em vez disso, falhe fechado e registe-o.

Desenho B: terminar no anfitrião

Um frontend configurado deliberadamente do lado do anfitrião, como um proxy TCP ou um proxy inverso à frente do contentor, mantém a resposta originada no endereço do anfitrião. As regras escritas para o anfitrião comportam-se então como esperado, e o contentor fica na sua rede privada.

O custo é mais uma peça móvel com a sua própria configuração, tratamento de endereços de origem e controlos de acesso. É normalmente o limite suportado mais simples, e é muitas vezes a resposta certa quando a política de encaminhamento seria mantida por uma só pessoa que pode sair.

Verifique a mudança, não a intenção

Abra uma nova ligação autorizada do lado público e confirme que a resposta sai pela interface pretendida. Depois verifique se um pedido não relacionado iniciado pelo contentor continua a seguir a VPN.

Não limpe a tabela de ligações da máquina para testar uma regra: as entradas existentes mantêm o mapeamento anterior, e a limpeza quebra tudo o resto no anfitrião. Publicar uma porta define a acessibilidade. Não define o caminho da resposta. Escreva o desenho escolhido com os nomes das suas tabelas, para que a próxima pessoa não tenha de o redescobrir durante um incidente.

Artigos relacionados