Soluciones de acceso remoto desde un Nexus 7 para Windows y GNU/Linux

Estos días he estado preparando la red de casa para poder acceder remotamente a los ordenadores desde cualquier sitio usando mi tableta Nexus 7. Tras probar unas cuantas cosas, al final he conseguido montar varias soluciones para poder administrar mis máquinas mediante terminales y escritorios remotos y encender mis ordenadores.

Lo dejo todo anotado por aquí por si a alguien le sirve :-). Empezaré contando las opciones gratuitas que hay (aunque requieren trastear), y acabaré hablando de varias opciones que no requieren tanto trabajo (aunque tampoco me resuelven el 100% de los problemas).

OpenVPN: conexión segura a la red de casa

Lo primero que se le pasaría a cualquiera sería abrir puertos a mansalva en su router y entrar a fuego con cualquier programa de acceso remoto tras asegurarse de que el router tenga un nombre fijo asociado a la IP que tengamos en cada momento, usando un servicio como no-ip.com.

Esto, sin embargo, plantea varios problemas:

• Es un incordio tener que mantener las asociaciones entre los puertos del router y los puertos concretos de cada máquina, y muy propenso a errores.
• Cada puerto abierto es una vulnerabilidad potencial, y si alguien se cuela por ella se puede colar en todas tus máquinas a la vez. Es necesario que haya el mínimo número de puertos abiertos al exterior, y que lo que esté detrás del puerto esté *muy* bien protegido.

En vez de eso, una opción mucho mejor es crear un túnel cifrado a través de Internet a la red a controlar, de forma que parezca que estamos en esa misma red y podamos acceder a todos los ordenadores como si nada. Para ello se ha de instalar un servidor VPN (Virtual Private Network) en la red a controlar, en un ordenador que esté siempre encendido y que sea visible desde el exterior (con el nombre fijo de no-ip.com, por ejemplo). El candidato ideal para todas estas cosas es el router, precisamente :-D. La mayoría de los routers domésticos no incorporan esta funcionalidad, pero si tienes un router compatible con algunas de las variantes más recientes de Tomato (como la de Toastman, basada en TomatoUSB) puede instalársela y aprovechar el servidor OpenVPN que tienen incorporado. Mi (algo vetusto) WRT54GL es uno de ellos: si queréis compraros uno, quizás os venga mejor el ASUS RT-N16 e EasyTomato.

La mayor complejidad a la hora de montar una VPN con OpenVPN es configurar la autenticación de los usuarios. Aunque se admite la posibilidad de usar un simple par usuario/contraseña (una «static key«), esto no funciona bien cuando hay que darle permiso a varios ordenadores. Es mucho mejor utilizar certificados X.509 (como los de SSL) para autenticar tanto al servidor como al cliente, pero gestionar los certificados (lo que se llama la «Public Key Infrastructure» o PKI) es bastante complejo si no se tienen conocimientos previos. Para esto existen programas que simplifican todo el proceso. Probé XCA (no me convenció la interfaz) y TinyCA (no funcionaba en Arch Linux), así que al final utilicé EasyRSA, un conjunto de guiones Bash del proyecto OpenSSL en el que se basa el cifrado de OpenVPN. Funcionan muy bien, aunque tuve que tirar todas las claves varias veces hasta que quedaron como me gustaron :-). El proceso es básicamente el siguiente:

• Editar el fichero «vars» de EasyRSA apropiadamente.
• Generar el fichero de parámetros de Diffie-Helman, que se usarán para generar todas las claves privadas y públicas.
• Generar el par de claves de nuestra Certification Authority.
• Generar el par de claves de nuestro servidor OpenVPN (el Common Name debería coincidir con el nombre público del servidor).
• Generar un par de claves para cada cliente OpenVPN (hay que usar –interact para poder poner el Common Name de cada cliente).

El siguiente paso es configurar el cliente. En el caso de Android, OpenVPN tiene un cliente oficial, aunque el que estoy usando (y con el que me va bien, así que para qué cambiar :-D) es el de Arne Schwabe. Por cierto, este último ya no requiere root desde Android 4.0, creo, ya que utiliza un API estándar de Android. En general, con seguir los pasos que da la aplicación irá bien, aunque tendréis que toquetear un poco hasta que termine de funcionar. Un pequeño problema que yo tuve fue en el detalle del enrutado. Mi router neutro está detrás de un módem+router del que es destino por omisión para todas las conexiones entrantes (DMZ), y esto en general funciona bien para las conexiones TCP. Sin embargo, no es así para las conexiones UDP, que son las que usa OpenVPN por omisión: tuve que poner explícitamente un mapeo de puertos hasta que funcionó bien.

Con esta conexión pude sacar otro beneficio: poder entrar en la interfaz web de mi router y usar sus funciones de Wake-on-LAN (también cortesía de Tomato) para encender remotamente mis ordenadores. La clave para poder hacer esto es que estén conectados por cable al router, y que tengan debidamente configurada la BIOS para admitir esta forma de encendido. Esto varía de ordenador a ordenador, así que no puedo dar mucha más información :-/. Si todo va bien, con un clic enciendes el ordenador, te esperas un minuto o dos e inicias sesión por alguno de los métodos inferiores.

