probleme avec routage/iptables/DNS

Salut,

[Je coupe]

maintenant voila le point problematique :
si depuis 192.168.255.0/24 je peux pinger 192.168.254.252 et
192.168.254.253, je ne peux le faire si je suis sur 192.168.254.z.
a l'opposé, si je suis sur 192.168.254.0/24, je ne peux pinger que
192.168.255.252 et 192.168.255.253.

d'apres traceroute, ca bloque au niveau du routeur, a savoir qu'il ne
renvoie pas le premier ping

Normal, dans ce cas le routeur n'est pas impliqué, il ne reçoit même pas
les paquets du ping ou du traceroute. Ce problème est lié à la
résolution ARP qui sert à convertir les adresses IP en adresses MAC (ou
ethernet). Si nécessaire je te renvoie aux nombreuses sources
d'informations disponibles sur le fonctionnement d'ARP.

Par défaut, une machine qui veut joindre une adresse dans son propre
sous-réseau n'a aucune raison de passer par le routeur. Elle émet une
requête ARP pour l'adresse IP destination pour connaître l'adresse MAC
de l'interface correspondante sur le lien ethernet. Comme aucune machine
dans le sous-réseau n'a l'adresse IP demandée, pas de réponse ARP et les
paquets IP ne peuvent même pas être émis.

Par contre, pour joindre les adresses de DNS définies dans l'autre
sous-réseau, la machine émettrice sait grâce à sa table de routage
qu'elle doit passer par une passerelle. Dans ce cas, la requête ARP
porte sur l'adresse IP de la passerelle et non de l'adresse IP
destination. Le routeur répond à la requête ARP avec sa propre adresse
MAC, et la machine envoie le paquet IP avec l'adresse IP destination
réelle mais l'adresse MAC destination du routeur. Le routeur reçoit le
paquet et peut faire le masquerading.

Bref, il faut faire en sorte que le routeur réponde lui-même aux
requêtes ARP pour ces adresses IP inexistantes. Je pensais qu'on pouvait
le faire avec l'option "pub" de la commande arp :

$ arp -i eth0 -Ds 192.168.255.252 eth0 pub
et ainsi de suite.

Mais je n'ai pas réussi à le faire fonctionner avec mon propre routeur
bien que la commande soit acceptée. D'après mes recherches je ne suis
pas le seul. Tu auras peut-être plus de chance.

Une autre possibilité est de définir ces adresses de DNS comme alias des
interfaces du routeur. Ainsi celui-ci répondra aux requêtes ARP.

Je terminerai en notant qu'il est inutile que les adresses de DNS
virtuelles appartiennet au même sous-réseau que les machines. Il serait
donc plus simple qu'elles appartiennent à un bloc privé quelconque que
tu es sûr de ne jamais utiliser, du moment que pour les machines locales
ces adresses sont joignables à travers le routeur. Exemples :
- 192.168.0-253.x
- 172.16-31.x.y
- 10.x.y.z

marin_shadok wrote:

Bonjour,

je suis actuellement en train de travailler sur la configuration d'une
machine routeur dédiée sous Linux qui va servir a partager ma connection
free entre moi et 4 potes. Pour rendre les choses un peu plus facile,
j'ai masqueradé les DNS sur 192.168.{254,255}.{252,253} de maniere a ce
que vu de l'interieur, les adresses de DNS soient constantes.
Mouais, en général on place plutôt un proxyDNS qui est une application dédié

à ce genre de boulot. L'application a en outre l'avantage de mémoriser
(cacher en anglo-amerloque) les requêtes et d'offrir une seule adresse
interne tout en redirigeant les requêtes sur autant de serveurs qeu l'on
souhaite.
Dans le jargon DNS cette fonctionnalité se nomme un cache DNS.
BIND peut faire l'affaire, of course, mais il y a plus simple, plus petit.
Cela évite en outre d'écrire des règles qui n'ont rien à faire là.
La meilleure solution reste en ocre d'installer son propore serveur DNS. On
ne dépend ainsi pas de la charge des serveurs du FAI. C'est à peine plus
compliqué.
Bref, ce n'est pas le sujet.

