Tous les produits
Search
Centre de documentation

VPN Gateway:FAQ sur les connexions SSL-VPN

Dernière mise à jour :Aug 10, 2026

Cette rubrique vous aide à résoudre les problèmes courants liés aux connexions SSL-VPN, tels que les échecs de connexion client et les problèmes de transfert de trafic.

Liens rapides vers les problèmes courants

Problèmes de connexion du client

Problèmes de connectivité SSL-VPN

Problème d'authentification à deux facteurs

Puis-je sélectionner une instance IDaaS appartenant à un autre compte Alibaba Cloud lors de la configuration de l'authentification à deux facteurs ?

Non. Vous pouvez uniquement sélectionner une instance IDaaS au sein de votre propre compte Alibaba Cloud.

Échec de connexion du client

Ce tableau décrit les causes possibles et les solutions.

Catégorie

Cause

Solution

Erreur de configuration

Le serveur SSL ou le client est mal configuré.

  1. Vérifiez la configuration du Local CIDR Block du serveur SSL. Assurez-vous que le bloc CIDR du VPC cible est ajouté au Local CIDR Block. Pour plus d'informations, consultez Modifier un serveur SSL.

  2. Vérifiez que le logiciel VPN sur le client est correctement configuré. Pour plus d'informations sur la configuration d'un client, consultez Configurer un client.

Certificat client SSL expiré

Le certificat client SSL est expiré ou invalide.

  1. Vérifiez la validité du certificat client SSL.

    Par défaut, un certificat client SSL est valide pendant trois ans.

  2. Supprimez le certificat client SSL existant et toutes ses configurations. Ensuite, téléchargez et installez un nouveau certificat client SSL.

    Vous devez retélécharger et réinstaller le certificat client SSL après avoir activé ou désactivé l'authentification à deux facteurs, ou après avoir modifié la configuration du serveur SSL. Pour plus d'informations, consultez Télécharger un certificat client SSL.

Limite de connexion dépassée

Le nombre de clients connectés au serveur SSL dépasse la limite.

  1. Vérifiez si le nombre de clients connectés à l'instance VPN Gateway dépasse la limite.

  2. Modifiez le Protocol du serveur SSL en TCP. Ensuite, retéléchargez et installez le certificat client SSL. Pour plus d'informations, consultez Modifier un serveur SSL et Télécharger un certificat client SSL.

    Utilisez TCP pour une meilleure fiabilité. En tant que protocole non fiable, UDP peut entraîner l'occupation des emplacements de connexion par des connexions instables.

Problème d'adresse IP

Le bloc CIDR du VPC chevauche le bloc CIDR du client.

Modifiez le Local CIDR Block (le bloc CIDR du VPC ou du vSwitch) ou le Client CIDR Block du serveur SSL pour éviter les conflits d'adresses IP. Pour plus d'informations, consultez Modifier un serveur SSL.

Le Client CIDR Block du serveur SSL est trop petit. Par conséquent, aucune adresse IP ne peut être allouée aux clients.

Assurez-vous que le nombre d'adresses IP dans le bloc CIDR client spécifié est au moins quatre fois supérieur au nombre maximal de connexions SSL-VPN. Pour plus d'informations, consultez Créer et gérer un serveur SSL.

Par exemple, si vous spécifiez 192.168.0.0/24 comme bloc CIDR client, le système divise d'abord un sous-réseau avec un masque de sous-réseau de 30 à partir de 192.168.0.0/24, tel que 192.168.0.4/30. Ce sous-réseau fournit jusqu'à quatre adresses IP. Ensuite, le système attribue une adresse IP issue de 192.168.0.4/30 au client et utilise les trois autres adresses IP pour assurer la communication réseau. Dans ce cas, un client consomme quatre adresses IP. Par conséquent, pour garantir qu'une adresse IP puisse être attribuée à votre client, vous devez vous assurer que le nombre d'adresses IP dans le bloc CIDR client est au moins quatre fois supérieur au nombre maximal de connexions SSL-VPN prises en charge par la passerelle VPN associée.

Problème de logiciel VPN

Un conflit de logiciel VPN se produit sur le client.

  1. Si plusieurs applications VPN sont installées sur votre client, nous vous recommandons d'en utiliser une seule pour établir la connexion SSL-VPN.

  2. Essayez de redémarrer le client ou de réinstaller le logiciel VPN. Pour plus d'informations, consultez Configurer un client.

