Scénario #15594
Mis à jour par Fabrice Barconnière il y a environ 8 ans
Un tunnel peut se retrouver dans un état où seule une moitié est montée.
Par exemple, sur le serveur Amon le tunnel parait monté, mais sur le serveur Sphynx, le tunnel n'existe pas.
L'agent détecte bien la problème du tunnel non monté, mais comme il n'y a aucune action de la part de l'agent sur Sphynx, le tunnel ne sera pas remonté. L'agent sur Amon, voyant ce tunnel monté, ne fera également aucune action.
Côté Amon, cela pourrait être détecter en pinguant depuis toutes les interfaces concernées par un tunnel.
* strongSwan sait-il gérer ce genre de situation ?
* traiter cette situation dans l'agent Zéphir
** l'agent (test-rvp utilise l'agent) devrait tester le ping depuis toutes interfaces concernées par un tunnel
<pre>
Bonjour,
J'avais évoqué avec Fabrice le fait que l'on a parfois des pbs de vpns de tunnels montés de manière asymétrique (le ping passe dans un sens mais pas dans l'autre). Voici un extrait de ipsec status au moment ou cela se produit.
Coté sphynx :
root@sphynx-adriatic-24:~# ipsec statusall|grep 371418
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic: 195.83.89.137...194.199.244.130 IKEv1/2, dpddelay=120s
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic: local: [C=fr, O=gouv, OU=education, OU=ac-orleans-tours, CN=AGRIATES-ORLEANS-07] uses public key authentication
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic: cert: "C=fr, O=gouv, OU=education, OU=ac-orleans-tours, CN=AGRIATES-ORLEANS-07"
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic: remote: [C=fr, O=gouv, OU=education, OU=ac-orleans-tours, CN=0371418R-03] uses public key authentication
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic: child: 172.16.0.0/13 === 10.37.80.0/24 TUNNEL, dpdaction=clear
sphynx-adriatic-DSI-amon 0371418R_1-pedago1D-adriatic: child: 172.16.0.0/13 === 10.137.80.0/24 TUNNEL, dpdaction=clear
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic[22159]: ESTABLISHED 103 minutes ago, 195.83.89.137[C=fr, O=gouv, OU=education, OU=ac-orleans-tours, CN=AGRIATES-ORLEANS-07]...194.199.244.130[C=fr, O=gouv, OU=education, OU=ac-orleans-tours, CN=0371418R-03]
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic[22159]: IKEv2 SPIs: 8093b2859d27be74_i 4ae97026d4e7f559_r*, public key reauthentication in 60 minutes
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic[22159]: IKE proposal: AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic{36096}: INSTALLED, TUNNEL, ESP SPIs: c28b5515_i c8dfdb40_o
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic{36096}: AES_GCM_16_128, 226730 bytes_i (1652 pkts, 6s ago), 1165744 bytes_o (1434 pkts, 6s ago), rekeying in 27 minutes
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic{36096}: 172.16.0.0/13 === 10.37.80.0/24
root@sphynx-adriatic-24:~#
Coté amon :
root@amon-0371418r:~# ipsec status
Security Associations (2 up, 0 connecting):
amon 0371418R-sphynx-agriates-DSI_1-admin-agr10[2]: ESTABLISHED 101 minutes ago, 194.199.244.130[C=fr, O=gouv, OU=education, OU=ac-orleans-tours, CN=0371418R-02]...195.83.89.136[C=fr, O=gouv, OU=education, OU=ac-orleans-tours, CN=AGRIATES-ORLEANS-06]
amon 0371418R-sphynx-agriates-DSI_1-admin-agr10{2}: INSTALLED, TUNNEL, ESP SPIs: c0c706f4_i c46d6a64_o
amon 0371418R-sphynx-agriates-DSI_1-admin-agr10{2}: 10.37.80.0/24 === 10.0.0.0/8
amon 0371418R-sphynx-agriates-DSI_1-admin-reseau_ader{4}: INSTALLED, TUNNEL, ESP SPIs: c747e71b_i c1b588a9_o
amon 0371418R-sphynx-agriates-DSI_1-admin-reseau_ader{4}: 10.37.80.0/24 === 161.48.0.0/19
amon 0371418R-sphynx-agriates-DSI_1-admin-agr172{5}: INSTALLED, TUNNEL, ESP SPIs: ce678de3_i c73eb2fe_o
amon 0371418R-sphynx-agriates-DSI_1-admin-agr172{5}: 10.37.80.0/24 === 172.24.0.0/13
amon 0371418R-sphynx-adriatic-DSI_1-admin-adriatic[1]: ESTABLISHED 101 minutes ago, 194.199.244.130[C=fr, O=gouv, OU=education, OU=ac-orleans-tours, CN=0371418R-03]...195.83.89.137[C=fr, O=gouv, OU=education, OU=ac-orleans-tours, CN=AGRIATES-ORLEANS-07]
amon 0371418R-sphynx-adriatic-DSI_1-pedago1D-adriatic{3}: INSTALLED, TUNNEL, ESP SPIs: cd8d3cbd_i cd99ff63_o
amon 0371418R-sphynx-adriatic-DSI_1-pedago1D-adriatic{3}: 10.137.80.0/24 === 172.16.0.0/13
amon 0371418R-sphynx-adriatic-DSI_1-admin-adriatic{1}: INSTALLED, TUNNEL, ESP SPIs: c8dfdb40_i c28b5515_o
amon 0371418R-sphynx-adriatic-DSI_1-admin-adriatic{1}: 10.37.80.0/24 === 172.16.0.0/13
root@amon-0371418r:~#
On voit bien que la connexion est "installed" coté amon mais pas coté sphynx.
Pourtant depuis le amon on arrive à pinger la patte interne du sphynx (172.23.255.234 ; c'est l'IP que l'on pinge dans le test-rvp).
A première vue on a du mal voir comment cela peut-être possible vu que le tunnel n'est monté que d'un coté
En y réfléchissant j'ai compris pourquoi le test-rvp était en quelque sorte "biaisé" :
- dans zephir on a forcé l'IP source "émettrice" des flux émis dans le vpn (via la variable sw_force_ip_src) : en l'occurence eth1 chez nous.
- dans le cas présent on voit que le vpn admin<->adriatic est opérationnel ; lorsque l'on pinge 172.23.255.234, la trame icmp part dans ce tunnel (qui est opérationnel) avec comme IP source celle d'eth1 de l'amon. Le test-rvp ne peut donc pas s'apercevoir que le tunnel est tombé...
Pour confirmer mes hypothèses, j'ai effectué un ping -I eth2 afin de forcer le ping à partir avec la bonne IP et là effectivement celui ci ne répond pas alors qu'un ping -I eth1 répond.
Si l'on cherche à pinger depuis le sphynx adriatic vers une IP du réseau pédagogique de l'amon, le flux ne passe pas car il faudrait emprunter le tunnel qui est tombé...
Ce que je n'arrive pas à comprendre c'est pourquoi dans ipsec status, le amon "voit" le tunnel monté alors que le sphynx ne le "voit" pas ?
Comment se fait il que le dead peer detection n'arrive pas à identifier ce pb et y remédier ?
Même si ce cas reste marginal par rapport au problème signalé précédemment (vpns qui tombent et ne remontent pas d'eux mêmes) il est malgré tout bien réel et pose problème.
Merci d'avance,
Olivier
</pre>
Par exemple, sur le serveur Amon le tunnel parait monté, mais sur le serveur Sphynx, le tunnel n'existe pas.
L'agent détecte bien la problème du tunnel non monté, mais comme il n'y a aucune action de la part de l'agent sur Sphynx, le tunnel ne sera pas remonté. L'agent sur Amon, voyant ce tunnel monté, ne fera également aucune action.
Côté Amon, cela pourrait être détecter en pinguant depuis toutes les interfaces concernées par un tunnel.
* strongSwan sait-il gérer ce genre de situation ?
* traiter cette situation dans l'agent Zéphir
** l'agent (test-rvp utilise l'agent) devrait tester le ping depuis toutes interfaces concernées par un tunnel
<pre>
Bonjour,
J'avais évoqué avec Fabrice le fait que l'on a parfois des pbs de vpns de tunnels montés de manière asymétrique (le ping passe dans un sens mais pas dans l'autre). Voici un extrait de ipsec status au moment ou cela se produit.
Coté sphynx :
root@sphynx-adriatic-24:~# ipsec statusall|grep 371418
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic: 195.83.89.137...194.199.244.130 IKEv1/2, dpddelay=120s
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic: local: [C=fr, O=gouv, OU=education, OU=ac-orleans-tours, CN=AGRIATES-ORLEANS-07] uses public key authentication
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic: cert: "C=fr, O=gouv, OU=education, OU=ac-orleans-tours, CN=AGRIATES-ORLEANS-07"
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic: remote: [C=fr, O=gouv, OU=education, OU=ac-orleans-tours, CN=0371418R-03] uses public key authentication
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic: child: 172.16.0.0/13 === 10.37.80.0/24 TUNNEL, dpdaction=clear
sphynx-adriatic-DSI-amon 0371418R_1-pedago1D-adriatic: child: 172.16.0.0/13 === 10.137.80.0/24 TUNNEL, dpdaction=clear
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic[22159]: ESTABLISHED 103 minutes ago, 195.83.89.137[C=fr, O=gouv, OU=education, OU=ac-orleans-tours, CN=AGRIATES-ORLEANS-07]...194.199.244.130[C=fr, O=gouv, OU=education, OU=ac-orleans-tours, CN=0371418R-03]
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic[22159]: IKEv2 SPIs: 8093b2859d27be74_i 4ae97026d4e7f559_r*, public key reauthentication in 60 minutes
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic[22159]: IKE proposal: AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic{36096}: INSTALLED, TUNNEL, ESP SPIs: c28b5515_i c8dfdb40_o
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic{36096}: AES_GCM_16_128, 226730 bytes_i (1652 pkts, 6s ago), 1165744 bytes_o (1434 pkts, 6s ago), rekeying in 27 minutes
sphynx-adriatic-DSI-amon 0371418R_1-admin-adriatic{36096}: 172.16.0.0/13 === 10.37.80.0/24
root@sphynx-adriatic-24:~#
Coté amon :
root@amon-0371418r:~# ipsec status
Security Associations (2 up, 0 connecting):
amon 0371418R-sphynx-agriates-DSI_1-admin-agr10[2]: ESTABLISHED 101 minutes ago, 194.199.244.130[C=fr, O=gouv, OU=education, OU=ac-orleans-tours, CN=0371418R-02]...195.83.89.136[C=fr, O=gouv, OU=education, OU=ac-orleans-tours, CN=AGRIATES-ORLEANS-06]
amon 0371418R-sphynx-agriates-DSI_1-admin-agr10{2}: INSTALLED, TUNNEL, ESP SPIs: c0c706f4_i c46d6a64_o
amon 0371418R-sphynx-agriates-DSI_1-admin-agr10{2}: 10.37.80.0/24 === 10.0.0.0/8
amon 0371418R-sphynx-agriates-DSI_1-admin-reseau_ader{4}: INSTALLED, TUNNEL, ESP SPIs: c747e71b_i c1b588a9_o
amon 0371418R-sphynx-agriates-DSI_1-admin-reseau_ader{4}: 10.37.80.0/24 === 161.48.0.0/19
amon 0371418R-sphynx-agriates-DSI_1-admin-agr172{5}: INSTALLED, TUNNEL, ESP SPIs: ce678de3_i c73eb2fe_o
amon 0371418R-sphynx-agriates-DSI_1-admin-agr172{5}: 10.37.80.0/24 === 172.24.0.0/13
amon 0371418R-sphynx-adriatic-DSI_1-admin-adriatic[1]: ESTABLISHED 101 minutes ago, 194.199.244.130[C=fr, O=gouv, OU=education, OU=ac-orleans-tours, CN=0371418R-03]...195.83.89.137[C=fr, O=gouv, OU=education, OU=ac-orleans-tours, CN=AGRIATES-ORLEANS-07]
amon 0371418R-sphynx-adriatic-DSI_1-pedago1D-adriatic{3}: INSTALLED, TUNNEL, ESP SPIs: cd8d3cbd_i cd99ff63_o
amon 0371418R-sphynx-adriatic-DSI_1-pedago1D-adriatic{3}: 10.137.80.0/24 === 172.16.0.0/13
amon 0371418R-sphynx-adriatic-DSI_1-admin-adriatic{1}: INSTALLED, TUNNEL, ESP SPIs: c8dfdb40_i c28b5515_o
amon 0371418R-sphynx-adriatic-DSI_1-admin-adriatic{1}: 10.37.80.0/24 === 172.16.0.0/13
root@amon-0371418r:~#
On voit bien que la connexion est "installed" coté amon mais pas coté sphynx.
Pourtant depuis le amon on arrive à pinger la patte interne du sphynx (172.23.255.234 ; c'est l'IP que l'on pinge dans le test-rvp).
A première vue on a du mal voir comment cela peut-être possible vu que le tunnel n'est monté que d'un coté
En y réfléchissant j'ai compris pourquoi le test-rvp était en quelque sorte "biaisé" :
- dans zephir on a forcé l'IP source "émettrice" des flux émis dans le vpn (via la variable sw_force_ip_src) : en l'occurence eth1 chez nous.
- dans le cas présent on voit que le vpn admin<->adriatic est opérationnel ; lorsque l'on pinge 172.23.255.234, la trame icmp part dans ce tunnel (qui est opérationnel) avec comme IP source celle d'eth1 de l'amon. Le test-rvp ne peut donc pas s'apercevoir que le tunnel est tombé...
Pour confirmer mes hypothèses, j'ai effectué un ping -I eth2 afin de forcer le ping à partir avec la bonne IP et là effectivement celui ci ne répond pas alors qu'un ping -I eth1 répond.
Si l'on cherche à pinger depuis le sphynx adriatic vers une IP du réseau pédagogique de l'amon, le flux ne passe pas car il faudrait emprunter le tunnel qui est tombé...
Ce que je n'arrive pas à comprendre c'est pourquoi dans ipsec status, le amon "voit" le tunnel monté alors que le sphynx ne le "voit" pas ?
Comment se fait il que le dead peer detection n'arrive pas à identifier ce pb et y remédier ?
Même si ce cas reste marginal par rapport au problème signalé précédemment (vpns qui tombent et ne remontent pas d'eux mêmes) il est malgré tout bien réel et pose problème.
Merci d'avance,
Olivier
</pre>