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!!!

Test de velocidad desde la consola de Linux

¿Cual era mi problema?

En uno de mis clientes tengo montada una red wifi con equipamiento ubiquiti y necesitaba saber si el acceso a internet iba mal pero no podía conectarme a ningún equipo para realizar un test de velocidad. Estos puntos de acceso funcionan con Linux , por tanto se puede acceder a ellos por ssh y realizar un test de velocidad desde su terminal.

La receta de hoy: Como realizar un test de velocidad de internet desde la consola de Linux

Ingredientes

  • 1 Un equipo con linux.
  • 2 Un acceso a internet

Preparación

Podemos hacer el test de velocidad en un terminal de linux de dos formas, mediante el comando wget y el comando curl. ¿Porque de dos formas? pues porque en algunos equipos como son los AP de Ubiquiti no está instalado el comando wget pero si el cual. Curl también se puede usar en en equipos con MacOS. Queda a gusto de consumidor usar uno u otro.

Test de velocidad con curl

Para realizar este test de velocidad nos vamos a escribir el siguiente comando:

curl -o /dev/null http://speedtest.wdc01.softlayer.com/downloads/test10.zip

Esto lo que hace es descarte el fichero test10.zip que pesa 10MB y calcular la velocidad de descarga en Bytes por segundo (recordar hay que multiplicar por 8 para tener bits por segundo que es la unidad con la que se nos indica la velocidad por lo operadores)

test de velocidad con curl

En la esquina de la derecha se muestra la velocidad de descarga que en este caso es de 2,34MBps. Si 10MB os parece poco para un test solo tenéis que cambiar en test10.zip por test100.zip para hacer un test de 100MB y si cambias el 10 por 1000 te descargas un fichero de un TB. Cuanto más larga es la descarga más fiable es.

Test de velocidad con wget

Para realizar esta prueba de velocidad con wget es lo mismo que con curl pero poniendo la O en mayusculas:

wget -O /dev/null http://speedtest.wdc01.softlayer.com/downloads/test100.zip

obteniendo el siguiente resultado:

test de velocidad con wget

En este caso caso obtenemos una velocidad de 18MBbs.

Listo ya podemos medir la velocidad de nuestra conexión de un terminal. Deciros que los ficheros que nos descargamos no se guardan en el equipo por lo que no tenéis que preocuparos de borrarlos.

Me voy a por un café, que me lo he ganado.

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!!!

Activar o desactivar servicios en Linux

¿Cual era mi problema?

En muchas ocasiones he necesitado poder activar que un servicio en Linux se active automáticamente al arrancar el equipo. Normalmente al instalar un servicio,  por ejemplo un servidor web (apache, nginx, etc…), este se instala para que arranque al reiniciarse la máquina pero puede que esto no sea interesante en un momento dado y querramos desactivarlo.

Vamos a ver como hacemos esto para las distintas distribuciones de Linux.

La receta de hoy: Como activar o desactivar servicios en Linux.

Ingredientes.

    1. Una consola conectada a nuestra maquina Linux.
    2. Un servicio instalado por ejemplo SSH.

Preparación.

Activación de servicios en CentOS, Red Hat o Suse

Para estas distribuciones la herramienta que gestiona los servicios es chkconfig la cual permite activarlos y desactivarlos.

Si quiséramos ver el listado de servicios instalados y en que nivel del arranque se activan podemos verlos con

# chkconfig –list

obtendríamos algo como esto

# chkconfig –list
atd                                0:off     1:off    2:off    3:on    4:on     5:on   6:off
attach-static-vdis 0:off     1:off    2:on     3:on    4:on     5:on   6:off
crond                           0:off     1:off    2:on     3:on    4:on     5:on   6:off
dhcpd                          0:off     1:off    2:off    3:off   4:off     5:off  6:off
dhcrelay                     0:off     1:off    2:off    3:off   4:off     5:off   6:off

Vemos los servicios instalados y en que nivel del arranque se activan. Para activar nuestro servicio SSH solamente tendríamos que escribir:

# chkconfig ssh on

Si lo queremos desactivar

# chkconfig ssh off