Autre

La cause n'est pas répertoriée ci-dessus.

Consultez les journaux de la connexion SSL-VPN pour résoudre l'échec. Pour plus d'informations, consultez Résoudre les problèmes de connexion SSL-VPN.

Déconnexions intermittentes

Ce tableau décrit les causes possibles et les solutions.

Catégorie

Cause

Solution

Réseau public peu fiable

Une mauvaise qualité du réseau public entre le client et la VPN Gateway entraîne des déconnexions intermittentes.

Sur le client, exécutez la commande ping ou mtr pour tester la qualité du réseau depuis le client vers l'adresse IP publique de la VPN Gateway.

Si la qualité du réseau est médiocre (par exemple, latence élevée ou perte de paquets), contactez votre fournisseur d'accès Internet (FAI) pour obtenir de l'aide.

Les connexions SSL-VPN longue distance, par exemple des États-Unis (Silicon Valley) à Singapour, peuvent subir des déconnexions intermittentes lorsque le client accède au VPC.

Modifiez le Protocol du serveur SSL en TCP pour une meilleure fiabilité. Pour plus d'informations, consultez Modifier un serveur SSL.

Si le problème persiste après avoir changé le Protocol en TCP, nous vous recommandons d'utiliser Cloud Enterprise Network (CEN) et Smart Access Gateway (SAG) pour connecter le client au VPC.

Modification de la configuration du serveur SSL

Le client se déconnecte car la configuration du serveur SSL a été modifiée.

Après avoir modifié la configuration du serveur SSL, reconnectez le client.

Connexion partielle des clients

Ce tableau décrit les causes possibles et les solutions.

Catégorie

Cause

Solution

Réseau public peu fiable

Les connexions SSL-VPN longue distance, par exemple des États-Unis (Silicon Valley) à Singapour, peuvent subir des déconnexions intermittentes lorsque le client accède au VPC.

Modifiez le Protocol du serveur SSL en TCP pour une meilleure fiabilité. Pour plus d'informations, consultez Modifier un serveur SSL.

Si vous utilisez une connexion SSL-VPN pour une communication longue distance, par exemple des États-Unis (Silicon Valley) à Singapour, et que le problème persiste après avoir changé le Protocol en TCP, nous vous recommandons d'utiliser Cloud Enterprise Network et Smart Access Gateway pour connecter votre client au VPC.

Limite de connexion dépassée

Le nombre de clients connectés au serveur SSL dépasse la limite.

  1. Vérifiez si le nombre de clients connectés à l'instance VPN Gateway dépasse la limite.

  2. Modifiez le Protocol du serveur SSL en TCP. Ensuite, retéléchargez et installez le certificat client SSL. Pour plus d'informations, consultez Modifier un serveur SSL et Télécharger un certificat client SSL.

    Utilisez TCP pour une meilleure fiabilité. En tant que protocole non fiable, UDP peut entraîner l'occupation des emplacements de connexion par des connexions instables.

Problème côté client

Le client ne parvient pas à se connecter car le client ou le logiciel VPN ne fonctionne pas comme prévu.

Essayez de redémarrer le client, ou réinstallez et reconfigurez le logiciel VPN. Pour plus d'informations sur l'installation et la configuration du logiciel VPN, consultez Configurer un client.

Désynchronisation de l'heure

La différence d'heure entre le client et le serveur SSL est trop importante, ce qui entraîne l'échec de la vérification SSL.

La différence d'heure entre le client et le serveur SSL ne doit pas dépasser 10 minutes. Ajustez l'heure du client pour la synchroniser avec une source de temps standard.

  1. Vérifiez l'heure actuelle sur le client.

    Par exemple, sur un système d'exploitation Linux, exécutez la commande date pour afficher l'heure actuelle. Si elle diffère significativement de l'heure standard, vous devez l'ajuster.

  2. Synchronisez l'heure à l'aide d'un service NTP (Network Time Protocol).

    Par exemple, sur un système d'exploitation Linux, exécutez les commandes suivantes pour synchroniser l'heure :

    yum install -y ntp    # Install the NTP service.
    ntpdate pool.ntp.org  # Synchronize the time.
    date                  # Check whether the time is synchronized.

