Inicio » Blog » ¿ Cómo crear una VPN con OpenVPN y routers Teltonika ? (II)

¿ Cómo crear una VPN con OpenVPN y routers Teltonika ? (II)

Generación de certificados TLS

El primer paso que debemos hacer antes de configurar nuestros routers servidor y clientes es generar todos los certificados y claves necesarias para poder encriptar y autenticar los extremos de la VPN.

La forma más sencilla de generar estos certificados y claves es a través del software OpenVPN para Windows o Linux.

En la página https://wiki.teltonika-networks.com/view/How_to_generate_TLS_certificates_(Windows)%3F de la wiki de Teltonika tenemos el proceso para instalación del software bajo SO Windows y la generación de los certificados. En cualquier caso destacamos los siguientes puntos:

El fichero vars.bat contiene algunos parámetros que luego se usarán por defecto en la generación de los certificados. Debemos ajustarlos a nosotros para poder así personalizarlos y poderlos asociar al uso que vayamos a hacer de ellos.

Certificate Authority (CA): es el certificado raíz que se usa para firmar el resto de los certificados y claves. Posteriormente deberemos cargarlo tanto en el router servidor como en los routers clientes.

A continuación, generaremos el certificado del router servidor con el comando build-key-server y los certificados de los routers clientes con el comandos build-key. Para cada certificado que creamos se crean dos ficheros: nombre_certificado.crt y nombre_certificado.key donde nombre_certificado es el nombre que le hemos dado al certificado como parámetro del comando de generación (no es importante, aunque sí recomendable usar un nombre identificativo).

En la generación de certificados debemos tener en cuenta los dos siguientes puntos:

En los certificados de clientes hay un parámetro llamado CN=Common Name. Este parámetro es de vital importancia ya que es el que le permite al servidor asociar la petición al cliente VPN en concreto. Por ello, deberemos modificar el valor que nos proponer por defecto el comando de generación del certificado y cambiarlo por un nombre único en toda la VPN y a ser posible identificativo (lugar, instalación, código,…). Cuando en el router servidor demos de alta al cliente TLS deberemos usar este mismo parámetro usando idéntico texto.

En segundo lugar, debemos tener en cuenta que el proceso de generación de certificados que se explica en el link adjunto es un proceso desde cero. Cada vez que repetimos este proceso creamos un CA.crt y un CA.key diferentes y en base a ellos generamos después el resto de los certificados. Si a posteriori necesitamos añadir algún certificado cliente, no debemos repetir todos los pasos ni generar el certificado CA de nuevo ya que éste sería diferente y nuestro certificado cliente, por tanto, no correspondería con los anteriores. En este caso, debemos saltarnos todos los pasos iniciales y únicamente generar el certificado cliente mediante el comando build-key.

Siendo prácticos, puede resultar difícil recordar si en algún momento hemos generado otra CA y otros certificados en cuyo caso ya no podríamos generar un nuevo certificado cliente para una VPN anterior. Por ello recomendamos generar certificados cliente en exceso, aunque sea nombrándolos de forma genérica como client100, client101, … y guardarlos junto con el resto de las claves y certificados en un directorio aparte del propio de la instalación de OpenVPN. En este caso tendremos siempre la seguridad de que los ficheros contenidos en ese directorio representan un grupo válido de claves y certificados.

Configuración de una VPN TAP

Configuración del router servidor

En primer lugar, configuraremos el router servidor. Para ello iremos al menú VPN – OpenVPN y crearemos una nueva instancia de servidor OpenVPN. El nombre que le demos no es importante.

NOTA: aunque teóricamente es posible tener creadas (aunque sólo una activa) varias instancias de servidor OpenVPN recomendamos borrar las que no usemos y dejar sólo la válida. En ocasiones, el router puede mezclar certificados entre varias instancias y por ello recomendamos sólo tener una instancia activa con unos certificados cargados.

Una vez creado pincharemos sobre Edit para configurar el servidor.

Certificados a cargar en el servidor VPN

Por defecto el servidor está en modo TUN. Lo cambiaremos a TAP. Podemos dejar por defecto el resto de los parámetros de configuración (puerto a 1194, protocolo UDP/TCP y compresión LZO). En todo caso tengamos en cuenta que deben coincidir entre servidor y clientes.

A continuación, deberemos cargar los certificados (ca.crt, server.crt, server.key, dh2048.pem) (suponemos que el certificado servidor lo hemos creado con el nombre server).

Finalmente pincharemos sobre el botón Save para guardar los cambios.

