• Software Libre y Comunidades (ODP)
• Software Libre y Comunidades (PDF)

La presentación esta bajo licencia  CC share alike. Si les utiliza, me gustaría mucho saberlo

Una Red Privada Virtual (VPN por sus siglas en inglés) sirve para crear una conexión encriptada entre 2 o más puntos a través de Internet. Un caso de uso típico puede ser permitir al acceso a servicios de una intranet de forma segura desde Internet.  Otro caso típico de uso es interconectar redes locales de 2 ó más sucrusales a través de Internet. En este artículo haremos la primera opción y en un futuro cercano publicaré cómo interconectar 2 redes.

Existen varias implementaciones de VPN y en el mundo de software libre una de las más populares es OpenVPN.  Una de sus grandes ventajas, es que se pueden tener clientes en distintos sistemas operativos com GNU/Linux, Windows, Mac y seguro que en todas las versiones BSD.

Instalación

OpenVPN viene por defecto en la mayoría de las distribuciones GNU/Linux. En mi caso suelo utilizar Debian o Ubuntu. La instalación la hice con aptitude:

aptitude install openvpn

En distros basadas en RPM la instalación se la hace con yum:

yum install openvpn

Listo , así de fácil y de sencillo.

Crear los certificados digitales

OpenVPN autentica sus clientes a través de llaves públicas y privadas. De esta manera cada cliente tiene su llave privada y debe enviar su llave pública al servidor. Estas llaves son creadas con un certificado conocido como “Certificado de Autoridad“. De esta forma cuando el servidor recibe una llave pública este revisa si esta firmado con el certificado de autoridad. Sino esta no aceptará la conexión.

La forma más fácil de crear estos certificados es utilizando la utilidad easy-rsa que viene en el paquete de OpenVPN. En el caso de debian esta aplicación se encuentra en: /usr/share/doc/openvpn/examples/easy-rsa/2.0/ easy-rsa. Otras distribuciones tendrán una ruta similar.

Copiamos la aplicación a una ruta más fácil de recordar. Personalmente opté por un subdirectorio dentro de /etc/openvpn. Para tener las cosas ordenadas:

cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/ /etc/openvpn/easy-rsa


Ahora ingresamos al directorio para crear las claves:

cd /etc/openvpn/easy-rsa/

Dentro de esta carpeta tenemos un archivo que almacena algunas variables importantes. Recomiendo revisar este archivo y de ser el caso modificar algunas variables.

vim vars

En mi caso personalice la siguiente parte para que cuando cree los certificados los valores por defecto tengan que ver con mi realidad:

export KEY_COUNTRY="EC"
export KEY_PROVINCE="Pichicha"
export KEY_CITY="Cayambe"
export KEY_ORG="Mi empresa"
export KEY_EMAIL="yo@midominio.com"

Guardamos y cerramos el archivo. Si no queremos no modificamos el archivo, es algo netamente opcional.

Cargamos las variables de este archivo al shell que estamos utilizando:

. vars

Borramos las claves previamete creados en caso de existir. Hacer esto solo si es la primera vez que vamos a crear los certificados y las claves.

./clean-all

Creamos el certificado de autoridad:

./build-ca

Si modificaron las variables, se darán cuenta que ahora las estaremos utilizando.

Certificado y clave privada para el servidor

/build-key-server servidor

Esto generara los archivos servidor.crt y servidor.key. donde el archivo .key es la llave privada y .crt es la pública.

Generamos los parámetros  Diffie Helman

./build-dh

Generamos las claves de los clientes.

./build-key cliente1
./build-key cliente2
./build-key cliente3


De manera similar al servidor se crearán las claves *.key y *.crt que serán las claves privadas y públicas respectivamente. Las 2 claves las deberemos copiar al cliente.

Listo, hemos creado todos los certificados necesarios y estamos listos para configurar los clientes y el servidor. Es importante sacar un respaldo del directorio /etc/openvpn/easy-rsa ya que ahí están todas las claves, incluido el certificado de autoridad que nos permitirá crear nuevas claves a futuro.

Resumen de las claves y certificados creados:

Nota: en clienteX, X quiere decir el número del cliente. En este ejemplo estamos trabajamos con 3 clientes para la VPN pr lo que deberíámos tener 3 pares de claves .crt y .key.

Configurar el Servidor

