LinuxParty

Virtual Network Computing (VNC) es una popular herramienta para proporcionar acceso remoto a los ordenadores. La configuración habitual VNC está optimizado para estaciones de trabajo de un usuario único, y el registro en el puerto VNC para acceder directamente al escritorio del usuario. Esta configuración es erronea para las computadoras multiusuario, sin embargo. Afortunadamente, hay una alternativa. Al vincular VNC con una estación de trabajo Linux con X Display Manager Control Protocol (XDMCP), el acceso al puerto VNC permite a los usuarios registrarse con sus nombres de usuario y contraseñas, lo que permite una única instancia en el servidor VNC para manejar múltiples cuentas de usuario.

VNC y arquitecturas de servidor X.

Linux utiliza el sistema X Window System (X para abreviar) como su interfaz gráfica de usuario (GUI). X es un GUI inusual por varias razones, una es que está inherentemente habilitada a la red. Un servidor de X es, literalmente, un programa de servidor de red. Los programas de servidor de red permiten a los programas clientes acceso a los recursos locales, y este es el caso de un servidor X, también. Lo extraño es que los "recursos locales" en el caso de un servidor de X son la pantalla, el teclado y el ratón, que el usuario utiliza. En la configuración más común, los programas cliente de X se ejecutan en el mismo equipo que el servidor. Por lo tanto, LibreOffice, el GNU Image Manipulation Program (GIMP), u otros programas clientes de X que utilizan protocolos de red de X aceptan la entrada del usuario y la salida de la pantalla para los usuarios en el mismo equipo.

Cuando X se utiliza sobre una red, sin embargo, el usuario se sienta en el ordenador con servidor X, y los clientes X son los programas que el usuario ejecuta en otro equipo. Esta configuración requiere un segundo protocolo de red para iniciar la conexión. Este segundo protocolo puede ser telnet, Secure Shell (SSH), o el X Display Manager Control Protocol (XDMCP). El servidor de este protocolo de inicio de sesión se ejecuta en el equipo cliente X, y el cliente de acceso remoto se ejecuta en el equipo servidor X. El servidor de acceso remoto lanza clientes X que a su vez están en contacto con el servidor X.

Figura 1 muestra esta relación. Las Flechas punteadas indican el inicio de sesión. (En el caso de XDMCP, el cliente XDMCP está integrado en el programa del servidor X).

Figura 1. X con acceso remoto requiere un cliente y un servidor en ambos equipos. El Diagrama muestra la relación entre los clientes X y un servidor de X

Este tipo de configuración funciona bien en muchas redes locales, pero tiene inconvenientes. Por ejemplo, esta configuración requiere dos direcciones de protocolo de red de iniciación, que podría no ser posible a través de algunos cortafuegos o traducción de direcciones de red (NAT) "routers". (SSH puede tunelizar sesiones X, obviando esta necesidad.) Por otra parte, aunque los servidores X están disponibles para la mayoría de las plataformas, no es habitual instalarlos en equipos con Windows. Por estas y otras razones, muchos sitios prefieren usar otro protocolo, com el "Remote Frame Buffer" (RFB), que se implementa en el Virtual Network Computing (VNC)

VNC es una herramienta multiplataforma que puede proporcionar acceso remoto para Linux, UNIX, Mac OS X, Windows y otros sistemas con cualquier tipo de cliente. Con VNC, el usuario se sienta frente a la computadora cliente y tiene acceso a una computadora en un servidor remoto. En Linux, el servidor VNC o bien refleja el contenido de la pantalla del servidor X local al equipo remoto o incluye su propio servidor X que puede funcionar de forma independiente de la que gestiona la pantalla local. El resultado se parece a la Figura 2. De nuevo, la flecha de trazos indica la iniciación de sesiones. Esta configuración elimina la necesidad de la Conexión de Red Inversa "reverse network connection", y porque los clientes y servidores VNC existen para que muchos sistemas operativos, los usuarios pueden emplear un programa de cliente único para acceder a cualquier servidor.

Figura 2. Un servidor VNC incluye un servidor X que puede comunicarse con los programas locales de clientes de X. El Diagrama  muestra cómo los servidores VNC envían el contenido del servidor X a los clientes

La desventaja es que la autenticación VNC RFB está basada en contraseñas, sin nombres de usuarios. Por lo tanto, cada usuario debe iniciar una sesión de VNC en un servidor independiente y conectarse a la instancia VNC especificando el número de puerto correcto. Este requisito puede ser tolerable en un sistema de un solo usuario, pero es extremadamente raro en un equipo multiusuario.

