Sombreado de sesiones
El sombreado de sesiones permite a los administradores de dominio ver las sesiones ICA® de los usuarios en una intranet. Esta función usa noVNC para conectarse a las sesiones ICA.
Nota:
Para usar la función, usa
Citrix Director7.16 o posterior.
Instalación y configuración
Dependencias
Se requieren dos nuevas dependencias, python-websockify y x11vnc, para el sombreado de sesiones. Instala python-websockify y x11vnc manualmente después de instalar el VDA de Linux.
Para Amazon Linux2:
Ejecuta los siguientes comandos para instalar python-websockify y x11vnc (versión 0.9.13 o posterior de x11vnc):
sudo pip3 install websockify
sudo yum install x11vnc
<!--NeedCopy-->
Para RHEL 9.x/8.x y Rocky Linux 9.x/8.x:
Ejecuta los siguientes comandos para instalar python-websockify y x11vnc (versión 0.9.13 o posterior de x11vnc).
sudo pip3 install websockify
sudo yum install x11vnc
<!--NeedCopy-->
Resuelve 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:
Ejecuta los siguientes comandos para instalar python-websockify y x11vnc (versión 0.9.13 o posterior de x11vnc):
sudo pip3 install websockify
sudo apt-get install x11vnc
<!--NeedCopy-->
Para SUSE:
Primero, habilita el módulo “SUSE Linux Enterprise Workstation Extension 15 SP6” usando YaST o el siguiente comando de SUSEConnect:
suseconnect -p sle-we/15.6/x86_64 -r <regcode>
<!--NeedCopy-->
Para obtener más información, consulta la documentación de SUSE: https://documentation.suse.com/en-us/sles/15-SP6/html/SLES-all/article-modules.html.
Luego, ejecuta los siguientes comandos para instalar python-websockify y x11vnc (versión 0.9.13 o posterior de x11vnc):
sudo pip3 install websockify
sudo zypper install x11vnc
<!--NeedCopy-->
Para Debian 12:
Ejecuta los siguientes comandos para instalar python-websockify y x11vnc (versión 0.9.13 o posterior de x11vnc):
apt install python3-websockify
sudo apt-get install x11vnc
<!--NeedCopy-->
Para Debian 11:
- Ejecuta los siguientes comandos para instalar
python-websockifyyx11vnc(versión 0.9.13 o posterior dex11vnc):
sudo pip3 install websockify
sudo apt-get install x11vnc
<!--NeedCopy-->
Puerto
La función de sombreado de sesiones selecciona automáticamente los puertos disponibles entre 6001 y 6099 para establecer conexiones desde el VDA de Linux a Citrix Director. Por lo tanto, el número de sesiones ICA que puedes sombrear simultáneamente está limitado a 99. Asegúrate de que haya suficientes puertos disponibles para satisfacer tus requisitos, especialmente para el sombreado de varias sesiones.
Registro
La siguiente tabla enumera los registros relacionados:
| Registro | Descripción | Valor predeterminado |
|---|---|---|
| EnableSessionShadowing | Habilita o deshabilita la función de sombreado de sesiones | 1 (Habilitado) |
| ShadowingUseSSL | Determina si se debe cifrar la conexión entre el VDA de Linux y Citrix Director | 0 (Deshabilitado) |
Ejecuta el comando ctxreg en el VDA de Linux para cambiar los valores del registro. Por ejemplo, para deshabilitar el sombreado de sesiones, ejecuta 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 el VDA de Linux y Citrix Director usa el protocolo WebSocket. Para el sombreado de sesiones, la elección entre
ws://owss://depende del registro “ShadowingUseSSL” mencionado anteriormente. De forma predeterminada, se eligews://. Sin embargo, por razones de seguridad, te recomendamos que useswss://e instales certificados en cada cliente de Citrix Director y en cada servidor VDA de Linux. Citrix declina cualquier responsabilidad de seguridad por el sombreado de sesiones del VDA de Linux al usarws://. -
Para habilitar SSL, ejecuta el siguiente comando:
- /opt/Citrix/VDA/bin/ctxreg update -k "HKLM\Software\Citrix\VirtualDesktopAgent" -v "ShadowingUseSSL" -d "0x00000001"
<!--NeedCopy-->
Obtener certificados SSL de servidor y raíz
Los certificados deben estar firmados por una autoridad de certificación (CA) de confianza.
Se requiere un certificado de servidor independiente (incluida la clave) para cada servidor Linux VDA en el que quieras configurar SSL. Un certificado de servidor identifica un equipo específico, por lo que debes conocer el nombre de dominio completo (FQDN) de cada servidor. Para mayor comodidad, considera 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 el Linux VDA. Los certificados raíz están disponibles en las mismas CA que emiten los certificados de servidor.
Puedes instalar certificados de servidor y de cliente de las siguientes CA:
- Una CA que se incluye con tu sistema operativo
- Una CA empresarial (una CA que tu organización pone a tu disposición)
- Una CA no incluida con tu sistema operativo
Consulta al equipo de seguridad de tu organización para saber qué métodos requieren para obtener certificados.
Importante:
- El nombre común de un certificado de servidor debe ser el FQDN exacto del Linux VDA o, al menos, el comodín correcto más los caracteres de dominio. Por ejemplo, vda1.basedomain.com o *.basedomain.com.
- Los algoritmos de hash, incluidos SHA1 y MD5, son demasiado débiles para las firmas en certificados digitales para que algunos navegadores los admitan. Por lo tanto, SHA-256 se especifica como el estándar mínimo.
- Chrome ha dejado de aceptar certificados SSL autofirmados, considerándolos inseguros. El error
NET::ERR_CERT_COMMON_NAME_INVALIDse produce porque el certificado generado carece del campo SAN (subjectAltName). Para resolver este problema, proporciona 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 shadowing de sesiones utiliza el mismo almacén de certificados basado en el Registro que IIS, por lo que puedes instalar certificados raíz mediante IIS o el complemento Certificados de Microsoft Management Console (MMC). Cuando recibes un certificado de una CA, puedes reiniciar el Asistente para certificados de servidor web en IIS y el asistente instala el certificado. Alternativamente, puedes ver e importar certificados en el equipo mediante MMC y agregar el certificado como un complemento independiente. Internet Explorer y Google Chrome importan los certificados instalados en tu sistema operativo de forma predeterminada. Para Mozilla Firefox, debes importar tus 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
Nombra los certificados de servidor como “shadowingcert.*” y el archivo de clave como “shadowingkey.*” (* indica el formato, por ejemplo, shadowingcert.pem y shadowingkey.key). Coloca los certificados de servidor y los archivos de clave en la ruta /etc/xdl/shadowingssl y protégelos correctamente con permisos restringidos, permitiendo que solo ctxsrvr tenga acceso de lectura. Un nombre o una ruta incorrectos hacen que el Linux VDA no pueda encontrar un certificado o un archivo de clave específicos y, por lo tanto, provoca 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, busca la sesión de destino y haz clic en Shadow en la vista Detalles de la sesión para enviar una solicitud de shadowing al Linux VDA.
Una vez que se inicializa la conexión, aparece una confirmación en el cliente de la sesión ICA (no en el cliente de Citrix Director) para pedir al usuario permiso para hacer shadowing de la sesión.
Si el usuario hace clic en Sí, aparece una ventana en el lado de Citrix Director, lo que indica que se está haciendo shadowing de la sesión ICA.
Para obtener más información sobre el uso, consulta la documentación de Citrix Director.
Limitaciones
- Si tus VDA están unidos a un dominio y están alojados en Microsoft Azure mediante Azure Active Directory (AAD) para la autenticación, la función de shadowing de sesiones no funciona.
- El shadowing de sesiones está diseñado para usarse solo en una Intranet. No funciona para redes externas, incluso si se conecta a través de Citrix Gateway. Citrix declina toda responsabilidad por el shadowing de sesiones de Linux VDA en una red externa.
- Con el shadowing de sesiones habilitado, un administrador de dominio solo puede ver las sesiones ICA, pero no tiene permiso para escribir o controlarlas.
- Después de que un administrador hace clic en Shadow desde
Citrix Director, aparece una confirmación para pedir al usuario permiso para hacer shadowing de la sesión. Una sesión solo se puede hacer shadowing cuando el usuario de la sesión da el permiso. - La confirmación mencionada anteriormente tiene una limitación de tiempo de espera de 20 segundos. Una solicitud de shadowing falla cuando se agota el tiempo.
- Una sesión solo puede ser objeto de shadowing por un administrador. Por ejemplo, si el administrador B envía una solicitud de shadowing para una sesión de la que el administrador A está haciendo shadowing, la confirmación para obtener el permiso del usuario vuelve a aparecer en el dispositivo del usuario. Si el usuario acepta, la conexión de shadowing para el administrador A se detiene y se establece una nueva conexión de shadowing para el administrador B. Si un administrador envía otra solicitud de shadowing para la misma sesión, también se puede establecer una nueva conexión de shadowing.
- Para usar el shadowing de sesiones, instala
Citrix Director7.16 o posterior. - Un cliente de
Citrix Directorutiliza 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 el shadowing de sesiones falla, depura tanto en el cliente de Citrix Director como en el Linux VDA.
En el cliente de Citrix Director
A través de las herramientas de desarrollador del navegador, comprueba los registros de salida en la ficha Consola. O bien, comprueba la respuesta de la API ShadowLinuxSession en la ficha Red. Si aparece la confirmación para obtener el permiso del usuario, pero la conexión falla, haz ping manualmente al FQDN del VDA para verificar que Citrix Director pueda resolver el FQDN. Si hay un problema con la conexión wss://, comprueba tus certificados.
En el Linux VDA
-
Comprueba el archivo
/var/log/xdl/vda.logen busca de pistas. -
Edita el archivo
/var/xdl/sessionshadowing.shy cambia la variable ‘logFile’ para especificar un archivo de registro que se pueda seguir en busca de pistas durante el shadowing de sesiones desde el director. -
Además, puedes verificar manualmente si tus certificados funcionan correctamente con la conexión noVNC:
-
Ejecuta ps aux | grep xorg para encontrar el número de pantalla Xorg de la sesión actual $display-num, por ejemplo, :3.
-
Ejecuta el siguiente comando para iniciar un servidor x11vnc y esperar una conexión entrante.
Nota:
Antes de ejecutar el siguiente comando, establece 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--> -
Intenta conectarte usando noVNC para verificar el modo SSL de la siguiente manera. Introduce el FQDN de tu VDA y el número de puerto. En este ejemplo, el número de puerto es 6009.
-
Resuelve cualquier error impreso por Websockify en el VDA o informado por el navegador en el cliente.
Puntos de control clave durante el establecimiento de la conexión:
- Comprueba si hay alguna limitación de firewall que impida que el shadowing de sesiones abra el puerto.
- Verifica que hayas nombrado los certificados y los archivos de clave correctamente y que los hayas colocado en la ruta correcta si se trata del escenario SSL.
- Verifica que queden suficientes puertos entre 6001 y 6099 para nuevas solicitudes de shadowing.
- Ejecuta
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, puede que haya un problema en el que no se encuentre
rebind.so. Para resolver este problema, ejecuta el siguiente comando:``` ln -s /usr/bin/rebind.so /usr/local/bin/rebind.so <!--NeedCopy--> ```