Puisque mon p'tit routeur à 50$ plantait sans arrêt, j'ai décidé de
faire de mon vieux Pentium II sous Linux, un routeur avec iptables.
En ce moment tout semble assez bien fonctionner. Il y a une chose que je
ne sais pas trop comment faire par contre. J'aimerais que le port 113
soit redirigé différemment selon l'utilisation de ports spécifiques
sortants (exemple 6667). Par exemple, si j'utilise un client IRC sur le
Pentium ii, j'aimerais que ce soit l'identd sur celui-ci qui reçoit sur
le port 113. Par contre, si mIRC sur mon autre ordinateur vient
d'envoyer une requête sur le port 6667 (bref, vient tout juste de se
connecter à un serveur IRC), j'aimerais qu'iptables redirige le port 113
temporairement vers cet ordinateur.
J'ai été assez clair?
Merci
--
EnleveR_legabier@EnleveR_gmail.com (Devinez ce qu'il faut EnleveR_..)
À mort Outlook Express, il y a maintenant Thunderbird en français !
http://www.mozilla.org/products/thunderbird/all.html
Puisque mon p'tit routeur à 50$ plantait sans arrêt, j'ai décidé de faire de mon vieux Pentium II sous Linux, un routeur avec iptables. En ce moment tout semble assez bien fonctionner. Il y a une chose que je ne sais pas trop comment faire par contre. J'aimerais que le port 113 soit redirigé différemment selon l'utilisation de ports spécifiques sortants (exemple 6667). Par exemple, si j'utilise un client IRC sur le Pentium ii, j'aimerais que ce soit l'identd sur celui-ci qui reçoit sur le port 113. Par contre, si mIRC sur mon autre ordinateur vient d'envoyer une requête sur le port 6667 (bref, vient tout juste de se connecter à un serveur IRC), j'aimerais qu'iptables redirige le port 113 temporairement vers cet ordinateur. J'ai été assez clair?
Merci
ça ne répond pas à la question mais tu peux installer une distrib Linux / BSD sur cette machine.
Ensuite ça s'administre comme un routeur par une interface web
IPCop Monowall Smoothwall E-Smith SME Server Mandrake MNF SecurePoint Clarkconnect Engarde Secure Linux
http://www.fr.ixus.net/
Puisque mon p'tit routeur à 50$ plantait sans arrêt, j'ai décidé de
faire de mon vieux Pentium II sous Linux, un routeur avec iptables.
En ce moment tout semble assez bien fonctionner. Il y a une chose que je
ne sais pas trop comment faire par contre. J'aimerais que le port 113
soit redirigé différemment selon l'utilisation de ports spécifiques
sortants (exemple 6667). Par exemple, si j'utilise un client IRC sur le
Pentium ii, j'aimerais que ce soit l'identd sur celui-ci qui reçoit sur
le port 113. Par contre, si mIRC sur mon autre ordinateur vient
d'envoyer une requête sur le port 6667 (bref, vient tout juste de se
connecter à un serveur IRC), j'aimerais qu'iptables redirige le port 113
temporairement vers cet ordinateur.
J'ai été assez clair?
Merci
ça ne répond pas à la question mais tu peux installer une distrib Linux
/ BSD sur cette machine.
Ensuite ça s'administre comme un routeur par une interface web
IPCop
Monowall
Smoothwall
E-Smith SME Server
Mandrake MNF
SecurePoint
Clarkconnect
Engarde Secure Linux
Puisque mon p'tit routeur à 50$ plantait sans arrêt, j'ai décidé de faire de mon vieux Pentium II sous Linux, un routeur avec iptables. En ce moment tout semble assez bien fonctionner. Il y a une chose que je ne sais pas trop comment faire par contre. J'aimerais que le port 113 soit redirigé différemment selon l'utilisation de ports spécifiques sortants (exemple 6667). Par exemple, si j'utilise un client IRC sur le Pentium ii, j'aimerais que ce soit l'identd sur celui-ci qui reçoit sur le port 113. Par contre, si mIRC sur mon autre ordinateur vient d'envoyer une requête sur le port 6667 (bref, vient tout juste de se connecter à un serveur IRC), j'aimerais qu'iptables redirige le port 113 temporairement vers cet ordinateur. J'ai été assez clair?
Merci
ça ne répond pas à la question mais tu peux installer une distrib Linux / BSD sur cette machine.
Ensuite ça s'administre comme un routeur par une interface web
IPCop Monowall Smoothwall E-Smith SME Server Mandrake MNF SecurePoint Clarkconnect Engarde Secure Linux
http://www.fr.ixus.net/
Pascal
Salut,
Puisque mon p'tit routeur à 50$ plantait sans arrêt, j'ai décidé de faire de mon vieux Pentium II sous Linux, un routeur avec iptables.
Bravo o/
En ce moment tout semble assez bien fonctionner. Il y a une chose que je ne sais pas trop comment faire par contre. J'aimerais que le port 113 soit redirigé différemment selon l'utilisation de ports spécifiques sortants (exemple 6667). Par exemple, si j'utilise un client IRC sur le Pentium ii, j'aimerais que ce soit l'identd sur celui-ci qui reçoit sur le port 113. Par contre, si mIRC sur mon autre ordinateur vient d'envoyer une requête sur le port 6667 (bref, vient tout juste de se connecter à un serveur IRC), j'aimerais qu'iptables redirige le port 113 temporairement vers cet ordinateur. J'ai été assez clair?
Oui, je pense. Apparemment certains démons Ident comme bidentd, midentd, oidentd savent rediriger les requêtes Ident entrantes vers les machines masqueradées. Liste probablement non limitative.
Salut,
Puisque mon p'tit routeur à 50$ plantait sans arrêt, j'ai décidé de
faire de mon vieux Pentium II sous Linux, un routeur avec iptables.
Bravo o/
En ce moment tout semble assez bien fonctionner. Il y a une chose que je
ne sais pas trop comment faire par contre. J'aimerais que le port 113
soit redirigé différemment selon l'utilisation de ports spécifiques
sortants (exemple 6667). Par exemple, si j'utilise un client IRC sur le
Pentium ii, j'aimerais que ce soit l'identd sur celui-ci qui reçoit sur
le port 113. Par contre, si mIRC sur mon autre ordinateur vient
d'envoyer une requête sur le port 6667 (bref, vient tout juste de se
connecter à un serveur IRC), j'aimerais qu'iptables redirige le port 113
temporairement vers cet ordinateur.
J'ai été assez clair?
Oui, je pense.
Apparemment certains démons Ident comme bidentd, midentd, oidentd savent
rediriger les requêtes Ident entrantes vers les machines masqueradées.
Liste probablement non limitative.
Puisque mon p'tit routeur à 50$ plantait sans arrêt, j'ai décidé de faire de mon vieux Pentium II sous Linux, un routeur avec iptables.
Bravo o/
En ce moment tout semble assez bien fonctionner. Il y a une chose que je ne sais pas trop comment faire par contre. J'aimerais que le port 113 soit redirigé différemment selon l'utilisation de ports spécifiques sortants (exemple 6667). Par exemple, si j'utilise un client IRC sur le Pentium ii, j'aimerais que ce soit l'identd sur celui-ci qui reçoit sur le port 113. Par contre, si mIRC sur mon autre ordinateur vient d'envoyer une requête sur le port 6667 (bref, vient tout juste de se connecter à un serveur IRC), j'aimerais qu'iptables redirige le port 113 temporairement vers cet ordinateur. J'ai été assez clair?
Oui, je pense. Apparemment certains démons Ident comme bidentd, midentd, oidentd savent rediriger les requêtes Ident entrantes vers les machines masqueradées. Liste probablement non limitative.
Pascal
[Ident et masquerading]
Deux petites précisions.
1) Ce n'est pas iptables qui effectue la redirection mais le démon Ident, grâce à la table de suivi d'état de connexion/NAT d'iptables. Je ne connais pas de module iptables qui permettrait de le faire, à l'instar des connexions FTP-data.
2) Préfère un sujet plus explicite et original que "iptables". Explicite, pour attirer les lecteurs. Original, pour éviter que dans certains logiciels lecteurs de news ton article vienne se coller à un ancien fil ayant le même sujet et passe inaperçu. Dans mon lecteur, il apparaît collé à un fil qui date de février (oui, le serveur que j'utilise a des ratés mais une grande durée de rétention).
[Ident et masquerading]
Deux petites précisions.
1) Ce n'est pas iptables qui effectue la redirection mais le démon
Ident, grâce à la table de suivi d'état de connexion/NAT d'iptables. Je
ne connais pas de module iptables qui permettrait de le faire, à
l'instar des connexions FTP-data.
2) Préfère un sujet plus explicite et original que "iptables".
Explicite, pour attirer les lecteurs. Original, pour éviter que dans
certains logiciels lecteurs de news ton article vienne se coller à un
ancien fil ayant le même sujet et passe inaperçu. Dans mon lecteur, il
apparaît collé à un fil qui date de février (oui, le serveur que
j'utilise a des ratés mais une grande durée de rétention).
1) Ce n'est pas iptables qui effectue la redirection mais le démon Ident, grâce à la table de suivi d'état de connexion/NAT d'iptables. Je ne connais pas de module iptables qui permettrait de le faire, à l'instar des connexions FTP-data.
2) Préfère un sujet plus explicite et original que "iptables". Explicite, pour attirer les lecteurs. Original, pour éviter que dans certains logiciels lecteurs de news ton article vienne se coller à un ancien fil ayant le même sujet et passe inaperçu. Dans mon lecteur, il apparaît collé à un fil qui date de février (oui, le serveur que j'utilise a des ratés mais une grande durée de rétention).
R12y
On Tue, 20 Sep 2005 09:02:22 +0200, wrote:
1) Ce n'est pas iptables qui effectue la redirection mais le démon Ident, grâce à la table de suivi d'état de connexion/NAT d'iptables. Je ne connais pas de module iptables qui permettrait de le faire, à l'instar des connexions FTP-data.
-- SPIP, phpNuke, Plone, opengroupware... c'est bien CPS c'est mieux: http://www.cps-project.org/ Hébergement de sites CPS: http://www.objectis.org/
On Tue, 20 Sep 2005 09:02:22 +0200, Pascal@plouf wrote:
1) Ce n'est pas iptables qui effectue la redirection mais le démon
Ident, grâce à la table de suivi d'état de connexion/NAT d'iptables. Je
ne connais pas de module iptables qui permettrait de le faire, à
l'instar des connexions FTP-data.
1) Ce n'est pas iptables qui effectue la redirection mais le démon Ident, grâce à la table de suivi d'état de connexion/NAT d'iptables. Je ne connais pas de module iptables qui permettrait de le faire, à l'instar des connexions FTP-data.
-- SPIP, phpNuke, Plone, opengroupware... c'est bien CPS c'est mieux: http://www.cps-project.org/ Hébergement de sites CPS: http://www.objectis.org/
TiChou
Dans le message <news:E6KXe.24668$, *legabier* tapota sur f.c.o.l.configuration :
si j'utilise un client IRC sur le Pentium ii, j'aimerais que ce soit l'identd sur celui-ci qui reçoit sur le port 113. Par contre, si mIRC sur mon autre ordinateur vient d'envoyer une requête sur le port 6667 (bref, vient tout juste de se connecter à un serveur IRC), j'aimerais qu'iptables redirige le port 113 temporairement vers cet ordinateur.
oidentd
-- TiChou
Dans le message <news:E6KXe.24668$Wo4.301261@weber.videotron.net>,
*legabier* tapota sur f.c.o.l.configuration :
si j'utilise un client IRC sur le Pentium ii, j'aimerais que ce soit
l'identd sur celui-ci qui reçoit sur le port 113. Par contre, si mIRC sur
mon autre ordinateur vient d'envoyer une requête sur le port 6667 (bref,
vient tout juste de se connecter à un serveur IRC), j'aimerais qu'iptables
redirige le port 113 temporairement vers cet ordinateur.
Dans le message <news:E6KXe.24668$, *legabier* tapota sur f.c.o.l.configuration :
si j'utilise un client IRC sur le Pentium ii, j'aimerais que ce soit l'identd sur celui-ci qui reçoit sur le port 113. Par contre, si mIRC sur mon autre ordinateur vient d'envoyer une requête sur le port 6667 (bref, vient tout juste de se connecter à un serveur IRC), j'aimerais qu'iptables redirige le port 113 temporairement vers cet ordinateur.
oidentd
-- TiChou
Pascal
On Tue, 20 Sep 2005 09:02:22 +0200, wrote:
1) Ce n'est pas iptables qui effectue la redirection mais le démon Ident, grâce à la table de suivi d'état de connexion/NAT d'iptables. Je ne connais pas de module iptables qui permettrait de le faire, à l'instar des connexions FTP-data.
J'y ai pensé, mais la documentation du noyau indique que ces modules servent au DCC (le protocole de communication pair-à-pair d'IRC). Je n'ai rien trouvé qui indique qu'il prenne en charge le protocole Ident.
Il me semble que ce serait d'ailleurs assez difficile à réaliser par iptables, car il faudrait attendre que la connexion Ident soit établie et la requête d'identification transmise avant de pouvoir déterminer vers quelle machine elle doit être redirigée. C'est carrément du proxy transparent, et ce n'est pas vraiment le rôle d'iptables.
On Tue, 20 Sep 2005 09:02:22 +0200, Pascal@plouf wrote:
1) Ce n'est pas iptables qui effectue la redirection mais le démon
Ident, grâce à la table de suivi d'état de connexion/NAT d'iptables. Je
ne connais pas de module iptables qui permettrait de le faire, à
l'instar des connexions FTP-data.
J'y ai pensé, mais la documentation du noyau indique que ces modules
servent au DCC (le protocole de communication pair-à-pair d'IRC). Je
n'ai rien trouvé qui indique qu'il prenne en charge le protocole Ident.
Il me semble que ce serait d'ailleurs assez difficile à réaliser par
iptables, car il faudrait attendre que la connexion Ident soit établie
et la requête d'identification transmise avant de pouvoir déterminer
vers quelle machine elle doit être redirigée. C'est carrément du proxy
transparent, et ce n'est pas vraiment le rôle d'iptables.
1) Ce n'est pas iptables qui effectue la redirection mais le démon Ident, grâce à la table de suivi d'état de connexion/NAT d'iptables. Je ne connais pas de module iptables qui permettrait de le faire, à l'instar des connexions FTP-data.
J'y ai pensé, mais la documentation du noyau indique que ces modules servent au DCC (le protocole de communication pair-à-pair d'IRC). Je n'ai rien trouvé qui indique qu'il prenne en charge le protocole Ident.
Il me semble que ce serait d'ailleurs assez difficile à réaliser par iptables, car il faudrait attendre que la connexion Ident soit établie et la requête d'identification transmise avant de pouvoir déterminer vers quelle machine elle doit être redirigée. C'est carrément du proxy transparent, et ce n'est pas vraiment le rôle d'iptables.
Nicolas George
"" wrote in message <432fb06c$0$8411$:
Apparemment certains démons Ident comme bidentd, midentd, oidentd savent rediriger les requêtes Ident entrantes vers les machines masqueradées. Liste probablement non limitative.
Attention : une connexion TCP est identifiée par le quadriplet (IP source, port source, IP cible, port cible). Le protocole d'identification fait passer explicitement l'information (port source, port cible) de la connexion à identifier, mais l'information (IP source, IP cible) est transmise par la bande, sous la forme des paramètres de la connexion d'identification elle-même. Ceci a pour conséquence qu'il est impossible de faire suivre une requête d'identification purement en userland.
Je n'ai pas regardé toutes les implémentations, mais la solution typique à ce problème est en général d'ajouter une extension au protocole pour ajouter explicitement la mention des adresses IP. Ça suppose en particulier que le serveur ident sur le routeur et celui sur les machines clientes sachent se parler suivant le protocole étendu.
"Pascal@plouf" wrote in message
<432fb06c$0$8411$626a14ce@news.free.fr>:
Apparemment certains démons Ident comme bidentd, midentd, oidentd savent
rediriger les requêtes Ident entrantes vers les machines masqueradées.
Liste probablement non limitative.
Attention : une connexion TCP est identifiée par le quadriplet (IP source,
port source, IP cible, port cible). Le protocole d'identification fait
passer explicitement l'information (port source, port cible) de la connexion
à identifier, mais l'information (IP source, IP cible) est transmise par la
bande, sous la forme des paramètres de la connexion d'identification
elle-même. Ceci a pour conséquence qu'il est impossible de faire suivre une
requête d'identification purement en userland.
Je n'ai pas regardé toutes les implémentations, mais la solution typique à
ce problème est en général d'ajouter une extension au protocole pour ajouter
explicitement la mention des adresses IP. Ça suppose en particulier que le
serveur ident sur le routeur et celui sur les machines clientes sachent se
parler suivant le protocole étendu.
Apparemment certains démons Ident comme bidentd, midentd, oidentd savent rediriger les requêtes Ident entrantes vers les machines masqueradées. Liste probablement non limitative.
Attention : une connexion TCP est identifiée par le quadriplet (IP source, port source, IP cible, port cible). Le protocole d'identification fait passer explicitement l'information (port source, port cible) de la connexion à identifier, mais l'information (IP source, IP cible) est transmise par la bande, sous la forme des paramètres de la connexion d'identification elle-même. Ceci a pour conséquence qu'il est impossible de faire suivre une requête d'identification purement en userland.
Je n'ai pas regardé toutes les implémentations, mais la solution typique à ce problème est en général d'ajouter une extension au protocole pour ajouter explicitement la mention des adresses IP. Ça suppose en particulier que le serveur ident sur le routeur et celui sur les machines clientes sachent se parler suivant le protocole étendu.
Pascal
Il me semble que ce serait d'ailleurs assez difficile à réaliser par iptables, car il faudrait attendre que la connexion Ident soit établie et la requête d'identification transmise avant de pouvoir déterminer vers quelle machine elle doit être redirigée. C'est carrément du proxy transparent, et ce n'est pas vraiment le rôle d'iptables.
A la réflexion, plutôt du reverse proxy, non ?
Il me semble que ce serait d'ailleurs assez difficile à réaliser par
iptables, car il faudrait attendre que la connexion Ident soit établie
et la requête d'identification transmise avant de pouvoir déterminer
vers quelle machine elle doit être redirigée. C'est carrément du proxy
transparent, et ce n'est pas vraiment le rôle d'iptables.
Il me semble que ce serait d'ailleurs assez difficile à réaliser par iptables, car il faudrait attendre que la connexion Ident soit établie et la requête d'identification transmise avant de pouvoir déterminer vers quelle machine elle doit être redirigée. C'est carrément du proxy transparent, et ce n'est pas vraiment le rôle d'iptables.
A la réflexion, plutôt du reverse proxy, non ?
Pascal
Attention : une connexion TCP est identifiée par le quadriplet (IP source, port source, IP cible, port cible). Le protocole d'identification fait passer explicitement l'information (port source, port cible) de la connexion à identifier, mais l'information (IP source, IP cible) est transmise par la bande, sous la forme des paramètres de la connexion d'identification elle-même. Ceci a pour conséquence qu'il est impossible de faire suivre une requête d'identification purement en userland.
Excuse-moi mais je ne vois pas bien où est le problème. Le démon Ident qui écoute sur le port 113 de la passerelle et reçoit la connexion TCP contenant la demande d'identification de la part de la machine distante a bien en sa possession le quadruplet adresses+ports, non ?
Attention : une connexion TCP est identifiée par le quadriplet (IP source,
port source, IP cible, port cible). Le protocole d'identification fait
passer explicitement l'information (port source, port cible) de la connexion
à identifier, mais l'information (IP source, IP cible) est transmise par la
bande, sous la forme des paramètres de la connexion d'identification
elle-même. Ceci a pour conséquence qu'il est impossible de faire suivre une
requête d'identification purement en userland.
Excuse-moi mais je ne vois pas bien où est le problème.
Le démon Ident qui écoute sur le port 113 de la passerelle et reçoit la
connexion TCP contenant la demande d'identification de la part de la
machine distante a bien en sa possession le quadruplet adresses+ports, non ?
Attention : une connexion TCP est identifiée par le quadriplet (IP source, port source, IP cible, port cible). Le protocole d'identification fait passer explicitement l'information (port source, port cible) de la connexion à identifier, mais l'information (IP source, IP cible) est transmise par la bande, sous la forme des paramètres de la connexion d'identification elle-même. Ceci a pour conséquence qu'il est impossible de faire suivre une requête d'identification purement en userland.
Excuse-moi mais je ne vois pas bien où est le problème. Le démon Ident qui écoute sur le port 113 de la passerelle et reçoit la connexion TCP contenant la demande d'identification de la part de la machine distante a bien en sa possession le quadruplet adresses+ports, non ?
Nicolas George
"" wrote in message <432ff9ca$0$14855$:
Le démon Ident qui écoute sur le port 113 de la passerelle et reçoit la connexion TCP contenant la demande d'identification de la part de la machine distante a bien en sa possession le quadruplet adresses+ports, non ?
Oui, mais dans le protocole ident, il n'a aucun moyen de le faire parvenir au serveur ident de la machine finale.
"Pascal@plouf" wrote in message
<432ff9ca$0$14855$626a14ce@news.free.fr>:
Le démon Ident qui écoute sur le port 113 de la passerelle et reçoit la
connexion TCP contenant la demande d'identification de la part de la
machine distante a bien en sa possession le quadruplet adresses+ports, non ?
Oui, mais dans le protocole ident, il n'a aucun moyen de le faire parvenir
au serveur ident de la machine finale.
Le démon Ident qui écoute sur le port 113 de la passerelle et reçoit la connexion TCP contenant la demande d'identification de la part de la machine distante a bien en sa possession le quadruplet adresses+ports, non ?
Oui, mais dans le protocole ident, il n'a aucun moyen de le faire parvenir au serveur ident de la machine finale.