Para evitar este problema, puede vincular los dos enfoques. Puede volver a configurar el servidor XDMCP local para ayudar a que el servidor X VNC integrado proporcione la autenticación multiusuario que le  falta (la configuración resultante se asemeja a la figura 3). La flecha punteada indica el inicio de sesión. Ahora, cuando los usuarios remotos de VNC contacten con el equipo servidor VNC, van a ser capaces de introducir sus nombres de usuario y contraseñas para acceder a sus propias sesiones únicas VNC, por lo que el equipo puede manejar tantos usuarios como quieras/pueda.

Figura 3. Adición de XDMCP a una configuración de VNC le proporciona una flexibilidad adicional. El diagrama muestra cómo la adición de XDMCP a una configuración de VNC proporciona una flexibilidad adicional

Configurar el servidor VNC

Existen varias maneras de iniciar VNC, incluyendo el uso de scripts, un lanzador VNC para el escritorio utilizando las herramientas de escritorio, y el uso de xinetd para escuchar las conexiones VNC. Este último enfoque es el que se describe aquí, ya que le permite iniciar VNC para que pueda utilizar el servidor XDMCP. Antes de detallar cómo configurar VNC para poner en marcha a través de xinetd , debe seleccionar un servidor VNC.

Selección de un servidor VNC

Hayt varios programas de servidor VNC disponibles.  Algunas de las opciones más populares incluyen TightVNC, TigerVNC y RealVNC. Este artículo utiliza TightVNC como ejemplo. Desafortunadamente, los detalles de configuración varían de un servidor a otro, así como de una distribución Linux a otra, por lo que es posible que tenga que ajustar las instrucciones proporcionadas aquí para su software.

Instalación de xinetd

Muchas distribuciones instalan el "xinetd super servidor" por defecto, pero algunos no lo hacen. Debido a que el método descrito aquí utiliza xinetd , debe instalar xinetd si no está ya instalado. En la mayoría de las distribuciones, puede instalar xinetd usando el sistema de paquetes, como "apt-get install xinetd" en distribuciones basadas en Debian, "zypper install xinetd" en openSUSE o "yum -y install xinetd" en Fedora/CentOS/RedHat

También podría tener que configurar xinetd para ejecutarlo. Por lo general, se puede ejecutar una sola vez mediante el uso de su script SistemV (SysV) de arranque:

 /etc/init.d/xinetd start

La configuración de xinetd para ejecutarse automáticamente cuando se inicia el equipo requiere el conocimiento de los métodos de script de inicio para su distribución. Normalmente, se utiliza una utilidad como chkconfig (utilizado en Fedora, openSUSE y distribuciones relacionadas), update-rc.d (utilizado en las distribuciones Debian y otras relacionadas), o rc-update (utilizado en Gentoo) para hacer el trabajo:

# chkconfig xinetd on
# update-rc.d xinetd enable
# rc-update add xinetd default

Escriba sólo una de esas órdenes, o localice a un equivalente para su distribución.

Tenga en cuenta que xinetd puede negarse a arrancar si no cuenta con ningún servicio configurado. Por lo tanto, es posible que desee posponer su lanzamiento hasta que haya configurado xinetd para administrar el servidor VNC.

Configuración de xinetd

Los servidores que deben ser manejados por xinetd colocar archivos de configuración en el directorio  /etc/xinetd.d. Por lo tanto, para configurar xinetd para manejar VNC, es necesario crear o editar un archivo con un nombre como /etc/xinetd.d/vnc. (En algunas distribuciones, como openSUSE, el paquete del servidor VNC instala un archivo.) El Listado 1 proporciona un ejemplo.

Listado 1. Un ejemplo de configuración para xinetd VNC

service vnc
{
   disable     = no
   socket_type = stream
   protocol    = tcp
   wait        = no
   user        = nobody
   server      = /usr/bin/Xvnc
   server_args = -inetd -once -query localhost -geometry 1024x768 -depth 16
   type        = UNLISTED
   port        = 5900
}

Esta entrada permite seleccionar varias opciones de xinetd, la mayoría de las cuales son únicas. Es posible que desee ajustarlas:

• service . Puede ejecutar VNC en varios puertos con opciones diferentes en cada uno, pero si lo hace, debe dar un nombre de servicio diferente para cada puerto en la primera línea en el Listado 1.

• server . Usted debe cambiar esta entrada para que señale a binariosu servidor VNC, que generalmente se llama Xvnc.
• server_args . Seguramente quiere cambiar alguna de estas opciones, como se describe en breve.

• port . VNC utiliza los puertos numerados desde 5900 en adelante. Puede ejecutar el servidor con diferentes opciones en diferentes puertos. Si lo hace, debe asignarle a cada instancia su propio número de puerto.

