Paso 3 Planear la implementación multisitio

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

Tras planificar la infraestructura multisitio, planee los requisitos de certificado adicionales, cómo los equipos de cliente seleccionan los puntos de entrada y las direcciones IPv6 asignadas en la implementación.

En las siguientes secciones se proporciona información detallada sobre la planificación.

3.1 Planificar certificados IP-HTTPS

Al configurar los puntos de entrada, se configura cada punto de entrada con una dirección ConnectTo específica. El certificado IP-HTTPS para cada punto de entrada debe coincidir con la dirección ConnectTo. Tenga en cuenta lo siguiente al obtener el certificado:

• Este tipo de certificados no se puede usar en una implementación multisitio.

• Se recomienda usar una entidad de certificación pública para que haya CRL disponibles.

• En el campo de asunto, especifique la dirección IPv4 del adaptador externo del servidor de acceso remoto (si la dirección ConnectTo se ha especificado como una dirección IP y no un nombre DNS) o el FQDN de la dirección URL IP-HTTPS.

• El nombre común del certificado debe coincidir con el nombre del sitio web IP-HTTPS. También se admite el uso de una dirección URL con caracteres comodín que coincida con el nombre DNS ConnectTo.

• Los certificado IP-HTTPS pueden usar comodines en el nombre del asunto. Se puede usar el mismo certificado comodín para todos los puntos de entrada.

• En el campo Uso mejorado de claves, use el identificador de objeto (OID) Autenticación de servidor.

• Si admite equipos cliente que ejecutan Windows 7 en la implementación multisitio, en el campo Puntos de distribución de CRL, especifique un punto de distribución CRL al que pueden acceder los clientes de DirectAccess que están conectados a Internet. Esto no es necesario para los clientes que ejecutan Windows 8 (de forma predeterminada, la comprobación de revocación de CRL está deshabilitada para IP-HTTPS en estos clientes).

• El certificado IP-HTTPS debe tener una clave privada.

• El certificado IP-HTTPS debe importarse directamente en el almacén personal del equipo y no en el usuario.

3.2 Planificar el servidor de ubicación de red

El sitio web del servidor de ubicación de red se puede hospedar en el servidor de acceso remoto o en otro servidor de la organización. Si hospeda el servidor de ubicación de red en el servidor de acceso remoto, el sitio web se crea automáticamente cuando implementa el acceso remoto. Si hospeda el servidor de ubicación de red en otro servidor que ejecute un sistema operativo Windows en su organización, debe asegurarse de que Internet Information Services (IIS) esté instalado para crear el sitio web.

3.2.1 Requisitos de certificado para el servidor de ubicación de red

Asegúrese de que el sitio web del servidor de ubicación de red cumpla los siguientes requisitos para la implementación de certificado:

• Requiere un certificado de servidor HTTPS.

• Si el servidor de ubicación de red se encuentra en el servidor de acceso remoto y ha seleccionado usar un certificado autofirmado al implementar el único servidor de acceso remoto, debe volver a configurar la implementación de un solo servidor para usar un certificado emitido por una entidad de certificación interna.

• Los equipos cliente de DirectAccess deben confiar en la entidad de certificación que emitió el certificado de servidor para el sitio web del servidor de ubicación de red.

• Los equipos cliente de DirectAccess de la red interna deben poder resolver el nombre del sitio web del servidor de ubicación de red.

• El sitio web del servidor de ubicación de la red debe estar altamente disponible para los ordenadores de la red interna.

• El servidor de ubicación de red no debe ser accesible para los equipos cliente de DirectAccess en Internet.

• El certificado de servidor debe comprobarse con una lista de revocación de certificados (CRL).

• Los certificados comodín no se admiten cuando el servidor de ubicación de red se hospeda en el servidor de acceso remoto.

A la hora de obtener el certificado de sitio web para usarlo en el servidor de ubicación de red, tenga en cuenta lo siguiente:

1. En el campo Asunto, especifica una dirección IP de la interfaz de intranet del servidor de ubicación de red o el FQDN de la dirección URL de la ubicación de red. Tenga en cuenta que no debe especificar una dirección IP si el servidor de ubicación de red está hospedado en el servidor de acceso remoto. Esto se debe a que el servidor de ubicación de red debe usar el mismo nombre de sujeto para todos los puntos de entrada y no todos los puntos de entrada tienen la misma dirección IP.

