Metodología del diseño: capa de acceso

La segunda capa de la metodología del diseño es la capa de acceso, que se define para cada grupo de usuarios.

La creación de un diseño adecuado para la capa de acceso es una parte importante del proceso de virtualización de escritorios. Esta capa gestiona la validación de usuarios mediante la autenticación y organiza el acceso a todos los componentes necesarios para establecer una conexión segura al escritorio virtual.

Las decisiones para diseñar la capa de acceso se basan en los requisitos de movilidad de cada grupo de usuarios, así como en los dispositivos de punto final utilizados.

Autenticación

El acceso a los recursos se basa en la identidad del usuario. Al definir la estrategia de autenticación, se tiene en cuenta el punto de entrada del usuario en el entorno, así como la forma en que se autenticará el usuario.

Decisión: Proveedor de autenticación

Tradicionalmente, los usuarios necesitaban un nombre de usuario y una contraseña de Active Directory para obtener acceso a sus recursos de XenApp y XenDesktop. Como la mayoría de las organizaciones solían tener una implementación local de Active Directory, este requisito concreto era fácil de cumplir.

Sin embargo hoy día, las organizaciones utilizan contratistas externos, lo que requiere una cuenta para poder acceder a los recursos de XenApp y XenDesktop. Por eso, las organizaciones están explorando el uso de un proveedor de identidades (IdP) de terceros (como Azure Active Directory, Google, LinkedIn, etc.), en lugar de administrar el suyo propio.

Con la implementación del Servicio de autenticación federada de Citrix, en XenApp y XenDesktop se puede usar un IdP de terceros. Un administrador puede indicar a un contratista que utilice su propia cuenta de Google para acceder a aplicaciones y escritorios aprobados, lo que facilita la incorporación de usuarios.

Decisión: Punto de autenticación

Antes de que un usuario se conecte a un recurso virtual, primero debe autenticarse. El lugar de autenticación suele estar determinado por los requisitos de movilidad del grupo de usuarios, que se definieron durante el proceso de segmentación de usuarios. Existen dos puntos de autenticación disponibles en XenDesktop:

  • StoreFront: Citrix StoreFront ofrece servicios de autenticación y entrega de recursos para Citrix Receiver, lo que permite a los almacenes empresariales centralizados entregar escritorios, aplicaciones y otros recursos.
  • NetScaler Gateway: NetScaler Gateway es un dispositivo que proporciona acceso seguro a las aplicaciones y los datos, y ofrece controles mediante directivas precisas que se pueden aplicar a aplicaciones y datos, a la vez que permite a los usuarios trabajar desde cualquier lugar.

En la siguiente tabla, se indican los puntos de autenticación preferidos según los requisitos de movilidad del grupo de usuarios:

Requisito de movilidad del grupo de usuarios Punto de autenticación preferido
Locales StoreFront
Local itinerante StoreFront
Remota NetScaler Gateway
Locales NetScaler Gateway

La autenticación para grupos de usuarios con un requisito de movilidad remota o móvil puede ocurrir directamente en StoreFront cuando sea necesario. Por ejemplo, puede que las directivas de seguridad DMZ prohíban el acceso desde NetScaler Gateway al dominio, acceso necesario para la autenticación de certificados del cliente con tarjetas inteligentes. En ese caso, el acceso a StoreFront para la autenticación se puede entregar a través de un servidor virtual SSL_BRIDGE de NetScaler, que ofrece un conducto para el tráfico HTTPS. Por regla general, el servidor virtual se alojaría junto a NetScaler Gateway en el mismo NetScaler configurado para proporcionar el acceso HDX Proxy al entorno del escritorio virtual. Aunque tal caso de uso pueda ser necesario a veces, se recomienda autenticar a los usuarios externos a través de NetScaler Gateway.

Decisión: Directiva de autenticación