La parte más complicada de la configuración xinetd es establecer los argumentos de servidor. Puede utilizar los argumentos del Listado 1 como modelo, pero es posible que desee cambiar algunos de ellos:

• -query localhost.. Esta opción indica al servidor VNC X comprobar con el sistema host local la autenticación XDMCP. Puede cambiarlo si desea utilizar un ordenador como un relé para acceder a los programas sobre otro.

• -geometry 1024x768. Establece la resolución virtual de la sesión de VNC con esta opción. Tenga en cuenta que esta resolución no tiene por qué parecerse a la resolución del servidor X normal que se ejecuta en el equipo servidor. Es posible que desee crear entradas múltiples que se ejecutan en diferentes resoluciones para que los usuarios puedan iniciar sesión en el servidor de VNC usando cualquier resolución es conveniente para sus propios sistemas locales.

• -depth 16. Esta opción permite establecer la profundidad de color. Los valores más bajos producen actualizaciones más rápidas de la pantalla, pero de alto colorido entornos de escritorio pueden sufrir de artefactos de color. Los valores válidos varian del 2 a 32. (recomendado entre 8 y 16)

Muchas otras opciones están disponibles, y algunos varían de un servidor VNC a otro. Consulte la documentación de su servidor VNC para obtener más información.

Configuración del servidor XDMCP

La mayoría de distribuciones Linux configuran sus servidores XDMCP para manejar la pantalla local y nada más. Para permitir el acceso remoto, debe editar a configurar del servidor XDMCP para aceptar las solicitudes de acceso desde el servidor VNC que se ejecuta en el mismo equipo. Los detalles varían de servidor XDMCP a otro. El uso más común en Linux son GNOME Display Manager (GDM), el gestor de pantallas de luz (LightDM), y el gestor de pantallas de KDE (KDM). Otros servidores XDMCP, como XDM, requieren ajustes diferentes a los descritos aquí. En cualquier caso, después de volver a configurar el servidor XDMCP, tendrás que reiniciarlo.

Editar el archivo de configuración XDMCP

Si no está seguro de qué servidor XDMCP usa su sistema, usted puede identificar mediante la búsqueda de una lista de procesos de la cadena de dm , como en:

$ ps ax | grep dm
  929 ?        Ss     0:00 /usr/bin/kdm
  962 tty7     Ss+    0:19 /usr/bin/Xorg -br :0 vt7 -nolisten tcp -auth \
                           /var/lib/xdm/authdir/authfiles/A:0-pp4shb
30157 pts/3    S+     0:00 grep --color=auto dm

La primera línea de esta salida revela que KDM se está ejecutando, por lo que tendría que editar el archivo de configuración de este servidor VNC para permitir utilizar XDMCP. Muchos XDMCP tienen sus archivos de configuración que siguen un formato similar. Se incluyen secciones que identifican los nombres de la sección en corchetes, por ejemplo [xdmcp] . Las líneas siguientes para el nombre de sección ajusta con un signo igual, como en enable=true. Tabla 1 se resumen los nombres de los archivos de configuración,

Tabla 1. Opciones para habilitar el soporte para XDMCP VNC para varios servidores XDMCP XMDCP servidor Configuración del nombre de archivo Sección nombre Opción

XMDCP server	Configuration file name	Section name	Option
GDM	/etc/X11/gdm/custom.conf	[xdmcp]	enable=true
KDM	/usr/share/kde4/config/kdm/kdmrc	[Xdmcp]	Enable=true
LightDM	/etc/lightdm/lightdm.conf	[XDMCPServer]	enabled=true

Usted puede encontrar la sección XDMCP en el archivo de configuración, o puede estar ausente por completo. Si está presente, de forma explícita puede desactivar el soporte XMDCP, Si la contienen comentada, descomentala, y si no asigne un valor "true". Cualquiera que sea el estado original del archivo, usted quiere asegurarse de que la sección XDMCP está presente y que el soporte está habilitado. Como ejemplo, considerar una configuración de KDM para habilitar XDMCP:

[Xdmcp]
Enable=true

Algunas distribuciones puede que tengan medidas de seguridad adicionales que pueda necesitar para aflojar. Uno de ellos es un servidor de seguridad.

Scripts de servidor de seguridad tienden a ser específicos de distribución, así que consulte la documentación de su sistema para aprender a modificar su firewall. Debe asegurarse de que tiene acceso a localhost por el puerto 177 y que sus clientes VNC tener acceso al puerto 5900 (o lo que otros puertos utilicen para VNC).