Copiamos los archivos que corresponden al servidor en una carpeta dentro del mismo. En mi caso copie la configuración en /etc/openvpn/claves. Si generamos las claves en una máquina que no es el servidor debemos usar scp u otra aplicación para subirlas a nuestro servidor.
Copiamos un archivo de ejemplo de configuración del servidor y la adaptamos a nuestras necesidades.

cd /etc/openvpn
cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz .
gunzip server.conf.gz
vim server.conf


Dentro del archivo modificamos algunas variables para que funcione. Aquí expico algunas:
Protocolo a utilizar:

# TCP or UDP server?
proto udp


Vamos a configurar la vpn utilizando el protocolo UDP ya que esto nos dará un mejor rendimiento. No tiene sentido trabajar en TCP ya que dentro de nuestra vpn se correra el protocolo IP donde de ser necesario se volver a utilizar el protocolo TCP y no tiene sentido utilizar 2 veces este protocolo. En otras palabras, utilizar TCP solo cuando no lo puedan hacer con UDP.

Definimos las rutas a los certifiados. Recordar que en este ejemplo estamos utilizando /etc/openvpn/claves

ca claves/ca.crt
cert claves/servidor.crt
key claves/servidor.key
dh dh1024.pem


Por último, en el mismo archivo, decimos a que redes queremos que los clientes vpn puedan acceder.

push "route 192.168.45.0 255.255.255.0"

Listo podremos iniciar el servidor:

/etc/init.d/openvpn start

En caso de necesitar corregir errores se puede iniciar el servicio así:

openvpn <archivo de configuración>

Nota: El servidor VPN debería poder trabajar como ruteador por lo que debemos activar esto a nivel del kernel:

echo 1 > /proc/sys/net/ipv4/ip_forward

Para que la configuración quede grabada y no se pierda al reiniciar la máquina se debe editar el archivo /etc/sysctl.conf y poner el valor de 1 a la variable correspondiente:

net.ipv4.ip_forward=1

Configuración de un Cliente

Instalar OpenVPN en el cliente. En el caso de usar Linux, la instalación es igual a como se instala el servidor.
Copiamos los archivos correspondientes al cliente dentro de la máquina del mismo (Ver la tabla de arriba). En mi caso los copie en /etc/openvpn/claves

Una vez que tenemos las claves, copiamos un archivo de configuración de ejemplo para cliente y lo configuramos para nuestras necesidades:

cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/
vim client.conf

Definimos el protocolo como UDP igual que en el servidor:

proto udp


De manera similar al servidor, editamos las varialbes ca, cr y key:

ca claves/ca.crt
cert claves/clienteX.crt
key claves/clientX.key

El cliente debe saber a que servidor se debe conectar. Para esto debemos utilizar un nombre de dominio o el IP público y el puerto a conectarse. Por defecto OpeVPN corre en el puerto 1194.

remote miservidor.com 1194

Iniciamos OpenVPN en el cliente

/etc/init.d/openvpn start

En caso de tener errores podemos probar con

openvpn <archivo de configuracion>

Para probar la conectividad podemos hacer ping al ip 10.8.0.1 que es el ip de nuestro servidor. Si lo hacemos ya estamos con la VPN arriba. en caso de haber puesto la sentencia push podríamos hacer ping a ips dentro de la red LAN donde se encuentra la VPN. Ojo que las máquinas de la red LAN deberían saber como llegar a la red 10.8.0.0/24, para esto deberíamos ver la configuración del servidor.

Referencias Adicionales

• How to OpenVPN

En este artículo explicaré como asegurar WordPress para que la administración del mismo tenga una comunicación encriptada con el servidor. Para esto modificamos el archivo:

/directorio/instalacion/wp-admin.php

Añádimos la siguiente línea:

define('FORCE_SSL_ADMIN', true);

Esta línea debería estar antes de este comentario:

/* That's all, stop editing! Happy blogging. */define('ABSPATH', dirname(__FILE__).'/');


Con esto estaremos obligados a administrar WordPress através de HTTPS. Ojo deberían tener configurado su servidor web para que escuche por HTTPS en ese puerto.

Una vez terminado el FLISOL de Cayambe envié un correo muy emocionado compartiendo mi experiencia a varias listas. Al parecer mi emoción fue tanta que me publicaron el correo en el sitio de LinuxPreview.

Luego de enviar el correo decidí descagar mis correos y obtuve una triste noticia desde la ciudad de Portoviejo. Lamentablemente justo el día en que se realizaba el FLISOL hubo un apagón. Por más buenas intenciones que alguien pueda tener, es imposible hacer un festival de instalaciones sin electricidad.

