Configurar un cliente vpn l2tp en linux como servicio

¿Cual era mi problema?

Uno de mis cliente necesitaba conectar su pagina web con su ERP, como es normal el servidor web esta en un hosting y el ERP en su servidor de la oficina. Como medida de seguridad me pidieron que la comunicación entre los equipos fuera por vpn, y como no…el servidor solamente aceptaba l2tp sobre ipsec, lo más complicado para configurar en un linux por consola, no podía ser openvpn no….en fin que nos toco investigar como se configura el l2tp en linux y no te creas que hay una información clara. 

Por último para complicar un poco más el asunto era necesario que el cliente (la web tuviese un ip fija interna), esto costo un riñón encontrar como hacerlo. Pero el menda es un poco cabezón y después de mucho investigar encontré como hacerlo. Viva la documentación!!!

La receta de hoy: Como configurar un cliente l2tp sobre IPSec en linux con ip fija por consola y con comprobación de conexión cada minuto

Ingredientes.

    1. Un servidor de vpn l2tp sobre ipsec con ip fija.
    2. Un usuario, contraseña de usuario y contraseña de ipsec.

Preparación.

Vamos al lío. Para poder conectar el cliente linux por l2tp osobre ipsec vamos a necesitar instalar los siguientes paquetes: libreswan para la parte ipsec, y xl2tpd para la parte l2tp para ello escribimos lo siguiente:

Para debian/ubuntu:

apt install libreswan x2ltpd

Para centos

yum install libreswan x2ltpd 

Empezamos por configurar libreswan, para lo que tenemos que crear un fichero de configurar en /etc/ipsec.d/ en nuestro caso le vamos a llamar v_cli.conf y le pegamos lo siguiente:

conn v_cli

  left=%defaultroute

  auto=add

  authby=secret

  type=transport

  leftprotoport=17/1701

  rightprotoport=17/1701

  right=X.X.X.X #la ip publica del servidor vpn

  rightid=Y.Y.Y.Y #la ip privada del servidor vpn

Con esto ya tenemos una configuración estándar para el túnel ipsec. Solamente nos queda indicar la contraseña del túnel. Esto lo hacemos modificando el fichero /etc/ipsec.secrets añadiendo la siguiente línea con nuestro:

%any : PSK "Contraseña"

Con esto ya tendríamos la parte ipsec configurada. Vamos a por la parte L2TP, esto la hacemos configurando el paquete xl2tp, lo cual hacemos modificando el fichero /etc/x2ltpd/xl2tp.conf con los siguientes datos:

[lac v_cli] #nombre de nuestra conexión

lns=X.X.X.X #la ip publica de nuestro servidor

ppp debug = yes

pppoptfile = /etc/ppp/options.xl2tpd.client #indicamos donde está el fichero de configuración del cliente

length bit = yes

Ahora configuramos el cliente ppp para meter los datos de nuestros usuario:

pcp-accept-local

ipcp-accept-remote

require-mschap-v2

noaccomp

noccp

noauth

idle 1800

mtu 1410

mru 1410

noipdefault

nodefaultroute

Y.Y.Y.Z:Y.Y.Y.Y #donde Y.Y.Y.z es la ip fija que le queremos dar a nuestro equipo en la red remota y Y.Y.Y.Y la ip privada del servidor vpn

usepeerdns

debug

logfile /var/log/xl2tpd.log

connect-delay 5000

proxyarp

name v_name #nuestro usuario

password v_password #nuestra contraseña de usuario

Si lo hemos hecho todo bien, ya tendríamos nuestro túnel levantado ahora solo tendríamos que ejecutar los siguientes comandos para levantarlo

sudo systemctl start ipsec #arrancamos el servicio de ipsec
sudo systemctl start xl2tpd #arrancamos el servicios de l2tp
sudo ipsec auto --up v_cli #levanta el tunel ipsec v_cli
sudo xl2tpd connect v_cli #conecta a nuestro usuario con el túnel l2tp 

Con esto tendríamos levantado el túnel a través de una nueva interfaz ppp0 con una ip estática Y.Y.Y.Z, solo nos queda indicar la ruta que para llegar a nuestra red remota Y.Y.Y.Y tiene que usar esta nueva interfaz para eso añadimos una ruta estática:

route add -net Y.Y.Y.0/24 gw Y.Y.Y.Z dev ppp0

y voilá ya tenemos nuestro cliente conectado a nuestra red remota. Este proceso lo tendríamos que repetir cada vez que queramos conectarnos. Para que no tengamos que estar pendientes de hacerlo creamos un script que ejecutado cada minuto compruebe que la conexión está creada y sino creará de nuevo el túnel.

#!/bin/bash
 #obtenemos las ip de la interfaz ppp0
 IP_P=$(ip -o -4 a show dev ppp0 | awk -F '[ /]+' '/global/ {print $4}') 
 
#comprobamos que la ip concede con la nuestra y sino volvemos a levantar el túnel
 if [ "$IP_P" = "Y.Y.Y.Z" ]
         then
                 exit -1
         else
                 echo "Hay que conectar v_cli"
                 sleep 1
                 echo "Reinciamos los servicios....."
                 systemctl stop ipsec || true
                 systemctl start ipsec 
                 systemctl stop xl2tpd || true
                 systemctl start xl2tpd
                 echo "Servicios reiniciados, conectamos v_cli"
                 sleep 5
                 ipsec auto --up v_cli
                 xl2tpd-control connect v_cli
                 sleep 10
                 echo "Comprobamos PPP0 y añadimos la ruta ..."
                 ipconfig ppp0
                 route add -net Y.Y.Y.0/24 gw Y.Y.Y.Z dev ppp0
                 echo "Todo listo"
 fi

