lunes, marzo 12, 2012

VPN casera con pptpd

A causa de la petición de un compañero en la que me pidio algo relacionado con montar un servidor VPN, me puse a trastear en casa para disponer de mi propio servidor VPN. Tener una VPN en casa me permite que equipos que están en el exterior, se puedan conectar a la red local, tomando un ip de ella (o de otra red pero con las rutas necesarias para comunicarse entre sí). En situaciones normales, este tipo de cosas no las he necesitado, siempre me he servido de los túneles SSH que son la navaja suiza de la comunicaciones.

Mirando el estado actual del arte1, hay varias formas de montar la VPN: pptp, l2tp y openvpn. Como mis requerimiento de seguridad no son elevados, sino que simplemente quiero algo que funcione rapidamente sin complicaciones, me decanto por la primera de ellas, pptp.

Consideraciones previas:
  • Rango de la red local 192.168.1.1/24
  • En la red hay un rango ofrecido por DHCP 192.168.1.100-199
  • El rango para los equipos que van a entrar por PPTP sera el 192.168.1.200-2452
  • IP del servidor PPTP 192.168.1.97
  • Puerta de enlace 192.168.1.1
  • Servidor dns 192.168.1.1
Como en todo este tipo de cosas, lo primera que se hace es instalar el demonio que va a prestar el servicio. Con apt-get install pptpd tenemos lo necesario para echarlo a andar. Sólo queda retocar la configuración y añadir algunos ajustes adicionales.

Editamos el fichero de configuracion /etc/pptpd.conf.
ppp /usr/sbin/pppd
option /etc/ppp/pptpd-options
debug
localip 192.168.1.97
remoteip 192.168.1.200-245
La opción localip es la ip que tiene el servidor donde va a arrancar el servicio pptpd. La opción remoteip define el rango de direcciones que va a entregar el demonio a los clientes cuando se conecten. Si vemos necesario, activamos la depuración para ver luego todo el proceso de login de los usuarios vpn (en /var/log/daemon.log y /var/log/messages).

El siguiente paso es editar el fichero de configuracion de opciones /etc/ppp/pptpd-options
name debian-wheezy-001
require-mschap-v2
require-mppe-128
ms-dns 192.168.1.1
proxyarp
defaultroute
nodefaultroute
debug
lock
La duda más importante que tengo aqui es relativa al parametro defaultroute, las guias que he leido incluyen la opción contraria (nodefaultroute) pero hasta que lo cambie no funcionó la conexión.

El último aspecto a retocar es la configuración de los usuarios que se encuentra en el fichero /etc/ppp/chap-secrets.

# client server secret IP addresses
usuariovpn1 debian-wheezy-001 claveusuariovpn1 192.168.1.200
Después de reiniciar el servicio pptpd, conseguí que los usuarios se logaran, pero no habia forma de que estos pudieran ver el resto de la red, aunque desde el servidor vpn si que lograba hacerle un ping. Me faltaba un detalle que había visto en algunas partes, permitir el ip_forward.
$ sysctl -w net.ipv4.ip_forward=1
Con esto conseguí que el cliente usuariovpn1, con ip 192.168.1.200 se viera en la red y pudiera acceder al resto de equipos de la misma (y viceversa). Si la opción net_ipv4.ip_forward la quiero dejar permanenten en el arranque, edito el fichero /etc/sysctlf.conf para incluirla.

El último paso a dar es la apertura de puertos en el router. Se debe abrir en el router el puerto del demonio pptpd (tcp/1723) y redirigirlo a la ip del servidor vpn (192.168.1.97 en este caso).

Un aspecto a modificar es el hecho de seleccionar la red 192.168. No es muy acertado, debido a que muchos clientes pueden conectarse mediante una conexión por wifi de su red local, y si la wifi suele estar configurada con la misma subred que la mía, con lo que si tenemos un cliente de la red 192.168, no se podrá comunicarse correctamente (no se puede tener la misma red en ambos extremos). Es mejor eligir otra (una 10.X.X.X) y agregar las rutas necesarias.

La duda que tengo con los parámetros defaultroute/nodefaultroute la aclararé pronto. Ha sido aclarada, es mejor poner nodefaultroute. El que no me funcionara se debe a que en mi prueba pasé por el alto que aún estaba sin configurar el parámetro del net.ipv4.ip_forward.
1 Me encanta esta frase.
2 Esto se demostrara más adelante que puede traer inconvenientes.

No hay comentarios:

Publicar un comentario

Cómo utilizar el servicio Secrets Manager para guardar las claves privadas de SSH

Para guardar la clave privada en el servicio Secrets Manager como un secreto en modo texto sin formato, sigue estos pasos Supongamos que la ...