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

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.

--
-Stan

"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,

Stan a écrit :
> [ 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

"Vincent Bernat" <vincent.bernat@raysa.org> a écrit dans le message de news:
m31wt7u7on.fsf@neo.luffy.cx...
> 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.

Tu ne peux pas être un peu plus précis ;-)
Contraitement, comment je fais ?

--
-Stan

"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

OoO En cette matinée ensoleillée du vendredi 30 juin 2006, vers 09:56,
"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.

> Tu ne peux pas être un peu plus précis ;-)
> Contraitement, comment je fais ?

Non, rien, je me suis emmêlé les pinceaux. Un instant, j'ai cru que
l'application tournait en local sur le RAS (genre lancée par pppd).
--
BOFH excuse #81:
Please excuse me, I have to circuit an AC line through my head to get this database working.

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

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

Dans le fichier /etc/ppp/ip-up ou dans un nouveau fichier dans le répertoire
/etc/ppp/ip-up.d, selon la distribution Linux :

if [ "$PPPLOGNAME" -eq "login c" ]
then
iptables -t nat -A PREROUTING -p udp -s $IPREMOTE \
-d 192.168.1.1 --dport 2000 -j DNAT --to 1.2.3.4:2004
fi

ou :

case "$PPPLOGNAME" in
login a)
PORT=...
;;
login b)
PORT=...
;;
[...]
*)
PORT=...
;;
esac

iptables -t nat -A PREROUTING -p udp -s $IPREMOTE \
-d 192.168.1.1 --dport 2000 -j DNAT --to 1.2.3.4:$PORT

L'idée est là.

--
Sébastien Monbrun aka TiChou

"Sébastien Monbrun aka TiChou" <gro.uohcit@uohcit> a écrit dans le message
de news: pwet.20060630163615@florizarre.tichou.org...
[...]
> L'idée est là.
>

Merci beaucoup.
Entre temps j'avais fait quelques essais
pour récupérer PPPLOGNAME dans /etc/ppp/ip-up ( ip-up.local pour être
précis )
et il ne me manquait plus que les régles adéquates.

Une dernière question ;-)
A-t-on vraiment besoin d'annuler ces règles dans le /etc/ppp/ip-down ?

A priori, je dirai non, mais si oui comment
faut-il faire ?

Avec iptables -X ?

--
-Stan

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

> A-t-on vraiment besoin d'annuler ces règles dans le /etc/ppp/ip-down ?

Oui, il vaudrait mieux. Si la règle n'est plus utile ou devient obsolète, il
faut l'effacer. Sinon, à chaque connexion du même client, une nouvelle règle
va être ajoutée et sera redondante voire rentrer en conflit si les
paramètres réseaux (IP, port) différent de la précédente connexion.

> A priori, je dirai non, mais si oui comment
> faut-il faire ?

Le même script que dans ip-up mais en remplaçant l'option -A (append) par
l'option -D (delete).

> Avec iptables -X ?

Non. iptables -X effacera la chaîne utilisateur spécifiée en argument ou
toutes les chaînes utilisateur.

--
Sébastien Monbrun aka TiChou

Sébastien Monbrun aka TiChou wrote in message
<bzium.20060630173522@florizarre.tichou.org>:
> Non. iptables -X effacera la chaîne utilisateur spécifiée en argument ou
> toutes les chaînes utilisateur.

Pour le coup, ça peut être pas mal: créer une chaîne nommée par règle ou
groupe de règles susceptible d'être supprimées, ça permet de supprimer par
nom plutôt qu'en retrouvant les mêmes paramètres exactement.

"Nicolas George" <nicolas$george@salle-s.org> a écrit dans le message de
news: e83h18$fc6$1@biggoron.nerim.net...
> Sébastien Monbrun aka TiChou wrote in message
> <bzium.20060630173522@florizarre.tichou.org>:
>> Non. iptables -X effacera la chaîne utilisateur spécifiée en argument ou
>> toutes les chaînes utilisateur.
>
> Pour le coup, ça peut être pas mal : créer une chaîne nommée par règle ou
> groupe de règles susceptible d'être supprimées, ça permet de supprimer par
> nom plutôt qu'en retrouvant les mêmes paramètres exactement.

Ok,
merci à tous, je vais m'y coller...

--
-Stan

Salut,

Nicolas George a écrit :
>
>>Non. iptables -X effacera la chaîne utilisateur spécifiée en argument ou
>>toutes les chaînes utilisateur.

Et ne marchera que si ladite chaîne est vide.

> Pour le coup, ça peut être pas mal : créer une chaîne nommée par règle ou
> groupe de règles susceptible d'être supprimées, ça permet de supprimer par
> nom plutôt qu'en retrouvant les mêmes paramètres exactement.

Ne serait-il pas plus simple de vider la chaîne avec iptables -F ?