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.
Probar la conectividad de DirectAccess desde Internet. Conecte CLIENT1 a una red Internet simulada. Cuando se conecta a una red Internet simulada, al cliente se le asignan direcciones IPv4 públicas. Cuando se asigna a un cliente de DirectAccess una dirección IPv4 pública, esta 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 varias razones para ello, entre las que se incluyen los tiempos de espera de la caché de ARP y los cambios relacionados con NLB. Al validar la configuración de NLB en un laboratorio de pruebas, deberá ser paciente, ya que los cambios en la configuración no se reflejarán inmediatamente en la conectividad hasta después de que haya transcurrido un período de tiempo. Es importante tener esto en cuenta al realizar las siguientes tareas.
Sugerencia
Se recomienda borrar la memoria 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é.
Probar la conectividad de DirectAccess desde Internet
Desconecte CLIENT1 del conmutador de la red corporativa y conéctelo al de Internet. Espere 30 segundos.
En una ventana de Windows PowerShell con privilegios elevados, escriba ipconfig /flushdns y presione ENTRAR. De este modo, se vacían las entradas de resolución de nombres que todavía existen en la caché de DNS de cliente desde el momento en que el equipo cliente se conectó a la red corporativa.
En la ventana de Windows PowerShell, escribe Get-DnsClientNrptPolicy y presiona ENTRAR.
El resultado muestra la configuración actual de la tabla de directivas de resolución de nombres (NRPT). Esta configuración indica que todas las conexiones a .corp.contoso.com deben resolverse a través del servidor DNS de acceso remoto, con la siguiente 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 al servidor de acceso remoto; por ejemplo, puede hacer ping a 2001:db8:1::2.
En la ventana de Windows PowerShell, escribe ping app1 y presiona ENTRAR. Debería ver las respuestas de la dirección IPv6 para APP1, que, en este caso, es 2001:db8:1::3.
En la ventana de Windows PowerShell, escribe ping app2 y presiona 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.
Deja abierta la ventana de Windows PowerShell para el siguiente procedimiento.
Abre Internet Explorer, escribe https://app1/ en la barra de direcciones y presiona ENTRAR. Verás el sitio web IIS predeterminado en APP1.
En la barra de direcciones de Internet Explorer, escribe https://app2/ y presiona ENTRAR. Verás el sitio web predeterminado en APP2.
En la pantalla Inicio, escribe \\App2\Files y, a continuación, presiona ENTRAR. Haz doble clic en el archivo Nuevo documento de texto.
Esto demuestra que ha sido capaz de conectarse a un servidor solo IPv4 mediante SMB para obtener un recurso en el dominio de recursos.
En la pantalla Inicio, escriba wf.msc y, después, presione ENTRAR.
En la consola Firewall de Windows con seguridad avanzada, observe que solo está activo el perfil Privado o Público. El firewall de Windows debe estar habilitado para que DirectAccess funcione correctamente. Si el firewall de Windows está deshabilitado, la conectividad de DirectAccess no funciona.
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 Primer método de autenticación y Segundo método de autenticación. Tenga en cuenta 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.
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 que usa NTLMv2 y la asociación de seguridad del túnel de intranet mediante Kerberos V5. Haga clic con el botón derecho en la entrada que muestra Usuario (Kerberos V5) como el Método de segunda 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.
Probar la conectividad del cliente de DirectAccess a través del clúster
Realice un apagado seguro en EDGE2.
Puede usar el Administrador de equilibrio de carga de red para ver el estado de los servidores al ejecutar estas pruebas.
En CLIENT1, en la 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.
En la ventana de Windows PowerShell, haga ping a APP1 y APP2. Debe recibir respuestas de ambos recursos.
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.
Abra Internet Explorer y, a continuación, abra los sitios web https://app1/ y https://app2/.. La capacidad de abrir ambos sitios web confirma que los túneles primero y segundo están en funcionamiento. Cierre Internet Explorer.
Inicie el equipo EDGE2.
Realice un apagado seguro en EDGE1.
Espere 5 minutos y vuelva a CLIENT1. Realice los pasos del 2 al 5. Esto confirma que CLIENT1 pudo conmutar por error de forma transparente a EDGE2 después de que EDGE1 dejara de estar disponible.