PASO 5: Probar la conectividad de DirectAccess desde Internet y a través del clúster

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

CLIENT1 ya está listo para las pruebas de DirectAccess.

  • Pruebe la conectividad de DirectAccess desde Internet. Conectar CLIENT1 a Internet simulado. Cuando se conecta a Internet simulado, al cliente se le asignan direcciones IPv4 públicas. Cuando a un cliente de DirectAccess se le asigna una dirección IPv4 pública, intenta establecer una conexión con el servidor de acceso remoto mediante una tecnología de transición IPv6.

  • Pruebe la conectividad del cliente de DirectAccess a través del clúster. Pruebe la funcionalidad del clúster. Antes de comenzar las pruebas, se recomienda apagar EDGE1 y EDGE2 durante al menos cinco minutos. Hay una serie de razones para esto, que incluyen tiempos de espera de caché ARP y cambios relacionados con NLB. Al validar la configuración de NLB en un laboratorio de pruebas, deberá tener paciencia, ya que los cambios en la configuración no se reflejarán inmediatamente en la conectividad hasta que haya transcurrido un período de tiempo. Esto es importante tener en cuenta al realizar las siguientes tareas.

    Sugerencia

    Se recomienda borrar la caché de Internet Explorer antes de realizar este procedimiento y cada vez que pruebe la conexión a través de un servidor de acceso remoto diferente para asegurarse de que está probando la conexión y no recuperando las páginas web de la memoria caché.

Prueba de la conectividad de DirectAccess desde Internet

  1. Desconecte CLIENT1 del conmutador de red corpnet y conéctelo al conmutador de Internet. Espere 30 segundos.

  2. En una ventana de Windows PowerShell, escriba ipconfig /flushdns y presione ENTRAR. Esto vacía las entradas de resolución de nombres que pueden seguir existiendo en la caché DNS del cliente desde el momento en que el equipo cliente estaba conectado a la red corpnet.

  3. En la Windows PowerShell, escriba Get-DnsClientNrptPolicy y presione ENTRAR.

    El resultado muestra la configuración actual de la tabla de directivas de resolución de nombres (NRPT). Esta configuración indica que el servidor DNS de acceso remoto debe resolver todas las conexiones a .corp.contoso.com, con la dirección IPv6 2001:db8:1::2. Asimismo, fíjate en la entrada NRPT que indica que existe una exención para el nombre nls.corp.contoso.com; los nombres de la lista de exenciones no reciben respuesta del servidor DNS de acceso remoto. Puede hacer ping a la dirección IP del servidor DNS de acceso remoto para confirmar la conectividad con el servidor de acceso remoto. Por ejemplo, puede hacer ping a 2001:db8:1::2.

  4. En la Windows PowerShell, escriba ping app1 y presione ENTRAR. Debería ver respuestas de la dirección IPv6 de APP1, que en este caso es 2001:db8:1::3.

  5. En la Windows PowerShell, escriba ping app2 y presione ENTRAR. Deberías ver respuestas de la dirección NAT64 que EDGE1 asigna a APP2, que en este caso es fdc9:9f4e:eb1b:7777::a00:4.

    La capacidad de hacer ping a APP2 es importante, ya que el éxito indica que se pudo establecer una conexión mediante NAT64/DNS64, ya que APP2 es un recurso solo IPv4.

  6. Deje abierta Windows PowerShell ventana para el siguiente procedimiento.

  7. Abra Internet Explorer, en la Internet Explorer de direcciones, escriba y https://app1/ presione ENTRAR. Verás el sitio web IIS predeterminado en APP1.

  8. En la Internet Explorer de direcciones, escriba y https://app2/ presione ENTRAR. Verás el sitio web predeterminado en APP2.

  9. En la pantalla Inicio , escriba\\App2\Files y presione ENTRAR. Haz doble clic en el archivo Nuevo documento de texto.

    Esto demuestra que pudo conectarse a un servidor solo IPv4 mediante SMB para obtener un recurso en el dominio de recursos.

  10. En la pantalla Inicio , escribawf.msc y presione ENTRAR.

  11. En la Windows firewall con seguridad avanzada, observe que solo el perfil privado o público está activo. El Windows firewall debe estar habilitado para que DirectAccess funcione correctamente. Si el Windows firewall está deshabilitado, la conectividad de DirectAccess no funciona.

  12. En el panel izquierdo de la consola, expanda el nodo Supervisión y haga clic en el nodo Reglas de seguridad de conexión. Debería ver las reglas de seguridad de conexión activas: DirectAccess Policy-ClientToCorp, DirectAccess Policy-ClientToDNS64NAT64PrefixExemption, DirectAccess Policy-ClientToInfra y DirectAccess Policy-ClientToNlaExempt. Desplácese por el panel central a la derecha para mostrar las columnas 1st Authentication Methods (Métodos de autenticación) y 2nd Authentication Methods (Métodos de autenticación 2nd ). Observe que la primera regla (ClientToCorp) usa Kerberos V5 para establecer el túnel de intranet y la tercera regla (ClientToInfra) usa NTLMv2 para establecer el túnel de infraestructura.

  13. En el panel izquierdo de la consola, expanda el nodo Asociaciones de seguridad y haga clic en el nodo Modo principal. Observe las asociaciones de seguridad del túnel de infraestructura mediante NTLMv2 y la asociación de seguridad de túnel de intranet mediante Kerberos V5. Haga clic con el botón derecho en la entrada que muestra Usuario (Kerberos V5) como segundo método de autenticación y haga clic en Propiedades. En la pestaña General , observe que el segundo identificador local de autenticación es CORP\User1, lo que indica que User1 pudo autenticarse correctamente en el dominio CORP mediante Kerberos.

Prueba de la conectividad del cliente de DirectAccess a través del clúster

  1. Realice un apagado estable en EDGE2.

    Puede usar el Administrador de equilibrio de carga de red para ver el estado de los servidores al ejecutar estas pruebas.

  2. En CLIENT1, en la Windows PowerShell, escriba ipconfig /flushdns y presione ENTRAR. Esto vacía las entradas de resolución de nombres que pueden seguir existiendo en la caché DNS del cliente.

  3. En la Windows PowerShell, haga ping a APP1 y APP2. Debe recibir respuestas de ambos recursos.

  4. En la pantalla Inicio, escriba\\app2\files. Debería ver la carpeta compartida en el equipo app2. La capacidad de abrir el recurso compartido de archivos en APP2 indica que el segundo túnel, que requiere la autenticación Kerberos para el usuario, funciona correctamente.

  5. Abra Internet Explorer y, a continuación, abra los sitios web y https://app1/https://app2/. La capacidad de abrir ambos sitios web confirma que los túneles primero y segundo están en funcionamiento. Cierre Internet Explorer.

  6. Inicie el equipo EDGE2.

  7. En EDGE1, realice un apagado estable.

  8. Espere 5 minutos y vuelva a CLIENT1. Realice los pasos 2 a 5. Esto confirma que CLIENT1 pudo conmutar por error de forma transparente a EDGE2 después de que EDGE1 dejara de estar disponible.