NOTA: en VPN de tipo TAP NO debemos añadir los clientes TLS manualmente.

Configuración del router cliente

Como en el caso del servidor iremos al menú VPN – OpenVPN y también como en el caso anterior no recomendamos tener más de una instancia de cliente. Una vez creado pincharemos en Edit para configurarlo.

Cambiaremos el modo de TUN a TAP y verificaremos que el resto de los parámetros coincide con los del servidor VPN.

Certificados a cargar en el router cliente

Finalmente cargaremos los certificados (ca.crt (el mismo que en el servidor), client.crt y client.key). Al final pincharemos en Save para guardar los cambios.

Verificación de la VPN

Podemos verificar si el router cliente se ha conectado al router servidor VPN y se ha establecido en túnel VPN a través del menú Status – Network – OpenVPN.

Status – Network – OpenVPN

En esta pantalla podemos ver un listado de los clientes conectados con su CN (Common Name), la IP púbica desde la que se conecta, la dirección MAC virtual del cliente en la VPN  y el instante de la conexión.

Lógicamente, la mejor verificación de la VPN es conectar un PC detrás del servidor VPN y poder hacer ping y acceder a todos los routers cliente VPN y a cualquier equipo conectado a la LAN de ellos.

Troubleshooting

En caso de que no se establezca la VPN deberemos:

  • Verificar que la dirección IP pública del router servidor es accesible y que tenemos redireccionado el puerto TCP/UDP 1194 en el router ADSL/FTTH a la IP WAN de nuestro router servidor
  • Verificar que los parámetros de puerto, protocolo, compresión, encriptación, … son idénticos en el router servidor y en los clientes
  • Verificar que tanto router servidor como cliente tienen la fecha correcta (por defecto la obtienen de servidores NTP en Internet)

Finalmente, también podemos verificar el log del router en System – Administration – Troubleshoot – System Log

Mon Mar 25 15:30:49 2019 daemon.notice openvpn(7365727665725F53657276657232)[17144]: client32/95.131.170.224 peer info: IV_VER=2.4.4

Mon Mar 25 15:30:49 2019 daemon.notice openvpn(7365727665725F53657276657232)[17144]: client32/95.131.170.224 peer info: IV_PLAT=linux

Mon Mar 25 15:30:49 2019 daemon.notice openvpn(7365727665725F53657276657232)[17144]: client32/95.131.170.224 peer info: IV_PROTO=2

Mon Mar 25 15:30:49 2019 daemon.notice openvpn(7365727665725F53657276657232)[17144]: client32/95.131.170.224 peer info: IV_LZ4=1

Mon Mar 25 15:30:49 2019 daemon.notice openvpn(7365727665725F53657276657232)[17144]: client32/95.131.170.224 peer info: IV_LZ4v2=1

Mon Mar 25 15:30:49 2019 daemon.notice openvpn(7365727665725F53657276657232)[17144]: client32/95.131.170.224 peer info: IV_LZO=1

Mon Mar 25 15:30:49 2019 daemon.notice openvpn(7365727665725F53657276657232)[17144]: client32/95.131.170.224 peer info: IV_COMP_STUB=1

Mon Mar 25 15:30:49 2019 daemon.notice openvpn(7365727665725F53657276657232)[17144]: client32/95.131.170.224 peer info: IV_COMP_STUBv2=1

Mon Mar 25 15:30:49 2019 daemon.notice openvpn(7365727665725F53657276657232)[17144]: client32/95.131.170.224 peer info: IV_TCPNL=1

Mon Mar 25 15:30:49 2019 daemon.notice openvpn(7365727665725F53657276657232)[17144]: client32/95.131.170.224 Outgoing Data Channel: Cipher ‘AES-256-CBC’ initialized with 256 bit key

Mon Mar 25 15:30:49 2019 daemon.notice openvpn(7365727665725F53657276657232)[17144]: client32/95.131.170.224 Outgoing Data Channel: Using 160 bit message hash ‘SHA1’ for HMAC authentication

Mon Mar 25 15:30:49 2019 daemon.notice openvpn(7365727665725F53657276657232)[17144]: client32/95.131.170.224 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 4096 bit RSA

En los registros openvpn podemos localizar los posibles errores en la negociación entre servidor y cliente.

Post anterior: ¿ Cómo crear una VPN con OpenVPN y routers Teltonika (I) ?

1 estrella2 estrellas3 estrellas4 estrellas5 estrellas (2 votos, promedio: 5,00 de 5)
Cargando...