Échec du ping après la connexion

Ce tableau décrit les causes possibles et les solutions.

Cause

Solution

La politique de contrôle d'accès de l'application cliente bloque les requêtes ping.

Vérifiez si la politique de contrôle d'accès de l'application cliente bloque les requêtes ping. Si c'est le cas, modifiez la politique de contrôle d'accès. Pour plus d'informations, consultez le guide d'utilisation du client.

Par défaut, le pare-feu d'un système d'exploitation Windows bloque les requêtes ping. Vous devez modifier la règle entrante du pare-feu pour autoriser ICMPv4-In.

Le pare-feu du système d'exploitation sur l'instance ECS de destination bloque les paquets ICMP.

Si les entrées de routage sur le client sont correctes (vous pouvez voir la route vers le bloc CIDR du VPC en exécutant route print ou ip route), mais que vous ne pouvez toujours pas effectuer de ping sur l'instance ECS dans le VPC, vérifiez les paramètres du pare-feu du système d'exploitation sur l'instance ECS de destination :

  1. Vérifiez l'état de firewalld : Exécutez systemctl status firewalld. Si la sortie affiche active (running), le pare-feu est actif.

  2. Affichez les détails du pare-feu : Exécutez firewall-cmd --list-all. Vérifiez si le champ icmp-blocks contient echo-request.

  3. Désactivez temporairement le pare-feu pour vérification : Exécutez systemctl stop firewalld et essayez de faire un ping à nouveau. Si le ping réussit, le problème est causé par firewalld.

  4. Vérifiez les règles iptables : Exécutez iptables -L INPUT -n pour vérifier s'il existe des règles DROP ou REJECT pour ICMP.

  5. Vérifiez SELinux : Exécutez getenforce. Si c'est Enforcing, vous pouvez le définir temporairement sur Permissive en exécutant setenforce 0 pour vérifier si SELinux est la cause.

  6. Vérifiez que la liste de contrôle d'accès réseau (ACL) pour le vSwitch de l'instance autorise le trafic ICMP via ses règles entrantes et sortantes.

Remarque

Après avoir confirmé que le pare-feu est la cause racine, nous vous recommandons d'ajouter une règle d'autorisation au lieu de laisser le pare-feu désactivé. Par exemple, exécutez firewall-cmd --permanent --add-rich-rule='rule protocol value="icmp" accept' puis exécutez firewall-cmd --reload pour appliquer la règle.

Problèmes de ping unidirectionnel

Ce tableau décrit les causes possibles et les solutions.

Scénario

Cause

Solution

Un client peut utiliser avec succès la commande ping pour accéder au VPC, mais le VPC échoue lorsqu'il utilise ping pour accéder au client.

La politique de contrôle d'accès de l'application cliente bloque les requêtes ping.

Vérifiez si la politique de contrôle d'accès de l'application cliente bloque les requêtes ping. Si c'est le cas, modifiez la politique de contrôle d'accès. Pour plus d'informations, consultez le guide d'utilisation du client.

Par défaut, le pare-feu d'un système d'exploitation Windows bloque les requêtes ping. Vous devez modifier la règle entrante du pare-feu pour autoriser ICMPv4-In.

L'utilisation de ping pour accéder au client depuis le VPC réussit, mais l'utilisation de la commande ping pour accéder au VPC depuis le client échoue.

Les chemins de trafic sortant et de retour entre le client et le VPC sont différents.

  1. Si vous utilisez Cloud Enterprise Network (CEN) dans votre réseau, vérifiez les configurations de routage de tous les nœuds de transfert entre le client et le VPC. Assurez-vous que le trafic entre le client et le VPC suit le même chemin dans les deux sens.

  2. Vérifiez si la ressource VPC, telle qu'une instance ECS, possède une adresse IP publique. Si la ressource possède une adresse IP publique et que l'adresse IP de destination pour le trafic du VPC vers le client est une adresse IP publique, le trafic peut être acheminé via Internet plutôt que via le réseau privé.

Le ping fonctionne mais l'accès aux applications échoue

Ce tableau décrit les causes possibles et les solutions.

Cause

Solution