Ahora solo tenéis que configurar el cron para que ejecute el script cada minuto y así os aseguráis que nunca estaréis sin conexión.

Esto es todo amigos!!!

Fetchmail error: server certificate verification error self signed certificate

¿Cual era mi problema?

Uso fetchmail para descargar el correo de mis servidores externos a mi servidor Zimbra de esta forma tengo almacenado el local el correo de los distintos dominios y no dependo de terceros para que los buzones tengan un tamaño limitado (jeje si le digo al CEO que no puede tener un buzón de 30GB le da algo…).

La cuestión es que como muchos proveedores de servicios de correo tienen sus servidores con seguridad SSL pero con certificados autogererados y esto al fecthcmail no le hace mucha gracia. Te llena los los de correo con el siguiente mensaje:

fetchmail[1283]: Server certificate verification error: self signed certificate
fetchmail[1283]: Missing trust anchor certificate: /C=CH/L=Schaffhausen/O=Plesk/CN=Plesk/emailAddress=info@plesk.com fetchmail[1283]: This could mean that the root CA’s signing certificate is not in the trusted CA certificate location, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of –sslcertpath and –sslcertfile in the manual page.

Esto no molesta mucho si tienes pocas cuentas pero si tienes 100 pues ya empieza a ser un poco tocadura de narices….

La receta de hoy: Como resolver el error de certificado autofirmado en fechtmail

Ingredientes.

    1. Una consola conectada a nuestra maquina Linux.
    2. Un servidor con fecthmail funcionando.

Preparación.

Lo primero que tenemos que hacer es crear un directorio oculto  , por ejemplo en la carpeta root:

mkdir ~/.fetchmail/altic
cd ~/.fetchmail/altic

ahora obtenemos el certificado del servidor autofirmado:

echo | openssl s_client -connect mail.al-tic.com:993 -showcerts 2>/dev/null |sed -ne '/BEGIN CERT/,/END CERT/p' > mail.al-tic.com.pem

Ahora obtenemos el certificado raíz del servidor y extraemos el emisor:

echo | openssl s_client -connect mail.al-tic.com:993 -showcerts 2>/dev/null | sed -ne '/issuer=/p'

verificamos los certificados:

c_rehash /root/.fetchmail/altic

Se generaran dos ficheros de verificación que se guardan en la carpeta altic

Modificamos el fichero de configuración de fechmail /etc/fechmailrc  y añadimos las siguientes lineas en la opciones del poll

sslcertck
sslcertpath "/root/.fetchmail/altic"

Quedando algo parecido a esto

poll mail.al-tic.com
proto IMAP
user "aalvarez" password "recetillas"
sslcertck
sslcertpath ~/.fetchmail/altic

reiniciamos fechmail y problema resuelto

Esto es todo amigos!!!

Configurar los dns en Ubuntu server 16.04

¿Cual era mi problema?

Uno ya lleva sus años en esto de la informática y en el tema del software libre  y ya tenemos nuestras costumbres a la hora de hacer nuestras configuraciones. Siempre que hay un cambio pues nos cuesta un poco adaptarnos. La cuestión estaba instalando un servidor con Ubuntu 16.04 por supuesto sin entorno gráfico y por tanto sin network-manager, configuro la red como siempre modificando los ficheros interfaces y resolvf.conf. Acabo de  configurarlo todo, reinicio el servidor y ¡¡oh sorpresa!! estoy sin internet. Viendo que podría estar pasando veo que no funcionan los dns.  Resulta que el fichero resolvf.conf se sobreescribe con cada reinicio. Pues ala nos toca investigar como evitar esto….porque con versiones anteriores de Ubuntu no pasaba.

La receta de hoy: Como configurar los dns en un ubuntu server 16.04

Ingredientes.

    1. Una consola conectada a nuestra maquina Linux.
    2. Un servidor Ubuntu 16.04 sin entorno gráfico.

Preparación.

Bueno pues resulta que que en Ubuntu 16.04 en adelante la configuración de los dns en instalaciones sin entorno gráfico (por tanto sin network-manager) se realiza en la carpeta /etc/resolvconf. Me preguntaréis ¿por qué? pues ni idea y no voy a perder el tiempo en saberlo….

Dentro de esa carpeta  hay otras cuatro:

-rw-r--r--   1 root root   511 Jun  3  2015 interface-order
drwxr-xr-x   2 root root  4096 Mar 21 22:59 resolv.conf.d/
drwxr-xr-x   2 root root  4096 Mar 21 22:59 update.d/
drwxr-xr-x   2 root root  4096 Jun 20  2017 update-libc.d/

La que nos interesa es resolv.conf.d entramos y nos encontramos con dos ficheros:

-rw-r--r-- 1 root root    0 Jun  3  2015 base
-rw-r--r-- 1 root root  151 Jun  3  2015 head

podríamos editar cualquiera de los dos pero yo me decanté por head porque parece ser que hay varias aplicaciones que leen este fichero y no el base (o eso dicen por los foros…..). Editamos nuestro fichero y añadimos las lineas para configurar los servidores dns:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

nameserver 1.1.1.1
nameserver 1.0.0.1
nameserver 8.8.8.8

los dos primeros servidores dns se autodenominan los más rápidos del mundo y el tercero es del Google, que lo pongo por si acaso.

Guardamos nuestro fichero, y ahora nos toca actualizar el fichero resolvf.conf para cargar los nuevos servidores. Esto lo hacemos con el comando

resovlconf -u

Listo ya tenemos nuestros servidores configurados antireinicios y según los del 1.1.1.1 navegando a toda pastilla.

Esto es todo amigos!!!