Compartir a través de

PASO 13: Prueba de la conectividad de DirectAccess desde detrás de un dispositivo NAT

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 3544 de salida para la dirección IP pública del servidor de acceso remoto, se utiliza 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.

Los siguientes procedimientos deben efectuarse en ambos equipos cliente:

  1. Prueba la conectividad 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. En primer lugar, ejecute las pruebas en CLIENT1 y, luego, ejecútelas en CLIENT2.

  2. Prueba 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. En primer lugar, ejecute las pruebas en CLIENT1 y, luego, ejecútelas en CLIENT2.

Requisitos previos

Inicie EDGE1 y 2-EDGE1 si aún no están en ejecución y asegúrese de que están conectados a la subred de Internet.

Antes de efectuar estas pruebas, desconecte CLIENT1 y CLIENT2 del conmutador de Internet y conéctalo al conmutador de Homenet. Si se le pregunta qué tipo de red desea definir la red actual, seleccione Red principal.

Probar la conectividad Teredo

  1. En CLIENT1, abra una ventana de Windows PowerShell con privilegios elevados.

  2. Habilite el adaptador teredo, escriba netsh interface teredo set state enterpriseclient y presione ENTRAR.

  3. En la ventana de Windows PowerShell, escriba ipconfig /all y presione ENTRAR.

  4. 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. 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 observa la salida del comando ipconfig, debería ver una sección para el adaptador de túnel "Teredo Tunneling Pseudo-Interface" seguida de la descripción "Microsoft Teredo Tunneling Adapter", con una dirección IP que empieza por 2001:0, lo que es coherente con una dirección de Teredo. Debería ver que aparece la puerta de enlace predeterminada para el adaptador de túnel de Teredo como "::".

  5. En la ventana de 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.

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

  7. En la ventana de Windows PowerShell, escriba ping app2 y presione ENTRAR. Debería ver respuestas de la dirección NAT64 que EDGE1 asigna a APP2, que en este caso es fdc9:9f4e:eb1b:7777::a00:4. Tenga en cuenta que los valores en negrita variarán debido a cómo se genera la dirección.

  8. En la ventana de Windows PowerShell, escriba ping 2-app1 y presione ENTRAR. Debería ver respuestas de la dirección IPv6 de 2-APP1, 2001:db8:2::3.

  9. Abre Internet Explorer, escribe https://2-app1/ en la barra de direcciones y presiona ENTRAR. Verá el sitio web IIS predeterminado en 2-APP1.

  10. En la barra de direcciones de Internet Explorer, escribe https://app2/ y presiona ENTRAR. Verás el sitio web predeterminado en APP2.

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

  12. Repita este procedimiento en CLIENT2.

Probar la conectividad IP-HTTPS

  1. En CLIENT1, abra una ventana de Windows PowerShell con privilegios elevados y 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. Aparece una respuesta Ok cuando se completa el comando.

  2. En la ventana de 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 observa la salida del comando ipconfig, verá una sección para el adaptador de túnel iphttpsinterface con una dirección IP que empieza por 2001:db8:1:1000 o 2001:db8:2:2000, lo que es coherente con una dirección IP-HTTPS basada en los prefijos que se establecieron al configurar DirectAccess. No verá ninguna puerta de enlace predeterminada para el adaptador de túnel IPHTTPSInterface.

  4. En la ventana de 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 ventana de 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 ventana de Windows PowerShell, escriba ping app2 y presione ENTRAR. Debería ver respuestas de la dirección NAT64 que EDGE1 asigna a APP2, que en este caso es fdc9:9f4e:eb1b:7777::a00:4. Tenga en cuenta que los valores en negrita variarán debido a cómo se genera la dirección.

  7. En la ventana de Windows PowerShell, escriba ping 2-app1 y presione ENTRAR. Debería ver respuestas de la dirección IPv6 de 2-APP1, 2001:db8:2::3.

  8. Abre Internet Explorer, escribe https://2-app1/ en la barra de direcciones y presiona ENTRAR. Verá el sitio web IIS predeterminado en 2-APP1.

  9. En la barra de direcciones de Internet Explorer, escribe https://app2/ y presiona 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.

  11. Repita este procedimiento en CLIENT2.