Le client n'a pas de route vers le serveur DNS, donc la résolution de noms de domaine est indisponible.

  1. Ajoutez le bloc CIDR du serveur DNS au Local CIDR Block du serveur SSL afin que le client puisse apprendre la route vers le serveur DNS.

    Par exemple, si vous utilisez Alibaba Cloud DNS PrivateZone pour la gestion des noms de domaine, vous pouvez ajouter 100.100.2.136/32 et 100.100.2.138/32 au Local CIDR Block du serveur SSL. De cette façon, le client peut utiliser le service de résolution de noms de domaine.

  2. Sur le client, exécutez la commande ping ou mtr pour tester la connectivité à l'application. Si la connexion est normale, la connexion SSL-VPN, le client, le serveur et les routes fonctionnent comme prévu. Dans ce cas, vous devez effectuer un dépannage supplémentaire en fonction des services cloud déployés et de l'application.

Échec d'accès aux ressources

Ce tableau décrit les causes possibles et les solutions.

Catégorie

Cause

Solution

Problème de routage

Le Local CIDR Block du serveur SSL n'est pas spécifié ou est mal configuré.

  1. Vérifiez la configuration du Local CIDR Block du serveur SSL. Assurez-vous que le bloc CIDR auquel le client doit accéder est correctement ajouté au Local CIDR Block du serveur SSL. Pour plus d'informations, consultez Modifier un serveur SSL.

  2. Vérifiez que le client a reçu les routes vers le Local CIDR Block du serveur SSL.

    • Sur un client Windows, exécutez la commande ipconfig pour afficher l'adresse IP attribuée au client. Ensuite, exécutez la commande route print pour vérifier que le client a reçu les routes vers le Local CIDR Block du serveur SSL.

    • Sur un client Linux, exécutez la commande ifconfig pour afficher l'adresse IP attribuée au client. Ensuite, exécutez la commande ip route show all pour vérifier que le client a reçu les routes vers le Local CIDR Block du serveur SSL.

Problème de configuration du bloc CIDR

Le Local CIDR Block chevauche le Client CIDR Block du serveur SSL.

Vérifiez la configuration du serveur SSL. Assurez-vous que le Local CIDR Block et le Client CIDR Block ne se chevauchent pas. Pour plus d'informations, consultez Modifier un serveur SSL.

Le Destination CIDR Block d'une entrée de route pour une connexion IPsec-VPN sur la même VPN Gateway entre en conflit avec le Client CIDR Block du serveur SSL.

Modifiez l'entrée de route pour la connexion IPsec-VPN vers une route plus spécifique, ou changez le Client CIDR Block du serveur SSL vers un autre bloc CIDR. Cela évite que le Destination CIDR Block n'entre en conflit avec le Client CIDR Block. Pour plus d'informations, consultez Modifier une route basée sur une politique, Modifier une route basée sur la destination ou Modifier un serveur SSL.

Problème de règle de groupe de sécurité

Les règles de groupe de sécurité de l'application VPC ou les politiques de contrôle d'accès de l'application cliente n'autorisent pas la communication entre le client et le VPC.

  1. Vérifiez les règles de groupe de sécurité de l'application VPC. Assurez-vous que les règles de groupe de sécurité autorisent le trafic entre le client et le VPC. Pour plus d'informations, consultez Afficher les règles de groupe de sécurité et Ajouter une règle de groupe de sécurité.

  2. Vérifiez les politiques de contrôle d'accès de l'application cliente. Assurez-vous que les politiques de contrôle d'accès autorisent le trafic entre le client et le VPC.

Problème de logiciel VPN

Des versions incompatibles d'OpenVPN sur le client (trop anciennes ou trop récentes) peuvent empêcher le client de recevoir ou de traiter les paquets de réponse de la VPN Gateway.

Par exemple, un client Windows ayant OpenVPN 2.6.6 installé peut échouer à effectuer un ping sur les ressources cloud.

Nous vous recommandons de télécharger et d'utiliser la version d'OpenVPN fournie dans la documentation de VPN Gateway. Pour plus d'informations, consultez Configurer un client.

Perte de paquets après la connexion

Ce tableau décrit les causes possibles et les solutions.

Catégorie

Cause

Solution

Problème de spécification de la VPN Gateway