Una vez identificado el punto de autenticación, se debe determinar el tipo de autenticación. A continuación, dispone de los métodos principales disponibles:

  • StoreFront: Admite varios métodos de autenticación, aunque no todos se recomiendan en función del método de acceso del usuario, los requisitos de seguridad y la ubicación de la red. Tenga en cuenta que, de forma predeterminada, StoreFront autentica a los usuarios directamente con Active Directory, no a través de XML, como hacía la Interfaz Web. A partir de la versión 3.0, StoreFront se puede configurar para delegar la autenticación a XML (por ejemplo, si los servidores StoreFront se encuentran en un dominio que no confía en los dominios de usuario).
    • Nombre de usuario y contraseña: Requiere que los usuarios inicien sesión directamente en el sitio introduciendo un nombre de usuario y una contraseña.
    • PassThrough de dominio: Permite la transferencia de credenciales de dominio desde los dispositivos de los usuarios. Los usuarios realizan la autenticación en los equipos unidos a un dominio de Windows y su sesión se inicia automáticamente cuando acceden a los almacenes.
    • PassThrough de NetScaler Gateway: Permite la autenticación PassThrough desde NetScaler Gateway. Los usuarios se autentican en NetScaler Gateway y su sesión se inicia automáticamente cuando acceden a sus almacenes.
    • Tarjeta inteligente: Permite a los usuarios autenticarse mediante tarjetas inteligentes y números PIN a través de Citrix Receiver para Windows y NetScaler Gateway. Para habilitar la autenticación con tarjeta inteligente, las cuentas de los usuarios deben configurarse ya sea en el dominio de Microsoft Active Directory que contiene los servidores de StoreFront, o bien, en un dominio que tenga una relación de confianza bidireccional directa con el dominio del servidor de StoreFront. No se admiten las implementaciones de varios bosques que requieran relaciones de confianza unidireccionales o relaciones de confianza de diferentes tipos.
    • Anónimo: Permite a los usuarios acceder a aplicaciones y escritorios sin presentar credenciales a StoreFront o Citrix Receiver. Las cuentas anónimas locales se crean cuando se solicitan en el VDA de servidor cuando se inician las sesiones. Eso requiere un almacén de StoreFront configurado para el acceso no autenticado, un VDA basado en SO de servidor y un grupo de entrega de XenApp configurado para usuarios no autenticados.
  • NetScaler Gateway: NetScaler Gateway admite varios métodos de autenticación. La siguiente lista contiene los utilizados principalmente en entornos de escritorios virtuales. Cada uno se puede utilizar individualmente, pero a menudo se combinan para ofrecer la autenticación de varios factores.
    • LDAP: El protocolo ligero de acceso a directorios (LDAP) se utiliza para acceder a servicios de información de directorios como Microsoft Active Directory. NetScaler Gateway utiliza LDAP para autenticar a los usuarios y extraer la información de pertenencia a grupos de esos usuarios.
    • RADIUS (token): RADIUS es un protocolo de seguridad de red basado en UDP que proporciona autenticación, autorización y contabilidad. Un servidor de acceso a la red (NetScaler Gateway en este caso) reenvía las credenciales a un servidor de RADIUS que puede comprobar las credenciales localmente o comprobarlas en un servicio de directorio. Tras la comprobación, el servidor RADIUS puede aceptar la conexión, rechazarla o desafiarla y solicitar una segunda forma de autenticación, como un token.
    • Certificado de cliente: Los usuarios que inician sesión en un servidor virtual de NetScaler Gateway también se pueden autenticar en función de los atributos de un certificado de cliente presentado al servidor virtual. Por lo general, los certificados de cliente se reparten a los usuarios en forma de tarjetas inteligentes o tarjetas de acceso común (CAC) que lee un lector conectado al dispositivo de cada usuario.

El tipo de autenticación de un grupo de usuarios suele determinarse en función de los requisitos de seguridad y el punto de autenticación utilizado. La siguiente tabla ayuda a definir la solución adecuada para cada grupo de usuarios en función del nivel de seguridad requerido:

Punto de autenticación Requisito de seguridad Tipo de autenticación
StoreFront Bajo, medio, alto Bajo: Nombre de usuario y contraseña de LDAP; PassThrough. Medio: Nombre de usuario y contraseña de LDAP; PassThrough. Alto: LDAP y/o tarjeta inteligente
NetScaler Gateway Bajo, medio, alto Bajo: Nombre de usuario y contraseña de LDAP. Medio: Nombre de usuario y contraseña de LDAP. Alto: LDAP y token; LDAP y tarjeta inteligente; token y tarjeta inteligente

Experiencia sobre el terreno

  • Venta al por menor: Una pequeña empresa privada de venta al por menor ofrece a los usuarios de escritorios virtuales acceso a datos no confidenciales, como catálogos de marketing y correo electrónico. No están obligados a cumplir ninguna norma de seguridad, como la ley Sarbanes-Oxley. Por lo tanto, la autenticación de LDAP se ha implementado en función del nombre de usuario y la contraseña.
  • Finanzas: Una empresa mediana dedicada a las finanzas ofrece a sus usuarios de escritorios virtuales acceso a datos confidenciales, como registros de transacciones bancarias. Se rigen por normas de seguridad como SAS 70 y deben utilizar la autenticación de varios factores para los usuarios de acceso remoto. La autenticación LDAP se ha implementado en función del nombre de usuario y la contraseña, junto con la autenticación RADIUS mediante tokens.
  • Gobierno: Una gran institución federal proporciona a los usuarios de escritorios virtuales acceso a datos altamente confidenciales, como registros personales de ciudadanos. Están sujetos a la regulación de las normas de seguridad del Departamento de Defensa (DOD). La autenticación LDAP se ha implementado en función del nombre de usuario y la contraseña, junto con la autenticación de certificado del cliente mediante tarjetas CAC.
  • Asistencia sanitaria: Un hospital utiliza XenApp para entregar su aplicación EMR a los usuarios. El personal médico y de enfermería utilizan dispositivos de clientes ligeros en los carritos estacionarios y móviles para capturar y obtener datos de los pacientes. El acceso no autenticado se ha configurado para evitar que el personal médico tenga que autenticarse en el dominio o en la aplicación EMR.

StoreFront

Citrix StoreFront autentica a los usuarios en los recursos de XenApp y XenDesktop. StoreFront indica y agrega escritorios y aplicaciones disponibles en una única interfaz a la que los usuarios acceden a través de Citrix Receiver para Windows, iOS o Android, o bien desde el sitio web de StoreFront.

Decisión: Alta disponibilidad

