Řešení 1:
Tato pravidla by měla fungovat za předpokladu, že iptables běží na serveru 192.168.12.87 :
#!/bin/sh
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -F
iptables -t nat -F
iptables -X
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.12.77:80
iptables -t nat -A POSTROUTING -p tcp -d 192.168.12.77 --dport 80 -j SNAT --to-source 192.168.12.87
Musíte DNAT příchozího provozu na portu 80, ale budete také muset SNAT provoz zpět.
Alternativa (a nejlepší přístup IMHO):
V závislosti na tom, jaký je váš webový server (Apache, NGinx), byste měli zvážit použití HTTP proxy na vašem front-end serveru (192.168.12.87):
-
mod_proxy (Apache)
-
proxy_pass (NGinx)
Řešení 2:
Důvod je zdánlivě zřejmý iptables -t nat -A PREROUTING -d 192.168.12.87 -p tcp --dport 80 -j DNAT --to-destination 192.168.12.77 nebude fungovat, jak budou směrovány návratové pakety.
Můžete nastavit pravidla, která způsobí, že pakety odesílané na 192.168.12.87 budou jednoduše NATovány na 192.168.12.77, ale 192.168.12.77 pak odešle odpovědi přímo zpět klientovi. Tyto odpovědi neprojdou přes hostitele, kde vaše pravidlo iptables provádí NAT, takže pakety v jednom směru jsou přeloženy, ale pakety v druhém ne.
Existují tři přístupy k řešení tohoto problému.
- Na prvním hostiteli neprovádějte pouze DNAT, ale také SNAT, takže zpětný provoz bude poslán zpět přes prvního hostitele. Pravidlo může vypadat jako
iptables -t NAT -A POSTROUTING -d 192.168.12.77 -p tcp --dport 80 -j SNAT --to-source 192.168.12.87 - Inspirujte se vyrovnáváním zátěže DSR a DNAT paketů na vrstvě Ethernet místo na vrstvě IP. Nahrazením cílové MAC paketů MAC 192.168.12.77 a jejím odesláním na Ethernet bez dotyku IP vrstvy, pak 192.168.12.77 může mít 192.168.12.87 nakonfigurováno na fiktivním rozhraní a tak být schopno ukončit TCP spojení. s IP serveru známou klientovi.
- Na prvním hostiteli použijte naivní (ale nefunkční) řešení. Poté zpracujte návratové pakety na druhém hostiteli provedením SNAT na návratovém provozu. Pravidlo může vypadat jako
iptables -t nat -A OUTPUT -p tcp --sport 80 -j SNAT --to-source 192.168.12.87
Každé z těchto tří řešení má své nevýhody, takže musíte pečlivě zvážit, zda toto konkrétní přeposílání opravdu potřebujete.
- Použití SNAT ztratí IP klienta, takže hostitel číslo 2 si bude myslet, že všechna připojení pocházejí z 192.168.12.87. Navíc budete používat šířku pásma přes hostitele číslo 1 pro všechny pakety odpovědí, což by s ostatními přístupy mělo přímější cestu.
- Přístup DSR přeruší veškerou další komunikaci mezi těmito dvěma uzly. Přístup DSR je skutečně vhodný pouze tehdy, když adresa serveru není primární IP žádného z hostitelů. Každý hostitel musí mít primární IP, která není DSR IP.
- Používání sledování připojení na jednom hostiteli k překladu jedním směrem a sledování připojení na jiném hostiteli k překladu opačným směrem je prostě ošklivé a existuje několik způsobů, jak by se to mohlo přerušit. Pokud jsou například čísla portů změněna pomocí NAT na kterémkoli hostiteli, neexistuje způsob, jak je rekonstruovat. Není také samozřejmé, že sledování připojení bude fungovat správně, pokud první paket, který uvidí, je SYN-ACK spíše než ACK.
Ze tří přístupů si myslím, že první je ten, který s největší pravděpodobností bude fungovat. Pokud tedy nepotřebujete znát klientské IP adresy, doporučuji právě tu.
Můžete se také rozhodnout zapomenout na NAT úplně a nepokoušet se řešit problém na vrstvě MAC nebo IP. Můžete jít až k vrstvě HTTP a hledat řešení tam. V tom případě řešením, které najdete, je HTTP proxy. Pokud nainstalujete HTTP proxy na 192.168.12.87 a nakonfigurujete jej správně, můžete nechat přeposílat požadavky na 192.168.12.77 a přeposílat odpovědi zpět. Navíc může vložit hlavičku X-Forwarded-For, která zachová původní IP klienta. Server na 192.168.12.77 pak musí být nakonfigurován tak, aby důvěřoval hlavičce X-Forwarded-For z 192.168.12.87.