Маршрутизация LDAP-трафика от сервера приложений к прокси-серверу в Интернет

Я добавил рисунок, чтобы вы поняли, как это будет работать. (Красный = соединения LDAP, синий = HTTP / AJP в бэкэнде)

Проблема: Мы хотим подключить наш сервер приложений клиента к LDAP клиента (или позволить им сделать это).

Это было бы легко, если бы мы сделали это с общедоступным интерфейсом сервера приложений, НО мы хотели бы со временем отключить этот интерфейс. Мы хотим направить весь трафик, который необходим для выхода на прокси, и он доставит пакеты по назначению.

Теперь это будет также для других сервисов, но основным из них является LDAP (настроить дополнительные не так сложно, если у нас есть LDAP в порядке). Мы не хотим перенаправлять ВСЕ трафик, потому что нам все еще нужен трафик для наших внутренних служб (баз данных и т. Д.).

Решение было бы:

Запустите запрос LDAP с сервера приложений.
Отправить весь запрос LDAP + трафик на eth1 с сервера приложений на прокси eth1
Перенаправьте весь трафик LDAP с eth1 на eth0 (прокси), чтобы иметь доступ к Интернету.

Я хотел бы знать, как решить эту проблему наиболее безопасным и масштабируемым способом (чтобы автоматизировать это) с помощью IPTABLES.

Итак, я ищу лучшее решение IPTABLES реализовать на нашем сервере приложений и прокси

РЕДАКТИРОВАТЬ :

Тестирование с двумя бродячими боксами: Host0 = сервер приложений Host1 = прокси

Все еще борюсь с этим. Но я подхожу на шаг ближе.

Весь мой LDAP-трафик отправляется на прокси-сервер и обратно, но я получаю только [S] и [S.] обратно и никакого соединения.

Вот что я сделал.

Сервер приложений :

iptables -t mangle -A OUTPUT -p tcp --dport 389 -j MARK --set-mark 0x1
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

$echo 1 LDAP >> /etc/iproute2/rt_tables
$ip rule add fwmark 0x1 lookup LDAP
$ip route add default via 192.168.1.2 table LDAP


[root@host0 ~]# sysctl -A | grep rp_filter
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.arp_filter = 0
net.ipv4.conf.lo.rp_filter = 1
net.ipv4.conf.lo.arp_filter = 0
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.eth0.arp_filter = 0
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.eth1.arp_filter = 0

[root@host0 ~]# sysctl -A | grep net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Прокси:

iptables -t nat -A POSTROUTING -p tcp -o eth0 --dport 389 -j SNAT --to 10.0.2.15


[root@host1 ~]# sysctl -A | grep rp_filter
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.arp_filter = 0
net.ipv4.conf.lo.rp_filter = 1
net.ipv4.conf.lo.arp_filter = 0
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.eth0.arp_filter = 0
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.eth1.arp_filter = 0

[root@host1 ~]# sysctl -A | grep net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Это tcpdump на eth1 (частном) сервера приложений.

13:31:51.629687 IP 192.168.56.10.59528 > ec2-23-20-46-132.compute-1.amazonaws.com.ldap: Flags [S], seq 1571039960, win 14600, options [mss 1460,sackOK,TS val 18491218 ecr 0,nop,wscale 3], length 0
13:31:51.749145 IP ec2-23-20-46-132.compute-1.amazonaws.com.ldap > 192.168.56.10.59528: Flags [S.], seq 1604232705, ack 1571039961, win 65535, options [mss 1460], length 0
13:31:52.630908 IP 192.168.56.10.59528 > ec2-23-20-46-132.compute-1.amazonaws.com.ldap: Flags [S], seq 1571039960, win 14600, options [mss 1460,sackOK,TS val 18492219 ecr 0,nop,wscale 3], length 0
13:31:54.633277 IP 192.168.56.10.59528 > ec2-23-20-46-132.compute-1.amazonaws.com.ldap: Flags [S], seq 1571039960, win 14600, options [mss 1460,sackOK,TS val 18494222 ecr 0,nop,wscale 3], length 0