VNC o Virtual Network Computing existe hace mucho tiempo. Uno lo utiliza en situaciones típicas, cuando el servidor remoto tiene algún tipo de aplicación gráfica que sólo se puede utilizar en ésa máquina.
Por ejemplo, supongamos que tenemos un servidor de storage en nuestra LAN. Muchos servidores de storage vienen con una GUI (graphic user interface) para administrar el mismo. A menudo estas herramientas necesitan una conexión directa al storage a través de una red que, a su vez, está dentro de una subred privada (nuestra LAN). De modo que la única forma de acceder a la GUI es haciéndolo desde el servidor de storage (a partir de ahora S1).
Se puede intentar acceder por ssh con la opción -X (para activar el X11 forwarding), pero esto puede requerir mucho ancho de banda y tornar la espera en algo frustrante. VNC es una herramienta mucho más amigable y flexible en éste sentido, y está disponible en la mayoría de los sistemas operativos.
Digamos que, como soporte técnico, queremos acceder desde afuera a S1 y a la GUI del storage, pero S1 está detrás de un firewall, de manera que la conexión directa por VNC es imposible ¿Cómo hacemos un túnel SSH para VNC? De la siguiente manera:
- Arrancamos un servidor VNC en S1, ejecutando algo así:
root@S1:~# vncserver -geometry 1024×768 -depth 24 :99
Lo que las opciones dicen es que el servidor arranque con una definición de 1024×768 y una profundidad de color de 24 bits por pixel. Si estamos usando una conexión muy lenta, sería conveniente reducir la resolución y la profundidad de color (esta última a 8, para enlaces pequeños). El :99 al final especifica en qué puerto va a ser accesible el servidor de VNC. El protocolo VNC arranca en el puerto 5900, asi que lo que en realidad estamos diciendo es que el servicio estará escuchando en el puerto 5999. Cuando arranques una sesión en VNC se te pedirá una password. El user id será el mismo que el que lanzó el servicio (en nuestro caso, el root).
- Ahora nos conectamos por ssh hacia el servidor externo (que llamaremos S2) desde S1, haciendo un forward del puerto 5999 de S2 hacia S1. Lo hacemos desde S1 ejecutando lo que sigue:
root@S1:~# ssh -R 5999:localhost:5999 eltecnico@S2.ejemplo.com
Una vez que corras este comando, necesitarás mantener la conexión abierta (generalmente las conexiones por ssh se cierran por time out). Así que una vez que estés logueado en S2, podrías ejecutar algo así:
eltecnico@S2:~$ while [1]; do date; sleep 300; done
A estas alturas, si estás en S2, ya podrás acceder a S1 por VNC con el siguiente comando:
eltecnico@S2:~$ vncviewer localhost:99
Eso va a hacer un forward del puerto, a través de ssh, hacia S2. Pero si estamos interesados en que el técnico acceda desde otra máquina dentro de la red de S2, a S1, vamos a necesitar otro túnel. Así que pasamos al siguiente punto.
- Desde la máquina del técnico (que llamaremos T1), abrimos un túnel vía ssh para hacer forward del puerto 5999 de T1 hacia el puerto 5999 en S2:
root@T1:~# ssh -L 5999:localhost:5999 eltecnico@S2.ejemplo.com
En este caso utilizamos el flag -L, que en vez de mandar desde 5999 hacia S2, lee desde él (es decir que trae, en vez de mandar). Una vez que hayas establecido una conexión por ssh hacia S2, necesitarás mantenerla activa, así que deberías hacer algo parecido a lo de arriba con el while. Ahora está todo listo para conectarse por VNC a S1 desde T1.
- Desde T1 nos conectamos por VNC a S2, como sigue:
root@T1:~# vncviewer localhost:99
Ahora el técnico tiene una sesión VNC directa hacia S1.
Aunque parezca un poco rebuscada, esta solución es muy utilizada, sobre todo para la asistencia y mantenimiento de muchos storage arrays.
Ahora bien, si el técnico está corriendo un Windows® y no tiene un cliente ssh de línea de comandos, puede ejecutar un putty. Este puede ser configurado para hacer forward de los puertos ssh, en la rama Connection → SSH → Tunnels.
Fuente: IBM(developer works) vía Error: No Coinciden Los Tipos.
Keep Walking 