translation de port dans une liaison UDP

"Stan" wrote in message <44a3c714$0$863$ba4acef3@news.orange.fr>:

[ X-post: fcolc, fcri, fcou ; fu2: fcolc]

Le fu2 n'était pas positionné.

Aujourd'hui, j'ai la configuration suivante ( Linux RedHat ):

login a , password -> mgetty -> pppd ....( UDP, port x ).... application1
login b , password -> mgetty -> pppd ....( UDP, port y ).... application2

Je ne comprends absolument pas ce que tu veux dire par là. Si tu veux de
l'aide, il faut probablement expliquer un peu mieux.

Dans le message <news:e80mo4$28l4$1@biggoron.nerim.net>,
*Nicolas George* tapota sur f.c.o.l.configuration, f.c.o.unix et f.c.r.ip :

"Stan" wrote in message <44a3c714$0$863$ba4acef3@news.orange.fr>:

[ X-post: fcolc, fcri, fcou ; fu2: fcolc]

Le fu2 n'était pas positionné.

Et j'ai un beau « No such article » avec ce M-ID. Filtrage du à un message
crossposté sur trop de groupes à la fois sans fu2 positionné ?

--
Sébastien Monbrun aka TiChou

Salut,

[ X-post: fcolc, fcri, fcou ; fu2: fcolc]

Suivi respecté, même si l'en-tête manquait. ;-)

Bonjour,

Aujourd'hui, j'ai la configuration suivante ( Linux RedHat ):

login a , password -> mgetty -> pppd ....( UDP, port x ).... application1
login b , password -> mgetty -> pppd ....( UDP, port y ).... application2

Je souhaiterai faire en sorte que :
login c , password -> mgetty -> pppd ....( UDP, port x ).... application1
et ce, quelque soit le port utilisé par l'application qui se connecte
sous le login 'c'.

Avez-vous une idée pour réaliser cela ?

Merci d'avance.

Je cite l'intégraité de l'article pour les ceusses qui lisent sur un
serveur fassiste qui filtre les crossposts dans trois forums sans suivi
et qui auraient la flemme d'aller le chercher ailleurs. :-p

Au fait, moi non plus je n'ai rien compris à la question...

Dans le message <news:e80rmg$2aro$1@biggoron.nerim.net>,
*Pascal Hambourg* tapota sur f.c.o.l.configuration :

Salut Pascal,

[...]

Je cite l'intégraité de l'article pour les ceusses qui lisent sur un
serveur fassiste qui filtre les crossposts dans trois forums sans suivi et
qui auraient la flemme d'aller le chercher ailleurs. :-p

Ouf, ça va, je ne me sens pas concerné, ayant cherché ailleurs. :-P

Au fait, moi non plus je n'ai rien compris à la question...

Avec une contribution financière, je me forcerais bien à comprendre. Mais va
falloir qu'elle soit sacrément élevée. ;-)

--
Sébastien Monbrun aka TiChou

"Nicolas George" <nicolas$george@salle-s.org> a écrit dans le message de
news: e80mo4$28l4$1@biggoron.nerim.net...

"Stan" wrote in message <44a3c714$0$863$ba4acef3@news.orange.fr>:

[ X-post: fcolc, fcri, fcou ; fu2: fcolc]

Le fu2 n'était pas positionné.

Raaah, v'la c'que c'est de se précipiter :-(

Aujourd'hui, j'ai la configuration suivante ( Linux RedHat ):

login a , password -> mgetty -> pppd ....( UDP, port x ).... application1
login b , password -> mgetty -> pppd ....( UDP, port y ).... application2

Je ne comprends absolument pas ce que tu veux dire par là. Si tu veux de
l'aide, il faut probablement expliquer un peu mieux.

J'ai un flux UDP qui arrive sur un RAS ( modems ), je voudrai,
en fonction du login utilisateur, faire une translation du port de
destination.

Ex : un automate se connecte sur le RAS avec le login machin;
il envoie des paquets vers l'adresse 192.168.1.1, port 2000.

Je veux que le port soit modifié par une nouvelle valeur, 2004.

C'est plus clair ?

--
-Stan

OoO Lors de la soirée naissante du jeudi 29 juin 2006, vers 18:43,
"Stan" <none@none.fr> disait:

Ex : un automate se connecte sur le RAS avec le login machin;
il envoie des paquets vers l'adresse 192.168.1.1, port 2000.

Je veux que le port soit modifié par une nouvelle valeur, 2004.

Tu utilises l'owner match pour effectuer la translation.
--
I WILL ONLY DO THIS ONCE A YEAR
I WILL ONLY DO THIS ONCE A YEAR
I WILL ONLY DO THIS ONCE A YEAR
-+- Bart Simpson on chalkboard in episode 3F31

Dans le message <news:44a40345$0$863$ba4acef3@news.orange.fr>,
*Stan* tapota sur f.c.o.l.configuration :

J'ai un flux UDP qui arrive sur un RAS ( modems ), je voudrai,
en fonction du login utilisateur, faire une translation du port de
destination.

Ex : un automate se connecte sur le RAS avec le login machin;
il envoie des paquets vers l'adresse 192.168.1.1, port 2000.

Je veux que le port soit modifié par une nouvelle valeur, 2004.

C'est plus clair ?

Pas trop non. Je vous propose malgré tout quelques solutions.

- Attribuer une adresse IP fixe et distincte pour chaque client/login.
Ainsi, en fonction de l'adresse IP source, du protocole et de la destination
on peut établir une règle de DNAT.

- Utiliser les scripts d'initialisation lancés par pppd (auth-up et
auth-down et/ou ip-up et ip-down) et en fonction du login, récupérable via
les variables d'environnement (PEERNAME, PPPLOGNAME) et/ou via les arguments
des scripts, créer/supprimer la règle de DNAT qui convient. man pppd.

