Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Comment rediriger du traffic interne en repassant par internet ?

25 réponses
Avatar
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 :)

Merci pour toute aide !

Chris

10 réponses

1 2 3
Avatar
Jonathan ROTH
Chris a écrit :

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 ?



Les clients locaux, lors d'une connection à http://mondomaine.com
exécutent une requète DNS, laquelle renvoie (logiquement) ton adresse
publique.
Les clients essayent de se connecter à cette IP, pour eux elle est
extérieur au réseau local, donc ils "sortent" par la passerelle, et
paf... des paquets dans la nature.

Si possible j'aimerais éviter de passer par une zone DNS spécifique pour
le LAN,



Dommage, la zone DNS *est* la solution, par contre il peut y avoir des
autres solutions...

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 :)



Bah ça tombe bien, sans zone, tu va devoir soit rerouter les paquets,
soit modifier les entêtes. D'ailleurs c'est la dernière solution que je
trouve la plus interessante, mais c'est resté dans le domaine théorique
chez moi.
Avatar
Chris
Jonathan ROTH submitted this idea :
Chris a écrit :

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 ?



Les clients locaux, lors d'une connection à http://mondomaine.com exécutent
une requète DNS, laquelle renvoie (logiquement) ton adresse publique.
Les clients essayent de se connecter à cette IP, pour eux elle est extérieur
au réseau local, donc ils "sortent" par la passerelle, et paf... des paquets
dans la nature.



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, et là je sais plus ce qu'il se passe.

Ce qui paraitrait logique, serait qu'il soit naté vers l'ip publique
par le modem, 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, donc le soucis semble être au niveau du modem. 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 :/

Sur fr.comp.reseaux.ip (oui je multiposte, 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.

Si possible j'aimerais éviter de passer par une zone DNS spécifique pour le
LAN,



Dommage, la zone DNS *est* la solution, par contre il peut y avoir des autres
solutions...

parce que je n'ai pas envie de le modifier à chaque fois que la zone
internet est modifiée,



?!?



Ben j'ai pas mal d'alias, et c'est ce que j'avais avant de virtualiser
tout ça, mais j'ai supprimé le bind local pour plein de raisons, je
n'ai gardé que le DNS de l'AD et je ne m'étendrais pas là dessus pour
éviter tout troll :o)
Bref je souhaite éviter de m'appuyer sur le DNS, en tout cas en premier
lieu :)

et aussi surtout parce que je veux comprendre ce qui se passe au niveau IP
:)



Bah ça tombe bien, sans zone, tu va devoir soit rerouter les paquets, soit
modifier les entêtes. D'ailleurs c'est la dernière solution que je trouve la
plus interessante, mais c'est resté dans le domaine théorique chez moi.



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 :)
Avatar
Jonathan ROTH
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, et là je sais plus ce qu'il se passe.



D'après mes expériences sur ce problème, la box ignore le paquet,
certainemement car il rentre par l'interface locale avec une IP publique.

Ce qui paraitrait logique, serait qu'il soit naté vers l'ip publique par
le modem,



Oui...

et renaté vers l'ip RED du firewall,



... perso je crois que non...

comme les autres paquets venant d'internet,



... car ce n'est pas un paquet comme les autres (ip source différente,
interface source différente).

mais je ne vois aucune trace de ça sur le firewall,
donc le soucis semble être au niveau du modem.



Oui...

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 :/



Je penses que c'est la politique de routage du modem/routeur qui est en
cause. Donc à part modifier les tables de routage, je ne vois pas trop
ce que tu peux faire (hormis faire en sorte que le DNS renvoie la
*bonne* réponse, càd pas 62.123.45.67 à la place de 192.168.42.42).

Sur fr.comp.reseaux.ip (oui je multiposte, 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.



Je ne vois pas trop non plus...

Si possible j'aimerais éviter de passer par une zone DNS spécifique
pour le LAN,



Dommage, la zone DNS *est* la solution, par contre il peut y avoir des
autres solutions...

parce que je n'ai pas envie de le modifier à chaque fois que la zone
internet est modifiée,



?!?



Ben j'ai pas mal d'alias, et c'est ce que j'avais avant de virtualiser
tout ça, mais j'ai supprimé le bind local pour plein de raisons, je n'ai
gardé que le DNS de l'AD et je ne m'étendrais pas là dessus pour éviter
tout troll :o)



