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.

[Invité]

A partir du moment que les adresses IP1 et IP2 (serveur nominal et backup respectivement) sont publiques, ells sont routables au travers du réseau GPRS de votre opérateur. Donc un mécanisme de routage devrait suffire, vous n'avez pas besoin de translation d'adresse !

J'ai compris que faisiez du testing... Quid de votre architecture cible ? Est-ce que les serveurs d'adresses IP1 et IP2 sont physiquement distincts ?

Steph

[eracius]

L'idée du routage chez l'opérateur n'est pas bête seulement nous travaillons avec plusieurs opérateur en Europe selon les pays. Pour certain avec un APN public et pour d'autre avec un APN privé. Sur les APN privés, je pense qu'on doit pouvoir faire ce routage mais je dois voir avec mes contacts techniques. Sur les APN publics j'y crois moins. Mais ça peut être une solution de secours.

Par contre, cela implique une grosse dépendance envers les opérateurs et nous voulons éviter cela. Nous voulons avec les clefs au maximum et avoir toute la souplesse possible. D'où les IP failover.

Sinon IP1 et IP2 sont bien distincts.

[Invité]

Le principe de base dans ces archis, c'est de router ce qui est routable... C'est quand même le job d'un opérateur. Et vaut mieux dépendre de x opérateurs plutôt qu'un seul, histoire d'éviter le fameux "single point of failure" qui fait pleurer les DSI le jour de grand crash. Enfin, c'est mon avis...

Si vous payez pour des adresses IP publiques, le coût implique non seulement la propriété de ces adresses mais également leur propagation sur tout réseau de transport de données IP public. Donc si vos opérateurs s'engagent à router ce qui est routable, votre job est de mettre à disposition les subnets/adresses vitales disponibles pour vos clients :-)

Dans votre démarche, vous voulez translater une adresse par une autre qui est routable dans votre réseau de transport... Avec cet artifice, vous augmentez la complexité technique de votre projet parce que sans le vouloir, vous vous substituez au travail des opérateurs.

Rapprochez-vous de votre opérateur, je sais qu'il existe des solutions à ce genre de problématique !

Steph