Bienvenidos a este cuarto episodio de deployando.me, el podcast de tecnología para sysadmins y devops. Soy Rodolfo Pilas y estoy grabando el 16 de noviembre de 2016.
Ha sido para mi una semana movida, ya que participé del I Congreso Latinoamericano de Instructores de RedHat en San Pablo, así que ando con mi portunhol a flor de piel.
Como siempre quiero agradecer a todos Ustedes, escuchas de este podcast. También a todos los que nos siguen en twitter; estoy sorprendido la cantidad de nuevos seguidores que tenemos día a día. Y un agradecimiento espacial a los que han difundido deployando.me en las redes sociales ya sea retuiteando o haciendo comentarios.
Para esta edición he les planteo un cambio, sutil, pero cambio al fin, ¿que tal si empezamos una serie? ¿sobre qué? Sobre herramientas basadas en OpenSSH.
No se Ustedes, pero para mi OpenSSH es parte integral de mi actividad profesional, tanto o más que el propio GNU/Linux, pues openSSH es multiplataforma y también es la forma que accedo a otros Unix.
Por eso que decidí juntar mis herramientas preferidas de OpenSSH y armar una serie.
Entonces vamos por este primer episodio de la serie OpenSSH en el que voy a contarles de sshuttle.
Sshuttle se escribe como ‘lanzadera’ en inglés, pero con dos eses al principio, con lo que su pronunciación es igual, pero su escritura es distinta.
Para presentarles rápidamente sshuttle les digo que es la forma de tener una VPN con ssh. Pero también les aclaro que sshuttle no es una VPN.
Ahi ta! creo que esto va a ser difícil de explicar, así que vamos por partes.
Sshuttle llegó a mi vida este año 2016, así que anteriormente no la conocía por lo que usaba otras cosas para su función.
Todos hemos tenido que acceder a servicios o a servidores que no están directamente conectados o publicados en internet. O dicho de una forma más técnica hemos tenido que conectarnos a servicios que están en una sub-red para la cual no se dispone de rutas.
¿cómo hacemos estas conexiones?
Pues nos conectamos a un servidor ‘de borde’ y desde él llegamos hasta el servicio en la sub-red, y para poder llegar al servicio en cuestión tenemos dos formas, mediante túnel o mediante vpn.
Cuando hablamos de un túnel con ssh trata de presentar en un puerto local un servicio que está en un servidor remoto, llevando el tráfico por dentro de la conexión ssh que tenemos que establecer para armar dicho túnel.
Entonces generalmente he utilizado túneles de ssh para conectarme a servicios de MYSQL que están en una sub-red a la que no tengo acceso y poder consumir esos servicios como si estuvieran locales para mi. En concreto, suelo hacer que el puerto de localhost 3306 termine tunelizado el puerto 3306 del servidor mysql con una conexión ssh desde localhost al servidor ‘de borde’.
ssh -L 3306:mysqlserver:3306 usuario@sshserver
También he utilizado túneles reversos, es decir, publicar en internet un puerto de mi equipo para que puedan consumir los servicios que ofrezco desde cualquier parte del mundo. Recuerdo una ‘ligthning talk’ que tuve oportunidad de dar en el Techmeetup 2014 titulada ‘Receta de Túnel para llegar a tu computador’. Técnicamente es abrir un puerto en un servidor de internet mediante una conexión ssh desde tu computador de forma que quién se conecte a ese puerto tenga su tráfico tunelizado por esa conexión ssh y llegue directo a un puerto de tu localhost donde tienes un servicio específico.
ssh -R 8080:localhost:80 usuario@sshserver
O sea que los túneles son bárbaros cuando tienes que conectar a uno, dos o tres puertos de un servidor específico y no quieres mucha complicación.
Pero también existen los casos, que las conexiones tienen que ser hechas a diferentes servidores y diferentes puertos en cada uno. En esos casos, siempre he optado por VPN.
Técnicamente sabemos que la VPN es la forma de conectar con la sub-red privada (sin rutas) que está detrás del servidor con el cual armamos la VPN. La VPN supone todo el stack de red interfaces de red y rutas, por lo que obtenemos todas las ventajas y desventajas de una nueva conexión.
Por ejemplo, en la nube de Amazon, cuando armo una infraestructura en un VPC privado, suelo levantar una VPN contra un instancia que tiene además una IP pública y así accedo a todo el VPC como una instancia más.
Las VPN requieren de servicios y puertos especiales que se deben configurar, de certificados para acceso y de herramientas propias de conexión.
Pero ahora conocí sshuttle (y llegamos al tema de este podcast)
A partir de sshuttle he dejado de pensar en túneles y vpenes cuando hablo de conexiones que no son dedicadas, o sea las que hago todo el tiempo desde mi computador para administrar servidores o probar servicios remotos.
Sshuttle es un cliente especial del servicio OpenSSH que debe ser instalado y que permite hacer una conexión a un servidor remoto, generando en el momento un NAT para la sub-red que uno le especifique que debe ser accesible desde por el servidor ‘de borde’.
Entonces, sshuttle es una conexión ssh, con todo lo que implica a nivel de cifrado del canal, de validación y permisos. Pero, una vez establecida, verificará las rutas disponibles en el servidor de remoto y generará una estructura de iptables para redirigir y hacer nat de las conexiones que se inicien en localhost hacia la sub-red que se ha especificado al invocar a sshuttle.
En definitiva un comportamiento equivalente al de una VPN.
Veamos un ejemplo:
Tengo un VPC en Amazon AWS con la sub-red 172.16.1.0/24, una instancia que solo se accede desde el VPC con IP privada y otra instancia con una IP pública.
En mi computador ejecuto sshuttle para conectarme a la instancia con IP pública y le digo que se encargue de la sub-red 172.16.1.0/24.
sudo sshuttle -r username@sshserver 172.16.1.0/24
A partir de ahí podré consumir los servicios de la instancia con IP privada directamente accediendo a su IP, ya que dispondré de un NAT que dejará mi tráfico con la IP privada de la instancia a la que me he conectado por SSH.
Otro ejemplo:
sudo sshuttle --dns -r usuario@sshserver 0.0.0.0/0
Ejecuto sshuttle para conectarme a un servidor remoto en internet y le digo que quiero asignarle todo posible destino (o sea la sub-red 0 .0 .0 .0/0) y además le incluyo el tráfico DNS (con el parámetro --dns), entonces toda mi navegación, correo y demás estará saliendo a internet por la IP pública de dicho servidor remoto y usará su configuración de DNS para la resolución de mis destinos.
No es VPN… pero qué parecido ¿no?
Si he logrado explicarte el funcionamiento de sshuttle seguro estarás tan entusiasmado en probarlo como lo estuve yo la primera vez que me enteré de él.
Pero no dispares el entusiasmo, en distintos ambientes habrá que ponderar si una una herramienta de vpn (como openvpn) o de túneles (stunnel) es más adecuada para las necesidades particulares.
Lo que si te aseguro que sshuttle es la forma de tener una vpn en la punta de mis dedos cada vez que quiero, sin tener que empezar a configurar cosas, pues el servicio openssh lo tenemos en todos los servidores y sshuttle instalamos una vez en nuestra notebook o desktop.
Claro, si quieres hacer una conexión permanente de sshattle puedes utilizar autossh … pero antes de hacerlo, te sugiero esperar a la próxima edición de deplorándome, de la cual te diré que continuará con la serie de herramientas OpenSSH, pero no te adelantaré cuál es…
Soy Rodolfo Pilas, en twitter me siguen por @pilasguru y les dejo un saludo a todos, confiando en que este podcast les haya aportado para mejorar y, como siempre, espero sus inquietudes y sugerencias comentando en deployando.me