Decisión de diseño: diseño de la integración de StoreFront y Gateway

El propósito de este artículo es profundizar un poco más en la integración de NetScaler Gateway con StoreFront: qué significan los ajustes y consideraciones de diseño sobre cómo configurarlos.

URL de puerta de enlace, URL de respuesta y URL GSLB

StoreFront permite a los administradores definir varias puertas de enlace que se pueden utilizar para la autenticación PassThrough de Gateway en un único almacén. Esta función es muy beneficiosa, ya que minimiza el número de almacenes que deben configurarse en implementaciones globales grandes. Vemos que existen cuatro parámetros clave para que esta integración funcione correctamente: URL de NetScaler Gateway, dirección IP del servidor virtual, URL de respuesta y URL de GSLB, que se describen en las siguientes secciones.

URL de puerta de enlace

La primera pantalla de configuración en la configuración de una puerta de enlace solicita al administrador que introduzca un nombre para mostrar descriptivo y la URL de la puerta de enlace, que es la URL introducida por los usuarios, como se muestra a continuación:

Configuración general Figura 1: Configuración general

StoreFront solo permite el paso a través de la puerta de enlace desde las puertas de enlace definidas en su configuración. NetScaler Gateway toma la URL introducida en los exploradores web de los usuarios o en los clientes de la aplicación Workspace (Receiver) y la inserta en un encabezado HTTP (XCITRIXVIA). Esta información se devuelve a StoreFront. StoreFront intenta entonces hacer coincidir este valor con una de las URL de puerta de enlace definidas. El campo URL de puerta de enlace es obligatorio y debe coincidir con lo que se ha introducido en el explorador web o en la aplicación Workspace (Receiver) de un usuario para que funcione el paso de Gateway a StoreFront.

URL de respuesta y direcciones IP de servidor virtual

A continuación, cubrimos algunos campos opcionales: la dirección IP del servidor virtual y la URL de devolución de llamada, cuyo uso está relacionado y se tratan juntos. Estos campos aparecen en la pantalla de configuración de autenticación del asistente de configuración de la puerta de enlace, como se muestra a continuación:

Configuración general Figura 2: Configuración de autenticación

StoreFront pretende utilizar la URL de respuesta para recopilar información adicional sobre la sesión de Gateway de un usuario. No se utiliza estrictamente para la autenticación. En su lugar, consulta cosas como el nombre de la directiva Sesión de puerta de enlace aplicada a la sesión del usuario. Estos detalles adicionales se pueden usar como parte de los filtros de políticas basados en el control de acceso de Citrix Virtual Apps and Desktops. También es necesario en casos de autenticación “sin contraseña”, como cuando la tarjeta inteligente y SAML están en uso para realizar una validación adicional en la sesión de Gateway del usuario. Para las implementaciones de Global Site Load Balancing (GSLB), se utilizan tanto la URL de devolución de llamada como la dirección IP del servidor virtual . Estos casos se analizan más adelante en este artículo. Si uno de estos casos no está en juego, los campos URL de respuesta y dirección IP del servidor virtual no son obligatorios y pueden dejarse en blanco.

Si se requiere una URL de respuesta y varias puertas de enlace están vinculadas a un solo almacén, StoreFront necesita una forma de identificar correctamente no solo si el tráfico viene a través de una puerta de enlace, sino del servidor virtual de puerta de enlace del que proviene el tráfico para redirigir la respuesta a la puerta de enlace correcta que contiene el sesión. StoreFront primero realiza esta acción haciendo coincidir con la URL de la puerta de enlace, que recibe a través del encabezado HTTP XCITRIXVIA como se había cubierto anteriormente. Si hay varias puertas de enlace que tienen especificada la misma URL de puerta de enlace (lo que ocurriría en arquitecturas GSLB donde la misma URL se resuelve en varios servidores virtuales de puerta de enlace individuales), StoreFront vuelve a utilizar una dirección IP para identificar una puerta de enlace, que es un valor único. StoreFront recibe la dirección VIP del servidor virtual desde una puerta de enlace a través de otro encabezado HTTP (XCITRIXVIAVIP). Una vez recibido, intenta hacer coincidir con el valor del campo Dirección IP de vServer en una de sus puertas de enlace asignadas. Suponiendo que StoreFront puede identificar una puerta de enlace basada en una coincidencia de dirección IP de servidor virtual, la respuesta se completa correctamente. Por lo tanto, la dirección IP del servidor virtual solo es necesaria cuando se especifica una URL de respuesta y hay varias puertas de enlace enlazadas a un almacén con la misma URL de puerta de enlace definida.