Bah euh, si tout va sur un serveur, c'est pas compliqué...

---
$ORIGIN mondomaine.com

### champs SOA NS & cie

@ IN A 192.168.42.42
* IN A 192.168.42.42
---

Après, si ton AD cherche les noms dans le DNS, je te l'accorde ça va
être plus long...

Bref je souhaite éviter de m'appuyer sur le DNS, en tout cas en premier
lieu :)



et aussi surtout parce que je veux comprendre ce qui se passe au
niveau IP :)



Bah ça tombe bien, sans zone, tu va devoir soit rerouter les paquets,
soit modifier les entêtes. D'ailleurs c'est la dernière solution que
je trouve la plus interessante, mais c'est resté dans le domaine
théorique chez moi.



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 :)



Comme je l'ai dit, je penses que ça vient du fait que le paquet ne
rentre pas avec la bonne IP source sur la bonne interface. Celà dit, je
ne connais pas ton modem, ni le logiciel qu'il contient.
Avatar
Chris
Jonathan ROTH pretended :
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, et là je sais plus ce qu'il se passe.



D'après mes expériences sur ce problème, la box ignore le paquet,
certainemement car il rentre par l'interface locale avec une IP publique.

Ce qui paraitrait logique, serait qu'il soit naté vers l'ip publique par le
modem,



Oui...

et renaté vers l'ip RED du firewall,



... perso je crois que non...

comme les autres paquets venant d'internet,



... car ce n'est pas un paquet comme les autres (ip source différente,
interface source différente).

mais je ne vois aucune trace de ça sur le firewall, donc le soucis semble
être au niveau du modem.



Oui...



Bon, le modem, c'est un bête SpeedTouch 510, Soft 4.2.10

Dans la liste des interfaces, j'ai ça: (je suis étonné du 10.0.0.138
d'ailleurs mais bon je touche pas pour l'instant.)

Intf Address/Netmask Type Translation
PPPoE_1 193.251.186.80/32 Auto napt
eth0 10.0.0.138/24 User none
eth0 192.168.0.1/24 Extra none
loop 127.0.0.1/8 Auto none

Néanmoins, par le paramétrage du default server placé à 192.168.0.253,
tous les paquets entrant sont donc naté vers le firewall.

Par contre coté table de routage, c'est un peu le bordel, on voit que
j'ai tatonné dans le passé :o) J'ai:

[ip]=>rtlist
Destination Label Gateway Intf Mtrc
Status
193.253.160.3/32 193.251.186.80 PPPoE_1 0 [UP]
193.251.186.80/32 193.251.186.80 PPPoE_1 0 [UP]
255.255.255.255/32 10.0.0.138 eth0 0 [UP]
10.0.0.138/32 10.0.0.138 eth0 0 [UP]
192.168.0.1/32 192.168.0.1 eth0 0 [UP]
127.0.0.1/32 127.0.0.1 loop 0 [UP]
10.0.0.0/24 10.0.0.138 eth0 0 [UP]
192.168.0.0/24 192.168.0.1 eth0 1 [UP]
172.16.0.0/16 192.168.0.254 eth0 1 [UP]
224.0.0.0/4 10.0.0.138* eth0 0 [UP]
0.0.0.0/0 193.251.186.80 PPPoE_1 1 [UP]

Et niveau config IP, j'ai:

[ip]=>config
Forwarding on
Firewalling on
Sendredirects on
Sourcerouting off <-- Je me demande s'il faut investiguer de ce coté.
NetBroadcasts off
Default TTL 64
Fraglimit 64 fragments
Fragcount currently 0 fragments
Defragment mode : always
Address checks : dynamic
Mss Clamping : on


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 :/



Je penses que c'est la politique de routage du modem/routeur qui est en
cause. Donc à part modifier les tables de routage, je ne vois pas trop ce que
tu peux faire (hormis faire en sorte que le DNS renvoie la *bonne* réponse,
càd pas 62.123.45.67 à la place de 192.168.42.42).



Nan le DNS je veux pas :o)