en interne
nous avons deux reseaux 192.168 , 192.168.255.0/24 utilisé exclusivement
par moi, et 192.168.254.0/24 utilisé par tout les autres, afin de
pouvoir restreindre les possibilités de prise de controle du routeur par
ssh.

on a donc ca :

routeur : -eth0 ; 192.168.255.254/24
-eth1 ; IP pseudostatique uuu.vvv.www.xxx/24
-eth2 ; 192.168.254.254/24

tables de routage :

uuu.vvv.www.0/24 dev eth1 proto kernel scope link src uuu.vvv.www.xxx
192.168.254.0/24 dev eth2 proto kernel scope link src 192.168.254.254
192.168.255.0/24 dev eth0 proto kernel scope link src 192.168.255.254
default via uuu.www.xxx.254 dev eth1

regles iptables

Hum, première remarque : les règles se confectionnent PAR INTERFACE.

Ne serait-ce que parce que toutes les interfaces n'ont pas les mêmes
contraintes de gestion des flux et de sécurité.
En outre, deuxième remarque : il est largement préférable de préciser les
adresses sources sinon les effets de bord ne se font pas attendre !
En n'observant pas cela on s'expose à des erreurs et au fouillis.
Un peu de méthode que DIABLE !

Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT all -- anywhere 192.168.254.252 to:213.228.0.168
DNAT all -- anywhere 192.168.255.252 to:213.228.0.168
DNAT all -- anywhere 192.168.254.253 to:213.228.0.96
DNAT all -- anywhere 192.168.255.253 to:213.228.0.96

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all -- anywhere anywhere to:uuu.vvv.www.xxx
Paf ! Gagné ! Ca ca se place UNIQUEMENT sur l'interface SORTANTE (eth1) et

en précisant les plans source concernés. Or là, cette règle figure sur
toutes les interfaces. Même remarque pour les DNAT du reste.

En fait le ping de 254.x vers 255.252 par exemple est en réalité un ping
entre 254.x et le serveur 0.168 !
Vous l'aviez remarqué ?

Bon allez nettoyer moi tout ça.

1. Virez-moi les règles DNAT pour commencer et écrivez-moi une règle SNAT
comme suit :
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.254.0/23
-j SNAT --to vvv.www.xxx

2. Refaites vos essais.

3. Si vous y tenez absolument écrivez vos règles DNAT sous la forme :
iptables -t nat -A PREROUTING -i eth2
-j DNAT --to 213.228.0.168

4. Et ensuite protégez l'accès à votre machine à l'aide de régles INPUT.

5. Et ça devrait aller bien mieux.


Bah, erreur de jeunesse ... :-)

db
--
email : usenet blas net

marin_shadok wrote:

Bonjour,

je suis actuellement en train de travailler sur la configuration d'une
machine routeur dédiée sous Linux qui va servir a partager ma connection
free entre moi et 4 potes. Pour rendre les choses un peu plus facile,
j'ai masqueradé les DNS sur 192.168.{254,255}.{252,253} de maniere a ce
que vu de l'interieur, les adresses de DNS soient constantes.

Mouais, en général on place plutôt un proxyDNS qui est une application
dédiée à ce genre de boulot. L'application a en outre l'avantage de
mémoriser (cacher en anglo-amerloque) les requêtes et d'offrir une seule
adresse interne tout en redirigeant les requêtes sur autant de serveurs qeu
l'on souhaite.
Dans le jargon DNS cette fonctionnalité se nomme un cache DNS.
BIND peut faire l'affaire, of course, mais il y a plus simple, plus petit.
Cela évite en outre d'écrire des règles qui n'ont rien à faire là.
La meilleure solution reste encore d'installer son propre serveur DNS. On
ne dépend ainsi pas de la charge des serveurs du FAI. Et c'est à peine plus
compliqué.
Bref, ce n'est pas le sujet.

en interne
nous avons deux reseaux 192.168 , 192.168.255.0/24 utilisé exclusivement
par moi, et 192.168.254.0/24 utilisé par tout les autres, afin de
pouvoir restreindre les possibilités de prise de controle du routeur par
ssh.

on a donc ca :

