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: No
Para usar la función, utilice
Citrix Director7.16 o una versión posterior.
Instalación y configuración
Dependencias
Se requieren dos nuevas dependencias, python-websockify y x11vnc, para el remedo de sesiones. Instale python-websockify y x11vnc manualmente después de instalar Linux VDA.
Para RHEL 7.x y Amazon Linux 2:
Ejecute los siguientes comandos para instalar python-websockify y x11vnc (x11vnc versión 0.9.13 o posterior):
sudo pip3 install websockify
sudo yum install x11vnc
<!--NeedCopy-->
(Para RHEL 7.x) Resuelva python-websockify y x11vnc habilitando los paquetes adicionales para Enterprise Linux (EPEL) y los repositorios de 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 el siguiente comando para habilitar el repositorio
RPMsopcional para 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 los siguientes comandos para instalar python-websockify y x11vnc (x11vnc versión 0.9.13 o posterior).
sudo pip3 install websockify
sudo yum install x11vnc
<!--NeedCopy-->
Resuelva x11vnc habilitando 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 los siguientes comandos para instalar python-websockify y x11vnc (x11vnc versión 0.9.13 o posterior):
sudo pip3 install websockify
sudo apt-get install x11vnc
<!--NeedCopy-->
Para SUSE:
Ejecute los siguientes comandos para instalar python-websockify y x11vnc (x11vnc versión 0.9.13 o posterior):
sudo pip3 install websockify
sudo zypper install x11vnc
<!--NeedCopy-->
Para Debian:
Ejecute los siguientes comandos para instalar python-websockify y x11vnc (x11vnc versión 0.9.13 o 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 entre 6001-6099 para crear conexiones desde Linux VDA a 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, la elección de ws:// o wss:// depende del registro “ShadowingUseSSL” mencionado anteriormente. De forma predeterminada, se elige ws://. Sin embargo, por razones de seguridad, se recomienda usar wss:// e instalar certificados en cada cliente 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 siguiente comando:
/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.basedomain.com o\ *.basedomain.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
Asigne a los certificados del servidor el nombre “shadowingcert.*” y el archivo de claves “shadowingkey.*” (\ * indica el formato, por ejemplo, shadowingcert.pem y 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 sesión ICA (no en el cliente de Citrix Director) para solicitar al usuario permiso 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 y están alojados en Microsoft Azure con 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 acepta, la conexión de remedo para el administrador A se detiene y se crea una nueva 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 una nueva conexión de remedo.
- Para usar el remedo de sesiones, instale
Citrix Director7.16 o una versión posterior. - Un cliente de
Citrix Directorusa un FQDN en lugar de una dirección IP para conectarse al servidor Linux VDA de destino. Por lo tanto, el cliente deCitrix Directordebe poder resolver el FQDN del servidor Linux VDA.
Solución de problemas
Si se produce un error en el remedo de la sesión, realice la depuración tanto en el cliente 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 de usuario, pero se produce un error al establecer la conexión, haga ping manualmente al FQDN del VDA para comprobar que Citrix Director puede resolver el FQDN. Si hay algún problema con la conexión wss://, compruebe sus certificados.
En Linux VDA
-
Consulte el archivo
/var/log/xdl/vda.logpara obtener pistas. -
Modifique el archivo
/var/xdl/sessionshadowing.shy cambie la variable “logFile” para especificar un archivo de registro al que se pueda seguir en busca de pistas durante el remedo de sesiones desde 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 de pantalla 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.
Nota: No
Antes de ejecutar el siguiente comando, defina las variables $passwd, $port, $display-num.
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 en 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.
- Verifique que “netstat” esté instalado porque
/var/xdl/sessionshadowing.shlo requiere. - 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 no se pueda encontrar
rebind.so. Para resolver este problema, ejecute el siguiente comando:ln -s /usr/bin/rebind.so /usr/local/bin/rebind.so <!--NeedCopy-->
-