Una vez que ya se tiene instalado OpenVPN en las máquinas servidor y clientes que serán miembros de la red virtual, hay que configurar correctamente el software, tanto en servicios como en generación de llaves de seguridad para poder tener la VPN funcionando.
Diseño de la red
La primer consideración importante a tener en cuenta es el diseño de la red virtual: qué máquinas formarán parte de la misma, si se formarán subredes dentro de la red virtual, cuestiones de ruteo y redireccionamiento, etc. Además se debe determinar el conjunto de direcciones IP que pertenecerán a las máquinas de la red.
En el RFC 1918, se establece que los rangos siguientes son exclusivos para redes privadas, es decir que ningún sitio en internet, que cualquiera podría ver, debe de tener asignada ninguna dirección de estos rangos, por lo que las múltiples redes privadas que puedan existir, virtuales o no, pueden hacer uso de estas direcciones IP para sus propósitos particulares.
De hecho, cualquiera que tenga una computadora dentro de una red privada (incluso en el hogar), podrá observar que la dirección IP que por lo común se le asigna cae en estos rangos:
Dir. inicial--------Dir. final----------CIDR
..10.0.0.0......10.255.255.255.....10.0.0.0/8
.172.16.0.0....172.31.255.255.....172.16.0.0/12
.192.168.0.0..192.168.255.255...192.168.0.0/16
La otra consideración importante a tomar en cuenta al momento de elegir las direcciones IP que se les asignará a las máquinas que pertenezcan a la red virtual viene del hecho de asegurar que para ninguna de las máquinas se producirán choques o conflictos, debido a que la dirección IP que se le asigne a cierta máquina, coincida con la dirección IP de alguna otra máquina dentro de alguna otra red a la que pertenezca o que la subred a la que pertenezca genere este mismo conflicto. Es decir, y por ejemplo:
supongamos que una máquina (que llamaremos A) que pertenecerá a la VPN quedará con dirección IP asignada de 192.168.1.10 (y otras máquinas de la VPN podrían quedar con IPs similares: B tendría IP 192.168.1.70, C tendría IP 192.168.1.43, etc.). Sin embargo, el problema vendría si A pertenece a su vez a una LAN en donde el rango de direcciones válidas queda dentro de la subred 192.168.1/24 (es decir, de 192.168.1.0 a 192.168.1.255). ¿Qué provocará esto? Por un lado, podría provocar que la dirección 192.168.1.10 ya estuviera asignada a alguna otra máquina de la LAN a la que pertenece nuestra desdichada máquina A. Pero peor aún, provocará que el sistema de ruteo y redireccionamiento de la LAN piense que todo el tráfico generado por y para 192.168.1.10 deberá quedarse dentro de la LAN misma, y no que pertenezca a una red diferente.
¿Qué hacer en estos casos? Bueno, la mejor solución es planear por adelantado. ¿Qué rangos posibles de subred van a tener las máquinas que pertenecerán a la VPN? Sabiendo esto, entonces habrá que tomar la decisión de diseño, de que la dirección de subred de toda la VPN quede en un rango que no ocasione ningún conflicto para nadie.
De acuerdo al ejemplo anterior, si se eligiera que la VPN quedara con direcciones dentro de la subred 192.168.20/24, con esto el problema para nuestra máquina conflictiva se vería resuelto: ahora A tendría dos direcciones IP: una dentro de la subred 192.168.20/24 (la de la VPN) y otra dentro de la subred 192.168.1/24 (la de la LAN a la que pertenece).
Servicios y puertos
El siguiente punto a considerar es que OpenVPN debe estar ejecutándose en la máquina que pertenecerá a la red (obviamente, por supuesto). La mejor opción es que se ejecute como un servicio que se levante por sí solo cada vez que se reinicie la máquina, de esta forma nos evitamos el tener que levantarlo nosotros mismos cada vez que recordemos que debemos pertenecer a la red virtual (o que alguien nos lo recuerde).
Además, al tratarse del servidor hay que definir el puerto sobre el que se conectarán las demás máquinas para establecer la VPN. Por lo general, ya que es la opción por defecto, se utiliza el puerto UDP 1194. Sin embargo, esto no es una regla, sino una recomendación. Se puede elegir otro número de puerto (desocupado por supuesto), y si se desea incluso, también otro protocolo de conexión, es decir en lugar de UDP se puede elegir TCP. (¡y no hay que olvidar abrir dicho puerto en el firewall del servidor una vez que se tenga todo listo para comenzar!)
Generación de llaves
Puesto que OpenVPN genera una VPN segura, se necesita alguna manera de garantizar dicha seguridad. Hay que tomar en cuenta que la información que se transmita entre las máquinas de la red virtual va a viajar através de internet y de máquinas desconocidas en lugares que podrían resultar muy variados. Esto conlleva un riesgo de seguridad: cualquiera con tiempo, ganas y habilidad podría interceptar la comunicación entre dos máquinas de la red que, de otra manera, se supone deberían ser datos privados, como en una LAN cualquiera.
Para garantizar la seguridad de la comunicación entre las máquinas de la red virtual se utiliza encriptación de llave pública, un método de encriptación de la información que, además de resultar muy popular hoy en día, resulta de los más seguros también (no hay que olvidar que, según la sabia filosofía del código abierto y el software libre, un protocolo entre más abierto y conocido sea por todos, más seguro es). En palabras breves, la encriptación de llave pública consiste en lo siguiente:
Supongamos que dos máquinas se quieren comunicar seguramente. En un lado de la comunicación se encripta la información a enviar utilizando algo llamado su llave privada, y de esa manera la información viaja por internet. Algo encriptado con llave privada es dificilísimo, sino es que imposible, de desencriptar en un tiempo que puede llegar a las décadas o más (incluso para las máquinas más potentes). Esto genera un pequeño problema: ¿cómo desencriptar la información rápidamente en el lado receptor? Una solución es utilizar la misma llave privada, pero esto ocasiona el problema de que ambas partes deben conocer dicha llave privada, y para que ambas conozcan la llave privada, entonces de alguna manera un lado debe hacer del conocimiento del otro lado dicha llave privada. Y como sea que lo veamos, esta transmisión de la llave privada puede ser igualmente insegura.
De esta forma, los algoritmos de llave pública implican que, en lugar de encriptar la información del transmisor con su llave privada, se encripte con la llave pública, una llave que puede ser conocida por quien sea, podría incluso transmitirse por TV o publicarse en un blog como estos, pero la forma de desencriptar la información, sólo se logra si el receptor cuenta con una llave privada generada de manera adecuada. Esta manera adecuada de obtener la llave privada correcta es a través de un certificado de seguridad. Y bueno, aún contando con la llave pública, las máquinas más potentes todavía tardarían décadas o más que eso en desencriptar la información, pues no cuentan con las llaves privadas adecuadas.
La manera de implementar todo esto en OpenVPN es utilizando SSL. Obviamente, se pueden conseguir (a un precio no tan accesible) los certificados de seguridad generados por compañías especializadas, pero si no se tienen los medios, en una instalación estándar de OpenVPN, se incluyen también algunos scripts hechos precisamente para permitir la generación de llaves privadas y certificados de seguridad para el servidor y las máquinas cliente que formarán parte de la red virtual, a través de SSL.
Ver la parte 1
Ver la parte 3
Saludos desde Mérida-Venezuela,
ResponderEliminarBuen articulo, muy util, nos gustaria continuar con el proyecto siguiendo sus recomendaciones, esperamos que pronto publiquen la parte 3.
¡Mil gracias!