routeur : -eth0 ; 192.168.255.254/24
-eth1 ; IP pseudostatique uuu.vvv.www.xxx/24
-eth2 ; 192.168.254.254/24

tables de routage :

uuu.vvv.www.0/24 dev eth1 proto kernel scope link src uuu.vvv.www.xxx
192.168.254.0/24 dev eth2 proto kernel scope link src 192.168.254.254
192.168.255.0/24 dev eth0 proto kernel scope link src 192.168.255.254
default via uuu.www.xxx.254 dev eth1

regles iptables

Hum, première remarque : les règles se confectionnent PAR INTERFACE.
Ne serait-ce que parce que toutes les interfaces n'ont pas les mêmes
contraintes de gestion des flux et de sécurité.
En outre, deuxième remarque : il est largement préférable de préciser les
adresses sources sinon les effets de bord ne se font pas attendre !
En n'observant pas cela on s'expose à des erreurs et au fouillis.
Un peu de méthode que DIABLE !

Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT all -- anywhere 192.168.254.252 to:213.228.0.168
DNAT all -- anywhere 192.168.255.252 to:213.228.0.168
DNAT all -- anywhere 192.168.254.253 to:213.228.0.96
DNAT all -- anywhere 192.168.255.253 to:213.228.0.96

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all -- anywhere anywhere to:uuu.vvv.www.xxx

Paf ! Gagné ! Ca ca se place UNIQUEMENT sur l'interface SORTANTE (eth1) et
en précisant les plans source concernés. Or là, cette règle figure sur
toutes les interfaces. Même remarque pour les DNAT du reste.

En fait le ping de 254.x vers 255.252 par exemple est en réalité un ping
entre 254.x et le serveur 0.168 !
Vous l'aviez remarqué ?

Bon allez nettoyer moi tout ça.

1. Virez-moi les règles DNAT pour commencer et écrivez-moi une règle SNAT
comme suit :
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.254.0/23
-j SNAT --to vvv.www.xxx

2. Refaites vos essais.

3. Si vous y tenez absolument écrivez vos règles DNAT sous la forme :
iptables -t nat -A PREROUTING -i eth2
-j DNAT --to 213.228.0.168

4. Et ensuite protégez l'accès à votre machine à l'aide de régles INPUT.

5. Et ça devrait aller bien mieux.


Bah, erreur de jeunesse ... :-)

db
--
email : usenet blas net

Mouais, en général on place plutôt un proxyDNS qui est une application
dédiée à ce genre de boulot.

Chuis d'accord avec Domi. <pub> dnsmasq </pub>

regles iptables

Hum, première remarque : les règles se confectionnent PAR INTERFACE.

Chuis encore d'accord avec Domi. En même temps, tu ne peux pas savoir si
ce sage précepte a été appliqué ici ou pas : la sortie "normale"
d'iptables -L (sans l'option bavarde -v) ne mentionne pas les
interfaces. Grosse carence AMA. Compte tenu de la mauvaise lisibilité de
la sortie complète, on préfèrera soit le listing du script de création
des règles, soit la sortie de la commande iptables-save qui a en plus
l'avantage de lister le contenu de toutes les tables d'un coup.

A part ça, tu penses que je suis complètement à côté de la plaque avec
mon histoire d'ARP ?

Pascal@plouf wrote:

Mouais, en général on place plutôt un proxyDNS qui est une application
dédiée à ce genre de boulot.

Chuis d'accord avec Domi. <pub> dnsmasq </pub>
Ah oui, c'est ça. Mais je crois en avoir vu un autre récemment.

Bref, ce n'est pas compliqué à trouver.

regles iptables

Hum, première remarque : les règles se confectionnent PAR INTERFACE.

Chuis encore d'accord avec Domi. En même temps, tu ne peux pas savoir si
ce sage précepte a été appliqué ici ou pas : la sortie "normale"
d'iptables -L (sans l'option bavarde -v) ne mentionne pas les
interfaces.
Ah oui, c'est vrai. Comme j'utilise systématiquement -nv effectivement