Si el servidor que aloja StoreFront no está disponible, los usuarios no podrán iniciar nuevos escritorios virtuales ni aplicaciones publicadas ni administrar sus suscripciones. Por lo tanto, se deben implementar al menos dos servidores de StoreFront para evitar que este componente se convierta en un único punto de fallo. Al implementar una solución de equilibrio de carga, los usuarios no sufrirán interrupciones del servicio. Entre las opciones se incluyen:

  • Equilibrio de carga de hardware: Un dispositivo inteligente capaz de verificar la disponibilidad del servicio de StoreFront y equilibrar de forma activa la carga de las solicitudes de los usuarios. Citrix NetScaler es un buen ejemplo de equilibrador de carga de hardware. Citrix NetScaler es un equilibrador de carga ideal, ya que viene preconfigurado con comprobaciones de estado de StoreFront.
  • Round robin de DNS: Ofrece un equilibrio de carga básico en varios servidores sin realizar comprobaciones de disponibilidad. Si un servidor de StoreFront deja de estar disponible, el round robin de DNS seguirá redirigiendo a los usuarios al servidor que ha fallado. Por eso, Citrix no recomienda round robin de DNS.
  • Equilibrio de carga de red de Windows: Un servicio de Windows capaz de realizar comprobaciones básicas para verificar que el servidor está disponible, pero que no puede determinar el estado de cada servicio. Esto puede provocar que se reenvíe a los usuarios a los servidores de StoreFront que no puedan procesar nuevas solicitudes. Los usuarios no podrían acceder a aplicaciones ni a escritorios.

Decisión: Referencia del Delivery Controller

Para proporcionar escritorios y aplicaciones a los usuarios, StoreFront debe configurarse con la dirección IP o el nombre DNS de, al menos, un Controller en cada sitio de XenDesktop y XenApp. Para la tolerancia a errores, se deben indicar varios controladores para cada sitio o comunidad especificados. De forma predeterminada, StoreFront trata una lista de servidores en orden de conmutación por error (activa/pasiva).

Para implementaciones grandes o entornos con una elevada carga de inicios de sesión, se recomienda una distribución activa de la carga de usuarios (activa/activa). Esto se puede lograr mediante un equilibrador de carga con monitores XML integrados, como Citrix NetScaler, o mediante la configuración de StoreFront para equilibrar la carga de la lista de Controllers en lugar de tratarlos como una lista ordenada.

Decisión: Balizas

Citrix Receiver utiliza balizas (sitios web) para identificar si un usuario se ha conectado a una red interna o externa. Los usuarios internos se conectan directamente a StoreFront para autenticarse, mientras que los usuarios externos se conectan a través de Citrix NetScaler Gateway. Es posible controlar lo que un usuario ve si se restringen las aplicaciones en función de la baliza a la que tienen acceso.

La baliza interna debe ser un sitio que no se pueda resolver externamente. De forma predeterminada, la baliza interna es la URL base de StoreFront. Esto tendrá que ajustarse si se configura la misma URL externa e interna. La baliza externa puede ser cualquier sitio externo que produzca una respuesta HTTP. Citrix Receiver supervisa continuamente el estado de las conexiones de red (por ejemplo, enlaces activos, enlaces inactivos o cambios de la puerta de enlace predeterminada). Cuando se detecta un cambio de estado, Citrix Receiver comprueba primero que se puede acceder a los puntos de la baliza interna antes de pasar a comprobar la accesibilidad de los puntos de la baliza externa. StoreFront proporciona a Citrix Receiver las direcciones HTTP(s) de los puntos de la baliza durante el proceso inicial de descarga de la conexión/configuración y ofrece las actualizaciones según convenga. Es necesario especificar al menos dos balizas externas de alta disponibilidad que se pueden resolver desde redes públicas.

Decisión: Presentación de los recursos

De forma predeterminada, StoreFront permite a los usuarios elegir (suscribirse) los recursos que quiere utilizar regularmente después de iniciar sesión (favoritos). Este enfoque, considerado como “autoservicio”, permite a los usuarios limitar los recursos que ven en su pantalla de inicio a los que usan habitualmente. El servicio del almacén de suscripción registra los recursos que elige cada usuario para cada almacén y los almacena localmente en cada servidor de StoreFront (sincronizados automáticamente entre los servidores del mismo grupo de servidores) para que puedan mostrarse en la pantalla de inicio de Citrix Receiver de cualquier dispositivo desde el que el usuario se conecte. Aunque, de forma predeterminada, las suscripciones son por almacén y por grupo de servidores, los administradores pueden configurar dos almacenes dentro de un grupo de servidores para compartir una base de datos de suscripciones y/o sincronizar suscripciones entre dos almacenes con un nombre idéntico en dos grupos de servidores independientes según una programación definida si fuera necesario.

Los administradores deben determinar las aplicaciones que deben mostrarse siempre a los usuarios en su pantalla de inicio o en la ficha destacada. En general, estas aplicaciones son aplicaciones comunes como el conjunto de programas de Microsoft Office y cualquier otra aplicación que puedan necesitar todos los usuarios de un entorno. StoreFront puede filtrar o presentar estos recursos mediante palabras clave definidas en el campo Descripción de las propiedades de las aplicaciones publicadas.

Esta tabla detalla las opciones de las palabras clave:

Palabra clave Descripción
Auto Suscribe automáticamente todos los usuarios de un almacén a una aplicación. Cuando los usuarios inicien sesión en el almacén, la aplicación se aprovisionará automáticamente sin que los usuarios tengan que suscribirse de forma manual a la aplicación. Los usuarios pueden optar por eliminar posteriormente esta suscripción si lo prefieren.
Mandatory Una novedad en StoreFront 2.5, la palabra clave Mandatory hará que las aplicaciones se suscriban automáticamente a los usuarios del almacén. Sin embargo, los usuarios no dispondrán de la opción de quitar la aplicación. Este parámetro es útil cuando se crea un conjunto básico de aplicaciones que siempre deben presentarse a todos los usuarios.
Featured Si quiere anunciar aplicaciones o facilitar a los usuarios la búsqueda de las aplicaciones más utilizadas, indíquelas en la lista Destacadas de Citrix Receiver.
Prefer Especifique que se debe utilizar una aplicación instalada localmente en lugar de una aplicación disponible en Receiver. Receiver busca el nombre o la ruta especificados para determinar si la aplicación está instalada localmente. Si lo está, Receiver suscribe la aplicación y no crea ningún acceso directo. Cuando el usuario inicia la aplicación desde la ventana de Receiver, Receiver inicia la aplicación instalada localmente (preferida). Si un usuario desinstala una aplicación preferida desde fuera de Receiver, la próxima vez que Receiver se actualice se cancela la suscripción a la aplicación. Si un usuario desinstala una aplicación preferida desde la ventana de Receiver, se cancela la suscripción a la aplicación pero no la desinstala.
TreatAsApp De forma predeterminada, Receiver para sitios web trata a los escritorios VDI de XenDesktop y a los escritorios compartidos alojados de XenApp como los demás escritorios. Al usar la palabra clave “TreatAsApp”, el escritorio se mostrará en las vistas de aplicaciones de Receiver para sitios web en lugar de mostrarse en las vistas de escritorios. Los usuarios deben suscribirse antes de poder acceder al escritorio.
Primary En una implementación de varios sitios, el uso de esta palabra clave garantiza la entrega de aplicaciones desde un sitio designado. Si una aplicación está disponible desde varios sitios, con el mismo nombre, la aplicación del sitio secundario solo se mostrará si la aplicación no está disponible desde el sitio principal.
Secondary La misma propiedad que la palabra clave “Primary”, excepto que designa una aplicación en el sitio secundario.

Decisión: Grupos de agregación

Si la solución XenApp y XenDesktop incluye varios sitios de entrega, StoreFront combina los recursos disponibles para que el usuario disponga de una única interfaz para todos los recursos publicados. Sin embargo, si varios sitios publican los mismos recursos, el usuario puede quedar confundido, ya que una sola aplicación aparece varias veces.

Experiencia del usuario sin una imagen de agregación

Los grupos de agregación de StoreFront definen cómo se combinan los recursos de varios sitios para proporcionar al usuario una vista única e intuitiva. StoreFront agrupa recursos publicados duplicados en un solo icono.

Experiencia del usuario con una imagen de agregación

El administrador debe determinar cómo equilibrar la carga de los usuarios en los diferentes sitios de XenApp y XenDesktop cuando el icono es una agregación. Las opciones son:

  • Equilibrio de carga: Se utiliza cuando los sitios duplicados se crean en función de las recomendaciones sobre la capacidad. StoreFront distribuye las solicitudes de los usuarios por todos los sitios configurados.
  • Conmutación por error: Se utiliza cuando las geografías necesitan disponer de recursos en caso de una interrupción del servicio o al migrar usuarios de un sitio a otro (como un proyecto de migración de XenApp).

Es aconsejable documentar los usuarios, los almacenes y los métodos de agregación durante la fase de diseño.

Grupo de usuarios Almacenes disponibles Almacenes de equilibrio de carga Almacenes de conmutación por error
NA_FinanceUsers NA_West_Store, NA_East_Store, EMEA_Store NA_West_Store, NA_East_Store EMEA_Store
EMEA_SalesUsers EMEA_Store, NA_East_Store EMEA_Store NA_East_Store

Decisión: Escalabilidad

La cantidad de usuarios de Citrix Receiver que admite un único servidor de StoreFront depende de los recursos asignados y del nivel de actividad de los usuarios. Tenga en cuenta que, de media, los usuarios de Receiver para Web consumirán más RAM que los usuarios nativos de Receiver, pero se recomienda un mínimo de 4 GB de RAM por servidor de StoreFront en todos los casos como base. Además, si hay más sitios o comunidades por almacén, esto incrementará la utilización de la CPU y el tiempo de respuesta del servidor, con las comunidades de IMA de XenApp que afectarán más a la escalabilidad que el sitio de FMA de XenApp y XenDesktop.

Implementación de StoreFront Uso de CPU Actividades simultáneas
Implementación independiente: 4 CPU, 4 GB de RAM, uso intensivo (inicio de sesión, enumeración, suscripción, cancelación de suscripción, cierre de sesión) 75% 291 por segundo
Implementación independiente: 4 CPU, 4 GB de RAM, uso intensivo (inicio de sesión, enumeración, suscripción, cancelación de suscripción, cierre de sesión) 90% 375 por segundo
Implementación de StoreFront en clúster: 2 nodos, cada uno con 4 unidades CPU, 4 GB de RAM, uso intensivo (inicio de sesión, enumeración, suscripción, cancelación de suscripción, cierre de sesión) 75% 529 por segundo
Implementación de StoreFront en clúster: 2 nodos, cada uno con 4 unidades CPU, 4 GB de RAM, uso intensivo (inicio de sesión, enumeración, suscripción, cancelación de suscripción, cierre de sesión) 90% 681 por segundo

Las pruebas han mostrado una disminución del rendimiento cuando una sola implementación de StoreFront crece más de 3 o 4 nodos de StoreFront con un máximo de 5 o 6 servidores admitidos en un único grupo de servidores.

