ÉTAPE 13 test de la connectivité DirectAccess derrière un périphérique NAT

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Quand un client DirectAccess est connecté à Internet alors qu'il se situe derrière un périphérique NAT ou un serveur proxy web, il utilise Teredo ou IP-HTTPS pour établir la connexion au serveur d'accès à distance. Si le périphérique NAT active le port UDP sortant 3544 à l’adresse IP publique du serveur d’accès à distance, Teredo est utilisé. Si l'accès Teredo n'est pas disponible, le client DirectAccess revient à IP-HTTPS sur le port TCP sortant 443, qui permet un accès via des pare-feu ou des serveurs proxy web sur le port SSL classique. Si le proxy web nécessite une authentification, la connexion IP-HTTPS échoue. Les connexions IP-HTTPS échouent également si le proxy web effectue une inspection SSL sortante, car la session HTTPS se termine au niveau du proxy web et non du serveur d'accès à distance.

Les procédures suivantes sont effectuées sur les deux ordinateurs clients :

  1. Tester la connectivité Teredo. Le premier ensemble de tests est effectué quand le client DirectAccess est configuré pour utiliser Teredo. Il s'agit du paramètre automatique quand le périphérique NAT autorise l'accès sortant vers le port UDP 3544. Commencez par exécuter les tests sur CLIENT1, puis exécutez les tests sur CLIENT2.

  2. Testez la connectivité IP-HTTPs. Le deuxième ensemble de tests est effectué quand le client DirectAccess est configuré pour utiliser IP-HTTPs. Pour illustrer la connectivité IP-HTTPS, Teredo est désactivé sur les ordinateurs clients. Commencez par exécuter les tests sur CLIENT1, puis exécutez les tests sur CLIENT2.

Prérequis

Démarrez EDGE1 et 2-EDGE1 s’ils ne sont pas déjà en cours d’exécution, et assurez-vous qu’ils sont connectés au sous-réseau Internet.

Avant d’effectuer ces tests, débranchez CLIENT1 et CLIENT2 du commutateur Internet et connectez-les au commutateur HomeNet Si le système vous demande le type de réseau pour lequel vous souhaitez définir le réseau actuel, sélectionnez réseau privé.

Test de la connectivité Teredo

  1. Sur CLIENT1, ouvrez une fenêtre de Windows PowerShell élevée.

  2. Activez l’adaptateur Teredo, tapez netsh interface Teredo Set State enterpriseclient, puis appuyez sur entrée.

  3. dans la fenêtre Windows PowerShell, tapez ipconfig/all et appuyez sur entrée.

  4. Examinez la sortie de la commande ipconfig.

    Cet ordinateur est maintenant connecté à Internet de derrière un périphérique NAT et une adresse IPv4 privée lui est affectée. Quand le client DirectAccess est derrière un périphérique NAT et qu'une adresse IPv4 privée lui est affectée, la technologie de transition IPv6 préférée est Teredo. si vous examinez la sortie de la commande ipconfig, vous devriez voir une section pour Tunnel tunneling teredo Pseudo-Interface, puis une description de la carte de tunnel teredo Microsoft, avec une adresse IP commençant par 2001:0 cohérente avec une adresse Teredo. Vous devez voir la passerelle par défaut indiquée pour la carte de tunnel Teredo en tant que' :: '.

  5. dans la fenêtre Windows PowerShell, tapez ipconfig/flushdns et appuyez sur entrée.

    Vous videz ainsi les entrées de résolution de noms susceptibles d'être restées dans le cache DNS client depuis la connexion de l'ordinateur client à Internet.

  6. dans la fenêtre Windows PowerShell, tapez « ping app1 » et appuyez sur entrée. Vous devez voir des réponses à partir de l'adresse IPv6 d'APP1, 2001:db8:1::3.

  7. dans la fenêtre Windows PowerShell, tapez ping app2 et appuyez sur entrée. Vous devez voir les réponses de l’adresse NAT64 assignée par EDGE1 à APP2, qui dans ce cas est FDC9:9f4e : eb1b: porte :: A00:4. Notez que les valeurs en gras varient en fonction de la façon dont l’adresse est générée.

  8. dans la fenêtre Windows PowerShell, tapez « ping 2-app1 » , puis appuyez sur entrée. Vous devez voir les réponses de l’adresse IPv6 2-APP1, 2001 : DB8:2 :: 3.

  9. Ouvrez Internet Explorer, dans la barre d’adresses d’Internet Explorer, entrez https://2-app1/ et appuyez sur entrée. Vous verrez le site Web IIS par défaut sur 2-APP1.

  10. Dans la barre d’adresses d’Internet Explorer, entrez https://app2/ et appuyez sur entrée. Vous allez voir le site web par défaut sur APP2.

  11. Dans l’écran d' Accueil , tapez\\App2\Files, puis appuyez sur entrée. Double-cliquez sur le fichier Nouveau document texte. Cela démontre que vous avez pu vous connecter à un serveur IPv4 uniquement à l'aide de SMB pour obtenir une ressource sur un hôte IPv4 uniquement.

  12. Répétez cette procédure sur CLIENT2.