y si queremos indicarle el nivel en el que queremos que arranque, por ejemplo el 5:

# chkconfig –level 5 ssh on

Chupao ¿verdad?

Activación de servicios en Debian, Ubuntu y derivados.

En estas distribuciones la herramienta update-rc.d es la  encargada de hacer la activación o desactivación.

Para iniciar automáticamente el servicio ssh se debe ejecutar el comando:

# update-rc.d ssh defaults

Si queremos indicarle el nivel en el que queremos que arranque en nuestro caso el 5:

# update-rc.d  ssh  start 5

Para descativar el servicio ejecutamos:

# update-rc.d ssh remove

Sencillo, hasta la próxima entrada

Añadir rutas estáticas en Linux, Windows o MacOS

¿Cual era mi problema?

A veces es necesario agregar rutas estáticas para que tu equipo llegue a una subred que es distinta de la tuya, por ejemplo si estás usando un vpn y esta no la establece el router sino otro equipo de tu red. Pues para poder acceder a esa otra red es necesario indicarle a tu equipo por donde tiene que ir de paseo para acceder a esa nueva red con una ruta estática.

En este caso no voy a ser racista y os mostraré como hacerlo en Windows, MacOS y Linux.

La receta de hoy: Como añadir una ruta estática en Linux, Windows o MacOS.

Ingredientes.

    1. Dos subredes por ejemplo la subred 1 con rango 10.1.0.0/24 y la subred 10.2.0.0/24 conectadas por un equipo con IP 10.1.0.1 y 10.2.0.1
    2. Un equipo que se quiere con IP 10.1.0.200 que se quiere conectar a un equipo de la sured 2. Con una consola (CMD en windows, terminal en linux y Macos)

Preparación.

Añadir rutas estáticas en LINUX

El comando es el  siguiente:

route add -net 10.2.0.0/24 gw 10.1.0.1  dev eht0

la explicación es muy sencilla, le estamos diciendo a nuestro equipo que para ir a la subred 2 (10.2.0.0) de paseo tiene que preguntarle al equipo 10.1.0.1 por donde se va. El 10.1.0.1 como ya se sabe el  camino le dice que ya se encarga el de llevarle.

Si quereis hacer esta ruta estática permanente tenéis que agregar en el fichero /etc/networks/interfaces la siguiente línea debajo de la interfaz que corresponda:

up route add -net 10.2.0.0/24 gw 10.1.0.1  dev eht0

De esta forma cada vez que se reinicie la máquina la ruta quedará guardada.

Si quereis ver la ruta solo tenéis que escribir:

route

y tendréis algo parecido a esto

Kernel IP routing table
Destination    Gateway     Genmask               Flags    Metric    Ref   Use   Iface
default              10.1.0.254  0.0.0.0                   UG          0              0        0       xapi0
10.2.0.0           10.1.0.1         255.255.255.0  U              1              0        0       xapi0

Donde la primera linea nos indica que para salir a Internet nuestro equipo le tiene que preguntar al router (10.1.0.254) y para ir a las subred 2 (10.2.0.0) le tiene que preguntar al 10.1.0.1.

Añadir rutas estáticas en WINDOWS

El comando es el siguiente:

route add -p 10.2.0.0 mask 255.255.255.0 10.1.0.1 metric 1

Para consultar la tabla de rutas hay que escribir en un terminal (CMD)

route print

Para agregar la ruta estática en Windows de forma persistente hay que escribir

route /p add -p 10.2.0.0 mask 255.255.255.0 10.1.0.1 metric 1

Añadir rutas estáticas en MacOS

El comando sería:

route -vn add 10.2.0.0/24 10.1.0.1

en un Mac para consultar las rutas de nuestro equipo tenemos que escribir:

netstat -rn

Para que la ruta estática que de guardada permanentemente se tiene que escribir:

sudo networksetup -setadditionalroutes LAN  10.2.0.0 255.255.255.0 10.1.0.1

donde LAN es el nombre de la interfaz de red de nuestro MAC sin está formada por dos palabras tiene que ir entre comillas «Ethernet 1».

Como podéis ver cada sistema lo hace de forma distinta por lo que creo que era interesante agruparlos todos en una sola entrada para tener la receta completa.