NetScaler Gateway

Los grupos de usuarios que utilizan NetScaler Gateway como punto de autenticación tienen en cuenta decisiones de diseño adicionales. Estas decisiones de diseño no se aplican a puntos de autenticación que no sean NetScaler Gateway.

Decisión: Topología

La selección de la topología de red es fundamental para planificar la arquitectura de acceso remoto a fin de garantizar la funcionalidad, el rendimiento y la seguridad necesarios. El diseño de la arquitectura de acceso remoto debe completarse en colaboración con el equipo de seguridad para garantizar el cumplimiento de los requisitos de seguridad corporativos. Existen dos topologías principales a considerar; una ofrece un nivel de seguridad mayor que la otra:

  • 1 brazo (seguridad estándar): Con la topología de 1 brazo, NetScaler Gateway utiliza una interfaz enlazada física o lógicamente, con LAN virtual y subred IP asociadas, para transportar tanto el tráfico front-end para los usuarios como el tráfico back-end para los servicios y servidores de la infraestructura de escritorios virtuales.

Imagen de la topología de brazo

  • 2 brazos (alta seguridad): Con la topología de 2 brazos, NetScaler Gateway utiliza dos o más interfaces enlazadas física o lógicamente, con las redes LAN virtuales y subredes IP asociadas. El transporte del tráfico front-end para los usuarios se dirige a una de estas interfaces. El tráfico front-end está aislado del tráfico back-end (entre los servicios y los servidores de la infraestructura de escritorios virtuales), que se dirige a una segunda interfaz. Eso permite el uso de zonas desmilitarizadas (DMZ) separadas para aislar los flujos del tráfico front-end y back-end, junto con un control y una supervisión granulares del firewall.

Imagen de la topología de brazo

Decisión: Alta disponibilidad

Si NetScaler Gateway no está disponible, los usuarios remotos no podrán acceder al entorno. Por lo tanto, se deben implementar al menos dos hosts NetScaler Gateway para evitar que este componente se convierta en un único punto de fallo.

Al configurar NetScaler Gateway en un par de alta disponibilidad (activo/pasivo), el NetScaler Gateway secundario supervisa el primer dispositivo enviando mensajes periódicos, también denominados mensajes de latido o comprobaciones de estado, para determinar si el dispositivo principal acepta conexiones. Si se produce un error en la comprobación del estado, el NetScaler Gateway secundario vuelve a intentar la conexión durante un período de tiempo especificado hasta que determine que el dispositivo principal no funciona. Si el dispositivo secundario confirma el error de comprobación del estado, el NetScaler Gateway secundario toma el lugar del NetScaler Gateway principal.