Une pointe de trafic dépasse la bande passante de l'instance VPN Gateway.

Vérifiez les données de surveillance du trafic de l'instance VPN Gateway dans la console VPN Gateway pour détecter les pointes de trafic.

Vous pouvez mettre à niveau l'instance VPN Gateway. Pour plus d'informations, consultez Mettre à niveau ou renouveler une passerelle VPN.

Configuration du serveur SSL

Le serveur SSL utilise UDP, un protocole non fiable, pour établir une connexion SSL-VPN avec le client.

  1. Modifiez le Protocol du serveur SSL en TCP. Cela permet au serveur SSL d'établir une connexion SSL-VPN fiable avec le client. Pour plus d'informations, consultez Modifier un serveur SSL.

  2. Retéléchargez le certificat client SSL et installez-le sur le client. Pour plus d'informations, consultez Télécharger un certificat client SSL et Configurer un client.

Réseau public peu fiable

Le client se déconnecte de manière intermittente en raison d'une mauvaise qualité du réseau public entre le client et la VPN Gateway.

Sur le client, exécutez la commande ping ou mtr pour tester la qualité du réseau depuis le client vers l'adresse IP publique de la VPN Gateway.

Si la qualité du réseau est médiocre, contactez votre FAI pour obtenir de l'aide.

Latence élevée après la connexion

Ce tableau décrit les causes possibles et les solutions.

Catégorie

Cause

Solution

Problème de spécification de la VPN Gateway

Une pointe de trafic dépasse la bande passante de l'instance VPN Gateway.

Vérifiez les données de surveillance du trafic de l'instance VPN Gateway dans la console VPN Gateway pour détecter les pointes de trafic.

Vous pouvez mettre à niveau l'instance VPN Gateway. Pour plus d'informations, consultez Mettre à niveau ou renouveler une passerelle VPN.

Version obsolète de la VPN Gateway

Les anciennes versions de VPN Gateway ont des performances de transfert inférieures, ce qui peut entraîner une latence élevée sous un trafic important.

Mettez à niveau les VPN Gateways créées avant le 1er avril 2021. Les versions plus récentes offrent des performances de transfert SSL-VPN optimisées. Pour plus d'informations, consultez Mettre à niveau une passerelle VPN.

Algorithme de chiffrement spécifié non utilisé

Cause

Le serveur SSL d'Alibaba Cloud et OpenVPN (version 2.4.0 et ultérieure) ont le mode NCP (Non-Compliant Plaintext) activé par défaut. Le mode NCP est une méthode de négociation dynamique des algorithmes de chiffrement. Lorsque ce mode est activé, le client et le serveur SSL établissent une connexion SSL-VPN en négociant l'utilisation de l'algorithme de chiffrement ayant le niveau de sécurité le plus élevé pris en charge par les deux parties à partir de la liste ncp_ciphers, au lieu d'utiliser l'algorithme de chiffrement que vous avez spécifié pour le serveur SSL.

Dans OpenVPN 2.4.0 et versions ultérieures, les algorithmes de chiffrement par défaut dans la liste ncp_ciphers sont AES-256-GCM et AES-128-GCM. Lorsqu'un client établit une connexion SSL-VPN avec un serveur SSL, vous pouvez consulter les journaux de connexion pour afficher l'algorithme de chiffrement négocié. Par exemple, le journal peut contenir Data Channel: using negotiated cipher 'AES-256-GCM'.

Si le client utilise une version d'OpenVPN antérieure à 2.4.0, qui ne prend pas en charge NCP, la connexion utilise l'algorithme de chiffrement spécifié pour le serveur SSL.

Recommandation

Nous vous recommandons d'utiliser OpenVPN 2.4.0 ou une version ultérieure sur le client pour permettre au client et au serveur SSL de négocier l'algorithme de chiffrement.

Remarque

Si le client utilise Tunnelblick, les algorithmes de chiffrement sont négociés dynamiquement par défaut. L'algorithme le plus sécurisé pris en charge mutuellement est utilisé, et l'algorithme que vous spécifiez pour le serveur SSL ne prend pas effet.

IDaaS inter-comptes pour l'authentification à deux facteurs

Non. Vous pouvez uniquement sélectionner une instance IDaaS au sein de votre propre compte Alibaba Cloud.