Comment rediriger du traffic interne en repassant par internet ?
25 réponses
Chris
Bonjour,
j'ai un petit problème
Le contexte:
J'héberge chez moi quelques sites internet. Pour cela j'ai une machine
Xen sur laquelle j'héberge plusieurs machines virtuelles, dont le
serveur web (sous Etch) et un firewall, une appliance Endian Firewall
Community 2.2 RC3.
J'ai donc mes 4 réseaux, RED, GREEN, ORANGE et BLUE.
Sur le ORANGE, 172.16.1.0/24, j'ai mon serveur web en 172.16.1.10.
Sur le RED, 192.168.0.1/24, j'ai juste le modem ADSL (192.168.0.1), qui
forwarde tout le traffic venant d'internet sur le firewall au
192.168.0.253. Le firewall, lui, NATe le port 80 du réseau ROUGE vers
172.16.1.10:80.
Concernant GREEN, j'ai mes postes et serveurs windows.
Depuis internet, tout va bien, les requêtes vers http://mondomaine.com
sont bien résolues vers l'ip publique du modem, qui NAT tout vers le
192.168.0.253, qui lui NAT vers le 172.16.1.10:80.
Par contre depuis mon poste, ma requête vers http://mondomaine.com est
bien résolue vers l'ip publique ADSL, mais part dans le vide.
Que puis-je faire pour que le traffic se fasse depuis le réseau GREEN,
et pourquoi ça ne passe pas ?
Si possible j'aimerais éviter de passer par une zone DNS spécifique
pour le LAN, parce que je n'ai pas envie de le modifier à chaque fois
que la zone internet est modifiée, et aussi surtout parce que je veux
comprendre ce qui se passe au niveau IP :)
Le multipost, c'est pas bien. Le Xpost + Fu2, c'est beaucoup mieux ;-)
Ah ben moi qui voulait éviter un crosspost pour éviter un impair, me vla bien. :)
En multi, chacun répond de son coté sans voir les fils dans les autres branches. Il est mieux que tout le monde en profite. Ne pas oublier de signaler le FU2 dans le post car certains clients ne l'affichent pas et on s'en rend compte trop tard.
Chris a écrit :
GuiGui has brought this to us :
Le multipost, c'est pas bien. Le Xpost + Fu2, c'est beaucoup mieux ;-)
Ah ben moi qui voulait éviter un crosspost pour éviter un impair, me vla
bien. :)
En multi, chacun répond de son coté sans voir les fils dans les autres
branches. Il est mieux que tout le monde en profite. Ne pas oublier de
signaler le FU2 dans le post car certains clients ne l'affichent pas et
on s'en rend compte trop tard.
Le multipost, c'est pas bien. Le Xpost + Fu2, c'est beaucoup mieux ;-)
Ah ben moi qui voulait éviter un crosspost pour éviter un impair, me vla bien. :)
En multi, chacun répond de son coté sans voir les fils dans les autres branches. Il est mieux que tout le monde en profite. Ne pas oublier de signaler le FU2 dans le post car certains clients ne l'affichent pas et on s'en rend compte trop tard.
Pascal Hambourg
Salut,
GuiGui a écrit :
Avantage : on peut telnetter le modem même si il est en bridge (oui, je sais, c'est con...).
Qu'est-ce que ça a de con, et quel rapport avec le fait qu'il soit en bridge ? Il faut bien une adresse IP pour le configurer, non ? Idem pour un switch manageable, qui n'est rien d'autre qu'un pont multiport.
Salut,
GuiGui a écrit :
Avantage : on peut telnetter le modem même si il est en bridge
(oui, je sais, c'est con...).
Qu'est-ce que ça a de con, et quel rapport avec le fait qu'il soit en
bridge ? Il faut bien une adresse IP pour le configurer, non ? Idem pour
un switch manageable, qui n'est rien d'autre qu'un pont multiport.
Avantage : on peut telnetter le modem même si il est en bridge (oui, je sais, c'est con...).
Qu'est-ce que ça a de con, et quel rapport avec le fait qu'il soit en bridge ? Il faut bien une adresse IP pour le configurer, non ? Idem pour un switch manageable, qui n'est rien d'autre qu'un pont multiport.
Pascal Hambourg
Chris a écrit :
Ben oui, le paquet sort du LAN, est routé sur le réseau ROUGE, (ça je le vois tracé dans les connections sous Endian) est probablement naté vers internet par le modem
Il n'y a aucune raison que le paquet soit envoyé vers l'internet public, l'adresse de destination étant le modem-routeur lui-même.
Ce qui paraitrait logique, serait qu'il soit naté vers l'ip publique par le modem,
Pourquoi ? Il est déjà destiné à l'adresse IP publique.
et renaté vers l'ip RED du firewall, comme les autres paquets venant d'internet, mais je ne vois aucune trace de ça sur le firewall,
Le modem-routeur ne redirige probablement que le trafic entrant par l'interface externe, c'est classique.
donc le soucis semble être au niveau du modem.
Non, le problème est dans le routeur-firewall. C'est à son niveau que doit se faire la redirection.
Peut-être la solution serait à ce niveau là, en le mettant en PPPoE par exemple, mais je vois pas trop encore ce que ça impacterait :/
Supprimer un étage de NAT est toujours une bonne idée, mais en revanche PPPoE => problèmes de MTU. En outre, je ne suis pas certain que ça résoudrait le problème.
Sur fr.comp.reseaux.ip (oui je multiposte, c'est pas bien)
Je confirme, c'est pas bien.
on me conseille de nater directement de GREEN vers le serveur web pour les paquets à destinations mais je vois pas comment faire sous endian. Dommage, c'était élégant ça.
C'est la bonne méthode. Si l'interface de configuration normale ne le permet pas, il faudra le faire directement avec des règles iptables. Il y a quand même un shell permettant de manipuler les règles iptables et de créer des scripts ?
Déja je voudrais comprendre ce qu'il se passe exactement au niveau de ce modem pour que les paquets soient perdus ! Après je verrais :)
Au niveau du modem-routeur, rien de particulier. Cas général : on envoie un paquet à l'adresse X, l'équipement qui possède cette adresse le reçoit et le garde pour lui. Fin de l'histoire.
Je répète : c'est au niveau du routeur-firewall que ça doit se passer.
Chris a écrit :
Ben oui, le paquet sort du LAN, est routé sur le réseau ROUGE, (ça je le
vois tracé dans les connections sous Endian) est probablement naté vers
internet par le modem
Il n'y a aucune raison que le paquet soit envoyé vers l'internet public,
l'adresse de destination étant le modem-routeur lui-même.
Ce qui paraitrait logique, serait qu'il soit naté vers l'ip publique par
le modem,
Pourquoi ? Il est déjà destiné à l'adresse IP publique.
et renaté vers l'ip RED du firewall, comme les autres paquets
venant d'internet, mais je ne vois aucune trace de ça sur le firewall,
Le modem-routeur ne redirige probablement que le trafic entrant par
l'interface externe, c'est classique.
donc le soucis semble être au niveau du modem.
Non, le problème est dans le routeur-firewall. C'est à son niveau que
doit se faire la redirection.
Peut-être la solution
serait à ce niveau là, en le mettant en PPPoE par exemple, mais je vois
pas trop encore ce que ça impacterait :/
Supprimer un étage de NAT est toujours une bonne idée, mais en revanche
PPPoE => problèmes de MTU. En outre, je ne suis pas certain que ça
résoudrait le problème.
Sur fr.comp.reseaux.ip (oui je multiposte, c'est pas bien)
Je confirme, c'est pas bien.
on me
conseille de nater directement de GREEN vers le serveur web pour les
paquets à destinations mais je vois pas comment faire sous endian.
Dommage, c'était élégant ça.
C'est la bonne méthode. Si l'interface de configuration normale ne le
permet pas, il faudra le faire directement avec des règles iptables. Il
y a quand même un shell permettant de manipuler les règles iptables et
de créer des scripts ?
Déja je voudrais comprendre ce qu'il se passe exactement au niveau de ce
modem pour que les paquets soient perdus ! Après je verrais :)
Au niveau du modem-routeur, rien de particulier. Cas général : on envoie
un paquet à l'adresse X, l'équipement qui possède cette adresse le
reçoit et le garde pour lui. Fin de l'histoire.
Je répète : c'est au niveau du routeur-firewall que ça doit se passer.
Ben oui, le paquet sort du LAN, est routé sur le réseau ROUGE, (ça je le vois tracé dans les connections sous Endian) est probablement naté vers internet par le modem
Il n'y a aucune raison que le paquet soit envoyé vers l'internet public, l'adresse de destination étant le modem-routeur lui-même.
Ce qui paraitrait logique, serait qu'il soit naté vers l'ip publique par le modem,
Pourquoi ? Il est déjà destiné à l'adresse IP publique.
et renaté vers l'ip RED du firewall, comme les autres paquets venant d'internet, mais je ne vois aucune trace de ça sur le firewall,
Le modem-routeur ne redirige probablement que le trafic entrant par l'interface externe, c'est classique.
donc le soucis semble être au niveau du modem.
Non, le problème est dans le routeur-firewall. C'est à son niveau que doit se faire la redirection.
Peut-être la solution serait à ce niveau là, en le mettant en PPPoE par exemple, mais je vois pas trop encore ce que ça impacterait :/
Supprimer un étage de NAT est toujours une bonne idée, mais en revanche PPPoE => problèmes de MTU. En outre, je ne suis pas certain que ça résoudrait le problème.
Sur fr.comp.reseaux.ip (oui je multiposte, c'est pas bien)
Je confirme, c'est pas bien.
on me conseille de nater directement de GREEN vers le serveur web pour les paquets à destinations mais je vois pas comment faire sous endian. Dommage, c'était élégant ça.
C'est la bonne méthode. Si l'interface de configuration normale ne le permet pas, il faudra le faire directement avec des règles iptables. Il y a quand même un shell permettant de manipuler les règles iptables et de créer des scripts ?
Déja je voudrais comprendre ce qu'il se passe exactement au niveau de ce modem pour que les paquets soient perdus ! Après je verrais :)
Au niveau du modem-routeur, rien de particulier. Cas général : on envoie un paquet à l'adresse X, l'équipement qui possède cette adresse le reçoit et le garde pour lui. Fin de l'histoire.
Je répète : c'est au niveau du routeur-firewall que ça doit se passer.
Jonathan ROTH
Pascal Hambourg a écrit :
Salut,
GuiGui a écrit :
Avantage : on peut telnetter le modem même si il est en bridge (oui, je sais, c'est con...).
Qu'est-ce que ça a de con, et quel rapport avec le fait qu'il soit en bridge ? Il faut bien une adresse IP pour le configurer, non ? Idem pour un switch manageable, qui n'est rien d'autre qu'un pont multiport.
Je crois qu'il parlait du mode concetrateur DSL, lequel n'a pas besoin d'être configuré, tout se passe sur la machine gérant la connection en PPPoE ou PPPoA.
Pascal Hambourg a écrit :
Salut,
GuiGui a écrit :
Avantage : on peut telnetter le modem même si il est en bridge (oui,
je sais, c'est con...).
Qu'est-ce que ça a de con, et quel rapport avec le fait qu'il soit en
bridge ? Il faut bien une adresse IP pour le configurer, non ? Idem pour
un switch manageable, qui n'est rien d'autre qu'un pont multiport.
Je crois qu'il parlait du mode concetrateur DSL, lequel n'a pas besoin
d'être configuré, tout se passe sur la machine gérant la connection en
PPPoE ou PPPoA.
Avantage : on peut telnetter le modem même si il est en bridge (oui, je sais, c'est con...).
Qu'est-ce que ça a de con, et quel rapport avec le fait qu'il soit en bridge ? Il faut bien une adresse IP pour le configurer, non ? Idem pour un switch manageable, qui n'est rien d'autre qu'un pont multiport.
Je crois qu'il parlait du mode concetrateur DSL, lequel n'a pas besoin d'être configuré, tout se passe sur la machine gérant la connection en PPPoE ou PPPoA.
GuiGui
Pascal Hambourg a écrit :
Salut,
GuiGui a écrit :
Avantage : on peut telnetter le modem même si il est en bridge (oui, je sais, c'est con...).
Qu'est-ce que ça a de con, et quel rapport avec le fait qu'il soit en bridge ? Il faut bien une adresse IP pour le configurer, non ? Idem pour un switch manageable, qui n'est rien d'autre qu'un pont multiport.
Oui, c'est pas le sens de ma réponse :-) "c'est con", comprendre : "Faut pas chercher midi à 14h, c'est juste pour que le soft de configuration (celui sur le CD livré avec) puisse le telnetter".
Pascal Hambourg a écrit :
Salut,
GuiGui a écrit :
Avantage : on peut telnetter le modem même si il est en bridge (oui,
je sais, c'est con...).
Qu'est-ce que ça a de con, et quel rapport avec le fait qu'il soit en
bridge ? Il faut bien une adresse IP pour le configurer, non ? Idem pour
un switch manageable, qui n'est rien d'autre qu'un pont multiport.
Oui, c'est pas le sens de ma réponse :-)
"c'est con", comprendre : "Faut pas chercher midi à 14h, c'est juste
pour que le soft de configuration (celui sur le CD livré avec) puisse le
telnetter".
Avantage : on peut telnetter le modem même si il est en bridge (oui, je sais, c'est con...).
Qu'est-ce que ça a de con, et quel rapport avec le fait qu'il soit en bridge ? Il faut bien une adresse IP pour le configurer, non ? Idem pour un switch manageable, qui n'est rien d'autre qu'un pont multiport.
Oui, c'est pas le sens de ma réponse :-) "c'est con", comprendre : "Faut pas chercher midi à 14h, c'est juste pour que le soft de configuration (celui sur le CD livré avec) puisse le telnetter".
Pascal Hambourg
Jonathan ROTH a écrit :
Pascal Hambourg a écrit :
GuiGui a écrit :
Avantage : on peut telnetter le modem même si il est en bridge (oui, je sais, c'est con...).
Qu'est-ce que ça a de con, et quel rapport avec le fait qu'il soit en bridge ? Il faut bien une adresse IP pour le configurer, non ? Idem pour un switch manageable, qui n'est rien d'autre qu'un pont multiport.
Je crois qu'il parlait du mode concetrateur DSL,
Quel mode "concentrateur DSL" ?
lequel n'a pas besoin d'être configuré, tout se passe sur la machine gérant la connection en PPPoE ou PPPoA.
Ben voyons. Ne serait-ce que pour faire fonctionner le modem dans tel ou tel mode, il faut bien le configurer.
Jonathan ROTH a écrit :
Pascal Hambourg a écrit :
GuiGui a écrit :
Avantage : on peut telnetter le modem même si il est en bridge (oui,
je sais, c'est con...).
Qu'est-ce que ça a de con, et quel rapport avec le fait qu'il soit en
bridge ? Il faut bien une adresse IP pour le configurer, non ? Idem
pour un switch manageable, qui n'est rien d'autre qu'un pont multiport.
Je crois qu'il parlait du mode concetrateur DSL,
Quel mode "concentrateur DSL" ?
lequel n'a pas besoin
d'être configuré, tout se passe sur la machine gérant la connection en
PPPoE ou PPPoA.
Ben voyons. Ne serait-ce que pour faire fonctionner le modem dans tel ou
tel mode, il faut bien le configurer.
Avantage : on peut telnetter le modem même si il est en bridge (oui, je sais, c'est con...).
Qu'est-ce que ça a de con, et quel rapport avec le fait qu'il soit en bridge ? Il faut bien une adresse IP pour le configurer, non ? Idem pour un switch manageable, qui n'est rien d'autre qu'un pont multiport.
Je crois qu'il parlait du mode concetrateur DSL,
Quel mode "concentrateur DSL" ?
lequel n'a pas besoin d'être configuré, tout se passe sur la machine gérant la connection en PPPoE ou PPPoA.
Ben voyons. Ne serait-ce que pour faire fonctionner le modem dans tel ou tel mode, il faut bien le configurer.
Pascal Hambourg
GuiGui a écrit :
Pascal Hambourg a écrit :
GuiGui a écrit :
Avantage : on peut telnetter le modem même si il est en bridge (oui, je sais, c'est con...).
Qu'est-ce que ça a de con, et quel rapport avec le fait qu'il soit en bridge ? Il faut bien une adresse IP pour le configurer, non ? Idem pour un switch manageable, qui n'est rien d'autre qu'un pont multiport.
Oui, c'est pas le sens de ma réponse :-) "c'est con", comprendre : "Faut pas chercher midi à 14h, c'est juste pour que le soft de configuration (celui sur le CD livré avec) puisse le telnetter".
Mais pourquoi avoir écrit "même s'il est en bridge" ?
GuiGui a écrit :
Pascal Hambourg a écrit :
GuiGui a écrit :
Avantage : on peut telnetter le modem même si il est en bridge (oui,
je sais, c'est con...).
Qu'est-ce que ça a de con, et quel rapport avec le fait qu'il soit en
bridge ? Il faut bien une adresse IP pour le configurer, non ? Idem
pour un switch manageable, qui n'est rien d'autre qu'un pont multiport.
Oui, c'est pas le sens de ma réponse :-)
"c'est con", comprendre : "Faut pas chercher midi à 14h, c'est juste
pour que le soft de configuration (celui sur le CD livré avec) puisse le
telnetter".
Mais pourquoi avoir écrit "même s'il est en bridge" ?
Avantage : on peut telnetter le modem même si il est en bridge (oui, je sais, c'est con...).
Qu'est-ce que ça a de con, et quel rapport avec le fait qu'il soit en bridge ? Il faut bien une adresse IP pour le configurer, non ? Idem pour un switch manageable, qui n'est rien d'autre qu'un pont multiport.
Oui, c'est pas le sens de ma réponse :-) "c'est con", comprendre : "Faut pas chercher midi à 14h, c'est juste pour que le soft de configuration (celui sur le CD livré avec) puisse le telnetter".
Mais pourquoi avoir écrit "même s'il est en bridge" ?
Jonathan ROTH
Pascal Hambourg a écrit :
Qu'est-ce que ça a de con, et quel rapport avec le fait qu'il soit en bridge ? Il faut bien une adresse IP pour le configurer, non ? Idem pour un switch manageable, qui n'est rien d'autre qu'un pont multiport.
Je crois qu'il parlait du mode concetrateur DSL,
Quel mode "concentrateur DSL" ?
Ce qui était utilisé avec les premiers modems DSL, c'est l'OS qui gère la connexion, envoie le mot de passe etc...
lequel n'a pas besoin d'être configuré, tout se passe sur la machine gérant la connection en PPPoE ou PPPoA.
Ben voyons. Ne serait-ce que pour faire fonctionner le modem dans tel ou tel mode, il faut bien le configurer.
Certes...
Pascal Hambourg a écrit :
Qu'est-ce que ça a de con, et quel rapport avec le fait qu'il soit en
bridge ? Il faut bien une adresse IP pour le configurer, non ? Idem
pour un switch manageable, qui n'est rien d'autre qu'un pont multiport.
Je crois qu'il parlait du mode concetrateur DSL,
Quel mode "concentrateur DSL" ?
Ce qui était utilisé avec les premiers modems DSL, c'est l'OS qui gère
la connexion, envoie le mot de passe etc...
lequel n'a pas besoin d'être configuré, tout se passe sur la machine
gérant la connection en PPPoE ou PPPoA.
Ben voyons. Ne serait-ce que pour faire fonctionner le modem dans tel ou
tel mode, il faut bien le configurer.
Qu'est-ce que ça a de con, et quel rapport avec le fait qu'il soit en bridge ? Il faut bien une adresse IP pour le configurer, non ? Idem pour un switch manageable, qui n'est rien d'autre qu'un pont multiport.
Je crois qu'il parlait du mode concetrateur DSL,
Quel mode "concentrateur DSL" ?
Ce qui était utilisé avec les premiers modems DSL, c'est l'OS qui gère la connexion, envoie le mot de passe etc...
lequel n'a pas besoin d'être configuré, tout se passe sur la machine gérant la connection en PPPoE ou PPPoA.
Ben voyons. Ne serait-ce que pour faire fonctionner le modem dans tel ou tel mode, il faut bien le configurer.
Certes...
GuiGui
Pascal Hambourg a écrit :
Mais pourquoi avoir écrit "même s'il est en bridge" ?
Parce que en mode bridge, certains modems DSL ne portent plus d'IP et ne sont donc accessibles que par la console.
Pascal Hambourg a écrit :
Mais pourquoi avoir écrit "même s'il est en bridge" ?
Parce que en mode bridge, certains modems DSL ne portent plus d'IP et ne
sont donc accessibles que par la console.
Mais pourquoi avoir écrit "même s'il est en bridge" ?
Parce que en mode bridge, certains modems DSL ne portent plus d'IP et ne sont donc accessibles que par la console.
Pascal Hambourg
Jonathan ROTH a écrit :
Je crois qu'il parlait du mode concetrateur DSL,
Quel mode "concentrateur DSL" ?
Ce qui était utilisé avec les premiers modems DSL, c'est l'OS qui gère la connexion, envoie le mot de passe etc...
Ça peut correspondre à plusieurs modes de fonctionnement différents, donc il faut bien pouvoir configurer le modem pour en choisir un lorsqu'il en supporte plusieurs. Exemple avec le Speed Touch Home : - mode bridge ethernet, généralement utilisé avec PPPoE (c'est probablement ce dont tu voulais parler), - mode relais PPTP/PPPoA, que j'utilise car il me permet d'éviter PPPoE.
Sans parler de la configuration des options propres à chaque mode : VPI/VCI, type d'encapsulation...
Jonathan ROTH a écrit :
Je crois qu'il parlait du mode concetrateur DSL,
Quel mode "concentrateur DSL" ?
Ce qui était utilisé avec les premiers modems DSL, c'est l'OS qui gère
la connexion, envoie le mot de passe etc...
Ça peut correspondre à plusieurs modes de fonctionnement différents,
donc il faut bien pouvoir configurer le modem pour en choisir un
lorsqu'il en supporte plusieurs. Exemple avec le Speed Touch Home :
- mode bridge ethernet, généralement utilisé avec PPPoE (c'est
probablement ce dont tu voulais parler),
- mode relais PPTP/PPPoA, que j'utilise car il me permet d'éviter PPPoE.
Sans parler de la configuration des options propres à chaque mode :
VPI/VCI, type d'encapsulation...
Ce qui était utilisé avec les premiers modems DSL, c'est l'OS qui gère la connexion, envoie le mot de passe etc...
Ça peut correspondre à plusieurs modes de fonctionnement différents, donc il faut bien pouvoir configurer le modem pour en choisir un lorsqu'il en supporte plusieurs. Exemple avec le Speed Touch Home : - mode bridge ethernet, généralement utilisé avec PPPoE (c'est probablement ce dont tu voulais parler), - mode relais PPTP/PPPoA, que j'utilise car il me permet d'éviter PPPoE.
Sans parler de la configuration des options propres à chaque mode : VPI/VCI, type d'encapsulation...