j'avais oublié ce détail.
Quoi qu'il en soit nous manquons d'info (comme d'hab).

Grosse carence AMA. Compte tenu de la mauvaise lisibilité de
la sortie complète, on préfèrera soit le listing du script de création
des règles, soit la sortie de la commande iptables-save qui a en plus
l'avantage de lister le contenu de toutes les tables d'un coup.
Oui l'un ou l'autre ou un schema ce serait bien préférable.

A part ça, tu penses que je suis complètement à côté de la plaque avec
mon histoire d'ARP ?
Ben, je t'avouerai que je n'ai pas compris ton histoire d'ARP.

Plus exactement je n'ai pas saisi ce qu'elle venait faire dans l'histoire.
Le routage fonctionne (ping vers l'extérieur) c'est donc que ARP fonctionne
sur les 2 interfaces eth0 et eth2.

Bah, à tous les coups il ya une politique DROP sur l'INPUT ...

db
--
email : usenet blas net

A part ça, tu penses que je suis complètement à côté de la plaque avec
mon histoire d'ARP ?

Ben, je t'avouerai que je n'ai pas compris ton histoire d'ARP.
Plus exactement je n'ai pas saisi ce qu'elle venait faire dans l'histoire.
Le routage fonctionne (ping vers l'extérieur) c'est donc que ARP fonctionne
sur les 2 interfaces eth0 et eth2.

Ça me paraissait pourtant simple : les adresses 192.168.254.253,
192.168.254.254, 192.168.255.253 et 192.168.255.254 n'appartiennent à
aucune interface dans leurs réseaux respectifs. En l'absence de tout
artifice, il est donc logique qu'il n'y ait pas de réponse aux requêtes
ARP pour ces adresses. Le paquet IP n'est même pas émis. Host
unreachable. Non ?

Pascal@plouf wrote:

Mouais, en général on place plutôt un proxyDNS qui est une application
dédiée à ce genre de boulot.

Chuis d'accord avec Domi. <pub> dnsmasq </pub>

pourquoi une regle iptables plutot qu'un cache DNS ? parce que j'ai pas
mal de truc a coté, donc si je peux me passer de l'administration d'un
service, c'est toujours bienvenu. Et en cas de defaillance, je peux me
planquer derriere le FAI (oui je suis lache et fourbe. et alors ? :-p)

Hum, première remarque : les règles se confectionnent PAR INTERFACE.

Chuis encore d'accord avec Domi. En même temps, tu ne peux pas savoir si
ce sage précepte a été appliqué ici ou pas : la sortie "normale"
d'iptables -L (sans l'option bavarde -v) ne mentionne pas les
interfaces. Grosse carence AMA. Compte tenu de la mauvaise lisibilité de
la sortie complète, on préfèrera soit le listing du script de création
des règles, soit la sortie de la commande iptables-save qui a en plus
l'avantage de lister le contenu de toutes les tables d'un coup.

j'ai pris la précaution de configurer par interface, je veux bien
admettre que je suis ignorant, mais bon quand meme ;-)

A part ça, tu penses que je suis complètement à côté de la plaque avec
mon histoire d'ARP ?

Ben en fait ca me parait tout a fait logique cette histoire d'ARP, je
suis convaincu que c'est la que se trouve la clé de mes problemes. En
tout cas chapeau, fallait y penser ...


Et désolé de donner si peu d'informations, mais je ne suis pas encore
tres familier de toutes les subtilités de iptables et consorts.
D'ailleurs hier a eu lieu mon premier cours de Réseaux. Ca te permet de
juger a quel point je "debute".

"Pascal@plouf" <pascal@plouf.invalid> wrote in message
news:ct0g2n$265j$1@biggoron.nerim.net

Par contre, pour joindre les adresses de DNS définies dans l'autre
sous-réseau, la machine émettrice sait grâce à sa table de routage
qu'elle doit passer par une passerelle. Dans ce cas, la requête ARP
porte sur l'adresse IP de la passerelle et non de l'adresse IP
destination. Le routeur répond à la requête ARP avec sa propre adresse
MAC, et la machine envoie le paquet IP avec l'adresse IP destination
réelle mais l'adresse MAC destination du routeur. Le routeur reçoit le
paquet et peut faire le masquerading.

Oui, ça me semble plausible.
Il suffit pour répondre à ce problème de mettre en place du proxy arp.
Ce problème est décrit là:
<http://www.lalitte.com/nat.htm>
Et plus précisemment là:
3.5 - Problèmes de routage liés à l'utilisation de la NAT statique
(proxy ARP)

Bref, il faut faire en sorte que le routeur réponde lui-même aux
requêtes ARP pour ces adresses IP inexistantes. Je pensais qu'on pouvait
le faire avec l'option "pub" de la commande arp :

$ arp -i eth0 -Ds 192.168.255.252 eth0 pub
et ainsi de suite.

Mais je n'ai pas réussi à le faire fonctionner avec mon propre routeur
bien que la commande soit acceptée. D'après mes recherches je ne suis
pas le seul. Tu auras peut-être plus de chance.

En faisant un alias IP sur les interfaces ça devrait aller (il faut
dans ce cas faire la nat avant le routage, sinon, on route sur notre
propre interface)
J'ai pas testé, mais sur le papier ça me semble correc !


--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

"Pascal@plouf" <pascal@plouf.invalid> wrote in message
news:ct0g2n$265j$1@biggoron.nerim.net

Par contre, pour joindre les adresses de DNS définies dans l'autre
sous-réseau, la machine émettrice sait grâce à sa table de routage
qu'elle doit passer par une passerelle. Dans ce cas, la requête ARP
porte sur l'adresse IP de la passerelle et non de l'adresse IP
destination. Le routeur répond à la requête ARP avec sa propre adresse
MAC, et la machine envoie le paquet IP avec l'adresse IP destination
réelle mais l'adresse MAC destination du routeur. Le routeur reçoit le
paquet et peut faire le masquerading.

Oui, ça me semble plausible.
Il suffit pour répondre à ce problème de mettre en place du proxy arp.
Ce problème est décrit là:
<http://www.lalitte.com/nat.htm>
Et plus précisemment là:
3.5 - Problèmes de routage liés à l'utilisation de la NAT statique
(proxy ARP)

Je devrais lire les FAQ avant de répondre, moi, ça m'éviterait de me
fatiguer à écrire des tartines ;-)

