Compartir por


Optimizar el flujo de tráfico con el proxy de aplicaciones de Microsoft Entra

Obtenga información sobre cómo optimizar el flujo de tráfico y las consideraciones de topología de red al usar el proxy de aplicación de Microsoft Entra.

Flujo de tráfico

Cuando se publica una aplicación a través del proxy de aplicaciones de Microsoft Entra, el tráfico de los usuarios a las aplicaciones fluye a través de tres conexiones:

  1. El usuario se conecta al punto de conexión público del servicio del proxy de aplicaciones de Microsoft Entra en Azure
  2. El conector de red privada se conecta al servicio de proxy de aplicación (saliente)
  3. El conector de red privada se conecta a la aplicación de destino

Diagrama que muestra el flujo de tráfico del usuario a la aplicación de destino.

Optimización de grupos de conectores para usar el servicio en la nube del proxy de aplicación más cercano

Al suscribirse a un inquilino de Microsoft Entra, la región del inquilino se establece con la región que elija. Las instancias de servicio en la nube del proxy de aplicación predeterminadas usan la misma región o más cercana que el inquilino de Microsoft Entra.

Por ejemplo, si la región del inquilino de Microsoft Entra es el Reino Unido, todos los conectores de red privados en predeterminado se asignan para usar instancias de servicio en centros de datos europeos. Cuando los usuarios acceden a aplicaciones publicadas, el tráfico pasa por las instancias del servicio en la nube del proxy de aplicación de esta ubicación.

Si tiene conectores instalados en regiones que no sean la predeterminada, es posible que le convenga cambiar la región para la que se optimiza el grupo de conectores, con el fin de mejorar el rendimiento al acceder a estas aplicaciones. Una vez que se especifica una región para un grupo de conectores, se conectará a los servicios en la nube de Application Proxy de la región designada.

Para optimizar el flujo de tráfico y reducir la latencia de un grupo de conectores, asigne el grupo a la región más cercana. Para asignar una región:

Importante

Para usar esta funcionalidad, los conectores deben utilizar, como mínimo, la versión 1.5.1975.0.

  1. Inicie sesión en el centro de administración de Microsoft Entra como Administrador de aplicaciones como mínimo.

  2. En la esquina superior derecha, seleccione su nombre de usuario. Compruebe que ha iniciado sesión en el directorio que usa el proxy de aplicación. Si necesita cambiar de directorio, seleccione Cambiar de directorio y elija un directorio que use el proxy de aplicación.

  3. Vaya a Identidad> Aplicaciones>aplicaciones para empresas> Aplicación proxy.

  4. Seleccione Nuevo grupo de conectores y especifique un nombre para el grupo de conectores.

  5. Después, en Configuración avanzada, seleccione la lista desplegable de Optimizar de región específica y seleccione la región más cercana a los conectores, después seleccione Guardar.

    Configurar un nuevo grupo de conectores.

  6. Seleccione los conectores que se van a asignar al grupo de conectores.

    Solo puede mover conectores al grupo de conectores si este está en un grupo de conectores que usa la región predeterminada. Comience con un conector en el grupo de conectores predeterminado. A continuación, muévalo al grupo de conectores adecuado.

    La región de un grupo de conectores solo se puede cambiar si no hay conectores o aplicaciones asignados a él.

  7. Asigne el grupo de conectores a sus aplicaciones. El tráfico va al servicio en la nube de proxy de aplicación en la región del grupo de conectores optimizado.

Consideraciones para reducir la latencia

Todas las soluciones de proxy introducirán latencia en la conexión de red. Independientemente del proxy o solución VPN que elija como solución de acceso remoto, siempre se incluirá un conjunto de servidores que habilita la conexión hacia su la red corporativa.

Las organizaciones suelen incluir puntos de conexión de servidor en su red perimetral. Sin embargo, con el proxy de la aplicaciones de Microsoft Entra, el tráfico fluye a través del servicio de proxy en la nube, mientras que los conectores residen en la red corporativa. No se requiere red perimetral.

Las siguientes secciones contienen más sugerencias para ayudarle a reducir aún más la latencia.

Colocación del conector

El proxy de aplicación elige automáticamente la ubicación de las instancias en función de la ubicación del inquilino. Sin embargo, corresponde al usuario decidir dónde instalar el conector, con lo que tiene la posibilidad de definir las características de la latencia del tráfico de su red.

Al configurar el servicio de proxy de aplicación, formule las siguientes preguntas:

  • ¿Dónde se encuentra la aplicación?
  • ¿Dónde se encuentran la mayoría de los usuarios que acceden a la aplicación?
  • ¿Dónde se encuentra la instancia del proxy de aplicación?
  • ¿Tiene ya configurada una conexión de red dedicada a los centros de datos de Microsoft, como Azure ExpressRoute o una VPN similar?

