6.14. Dépannage des configurations VPN IPsec
Les problèmes liés aux configurations de VPN IPsec surviennent le plus souvent pour plusieurs raisons principales. Si vous rencontrez de tels problèmes, vous pouvez vérifier si la cause du problème correspond à l'un des scénarios suivants et appliquer la solution correspondante.
Dépannage de base des connexions
La plupart des problèmes liés aux connexions VPN surviennent lors de nouveaux déploiements, lorsque les administrateurs ont configuré les points d'extrémité avec des options de configuration inadaptées. De même, une configuration fonctionnelle peut soudainement cesser de fonctionner, souvent en raison de valeurs incompatibles nouvellement introduites. Cela peut résulter d'une modification de la configuration par un administrateur. Il se peut également qu'un administrateur ait installé une mise à jour du micrologiciel ou une mise à jour du paquetage avec des valeurs par défaut différentes pour certaines options, telles que les algorithmes de chiffrement.
Pour confirmer qu'une connexion VPN IPsec est établie :
# ipsec trafficstatus
006 #8: "vpn.example.com"[1] 192.0.2.1, type=ESP, add_time=1595296930, inBytes=5999, outBytes=3231, id='@vpn.example.com', lease=100.64.13.5/32Si la sortie est vide ou ne montre pas d'entrée avec le nom de la connexion, le tunnel est rompu.
Vérifier que le problème se situe au niveau de la connexion :
Rechargez la connexion vpn.example.com:
# ipsec auto --add vpn.example.com 002 added connection description "vpn.example.com"Ensuite, lancez la connexion VPN :
# ipsec auto --up vpn.example.com
Problèmes liés au pare-feu
Le problème le plus courant est qu'un pare-feu situé sur l'un des points d'extrémité IPsec ou sur un routeur entre les points d'extrémité bloque tous les paquets IKE (Internet Key Exchange).
Pour IKEv2, une sortie similaire à l'exemple suivant indique un problème avec un pare-feu :
# ipsec auto --up vpn.example.com 181 "vpn.example.com"[1] 192.0.2.2 #15: initiating IKEv2 IKE SA 181 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: sent v2I1, expected v2R1 010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 0.5 seconds for response 010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 1 seconds for response 010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 2 seconds for ...Pour IKEv1, la sortie de la commande d'initiation se présente comme suit :
# ipsec auto --up vpn.example.com 002 "vpn.example.com" #9: initiating Main Mode 102 "vpn.example.com" #9: STATE_MAIN_I1: sent MI1, expecting MR1 010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 0.5 seconds for response 010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 1 seconds for response 010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 2 seconds for response ...
Le protocole IKE, utilisé pour configurer IPsec, étant crypté, l'outil tcpdump ne permet de résoudre qu'un nombre limité de problèmes. Si un pare-feu bloque des paquets IKE ou IPsec, vous pouvez essayer d'en trouver la cause à l'aide de l'utilitaire tcpdump. Cependant, tcpdump ne peut pas diagnostiquer d'autres problèmes liés aux connexions VPN IPsec.
Pour capturer la négociation du VPN et toutes les données cryptées sur l'interface
eth0:# tcpdump -i eth0 -n -n esp or udp port 500 or udp port 4500 or tcp port 4500
Algorithmes, protocoles et politiques inadaptés
Les connexions VPN exigent que les algorithmes IKE, les algorithmes IPsec et les plages d'adresses IP des points d'extrémité correspondent. En cas de non-concordance, la connexion échoue. Si vous identifiez une incohérence à l'aide de l'une des méthodes suivantes, corrigez-la en alignant les algorithmes, les protocoles ou les stratégies.
Si l'extrémité distante n'exécute pas IKE/IPsec, un paquet ICMP l'indique. Par exemple :
# ipsec auto --up vpn.example.com ... 000 "vpn.example.com"[1] 192.0.2.2 #16: ERROR: asynchronous network error report on wlp2s0 (192.0.2.2:500), complainant 198.51.100.1: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)] ...Exemple d'algorithmes IKE non compatibles :
# ipsec auto --up vpn.example.com ... 003 "vpn.example.com"[1] 193.110.157.148 #3: dropping unexpected IKE_SA_INIT message containing NO_PROPOSAL_CHOSEN notification; message payloads: N; missing payloads: SA,KE,NiExemple d'algorithmes IPsec non compatibles :
# ipsec auto --up vpn.example.com ... 182 "vpn.example.com"[1] 193.110.157.148 #5: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_256 group=MODP2048} 002 "vpn.example.com"[1] 193.110.157.148 #6: IKE_AUTH response contained the error notification NO_PROPOSAL_CHOSENUne version IKE inadaptée peut également entraîner l'abandon de la demande par le point d'extrémité distant sans réponse. Cette situation est identique à celle d'un pare-feu qui abandonne tous les paquets IKE.
Exemple de plages d'adresses IP non concordantes pour IKEv2 (appelées sélecteurs de trafic - TS) :
# ipsec auto --up vpn.example.com ... 1v2 "vpn.example.com" #1: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_512 group=MODP2048} 002 "vpn.example.com" #2: IKE_AUTH response contained the error notification TS_UNACCEPTABLEExemple de plages d'adresses IP non concordantes pour IKEv1 :
# ipsec auto --up vpn.example.com ... 031 "vpn.example.com" #2: STATE_QUICK_I1: 60 second timeout exceeded after 0 retransmits. No acceptable response to our first Quick Mode message: perhaps peer likes no proposalLors de l'utilisation de PreSharedKeys (PSK) dans IKEv1, si les deux parties ne mettent pas le même PSK, l'ensemble du message IKE devient illisible :
# ipsec auto --up vpn.example.com ... 003 "vpn.example.com" #1: received Hash Payload does not match computed value 223 "vpn.example.com" #1: sending notification INVALID_HASH_INFORMATION to 192.0.2.23:500Dans le cadre d'IKEv2, l'erreur de mauvaise concordance des paquets se traduit par l'envoi d'un message AUTHENTICATION_FAILED :
# ipsec auto --up vpn.example.com ... 002 "vpn.example.com" #1: IKE SA authentication request rejected by peer: AUTHENTICATION_FAILED
Unité de transmission maximale
Outre les pare-feu qui bloquent les paquets IKE ou IPsec, la cause la plus fréquente des problèmes de réseau est l'augmentation de la taille des paquets cryptés. Le matériel réseau fragmente les paquets dont la taille est supérieure à l'unité de transmission maximale (MTU), par exemple 1500 octets. Souvent, les fragments sont perdus et les paquets ne parviennent pas à se réassembler. Cela entraîne des défaillances intermittentes, lorsqu'un test ping, qui utilise des paquets de petite taille, fonctionne mais que d'autres trafics échouent. Dans ce cas, vous pouvez établir une session SSH, mais le terminal se fige dès que vous l'utilisez, par exemple en entrant la commande 'ls -al /usr' sur l'hôte distant.
Pour contourner le problème, réduisez la taille du MTU en ajoutant l'option mtu=1400 au fichier de configuration du tunnel.
Sinon, pour les connexions TCP, activez une règle iptables qui modifie la valeur MSS :
# iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Si la commande précédente ne résout pas le problème dans votre scénario, spécifiez directement une taille inférieure dans le paramètre set-mss:
# iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380Traduction d'adresses de réseau (NAT)
Lorsqu'un hôte IPsec sert également de routeur NAT, il peut accidentellement remapper des paquets. L'exemple de configuration suivant illustre le problème :
conn myvpn
left=172.16.0.1
leftsubnet=10.0.2.0/24
right=172.16.0.2
rightsubnet=192.168.0.0/16
…Le système avec l'adresse 172.16.0.1 a une règle NAT :
iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
Si le système à l'adresse 10.0.2.33 envoie un paquet à 192.168.0.1, le routeur traduit la source 10.0.2.33 en 172.16.0.1 avant d'appliquer le cryptage IPsec.
Le paquet avec l'adresse source 10.0.2.33 ne correspond plus à la configuration conn myvpn, et IPsec ne crypte pas ce paquet.
Pour résoudre ce problème, insérez des règles qui excluent la NAT pour les plages de sous-réseaux IPsec cibles sur le routeur, dans cet exemple :
iptables -t nat -I POSTROUTING -s 10.0.2.0/24 -d 192.168.0.0/16 -j RETURN
Bogues du sous-système IPsec du noyau
Le sous-système IPsec du noyau peut échouer, par exemple, lorsqu'un bogue provoque une désynchronisation de l'espace utilisateur IKE et du noyau IPsec. Pour vérifier l'existence de tels problèmes, procédez comme suit
$ cat /proc/net/xfrm_stat
XfrmInError 0
XfrmInBufferError 0
...Toute valeur non nulle dans la sortie de la commande précédente indique un problème. Si vous rencontrez ce problème, ouvrez un nouveau dossier d'assistance et joignez la sortie de la commande précédente ainsi que les journaux IKE correspondants.
Bûches Libreswan
Par défaut, Libreswan enregistre les données en utilisant le protocole syslog. Vous pouvez utiliser la commande journalctl pour trouver les entrées du journal relatives à IPsec. Comme les entrées correspondantes dans le journal sont envoyées par le démon IKE de pluto, recherchez le mot-clé "pluto", par exemple :
$ journalctl -b | grep pluto
Pour afficher un journal en direct pour le service ipsec:
$ journalctl -f -u ipsec
Si le niveau de journalisation par défaut ne révèle pas votre problème de configuration, activez les journaux de débogage en ajoutant l'option plutodebug=all à la section config setup du fichier /etc/ipsec.conf.
Notez que la journalisation de débogage produit beaucoup d'entrées et qu'il est possible que le service journald ou syslogd limite le débit des messages syslog. Pour vous assurer d'avoir des journaux complets, redirigez la journalisation vers un fichier. Modifiez le site /etc/ipsec.conf et ajoutez le site logfile=/var/log/pluto.log dans la section config setup.
Ressources supplémentaires
- Résolution des problèmes à l'aide des fichiers journaux.
-
tcpdump(8)etipsec.conf(5). - Utilisation et configuration de firewalld
