Tâche #18328
Mis à jour par Fabrice Barconnière il y a plus de 7 ans
Mise en place d'une architecture de test :
* 2 gateways
* un serveur Amon 2.5.2 configuré avec l'agrégation
Comme je l'évoquais sur la liste de diffusion, je n'ai malheureusement pas pu le proposer à temps pour la sortie de la maj du 23/11 mais en lien avec https://dev-eole.ac-dijon.fr/issues/17579 nous nous sommes aperçu d'un conflit un peu du même ordre.
Nous avons remarqué que l'arret/démarrage/relance du service bastion peut ne pas générer correctement certaines regles, en particulier pour la chaine POSTROUTING de la table nat. Il y a parfois des différences dans l'application des regles de NAT qui semblent attribués à un traitement trop rapide dans les différentes étapes au lancement du service bastion. Nous avions justement pensé à des interférences avec l'activité de agent rvp, mais d'apres nos tests il y a une autre source de perturbation. Nous n'en avons pas identifié précisément l'origine mais on pense à une interaction avec la relance des services d'agrégation et/ou rvp par le script, peut-être la phase de flush des SNAT du script d'agrégation qui se fait avant ou pendant la génération des regles SNAT de lance.firewall.
En tour cas il s'est avéré que le fait de mettre un timer (5 secondes suffisent à priori) dans le script /etc/init.d/bastion avant les phases du lancement de l'agrégation et de RVP permet d'éviter ce comportement indésirable.
En PJ un exemple des regles appliquées aprés différentes relances du service bastion (ne pas tenir compte des regles "-A POSTROUTING -s 10.4.201.0/25 -d 10.104.201.240/28 -o eth0 -j SNAT --to-source 10.104.201.245", c'est une modif académique pour éviter que le réseau de destination pour la zone d'interco externe ne parte dans les tunnels)
* 2 gateways
* un serveur Amon 2.5.2 configuré avec l'agrégation
Comme je l'évoquais sur la liste de diffusion, je n'ai malheureusement pas pu le proposer à temps pour la sortie de la maj du 23/11 mais en lien avec https://dev-eole.ac-dijon.fr/issues/17579 nous nous sommes aperçu d'un conflit un peu du même ordre.
Nous avons remarqué que l'arret/démarrage/relance du service bastion peut ne pas générer correctement certaines regles, en particulier pour la chaine POSTROUTING de la table nat. Il y a parfois des différences dans l'application des regles de NAT qui semblent attribués à un traitement trop rapide dans les différentes étapes au lancement du service bastion. Nous avions justement pensé à des interférences avec l'activité de agent rvp, mais d'apres nos tests il y a une autre source de perturbation. Nous n'en avons pas identifié précisément l'origine mais on pense à une interaction avec la relance des services d'agrégation et/ou rvp par le script, peut-être la phase de flush des SNAT du script d'agrégation qui se fait avant ou pendant la génération des regles SNAT de lance.firewall.
En tour cas il s'est avéré que le fait de mettre un timer (5 secondes suffisent à priori) dans le script /etc/init.d/bastion avant les phases du lancement de l'agrégation et de RVP permet d'éviter ce comportement indésirable.
En PJ un exemple des regles appliquées aprés différentes relances du service bastion (ne pas tenir compte des regles "-A POSTROUTING -s 10.4.201.0/25 -d 10.104.201.240/28 -o eth0 -j SNAT --to-source 10.104.201.245", c'est une modif académique pour éviter que le réseau de destination pour la zone d'interco externe ne parte dans les tunnels)