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) ?
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
[dessin tout cassé]
Ce n'est pas une bonne idée de composer des dessins ASCII avec une police à taille proportionnelle.
[...]
Quelle usine à gaz ! Ce ne serait pas plus simple de gérer les autorisations par des règles iptables plutôt que par le routage ?
A part ça, ça pourrait aider si tu donnais la liste des politiques de routage et des routes de toutes les tables.
$ ip rule $ ip -4 route list table all
PS : 192.1.x.y n'est pas une adresse privée.
Salut,
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
[dessin tout cassé]
Ce n'est pas une bonne idée de composer des dessins ASCII avec une
police à taille proportionnelle.
[...]
Quelle usine à gaz ! Ce ne serait pas plus simple de gérer les
autorisations par des règles iptables plutôt que par le routage ?
A part ça, ça pourrait aider si tu donnais la liste des politiques de
routage et des routes de toutes les tables.
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
[dessin tout cassé]
Ce n'est pas une bonne idée de composer des dessins ASCII avec une police à taille proportionnelle.
[...]
Quelle usine à gaz ! Ce ne serait pas plus simple de gérer les autorisations par des règles iptables plutôt que par le routage ?
A part ça, ça pourrait aider si tu donnais la liste des politiques de routage et des routes de toutes les tables.
$ ip rule $ ip -4 route list table all
PS : 192.1.x.y n'est pas une adresse privée.
Bruno C
"" a écrit dans le message de news: dj2mu4$254q$
Salut,
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
[dessin tout cassé]
Ce n'est pas une bonne idée de composer des dessins ASCII avec une police à taille proportionnelle.
Désolé si ça ne rend pas, y-a t-il un moyen pour que le schéma puisse se voir ?
[...]
Quelle usine à gaz ! Ce ne serait pas plus simple de gérer les autorisations par des règles iptables plutôt que par le routage ?
D'après moi, iptables ne sert qu'a gérer le filtrage et non le routage, peut etre ai-je manqué un aspect du programme. Si il y a un moyen de dire a un paquet venant de 192.1.X.X de passer par la connexion ppp1 et non ppp0 grace à IPtables, je suis preneur.
A part ça, ça pourrait aider si tu donnais la liste des politiques de routage et des routes de toutes les tables.
$ ip rule $ ip -4 route list table all
PS : 192.1.x.y n'est pas une adresse privée.
Je sais que ce n'est pas une adresse privée mais pour une raison inconnue de ma part, le réseau local a été fait de cette façon.
merci
"Pascal@plouf" <boite-a-spam@plouf.fr.eu.org> a écrit dans le message de
news: dj2mu4$254q$1@biggoron.nerim.net...
Salut,
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
[dessin tout cassé]
Ce n'est pas une bonne idée de composer des dessins ASCII avec une police
à taille proportionnelle.
Désolé si ça ne rend pas, y-a t-il un moyen pour que le schéma puisse se
voir ?
[...]
Quelle usine à gaz ! Ce ne serait pas plus simple de gérer les
autorisations par des règles iptables plutôt que par le routage ?
D'après moi, iptables ne sert qu'a gérer le filtrage et non le routage, peut
etre ai-je manqué un aspect du programme.
Si il y a un moyen de dire a un paquet venant de 192.1.X.X de passer par la
connexion ppp1 et non ppp0 grace à IPtables, je suis preneur.
A part ça, ça pourrait aider si tu donnais la liste des politiques de
routage et des routes de toutes les tables.
$ ip rule
$ ip -4 route list table all
PS : 192.1.x.y n'est pas une adresse privée.
Je sais que ce n'est pas une adresse privée mais pour une raison inconnue de
ma part, le réseau local a été fait de cette façon.
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
[dessin tout cassé]
Ce n'est pas une bonne idée de composer des dessins ASCII avec une police à taille proportionnelle.
Désolé si ça ne rend pas, y-a t-il un moyen pour que le schéma puisse se voir ?
[...]
Quelle usine à gaz ! Ce ne serait pas plus simple de gérer les autorisations par des règles iptables plutôt que par le routage ?
D'après moi, iptables ne sert qu'a gérer le filtrage et non le routage, peut etre ai-je manqué un aspect du programme. Si il y a un moyen de dire a un paquet venant de 192.1.X.X de passer par la connexion ppp1 et non ppp0 grace à IPtables, je suis preneur.
A part ça, ça pourrait aider si tu donnais la liste des politiques de routage et des routes de toutes les tables.
$ ip rule $ ip -4 route list table all
PS : 192.1.x.y n'est pas une adresse privée.
Je sais que ce n'est pas une adresse privée mais pour une raison inconnue de ma part, le réseau local a été fait de cette façon.
merci
Snarf
On 2005-10-18, wrote:
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 [dessin tout cassé]
Ce n'est pas une bonne idée de composer des dessins ASCII avec une police à taille proportionnelle. ça marche tres bien bien son truc avec un client nntp qui se respecte ;)
non? le troll s'est vu ? bon ok.. -> []
Snarf
-- "L'IRQ a été inventée par Murphy ; le partage des IRQ, par quelqu'un voulant le defier " echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
On 2005-10-18, Pascal@plouf <boite-a-spam@plouf.fr.eu.org> wrote:
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
[dessin tout cassé]
Ce n'est pas une bonne idée de composer des dessins ASCII avec une
police à taille proportionnelle.
ça marche tres bien bien son truc avec un client nntp qui se respecte ;)
non? le troll s'est vu ? bon ok.. -> []
Snarf
--
"L'IRQ a été inventée par Murphy ; le partage des IRQ, par quelqu'un
voulant le defier "
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
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 [dessin tout cassé]
Ce n'est pas une bonne idée de composer des dessins ASCII avec une police à taille proportionnelle. ça marche tres bien bien son truc avec un client nntp qui se respecte ;)
non? le troll s'est vu ? bon ok.. -> []
Snarf
-- "L'IRQ a été inventée par Murphy ; le partage des IRQ, par quelqu'un voulant le defier " echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
Pascal
Ce n'est pas une bonne idée de composer des dessins ASCII avec une police à taille proportionnelle.
Désolé si ça ne rend pas, y-a t-il un moyen pour que le schéma puisse se voir ?
Il suffit de le composer avec une police à largeur fixe, comme "Courier New" par exemple.
Quelle usine à gaz ! Ce ne serait pas plus simple de gérer les autorisations par des règles iptables plutôt que par le routage ?
D'après moi, iptables ne sert qu'a gérer le filtrage et non le routage, peut etre ai-je manqué un aspect du programme.
Non, c'est bien ça.
Si il y a un moyen de dire a un paquet venant de 192.1.X.X de passer par la connexion ppp1 et non ppp0 grace à IPtables, je suis preneur.
iproute est bien l'outil approprié. Mais dans ton premier article tu parlais des politiques de routage entre DMZ et LAN, DMZ et routeur mais pas du routage en sortie vers internet.
J'ai considéré la question et je pense avoir compris le pourquoi de ces contorsions "iproutesques". En gros, pour pouvoir router vers ppp0 ou ppp1 il va falloir créer une voire deux politiques de routage par l'adresse source quelque part entre la politique de la table de routage locale et la politique de la table de routage principale. Sans les précautions qui s'imposent, cela va court-circuiter les routes normales vers le LAN et/ou la DMZ.
Je pars du principe que la table de routage principale (main) ne contient pas de route par défaut mais seulement les 4 routes vers : - le sous-réseau DMZ via eth1 - le sous-réseau LAN via eth2, - le pair Net1 via ppp0 - le pair Net2 via ppp1
Pour router de la DMZ vers ppp0 :
ip rule add from 192.1.254.0/24 lookup route0 pref 112 ip route add default dev ppp0 table route0
Pour router du LAN vers ppp1 :
ip rule add from 192.1.2.0/24 lookup route1 pref 113 ip route add default dev ppp1 table route1
Il est nécessaire de rétablir le routage vers le LAN et la DMZ avec une priorité supérieure afin qu'ils puissent communiquer ensemble et avec la passerelle :
ip rule add to 192.168.254.0/24 lookup main pref 110 ip rule add to 192.168.2.0/24 lookup main pref 111
Ou bien, au choix, en rajoutant des routes dans les tables route0 et route1, ce qui devrait aboutir au même résultat :
ip route add 192.168.254.0/24 dev eth1 table route0 ip route add 192.168.2.0/24 dev eth2 table route0 ip route add 192.168.254.0/24 dev eth1 table route1 ip route add 192.168.2.0/24 dev eth2 table route1
Vous direz qu'il y a deux routes qui devraient être inutiles car elles supposent que le paquet entre et sorte par la même interface.
Il reste à ajouter les routes par défaut de la passerelle elle-même :
ip rule add from <ip_ppp0> lookup route0 pref 114 ip rule add from <ip_ppp1> lookup route1 pref 115
J'espère ne pas avoir écrit trop de bêtises à cause de l'heure tardive. Pour finir, quelques commentaires sur ton premier article.
# 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
Dans une route vers une interface point à point, la mention de la passerelle est facultative car elle n'est pas vraiment pertinente. La mention de l'interface suffit. (Imagine que tes deux connexions PPP arrivent sur le même LNS chez le FAI, elles auraient la même adresse de pair)
# 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
Euh... une route par défaut vers la machine elle-même, pour quoi faire ?
# 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
La mention de la plage d'adresses source n'était pas franchement utile.
# règle permettant d'aller du LAN vers le firewall lui même ip rule add from 192.1.2.0/24 to 192.1.2.254 table table_local pref 112
Ceci ne devrait avoir aucun effet. Les routes locales vers les adresses de l'hôte lui-même sont déjà dans la table 'local' qui a la priorité la plus élevée.
# 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.
Oui, elle détourne vers la mauvaise interface les paquets retour destinés au LAN.
Ce n'est pas une bonne idée de composer des dessins ASCII avec une police
à taille proportionnelle.
Désolé si ça ne rend pas, y-a t-il un moyen pour que le schéma puisse se
voir ?
Il suffit de le composer avec une police à largeur fixe, comme "Courier
New" par exemple.
Quelle usine à gaz ! Ce ne serait pas plus simple de gérer les
autorisations par des règles iptables plutôt que par le routage ?
D'après moi, iptables ne sert qu'a gérer le filtrage et non le routage, peut
etre ai-je manqué un aspect du programme.
Non, c'est bien ça.
Si il y a un moyen de dire a un paquet venant de 192.1.X.X de passer par la
connexion ppp1 et non ppp0 grace à IPtables, je suis preneur.
iproute est bien l'outil approprié. Mais dans ton premier article tu
parlais des politiques de routage entre DMZ et LAN, DMZ et routeur mais
pas du routage en sortie vers internet.
J'ai considéré la question et je pense avoir compris le pourquoi de ces
contorsions "iproutesques". En gros, pour pouvoir router vers ppp0 ou
ppp1 il va falloir créer une voire deux politiques de routage par
l'adresse source quelque part entre la politique de la table de routage
locale et la politique de la table de routage principale. Sans les
précautions qui s'imposent, cela va court-circuiter les routes normales
vers le LAN et/ou la DMZ.
Je pars du principe que la table de routage principale (main) ne
contient pas de route par défaut mais seulement les 4 routes vers :
- le sous-réseau DMZ via eth1
- le sous-réseau LAN via eth2,
- le pair Net1 via ppp0
- le pair Net2 via ppp1
Pour router de la DMZ vers ppp0 :
ip rule add from 192.1.254.0/24 lookup route0 pref 112
ip route add default dev ppp0 table route0
Pour router du LAN vers ppp1 :
ip rule add from 192.1.2.0/24 lookup route1 pref 113
ip route add default dev ppp1 table route1
Il est nécessaire de rétablir le routage vers le LAN et la DMZ avec une
priorité supérieure afin qu'ils puissent communiquer ensemble et avec la
passerelle :
ip rule add to 192.168.254.0/24 lookup main pref 110
ip rule add to 192.168.2.0/24 lookup main pref 111
Ou bien, au choix, en rajoutant des routes dans les tables route0 et
route1, ce qui devrait aboutir au même résultat :
ip route add 192.168.254.0/24 dev eth1 table route0
ip route add 192.168.2.0/24 dev eth2 table route0
ip route add 192.168.254.0/24 dev eth1 table route1
ip route add 192.168.2.0/24 dev eth2 table route1
Vous direz qu'il y a deux routes qui devraient être inutiles car elles
supposent que le paquet entre et sorte par la même interface.
Il reste à ajouter les routes par défaut de la passerelle elle-même :
ip rule add from <ip_ppp0> lookup route0 pref 114
ip rule add from <ip_ppp1> lookup route1 pref 115
J'espère ne pas avoir écrit trop de bêtises à cause de l'heure tardive.
Pour finir, quelques commentaires sur ton premier article.
# 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
Dans une route vers une interface point à point, la mention de la
passerelle est facultative car elle n'est pas vraiment pertinente. La
mention de l'interface suffit. (Imagine que tes deux connexions PPP
arrivent sur le même LNS chez le FAI, elles auraient la même adresse de
pair)
# 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
Euh... une route par défaut vers la machine elle-même, pour quoi faire ?
# 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
La mention de la plage d'adresses source n'était pas franchement utile.
# règle permettant d'aller du LAN vers le firewall lui même
ip rule add from 192.1.2.0/24 to 192.1.2.254 table table_local pref 112
Ceci ne devrait avoir aucun effet. Les routes locales vers les adresses
de l'hôte lui-même sont déjà dans la table 'local' qui a la priorité la
plus élevée.
# 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.
Oui, elle détourne vers la mauvaise interface les paquets retour
destinés au LAN.
Ce n'est pas une bonne idée de composer des dessins ASCII avec une police à taille proportionnelle.
Désolé si ça ne rend pas, y-a t-il un moyen pour que le schéma puisse se voir ?
Il suffit de le composer avec une police à largeur fixe, comme "Courier New" par exemple.
Quelle usine à gaz ! Ce ne serait pas plus simple de gérer les autorisations par des règles iptables plutôt que par le routage ?
D'après moi, iptables ne sert qu'a gérer le filtrage et non le routage, peut etre ai-je manqué un aspect du programme.
Non, c'est bien ça.
Si il y a un moyen de dire a un paquet venant de 192.1.X.X de passer par la connexion ppp1 et non ppp0 grace à IPtables, je suis preneur.
iproute est bien l'outil approprié. Mais dans ton premier article tu parlais des politiques de routage entre DMZ et LAN, DMZ et routeur mais pas du routage en sortie vers internet.
J'ai considéré la question et je pense avoir compris le pourquoi de ces contorsions "iproutesques". En gros, pour pouvoir router vers ppp0 ou ppp1 il va falloir créer une voire deux politiques de routage par l'adresse source quelque part entre la politique de la table de routage locale et la politique de la table de routage principale. Sans les précautions qui s'imposent, cela va court-circuiter les routes normales vers le LAN et/ou la DMZ.
Je pars du principe que la table de routage principale (main) ne contient pas de route par défaut mais seulement les 4 routes vers : - le sous-réseau DMZ via eth1 - le sous-réseau LAN via eth2, - le pair Net1 via ppp0 - le pair Net2 via ppp1
Pour router de la DMZ vers ppp0 :
ip rule add from 192.1.254.0/24 lookup route0 pref 112 ip route add default dev ppp0 table route0
Pour router du LAN vers ppp1 :
ip rule add from 192.1.2.0/24 lookup route1 pref 113 ip route add default dev ppp1 table route1
Il est nécessaire de rétablir le routage vers le LAN et la DMZ avec une priorité supérieure afin qu'ils puissent communiquer ensemble et avec la passerelle :
ip rule add to 192.168.254.0/24 lookup main pref 110 ip rule add to 192.168.2.0/24 lookup main pref 111
Ou bien, au choix, en rajoutant des routes dans les tables route0 et route1, ce qui devrait aboutir au même résultat :
ip route add 192.168.254.0/24 dev eth1 table route0 ip route add 192.168.2.0/24 dev eth2 table route0 ip route add 192.168.254.0/24 dev eth1 table route1 ip route add 192.168.2.0/24 dev eth2 table route1
Vous direz qu'il y a deux routes qui devraient être inutiles car elles supposent que le paquet entre et sorte par la même interface.
Il reste à ajouter les routes par défaut de la passerelle elle-même :
ip rule add from <ip_ppp0> lookup route0 pref 114 ip rule add from <ip_ppp1> lookup route1 pref 115
J'espère ne pas avoir écrit trop de bêtises à cause de l'heure tardive. Pour finir, quelques commentaires sur ton premier article.
# 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
Dans une route vers une interface point à point, la mention de la passerelle est facultative car elle n'est pas vraiment pertinente. La mention de l'interface suffit. (Imagine que tes deux connexions PPP arrivent sur le même LNS chez le FAI, elles auraient la même adresse de pair)
# 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
Euh... une route par défaut vers la machine elle-même, pour quoi faire ?
# 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
La mention de la plage d'adresses source n'était pas franchement utile.
# règle permettant d'aller du LAN vers le firewall lui même ip rule add from 192.1.2.0/24 to 192.1.2.254 table table_local pref 112
Ceci ne devrait avoir aucun effet. Les routes locales vers les adresses de l'hôte lui-même sont déjà dans la table 'local' qui a la priorité la plus élevée.
# 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.
Oui, elle détourne vers la mauvaise interface les paquets retour destinés au LAN.
Bruno C
Merci d'avoir passé du temps sur ce problème. J'essairai la solution que tu as proposé ce soir
merci encore
"" a écrit dans le message de news: dj3ndq$2jc5$
Ce n'est pas une bonne idée de composer des dessins ASCII avec une police à taille proportionnelle.
Désolé si ça ne rend pas, y-a t-il un moyen pour que le schéma puisse se voir ?
Il suffit de le composer avec une police à largeur fixe, comme "Courier New" par exemple.
Quelle usine à gaz ! Ce ne serait pas plus simple de gérer les autorisations par des règles iptables plutôt que par le routage ?
D'après moi, iptables ne sert qu'a gérer le filtrage et non le routage, peut etre ai-je manqué un aspect du programme.
Non, c'est bien ça.
Si il y a un moyen de dire a un paquet venant de 192.1.X.X de passer par la connexion ppp1 et non ppp0 grace à IPtables, je suis preneur.
iproute est bien l'outil approprié. Mais dans ton premier article tu parlais des politiques de routage entre DMZ et LAN, DMZ et routeur mais pas du routage en sortie vers internet.
J'ai considéré la question et je pense avoir compris le pourquoi de ces contorsions "iproutesques". En gros, pour pouvoir router vers ppp0 ou ppp1 il va falloir créer une voire deux politiques de routage par l'adresse source quelque part entre la politique de la table de routage locale et la politique de la table de routage principale. Sans les précautions qui s'imposent, cela va court-circuiter les routes normales vers le LAN et/ou la DMZ.
Je pars du principe que la table de routage principale (main) ne contient pas de route par défaut mais seulement les 4 routes vers : - le sous-réseau DMZ via eth1 - le sous-réseau LAN via eth2, - le pair Net1 via ppp0 - le pair Net2 via ppp1
Pour router de la DMZ vers ppp0 :
ip rule add from 192.1.254.0/24 lookup route0 pref 112 ip route add default dev ppp0 table route0
Pour router du LAN vers ppp1 :
ip rule add from 192.1.2.0/24 lookup route1 pref 113 ip route add default dev ppp1 table route1
Il est nécessaire de rétablir le routage vers le LAN et la DMZ avec une priorité supérieure afin qu'ils puissent communiquer ensemble et avec la passerelle :
ip rule add to 192.168.254.0/24 lookup main pref 110 ip rule add to 192.168.2.0/24 lookup main pref 111
Ou bien, au choix, en rajoutant des routes dans les tables route0 et route1, ce qui devrait aboutir au même résultat :
ip route add 192.168.254.0/24 dev eth1 table route0 ip route add 192.168.2.0/24 dev eth2 table route0 ip route add 192.168.254.0/24 dev eth1 table route1 ip route add 192.168.2.0/24 dev eth2 table route1
Vous direz qu'il y a deux routes qui devraient être inutiles car elles supposent que le paquet entre et sorte par la même interface.
Il reste à ajouter les routes par défaut de la passerelle elle-même :
ip rule add from <ip_ppp0> lookup route0 pref 114 ip rule add from <ip_ppp1> lookup route1 pref 115
J'espère ne pas avoir écrit trop de bêtises à cause de l'heure tardive. Pour finir, quelques commentaires sur ton premier article.
# 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
Dans une route vers une interface point à point, la mention de la passerelle est facultative car elle n'est pas vraiment pertinente. La mention de l'interface suffit. (Imagine que tes deux connexions PPP arrivent sur le même LNS chez le FAI, elles auraient la même adresse de pair)
# 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
Euh... une route par défaut vers la machine elle-même, pour quoi faire ?
# 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
La mention de la plage d'adresses source n'était pas franchement utile.
# règle permettant d'aller du LAN vers le firewall lui même ip rule add from 192.1.2.0/24 to 192.1.2.254 table table_local pref 112
Ceci ne devrait avoir aucun effet. Les routes locales vers les adresses de l'hôte lui-même sont déjà dans la table 'local' qui a la priorité la plus élevée.
# 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.
Oui, elle détourne vers la mauvaise interface les paquets retour destinés au LAN.
Merci d'avoir passé du temps sur ce problème.
J'essairai la solution que tu as proposé ce soir
merci encore
"Pascal@plouf" <boite-a-spam@plouf.fr.eu.org> a écrit dans le message de
news: dj3ndq$2jc5$1@biggoron.nerim.net...
Ce n'est pas une bonne idée de composer des dessins ASCII avec une police
à taille proportionnelle.
Désolé si ça ne rend pas, y-a t-il un moyen pour que le schéma puisse se
voir ?
Il suffit de le composer avec une police à largeur fixe, comme "Courier
New" par exemple.
Quelle usine à gaz ! Ce ne serait pas plus simple de gérer les
autorisations par des règles iptables plutôt que par le routage ?
D'après moi, iptables ne sert qu'a gérer le filtrage et non le routage,
peut etre ai-je manqué un aspect du programme.
Non, c'est bien ça.
Si il y a un moyen de dire a un paquet venant de 192.1.X.X de passer par
la connexion ppp1 et non ppp0 grace à IPtables, je suis preneur.
iproute est bien l'outil approprié. Mais dans ton premier article tu
parlais des politiques de routage entre DMZ et LAN, DMZ et routeur mais
pas du routage en sortie vers internet.
J'ai considéré la question et je pense avoir compris le pourquoi de ces
contorsions "iproutesques". En gros, pour pouvoir router vers ppp0 ou ppp1
il va falloir créer une voire deux politiques de routage par l'adresse
source quelque part entre la politique de la table de routage locale et la
politique de la table de routage principale. Sans les précautions qui
s'imposent, cela va court-circuiter les routes normales vers le LAN et/ou
la DMZ.
Je pars du principe que la table de routage principale (main) ne contient
pas de route par défaut mais seulement les 4 routes vers :
- le sous-réseau DMZ via eth1
- le sous-réseau LAN via eth2,
- le pair Net1 via ppp0
- le pair Net2 via ppp1
Pour router de la DMZ vers ppp0 :
ip rule add from 192.1.254.0/24 lookup route0 pref 112
ip route add default dev ppp0 table route0
Pour router du LAN vers ppp1 :
ip rule add from 192.1.2.0/24 lookup route1 pref 113
ip route add default dev ppp1 table route1
Il est nécessaire de rétablir le routage vers le LAN et la DMZ avec une
priorité supérieure afin qu'ils puissent communiquer ensemble et avec la
passerelle :
ip rule add to 192.168.254.0/24 lookup main pref 110
ip rule add to 192.168.2.0/24 lookup main pref 111
Ou bien, au choix, en rajoutant des routes dans les tables route0 et
route1, ce qui devrait aboutir au même résultat :
ip route add 192.168.254.0/24 dev eth1 table route0
ip route add 192.168.2.0/24 dev eth2 table route0
ip route add 192.168.254.0/24 dev eth1 table route1
ip route add 192.168.2.0/24 dev eth2 table route1
Vous direz qu'il y a deux routes qui devraient être inutiles car elles
supposent que le paquet entre et sorte par la même interface.
Il reste à ajouter les routes par défaut de la passerelle elle-même :
ip rule add from <ip_ppp0> lookup route0 pref 114
ip rule add from <ip_ppp1> lookup route1 pref 115
J'espère ne pas avoir écrit trop de bêtises à cause de l'heure tardive.
Pour finir, quelques commentaires sur ton premier article.
# 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
Dans une route vers une interface point à point, la mention de la
passerelle est facultative car elle n'est pas vraiment pertinente. La
mention de l'interface suffit. (Imagine que tes deux connexions PPP
arrivent sur le même LNS chez le FAI, elles auraient la même adresse de
pair)
# 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
Euh... une route par défaut vers la machine elle-même, pour quoi faire ?
# 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
La mention de la plage d'adresses source n'était pas franchement utile.
# règle permettant d'aller du LAN vers le firewall lui même
ip rule add from 192.1.2.0/24 to 192.1.2.254 table table_local pref 112
Ceci ne devrait avoir aucun effet. Les routes locales vers les adresses de
l'hôte lui-même sont déjà dans la table 'local' qui a la priorité la plus
élevée.
# 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.
Oui, elle détourne vers la mauvaise interface les paquets retour destinés
au LAN.
Merci d'avoir passé du temps sur ce problème. J'essairai la solution que tu as proposé ce soir
merci encore
"" a écrit dans le message de news: dj3ndq$2jc5$
Ce n'est pas une bonne idée de composer des dessins ASCII avec une police à taille proportionnelle.
Désolé si ça ne rend pas, y-a t-il un moyen pour que le schéma puisse se voir ?
Il suffit de le composer avec une police à largeur fixe, comme "Courier New" par exemple.
Quelle usine à gaz ! Ce ne serait pas plus simple de gérer les autorisations par des règles iptables plutôt que par le routage ?
D'après moi, iptables ne sert qu'a gérer le filtrage et non le routage, peut etre ai-je manqué un aspect du programme.
Non, c'est bien ça.
Si il y a un moyen de dire a un paquet venant de 192.1.X.X de passer par la connexion ppp1 et non ppp0 grace à IPtables, je suis preneur.
iproute est bien l'outil approprié. Mais dans ton premier article tu parlais des politiques de routage entre DMZ et LAN, DMZ et routeur mais pas du routage en sortie vers internet.
J'ai considéré la question et je pense avoir compris le pourquoi de ces contorsions "iproutesques". En gros, pour pouvoir router vers ppp0 ou ppp1 il va falloir créer une voire deux politiques de routage par l'adresse source quelque part entre la politique de la table de routage locale et la politique de la table de routage principale. Sans les précautions qui s'imposent, cela va court-circuiter les routes normales vers le LAN et/ou la DMZ.
Je pars du principe que la table de routage principale (main) ne contient pas de route par défaut mais seulement les 4 routes vers : - le sous-réseau DMZ via eth1 - le sous-réseau LAN via eth2, - le pair Net1 via ppp0 - le pair Net2 via ppp1
Pour router de la DMZ vers ppp0 :
ip rule add from 192.1.254.0/24 lookup route0 pref 112 ip route add default dev ppp0 table route0
Pour router du LAN vers ppp1 :
ip rule add from 192.1.2.0/24 lookup route1 pref 113 ip route add default dev ppp1 table route1
Il est nécessaire de rétablir le routage vers le LAN et la DMZ avec une priorité supérieure afin qu'ils puissent communiquer ensemble et avec la passerelle :
ip rule add to 192.168.254.0/24 lookup main pref 110 ip rule add to 192.168.2.0/24 lookup main pref 111
Ou bien, au choix, en rajoutant des routes dans les tables route0 et route1, ce qui devrait aboutir au même résultat :
ip route add 192.168.254.0/24 dev eth1 table route0 ip route add 192.168.2.0/24 dev eth2 table route0 ip route add 192.168.254.0/24 dev eth1 table route1 ip route add 192.168.2.0/24 dev eth2 table route1
Vous direz qu'il y a deux routes qui devraient être inutiles car elles supposent que le paquet entre et sorte par la même interface.
Il reste à ajouter les routes par défaut de la passerelle elle-même :
ip rule add from <ip_ppp0> lookup route0 pref 114 ip rule add from <ip_ppp1> lookup route1 pref 115
J'espère ne pas avoir écrit trop de bêtises à cause de l'heure tardive. Pour finir, quelques commentaires sur ton premier article.
# 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
Dans une route vers une interface point à point, la mention de la passerelle est facultative car elle n'est pas vraiment pertinente. La mention de l'interface suffit. (Imagine que tes deux connexions PPP arrivent sur le même LNS chez le FAI, elles auraient la même adresse de pair)
# 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
Euh... une route par défaut vers la machine elle-même, pour quoi faire ?
# 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
La mention de la plage d'adresses source n'était pas franchement utile.
# règle permettant d'aller du LAN vers le firewall lui même ip rule add from 192.1.2.0/24 to 192.1.2.254 table table_local pref 112
Ceci ne devrait avoir aucun effet. Les routes locales vers les adresses de l'hôte lui-même sont déjà dans la table 'local' qui a la priorité la plus élevée.
# 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.
Oui, elle détourne vers la mauvaise interface les paquets retour destinés au LAN.
Bruno C
"" a écrit dans le message de news: dj3ndq$2jc5$
Je pars du principe que la table de routage principale (main) ne contient pas de route par défaut mais seulement les 4 routes vers : - le sous-réseau DMZ via eth1 - le sous-réseau LAN via eth2, - le pair Net1 via ppp0 - le pair Net2 via ppp1
Qu'entends tu par pair ? est-ce l'addresse IP fixe fournie par le FAI ? L'adresse IP de l'interface sur laquelle est relié la connexion ppp ? L'adresse de la passerelle p-t-p (si c'est le cas, c'est la même pour les deux connexions donc problème) ?
merci
"Pascal@plouf" <boite-a-spam@plouf.fr.eu.org> a écrit dans le message de
news: dj3ndq$2jc5$1@biggoron.nerim.net...
Je pars du principe que la table de routage principale (main) ne contient
pas de route par défaut mais seulement les 4 routes vers :
- le sous-réseau DMZ via eth1
- le sous-réseau LAN via eth2,
- le pair Net1 via ppp0
- le pair Net2 via ppp1
Qu'entends tu par pair ? est-ce l'addresse IP fixe fournie par le FAI ?
L'adresse IP de l'interface sur laquelle est relié la connexion ppp ?
L'adresse de la passerelle p-t-p (si c'est le cas, c'est la même pour les
deux connexions donc problème) ?
Je pars du principe que la table de routage principale (main) ne contient pas de route par défaut mais seulement les 4 routes vers : - le sous-réseau DMZ via eth1 - le sous-réseau LAN via eth2, - le pair Net1 via ppp0 - le pair Net2 via ppp1
Qu'entends tu par pair ? est-ce l'addresse IP fixe fournie par le FAI ? L'adresse IP de l'interface sur laquelle est relié la connexion ppp ? L'adresse de la passerelle p-t-p (si c'est le cas, c'est la même pour les deux connexions donc problème) ?
merci
Bruno C
"" a écrit dans le message de news: dj3ndq$2jc5$
ip rule add from 192.1.254.0/24 lookup route0 pref 112 ip route add default dev ppp0 table route0
Pour router du LAN vers ppp1 :
ip rule add from 192.1.2.0/24 lookup route1 pref 113 ip route add default dev ppp1 table route1
ip rule add from <ip_ppp0> lookup route0 pref 114 ip rule add from <ip_ppp1> lookup route1 pref 115
Désolé pour le multipost mais une question me taraude,
Lorsqu'un paquet arrive sur la connexion ppp0, il rentre dans la table route0, mais cette table ne contient que la route par défaut vers ppp0, ne faudrait-il pas y rajouter une route vers la DMZ ?
et pareil pour un paquet venant de ppp1 pour le LAN
merci
"Pascal@plouf" <boite-a-spam@plouf.fr.eu.org> a écrit dans le message de
news: dj3ndq$2jc5$1@biggoron.nerim.net...
ip rule add from 192.1.254.0/24 lookup route0 pref 112
ip route add default dev ppp0 table route0
Pour router du LAN vers ppp1 :
ip rule add from 192.1.2.0/24 lookup route1 pref 113
ip route add default dev ppp1 table route1
ip rule add from <ip_ppp0> lookup route0 pref 114
ip rule add from <ip_ppp1> lookup route1 pref 115
Désolé pour le multipost mais une question me taraude,
Lorsqu'un paquet arrive sur la connexion ppp0, il rentre dans la table
route0, mais cette table ne contient que la route par défaut vers ppp0, ne
faudrait-il pas y rajouter une route vers la DMZ ?
et pareil pour un paquet venant de ppp1 pour le LAN
ip rule add from 192.1.254.0/24 lookup route0 pref 112 ip route add default dev ppp0 table route0
Pour router du LAN vers ppp1 :
ip rule add from 192.1.2.0/24 lookup route1 pref 113 ip route add default dev ppp1 table route1
ip rule add from <ip_ppp0> lookup route0 pref 114 ip rule add from <ip_ppp1> lookup route1 pref 115
Désolé pour le multipost mais une question me taraude,
Lorsqu'un paquet arrive sur la connexion ppp0, il rentre dans la table route0, mais cette table ne contient que la route par défaut vers ppp0, ne faudrait-il pas y rajouter une route vers la DMZ ?
et pareil pour un paquet venant de ppp1 pour le LAN
merci
Pascal
[Réponse groupée]
Qu'entends tu par pair ? est-ce l'addresse IP fixe fournie par le FAI ? L'adresse IP de l'interface sur laquelle est relié la connexion ppp ?
Non. Ça, c'est <ip_ppp0> ou <ip_ppp1>.
L'adresse de la passerelle p-t-p
Oui.
(si c'est le cas, c'est la même pour les deux connexions donc problème) ?
Si tu n'utilises pas l'adresse du pair - et tu n'en as pas besoin, l'interface suffit - pas de problème. Par contre si tu écris :
ip route add default via <ip_pair>
Alors que la table de routage contient :
<ip_pair>/32 dev ppp0 <ip_pair>/32 dev ppp1
Il y a une incertitude sur l'interface qui sera choisie.
ip rule add from <ip_ppp0> lookup route0 pref 114 ip rule add from <ip_ppp1> lookup route1 pref 115
Lorsqu'un paquet arrive sur la connexion ppp0, il rentre dans la table route0
Non. La règle concerne les paquets dont l'adresse IP *source* (from) est celle de ppp0. Or les paquet entrants par ppp0 ont l'adresse de ppp0 en *destination*.
[Réponse groupée]
Qu'entends tu par pair ? est-ce l'addresse IP fixe fournie par le FAI ?
L'adresse IP de l'interface sur laquelle est relié la connexion ppp ?
Non. Ça, c'est <ip_ppp0> ou <ip_ppp1>.
L'adresse de la passerelle p-t-p
Oui.
(si c'est le cas, c'est la même pour les deux connexions donc problème) ?
Si tu n'utilises pas l'adresse du pair - et tu n'en as pas besoin,
l'interface suffit - pas de problème. Par contre si tu écris :
ip route add default via <ip_pair>
Alors que la table de routage contient :
<ip_pair>/32 dev ppp0
<ip_pair>/32 dev ppp1
Il y a une incertitude sur l'interface qui sera choisie.
ip rule add from <ip_ppp0> lookup route0 pref 114
ip rule add from <ip_ppp1> lookup route1 pref 115
Lorsqu'un paquet arrive sur la connexion ppp0, il rentre dans la table
route0
Non. La règle concerne les paquets dont l'adresse IP *source* (from) est
celle de ppp0. Or les paquet entrants par ppp0 ont l'adresse de ppp0 en
*destination*.
Qu'entends tu par pair ? est-ce l'addresse IP fixe fournie par le FAI ? L'adresse IP de l'interface sur laquelle est relié la connexion ppp ?
Non. Ça, c'est <ip_ppp0> ou <ip_ppp1>.
L'adresse de la passerelle p-t-p
Oui.
(si c'est le cas, c'est la même pour les deux connexions donc problème) ?
Si tu n'utilises pas l'adresse du pair - et tu n'en as pas besoin, l'interface suffit - pas de problème. Par contre si tu écris :
ip route add default via <ip_pair>
Alors que la table de routage contient :
<ip_pair>/32 dev ppp0 <ip_pair>/32 dev ppp1
Il y a une incertitude sur l'interface qui sera choisie.
ip rule add from <ip_ppp0> lookup route0 pref 114 ip rule add from <ip_ppp1> lookup route1 pref 115
Lorsqu'un paquet arrive sur la connexion ppp0, il rentre dans la table route0
Non. La règle concerne les paquets dont l'adresse IP *source* (from) est celle de ppp0. Or les paquet entrants par ppp0 ont l'adresse de ppp0 en *destination*.
Bruno C
J'ai mis en place la solution hier soir, C'était tout bon sauf deux règles qui étaient inutiles :
Voici les règles que j'ai ajoutées dans l'ordre des préférences #0 from all lookup local #109 ip rule add to 192.1.254.0/24 lookup main pref 109 #110 ip rule add to 192.1.2.0/24 lookup main pref 110 #111 ip rule add from 192.1.254.0/24 lookup route0 pref 111 #112 ip rule add from 192.1.2.0/24 lookup route1 pref 112 #32766 from all lookup main
#Route des tables ip route add default dev ppp1 table route1 ip route add default dev ppp0 table route0
Merci pour ton aide
"" a écrit dans le message de news: dj64sm$eua$
[Réponse groupée]
Qu'entends tu par pair ? est-ce l'addresse IP fixe fournie par le FAI ? L'adresse IP de l'interface sur laquelle est relié la connexion ppp ?
Non. Ça, c'est <ip_ppp0> ou <ip_ppp1>.
L'adresse de la passerelle p-t-p
Oui.
(si c'est le cas, c'est la même pour les deux connexions donc problème) ?
Si tu n'utilises pas l'adresse du pair - et tu n'en as pas besoin, l'interface suffit - pas de problème. Par contre si tu écris :
ip route add default via <ip_pair>
Alors que la table de routage contient :
<ip_pair>/32 dev ppp0 <ip_pair>/32 dev ppp1
Il y a une incertitude sur l'interface qui sera choisie.
ip rule add from <ip_ppp0> lookup route0 pref 114 ip rule add from <ip_ppp1> lookup route1 pref 115
Lorsqu'un paquet arrive sur la connexion ppp0, il rentre dans la table route0
Non. La règle concerne les paquets dont l'adresse IP *source* (from) est celle de ppp0. Or les paquet entrants par ppp0 ont l'adresse de ppp0 en *destination*.
J'ai mis en place la solution hier soir, C'était tout bon sauf deux règles
qui étaient inutiles :
Voici les règles que j'ai ajoutées dans l'ordre des préférences
#0
from all lookup local
#109
ip rule add to 192.1.254.0/24 lookup main pref 109
#110
ip rule add to 192.1.2.0/24 lookup main pref 110
#111
ip rule add from 192.1.254.0/24 lookup route0 pref 111
#112
ip rule add from 192.1.2.0/24 lookup route1 pref 112
#32766
from all lookup main
#Route des tables
ip route add default dev ppp1 table route1
ip route add default dev ppp0 table route0
Merci pour ton aide
"Pascal@plouf" <boite-a-spam@plouf.fr.eu.org> a écrit dans le message de
news: dj64sm$eua$1@biggoron.nerim.net...
[Réponse groupée]
Qu'entends tu par pair ? est-ce l'addresse IP fixe fournie par le FAI ?
L'adresse IP de l'interface sur laquelle est relié la connexion ppp ?
Non. Ça, c'est <ip_ppp0> ou <ip_ppp1>.
L'adresse de la passerelle p-t-p
Oui.
(si c'est le cas, c'est la même pour les deux connexions donc problème) ?
Si tu n'utilises pas l'adresse du pair - et tu n'en as pas besoin,
l'interface suffit - pas de problème. Par contre si tu écris :
ip route add default via <ip_pair>
Alors que la table de routage contient :
<ip_pair>/32 dev ppp0
<ip_pair>/32 dev ppp1
Il y a une incertitude sur l'interface qui sera choisie.
ip rule add from <ip_ppp0> lookup route0 pref 114
ip rule add from <ip_ppp1> lookup route1 pref 115
Lorsqu'un paquet arrive sur la connexion ppp0, il rentre dans la table
route0
Non. La règle concerne les paquets dont l'adresse IP *source* (from) est
celle de ppp0. Or les paquet entrants par ppp0 ont l'adresse de ppp0 en
*destination*.
J'ai mis en place la solution hier soir, C'était tout bon sauf deux règles qui étaient inutiles :
Voici les règles que j'ai ajoutées dans l'ordre des préférences #0 from all lookup local #109 ip rule add to 192.1.254.0/24 lookup main pref 109 #110 ip rule add to 192.1.2.0/24 lookup main pref 110 #111 ip rule add from 192.1.254.0/24 lookup route0 pref 111 #112 ip rule add from 192.1.2.0/24 lookup route1 pref 112 #32766 from all lookup main
#Route des tables ip route add default dev ppp1 table route1 ip route add default dev ppp0 table route0
Merci pour ton aide
"" a écrit dans le message de news: dj64sm$eua$
[Réponse groupée]
Qu'entends tu par pair ? est-ce l'addresse IP fixe fournie par le FAI ? L'adresse IP de l'interface sur laquelle est relié la connexion ppp ?
Non. Ça, c'est <ip_ppp0> ou <ip_ppp1>.
L'adresse de la passerelle p-t-p
Oui.
(si c'est le cas, c'est la même pour les deux connexions donc problème) ?
Si tu n'utilises pas l'adresse du pair - et tu n'en as pas besoin, l'interface suffit - pas de problème. Par contre si tu écris :
ip route add default via <ip_pair>
Alors que la table de routage contient :
<ip_pair>/32 dev ppp0 <ip_pair>/32 dev ppp1
Il y a une incertitude sur l'interface qui sera choisie.
ip rule add from <ip_ppp0> lookup route0 pref 114 ip rule add from <ip_ppp1> lookup route1 pref 115
Lorsqu'un paquet arrive sur la connexion ppp0, il rentre dans la table route0
Non. La règle concerne les paquets dont l'adresse IP *source* (from) est celle de ppp0. Or les paquet entrants par ppp0 ont l'adresse de ppp0 en *destination*.
Pascal
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.
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.
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.
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.
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.
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.
