Distribution EOLE » Modules » Amon » conf-amon

Le thread en question est visible ici : http://eole.orion.education.fr/listes/arc/amon-sphynx/2015-11/msg00003.html

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.

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.

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