OpenVPN bajo Debian
- Modo de funcionamiento
OpenVPN posee dos modos de funcionamiento: Enrutado y Puente, a los cuales los conoceremos como modo Routing y modo Ethernet Bridging. Puede entenderse un poco las diferencias entre ambos modos de funcionamiento con la siguiente comparativa:Ventajas del modo Bridging:
• El tráfico broadcast a través de la VPN: esto permite el correcto funcionamiento de software que depende del tráfico broadcast en redes LAN tal como la navegación a través de redes Microsoft conocido comúnmente como network browsing.
• No es necesario configurar reglas de enrutamiento.
• Funciona con cualquier protocolo sobre Ethernet incluyendo IPv4, IPv6, Netware IPX, AppleTalk, etc.
• La configuración de road warriors es relativamente más sencilla.
Desventajas del modo Bridging:
• Menos eficiente que el modo Routing, y no es muy escalable.
Ventajas del modo Routing:
• Eficiencia y escalabilidad.
• Permite mejor afinamiento del MTU para mejorar la eficiencia.
Desventajas del modo Routing:
• Los clientes deben usar un servidor WINS para pemitir la resolución de nombres NetBIOS entre ordenadores que estén a ambos extremos de los túneles VPN.
• Deben configurarse reglas de enrutamiento en cada subred.
• Software que dependa del tráfico broadcast no será capaz de encontrar a los hosts al otro lado de los túneles VPN.
• Funciona solamente con IPv4 en general, e IPv6 en casos donde los drivers TUN en ambos extremos de los túneles soporten dicho protocolo de manera explícita.
Este documento cubre sólo la configuración de OpenVPN en modo Routing, el cual es uno de los modos más comunes para configurar VPNs.Numeración de redes
La IANA ha reservado los siguientes tres bloques de direcciones IP para ser usadas en redes privadas:
10.0.0.0 - 10.255.255.255.0 - Prefijo 10/8
172.16.0.0 - 172.31.255.255 - Prefijo 172.16/12
192.168.0.0 - 192.168.255.255 - Prefijo 192.168/16
- Instalamos el paquete openvpn
- apt-get install openvpn
- Configuración de OpenVPN
Estos pasos son necesarios para configurar OpenVPN en modo Routing en un papel de cliente y servidor, todo bajo una estructura basada en certificados digitales.
Construcción de certificados
El primer paso para construir una configuración de OpenVPN basada en certificados es establecer un PKI (Public Key Infrastructure).
El PKI consiste de:
- Un certificado (conocido también como llave pública) y llave privada separado para cliente y el servidor.
- Un Certificado Autoridad maestro (CA, Certificate Authority) y su respectiva llave privada usada para firmar cada certificado usado por los clientes y el servidor.
- Generación del CA y su llave privada
OpenVPN incluye un directorio de nombre ‘easy-rsa’ dentro del cual procederemos a ejecutar
los pasos que a continuación se explicarán.
Nos dirigimos a la siguiente ruta
# cd /usr/share/doc/openvpn/examples/easy-rsa/
Una vez dentro del directorio “easy-rsa” editamos algunas lineas del archivo de nombre “vars”
# nano vars
… …
… …
export KEY_SIZE=1024
export KEY_COUNTRY=PE
export KEY_PROVINCE=LI
export KEY_CITY=Lima
export KEY_ORG=”Via Network”
export KEY_EMAIL=”jvallejo@vnperu.com”
Si se observa con cuidado el contenido del archivo se puede comprender que se definen variables las cuales deben ser cargadas para ser usadas posteriormente en la construcción del certificado pudiendo tener valores a gusto y criterio del administrador pero recordando que ninguno de ellos debe ser dejado en blanco.
\\ Entonces se procede a cargar las variables del archivo recién editado:# . ./vars \\ # ./clean-all
Para saber que todo se ejecuto correctamente deberíamos poder constatar la existencia de un directorio con el nombre de la variable $KEY_DIR
# echo $KEY_DIR
Ahora es cuando ya se procederá a crear el CA ejecutando el script ‘build-ca’ y nos hará algunas preguntas de las cuales algunas ya tendrán los valores precargados del archivo de configuración ‘vars’ previamente editado y pueden aceptarse como respuesta presionando Enter, y otras opciones aún por rellenar con los valores apropiados como sigue:
# ./build-ca
Generating a 1024 bit RSA private key
…….++++++
..++++++
writing new private key to ‘ca.key’
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [PE]:
State or Province Name (full name) [LI]:
Locality Name (eg, city) [Lima]:
Organization Name (eg, company) [Via Network]:
Organizational Unit Name (eg, section) []:sistemas
Common Name (eg, your name or your server’s hostname) []:www.vnperu.com
Email Address [jvallejo@vnperu.com]:
Luego de esto puede verificarse dentro del directorio $KEY_DIR la existencia de los archivos ‘ca.crt’ (el CA) y ‘ca.key’ (la llave privada del CA).
Hasta este punto ya se ha creado correctamente el CA con su respectiva llave privada la misma que debe ser mantenida en la más absoluta privacidad por razones de seguridad obvias.
- Generación del archivo de parámetros Diffie Hellman
El protocolo Diffie-Hellman permite el intercambio secreto de claves entre dos partes que no han tenido contacto previo, utilizando un canal inseguro, y de manera anónima (no autenticada).
Se emplea generalmente como medio para acordar claves simétricas que serán empleadas para el cifrado de una sesión. Siendo no autenticado, sin embargo provee las bases para varios protocolos autenticados.
Por lo tanto es necesario generar un archivo que contenga los parámetros correspondientes del protocolo desde el mismo directorio de trabajo usado anteriormente para la generación de la CA. Para ello debe ejecutarse el script ‘build-dh’ como sigue:
# ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
…..+………………………………….+…………………….+……………………………….
…………………..+…………………………………………+……………………………….
…………..+……………………+…..+……………………………………………………….
………………………………………………………………….+……………….+………….
…………………………………………………………………..+……..+…..+……………..
…………………………………………………………………………….+…………………
………………………..+…+…….+…………………………………………………………+.
…..+……………………..+…………………………………………………………………..
……………………………………+……….+………………………………………………..
……………………………………..+…+…………………………………………………….
…………….+………………………………………………………………………….+…..+.
…………………………………..+………………..++*++*++*
Si todo ha funcionado correctamente debería haberse creado el archivo ‘dh1024.pem’ (u otro número distinto de 1024 dependiendo del valor de $KEY_SIZE en el archivo ‘vars’.
- Generación del certificado del servidor y su llave privada
Ahora se requiere generar un certificado con su respectiva llave privada para el servidor ejecutando el script ‘build-key-server’ pasándole como parámetro un nombre representativo para el servidor VPN como se aprecia a sigue:
# ./build-key-server vpn-server
Generating a 1024 bit RSA private key
………………………………++++++
.++++++
writing new private key to ‘vpn-server.key’
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [PE]:
State or Province Name (full name) [LI]:
Locality Name (eg, city) [Lima]:
Organization Name (eg, company) [Via Network]:
Organizational Unit Name (eg, section) []:sistemas
Common Name (eg, your name or your server’s hostname) []:vpn-server
Email Address [jvallejo@vnperu.com]:
Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /root/easy-rsa/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject’s Distinguished Name is as follows
countryName :PRINTABLE:’PE’
stateOrProvinceName :PRINTABLE:’LI’
localityName :PRINTABLE:’Lima’
organizationName :PRINTABLE:’Via Network’
organizationalUnitName :PRINTABLE:’sistemas’
commonName :PRINTABLE:’vpn-server’
emailAddress :IA5STRING:’jvallejo@vnperu.com’
Certificate is to be certified until Aug 1822:09:07 2017 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Es indispensable que el valor del Common Name en la creación del certificado sea el mismo que el pasado como parámetro al script. Si todo ha funcionado como debe ser se habrán creado un par de archivos de extensión .crt y .key dentro del directorio $KEY_DIR con el nombre especificado como parámetro al script, resultando en nuestro ejemplo ‘vpn-server.crt’ y ‘vpn-server.key’
'Observaciones
- Hasta este punto ya se ha creado el CA, el certificado del servidor y el archivo de parámetros Diffie Hellman pero debe
considerarse que este proceso debe ser ejecutado solamente una única vez, por ello hay que ser cuidadosos de no ejecutar
nuevamente el script ‘clean-all’ si antes no se ha hecho un respaldo del contenido del directorio $KEY_DIR.'
'- Si se desean generar certificados para los clientes en un futuro hay que considerar que deben cargarse las variables de entorno desde el archivo ‘vars’ usando # . ./vars.'
Creación de certificados de clientes y sus llaves privadas
'La creación de los certificados de clientes puede hacerse en dos pasos de los cuales el primero consiste en crear una solicitud de certificado y la segunda consiste en la firma de dicha solicitud para generar al fin el certificado del cliente.'Para ello debe usarse el script ‘build-req’ ó ‘build-req-pass’. La diferencia de usar uno u otro consiste en que el segundo protegerá la llave privada con una contraseña para mayor seguridad en caso de robo del certificado y su llave. De este modo tendríamos lo siguiente:
# ./build-req-pass cliente0
Generating a 1024 bit RSA private key
……….++++++
…………………………………………………………++++++
writing new private key to ‘cliente0.key’
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [PE]:
State or Province Name (full name) [LI]:
Locality Name (eg, city) [Lima]:
Organization Name (eg, company) [Via Network]:
Organizational Unit Name (eg, section) []:sistemas
Common Name (eg, your name or your server’s hostname) []:cliente0
Email Address [jvallejo@vnperu]:
Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Recordar que también el valor del Common Name debe ser el mismo que se pasó como parámetro al script. Si todo ha funcionado como se espera entonces se debe haber creado un archivo de extensión .key y otro de extensión .csr dentro del directorio $KEY_DIR con el nombre especificado para el cliente, mas no ninguno de extensión .crt todavía.
ahora cuando ya se puede proceder a firmar la solicitud de certificado del cliente ejecutando el script ’sign-req’ pasándole como parámetro el nombre anteriormente dado al cliente.
- ./sign-req cliente0
Using configuration from /root/easy-rsa/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject’s Distinguished Name is as follows
countryName :PRINTABLE:’PE’
stateOrProvinceName :PRINTABLE:’LI’
localityName :PRINTABLE:’Lima’
organizationName :PRINTABLE:’Soporte Linux’
organizationalUnitName :PRINTABLE:’sistemas’
commonName :PRINTABLE:’cliente0′
emailAddress :IA5STRING:’soporte@soportelinux.com.pe’
Certificate is to be certified until Aug 18 22:35:26 2017 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Con esto ya deberíamos ahora sí tener un archivo de extensión .crt con el nombre del cliente dentro del directorio $KEY_DIR. Con esto ya se concluye el proceso de creación de certificados y llaves para los clientes y/o el servidor. A continuación se procederá a entrar ya en detalle de la sintaxis y directivas de los archivos de configuración de OpenVPN.
Configuración en modo servidor
Pasamos a resumir nuestas configuración en un archivo que llamaremos openvpn.conf, a tener en cuenta que OpenVPN por defecto tratará de levantar tantas instancias del servicio como archivos de extensión .conf encuentre dentro del directorio ‘/etc/openvpn’. espesamos:
# cd /etc/openvpn \\ # touch openvpn.conf \\ # nano openvpn.conf
copiamos el siguiente script
dev tun port 1194 proto udp server 10.255.255.0 255.255.255.0 push “route 192.168.1.0 255.255.255.0" ifconfig-pool-persist ipp.txt dh /etc/openvpn/keys/dh1024.pem ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/vpn-server.crt key /etc/openvpn/keys/vpn-server.key cipher BF-CBC tls-serverduplicate-cn user nobody group nogroup comp-lzoping 15 ping-restart 60 ping-timer-rem persist-tunpersist-key verb 3 log-append /var/log/openvpn/vpn-server.log (crea toda esta ruta)
Hasta aquí se cubre algunas de las directivas básicas más comunes para conseguir una correcta configuración de OpenVPN como cliente y servidor usando certificados digitales. Sin embargo muchas otras opciones que pueden ser de interés para el lector pueden
ser encontradas en OpenVpn(sitios aprobados).
Arranque de OpenVPN \\ Una vez concluida la elaboración correcta de los archivos de configuración de OpenVPN arrancamos el servicios
- /etc/init.d/openvpn restart
Se esta manera se reinicia el servicios con la nueva configuración a la espera de alguna conexión
Configuración en modo cliente
En GNU/Linux la instalación es igual que el servidor, salvo que utilizamos el siguiente script:
dev tunport 1194 proto udp remote 200.40.220.169 1194 (ip de tu servirdor OpenVpn e indicado el puerto) pull tls-client ca ca.crt cert cliente0.crt key cliente0.key cipher BF-CBC ns-cert-type server comp-lzo ping 15 ping-restart 60 persist-tunpersist-key verb 3
En el mismo directorio hay que ubicar los archivos ca.crt, cliente0.crt y cliente0.key que fueron creados en el servidor OpenVpn.
Luego iniciar el servicio o ejecutar:
# openvpn --config /etc/openvpn/openvpn.conf
En este caso asumiremos que el cliente se conectara desde un Windows donde usaremos el OpenVPN GUI for Windows(sitios aprobados) (instalar con las opciones por default).
Una vez instalado iremos a la siguiente ruta:
C:\Archivos de programa\OpenVPN\config
Borramos todo lo que encontremos en ese diretorio y creamos un archivo de nombre cliente.ovpn y copiamos el mismo script anterior.
El siguiente paso es llevar ca.crt, cliente0.crt y cliente0.key que fueron creados en el servidor OpenVpn a la Pc del cliente y pegarlo en el directorio:
C:\Archivos de programa\OpenVPN\config
Luego Ejecutamos el cliente OpenVPN GUI desde:
Inicio -> programas -> openvpn -> OpenVPN GUI
Se carga OpenVPN GUI al costado del reloj y bastara con hacer un clic derecho y clic en Connect.
Fnalmente deberías conectarte sin problemas a tu servidor VPN y desde el punto del cliente ver a cualqueir PC de la LAN del otro extremos lo mas probable es que el servidor OpenVpn le asigne al cliente la ip 10.255.255.6 y podrás hacerle ping desde tu LAN sin problemas.
Recomendaciones
- Siempre dale un check a los log para detectar cualquier error.
# tail -f /var/log/openvpn/vpn-server.log
- Revisa que tengas la interfaz creada con el nombre tun0,tun1,tun2 o alguna parecida.
# ifconfig
- Asegurarse también que no existan reglas de firewall que impidan el ingreso de conexiones UDP al puerto de escucha del servidor OpenVPN.
- Tener cuidado con la hora y fecha de los sistemas operativos de modo tal que estén correctamente asignados. Si se generan los certificados en un host que tiene una hora y fecha atrasada entonces al querer hacer uso de ellos en un servidor o cliente que sí posean la hora correcta sucederá que la negociación SSL/TLS fallará debido a la desincronización de fecha y hora, donde se pretenderá validar un certificado en una fecha futura ficticia.