Las conexiones de DirectAccess iniciadas por clientes de DirectAccess se realizan en las siguientes etapas:

1. Conectividad del protocolo de Internet versión 6 (IPv6) al servidor de DirectAccess.
   
   
2. Negociación de la protección del tráfico de DirectAccess con el servidor de DirectAccess (para los modelos de acceso total a la intranet y al servidor seleccionado).
   
   
3. Conectividad IPv6 al recurso de la intranet.
   
   
4. Negociación de la protección del tráfico de DirectAccess con el servidor de la intranet (para los modelos de acceso al servidor seleccionado y de un extremo a otro).
   
   

Use el siguiente proceso como metodología general para recorrer los requisitos para que un cliente de DirectAccess en Internet tenga acceso correctamente a un recurso de la intranet:

1. El equipo cliente de DirectAccess debe estar ejecutando Windows 7 Ultimate Edition, Windows 7 Enterprise Edition o Windows Server 2008 R2.
   
   
2. El equipo cliente de DirectAccess debe ser miembro de un dominio de Servicios de dominio de Active Directory (AD DS) y su cuenta de equipo debe ser miembro de uno de los grupos de seguridad configurados en el paso 1 del Asistente para configuración de DirectAccess.
   
   
3. El equipo cliente de DirectAccess debe haber recibido de Directiva de grupo la configuración del equipo para DirectAccess.
   
   Para comprobarlo, use el complemento Conjunto resultante de directivas y asegúrese de que aparece DirectAccess Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12} en la lista de objetos de directiva de grupo de configuración del equipo asociados al equipo cliente de DirectAccess.
   
   
4. El equipo servidor de DirectAccess debe haber recibido de Directiva de grupo la configuración del equipo para DirectAccess.
   
   Para comprobarlo, use el complemento Conjunto resultante de directivas y asegúrese de que aparece DirectAccess Policy-{ab991ef0-6fa9-4bd9-bc42-3c397e8ad300} en la lista de objetos de directiva de grupo de configuración del equipo asociados al equipo servidor de DirectAccess.
   
   
5. El cliente de DirectAccess debe tener una dirección IPv6 global.
   
   Use el comando ipconfig para mostrar la configuración del protocolo de control de transmisión/protocolo de Internet (TCP/IP). ¿Hay una dirección IPv6 asignada a una interfaz que comienza con 2 ó 3?
   
   En caso afirmativo, vaya al paso 6.
   
   De lo contrario, emplee los comandos netsh interface 6to4 show relay, netsh interface teredo show state y netsh interface httpstunnel show interfaces en el cliente y el servidor de DirectAccess para comprobar la configuración de 6to4, Teredo y protocolo de Internet sobre protocolo seguro de transferencia de hipertexto (IP-HTTPS).
   
   

   Nota

   Si el cliente de DirectAccess está conectado a Internet por el protocolo de Internet versión 4 (IPv4), compruebe la dirección IPv4 asignada por el proveedor de acceso a Internet (ISP) o el enrutador local. Si se trata de una dirección IPv4 pública, su Adaptador de túnel: adaptador 6TO4 debe estar configurado con una dirección que empiece por 2002. El Adaptador de túnel: adaptador 6TO4 también debe tener asignada una puerta de enlace predeterminada. Si se trata de una dirección IPv4 privada, la interfaz Teredo debe estar configurada con una dirección que empiece con 2001. Para IP-HTTPS, examine el Adaptador de túnel: iphttpsinterface. A menos que tuviera una infraestructura IPv6 nativa antes de ejecutar el Asistente para configuración de DirectAccess, el Adaptador de túnel: iphttpsinterface debe estar configurado con una dirección que empiece con 2002. Para obtener más información, vea No se puede tener acceso al servidor de DirectAccess con IP-HTTPS. Si ha configurado el túnel forzado, solo se habilita el Adaptador de túnel iphttpsinterface.

   Para obtener más información y conocer pasos adicionales para la solución de problemas, vea Corregir problemas de conectividad entre el cliente de DirectAccess y el servidor de DirectAccess a través de Internet.
   
   
6. El cliente de DirectAccess debe poder tener acceso a las direcciones IPv6 del servidor de DirectAccess.
   
   Use el comando ipconfig en el servidor de DirectAccess para mostrar la configuración de TCP/IP. Anote las direcciones IPv6 globales del servidor de DirectAccess (las que empiezan por 2 ó 3). Desde el cliente de DirectAccess, haga ping a cualquiera de las direcciones IPv6 globales del servidor de DirectAccess, empezando por las direcciones IPv6 que comienzan con 2002.
   
   Si funciona correctamente, vaya al paso 7.
   
   Si no funciona correctamente, solucione el problema de disponibilidad de IPv6 entre el cliente y el servidor de DirectAccess. Para obtener más información y conocer pasos adicionales para la solución de problemas, vea Corregir problemas de conectividad entre el cliente de DirectAccess y el servidor de DirectAccess a través de Internet.
   
   