2. Para el campo Uso mejorado de clave, usa el OID Autenticación de servidor.

3. Para el campo Puntos de distribución CRL, usa un punto de distribución CRL que sea accesible para los clientes de DirectAccess que estén conectados a la intranet.

3.2.2 DNS para el servidor de ubicación de red

Si hospeda el servidor de ubicación de red en el servidor de acceso remoto, debe agregar una entrada DNS para el sitio web del servidor de ubicación de red para cada punto de entrada de la implementación. Tenga en cuenta lo siguiente:

• El nombre del firmante del primer certificado de servidor de ubicación de red en la implementación multisitio se usa como la dirección URL del servidor de ubicación de red para todos los puntos de entrada, por lo que el nombre del firmante y la dirección URL del servidor de ubicación de red no pueden ser iguales que el nombre de equipo del primer servidor de acceso remoto en la implementación. Debe ser un FQDN dedicado para el servidor de ubicación de red.

• El servicio proporcionado por el tráfico del servidor de ubicación de red se equilibra entre los puntos de entrada mediante DNS y, por lo tanto, debe haber una entrada DNS con la misma dirección URL para cada punto de entrada, configurada con la dirección IP interna del punto de entrada.

• Todos los puntos de entrada deben configurarse con un certificado de servidor de ubicación de red con el mismo nombre de asunto (que coincida con la dirección URL del servidor de ubicación de red).

• La infraestructura del servidor de ubicación de red (DNS y configuración de certificado) para un punto de entrada debe crearse antes de agregar el punto de entrada.

3.3 Planificar el certificado raíz IPsec para todos los servidores de acceso remoto

Tenga en cuenta lo siguiente al planificar la autenticación de cliente IPsec en una implementación multisitio:

1. Si optó por usar el proxy Kerberos integrado para la autenticación de equipo al configurar el único servidor de acceso remoto, debe cambiar la configuración para usar certificados de equipo emitidos por una entidad de certificación interna, ya que el proxy Kerberos no es compatible con una implementación multisitio.

2. Si ha usado un certificado autofirmado, debe volver a configurar la implementación de un único servidor para usar un certificado emitido por una entidad de certificación interna.

3. Para que la autenticación IPsec se realice correctamente durante la autenticación de cliente, todos los servidores de acceso remoto deben tener un certificado emitido por la entidad de certificación raíz o intermedia de IPsec y con el OID de autenticación de cliente para el uso mejorado de claves.

4. El mismo certificado raíz o intermedio de IPsec debe instalarse en todos los servidores de acceso remoto en la implementación multisitio.

3.4 Planificar el equilibrio de carga de servidores global

En una implementación multisitio, también se puede configurar un equilibrador de carga de servidor global. Un equilibrador de carga de servidor global puede ser útil para su organización si la implementación cubre una distribución geográfica grande, ya que puede distribuir la carga de tráfico entre los puntos de entrada. El equilibrador de carga del servidor global se puede configurar para proporcionar a los clientes de DirectAccess la información del punto de entrada del punto de entrada más cercano. El proceso funciona de la siguiente manera:

1. Los equipos cliente que ejecutan Windows 10 o Windows 8 tienen una lista de direcciones IP del equilibrador de carga del servidor global, cada una asociada a un punto de entrada.

2. El Windows 10 o Windows 8 equipo cliente intenta resolver el FQDN del equilibrador de carga del servidor global en el DNS público en una dirección IP. Si la dirección IP resuelta aparece como la dirección IP global del equilibrador de carga del servidor de un punto de entrada, el equipo cliente selecciona automáticamente ese punto de entrada y se conecta a su dirección URL IP-HTTPS (dirección ConnectTo) o a su dirección IP del servidor Teredo. Tenga en cuenta que la dirección IP del equilibrador de carga del servidor global no necesita ser idéntica a la dirección ConnectTo ni a la dirección del servidor Teredo del punto de entrada, ya que los equipos cliente nunca intentan conectarse a la dirección IP del equilibrador de carga del servidor global.

3. Si el equipo cliente está detrás de un proxy web (y no puede usar la resolución DNS), o si el FQDN del equilibrador de carga del servidor global no se resuelve en ninguna dirección IP configurada del equilibrador de carga del servidor, se seleccionará automáticamente un punto de entrada mediante un sondeo HTTPS en las direcciones URL IP-HTTPS de todos los puntos de entrada. El cliente se conectará al servidor que responda primero.