El conector debe comunicarse tanto con Microsoft Entra ID como con las aplicaciones. Los pasos 2 y 3 representan la comunicación en el diagrama de flujo de tráfico. La colocación del conector afecta a la latencia de esas dos conexiones. Al evaluar la posición del conector, tenga en cuenta lo siguiente.

  • Confirme la "línea de sitio" entre el conector y el centro de datos para la delegación restringida de Kerberos (KCD). Además, el servidor de conector debe estar unido al dominio.
  • Instale el conector lo más cerca posible de la aplicación.

Método general para minimizar la latencia

Minimice la latencia del tráfico de extremo a extremo optimizando cada conexión de red.

  • Reduzca la distancia entre los dos extremos del salto.
  • Elija la red adecuada para atravesarla. Por ejemplo, puede ser más rápido pasar por una red privada en lugar de la red pública de Internet debido a los vínculos dedicados.

Considere la posibilidad de usar una VPN dedicada o un vínculo de ExpressRoute entre Microsoft y su red corporativa.

Centrar la estrategia de optimización

Es poco lo que puede hacer para controlar la conexión entre los usuarios y el servicio del proxy de aplicación. Los usuarios acceden a sus aplicaciones desde una red doméstica, una cafetería o una región diferente. En su lugar, puede optimizar las conexiones desde el servicio de proxy de aplicación a los conectores de red privada a las aplicaciones. Es aconsejable incorporar los siguientes patrones a su entorno.

Patrón 1: colocar el conector cerca de la aplicación

Coloque el conector cerca de la aplicación de destino en la red del cliente. Esta configuración reduce al mínimo el paso 3 en el diagrama de la topología, porque el conector y la aplicación son similares.

Si el conector necesita una línea de visión al controlador de dominio, este modelo es ventajoso. La mayoría de nuestros clientes lo usa, puesto que funciona bien para la mayoría de los escenarios. Este modelo se puede combinar con el 2 para optimizar el tráfico entre el servicio y el conector.

Patrón 2: sacar partido de ExpressRoute con emparejamiento de Microsoft

Si tiene una configuración de ExpressRoute con emparejamiento de Microsoft, puede usar la conexión de ExpressRoute más rápida para el tráfico entre el proxy de la aplicación y el conector. El conector sigue en su red; cierre la aplicación.

Patrón 3: sacar partido de ExpressRoute con el emparejamiento privado

Si tiene una configuración de VPN o ExpressRoute dedicada con emparejamiento privado entre Azure y la red corporativa, tiene otra opción. En esta configuración, la red virtual de Azure normalmente se considera una extensión de la red corporativa. Así pues, puede instalar el conector en el centro de datos de Azure y aun así cumplir los requisitos de latencia baja de la conexión del conector a la aplicación.

La latencia no se ve comprometida porque el tráfico fluye por una conexión dedicada. También obtiene una mejor latencia del conector al servicio del proxy de aplicación, ya que el conector está instalado en un centro de datos Azure cerca de la ubicación del inquilino de Microsoft Entra.

Diagrama que muestra el conector instalado en un centro de datos de Azure

Otros enfoques

Aunque el centro de atención de este artículo es la selección de la ubicación del conector, también puede cambiar la ubicación de la aplicación para obtener mejores características de latencia.

Las organizaciones están cambiando sus redes a entornos hospedados cada vez con más frecuencia. Esto les permite colocar sus aplicaciones en un entorno hospedado que también forma parte de su red corporativa y seguir estando dentro del dominio. En este caso, los patrones analizados en las secciones anteriores se pueden aplicar a la nueva ubicación de la aplicación. Si se plantea esta opción, consulte Servicios de dominio de Microsoft Entra.

Además, considere organizar los conectores con grupos de conectores para las aplicaciones de destino que se encuentren en ubicaciones y redes distintas.

Diagramas para casos de uso habituales

En esta sección, se abordan algunos de los escenarios habituales. Suponga que el inquilino de Microsoft Entra (y, por tanto, el punto de conexión de servicio del proxy) se encuentra en Estados Unidos. Los aspectos descritos en estos casos de uso también se aplican a otras regiones de todo el mundo.

Para estos escenarios, se llama "salto" a cada una de las conexiones y les asignamos un número para facilitar el análisis:

  • Salto 1: usuario al servicio del proxy de aplicación
  • salto 2: servicio de proxy de aplicación al conector de red privada
  • salto 3: conector de red privada a la aplicación de destino

Caso de uso 1

Escenario: la aplicación se encuentra en la red de una organización en Estados Unidos con usuarios en la misma región. No hay ExpressRoute ni VPN entre el centro de datos de Azure y la red corporativa.

