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 :)
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.
Tu veux dire par liaison série ? Un exemple ?
GuiGui
Pascal Hambourg a écrit :
Tu veux dire par liaison série ? Un exemple ?
J'ai déjà utilisé, par exemple, des C827 en mode bridge simple. L'IP n'est pas obligatoire, il ne reste que la console. D'anciens STH, pour lesquels on pouvait même désactiver complètement l'ethernet (avec derrière un routeur atm-ethernet genre 5711). Les LinkAccess, en fonction de leur configuration. Remarque aussi, pour certains modems, il n'y a pas d'IP sur l'interface ethernet et pas d'interface série, ce qui n'empèche pas d'accéder au modem depuis le concentrateur via ATM.
Pascal Hambourg a écrit :
Tu veux dire par liaison série ? Un exemple ?
J'ai déjà utilisé, par exemple, des C827 en mode bridge simple. L'IP
n'est pas obligatoire, il ne reste que la console. D'anciens STH, pour
lesquels on pouvait même désactiver complètement l'ethernet (avec
derrière un routeur atm-ethernet genre 5711). Les LinkAccess, en
fonction de leur configuration.
Remarque aussi, pour certains modems, il n'y a pas d'IP sur l'interface
ethernet et pas d'interface série, ce qui n'empèche pas d'accéder au
modem depuis le concentrateur via ATM.
J'ai déjà utilisé, par exemple, des C827 en mode bridge simple. L'IP n'est pas obligatoire, il ne reste que la console. D'anciens STH, pour lesquels on pouvait même désactiver complètement l'ethernet (avec derrière un routeur atm-ethernet genre 5711). Les LinkAccess, en fonction de leur configuration. Remarque aussi, pour certains modems, il n'y a pas d'IP sur l'interface ethernet et pas d'interface série, ce qui n'empèche pas d'accéder au modem depuis le concentrateur via ATM.
Chris
After serious thinking Pascal Hambourg wrote :
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.
De toutes façons je ne sais pas pourquoi, mais je n'ai jamais réussi à faire du PPPoA sur ma ligne. Je parlais de mettre la gestion du PPPoE sur la patte RED du endian, en bridge donc si je ne m'abuse. Et le mtu reste définissable port par port, donc ça ne parait pas un problème.
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 ?
Etant sur un vm en mode applicance, toute modification ultérieure des règles de firewall/nat via l'interface web d'admin de endian ne va-t'elle pas faire sauter ces règles éditées manuellement ?
Certes je pourrais faire un firewall/routeur from scratch en codant toutes les règles, mais d'une part je n'en ai pas les compétences, d'autre part je n'en ai pas le temps matériel. Alors que là, je me contente de faire du paramétrage, et il ne me reste plus que ce soucis, certes agaçant, mais le reste est très satisfaisant.
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.
les seules règles NAT définissables sont au niveau de l'interface RED. Je peux éventuellement ajouter des règles SNAT mais je ne suis pas sur que ça puisse m'aider dans ce problème.
En tout cas merci pour les différents éclairages.
After serious thinking Pascal Hambourg wrote :
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.
De toutes façons je ne sais pas pourquoi, mais je n'ai jamais réussi à
faire du PPPoA sur ma ligne.
Je parlais de mettre la gestion du PPPoE sur la patte RED du endian, en
bridge donc si je ne m'abuse. Et le mtu reste définissable port par
port, donc ça ne parait pas un problème.
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 ?
Etant sur un vm en mode applicance, toute modification ultérieure des
règles de firewall/nat via l'interface web d'admin de endian ne
va-t'elle pas faire sauter ces règles éditées manuellement ?
Certes je pourrais faire un firewall/routeur from scratch en codant
toutes les règles, mais d'une part je n'en ai pas les compétences,
d'autre part je n'en ai pas le temps matériel. Alors que là, je me
contente de faire du paramétrage, et il ne me reste plus que ce soucis,
certes agaçant, mais le reste est très satisfaisant.
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.
les seules règles NAT définissables sont au niveau de l'interface RED.
Je peux éventuellement ajouter des règles SNAT mais je ne suis pas sur
que ça puisse m'aider dans ce problème.
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.
De toutes façons je ne sais pas pourquoi, mais je n'ai jamais réussi à faire du PPPoA sur ma ligne. Je parlais de mettre la gestion du PPPoE sur la patte RED du endian, en bridge donc si je ne m'abuse. Et le mtu reste définissable port par port, donc ça ne parait pas un problème.
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 ?
Etant sur un vm en mode applicance, toute modification ultérieure des règles de firewall/nat via l'interface web d'admin de endian ne va-t'elle pas faire sauter ces règles éditées manuellement ?
Certes je pourrais faire un firewall/routeur from scratch en codant toutes les règles, mais d'une part je n'en ai pas les compétences, d'autre part je n'en ai pas le temps matériel. Alors que là, je me contente de faire du paramétrage, et il ne me reste plus que ce soucis, certes agaçant, mais le reste est très satisfaisant.
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.
les seules règles NAT définissables sont au niveau de l'interface RED. Je peux éventuellement ajouter des règles SNAT mais je ne suis pas sur que ça puisse m'aider dans ce problème.
En tout cas merci pour les différents éclairages.
Pascal Hambourg
Chris a écrit :
After serious thinking Pascal Hambourg wrote :
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.
De toutes façons je ne sais pas pourquoi, mais je n'ai jamais réussi à faire du PPPoA sur ma ligne. Je parlais de mettre la gestion du PPPoE sur la patte RED du endian, en bridge donc si je ne m'abuse.
J'avais bien compris.
Et le mtu reste définissable port par port, donc ça ne parait pas un problème.
Ça permet de maîtriser la taille des paquets que tu envoies, mais pas la taille des paquets qu'on t'envoie. Quand on t'envoie un paquet de taille supérieure à 1492, il ne peut pas passer par la liaison PPPoE entre le modem et le routeur-firewall. Le modem étant un simple pont, transparent au niveau IP, il ne peut ni fragmenter le paquet ni renvoyer de message d'erreur ICMP signalant à l'expéditeur que le paquet est trop gros. Tu n'as plus qu'à espérer que ton FAI le fasse en amont.
Etant sur un vm en mode applicance, toute modification ultérieure des règles de firewall/nat via l'interface web d'admin de endian ne va-t'elle pas faire sauter ces règles éditées manuellement ?
C'est fort possible. Il faut regarder comment fonctionne l'appliance pour créer les règles au démarrage et après une modification via l'interface de configuration pour y intégrer tes règles aussi harmonieusement que possible. Il faut aussi que tes règles s'insèrent au bon endroit, elles ne serviraient à rien en fin de chaîne après une règle qui DROP tout.
les seules règles NAT définissables sont au niveau de l'interface RED.
Je trouve que cette appliance manque singulièrement de souplesse dans ses possibilités de configuration.
Je peux éventuellement ajouter des règles SNAT mais je ne suis pas sur que ça puisse m'aider dans ce problème.
Non, ça n'aiderait en rien. Ça peut être nécessaire dans les cas de redirection avec routage "triangulaire", où la connexion est redirigée vers un serveur qui est dans le même réseau que le client. Mais ce n'est pas le cas ici.
Chris a écrit :
After serious thinking Pascal Hambourg wrote :
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.
De toutes façons je ne sais pas pourquoi, mais je n'ai jamais réussi à
faire du PPPoA sur ma ligne.
Je parlais de mettre la gestion du PPPoE sur la patte RED du endian, en
bridge donc si je ne m'abuse.
J'avais bien compris.
Et le mtu reste définissable port par
port, donc ça ne parait pas un problème.
Ça permet de maîtriser la taille des paquets que tu envoies, mais pas la
taille des paquets qu'on t'envoie. Quand on t'envoie un paquet de taille
supérieure à 1492, il ne peut pas passer par la liaison PPPoE entre le
modem et le routeur-firewall. Le modem étant un simple pont, transparent
au niveau IP, il ne peut ni fragmenter le paquet ni renvoyer de message
d'erreur ICMP signalant à l'expéditeur que le paquet est trop gros. Tu
n'as plus qu'à espérer que ton FAI le fasse en amont.
Etant sur un vm en mode applicance, toute modification ultérieure des
règles de firewall/nat via l'interface web d'admin de endian ne
va-t'elle pas faire sauter ces règles éditées manuellement ?
C'est fort possible. Il faut regarder comment fonctionne l'appliance
pour créer les règles au démarrage et après une modification via
l'interface de configuration pour y intégrer tes règles aussi
harmonieusement que possible. Il faut aussi que tes règles s'insèrent au
bon endroit, elles ne serviraient à rien en fin de chaîne après une
règle qui DROP tout.
les seules règles NAT définissables sont au niveau de l'interface RED.
Je trouve que cette appliance manque singulièrement de souplesse dans
ses possibilités de configuration.
Je peux éventuellement ajouter des règles SNAT mais je ne suis pas sur
que ça puisse m'aider dans ce problème.
Non, ça n'aiderait en rien. Ça peut être nécessaire dans les cas de
redirection avec routage "triangulaire", où la connexion est redirigée
vers un serveur qui est dans le même réseau que le client. Mais ce n'est
pas le cas ici.
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.
De toutes façons je ne sais pas pourquoi, mais je n'ai jamais réussi à faire du PPPoA sur ma ligne. Je parlais de mettre la gestion du PPPoE sur la patte RED du endian, en bridge donc si je ne m'abuse.
J'avais bien compris.
Et le mtu reste définissable port par port, donc ça ne parait pas un problème.
Ça permet de maîtriser la taille des paquets que tu envoies, mais pas la taille des paquets qu'on t'envoie. Quand on t'envoie un paquet de taille supérieure à 1492, il ne peut pas passer par la liaison PPPoE entre le modem et le routeur-firewall. Le modem étant un simple pont, transparent au niveau IP, il ne peut ni fragmenter le paquet ni renvoyer de message d'erreur ICMP signalant à l'expéditeur que le paquet est trop gros. Tu n'as plus qu'à espérer que ton FAI le fasse en amont.
Etant sur un vm en mode applicance, toute modification ultérieure des règles de firewall/nat via l'interface web d'admin de endian ne va-t'elle pas faire sauter ces règles éditées manuellement ?
C'est fort possible. Il faut regarder comment fonctionne l'appliance pour créer les règles au démarrage et après une modification via l'interface de configuration pour y intégrer tes règles aussi harmonieusement que possible. Il faut aussi que tes règles s'insèrent au bon endroit, elles ne serviraient à rien en fin de chaîne après une règle qui DROP tout.
les seules règles NAT définissables sont au niveau de l'interface RED.
Je trouve que cette appliance manque singulièrement de souplesse dans ses possibilités de configuration.
Je peux éventuellement ajouter des règles SNAT mais je ne suis pas sur que ça puisse m'aider dans ce problème.
Non, ça n'aiderait en rien. Ça peut être nécessaire dans les cas de redirection avec routage "triangulaire", où la connexion est redirigée vers un serveur qui est dans le même réseau que le client. Mais ce n'est pas le cas ici.
Chris
Chris wrote :
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
Bon, la bascule du PPPoE du modem vers le endian semble avoir résolu mon problème, maintenatn en utilisant le fqdn public j'atteins bien mes services web depuis le réseau vert, comme si je venais du net.
Merci pour vos éclairages, je suis bien content de ce dénoument pour un détail d'ésthète :)
Chris
Chris wrote :
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
Bon, la bascule du PPPoE du modem vers le endian semble avoir résolu
mon problème, maintenatn en utilisant le fqdn public j'atteins bien mes
services web depuis le réseau vert, comme si je venais du net.
Merci pour vos éclairages, je suis bien content de ce dénoument pour un
détail d'ésthète :)
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
Bon, la bascule du PPPoE du modem vers le endian semble avoir résolu mon problème, maintenatn en utilisant le fqdn public j'atteins bien mes services web depuis le réseau vert, comme si je venais du net.
Merci pour vos éclairages, je suis bien content de ce dénoument pour un détail d'ésthète :)