7. Los servidores de la intranet tienen una dirección IPv6 global.
   
   Use el comando ipconfig en el servidor de la intranet para mostrar la configuración de TCP/IP. ¿Hay una dirección IPv6 asignada a una interfaz que comienza con 2 ó 3?
   
   En caso afirmativo, vaya al paso 8.
   
   De lo contrario, solucione los problemas de la infraestructura IPv6 de la intranet. En el caso de ISATAP (Intra-Site Automatic Tunnel Addressing Protocol), asegúrese de que en los servidores del Sistema de nombres de dominio (DNS) que ejecutan Windows Server 2008 con Service Pack 2 o posterior se ha quitado el nombre ISATAP de sus listas globales de consultas bloqueadas. Además, compruebe que el servidor de DirectAccess ha registrado un registro de host (A) de ISATAP en el DNS de la intranet. Para obtener información y pasos adicionales para la solución de problemas, vea El cliente de DirectAccess no puede tener acceso a recursos de la intranet.
   
   

   Nota
   Si está usando un traductor IPv6/IPv4 como NAT64, puede que el servidor de la intranet no tenga una dirección IPv6 global. En este caso, asegúrese de que NAT64 tenga una dirección IPv6 global.

8. El cliente de DirectAccess en Internet debe determinar correctamente que no está en la intranet.
   
   Use el comando netsh dnsclient show state para mostrar las opciones de la Tabla de directivas de resolución de nombres (NRPT). La ubicación de red determinada se muestra en el campo Ubicación de la máquina (Fuera de la red corporativa o Dentro de la red corporativa).
   
   Si el cliente de DirectAccess ha determinado correctamente que está fuera de la red corporativa (no en la intranet), vaya al paso 9.
   
   Si el cliente de DirectAccess ha determinado incorrectamente que está dentro de la red corporativa (en la intranet), utilice el comando netsh namespace show policy para mostrar las reglas de la NRPT configuradas mediante Directiva de grupo. Debe haber reglas de NRPT para el espacio de nombres de la intranet y una regla de exención para el nombre de dominio completo (FQDN) del servidor de ubicación de red.
   
   Use el comando reg query HKLM\software\policies\microsoft\windows\NetworkConnectivityStatusIndicator\CorporateConnectivity /v DomainLocationDeterminationUrl para mostrar el localizador uniforme de recursos (dirección URL) de ubicación de red.
   
   Compruebe que el FQDN de esta dirección URL no coincide con el sufijo DNS para el espacio de nombres de la intranet de la NRPT o que coincide con una regla de exención de la NRPT.
   
   Para obtener información y pasos adicionales para la solución de problemas, vea El cliente de DirectAccess determina que está en la intranet cuando está en Internet.
   
   
9. El cliente de DirectAccess no debe tener asignado el perfil del firewall de dominio.
   
   Use el comando netsh advfirewall monitor show currentprofile para mostrar las redes conectadas y sus perfiles del firewall determinados. Ninguna de las redes debe tener asignado el perfil del dominio.
   
   Si ninguna de las redes tiene asignado el perfil del dominio, vaya al paso 10.
   
   Si alguna de las redes se ha asignado al perfil del dominio, determine si tiene una conexión de red privada virtual (VPN) de acceso remoto activa o un controlador de dominio que esté disponible en Internet.
   
   
10. El cliente de DirectAccess debe tener disponibilidad de IPv6 en sus servidores DNS de la intranet.
    
    Desde la presentación del comando netsh namespace show effectivepolicy, obtenga las direcciones IPv6 de los servidores DNS de la intranet. Haga ping a estas direcciones IPv6 desde el cliente de DirectAccess.
    
    Si funciona correctamente, vaya al paso 11.
    
    Si no funciona correctamente, solucione el problema de disponibilidad de IPv6 entre el cliente de DirectAccess y los servidores DNS de la intranet.
    
    Asegúrese de que el servidor de DirectAccess solo tiene una puerta de enlace predeterminada IPv4 que está configurada en la interfaz de Internet. Compruebe también que el servidor de DirectAccess se ha configurado con el conjunto de rutas IPv4 en la interfaz de la intranet que le permiten tener acceso a todos los destinos IPv4 de la intranet.
    
    

    Nota
    El uso de la herramienta Ping.exe supone la configuración global predeterminada del protocolo de seguridad de Internet (IPsec) que exime al tráfico del protocolo de mensajes de control de Internet (ICMP) de la protección de IPsec.

