Project

General

Profile

Tâche #18328

Distribution EOLE - Scénario #20100: Assistance aux utilisateurs (16-18)

Reproduire le problème d'altération de l'application des regles de pare-feu au démarrage du service bastion

Added by Jean-Marc MELET almost 5 years ago. Updated over 4 years ago.

Status:
Fermé
Priority:
Normal
Assigned To:
-
Start date:
12/09/2016
Due date:
% Done:

100%

Estimated time:
3.00 h
Spent time:
Remaining (hours):
0.0

Description

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)

Exemple regles bastion.txt View (5.3 KB) Jean-Marc MELET, 12/09/2016 05:37 PM

bastion restart.txt View (11.8 KB) Jean-Marc MELET, 04/07/2017 06:14 PM

bastion restart-time.txt View (3.04 KB) Jean-Marc MELET, 04/07/2017 06:15 PM

bastion-modules (128 Bytes) Jean-Marc MELET, 04/07/2017 06:18 PM

agregation.conf View (1.83 KB) Jean-Marc MELET, 04/07/2017 06:18 PM

hosts.allow (210 Bytes) Jean-Marc MELET, 04/07/2017 06:18 PM

inclusion_statique (2.27 KB) Jean-Marc MELET, 04/07/2017 06:18 PM

ipset (1006 Bytes) Jean-Marc MELET, 04/07/2017 06:18 PM

iptables (25.1 KB) Jean-Marc MELET, 04/07/2017 06:18 PM

5zones-AixMars.xml View (52.1 KB) Jean-Marc MELET, 04/10/2017 06:35 PM

config.eol (10.6 KB) Jean-Marc MELET, 04/10/2017 06:35 PM

History

#1 Updated by Fabrice Barconnière almost 5 years ago

  • Status changed from Nouveau to En attente d'informations
  • Assigned To set to Fabrice Barconnière
As-tu remarqué si ça se produit à un moment précis ?
  • au moment du logrotate par exemple (vers 6h25)
  • avec un service bastion restart ?
  • avec un service bastion stop suivi d'un service bastion start ?

#2 Updated by Jean-Marc MELET almost 5 years ago

Oui bien sûr, j'ai reproduit lors de la relance de bastion à la main mais en effet c'est bien lors du logrotate que cela peut se produire automatiquement

#3 Updated by Fabrice Barconnière almost 5 years ago

De quelle façon la relance :
  • restart ou stop + start ?

#4 Updated by Jean-Marc MELET almost 5 years ago

Oupsss pardon j'ai zappé de répondre à cette question.
Oui cela se produit à la fois pour un stop + start et un restart

#5 Updated by Fabrice Barconnière almost 5 years ago

  • Tracker changed from Demande to Tâche
  • Subject changed from Altération possible de l'application des regles de pare-feu au démarrage du service bastion to Reproduire le problème d'altération de l'application des regles de pare-feu au démarrage du service bastion
  • Description updated (diff)
  • Status changed from En attente d'informations to Nouveau
  • Estimated time set to 3.00 h
  • Parent task set to #18394
  • Remaining (hours) set to 3.0

#6 Updated by Olivier FEBWIN over 4 years ago

Mon problème #19686 est certainement le même...

#7 Updated by Jean-Marc MELET over 4 years ago

Hmmm... je ne pense pas à priori.
Le comportement observé dans #19686 doit en effet être la conséquence du correctif #17579 (mais je ne sais pas pourquoi ton service bastion est détecté comme arrêté)
Le problème évoqué dans le signalement présent est de la même nature que #17579 ("conflit" dans l'execution de regles iptables) mais pas pour les même raisons. Comme je le disais il semble s'agir d'une interaction entre des phases du lancement du service bastion (automatique au logrotate ou manuellement). Une temporisation permet d'éviter le problème.

#8 Updated by Fabrice Barconnière over 4 years ago

  • Assigned To deleted (Fabrice Barconnière)

#9 Updated by Fabrice Barconnière over 4 years ago

Bonjour Jean-Marc,

le problème est toujours d'actualité en 2.5.2 ? Même avec la correction #17579 ?

#10 Updated by Fabrice Barconnière over 4 years ago

  • Status changed from Nouveau to En cours

#11 Updated by Fabrice Barconnière over 4 years ago

  • Assigned To set to Fabrice Barconnière

#12 Updated by Fabrice Barconnière over 4 years ago

  • % Done changed from 0 to 50

Test sur une infra etb1.amon avec agrégation en 2.6.1. Le script bastion a été revu (#19422). Le problème ne semble plus se poser. Les règles liées à l'agrégation sont toujours présentes après le logrotate.

#13 Updated by Jean-Marc MELET over 4 years ago

Salut Fabrice,

Oui il me semble l'avoir déja précisé mais le correctif #17579 n'a pas d'effet sur le comportement indésirable exposé dans ce signalement. En effet, le problème n'est pas lié à une interraction entre les service rvp et bastion mais entre différentes phases propres au service bastion.
Je ne peux pas confirmer si cela se reproduit ou pas en 2.6.1 mais en tout cas en 2.5.2 c'est toujours le cas.

#14 Updated by Fabrice Barconnière over 4 years ago

  • % Done changed from 50 to 70
  • Remaining (hours) changed from 3.0 to 2.0

Après analyse, le lock de bastion est mis avant la mise en place des règles iptables de l'agrégation, de la QOS et du VPN.
L'agent Zéphir bastion effectue une sauvegarde des règles qui est susceptible de s'exécuter pendant le restart de bastion au logrotate.
Je n'ai pas réussi à reproduire le problème, mais on pourrait retarder la mise en place du lock après l'agrégation, la QOS et le VPN.
Ainsi, on pourrait ne faire la sauvegarde des règles que si le lock est en place.

#15 Updated by Jean-Marc MELET over 4 years ago

Ca peut être une piste en effet, mais ceci est-il valable uniquement au logrotate? car le problème évoqué se produit à chaque relance de bastion même manuelle.
Sinon tu peux me donner les modifs à apporter pour pouvoir l'expérimenter en maquette et valider ou non cette hypothèse...

#16 Updated by Fabrice Barconnière over 4 years ago

Je t'avais envoyé un mail hier matin avec les modifs, mais si tu reproduis systématiquement le pb en relançant bastion, je ne pense pas que cela règle le problème.
Que donnent (sans le sleep dans bastion):
  • bash -x /etc/init.d/bastion restart ?
  • time /etc/init.d/bastion start ?
Peux-tu me fournir les fichiers suivants s'ils existent :
  • /etc/eole/iptables
  • /etc/eole/bastion-modules
  • /etc/eole/ipset
  • /etc/eole/inclusion_statique
  • /etc/eole/hosts.allow
  • /etc/qoseole.conf
  • /etc/agregation.conf

#17 Updated by Jean-Marc MELET over 4 years ago

Oui j'ai bien eu ton mail, du coup d'apres ta nouvelle réponse je n'ai pas testé la manip.
Tu trouveras les éléments demandés en PJ.

#18 Updated by Fabrice Barconnière over 4 years ago

Bonjour Jean Marc,
J'aurais également besoin du config.eol et du modèle ERA.
Merci

#19 Updated by Fabrice Barconnière over 4 years ago

Dans le fichier Exemple regles bastion.txt , ce sont les règles de SNAT vers eth0 qui disparaissent ?
  • Si c'est ça, c'est le script d'agrégation qui les supprime, ce qui me semble normal mais je ne connais pas toutes les subtilités de l'agrégation.
    Je ne vois pas comment en mettant une tempo de 5s les règles sont toujours là et/ou réapparaissent et/ou ne sont pas supprimées.

#20 Updated by Jean-Marc MELET over 4 years ago

Pas forcément, c'est un peu aléatoire. Parfois c'est des regles de SNAT du marquage des paquets pour les tables T1 et T2 de l'agregation comme celle-ci:
-A POSTROUTING -o eth0 -m mark --mark 0x1 -j SNAT --to-source 10.104.201.245
D'autres fois des regles ACCEPT comme celle-là:
-A POSTROUTING -s 10.4.201.0/25 -d 172.16.0.0/12 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
Ou bien au contraire on peut avoir un reste de regle SNAT présente habituellement sans agrégation encore active comme celle-ci:
-A POSTROUTING -s 10.4.201.0/25 -o eth0 -j SNAT --to-source 10.104.201.245

Oui j'ai bien vu qu'il a été publié certaines évolutions du script d'agrégation qui intègre d'ailleurs certaines de nos adaptations académiques, je dois le tester mais cependant je ne pense que cela règle notre problème qui doit se situer dans l'ordre ou le temps d'éxecution des différentes phases du script, enfin c'est une impression.

Voici les fichiers demandés

A l'occasion je tenterais de suivre un redémarrage en bash -x et de faire le rapprochement avec la génération des regles en temps réel pour tenter de mieux comprendre

#21 Updated by Karim Ayari over 4 years ago

c'est vrai que cela ressemble grandement au signalement #17579 et pourtant tu n'as aucune interface vlan
tu as regardé les log de l'agent RVP ? si au moment où tu constates le problème s'il n'y a pas eut un redémarrage des tunnels ?
tu n'as pas une tonne de règles iptables lancée par un script externe ?

#22 Updated by Fabrice Barconnière over 4 years ago

Il y a une différence entre le contenu du cache (/etc/eole/iptables) et le script généré (/sbin/lance.firewall) ?
Le problème ne se pose qu'avec l'agrégation activée ?

#23 Updated by Fabrice Barconnière over 4 years ago

  • % Done changed from 70 to 90
  • Remaining (hours) changed from 2.0 to 1.0

Si dans le cache, toutes les règles sont présentes, tu peux essayer un script de ce genre pour vérifier si éventuellement les règles mettent un certain temps à se mettre en place :

service bastion stop
ipset restore -exist < /etc/eole/ipset
iptables-restore < /etc/eole/iptables
I=0
while [ $I -lt 5 ]
do
    iptables-save > ipt_save$I
    let I+=1
done

Si on voit évoluer les fichiers ipt_saveX, cela proviendrai alors de iptables-restore qui demanderai un certain délai pour la mise en place des règles.

#24 Updated by Fabrice Barconnière over 4 years ago

  • Status changed from En cours to Nouveau
  • Assigned To deleted (Fabrice Barconnière)
  • Parent task changed from #18394 to #20100

Report sur le prochain sprint dans le scénario assistance car il s'agit d'un cas "isolé" qu'on n'arrive pas à reproduire.

#25 Updated by Fabrice Barconnière over 4 years ago

  • Status changed from Nouveau to Fermé
  • % Done changed from 90 to 100
  • Remaining (hours) changed from 1.0 to 0.0

Je ferme cette tâche.
Une nouvelle demande pourra être ouverte si on a des informations permettant de corriger ce problème.

#26 Updated by Jean-Marc MELET over 4 years ago

Salut à tous les deux,

Désolé j'ai loupé vos réponses et constaté trop tard que le signalement avait été fermé.
Tout d'abord pour répondre à Karim, mes tunnels sont assez stables et il n'y a pas de lien avec d'enventuels redémarrages de tunnels par l'agent rvp.
Ensuite, je n'ai pas une tonne de regles iptables mais en revanche 2 regles qui utilisent un ipset qui contient environ 7000 IP. J'ai évidemment pensé à ça au début, mais le problème persiste si je désactive la génération de ces regles.
Enfin, oui cela ne semble se produire qu'avec l'agrégation activée.

Pour la question du cache d'iptables, ce serait trop fastidieux de comparer chaque regle contenue dans /etc/eole/iptables et /sbin/lance.firewall, par contre on se traine depuis le début une erreur dans le diagnose au niveau du pare-feu dont je ne suis jamais arrivé à comprendre l'origine, cela ne nous gêne pas car tout fonctionne sans problème au niveau des accès.

Ensuite pour répondre à Fabrice, en faisant les essais avec le script proposé, je constate qu'il n'y a aucune différence entre les fichiers ipt_saveX générés. La seule chose à noter c'est qu'ils ne contiennent pas les regles qui utilisent le fameux ipset que l'on a ajouté car pour pouvoir l'intégrer nous avions opté pour ajouter notre ipset dans /usr/share/era/ipset-tor et la condition suivante dans les inclusions statiques de notre modèle:

if [ -e /usr/share/era/ipset-tor ] ; then
. /usr/share/era/ipset-tor > /dev/null
iptables -I OUTPUT -o eth0 -p tcp -m tcp -m set --match-set bastion-tor dst -j DROP
iptables -I FORWARD -o eth0 -p tcp -m tcp -m set --match-set bastion-tor dst -j DROP
fi

Ce qui explique je pense le fait qu'on ne retrouve pas ces 2 regles dans iptables-save avec ce script mais uniquement si on relance complètement bastion.

Quoiqu'il en soit, merci pour y avoir passé du temps.
J'avoue que je serais curieux de trouver une solution à ce problème, ne peut-on pas quand même envisager une tres legere évolution en ajoutant un sleep de 5 s entre les étapes comme évoqué au début du signalement, cela ne ralongerait le lancement du service que de 10 s et permettrait de regler notre problème et éviter peut-être de risquer d'autres phénomènes de bord dans la génération de regles que l'on aurait pas encore détecté?

Also available in: Atom PDF