Project

General

Profile

Scénario #24233

amon 2.6.2 : possible pb avec l'ipsec

Added by Valery CERETUS over 1 year ago. Updated 4 days ago.

Status:
Terminé (Sprint)
Priority:
Normal
Category:
-
Start date:
08/20/2019
Due date:
09/20/2019
% Done:

100%

Estimated time:
6.00 h (Total: 14.00 h)
Spent time:
9.50 h (Total: 16.00 h)
Story points:
8.0
Remaining (hours):
0.00 hour
Velocity based estimate:
3 days
Release:
Release relationship:
Auto

Description

Bonjour,

Depuis la bascule (une nouvelle install et non un upgrade) des eple de notre académie en amon 2.6.2, beaucoup d'entre eux se plaignent de déconnexions intempestives, de coupures de réseaux ...
Après investigation dans un lycée, il s'avère que les soucis interviennent dès qu'il y a un peu trop de coupures internet.
Symptômes :
- dans l'établissement, la plupart des réseaux internes ne peuvent sortir sur internet et même pinguer la patte de l'amon.
- depuis le rectorat, on peut se connecter via l'ip publique sur l'amon et le diagnose indique que tout est OK. Toutefois, quand un AED pingue la passerelle de l'amon, un tcpdump montre que le ping arrive sur l'interface mais que l'amon ne répond pas. Or le firewall est actif et les règles correctes.
Qu'est-ce qui pourrait entrainer une action dès que l'internet ne passe plus sur l'amon ? J'ai pensé au script magic-rvp.
Même s'il n'existe plus, il y a tout de même un agent zephir qui scrute le vpn et le relance en cas de défaut.
La version courte : dans /usr/share/zephir/monitor/actions/eole/rvp.actions, l'agent effectue un service strongswan restart
Le problème viendrait du stop car il ne ferait que de killer le process ipsec. Or celui-ci a lancé (au start) ipsec_updown qui a aussi lancé ip_xfrm_policy.
Au niveau des réseaux ne pouvant plus sortir, leurs directives xfrm policy étaient incomplètes ou manquantes.
En ajoutant à la main des directives xfrm policy concernant un réseau, le ping de la passerelle était OK et ce réseau pouvait de nouveau sortir.

Pour y remédier, dans /lib/systemd/system/strongswan.service, j'ai remplacé

ExecStopPost=/bin/rm -f /var/run/charon.pid /var/run/starter.charon.pid

par
ExecStopPost=-/bin/rm -f /var/run/charon.pid /var/run/starter.charon.pid
ExecStopPost=-/bin/ip xfrm policy flush

Le problème a pu être reproduit sur une plateforme VMware de notre rectorat.

Cordialement.

rvp.actions (972 Bytes) Fabrice Barconnière, 06/19/2018 02:10 PM


Subtasks

Tâche #28929: Vérifier le comportement avec un Amon et un Sphynx 2.7.1FerméFabrice Barconnière

Tâche #28953: Revoir l'agent Zéphir rvp en 2.6.2 pour tester les xfrm policiesFerméFabrice Barconnière

History

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

  • Description updated (diff)
  • Parent task set to #23987

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

  • Project changed from Amon to Distribution EOLE
  • Status changed from Nouveau to En cours

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

  • Description updated (diff)
  • Assigned To set to Fabrice Barconnière
  • Estimated time set to 6.00 h
  • Remaining (hours) set to 6.0

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

Bonjour,

Pouvez-vous tester l'action de l'agent Zéphir modifiée et sans modifier /lib/systemd/system/strongswan.service?

  • Remplacer le fichier /usr/share/zephir/monitor/actions/eole/rvp.actions par celui-ci : rvp.actions
  • Relancer le service z_stats

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

Après avoir regardé de plus près, je ne pense pas que la modification de l'action de l'agent RVP change quelquechose. Le restart fait un stop suivi d'un start.
Enfin bon, le stop est censé supprimer les directives xfrm policy.

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