Recomendación: siga el patrón 1 explicado en la sección anterior. Para mejorar la latencia, considere la posibilidad de usar ExpressRoute, si es necesario.

Puede optimizar el salto 3 colocando el conector cerca de la aplicación. El conector suele instalarse con línea de visión a la aplicación y al centro de datos para realizar las operaciones KCD.

Diagrama que muestra que los usuarios, el proxy, el conector y la aplicación están en EE. UU.

Caso de uso 2

Escenario: la aplicación se encuentra en la red de una organización en Estados Unidos con usuarios dispersos por todo el mundo. No hay ExpressRoute ni VPN entre el centro de datos de Azure y la red corporativa.

Recomendación: siga el patrón 1 explicado en la sección anterior.

Nuevamente, el patrón más común es optimizar el salto 3, donde el conector se coloca cerca de la aplicación. El salto 3 no es costoso por lo general si todo se encuentra dentro de la misma región. Sin embargo, el salto 1 puede resultar más costoso dependiendo de dónde esté el usuario, ya que los usuarios de todo el mundo tendrán que acceder a la instancia del proxy de aplicación en Estados Unidos. Merece la pena mencionar que cualquier solución de proxy tendrá similares características con respecto a los usuarios que se reparten por todo el mundo.

Los usuarios están distribuidos globalmente, pero todo lo demás está en EE. UU.

Caso de uso 3

Escenario: la aplicación se encuentra en una red de una organización en Estados Unidos. Hay una instancia de ExpressRoute con emparejamiento de Microsoft entre Azure y la red corporativa.

Recomendación: siga los modelos 1 y 2 explicados en la sección anterior.

En primer lugar, coloque el conector lo más próximo posible a la aplicación. Entonces, el sistema utilizará automáticamente ExpressRoute para el salto 2.

Si el vínculo de ExpressRoute usa emparejamiento de Microsoft, el tráfico entre el proxy y el conector pasará por ese vínculo. El salto 2 usa una latencia óptima.

Diagrama que muestra ExpressRoute entre el proxy y el conector

Caso de uso 4

Escenario: la aplicación se encuentra en una red de una organización en Estados Unidos. Hay una instancia de ExpressRoute con emparejamiento privado entre Azure y la red corporativa.

Recomendación: siga el modelo 3 explicado en la sección anterior.

Coloque el conector del centro de datos de Azure que esté conectado a la red corporativa a través del emparejamiento privado de ExpressRoute.

El conector puede colocarse en el centro de datos de Azure. Puesto que el conector todavía tiene una línea de visión hacia la aplicación y el centro de datos a través de la red privada, el salto 3 se mantiene optimizado. Además, el salto 2 se optimiza aún más.

Conector de Azure Datacenter, ExpressRoute entre el conector y la aplicación

Caso de uso 5

Escenario: la aplicación se encuentra en una red de la organización en Europa, la región predeterminada del inquilino es EE. UU. y la mayor parte de los usuarios están en Europa.

Recomendación: coloque el conector cerca de la aplicación. Actualice el grupo de conectores para utilizar las instancias del servicio proxy de aplicaciones de Europa. Para ver los pasos, consulte la sección Optimización de los grupos de conectores para usar el servicio en la nube del proxy de aplicación más cercano.

Puesto que los usuarios de Europa acceden a una instancia de Application Proxy que resulta estar en la misma región, el salto 1 no es caro. El salto 3 se optimiza. Es aconsejable usar ExpressRoute para optimizar el salto 2.

Caso de uso 6

Escenario: la aplicación se encuentra en una red de la organización en Europa, la región predeterminada del inquilino es EE. UU. y la mayor parte de los usuarios están en EE. UU.

Recomendación: coloque el conector cerca de la aplicación. Actualice el grupo de conectores para utilizar las instancias del servicio proxy de aplicaciones de Europa. Para ver los pasos, consulte la sección Optimización de los grupos de conectores para usar el servicio en la nube del proxy de aplicación más cercano. El salto 1 puede ser más caro, ya que todos los usuarios de EE. UU. deben acceder a la instancia del proxy de aplicación de Europa.

También puede considerar la utilización de alguna otra variante en esta situación. Si la mayoría de los usuarios de la organización están en Estados Unidos, lo más probable es que la red también se extienda a Estados Unidos. Coloque el conector en EE. UU., siga usando la región de EE. UU. predeterminada para los grupos de conectores y utilice la línea de red corporativa interna dedicada a la aplicación en Europa. De esta forma se optimizan los saltos 2 y 3.

Diagrama que muestra los usuarios, el proxy y el conector en EE. UU., y la aplicación en Europa.

Pasos siguientes