Cette fonctionnalité parfois utile, qui consiste à natter alors que la
machine ne dispose que d'une interface existe sur certains ios (voir
l'article suivant http://blogs.techrepublic.com.com/networking/?p=486).
Énoncé :
- 3 lans internes reliés en wan à base vpn et routés de bout en bout
- 1 des lans du dit wan est relié par vpn à un lan externe qui n'est pas
routé sur le reste du réseau.
- Les configurations présentes ne sont pas modifiables...
Le but du jeu est de mettre en place sur le lan interne relié au lan
externe une machine faisant office de gateway vers ce dernier pour
les autres lans internes.
Cela ressemble typiquement à un cas d'application de la NAT, donc est-il
possible d'obtenir d'une linuxette ou d'un bsd un fonctionnement
de type nat on a stick ?
Existe-t-il une alternative que je n'aurais pas vu ?
Merci d'avance.
--
Je crois que le meilleur moyen, c'est une signature qui contient
toutes les signatures et de virer les mauvaises avant envoi.
-+- Ivan in : <http://www.le-gnu.net> : Je signe donc je suis -+-
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
Salut,
Eric Masson a écrit :
- 3 lans internes reliés en wan à base vpn et routés de bout en bout - 1 des lans du dit wan est relié par vpn à un lan externe qui n'est pas routé sur le reste du réseau. - Les configurations présentes ne sont pas modifiables...
Le but du jeu est de mettre en place sur le lan interne relié au lan externe une machine faisant office de gateway vers ce dernier pour les autres lans internes.
Cela ressemble typiquement à un cas d'application de la NAT, donc est-il possible d'obtenir d'une linuxette ou d'un bsd un fonctionnement de type nat on a stick ?
On peut faire du "NAT on a stick" avec un noyau Linux et iptables moyennant quelques précautions comme désactiver l'envoi d'ICMP redirect. Par contre j'ai du mal à entrevoir ce que ça peut apporter dans la situation ci-dessus.
Salut,
Eric Masson a écrit :
- 3 lans internes reliés en wan à base vpn et routés de bout en bout
- 1 des lans du dit wan est relié par vpn à un lan externe qui n'est pas
routé sur le reste du réseau.
- Les configurations présentes ne sont pas modifiables...
Le but du jeu est de mettre en place sur le lan interne relié au lan
externe une machine faisant office de gateway vers ce dernier pour
les autres lans internes.
Cela ressemble typiquement à un cas d'application de la NAT, donc est-il
possible d'obtenir d'une linuxette ou d'un bsd un fonctionnement
de type nat on a stick ?
On peut faire du "NAT on a stick" avec un noyau Linux et iptables
moyennant quelques précautions comme désactiver l'envoi d'ICMP redirect.
Par contre j'ai du mal à entrevoir ce que ça peut apporter dans la
situation ci-dessus.
- 3 lans internes reliés en wan à base vpn et routés de bout en bout - 1 des lans du dit wan est relié par vpn à un lan externe qui n'est pas routé sur le reste du réseau. - Les configurations présentes ne sont pas modifiables...
Le but du jeu est de mettre en place sur le lan interne relié au lan externe une machine faisant office de gateway vers ce dernier pour les autres lans internes.
Cela ressemble typiquement à un cas d'application de la NAT, donc est-il possible d'obtenir d'une linuxette ou d'un bsd un fonctionnement de type nat on a stick ?
On peut faire du "NAT on a stick" avec un noyau Linux et iptables moyennant quelques précautions comme désactiver l'envoi d'ICMP redirect. Par contre j'ai du mal à entrevoir ce que ça peut apporter dans la situation ci-dessus.
Eric Masson
Pascal Hambourg writes:
'Lut,
On peut faire du "NAT on a stick" avec un noyau Linux et iptables moyennant quelques précautions comme désactiver l'envoi d'ICMP redirect.
Ok, tu as un lien à recommander stp ? J'ai trouvé quelque chose de similaire pour OpenBSD/pf entretemps.
Par contre j'ai du mal à entrevoir ce que ça peut apporter dans la situation ci-dessus.
Permettre à une machine sur un des lan internes qui n'a pas de connectivité avec le lan externe d'en disposer au travers d'une machine du lan qui dispose de la connectivité et qui va faire office de "proxy".
Je préfèrerais de loin revoir l'infra pour me passer de hacks de ce type mais cela implique des imbroglios politiques pour obtenir un début de commencement d'intérêt pour la problématique ainsi que du temps, dont je ne dispose pas, pour obtenir des cellules infra une implémentation correcte (Welcome to the real world, Neo...)
Si tu as d'autres idées, elles sont les bienvenues.
Merci.
-- Puisque les 3/4 des messages n'arrivent pas ou alors avec trois jours de retard, votons la grève du ng pendant une semaine. Je sais que ça va être dur pour certains qui sont accros, mais il y en a marre. -+- f in GNU : Newsmaster, salaud ! Les neuneux auront ta peau ! -+-
On peut faire du "NAT on a stick" avec un noyau Linux et iptables
moyennant quelques précautions comme désactiver l'envoi d'ICMP
redirect.
Ok, tu as un lien à recommander stp ?
J'ai trouvé quelque chose de similaire pour OpenBSD/pf entretemps.
Par contre j'ai du mal à entrevoir ce que ça peut apporter dans la
situation ci-dessus.
Permettre à une machine sur un des lan internes qui n'a pas de
connectivité avec le lan externe d'en disposer au travers d'une machine
du lan qui dispose de la connectivité et qui va faire office de "proxy".
Je préfèrerais de loin revoir l'infra pour me passer de hacks de ce type
mais cela implique des imbroglios politiques pour obtenir un début de
commencement d'intérêt pour la problématique ainsi que du temps, dont je
ne dispose pas, pour obtenir des cellules infra une implémentation
correcte (Welcome to the real world, Neo...)
Si tu as d'autres idées, elles sont les bienvenues.
Merci.
--
Puisque les 3/4 des messages n'arrivent pas ou alors avec trois jours
de retard, votons la grève du ng pendant une semaine. Je sais que ça
va être dur pour certains qui sont accros, mais il y en a marre.
-+- f in GNU : Newsmaster, salaud ! Les neuneux auront ta peau ! -+-
On peut faire du "NAT on a stick" avec un noyau Linux et iptables moyennant quelques précautions comme désactiver l'envoi d'ICMP redirect.
Ok, tu as un lien à recommander stp ? J'ai trouvé quelque chose de similaire pour OpenBSD/pf entretemps.
Par contre j'ai du mal à entrevoir ce que ça peut apporter dans la situation ci-dessus.
Permettre à une machine sur un des lan internes qui n'a pas de connectivité avec le lan externe d'en disposer au travers d'une machine du lan qui dispose de la connectivité et qui va faire office de "proxy".
Je préfèrerais de loin revoir l'infra pour me passer de hacks de ce type mais cela implique des imbroglios politiques pour obtenir un début de commencement d'intérêt pour la problématique ainsi que du temps, dont je ne dispose pas, pour obtenir des cellules infra une implémentation correcte (Welcome to the real world, Neo...)
Si tu as d'autres idées, elles sont les bienvenues.
Merci.
-- Puisque les 3/4 des messages n'arrivent pas ou alors avec trois jours de retard, votons la grève du ng pendant une semaine. Je sais que ça va être dur pour certains qui sont accros, mais il y en a marre. -+- f in GNU : Newsmaster, salaud ! Les neuneux auront ta peau ! -+-
Pascal Hambourg
Eric Masson a écrit :
Pascal Hambourg writes:
On peut faire du "NAT on a stick" avec un noyau Linux et iptables moyennant quelques précautions comme désactiver l'envoi d'ICMP redirect.
Ok, tu as un lien à recommander stp ?
Pas spécialement. La connaissance de base d'iptables et de ses cibles NAT (SNAT, DNAT, MASQUERADE, NETMAP...) devrait suffire. Pour l'ICMP redirect, voir dans /proc/sys/net/ipv4/conf/<interface>/send_redirects.
Par contre j'ai du mal à entrevoir ce que ça peut apporter dans la situation ci-dessus.
Permettre à une machine sur un des lan internes qui n'a pas de connectivité avec le lan externe d'en disposer au travers d'une machine du lan qui dispose de la connectivité et qui va faire office de "proxy".
Je ne vois toujours pas, désolé. Qu'entends-tu par "pas de connectivité" ? Pas de route aller, pas de route retour ? Quel genre de NAT penses-tu faire ? NAT source, NAT destination, dans quel sens ?
On peut faire du "NAT on a stick" avec un noyau Linux et iptables
moyennant quelques précautions comme désactiver l'envoi d'ICMP
redirect.
Ok, tu as un lien à recommander stp ?
Pas spécialement. La connaissance de base d'iptables et de ses cibles
NAT (SNAT, DNAT, MASQUERADE, NETMAP...) devrait suffire. Pour l'ICMP
redirect, voir dans /proc/sys/net/ipv4/conf/<interface>/send_redirects.
Par contre j'ai du mal à entrevoir ce que ça peut apporter dans la
situation ci-dessus.
Permettre à une machine sur un des lan internes qui n'a pas de
connectivité avec le lan externe d'en disposer au travers d'une machine
du lan qui dispose de la connectivité et qui va faire office de "proxy".
Je ne vois toujours pas, désolé.
Qu'entends-tu par "pas de connectivité" ? Pas de route aller, pas de
route retour ?
Quel genre de NAT penses-tu faire ? NAT source, NAT destination, dans
quel sens ?
On peut faire du "NAT on a stick" avec un noyau Linux et iptables moyennant quelques précautions comme désactiver l'envoi d'ICMP redirect.
Ok, tu as un lien à recommander stp ?
Pas spécialement. La connaissance de base d'iptables et de ses cibles NAT (SNAT, DNAT, MASQUERADE, NETMAP...) devrait suffire. Pour l'ICMP redirect, voir dans /proc/sys/net/ipv4/conf/<interface>/send_redirects.
Par contre j'ai du mal à entrevoir ce que ça peut apporter dans la situation ci-dessus.
Permettre à une machine sur un des lan internes qui n'a pas de connectivité avec le lan externe d'en disposer au travers d'une machine du lan qui dispose de la connectivité et qui va faire office de "proxy".
Je ne vois toujours pas, désolé. Qu'entends-tu par "pas de connectivité" ? Pas de route aller, pas de route retour ? Quel genre de NAT penses-tu faire ? NAT source, NAT destination, dans quel sens ?
Eric Masson
Pascal Hambourg writes:
'Re,
Pas spécialement. La connaissance de base d'iptables et de ses cibles NAT (SNAT, DNAT, MASQUERADE, NETMAP...) devrait suffire. Pour l'ICMP redirect, voir dans /proc/sys/net/ipv4/conf/<interface>/send_redirects.
Ok.
Permettre à une machine sur un des lan internes qui n'a pas de connectivité avec le lan externe d'en disposer au travers d'une machine du lan qui dispose de la connectivité et qui va faire office de "proxy".
Je ne vois toujours pas, désolé.
Je dois m'être mal expliqué, rien de grave. Un peut d'ascii-art :
192.168.4.254, 192.168.1.254 et 172.20.100.254 sont des routeurs dont je ne peux pas altérer la configuration pour les raisons précédemment exposées.
La machine 192.168.4.100 n'a pas de route pour 172.20.100/24 La machine 172.20.100.150 n'a pas de route pour 192.168.4/24 La machine 192.168.1.45 dispose d'une route pour 172.20.100/24 La machine 172.20.100.150 dispose d'une route pour 192.168.1/24
Quel genre de NAT penses-tu faire ? NAT source, NAT destination, dans quel sens ?
Le but du jeu serait d'utiliser 192.168.1.45 comme machine de rebond pour 192.168.4.100 et donc de procéder à une nat source sur 192.168.1.45 afin que les paquets à destination de 172.20.100.150 puissent arriver à destination.
Suis-je plus clair ?
Je pense que le problème qui va se poser sera de forcer le passage des paquets issus de 192.168.4.100 par 192.168.1.45 (en l'absence de routeur sur le chemin, avec un alias sur la carte réseau de 192.168.1.45, cela passerait tout seul, mais là, je suis un peu sec...)
Je pense donc qu'il me faut un proxy et non pas une solution à base nat, tu as déjà regardé du coté d'outils comme http://www.delegate.org/ ?
Encore merci.
-- Expliquez-moi, car je ne comprends pas ce qu'il se passe. Je n'ai jamais écrit quoi que ce soit à propos d'un "fichier MIME multivolet" : d'où vient donc cette citation apocryphe ? -+-RA in : GNU - Neuneu abattu en plein multivol -+-
Pas spécialement. La connaissance de base d'iptables et de ses cibles
NAT (SNAT, DNAT, MASQUERADE, NETMAP...) devrait suffire. Pour l'ICMP
redirect, voir dans /proc/sys/net/ipv4/conf/<interface>/send_redirects.
Ok.
Permettre à une machine sur un des lan internes qui n'a pas de
connectivité avec le lan externe d'en disposer au travers d'une machine
du lan qui dispose de la connectivité et qui va faire office de "proxy".
Je ne vois toujours pas, désolé.
Je dois m'être mal expliqué, rien de grave.
Un peut d'ascii-art :
192.168.4.254, 192.168.1.254 et 172.20.100.254 sont des routeurs dont je
ne peux pas altérer la configuration pour les raisons précédemment
exposées.
La machine 192.168.4.100 n'a pas de route pour 172.20.100/24
La machine 172.20.100.150 n'a pas de route pour 192.168.4/24
La machine 192.168.1.45 dispose d'une route pour 172.20.100/24
La machine 172.20.100.150 dispose d'une route pour 192.168.1/24
Quel genre de NAT penses-tu faire ? NAT source, NAT destination, dans
quel sens ?
Le but du jeu serait d'utiliser 192.168.1.45 comme machine de rebond
pour 192.168.4.100 et donc de procéder à une nat source sur
192.168.1.45 afin que les paquets à destination de 172.20.100.150
puissent arriver à destination.
Suis-je plus clair ?
Je pense que le problème qui va se poser sera de forcer le passage des
paquets issus de 192.168.4.100 par 192.168.1.45 (en l'absence de routeur
sur le chemin, avec un alias sur la carte réseau de 192.168.1.45, cela
passerait tout seul, mais là, je suis un peu sec...)
Je pense donc qu'il me faut un proxy et non pas une solution à base nat,
tu as déjà regardé du coté d'outils comme http://www.delegate.org/ ?
Encore merci.
--
Expliquez-moi, car je ne comprends pas ce qu'il se passe. Je n'ai jamais
écrit quoi que ce soit à propos d'un "fichier MIME multivolet" : d'où
vient donc cette citation apocryphe ?
-+-RA in : GNU - Neuneu abattu en plein multivol -+-
Pas spécialement. La connaissance de base d'iptables et de ses cibles NAT (SNAT, DNAT, MASQUERADE, NETMAP...) devrait suffire. Pour l'ICMP redirect, voir dans /proc/sys/net/ipv4/conf/<interface>/send_redirects.
Ok.
Permettre à une machine sur un des lan internes qui n'a pas de connectivité avec le lan externe d'en disposer au travers d'une machine du lan qui dispose de la connectivité et qui va faire office de "proxy".
Je ne vois toujours pas, désolé.
Je dois m'être mal expliqué, rien de grave. Un peut d'ascii-art :
192.168.4.254, 192.168.1.254 et 172.20.100.254 sont des routeurs dont je ne peux pas altérer la configuration pour les raisons précédemment exposées.
La machine 192.168.4.100 n'a pas de route pour 172.20.100/24 La machine 172.20.100.150 n'a pas de route pour 192.168.4/24 La machine 192.168.1.45 dispose d'une route pour 172.20.100/24 La machine 172.20.100.150 dispose d'une route pour 192.168.1/24
Quel genre de NAT penses-tu faire ? NAT source, NAT destination, dans quel sens ?
Le but du jeu serait d'utiliser 192.168.1.45 comme machine de rebond pour 192.168.4.100 et donc de procéder à une nat source sur 192.168.1.45 afin que les paquets à destination de 172.20.100.150 puissent arriver à destination.
Suis-je plus clair ?
Je pense que le problème qui va se poser sera de forcer le passage des paquets issus de 192.168.4.100 par 192.168.1.45 (en l'absence de routeur sur le chemin, avec un alias sur la carte réseau de 192.168.1.45, cela passerait tout seul, mais là, je suis un peu sec...)
Je pense donc qu'il me faut un proxy et non pas une solution à base nat, tu as déjà regardé du coté d'outils comme http://www.delegate.org/ ?
Encore merci.
-- Expliquez-moi, car je ne comprends pas ce qu'il se passe. Je n'ai jamais écrit quoi que ce soit à propos d'un "fichier MIME multivolet" : d'où vient donc cette citation apocryphe ? -+-RA in : GNU - Neuneu abattu en plein multivol -+-
Pascal Hambourg
Eric Masson a écrit :
Le but du jeu serait d'utiliser 192.168.1.45 comme machine de rebond pour 192.168.4.100 et donc de procéder à une nat source sur 192.168.1.45 afin que les paquets à destination de 172.20.100.150 puissent arriver à destination.
Suis-je plus clair ?
Ouais, sauf ça ne marche pas. Tant que 192.168.1.45 n'a pas de route pour 172.20.100.150 et les routeurs intermédiaires ne routent pas les paquets envoyés par 192.168.1.45 à 172.20.100.150 jusqu'à 192.168.1.45, le NAT source ne sert à rien car 192.168.1.45 ne recevra jamais les paquets.
Rappels : Le NAT source sert quand la destination ne peut joindre la source, c'est-à-dire quand la source n'est pas routée depuis la destination. Le NAT destination sert quand la source ne peut joindre la destination, c'est-à-dire quand la destination n'est pas routée depuis la source.
Là, si j'ai bien compris personne ne peut joindre personne et donc il faudrait faire à la fois du NAT source et destination : par exemple 192.168.4.100 s'adresse à un port de 192.168.1.45 qui est redirigé vers 172.20.100.150. Cela s'apparente au fonctionnement d'un proxy ou d'un relais de port.
Je pense que le problème qui va se poser sera de forcer le passage des paquets issus de 192.168.4.100 par 192.168.1.45 (en l'absence de routeur sur le chemin, avec un alias sur la carte réseau de 192.168.1.45, cela passerait tout seul, mais là, je suis un peu sec...)
Voilà.
Je pense donc qu'il me faut un proxy et non pas une solution à base nat, tu as déjà regardé du coté d'outils comme http://www.delegate.org/ ?
Je ne connais pas delegate, et après lecture rapide je n'arrive pas à comprendre comment ça marche, si c'est un proxy transparent ou explicite (genre SOCKS), comment on gère l'accès à plusieurs serveurs si c'est transparent...
Eric Masson a écrit :
Le but du jeu serait d'utiliser 192.168.1.45 comme machine de rebond
pour 192.168.4.100 et donc de procéder à une nat source sur
192.168.1.45 afin que les paquets à destination de 172.20.100.150
puissent arriver à destination.
Suis-je plus clair ?
Ouais, sauf ça ne marche pas. Tant que 192.168.1.45 n'a pas de route
pour 172.20.100.150 et les routeurs intermédiaires ne routent pas les
paquets envoyés par 192.168.1.45 à 172.20.100.150 jusqu'à 192.168.1.45,
le NAT source ne sert à rien car 192.168.1.45 ne recevra jamais les paquets.
Rappels :
Le NAT source sert quand la destination ne peut joindre la source,
c'est-à-dire quand la source n'est pas routée depuis la destination.
Le NAT destination sert quand la source ne peut joindre la destination,
c'est-à-dire quand la destination n'est pas routée depuis la source.
Là, si j'ai bien compris personne ne peut joindre personne et donc il
faudrait faire à la fois du NAT source et destination : par exemple
192.168.4.100 s'adresse à un port de 192.168.1.45 qui est redirigé vers
172.20.100.150. Cela s'apparente au fonctionnement d'un proxy ou d'un
relais de port.
Je pense que le problème qui va se poser sera de forcer le passage des
paquets issus de 192.168.4.100 par 192.168.1.45 (en l'absence de routeur
sur le chemin, avec un alias sur la carte réseau de 192.168.1.45, cela
passerait tout seul, mais là, je suis un peu sec...)
Voilà.
Je pense donc qu'il me faut un proxy et non pas une solution à base nat,
tu as déjà regardé du coté d'outils comme http://www.delegate.org/ ?
Je ne connais pas delegate, et après lecture rapide je n'arrive pas à
comprendre comment ça marche, si c'est un proxy transparent ou explicite
(genre SOCKS), comment on gère l'accès à plusieurs serveurs si c'est
transparent...
Le but du jeu serait d'utiliser 192.168.1.45 comme machine de rebond pour 192.168.4.100 et donc de procéder à une nat source sur 192.168.1.45 afin que les paquets à destination de 172.20.100.150 puissent arriver à destination.
Suis-je plus clair ?
Ouais, sauf ça ne marche pas. Tant que 192.168.1.45 n'a pas de route pour 172.20.100.150 et les routeurs intermédiaires ne routent pas les paquets envoyés par 192.168.1.45 à 172.20.100.150 jusqu'à 192.168.1.45, le NAT source ne sert à rien car 192.168.1.45 ne recevra jamais les paquets.
Rappels : Le NAT source sert quand la destination ne peut joindre la source, c'est-à-dire quand la source n'est pas routée depuis la destination. Le NAT destination sert quand la source ne peut joindre la destination, c'est-à-dire quand la destination n'est pas routée depuis la source.
Là, si j'ai bien compris personne ne peut joindre personne et donc il faudrait faire à la fois du NAT source et destination : par exemple 192.168.4.100 s'adresse à un port de 192.168.1.45 qui est redirigé vers 172.20.100.150. Cela s'apparente au fonctionnement d'un proxy ou d'un relais de port.
Je pense que le problème qui va se poser sera de forcer le passage des paquets issus de 192.168.4.100 par 192.168.1.45 (en l'absence de routeur sur le chemin, avec un alias sur la carte réseau de 192.168.1.45, cela passerait tout seul, mais là, je suis un peu sec...)
Voilà.
Je pense donc qu'il me faut un proxy et non pas une solution à base nat, tu as déjà regardé du coté d'outils comme http://www.delegate.org/ ?
Je ne connais pas delegate, et après lecture rapide je n'arrive pas à comprendre comment ça marche, si c'est un proxy transparent ou explicite (genre SOCKS), comment on gère l'accès à plusieurs serveurs si c'est transparent...
Pascal Hambourg
Pascal Hambourg a écrit :
Ouais, sauf ça ne marche pas. Tant que 192.168.1.45 n'a pas de route
Correction : 192.168.4.100
Pascal Hambourg a écrit :
Ouais, sauf ça ne marche pas. Tant que 192.168.1.45 n'a pas de route
Ouais, sauf ça ne marche pas. Tant que 192.168.1.45 n'a pas de route
Correction : 192.168.4.100
Eric Masson
Pascal Hambourg writes:
'Re,
Voilà.
Merci de confirmer que la nat était une fausse bonne idée.
Je ne connais pas delegate, et après lecture rapide je n'arrive pas à comprendre comment ça marche, si c'est un proxy transparent ou explicite (genre SOCKS), comment on gère l'accès à plusieurs serveurs si c'est transparent...
Il me semble qu'avec un setup de type relais tcp comme montré dans la page suivante : http://www.delegate.org/delegate/HowToDG.html#clproxy Je devrais pouvoir arriver à mes fins.
Encore merci pour ton aide.
-- BJ> Faudrait pas me prendre pour un con. Merci JB> Relis bien cette partie du thread, on n'officialise rien d'illégal. -+- In : <http://www.le-gnu.net> - Bien officialiser sa connerie -+-
Merci de confirmer que la nat était une fausse bonne idée.
Je ne connais pas delegate, et après lecture rapide je n'arrive pas à
comprendre comment ça marche, si c'est un proxy transparent ou explicite
(genre SOCKS), comment on gère l'accès à plusieurs serveurs si c'est
transparent...
Il me semble qu'avec un setup de type relais tcp comme montré dans la
page suivante :
http://www.delegate.org/delegate/HowToDG.html#clproxy
Je devrais pouvoir arriver à mes fins.
Encore merci pour ton aide.
--
BJ> Faudrait pas me prendre pour un con. Merci
JB> Relis bien cette partie du thread, on n'officialise rien d'illégal.
-+- In : <http://www.le-gnu.net> - Bien officialiser sa connerie -+-
Merci de confirmer que la nat était une fausse bonne idée.
Je ne connais pas delegate, et après lecture rapide je n'arrive pas à comprendre comment ça marche, si c'est un proxy transparent ou explicite (genre SOCKS), comment on gère l'accès à plusieurs serveurs si c'est transparent...
Il me semble qu'avec un setup de type relais tcp comme montré dans la page suivante : http://www.delegate.org/delegate/HowToDG.html#clproxy Je devrais pouvoir arriver à mes fins.
Encore merci pour ton aide.
-- BJ> Faudrait pas me prendre pour un con. Merci JB> Relis bien cette partie du thread, on n'officialise rien d'illégal. -+- In : <http://www.le-gnu.net> - Bien officialiser sa connerie -+-
Pascal Hambourg
Eric Masson a écrit :
Merci de confirmer que la nat était une fausse bonne idée.
Heh ! je ne confirme rien du tout, je donne juste mon avis qui n'a que la valeur que tu veux bien lui accorder.
Eric Masson a écrit :
Merci de confirmer que la nat était une fausse bonne idée.
Heh ! je ne confirme rien du tout, je donne juste mon avis qui n'a que
la valeur que tu veux bien lui accorder.
Merci de confirmer que la nat était une fausse bonne idée.
Heh ! je ne confirme rien du tout, je donne juste mon avis qui n'a que la valeur que tu veux bien lui accorder.
Eric Masson
Pascal Hambourg writes:
'Lut,
Heh ! je ne confirme rien du tout, je donne juste mon avis qui n'a que la valeur que tu veux bien lui accorder.
Ben, vu que je ne t'ai jamais vu pour le moment raconter de conneries ici, ma confiance en ton avis est plutôt élevée ;)
-- Bien reçu message via groupes discussion, je te répond avec la touche " répondre au groupe " en ayant sélectionné ton message. J'espère que tu le recevra dans ta boîte de réception. Le café est en préparation. -+- in Guide du Neuneu Usenet - Open up, open up -+-
Heh ! je ne confirme rien du tout, je donne juste mon avis qui n'a que
la valeur que tu veux bien lui accorder.
Ben, vu que je ne t'ai jamais vu pour le moment raconter de conneries
ici, ma confiance en ton avis est plutôt élevée ;)
--
Bien reçu message via groupes discussion, je te répond avec la touche "
répondre au groupe " en ayant sélectionné ton message. J'espère que tu le
recevra dans ta boîte de réception. Le café est en préparation.
-+- in Guide du Neuneu Usenet - Open up, open up -+-
Heh ! je ne confirme rien du tout, je donne juste mon avis qui n'a que la valeur que tu veux bien lui accorder.
Ben, vu que je ne t'ai jamais vu pour le moment raconter de conneries ici, ma confiance en ton avis est plutôt élevée ;)
-- Bien reçu message via groupes discussion, je te répond avec la touche " répondre au groupe " en ayant sélectionné ton message. J'espère que tu le recevra dans ta boîte de réception. Le café est en préparation. -+- in Guide du Neuneu Usenet - Open up, open up -+-
