115 votes

Comment faire le transfert de port d'une ip vers une autre ip dans le même réseau ?

J'aimerais faire NAT en iptables . Ainsi, tous les paquets arrivant à 192.168.12.87 et le port 80 sera transmise à 192.168.12.77 port 80 .

Comment faire cela avec iptables ?

Ou

Y a-t-il d'autres moyens de parvenir au même résultat ?

0 votes

@Matthewlfe, Pour une raison quelconque, je dois transférer toutes les requêtes apache de (192.168.12.87) vers (192.168.12.77).

1 votes

@Matthewlfe, j'ai deux serveurs de production. L'un est connecté avec une adresse IP statique publique. En raison de certains problèmes de connectivité, je ne suis pas en mesure de me connecter à la base de données et aux autres systèmes à partir de l'adresse IP publique. 192.168.12.87 . Donc, je dois transmettre toutes les demandes à 192.168.12.77 .

0 votes

@lain, je ne suis pas familier avec iptables . Et, j'ai vu quelques exemples. Mais, il semble qu'il faille deux ethernet. Lien : revsys.com/writings/quicktips/nat.html

107voto

krisFR Points 12580

Ces règles devraient fonctionner, en supposant que iptables est exécuté 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 IMHO) :

Selon le type de votre serveur Web (Apache, NGinx), vous devriez envisager d'installer un proxy HTTP sur votre serveur frontal (192.168.12.87) :

0 votes

Cela fonctionne tant que l'ufw est désactivé, même si le port est autorisé par l'ufw, mais si l'ufw est activé, le transfert ne fonctionne pas, une idée ?

2 votes

Excellente question avec une excellente réponse. Un autre cas d'utilisation pour lequel c'est utile est si vous avez besoin de rediriger temporairement tout le trafic arrivant à un service, disons squid, vers un autre ip/port afin d'effectuer une maintenance sur le service original sans avoir besoin de reconfigurer tous les clients ! Très pratique !

4 votes

" mais vous devrez aussi SNAT le trafic en retour. " -> Vous avez sauvé ma journée. Merci

35voto

martin Points 49

La raison qui semble évidente iptables -t nat -A PREROUTING -d 192.168.12.87 -p tcp --dport 80 -j DNAT --to-destination 192.168.12.77 ne fonctionnera pas est la façon dont les paquets de retour seront acheminés.

Vous pouvez configurer des règles qui feront en sorte que les paquets envoyés à 192.168.12.87 seront simplement NATés vers 192.168.12.77, mais 192.168.12.77 renverra alors les réponses directement au client. Ces réponses ne passeront pas par l'hôte sur lequel votre règle iptables effectue la NAT. Ainsi, les paquets dans une direction sont traduits, mais pas les paquets dans l'autre direction.

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

  1. Sur le premier hôte, ne faites pas seulement du DNAT, mais aussi du SNAT, de sorte que le trafic de retour soit renvoyé par 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. S'inspirer 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, 192.168.12.77 pourrait avoir 192.168.12.87 configuré sur une interface factice et ainsi être capable de terminer la connexion TCP avec l'IP du serveur connue du client.
  3. Utilisez la solution naïve (mais qui ne fonctionne pas) sur le premier hôte. Traitez ensuite les paquets de retour sur le second 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, et vous devez donc vous demander si vous avez vraiment besoin de cette redirection particulière.

  1. En utilisant le SNAT, vous perdrez 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, qui prendraient un chemin plus direct avec les autres approches.
  2. L'approche DSR interrompt toute autre communication entre les deux nœuds. L'approche DSR n'est vraiment appropriée que lorsque l'adresse du serveur n'est pas l'IP primaire de l'un des hôtes. Chaque hôte doit avoir une IP primaire, qui n'est pas l'IP DSR.
  3. 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 laid, et il y a plusieurs façons dont il pourrait se briser. Par exemple, si les numéros de port sont modifiés par la NAT sur l'un ou l'autre hôte, il n'y a aucun moyen de les reconstruire. Il n'est pas non plus acquis que le suivi de connexion fonctionnera correctement si le premier paquet qu'il voit est un SYN-ACK plutôt qu'un ACK.

De ces 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 recommande.

Vous pouvez également choisir d'oublier complètement la NAT et ne pas essayer de résoudre le problème sur la couche MAC ou IP. Vous pouvez remonter 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 correctement, 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 préservant l'IP du client original. 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.

1 votes

Je suis surpris -j MASQUERADE n'est pas mentionné ici ; n'est-ce pas l'approche habituelle avec le DNAT ?

7 votes

@remram j'ai mentionné SNAT au lieu de MASQUERADE car c'est ce que dit la documentation. La formulation exacte de la documentation est la suivante : It should only be used with dynamically assigned IP (dialup) connections: if you have a static IP address, you should use the SNAT target.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X