Direcciones URL de GSLB

Por último, un parámetro que no se muestra en la GUI: la URL GSLB. La versión 3.9 de StoreFront introdujo la capacidad a través de PowerShell solo para especificar un parámetro de URL GSLB en una definición de puerta de enlace. Esta dirección URL de GSLB funciona como un origen alternativo desde el que StoreFront acepta solicitudes de autenticación para esa misma definición de puerta de enlace. Este parámetro es visible en el resultado del comando Get-STFRoamingGateway. El propósito de este parámetro es reducir el número total de puertas de enlace que se deben definir para un único almacén para simplificar la administración. Sin él, se debe definir un objeto Gateway para cada combinación de URL de puerta de enlace + URL de respuesta única que pueden utilizar los usuarios, que pueden sumarse rápidamente en un entorno empresarial.

Por ejemplo, tres puertas de enlace globales detrás de una dirección GSLB unificada (https://www.nsg.com): una en América, una en Europa, una en Asia, cada una con una URL de respuesta única requerirían tres puertas de enlace definidas. Además, estos administradores quieren poder probar la autenticación en cada puerta de enlace individualmente. Esto es importante para entender si hay problemas de GSLB, lo que da como resultado nombres alternativos y únicos para cada puerta de enlace que se define. Esta instancia significa que se deben configurar un total de seis puertas de enlace para la tienda, con el siguiente aspecto:

Display Name URL de la puerta de enlace Dirección IP del servidor virtual URL de respuesta
GSLB de EE. UU. https://www.nsg.com 1.1.1.1 https://callback-us.nsg.com
GSLB de la UE https://www.nsg.com 2.2.2.2 https://callback-eu.nsg.com
GSLB de AP https://www.nsg.com 3.3.3.3 https://callback-ap.nsg.com
Puerta de enlace de EE. UU. https://us.nsg.com 1.1.1.1 https://callback-us.nsg.com
Puerta de enlace de la UE https://eu.nsg.com 2.2.2.2 https://callback-eu.nsg.com
Puerta de enlace de AP https://ap.nsg.com 3.3.3.3 https://callback-ap.nsg.com

Tabla 1: Lista completa de puertas de enlace

Al aplicar el parámetro URL de GSLB, el número de puertas de enlace definidas se puede reducir a la mitad, al tiempo que permite a los usuarios conectarse a través de todas las direcciones GSLB y Gateway únicas de la siguiente manera:

Nombre simplificado URL de la puerta de enlace Dirección IP del servidor virtual URL de respuesta URL de GSLB
Puerta de enlace de EE. UU. https://us.nsg.com 1.1.1.1 https://callback-us.nsg.com https://www.nsg.com
Puerta de enlace de la UE https://eu.nsg.com 2.2.2.2 https://callback-eu.nsg.com https://www.nsg.com
Puerta de enlace de AP https://ap.nsg.com 3.3.3.3 https://callback-ap.nsg.com https://www.nsg.com

Tabla 2: Lista de puertas de enlace consolidadas con URL de GSLB

Aunque el parámetro se llama “GslbUrl”, funciona como un nombre de host alternativo para esa definición de puerta de enlace. No tiene que ser una dirección GSLB, solo otro nombre por el que se puede acceder a ese mismo servidor virtual de puerta de enlace. Otro caso de uso puede ser dividir DNS con direcciones de puerta de enlace externa/interna que se redirigen al mismo servidor virtual.

Tenga en cuenta que la aplicación Workspace (Receiver) no reconoce este parámetro y, por lo general, las URL del ejemplo anterior se invierten para que los clientes de la aplicación Workspace (Receiver) puedan seguir usando la dirección GSLB y las URL por puerta de enlace se puedan usar al conectarse a través de navegadores web:

Display Name URL de la puerta de enlace Dirección IP del servidor virtual URL de respuesta URL de GSLB
Puerta de enlace de EE. UU. https://www.nsg.com 1.1.1.1 https://callback-us.nsg.com https://us.nsg.com
Puerta de enlace de la UE https://www.nsg.com 2.2.2.2 https://callback-eu.nsg.com https://eu.nsg.com
Puerta de enlace de AP https://www.nsg.com 3.3.3.3 https://callback-ap.nsg.com https://ap.nsg.com

Tabla 3: URL de GSLB ajustada para la aplicación Receiver y Workspace

Conclusiones sobre el diseño

Para resumir las secciones anteriores:

  • Siempre se necesita una URL de puerta de enlace, que debe coincidir con lo que se introduce en los navegadores web o en los clientes de la aplicación Workspace (Receiver)
  • La URL de devolución de llamada solo es necesaria si se utilizan políticas SmartAccess de Citrix Virtual Apps and Desktops, métodos de autenticación sin contraseña (tarjetas inteligentes, SAML, etc.) o URL GSLB
  • Solo se necesita una dirección IP de servidor virtual si se especifica una URL de devolución de llamada y hay varias puertas de enlace enlazadas a la tienda que tienen la misma URL de puerta de enlace especificada.
  • La URL de GSLB es un nuevo parámetro que se agregó en StoreFront 3.9. La URL simplifica la integración de Gateway con StoreFront cuando se puede acceder a un único servidor virtual de Gateway a través de varias URL
  • La aplicación Workspace (Receiver) no lee el parámetro URL de GSLB, por lo que la URL de puerta de enlace siempre es la URL utilizada por esos clientes y la URL de GSLB es una URL alternativa que puede ser utilizada por conexiones basadas en explorador web

Selección de un “Dispositivo predeterminado”

Cuando un administrador habilita el acceso remoto para un almacén, se debe definir un “dispositivo predeterminado” como se muestra en la captura de pantalla.

Dispositivo predeterminado Figura 3: Dispositivo predeterminado

Para el acceso basado en explorador web, la configuración de “dispositivo predeterminado” no tiene ningún impacto. Para el acceso basado en la aplicación Workspace (Receiver), esta configuración se descarga en Receiver al conectarse a la Almacén como parte de la configuración de la Almacén. La puerta de enlace se utiliza posteriormente de forma predeterminada. Si todas las puertas de enlace definidas comparten la URL de la puerta de enlace, la aparición no tiene ningún impacto (Receiver solo usa esa definición de puerta de enlace para extraer la URL y consultar la autenticación, por lo que en las configuraciones de GSLB, esa consulta se enruta por GSLB). Como se indicó anteriormente, la aplicación Workspace (Receiver) no lee el parámetro «URL de GSLB», por lo que la puerta de enlace definida como el dispositivo predeterminado debe tener definida una URL de puerta de enlace adecuada, como se muestra en la «Tabla 3: URL de GSLB ajustada para la aplicación Receiver y Workspace» de la sección anterior.

Si las puertas de enlace enlazadas a la tienda tienen diferentes URL de puerta de enlace, todos los clientes de Receiver utilizan la que definan como predeterminada. Esta ocurrencia es problemática si ha definido diferentes puertas de enlace para ser utilizadas por diferentes conjuntos de usuarios. Por ejemplo, una puerta de enlace configurada con autenticación LDAP+RADIUS para usuarios con tokens y una puerta de enlace configurada con autenticación de tarjeta inteligente. Si el usuario introduce la URL de puerta de enlace de tarjeta inteligente en la aplicación Workspace (Receiver), pero StoreFront tiene la puerta de enlace LDAP+RADIUS definida como la predeterminada, después de que la aplicación Workspace (Receiver) se conecte a StoreFront y almacena en caché la configuración, todas las solicitudes de autenticación futuras se enviarán a la puerta de enlace LDAP+RADIUS , a pesar de lo que el usuario introdujo originalmente. La única forma de evitar este problema es un almacén o un grupo de servidores separados.

Conclusiones sobre el diseño

  • Almacenar con acceso remoto habilitado tiene una puerta de enlace predeterminada que define la URL de puerta de enlace que utilizan los clientes de la aplicación Workspace (Receiver)
  • Para utilizar varias URL de puerta de enlace y acceso iniciado por la aplicación Workspace (Receiver), se deben definir almacenes independientes o grupos de servidores StoreFront

Redirección óptima de HDX

Además de realizar la autenticación, otra razón por la que las puertas de enlace se pueden definir en StoreFront es para Optimal HDX Routing. Esta configuración asigna una puerta de enlace por sitio o zona de Citrix Virtual Apps and Desktops. El propósito de la configuración es redirigir la conexión ICA a través de una puerta de enlace que puede ser diferente del punto de autenticación original del usuario (por ejemplo, a través de una puerta de enlace que esté más cerca del VDA que aloja la sesión del usuario). Si esta puerta de enlace “óptima” no realiza la autenticación, solo necesita servidores STA enlazados para el proxy de sesión y se puede configurar en StoreFront como un tipo de puerta de enlace “HDX Routing only”, lo que elimina toda la configuración de autenticación.

Al asignar esa puerta de enlace a un sitio (mediante Administrar Delivery Controllers) o a una zona (mediante Gestionar zonas) en la configuración de la tienda que se muestra aquí, hay una casilla de verificación opcional Solo para usuarios externos .

Enrutamiento HDX óptimo Figura 4: Enrutamiento HDX óptimo

Esa configuración significa que la puerta de enlace «óptima» solo se utilizará para las sesiones ICA que se originen «externamente», es decir, las sesiones que utilizan el acceso directo a la puerta de enlace como tipo de autenticación (lo que StoreFront supone que el usuario proviene de fuera de la red corporativa). La configuración no se aplicará a los usuarios que se autentiquen directamente en StoreFront (lo que StoreFront supone que el usuario está dentro de la red corporativa). Si la casilla está desactivada, todas las sesiones ICA destinadas a ese sitio o zona se redirigirán a través de la puerta de enlace definida, tanto si el usuario es externo como interno. No hay casilla de verificación “solo interno”. Esto significa que la URL de la puerta de enlace definida debe ser accesible desde todas las ubicaciones posibles de usuario, lo que puede ser difícil sin DNS dividido. Este es otro caso en el que pueden ser necesarios almacenes independientes (ya que se trata de una configuración a nivel de almacén) para casos de arquitectura complejos con redirección óptima de HDX.

Conclusiones sobre el diseño

Para resumir:

  • La puerta de enlace utilizada para el enrutamiento HDX óptimo solo requiere servidores STA enlazados
  • Las puertas de enlace utilizadas para Optimal HDX Routing pueden ser “solo externas” o “externas e internas”, pero no “internas solamente”
  • Se requieren almacenes o grupos de servidores independientes para definir direcciones URL de puerta de enlace internas y externas independientes para la redirección óptimo de HDX

Balizas

Los indicadores se definen por separado de las puertas de enlace en la configuración de StoreFront y se habilitan automáticamente al habilitar el acceso remoto para un almacén y configurar la primera puerta de enlace. Los indicadores son direcciones de sitios web que ayudan a la aplicación Workspace (Receiver) a identificar si el cliente de punto final está dentro o fuera de la red corporativa y redirigir sin problemas la solicitud de acceso a la URL base de StoreFront, si se determina que el cliente es “interno”, o la dirección predeterminada de Gateway, si el cliente se determina que es “externo” sin pedir al usuario más información. Para ello, la aplicación Workspace (Receiver) consultará primero la dirección de baliza interna (suponiendo que siempre se pueda acceder a la dirección externa orientada a Internet) y, a continuación, volverá a las direcciones de balizas externas solo si falla la interna. Si puede llegar a la URL interna (obtiene una respuesta HTTP 200), se supone que el cliente está en la red corporativa y se dirigirá a la URL base de StoreFront.

Administrar balizas Figura 5: Administrar balizas

Las balizas no se utilizan en absoluto si un usuario se está conectando a través de un explorador web. Esto se debe a que un usuario proporciona entrada escribiendo una URL en la barra del explorador y, por lo tanto, dirige el explorador a una dirección específica. Con la aplicación Workspace (Receiver), tras la configuración inicial, el usuario nunca proporciona más información sobre qué URL usar. La aplicación Workspace (Receiver) tiene la URL base y cualquier URL de Gateway configurada en caché como parte de la configuración y debe poder elegir de forma inteligente en nombre del usuario qué URL usar cuando el usuario intente usar la aplicación.

No es necesario modificar ni modificar las direcciones de las balizas a menos que se utilicen la misma URL de Gateway y la URL base de StoreFront. En este caso, las balizas externas e internas serían las mismas y la URL interna sería accesible externamente, lo que contradice el propósito. Por lo tanto, un administrador tendría que elegir “Especificar dirección de indicador” para el indicador interno e introducir un sitio web al que solo se puede acceder desde la red corporativa. De lo contrario, es simplemente una buena práctica de solución de problemas comprender cómo se aplican las direcciones de baliza para que no se examinen al investigar problemas con el acceso basado en explorador web.

Conclusiones sobre el diseño

Para resumir:

  • Los indicadores solo se utilizan clientes de aplicaciones Workspace (Receiver)
  • Los indicadores solo se modifican si la URL base de StoreFront coincide con una URL de puerta de enlace (y es accesible desde fuera de la red corporativa)

Referencias

Integración de Gateway y StoreFront

Configuración de la redirección de HDX óptima

Nuevas funciones de StoreFront

Decisión de diseño: diseño de la integración de StoreFront y Gateway