Acceso Privado a Internet con OpenVPN (I)

Hacía tiempo que no escribía nada nuevo fundamentalmente porque estoy empleando otros medios para documentar las ñapas que voy haciendo. Sin embargo, me parece interesante compartir la experiencia que acabo de completar así que voy a hacer una serie de posts sobre ello.

La idea que me rondaba la cabeza era cómo configurar una salida más privada a Internet. La solución era, por supuesto, emplear una Red Privada Virtual (VPN). Teniendo esto en cuenta se me planteaban dos opciones:

• Contratar un servicio VPN.
• Contratar un servidor virtual privado (VPS) y montar yo la VPN.

Teniendo en cuenta los antecedentes, me decidí por la segunda opción. Para montarla contraté un VPS con DigitalOcean. Me consta que hay otras opciones y, probablemente, mejores pero no quería darle más vueltas. Las características del servidor contratado son:

• Memoria RAM: 1 GB
• Número de procesadores/cores: 1/1
• Disco: 25 GB

Para los propósitos de la descripción que voy a hacer, asumimos que la dirección IP pública del servidor es: 125.125.125.125 y que el gateway por defecto 125.125.125.1.

El sistema operativo configurado es Ubuntu 18.04 LTS que es una distribución con la que me siento bastante cómodo.

En el lado de mi casa, creé, en el entorno virtual ESXi, una red para pruebas (TEST1) con un rango de direccionamiento 10.2.1.0/24 y configuré un gateway empleando una máquina virtual con VyOS con dos interfaces de red:

• Una conectada a la red de estaciones de trabajo del entorno ESXi con dirección IP: 10.1.3.64.
• Otra conectada a la red TEST1 con dirección IP: 10.2.1.1

Cree una máquina virtual con sistema operativo Lubuntu en la red TEST1 y le asigné la dirección IP: 10.2.1.2 para poder hacer las pruebas de conectividad.

Realicé la configuración del gateway para tener salida a Internet y que desde los clientes de la red TEST1 se tuviera acceso a las distintas redes domésticas y del entorno virtual. El esquema general de conexión queda de la siguiente forma:

Con este esquema, el camino que sigue un paquete IP que viaje desde el cliente del entorno de prueba hasta internet sería:

1. El paquete sale del cliente
2. El paquete llega al gateway de la red TEST1 que lo encamina al gateway del entorno virtual.
3. El gateway del entorno virtual encamina el paquete al router doméstico que conecta con el ISP haciendo un primer NAT de origen.
4. El router de conexión con el ISP encamina el paquete hacia hacia el ISP haciendo un segundo NAT.
5. El ISP encamina el paquete a su destino haciendo algunos NAT más.

El camino de vuelta de la respuesta es similar.

La idea es crear una VPN basada en tecnología OpenVPN que permita:

• Conectar clientes, por ejemplo teléfonos móviles, para una navegación segura por internet cuando estos estén conectados a redes inseguras (por ejemplo WiFis de hoteles).
• Establecer un túnel VPN entre el gateway de la red TEST1 y el servidor VPS que permita la salida privada a internet de las máquinas de la red TEST1.

Voy a empezar por esta última configuración. El esquema final de la red sería algo parecido a esto:

El direccionamiento de la VPN va a ser  172.17.17.0/24. El servidor VPS, que va a enrutar el tráfico de la VPN hacia internet tendrá la dirección 172.17.17.1 y el gateway de la red TEST1 tendrá la dirección  172.17.17.2. El resto de los clientes (vg. teléfonos móviles) recibirán direcciones dinámicamente.

La autenticación de los clientes se va a llevar a cabo mediante certificados emitidos por una CA privada, basada en OpenSSL.

En los siguientes posts iré describiendo cómo configurar los distintos elementos.

Sincronizando Tiempos

Una de las cosas que faltaba en el entorno lab era una fuente de tiempo que permitiera mantener sincronizados los relojes de los distintos servidores. Disponer de una fuente de tiempo para la sincronización permite, entre otras cosas, una correlación precisa de los eventos y logs de la red.

La idea es, por lo tanto, desplegar un servidor NTP en la red del lab. El primer problema que me planteo es dónde conectar el servidor. Como lo que pretendo es que de servicio, no sólo a los servidores virtuales, sino a otras máquinas de la red incluso a los servidores de la red doméstica, no queda otra alternativa que colocarlo en la DMZ del entorno virtual.

Voy a crear, por lo tanto, un servidor virtual Ubuntu con dos interfaces de red, una hacia la DMZ y otra hacia la red de gestión. El servidor va a ser necesariamente pequeño (1 GB de RAM y 10 GB de disco). Una vez creado y realizada la configuración básica del servidor de acuerdo a los estándares de mi red procedo a instalar el servidor NTP que, en este caso, va a ser ntpd.

Conectándome como administrador, procedo a instalar el servidor ntp:

$ sudo apt-get update 
$ sudo apt-get install ntp ntpdate 

Una vez instalado, el servidor arranca y se pone a la escucha en el puerto 123 UDP:

$ netstat -atun
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp6       0      0 :::22                   :::*                    LISTEN
udp        0      0 192.168.199.20:123      0.0.0.0:*
udp        0      0 10.1.4.16:123           0.0.0.0:*
udp        0      0 127.0.0.1:123           0.0.0.0:*
udp        0      0 0.0.0.0:123             0.0.0.0:*
udp6       0      0 fe80::20c:29ff:feb7:123 :::*
udp6       0      0 fe80::20c:29ff:feb7:123 :::*
udp6       0      0 ::1:123                 :::*
udp6       0      0 :::123                  :::*

A continuación, es necesario configurar el servidor. Mi servidor NTP va a sincronizarse con los servidores del proyecto NTP Pool así que lo que tengo que hacer es editar el fichero /etc/ntp.conf añadiendo las líneas necesarias para conectarme al pool europeo de servidores. Además, por si acaso, añado los servidores del pool de Ubuntu y el propio servidor NTP para el caso de que no tenga una conexión a Internet:

Una vez salvados los cambios, rearrancamos el servicio ntp y verificamos que el servidor se sincroniza con las fuentes establecidas:

Verificamos el estado de sincronización:

Por último, lo que necesito hacer es que los servidores de la red sincronicen los relojes hardware con el servidor NTP que acabo de desplegar. En los servidores Ubuntu, el proceso es el siguiente:

1. Verifico que el reloj de los servidores se sincronice a través de la red:

2. Si al ejecutar este comando, el resultado es que Network time on está a no o NTP synchronization está a no lo que hay que hacer es ejecutar el comando siguiente:

$ sudo timedatectl set-ntp true

3. Comprobar a qué servidor de tiempos se conecta el equipo:

4. Si el servidor de tiempos al que se conecta no es el de nuestra red (como en el caso anterior), es necesario configurarlo correctamente. Para ello seguimos los siguientes pasos:

4.1. Editamos el fichero /etc/systemd/timesync.conf y establecemos el nombre de nuestro servidor NTP de la siguiente forma:

4.2. Rearrancamos el servicio systemd-timesyncd y, una vez que arranca, el servidor de tiempos debería ser el nuestro.

Un servidor para logs

Los logs proporcionan información sobre el estado del sistema, centralizando los logs en único servidor me va a permitir tener un punto de supervisión único del estado de salud de mi lab.

El estándar para la recogida de logs es syslog y, por lo tanto, lo que voy a hacer es configurar un servidor Ubuntu, conectado a la red de gestión para la recolección de logs mediante el protocolo syslog. Inicialmente voy a dotar al servidor de 1GB de RAM y 10GB de disco.

El primer paso es, por lo tanto, crear la máquina virtual:

Lo que quiero conseguir es que el directorio /var/log aparezca un fichero de log para cada uno de los servidores con la dirección IP del servidor. El servicio syslog está implementado a través del programa rsyslog y su fichero de configuración es, naturalmente, rsyslog.conf. Edito, por lo tanto este fichero:

add@ubsyslog:~$ sudo vi /etc/rsyslog.conf

Para centralizar los logs en el servidor vamos a permitir que el servidor de logs escuche en los puertos TCP y UDP estándar. Para ello eliminamos los comentarios (borramos el ‘#’ al comienzo de la línea) de las líneas del fichero de configuración que configuran los puertos de escucha y que son las siguientes:

#$ModLoad imudp
#$UDPServerRun 514
#$ModLoad imtcp
#$InputTCPServerRun 514

El siguiente paso es definir una plantilla para los ficheros de log a los que se van a dirigir los logs recibidos en el servidor. Como ya comenté, la idea es que los ficheros de log de cada servidor se identifiquen por la dirección IP del servidor.

Para conseguir esto, añadimos las siguientes líneas al fichero de configuración antes de la sección de directivas globales.

$template ServerLogs,"/var/log/%FROMHOST-IP%/%PROGRAMNAME%.log"
*.*  ?ServerLogs
& ~

Como las cosas en Linux no son siempre intuitivas voy a explicar un poco que es lo que significa cada una de las líneas:

• La primera línea le dice a rsyslog que la plantilla, de nombre ‘ServerLogs’, escribe en ficheros de log en subdirectorios, cuyo nombre es la dirección IP del equipo bajo el directorio /var/log. El nombre de esos ficheros de log es el nombre del programa que genera el mensaje y la extensión ‘.log’.
• La segunda línea le dice a rsyslog que aplique la plantilla ServerLogs a todos los mensajes de log recibidos (de ahí el *.*).
• Por último, la tercera línea, es una regla de redirección que le dice a rsyslog que una vez procesados los mensajes por la regla ServerLogs detenga el proceso posterior de los mensajes. Sin esta regla los mensajes se recogerían dos veces.

El fichero de configuración quedaría:

Por último, reiniciamos el servicio rsyslog y comprobamos que el servicio escucha en los puertos correspondientes mediante el comando netstat:

add@ubsyslog:~$ sudo service rsyslog restart
add@ubsyslog:~$ sudo netstat -tulpn | grep rsyslog

El comando produce una salida como:

Ahora vamos a configurar los clientes de syslog, en este caso, el router VyOS para que envíe la información de log para todas las facilities de nivel notice o superior a nuestro servidor syslog.

En el servidor syslog vemos que se han creado directorios con la dirección IP de localhost y del router y que éstos contienen los ficheros de log.

Caso cerrado, por ahora. El siguiente paso va a ser el configurar un Nagios para la gestión de los equipos en la red.