Sur fr.comp.reseaux.ip (oui je multiposte, 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.



Je ne vois pas trop non plus...




Ben j'ai pas mal d'alias, et c'est ce que j'avais avant de virtualiser tout
ça, mais j'ai supprimé le bind local pour plein de raisons, je n'ai gardé
que le DNS de l'AD et je ne m'étendrais pas là dessus pour éviter tout
troll :o)



Bah euh, si tout va sur un serveur, c'est pas compliqué...

---
$ORIGIN mondomaine.com

### champs SOA NS & cie

@ IN A 192.168.42.42
* IN A 192.168.42.42
---

Après, si ton AD cherche les noms dans le DNS, je te l'accorde ça va être
plus long...



Surtout que Endian joue le rôle de proxy DNS transparent, avec renvoi
vers le DNS AD pour le domaine local. C'est tellement simple comme ça,
ça m'embêterait d'en faire un truc compliqué ...

Bref je souhaite éviter de m'appuyer sur le DNS, en tout cas en premier
lieu :)




Bah ça tombe bien, sans zone, tu va devoir soit rerouter les paquets, soit
modifier les entêtes. D'ailleurs c'est la dernière solution que je trouve
la plus interessante, mais c'est resté dans le domaine théorique chez moi.



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 :)



Comme je l'ai dit, je penses que ça vient du fait que le paquet ne rentre pas
avec la bonne IP source sur la bonne interface. Celà dit, je ne connais pas
ton modem, ni le logiciel qu'il contient.



Cf ci dessus. Bon et si je déplace le PPPoE vers le endian, du coup
c'est lui qui aura l'ip publique sur son interface RED, j'aurais
peut-être plus de contrôle. Il faudra que je fasse une règle spécifique
pour accéder au modem depuis mon cacti par contre, pour continuer à y
accéder en snmp, j'ai un peu peur de ce que ça va donner ça :/
Avatar
Jonathan ROTH
Chris a écrit :
Bon, le modem, c'est un bête SpeedTouch 510, Soft 4.2.10

Dans la liste des interfaces, j'ai ça: (je suis étonné du 10.0.0.138
d'ailleurs mais bon je touche pas pour l'instant.)



C'est une relique de l'ancienne époque... 10.0.0.138 était l'adresse des
modems et/ou du concentrateur PPPoE. Compatibilité ascendante toussa,
c'est resté.

Intf Address/Netmask Type Translation
PPPoE_1 193.251.186.80/32 Auto napt
eth0 10.0.0.138/24 User none
eth0 192.168.0.1/24 Extra none
loop 127.0.0.1/8 Auto none



[ip]=>rtlist
Destination Label Gateway Intf Mtrc Status
193.253.160.3/32 193.251.186.80 PPPoE_1 0 [UP]
193.251.186.80/32 193.251.186.80 PPPoE_1 0 [UP]
255.255.255.255/32 10.0.0.138 eth0 0 [UP]
10.0.0.138/32 10.0.0.138 eth0 0 [UP]
192.168.0.1/32 192.168.0.1 eth0 0 [UP]
127.0.0.1/32 127.0.0.1 loop 0 [UP]
10.0.0.0/24 10.0.0.138 eth0 0 [UP]
192.168.0.0/24 192.168.0.1 eth0 1 [UP]
172.16.0.0/16 192.168.0.254 eth0 1 [UP]
224.0.0.0/4 10.0.0.138* eth0 0 [UP]
0.0.0.0/0 193.251.186.80 PPPoE_1 1 [UP]

Et niveau config IP, j'ai:

[ip]=>config
Forwarding on
Firewalling on
Sendredirects on
Sourcerouting off <-- Je me demande s'il faut investiguer de ce coté.
NetBroadcasts off
Default TTL 64
Fraglimit 64 fragments
Fragcount currently 0 fragments
Defragment mode : always
Address checks : dynamic
Mss Clamping : on



A vrai dire j'en ai aucune idée...
Tout ce que je peux te dire, c'est que sur les modems/routeurs que j'ai
testés (box et grand public), le routage local -> local ne fonctionne
pas, juste local <-> public.

