Proposition Scénario #13967
Agregation de lien - mauvais routage des réponses aux paquets entrants vers la DMZ
Description
Sur la liste amon-sphynx@listeseole.ac-dijon.fr a été évoqué le pb de la route de retour suir l'accès DMZ lors de la mis een place de l'agrégation de LIEN.
Message avec sujet : [Amon-Sphynx] Agrégation de lien
Plusieurs solution ont ete évoquée.
Dans l'académie de montpellier nous ajoutons deux regles dans les règles IP ROUTE
Afin de forcer la route de retour sur T1 sauf dans le cas de réponse aux réseaux interne en 10.0.0.0/8
192 # ajout route retour
193 /sbin/ip rule add from $adresse_network_eth3/$adresse_netmask_eth3 table T1
194 /sbin/ip rule add from $adresse_network_eth3/$adresse_netmask_eth3 to 10.0.0.0/8 table main
Exigence :
- l’agrégation de lien permet de mutualisé les accès Internet entre deux abonnements
- l'agrégation de lien permet de basculer d'un abonnement à un autre en cas de coupure de l'accès Internet principal
Subtasks
Associated revisions
Correction du routage pour les réponses aux paquets entrants
à destination des DMZ (seulement pour le mode_lb)
avec prise en charge des interfaces vlan
Ref: 13967
correction
on crée les ip rule en dehors
de la fonction active_balancing
ref: #13967
History
#1 Updated by Scrum Master almost 8 years ago
- Assigned To set to Emmanuel GARETTE
#2 Updated by Emmanuel GARETTE almost 8 years ago
Le thread en question est visible ici : http://eole.orion.education.fr/listes/arc/amon-sphynx/2015-11/msg00003.html
#3 Updated by Emmanuel GARETTE almost 8 years ago
Message de Karim Ayari :
De mon côté la solution qui fonctionne est simplement d'ajouter la ou les routes concernées dans la bonne table : #ajoutées dans mes inclusions statiques /sbin/ip route add %%adresse_network_eth1/%%adresse_netmask_eth1 dev eth1 via %%adresse_ip_eth1 table T1 /sbin/ip route add %%adresse_network_eth2/%%adresse_netmask_eth2 dev eth2 via %%adresse_ip_eth2 table T1 /sbin/ip route add %%adresse_network_eth3/%%adresse_netmask_eth3 dev eth3 via %%adresse_ip_eth3 table T1 root@sermenaz:~# ip route list table T1 10.169.134.240 dev eth0 scope link src 10.169.134.252 192.168.220.0/24 via 192.168.220.252 dev eth3 10.69.134.0/24 via 10.69.134.252 dev eth1 172.16.0.0/16 via 172.16.0.252 dev eth2 default via 10.169.134.254 dev eth0 root@sermenaz:~# ip route list table T2 10.169.134.0 dev eth0 scope link src 10.169.134.124 default via 10.169.134.126 dev eth0 root@sermenaz:~# Fut un temps où j'en avais parlé avec Ludo et j'en avais conclut que le problème se pose pour les Amon qui sont en adressage privée sur eth0 (à Dijon pas de problème puisque vos Amon sont en ip publiques..si c'est toujours le cas). Pour moi le fait d'ajouter les routes locales dans la table correspondantes doit suffir, d'ailleurs c'est ce que doit faire Jean-Marc à Aix. J'avais tout de même commencé à travailler un peu sur l'intégration en ajoutant dans le dictionnaire agrégation la possibilité d'ajouter les routes au script avec notamment le choix du lien à utiliser pour joindre la DMZ, mais pas eut le temps de poursuivre :/ <!-- gestion de la dmz --> <variable name='acces_dmz1' type='oui/non' description='Accès à la dmz via le lien 1'> <value>non</value> </variable> <!-- gestion de la dmz --> <variable name='acces_dmz2' type='oui/non' description='Accès à la dmz via le lien 2'> <value>non</value> </variable> et ensuite ajouter les règles de routage dans le script selon la valeur de la variable.
#4 Updated by Eric Jourdan almost 8 years ago
Bonjour,
On a longtemps cru chez nous que le problème était lié a l'usage d'un alias sur eth0 avec une ip privé. J'ai actuellement plusieurs d'atblissement avec deux IP publiques sur eth0 qui rencontrent l'anomalie.
Ta réponse Karim ne répond pas a ma compréhension du problème car il indique des routes statiques vers les réseaux eth1, eth2 et eth3 or pour moi le problème est lié au routage des paquets provenant de eth3 et à destination de n'importe ou vers le net (eth0).
Après, ce n'est pas clair du tout pour nous et pour être plus précis depuis hier je tente de reproduire le problème sur un AMON virtualisé avec deux IP publiques (deux lignes ADSL) et je ne parviens pas à le reproduire.
Ce que je peux dire :
Lorsque dans un établisement le problème se rencontre, nous le réglons actuellement en ajoutant deux régles de source routing :
(eth3 etant la DMZ chez nous )
les paquets provenant de eth3 et a destination du réseau 10.0.0.0/8 sont routés via la table main (cas d'un echange entre eth3 et eth1 ou eth2)
les paquets provenant de eth3 et a destination du reste du monde sont routés via la table T1 (tous les autres cas...)
ce qui se traduit par l'ajout dans le script agregation.sh
$ /sbin/ip rule add from $adresse_ip_eth3/$netmask_eth3 table T1
$ /sbin/ip rule add from $adresse_ip_eth3/$netmask_eth3 to 10.0.0.0/8 table main
J'ai l'impression que Jean-Marc a Aix modifie les routes en forcant le TAG des paquets via iptables mais je ne peux le tester ne parvenant pas à reproduire le problème.
Je continue a tester mais j'aimerai bien déjà déterminer les conditions qui déclenche l'anomalie.
Merci d'avoir pris en compte ma demande.
#5 Updated by Emmanuel GARETTE almost 8 years ago
- Tracker changed from Demande to Proposition Scénario
- Description updated (diff)
- Category set to Version majeure
- Assigned To deleted (
Emmanuel GARETTE)
Changement fonctionnel.
#6 Updated by Joël Cuissinat almost 8 years ago
- Project changed from Amon to conf-amon
- Category changed from Version majeure to Version majeure
#7 Updated by Eric Jourdan almost 8 years ago
Bonjour, juste une remarque (j'ai pas le temps de tester plus en avant pour l'instant mais je ne lache pas l'affaire...).
Je m'aperçois que certaines fonctionnalités sur l'AMON n'était pas active car le modèle de pare-feu 4zones que l'on utilise (recyclé d'année en années) n'integre pas les dernières modifications (et celles de la 2.3)..
C'est le cas pour : authentification proxy (port 3127) , exceptions au proxy (era_proxy_bypass), WPAD, ...
Est-ce que les problèmes que nous avons sur l'agregation peuvent venir de règles iptables incluses dans le modèle par defaut et qui ne sont pas le notre ?
Cdlt
#8 Updated by Scrum Master over 7 years ago
- Tracker changed from Proposition Scénario to Bac à idée
#9 Updated by Karim Ayari over 6 years ago
- Assigned To set to Karim Ayari
je viens de reproduire le problème qui est le même que nous rencontrions auparavant.
pour reproduire :
un amon 2.5.2 (avec le script d'agrégation initial)
par exemepl un serveur ssh sur eth3
une règle de DNAT pour prendre la main depuis Internet sur ce serveur en DMZ
on ne parvient jamais à avoir la mire d'authentification.
on peut s'en sortir soit en forçant l'ip publique source (tout internet!) à être joint par le routeur lié à T1 mais ce n'est pas une solution :) soit avec la correction d'Eric.
je compare des traces tout de même pour comprendre et j'ajouterais ce qu'il faut au script.
#10 Updated by Karim Ayari over 6 years ago
- Tracker changed from Bac à idée to Anomalie
- Subject changed from Agregation de lien - probleme de la route de retour sur accès DMZ to Agregation de lien - mauvais routage des réponses aux paquets entrants
précision pour reproduire l'agrégation doit être en mode_lb.
en mode_fo le problème ne doit pas se produire, enfin je crois cela reste à tester.
#11 Updated by Karim Ayari over 6 years ago
- Subject changed from Agregation de lien - mauvais routage des réponses aux paquets entrants to Agregation de lien - mauvais routage des réponses aux paquets entrants vers la DMZ
- Estimated time set to 2.00 h
- Distribution set to EOLE 2.5
après vérifications le problème ne se produit que dans le mode_lb
ce que je vois :
- ajout d'une variable ag_dmz_eth0 pour le lien 1, valeur par défaut : oui
- ajout d'une variable ag_dmz_eth0_0 pour le lien 2, valeur par défaut : non
si valeur à oui :
- ajouter les ip rule pour les interfaces DMZ à partir de eth3
- ajouter les ip rule pour les interfaces vlan sur la DMZ à partir de eth3
faire une fonction qui sera applicable seulement dans le cas du mode_lb.
#12 Updated by Karim Ayari over 6 years ago
- Status changed from Nouveau to Résolu
#13 Updated by Joël Cuissinat over 1 year ago
- Tracker changed from Anomalie to Proposition Scénario
- Status changed from Résolu to Classée sans suite