En el blog ya he escrito varias notas sobre el tema de conectar clientes a la red usando VPNs (“Virtual Private Networks”), algunas con Windows Server 2008 y otras con Windows Server 2012 (R2). Pueden consultarlas fácilmente utilizando sobre el margen izquierdo la búsqueda de “VPN”
En esta nota, en lugar de poner el foco en cómo hacerlo, aunque lo muestro, lo dedicaré más al tema de la comparativa entre los cuatro protocolos posibles: PPTP, SSTP, IKEv2 y L2TP-IPSec, y las ventajas e inconvenientes de cada uno
Utilizaré la siguiente infraestructura:
Las máquinas utilizadas son las siguientes:
- DC1.ad.guillermod.com.ar que es un Controlador de Dominio
- VPN.ad.guillermod.com.ar que es el servidor VPN miembro del Dominio
- NAT-Router que simula ser un “Router” de tipo hogareño
- W81Ent-2 que es un sistema de escritorio en grupo de trabajo
- ISP-SRV.isp.com que simula ser un servidor de Internet que proveerá los servicios necesarios para algunos protocolos
- Servidor DNS
- Autoridad Certificadora
En el Dominio he creado un usuario de prueba “User Uno” al que le he dado el permiso de acceso remoto
En el servidor VPN he configurado con los nombres adecuados ambas interfaces de red, e inclusive he implementado una seguridad básica sobre la interfaz externa dejando sólo TCP/IPv4 y deshabilitando NetBIOS sobre TCP/IP
De la misma forma que lo he demostrado en otras notas del blog he configurado el acceso remoto por VPN. Si tienen dudas pueden consultar el siguiente artículo, aunque por supuesto pueden variar nombres y direcciones IP utilizadas
Windows Server 2012 (R2): Configurar Servidor VPN | WindowServer:
https://windowserver.wordpress.com/2014/03/27/windows-server-2012-r2-configurar-servidor-vpn/
Para simular un servidor DNS de Internet, y suponiendo que el nombre de prescencia en Internet es “guillermod.com.ar” he creado en ISP-SRV la correspondiente zona y el registro correspondiente a “vpn.guillermod.com.ar” (observen que no incluye “ad”)
Y por último en la máquina CL que será la máquina cliente en grupo de trabajo que se conectará por VPN, la he configurado para que reciba configuración IP a través del NAT-Router como si fuera una red hogareña
Verifico a través de NSLOOKUP que resuelve los nombres correctamente (Los “timeout” son problemas de mi infaestructura)
Siguiendo en la máquina CL, he creado cuatro conexiones cliente VPN identificando en cada una de ellas qué protocolo forzaré a que utilice
Muestro cómo forzar en cada una el protocolo a utilizar
Comencemos por lo más fácil, y además porque sé que funcionará sin hacer ninguna configuración adicional como es PPTP
Podemos ver que se conecta por PPT sin ningún tipo de problema
Y podemos ver los detalles de la misma
PPTP tiene como ventajas que es de muy fácil configuración, y que es un protocolo disponible en todas las versiones anteriores de Windows e inclusive en otros sistemas
A tener en cuenta es que el cifrado utilizado es MPPE-128 (Microsoft Point to Point Encryption), no es que sea débil, pero actualmente hay más seguros, y lo veremos con los otros protocolos
Como datos adicionales, podemos observar que no sólo tenemos conectividad a la red interna, sino que además puede resolver nombres de la red interna, esto es así porque como se muestra recibe configuración de DNS desde el servidor VPN
Probaré ahora las otras tres opciones, que aunque sé que no funcionarán, ya veremos más adelante los requerimientos, es interesante observar los mensajes de error que muestra el sistema ya que en mi consideración no son claros para nada
Comenzaré con L2TP/IPSec
El error indica que no puede conectarse porque el el servidor remoto no responde, pero sin embargo conocemos perfectamente que sí responde. El problema como veremos adelante es que nos faltan certificados digitales, por lo cual aunque es más seguro que PPTP también lleva más trabajo de configuración. Es un protocolo usable a partir de Windows 2000
Continuemos ahora probando por SSTP
El error en este caso dice que una conexión existente fue forzadamente cerrada por la máquna remota. Muy raro porque no había ninguna conexión existente
En realidad el problema de no poder conectarse es que para usar SSTP, que encapsula PPP en HTTPS, es que se necesita certificado digital en el servidor VPN. Es un protocolo disponible a partir de Windows Vista
Y por último probaré con IKEv2, disponible desde Windows 7
Ahora el mensaje de error es un poco más claro, aunque no da mucha información nos nombra que está faltando un certificado de máquina
Y sí, es así, para cualquiera de estos tres últimos protocolos necesitamos certificados digitales de máquina. Mejoraremos la seguridad pero a costa de un poco más de trabajo y costos
No mostraré el procedimiento de obtención de certificados de máquina, lo he hecho varias veces en el blog, hay varias formas de obtenerlos de acuerdo a la configuración, y sería mucho más largo de desarrollar que el tema que nos ocupa en esta nota que son los protocolos de VPN
Comenzaré obteniendo un certificado para la máquina VPN, para lo cual lo primero que debemos tener es considerar que la Autoridad Certificadora sea confiable para el servidor y el cliente. Como en mi caso he simulado una de tipo comercial, debemos instalar el certificado de la Autoridad Certificadora (tipo raíz) en “Trusted Root Certification Authorities” de la parte de máquina
Luego solicitar e instalar el certificado digital para la máquina, que debemos colocar en “Personal / Certificates” de la parte de máquina. Atención con algo importante: el nombre del certificado debe coincidir exactamente con el nombre por el cual se va a accederala, independientemente del nombre real de la máquina
Observen que el certificado está otorgado a “vpn.guillermod.com.ar”, cuando en realidad la máquina se llama “vpn.ad.guillermod.com.ar”
Algo más a tener en cuenta, como estoy usando una Autoridad Certificadora propia, para que el cliente (CL) confíe en el certificado que le presente el servidor (VPN), el cliente debe tener instalado el certificado de la Autoridad Certificadora, análogamente a como hicimos en VPN, pero sólo el certificado de la Autoridad Certificadora, esto es, para que lo considere confiable
Ya podemos probar con los otros protocolos que antes no funcionaban
Comenzaré por SSTP
Ahora que el servidor VPN tiene un certificado digital que el cliente puede validar se puede conectar sin problemas
Recordemos que SSTP se vale de encapsular el tráfico PPP en HTTPS y por eso es necesario el certificado del servidor.
En este caso el cifrado está basado en la longitud de claves del certificado
La ventaja importante de SSTP es que como se trata de tráfico HTTPS es normal que pase a través de los cortafuegos
Probaré ahora con IKEv2, que está disponible desde Windows 7
Podemos ver que con este protocolo también alcanza con que el servidor VPN disponga de un certificado digital que el cliente pueda validar
Importante a destacar es que el cifrado es algo que actualmente se considera seguro como es AES-256
La ventaja importante de IKEv2 es lo que llama “Fast reconnect” y aclararé un poco de qué se trata esto y cuándo puede ser útil
Con cualquiera de los otros tres protocolos, si durante una conexión el cliente cambiara su dirección IP, por la causa que sea, como podría ser por ejemplo cambiar de punto de acceso, la conexión se corta y habría que iniciarla nuevamente, lo cual podría por ejemplo tener que recomenzar una lenta copia de un archivo grando. Bueno, eso no sucede con IKEv2, la conexión se restablecería automáticamente y la copia continuaría desde el punto de corte
Y por último probemos ahora con L2TP/IPSec
Sigue con el mismo error que registramos anteriormente
Esto se debe a que L2TP/IPSec requiere no sólo certificado en el servidor VPN, sino que además requiere certificado digital en la máquina cliente que se va a conectar; ambas máquinas requieren poder autenticarse mutuamente, lo cual nos da aún más seguridad
Entonces debemos instalar en la máquina cliente, un certificado digital de máquina el cual sea considerado confiable por el servidor VPN. El proceso es análogo a lo que hicimos antes en el servidor VPN
Con el certificado ya instalado probamos conectarnos nuevamente usando L2TP/IPSec y veremos que ahora se conectará exitosamente
Como podemos observar, al igual que IKEv2 también utiliza cifrado AES-256, pero agrega como seguridad la autenticación de máquinas
Resumiendo:
- PPTP es el más fácil de configurar, y es el único que no requiere certificados
- SSTP tiene la ventaja que al usar HTTPS es fácil atravesar cortafuegos
- IKEv2 utiliza “Fast Reconnect” ideal para portables que pueden cambiar IP
- L2TP/IPSec es el más seguro de todos, aunque requiere mayor configuración, y puede tener problemas para atravesar algunos cortafuegos, especialmente si hacen NAT
Comentarios
Hola Guillermo.
Como siempre estipendo tu post. Solo una pregunta: ¿si el cliente es un server, el procedimiento sirve igual?
Gracias
Hola Borja, es igual cualquiera sea el cliente, sólo tener en cuenta la versión equivalente del cliente por las limitaciones de protocolos en sistemas «viejos»
Muy bueno el tutorial
Respecto a la velocidad ¿Son todas las conexiones similares o alguno es más rápido que otros?
Hola Nacho, en mi experiencia no he notado diferencias en cuanto a velocidad, aunque supongo que algo debe influenciar ya que cuando más seguro sea el proceso de cifrado en general requiere más procesamiento, aunque te reitero no he notado diferencia notable
Inclusive la autenticación inicial a través de certificados suele ser un poquito más lenta por el proceso de verificación, revocación, etc.
Cuando uno quiere aumentar la seguridad, la velocidad pasa a segundo plano :)
Gracias por las respuesta Guillermo
Trackbacks
[…] Conectando Clientes a la Red por VPN – Qué Protocolo Usar | WindowServer […]