Я хочу заменить iptables (8) на IPVS для обратного прокси TCP, в котором используется двусторонний NAT.
Моя текущая установка с использованием iptables функционально эквивалентна пересылке пользовательского пространства (например, socat (1)). Он имеет следующую настройку:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8000 -j DNAT --to-destination 172.31.1.1:80
# iptables -P FORWARD ACCEPT
iptables -t nat -A POSTROUTING -o eth1 -d 172.31.1.1 -p tcp --dport 80 -j MASQUERADE
На машине стоит 10.0.0.2 на eth0 и 172.31.0.2 на eth1. Также есть следующие маршруты:
default via 10.0.0.1 dev eth0
172.31.0.0/24 dev eth1
172.31.1.0/24 via 172.31.0.1 dev eth1
Я говорю, что это «функционально эквивалентно» прокси пользовательского пространства, потому что весь трафик, поступающий на TCP-адрес 10.0.0.2:8000, перенаправляется на узел интрасети 172.31.1.1, тогда как на целевом узле трафик, по-видимому, исходит от 172.31.0.2 вместо настоящий хозяин. Ни одна из сторон не видит фактический адрес противоположной стороны, только этот обратный прокси-сервер.
Я пытаюсь изучить IPVS, заменив эту настройку на основе iptables на Linux Virtual Server. Я начал с этого:
ipvsadm -A -t 10.0.0.2:8000
ipvsadm -a -t 10.0.0.2:8000 -r 172.31.1.1:80 -m
Критический момент заключается в том, что часто ни исходный, ни целевой хост недоступны по той же ссылке, что и один из интерфейсов. Возможно, потребуется направить трафик на шлюз с обеих сторон.
Я не мог понять почему curl http://10.0.0.2:8000/ на этом хосте дает ожидаемый результат, в то время как та же самая команда даже не устанавливает TCP-соединение при запуске на хосте вне сети (10.0.0.2 / eth0 общедоступен).
С помощью tcpdump, Я вижу пакет SYN на бэкэнд, пакет SYNACK вернулся, но после этого нет ACK (3-й шаг трехстороннего установления связи TCP).
Я знаю, что эту проблему может решить VPN или просто туннелирование, но я хочу обойтись без них.
Если это актуально, этот обратный прокси-сервер работает под управлением CentOS 7.7 с отключенными SELinux и firewalld.