La autenticación es llevada a cabo generalmente
al inicio de una sesión, y luego aleatoriamente durante el
curso de la misma, para asegurar que no haya algún tercer
participante que se haya intrometido en la conversación.
La autenticación también puede ser usada para
asegurar la integridad de los datos. Los datos son procesados con
un algoritmo de
hashing para derivar un valor incluido
en el mensaje como checksum. Cualquier desviación en el
checksum indica que los datos fueron corruptos en la
transmisión o interceptados y modificados en el
camino.
Ejemplos de sistemas de autenticación son
Challenge Handshake Authentication Protocol (CHAP) y
RSA.
Todas las VPNs tienen algún tipo de
tecnología de encriptación, que esencialmente
empaqueta los datos en un paquete seguro. La
encriptación es considerada tan esencial como la
autenticación, ya que protege los datos transportados de
la poder ser
vistos y entendidos en el viaje de un extremo a otro de la
conexión. Existen dos tipos de técnicas de
encriptación que se usan en las VPN: encriptación
de clave secreta, o privada, y encriptación de clave
pública.
En la encriptación de clave secreta, se utiliza
una contraseña secreta conocida por todos los
participantes que necesitan acceso a la información
encriptada. Dicha contraseña se utiliza tanto para
encriptar como para desencriptar la información. Este tipo
de encriptación posee el problema que, como la
contraseña es compartida por todos los participantes y
debe mantenerse secreta, al ser revelada, debe ser cambiada y
distribuida a los participantes, con lo cual se puede crear de
esta manera algún problema de seguridad.
La encriptación de clave pública implica
la utilización de dos claves, una pública y una
secreta. La primera es enviada a los demás participantes.
Al encriptar, se usa la clave privada propia y la clave
pública del otro participante de la conversación.
Al recibir la información, ésta es desencriptada
usando su propia clave privada y la pública del generador
de la información. La gran desventaja de este tipo de
encriptación es que resulta ser más lenta que la de
clave secreta.
En las VPNs, la encriptación debe ser realizada
en tiempo real. Por eso, los flujos encriptados a través
de una red son encriptados utilizando encriptación de
clave secreta con claves que son solamente buenas para sesiones
de flujo.
El protocolo más usado para la
encriptación dentro de las VPNs es IPSec, que consiste en
un conjunto de proposals del IETF que delinean un protocolo
IP seguro para
IPv4 y IPv6. IPSec provee encriptación a nivel de
IP.
El método de
túneles, como fue descrita anteriormente, es una forma de
crear una red privada. Permite encapsular paquetes dentro de
paquetes para acomodar protocolos incompatibles. Dentro de los
protocolos que se usan para la metodología de túneles se encuentran
Point-to-Point Tunneling Protocol (PPTP), Layer-2 Fowarding
Protocol (L2FP) y el modo túnel de IPSec.
Protocolos utilizados en las
VPNs
Point-to-Point Tunneling Protocol fue desarrollados por
ingenieros de Ascend Communications, U.S. Robotics, 3Com
Corporation, Microsoft, y
ECI Telematics para proveer entre usuarios de acceso remoto y
servidores de
red una red privada virtual.
Como protocolo de túnel, PPTP encapsula
datagramas de cualquier protocolo de red en datagramas IP, que
luego son tratados como
cualquier otro paquete IP. La gran ventaja de este tipo de
encapsulamiento es que cualquier protocolo puede ser ruteado a
través de una red IP, como Internet.
PPTP fue diseñado para permitir a los usuarios
conectarse a un servidor RAS
desde cualquier punto en Internet para tener la misma
autenticación, encriptación y los mismos accesos de
LAN como si discaran directamente al servidor. En vez de discar a
un modem
conectado al servidor RAS, los usuarios se conectan a su
proveedor y luego "llaman" al servidor RAS a través de
Internet utilizando PPTP.
Existen dos escenarios comunes para este tipo de
VPN:
- el usuario remoto se conecta a un ISP que provee el
servicio de PPTP hacia el servidor RAS. - el usuario remoto se conecta a un ISP que no provee
el servicio de PPTP hacia el servidor RAS y, por lo tanto, debe
iniciar la conexión PPTP desde su propia máquina
cliente.
Para el primero de los escenarios, el usuario remoto
estable una conexión PPP con el ISP, que luego establece
la conexión PPTP con el servidor RAS. Para el segundo
escenario, el usuario remoto se conecta al ISP mediante PPP y
luego "llama" al servidor RAS mediante PPTP. Luego de establecida
la conexión PPTP, para cualquiera de los dos casos, el
usuario remoto tendrá acceso a la red corporativa como si
estuviera conectado directamente a la misma.
La técnica de encapsulamiento de PPTP se basa en
el protocolo Generic Routing Encapsulation (GRE), que puede ser
usado para realizar túneles para protocolos a
través de Internet. La versión PPTP, denominada
GREv2, añade extensiones para temas específicos
como Call Id y velocidad de
conexión.
El paquete PPTP está compuesto por un header de
envío, un header Ip, un header GREv2 y el paquete de
carga. El header de envío es el protocolo enmarcador para
cualquiera de los medios a
través de los cuales el paquete viaja, ya sea Ethernet,
frame relay,
PPP. El header IP contiene información relativa al paquete
IP, como ser, direcciones de origen y destino, longitud del
datagrama enviado, etc. El header GREv2 contiene
información sobre el tipo de paquete encapsulado y datos
específicos de PPTP concernientes a la conexión
entre el cliente y servidor. Por último, el paquete de
carga es el paquete encapsulado, que, en el caso de PPP, el
datagrama es el original de la sesión PPP que viaja del
cliente al servidor y que puede ser un paquete IP, IPX, NetBEUI,
entre otros. La siguiente figura ilustra las capas del
encapsulamiento PPTP.
Para la autenticación, PPTP tiene tres opciones
de uso: CHAP, MS-CHAP y aceptar cualquier tipo, inclusive
texto plano.
Si se utiliza CHAP, standard en el que se intercambia un
"secreto" y se comprueba ambos extremos de la conexión
coincidan en el mismo, se utiliza la contraseña de
Windows NT, en
el caso de usar este sistema
operativo, como secreto. MS-CHAP es un standard propietario
de Microsoft y resulta ser una ampliación de CHAP. Para la
tercer opción, el servidor RAS aceptará CHAP,
MS-CHAP o PAP (Password Autenthication Protocol), que no encripta
las contraseñas.
Para la encriptación, PPTP utiliza el sistema RC4
de RSA, con una clave de sesión de 40 bits.
IPSec trata de remediar algunas falencias de IP, tales
como protección de los datos transferidos y
garantía de que el emisor del paquete sea el que dice el
paquete IP. Si bien estos servicios son distintos, IPSec da
soporte a ambos de una manera uniforme.
IPSec provee confidencialidad, integridad, autenticidad
y protección a repeticiones mediante dos protocolos, que
son Authentication Protocol (AH) y Encapsulated Security Payload
(ESP).
Por confidencialidad se entiende que los datos
transferidos sean sólo entendidos por los participantes de
la sesión.
Por integridad se entiende que los datos no sean
modificados en el trayecto de la comunicación.
Por autenticidad se entiende por la validación de
remitente de los datos.
Por protección a repeticiones se entiende que una
sesión no pueda ser grabada y repetida salvo que se tenga
autorización para hacerlo.
AH provee autenticación, integridad y
protección a repeticiones pero no así
confidencialidad. La diferencia más importante con ESP es
que AH protege partes del header IP, como las direcciones de
origen y destino.
ESP provee autenticación, integridad,
protección a repeticiones y confidencialidad de los datos,
protegiendo el paquete entero que sigue al header.
AH sigue al header IP y contiene diseminaciones
criptográficas tanto en los datos como en la
información de identificación. Las diseminaciones
pueden también cubrir las partes invariantes del header
IP.
El header de ESP permite rescribir la carga en una forma
encriptada. Como no considera los campos del header IP, no
garantiza nada sobre el mismo, sólo la carga.
Una división de la funcionalidad de IPSec es
aplicada dependiendo de dónde se realiza la
encapsulación de los datos, si es la fuente original o un
gateway:
- El modo de transporte
es utilizado por el host que genera los paquetes. En este modo,
los headers de seguridad son antepuestos a los de la capa de
transporte, antes de que el header IP sea incorporado al
paquete. En otras palabras, AH cubre el header TCP y algunos
campos IP, mientras que ESP cubre la encriptación del
header TCP y los datos, pero no incluye ningún campo del
header IP. - El modo de túnel es usado cuando el header IP
entre extremos está ya incluido en el paquete, y uno de
los extremos de la conexión segura es un gateway. En
este modo, tanto AH como ESP cubren el paquete entero,
incluyendo el header IP entre los extremos, agregando al
paquete un header IP que cubre solamente el salto al otro
extremo de la conexión segura, que, por supuesto, puede
estar a varios saltos del gateway.
Los enlaces seguros de IPSec
son definidos en función de
Security Associations (SA). Cada SA está definido para un
flujo unidireccional de datos y generalmente de un punto
único a otro, cubriendo tráfico distinguible por un
selector único. Todo el tráfico que fluye a
través de un SA es tratado de la misma manera. Partes del
tráfico puede estar sujeto a varios SA, cada uno de los
cuales aplica cierta transformación. Grupos de SA son
denominados SA Bundles. Paquetes entrantes pueden ser asignados a
un SA específico por los tres campos definitorios: la
dirección IP de destino, el índice
del parámetro de seguridad y el protocolo de seguridad. El
SPI puede ser considerado una cookie que es repartido por el
receptor del SA cuando los parámetros de la
conexión son negociados. El protocolo de seguridad debe
ser AH o ESP. Como la dirección IP de destino es parte de
la tripleta antes mencionada, se garantiza que este valor sea
único.
Un ejemplo de paquete AH en modo túnel
es:
Un ejemplo de paquete AH en modo transporte
es:
Como ESP no puede autentificar el header IP más
exterior, es muy útil combinar un header AH y ESP para
obtener lo siguiente:
Este tipo de paquete se denomina Transport
Adjacency.
La versión de entunelamiento
sería:
Sin embargo, no es mencionado en las RFC que definen
estos protocolos. Como en Transport Adjacency, esto
autenticaría el paquete completo salvo algunos pocos
campos del header IP y también encriptaría la
carga. Cuando un header AH y ESP son directamente aplicados como
en esta manera, el orden de los header debe ser el indicado. Es
posible, en el modo de túnel, hacer una
encapsulación arbitrariamente recursiva para que el orden
no sea el especificado.
Layer-2 Tunneling Protocol (L2TP) facilita el
entunelamiento de paquetes PPP a través de una red de
manera tal que sea lo más transparente posible a los
usuarios de ambos extremos del túnel y para las
aplicaciones que éstos corran.
El escenario típico L2TP, cuyo objetivo es la
creación de entunelar marcos PPP entre el sistema remoto o
cliente LAC y un LNS ubicado en una LAN local, es el que se
muestra en la siguiente figura:
Un L2TP Access
Concentrator (LAC) es un nodo que actúa como un extremo de
un túnel L2TP y es el par de un LNS. Un LAC se
sitúa entre un LNS y un sistema remoto y manda paquetes
entre ambos. Los paquetes entre el LAC y el LNS son enviados a
través del túnel L2TP y los paquetes entre el LAC y
el sistema remoto es local o es una conexión
PPP.
Un L2TP Network Server (LNS) actúa como el otro
extremo de la conexión L2TP y es el otro par del LAC. El
LNS es la terminación lógica
de una sesión PPP que está siendo puesta en un
túnel desde el sistema remoto por el LAC.
Un cliente LAC, una máquina que corre nativamente
L2TP, puede participar también en el túnel, sin
usar un LAC separado. En este caso, estará conectado
directamente a Internet.
El direccionamiento, la autenticación, la
autorización y el servicio de cuentas son
proveídos por el Home LAN’s Management
Domain.
L2TP utiliza dos tipos de mensajes: de control y de
datos. Los mensajes de control son usados para el
establecimiento, el mantenimiento
y el borrado de los túneles y las llamadas. Utilizan un
canal de control confiable dentro de L2TP para garantizar el
envío. Los mensajes de datos encapsulan los marcos PPP y
son enviados a través del túnel.
La siguiente figura muestra la relación entre los
marcos PPP y los mensajes de control a través de los
canales de control y datos de L2TP.
Los marcos PPP son enviados a través de un canal
de datos no confiable, encapsulado primero por un encabezado L2TP
y luego por un transporte de paquetes como UDP, Frame Relay o
ATM. Los mensajes
de control son enviados a través de un canal de control
L2TP confiable que transmite los paquetes sobre el mismo
transporte de paquete.
Se requiere que haya números de secuencia en los
paquetes de control, que son usados para proveer el envío
confiable en el canal de control. Los mensajes de datos pueden
usar los números de secuencia para reordenar paquetes y
detectar paquetes perdidos.
Al correr sobre UDP/IP, L2TP utiliza el puerto 1701. El
paquete entero de L2TP, incluyendo la parte de datos y el
encabezado, viaja en un datagrama UDP. El que inicia un
túnel L2TP toma un puerto UDP de origen que esté
disponible, pudiendo ser o no el 1701 y envía a la
dirección de destino sobre el puerto 1701. Este extremo
toma un puerto libre, que puede ser o no el 1701, y envía
la respuesta a la dirección de origen, sobre el mismo
puerto iniciador. Luego de establecida la conexión, los
puertos quedan estáticos por el resto de la vida del
túnel.
En la autenticación de L2TP, tanto el LAC como el
LNS comparten un secreto único. Cada extremo usa este
mismo secreto al actuar tanto como autenticado como
autenticador.
Sobre la seguridad del paquete L2TP, se requiere que el
protocolo de transporte de L2TP tenga la posibilidad de brindar
servicios de encriptación, autenticación e
integridad para el paquete L2TP en su totalidad. Como tal, L2TP
sólo se preocupa por la confidencialidad, autenticidad e
integridad de los paquetes L2TP entre los puntos extremos del
túnel, no entre los extremos físicos de la
conexión.
Configuración de una VPN bajo
Windows
Para configurar una VPN bajo Windows se
necesita lo siguiente:
- Conexión a Internet tanto para el servidor
local de NT como para las máquinas
remotas. - Una dirección IP estática
para el servidor NT. - Proxy que se ejecute en el servidor NT, para evitar
el acceso desautorizado al sistema. - Direcciones IP para los recursos a
compartir. - Adaptador virtual de la red instalado en la
máquina remota o cliente.
La secuencia de pasos es:
- Hacer una lista de las direcciones IP de los recursos
que serán compartidos a través de
Internet. - Instalación y ejecución del proxy.
- En el servidor NT, se deben configurar los archivos del
usuario NT para que pueda llamar y conectarse al servidor,
garantizando su acceso al sistema con los permisos de la
VPN.
Luego de estos pasos, se deberá instalar el
adaptador privado de la red en la máquina cliente, como se
indica:
- Dentro del Diálogo de Red, que se muestra debajo, y
al cual se accede a través de la opción
Propiedades del icono Entorno de Red, se presiona el
botón Add.
- Aparecerá la siguiente pantalla, se
deberá seleccionar Adapter y luego presionar el
botón Add.
- Aparece el cuadro Select Network adapters, donde se
deberá elegir el fabricante y el adaptador como se
muestra en la siguiente figura:
- Posteriormente, para instalar la conexión a la
LAN, se deberá acceder al Acceso Remoto a
Redes
- Se selecciona Make a New Connection, apareciendo la
siguiente pantalla, donde se podrá elegir el adaptador
de VPN:
- Luego de presionar el botón Next, se
deberá introducir la dirección IP del servidor
VPN en la siguiente pantalla:
- Así se finaliza la creación de la
nueva conexión:
Para acceder al servidor NT, se abre el Acceso Remoto a
Redes:
Al hacer doble-click en el icono de la conexión
VPN, aparecerá la siguiente pantalla, donde se debe
introducir el nombre de usuario, la contraseña y la
dirección IP del servidor NT:
Para configurar el servidor VPN, se deberá
configurar PPTP, activar el filtro PPTP y activar el soporte PPTP
en los clientes.
Para configurar PPTP en el servidor RAS y en los
clientes que vayan a utilizarlo, se deberán realizar los
siguientes pasos:
- Dentro de Red en el Panel de
Control, seleccionando Protocolos, se deberá
presionar el botón Agregar:
- Se selecciona Point to Point Tunneling Protocol, y,
luego de copiados los archivos, aparecerá el cuadro de
diálogo Configuración de PPTP. El campo
Número de redes privadas virtuales indica el
número de conexiones PPTP admitidas. En el ejemplo, se
establecen 2 VPN:
- Luego, se inicia la herramienta de
configuración RAS, donde se deben añadir los
puertos virtuales que darán servicio a las redes
privadas virtuales que se deseen establecer. Al presionar el
botón Agregar, se accede al dialogo
Agregar dispositivo RAS:
- Después de ingresadas las entradas, se
presiona Aceptar. Luego se podrá seleccionar cada
entrada del diálogo Instalación de Acceso
Remoto, para configurar el uso del puerto. Las opciones son:
Sólo recibir llamadas o Hacer y recibir
llamadas. - Después de añadir todos los
dispositivos virtuales, se podrá cerrar este
diálogo para volver a la ficha Protocolos. Al
reiniciar la computadora, ya estará configurado el
server.
Para la activación del filtro PPTP, se debe
selecciona la solapa Protocolos de Panel de Configuración
/ Red. Dentro de esta pantalla, se elige Protocolo TCP/IP, luego
Propiedades. En la solapa Dirección IP, se selecciona el
adaptador de red sobre el que se aplicará el filtro. Luego
de presionar el botón Avanzadas, se marca la casilla
Activar filtro PPTP y, por último, se reinicia la
máquina para activar la configuración.
Cuando un cliente se conecta a Internet, el procedimiento
para establecer un túnel VPN consta de dos
pasos:
- Establecimiento por parte del cliente mediante una
conexión de acceso telefónico a través de
un ISP. - Establecimiento de una conexión PPTP con el
servidor RAS.
Cuando un cliente se conecta directamente a Internet, no
es necesario establecer una conexión de acceso
telefónico. Sin embargo, el procedimiento para iniciar la
conexión PPTP con el servidor RAS es idéntico. Para
establecer una conexión PPTP es necesario crear una
entrada especial en la guía telefónica. Esta
entrada se distingue por dos características:
- El campo Marcar utilizado tiene uno de los
dispositivos virtuales VPN añadidos a la
configuración RAS al instalar PPTP. Esta lista
sólo muestra los VPN configurados para hacer
llamadas. - El campo Presentación preliminar de
número telefónico contiene el nombre DNS o la
dirección IP del servidor PPTP.
La creación de una conexión PPTP implica
también dos pasos:
- Se abre la aplicación Acceso telefónico
a redes, utilizando la guía telefónica que
permite acceder al ISP a través de un número de
teléfono y un modem. - Establecida la conexión, se debe abrir la
entrada de la guía telefónica que se conecta al
túnel PPTP mediante un nombre DNS o una dirección
IP.
Si el cliente está conectado directamente a
Internet, sólo es necesario el segundo paso.
Configuración de una VPN bajo
LINUX
En este apartado se explica la configuración del
demonio de VPN (VPND) sobre Debian, pero no debiera traer
ningún problema configurarlo en otra distribución.
VPND permite crear enlaces seguros sobre TCP/IP con
claves de hasta 512 bits y algoritmo de encriptación
BLOWFISH, montando una interfaz virtual serie que proporciona la
posibilidad de enrutamiento de IP entre redes. Los pasos a seguir
son:
- Dar soporte SLIP en el kernel LINUX,
recompilándolo y probando que funcione. - Instalación del paquete vnpd, que, en Debian,
se puede hacer con ‘apt-get install
vpnd’. - Creación de una clave de sesión,
utilizando ‘vpnd –m
/etc/vnpd/vpnd.key’, que debe ser pasada al otro
extremo de la VPN mediante un medio seguro, ya que es la clave
que ambos extremos de la VPN comparten. - Configuración de los extremos de la VPN,
siguiendo la estructura
Cliente/Servidor. A continuación, se muestran el
contenido de los archivos vpnd.conf de
configuración para el servidor y el cliente.
Archivo /etc/vpn/vpnd.conf para el
servidor:
mode server
# Direccion IP y puerto del servidor
server a.b.c.d 2001
# Direccion IP y puerto del cliente
client w.x.y.z 2001
# Direccion IP privada del servidor
local a.b.c.d
# Direccion IP privada del cliente
remote w.x.y.z
# Opciones generales
autoroute
Keepalive 10
noanswer 3
keyfile /etc/vnpd/vnpd.key
pidfile /var/run/vpnd.pid
keyttl 120
ramdomdev /dev/urandom
mtu 1600
Archivo /etc/vpn/vpnd.conf para el
cliente:
mode client
# Direccion IP y puerto del servidor
client w.x.y.z 2001
# Direccion IP y puerto del cliente
server a.b.c.d 2001
# Direccion IP privada del servidor
local w.x.y.z
# Direccion IP privada del cliente
remote a.b.c.d
# Opciones generales
autoroute
Keepalive 10
noanswer 3
keyfile /etc/vnpd/vnpd.key
pidfile /var/run/vpnd.pid
keyttl 120
ramdomdev /dev/urandom
mtu 1600
Una vez creados estos archivos, se podrá levantar
la VPN, iniciando los demonios con ‘/etc/init.d/vpnd
start’. Para comprobar el correcto funcionamiento, se
puede hacer pings a las direcciones privada y del otro
extremo y verificar con ‘ifconfig –a’
que exista una nueva interfaz como la siguiente:
sl0 Link encap: VJ Serial Line IP
Inet addr: 10.0.0.1 P-t-P: 10.0.0.2 Mask :
255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU: 1600
Metric: 1
Rx packets:0 errors: 0 dropped:0 overruns: 0 frame:
0
Compressed: 0
Tx packets:0 errors: 0 dropped:0 overruns: 0
carrier: 0
Collisions: 0 compressed: 0 txqueuelen:
10
RX bytes: 0 (0.0 b) TX bytes; 0 (0.0 b)
Bibliografía
Scott, Charly, Wolfe, Paul, Erwin, Mike: "Virtual
Private Networks", 2° edición, O’Reilly &
Associates, Enero 1999.
Universidad de Valencia: http://www.uv.es/ciuv/cas/vpn/
OpenBSD: http://www.openbsd.org/faq/faq13.html
Gutiérrez González, Ma. Nieves, Sancho
Buzón, Ana Rosa, Casas Cuadrado, Amadeo:
Estudio sobre las VPN (Redes Privadas Virtuales),
http://www.infor.uva.es/~jvegas/docencia/ar/seminarios/VPN.pdf
Valencia, A., Townsley, W., Rubens, A., Pall, G.,
Zorn, G., Palter, B.: RFC 2661,1999.
Autor:
Ing. Mariano Hevia
 Página anterior | Volver al principio del trabajo | Página siguiente  |