Lo primero que pensé luego de leer ese correo fue en que iba a hacer el próximo sábado. No tenía planes, podría irme a Portoviejo. Llame a Gabriel por teléfono y le dije porque no hacemos el evento en una semana y por lo menos yo desde Quito/Cayambe iría hasta allá para ayudar. Gabriel aceptó, compartí la idea con la comunidad del FLISOL de Ecuador y a la final fui yo desde Cayambe, David Puente desde Quito y Guillermo Salas desde Manta (más fácil ).

El viaje de Quito a Portoviejo toma alrededor de 8 horas en bus, que normalmente me gusta hacerlas de noche. Para los que conocen Ecuador un viaje como este se podría definir como una mala noche, un susto y $8. Riesgo que no me lo podía perder para conocer y ayudar a mis amigos de Portoviejo.

El siguiente viernes de noche, emprendí el viaje con mi amigo David y nos fuimos hasta Portoviejo. Una vez ahí llamamos a Gabriel al celular y nos fuimos a desayunar con Gabriel. Luego se nos unió Debray Acosta . Fuimos a la universidad a conocer el laboratorio y ver lo que tenían preparado.

La idea era simple, en un laboratorio se darían charlas de software libre y luego empezaríamos a instalar. Gabriel empezó con su charla sobre demostrativa del software libre. Entre otras cosas recuerdo que habló de Gambas, emuladores de nintendo, MySQL y mucho más.

Yo estaba sumamente cansado luego de haber viajado toda la noche cuando escuché a Gabriel terminar su presentación con las siguientes palabras: “Bueno, ahora les dejo con Rafael Bonifaz para que les cuente sobre software libre”

En ese entonces yo había dado exactamente una sola conferencia de software libre en toda mi vida y fue la semana anterior en el FLISOL de Cayambe. Claro para esa presentación casi no dormí la noche anterior (era mi primera) y tenía mis diapositivas para apoyarme.

Ahora una semana después, mal dormido me habían anunciado para que de una charla de software libre que no había preparado y además no tenía mis diapositivas. Me llené de valor, caminé hacia adelante donde veía a toda la gente que me veía y decidí contar mi experiencia con el software libre. Creo que fue entonces cuando perdí el miedo escénico para hablar de software libre e improvisé una charla de 45 minutos. Lo increíble fue que nadie se aburrió (bueno tal vez David que tampoco había dormido muy bien), por lo contrario todos se veían sumamente interesados por el tema.

Luego de mi charla, paso adelante Gabriel y dijo que ahora ahora David Puente daría su charla sobre OpenOffice.org. David que tampoco había preparado su presentación salió muy bien librado.

Terminadas las charlas, empezamos a instalar GNU/Linux. Fue durante las instalaciones que me presentaron al mítico Razametal (Guillermo Salas) que venía desde Manta. Digo mítico porque en esa época el sitio de software libre más popular de Ecuador era el Ecualug y era simplemente imposible tratar de igualar la participación de Razametal. Para mi en ese momento era como conocer a uno de los duros. (Todavía es de los duros, pero ya le conozcó un bueno tiempo)

Terminado el evento, el buen Debray Acosta empezó con su tour gastronómico por Manabí. Fuimos a almorzar y en algún momento comimos unos deliciosos corviches que yo tanto había pedido. Luego nos fuimos a dormir en la playa de Crucita y a seguir disfrutando de la comida de mar.

El FLISOL fue una iniciativa de la comunidad colombiana de software libre COLIBRI que organizaba un evento similar al FLISOL pero con alcance local en Colombia desde el año 2003. La idea original de este evento fue de Alejandro Forero Cuervo y se llamaba FISL. El mismo Alejandro en octubre del año 2004 propone realizar un evento similar, pero invitando a gente de otros países. En poco tiempo Alejandro mejoró la idea y surgió lo que ahora conocemos como FLISOL.

Al ingresar al sitio oficial del FLISOL se puede ver que no existe una referencia del primer evento en el año 2005. Sospecho que por algún motivo se perdió el backup pero recientemente encontré un snapshot del 3 de abril del año 2005, que muestra como se veía el sitio un día después de la realización del primer FLISOL.

Cuando me enteré de la idea de organizar un evento sobre el primer FLISOL, llené de emoción porque me pareció simplemente una idea fantástica. Este evento ayudó a unir a las comunidades de software libre de América Latina que no nos conocíamos y además ayudó a conocer a la comunidad de software libre a nivel nacional y a nivel de ciudad.