Para obtener una lista de dispositivos de equilibrio de carga de servidor globales que admiten el acceso remoto, vaya a la página Buscar un asociado en Microsoft Server y Cloud Platform.

3.5 Planificar la selección del punto de entrada del cliente de DirectAccess

Al configurar una implementación multisitio, de forma predeterminada, Windows 10 y Windows 8 equipos cliente se configuran con la información necesaria para conectarse a todos los puntos de entrada de la implementación y conectarse automáticamente a un único punto de entrada basado en un algoritmo de selección. También puede configurar la implementación para permitir los equipos cliente de Windows 10 y Windows 8 para seleccionar manualmente el punto de entrada al que se conectarán. Si un equipo cliente de Windows 10 o Windows 8 está conectado actualmente al punto de entrada de Estados Unidos y la selección automática del punto de entrada está habilitada, si el punto de entrada de Estados Unidos deja de estar accesible, después de unos minutos el equipo cliente intentará conectarse a través del punto de entrada de Europa. Se recomienda utilizar la selección automática de puntos de entrada; sin embargo, permitir la selección manual del punto de entrada permite a los usuarios finales conectarse a un punto de entrada diferente en función de las condiciones de red actuales. Por ejemplo, si un equipo está conectado al punto de entrada de Estados Unidos y la conexión a la red interna se vuelve mucho más lenta de lo esperado. En esta situación, el usuario final puede seleccionar manualmente para conectarse al punto de entrada de Europa para mejorar la conexión a la red interna.

Nota

Después de que un usuario final seleccione manualmente un punto de entrada, el equipo cliente no volverá a la selección automática de puntos de entrada. Es decir, si el punto de entrada seleccionado manualmente deja de ser accesible, el usuario final debe revertir a la selección automática de puntos de entrada o seleccionar manualmente otro punto de entrada.

Los equipos cliente de Windows 7 se configuran con la información necesaria para conectarse a un único punto de entrada en la implementación multisitio. No pueden almacenar la información de varios puntos de entrada simultáneamente. Por ejemplo, un equipo cliente de Windows 7 se puede configurar para conectarse al punto de entrada de Estados Unidos, pero no al punto de entrada de Europa. Si el punto de entrada de Estados Unidos es inaccesible, el equipo cliente de Windows 7 perderá la conectividad a la red interna hasta que se pueda acceder al punto de entrada. El usuario final no puede realizar ningún cambio para intentar conectarse al punto de entrada de Europa.

3.6 Planificar prefijos y enrutamiento

Prefijo IPv6 interno

Durante la implementación del único servidor de acceso remoto, planificó los prefijos IPv6 de red interna. Tenga en cuenta lo siguiente en una implementación multisitio:

1. Si incluyó todos los sitios de Active Directory al configurar la implementación de acceso remoto de servidor único, los prefijos IPv6 de red interna ya estarán definidos en la consola de administración de acceso remoto.

2. Si crea sitios de Active Directory adicionales para la implementación multisitio, debe planificar nuevos prefijos IPv6 para los sitios adicionales y definirlos en acceso remoto. Tenga en cuenta que los prefijos IPv6 solo se pueden configurar mediante la consola de administración de acceso remoto o los cmdlets de PowerShell si IPv6 se implementa en la red corporativa interna.

Prefijo IPv6 para equipos cliente de DirectAccess (prefijo IP-HTTPS)

1. Si IPv6 se implementa en la red corporativa interna, debe planear un prefijo IPv6 para asignar a los equipos cliente de DirectAccess en cualquier punto de entrada adicional de la implementación.

2. Asegúrese de que los prefijos IPv6 que se asignarán a los equipos cliente de DirectAccess en cada punto de entrada sean distintos y que no haya superposición en los prefijos IPv6.

3. Si IPv6 no se implementa en la red corporativa, se seleccionará automáticamente un prefijo IP-HTTPS para cada punto de entrada al agregar el punto de entrada.

Prefijo IPv6 para clientes VPN

Si ha implementado VPN en el único servidor de acceso remoto, tenga en cuenta lo siguiente:

1. La adición de un prefijo VPN IPv6 a un punto de entrada solo es necesaria si desea permitir la conectividad IPv6 del cliente VPN a la red corporativa.

