Distribution EOLE

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.

• 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 ?

Ç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

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

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 !

Cf. fil de discussion sur la liste amon-sphynx