J'ai une passerelle firewall sous Linux Gentoo qui connecte mon LAN a
Internet.
Plage du LAN : 192.168.1.0/24 (le .1 etant la passerelle en question)
IP publique fixe
(Le LAN est sur eth0 et le WAN sur eth1)
Cette passerelle est egalement DNS pour mon nom de domaine.
Les entrées DNS sont :
smtp.mondomaine.fr A ip_publique
mail.mondomaine.fr A ip_publique
Ensuite, le firewall redirige les paquets des ports 25,110 et 143
venant du WAN vers la machine ayant l'IP .10 sur le LAN.
Depuis l'exterieur, cela fonctionne correctement. MAis depuis le LAN,
aucune réponse lorsque l'on donne le FQDN (ie mail.mondomaine.fr).
Je suppose que cela vient du fait que la machine (du LAN) demande une
connection sur l'IP eth1 de la gateway (le paquet venant du LAN), le
firewall va ensuite renvoyer cette demande par la même interface (eth0
donc) sur la machine du LAN.
Je ne sais pas si l'on peut faire en sorte que cela fonctionne sans tucher
au DNS (donc réaliser des actions sur les tables IP par ex)
Sinon, est il possible qu'un DNS retourne une IP différentes selon
l'interface de la requete ?
Je m'explique : si le requete "smtp.mondomaine.fr" vient du LAN, la
réponse sera 192.168.1.10 si elle vient du WAN, le DNS retournera en
réponse l'IP pubique
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,
J'ai une passerelle firewall sous Linux Gentoo qui connecte mon LAN a Internet.
Plage du LAN : 192.168.1.0/24 (le .1 etant la passerelle en question) IP publique fixe (Le LAN est sur eth0 et le WAN sur eth1)
Cette passerelle est egalement DNS pour mon nom de domaine. Les entrées DNS sont : smtp.mondomaine.fr A ip_publique mail.mondomaine.fr A ip_publique
Ensuite, le firewall redirige les paquets des ports 25,110 et 143 venant du WAN vers la machine ayant l'IP .10 sur le LAN.
Depuis l'exterieur, cela fonctionne correctement. MAis depuis le LAN, aucune réponse lorsque l'on donne le FQDN (ie mail.mondomaine.fr).
Je suppose que cela vient du fait que la machine (du LAN) demande une connection sur l'IP eth1 de la gateway (le paquet venant du LAN), le firewall va ensuite renvoyer cette demande par la même interface (eth0 donc) sur la machine du LAN.
"Jusque là, tout va bien", à condition de ne pas bloquer les paquets de eth0 vers eth0 dans la chaîne FORWARD. C'est le routage direct des paquets de réponse du serveur vers le client sans passer par la passerelle, et donc sans subir le NAT retour, qui fait que la connexion échoue.
Je ne sais pas si l'on peut faire en sorte que cela fonctionne sans tucher au DNS (donc réaliser des actions sur les tables IP par ex)
Il suffit de NATer l'adresse source des clients du LAN, avec des règles du style :
Inconvénient : toutes les connexions venant du LAN semblent venir de la passerelle. Pour l'éviter, on peut faire du NAT source 1:1 avec une plage d'adresses inutilisées grâce à NETMAP. Attention, NETMAP n'est pas supporté par tous les noyaux, mais il existe un patch dans les versions antérieurs à 20060512 du patch-o-matic-ng de Netfilter. Par exemple :
Ainsi une connexion venant de 192.168.1.45 a l'air de venir de 192.168.2.45.
Sinon, est il possible qu'un DNS retourne une IP différentes selon l'interface de la requete ? Je m'explique : si le requete "smtp.mondomaine.fr" vient du LAN, la réponse sera 192.168.1.10 si elle vient du WAN, le DNS retournera en réponse l'IP pubique
C'est possible avec Bind 9, en créant des "vues" (views) différentes pour les requêtes venant du LAN et de l'extérieur.
[Suivi vers fr.comp.reseaux.ip]
Salut,
J'ai une passerelle firewall sous Linux Gentoo qui connecte mon LAN a
Internet.
Plage du LAN : 192.168.1.0/24 (le .1 etant la passerelle en question)
IP publique fixe
(Le LAN est sur eth0 et le WAN sur eth1)
Cette passerelle est egalement DNS pour mon nom de domaine.
Les entrées DNS sont :
smtp.mondomaine.fr A ip_publique
mail.mondomaine.fr A ip_publique
Ensuite, le firewall redirige les paquets des ports 25,110 et 143
venant du WAN vers la machine ayant l'IP .10 sur le LAN.
Depuis l'exterieur, cela fonctionne correctement. MAis depuis le LAN,
aucune réponse lorsque l'on donne le FQDN (ie mail.mondomaine.fr).
Je suppose que cela vient du fait que la machine (du LAN) demande une
connection sur l'IP eth1 de la gateway (le paquet venant du LAN), le
firewall va ensuite renvoyer cette demande par la même interface (eth0
donc) sur la machine du LAN.
"Jusque là, tout va bien", à condition de ne pas bloquer les paquets de
eth0 vers eth0 dans la chaîne FORWARD. C'est le routage direct des
paquets de réponse du serveur vers le client sans passer par la
passerelle, et donc sans subir le NAT retour, qui fait que la connexion
échoue.
Je ne sais pas si l'on peut faire en sorte que cela fonctionne sans tucher
au DNS (donc réaliser des actions sur les tables IP par ex)
Il suffit de NATer l'adresse source des clients du LAN, avec des règles
du style :
Inconvénient : toutes les connexions venant du LAN semblent venir de la
passerelle. Pour l'éviter, on peut faire du NAT source 1:1 avec une
plage d'adresses inutilisées grâce à NETMAP. Attention, NETMAP n'est pas
supporté par tous les noyaux, mais il existe un patch dans les versions
antérieurs à 20060512 du patch-o-matic-ng de Netfilter.
Par exemple :
Ainsi une connexion venant de 192.168.1.45 a l'air de venir de 192.168.2.45.
Sinon, est il possible qu'un DNS retourne une IP différentes selon
l'interface de la requete ?
Je m'explique : si le requete "smtp.mondomaine.fr" vient du LAN, la
réponse sera 192.168.1.10 si elle vient du WAN, le DNS retournera en
réponse l'IP pubique
C'est possible avec Bind 9, en créant des "vues" (views) différentes
pour les requêtes venant du LAN et de l'extérieur.
J'ai une passerelle firewall sous Linux Gentoo qui connecte mon LAN a Internet.
Plage du LAN : 192.168.1.0/24 (le .1 etant la passerelle en question) IP publique fixe (Le LAN est sur eth0 et le WAN sur eth1)
Cette passerelle est egalement DNS pour mon nom de domaine. Les entrées DNS sont : smtp.mondomaine.fr A ip_publique mail.mondomaine.fr A ip_publique
Ensuite, le firewall redirige les paquets des ports 25,110 et 143 venant du WAN vers la machine ayant l'IP .10 sur le LAN.
Depuis l'exterieur, cela fonctionne correctement. MAis depuis le LAN, aucune réponse lorsque l'on donne le FQDN (ie mail.mondomaine.fr).
Je suppose que cela vient du fait que la machine (du LAN) demande une connection sur l'IP eth1 de la gateway (le paquet venant du LAN), le firewall va ensuite renvoyer cette demande par la même interface (eth0 donc) sur la machine du LAN.
"Jusque là, tout va bien", à condition de ne pas bloquer les paquets de eth0 vers eth0 dans la chaîne FORWARD. C'est le routage direct des paquets de réponse du serveur vers le client sans passer par la passerelle, et donc sans subir le NAT retour, qui fait que la connexion échoue.
Je ne sais pas si l'on peut faire en sorte que cela fonctionne sans tucher au DNS (donc réaliser des actions sur les tables IP par ex)
Il suffit de NATer l'adresse source des clients du LAN, avec des règles du style :
Inconvénient : toutes les connexions venant du LAN semblent venir de la passerelle. Pour l'éviter, on peut faire du NAT source 1:1 avec une plage d'adresses inutilisées grâce à NETMAP. Attention, NETMAP n'est pas supporté par tous les noyaux, mais il existe un patch dans les versions antérieurs à 20060512 du patch-o-matic-ng de Netfilter. Par exemple :
Ainsi une connexion venant de 192.168.1.45 a l'air de venir de 192.168.2.45.
Sinon, est il possible qu'un DNS retourne une IP différentes selon l'interface de la requete ? Je m'explique : si le requete "smtp.mondomaine.fr" vient du LAN, la réponse sera 192.168.1.10 si elle vient du WAN, le DNS retournera en réponse l'IP pubique
C'est possible avec Bind 9, en créant des "vues" (views) différentes pour les requêtes venant du LAN et de l'extérieur.
[Suivi vers fr.comp.reseaux.ip]
Sébastien Monbrun aka TiChou
Dans le message <news:ef1a6d$3010$, *Pascal Hambourg* tapota sur f.c.r.ip et f.c.o.l.configuration :
Il suffit de NATer l'adresse source des clients du LAN, avec des règles du style :
Ou bien (plus simplement, dirais-je) de changer l'adresse source des paquets retours sur la machine du LAN hébergeant les services, si cette machine le permet bien évidement.
-- Sébastien Monbrun aka TiChou
Dans le message <news:ef1a6d$3010$1@biggoron.nerim.net>,
*Pascal Hambourg* tapota sur f.c.r.ip et f.c.o.l.configuration :
Il suffit de NATer l'adresse source des clients du LAN, avec des règles du
style :
Ou bien (plus simplement, dirais-je) de changer l'adresse source des paquets
retours sur la machine du LAN hébergeant les services, si cette machine le
permet bien évidement.
Dans le message <news:ef1a6d$3010$, *Pascal Hambourg* tapota sur f.c.r.ip et f.c.o.l.configuration :
Il suffit de NATer l'adresse source des clients du LAN, avec des règles du style :
Ou bien (plus simplement, dirais-je) de changer l'adresse source des paquets retours sur la machine du LAN hébergeant les services, si cette machine le permet bien évidement.
-- Sébastien Monbrun aka TiChou
Pascal Hambourg
Il suffit de NATer l'adresse source des clients du LAN, avec des règles du style :
Ou bien (plus simplement, dirais-je) de changer l'adresse source des paquets retours sur la machine du LAN hébergeant les services, si cette machine le permet bien évidement.
Bof, parce que :
- Le DNAT de la passerelle peut avoir pour effet de bord de modifier également le port source original.
- Le serveur ne peut savoir si la connexion reçue est directe ou a été DNATée, et donc s'il doit répondre avec son adresse réelle ou avec l'adresse publique.
- Le suivi de connexion de la passerelle ne voit jamais les paquets retour. Les valeurs de time-out restent doncà des valeurs faibles. Ça pourrait avoir des conséquences si la connexion doit être persistante, même si je ne vois pas lesquelles dans l'immédiat.
Enfin, pour mon édification, à quoi penses-tu pour modifier l'adresse source des paquets de réponse ? Sous Linux, iptables ne le permet pas. Au NAT stateless intégré au routage avancé (CONFIG_IP_ROUTE_NAT) ?
Il suffit de NATer l'adresse source des clients du LAN, avec des
règles du style :
Ou bien (plus simplement, dirais-je) de changer l'adresse source des
paquets retours sur la machine du LAN hébergeant les services, si cette
machine le permet bien évidement.
Bof, parce que :
- Le DNAT de la passerelle peut avoir pour effet de bord de modifier
également le port source original.
- Le serveur ne peut savoir si la connexion reçue est directe ou a été
DNATée, et donc s'il doit répondre avec son adresse réelle ou avec
l'adresse publique.
- Le suivi de connexion de la passerelle ne voit jamais les paquets
retour. Les valeurs de time-out restent doncà des valeurs faibles. Ça
pourrait avoir des conséquences si la connexion doit être persistante,
même si je ne vois pas lesquelles dans l'immédiat.
Enfin, pour mon édification, à quoi penses-tu pour modifier l'adresse
source des paquets de réponse ? Sous Linux, iptables ne le permet pas.
Au NAT stateless intégré au routage avancé (CONFIG_IP_ROUTE_NAT) ?
Il suffit de NATer l'adresse source des clients du LAN, avec des règles du style :
Ou bien (plus simplement, dirais-je) de changer l'adresse source des paquets retours sur la machine du LAN hébergeant les services, si cette machine le permet bien évidement.
Bof, parce que :
- Le DNAT de la passerelle peut avoir pour effet de bord de modifier également le port source original.
- Le serveur ne peut savoir si la connexion reçue est directe ou a été DNATée, et donc s'il doit répondre avec son adresse réelle ou avec l'adresse publique.
- Le suivi de connexion de la passerelle ne voit jamais les paquets retour. Les valeurs de time-out restent doncà des valeurs faibles. Ça pourrait avoir des conséquences si la connexion doit être persistante, même si je ne vois pas lesquelles dans l'immédiat.
Enfin, pour mon édification, à quoi penses-tu pour modifier l'adresse source des paquets de réponse ? Sous Linux, iptables ne le permet pas. Au NAT stateless intégré au routage avancé (CONFIG_IP_ROUTE_NAT) ?
Elekaj
Le Fri, 22 Sep 2006 20:31:34 +0200, Pascal Hambourg a écrit :
Il suffit de NATer l'adresse source des clients du LAN, avec des règles du style :
En effet, le problème venait bien de la (et j'ai pu le vérifier avec un tcpdump ce que j'aurai du faire avant d'ailleurs) Avec la règle ci-dessus, problème résolu.
Inconvénient : toutes les connexions venant du LAN semblent venir de la passerelle.
Pour moi, cela ne me gène pas. Ce que je recherche c'est une solution fonctionnelle.
C'est possible avec Bind 9, en créant des "vues" (views) différentes pour les requêtes venant du LAN et de l'extérieur.
Je vais tout de même essayer pour l'aspect éducatif de la chose et pouvoir me coucher moins bête se soir :-)
[Suivi vers fr.comp.reseaux.ip] Merci pour le fu2 et au passage désolé d'avoir fais du crossposting.
Cordialement,
Elekaj
Le Fri, 22 Sep 2006 20:31:34 +0200, Pascal Hambourg a écrit :
Il suffit de NATer l'adresse source des clients du LAN, avec des règles
du style :
En effet, le problème venait bien de la (et j'ai pu le vérifier avec un
tcpdump ce que j'aurai du faire avant d'ailleurs)
Avec la règle ci-dessus, problème résolu.
Inconvénient : toutes les connexions venant du LAN semblent venir de la
passerelle.
Pour moi, cela ne me gène pas. Ce que je recherche c'est une solution
fonctionnelle.
C'est possible avec Bind 9, en créant des "vues" (views) différentes
pour les requêtes venant du LAN et de l'extérieur.
Je vais tout de même essayer pour l'aspect éducatif de la chose et
pouvoir me coucher moins bête se soir :-)
[Suivi vers fr.comp.reseaux.ip]
Merci pour le fu2 et au passage désolé d'avoir fais du crossposting.
En effet, le problème venait bien de la (et j'ai pu le vérifier avec un tcpdump ce que j'aurai du faire avant d'ailleurs) Avec la règle ci-dessus, problème résolu.
Inconvénient : toutes les connexions venant du LAN semblent venir de la passerelle.
Pour moi, cela ne me gène pas. Ce que je recherche c'est une solution fonctionnelle.
C'est possible avec Bind 9, en créant des "vues" (views) différentes pour les requêtes venant du LAN et de l'extérieur.
Je vais tout de même essayer pour l'aspect éducatif de la chose et pouvoir me coucher moins bête se soir :-)
[Suivi vers fr.comp.reseaux.ip] Merci pour le fu2 et au passage désolé d'avoir fais du crossposting.