Para los que les interese un poco más como surgió este evento, les comparto mi experiencia coordinando el primer FLISOL de Ecuador y un artículo que escribí sobre el impacto del FLISOL en el Ecuador. Además recomiendo leer esta página del Wiki del FLISOL que nos cuenta más de la historia del FLISOL.

Quiero agradecer a Alejandro y a COLIBRI por haber aportado con esta excelente idea. Además hay que agradecer a toda la comunidad a nivel regional por apoyar constantemente a este evento.

Por último quiero agradecer a María del Pilar Saenz porque a través de Identi.ca me ayudo a encontrar los links a los correos de Alejandro que me aclararon mucho sobre como inicio esto.

En esta imagen se puede ver a mi sobrina montada en el caballo

Con esto de ser papá e informático tenía que llegar el momento de compartir la computadora con las hijas. Actualmente la Ana Martina le encanta jugar con Gcompris, pero en especial con Tux Paint. Estos son 2 aplicaciones de software libre educativas excelentes para los más pequeños y sus padres .
Para los que no han utilizado alguna vez Tux Paint saben que una de las partes más interesantes son las sellos. Con los sellos podemos agregar imágenes, las mismas que suelen ser asociadas con un sonido y un texto descriptivo. Por ejemplo si añadimos la vaca, al seleccionarla va a sonar “moo” y luego el audio nos dice la palabra “vaca”. Así el niño asocia la vaca con la imagen, el sonido y su nombre.
Si bien hay muchos sellos con muchos sonidos, me parece interesante poder añadir más. Por ejemplo, me gustaría tener animales andinos como el condor, las llamas, etc… Esto todavía no lo hago, probablemente alguien ya lo ha hecho y sino espero que este artículo ayude a alguien a hacerlo .
Una de las libertades del software libre es poder modificar sus aplicaciones y entender como funcionan. En este artículo vamos a ver lo sencillo que es hacer estos cambios en Tux Paint sin tocar el código fuente.

Añadir Sellos a 1 Usuario

En este caso en particular es necesario crear el directorio ~/.tuxpaint/stamps (/hpme/usuario/.tuxpaint/stamps). Dentro del mismo creamos los sub directorios que necesitemos para organizar nuestros sellos.

En cada sub directorio deberíamos añadir una imagen PNG (con transparencia) o SVG para lo que se puede usar el Gimp u otra aplicación gráfica. Listo luego ya podremos ver los sellos en Tux Paint.

Nota: Además de los sellos se pueden crear las carpetas ~/.tuxpaint/brushes y ~/.tuxpaint/starters para añadir brochas e imagenes de fondo para iniciar los dibujos.

Añadir Sellos para todos los Usuarios

Esta solución es útil si tenemos más de una persona usando la computadora. Por ejemplo podría ser el caso de una escuela donde cada niño tiene su propio usuario, pero queremos que todos tengan acceso a nuestras personalizaciones.

TuxPaint guarda las imagenes, sellos y sonidos dentro del directorio /usr/share/tuxpaint. En este directorio esta el subdirectorio /usr/share/tuxpaint/stamps. Si revisamos este directorio vamos a ver varios subdirectorios. Lo que yo hice fue crear el directorio personal y asignar privilegios de escritura a mi usuario.

mkdir /usr/share/tuxpaint/stamps/personal/


De esta manera tendré un directorio donde podré copiar las imágenes sin preocuparme e los permisos.. En mi caso subí una foto de mi sobrina para que mi hija tenga a su prima dentro del Tux Paint. Para esto con mis pocas habilidades en el Gimp cree el archivo sobrina.png. Uso este formato porque soporta transparencias. El archivo lo guardé en el directorio personal recién creado. Luego cree un archivo de texto llamado sobrina.txt dentro del mismo directorio y dentro del mismo puse el texto “nombre de mi sobrina”. Además utilizando el micrófono puede haber creado el archivo sobrina.ogg y copiarlo ahí mismo. Listo ahora hay una nueva categoría dentro de los sellos donde esta mi sobrina. Ahora a agregar a toda la familia .

Conclusión

No se si esta es la manera en la que se debe hacer. La verdad leí cero documentación, solo revisé el árbol de directorio y vi como estaban estructuradas las otras imágenes. El resto fue experimentar :). Si alguien sabe una mejor forma de hacerlo avise .

Gracias a Ricardo Arguello y a Bill Kendrick mejore este mini how to y encontré este tutorial en Inglés mucho más detallado y con explicaciones para Windows y Mac.