- Revoir l'application client-serveur. ;-)

--
Sébastien Monbrun aka TiChou

"Sébastien Monbrun aka TiChou" <gro.uohcit@uohcit> a écrit dans le message
de news: bzium.20060629234628@florizarre.tichou.org...

C'est plus clair ?

Pas trop non. Je vous propose malgré tout quelques solutions.

Sans doute parce que vous essayez de comprendre à quoi

ça correspond au niveau applicatif ; mais ce n'est
pas une application très 'standard'.

- Utiliser les scripts d'initialisation lancés par pppd (auth-up et
auth-down et/ou ip-up et ip-down) et en fonction du login, récupérable via
les variables d'environnement (PEERNAME, PPPLOGNAME) et/ou via les
arguments des scripts, créer/supprimer la règle de DNAT qui convient. man
pppd.

Et en utilisant REDIRECT (iptable), n'est-ce pas plus approprié ou plus
simple ?

- Revoir l'application client-serveur. ;-)

Nan !

--
-Stan

Dans le message <news:44a4db85$0$868$ba4acef3@news.orange.fr>,
*Stan* tapota sur f.c.o.l.configuration :

C'est plus clair ?

Pas trop non. Je vous propose malgré tout quelques solutions.

Sans doute parce que vous essayez de comprendre à quoi
ça correspond au niveau applicatif ;

Non, à ce stade cela m'importe peu de comprendre ce que votre application
peu bien faire. Même si effectivement cela peut avoir une importance pour
nous contributeurs. En effet, l'expérience montre que très souvent la
solution recherchée à une problématique donnée et qui nous a été exposée
ici, n'est pas, une fois une solution trouvée, la plus adaptée. La solution
ressemblera vraisemblablement à du bricolage. Pourquoi ? Parce que la réelle
problématique se situe en fait en amont, mais celle-ci nous est
partiellement inconnue, partiellement car on la devine, mais à peine. Et
parce qu'en fait le demandeur n'a pas voulu ou n'a pas jugé utile de nous
donner le contexte, de nous planter le décor et de nous indiquer la finalité
de la chose.
Donc au lieu de nous exposer clairement les choses, nous sommes obligés de
jouer au chat et à la souris si nous souhaitons donner une réponse efficace.

Ici, ce que j'ai essayé de comprendre, et je pense que c'était aussi le cas
des autres contributeurs qui ont commencé à vous répondre, c'est dans un
premier temps votre schéma qui, soyons franc, ne veut rien dire.

pas une application très 'standard'.

Cela vous empêche-t-il d'en parler un minimum ? ;-)

- Utiliser les scripts d'initialisation lancés par pppd (auth-up et
auth-down et/ou ip-up et ip-down) et en fonction du login, récupérable
via les variables d'environnement (PEERNAME, PPPLOGNAME) et/ou via les
arguments des scripts, créer/supprimer la règle de DNAT qui convient.
man pppd.

Et en utilisant REDIRECT (iptable),

REDIRECT est du DNAT local et limité à la translation de port.

n'est-ce pas plus approprié

Oui, sûrement.

ou plus simple ?

À mettre en place ? Non, c'est juste un nom de cible qui change.

--
Sébastien Monbrun aka TiChou

"Sébastien Monbrun aka TiChou" <gro.uohcit@uohcit> a écrit dans le message
de news: gniii.20060630112003@florizarre.tichou.org...
[...]

Donc au lieu de nous exposer clairement les choses, nous sommes obligés de
jouer au chat et à la souris si nous souhaitons donner une réponse
efficace.

Je sais. Dans d'autres domaines, c'est moi qui suit dans cette position.
Cependant il faut aussi être conscient qu'il n'est pas toujours
indispensable d'entrer
dans les détails; mais ça, ce n'est qu'à postériori qu'on s'en rend compte.

Certains pb sont si courrant que le 'schéma' suffit pour le résoudre,
mais d'autres sont fortement liés au contexte, sans lequel aucune réponse
ne peut être apportée.

Ici, ce que j'ai essayé de comprendre, et je pense que c'était aussi le
cas des autres contributeurs qui ont commencé à vous répondre, c'est dans
un premier temps votre schéma qui, soyons franc, ne veut rien dire.

La prochaine fois j'utiliserai DIA, promis ;-)

pas une application très 'standard'.

Cela vous empêche-t-il d'en parler un minimum ? ;-)

Je croyais l'avoir fait ;-)

Ce sont des automates qui se connectes sur un RAS.
En fonction du client chez qui se trouve l'automate,
correspond un login de cnx ( 1 par famille de clients ).
L'automate dialogue avec une application serveur qui
se trouve sur une autre machine que le RAS ( ds le même subnet ).
Il y a donc autant d'applications serveur que de login.
Chaque applications serveur écoute sur un port donné;
Aujourd'hui, ce n'est pas le login qui défini de façon absollu
l'application cible; c'est le numéro de port que l'automate utilise.
Or moi, je souhaite que ce soit uniquement le login qui définisse
l' application à utiliser au bout du 'tuyau' UDP.

Même si cela semble un peu ésotérique, il s'agit d'un parc
qui a évolué avec le temps et sur lequel on ne peut rien modifier
côté client.

REDIRECT est du DNAT local et limité à la translation de port.

En fait, dans mon cas, c'est DNAT qu'il me faut ( le flux UDP
doit aller vers une autre machine ).

À mettre en place ? Non, c'est juste un nom de cible qui change.

Vous n'auriez pas un p'tit exemple ( auth-up et
auth-down + DNAT) ?

Merci.

--
-Stan