11. El cliente de DirectAccess debe poder usar los servidores DNS de la intranet para resolver los FQDN de la intranet.
    
    Use el comando nslookup –q=aaaa FQDNIntranet direcciónIPv6ServidorDNSIntranet para resolver los nombres de los servidores de la intranet (por ejemplo: nslookup –q=aaaa dc1.corp.contoso.com 2002:836b:2:1::5efe:10.0.0.1). La herramienta Nslookup.exe debe mostrar las direcciones IPv6 del servidor de la intranet especificado.
    
    Si la herramienta Nslookup.exe realiza la resolución de nombres correctamente, vaya al paso 12.
    
    Si no hay ninguna respuesta del servidor DNS de la intranet, pruebe la resolución de nombres DNS desde un equipo de la intranet con el comando nslookup –q=aaaa FQDNIntranet direcciónIPv6ServidorDNSIntranet. Si no hay ninguna respuesta, asegúrese de que el servicio Servidor DNS de los servidores DNS basados en Windows está escuchando en sus direcciones IPv6 asignadas. Utilice la pestaña Interfaces para las propiedades del servidor DNS en el complemento Administrador de DNS. De lo contrario, vaya al paso 14.
    
    Si no se encuentra el nombre, averigüe por qué el registro AAAA correspondiente no está en el DNS de la intranet.
    
    Para obtener información y pasos adicionales para la solución de problemas, vea El cliente de DirectAccess no puede resolver nombres con los servidores DNS de la intranet.
    
    
12. El cliente de DirectAccess debe tener disponibilidad en los servidores de la intranet.
    
    Use la herramienta Ping.exe para hacer ping a las direcciones IPv6 de los servidores de la intranet.
    
    Si funciona correctamente, vaya al paso 13.
    
    Si no funciona correctamente, solucione el problema de disponibilidad de IPv6 entre el cliente de DirectAccess y los servidores de la intranet.
    
    

    Nota
    El uso de la herramienta Ping.exe supone la configuración de IPsec global predeterminada que exime al tráfico de ICMP de la protección de IPsec.

13. El cliente de DirectAccess debe poder comunicarse con los servidores de la intranet mediante protocolos de nivel de aplicación.
    
    Use el programa adecuado para tener acceso al servidor de la intranet. Si Compartir impresoras y archivos está habilitado en el servidor de la intranet, pruebe el acceso del protocolo de nivel de aplicación con el comando net view \\FQDNIntranet. La aplicación del cliente de DirectAccess debe ser compatible con IPv6. De lo contrario, debe utilizar un NAT64/DNS64 intermedio como Microsoft Forefront Unified Access Gateway (UAG) 2010.
    
    Si no funciona correctamente, vaya al paso 14.
    
    
14. En los modelos de acceso total a la intranet o al servidor seleccionado, el cliente de DirectAccess debe poder negociar correctamente las asociaciones de seguridad (SA) de IPsec de modo principal y de modo rápido con el servidor de DirectAccess para el túnel de infraestructura.
    
    En el cliente de DirectAccess, use el complemento Servicios o el comando sc query mpssvc en un símbolo del sistema de Windows para asegurarse de que el servicio Firewall de Windows está en ejecución. Si está usando un firewall de host de terceros, vea DirectAccess y firewalls de host de terceros.
    
    En el cliente de DirectAccess, use el complemento Firewall de Windows con seguridad avanzada o los comandos netsh advfirewall monitor show mmsa y netsh advfirewall monitor show qmsa para determinar si hay SA de modo principal y de modo rápido para la dirección IPv6 2002:WWXX:YYZZ::WWXX:YYZZ. WWXX:YYZZ es la notación hexadecimal separada con signo de dos puntos de la primera dirección IPv4 pública consecutiva asignada a la interfaz de Internet del servidor de DirectAccess. Por ejemplo, para 131.107.0.1, la dirección IPv6 correspondiente es 2002:836b:1::836b:1 (131=0x83, 107=0x6b).
    
    Si funciona correctamente, vaya al paso 15.
    
    Si no funciona correctamente, utilice el comando nltest /dsgetdc: /force en el servidor de DirectAccess para asegurarse de que puede tener acceso a un controlador de dominio. Si no se muestra ningún controlador de dominio, solucione el problema de falta de disponibilidad y conectividad entre el servidor de DirectAccess y un controlador de dominio de Active Directory.
    
    Asegúrese de que el cliente de DirectAccess y el servidor de DirectAccess tienen los certificados apropiados para la autenticación del mismo nivel de IPsec.
    
    Si en el cliente de DirectAccess y el servidor de DirectAccess están instalados los certificados apropiados, use el seguimiento de Firewall de Windows en el cliente de DirectAccess y analice el contenido del archivo Wfpdiag.xml. Para obtener más información, vea Diagnósticos y seguimiento de red.
    
    
