Partager via

Les clients DirectAccess peuvent ne pas être en mesure de se connecter au serveur DirectAccess avec le code d’erreur 0x103, 0x2AFC ou 0x2AF9 lors de l’utilisation d’IP-HTTPS

Cet article fournit de l’aide pour corriger les erreurs 0x103, 0x2AFC ou 0x2AF9 qui se produisent lorsque vous utilisez IP-HTTPS pour connecter des clients DirectAccess au serveur DirectAccess.

Numéro de base de connaissances d’origine : 2980635

Symptômes

Les clients DirectAccess peuvent ne pas être en mesure de se connecter au serveur DirectAccess à l’aide du protocole Internet via des connexions IP-HTTPS (Secure Hypertext Transfer Protocol).

Lorsque vous exécutez la commande d’interface netsh http show, la sortie est la suivante :

Erreur : 0x103 ou 0x2AFC ou 0x2AF9

Se traduit par :

Échec de la connexion à l’interface IP-HTTPS.

Cause

Error: 0x103  
Role: Client  
URL: `https://da.contoso.com/IPHTTPS`  
Last Error Code: 0x103  
Interface Status: No usable certificate found  
0x103 translates to:  
ERROR_NO_MORE_ITEMS  
# No more data is available.  
(This means no matching certificates were found)

Cette erreur s’affiche dans les scénarios suivants :

  • L’URL IP-HTTPS ne correspond pas au certificat fourni.
  • Le certificat IP-HTTPS contient des informations indésirables supplémentaires dans le champ Objet.
  • Le certificat IP-HTTPS a le nom correct dans le champ Objet, mais des valeurs incorrectes dans l’autre nom de l’objet (SAN).
Error: 0x2AFC  
Role: Client  
URL: `https://da.contoso.com/IPHTTPS`  
Last Error Code: 0x2AFC  
Interface Status: Failed to connect to IPHTTPs server; Waiting to reconnect.  
0x2AFC translates to:  
WSANO_DATA  
# The requested name is valid, but no data of the requested type was found.  
WSANO_DATA  
# Successfully returned a NULL value.

Cette erreur peut se produire pour plusieurs raisons :

  • Un serveur proxy bloque la connexion.
  • Impossibilité de résoudre le nom du serveur IP-HTTPS (serveur DirectAccess) mentionné dans l’URL de l’interface IP-HTTPS.
  • Le pare-feu côté client ou côté serveur peut bloquer la connexion au serveur IP-HTTPS (serveur DirectAccess).
  • L’appareil NAT est configuré de manière incorrecte (si un scénario behind-edge est utilisé).
  • Toute la connectivité est correcte, mais le serveur n’a pas le préfixe IPv6 publié, ou IP-HTTPS côté serveur est défini sur désactivé.
Error: 0x2AF9  
Role: Client  
URL: `https://da.contoso.com/IPHTTPS`  
Last Error Code: 0x2AF9  
Interface Status: Failed to connect to the IPHTTPS server; waiting to reconnect  
0x2AF9 translates to:  
WSAHOST_NOT_FOUND  
# No such host is known.  
WSAHOST_NOT_FOUND  
# Non-NULL value successfully returned.

Cette erreur peut se produire pour plusieurs raisons :

  • Un proxy bloque la connexion.
  • Impossibilité de résoudre le nom du serveur IP-HTTPS (serveur DirectAccess).
  • Le pare-feu côté client ou côté serveur peut bloquer la connexion.
  • L’appareil NAT devant le serveur DirectAccess est configuré de manière incorrecte (si un scénario behind-edge est utilisé).
  • Toute la connectivité est correcte, mais le serveur n’a pas le préfixe IPv6 publié, ou IP-HTTPS côté serveur est défini sur désactivé.

Résolution

Essayez de vous connecter au serveur via telnet à l’aide de l’adresse IP externe ou du nom du serveur DirectAccess sur le port 443. S’il ne parvient pas à se connecter, cela peut être dû au fait que le paquet est supprimé quelque part sur le réseau ou que les règles NAT ne sont pas créées correctement sur l’appareil NAT externe derrière lequel DirectAccess est configuré.

Pour plus d’informations, consultez la section « Planifier les exigences en matière de pare-feu » de la page suivante sur Microsoft Technet : Planifier l’infrastructure DirectAccess
Le nom externe doit être résolu à partir du client. Essayez d’effectuer un test ping sur le nom du site IP-HTTPS (nom public du serveur DirectAccess) et vérifiez si la résolution de noms réussit. Si le nom ne se résout pas, corrigez la résolution de noms.

Note

Nous recherchons simplement la réussite de la résolution de noms du nom public du serveur DirectAccess sur une adresse IP, et non la réussite réelle de la commande Ping.

Si une connexion telnet réussit, examinez une trace réseau. L’établissement d’une liaison SSL doit réussir.

Réinitialisez les paramètres du proxy système local. Vous pouvez manipuler ces paramètres en affichant les paramètres de proxy dans Internet Explorer. Vous devez ouvrir Internet Explorer sous le contexte système local plutôt que d’utiliser un compte normal.

Les clients DirectAccess peuvent être configurés pour atteindre le site HTTPS via un serveur proxy (qui peut bloquer la connexion). Les dernières adresses proxy sont mises en cache dans le Registre. Pour les afficher, ouvrez l’Éditeur de Registre (regedit) sur votre client DirectAccess, puis accédez à la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\iphlpsvc\Parameters\ProxyMgr

Exportez la sous-clé de Registre ProxyMgr. Si vous n’utilisez plus le serveur proxy, supprimez toutes les clés de Registre sous cette sous-clé de Registre, puis redémarrez le client DirectAccess.

Plus d’informations

Méthodes de connectivité DirectAccess

Les clients DirectAccess utilisent plusieurs méthodes pour se connecter au serveur DirectAccess, ce qui permet d’accéder aux ressources internes. Les clients ont la possibilité d’utiliser Teredo, 6to4 ou IP-HTTPS pour se connecter à DirectAccess. Cela dépend également de la configuration du serveur DirectAccess.

Lorsque le client DirectAccess a une adresse IPv4 publique, il tente de se connecter à l’aide de l’interface 6to4. Toutefois, certains fournisseurs d’accès web donnent l’illusion d’une adresse IP publique. Ce qu’ils fournissent aux utilisateurs finaux est une pseudo-adresse IP publique. Cela signifie que l’adresse IP reçue par le client DirectAccess (une carte de données ou une connexion SIM) peut être une adresse IP de l’espace d’adressage public, mais en réalité se trouve derrière un ou plusieurs naTs.

Lorsque le client se trouve derrière un appareil NAT, il tente d’utiliser Teredo. De nombreuses entreprises telles que les hôtels, les aéroports et les cafés ne permettent pas au trafic Teredo de traverser leur pare-feu. Dans de tels scénarios, le client bascule vers IP-HTTPS. IP-HTTPS est créé sur une connexion TCP 443 TCP 443. Le trafic sortant SSL sera probablement autorisé sur tous les réseaux.

Ceci étant à l’esprit, IP-HTTPS a été conçu pour fournir une connexion de sauvegarde fiable et toujours accessible. Un client DirectAccess l’utilise lorsque d’autres méthodes (telles que Teredo ou 6to4) échouent.

Pour plus d’informations sur les technologies de transition, consultez les technologies de transition IPv6.