Test de la connectivité IP-HTTPS

  1. sur CLIENT1, ouvrez une fenêtre de Windows PowerShell avec des privilèges élevés, puis tapez netsh interface teredo set state disabled et appuyez sur entrée. Teredo est ainsi désactivé sur l'ordinateur client qui peut se configurer pour utiliser IP-HTTPS. La réponse Ok s'affiche quand la commande est terminée.

  2. dans la fenêtre Windows PowerShell, tapez ipconfig/all et appuyez sur entrée.

  3. Examinez la sortie de la commande ipconfig. Cet ordinateur est maintenant connecté à Internet de derrière un périphérique NAT et une adresse IPv4 privée lui est affectée. Teredo est désactivé et le client DirectAccess revient à IP-HTTPS. lorsque vous examinez la sortie de la commande ipconfig, vous voyez une section pour Tunnel adaptateur iphttpsinterface avec une adresse IP commençant par 2001 : db8:1 : 1000 ou 2001 : db8:2 : 2000 cohérent avec cette adresse IP-https basée sur les préfixes qui ont été configurés lors de la configuration de DirectAccess. Vous ne verrez pas de passerelle par défaut indiquée pour la carte tunnel IPHTTPSInterface.

  4. dans la fenêtre Windows PowerShell, tapez ipconfig/flushdns et appuyez sur entrée. Vous videz ainsi les entrées de résolution de noms susceptibles d'être restées dans le cache DNS client depuis la connexion de l'ordinateur client au réseau d'entreprise.

  5. dans la fenêtre Windows PowerShell, tapez « ping app1 » et appuyez sur entrée. Vous devez voir des réponses à partir de l'adresse IPv6 d'APP1, 2001:db8:1::3.

  6. dans la fenêtre Windows PowerShell, tapez ping app2 et appuyez sur entrée. Vous devez voir les réponses de l’adresse NAT64 assignée par EDGE1 à APP2, qui dans ce cas est FDC9:9f4e : eb1b: porte :: A00:4. Notez que les valeurs en gras varient en fonction de la façon dont l’adresse est générée.

  7. dans la fenêtre Windows PowerShell, tapez « ping 2-app1 » , puis appuyez sur entrée. Vous devez voir les réponses de l’adresse IPv6 2-APP1, 2001 : DB8:2 :: 3.

  8. Ouvrez Internet Explorer, dans la barre d’adresses d’Internet Explorer, entrez https://2-app1/ et appuyez sur entrée. Vous verrez le site Web IIS par défaut sur 2-APP1.

  9. Dans la barre d’adresses d’Internet Explorer, entrez https://app2/ et appuyez sur entrée. Vous allez voir le site web par défaut sur APP2.

  10. Dans l’écran d' Accueil , tapez\\App2\Files, puis appuyez sur entrée. Double-cliquez sur le fichier Nouveau document texte. Cela démontre que vous avez pu vous connecter à un serveur IPv4 uniquement à l'aide de SMB pour obtenir une ressource sur un hôte IPv4 uniquement.

  11. Répétez cette procédure sur CLIENT2.