web-dev-qa-db-fra.com

Comment faire la redirection de port d'une IP à une autre IP dans le même réseau?

Je voudrais faire un peu de NAT dans iptables. Pour que tous les paquets arrivant à 192.168.12.87 et port 80 sera transmis à 192.168.12.77 Port 80.

Comment faire cela avec iptables?

Ou

Y a-t-il d'autres façons d'y parvenir?

linuxiptablesport-forwarding
81
sat

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 trafic entrant sur le port 80, mais vous devrez également SNAT le trafic retour.

Alternative (et meilleure approche à mon humble avis):

En fonction de votre serveur Web (Apache, NGinx), vous devez envisager un proxy HTTP sur votre serveur frontal (192.168.12.87):

79
krisFR

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 routé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 ensuite des réponses directement au client. Ces réponses ne passeront pas par l'hôte où votre règle iptables fait NAT, donc les paquets dans un sens sont traduits, mais les paquets dans l'autre sens ne le sont pas.

Il existe trois approches pour résoudre ce problème.

  1. Sur le premier hôte, ne faites pas seulement DNAT, mais aussi SNAT de telle sorte que le trafic de retour sera 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
  2. Inspirez-vous de l'équilibrage de charge DSR et DNAT les paquets au niveau de la couche Ethernet au lieu de la couche IP. En remplaçant le MAC de destination des paquets par le MAC de 192.168.12.77 et en l'envoyant sur Ethernet sans toucher la couche IP, alors 192.168.12.77 pourrait avoir 192.168.12.87 configuré sur une interface factice et ainsi être en mesure de terminer le TCP avec l'IP du serveur connue du client.
  3. Utilisez la solution naïve (mais ne fonctionne pas) sur le premier hôte. Ensuite, gérez 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.

  1. L'utilisation de SNAT perdra l'IP du client, donc 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 itinéraire plus direct avec les autres approches.
  2. 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 l'adresse IP principale d'aucun des hôtes. Chaque hôte doit avoir une IP principale, qui n'est pas l'IP DSR.
  3. Utiliser le suivi de connexion sur un hôte pour traduire dans une direction et le suivi de connexion sur un autre hôte pour traduire dans l'autre direction est tout simplement laid, et il existe plusieurs façons de le casser. Par exemple, si les numéros de port sont modifiés par NAT sur l'un ou l'autre hôte, il n'y a aucun moyen de les reconstruire. Ce n'est pas non plus une donnée, 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 est la plus susceptible 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 NAT et 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 demander de transmettre les demandes à 192.168.12.77 et de renvoyer les réponses. De plus, il peut insérer un en-tête X-Forwarded-For en préservant l'IP client d'origine. Le serveur sur 192.168.12.77 doit ensuite être configuré pour faire confiance à l'en-tête X-Forwarded-For de 192.168.12.87.

29
kasperd