Demande #27375
Relancer ipsec dans la commande "bastion regen" sur Amon 2.7.0
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.
Historique
#1 Mis à jour par Fabrice Barconnière il y a environ 5 ans
- Assigné à mis à 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 Mis à jour par Laurent HAEFFELE il y a environ 5 ans
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 Mis à jour par Fabrice Barconnière il y a environ 5 ans
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 Mis à jour par Laurent HAEFFELE il y a environ 5 ans
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 Mis à jour par Fabrice Barconnière il y a environ 5 ans
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 Mis à jour par Fabrice Barconnière il y a environ 5 ans
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 Mis à jour par Fabrice Barconnière il y a plus de 4 ans
- Statut changé de Nouveau à Fermé
- % réalisé changé de 0 à 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".