Discussion :

[eracius]

Bonjour,

Nous souhaitons mettre en place des règles iptables pour réaliser le schéma suivant :

- IP client : 1.1.1.1
- IP serveur : 2.2.2.2 (ip physique) et 3.3.3.3 (alias IP)
- protocole UDP

Le client essaye d'accéder en UDP à un programme du serveur qui écoute sur 9292

-> client fait une requête UDP à 1.1.1.1:9999/3.3.3.3:9292
-> réception par le serveur et traitement
<- réponse UDP du serveur à 3.3.3.3:9292/1.1.1.1:9999
<- réception par le client

Hors, dans la pratique, le serveur répond 2.2.2.2:9292/1.1.1.1:9999 ce qui fait que le client ne reçoit jamais la réponse.

Avec iptables, il est possible de faire du post routing sur le serveur pour dire : tout ce qui sort par udp, tu dois utiliser 3.3.3.3 comme adresse source :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

iptables -t nat -A POSTROUTING -o eth0 -p udp -j SNAT --to-source 3.3.3.3:9292

Mais problème, lorsque nous faisons ça, la réponse ne part pas. Il semblerait que lorsqu'un programme écoute sur un port, les post routage iptables ne fonctionnent pas dessus. Nous avons essayé la même règle en mettant 9393 et la réponse est bien envoyée avec 3.3.3.3:9393/1.1.1.1:9999 ce qui ne résout pas notre problème mais est une première piste.

Première question : connaissez vous la raison pour laquelle la règle iptable ne fonctionne pas sur un port écouté ?

Pour résoudre le problème, nous avons eu l'idée de coupler notre règle de post routing avec une règle de pré routing :

- Le serveur écoute sur le port 9595
- Le client fait sa requête sur le port 9292
- iptables se charge de faire la traduction entre 9292 et 9595 sur le serveur

-> client 1.1.1.1:9999/3.3.3.3:9292
-> serveur reçoit
-> iptable transforme en 1.1.1.1:9999/3.3.3.3:9595
<- le programme du serveur traite et répond à 3.3.3.3:9595/1.1.1.1:9999
<- iptable transforme en 3.3.3.3:9292/1.1.1.1:9999
<- le client reçoit

Les règles iptables :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
iptables -t nat -A PREROUTING -i eth0 -p udp -j DNAT --to 2.2.2.2:9595
iptables -t nat -A POSTROUTING -o eth0 -p udp -j SNAT --to-source 3.3.3.3:9292

Problème ici, nous arrivons bien à nos fins seulement tout le trafic UDP est redirigé vers notre programme qui écoute sur 9595 sur le serveur et nous ne trouvons pas l'option pour spécifier le port pour la règle de pré routing.

Deuxième question : comment spécifier un port pour le pré routing ?

Merci d'avance d'avoir pris le temps de lire tout ça. En espérant que vous soyez inspirés !

[eracius]

oubliez la 2ème question, la règle suivante permet bien de définir correctement les IP et PORT de la règle de PREROUTING

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

iptables -t nat -A PREROUTING -p udp -d 3.3.3.3 --dport 9292 -j DNAT --to 2.2.2.2:9595

[Invité]

Salut,

Quelle est la table de routage du serveur ?

Et quelle est la default gateway du client ?

Steph

[eracius]

Les clients sont des appareils communiquant par GPRS avec le serveur. Les deux entités ne sont donc pas sur un même réseau local. Les adresses IP que nous utilisons sont des adresses publiques.

L'idée de cette manoeuvre est d'avoir une adresse IP failover configurée sur nos appareils lorsqu'ils partent chez les clients de façon à pouvoir rediriger le trafic à notre convenance en cas de défaillance du serveur principal.

[Invité]

J'essaie de comprendre un peu mieux ce que vous voulez modéliser...

D'après ce que je comprends,
- vos équipements accèdent normalement à un serveur IP1,
- lorsqu'IP1 n'est plus joignable, vos équipements ont une adresse de backup, configurée en dur, disons IP2 dans un subnet différent de IP1.

Raisonnons d'abord au niveau IP, je fais abstraction du réseau de transport de données GPRS, je suppose dans un 1er temps qu'il est transparent :-)

Quel mécanisme déclenche la bascule sur IP2 ?

C'est dynamique ? Par exemple le device tentera la connexion sur IP2 après x tentatives et/ou y secondes de timeout.


D'autre part, comment avez-vous configuré votre alias ? Avec une subinterface ?

Steph

[eracius]

Concernant la connexion des appareils, ça fonctionne effectivement comme vous l'avez décrit sauf qu'en l’occurrence, ce mécanisme n'est pas le sujet de notre problème mais plutôt un ancien fonctionnement que nous voulons contourner.

En effet, nos appareils avaient jusqu'à présent 2 IP public vers un serveur et un backup. Nous avons ces serveurs chez OVH et ils ont la particularité d'avoir leur IP liée au hardware. Donc si un jour nous voulons changer de serveur pour monter en gamme par exemple, nous serons obligé de changer d'IP. Ce qui n'est pas possible pour les appareils déjà chez les clients, ils ne sont pas reconfigurables à distance.

Pour les prochains appareils, nous voulons donc remplacer les IP des serveurs par des IP Failover qui pourront être redirigées où bon nous semble.

La problématique est que notre protocole propriétaire est en UDP, ce qui pose des problèmes avec l'IP Failover (voir premier post) et nécessite d'avoir recours à du POSTROUTING. Mais comme nous n'avons pas d'admin réseau dans l'équipe, on patauge tranquillement...

J'espère que ça vous aidera à mieux comprendre le pourquoi du comment.