Início / server / Perguntas / 1041173
Accepted
TCB13
Asked: 2020-11-04 12:42:36 +0800 CST

iptables: containers NAT e IP externo

  • 772

Eu tenho um servidor Debian 10 (IP público 85.xxx.xxx.xxx em enp6s0) executando vários contêineres LXC em uma ponte de redecbr0 . Eu tenho as seguintes regras do iptables em vigor para que os contêineres possam se comunicar com o mundo exterior:

iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i cbr0 -j ACCEPT
iptables -A FORWARD -i cbr0 -o enp6s0 -j ACCEPT
iptables -A FORWARD -i enp6s0 -o cbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o enp6s0 -j MASQUERADE

Eu criei um contêiner (10.0.0.1) que tem nginx e redirecione o tráfego http de entrada para esse contêiner:

iptables -t nat -A PREROUTING -i enp6s0 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.1:80
iptables -A FORWARD -i enp6s0 -o cbr0 -p tcp --dport 80 -j ACCEPT

Tudo funciona como esperado, consigo navegar no site no container etc.

Agora eu criei um segundo contêiner (10.0.0.2) que precisa buscar alguns dados do contêiner nginx. Se eu usar o IP interno 10.0.0.1 para a comunicação, meu segundo container é capaz de wget pages. No entanto, se eu tentar usar o IP externo do servidor :

root@second-container:~# nc example.com 80
example.com [85.xxx.xxx.xxx] 80 (http) : Connection refused

Minha solução atual é adicionar manualmente entradas em /etc/hostspara todos os domínios hospedados pelo nginx para que eles resolvam para 10.0.0.1 em vez de seu IP público.

Quais regras eu preciso para permitir também a comunicação usando o IP do servidor externo?

Obrigada.

Aqui está um diagrama adicional do problema: insira a descrição da imagem aqui

debian nat iptables containers

2 respostas

  1. Best Answer

    Este é o problema comum sobre o roteamento hairpin. A solução adequada é configurar o DNS local com o endereço local para não desperdiçar recursos de roteamento com NAT, que consome muitos recursos. O DNS local deve apontar para o endereço local para que o tráfego permaneça local e possa ser conectado em ponte em vez de roteado.

    • 2

  2. Este é um problema comum chamado NAT hairpin . A solução que eu geralmente prefiro é apenas adicionar SNAT (tradução de endereço de origem). Portanto, o dispositivo que já faz DNAT ao mesmo tempo faria SNAT para o mesmo pacote.

    A sobrecarga é minúscula. E, o mais importante, você deixa seu DNS puro, simples e previsível.

    • 0

relate perguntas