ÉTAPE 5 : Tester la connectivité DirectAccess à partir d’Internet et via le cluster

  • Article

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

CLIENT1 est maintenant prêt pour les tests DirectAccess.

  • Testez la connectivité DirectAccess à partir d’Internet. Connectez CLIENT1 au réseau Internet simulé. Une fois connecté au réseau Internet simulé, le client se voit attribuer des adresses IPv4 publiques. Quand un client DirectAccess reçoit une adresse IPv4 publique, il tente d’établir une connexion au serveur d’accès à distance en utilisant une technologie de transition IPv6.

  • Testez la connectivité du client DirectAccess via le cluster. Testez le fonctionnement du cluster. Avant de commencer les tests, nous vous recommandons d’arrêter EDGE1 et EDGE2 pendant au moins cinq minutes. Il existe plusieurs raisons à cela, notamment les délais d’expiration du cache ARP et les modifications liées à l’équilibrage de la charge réseau. Soyez patient lors de la validation de la configuration de l’équilibrage de charge réseau dans un laboratoire de test. En effet, les modifications apportées à la configuration ne seront visibles au niveau de la connectivité qu’après un certain laps de temps. Il est important de garder cela à l’esprit quand vous effectuez les tâches suivantes.

    Conseil

    Nous vous recommandons d’effacer le cache d’Internet Explorer avant d’effectuer cette procédure, mais aussi chaque fois que vous testez la connexion via un autre serveur d’accès à distance pour vous assurer que vous testez bien la connexion et que vous ne récupérez pas les pages web du cache.

Tester la connectivité DirectAccess à partir d’Internet

  1. Débranchez CLIENT1 du commutateur Corpnet et connectez-le au commutateur Internet. Attendez 30 secondes.

  2. Dans une fenêtre Windows PowerShell avec élévation de privilèges, tapez ipconfig /flushdns, puis 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.

  3. Dans la fenêtre Windows PowerShell, tapez Get-DnsClientNrptPolicy, puis appuyez sur Entrée.

    La sortie indique les paramètres actifs pour la table de stratégie de résolution de noms. Ces paramètres indiquent que toutes les connexions à .corp.contoso.com doivent être résolues par le serveur DNS d'accès à distance, avec l'adresse IPv6 2001:db8:1::2. Notez également l'entrée de la table de stratégie de résolution de noms indiquant une exemption pour le nom nls.corp.contoso.com ; le serveur DNS d'accès à distance ne répond pas aux noms qui figurent sur la liste des exemptions. Vous pouvez effectuer un test ping sur l'adresse IP du serveur DNS d'accès à distance pour vérifier la connectivité au serveur d'accès à distance ; par exemple, faites un test ping sur 2001:db8:1::2.

  4. Dans la fenêtre Windows PowerShell, tapez ping app1, puis appuyez sur ENTRÉE. Vous devez voir les réponses de l’adresse IPv6 pour APP1, à savoir 2001:db8:1::3 dans ce cas précis.

  5. Dans la fenêtre Windows PowerShell, tapez ping app2, puis appuyez sur Entrée. Vous devez voir des réponses à partir de l'adresse NAT64 affectée par EDGE1 à APP2, qui est ici fdc9:9f4e:eb1b:7777::a00:4.

    La possibilité de tester APP2 est importante, car la réussite indique que vous avez pu établir une connexion à l’aide de NAT64/DNS64, car APP2 est une ressource IPv4 uniquement.

  6. Laissez la fenêtre Windows PowerShell ouverte pour la procédure suivante.

  7. Ouvrez Internet Explorer et, dans la barre d’adresses, entrez https://app1/ et appuyez sur Entrée. Vous allez voir le site web IIS par défaut sur APP1.

  8. 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.

  9. Dans l’écran Démarrer, 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 dans le domaine de ressources.

  10. Dans l’écran Démarrer, tapez wf.msc, puis appuyez sur ENTRÉE.

  11. Dans la console Pare-feu Windows avec sécurité avancée, notez que seul le profilPrivé ou Public est actif. Le Pare-feu Windows doit être activé pour que DirectAccess fonctionne correctement. Si le Pare-feu Windows est désactivé, la connectivité DirectAccess ne fonctionne pas.

  12. Dans le volet gauche de la console, développez le nœud Supervision, puis cliquez sur le nœud Règles de sécurité de connexion. Vous devez voir les règles de sécurité de connexion actives : DirectAccess Policy-ClientToCorp, DirectAccess Policy-ClientToDNS64NAT64PrefixExemption, DirectAccess Policy-ClientToInfra et DirectAccess Policy-ClientToNlaExempt. Faites défiler le volet central vers la droite pour afficher les colonnes Premières méthodes d’authentification et Secondes méthodes d’authentification. Notez que la première règle (ClientToCorp) utilise Kerberos V5 pour établir le tunnel intranet et que la troisième règle (ClientToInfra) utilise NTLMv2 pour établir le tunnel d’infrastructure.

  13. Dans le volet gauche de la console, développez le nœud Associations de sécurité, puis cliquez sur le nœud Mode principal. Notez les associations de sécurité de tunnel d’infrastructure utilisant NTLMv2 et l’association de sécurité de tunnel intranet à l’aide de Kerberos V5. Cliquez avec le bouton droit sur l’entrée qui affiche Utilisateur (Kerberos V5) comme Seconde méthode d’authentification, puis cliquez sur Propriétés. Sous l’onglet Général, notez que le Deuxième ID local d’authentification est CORP\User1, ce qui indique que l’Utilisateur1 a réussi à s’authentifier auprès du domaine CORP à l’aide de Kerberos.

Tester la connectivité du client DirectAccess via le cluster

  1. Arrêtez correctement EDGE2.

    Vous pouvez utiliser le Gestionnaire d’équilibrage de la charge réseau pour voir l’état des serveurs durant l’exécution de ces tests.

  2. Sur CLIENT1, dans la fenêtre Windows PowerShell, tapez ipconfig /flushdns, puis appuyez sur Entrée. Cette commande efface les entrées de résolution de noms qui peuvent encore exister dans le cache DNS du client.

  3. Dans la fenêtre Windows PowerShell, effectuez un test ping sur APP1 et APP2. Vous recevez normalement des réponses de ces deux ressources.

  4. Dans l’écran Démarrer, tapez \\app2\files. Vous devez voir le dossier partagé sur l’ordinateur APP2. Le fait que vous puissiez ouvrir le partage de fichiers sur APP2 indique que le deuxième tunnel, qui exige une authentification Kerberos pour l’utilisateur, fonctionne correctement.

  5. Ouvrez Internet Explorer, puis ouvrez les sites web https://app1/ et https://app2/. L’ouverture des deux sites web confirme que le premier et le deuxième tunnels sont opérationnels. Fermez Internet Explorer.

  6. Démarrez l’ordinateur EDGE2.

  7. Arrêtez correctement EDGE1.

  8. Attendez cinq minutes, puis retournez sur CLIENT1. Effectuez les étapes 2 à 5. Cela confirme que CLIENT1 a pu basculer correctement vers EDGE2 quand EDGE1 est devenu indisponible.