Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

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/32
Copy to Clipboard Toggle word wrap

Si 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 :

  1. Rechargez la connexion vpn.example.com: 

    # ipsec auto --add vpn.example.com
002 added connection description "vpn.example.com"
    Copy to Clipboard Toggle word wrap

  2. Ensuite, lancez la connexion VPN : 

    # ipsec auto --up vpn.example.com
    Copy to Clipboard Toggle word wrap

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
...
    Copy to Clipboard Toggle word wrap

  • 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
...
    Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap

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)]
...
    Copy to Clipboard Toggle word wrap

  • 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,Ni
    Copy to Clipboard Toggle word wrap

  • Exemple 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_CHOSEN
    Copy to Clipboard Toggle word wrap

    Une 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_UNACCEPTABLE
    Copy to Clipboard Toggle word wrap

  • Exemple 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 proposal
    Copy to Clipboard Toggle word wrap

  • Lors 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:500
    Copy to Clipboard Toggle word wrap

  • Dans 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
    Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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 1380
Copy to Clipboard Toggle word wrap

Traduction 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
…
Copy to Clipboard Toggle word wrap

Le système avec l'adresse 172.16.0.1 a une règle NAT : 

iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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
...
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

Pour afficher un journal en direct pour le service ipsec: 

$ journalctl -f -u ipsec
Copy to Clipboard Toggle word wrap

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.

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat