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
Que faire si un client se déconnecte de manière intermittente après la connexion ?
Que faire si seuls certains clients parviennent à se connecter ?
Problèmes de connectivité SSL-VPN
Que faire si un client se connecte avec succès mais ne répond pas au ping ?
Que faire si un client se connecte avec succès mais ne répond au ping que dans un seul sens ?
Que faire si un client se connecte avec succès mais ne peut pas accéder aux ressources ?
Que faire en cas de perte de paquets après une connexion réussie ?
Que faire en cas de latence élevée après une connexion réussie ?
Pourquoi une connexion SSL-VPN n'utilise-t-elle pas l'algorithme de chiffrement spécifié ?
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é. |
|
|
Certificat client SSL expiré |
Le certificat client SSL est expiré ou invalide. |
|
|
Limite de connexion dépassée |
Le nombre de clients connectés au serveur SSL dépasse la limite. |
|
|
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. |
|
|
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 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. |
|
|
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.
|
É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 |
Vérifiez si la politique de contrôle d'accès de l'application cliente bloque les requêtes Par défaut, le pare-feu d'un système d'exploitation Windows bloque les requêtes |
|
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
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 |
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 |
La politique de contrôle d'accès de l'application cliente bloque les requêtes |
Vérifiez si la politique de contrôle d'accès de l'application cliente bloque les requêtes Par défaut, le pare-feu d'un système d'exploitation Windows bloque les requêtes |
|
L'utilisation de |
Les chemins de trafic sortant et de retour entre le client et le VPC sont différents. |
|
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. |
|
É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é. |
|
|
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. |
|
|
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. |
|
|
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 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.
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.