OpenSSH y JuiceSSH: terminales remotas

Con la VPN permitiendo a nuestra tableta ser parte de la red de casa, lo siguiente es ver cómo abrir una terminal (texto puro y duro) a una de las máquinas. Esto es muy eficiente y requiere muy poco ancho de banda, y es ideal para administrar sistemas remotamente. El protocolo ideal para estas cosas es SSH (Secure SHell), y para ello necesitaremos instalar un servidor SSH en la máquina a la que nos vayamos a conectar (el de OpenSSH es estupendo), y un cliente SSH en la tableta.

En Android hay unos cuantos clientes SSH. Originalmente usaba ConnectBot, pero hace unos meses me cambié a JuiceSSH, que en mi opinión tiene una interfaz muy superior. Hay una versión de pago, pero con la versión gratuita vais sobrados. Por cierto, no olvidéis usar Byobu para multiplexado de sesiones (o por lo menos tmux) si os conectáis a una máquina con Ubuntu.

Otro uso para SSH es como túnel para protocolos inseguros, como VNC (cuando se usa sin cifrado), que veremos a continuación.

TightVNC, TigerVNC, x11vnc y bVNC: pantallas compartidas remotas

El siguiente paso era conseguir acceso a un entorno gráfico. Básicamente, hay dos protocolos estándar para esto: RDP (Remote Desktop Protocol, el «escritorio remoto» de Windows) y VNC (Virtual Network Computing). RDP viene de serie en muchas versiones de Windows (en Linux no es tan popular: existe xrdp pero es peliagudo de configurar), permite transmitir el audio del ordenador remoto y es muy eficiente y flexible, pero tiene la pega de que al iniciar sesión remotamente se cierra la sesión local. Si tienes que darle soporte a un familiar, no le va a hacer gracia que su música o su partida de GranjaPueblo se interrumpa mientras le arreglas el cacharro :-D.

Por eso, prefiero VNC, que permite «compartir» la pantalla, con lo que la otra persona podrá ir viendo todo lo que vas haciendo. Al igual que con SSH, necesitaremos instalar un servidor en el ordenador a administrar y un cliente en la tableta.

El servidor a usar depende mucho del sistema operativo. Para Windows, el mejor (de los gratuitos) que hay ahora mismo es TightVNC 2.6. Se puede instalar como un servicio, de forma que esté disponible incluso antes de iniciar sesión, y es muy fácil de montar. De hecho, veremos que es el que te instala JumpDesktop cuando le pides acceso por VNC en Windows. TightVNC hereda de las versiones de código abierto de RealVNC, que se publicaron bajo la GNU GPL.

Para Linux, podríamos también usar TightVNC, pero sería una versión demasiado antigua (la 1.3). En este caso es mucho mejor trabajar con TigerVNC 1.2, un fork de TightVNC con mejor soporte para Linux. TigerVNC permite abrir un servidor X virtual al que conectarse remotamente por VNC como si fuera una pantalla normal y corriente: sólo tenemos que establecer la contraseña con «vncpasswd», abrir el servidor con «vncserver» desde una sesión SSH y listo.Si lo que queremos es conectarnos a una pantalla «de verdad» en una sesión ya abierta, tendremos que usar x11vnc. Es un poco más complicado de usar, pero no mucho más. Tendremos que ejecutar una orden como ésta desde una sesión SSH, y luego ya podremos entrar con el cliente oportuno:

x11vnc -rfbauth ~/.vnc/passwd &

Un aspecto molesto de Linux que no he podido solventar aún es cómo entrar por VNC sin haber iniciado sesión, como se puede hacer en Windows. La solución que he adoptado por lo pronto es entrar automáticamente en mi cuenta de usuario e inmediatamente bloquear la pantalla por contraseña de forma automática, usando las opciones de KDE 4. Para no tener que abrir el servidor VNC yo, he añadido esta línea al final de ~/.xprofile:

x11vnc -rfbauth ~/.vnc/passwd -forever &

La opción «-forever» evitará que se cierre el servidor VNC cuando cierre mi sesión en algún momento. De esta forma, puedo encender remotamente mi ordenador y luego entrar a una sesión remota sin más.

Con los servidores resueltos, el siguiente paso es seleccionar un buen cliente VNC para Android. Primero probé el que tiene más solera de los gratuitos, androidVNC, pero no me gustó demasiado la interfaz: era bastante primitiva, la verdad. Tras mirar un poco, en un hilo de comentarios vi al autor de bVNC promocionar su aplicación, y tras probarla creo que es muchísimo mejor, y que se merece más instalaciones. El manejo es más cómodo, y permite compartir fácilmente el portapapeles, cambiar de modo de color sobre la marcha y desplazarse por la pantalla, además de implementar más opciones de seguridad, como SSL anónimo o túneles SSH. Lo único que me costó trabajo fue averiguar cómo hacer clic derecho, pero mirando la ayuda se resolvió todo.