Seguro esto también se puede hacer en Mac y Windows, solo hay que revisar donde estan los archivos.

Como dato anegdótico, tuve la oportunidad de conocer a Charles en el BRM de OOXML en Ginebra en el año 2008. Si bien estuve una semana ahí tuve la oportunidad de conversar mucho con el y otra gente interesante del movimiento del software libre y estándares abiertos. Algo paradójico es que nunca hubiera conocido a Charles y a mucha otra gente interesante si no hubiera sido gracias a Microsoft el estandard OOXML que todavía no lo implementa nadie.

Ejemplo #1: Acceder con ssh a computador con ip privado

Vamos a suponer el siguiente caso práctico. Mi mamá es una usuaria de GNU/Linux y tiene algún problema en su computador. Ella tiene su computadora en la casa y no tiene ip pública ni la menor idea de lo que es un ip. Su hijo tiene algo de experiencia le puede ayudar. Para esto con mucha paciencia le va a decir” mami vaya a accesorios terminal y escribe lo siguiente:

ssh -R *:8080:localhost:22 usuarioremoto@servidorremoto.com

Mi mamá no tiene porque entender este comando, pero ustedes sí. El * quiere decir que vamos a ser accesibles desde cualquier ip que tenga mi servidor remoto. El 8080 es el puerto que utilizaremos en el servidor remoto y localhost:22 quiere decir que vamos a hacer accesible el puerto 22 de mi máquina local. La segunda parte del comando quiere decir a que servidor ingresamos y con que usuario.
En otras palabras mi mamá esta ingresando a mi servidor y publicando el puerto 22 de su computador en el puerto 8080. Obviamente sin tener la menor idea de lo que esta haciendo.
Ahora para yo ingresar al computador de mi mamá simplemente hago ssh al puerto 8080 en el servidor remoto con el usuario local del computador de mi mamá.

ssh -p 8080 usuario@servidorremoto.com

Para que esto funcione necesitamos poder acceder como root al servidor por lo menos una vez y/o ser amigo de una persona que tenga acceso a root. Es necesario modificar el archivo de configuración del servidor ssh: /etc/ssh/sshd_config y añadir la siguiente línea:

GatewayPorts yes

Luego reiniciamos ssh

/etc/init.d/ssh restart

Ahora sí debe funcionar.
Si se fijan bien lo que estamos haciendo hay una falla de seguridad. Si mucha gente puede hacer ssh a mi servidor remoto, entonces podrían estar utilizando varios puertos de mi servidor para fines que desconozco.
La buena noticia, es que sumando los conocimientos adquiridos aquí con el primer ejemplo de túneles ssh podemos obtener el mismo resultado.

Ejemplo #2: Acceder con ssh a computador con ip privado sin necesidad de root en el servidor

Por defecto la siguiente línea no va a funcionar si no editamos el archivo de configuración del ejemplo anterior.

ssh -R *:8080:localhost:22 usuarioremoto@servidorremoto.com

El * quiere decir escuchar en cualquier IP. SSH por seguridad viene configurado para que solo podamos redirigir al ip  local de nuestro servidor.
Entonces lo que haremos en este ejemplo  es los siguiente. Mi mamá redirecciona su puerto local de ssh (22) al 8080 de mi servidor. Luego yo redirecciono el puerto 8080 de mi servidor al 9090 de mi máquina local. Para termina hago ssh en mi máquina local
Manos a la obra. Mi mamá debería escribir lo siguiente:

ssh -R 8080:localhost:22 mama@servidorremoto.com

En este caso ya no usamos el * ni un ip porque se asume que estamos accediendo a localhost.
Ahora yo desde mi computadora voy a redirigir el puerto 8080 del servidor remoto (accesible solamente desde el mismo) al puerto 9090 en mi máquina personal.

ssh -L 9090:localhost:8080 rafael@servidorremoto.com

Luego en otro terminal en mi computador hago ssh al puerto 9090 de localhost con el usuario del computador de mi mamá.

ssh -p 9090 usuariomama@locahost

Un poco más complicado que el anterior, pero mucho más accesible y seguro.

Conclusión

Este ejemplo talvez no todos los tengan, pero podría ser una forma muy útil de tener soporte. Por ejemplo Juan es un administrador novato que da soporte y tiene problemas. Requiere la ayuda de Pedro que esta en otra localidad. Bajo este mismo principio Pedro podría dar soporte a Juan.

