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) ?
La connexion est établie au niveau 2 (liaison), iptables n'a aucune influence là-dessus.
Je parle de lien au niveau ip.
Reprenons. Tu as écrit en réponse à Bruno :
Iptables lui empeche toutes communication avec le net
Non, sinon elle aurait du mal tant à se connecter [...]
L'établissement d'IP sur PPP proprement dit (négociation IPCP) se passe au niveau liaison sans faire intervenir de paquets IP. IPCP ne peut être bloqué par iptables (sauf encapsulation de PPP dans un protocole IP, mais c'est une autre histoire). Le fait de bloquer tout le trafic IP avec iptables, par exemple :
iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP iptables -F
et rien d'autre n'empêche pas l'établissement du lien au niveau IP.
[Note : n'essayez pas ça chez vous, votre machine risque de beaucoup moins bien marcher]
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 ?
Tu as répondu à Bruno :
Iptables lui empeche toutes communication avec le net
Non, sinon elle aurait du mal [...] à forwarder quoi que ce soit.
Je t'ai montré qu'au contraire on peut bloquer les communications IP entre la passerelle elle-même et l'extérieur tout en forwardant les communications IP entre ses différentes interfaces.
La connexion est établie au niveau 2 (liaison), iptables n'a aucune
influence là-dessus.
Je parle de lien au niveau ip.
Reprenons. Tu as écrit en réponse à Bruno :
Iptables lui empeche toutes communication avec le net
Non, sinon elle aurait du mal tant à se connecter [...]
L'établissement d'IP sur PPP proprement dit (négociation IPCP) se passe
au niveau liaison sans faire intervenir de paquets IP. IPCP ne peut être
bloqué par iptables (sauf encapsulation de PPP dans un protocole IP,
mais c'est une autre histoire). Le fait de bloquer tout le trafic IP
avec iptables, par exemple :
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -F
et rien d'autre n'empêche pas l'établissement du lien au niveau IP.
[Note : n'essayez pas ça chez vous, votre machine risque de beaucoup
moins bien marcher]
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 ?
Tu as répondu à Bruno :
Iptables lui empeche toutes communication avec le net
Non, sinon elle aurait du mal [...] à forwarder quoi que ce soit.
Je t'ai montré qu'au contraire on peut bloquer les communications IP
entre la passerelle elle-même et l'extérieur tout en forwardant les
communications IP entre ses différentes interfaces.
La connexion est établie au niveau 2 (liaison), iptables n'a aucune influence là-dessus.
Je parle de lien au niveau ip.
Reprenons. Tu as écrit en réponse à Bruno :
Iptables lui empeche toutes communication avec le net
Non, sinon elle aurait du mal tant à se connecter [...]
L'établissement d'IP sur PPP proprement dit (négociation IPCP) se passe au niveau liaison sans faire intervenir de paquets IP. IPCP ne peut être bloqué par iptables (sauf encapsulation de PPP dans un protocole IP, mais c'est une autre histoire). Le fait de bloquer tout le trafic IP avec iptables, par exemple :
iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP iptables -F
et rien d'autre n'empêche pas l'établissement du lien au niveau IP.
[Note : n'essayez pas ça chez vous, votre machine risque de beaucoup moins bien marcher]
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 ?
Tu as répondu à Bruno :
Iptables lui empeche toutes communication avec le net
Non, sinon elle aurait du mal [...] à forwarder quoi que ce soit.
Je t'ai montré qu'au contraire on peut bloquer les communications IP entre la passerelle elle-même et l'extérieur tout en forwardant les communications IP entre ses différentes interfaces.
Eric Masson
"" writes:
Reprenons. Tu as écrit en réponse à Bruno :
Rhah, au temps pour moi, je viens de voir en remontant au premier post qu'il utilisait effectivement un lien ppp, je n'ai rien dit.
-- WD> On ne discute pas avec les brouettes, on les pousse. VD> Tiens il est de mauvais poil. Vous n'y êtes pas du tout, je pêche le thon. -+- WoD in <http://www.le-gnu.net> - Et thon sur thon ça fait tâche -+-
Rhah, au temps pour moi, je viens de voir en remontant au premier post
qu'il utilisait effectivement un lien ppp, je n'ai rien dit.
--
WD> On ne discute pas avec les brouettes, on les pousse.
VD> Tiens il est de mauvais poil.
Vous n'y êtes pas du tout, je pêche le thon.
-+- WoD in <http://www.le-gnu.net> - Et thon sur thon ça fait tâche -+-
Rhah, au temps pour moi, je viens de voir en remontant au premier post qu'il utilisait effectivement un lien ppp, je n'ai rien dit.
-- WD> On ne discute pas avec les brouettes, on les pousse. VD> Tiens il est de mauvais poil. Vous n'y êtes pas du tout, je pêche le thon. -+- WoD in <http://www.le-gnu.net> - Et thon sur thon ça fait tâche -+-
Pascal
Rhah, au temps pour moi, je viens de voir en remontant au premier post qu'il utilisait effectivement un lien ppp, je n'ai rien dit.
Juste par curiosité, ça aurait changé quoi si la couche liaison avait été autre chose que PPP ?
Rhah, au temps pour moi, je viens de voir en remontant au premier post
qu'il utilisait effectivement un lien ppp, je n'ai rien dit.
Juste par curiosité, ça aurait changé quoi si la couche liaison avait
été autre chose que PPP ?
Rhah, au temps pour moi, je viens de voir en remontant au premier post qu'il utilisait effectivement un lien ppp, je n'ai rien dit.
Juste par curiosité, ça aurait changé quoi si la couche liaison avait été autre chose que PPP ?
Eric Masson
"" writes:
Juste par curiosité, ça aurait changé quoi si la couche liaison avait été autre chose que PPP ?
Attends, je reprend ton post précédent, j'ai répondu trop vite (midi, obligations familiales toussa)
L'établissement d'IP sur PPP proprement dit (négociation IPCP) se passe au niveau liaison sans faire intervenir de paquets IP. IPCP ne peut être bloqué par iptables (sauf encapsulation de PPP dans un protocole IP, mais c'est une autre histoire). Le fait de bloquer tout le trafic IP avec iptables, par exemple :
iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP iptables -F
et rien d'autre n'empêche pas l'établissement du lien au niveau IP.
Tu n'établis pas de lien ip mais une session ppp qui est fonctionnellement équivalente à un lien niveau 2, et effectivement Netfilter n'y peut rien.
Je t'ai montré qu'au contraire on peut bloquer les communications IP entre la passerelle elle-même et l'extérieur tout en forwardant les communications IP entre ses différentes interfaces.
Non, le fait que la règle sur la chaine FORWARD ne soit pas drop fait que la machine dispose bel et bien d'une connectivité au niveau ip.
Je crois qu'il y a plus un problème de définition sur ce chacun de nous recouvre sous l'expression "absence de connectivité ip".
-- je pense pas que ce soit toi....tu es bien trop vicieux pour agir de cette façon. Toi ton genre, c'est plus de contacter banque direct en esperant que je n'auras pas mes cadeaux de parrainages!!!!! -+- JD in <http://www.le-gnu.net> : Petit neuneu Noël -+-
Juste par curiosité, ça aurait changé quoi si la couche liaison avait
été autre chose que PPP ?
Attends, je reprend ton post précédent, j'ai répondu trop vite (midi,
obligations familiales toussa)
L'établissement d'IP sur PPP proprement dit (négociation IPCP) se passe
au niveau liaison sans faire intervenir de paquets IP. IPCP ne peut être
bloqué par iptables (sauf encapsulation de PPP dans un protocole IP,
mais c'est une autre histoire). Le fait de bloquer tout le trafic IP
avec iptables, par exemple :
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -F
et rien d'autre n'empêche pas l'établissement du lien au niveau IP.
Tu n'établis pas de lien ip mais une session ppp qui est
fonctionnellement équivalente à un lien niveau 2, et effectivement
Netfilter n'y peut rien.
Je t'ai montré qu'au contraire on peut bloquer les communications IP
entre la passerelle elle-même et l'extérieur tout en forwardant les
communications IP entre ses différentes interfaces.
Non, le fait que la règle sur la chaine FORWARD ne soit pas drop fait
que la machine dispose bel et bien d'une connectivité au niveau ip.
Je crois qu'il y a plus un problème de définition sur ce chacun de nous
recouvre sous l'expression "absence de connectivité ip".
--
je pense pas que ce soit toi....tu es bien trop vicieux pour agir de
cette façon. Toi ton genre, c'est plus de contacter banque direct en
esperant que je n'auras pas mes cadeaux de parrainages!!!!!
-+- JD in <http://www.le-gnu.net> : Petit neuneu Noël -+-
Juste par curiosité, ça aurait changé quoi si la couche liaison avait été autre chose que PPP ?
Attends, je reprend ton post précédent, j'ai répondu trop vite (midi, obligations familiales toussa)
L'établissement d'IP sur PPP proprement dit (négociation IPCP) se passe au niveau liaison sans faire intervenir de paquets IP. IPCP ne peut être bloqué par iptables (sauf encapsulation de PPP dans un protocole IP, mais c'est une autre histoire). Le fait de bloquer tout le trafic IP avec iptables, par exemple :
iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP iptables -F
et rien d'autre n'empêche pas l'établissement du lien au niveau IP.
Tu n'établis pas de lien ip mais une session ppp qui est fonctionnellement équivalente à un lien niveau 2, et effectivement Netfilter n'y peut rien.
Je t'ai montré qu'au contraire on peut bloquer les communications IP entre la passerelle elle-même et l'extérieur tout en forwardant les communications IP entre ses différentes interfaces.
Non, le fait que la règle sur la chaine FORWARD ne soit pas drop fait que la machine dispose bel et bien d'une connectivité au niveau ip.
Je crois qu'il y a plus un problème de définition sur ce chacun de nous recouvre sous l'expression "absence de connectivité ip".
-- je pense pas que ce soit toi....tu es bien trop vicieux pour agir de cette façon. Toi ton genre, c'est plus de contacter banque direct en esperant que je n'auras pas mes cadeaux de parrainages!!!!! -+- JD in <http://www.le-gnu.net> : Petit neuneu Noël -+-
Pascal
L'établissement d'IP sur PPP proprement dit (négociation IPCP) se passe au niveau liaison sans faire intervenir de paquets IP. IPCP ne peut être bloqué par iptables (sauf encapsulation de PPP dans un protocole IP, mais c'est une autre histoire). Le fait de bloquer tout le trafic IP avec iptables [...] n'empêche pas l'établissement du lien au niveau IP.
Tu n'établis pas de lien ip mais une session ppp qui est fonctionnellement équivalente à un lien niveau 2, et effectivement Netfilter n'y peut rien.
Et la négociation IPCP, la fourniture des adresses IP locale, distante et de DNS, la configuration IP de l'interface PPP et la création des routes associées, c'est rien que du niveau 2 ?
Je t'ai montré qu'au contraire on peut bloquer les communications IP entre la passerelle elle-même et l'extérieur tout en forwardant les communications IP entre ses différentes interfaces.
Non, le fait que la règle sur la chaine FORWARD ne soit pas drop fait que la machine dispose bel et bien d'une connectivité au niveau ip.
Je crois qu'il y a plus un problème de définition sur ce chacun de nous recouvre sous l'expression "absence de connectivité ip".
Je viens de relire le fil et sauf erreur personne n'avait parlé de "connectivité" jusqu'ici. Le débat ne porte pas là-dessus mais sur la capacité de la passerelle à communiquer avec l'extérieur. Dans la mesure où ses propres processus locaux ne peuvent pas émettre ni recevoir de trafic IP, je considère qu'elle ne peut communiquer avec l'extérieur.
L'établissement d'IP sur PPP proprement dit (négociation IPCP) se passe
au niveau liaison sans faire intervenir de paquets IP. IPCP ne peut être
bloqué par iptables (sauf encapsulation de PPP dans un protocole IP,
mais c'est une autre histoire). Le fait de bloquer tout le trafic IP
avec iptables [...] n'empêche pas l'établissement du lien au niveau IP.
Tu n'établis pas de lien ip mais une session ppp qui est
fonctionnellement équivalente à un lien niveau 2, et effectivement
Netfilter n'y peut rien.
Et la négociation IPCP, la fourniture des adresses IP locale, distante
et de DNS, la configuration IP de l'interface PPP et la création des
routes associées, c'est rien que du niveau 2 ?
Je t'ai montré qu'au contraire on peut bloquer les communications IP
entre la passerelle elle-même et l'extérieur tout en forwardant les
communications IP entre ses différentes interfaces.
Non, le fait que la règle sur la chaine FORWARD ne soit pas drop fait
que la machine dispose bel et bien d'une connectivité au niveau ip.
Je crois qu'il y a plus un problème de définition sur ce chacun de nous
recouvre sous l'expression "absence de connectivité ip".
Je viens de relire le fil et sauf erreur personne n'avait parlé de
"connectivité" jusqu'ici. Le débat ne porte pas là-dessus mais sur la
capacité de la passerelle à communiquer avec l'extérieur. Dans la mesure
où ses propres processus locaux ne peuvent pas émettre ni recevoir de
trafic IP, je considère qu'elle ne peut communiquer avec l'extérieur.
L'établissement d'IP sur PPP proprement dit (négociation IPCP) se passe au niveau liaison sans faire intervenir de paquets IP. IPCP ne peut être bloqué par iptables (sauf encapsulation de PPP dans un protocole IP, mais c'est une autre histoire). Le fait de bloquer tout le trafic IP avec iptables [...] n'empêche pas l'établissement du lien au niveau IP.
Tu n'établis pas de lien ip mais une session ppp qui est fonctionnellement équivalente à un lien niveau 2, et effectivement Netfilter n'y peut rien.
Et la négociation IPCP, la fourniture des adresses IP locale, distante et de DNS, la configuration IP de l'interface PPP et la création des routes associées, c'est rien que du niveau 2 ?
Je t'ai montré qu'au contraire on peut bloquer les communications IP entre la passerelle elle-même et l'extérieur tout en forwardant les communications IP entre ses différentes interfaces.
Non, le fait que la règle sur la chaine FORWARD ne soit pas drop fait que la machine dispose bel et bien d'une connectivité au niveau ip.
Je crois qu'il y a plus un problème de définition sur ce chacun de nous recouvre sous l'expression "absence de connectivité ip".
Je viens de relire le fil et sauf erreur personne n'avait parlé de "connectivité" jusqu'ici. Le débat ne porte pas là-dessus mais sur la capacité de la passerelle à communiquer avec l'extérieur. Dans la mesure où ses propres processus locaux ne peuvent pas émettre ni recevoir de trafic IP, je considère qu'elle ne peut communiquer avec l'extérieur.
Eric Masson
"" writes:
Et la négociation IPCP, la fourniture des adresses IP locale, distante et de DNS, la configuration IP de l'interface PPP et la création des routes associées, c'est rien que du niveau 2 ?
Ben, c'est pas moi qui le dit, mais la rfc1661.
Dans le cadre de pppoe, il y a une étape d'encapsulation en plus, définie dans la rfc2516, mais cela n'en fait pas un protocole de niveau 3.
Je viens de relire le fil et sauf erreur personne n'avait parlé de "connectivité" jusqu'ici.
Le débat ne porte pas là-dessus mais sur la capacité de la passerelle à communiquer avec l'extérieur. Dans la mesure où ses propres processus locaux ne peuvent pas émettre ni recevoir de trafic IP, je considère qu'elle ne peut communiquer avec l'extérieur.
Modulo les bugs d'implémentation de la pile ip et du filtre, sans chercher un contournement quelconque on est d'accord.
Par contre en cas de trafic hostile, il reste tout à fait possible de communiquer avec un processus s'exécutant sur la machine (via un canal caché, la passerelle forwarde le trafic et peut donc l'inspecter et/ou le modifier) ou de crasher celle-ci (bug exploitable dans la pile ip)
Mais il est clair que l'on ne parlait pas vraiment de la même chose, tout en utilisant un vocabulaire proche, ce qui n'aide pas :)
-- SC> s'occupe de le transmettre au bon endroite. TL> Tiens c'est l'accent de quelle région ça ? De la fatiguie, un petit pays situé au sud de "nuit blanche" -+- SC in: <http://www.le-gnu.net> - Oh douce nuit... -+-
Et la négociation IPCP, la fourniture des adresses IP locale, distante
et de DNS, la configuration IP de l'interface PPP et la création des
routes associées, c'est rien que du niveau 2 ?
Ben, c'est pas moi qui le dit, mais la rfc1661.
Dans le cadre de pppoe, il y a une étape d'encapsulation en plus,
définie dans la rfc2516, mais cela n'en fait pas un protocole de niveau
3.
Je viens de relire le fil et sauf erreur personne n'avait parlé de
"connectivité" jusqu'ici.
Le débat ne porte pas là-dessus mais sur la capacité de la passerelle
à communiquer avec l'extérieur.
Dans la mesure où ses propres processus locaux ne peuvent pas émettre
ni recevoir de trafic IP, je considère qu'elle ne peut communiquer avec
l'extérieur.
Modulo les bugs d'implémentation de la pile ip et du filtre, sans
chercher un contournement quelconque on est d'accord.
Par contre en cas de trafic hostile, il reste tout à fait possible de
communiquer avec un processus s'exécutant sur la machine (via un canal
caché, la passerelle forwarde le trafic et peut donc l'inspecter et/ou
le modifier) ou de crasher celle-ci (bug exploitable dans la pile ip)
Mais il est clair que l'on ne parlait pas vraiment de la même chose,
tout en utilisant un vocabulaire proche, ce qui n'aide pas :)
--
SC> s'occupe de le transmettre au bon endroite.
TL> Tiens c'est l'accent de quelle région ça ?
De la fatiguie, un petit pays situé au sud de "nuit blanche"
-+- SC in: <http://www.le-gnu.net> - Oh douce nuit... -+-
Et la négociation IPCP, la fourniture des adresses IP locale, distante et de DNS, la configuration IP de l'interface PPP et la création des routes associées, c'est rien que du niveau 2 ?
Ben, c'est pas moi qui le dit, mais la rfc1661.
Dans le cadre de pppoe, il y a une étape d'encapsulation en plus, définie dans la rfc2516, mais cela n'en fait pas un protocole de niveau 3.
Je viens de relire le fil et sauf erreur personne n'avait parlé de "connectivité" jusqu'ici.
Le débat ne porte pas là-dessus mais sur la capacité de la passerelle à communiquer avec l'extérieur. Dans la mesure où ses propres processus locaux ne peuvent pas émettre ni recevoir de trafic IP, je considère qu'elle ne peut communiquer avec l'extérieur.
Modulo les bugs d'implémentation de la pile ip et du filtre, sans chercher un contournement quelconque on est d'accord.
Par contre en cas de trafic hostile, il reste tout à fait possible de communiquer avec un processus s'exécutant sur la machine (via un canal caché, la passerelle forwarde le trafic et peut donc l'inspecter et/ou le modifier) ou de crasher celle-ci (bug exploitable dans la pile ip)
Mais il est clair que l'on ne parlait pas vraiment de la même chose, tout en utilisant un vocabulaire proche, ce qui n'aide pas :)
-- SC> s'occupe de le transmettre au bon endroite. TL> Tiens c'est l'accent de quelle région ça ? De la fatiguie, un petit pays situé au sud de "nuit blanche" -+- SC in: <http://www.le-gnu.net> - Oh douce nuit... -+-