JumpDesktop: pantallas compartidas y escritorios remotos seguros sin VPN

De todos modos, la verdad es que estaba algo molesto con la dificultad en bVNC a la hora de hacer clic sobre ciertos elementos pequeños, la imposibilidad de dejar «flotar» el cursor sin hacer clic y otros detalles varios de la interfaz. Son cosas menores, pero me puse a buscar clientes VNC mejores. Y tras hacerlo, di con JumpDesktop: un cliente RDP y VNC con mejor acabado aún, aunque de pago (unos 7,5€  a fecha de hoy). Un detalle aparentemente tonto es que ahora el cursor se puede manejar con una «lupa» que tiene debajo, permitiendo dejar flotando el ratón sobre un punto dado y apuntar con mucha más exactitud y comodidad. El botón derecho es mucho más sencillo de introducir, además :-D. JumpDesktop parece estar en desarrollo activo: hace poco han sacado una versión con soporte para los gestos multitouch de Windows 8.

El precio sería un tanto alto si no fuera porque tiene otra ventaja: puede operar a través de NAT y cortafuegos sin necesidad de montar una VPN. Yo ya tenía montada mi VPN, pero la verdad es que me intrigó bastante de cara a otras posibilidades. Tienes que instalar un software específico en cada máquina con Windows o Mac (lástima, nada para Linux) e introducir las credenciales de una cuenta de Google en cada una. Esas credenciales no se mandan a JumpDesktop, sino que se usan para iniciar sesión en Google Talk y utilizar el protocolo XMPP en que se basa Talk para establecer la conexión VNC o RDP oportuna. Lo probé con varias máquinas y funcionó estupendamente, así que no me arrepiento demasiado del gasto :-D. Las contraseñas se guardan localmente en cada dispositivo y no se mandan a JumpDesktop, así que si hay que fiarse de alguien es de Google.

Pero, por si acaso, me dió por mirar la competencia, y encontré otras dos opciones parecidas que también se saltaban NAT y cortafuegos: Splashtop y TeamViewer. Las dos son gratuitas para uso personal, y luego ofrecen productos de pago para uso profesional. Por mi parte bien: probé Splashtop y su Streamer no me funcionó bajo Arch Linux, así que lo descarté inmediatamente.

TeamViewer sí funcionó bastante bien en Linux. El problema es la aplicación para Android, que no es tan buena como la de JumpDesktop. Mover el ratón exige arrastrarlo por toda la pantalla de forma bastante irritante, y no se pueden usar las flechas de mi teclado Bluetooth ni las combinaciones de tipo Ctrl+X o Alt+Y. Además, la aplicación y el servicio eran propensos a cuelgues y corrupción de su base de datos interna si cerrabas e iniciabas sesión con cierta frecuencia (normal durante mis pruebas), y no respetaban bien la multitarea de Android. En general, JumpDesktop me resultó más agradable de usar, y al estar basado en estándares, la falta de un cliente Linux no es importante: uso OpenVPN y luego abro el cliente VNC o RDP que prefiera :-D. De todos modos, TeamViewer tiene una importante ventaja si tenéis que dar soporte a otras personas: no requiere introducir nuestras credenciales en las máquinas que vayamos a controlar. Cada máquina tiene asignado un número, y cada vez que lanzamos TeamViewer se nos genera una contraseña de un uso. El dueño de la máquina a controlar nos puede dar ambos datos por teléfono, nos conectamos, resolvemos el problema y listo. Esto puede ser crucial en ciertas situaciones. Otra ventaja es que incorpora transferencia de archivos entre la tableta y la máquina remota, que en otros casos puede venir bien.

Resumen

Mis recomendaciones personales son más o menos las siguientes:

• Todo basado en estándares y software libre: Tomato, OpenVPN (servidor+cliente VPN), OpenSSH (servidor+cliente SSH), TightVNC, TigerVNC, x11vnc y bVNC. Lo cubren todo, son BSD o GPL y encima gratis. La pega es que requieren bastante configuración inicial. Hay clientes mejores que bVNC como JumpDesktop (aunque son cerrados y de pago).
• Acceso RDP a través de NAT y cortafuegos sin usar VPN, usando credenciales de Google: JumpDesktop. Quizás lo de dar las credenciales de Google duela mucho menos si usas las claves específicas de aplicación que da Google al activar autenticación de doble factor. Estas contraseñas se pueden revocar automáticamente cuando ya no las necesites, y no valen para acceder a las partes más sensibles de la cuenta.
• Acceso VNC a través de NAT y cortafuegos sin usar VPN: JumpDesktop con credenciales de Google o TeamViewer con claves permanentes o de un solo uso. TeamViewer tiene más funcionalidad y cliente Linux, pero JumpDesktop tiene mejor acabado en Android.

Tengo entendido que Splashtop es mejor para videojuegos, pero no pienso usar el acceso remoto de esa forma, así que no me he molestado mucho más con ello :-D.