Mis comandos habituales en linux

¿Cuales son los comandos que utilizo en la consola de Linux?

En esta entrada os voy a ir mostrando cuales son los comando más habituales que utilizo en mi día a día y que se salen un poco del típicos que se ven en otros sitios: cd, ls, etc…

PV

Este comando te permite copiar un fichero pero mostrándote el el tiempo y la velocidad de transferencia. Es muy útil cuando transfieres archivos grandes que no sabes cuanto van a tardar.

ejemplo de uso

pv fichero > /ubicacion/fichero

$ pv 20081021020204507 > /home/20081021020204507
  11MB 0:00:05 [1.89MB/s] [>              ]  0% ETA 1:29:21

Como podéis ver al principio te indica cuanto tiempo lleva y cuanto datos ha transferido y al final te indica el tiempo que le queda. A mi me resulta muy útil para saber cuando me tengo que ir a por un café.

LL

Este comando es un alias de ls -alF (al menos en Ubuntu) lo que hace es un listado del contenido de un directorio pero en mostrándolo en columna con los permisos el tamaño y quienes son los propietarios. Si le añadimos -h nos saca el tamaño del fichero en modo humano, es decir mostrando si son K,M,G

ejemplo de uso

ll -h

root@cloudserver:/# ll -h
total 104K
drwxr-xr-x  24 root root 4.0K Jan 23 09:14 ./
drwxr-xr-x  24 root root 4.0K Jan 23 09:14 ../
drwxr-xr-x   3 root root 4.0K Feb 14  2017 .ansible/
drwxr-xr-x   2 root root  12K Feb  6 06:13 bin/
drwxr-xr-x   3 root root 4.0K Feb 15 06:56 boot/
drwxr-xr-x  18 root root 3.9K Jan 23 09:14 dev/
drwxr-xr-x 113 root root 4.0K Feb  6 06:13 etc/
drwxr-xr-x   2 root root 4.0K May  2  2016 home/
drwxr-xr-x  20 root root 4.0K Dec 17 11:45 lib/
drwxr-xr-x   2 root root 4.0K Jan 18 06:14 lib64/
drwx------   2 root root  16K May  2  2016 lost+found/
drwxr-xr-x   3 root root 4.0K May  2  2016 media/
drwxr-xr-x   3 root root 4.0K Jun 28  2017 mnt/
drwxr-xr-x   2 root root 4.0K Apr 21  2016 opt/
dr-xr-xr-x 106 root root    0 Jan 23 09:14 proc/
drwx------   6 root root 4.0K Feb 14 10:38 root/
drwxr-xr-x  26 root root  980 Feb 20 10:27 run/
drwxr-xr-x   2 root root  12K Feb  6 06:13 sbin/
drwxr-xr-x   3 root root 4.0K Feb 14  2017 srv/
drwxr-xr-x   2 root root 4.0K May  2  2016 swap/
dr-xr-xr-x  13 root root    0 Feb 20 10:27 sys/
drwxrwxrwt   8 root root  160 Feb 20 10:40 tmp/
drwxr-xr-x  10 root root 4.0K May  2  2016 usr/
drwxr-xr-x  13 root root 4.0K Aug  1  2017 var/

Muy cómodo para ver permisos y tamaños de ficheros y directorios.

CP -P

Con el comando cp podemos copiar cualquier archivo o directorio en linux. Pero usando el modificador -p nos permite copiar todos los permisos del archivo, lo cual es muy útil si estás trabajando como root pero quieres copiar un fichero del servidor web que tiene que tener permisos para el usuario www-data

ejemplo de uso

cp -p archivo.php /www/web

Resolver el error:0B080074:x509 en Zimbra

¿Cual era mi problema?

Actualizando un servidor de correo Zimbra (una fantástica plataforma de correo, que por ahora solo me había dado alegrías) para un cliente, me apareció el siguiente error:

Failed to start slapd. Attempting debug start to determine error.
TLS: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch x509_cmp.c:340
57967c82 main: TLS init def ctx failed: -1
failed with exit code: 256.
UPGRADE FAILED – exiting.