Ben j'ai pas mal d'alias, et c'est ce que j'avais avant de
virtualiser tout ça, mais j'ai supprimé le bind local pour plein de
raisons, je n'ai gardé que le DNS de l'AD et je ne m'étendrais pas là
dessus pour éviter tout troll :o)



Bah euh, si tout va sur un serveur, c'est pas compliqué...

---
$ORIGIN mondomaine.com

### champs SOA NS & cie

@ IN A 192.168.42.42
* IN A 192.168.42.42
---

Après, si ton AD cherche les noms dans le DNS, je te l'accorde ça va
être plus long...



Surtout que Endian joue le rôle de proxy DNS transparent, avec renvoi
vers le DNS AD pour le domaine local. C'est tellement simple comme ça,
ça m'embêterait d'en faire un truc compliqué ...



Hmm, et pourquoi pas configurer le champ A dans ton DNS AD, vu que t'as
déjà la zone et les clients configurés...

Cf ci dessus. Bon et si je déplace le PPPoE vers le endian, du coup
c'est lui qui aura l'ip publique sur son interface RED, j'aurais
peut-être plus de contrôle.



C'est quasiment certain, et il y a même des chances que ça fonctionne
directement sans changer la configuration.

Il faudra que je fasse une règle spécifique
pour accéder au modem depuis mon cacti par contre, pour continuer à y
accéder en snmp, j'ai un peu peur de ce que ça va donner ça :/


Avatar
GuiGui
Chris a écrit :


Dans la liste des interfaces, j'ai ça: (je suis étonné du 10.0.0.138
d'ailleurs mais bon je touche pas pour l'instant.)



C'est l'IP sur lequel le soft de configuration s'attend à trouver le
modem. Avantage : on peut telnetter le modem même si il est en bridge
(oui, je sais, c'est con...).
Avatar
GuiGui
Le multipost, c'est pas bien. Le Xpost + Fu2, c'est beaucoup mieux ;-)
Avatar
Chris
GuiGui submitted this idea :
Chris a écrit :


Dans la liste des interfaces, j'ai ça: (je suis étonné du 10.0.0.138
d'ailleurs mais bon je touche pas pour l'instant.)



C'est l'IP sur lequel le soft de configuration s'attend à trouver le modem.
Avantage : on peut telnetter le modem même si il est en bridge (oui, je sais,
c'est con...).



pakon.

Donc même si je mets le port RED en mode PPPoE, je peux continuer de
telnetter et snmp-iser le modem en rajoutant la règle de routage qui va
bien ? je note.
Avatar
Chris
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. :)
Avatar
Chris
Jonathan ROTH used his keyboard to write :
Chris a écrit :
Bon, le modem, c'est un bête SpeedTouch 510, Soft 4.2.10

Dans la liste des interfaces, j'ai ça: (je suis étonné du 10.0.0.138
d'ailleurs mais bon je touche pas pour l'instant.)



C'est une relique de l'ancienne époque... 10.0.0.138 était l'adresse des
modems et/ou du concentrateur PPPoE. Compatibilité ascendante toussa, c'est
resté.



Oké.

A vrai dire j'en ai aucune idée...
Tout ce que je peux te dire, c'est que sur les modems/routeurs que j'ai
testés (box et grand public), le routage local -> local ne fonctionne pas,
juste local <-> public.



Bon je vais peut-être pas m'acharner sur ce scénario, mais j'aurais
aimé comprendre le fin mot de l'histoire.


Surtout que Endian joue le rôle de proxy DNS transparent, avec renvoi vers
le DNS AD pour le domaine local. C'est tellement simple comme ça, ça
m'embêterait d'en faire un truc compliqué ...



Hmm, et pourquoi pas configurer le champ A dans ton DNS AD, vu que t'as déjà
la zone et les clients configurés...



Parce que le domaine local et le domaine internet sont complêtement
différents.


Cf ci dessus. Bon et si je déplace le PPPoE vers le endian, du coup c'est
lui qui aura l'ip publique sur son interface RED, j'aurais peut-être plus
de contrôle.



C'est quasiment certain, et il y a même des chances que ça fonctionne
directement sans changer la configuration.



Bon je vais essayer ça tranquillement ce week end alors.

Merci à vous deux avec GuiGui.
1 2 3