Remedo de sesiones
El remedo de sesiones permite a los administradores de dominio ver las sesiones ICA de los usuarios en una red de intranet. La función utiliza noVNC para conectarse a las sesiones ICA.
Nota:
Para usar la función, utilice
Citrix Directorversión 7.16 o posterior.
Instalación y configuración
Dependencias
Se requieren dos dependencias nuevas, python-websockify y x11vnc, para el remedo de sesiones. Instale python-websockify y x11vnc de forma manual después de instalar Linux VDA.
Para RHEL 7.x y Amazon Linux 2:
Ejecute este comando para instalar python-websockify y x11vnc (la versión 0.9.13 de x11vnc o una posterior):
sudo pip3 install websockify
sudo yum install x11vnc
<!--NeedCopy-->
(Para RHEL 7.x) Para resolver python-websockify y x11vnc, habilite los repositorios Extra Packages for Enterprise Linux (EPEL) y RPM opcionales:
-
EPEL
El repositorio EPEL es necesario para
x11vnc. Ejecute este comando para habilitar el repositorio de EPEL:yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm <!--NeedCopy--> -
RPM opcionales
Ejecute este comando para habilitar el repositorio opcional de
RPMspara instalar algunos paquetes de dependencias dex11vnc:subscription-manager repos --enable rhel-7-server-optional-rpms --enable rhel-7-server-extras-rpms <!--NeedCopy-->
Para RHEL 9.4/9.3/9.2/9.0/8.x y Rocky Linux 9.4/9.3/9.2/9.0/8.x:
Ejecute este comando para instalar python-websockify y x11vnc (la versión 0.9.13 de x11vnc o una posterior).
sudo pip3 install websockify
sudo yum install x11vnc
<!--NeedCopy-->
Para resolver x11vnc, habilite los repositorios EPEL y CodeReady Linux Builder:
dnf install -y --nogpgcheck https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
subscription-manager repos --enable "codeready-builder -for-rhel-8-x86_64-rpms"
<!--NeedCopy-->
Para Ubuntu:
Ejecute este comando para instalar python-websockify y x11vnc (la versión 0.9.13 de x11vnc o una posterior):
sudo pip3 install websockify
sudo apt-get install x11vnc
<!--NeedCopy-->
Para SUSE:
Ejecute este comando para instalar python-websockify y x11vnc (la versión 0.9.13 de x11vnc o una posterior):
sudo pip3 install websockify
sudo zypper install x11vnc
<!--NeedCopy-->
Para Debian:
Ejecute este comando para instalar python-websockify y x11vnc (la versión 0.9.13 de x11vnc o una posterior):
sudo pip3 install websockify
sudo apt-get install x11vnc
<!--NeedCopy-->
Puerto
La función de remedo de sesiones selecciona automáticamente los puertos disponibles desde el puerto 6001 al puerto 6099 para crear las conexiones de Linux VDA con Citrix Director. Por lo tanto, la cantidad de sesiones ICA que puede remedar simultáneamente se limita a 99. Compruebe que haya puertos disponibles suficientes para ajustarse a sus necesidades, sobre todo para el remedo de varias sesiones.
Registro
Esta tabla contiene los registros relacionados:
| Registro | Descripción | Valor predeterminado |
|---|---|---|
| EnableSessionShadowing | Habilita o inhabilita la función de remedo de sesiones | 1 (Habilitada) |
| ShadowingUseSSL | Determina si cifrar la conexión entre Linux VDA y Citrix Director. | 0 (Inhabilitada) |
Ejecute el comando ctxreg en Linux VDA para cambiar los valores de Registro. Por ejemplo, para inhabilitar el remedo de sesiones, ejecute el siguiente comando:
/opt/Citrix/VDA/bin/ctxreg update -k "HKLM\Software\Citrix\VirtualDesktopAgent" -v "EnableSessionShadowing" -d "0x00000000"
<!--NeedCopy-->
SSL
La conexión noVNC entre Linux VDA y Citrix Director usa el protocolo WebSocket. Para el remedo de sesiones, el registro “ShadowingUseSSL” mencionado anteriormente determina si se selecciona ws:// o wss://. De forma predeterminada, se elige ws://. Sin embargo, por razones de seguridad, se recomienda usar wss:// e instalar certificados en cada cliente de Citrix Director y en cada servidor Linux VDA. Citrix renuncia a toda responsabilidad de seguridad sobre el remedo de sesiones de Linux VDA mediante ws://.
Para habilitar SSL, ejecute el comando siguiente:
/opt/Citrix/VDA/bin/ctxreg update -k "HKLM\Software\Citrix\VirtualDesktopAgent" -v "ShadowingUseSSL" -d "0x00000001"
<!--NeedCopy-->
Obtener certificados SSL raíz y de servidor
Los certificados deben estar firmados por una entidad de confianza llamada Entidad de certificación (CA).
Se necesita un certificado de servidor (clave incluida) por cada servidor Linux VDA donde quiera configurar SSL. Un certificado de servidor identifica a un equipo concreto, de modo que necesita el nombre de dominio completo (FQDN) de cada servidor. Para mayor comodidad, considere la posibilidad de usar un certificado comodín para todo el dominio.
También se requiere un certificado raíz para cada cliente de Citrix Director que se comunique con Linux VDA. Los certificados de raíz están disponibles en las mismas CA que emiten los certificados de servidor.
Puede instalar certificados de servidor y cliente de las siguientes entidades de certificación:
- Una entidad de certificación incluida en el sistema operativo
- Una entidad de certificación empresarial (una entidad que su organización pone a su disposición)
- Una entidad de certificación no incluida en el sistema operativo
Consulte con el equipo de seguridad de su organización para saber qué método es necesario para obtener certificados.
Importante:
- El nombre común de un certificado de servidor debe contener el FQDN exacto de Linux VDA o, al menos, el comodín y los caracteres de dominio correctos. Por ejemplo, vda1.dominiobase.com o *.dominiobase.com.
- Algunos exploradores Web no admiten los algoritmos hash, incluidos SHA1 y MD5, porque estos ofrecen demasiado poca seguridad para las firmas en los certificados digitales. Por lo tanto, se especifica SHA-256 como el estándar mínimo.
- Chrome ha dejado de aceptar certificados SSL autofirmados por considerarlos inseguros. El error
NET::ERR_CERT_COMMON_NAME_INVALIDse produce porque el certificado generado carece del campo SAN (subjectAltName). Para resolver este problema, proporcione un certificado con atributos extendidos (extensiones X509 v3) que incluyan el campo SAN.
Instalar un certificado raíz en cada cliente de Citrix Director
El remedo se sesiones usa el mismo almacén de certificados (basado en el registro del sistema) que IIS, de modo que se puede instalar certificados con IIS o el complemento de certificados de Microsoft Management Console (MMC). Cuando reciba un certificado de la entidad de certificación, puede reiniciar el asistente para certificados de servidor web en IIS y será el asistente quien instalará el certificado. Como alternativa, puede ver e importar certificados en el equipo. Para ello, abra MMC y agregue el certificado como un complemento independiente a dicha consola. Internet Explorer y Google Chrome importan los certificados instalados en su sistema operativo de forma predeterminada. Para Mozilla Firefox, debe importar los certificados de CA raíz en la ficha Autoridades del Administrador de certificados.
Instalar un certificado de servidor y su clave en cada servidor Linux VDA
Denomine los certificados de servidor “shadowingcert.*” y el archivo de clave “shadowingkey.*” (* indica el formato, como shadowingcert.pem o shadowingkey.key). Coloque los certificados de servidor y los archivos de clave en la ruta /etc/xdl/shadowingssl y protéjalos con permisos restringidos, permitiendo que solo ctxsrver tenga acceso de lectura. Un nombre o una ruta incorrectos impide a Linux VDA encontrar un certificado o archivo de clave concreto, lo que causa un error de conexión con Citrix Director. Los comandos son los siguientes:
cp <vda's-public-key> /etc/xdl/shadowingssl/shadowingcert.pem
cp <vda's-server-private-key> /etc/xdl/shadowingssl/shadowingkey.key
sudo chown ctxsrvr:ctxadm /etc/xdl/shadowingssl/shadowingcert.pem
sudo chown ctxsrvr:ctxadm /etc/xdl/shadowingssl/shadowingkey.key
<!--NeedCopy-->
Uso
Desde Citrix Director, busque la sesión de destino y haga clic en Remedar en la vista Detalles de la sesión para enviar una solicitud de remedo a Linux VDA.
Una vez inicializada la conexión, aparece una confirmación en el cliente de la sesión ICA (no en el cliente de Citrix Director) con el fin de solicitar permiso al usuario para remedar la sesión.
Si el usuario hace clic en Sí, aparecerá una ventana en la parte de Citrix Director que indicará que se está aplicando el remedo a la sesión ICA.
Para obtener más información de uso, consulte la documentación de Citrix Director.
Limitaciones
- Si sus VDA están unidos a un dominio, están alojados en Microsoft Azure y usan Azure Active Directory (AAD) para la autenticación, la función de remedo de sesiones no funciona.
- El remedo de sesiones está pensado para usarlo únicamente en la intranet. No funciona para redes externas, ni siquiera en conexiones a través de Citrix Gateway. Citrix renuncia a cualquier responsabilidad sobre el remedo de sesiones de Linux VDA en una red externa.
- Con el remedo de sesiones habilitado, un administrador de dominio solo puede ver las sesiones ICA (no tiene permiso de escritura en ellas ni las controla).
- Después de que un administrador haga clic en Remedar en
Citrix Director, aparecerá una confirmación donde se pide permiso al usuario para remedar la sesión. Una sesión solo puede remedarse cuando el usuario de la sesión lo permita. - La confirmación mencionada tiene 20 segundos de tiempo de espera. Por tanto, una solicitud de remedo falla cuando se agota este tiempo.
- Solo un administrador puede remedar sesiones. Por ejemplo, si el administrador B envía una solicitud de remedo para una sesión que remeda el administrador A, la confirmación para obtener el permiso del usuario aparece de nuevo en el dispositivo del usuario. Si el usuario la acepta, la conexión de remedo del administrador A se detiene y se crea otra conexión de remedo para el administrador B. Si un administrador envía otra solicitud de remedo para la misma sesión, también se puede crear otra conexión de remedo.
- Para usar el remedo de sesiones, instale
Citrix Director7.16 o una versión posterior. - Un cliente de
Citrix Directorutiliza un FQDN, en lugar de una dirección IP, para conectarse al servidor de Linux VDA de destino. Por lo tanto, el cliente deCitrix Directordebe poder resolver el FQDN del servidor de Linux VDA.
Solución de problemas
Si se produce un error en el remedo de sesiones, realice la depuración de errores tanto en el cliente de Citrix Director como en Linux VDA.
En el cliente de Citrix Director
Con las herramientas de desarrollador que ofrece el explorador Web, consulte los registros de salida en la ficha Consola. O bien, consulte la respuesta de la API ShadowLinuxSession en la ficha Red. Si aparece la confirmación para obtener el permiso del usuario, pero falla la creación de la conexión, haga ping al FQDN del VDA manualmente para comprobar que Citrix Director puede resolver el FQDN. Si hay problemas con la conexión wss://, compruebe que los certificados están en orden.
En Linux VDA
-
Revise el archivo
/var/log/xdl/vda.logen busca de pistas. -
Modifique el archivo
/var/xdl/sessionshadowing.shy cambie la variable “logFile” para especificar un archivo de registro que pueda rastrearse en busca de pistas durante el seguimiento de la sesión con Director. -
Además, puede verificar manualmente si sus certificados funcionan correctamente con la conexión noVNC:
-
Ejecute ps aux | grep xorg para buscar el número mostrado de Xorg de la sesión actual
<display-num>, por ejemplo,:3. -
Ejecute el siguiente comando para iniciar un servidor x11vnc y esperar a que se produzca una conexión entrante.
runuser -l "ctxsrvr" -s /bin/bash -c "websockify <port> -v --cert /etc/xdl/shadowingssl/shadowingcert.pem --key /etc/xdl/shadowingssl/shadowingkey.key -- x11vnc -viewonly -shared -passwd <passwd> -rfbport <port> -display <display-num> -many -o /var/log/xdl/x11vnc.log" <!--NeedCopy--> -
Intente conectarse mediante noVNC para verificar el modo SSL de la siguiente manera. Introduzca el FQDN y el número de puerto del VDA. En este ejemplo, el número de puerto es 6009.
-
Resuelva los errores que Websockify imprima sobre el VDA o que notifique el explorador del cliente.
Puntos de control clave durante el establecimiento de la conexión:
- Compruebe si hay alguna limitación de firewall que impida que el remedo de sesiones abra el puerto.
- En el caso de utilizar SSL, compruebe que los certificados y los archivos de clave tengan los nombres correctos y que se encuentran en la ruta adecuada.
- Compruebe que haya suficientes puertos entre 6001 y 6099 para las nuevas solicitudes de remedo de sesiones.
- Compruebe que “netstat” esté instalado porque lo requiere
/var/xdl/sessionshadowing.sh. - Ejecute
openssl x509 -in shadowingcert.pem -text -nooutpara verificar que los certificados estén configurados correctamente, prestando especial atención a los campos CN y SAN. -
En RHEL 8, es posible que haya un problema en el que
rebind.sono se pueda encontrar. Para resolver este problema, ejecute el siguiente comando:ln -s /usr/bin/rebind.so /usr/local/bin/rebind.so <!--NeedCopy-->
-