15. En los modelos de acceso total a la intranet o al servidor seleccionado, el cliente de DirectAccess debe poder negociar correctamente las SA de IPsec de modo principal y de modo rápido con el servidor de DirectAccess para el túnel de intranet.
    
    Compruebe que ha iniciado sesión en el equipo cliente de DirectAccess con una cuenta de dominio. Las cuentas de equipo locales no tienen las credenciales para autenticar el túnel de intranet.
    
    En el cliente de DirectAccess, use el complemento Firewall de Windows con seguridad avanzada o los comandos netsh advfirewall monitor show mmsa y netsh advfirewall monitor show qmsa para determinar si hay SA de modo principal y de modo rápido para la dirección IPv6 2002:RRSS:TTUU::RRSS:TTUU. RRSS:TTUU es la notación hexadecimal separada con signo de dos puntos de la segunda dirección IPv4 consecutiva asignada a la interfaz de Internet del servidor de DirectAccess.
    
    Si las SA existen y está usando un traductor IPv6/IPv4 como NAT64 para tener acceso al servidor de la intranet, compruebe que el traductor IPv6/IPv4 permite traducir el protocolo de aplicación. Algunos protocolos incrustan información de dirección IP en la carga del paquete y no se pueden usar en algunos traductores IPv6/IPv4.
    
    Si funciona correctamente, vaya al paso 16.
    
    Si no funciona correctamente, utilice el comando nltest /dsgetdc: /force en el servidor de DirectAccess para asegurarse de que tiene acceso a un controlador de dominio. Si no se muestra ningún controlador de dominio, solucione el problema de falta de disponibilidad y conectividad entre el servidor de DirectAccess y Active Directory.
    
    Utilice el comando nltest /dsgetdc: /force en el cliente de DirectAccess para asegurarse de que tiene acceso a un controlador de dominio. Si no se muestra ningún controlador de dominio, asegúrese de que los controladores de dominio compatibles con IPv6 empleados por los clientes de DirectAccess están usando registros del ubicador sin sitio en DNS.
    
    Asegúrese de que el cliente de DirectAccess y el servidor de DirectAccess tienen los certificados apropiados para la autenticación del mismo nivel de IPsec.
    
    Si en el cliente de DirectAccess y el servidor de DirectAccess están instalados los certificados apropiados, use el seguimiento de Firewall de Windows en el cliente de DirectAccess y analice el contenido del archivo Wfpdiag.xml. Para obtener más información, vea Diagnósticos y seguimiento de red.
    
    Para obtener información y pasos adicionales para la solución de problemas, vea El cliente de DirectAccess no puede establecer túneles al servidor de DirectAccess.
    
    
16. En el modelo de acceso de un extremo a otro o en los servidores seleccionados en el modelo de acceso al servidor seleccionado, el cliente de DirectAccess debe poder negociar correctamente las SA de IPsec de modo principal y de modo rápido con el servidor de la intranet o con el servidor seleccionado.
    
    En el cliente de DirectAccess, use el complemento Firewall de Windows con seguridad avanzada o los comandos netsh advfirewall monitor show mmsa y netsh advfirewall monitor show qmsa para determinar si hay SA de modo principal y de modo rápido para la dirección IPv6 del servidor de la intranet o del servidor seleccionado.
    
    Si no funciona correctamente, utilice el comando nltest /dsgetdc: /force en el servidor de la intranet o en el servidor seleccionado para asegurarse de que tiene acceso a un controlador de dominio. Si no se muestra ningún controlador de dominio, solucione el problema de falta de disponibilidad y conectividad entre el servidor de la intranet o el servidor seleccionado y Active Directory.
    
    Utilice el comando nltest /dsgetdc: /force en el cliente de DirectAccess para asegurarse de que tiene acceso a un controlador de dominio. Si no se muestra ningún controlador de dominio, asegúrese de que los controladores de dominio compatibles con IPv6 usados por los clientes de DirectAccess están usando registros Ubicación de servicio (SRV) de DNS que no son específicos de un sitio de Active Directory.
    
    Asegúrese de que el cliente de DirectAccess y el servidor de la intranet o el servidor seleccionado tienen los certificados apropiados para la autenticación del mismo nivel de IPsec.
    
    Si en el cliente de DirectAccess y en el servidor de la intranet o en el servidor seleccionado están instalados los certificados apropiados, use el seguimiento de Firewall de Windows en el cliente de DirectAccess y analice el contenido del archivo Wfpdiag.xml. Para obtener más información, vea Diagnósticos y seguimiento de red.
    
    Para obtener información y pasos adicionales para la solución de problemas, vea Corregir problemas de la creación de conexiones protegidas a un recurso de la intranet.
    
    

Para solucionar problemas de las conexiones de DirectAccess en el cliente de DirectAccess mediante el Asistente de conectividad de DirectAccess (DCA), vea Using the DCA Software.