bueno, más que jugando, sacándole jugo a la conexión VPN que conseguimos con el post anterior. En este caso, una necesidad y ganas de retorcer la cosas, hemos metido en nuestra “red” un servidor dedicado que tenemos en housing, pongamos que en… hostinet (publicidad gratuita ;p).

vale, el servidor corre servicios web, para continuar con el ejemplo, este mismo blog… lostintheshell.net, a parte, supongamos que en https://aplicacion.lostintheshell.net tenemos acceso web a una aplicación que debe acceder, o incluso realizar querys en tiempo real, a la información recogida en la BBDD de uno de nuestros servidores locales. (recordamos que en las net-lan de telefónica no se permite la apertura de ningún puerto).

Vale, la cosa es bien sencilla, instalamos en nuestro servidor el software que comentábamos el otro día VPNC, con nuestro fichero de configuración debidamente configurado (recordamos):

LOSTINTHESHELL.conf

IPSec ID LOSTINTHESHELL
IPSec gateway LOSTINTHESHELL1.ipsec.rima-tde.net
IPSec secret LOSTINTHESHELL
IKE Authmode psk

Xauth username berto@LOSTINTHESHELL

NAT Traversal Mode cisco-udp

Bien, pues ya está listo, ¿no?. Pues bien, en este caso no es oro todo lo que reluce, ya que tenemos una problemilla relativamente “gordo”. Tranquilos, no asustarse, que lo explico.

- Tenemos un único punto de acceso a ese servidor dedicado, es decir, accedemos a él por una única ip (da igual que sea través de web, de telnet, de ssh…), su ip pública (que sigue unas reglas de networking); no tenemos acceso físico a ese servidor, ni tan siquiera a un terminal, que no sea a través de ssh, en este punto es dónde debemos tener ¡cuidado!

Al levantar la VPN todo el enrutamiento, por defecto, se hace a través de las reglas establecidas para la VPN, quedando “absorvido” o “anulado” el tráfico habitual del funcionamiento normal del servidor. Es decir, en el mismo momento que levantemos la VPN perdemos el control del servidor, ya que no tenemos modo de acceder al terminal.

Para no encontrarnos con esta problemática, y cómo lo único que perdemos es la conectividad con el servidor, lanzamos un script que nos levante la vpn, pero que después continúe reestableciendo las rutas por defecto, es decir, (re)configurando su red normal para dejarla tal y como estaba antes de establecerse el tunel VPN y estableciendo la red y ruta del tráfico que debe pasar por la VPN. He aquí un ejemplo, suponiendo que nuestra red es de clase B, una 192.168.0.0 y la ip pública de nuestro servidor 91.171.157.227

open-vpn.sh

echo “Conexión realizada con éxito”

#!/bin/bash
# Sencillisimo script realizado por b3r2c0 para establecer la VPN con la NetLan de Telefónica y un servidor dedicado (externo)
echo “Realizando Backup de las DNS locales”
cp /etc/resolv.conf /etc/resolv.conf.local
echo “Conectando a la VPN de l.i.t.s.”
vpnc-connect LOSTINTHESHELL
echo “Manteniendo el GW por defecto para la conexión principal”
route add default gw 91.171.157.254 dev eth0
echo “Añadiendo la gestión de tráfico de la VPN”
route add -net 192.168.0.0 netmask 255.255.0.0 dev tun0
echo “Restaurando DNS”
cat /etc/resolv.conf.local >> /etc/resolv.conf

el default gw que le añado, no es aleatorio, antes de elaborar el mini-script, has de consultar tu configuración de red con ifconfig; por otro lado, el juego de idas y venidas con el resolv.conf es para solventar el problemilla que se nos planteaba en el post anterior, ya que el vpnc machaca tus dns por defecto, así pues nos quedamos con las que teníamos y se las añadimos a las generadas por la net-lan (pese a que no les demos utilidad, más vale prevenir); luego en un script vpn-off.sh, desconectaremos la vpn y le dejaremos sólo las dns previas. Por cierto, no te olvides de darles permisos de ejecución a los scrpits, ejjeej.

ciao.

Share on Facebook