2. El prefijo VPN solo se puede configurar en un punto de entrada mediante la consola de administración de acceso remoto o el cmdlet de PowerShell si IPv6 se implementa en la red corporativa interna y si la VPN está habilitada en el punto de entrada.

3. El prefijo VPN debe ser único en cada punto de entrada y no debe superponerse con otros prefijos VPN o IP-HTTPS.

4. Si IPv6 no se implementa en la red corporativa, a los clientes VPN que se conectan al punto de entrada no se les asignará una dirección IPv6.

Enrutamiento

En un enrutamiento simétrico de implementación multisitio se aplica mediante Teredo y IP-HTTPS. Cuando IPv6 se implementa en la red corporativa, tenga en cuenta lo siguiente:

1. Los prefijos Teredo e IP-HTTPS de cada punto de entrada deben ser enrutables a través de la red corporativa a su servidor de acceso remoto asociado.

2. Las rutas deben configurarse en la infraestructura de enrutamiento de red corporativa.

3. Para cada punto de entrada debe haber de una a tres rutas en la red interna:

   1. Prefijo IP-HTTPS: el administrador elige este prefijo en el asistente para agregar un punto de entrada.

   2. Prefijo IPv6 de VPN (opcional). Este prefijo se puede elegir después de habilitar VPN para un punto de entrada

   3. Prefijo Teredo (opcional). Este prefijo solo es relevante si el servidor de acceso remoto está configurado con dos direcciones IPv4 públicas consecutivas en el adaptador externo. El prefijo se basa en la primera dirección IPv4 pública del par de direcciones. Por ejemplo, si las direcciones externas son:

      1. www.xxx.yyy.zzz

      2. www.xxx.yyy.zzz+1

      A continuación, el prefijo Teredo que se va a configurar es 2001:0:WWXX:YYZZ::/64, donde WWXX:YYZZ es la representación hexadecimal de la dirección IPv4 www.xxx.yyy.zzz.

      Tenga en cuenta que puede usar el siguiente script para calcular el prefijo Teredo:

      $TeredoIPv4 = (Get-NetTeredoConfiguration).ServerName # Use for a Remote Access server that is already configured
      $TeredoIPv4 = "20.0.0.1" # Use for an IPv4 address
      
          [Byte[]] $TeredoServerAddressBytes = `
          [System.Net.IPAddress]::Parse("2001::").GetAddressBytes()[0..3] + `
          [System.Net.IPAddress]::Parse($TeredoIPv4).GetAddressBytes() + `
          [System.Net.IPAddress]::Parse("::").GetAddressBytes()[0..7]
      
      Write-Host "The server's Teredo prefix is $([System.Net.IPAddress]$TeredoServerAddressBytes)/64"
      

   4. Todas las rutas anteriores deben enrutarse a la dirección IPv6 en el adaptador interno del servidor de acceso remoto (o a la dirección IP virtual (VIP) interna para un punto de entrada con equilibrio de carga).

Nota

Cuando IPv6 se implementa en la red corporativa y la administración del servidor de acceso remoto se realiza de forma remota a través de DirectAccess, las rutas para los prefijos Teredo e IP-HTTPS de todos los demás puntos de entrada deben agregarse a cada servidor de acceso remoto para que el tráfico se reenvíe a la red interna.

Prefijos IPv6 específicos del sitio de Active Directory

Cuando un equipo cliente que ejecuta Windows 10 o Windows 8 está conectado a un punto de entrada, el equipo cliente se asocia inmediatamente al sitio de Active Directory del punto de entrada y se configura con prefijos IPv6 asociados al punto de entrada. La preferencia es que los equipos cliente se conecten a los recursos mediante estos prefijos IPv6, ya que se configuran dinámicamente en la tabla de directivas de prefijo IPv6 con mayor prioridad al conectarse a un punto de entrada.

Si su organización usa una topología de Active Directory con prefijos IPv6 específicos del sitio (por ejemplo, un FQDN de recursos interno app.corp.com se hospeda en Norteamérica y Europa con una dirección IP específica del sitio en cada ubicación), esto no se configura de forma predeterminada mediante la consola de acceso remoto y los prefijos IPv6 específicos del sitio no están configurados para cada punto de entrada. Si desea habilitar este escenario opcional, debe configurar cada punto de entrada con los prefijos IPv6 específicos que deben preferir los equipos cliente que se conectan a un punto de entrada específico. Para ello, realice lo siguiente:

1. Para cada GPO usado para equipos de cliente de Windows 10 o Windows 8, ejecute el cmdlet de PowerShell Set-DAEntryPointTableItem

2. Establezca el parámetro EntryPointRange para el cmdlet con los prefijos IPv6 específicos del sitio. Por ejemplo, para agregar los prefijos específicos del sitio 2001:db8:1:1::/64 y 2001:db:1:2::/64 a un punto de entrada denominado Europa, ejecute lo siguiente

   $entryPointName = "Europe"
   $prefixesToAdd = @("2001:db8:1:1::/64", "2001:db8:1:2::/64")
   $clientGpos = (Get-DAClient).GpoName
   $clientGpos | % { Get-DAEntryPointTableItem -EntryPointName $entryPointName -PolicyStore $_ | %{ Set-DAEntryPointTableItem -PolicyStore $_.PolicyStore -EntryPointName $_.EntryPointName -EntryPointRange ($_.EntryPointRange) + $prefixesToAdd}}
   

3. Al modificar el parámetro EntryPointRange, asegúrese de no quitar los prefijos de 128 bits existentes que pertenecen a los puntos de conexión del túnel IPsec y a la dirección DNS64.

3.7 Planificar la transición a IPv6 cuando se implementa el Acceso remoto multisitio

Numerosas organizaciones usan el protocolo IPv4 en la red corporativa. Con el agotamiento de los prefijos IPv4 disponibles, muchas organizaciones realizan la transición de solo IPv4 a redes solo IPv6.

Es más probable que esta transición tenga lugar en dos fases:

1. De solo IPv4 a una red corporativa IPv6+IPv4.

2. De IPv6+IPv4 a una red corporativa solo IPv6.

En cada parte, la transición se puede realizar en fases. En cada fase, solo se puede cambiar una subred de la red a la nueva configuración de red. Por lo tanto, se requiere una implementación multisitio de DirectAccess para admitir una implementación híbrida en la que, por ejemplo, algunos de los puntos de entrada pertenecen a una subred de solo IPv4 y otros pertenecen a una subred IPv6+IPv4. Además, los cambios de configuración durante los procesos de transición no deben interrumpir la conectividad del cliente a través de DirectAccess.

Transición de solo IPv4 a una red corporativa IPv6+IPv4

Al agregar direcciones IPv6 a una red corporativa solo IPv4, es posible que desee agregar una dirección IPv6 a un servidor de DirectAccess ya implementado. Además, puede agregar un punto de entrada o un nodo a un clúster con equilibrio de carga con direcciones IPv4 e IPv6 a la implementación de DirectAccess.

El acceso remoto permite agregar servidores con direcciones IPv4 e IPv6 a una implementación que se configuró originalmente con solo direcciones IPv4. Estos servidores se agregan como servidores solo IPv4 y DirectAccess omite sus direcciones IPv6; por lo tanto, su organización no puede aprovechar las ventajas de la conectividad IPv6 nativa en estos nuevos servidores.

Para transformar la implementación en una implementación IPv6+IPv4 y aprovechar las funcionalidades nativas de IPv6, se debe reinstalar DirectAccess. Para mantener la conectividad de cliente a lo largo de la reinstalación, consulte Transición de una implementación solo IPv4 a una implementación solo IPv6 mediante implementaciones de DirectAccess duales.

Nota

Al igual que con una red solo IPv4, en una red IPv4+IPv6 mixta, la dirección del servidor DNS que se usa para resolver las solicitudes DNS de cliente debe configurarse con el DNS64 implementado en los propios servidores de acceso remoto y no con un DNS corporativo.

Transición de IPv6+IPv4 a una red corporativa solo IPv6

DirectAccess permite agregar solo puntos de entrada IPv6 solo si el primer servidor de acceso remoto de la implementación tenía originalmente direcciones IPv4 e IPv6 o solo una dirección IPv6. Es decir, no se puede pasar de una red solo IPv4 a una red solo IPv6 en un solo paso sin volver a instalar DirectAccess. Para pasar directamente de una red solo IPv4 a una red solo IPv6, consulte Transición de una implementación solo IPv4 a una implementación solo IPv6 con implementaciones duales de DirectAccess.

Una vez completada la transición de una implementación solo IPv4 a una implementación IPv6+IPv4, puede realizar la transición a una red solo IPv6. Durante y después de la transición, tenga en cuenta lo siguiente:

• Si los servidores back-end de solo IPv4 permanecen en la red corporativa, no serán accesibles para los clientes que se conectan a través de los puntos de entrada solo IPv6.

• Al agregar puntos de entrada solo IPv6 a una implementación de IPv4+IPv6, DNS64 y NAT64 no se habilitarán en los nuevos servidores. Los clientes que se conectan a estos puntos de entrada se configurarán automáticamente para usar los servidores DNS corporativos.

• Si necesita eliminar direcciones IPv4 de un servidor implementado, debe quitar el servidor de la implementación de DirectAccess, quitar su dirección de red corporativa IPv4 y agregarla de nuevo a la implementación.

Para admitir la conectividad de cliente con la red corporativa, debe asegurarse de que el DNS corporativo pueda resolver el servidor de ubicación de red en su dirección IPv6. También se puede establecer una dirección IPv4 adicional, pero no es necesaria.

Transición de una implementación solo IPv4 a una implementación solo IPv6 mediante implementaciones de DirectAccess dual

La transición de un solo IPv4 a una red corporativa solo IPv6 no se puede realizar sin volver a instalar la implementación de DirectAccess. Para mantener la conectividad de cliente durante la transición, puedes usar otra implementación de DirectAccess. La implementación dual es necesaria cuando finaliza la primera fase de transición (red solo IPv4 actualizada a IPv4+IPv6) y tiene previsto prepararse para una transición futura a una red corporativa solo IPv6 o aprovechar las ventajas de conectividad IPv6 nativas. La implementación dual se describe en los siguientes pasos generales:

1. Instalar una segunda implementación de DirectAccess. Puede instalar DirectAccess en nuevos servidores o quitar servidores de la primera implementación y usarlos para la segunda implementación.

   Nota

   Al instalar una implementación de DirectAccess adicional junto con una actual, asegúrese de que no hay dos puntos de entrada que compartan el mismo prefijo de cliente.

   Si instala DirectAccess con el asistente de introducción o con el cmdlet Install-RemoteAccess, el acceso remoto establece automáticamente el prefijo de cliente del primer punto de entrada de la implementación en un valor predeterminado de <IPv6 subnet_prefix>:1000::/64. Si es necesario, debe cambiar el prefijo.

2. Quite los grupos de seguridad de cliente elegidos de la primera implementación.

3. Agregue los grupos de seguridad de cliente a la segunda implementación.

   Importante

   Para mantener la conectividad de cliente a lo largo del proceso, debe agregar los grupos de seguridad a la segunda implementación inmediatamente después de quitarlos del primero. Esto garantiza que los clientes no se actualicen con dos o cero GPO de DirectAccess. Los clientes empezarán a usar la segunda implementación una vez que recuperen y actualicen su GPO de cliente.

4. Opcional: retire los puntos de entrada de DirectAccess de la primera implementación y agregue esos servidores como nuevos puntos de entrada en el segundo.

Cuando haya completado la transición, puede desinstalar la primera implementación de DirectAccess. Al desinstalar, pueden producirse los siguientes problemas:

• Si la implementación se configuró para admitir solo clientes en equipos móviles, se eliminará el filtro WMI. Si los grupos de seguridad de cliente de la segunda implementación incluyen equipos de escritorio, el GPO de cliente de DirectAccess no filtrará los equipos de escritorio y puede causar problemas en ellos. Si se necesita un filtro de equipos móviles, vuelva a crearlo siguiendo las instrucciones de Crear filtros WMI para el GPO.

• Si ambas implementaciones se crearon originalmente en el mismo dominio de Active Directory, se eliminará la entrada de sondeo DNS que apunta a localhost y puede causar problemas de conectividad de cliente. Por ejemplo, los clientes pueden conectarse mediante IP-HTTPS en lugar de Teredo, o cambiar entre puntos de entrada multisitio de DirectAccess. En este caso, debe agregar la siguiente entrada DNS al DNS corporativo:

  • Zona: nombre de dominio

  • Nombre: directaccess-corpConnectivityHost

  • Dirección IP: ::1

  • Tipo: AAAA