Je reproduis un problème similaire comme ceci:
  • Depuis un Horus en admin : ping interface 1 d'Amon
  • Tunnels OK entre Amon et Sphynx (admin-reseau_eth1 + admin-reseau_10)
    • C'est le tunnel admin (qui est en 10.x.y.x) avec le réseau 10.0.0.0/8 qui entraîne cette situation
      • On pourrait éviter le problème en ne déclarant que des tunnels vers des réseaux plus ciblés et n'interférant pas avec le réseau admin
  • Couper sauvagement Sphynx (Éteindre forcé sur OpenNebula par exemple)
  • Sur Amon, redémarrer z_stats -> restart de strongswan
    • les tunnels ne se montent pas
      root@amon:~# ipsec statusall
      [...]
      Security Associations (0 up, 1 connecting):
      etb1.amon-default-2.6.2-aca.sphynx-default-2.6.2_1-T2[1]: CONNECTING, 192.168.0.31[%any]...192.168.0.11[%any]
      etb1.amon-default-2.6.2-aca.sphynx-default-2.6.2_1-T2[1]: IKEv2 SPIs: 0d9bd667657fc050_i* 0000000000000000_r
      [...]
      root@amon:~# ip xfrm policy                                                                                                            
      src 0.0.0.0/0 dst 0.0.0.0/0 
              socket in priority 0 
      src 0.0.0.0/0 dst 0.0.0.0/0 
              socket out priority 0 
      src 0.0.0.0/0 dst 0.0.0.0/0 
              socket in priority 0 
      src 0.0.0.0/0 dst 0.0.0.0/0 
              socket out priority 0 
      src ::/0 dst ::/0 
              socket in priority 0 
      src ::/0 dst ::/0 
              socket out priority 0 
      src ::/0 dst ::/0 
              socket in priority 0 
      src ::/0 dst ::/0 
              socket out priority 0 
      
  • Redémarrer Sphynx et attendre qu'il soit prêt
  • Les tunnels remontent pendant quelques secondes
    On se retrouve dans cette situation avec les directives xfrm policy correctes :
    root@amon:~# ipsec statusall
    [...]
    Security Associations (1 up, 1 connecting):
    etb1.amon-default-2.6.2-aca.sphynx-default-2.6.2_1-T2[2]: ESTABLISHED 3 seconds ago, 192.168.0.31[C=FR, L=Dijon, O=Education Nationale,
     OU=0002 110043015, CN=amon262.ac-test.fr]...192.168.0.11[C=FR, L=Dijon, O=Education Nationale, OU=0002 110043015, CN=sphynx]
    etb1.amon-default-2.6.2-aca.sphynx-default-2.6.2_1-T2[2]: IKEv2 SPIs: 140b8e1630f23bc1_i 42f0e79f735b004a_r*, public key reauthenticati
    on in 2 hours
    etb1.amon-default-2.6.2-aca.sphynx-default-2.6.2_1-T2[2]: IKE proposal: AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
    etb1.amon-default-2.6.2-aca.sphynx-default-2.6.2_1-T2{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c1bebef1_i cc575a1e_o
    etb1.amon-default-2.6.2-aca.sphynx-default-2.6.2_1-T2{1}:  AES_GCM_16_128, 0 bytes_i, 0 bytes_o, rekeying in 46 minutes
    etb1.amon-default-2.6.2-aca.sphynx-default-2.6.2_1-T2{1}:   10.1.1.0/24 === 10.0.0.0/8
    etb1.amon-default-2.6.2-aca.sphynx-default-2.6.2_1-T1{2}:  INSTALLED, TUNNEL, reqid 2, ESP SPIs: cdcfd934_i c7fc3370_o
    etb1.amon-default-2.6.2-aca.sphynx-default-2.6.2_1-T1{2}:  AES_GCM_16_128, 0 bytes_i, 0 bytes_o, rekeying in 46 minutes
    etb1.amon-default-2.6.2-aca.sphynx-default-2.6.2_1-T1{2}:   10.1.1.0/24 === 172.30.101.0/24
    etb1.amon-default-2.6.2-aca.sphynx-default-2.6.2_1-T2[1]: CONNECTING, 192.168.0.31[%any]...192.168.0.11[%any]
    etb1.amon-default-2.6.2-aca.sphynx-default-2.6.2_1-T2[1]: IKEv2 SPIs: 0d9bd667657fc050_i* 0000000000000000_r
    [...]
    root@amon:~# ip xfrm policy
    src 172.30.101.0/24 dst 10.1.1.0/24 
            dir fwd priority 2883 
            tmpl src 192.168.0.11 dst 192.168.0.31
                    proto esp reqid 2 mode tunnel
    src 172.30.101.0/24 dst 10.1.1.0/24 
            dir in priority 2883 
            tmpl src 192.168.0.11 dst 192.168.0.31
                    proto esp reqid 2 mode tunnel
    src 10.1.1.0/24 dst 172.30.101.0/24 
            dir out priority 2883 
            tmpl src 192.168.0.31 dst 192.168.0.11
                    proto esp reqid 2 mode tunnel
    src 10.1.3.0/24 dst 10.1.3.0/24 
            dir fwd priority 0 
    src 10.1.3.0/24 dst 10.1.3.0/24
    [...]
    
  • Après quelque secondes, les directives xfrm policy sont supprimées
    • Le ping depuis Horus ne répond plus
    • On trouve ceci dans les logs d'Amon /var/log/rsyslog/local/charon/ charon.info.log
      DELETE?????
      
    • Explication:
      • La connexion en status CONNECTING est supprimée
      • Du coup, le script ipsec_updown est appelé avec le paramètre down-client ce qui entraîne l'exécution de /etc/ipsec.d/ip_xfrm_policy delete
      • La connexion ESTABLISHED uniquement avec les directives xfrm policy de base
        src 172.30.101.0/24 dst 10.1.1.0/24 
                dir fwd priority 2883 
                tmpl src 192.168.0.11 dst 192.168.0.31
                        proto esp reqid 2 mode tunnel
        src 172.30.101.0/24 dst 10.1.1.0/24 
                dir in priority 2883 
                tmpl src 192.168.0.11 dst 192.168.0.31
                        proto esp reqid 2 mode tunnel
        src 10.1.1.0/24 dst 172.30.101.0/24 
                dir out priority 2883 
                tmpl src 192.168.0.31 dst 192.168.0.11
                        proto esp reqid 2 mode tunnel
        src 10.0.0.0/8 dst 10.1.1.0/24 
                dir fwd priority 2947 
                tmpl src 192.168.0.11 dst 192.168.0.31
                        proto esp reqid 1 mode tunnel
        src 10.0.0.0/8 dst 10.1.1.0/24 
                dir in priority 2947 
                tmpl src 192.168.0.11 dst 192.168.0.31
                        proto esp reqid 1 mode tunnel
        src 10.1.1.0/24 dst 10.0.0.0/8 
                dir out priority 2947 
                tmpl src 192.168.0.31 dst 192.168.0.11
                        proto esp reqid 1 mode tunnel
        
  • Comment faire en sorte que ces directives ne soient pas supprimées dans cette situation ?

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

Ça semble venir de là : https://wiki.strongswan.org/issues/853
En 2.6.2, Ubuntu fournit strongSwan en v5.3.5 mais le bug n'est corrigé qu'en v5.4.0 : https://wiki.strongswan.org/versions/61

Faire un test avec strongSwan >=5.4.0
ou recompiler la 5.3.5 avec ce patch https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=4d7f9a81ac575207edb6bb69f8bbea8762feab96

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

  • Release set to EOLE 2.6.2.1

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

  • Assigned To deleted (Fabrice Barconnière)

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

  • Parent task deleted (#23987)

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

  • Tracker changed from Tâche to Scénario
  • Status changed from En cours to Nouveau
  • Target version deleted (sprint 2018 23-25 Equipe MENSR)
  • Start date deleted (06/18/2018)

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

Même problème sur EOLE 2.7.0 (strongSwan 5.6.2)

#13 Updated by Fabrice Barconnière about 1 year ago

  • Story points set to 8.0

#14 Updated by Daniel Dehennin about 1 year ago

  • Release changed from EOLE 2.6.2.1 to EOLE 2.6.2.2

#15 Updated by Valery CERETUS 4 months ago

Rebonjour,

le souci est toujours d'actualité et bloquant.
Une petite idée à valider : vu que le souci n'intervient que quand il y a un pb d'internet, ne serait-il pas plus simple de relancer le VPN si et seulement si on est sûr qu'internet fonctionne et que l'ip publique du Sphynx est joignable.
Pourquoi ces deux conditions ?
- internet fonctionne : cela ne sert à rien de relancer à l'infini un VPN s'il y a un souci pour sortir sur internet !!!
- Sphynx joignable : on vérifie à minima que le Sphynx est disponible. Cela nous est arrivé cette année d'avoir un souci sur la liaison internet du rectorat, et avec le bug en cours sur les amon, tous nos eple ont eu des problèmes pour accéder à leur propre lan !

#16 Updated by Gilles Grandgérard about 1 month ago

  • Due date set to 09/20/2019
  • Target version set to sprint 2019 36-38 Equipe MENSR
  • Start date set to 08/20/2019

#17 Updated by Joël Cuissinat 17 days ago

  • Release changed from EOLE 2.6.2.2 to EOLE 2.7.1.1

#18 Updated by Fabrice Barconnière 15 days ago

  • Assigned To set to Fabrice Barconnière

#19 Updated by Joël Cuissinat 4 days ago

Cf. fil de discussion sur la liste amon-sphynx

#20 Updated by Joël Cuissinat 4 days ago

  • Status changed from Nouveau to Terminé (Sprint)

Also available in: Atom PDF