PASO 6: Probar la conectividad de cliente de DirectAccess desde detrás de un dispositivo NAT

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

Cuando un cliente de DirectAccess está conectado a Internet desde detrás de un dispositivo NAT o un servidor proxy web, el cliente de DirectAccess usa Teredo o IP-HTTPS para conectarse al servidor de acceso remoto.

Si el dispositivo NAT habilita el puerto UDP saliente 3544 a la dirección IP pública del servidor de acceso remoto, se usa Teredo. Si no es posible acceder a Teredo, el cliente de DirectAccess vuelve a IP-HTTPS a través del puerto TCP 443 de salida, lo que permite el acceso a través de firewalls o servidores proxy web a través del puerto SSL tradicional.

Si el servidor proxy web requiere autenticación, se producirá un error en la conexión IP-HTTPS. También se producirá un error en las conexiones IP-HTTPS si el servidor proxy web realiza una inspección SSL saliente, debido a que la sesión HTTPS se finaliza en el servidor proxy web en lugar de en el servidor de acceso remoto. En esta sección se realizarán las mismas pruebas que se llevaron a cabo en la sección anterior al conectarse a través de una conexión 6to4.

Los siguientes procedimientos deben efectuarse en ambos equipos cliente:

  1. Pruebe la conectividad de Teredo. El primer conjunto de pruebas se realiza cuando el cliente de DirectAccess está configurado para usar Teredo. Esta es la configuración automática cuando el dispositivo NAT permite el acceso saliente al puerto UDP 3544.

  2. Pruebe la conectividad IP-HTTPS. El segundo conjunto de pruebas se realiza cuando el cliente de DirectAccess está configurado para usar IP-HTTPS. Para demostrar la conectividad IP-HTTPS, Teredo debe deshabilitarse en los equipos cliente.

Sugerencia

Se recomienda borrar la caché de Internet Explorer antes de realizar estos procedimientos para asegurarse de que está probando la conexión y no recuperando las páginas del sitio web de la memoria caché.

Requisitos previos

Antes de efectuar estas pruebas, desconecta CLIENT1 del conmutador de Internet y conéctalo al conmutador Homenet. Si se te pregunta qué tipo de red deseas para definir la red actual, selecciona Red doméstica.

Inicia EDGE1 y EDGE2 si todavía no se están ejecutando.

Probar la conectividad Teredo

  1. En CLIENT1, abra una ventana de Windows PowerShell, escriba ipconfig /all y presione ENTRAR.

  2. Examina el resultado del comando ipconfig.

    CLIENT1 está ahora conectado a Internet desde detrás de un dispositivo NAT y se le ha asignado una dirección IPv4 privada. Cuando el cliente de DirectAccess está detrás de un dispositivo NAT y se le asigna una dirección IPv4 privada, la tecnología de transición IPv6 preferida es Teredo. Si observas el resultado del comando ipconfig, deberías ver una sección para la pseudointerfaz de túnel Teredo para el adaptador de túnel seguida de la descripción Adaptador de túnel Teredo de Microsoft, con una dirección IP que empieza por 2001, lo que es coherente con una dirección Teredo. Si no ve la sección Teredo, habilite Teredo con el siguiente comando: netsh interface Teredo set state enterpriseclient y vuelva a ejecutar el comando ipconfig. No verás ninguna puerta de enlace predeterminada para el adaptador de túnel Teredo.

  3. En la Windows PowerShell, escriba ipconfig /flushdns y presione ENTRAR.

    De este modo, se vaciarán las entradas de resolución de nombres que todavía existan en la caché de DNS de cliente desde el momento en que el equipo cliente se conectó a Internet.

  4. 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). Dicha 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. Puedes hacer ping a la dirección IP del servidor DNS de acceso remoto para confirmar la conectividad al servidor de acceso remoto; por ejemplo, puedes hacer ping a 2001:db8:1::2 en este ejemplo.

  5. En la Windows PowerShell, escriba ping app1 y presione ENTRAR. Deberías ver respuestas de la dirección IPv6 de APP1, 2001:db8:1::3.

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

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

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

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

  10. En la pantalla Inicio , escriba\\App2\Files y presione ENTRAR. Haz doble clic en el archivo Nuevo documento de texto. Esto demuestra que has sido capaz de conectarte a un servidor solo IPv4 utilizando SMB para obtener un recurso en un host solo IPv4.

Probar la conectividad IP-HTTPS

  1. Abra una ventana de Windows PowerShell, escriba netsh interface teredo set state disabled y presione ENTRAR. Esto deshabilita Teredo en el equipo cliente y permite que el equipo cliente se configure a sí mismo para usar IP-HTTPS. Cuando se completa el comando, aparece la respuesta Aceptar.

  2. En la Windows PowerShell, escriba ipconfig /all y presione ENTRAR.

  3. Examina el resultado del comando ipconfig. El equipo está ahora conectado a Internet desde detrás de un dispositivo NAT y se le ha asignado una dirección IPv4 privada. Teredo está deshabilitado y el cliente de DirectAccess vuelve a IP-HTTPS. Si observas el resultado del comando ipconfig, verás una sección para el adaptador de túnel iphttpsinterface con una dirección IP que empieza por 2001:db8:1:100, lo que es coherente con una dirección IP-HTTPS basada en el prefijo que se estableció al configurar DirectAccess. No verás ninguna puerta de enlace predeterminada para el adaptador de túnel IP-HTTPS.

  4. En la Windows PowerShell, escriba ipconfig /flushdns y presione ENTRAR. De este modo, se vaciarán las entradas de resolución de nombres que todavía existan en la caché de DNS de cliente desde el momento en que el equipo cliente se conectó a corpnet.

  5. En la Windows PowerShell, escriba ping app1 y presione ENTRAR. Deberías ver respuestas de la dirección IPv6 de APP1, 2001:db8:1::3.

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

  7. Abra Internet Explorer, en la Internet Explorer de direcciones, escriba y https://app1/ presione ENTRAR. Verás el sitio 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 has sido capaz de conectarte a un servidor solo IPv4 utilizando SMB para obtener un recurso en un host solo IPv4.