- 1. Introduccion.
- 2. Requerimientos.
- 3. Reunion de informacion para formar la VPN.
- 4. Configurando tu propia Autoridad Certificadora (CA - Certificate Authority) y generacion de certificados y par de llaves para el Servidor OpenVPN y un cliente VPN.
- 5. Generar la llave y el certificado Maestro para la Autoridad Certificadora (CA).
- 6. Generacion de certificado y llaves para el servidor.
- 7. Generacion de certificado y llave privada para un cliente.
- 8. Archivos claves.
- 9. Creando archivos de configuracion para el servidor y el cliente.
- 10. Editando el archivo de configuracion de el servidor.
- 11. Editando el archivo de configuracion de el cliente.
- 12. Inicializacion de la VPN y pruebas iniciales de conectividad.
- 13. Iniciando el Cliente.
- 14. Solucion de errores:
- 15. Configurando OpenVPN para correr automaticamente al inicio de el sistema.
- 16. Controlando un proceso de OpenVPN que ya este corriendo.
- 17. Modificando una configuracion de un servidor en vivo.
- 18. Expandiendo el ambito de la VPN para incluir maquinas adicionales en la subred de el cliente o el servidor.
- 19. Reforzando la seguridad de OpenVPN.
- 20. Revocando Certificados
- 21. Referencias
OpenVPN es una implementacion de VPN SSL la cual usa las extenciones OSI layer 2 o 3 para asegurar redes la cual usa los protocolos SSL/TLS, soporta diferentes medios de autenticacion como certificados, smart cards, y/o usuarios/contraseñas, y permite politicas de control de acceso para usaurios o grupos usando reglas de firewall aplicadas a las interfaces virtuales de la VPN. OpenVPN 2.0 permite multiples clientes conectar a un solo servidor (proceso) OpenVPN sobre un simple puerto TCP o UDP.
Para seguir este documento se requieren conocimientos basicos de redes TCP/IP como , direcciones IP, DNS, netmasks, subnets, IP routing, routers, interfaces de red, LANs, gateways, y reglas de firewall.
La implementacion de la VPN en este documento se centra en la distrubucion GNU/Linux Slackware, por lo que la instalacion de el programa OpenVPN sera con un paquete de Slackware .tgz que yo construi. Antes de seguir con la instalacion es recomendable instalar primero los paquetes:
iproute2 lzo openssl tcpip iproute2, openssl y tcpip son paquetes oficiales de Slackware, por lo que los puedes encontrar en tus CD's o en un mirror de Slackware. Despues sigue la biblioteca "lzo" que es requerida para la compresion de el tunel VPN, el paquete binario lo puedes encontrar en: Paquete binario de lzo 1.08:
http://tuxjm.net/downloads/packages/slackware-10.2/lzo/
Claro siempre puedes ver el SlackBuild y ver como se contruyo y/o construirlo tu mismo para optimizarlo para la arquitectura de tu computadora. Builds de lzo 1.08:
http://tuxjm.net/downloads/source/slackware-10.2/lzo/
Una vez que se tengan instalados los requerimientos antes mencionados es hora de instalar OpenVPN, el paquete para Slackware se encuentra aqui: Builds de OpenVPN 2.0.6:
http://www.tuxjm.net/downloads/source/slackware-10.2/openvpn/
Paquete binario de OpenVPN 2.0.6:
En este documento el tipo de VPN sera tipo "routed VPN" .
Configuraciones de subnets
El proposito de la VPN es unir dos subredes en dos localizacioes, una la red de la oficina y la subred de mi red casera.
Subnet Oficina.
La subnet de la officina esta en el segmento 10.0.0.0/24 el gateway/proxy/VPNs server tiene la direccion IP 10.0.0.107.
Subnet Casa.
La subnet de la casa esta en el segmento 10.0.20.0/24 y el gateway/proxy/VPN server tiene la direccion IP IP 10.0.20.1.
La subnet de el tunel VPN sera 10.8.0.0/24, esto se usara asi ya que en los archivos de configuracion proporcionados por OpenVPN usan esa subnet.
El primer paso al construir una VPN con OpenVPN 2.0 es establecer una PKI (Infraestructura de LLave Publica - Public Key Infrastructure), esta PKI consiste de:
Un certificado aparte (tambien conocido como llave publica) y una llave privada para el servidor y cada cliente.
Un Certificado Mastro para la Autoridad Certificadora (CA) y su llave la cual es usada para firmar cada certificado de el servidor y el cliente.
En esta seccion se generaran los certificados/llaves para la CA, el server y el cliente. Para la administracion de la PKI usaremos los scripts que vienen con OpenVPN (easy-rsa) pero en este caso usaremos la nueva version que tiene muchas mejoras, es esta easy-rsa 2.0.
Estos scripts de la version 2.0 de easy-rsa estan en: /usr/doc/openvpn-2.0.6/easy-rsa/2.0/
Se recomienda copiar el contenido de dicho directorio por ejemplo a /etc/openvpn/easy-rsa-V2.0.
Entonces haremos:
# cd /etc/openvpn # mkdir easy-rsa-V2.0 # cp -r /usr/doc/openvpn-2.0.6/easy-rsa/2.0/* /etc/openvpn/easy-rsa-V2.0
# cd /etc/openvpn/easy-rsa-V2.0
Ahora editaremos el archivo vars lo primero que se hara es definir la ruta para la variable KEY_DIR que por default estara asi: /etc/openvpn/easy-rsa-V2.0/keys, pero dicho directorio no existe por lo que primero lo crearemos:
# mkdir -p /etc/openvpn/easy-rsa-V2.0/keys
Es en este directorio donde se almacenaran las llaves privadas, los archivos de requerimiento de certificado (.csr) y los certificados (.crt) y otros archvos e como el serial y el index.txt.
Ahora configuraremos los parametros KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG y KEY_MAIL, no hay que dejar ninguno de estos parametros vacios, los valores de estas variables seran pasadas de manera determinada a los certificados que crearemos, por ejemplo:
export KEY_COUNTRY="MX" export KEY_PROVINCE="Baja California" export KEY_CITY="Tijuana" export KEY_ORG="Tuxjm" export KEY_EMAIL="jmedinaaa@tuxjm.net"
Lo siguiente es inicializar la PKI, asi:
# source ./vars NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa-V2.0/keys
Si se editaron los parametros correctamente veras algo como lo que salio arriba.
Ahora configuraremos un entorno nuevo.
# ./clean-all
Conforme vayas creando certificados, keys, y requerimientos para firma de certificados, tendras que entender que solo los archivos.key deben de mantenerse confidenciales. Los archivos .crt y .csr pueden ser enviados sobre un canal inseguro como un email en texto plano.
- Generando Parametros Diffie Hellman.
Los parametros Diffie Hellman deben de ser generados para el Servidor OpenVPN:
# ./build-dh Generating DH parameters, 1024 bit long safe prime, generator 2 This is going to take a long time .............................................................................+.. ..............................................................+................. ..................+........................+.................................... +................................. #
Construiremos el certificado/key para la CA: Veremos algo asi:
# ./pkitool --initca Using CA Common Name: Tuxjm CA Generating a 1024 bit RSA private key ............................++++++ ........................++++++ writing new private key to 'ca.key' ----- #
Lo siguiente es generar el certiicado y la llave privada par el servidor:
# ./pkitool --server servidor Generating a 1024 bit RSA private key ...........++++++ ...................................................................++++++ writing new private key to 'servidor.key' ----- Using configuration from /etc/openvpn/easy-rsa-V2.0/openssl.cnf Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows countryName :PRINTABLE:'MX' stateOrProvinceName :PRINTABLE:'Baja California' localityName :PRINTABLE:'Tijuana' organizationName :PRINTABLE:'Tuxjm' commonName :PRINTABLE:'servidor' emailAddress :IA5STRING:'jmedinaaa@tuxjm.net' Certificate is to be certified until Apr 30 03:50:13 2016 GMT (3650 days) Write out database with 1 new entries Data Base Updated #
Como pudimos ver lo todos los valores fueron tomados de el archivo vars y le agrego el valor de commonName el valor de el argumento que pusimos: ./pkitool --server servidor, en este caso le puso servidor.
Esto es muy similar a los pasos previos
# ./pkitool cliente1 Generating a 1024 bit RSA private key .........................................++++++ ............................++++++ writing new private key to 'cliente1.key' ----- Using configuration from /etc/openvpn/easy-rsa-V2.0/openssl.cnf DEBUG[load_index]: unique_subject = "yes" Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows countryName :PRINTABLE:'MX' stateOrProvinceName :PRINTABLE:'Baja California' localityName :PRINTABLE:'Tijuana' organizationName :PRINTABLE:'Tuxjm' commonName :PRINTABLE:'cliente1' emailAddress :IA5STRING:'jmedinaaa@tuxjm.net' Certificate is to be certified until Apr 30 03:51:59 2016 GMT (3650 days) Write out database with 1 new entries Data Base Updated #
Como pudimos ver lo todos los valores fueron tomados de el archivo vars y le agrego el valor de commonName el valor de el argumento que pusimos: ./pkitool --server cliente1, en este caso le puso cliente1.
Ahora crearemos un segundo certiicado para un nuevo cliente:
# source ./vars NOTE: If you run ./clean-all, I will be doing a rm -rf on /etc/openvpn/easy-rsa-V2.0/keys
# ./pkitool cliente2
Conforme vayas agregando clientes lo haras con esta misma herramienta (pkitool) no hay que olvidar que cada vez que se vaya a usar el script pkitool se tiene que ejecutar el comando sounce ./vars antes de crear, o revocar algun certificado.
Ahora podremos encontrar nuestros nuevos certificados y llaves en el subdirectorio keys
| Nombre de Archivo | Necesario para | Proposito | Secreto |
|---|---|---|---|
| ca.crt | servidor + todos los clientes | Certificado para Root CA | NO |
| ca.key | Solo maquina con la llave para firmar | Llave para Root CA | SI |
| dh1024.pem | Solo Servidor | Parametros Diffie Hellman | NO |
| servidor.crt | Solo Servidor | Certificado para Servidor | NO |
| servidor.key | Solo Servidor | Llave privada para Servidor | SI |
| cliente1.crt | Solo cliente1 | Certificado para Cliente1 | NO |
| cliente1.key | Solo cliente1 | Llave privada para Cliente1 | SI |
| cliente2.crt | Solo cliente2 | Certificado para Cliente2 | NO |
| cliente2.key | Solo cliente2 | Llave priada para Cliente2 | SI |
En este documento se explica la generacion de los archivos anteriores en el mismo server, aunque se puede tener una maquina dedicada para la CA, asi los archivos marcados como secretos se mantienen aparte, los clientes pueden generar su propio "Certificate Signing Request (CSR) y que la CA lo firme.
Bien, ahora lo que sigue es copiar los archivos necesarios a su lugar respectivo, en el caso de: ca.crt, dh1024.pem, servidor.crt y servidor.key van en el servidor, asi que los podemos dejar en donde estan, los archivos ca.crt, cliente1.crt y cliente1.key se tendran que pasar a el cliente, esto tiene que ser por un medio seguro, se puede usar ssh para pasarlos a la maquina cliente.
Yo hago algo asi:
Suponiendo que aun estamos en /etc/openvpn/easy-rsa-V2.0
# mkdir archivos-cliente1 # cd keys # cp -v ca.crt cliente1.crt cliente1.key ../archivos-cliente1/
Y luego:
# cd .. # chmod -R 755 archivos-cliente1 $ scp -r archivos-cliente1 usuario@cliente-vpn:.
Consiguendo los archivos de configuracion de ejemplo.
Es recomendable usar los archivos de configuracion de ejemplo de OpenVPN como un punto inicial para tu propia configuracion. estos pueden ser encontrados en: /usr/doc/openvpn-2.0.6/sample-config-files/server.conf y client.conf
El archivo de configuracion de ejemplo para el servidor es un punto de inicio ideal para la configuracion de un servidor OpenVPN. Creara una VPN usando una interfaz de red virtual TUN (para routed mode), escuchara conexiones de clientes en el puerto UDP 1194 (El numero de puerto oficial de OpenVPN), y distribuira direcciones virtuales de la subred 10.8.0.0/24 para los clientes que se conecten.
Copiamos el archivo de configuracion de el servidor:
# cd /etc/openvpn/ # cp /usr/doc/openvpn-2.0.6/sample-config-files/server.conf .
Editar el archivo server.conf y cambiar los valores de las lineas de los parametros: ca, cert, key y dh para que apunten a los archivos generados en la seccion anterior.
Por ejemplo quedaria asi:
ca/etc/openvpn/easy-rsa-V2.0/keys/ca.crtcert/etc/openvpn/easy-rsa-V2.0/keys/servidor.crtkey/etc/openvpn/easy-rsa-V2.0/keys/servidor.keydh /etc/openvpn/easy-rsa-V2.0/keys/dh1024.pem
En el cliente VPN tambien se deben de seguir los procedimientos de instalacion que se dieron al inicio, una vez que este todo instalado es hora de copiar los archivos que se generaron en el servidor y se copiaron por un medio seguro (ssh/scp), dichos archivos son:
ca.crt cliente1.crt cliente1.key
Y hay que copiarlos de donde esten a /etc/openvpn/ y ponerles los permisos adecuados:
# chmod 644 ca.crt # chmod 644 cliente1.crt # chmod 600 cliente1.key
Ahora lo que sigue es usar un archivo de configuracion para el cliente de ejemplo:
# pwd /etc/openvpn # cp /usr/doc/openvpn-2.0.6/sample-config-files/client.conf .
Entonces en el cliente tendremos:
# pwd /etc/openvpn # ls ca.crt client.conf cliente1.crt cliente1.key
Teniendo estos archivos, lo que sigue es editar el archivo client.conf y cambiar los parametros de ca, cert y key para que apunten a los nombres de archivos que acabamos de copiar, en este caso el valor de ca se deja como esta, y se cambia el valor de cert de client.crt a cliente1.crt y el valor de key de client.key a cliente1.key, hay que recordar que el archivo ca.crt es universal tanto para los clientes y los servidores.
Ahora hay que editar el parametro de remote para puntarlo a el nombre de host o direccion IP y puerto de el servidor OpenVPN.
Por ejemplo:
remote 200.222.111.101 1194
Bien una vez editado el parametro guardar el archivo.
Iniciando el Servidor.
Primero hay que asegurarse que el servidor OpenVPN es accesible desde el Internet, esto quiere decir:
Abrir el puerto UDP 1194 en el firewall o configurar una regla de redireccionamiento de puerto (port forwarding) de el puerto UDP 1194 desde el gateway/firewall a la maquina servidor OpenVPN.
Lo siguiete es asegurarse que la interfaz TUN no esta firewalleada.
Por simplicidad y para hacer pruebas iniciales, es recomendable iniciar el servidor OpenVPN desde la linea de comando, en lugar de iniciarlo como un servicio (daemon).
# cd /etc/openvpn/
# openvpn server.conf
Tue May 2 21:30:49 2006 OpenVPN 2.0.6 i686-pc-linux [SSL] [LZO] built on Apr 29 2006
Tue May 2 21:30:49 2006 Diffie-Hellman initialized with 1024 bit key
Tue May 2 21:30:49 2006 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue May 2 21:30:49 2006 TUN/TAP device tun0 opened
Tue May 2 21:30:49 2006 /sbin/ip link set dev tun0 up mtu 1500
Tue May 2 21:30:49 2006 /sbin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2
Tue May 2 21:30:49 2006 /sbin/ip route add 10.8.0.0/24 via 10.8.0.2
Tue May 2 21:30:49 2006 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Tue May 2 21:30:49 2006 UDPv4 link local (bound): [undef]:1194
Tue May 2 21:30:49 2006 UDPv4 link remote: [undef]
Tue May 2 21:30:49 2006 MULTI: multi_init called, r=256 v=256
Tue May 2 21:30:49 2006 IFCONFIG POOL: base=10.8.0.4 size=62
Tue May 2 21:30:49 2006 IFCONFIG POOL LIST
Tue May 2 21:30:49 2006 Initialization Sequence CompletedSi muestra algo similar a lo de arriba significa que en el servidor todo fue bien.
Como en la configuracion de el servidor, es mejor inicializar el cliente desde la linea de comandos.
# cd /etc/openvpn/
# openvpn client.conf
Wed May 3 10:36:32 2006 OpenVPN 2.0.6 i686-pc-linux [SSL] [LZO] built on Apr 29 2006
Wed May 3 10:36:32 2006 IMPORTANT: OpenVPN's default port number is now 1194, based on an official
port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000
as the default port.
Wed May 3 10:36:32 2006 WARNING: No server certificate verification method has been enabled.
See http://openvpn.net/howto.html#mitm for more info.
Wed May 3 10:36:32 2006 LZO compression initialized
Wed May 3 10:36:32 2006 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Wed May 3 10:36:32 2006 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Wed May 3 10:36:32 2006 Local Options hash (VER=V4): '41690919'
Wed May 3 10:36:32 2006 Expected Remote Options hash (VER=V4): '530fdded'
Wed May 3 10:36:32 2006 UDPv4 link local: [undef]
Wed May 3 10:36:32 2006 UDPv4 link remote: 200.222.111.101:1194
Wed May 3 10:36:32 2006 TLS: Initial packet from 200.222.111.101:1194, sid=cb908c7a 37dab07c
Wed May 3 10:36:33 2006 VERIFY OK: depth=1,
/C=MX/ST=Baja_California/L=Tijuana/O=Tuxjm/CN=Calcom_CA/emailAddress=jmedinaaa@tuxjm.net
Wed May 3 10:36:33 2006 VERIFY OK: depth=0,
/C=MX/ST=Baja_California/L=Tijuana/O=Tuxjm/CN=servidor/emailAddress=jmedinaaa@tuxjm.net
Wed May 3 10:36:34 2006 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed May 3 10:36:34 2006 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed May 3 10:36:34 2006 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed May 3 10:36:34 2006 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed May 3 10:36:34 2006 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Wed May 3 10:36:34 2006 [servidor] Peer Connection Initiated with 200.222.111.101:1194
Wed May 3 10:36:35 2006 SENT CONTROL [servidor]: 'PUSH_REQUEST' (status=1)
Wed May 3 10:36:35 2006 PUSH: Received control message:
'PUSH_REPLY,route 10.8.0.1,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Wed May 3 10:36:35 2006 OPTIONS IMPORT: timers and/or timeouts modified
Wed May 3 10:36:35 2006 OPTIONS IMPORT: --ifconfig/up options modified
Wed May 3 10:36:35 2006 OPTIONS IMPORT: route options modified
Wed May 3 10:36:35 2006 TUN/TAP device tun0 opened
Wed May 3 10:36:35 2006 /sbin/ip link set dev tun0 up mtu 1500
Wed May 3 10:36:35 2006 /sbin/ip addr add dev tun0 local 10.8.0.6 peer 10.8.0.5
Wed May 3 10:36:35 2006 /sbin/ip route add 10.8.0.1/32 via 10.8.0.5
Wed May 3 10:36:35 2006 Initialization Sequence CompletedSi muestra algo similar a lo de arriba significa que en el cliente todo fue bien. Ahora, intenta hacer ping a traves de la VPN desde el cliente. Si estas usando openvpn en modo routed ( usando dev tun en el archivo de configuracion de el server), intenta:
# ping 10.8.0.1
Si el ping se hace con exito, Felicitaciones! ahora ya tienes una VPN funcional.
Si el ping fallo o la inicializacion de el cliente OpenVPN para completar, aqui hay un checklist de sintomas comunes y sus soluciones:
Obtienes el mensaje de error: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity).
Este error indica que el cleinte no fue capaz de establecer una conexion de red con el servidor.
Soluciones:
- Asegurate de que el ciente esta usando la direccion correcta de el hostname/IP y el numero de puerto que le permitira alcanzar a el servidor OpenVPN.
- Si la maquina que corre el servidor OpenVPN es una maquina con una sola interfaz de red dentro de una red LAN protegida, asegurate de que estas usando un regla de redireccion de puerto en el firewall gateway de el servidor OpenVPN. For ejemplo, supongamos que tu servidor OpenVPN esta en la direccion 10.0.0.105 dentro de el firewall, escuchando por conexiones de clientes en el puerto UDP 1194. El dispositivo que hace NAT para la subred 10.0.0.x deberia una regla de reenvio de puerto que diga: reenviar el puerto UDP 1194 desde cuaqluier direccion IP publca a el host 10.0.0.105.
- Abre el firewalll de el servidor OpenVPN para permitir conexiones a el puerto UDP 1194 ( o cualquier puerto TCP/UPD que hayas configurado en el archivo de configuracion de el servidor.
Obtienes el mensaje de error: Initialization Sequence Completado con errores -- Este error puede ocurrir en Windows si (a) No tienes el servicio DHCP client corriendo, o (b) Estas usando ciertos personal firewall de terceras personas en XP SP2. Solucion: - Inicia el servicio DHCP client y asegurate que esats usando un firewall personal que trabaje correctamente con XP SP2. * Obtienes el mensaje Initialization Sequence Complete pero el test de ping falla -- Esto usualmente indica que el firewall ya sea en el servidor o el cliente esta bloqueando trafico de red VPN porque esta filtrando la interfaz TUN/TAP.
Solucion:
- Desactiva el firewall en el cliente ( si es que existe alguno) para que no haga filtrado en la interfaz TUN/TAP en el cliente. Por ejemplo en Windows XP SP2, puedes hacer esto llendo a Windwows Security Center -> Windows Firewall ->Advanced y desactiva la casilla la cual corresponde a el adaptador TAP-Win32 (desactivando el firewall de el cliente para que no haga filtrado en el adaptador TUN/TAP es generalmente rasonable desde la perspectiva de la seguridad, ya que escencialmente le estas diciendo al firewall que no bloquee el trafico en la VPN autenticada). Tambien asegurate que la interfaz TUN/TAP en el servidor no este filtrada por un firewall (habiendo dicho esto, note que haciendo filtrado selectivo en la interfaz TUN/TAP en el servidor puede ofrecer ciertos beneficios en cuanto a seguridad. Vee la seccion "access policy" abajo).
La conexion "stalls" al inicio cuando se usa la configuracion proto udp, el archivo de log de el servidor muestra la linea:
TLS: Initial packet from x.x.x.x:x, sid=xxxxxxxx xxxxxxxx
Sin embargo el log de el cliente no muestra una linea equivalente.
Solucion:
- Tienes una conexion en un solo sentido de el cliente a el servidor. La direccion de el servidor hacia el cliente esta bloqueada por un firewall, usualmente en el lado e el cliente. El firewall puede ser (a) un software de firewall personal corriendo en el cliente, o (b) el gateway (router)_ que hace NAT para el cliente. Modifica el firewall para permitir conexiones de regreso a paquetes UDP de el servidor para alcanzar el cliente.
Ver el FAQ para informacion adicional para la resolucion de problemas.
La carencia de estandars en esta area significa que la mayoria de OSes tienen una diferente manera para configurar demonios/servicios para autoiniciar al arranque de el sistema. La mejor manera para tener esta funcionalidad configurada de manera predeterminada es instalar OpenVPN como un paquete, como puede ser via RPM on Linux o usando un installador de Windows.
NOTA: En este caso el paquete openvpn-2.0.6-i486-1jm.tgz provee el script /etc/rc.d/rc.openvpn
Si instalaste OpenVPN via un paquete TGZ en Slackware Linux, el paquete creara un rc script /etc/rc.d/rc.openvpn. Cuando es ejecutado, el rc script escaneara por archivos de configuracion .conf en el directorio /etc/openvpn, y si encuentra alguno, iniciara un demonio separado de OpenVPN por cada archivo.
Si deseas que OpenVPN sea ejecutado al inicio de el sistema puedes agregar unas lineas como estas a tu archivo /etc/rc.d/rc.local
# Start the OpenVPN Daemon: if [ -x /etc/rc.d/rc.openvpn ]; then . /etc/rc.d/rc.openvpn start fi
Corriendo en Linux OpenVPN acepta varias señales:
SIGUSR1 -- Reinicio condicional, diseñado para reiniciar sin privilegios de root.
SIGHUP -- Hard Restart.
SIGUSR2 -- Saca las estadisticas de conexino a un archivo de log o a syslog.
SIGTERM, SIGINT -- Termina.
Usa la directiva writepid para escribir el PID de el demonio OpenVPN a un archivo, asi sabras a donde enviar la señal ( si estas iniciando el script con un rc script, el script puede que ya este pasando la directiva --wirtepid en la linea de comandos).
El script /etc/rc.d/rc.openvpn puede usar algunos argumentos para mandar esas señales, por ejemplo:
/etc/rc.d/rc.openvpn reload - SIGHUP
/etc/rc.d/rc.openvpn reopen - SIGUSR1
/etc/rc.d/rc.openvpn status - SIGUSR2
Mientras que la mayoria de las configuraciones requiren que reinicies el servidor, hay dos directivas in particular que se refieren a archivos que pueden ser dinamicamente actualizados "al vuelo", y los cuales tomaran efecto de inmediato en el servidor sin necesidad de reiniciar el proceso de el servidor.
client-config-dir -- Esta directiva configura el directorio de configuracion, el cual el servidor OpenVPN escaneara en cada conexion entrante, en busca de un archivo de configuracion especifico para el cliente que inicia la conexion ( ver la pagina de el manual para mayor informacion). Los archivos en este directorio pueden ser actualizados "al vuelo", sin reiniciar el servidor. Note que los cambios en este directorio solo tomaran efecto para nuevas conexiones, y no para conexiones ya existentes. Si quisieras que el cambio en un archivo de configuracion especifico para un clente tome efecto inmediato en un cliente actualmente conectado (o en uno el cual se ha desconectado, pero cuando el server no dado tiempo fuera a su instancia), mata la instancia de el cliente usando la interfaz de administracion ( descrita abajo). Esto causara el cliente para reconectarse y usar el nuevo archivo en client-config-dir.
crl-verify -- Esta directiva nombra el archivo con la Lista de Revocacion de Certificados, de el ingles (Certificate Revocation List), descrito en la seccion "Revocando Certificados. El archivo CRL puede ser modificado "al vuelo", y los cambios tomaran efecto inmediato para nuevas conexiones, o conexiones existentes que estan renegociando su canal SSL/TLS (Ocurre una vez por hora de manera predeterminada). Si quisieras matar una conexion de un cliente actualmente conectada que su certificado ha sido agregado a la CRL, usa la interfaz de administracion (descrita abajo).
Status File
El archivo default server.conf tiene una linea:
status openvpn-status.log
El cual mandara la salida de una lista de conexiones de clientes actuales a el archivo openvpn-status.log una vez por minuto.
Una vez que la VPN es operacional con una capacidad punto-a-punto entre el cliente y el servidor, seria deseable expandir el ambito de la VPN de manera que los clientes puedan alcanzar multiples maquinas en la red de el servidor, en lugar de solo la maquina servidor en si.
Para el proposito de este ejemplo, asumiremos que la LAN de el lado de el servidor usa una subred de 10.0.0.0/24 y el pool de direcciones IP de la VPN usa 10.8.0.0/24 como fue citado en la directiva "server" en el archivo de configuracion de el servidor OpenVPN.
Primero debes de anunciar la subred 10.0.0.0/24 a los clientes para que sea accesible a travez de la VPN. esto puede ser facilmente hecho con la siguiente directiva en el archivo de configuracion de el lado servidor:
push "route 10.0.0.0 255.255.255.0"
Lo siguiente, debes de de configurar una ruta en el gateway de la LAN en el lado de el servidor para enrutar la subred de el cliente VPN (10.8.0.0/24) hacia el servidor OpenVPN (esto es solo necesario si el servidor OpenVPN y el gateway de la LAN estan en diferentes maquinas).
Asegurate de que has activado IP y TUN/TAP forwarding en la maquina servidor OpenVPN.
En un tipico escenario road-warrior o acceso remoto, la maquina cliente se conecta a la VPN como una sola maquina. Pero supon que la maquina cliente es un gateway para una LAN local ( como la oficina de casa), y quisieras que cada maquina en la LAN de el cliente sea ruteada a traves de la VPN.
Para este ejemplo, asumiremos que la LAN de el cliente esta usando la subred 10.0.20.0/24, y que el cliente VPN esta usando un certificado con el common name de cliente1. Nuestra meta es configurar la VPN de manera que cualquiera maquina en la LAN de el cliente se pueda comunicar con cualquier maquina en la LAN de el servidor a traves de la VPN.
Antes de configurarlo, hay unos prerequisitos basicos que deben de seguirse:
La LAN de el cliente (10.0.20.0/24 en nuestro ejemplo) no debe de ser exportada a la VPN por el servidor o algun cliente que este usando la misma subred. Cada subred que sea unida a la VPN via enrutamiento debe de ser unica.
El cliente debe de tener un certificado con un Common Name unico (cliente1 en nuestro ejemplo), y la directiva "duplicate-cn" no debe de ser usada en el archivo de configuracion de el servidor OpenVPN.
Primero asegurate que el reenvio IP y TUN/TAP esta activado en la maquina cliente.
Ahora trataremos con los cambios de configuracion necesarias en el lado de el servidor. Si el archivo de configuraion de el servidor actualmente no hace ninguna referencia a el directorio de configuraciones de clientes, agrega una ahora:
client-config-dir ccd
En la directiva de arriba, ccd debe de ser el nombre de un directorio el cual ha sido pre-creado en el directorio predeterminado donde el demonio de el servidor openvpn corre. En Linux esto tiende a ser /etc/openvpn y en Windows es usualmente \Program Files\OpenVPN\config. Cuando un nuevo cliente se conecta al servidor OpenVPN, el demonio revisara este directorio en busca de algun archivo que concuerde con el common name de el certificado de el cliente que se conecta. Si un archivo concuerda, sera leido y procesado para aplicar directivas adicionales a dicho cliente.
El siguiente paso es crear un archivo llamado cliente1 en el directorio ccd.
Este archivo debe de contener la linea:
iroute 10.0.20.0 255.255.255.0
Esto le dira a el servidor OpenVPN que la subred 10.0.20.0/24 debe de ser enrutada a cliente1.
Despues, agraga la siguiente linea a el archivo de configuracion principal de el servidor (no el archivo ccd/cliente1 ):
route 10.0.20.0 255.255.255.0
Porque las sentencias redundantes de route e iroute, te has de preguntar? La razon es que route controla el enrutamiento desde el kernel a el servidor OpenVPN (via la interfaz TUN) mientras que iroute controla el enrutamiento desde el servidor OpenVPN a los clientes remotos. Ambos son necesarios.
Ahora preguntate tu mismo si te gustaria permitir trafico de red entre la subred de cliente1 (10.0.20.0/24) y los otros clientes de el servidor OpenVPN. Si es asi, agrega lo siguiente a el archivo de configuracion de el servidor.
client-to-client
push "route 10.0.20.0 255.255.255.0"
Esto causara a el servidor OpenVPN anunciar la subred de cliente1 a los otros clientes que se coencten. (asi sabran que ruta tomar para llegar a determinada subred).
Una de las tan a menudo repetidas maximas en la seguridad de redes es que uno no debe de poner tanta confianza en un solo componente de seguridad que su falla pueda causar una brecha de seguridad catastrofica. OpenVPN provee varios mecanismos para agregar niveles de seguiridad adicionales para HEDGE AGAINST SUCH AN OUTCOME.
La directiva tls-auth una firma HMAC adicional para todos las negociaciones SSL/TLS para la verficacion de la integridad. Cualquier paquete UDP que no posea la firma HMAC correcta puede ser bloqueado sin mas procesamiento. La firma HMAC tls-auth provee un nivel de seguridad adicional mas alla de el que provee SSL/TLS. Puede proteger contra:
Ataques DoS o inundamiento de puertos en el puerto UDP de OpenVPN.
Escaneo de puertos para determinar en cual que puertos UDP de un servidor estan en estado de escucha.
Vulnerabilidades de desbordamiento de buffer en la implementacion SSL/TLS.
nicializacion de negociaciones SSL/TLS de maquinas no autorizadas (podria ser que tales negociaciones al final fallen autenticandose, tls-auth puede cortarlas desde un punto inicial).
Para usar tls-auth se requiere que generes una llave secreta compartida que es usada en conjunto con con los certificados/llaves RSA estandar:
# openvpn --genkey --secret ta.key
Este comando generara una llave OpenVPN estatica y la escribe en el archivo ta.key. Esta llave debera de ser copiada por un canal seguro pre-existente a el servidor y todas las maquinas clientes. Puede ser colocada en el mismo directorio en el que estan los archivos RSA .key y .crt.
En la configuracion de el servidor, agrega:
tls-auth ta.key 0
En la configuracion de el cliente, agrega:
tls-auth ta.key 1
Puesto que OpenVPN permite que sean usados tanto los protocolos TCP o UDP como el transporte de la conexion VPN, el protocolo UPD proveera mejor proteccion en contra de ataques DoS y escaneos de puertos que el protocolo TCP:
proto udp
OpenVPN ha sido muy cuidadosamente diseñado para permitir que los privilegios de root sean tirados despues de su inicializacion, y esta caracteristica siempre deberia de ser usada en Linux/BSD/Solaris. Sin privilegios de root, el demonio de un servidor OpenVPN que este corriendo provee menos tentacion a un atacante.
user nobody
group nobody
El tamaño de la llave RSA es controlado por la variable KEY_SIZE en el archivo vars, la cual debe de ser definida antes de que ninguna llave sea generada. Actualmente esta configurarlo a 1024 de manera predeterminada, este valor puede ser rasonablemente incrementado a 2048 sin ningun impacto negativo en el rendimiento de el tunel, excepto por una pequeñisima negociacion SSL/TLS la cual ocurre una vez por hora por cada cliente, tambien un poco en la generacion de los parametros Diffie Hellman en el script build-dh.
De manera predeterminada OpenVPN usa Blowfish, un cifrado simetrico de 128 bits.
OpenVPN de manera automatica soporta cualquier cifrado que seea soportado por la biblioteca OpenSSL, y asi puede soportar cifrados los cuales usen llaves de tamaño largo. Por ejemplo, la version ASES (Advanced Encryption Standard) de 256-bits puede ser usada agregando lo siguiente a los archivos de configuracion tanto de el servidor como de el cliente:
cipher AES-256-CBC
Uno de los beneficios en cuanto a seguridad al usar una PKI X509 (como OpenVPN lo hace) es que la llave raiz de la CA (ca.key) no necesita estar presente en la maquina servidor OpenVPN. En un entorno de alta seguridad, deberias de de designar una maquina solo para propositos de firma de certificados, manten la maquina bien protegida en el aspecto fisico, y desconectala de toda red.
Los disquetes pueden ser usados para mover los archivos de las llaves de un lugar a otro, como sea necesario. Tales medidas pueden hacer extremadamente dificil que un atacante pueda robar la llave raiz, a menos que robe la maquina completa.
Revocando un certificado significa invalidar un certiicado previamente firmdo para que ya no pueda ser usado para propositos de autenticacion.
Las razones tipicas para querer removar un certificado incluyen:
La llave privada asociada con el certificado esta cmprometida o robada.
El usuario de una llave privada cifrada olvia la conraseña de la llave.
Quieres erminar el acceso a la VPN para un usuario.
Ejemplo
Como un ejemplo, revocaremos el certificado cliente2, el cual generamos arriba en la seccion "Creando tu propia CA" de este documento.
Primero abre un shell y has cd a el directorio de easy-rsa-V2.0 como lo hiciste en la seccion "Creando tu propia CA". Asi:
cd /etc/openvpn/easy-rsa-V2.0
source ./vars
./revoke-full cliente2
Deberias de ver una salida similar a esta:
# ./revoke-full cliente1 Using configuration from /etc/openvpn/easy-rsa-V2.0/openssl.cnf DEBUG[load_index]: unique_subject = "yes" Revoking Certificate 02. Data Base Updated Using configuration from /etc/openvpn/easy-rsa-V2.0/openssl.cnf DEBUG[load_index]: unique_subject = "yes" cliente1.crt: /C=MX/ST=Baja California/L=Tijuana/O=Tuxjm/CN=cliente2/emailAddress=jmedinaa@tuxjm.net error 23 at 0 depth lookup:certificate revoked #
Note el "error 23" en la ultima linea. Eso es lo que tu quieres ver, ya que indica que el la verificacion de el certificado revocado fallo.
El script revoke-full generara un archivo CRL (certificate revocation list) llamado crl.pem en el subdirectorio keys. El archivo debera ser copiado a el directoro donde el servidor OpenVPN puede accesarlo, entonces la verifiacion de CRL debera de ser activada en la configuracion de el servidor.
crl-verify crl.pm
Ahora todos los certificados de los clientes seran verificados contra la CRL, y cuaquiera concordancia positiva resultara en que la la conexion sera bloqueada.
Notas sobre CRL
Cuando la opcion crl-verify es usada en OpenVPN, el archivo CRL sera re-leido cada vez que un nuevo cliente se conecta o un cliente existente renegocia la conexion SSL/TLS (de manera predeterminada una vez por hora). Esto significa que puedes actualizar el archivo CRL mintras el demonio de el servidor OpenVPN este corriendo, y que el nuevo CRL tenga efecto inmediato para los nuevos clientes que se conecten. Si el cliente para el que estas revocando su certificado esta actualente conectado, puedes reiniciar el servidor via la señal (SIGUSR1 o SIGHUP) y "flushear" todos los clientes, o puedes hacer telnet a el puerto de la interfaz de administracion y explicitamente matar la instancia de el cliente en el servidor sin molestar a los otros clientes.
Puesto la directiva crl-verify puede ser usada en ambos el servidor OpenVPN y el cliente, esto es generalmente inecesario para distribuir el arcivo CRL a los clientes a menos que el certificado de el servidor ha sido revocado. Los clientes no necesitan saber acerca de los certificados de otros clientes que han sido revocados porque los clientes no deberian de aceptar conexiones directas de otros clientes en primer lugar.
El archivo CRL no es secreto, y deberia ser leible por todos para que el demonio OpenVPN pueda leerlo despues de que los privilegios de root han sido tirados.
Si estas usando la directiva chroot, asegurate de poner una copia de el archivo CRL en el directorio chroot, puesto que a diferencia de la mayoria de archivos que OpenVPN lee, el archivo CRL sera leido despues de que el chroot es ejecutado, no antes.
Una razon comun para que un certificado necesite ser revocado es que el usuario cifra su llave privada con una contraseña, entonces olvida la contraseña. Al revocar el certificado original, es posible re-generar un nuevo nuevo para de llave/certificado con el common name original de el usuario.