También es importante notar que en este caso estamos redirigiendo solo el puerto de ssh, pero podría ser cualquier puerto. Por ejemplo, estoy trabajando en una aplicación web de manera local en mi computadora. Podría redirigir ese puerto para que sea visible desde la web.

Básicamente un tunel ssh sirve para acceder a un servicio remoto a través de un canal ssh. Así utilizando ssh podríamos hacer cosas como acceder a un servidor smtp que suele estar bloqueado por proveedores de Internet. Se podría compartir un recurso de mi máquina local con ip privado al mundo a través de Internet. En fin se puede hacer muchísimo más que esto y ojalá por ahí comparta alguna otra experiencia interesante.

Redirigir un puerto remoto a mi red local

Para ilustrar esta idea voy poner allgunos ejemplos hipotéticos:

Ejemplo #1: Acceder a un pop3 bloqueado

Supongamos que usted tiene acceso a Internet y el proveedor de Internet tiene bloqueado el puerto 25. Necesita enviar un correo de urgencia, pero no lo puede hacer. Pues bien un tunel ssh es una solución rápida para solucionar este problema (siempre y cuando tenga un servidor donde pueda hacer ssh)

ssh -L 2525:localhost:25 usuario@servidorremoto.com

En esta línea decimos que nos vamos a conectar al servidor servidorremoto.com con el usuario usuario. Una vez que estamos en ese servidor creamos un túnel para redirigir el puerto 25 local del servidor (localhost) en el puerto 2525 local de mi computador de escritorio. En otras palabras el puerto 25 remoto ahora será accesible desde el puerto 2525 local de mi computadora. Así ya no estaremos bloqueados.

Para poder enviar correos, configuramos nuestro smtp como localhost:2525 en nuestro cliente de correo preferido. El puerto 2525 es totalmente arbitrario. En general para hacer esto sin privilegios de administrador se deben usar puertos mayores a 1024.

En este ejemplo asumimos que el servidor de correo es el mismo que el que estamos haciendo ssh, pero esto no es obligatorio. En lugar de localhost podríamos utilizar algo como smtp.otroservidor.com. (ver ejemplo 3)

Para probar que la configuración es correcta podemos usar telnet en nuestro computador de escritorio

telnet localhost 2525
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 servidorremoto.com ESMTP Postfix
telnet localhost 2525Trying 127.0.0.1...Connected to localhost.Escape character is '^]'.220 servidorremoto.com ESMTP Postfix

Ejemplo 2: Acceder a un servidor web con ip privado desde Internet

Supongamos que usted necesita acceder a un servidor web privado en una Intranet desde el Internet. En este caso usted puede acceder como usuario sin privilegios a un servidor con ip pública que puede ver al servidor web de la intranet con ip privada. En una red pequeña, esto podría ser a través del firewall.

Entonces generamos el túnel

ssh -L 8080:10.10.10.30:80 usuario@servidorremoto.com

En este caso el puerto 80 del servidor 10.10.10.30 estará accesible en máquina local en el puerto 8080.

Para probar abrimos un navegador web con la url http://localhost:8080

Ejemplo 3: comparta su conexión con otras máquinas en la red.

En los 2 ejemplos anteriores creamos los tuneles ssh accesibles solo desde mi computador personal. Ahora bien, podríamos compartir los tuneles para la red local en la que me encuentro.

En el primer ejemplo esto sería útil si mi amigo que no tiene acceso a un servidor ssh necesita enviar un correo. Por ejemplo:

ssh -L 192.168.1.45:2525:smtp.remoto.com:25 usuario@servidorremoto.com

En este caso ingresamos con el usuario usuario al servidor servidorremoto.com. Desde servidor nos conectamos al servidor smtp.remoto.com al puerto 25 y lo hacemos accesible en nuestro ip local 192.168.1.45 en el puerto 2525.

Su amigo tendrá que poner en su configuración de smtp: 192.168.1.45:2525. Si tiene acceso de root en su máquina local podría configurar el puerto 25 para que su amigo no tenga que ver como cambiar de puerto en su cliente de correo.

En el caso del servidor web (ejemplo 2), usted puede compartir a su amigo el acceso al servidor de la intranet.

ssh 192.168.1.45:8080:10.10.10.30:80 usuario@servidorremoto.com

Listo ahora su amigo podrá poner en su navegador web http://192.168.1.45:8080

En la próxima entrega voy a explicar como hacer accesible un puerto local de mi computador de escritorio desde el Internet.