Solution 1 :
Ces règles devraient fonctionner, en supposant que iptables s'exécute sur le serveur 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
Vous devez DNAT le trafic entrant sur le port 80, mais vous devrez également SNAT le trafic en retour.
Alternative (et meilleure approche à mon humble avis) :
En fonction de votre serveur Web (Apache, NGinx), vous devriez envisager un proxy HTTP sur votre serveur frontal (192.168.12.87) :
-
mod_proxy (Apache)
-
proxy_pass (NGinx)
Solution 2 :
La raison pour laquelle un iptables -t nat -A PREROUTING -d 192.168.12.87 -p tcp --dport 80 -j DNAT --to-destination 192.168.12.77 apparemment évident ne fonctionnera pas est la façon dont les paquets de retour seront acheminés.
Vous pouvez configurer des règles qui feront que les paquets envoyés à 192.168.12.87 seront simplement NATtés à 192.168.12.77, mais 192.168.12.77 enverra alors des réponses directement au client. Ces réponses ne passeront pas par l'hôte sur lequel votre règle iptables effectue le NAT, donc les paquets dans un sens sont traduits, mais pas les paquets dans l'autre sens.
Il existe trois approches pour résoudre ce problème.
- Sur le premier hôte, ne faites pas que DNAT, mais faites également SNAT de sorte que le trafic de retour soit renvoyé via le premier hôte. La règle pourrait ressembler à quelque chose comme
iptables -t NAT -A POSTROUTING -d 192.168.12.77 -p tcp --dport 80 -j SNAT --to-source 192.168.12.87 - Inspirez-vous de l'équilibrage de charge DSR et DNAT les paquets au niveau Ethernet plutôt qu'au niveau IP. En remplaçant le MAC destination des paquets par le MAC de 192.168.12.77 et en l'envoyant sur l'Ethernet sans toucher à la couche IP, alors 192.168.12.77 pourrait avoir 192.168.12.87 configuré sur une interface factice et ainsi pouvoir terminer la connexion TCP avec l'IP du serveur connue du client.
- Utilisez la solution naïve (mais qui ne fonctionne pas) sur le premier hôte. Gérez ensuite les paquets de retour sur le deuxième hôte en effectuant un SNAT sur le trafic de retour. Une règle pourrait ressembler à
iptables -t nat -A OUTPUT -p tcp --sport 80 -j SNAT --to-source 192.168.12.87
Chacune de ces trois solutions présente des inconvénients, vous devez donc examiner attentivement si vous avez vraiment besoin de faire ce transfert particulier.
- L'utilisation de SNAT entraînera la perte de l'adresse IP du client. Ainsi, l'hôte numéro 2 pensera que toutes les connexions proviennent de 192.168.12.87. De plus, vous utiliserez la bande passante via l'hôte numéro 1 pour tous les paquets de réponse, ce qui emprunterait un chemin plus direct avec les autres approches.
- L'approche DSR interrompra toutes les autres communications entre les deux nœuds. L'approche DSR n'est vraiment appropriée que lorsque l'adresse du serveur n'est pas l'adresse IP principale de l'un des hôtes. Chaque hôte doit avoir une adresse IP principale, qui n'est pas l'adresse IP du DSR.
- Utiliser le suivi de connexion sur un hôte pour traduire dans un sens et le suivi de connexion sur un autre hôte pour traduire dans l'autre sens est tout simplement moche, et il peut se casser de différentes manières. Par exemple, si les numéros de port sont modifiés par NAT sur l'un ou l'autre des hôtes, il n'y a aucun moyen de les reconstruire. Il n'est pas non plus certain que le suivi de connexion fonctionnera correctement si le premier paquet qu'il voit est un SYN-ACK plutôt qu'un ACK.
Des trois approches, je pense que la première est celle qui a le plus de chances de fonctionner. Donc, si vous n'avez pas besoin de connaître les adresses IP des clients, c'est celle que je recommanderais.
Vous pouvez également choisir d'oublier complètement le NAT et de ne pas essayer de résoudre le problème sur la couche MAC ou IP. Vous pouvez aller jusqu'à la couche HTTP et y chercher une solution. Dans ce cas, la solution que vous trouverez est un proxy HTTP. Si vous installez un proxy HTTP sur 192.168.12.87 et que vous le configurez de manière appropriée, vous pouvez lui faire transférer les requêtes vers 192.168.12.77 et renvoyer les réponses. De plus, il peut insérer un en-tête X-Forwarded-For en préservant l'adresse IP client d'origine. Le serveur sur 192.168.12.77 doit alors être configuré pour faire confiance à l'en-tête X-Forwarded-For de 192.168.12.87.