Conectando Clientes a la Red por VPN – Qué Protocolo Usar

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:

DiagramaVPN4

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

VPN4-01

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

VPN4-02

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/

VPN4-03

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”)

VPN4-04

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)

VPN4-05

VPN4-06

Siguiendo en la máquina CL, he creado cuatro conexiones cliente VPN identificando en cada una de ellas qué protocolo forzaré a que utilice

VPN4-07

Muestro cómo forzar en cada una el protocolo a utilizar

VPN4-08

VPN4-09

VPN4-10

VPN4-11

Comencemos por lo más fácil, y además porque sé que funcionará sin hacer ninguna configuración adicional como es PPTP

VPN4-12

VPN4-13

Podemos ver que se conecta por PPT sin ningún tipo de problema

VPN4-14

Y podemos ver los detalles de la misma

VPN4-16

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

VPN4-17

VPN4-18

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

VPN4-19

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

VPN4-20

 

Continuemos ahora probando por SSTP

VPN4-21

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

VPN4-22

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

VPN4-23

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

VPN4-24

 

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

VPN4-25

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”

VPN4-26

 

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

VPN4-28

Ya podemos probar con los otros protocolos que antes no funcionaban

 

Comenzaré por SSTP

VPN4-27

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

VPN4-29

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

VPN4-30

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

VPN4-31

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

VPN4-32

Sigue con el mismo error que registramos anteriormente

VPN4-33

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

VPN4-34

Con el certificado ya instalado probamos conectarnos nuevamente usando L2TP/IPSec y veremos que ahora se conectará exitosamente

VPN4-35

Como podemos observar, al igual que IKEv2 también utiliza cifrado AES-256, pero agrega como seguridad la autenticación de máquinas

VPN4-36

 

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

 

 

Anuncios
Post a comment or leave a trackback: Trackback URL.

Comentarios

  • Borja  On 09/12/2015 at 05:39

    Hola Guillermo.

    Como siempre estipendo tu post. Solo una pregunta: ¿si el cliente es un server, el procedimiento sirve igual?

    Gracias

    • Guillermo Delprato  On 09/12/2015 at 06:42

      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”

  • Nacho  On 10/12/2015 at 05:03

    Muy bueno el tutorial

    Respecto a la velocidad ¿Son todas las conexiones similares o alguno es más rápido que otros?

    • Guillermo Delprato  On 10/12/2015 at 06:38

      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 :)

      • Nacho  On 10/12/2015 at 13:07

        Gracias por las respuesta Guillermo

Trackbacks

Este espacio es para comentarios sobre la nota. No es un sitio de soporte

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: