Project

General

Profile

Demande #27375

Relancer ipsec dans la commande "bastion regen" sur Amon 2.7.0

Added by Laurent HAEFFELE about 2 years ago. Updated over 1 year ago.

Status:
Fermé
Priority:
Normal
Category:
-
Target version:
-
Start date:
03/25/2019
Due date:
% Done:

100%


Description

Lorsqu'on effectue la commande "bastion regen" sur Amon 2.7.0 ayant un VPN, cela régénère les commandes iptables, mais il manque les règles "* pol ipsec proto 50" ajoutées lors de l'exécution de la commande "ipsec restart".
Cela bloque donc les nouvelles connexions dans le tunnel VPN.

History

#1 Updated by Fabrice Barconnière about 2 years ago

  • Assigned To set to Fabrice Barconnière

C'est normalement le cas.
Le problème peut éventuellement provenir du fait qu le VPN est arrêté après le flush des règles iptables.
Dans ce cas, il semble que strongswan ne s'arrête pas toujours correctement et que les commandes d'arrêt et de redémarrage de ipsec ne fonctionnent plus.
J'ai pu reproduire une fois le problème mais ce n'est pas systématique.
Peux-tu tester en modifiant /usr/sbin/bastion :

--- /usr/sbin/bastion~  2019-03-25 14:51:45.609054503 +0100
+++ /usr/sbin/bastion   2019-03-25 14:51:50.625169336 +0100
@@ -200,6 +200,7 @@
         return 1
     fi
     test_iptables
+    stopother
     /usr/sbin/ferme.firewall $silent
     RETVAL=$?

@@ -209,7 +210,6 @@
     fi

     log_end_msg $RETVAL
-    stopother
     return $RETVAL
 }

#2 Updated by Laurent HAEFFELE about 2 years ago

Cela ne change rien.
En fait, j'ai l'impression que la commande "service strongswan stop" est bien exécutée, mais elle n'arrête pas le service ipsec.
C'est pareil si je tente cela en ligne de commande :

root@0670134g-01:~# ipsec status | grep ESTA | sed 's/\.\.\.[^[]*\[/...W.X.Y.Z[/'
0670134G-01-Sphynx NG 3_1-admin-10[2]: ESTABLISHED 46 minutes ago, 192.168.239.2[C=FR, L=STRASBOURG, O=Education Nationale, OU=Academie de Strasbourg, OU=0002 110043015, CN=0670134G-01.ac-strasbourg.fr]...W.X.Y.Z[C=FR, L=STRASBOURG, O=Education Nationale, OU=Academie de Strasbourg, OU=0002 110043015, CN=sphynx.ac-strasbourg.fr]
root@0670134g-01:~# service strongswan stop
root@0670134g-01:~# ipsec status | grep ESTA | sed 's/\.\.\.[^[]*\[/...W.X.Y.Z[/'
0670134G-01-Sphynx NG 3_1-admin-10[2]: ESTABLISHED 47 minutes ago, 192.168.239.2[C=FR, L=STRASBOURG, O=Education Nationale, OU=Academie de Strasbourg, OU=0002 110043015, CN=0670134G-01.ac-strasbourg.fr]...W.X.Y.Z[C=FR, L=STRASBOURG, O=Education Nationale, OU=Academie de Strasbourg, OU=0002 110043015, CN=sphynx.ac-strasbourg.fr]

A priori, si j'exécute "ipsec stop" suivi de "service strongswan start" alors "service strongswan stop" arrête bien le tunnel.
Par contre, si j'exécute ensuite "ipsec restart", alors "service strongswan stop" n'arrête plus le tunnel.

root@0670134g-01:~# service strongswan status | head -n +8
● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf
   Loaded: loaded (/lib/systemd/system/strongswan.service; disabled; vendor preset: enabled)
   Active: active (running) since Mon 2019-03-25 15:59:37 CET; 51s ago
 Main PID: 19475 (starter)
    Tasks: 34 (limit: 1129)
   CGroup: /system.slice/strongswan.service
           ├─19475 /usr/lib/ipsec/starter --daemon charon --nofork
           └─19484 /usr/lib/ipsec/charon
root@0670134g-01:~# ipsec restart
Stopping strongSwan IPsec...
Starting strongSwan 5.6.2 IPsec [starter]...
root@0670134g-01:~# ipsec status | grep ESTA | sed 's/\.\.\.[^[]*\[/...W.X.Y.Z[/'
Security Associations (1 up, 0 connecting):
0670134G-01-Sphynx NG 3_1-admin-10[1]: ESTABLISHED 6 seconds ago, 192.168.239.2[C=FR, L=STRASBOURG, O=Education Nationale, OU=Academie de Strasbourg, OU=0002 110043015, CN=0670134G-01.ac-strasbourg.fr]...W.X.Y.Z[C=FR, L=STRASBOURG, O=Education Nationale, OU=Academie de Strasbourg, OU=0002 110043015, CN=sphynx.ac-strasbourg.fr]
root@0670134g-01:~# service strongswan stop
root@0670134g-01:~# service strongswan status | head -n +3
● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf
   Loaded: loaded (/lib/systemd/system/strongswan.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

#3 Updated by Fabrice Barconnière about 2 years ago

Je suis tombé sur ce cas avant de modifier /usr/sbin/bastion .
J'ai du killer les process de strongSwan : pkill -f charon

Ensuite, avec la modification proposée de /usr/sbin/bastion je ne suis plus retombé sur ce problème.

#4 Updated by Laurent HAEFFELE about 2 years ago

J'ai bien compris ta solution et j'ai appliqué ton patch, mais cela ne change rien à mon problème.

Lorsqu'on lance la commande ipsec restart, cela casse le service strongswan. La commande service strongswan status retourne alors que le service est arrêté (pourtant le tunnel ipsec fonctionne très bien). Du coup, la commande service strongswan stop (qui est utilisé dans la commande bastion) ne fonctionne plus. Même lancée à la main, cela ne coupe pas le tunnel VPN.

Bref, je pense qu'il faut soit utiliser la commande ipsec restart dans la commande bastion à la place de service strongswan restart ou alors trouver pourquoi ipsec restart casse le service strongswan, ce qui serait encore mieux, ou enfin interdire l'usage de la commande ipsec restart.

Je vais commencer par m'interdire d'utiliser ipsec restart et informer mes collègues.

#5 Updated by Fabrice Barconnière about 2 years ago

En 2.7, c'est systemd qui gère les service. Du coup, utiliser directement ipsec restart doit perturber le fonctionnement du service.

Voici un lien qui explique le problème (avec upstart et systemd) : https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1287339
"do not use "ipsec restart" even with systemd."

#6 Updated by Fabrice Barconnière about 2 years ago

Tu peux me confirmer qu'en utilisant service strongswan restart à la place de ipsec restart on ne perd pas les règles "* pol ipsec proto 50" ?

#7 Updated by Fabrice Barconnière over 1 year ago

  • Status changed from Nouveau to Fermé
  • % Done changed from 0 to 100

Je clôture la demande. C'est Simon Déziel qui a dit de ne pas utiliser la commande ipsec restart "even with systemd".

Also available in: Atom PDF