Bref, il faut faire en sorte que le routeur réponde lui-même aux
requêtes ARP pour ces adresses IP inexistantes. Je pensais qu'on pouvait
le faire avec l'option "pub" de la commande arp :

$ arp -i eth0 -Ds 192.168.255.252 eth0 pub
et ainsi de suite.

Mais je n'ai pas réussi à le faire fonctionner avec mon propre routeur
bien que la commande soit acceptée. D'après mes recherches je ne suis
pas le seul. Tu auras peut-être plus de chance.

En faisant un alias IP sur les interfaces ça devrait aller (il faut
dans ce cas faire la nat avant le routage, sinon, on route sur notre
propre interface)

Dans l'architecture de Netfilter, la NAT destination se fait avant la
décision de routage, donc c'est bon. Note que si ce n'était pas le cas,
la NAT donnerait de drôles de résultats !

J'ai pas testé, mais sur le papier ça me semble correc !

Y a pas de raison.

Pascal@plouf wrote:

Oui, ça me semble plausible.
Il suffit pour répondre à ce problème de mettre en place du proxy arp.
Ce problème est décrit là:
<http://www.lalitte.com/nat.htm>
Et plus précisemment là:
3.5 - Problèmes de routage liés à l'utilisation de la NAT statique
(proxy ARP)

Je devrais lire les FAQ avant de répondre, moi, ça m'éviterait de me
fatiguer à écrire des tartines ;-)

En faisant un alias IP sur les interfaces ça devrait aller (il faut
dans ce cas faire la nat avant le routage, sinon, on route sur notre
propre interface)

Dans l'architecture de Netfilter, la NAT destination se fait avant la
décision de routage, donc c'est bon. Note que si ce n'était pas le cas,
la NAT donnerait de drôles de résultats !

J'ai pas testé, mais sur le papier ça me semble correc !

Y a pas de raison.

ben encore merci de t'etre cassé la tete pour moi :-)
et merci pareil a domi