Tâche #8966
Bac à idée #10629: Etudier l'héritage, l'héritage multiple et l'héritage à plusieurs niveau Era
Clarifier l'héritage des zones inversées
Description
Nous avons constaté que le fait d'inverser une politique entre 2 zones n'a aucun effet malgré que le XML ait bien été modifié pour le flux concerné
Par exemple, pour les regles pubdmz -> ext, si on inverse la politique, ça passe bien de vert à rouge dans ERA et le XML est bien modifié avec la bonne valeur "<descendantes default_policy="0">" mais la regle suivante est toujours appliquée:
/sbin/iptables -t filter -A pub-ext -i eth4 -o eth0 -s 0/0 -d 0/0 -j ACCEPT
Ce qui correspond à une politique ACCEPT et non DROP comme on le voudrait
Historique
#1 Mis à jour par Jean-Marc MELET il y a environ 9 ans
Bonjour,
Petit up...
#2 Mis à jour par Gwenael Remond il y a presque 9 ans
- Assigné à mis à Gwenael Remond
- % réalisé changé de 0 à 20
- Temps estimé mis à 3.00 h
- Distribution changé de EOLE 2.3 à EOLE 2.4
Je ne reproduis pas le bug en fait, si j'inverse un flux dans l'interface Era
la politique par défaut passe bien en DROP au niveau des règles iptables,
< /sbin/iptables -t filter -A ped-dmz -i %%nom_zone_eth2 -o %%nom_zone_eth3 -s 0/0 -d 0/0 -j ACCEPT --- > /sbin/iptables -t filter -A ped-dmz -i %%nom_zone_eth2 -o %%nom_zone_eth3 -s 0/0 -d 0/0 -j DROP
ou bien en accept :
< /sbin/iptables -t filter -A dmz-ped -i %%nom_zone_eth3 -o %%nom_zone_eth2 -s 0/0 -d 0/0 -j DROP --- > /sbin/iptables -t filter -A dmz-ped -i %%nom_zone_eth3 -o %%nom_zone_eth2 -s 0/0 -d 0/0 -j ACCEPT
Donc il faut préciser ta demande pour que je puisse reproduire le bug : es-tu dans des conditions particulière, est-ce que tes modèles sont des modèles hérités ?
#3 Mis à jour par Gwenael Remond il y a presque 9 ans
- Statut changé de Nouveau à En attente d'informations
#4 Mis à jour par Jean-Marc MELET il y a presque 9 ans
Salut,
J'effectue l'inversion de politique entre les zones sur notre modèle académique enfant qui hérite du modèle 5zones.xml
Je pensais qu'il était possible de modifier ces politiques sur notre modèle étant donné que les cases ne sont pas grisés dans era et encore une fois la directive est bien modifiée dans le XML (passe bien de "<descendantes default_policy="1"> à "<descendantes default_policy="0">)
Mais je constate que c'est toujours le modèle parent qui a le dernier mot sur les politiques. En effet, si je modifie en dur la politique dans le XML du modèle père 5zones.xml, alors cette fois-ci la règle passe bien en:
/sbin/iptables -t filter -A pub-ext -i eth4 -o eth0 -s 0/0 -d 0/0 -j DROP
Donc ma question serait plutôt:
1) Est-ce voulu de ne pas pouvoir modifier les politique par défaut dans un modèle enfant? dans ce cas pourquoi a-t-on la main dessus? (j'aurais imaginé que les cases soient grisés pour ne pas faire croire que l'on peut le modifier)
2) Si c'est voulu, pourrait-on modifier ce comportement et permettre d'inverser des politiques par défaut entre 2 zones dans notre modèle enfant académique?
Merci
#5 Mis à jour par Emmanuel GARETTE il y a plus de 8 ans
- Tracker changé de Anomalie à Demande
- Statut changé de En attente d'informations à Nouveau
#6 Mis à jour par Emmanuel GARETTE il y a plus de 8 ans
- Tracker changé de Demande à Tâche
- Sujet changé de L'inversement de la politique entre 2 zones n'est pas appliquée à Clarifier l'héritage des zones inversées
- Tâche parente mis à #10629
- Restant à faire (heures) mis à 3.0