Tenga en cuenta que en el firmware 10.5 y versiones posteriores, la agrupación en clústeres también es posible con varias instancias de NetScaler Gateway para ofrecer la alta disponibilidad, aunque el soporte para las configuraciones de nodos concretos frente a las configuraciones de nodos intermitentes varía según el firmware y la configuración de Gateway (VPN SSL completo frente al proxy ICA). (https://docs.citrix.com/en-us/netscaler/11-1/clustering/cluster-features-supported.html)

Decisión: Plataforma

Para identificar una plataforma NetScaler adecuada para cumplir los requisitos del proyecto, se deben identificar las restricciones clave de los recursos. Dado que todo el tráfico de acceso remoto se protegerá mediante la capa de sockets seguros (SSL), transportada por el protocolo de transferencia de hipertexto (HTTP), existen dos métricas de recursos:

  • Procesamiento de SSL: El procesamiento de SSL son los gigabits del tráfico SSL que se pueden procesar por segundo (Gbps).
  • Transacciones SSL por segundo (TPS): La métrica TPS identifica cuántas veces por segundo un Application Delivery Controller (ADC) puede ejecutar una transacción SSL. La capacidad varía principalmente en función de la longitud de clave requerida. La capacidad de TPS es una consideración útil principalmente durante la fase de negociación, cuando SSL se configura por primera vez, y es menos un factor en la fase de cifrado y descifrado por lotes, que es la mayor parte de la sesión. Aunque TPS es una métrica importante que supervisar, la experiencia de campo ha demostrado que el procesamiento de SSL es el factor más importante para identificar el NetScaler Gateway apropiado.

La sobrecarga media del ancho de banda de SSL se suele considerar insignificante en relación con el volumen de tráfico de escritorio virtual y no se suele tener en cuenta como parte del procesamiento de SSL requerido. Sin embargo, hacer provisiones para el ancho de banda de SSL garantizará que el procesamiento total estimado sea suficiente. El ancho de banda fijo agregado a los encabezados de los paquetes puede variar según los algoritmos de cifrado utilizados; el porcentaje general del ancho de banda puede variar ampliamente según el tamaño del paquete. Idealmente, la sobrecarga debe medirse durante una prueba piloto o de concepto. Sin embargo, en ausencia de tales datos que incrementen el ancho de banda de la carga de trabajo en un 2%, es una regla general razonable. Por lo tanto, para determinar el procesamiento de SSL requerido por una plataforma de NetScaler, multiplique por 1,02 el máximo de ancho de banda simultáneo para un centro de datos:

Procesamiento de SSL = Máximo de ancho de banda simultáneo x 1,02

Por ejemplo, tomando 128 Mbps como máximo de ancho de banda simultáneo, el modelo de NetScaler apropiado se puede determinar de la siguiente manera:

~130 Mbps = 128 Mbps x 1,02

El valor del procesamiento de SSL debe compararse con las prestaciones de rendimiento de varias plataformas de NetScaler con el objetivo de determinar la más adecuada para el entorno. Hay tres grupos principales de plataformas disponibles. Cada uno ofrece amplias opciones de escalabilidad.

  • VPX: Un dispositivo NetScaler VPX proporciona la misma funcionalidad completa que NetScaler en hardware. Sin embargo, los dispositivos NetScaler VPX pueden aprovechar servidores “comerciales” para el alojamiento y son adecuados para entornos de tamaño pequeño y mediano. Normalmente, las organizaciones crean un límite de referencia de 500 usuarios para las instancias de VPX.
  • MPX: NetScaler MPX es la versión en hardware de los dispositivos NetScaler. El dispositivo MPX es más potente que el dispositivo virtual NetScaler y puede admitir optimizaciones de red para implementaciones empresariales a gran escala, especialmente al configurar la descarga de SSL, ya que esto lleva a cabo en el software de los dispositivos VPX en lugar de los chips de SSL dedicados en los dispositivos MPX.
  • SDX: NetScaler SDX es una mezcla entre los dispositivos NetScaler virtuales y físicos. Una máquina SDX es un dispositivo físico capaz de alojar múltiples dispositivos virtuales NetScaler. Esta consolidación de dispositivos ayuda a reducir el espacio de estantería requerido y la consolidación de dispositivos. Los dispositivos NetScaler SDX son adecuados para manejar comunicaciones de red en implementaciones de grandes empresas y proveedores de alojamiento multiarrendatario.

Las prestaciones del procesamiento de SSL de las plataformas de NetScaler se pueden consultar en la hoja de datos de Citrix NetScaler. Por lo tanto, basándose en el cálculo de ejemplo anterior, un dispositivo NetScaler MPX 5550 sería suficiente para manejar la carga requerida. Sin embargo, la escalabilidad dependerá, en realidad, de los requisitos de seguridad. El procesamiento de SSL de NetScaler disminuye con el uso de algoritmos de cifrado cada vez más complejos y longitudes de clave más largas. Además, este cálculo representa un único dispositivo NetScaler principal. Como mínimo, se recomienda la redundancia N+1 que requeriría un dispositivo NetScaler adicional de la misma plataforma y el mismo modelo.

Nota

La hoja de datos de Citrix NetScaler suele representar prestaciones de procesamiento en condiciones óptimas para el rendimiento. No obstante, el rendimiento se ve directamente afectado por los requisitos de seguridad. Por ejemplo, si se utiliza el algoritmo de cifrado RC4 y una longitud de clave 1k, una plataforma de VPX puede manejar más de 500 conexiones proxy HDX. Sin embargo, si se utiliza un algoritmo de cifrado 3DES y una longitud de clave 2k (que son cada vez más comunes), es posible que el rendimiento se reduzca a la mitad.

Decisión: Directiva de preautenticación

Si se quiere, se puede aplicar una directiva de preautenticación a grupos de usuarios con NetScaler Gateway como punto de autenticación. Las directivas de preautenticación limitan el acceso al entorno en función de si el dispositivo de punto final cumple determinados criterios mediante análisis de Endpoint Analysis (EPA).

Las directivas de acceso de preautenticación se pueden configurar para probar antivirus, firewalls, sistemas operativos o incluso la configuración del Registro. Estas directivas se pueden utilizar para impedir el acceso por completo o las puede usar XenDesktop para controlar las funciones de sesión, como la asignación de portapapeles, la asignación de impresoras e incluso la disponibilidad de aplicaciones y escritorios específicos. Por ejemplo, si un dispositivo de usuario no tiene antivirus instalado, se puede establecer un filtro para ocultar aplicaciones confidenciales.

La siguiente imagen ofrece una descripción general de cómo se pueden utilizar varias directivas para personalizar las funciones de un recurso de virtualización:

Imagen de la lógica de la decisión sobre el acceso inteligente

Experiencia sobre el terreno

  • Minoristas: Un pequeño minorista privado utiliza EPA para detectar la presencia de definiciones de antivirus actualizadas antes de permitir el acceso.
  • Financieras: Una empresa financiera mediana utiliza análisis de EPA del SID de dominio para comprobar que los usuarios son miembros del dominio empresarial antes de permitirles el acceso.
  • Gubernamentales: Una gran institución federal utiliza EPA para escanear dispositivos de punto final y comprobar que se ha instalado un certificado (o un conjunto de certificados) específico en el dispositivo antes de permitirles el acceso.

Decisión: Directiva de sesión

Los grupos de usuarios con NetScaler Gateway como punto de autenticación deben tener definidas las directivas de sesión correspondientes. Las directivas de sesión se utilizan para definir la experiencia general de usuario posterior a la autenticación.

Las organizaciones crean directivas de sesión basadas en el tipo de dispositivo Citrix Receiver utilizado. Para la asignación de directivas de sesión, los dispositivos se agrupan normalmente en no móviles (como Windows, Mac y Linux OS) y móviles (como iOS o Android). Por lo tanto, debe adoptarse una decisión sobre la compatibilidad con dispositivos móviles, dispositivos no móviles o ambos en función de los requisitos de los dispositivos cliente identificados durante la fase de evaluación.

Para identificar las directivas de sesión de dispositivos, incluya expresiones como las descritas en este artículo.

  • Dispositivos móviles: La expresión se establece en REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver, que tiene una prioridad más alta que la directiva de dispositivos no móviles para garantizar que los dispositivos móviles se detecten (y no los dispositivos no móviles).
  • Dispositivos no móviles: La expresión se establece en ns_true, lo que significa que debe aplicarse a todo el tráfico que se le envíe.

Las directivas de sesión también se pueden usar para aplicar expresiones de análisis de dispositivos de punto final. Estas directivas de sesión se aplican después de la autenticación, pero imitan las directivas de preautenticación mencionadas anteriormente. El uso de directivas de sesión es una opción para ofrecer un plan B a los dispositivos de punto final que no cumplen todos los requisitos de seguridad, como el acceso de solo lectura a aplicaciones específicas.

Decisión: Perfil de sesión

Cada directiva de sesión debe tener definido un perfil de sesión correspondiente. El perfil de sesión define los detalles necesarios para que el grupo de usuarios obtenga acceso al entorno. Existen dos formas principales de perfiles de sesión que determinan el método de acceso al entorno de los escritorios virtuales:

  • VPN SSL: Los usuarios crean una red privada virtual y tunelizan todo el tráfico configurado por direcciones IP a través de la red interna. El dispositivo cliente del usuario puede acceder a los recursos de intranet permitidos como si se hallara en la red interna. Esto incluye los sitios de XenDesktop y cualquier otro tráfico interno, como recursos compartidos de archivos o sitios web de la intranet. Esto se considera un método de acceso potencialmente menos seguro, ya que los puertos de red y las rutas a servicios fuera de la VDI pueden abrirse, lo que deja vulnerable a la empresa antes los posibles riesgos que conlleva el acceso completo a una VPN. Estos riesgos pueden incluir ataques de denegación de servicio, intentos para hackear servidores internos o cualquier otra forma de actividad dañina que se pueda iniciar desde malware, troyanos u otros virus a través de un cliente basado en Internet contra servicios empresariales vulnerables a través de rutas y puertos.

Otra decisión a tener en cuenta sobre cuándo se requiere una VPN SSL es si habilitar la tunelización dividida para el tráfico de red del cliente. Al habilitar la tunelización dividida, el tráfico de red del cliente dirigido a la intranet por Citrix Receiver puede limitarse a rutas y puertos asociados a servicios específicos. Al inhabilitar la tunelización dividida, todo el tráfico de red del cliente se dirige a la intranet, por lo que tanto el tráfico destinado a servicios internos como el tráfico destinado a los servicios externos (Internet) atraviesa la red corporativa. La ventaja de habilitar la tunelización dividida es que la exposición de la red corporativa es limitada y se conserva el ancho de banda de la red. La ventaja de inhabilitar la tunelización dividida es que el tráfico del cliente puede supervisarse o controlarse a través de sistemas como filtros web o sistemas de detección de intrusiones.

Imagen de la VPN SSL

  • HDX Proxy: Con HDX Proxy, los usuarios se conectan a sus escritorios y aplicaciones virtuales a través de NetScaler Gateway sin exponer direcciones internas externamente. En esta configuración, NetScaler Gateway actúa como una micro VPN y solo maneja el tráfico HDX. Otros tipos de tráfico en el dispositivo de punto final del cliente, como el correo privado o el tráfico personal de Internet, no utilizan NetScaler Gateway.

En función del dispositivo de punto final y el dispositivo Citrix Receiver utilizados, se debe tomar una decisión sobre si este método es compatible con cada grupo de usuarios. HDX Proxy se considera un método de acceso seguro para el acceso a escritorios virtuales remotos, ya que solamente el tráfico específico de la sesión de escritorio tiene permiso para atravesar la infraestructura corporativa. La mayoría de los dispositivos Citrix Receiver admiten HDX Proxy, y es el método preferido:

Imagen de HDX Proxy

Decisión: Centro de datos preferido

Las empresas suelen tener varios centros de datos activos que proporcionan alta disponibilidad para aplicaciones con misiones de gran importancia. Es posible que algunos escritorios o aplicaciones virtuales entren en esa categoría, mientras que a otros solo se puede acceder desde un específico centro de datos preferido. Por lo tanto, es posible que el dispositivo NetScaler Gateway inicial en el que un usuario se autentica en el entorno de varios centros de datos activos se halle en el centro de datos preferido correspondiente a los recursos de la VDI del usuario. StoreFront puede determinar la ubicación de los recursos asignados al usuario y dirigir la sesión HDX a dichos recursos; sin embargo, es posible que la ruta resultante sea subopcional (conexión WAN del dispositivo NetScaler Gateway a los recursos de escritorio/aplicación virtual, al contrario que la conexión LAN).

Existen métodos estáticos y dinámicos disponibles para dirigir las sesiones HDX a sus recursos de escritorio virtual en su centro de datos principal. La decisión sobre el qué método seleccionar debe basarse en la disponibilidad de tecnología para asignar de manera dinámica enlaces a sitios como Global Server Load Balancing (GSLB), junto con la evaluación de la red del ancho de banda de la intranet y de Internet, así como las prestaciones de la calidad de servicio (QoS).

Nota

Para obtener más información sobre la configuración de los métodos estáticos y dinámicos de GSLB, consulte la documentación de los productos Citrix: Configuring GSLB for Proximity.

Estático

  • Directo: Se puede otorgar al usuario un FQDN asignado a un registro A dedicado a los dispositivos NetScaler Gateway del centro de datos principal, lo que les permite acceder a su escritorio virtual directamente en cualquier lugar del mundo. Este enfoque elimina una capa de complejidad agregada con la asignación dinámica. No obstante, también elimina las opciones de tolerancia de fallos, como la capacidad de acceder al escritorio virtual a través de una ruta de intranet alternativa cuando una interrupción del centro de datos principal se limita a la infraestructura de acceso.

Dinámico

  • Intranet: Para la mayoría de los entornos dinámicos, el centro de datos inicial seleccionado para la autenticación es el más cercano al usuario. Protocolos como la proximidad dinámica GSLB calculan la menor latencia entre el servidor DNS local del usuario y el dispositivo NetScaler Gateway. Entonces, de forma predeterminada, la sesión HDX se redirige a través del mismo dispositivo NetScaler Gateway al centro de datos que aloja las aplicaciones y escritorios virtuales del usuario. La ventaja de este enfoque es que la mayor parte de la sesión HDX atravesaría la red WAN corporativa, donde se puede utilizar la calidad del servicio.

Imagen de la conexión de intranet

  • Internet: Asimismo, la sesión HDX puede volver a redirigirse a través de un dispositivo NetScaler Gateway alternativo que esté próximo al servidor de XenApp o del escritorio VDI back-end, lo que hace que la mayor parte de la sesión HDX se transfiera por Internet. Por ejemplo, un usuario con un escritorio dedicado en Estados Unidos que viaja a Europa puede verse dirigido a un dispositivo NetScaler Gateway alojado en un centro de datos europeo basado en proximidad. Sin embargo, cuando el usuario inicia su escritorio, se establecerá una conexión HDX con el escritorio virtual a través de un dispositivo NetScaler Gateway alojado en el centro de datos preferido de Estados Unidos.

Esto conserva el uso de la red WAN (a costa de QoS) y se recomienda en los casos en que la conexión a Internet del usuario puede ofrecer una experiencia más estable que la red WAN corporativa.

Imagen de la conexión a Internet

Algunos clientes utilizarán una combinación de estos métodos, como direcciones URL dinámicas geoespecíficas, de modo que se ofrece la tolerancia de fallos dentro de una zona geográfica (como Norteamérica) sin incurrir en la complejidad de GSLB global.

Conectividad de sitio a sitio

Un sitio de XenApp y XenDesktop es capaz de abarcar varias ubicaciones. Para implementar correctamente una solución para varios sitios, el diseño debe tener en cuenta los enlaces de sitio a sitio y la redirección de sesiones de XenApp y XenDesktop entre ubicaciones para ofrecer la mejor experiencia de usuario posible.

Decisión: Redirección optimizada de HDX

En una solución de XenApp y XenDesktop para varios sitios, ciertos criterios, como el tiempo más rápido de respuesta o la proximidad más cercana, redirigen a los usuarios al sitio óptimo. Estos algoritmos no tienen en cuenta los recursos a los que un usuario quiere acceder.

Una redirección incorrecta de la sesión de un usuario da como resultado lo siguiente:

Imagen de redirección de HDX

  1. Se redirige al usuario al sitio de mayor preferencia en función de la proximidad o el tiempo de respuesta
  2. NetScaler Gateway actúa como proxy del tráfico ICA al recurso correcto, que podría estar en la red WAN corporativa.

Idealmente, la redirección optimizada debería asemejarse a esto:

Imagen de redirección optimizada

  1. Se redirige al usuario al sitio de mayor preferencia en función de la proximidad o el tiempo de respuesta
  2. En función del recurso seleccionado, NetScaler Gateway redirige la sesión a un dispositivo NetScaler Gateway del sitio preferido.
  3. NetScaler Gateway actúa como proxy del tráfico ICA al recurso correcto, que permanece en la red LAN local.

El uso de la opción de redirección de HDX optimizada en StoreFront descarga el tráfico de la red WAN corporativa y lo transfiere a la red pública.

Decisión: Red WAN virtual

Cuando hay sucursales, el diseño de XenApp y XenDesktop debe evaluar la conexión de la sucursal con los centros de datos que alojan los recursos de escritorio y aplicaciones. Si la conexión WAN entre la sucursal y el centro de datos no puede cumplir los requisitos de usuario, la experiencia de usuario general empeora. Las organizaciones tienen un par de opciones para las conexiones WAN:

  • Ampliación vertical: Las organizaciones pueden, simplemente, aumentar el tamaño de la canalización de la red WAN que conecta las sucursales con el centro de datos, normalmente a un coste considerable.
  • Ampliación horizontal: Las organizaciones pueden mantener su conexión WAN actual y ampliarla con varias alternativas de bajo coste. La integración de todas las conexiones entre la sucursal y el centro de datos crea una red WAN virtual definida por software, como NetScaler SD-WAN. El dispositivo envía paquetes de red duplicados a través de todas las conexiones WAN definidas dentro de la red WAN virtual. El dispositivo del otro extremo de la red WAN utiliza el primer paquete que llega y descarta todos los paquetes posteriores. A medida que las condiciones de los múltiples enlaces cambian a lo largo del día, este enfoque sigue garantizando la mejor experiencia posible.

Imagen de NetScaler SD-WAN

Metodología del diseño: capa de acceso