J'essaye de mettre en place une solution de routage avancé sur un réseau
(iproute2).
J'ai sur un Firewall (Linux Debian) 4 pattes :
- 2 vers deux connexions Internet du même fournisseur (2 IP fixes)
- 1 vers un réseau local
- 1 vers une DMZ
Voila ce que je souhaiterais faire :
- Le surf depuis le LAN passe par ppp1.
- Des personnes exterieur peuvent se connecter à la DMZ en entrant l'adresse
IP de ppp0.
- Accéder à la DMZ depuis le LAN
- Accéder au firewall en SSH depuis le LAN.
Les règles Iptables semblent correctement configurées.
Voici la solution que j'ai testée :
fichier /etc/iproute2/rt_tables :
#
# reserved values
#
255 local
254 main
253 default
0 unspec
99 table_local
104 table_eth4
# j'ajoute la passerelle fourni par le FAI dans la table table_eth4
ip route add table table_eth4 via 62.4.X.X dev ppp1
# j'ajoute le firewall lui même comme passerelle par défaut à la table
table_local
ip route add default via 192.1.2.254 table table_local
# règle permettant d'aller du LAN vers la DMZ
ip rule add from 192.1.2.0/24 to 192.1.254.0/24 table main pref 110
# règle permettant d'aller du LAN vers le firewall lui même
# autres solutions testées mais ne fonctionnant pas :
#- renvoyer vers la table main au lieu de table_local
#- renvoyer vers la table local au lieu de table_local
ip rule add from 192.1.2.0/24 to 192.1.2.254 table table_local pref 112
# règle qui renvoie les paquets du réseau local vers la table table_eth4 qui
elle renvoie vers ppp1
ip rule add from 192.1.2.0/24 to 0/0 table table_eth4 pref 113
Cette solution bloque l'accés au Firewall en SSH depuis le LAN, la règle
"from 192.1.2.0/24 to 0/0 table table_eth4" en est je pense la cause.
L'accés Internet depuis le LAN passe bien par ppp1 (vérifié par les
compteurs Iptables et par l'adresse IP) mais fonctionne aléatoirement
(certains sites Internet sont accesibles d'autres pas).
Quelle peut etre la cause des problèmes rencontrés ? et la solution (si il
y'en a une) ?
----- Original Message ----- From: "" Newsgroups: fr.comp.reseaux.ip Sent: Thursday, October 20, 2005 1:28 PM Subject: Re: Routage avancé (iproute2)
J'ai mis en place la solution hier soir, C'était tout bon sauf deux règles qui étaient inutiles :
Si je compte bien, tu as supprimé les règles de sortie vers internet des paquets émis par la passerelle elle-même. Elles sont effectivement inutiles pour le trafic entre DMZ, LAN et accès internet. Mais alors, à moins que la table 'main' comporte une route par défaut, la passerelle elle-même ne peut communiquer avec internet. Or c'est utile, ne serait-ce que pour répondre au ping ou renvoyer des messages d'erreur ICMP.
Justement, la passerelle étant un Firewall, on ne veut pas qu'elle ait l'accés à Internet.
Concernant les adresses IP de pairs PPP : si tu as deux accès Nerim Max, comme il y a deux LNS pour ce type d'accès, tu as une chance sur deux que tes deux connexions PPP soient terminées sur le même LNS et récupèrent la même adresse de pair.
C'est ce que j'ai remarqué, en gros, j'avais une fois sur deux la même IP.
J'ai mis en place la solution hier soir, C'était tout bon sauf deux
règles qui étaient inutiles :
Si je compte bien, tu as supprimé les règles de sortie vers internet des
paquets émis par la passerelle elle-même. Elles sont effectivement
inutiles pour le trafic entre DMZ, LAN et accès internet. Mais alors, à
moins que la table 'main' comporte une route par défaut, la passerelle
elle-même ne peut communiquer avec internet. Or c'est utile, ne serait-ce
que pour répondre au ping ou renvoyer des messages d'erreur ICMP.
Justement, la passerelle étant un Firewall, on ne veut pas qu'elle ait
l'accés à Internet.
Concernant les adresses IP de pairs PPP : si tu as deux accès Nerim Max,
comme il y a deux LNS pour ce type d'accès, tu as une chance sur deux que
tes deux connexions PPP soient terminées sur le même LNS et récupèrent la
même adresse de pair.
C'est ce que j'ai remarqué, en gros, j'avais une fois sur deux la même IP.
----- Original Message ----- From: "" Newsgroups: fr.comp.reseaux.ip Sent: Thursday, October 20, 2005 1:28 PM Subject: Re: Routage avancé (iproute2)
J'ai mis en place la solution hier soir, C'était tout bon sauf deux règles qui étaient inutiles :
Si je compte bien, tu as supprimé les règles de sortie vers internet des paquets émis par la passerelle elle-même. Elles sont effectivement inutiles pour le trafic entre DMZ, LAN et accès internet. Mais alors, à moins que la table 'main' comporte une route par défaut, la passerelle elle-même ne peut communiquer avec internet. Or c'est utile, ne serait-ce que pour répondre au ping ou renvoyer des messages d'erreur ICMP.
Justement, la passerelle étant un Firewall, on ne veut pas qu'elle ait l'accés à Internet.
Concernant les adresses IP de pairs PPP : si tu as deux accès Nerim Max, comme il y a deux LNS pour ce type d'accès, tu as une chance sur deux que tes deux connexions PPP soient terminées sur le même LNS et récupèrent la même adresse de pair.
C'est ce que j'ai remarqué, en gros, j'avais une fois sur deux la même IP.
Encore merci pour ton aide
Eric Masson
"Bruno C" writes:
Justement, la passerelle étant un Firewall, on ne veut pas qu'elle ait l'accés à Internet.
Euh, elle a accès au net, étant donné qu'elle fait office de passerelle...
-- Floriano veux détruire le ng , alors pour quoi ne pas le résusiter juste après sa destruction je m'explique il ne veux plus de ce groupe ben ont en recrée un nouveau du même nom -+- L in GNU - Neuneu fait des miracles -+-
Justement, la passerelle étant un Firewall, on ne veut pas qu'elle ait
l'accés à Internet.
Euh, elle a accès au net, étant donné qu'elle fait office de
passerelle...
--
Floriano veux détruire le ng , alors pour quoi ne pas le résusiter
juste après sa destruction je m'explique il ne veux plus de ce groupe
ben ont en recrée un nouveau du même nom
-+- L in GNU - Neuneu fait des miracles -+-
Justement, la passerelle étant un Firewall, on ne veut pas qu'elle ait l'accés à Internet.
Euh, elle a accès au net, étant donné qu'elle fait office de passerelle...
-- Floriano veux détruire le ng , alors pour quoi ne pas le résusiter juste après sa destruction je m'explique il ne veux plus de ce groupe ben ont en recrée un nouveau du même nom -+- L in GNU - Neuneu fait des miracles -+-
Bruno C
"Eric Masson" a écrit dans le message de news:
"Bruno C" writes:
Justement, la passerelle étant un Firewall, on ne veut pas qu'elle ait l'accés à Internet.
Euh, elle a accès au net, étant donné qu'elle fait office de passerelle...
Non, elle ne fait que se connecter et router, Iptables lui empeche toutes communication avec le net
"Eric Masson" <emss@free.fr> a écrit dans le message de news:
86k6g85qnx.fsf@srvbsdnanssv.interne.kisoft-services.com...
Justement, la passerelle étant un Firewall, on ne veut pas qu'elle ait l'accés à Internet.
Euh, elle a accès au net, étant donné qu'elle fait office de passerelle...
Non, elle ne fait que se connecter et router, Iptables lui empeche toutes communication avec le net
Eric Masson
"Bruno C" writes:
Non,
Mais si.
elle ne fait que se connecter et router
Elle est donc connectée au net et fait du forwarding.
Iptables lui empeche toutes communication avec le net
Non, sinon elle aurait du mal tant à se connecter qu'à forwarder quoi que ce soit.
Enfin, quel est l'intérêt profond de l'interdiction administrative de trafic depuis le fw vers le net ? Il peut être tout à fait intéressant de disposer d'outils de diagnostic sur un fw (ping, traceroute, entre autres) et cela n'est pas bien compliqué à implémenter avec Netfilter, sans pour cela ouvrir la machine à tous vents...
-- FTI: Internet est un nouveau média. Il n'est pas encore aussi fiable, que le téléphone ou la télévision. Si un problème est détecté, Wanadoo cherche toujours, à le résoudre dans les plus brefs délais. -+- Wanadoo in GNU -+- Le support sans faille du FAI sans support -+-
Elle est donc connectée au net et fait du forwarding.
Iptables lui empeche toutes communication avec le net
Non, sinon elle aurait du mal tant à se connecter qu'à forwarder quoi
que ce soit.
Enfin, quel est l'intérêt profond de l'interdiction administrative de
trafic depuis le fw vers le net ? Il peut être tout à fait intéressant
de disposer d'outils de diagnostic sur un fw (ping, traceroute, entre
autres) et cela n'est pas bien compliqué à implémenter avec Netfilter,
sans pour cela ouvrir la machine à tous vents...
--
FTI: Internet est un nouveau média. Il n'est pas encore aussi fiable,
que le téléphone ou la télévision. Si un problème est détecté, Wanadoo
cherche toujours, à le résoudre dans les plus brefs délais.
-+- Wanadoo in GNU -+- Le support sans faille du FAI sans support -+-
Elle est donc connectée au net et fait du forwarding.
Iptables lui empeche toutes communication avec le net
Non, sinon elle aurait du mal tant à se connecter qu'à forwarder quoi que ce soit.
Enfin, quel est l'intérêt profond de l'interdiction administrative de trafic depuis le fw vers le net ? Il peut être tout à fait intéressant de disposer d'outils de diagnostic sur un fw (ping, traceroute, entre autres) et cela n'est pas bien compliqué à implémenter avec Netfilter, sans pour cela ouvrir la machine à tous vents...
-- FTI: Internet est un nouveau média. Il n'est pas encore aussi fiable, que le téléphone ou la télévision. Si un problème est détecté, Wanadoo cherche toujours, à le résoudre dans les plus brefs délais. -+- Wanadoo in GNU -+- Le support sans faille du FAI sans support -+-
Bruno C
"Eric Masson" a écrit dans le message de news:
"Bruno C" writes:
Enfin, quel est l'intérêt profond de l'interdiction administrative de trafic depuis le fw vers le net ?
Parce qu'on ne s'en sert pas tout simplement.
Il peut être tout à fait intéressant de disposer d'outils de diagnostic sur un fw (ping, traceroute, entre autres) et cela n'est pas bien compliqué à implémenter avec Netfilter, sans pour cela ouvrir la machine à tous vents...
Ce que je sais c'est que moins on ouvre et plus on a de chance d'éviter les problèmes. Si un jour j'ai besoin de vérifier quelque chose depuis le Firewall, je n'aurai qu'a changer une ou deux règles d'Iptables et pareil dans l'autre sens une fois la vérification finie.
"Eric Masson" <emss@free.fr> a écrit dans le message de news:
86fyqw5mj8.fsf@srvbsdnanssv.interne.kisoft-services.com...
Enfin, quel est l'intérêt profond de l'interdiction administrative de
trafic depuis le fw vers le net ?
Parce qu'on ne s'en sert pas tout simplement.
Il peut être tout à fait intéressant
de disposer d'outils de diagnostic sur un fw (ping, traceroute, entre
autres) et cela n'est pas bien compliqué à implémenter avec Netfilter,
sans pour cela ouvrir la machine à tous vents...
Ce que je sais c'est que moins on ouvre et plus on a de chance d'éviter les
problèmes.
Si un jour j'ai besoin de vérifier quelque chose depuis le Firewall, je
n'aurai qu'a changer une ou deux règles d'Iptables et pareil dans l'autre
sens une fois la vérification finie.
Enfin, quel est l'intérêt profond de l'interdiction administrative de trafic depuis le fw vers le net ?
Parce qu'on ne s'en sert pas tout simplement.
Il peut être tout à fait intéressant de disposer d'outils de diagnostic sur un fw (ping, traceroute, entre autres) et cela n'est pas bien compliqué à implémenter avec Netfilter, sans pour cela ouvrir la machine à tous vents...
Ce que je sais c'est que moins on ouvre et plus on a de chance d'éviter les problèmes. Si un jour j'ai besoin de vérifier quelque chose depuis le Firewall, je n'aurai qu'a changer une ou deux règles d'Iptables et pareil dans l'autre sens une fois la vérification finie.
Eric Masson
"Bruno C" writes:
Ce que je sais c'est que moins on ouvre et plus on a de chance d'éviter les problèmes.
Ça se défend.
Si un jour j'ai besoin de vérifier quelque chose depuis le Firewall, je n'aurai qu'a changer une ou deux règles d'Iptables et pareil dans l'autre sens une fois la vérification finie.
C'est là qu'il ne faut pas se rater...
-- Je propose que chacun de nous expose le problème (et dénoncent les fufeurs, cf liste des votants, ceux qui ont voté NNO sont les fufeurs) à son FAI. -+- Rocou In GNU - Comment tu écris Kommandantur ? -+-
Ce que je sais c'est que moins on ouvre et plus on a de chance
d'éviter les problèmes.
Ça se défend.
Si un jour j'ai besoin de vérifier quelque chose depuis le Firewall, je
n'aurai qu'a changer une ou deux règles d'Iptables et pareil dans l'autre
sens une fois la vérification finie.
C'est là qu'il ne faut pas se rater...
--
Je propose que chacun de nous expose le problème (et dénoncent les
fufeurs, cf liste des votants, ceux qui ont voté NNO sont les fufeurs)
à son FAI.
-+- Rocou In GNU - Comment tu écris Kommandantur ? -+-
Ce que je sais c'est que moins on ouvre et plus on a de chance d'éviter les problèmes.
Ça se défend.
Si un jour j'ai besoin de vérifier quelque chose depuis le Firewall, je n'aurai qu'a changer une ou deux règles d'Iptables et pareil dans l'autre sens une fois la vérification finie.
C'est là qu'il ne faut pas se rater...
-- Je propose que chacun de nous expose le problème (et dénoncent les fufeurs, cf liste des votants, ceux qui ont voté NNO sont les fufeurs) à son FAI. -+- Rocou In GNU - Comment tu écris Kommandantur ? -+-
Bruno C
"Eric Masson" a écrit dans le message de news:
"Bruno C" writes:
Si un jour j'ai besoin de vérifier quelque chose depuis le Firewall, je n'aurai qu'a changer une ou deux règles d'Iptables et pareil dans l'autre sens une fois la vérification finie.
C'est là qu'il ne faut pas se rater...
Il sufit de mettre les règles en commentaire dans le script qui va bien et de les décommenter au moment voulu.
"Eric Masson" <emss@free.fr> a écrit dans le message de news:
86br1k5li1.fsf@srvbsdnanssv.interne.kisoft-services.com...
Si un jour j'ai besoin de vérifier quelque chose depuis le Firewall, je
n'aurai qu'a changer une ou deux règles d'Iptables et pareil dans l'autre
sens une fois la vérification finie.
C'est là qu'il ne faut pas se rater...
Il sufit de mettre les règles en commentaire dans le script qui va bien et
de les décommenter au moment voulu.
Si un jour j'ai besoin de vérifier quelque chose depuis le Firewall, je n'aurai qu'a changer une ou deux règles d'Iptables et pareil dans l'autre sens une fois la vérification finie.
C'est là qu'il ne faut pas se rater...
Il sufit de mettre les règles en commentaire dans le script qui va bien et de les décommenter au moment voulu.
Pascal
Justement, la passerelle étant un Firewall, on ne veut pas qu'elle ait l'accés à Internet.
C'est mal, car cela viole le protocole IP. Avant d'être un firewall, la passerelle est avant tout un routeur, ce qui implique un minimum de communication avec le reste du monde à des fins de diagnostic et signalisation (messages ICMP). Laisser passer cette signalisation normale ne signifie pas ouvrir quoi que ce soit.
Euh, elle a accès au net, étant donné qu'elle fait office de passerelle...
Non, elle ne fait que se connecter et router, Iptables lui empeche toutes communication avec le net
Du genre qui bloque tout ce qui passe par les chaînes INPUT et OUTPUT sur les interfaces internet ? D'accord, c'est du filtrage, et comme tu l'as écrit plus haut c'est le rôle d'iptables, et pas celui des règles de routage.
Justement, la passerelle étant un Firewall, on ne veut pas qu'elle ait
l'accés à Internet.
C'est mal, car cela viole le protocole IP. Avant d'être un firewall, la
passerelle est avant tout un routeur, ce qui implique un minimum de
communication avec le reste du monde à des fins de diagnostic et
signalisation (messages ICMP). Laisser passer cette signalisation
normale ne signifie pas ouvrir quoi que ce soit.
Euh, elle a accès au net, étant donné qu'elle fait office de
passerelle...
Non, elle ne fait que se connecter et router, Iptables lui empeche toutes
communication avec le net
Du genre qui bloque tout ce qui passe par les chaînes INPUT et OUTPUT
sur les interfaces internet ? D'accord, c'est du filtrage, et comme tu
l'as écrit plus haut c'est le rôle d'iptables, et pas celui des règles
de routage.
Justement, la passerelle étant un Firewall, on ne veut pas qu'elle ait l'accés à Internet.
C'est mal, car cela viole le protocole IP. Avant d'être un firewall, la passerelle est avant tout un routeur, ce qui implique un minimum de communication avec le reste du monde à des fins de diagnostic et signalisation (messages ICMP). Laisser passer cette signalisation normale ne signifie pas ouvrir quoi que ce soit.
Euh, elle a accès au net, étant donné qu'elle fait office de passerelle...
Non, elle ne fait que se connecter et router, Iptables lui empeche toutes communication avec le net
Du genre qui bloque tout ce qui passe par les chaînes INPUT et OUTPUT sur les interfaces internet ? D'accord, c'est du filtrage, et comme tu l'as écrit plus haut c'est le rôle d'iptables, et pas celui des règles de routage.
Pascal
Iptables lui empeche toutes communication avec le net
Non, sinon elle aurait du mal tant à se connecter qu'à forwarder quoi que ce soit.
La connexion est établie au niveau 2 (liaison), iptables n'a aucune influence là-dessus. Quant au forwarding, il ne traverse que la chaîne FORWARD, donc on peut bloquer le trafic émis ou reçu localement dans les chaînes INPUT et OUTPUT sans perturber le forwarding.
Iptables lui empeche toutes communication avec le net
Non, sinon elle aurait du mal tant à se connecter qu'à forwarder quoi
que ce soit.
La connexion est établie au niveau 2 (liaison), iptables n'a aucune
influence là-dessus. Quant au forwarding, il ne traverse que la chaîne
FORWARD, donc on peut bloquer le trafic émis ou reçu localement dans les
chaînes INPUT et OUTPUT sans perturber le forwarding.
Iptables lui empeche toutes communication avec le net
Non, sinon elle aurait du mal tant à se connecter qu'à forwarder quoi que ce soit.
La connexion est établie au niveau 2 (liaison), iptables n'a aucune influence là-dessus. Quant au forwarding, il ne traverse que la chaîne FORWARD, donc on peut bloquer le trafic émis ou reçu localement dans les chaînes INPUT et OUTPUT sans perturber le forwarding.
Eric Masson
"" writes:
La connexion est établie au niveau 2 (liaison), iptables n'a aucune influence là-dessus.
Je parle de lien au niveau ip.
Quant au forwarding, il ne traverse que la chaîne FORWARD, donc on peut bloquer le trafic émis ou reçu localement dans les chaînes INPUT et OUTPUT sans perturber le forwarding.
Oui et ?
Ou est la contradiction avec ce que j'ai écrit ?
-- salut Lolo!!! Alors les vacances, c'était bien? Faut que j'te raconte ce qui m'est arrivé samedi -+- AC in: GNU - Allo lolo, pourquois tu GNUtes ? -+-
La connexion est établie au niveau 2 (liaison), iptables n'a aucune
influence là-dessus.
Je parle de lien au niveau ip.
Quant au forwarding, il ne traverse que la chaîne FORWARD, donc on
peut bloquer le trafic émis ou reçu localement dans les chaînes INPUT
et OUTPUT sans perturber le forwarding.
Oui et ?
Ou est la contradiction avec ce que j'ai écrit ?
--
salut Lolo!!!
Alors les vacances, c'était bien?
Faut que j'te raconte ce qui m'est arrivé samedi
-+- AC in: GNU - Allo lolo, pourquois tu GNUtes ? -+-
La connexion est établie au niveau 2 (liaison), iptables n'a aucune influence là-dessus.
Je parle de lien au niveau ip.
Quant au forwarding, il ne traverse que la chaîne FORWARD, donc on peut bloquer le trafic émis ou reçu localement dans les chaînes INPUT et OUTPUT sans perturber le forwarding.
Oui et ?
Ou est la contradiction avec ce que j'ai écrit ?
-- salut Lolo!!! Alors les vacances, c'était bien? Faut que j'te raconte ce qui m'est arrivé samedi -+- AC in: GNU - Allo lolo, pourquois tu GNUtes ? -+-
