Назад | Перейти на главную страницу

перенаправление портов iptables от балансировщика нагрузки на внутренний веб-сервер

У меня возникли проблемы с перенаправлением порта 8000 из моего балансировщика нагрузки (единственная точка входа с внешним IP-адресом) на веб-сервер (на порт 8000), имеющий внутренний IP-адрес.

Итак, мне нужно XX.XX.XX.XX: 8000 -> YY.YY.YY.YY: 8000, где XX.XX.XX.XX - внешний IP-адрес, а YY.YY.YY.YY - внутренний.

При входе в систему XX.XX.XX.XX через ssh можно выполнить telnet YY.YY.YY.YY 8000, и он успешно подключается. Вот команды iptables, которые я запустил (на 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

и вот вывод 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

Итак, правило было добавлено, и через него прошли несколько пакетов. Но при подключении к XX.XX.XX.XX: 8000 у меня все еще появляется тайм-аут соединения из браузера.

Может кто-нибудь указать мне на ошибку? Заранее спасибо!

PS. route -n вывод из балансировщика нагрузки - где я поместил эти правила:

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 на самом деле 172.17.4.10.

ifconfig, только два интерфейса, которые, вероятно, влияют на все это:

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

Ваше правило iptables nat неверно. Измените его на:

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

Поскольку маршрутизация явно включена, другой возможной и довольно популярной ошибкой в ​​конфигурации будет маршрут по умолчанию на 172.17.4.10, не проходящий через 172.17.4.163. В этом случае входящий пакет будет правильно назначен DNAT на 172.17.4.10, но ответ будет направлен через другое место назначения, таким образом получится «неправильный» IP-адрес источника.

В общем, хороший способ узнать, что происходит, - запустить tcpdump.

tcpdump -i eth0 -v -n host 172.17.4.10

и пытаюсь подключиться. Результат должен быть проницательным.