Ohh pánico, terror, sudores fríos……y todo esto a las 2 de la mañana…Bueno resulta que googleleando un poco encontré la solución. Resulta que casualmente concidió que los certificados del servidor había caducado y era necesario renovarlo. Vamos a ver como hacerlo.

La receta de hoy: Resolver el error: 0B080074:x509 en Zimbra.

Ingredientes.

    1. Servidor Zimbra
    2. Acceso a consola bien por terminal bien por ssh

Preparación.

Lo primero que tenemos que hacer es acceder con el usuario Zimbra, para ellos escribimos:

sudo su -zimbra

nos situamos en el directorio de ejecutables del zimbra:

cd /opt/zimbra/bin/

y ahora lo ejecutamos lo bueno…. Creamos una nueva clave:

zmcertmgr createca -new -newkey

Creamos el nuevo certificado de 1 año, o de lo que quieras….

zmcertmgr createcrt -new -days 365

Desplegamos el certificado entre los distinto servicios:

zmcertmgr deploycrt self

Desplegamos la autoridad certificadora (ya que es un certificado autofirmado)

zmcertmgr deployca

Por último, le decimos al Zimbra que acepte los certificados autogenerados

$ zmlocalconfig -e ssl_allow_untrusted_certs=true

Y voila nuestros servicios de zimbra volverán a funcionar como el primer día. Espero que os sirva.

Configurar un cliente openvpn en centOS

¿Cual era mi problema?

Uno de mis clientes necesita conectar su sistema de gestión con el servidor de la tienda online para sincronizar las bases de datos. Para que esta sincronización no se haga al aire, le monté una vpn usando openvpn que permita que los datos vayan lo más protegidos que sea posible. Hoy vamos a ver como configurar un cliente openvpn en centOS.

La receta de hoy: como configurar un cliente openvpn en centOS.

Yo normalmente trabajo con sistemas Debian pero el servidor web de mi cliente estaba con centOS por lo que he tenido que buscar en varias webs como hacerlo. Vamos a la faena…

Ingredientes.

    1. Servidor cliente con SO centOS
    2. Nuestro servidor openvpn configurado.
    3. Los ficheros de configuración del cliente (son 4): cliente.conf (fichero de configuración del cliente vpn), cacert.pem(certificado de la autoridad), XXXXXXX.pem(clave del cliente) y cliente.pem (certificado del cliente).
    4.  Acceso ssh y SFTP al Servidor cliente.

Preparación.

Lo primero que hay que instalar es el cliente de openvpn, pero resulta que los repositorios de centOS por defecto no tienen el paquete openvpn. Por lo que primero tenemos que instalar los repositorios  Extra Packages for Enterprise Linux (EPEL) en los que viene:

yum install epel-release

Una vez instalado el repositorio pasamos a instalar el paquete openvpn

yum install openvpn

Instalado el cliente openvpn. Vale, pero toca configurarlo ¿no? Pues nada, la cosa mas sencilla del mundo, subimos nuestros ficheros de configuración al servidor y los colocamos en la carpeta:

/etc/openvpn/

Listo! ya tenemos configurado el cliente.

¿Cómo conectar el cliente de openvpn?

Para probar que todo funciona, nos posicionaros en /etc/openvpn/ y ejecutamos:

openvpn –config cliente.conf

Y por arte de magia si nuestros ficheros de configuración están bien tendremos conectado nuestro servidor centOS con el servidor de openvpn.

Ahora me diréis muy bien pero ¿que pasa  si se reincia la máquina?

¿Cómo hacer que openvpn no se desconecte o se conecte automáticamente?.

Vamos automátizar el cliente para que se conectarse automáticamente cada vez que pierda la conexión. Vamos a configurar el cliente de openvpn como un servicio para lo cual escribimos lo siguiente:

systemctl start openvpn@cliente

Problema resuelto, ahora nuestro cliente se arranca automáticamente cada vez que la máquina se encienda.

Realmente es una configuración sencilla para alguien que esté acostumbrado a manejar centOS pero como no es mi caso he tenido que cocinarme esta receta buscando de aquí y de allá como hacerlo.