iptables encaminhamento de porta do balanceador de carga para o servidor da web interno

Question

Estou com problemas para encaminhar a porta 8000 do meu balanceador de carga (o único ponto de entrada com endereço IP externo) para um servidor da Web (para a porta 8000) com IP interno.

Então eu preciso de XX.XX.XX.XX: 8000 - > YY.YY.YY.YY: 8000, em que XX.XX.XX.XX é o ip externo e YY.YY.YY.YY é interno.

Quando logado em XX.XX.XX.XX via ssh, é possível fazer o telnet YY.YY.YY.YY 8000 e ele se conecta com sucesso. Aqui estão os comandos iptables que eu lancei (em XX.XX.XX.XX):

iptables -F
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

iptables -A PREROUTING -t nat -p tcp --dport 8000 -j DNAT --to YY.YY.YY.YY:8000
iptables -A FORWARD -p tcp -d YY.YY.YY.YY --dport 8000 -j ACCEPT

e aqui está a saída iptables -L:

Chain INPUT (policy ACCEPT 13486 packets, 6361K bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1      122  6968 ACCEPT     tcp  --  any    any     anywhere             YY.YY.YY.YY         tcp dpt:irdmi

Chain OUTPUT (policy ACCEPT 14248 packets, 8532K bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain acctboth (0 references)
num   pkts bytes target     prot opt in     out     source               destination

então a regra foi adicionada e alguns pacotes passaram por ela. Mas ainda estou recebendo tempo limite de conexão do navegador ao conectar a XX.XX.XX.XX: 8000

Alguém pode me indicar o erro? Obrigado antecipadamente!

PS. route -n output do balanceador de carga - onde eu coloquei estas regras:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
173.199.160.147 0.0.0.0         255.255.255.255 UH    0      0        0 eth1
173.199.160.146 0.0.0.0         255.255.255.255 UH    0      0        0 eth1
173.199.160.145 0.0.0.0         255.255.255.255 UH    0      0        0 eth1
173.199.160.144 0.0.0.0         255.255.255.255 UH    0      0        0 eth1
96.30.32.0      0.0.0.0         255.255.255.192 U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
172.16.0.0      0.0.0.0         255.252.0.0     U     0      0        0 eth0
0.0.0.0         96.30.32.1      0.0.0.0         UG    0      0        0 eth1

YY.YY.YY.YY é na realidade 172.17.4.10.

saída ifconfig, apenas duas interfaces que provavelmente afetam tudo isso:

eth0      Link encap:Ethernet  HWaddr 00:25:90:53:1F:A8
          inet addr:172.17.4.163  Bcast:172.19.255.255  Mask:255.252.0.0
          inet6 addr: fe80::225:90ff:fe53:1fa8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:111646 errors:0 dropped:0 overruns:0 frame:0
          TX packets:79057 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:63144265 (60.2 MiB)  TX bytes:11600837 (11.0 MiB)
          Interrupt:217 Memory:fb900000-fb920000

eth1      Link encap:Ethernet  HWaddr 00:25:90:53:1F:A9
          inet addr:96.30.32.10  Bcast:96.30.32.63  Mask:255.255.255.192
          inet6 addr: fe80::225:90ff:fe53:1fa9/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:116136 errors:0 dropped:0 overruns:0 frame:0
          TX packets:101365 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:16607792 (15.8 MiB)  TX bytes:89471131 (85.3 MiB)
          Interrupt:233 Memory:fba00000-fba20000

ip_forwarding:

root@load1 [~]# cat /proc/sys/net/ipv4/conf/eth0/forwarding
1
root@load1 [~]# cat /proc/sys/net/ipv4/conf/eth1/forwarding
1
root@load1 [~]# cat /proc/sys/net/ipv4/ip_forward
1

    

Answer 1

Como o roteamento está aparentemente habilitado, outra configuração incorreta possível e bastante popular seria a rota padrão em 172.17.4.10 não passando por 172.17.4.163. Nesse caso, um pacote de entrada seria DNATed corretamente para 172.17.4.10, mas a resposta seria roteada para fora através de um destino diferente, obtendo assim o endereço IP de origem "errado".

Em geral, uma boa maneira de realmente saber o que está acontecendo é executar o tcpdump

tcpdump -i eth0 -v -n host 172.17.4.10

e tentando se conectar. A saída deve ser perspicaz.

    

Answer 2

Sua regra nat de iptables está errada. Altere para:

iptables -A PREROUTING -t nat -p tcp --dport 8000 -j DNAT --to-destination YY.YY.YY.YY:8000