OpenSUSE utiliza un archivo de configuración adicional que controla algunos tipos de acceso, incluyendo el acceso XDMCP: / /etc/sysconfig/displaymanager. Abra el archivo en un editor de texto y busque la siguiente línea:

DISPLAYMANAGER_REMOTE_ACCESS="no"

Cambie esta opción para "yes" . Si se deja en "no" , el indicador de entrada de su servidor XDMCP no es visible cuando se conecta al servidor de VNC. Este cambio no es necesario en la mayoría de las distribuciones: openSUSE sólo enlaza a este archivo.

Reinicio del servidor XDMCP

Con su servidor XDMCP configurado para aceptar conexiones remotas, debe reiniciar. En distribuciones que lanzan X a través de un archivo de SysV init, como Debian y Gentoo, puede pasar la opción restart:

# /etc/init.d/gdm restart

Si su sistema utiliza el número de nivel de ejecución para iniciar X, como Fedora y openSUSE, usted tendrá que cambiar a un nivel de ejecución en modo texto (normalmente 3), y luego de vuelta al nivel de ejecución GUI (normalmente 5):

# telinit 3
# telinit 5

Tenga en cuenta que ambos enfoques apagan las X, así que asegúrese de que ha guardado todo su trabajo abierta en su sesión X antes de proceder.

Probar y depurar la configuración

En este punto, usted debería ser capaz de iniciar sesión desde un equipo remoto mediante un cliente VNC. Por ejemplo, la mayoría de las distribuciones de Linux proporcionan un comando llamado vncviewer , se puede escribir:

vncviewer remotename

. . . para iniciar sesión en remotename a través de VNC. El resultado, cuando VNC está configurado y funciona correctamente, se asemeja a la figura 4 . Si ha configurado múltiples sesiones VNC en puertos diferentes, se puede especificar el número de sesión VNC haciéndolo pasar como parte del nombre de host, como en:

vncviewer remotename:3

. . . conectarse a la sesión 3 (en el puerto 5903).

Figura 4. Cuando se configura para trabajar con XDMCP, VNC proporciona una tradicional Linux indicador de entrada Captura de pantalla de un tradicional sistema de acceso en Linux VNC

Si usted no ve una pantalla de acceso XDMCP al realizar esta prueba, deberá revisar las siguientes cosas:

Si vncviewer informa de que la conexión se ha negado, lo más probable es que el super servidor no tenga configurado correctamente en el equipo el servidor VNC. Revise su configuración xinetd  y reinicie el servidor X. También es posible que un firewall está bloqueando el acceso al equipo servidor VNC.

Si el cliente VNC se inicia y se conecta con el servidor, pero todo lo que ves es una pantalla gris con un cursor que puede moverse, el problema es probablemente con la configuración del servidor XDMCP. Revise los ajustes descritos anteriormente, y volver a iniciar el servidor XDMCP.

Como una técnica de solución de problemas generales, revisar sus archivos de registro. Puede que tenga que buscar en todos los archivos de registro en /var /log para las referencias a xinetd , el servidor XDMCP, y su servidor VNC.

VNC preocupaciones de seguridad

RFB no es un protocolo seguro, la mayoría de los clientes VNC y servidores no cifran sus datos. (VNC no cifra sus propias contraseñas, pero el método aquí descrito no utiliza estas contraseñas.) Tenga cuidado acerca de dónde y cómo se implementa VNC. Si desea utilizar VNC a través de una red no segura, tienes tres opciones:

Utilice una red privada virtual (VPN). Túnel del protocolo SSH. Utilice una variante de VNC que admite el cifrado, como TigerVNC, que permite el transporte de cifrado de Seguridad de nivel.

Activación de inicios de sesión VNC como se describe en este artículo se abre por lo menos dos puertos (el puerto VNC y el puerto XDMCP) para el mundo exterior. Es posible que desee restringir los dos puertos con las reglas de firewall para minimizar el riesgo de abuso. Tenga en cuenta que el puerto XDMCP (puerto UDP 177) sólo necesita estar abierto para localhost, por lo que su regla de firewall puede ser bastante restrictiva.

Conclusión

En general, la vinculación VNC y XDMCP es una técnica útil para permitir logins remotos GUI para multiusuario Linux. Este método tiene ventajas sobre el uso XDMCP directamente en entornos multi-plataforma o si se trabaja alrededor de firewall o problemas de NAT podría ser un problema. Es beneficioso sobre los enfoques más comunes directos VNC en los equipos multiusuario. Si utiliza este método, asegúrese de considerar los problemas de seguridad. Esté preparado para configurar las reglas de firewall para restringir el acceso al exterior no deseado, y el uso de cifrado si las transferencias atravesar redes no confiables.