REDES VPNs DE ACCESO REMOTO - Universidad Nacional de la

REDES VPNs DE ACCESO REMOTO
Tesina presentada como trabajo final de los estudios en la carrera de
Licenciatura de Informática de la Facultad de Ingeniería de la Universidad
Nacional de la Patagonia San Juan Bosco
Autores:
APU Mario Rubén Mansilla
APU Eduardo Rodolfo Colombres
Tutor de Tesina: Ing. Alejandro Rosales
Trelew Abril 2009
VPNs de Acceso Remoto
Propuesta de Tesina
Redes VPN de acceso Remoto
INTRODUCCIÓN
Las redes privadas virtuales o VPN (Virtual Private Network) por sus
siglas en inglés, han surgido como alternativa de bajo costo a servicios
contratados, dedicados de red de área amplia para las comunicaciones de
datos, tanto para conectar redes distantes como usuarios remotos con la red
de la organización, utilizando una infraestructura de comunicación de datos
pública y compartida.
Las tecnologías de redes privadas virtuales han evolucionado para
representar ya no solo una opción económica para las comunicaciones sino
también como una solución complementaria para lograr eficiencia, velocidad,
seguridad, confiabilidad en otros servicios de red de área amplia. Además se
la considera una herramienta estratégica que permite interconectar en forma
segura redes y equipos externos cuya administración y control están fuera del
alcance de la organización.
Debido a que se utiliza una infraestructura compartida y pública
para la
interconexión, la seguridad de los datos que se transmiten
es
fundamental. En el contexto de una VPN esto se resuelve mediante un protocolo
de túnel, es decir un mecanismo que es capaz de encapsular paquetes de
protocolos arbitrarios, mediante el agregado de encabezados, utilizando
además mecanismos para preservar la confidencialidad e integridad de los
datos enviados.
En la actualidad existe una gran diversidad de tecnologías que
implementan VPN, lo cual
permite clasificarlas según distintos criterios,
por ejemplo en función de quien provee el servicio (el usuario o un ISP),
según en que capa del modelo de referencia ISO/OSI se establece la VPN (VPN
de capa 2, capa 3 o de transporte/aplicación) o de acuerdo a la topología de
interconexión utilizada (VPN punto a punto o punto multipunto).
De acuerdo a este último criterio,
generales, dos escenarios donde se aplican
sitios, es decir dos redes y al comunicar
conoce como VPN sitio a sitio y VPN de acceso
se pueden apreciar en términos
las VPNs, al interconectar dos
dos hosts entre sí, a esto se
remoto respectivamente.
Las redes privadas virtuales de acceso remoto son el mecanismo ideal
para extender o acercar los servicios de
red local, en forma completa o
parcial, a los usuarios itinerantes y tele trabajadores. Esta circunstancia
dista de ser ideal si no se tiene en cuenta, nuevamente, el aspecto seguridad
respecto a validar a quién se conecta y de acuerdo a esto, que permisos y
autorizaciones posee. Estas precauciones deben
reflejar las
políticas de
seguridad de la información definidas previamente por la organización.
1
VPNs de Acceso Remoto
OBJETIVOS GENERALES

Investigar las características, componentes, mecanismos de una VPN de
acceso remoto y como solucionan la necesidad de un ingreso seguro a los
recursos informáticos de la organización desde cualquier sitio.

Aplicar los conceptos de VPN de acceso remoto a través de una solución
que implemente un cliente VPN portátil que evite la instalación de
programas para esta tarea.
OBJETIVOS PARTICULARES

Determinar las características necesarias para que una solución sea
considerada una VPN.

Determinar las ventajas y desventajas de la utilización de IPSec y SSL
en la implementación de VPNs de acceso remoto.

Investigar diferentes enfoques para la creación de una distribución
LINUX específica para el desarrollo de la práctica.

Evaluar alternativas de lenguajes de programación para el desarrollo de
aplicaciones a utilizar en la práctica.

Evaluar alternativas de software de virtualización que sean portables
para el desarrollo de la práctica.
FUNDAMENTACIÓN
En la actualidad existe un incremento de las conexiones de banda
ancha tanto en puntos de acceso comerciales
como en los hogares. Este
aumento se observa también en la capacidad de ancho de banda ofrecido. Esta
situación beneficia
la puesta en práctica de VPN de acceso remoto. Una
actividad muy popular es el tele trabajo, que permite desde otra ubicación
física contar con los recursos de la información que se poseen en la oficina.
Las organizaciones o empresas necesitan de estas herramientas para poder
adaptarse al dinamismo de los negocios de hoy en día.
Esto genera una problemática que combina aspectos de seguridad y
facilidad de uso. Se puede considerar estos dos aspectos antagónicos.
Mientras más seguridad se quiera aplicar menos dinámico y transparente se
torna el proceso o tarea requerida (utilización de certificados, claves de
acceso, mecanismos de distribución de claves). Tampoco se puede priorizar la
facilidad de uso sobre la seguridad, porque se estaría poniendo en riesgo el
recurso más valioso de una organización que es la información, los sistemas
que la generan y los datos que estos procesan. En este campo, algo que no es
negociable es la seguridad.
Se trata, entonces, de buscar una solución que balancee seguridad
con facilidad de uso. Es este intento de equilibrio y la importancia de la
flexibilidad del acceso remoto para los usuarios de una red, que motivan la
realización de este trabajo.
Para esto se desarrolla un cliente sobre plataforma LINUX que se
conecta con un servidor VPN. El cliente se ejecuta en una máquina virtual la
cual reside en un dispositivo USB (pendrive). La aplicación que virtualiza el
sistema LINUX se ejecuta en la plataforma más popular en la actualidad.
2
VPNs de Acceso Remoto
ORGANIZACIÓN DEL TRABAJO
El siguiente trabajo se compone de cuatro capítulos donde se
desarrollarán los diversos temas relacionados con las redes privadas
virtuales (VPNs) en general y aquellos en particular referidos a las VPNs de
acceso remoto.
Las redes privadas virtuales resulta ser un tema amplio que
involucra diversos conceptos. Un desarrollo particular de la teoría sin
referir el contexto general resulta en un desarrollo aislado que impide la
compresión correcta del tema particular. Por esta razón se dedicó un par de
capítulos a las definiciones y teoría general para introducir el tema
principal el cual es sujeto de este trabajo.
El capítulo 1 refiere a definiciones y terminología utilizada en la
teoría de las VPNs, además presenta las diversas clasificaciones, los
criterios que provocan tales distinciones y las aplicaciones.
En el capítulo 2 se desarrollan las arquitecturas, los protocolos y
las aplicaciones de las redes privadas virtuales. Dentro de las arquitecturas
se mencionan las tecnologías involucradas. En cuanto a los protocolos VPN se
destacan IPSec, L2TP y SSL, los cuales serán referidos en el capítulo
dedicado a las VPNs de acceso remoto.
El capítulo 3 esta dedicado a las VPNs de acceso remoto. Su
desarrollo presenta los requerimientos de seguridad y todo lo concerniente a
la arquitectura de seguridad, los escenarios de acceso remoto existentes, los
protocolos más utilizados y características de las soluciones VPN de acceso
remoto.
Finalmente el capítulo 4 presenta el desarrollo del trabajo práctico
realizado como aplicación y las conclusiones del mismo.
3
VPNs de Acceso Remoto
Índice
CAPÍTULO 1 –INTRODUCCIÓN A LAS VPN ..........................................7
1.1 DEFINICIONES Y TERMINOLOGÍA .............................................................................................. 8
1.1.1 Red Privada............................................................................................................................... 8
1.1.2 Red Pública ............................................................................................................................... 9
1.1.3 Red Privada Virtual .................................................................................................................. 9
1.1.4 Definición de VPN ..................................................................................................................10
1.1.5 Terminología............................................................................................................................11
1.2 CLASIFICACIÓN .........................................................................................................................13
1.2.1 VPNs provistas por el cliente o por el proveedor ............................................................13
1.2.2 VPNs Sitio a Sitio y de Acceso Remoto..............................................................................16
1.2.3 VPNs de capa 2 y capa 3 ....................................................................................................17
1.2.4 Integración de las clasificaciones......................................................................................18
1.2.5 Confiables y Seguras .............................................................................................................20
1.2.6 Overlay y Peer ........................................................................................................................20
1.2.7 No Orientadas y orientadas a la conexión ......................................................................23
1.2.8 VPN de capa de transporte/aplicación...........................................................................23
1.2.9 VPN multiservicio ....................................................................................................................24
1.3 APLICACIONES ...........................................................................................................................24
1.3.1 Intranet /Intranet extendida ................................................................................................24
1.3.2 Extranets ...................................................................................................................................25
1.3.3 Servicio VPN provisto por un proveedor ...........................................................................25
CAPÍTULO 2 – ARQUITECTURAS, CLASIFICACIÓN Y PROTOCOLOS .....................29
2.1 INTRODUCCIÓN A LAS ARQUITECTURAS DE VPN ................................................................30
2.1.1 Componentes de una Red Privada Virtual ......................................................................31
2.1.2 Hardware .................................................................................................................................31
2.1.3 Seguridad de la infraestructura ..........................................................................................32
2.1.4 Infraestructura de soporte para el servicio del proveedor...........................................33
2.1.5 Redes Públicas........................................................................................................................33
2.1.6 Túneles ......................................................................................................................................34
2.2 ARQUITECTURAS .........................................................................................................................34
2.2.1 Basadas en software .............................................................................................................34
2.2.2 Basadas en la Implementación..........................................................................................34
2.2.3 Basada en Seguridad ...........................................................................................................35
2.2.4 Iniciadas por el cliente..........................................................................................................37
2.2.5 Dirigidas....................................................................................................................................37
2.2.6 Basado en la capa................................................................................................................37
2.2.7 Basada en Clases...................................................................................................................38
2.2.8 Basada en Caja Negra.........................................................................................................39
2.2.9 Basada en Acceso Remoto.................................................................................................39
2.2.10 VPN múltiple servicios..........................................................................................................39
2.3 PROTOCOLOS DE TÚNEL...........................................................................................................41
2.3.1 Requerimientos de un Túnel.................................................................................................42
2.4 PROTOCOLOS DE TÚNEL CAPA 2 ...........................................................................................45
2.4.1 Point to Point Protocol (PPP) ................................................................................................45
4
VPNs de Acceso Remoto
2.4.2 Point to Point Tunneling Protocol (PPTP) ............................................................................46
2.4.3 Layer 2 Forwarding Protocolo (L2F)....................................................................................48
2.4.4 Layer 2 Tunneling Protocolo (L2TP) .....................................................................................48
2.5 PROTOCOLOS DE TÚNEL CAPA 3 ...........................................................................................51
2.5.1 IP Security Protocol (IPSec)...................................................................................................51
2.5.2 Generic Routing Encapsulation protocol (GRE) ..............................................................59
2.5.3 Multiprotocol Label Switching (MPLS) ................................................................................61
2.6 PROTOCOLOS DE TÚNEL CAPA 4 ...........................................................................................62
2.6.1 Secure Shell (SSH) ...................................................................................................................62
2.6.2 Secure Sockets Layer/Transport Layer Security (SSL/TLS) ...............................................64
2.7 TOPOLOGÍAS ..............................................................................................................................64
2.7.1 Escenarios ................................................................................................................................65
2.7.2 Topología Punto a Punto......................................................................................................67
2.7.3 Topología Punto a Multipunto.............................................................................................68
2.7.4 Topología Estrella (Hub and Spokes) .................................................................................69
2.7.5 Topología de Malla Completa o Parcial (Full or Partial Mesh).....................................70
CAPÍTULO 3 – VPN DE ACCESO REMOTO ..........................................72
3.1 INTRODUCCIÓN .........................................................................................................................73
3.1.1 Requerimientos básicos de seguridad ..............................................................................74
3.1.2 Configuración de las políticas de seguridad...................................................................75
3.1.3 Auditoría...................................................................................................................................75
3.2 ESCENARIOS................................................................................................................................76
3.2.1 Tele trabajadores/usuarios móviles operando dispositivos propios ............................76
3.2.2 Acceso con un dispositivo propio a la red local desde una extranet .......................77
3.2.3 Acceso desde una extranet con un dispositivo propio de esta, a la red local.......77
3.2.4 Acceso de usuarios móviles desde dispositivos públicos ..............................................77
3.3 ARQUITECTURA DE SEGURIDAD ..............................................................................................78
3.3.1 Gateway VPN y Firewall, seguridad en la frontera.........................................................79
3.3.2 Disponibilidad .........................................................................................................................84
3.3.3 Autenticación, Autorización y Registro (AAA) .................................................................86
3.3.4 Administración y monitoreo.................................................................................................88
3.4 PROTOCOLOS ............................................................................................................................89
3.4.1 SSH .............................................................................................................................................89
3.4.2 IPSec..........................................................................................................................................91
3.4.3 SSL/TLS .......................................................................................................................................94
3.4.4 Comparativa de las tecnologías de acceso remoto ....................................................94
3.5 SOLUCIONES VPNs DE ACCESO REMOTO ............................................................................99
3.5.1 IPSEC .......................................................................................................................................100
3.5.2 SSL/TLS .....................................................................................................................................101
CAPÍTULO 4 – TRABAJO PRÁCTICO .............................................102
4.1 INTRODUCCIÓN .......................................................................................................................103
4.2 ALCANCES ................................................................................................................................104
4.3 FUNCIONAMIENTO ..................................................................................................................105
4.3.1 Perfiles de usuarios ...............................................................................................................105
4.3.2 Esquema de validación......................................................................................................105
4.3.3 Servicios..................................................................................................................................105
4.3.4 Gateway VPN .......................................................................................................................106
4.4 TECNOLOGÍAS DE LA SOLUCIÓN..........................................................................................106
5
VPNs de Acceso Remoto
4.4.1 Lenguajes de programación.............................................................................................106
4.4.2 Entorno de virtualización ....................................................................................................107
4.4.3 Distribución LINUX.................................................................................................................107
4.4.4 Tecnología VPN ....................................................................................................................109
4.5 LA SOLUCIÓN ...........................................................................................................................109
4.5.1 Funcionamiento de la Máquina Virtual ..........................................................................109
4.5.2 Aplicación de gestión de archivos ..................................................................................112
4.6 CONCLUSIONES DEL TRABAJO PRÁCTICO .........................................................................113
ANEXOS ....................................................................114
5.1 ÍNDICES DE FIGURAS................................................................................................................115
5.2 REFERENCIAS BIBLIOGRÁFICAS .............................................................................................116
6
VPNs de Acceso Remoto
CAPÍTULO 1
INTRODUCCIÓN A LAS VPN
1
7
VPNs de Acceso Remoto
1.1 DEFINICIONES Y TERMINOLOGÍA
La importancia de la tecnología de las redes de datos para las
comunicaciones
en
las
organizaciones
(empresas,
instituciones
gubernamentales, no gubernamentales) ha sido fundamental para su desarrollo y
crecimiento, tanto en el aspecto económico y funcional, siendo una
herramienta estratégica que brinda soporte y permite el desenvolvimiento y
transformación de dichas organizaciones. Hoy en día no se puede concebir, a
nivel organizacional, algún cambio, fusión u unión sin considerar las
comunicaciones y las tecnologías de información que le dan soporte.
1.1.1 Red Privada
Las redes de datos interconectaban, en un principio en forma local,
las computadoras personales de una organización, permitiendo compartir la
información, y el trabajo en grupo de una forma más ágil y eficiente. Sin
embargo esto requirió considerar el aspecto de la seguridad, ya que si bien
se trabajaba en un mismo ámbito, es decir dentro de la misma empresa, no
todos los usuarios debían acceder a los datos por igual. Este esquema
funcionó para pequeñas organizaciones, pero para aquellas cuya estructura
incluía sitios geográficamente alejados, surgió la necesidad de interconectar
también dichos lugares.
La solución vino de la mano de los proveedores de servicio de red de
área amplia de datos o WAN (Wide Area Network), a través de la contratación
de enlaces dedicados, los cuales conectaban las redes distantes con la red
central. Esta solución implicaba un costo, que resultó prohibitivo para la
mayoría, excepto para aquellos que podían abonar un
costo fijo de
contratación más un valor que variaba proporcionalmente a la distancia
existente entre los sitios a interconectar (mile-age fee). En la actualidad
existen tecnologías WAN (Frame Relay, ATM1) donde el costo esta en función del
caudal de datos o ancho de banda comprometido del enlace, que una
organización esta dispuesta a pagar, sin considerar ya la distancia
geográfica.
De esta forma se contaba con una red privada o estructura de
comunicación propia, en el sentido de que el control y la administración de
la red estaban bajo el dominio de la organización. Las políticas de uso, los
servicios suministrados, los medios activos y pasivos de comunicación por
donde fluían los datos estaban bajo un control propio. Si bien las
comunicaciones de área amplia eran suministradas por un proveedor, este se
comprometía a respetar los requerimientos de la organización cliente y además
los datos que atravesaban su red, no iban a estar al alcance de otros
clientes.
1
Asynchronous Transfer Mode
8
VPNs de Acceso Remoto
1.1.2 Red Pública
Uno de los eventos mas importantes que acompañó al desarrollo de las
redes en las organizaciones, fue la rápida evolución de la mayor de las redes
IP existentes, Internet. Esta se define como un sistema cooperativo de
interconexión de redes que suministra un servicio de comunicación universal.
De esta manera satisface la necesidad de los usuarios de comunicar dos puntos
cualesquiera, también denominados sistemas o nodos finales, pudiendo acceder
a recursos más allá de los disponibles en un único sistema y ubicados fuera
de los límites de la red local.
Los datos atraviesan redes intermedias hasta llegar a su destino,
en una operación no orientada a la conexión, mediante el uso de equipos
especiales denominados routers, también conocidos como sistemas o nodos
intermedios. La naturaleza no orientada a la conexión de Internet, significa
que no hay una ruta preestablecida o circuito virtual dedicado entre los
sistemas que se comunican, tampoco niveles de servicio, priorización o
separación de tráfico que puedan aplicarse a los datos que se transmiten.
La función de los routers es interconectar al menos dos redes,
transfiriendo paquetes desde una red a otra. Estas pertenecen a diversas
organizaciones y proveedores. Esto convierte a Internet en una red pública,
en el sentido de que son muchos los que participan en su conformación y los
medios de transmisión son compartidos. Dependerá de quien utilice la
infraestructura de Internet para comunicar dos sistemas finales, tomar las
medidas
de
seguridad
apropiadas
para
asegurar
la
confidencialidad,
autenticidad, integridad y no repudio de los datos transmitidos.
1.1.3 Red Privada Virtual
El funcionamiento de algunas organizaciones, determinaron la
necesidad de permitir el acceso a la red propia a usuarios que se encontraban
geográficamente fuera de los límites de ésta. Éstos requerían desplazarse con
frecuencia y en algún momento acceder a sus archivos en la red local, revisar
su correo electrónico o utilizar un sistema de información.
En un principio se utilizaron servicios de acceso remoto mediante
la implementación de servidores para tal fin o RAS (Remote Access Server), el
uso de líneas discadas para la conexión y pools de modems para atender las
llamadas. Toda esta infraestructura era costeada por la organización la cual
era responsable de su administración y mantenimiento. Si bien se solucionaba
el problema de acceso a la red local, se lograba a un costo económicamente
alto.
Otra necesidad fue la de encontrar una alternativa más económica de
interconectar diversas redes entre sí y ya no solamente las de una misma
organización, sino redes de diferentes organizaciones. Razones de política
estratégica justificaban este desafío, ya sea a nivel empresarial,
universitario o gubernamental.
Ambos requerimientos tuvieron su solución a partir de la idea de
utilizar Internet, teniendo en cuenta su alcance global y su capacidad de
entrega de datos a casi cualquier sistema final a un bajo costo.
Dado que se utiliza Internet para transmitir datos, no hay garantía
de que estos no puedan ser captados por terceros. También es claro que los
sistemas finales que se comunican están expuestos.
9
VPNs de Acceso Remoto
En la actualidad no solo se considera a Internet como medio donde
una organización puede implementar una VPN. Los proveedores de servicios de
comunicaciones o SP (Service Provider) ofrecen servicios de VPN de acuerdo a
las necesidades del cliente a través de su red backbone. Un SP puede
administrar múltiples VPNs pertenecientes a varios clientes operando a través
de su backbone.
1.1.4 Definición de VPN
Es habitual encontrar varias definiciones sobre VPN, aunque éstas no
difieren en esencia. Algunas de ellas pueden ser:
“Una VPN es una red privada construida dentro de una infraestructura
de red pública, como la red Internet”2
“La idea básica de una VPN es muy simple. Una corporación podría
tener un número de oficinas (o grupos de ellas) en diferentes lugares, y en
cada uno de estos tener su propia red local. Muchas corporaciones han
aumentado la cantidad de empleados que deben trabajar en forma remota, ya sea
desde sus hogares o en forma itinerante. Interconectar estas redes y lugares
mediante una red compartida (no privada) crea una VPN”3
“Una
red
privada
virtual
basada
en
Internet
utiliza
la
infraestructura abierta y distribuida de Internet para transmitir datos entre
sitios corporativos” 4
“Una red privada virtual es una red privada de datos que utiliza una
infraestructura de telecomunicación pública, manteniendo la privacidad
mediante protocolos de túnel y procedimientos seguros.
....El propósito principal de una VPN es dar a la compañía la misma
capacidad que otorgan los enlaces dedicados contratados pero a un costo
menor, utilizando medios de comunicación públicos.” 5
Se puede definir a una VPN de manera más formal. Esta definición
aparece publicada en el artículo What Is a VPN? Part 1 escrito por Ferguson y
Houston para la publicación mensual The Internet Protocol Journal de Cisco
System en Marzo de 2001:
“Una VPN es un ambiente de comunicaciones en el cual existe un
control de acceso, para permitir la conexión entre sistemas pares únicamente
dentro de una comunidad de interés definida, y está creado considerando
alguna forma de partición de un medio de comunicación subyacente, donde este
brinda servicios a la red de una forma no exclusiva.”
De acuerdo a estas definiciones se puede decir que una red privada
virtual es una red, que comunica dos o más dispositivos finales (estos a su
vez pueden interconectar una red completa) que pueden estar ubicados
geográficamente distantes y representan una comunidad de interés. Para esto
se utiliza como medio de transmisión una estructura compartida común a varios
usuarios. Ésta puede ser Internet o la red principal o backbone de un
proveedor de servicios de comunicaciones.
2
What Is a VPN? Part I by Ferguson -Houston - The Internet Protocol Journal Marzo 2001 Cisco System
3
VPN Technologies a Comparison by Finlayson-Harrison-Sugarman – Data Connection Limited Febrero 2003
4
Virtual Private Networks (VPNs) – Web ProForum Tutorials - IEC
5
VPN Technologies: Definitions and Requirements by VPN Consortium – Marzo 2006
10
VPNs de Acceso Remoto
Se dice privada porque los dispositivos que no participan en esta
comunicación no tienen acceso al contenido de la misma y de hecho no son
conscientes de su establecimiento. El acceso a esta red y su administración
está restringido solo a un número limitado de dispositivos. La privacidad se
aplica también al espacio de direccionamiento y esquema de enrutamiento
utilizado en una
VPN, en el sentido de que están separados o difieren de
aquellos instrumentados en alguna otra red privada existente o en la
infraestructura de red subyacente por donde ocurre la comunicación.
El concepto de virtual, por definición es la representación de un
objeto no existente mediante la ejecución de funciones que simulan su
existencia. En el contexto de una VPN, significa que esta última representa
una red de comunicaciones, que no tiene una contraparte física real. Este
concepto fundamenta la
naturaleza discreta o de separación, de una red
lógica privada funcionando sobre una infraestructura de comunicaciones
compartida y real. El aspecto de privacidad, definido en el párrafo anterior,
está en función de la virtualización.
1.1.5 Terminología
La literatura relacionada con redes privadas virtuales esta plagada
de acrónimos, siglas, términos muy específicos que tornan difícil la
interpretación de cualquier lectura relacionada con el tema. Esta sección
define los principales elementos que componen un escenario VPN.

Sitio: ubicación geográfica con uno o más usuarios o uno o más
servidores o una combinación de servidores y usuarios. El usuario
refiere al host o estación de trabajo.

Servidor VPN: software o firmware VPN el cual se ejecuta en un
dispositivo. Tiene la función de establecer un túnel con un cliente
VPN. Previamente verifica la identidad del cliente para autorizar su
acceso y determinar los permisos de este para acceder a los recursos
locales. El dispositivo donde se ejecuta el servidor VPN puede ser un
host, router o switch. Este equipo comunica la red local con la red
pública. Otras acepciones pueden ser: gateway VPN, servidor de
túneles.

Cliente VPN: software o firmware VPN ejecutándose en un dispositivo,
cuya función es establecer un túnel con un servidor VPN. Previamente,
debe presentar las credenciales correctas al servidor. Otra acepción
puede ser cliente de túnel.

Túnel: Enlace lógico entre el servidor y cliente VPN, creado por un
protocolo de túnel. Por este canal se envían los datos que han sido
encapsulados y quizás encriptados por el protocolo. Es posible
transmitir datos sin encriptar por un túnel. Un túnel puede
establecerse en diferentes capas del modelo ISO/OSI de protocolos de
comunicaciones.

Extremos de un túnel: dispositivos que gestionan la creación, el
establecimiento y la finalización de un túnel mediante la ejecución
de software o firmware dedicado para tal fin, por lo tanto se
encargan
también
del
procesamiento
relacionado
con
la
des/encapsulación, des/encriptación y transmisión de los paquetes
recibidos.
11
VPNs de Acceso Remoto

NAS (Network Access Server): servidor de acceso de red, un
dispositivo que representa una interfase entre un medio de acceso
como la red de telefonía y una red de conmutación de paquetes, como
el backbone de un proveedor o Internet. En una VPN este dispositivo
permite que un usuario utilizando un acceso telefónico acceda a su
red mediante un túnel creado por el NAS hacia el servidor de acceso
remoto de la red destino.

Túnel voluntario (Voluntary Tunnel): Túnel creado y configurado a
partir de la solicitud de un cliente VPN. Esta clase de túnel es
común en las VPN de acceso remoto, donde uno de los extremos es una
computadora personal o notebook de un usuario hogareño o móvil.

Túnel obligatorio (Compulsory Tunnel): Túnel asociado con las VPN de
acceso remoto. Su creación y configuración está a cargo de un
dispositivo denominado servidor de acceso de red o NAS. Éste se ubica
entre la PC del usuario y el servidor VPN. En el NAS se ubica el
extremo del túnel donde funciona el cliente VPN. Es posible que
múltiples usuarios conectados al servidor de acceso de red, compartan
el túnel en forma concurrente. En general el NAS es propiedad y es
administrado por un proveedor de servicios. Ver más detalles en el
capítulo 2”Protocolos de túnel capa 2”.

Dispositivo de borde: Es el dispositivo ubicado en la frontera entre
la red local y la red pública.

CE: Dispositivo de borde del cliente (Customer Edge Device). Es el
equipo perteneciente a un cliente de un servicio de comunicaciones
que se sitúa en el borde de la red privada local y conecta con la red
del proveedor del servicio a través de un PE. Un CE puede ser un
router o switch.

C: Dispositivo que pertenece al cliente y que se ubica dentro de la
red del mismo. Estos no tiene conectividad directa con la red del
Proveedor ni participan de la VPN. Pueden ser routers o switchs.

PE: Dispositivo de borde del proveedor (Provider Edge Device). Este
es propiedad del proveedor de servicio de comunicaciones. Se conecta
directamente a la red del cliente a través del CE. Un PE puede ser un
router, switch o un dispositivo que combine ambas funciones.

P: Dispositivos que componen el núcleo de la red del Proveedor. No
tienen conectividad directa con la red del cliente ni participan de
las VPN. Estos son equipos como routers y switches.
12
VPNs de Acceso Remoto
Figura 1-1 Componentes de una VPN
1.2 CLASIFICACIÓN
Se pueden encontrar
varias clasificaciones de las VPN, lo cual
puede generar cierta confusión. Esto se debe a que existen diversos tipos de
tecnologías y clases de redes privadas virtuales, lo que permite más de un
criterio de organización.
Las clasificaciones generales y más habituales son:

De acuerdo a quien implementa y administra el servicio: la propia
organización o un proveedor de servicios.

Según que comunican: redes entre sí o usuarios a la red.

Según la capa del modelo de referencia de pila ISO/OSI para
comunicaciones donde se establece la VPN: capa 2, 3 y las VPNs de
capa de aplicación/transporte que utilizan el protocolo SSL/TLS.
Estas representan una clase particular de VPN que se describen
aparte.
Otros criterios pueden ser:

Según si los dispositivos de borde de un proveedor participan o no en
el enrutamiento del tráfico de datos del cliente: VPN peer to peer o
VPN overlay.

Según si son orientadas o no a la conexión.

Si son confiables o seguras.
1.2.1 VPNs provistas por el cliente o por el proveedor
Uno de los principales criterios para clasificar las VPN, define
quien esta a cargo de la implementación y administración de la red privada
virtual, ya sea el cliente (la organización) o el proveedor de servicios de
comunicaciones. Esto se refiere a la definición de las políticas a cumplir
con esta solución, los requerimientos para la implementación, la adquisición
y configuración de equipamiento, mantenimiento, resolución de problemas y
monitoreo, especificación del espacio de direccionamiento a utilizar, esquema
de enrutamiento etc.
13
VPNs de Acceso Remoto
VPNS provistas por el cliente (CE o CPE VPN)
También denominadas VPNs del ámbito del cliente (Customer Promises
VPN). Estas VPNs son definidas e implementadas por el cliente de un servicio
de comunicaciones. Generalmente este tiene acceso al backbone de un proveedor
o bien posee un servicio de acceso a Internet. En este contexto el cliente
puede tener más de un sitio propio, geográficamente distante que desea
conectar o bien requiere hacerlo con otra red fuera de su dominio, también
remota.
En este tipo de VPN, el túnel se establece, únicamente, entre los
equipos del cliente. Estos representan los extremos del o los túneles. Los
equipos del proveedor o PE, no participan de la VPN. Tampoco del esquema de
direccionamiento que esta utiliza o del enrutamiento necesario. Tratan a los
paquetes o tramas como proveniente de un cliente del servicio, es decir solo
lo reenvían. En el caso de la utilización de Internet, los routers
intermedios también lo hacen con los paquetes IP, sin tener en cuenta el
contenido encapsulado por el túnel de la VPN.
La ventaja de esta clase de VPN radica en que el cliente tiene el
control de la seguridad aplicada a los datos que transmite. Para el proveedor
sus dispositivos de borde no requieren ninguna configuración especial para el
tratamiento de los paquetes de las VPN, además no surgen problemas de
escalabilidad al momento de aumentar la cantidad de VPNs o los sitios a
interconectar mediante estas ya que, como se mencionó anteriormente, estos
equipos no participan en este escenario virtual.
Como desventaja, el cliente debe hacerse cargo básicamente de todo.
Esto puede implicar un gran costo, tanto en la compra de equipamiento, como
en la preparación de personal para la configuración y el mantenimiento de la
VPN. Esta solución presenta problemas de escalabilidad para el cliente cuando
existen varios sitios para interconectar.
Los tipos de VPN provistas por el cliente son:

VPN IPSec
(IP Security)

VPN GRE
(Generic Routing Encapsulation)

VPN SSL/TLS (Secure Sockets Layer/Transport Layer Security)
Figura 1-2 VPN Provista por el Cliente
14
VPNs de Acceso Remoto
VPNs provistas por el Proveedor (PPVPN)
En esta clase de VPN el proveedor de servicio se encarga de su
implementación. Los equipos de borde o PE participan activamente de la red
virtual como así también, pero en menor grado, los dispositivos de borde del
cliente. Esto significa que los PE realizan la mayor parte del procesamiento
específico de la VPN, permitiendo que los equipos CE puedan ser routers o
switches estándar sin necesidad de comprar equipamiento especial.
El proveedor es responsable de la administración de la VPN,
liberando al cliente de estas tareas. Esto resulta, para este último, en un
menor costo de implementación respecto de un emprendimiento propio.
Actualmente los proveedores
ofrecen un servicio de VPN mejorado,
donde suman
además de la conectividad, acuerdos de nivel de servicio,
calidad y diferenciación de servicio, seguridad, ingeniería de tráfico etc.
Esto redunda en un producto con valor agregado que beneficia a ambas partes.
Las soluciones VPN de esta clase, pueden operar en la red de un
único proveedor, entre un conjunto de proveedores de servicio y sobre
Internet. En este
último caso se asume que los routers de núcleo de
Internet, no mantendrán información referida a la VPN, sin considerar si se
utilizan protocolos de enrutamiento para distribuir o no dicha información.
Existen cuatro escenarios donde pueden desplegarse estas VPN 6:

Único Proveedor, único Sistema Autónomo o AS (Autonomous System):
escenario más simple, el servicio se brinda a través del AS de un único
proveedor.

Único Proveedor, múltiples AS: un proveedor administra varios AS
(adquisición de varias redes). Este escenario implica la distribución
con restricciones de la información de enrutamiento entre los diversos
Sistemas Autónomos.

Multi Proveedor: es el caso más complejo, debido a que es necesario
negociar relaciones de confianza entre los backbones de los diversos
proveedores para cumplir con las medidas de seguridad y niveles de
servicio acordados para la VPN de un cliente. En este caso el servicio
se denomina VPN inter-AS o ínter proveedor.

Proveedor de Proveedores (Carrier's Carrier): este es un caso especial
del primer escenario, excepto que los clientes son
proveedores de
servicios de comunicaciones que contratan el servicio de VPN a un
proveedor principal, para ofrecerlo a su vez a sus propios clientes.
Los tipos de VPN provistas por el Proveedor son:
6

VPN VPWS (Virtual Private Wire Service)

VPN VPLS (Virtual Private Lan Service)

VPN IPLS (IP only Private Lan Service)

VPN basada en routers virtuales

VPN IPSec

VPN MPLS (Multiprotocol Label Switching)
RFC 3809 – Generic Requirements for Provider Provisioned VPN
15
VPNs de Acceso Remoto
1.2.2 VPNs Sitio a Sitio y de Acceso Remoto
Otra forma general de distinguir las VPN es en función de si
conectan redes entre sí o usuarios a una red. Una VPN sitio a sitio (site-tosite VPN) conecta dos o más redes entre sí que están geográficamente
dispersas, estas pueden pertenecer a una o varias organizaciones.
Si las redes pertenecen a una misma organización, esta clase de VPN
se denomina intranet. Si las redes pertenecen a varias organizaciones se
conoce como extranet. La intención en este último caso es comunicar
organizaciones diferentes que persiguen un objetivo común y requieren
compartir información útil para el conjunto. El servicio de VPN entre sitios
debería ser independiente del alcance geográfico de la implementación.
Figura 1-3 VPN Sitio a Sitio
Las VPN de Acceso Remoto o RAVPN (Remote Access VPN), también
denominadas VPN de acceso, permiten a los usuarios móviles o itinerantes y a
los usuarios hogareños de una organización o tele trabajadores, acceder en
forma remota a la red. Esta clase de VPN puede establecer un túnel en modo
voluntario u obligatorio.
Figura 1-4 VPN de Acceso Remoto
16
VPNs de Acceso Remoto
Las tecnologías y protocolos asociados a esta clasificación son:
VPNs sitio a sitio:

IPSec

GRE

AtoM

L2TPv3 (Layer 2 Tunneling Protocol version 3)

IEEE 802.1Q

MPLS LSP (MPLS Label Switched Path)
(Any Transport over MPLS)
VPNs de acceso remoto:

L2F

PPTP (Point to Point Tunneling Protocol)

L2TPv2/v3

IPSec

SSL/TLS
(Layer 2 Forwarding)
Algunos de estos serán descriptos más adelante en el capítulo 2
dedicado a protocolos VPN.
1.2.3 VPNs de capa 2 y capa 3
El criterio de esta clasificación se basa en las capas, del modelo
de referencia ISO/OSI de protocolo de comunicaciones, por donde se establece
el túnel de la VPN. Esta clasificación surge a partir de la variedad de
tecnologías existentes que se utilizan para implementar la VPN.
Esta distinción tiene sentido cuando se la aprecia en el contexto de
las clasificaciones anteriores.
Las VPN de capa 2 permiten la conectividad a nivel de la capa de
enlace de datos y puede ser establecida entre switches, routers o hosts. La
comunicación esta basada en el direccionamiento de capa 2 y el reenvío del
tráfico esta basado respecto del enlace entrante y la información de
encabezados de dicha capa, tales como direcciones MAC (Media Access Control)
o DLCI (Frame Relay Data Link Connection Identifier).
Las VPN de capa 3 interconectan hosts o routers, la comunicación se
basa en el direccionamiento a nivel de capa de red. El reenvío del tráfico se
lleva a cabo teniendo en cuenta el enlace entrante y las direcciones del
encabezado IP.
17
VPNs de Acceso Remoto
1.2.4 Integración de las clasificaciones
Las clasificaciones anteriores se pueden integrar para tener una
perspectiva más práctica y operativa de las VPN. Esta integración muestra las
VPN provista por el cliente o proveedor como el criterio de clasificación más
general, dentro de la cual se pueden diferenciar las VPN sitio a sitio y
remota. Finalmente se consideran según las tecnologías VPN de capa 2 y 3. El
siguiente esquema muestra esta relación:
Figura 1-5 Clasificación de las VPN
VPN Sitio a Sitio Provistas por el Proveedor de Capa 2 (L2VPN)
Estas VPN pueden ser establecidas entre switches, routers y hosts,
permitiendo la conectividad a nivel de capa de enlace entre sitios separados.
Tanto el direccionamiento como el reenvío del tráfico de la VPN se llevan a
cabo en función del enlace entrante y de la información del encabezado de
capa 2.
Dentro de las L2VPN se pueden distinguir dos categorías:

VPNs basadas en circuitos Punto a Punto (P2P): conocidas también
como VPWS (Virtual Private Wire Service). Se implementan usando
MPLS o circuitos emulados (pseudowires) L2TPv3.

VPNs Multipunto a Multipunto (M2M): en esta categoría entran las
VPN VPLS (Virtual Private LAN Service) e IPLS (IP-Only LAN
Service).
VPN VPWS
La red del proveedor puede considerarse como una emulación de un
conjunto de enlaces punto a punto o pseudowires entre los sitios del cliente.
Es útil en escenarios donde el cliente ya posee circuitos virtuales ATM o
Frame Relay que interconectan sus redes. En lugar de que el tráfico del
cliente atraviese el backbone hasta su destino en su formato nativo de capa
2, éste es encapsulado y enrutado sobre la infraestructura IP del Proveedor.
El cliente mantiene las conexiones de capa 2 al backbone. Los
routers CE deben seleccionar el circuito virtual a usar para enviar el
tráfico al sitio destino.
18
VPNs de Acceso Remoto
Este esquema permite el reemplazo de redes con topologías estrella
que requieren la interconexión de redes satélites hacia una red central,
permitiendo alternativas de rutas hacia un destino.
Unas de las tecnologías habituales, en el núcleo de la red del
proveedor, para esta clase de VPN es MPLS junto a extensiones conocidas como
PWE3 (Pseudowire Emulation Edge to Edge). Un enfoque más escalable, respecto
de la administración del servicio, utiliza BGP (Border Gateway Protocol) como
protocolo de señalización y auto detección. En este caso, los dispositivos PE
usan BGP multiprotocolo para anunciar los dispositivos CE y VPN que
controlan, junto con las etiquetas MPLS utilizadas para encaminar el tráfico.
De esta forma, cuando los otros CE reciben esta información, saben como
establecer los pseudowires.
VPN VPLS
En este caso la red LAN ethernet de cada sitio del cliente se
extiende hasta el borde de la red backbone del proveedor. Luego, una vez
aquí, se emula la función de un bridge o switch para conectar todas las LANs
del cliente. De esta forma se emula, en la red del proveedor, una única LAN
ethernet. Esta solución provee un servicio punto a multipunto donde los
routers CE envían todo el tráfico, destinados a los otros sitios,
directamente al router PE.
Este servicio se basa en la utilización de pseudowires, combinados
en una topología de malla completa (full mesh) de interconexiones entre los
dispositivos PE que participan en una VPN determinada. Éstos llevan a cabo el
aprendizaje de las direcciones MAC, de la misma forma que un switch ethernet
para reenviar las tramas desde un CE a otro. Así, un CE puede reenviar
tráfico en una forma punto a multipunto a otros CE.
Existe un problema de escalabilidad con este servicio, y tiene que
ver con el incremento de sitios del cliente. Es necesario mantener en los PE
un gran número de direcciones MAC para el reenvío de tramas por sitio de
cliente.
VPN IPLS
Si se requiere intercambiar tráfico IP exclusivamente y los
dispositivos CE son routers IP, entonces es posible el servicio IP sobre LAN.
Si bien se transmiten datagramas IP, el mecanismo de reenvío se basa en
información de encabezado de capa 2.
Dado que el siguiente salto o hop para cada datagrama IP es otro CE,
las únicas direcciones MAC que un PE debe aprender, cuando reenvía las tramas
de capa 2, son aquellas de los routers CE. Esto es una ventaja respecto del
servicio VPLS por el reducido número de direcciones MAC a preservar por sitio
de cliente.
VPN Sitio a Sitio Provistas por el Proveedor
de Capa 3 (L3VPN)
Esta clase de VPN se basa en tecnologías más estables que las
empleadas en las L2VPN, debido al estudio y desarrollo de las mismas. Esto le
permite al proveedor de servicio tener mayor seguridad al momento de
implementar una u otra solución.
19
VPNs de Acceso Remoto
Se pueden dividir a su vez en:

VPN basadas en PE: Los dispositivos PE participan en el
enrutamiento y reenvío del tráfico del cliente basado en el
espacio de direcciones de la red del cliente. En este caso los
CE no participan de la VPN. El tráfico del cliente se reenvía
entre los PE a través de túneles MPLS LSP, IPSec, L2TPv3 o GRE.

VPN basadas en CE: En este caso los túneles son creados entre
los equipos CE, mientras los PE no participan en la VPN, solo
reenvían el tráfico del cliente. Se utiliza IPSec o GRE para
establecer los túneles.
1.2.5 Confiables y Seguras
Esta es una clasificación donde se tiene en cuenta si es o no
necesaria la encriptación y autenticación de los datos a transferir entre los
nodos de la VPN.
Los proveedores que no utilizan encriptación para los datos de sus
clientes debido a que utilizan circuitos virtuales de capa 2 se pueden
definir como VPN Confiables. Podemos mencionar las redes FRAME RELAY, ATM y
MPLS.
En cambio en las VPN Seguras el tráfico de datos es autenticado y
encriptado sobre el backbone del proveedor del servicio. Utilizan los
protocolos IPSEC, SSL, L2TP asegurado mediante IPSEC, PPTP
asegurado con
MPPE (Microsoft Point-to-Point Encryption).
1.2.6 Overlay y Peer
Las VPN overlay se dan entre dispositivos CE, los dispositivos PE no
participan en el enrutamiento de los clientes de la red, sino que reenvían
tráfico de clientes basados en direccionamiento globalmente único, por lo
tanto no tiene conocimiento del direccionamiento utilizado por el cliente.
Los túneles son configurados entre dispositivos CE usando protocolos
como IPSec y GRE. Cabe observar que el modelo overlay tiene serios problemas
de escalabilidad debido a que si se cuenta con muchos nodos de egreso el
número de adyacencias se incrementa en directa proporción con el número de
nodos.
20
VPNs de Acceso Remoto
Figura 1-6 Adyacencias del Ruteo
Pueden ser implementadas a nivel de capa física usando líneas
telefónicas (dialup), a nivel de capa 2 utilizando Frame Relay, X-25 y ATM, o
a nivel de capa 3 utilizando túneles IP o GRE.
Con el fin de clarificar veamos un ejemplo, la Figura 1-6, muestra
un esquema en el que figuran tres sitios. Un sitio se conecta a través de los
circuitos virtuales VC #1 Y VC #2 con otros dos sitios. Si suponemos que el
sitio principal es Londres y los otros son Paris y Zurich podríamos ver que
la percepción que poseen los routers CE es la que grafica la Figura 1-7
21
VPNs de Acceso Remoto
Figura 1-7 Infraestructura del proveedor
Si son reemplazados los dispositivo PE por routers y estos participan en
el enrutamiento entonces es una VPN tipo Peer. Los routers tienen que poseer
conocimiento del direccionamiento que utiliza el cliente. Esto es necesario
debido a que las rutas se intercambian entre dispositivos CE y los
dispositivos PE. Estas VPN son provistas por un proveedor de servicios.
Figura 1-8 VPNs tipo Peer
22
VPNs de Acceso Remoto
En la Figura 1-8 podemos observar que al reemplazar los switches por
routers se convierte en una VPN tipo Peer.
1.2.7 No Orientadas y orientadas a la conexión
Son orientadas o no orientadas a la conexión dependiendo si el
proveedor provee o no circuitos virtuales dedicados.
Orientada a la conexión: Son en las que provee el proveedor un
circuito virtual dedicado. Por ejemplo FRAME RELAY y ATM.
No orientadas a la conexión: Son las que no poseen un circuito
virtual. Por ejemplo las VPN basadas en IP.
1.2.8 VPNs de capa de transporte/aplicación
El protocolo SSH (Secure Shell) desarrollado por Communications
Security Ltd., permite acceder a otro dispositivo a través de una red
insegura, ejecutar comandos a una máquina remota y mover archivos de una
computadora a otra. Utilizando encriptación sobre canales inseguros provee
una fuerte autenticación y encriptación.
Existen dos versiones incompatibles entre sí. Son dos protocolos
totalmente diferentes que usan distinto cifrado.
SSH v1
SSH v2
Autenticación de
sistemas
Llaves de servidor y cliente
Llaves de host
Autenticación
Llaves
Certificados
SSH2 es una completa reescritura del protocolo que lo hace mas
seguro y utiliza una implementación de red totalmente distinta que SSH1.
Debido a la diferente implementación ambos protocolos son incompatibles. Por
ejemplo se lo utiliza para asegurar un túnel PPP. El principio de
funcionamiento es el mismo que el de SSL diferenciándose en la capa en la que
actúan y el método de autenticación.
Capa en la que trabaja
Autenticación
SSH
Aplicación
Llaves
SSL
Transporte
Certificados
También es posible establecer túneles en la capa de aplicación. Para
esto se utiliza un browser del lado del cliente, por lo que no es necesario
instalar ningún programa. La conexión se realiza a un sitio web seguro
mediante el protocolo HTTPS (Hypertext Transfer Protocol Secure).
Además, existen otros productos los cuales ofrecen una combinación
de gran flexibilidad, seguridad y que intentan lograr una configuración que
no requiera mucho conocimiento. La seguridad es lograda mediante cifrado del
tráfico usando el protocolo SSL/TLS.
23
VPNs de Acceso Remoto
1.2.9 VPN multiservicio
Trabajan sobre MPLS, cuyo sello distintivo es la calidad de servicio
o QoS (Quality of Service). El objetivo de estas VPN es integrar diferentes
aplicaciones en una sola conexión: voz, datos, multimedia, etc.
1.3 APLICACIONES
Las VPN se utilizan en situaciones donde es necesario establecer una
comunicación en forma segura utilizando un medio o infraestructura compartida
de transmisión. Además de comunicar redes propias de la organización,
usuarios móviles, tele trabajadores etc. también es posible comunicar
distintas organizaciones entre sí. Esta alternativa surge a partir de la
necesidad de establecer lazos de negocios, o la concreción de intereses
comunes.
La extranet refleja dichos intereses mediante la interconexión de
las redes de datos de las distintas organizaciones. En realidad solo
comparten los recursos necesarios para cumplir con los objetivos comunes, por
lo que el acceso es parcial y controlado.
Finalmente las VPN se pueden considerar como un negocio con valor
agregado en la forma de un servicio. El hecho de que hoy en día las
organizaciones
dependan fuertemente de las tecnologías de información para
su desenvolvimiento y que sus
necesidades sean diferentes, plantea un
mercado donde las soluciones de comunicaciones de datos son casi a la medida
del cliente. No existe una única solución para todos los tipos de
organizaciones. Es por esto que los proveedores de servicios han sumado a su
oferta de soluciones empresariales, el servicio de VPN, donde una buena
relación costo-beneficio para el cliente es posible.
1.3.1 Intranet /Intranet extendida
Una intranet en principio no se refiere a esquemas o topologías de
redes, sino a un conjunto de contenidos y recursos de información que son
accedidos y compartidos en forma privada y segura entre miembros de una misma
organización, con el objetivo de proveer la lógica de negocio para las
aplicaciones de la organización. Es un medio, además, para la difusión de
información interna, permitiendo que los empleados estén al tanto de lo que
sucede en su ámbito laboral de una manera eficiente.
Una característica fundamental de las intranets, es el hecho que su
funcionamiento se basa en tecnologías que implementan estándares abiertos,
tanto en los protocolos de comunicación como en aquellos protocolos a nivel
de aplicación. Es decir, utilizan la tecnología de Internet. En particular el
uso de la suite TCP/IP para la comunicación y a nivel de aplicación los
protocolos: HTTP, FTP, SMTP, POP3, LDAP, etc.
La clase de aplicaciones que se pueden encontrar en una intranet van
desde el servicio de correo electrónico, hasta sistemas de información
basados en web, sistemas de mensajería instantánea y colaborativos, sistemas
de videoconferencia y comunicaciones de voz mediante IP (VoIP). El acceso y
manipulación de la información, mediante estos sistemas se encuentra
restringido, por lo tanto también existen sistemas que permiten autenticar y
autorizar a los diferentes usuarios de la organización.
24
VPNs de Acceso Remoto
Una VPN sirve para expandir el alcance de una intranet. La
privacidad que aporta una red privada virtual brinda la seguridad para
acercar la intranet a los diferentes sitios o redes de datos que integran la
organización logrando su interconexión a través de Internet y/o las redes
backbone de los proveedores de servicio.
La intranet debería estar disponible para aquellos usuarios de la
organización cuyo rol requiere movilidad y estar fuera de los límites de la
misma, por lo tanto fuera de la red de datos. Es necesario que estos usuarios
móviles estén conectados para acceder a aquellos recursos o datos que la
intranet pone a disposición. Las redes distantes propias que pueden
interconectarse y los usuarios móviles que pueden tener acceso se denominan,
en su totalidad, una intranet extendida.
1.3.2 Extranets
Una extranet es un conjunto de intranets de organizaciones
diferentes que se interconectan entre sí para cumplir con objetivos comunes.
Esta relación esta bien definida y es establecida bajo un estricto control
del acceso. Se puede definir también como la intersección de un grupo de
intranets de varias empresas, lo cual indica que solo se comparte una porción
de la intranet hacia el resto de la extranet.
Por otro lado Internet es el medio común que resuelve problemas de
incompatibilidad entre sistemas de empresas muy diferentes. Es decir, ofrece
una interfaz común que permite una interacción difícil de lograr con otras
tecnologías. Por lo tanto, como en el caso de las intranets, adoptan las
tecnologías basadas en estándares abiertos propias de Internet para lograr
comunicación dentro de la extranet.
Una extranet puede tener un impacto notable en las relaciones
e
interrelaciones con las demás empresas que la integran. De hecho puede
modificar notablemente la posición de la organización frente a sus clientes y
competidores. Por esta razón la decisión de su implementación debe responder
a fines estratégicos, por lo cual deberá ser tomada por la alta gerencia de
la organización.
Las VPNs son la forma más efectiva de implementar las extranets, ya
que pueden hacer uso de Internet para lograr la interconexión de los
diferentes sitios. Nuevamente los puntos más importantes a considerar son la
seguridad en cuanto al acceso solo de los usuarios autorizados mediante
mecanismos de autenticación, como también el transporte a través de la
encapsulación y encriptado de los datos. Como se ha visto en este capítulo,
existen diversos protocolos de túnel utilizados en VPNs, los cuales se
aplican obviamente en las extranets. Algunos de ellos como IPSec, encapsulan
los paquetes originales y encriptan la información sensible, otros como PPTP
y L2TP se valen de IPSec para brindar la confidencialidad.
1.3.3 Servicio VPN provisto por un proveedor
Las corporaciones y organizaciones dependen cada vez más de las
telecomunicaciones y redes de datos. Es muy importante la interconexión de
redes propias en diferentes sitios. Esta necesidad fue resuelta por
proveedores de servicios de telecomunicaciones, principalmente a través de
conexiones Frame Relay, ATM y más recientemente mediante ethernet y túneles
basados en IP.
25
VPNs de Acceso Remoto
Estas organizaciones, requieren con más frecuencia, servicios de
conectividad sobre uno o más backbones, incluso a través de Internet, pero
que este servicio incluya contratos de nivel de servicio (Service Level
Agreement), calidad de servicio (QoS), y otros parámetros que permitan una
comunicación segura, estable, con alto grado de disponibilidad, con un umbral
de ancho de banda, con priorización de tráfico, etc.
Estas características son difíciles de lograr cuando la comunicación
entre sitios debe atravesar redes de diferentes proveedores más la Internet,
es decir un entorno compartido y de naturaleza no orientada a la conexión.
Las VPN permiten una comunicación segura y privada mediante la
encapsulación y encriptación. Es decir, aíslan el tráfico de datos privados
de una organización del resto con el cual pueda compartir un canal de
comunicación. Actualmente la relación costo-beneficio en la implementación de
este mecanismo ha determinado la conveniencia de la contratación del servicio
a proveedores, en lugar de la puesta en funcionamiento y control por parte de
la propia organización.
Para poder diferenciar y aislar los tráficos pertenecientes a varios
clientes, el proveedor utiliza conexiones de capa 2 (VPNs tradicionales) o
túneles de capa 2 o 3. Para el caso de conexiones a través de Internet, las
VPN se han basado en IPSec para brindar la mayor seguridad.
El concepto de servicio VPN provisto por el proveedor debe soportar
los
tipos tradicionales de VPN, además debe funcionar con las clases de
proveedor definidos en el capítulo 1, además de Internet: único proveedor,
conjunto de proveedores y proveedor de proveedores.
Existen requerimientos generales para esta clase de VPNs, un
análisis detallado se expresa en la RFC 3809 7 . Estos requerimientos pueden
clasificarse en:
7

Requerimientos del servicio: atributos del servicio que el
cliente puede observar o medir, por ejemplo: disponibilidad y
estabilidad, garantías de seguridad, servicio de tramas o
datagramas.

Requerimientos del proveedor: características que el proveedor
evalúa para determinar la viabilidad en términos de la relación
costo-efectividad del servicio, por ejemplo escalabilidad y
grado de administración

Requerimientos de Ingeniería: características de implementación
que permiten cumplir con los requerimientos del proveedor y del
servicio. Estos a su vez pueden clasificarse en:

Requerimientos en el plano de
mecanismos de reenvío de datos.

Requerimientos en el plano de control: asociados
de distribución de la información de enrutamiento.

Requerimientos relacionados a la uniformidad de los mecanismos
en esta clase de VPN respecto de otros esquemas y en general con
la forma de operación de Internet.
RFC 3809 - Generic Requirements for Provider Provisioned Virtual Private Networks
26
reenvío:
asociados
a
los
al mecanismo
VPNs de Acceso Remoto
Calidad de servicio (QoS) y Acuerdos de nivel de servicio (SLA)
En general calidad de servicio se refiere a la habilidad de brindar
servicios de redes y comunicaciones de acuerdo a un conjunto de parámetros
especificados un contrato de nivel de servicio o SLA. La calidad esta
caracterizada
por la disponibilidad del servicio, tasa de demora, de
variación de la demora (jitter), tasa de proceso de paquetes (throughput), de
pérdida de paquetes. En particular, y desde una perspectiva de recurso de
red, calidad de servicio se refiere a un conjunto de herramientas que
permiten a un proveedor de servicio priorizar tráfico, controlar el ancho de
banda y la demora en la red. Existen dos maneras de lograrlo en redes IP,
mediante Servicios Integrados y a través de Servicios Diferenciados8
El ámbito en el cual un servicio VPN cumple con calidad de servicio
dependerá del proveedor de servicio. En la mayoría de los casos de VPN
definida en el sistema autónomo de un único proveedor es posible cumplir con
este requerimiento. El soporte de QoS en ambientes de multi proveedores o
diversos sistemas autónomos estará en función de los acuerdos de cooperación
entre los involucrados en la provisión del servicio y de que todos utilicen
los mismos mecanismos. Es decir que los dispositivos CE y/o PE ejecuten al
menos formateo y apliquen políticas al tráfico (shaping y policing).
La necesidad de aplicar calidad de servicio ocurre principalmente en
la red de acceso al backbone del proveedor y no en el interior del mismo, de
hecho QoS sobre las conexiones PE a PE no son un inconveniente. En cuanto a
la calidad de servicio en el acceso, se pueden distinguir dos enfoques:

Desde el CE a través de la red de acceso al PE

Desde el PE a través de la red de acceso al CE
Los dispositivos CE y PE deberían poder soportar QoS sin importar
la tecnología de acceso ya sea de capa 2 o 3: circuitos virtuales ATM y Frame
Relay, acceso basado en MPLS, DSL etc. Se pueden distinguir dos modelos de
servicio para QoS:

Servicio de administración del acceso: este provee QoS sobre el
acceso entre CE y los puertos del lado de cliente en el PE. No
es requerido en el núcleo del backbone.

QoS borde a borde: brinda QoS sobre el backbone del proveedor,
ya sea entre pares de dispositivos CE o pares de PE, dependiendo
de los límites del túnel.
Un acuerdo de nivel de servicio SLA (Service Level Agreement) es una
documentación donde se expresan los resultados de una negociación entre un
cliente y un proveedor de servicios. En este documento se especifican los
niveles de disponibilidad, perfomance, nivel de servicio, forma de operación
y otros atributos del servicio.
A partir de un SLA se pueden determinar objetivos de nivel de
servicio o SLO (Service Level Objective), considerando métricas individuales
con los valores deseados e información operacional para controlar el SLA.
Estas se pueden implementarse como políticas.
8
RFC 1633 - Integrated Services; RFC 2475 - Differentiated Service
27
VPNs de Acceso Remoto
Una especificación de nivel de servicio o SLS (Service Level
Specification) engloba a las dos anteriores, es decir especifica un acuerdo
negociado y las métricas individuales y datos operacionales, para garantizar
la calidad de servicio del tráfico de red para ese cliente. Una SLS puede
definirse sobre la base de los siguientes objetivos y parámetros, los cuales
se pueden considerar sobre la base de conexiones a la red de acceso, VPNs o
sitios:

Disponibilidad del sitio, VPN o conexión de acceso.

Duración de los intervalos de no disponibilidad del servicio.

Tiempo de activación del servicio.

Tiempo de respuesta para la resolución de un problema.

Tiempo de aviso de un inconveniente.

Limites para la variación del delay y jitter.
El sistema de administración y monitoreo del proveedor deberá medir
y generar reportes respecto si las perfomance medida cumple o no los
objetivos de la SLS. Muchas veces el nivel garantizado para los parámetros de
los objetivos de nivel de servicio, dependen del alcance de la VPN, por
ejemplo ciertos niveles pueden ser garantizados en el ámbito de un solo
sistema autónomo, mientras que otro, aún más estricto, se puede cumplir en
un dominio de un único proveedor pero con varios sistemas autónomos bajo su
cargo. En un escenario multi proveedor es más difícil cumplir con aquellos
parámetros que requieran un alto grado de cumplimiento, por ejemplo el
requerimiento de QoS.
28
VPNs de Acceso Remoto
CAPÍTULO 2
ARQUITECTURAS, CLASIFICACIÓN
Y PROTOCOLOS
2
29
VPNs de Acceso Remoto
2.1 INTRODUCCIÓN A LAS ARQUITECTURAS DE VPN
Las distintas infraestructuras de red y los distintos requerimientos
exigen diversos tipos de arquitectura de redes VPNs. Deberíamos realizarnos
ciertos cuestionamientos para escoger cual es la que mejor se adapta a
nuestras necesidades. Podríamos mencionar los siguientes:
¿Se posee con el personal calificado como para implementar las
tecnologías necesarias
o las soluciones existentes en el mercado
proporcionadas por un proveedor pueden ser una mejor solución?
¿Cual es la interoperatividad
infraestructura de red actual?
¿Es
proveedores?
requisito
indispensable
de
la
arquitectura
comunicarnos
con
los
con
nuestra
clientes
y/o
¿Será fácilmente actualizable para nuestros futuros requerimientos
en cuanto a escalabilidad, seguridad, facilidad de actualización y
flexibilidad?
¿Soporta conferencia en red y multimedia?
¿El equipo actual soportara la carga nueva del procesamiento de la
VPN o tendré que adquirir hardware?
¿Los ahorros son el único propósito o quiero implementar servicios
con valor agregado?
¿Cuántos usuarios
crecimiento futuro?
tendrían
en
la
actualidad
y
cual
seria
su
Al contestar estas preguntas y algunas que puedan surgir al
cuestionarse cuáles son sus objetivos se podrá empezar a limitar las
distintas soluciones que podrá implementar y mantener con el transcurso del
paso del tiempo.
30
VPNs de Acceso Remoto
2.1.1 Componentes de una Red Privada Virtual
Los componentes
observar en la Figura 2-1
que
forman
una
Red
Privada
Virtual
se
pueden
Figura 2-1 Componentes
Una solución de VPN se compone de varios elementos, los cuales se
detallan a continuación:
2.1.2 Hardware
El hardware es muy variado, lo integran servidores, PC y notebooks,
netbooks, routers, gateways y switches.
Las funciones que tienen asignadas el servidor son:

Esperar por los pedidos de conexión

Negociar las
autenticación.

Autenticar

Recibir datos del cliente y enviarle los pedidos por él.

También puede actuar como VPN gateway o VPN router.
conexiones,
entre
otros
la
encriptación
y
y autorizar a los clientes VPN.
El cliente generalmente se ejecuta en un equipo de un empleado en su
hogar (tele trabajo), en una notebook, netbook
o palmtops en algún sitio
usando Internet o una red pública.
También puede realizarse tareas administrativas, en general son
administradores remotos que realizan tareas de configuración, monitoreo y de
gestión.
31
VPNs de Acceso Remoto
Para tener un mejor rendimiento se recomienda utilizar hardware
específico como pueden ser routers que se encuentran optimizados para las
tareas de VPN o se puede adicionar placas a routers existentes para dotarlos
con la capacidad física y los protocolos necesarios para la encriptación y
autenticación.
2.1.3 Seguridad de la infraestructura
Consta de algunos de los siguientes elementos:
Firewall
El firewall protege a la intranet de ataques externos. En la Figura
2-2 se puede observar la ubicación del firewall en una organización con
enlace a Internet.
Figura 2-2 Firewall
NAT
Los dispositivos que realizan NAT (Network Address Translation)
permiten conectan dispositivos a otra red sin dar a conocer las verdaderas IP
de los equipos. Este mecanismo se basa en el reemplazo de la dirección IP
origen o destino real por otras direcciones IP. Esto permite economizar
direcciones IP, al reemplazar varias direcciones IP privadas de origen por
una única dirección IP pública asociada a la conexión a Internet. En la
actualidad este mecanismo se encuentra implementado por defecto en los
routers.
Servidores de autenticación
Los servidores de autenticación ofrecen mecanismos de autenticación
y autorización para autenticación remota.
Estos pueden pertenecer a la organización o puede ser un servicio
dado por el proveedor junto con el NAS. La Figura 2-3 describe estas dos
opciones en el mismo grafico.
32
VPNs de Acceso Remoto
Figura 2-3 Servidores de Autenticación
Arquitectura AAA
AAA (Authentication Authorization Accounting) es un mecanismo de
autenticación y autorización, puede ser implementado mediante los protocolos
RADIUS (Remote Authentication Dial-In User Server) o TACACS (Terminal Access
Controller Access Control System) con el objetivo de brindar un nivel más de
seguridad. Tiene la capacidad de reconocer quien accede a la red, y saber a
que recursos puede acceder y puede monitorear quien realiza que cosas en que
lugar.
El mecanismo AAA funciona en conjunto con el servidor NAS que actúa
como proxy. Este consulta al servidor RADIUS/TACACS y permite o deniega el
acceso según corresponda.
2.1.4 Infraestructura de soporte para el servicio del proveedor
Incluye los dispositivos que componen el backbone y el backbone de
Internet. El backbone del proveedor debería ser capaz de dar soporte a
distintas tecnologías como Frame Relay, ATM, IP, IP Multicast, Voice over IP
y también
protocolos de túnel. Sería recomendable que soporte calidad de
servicio. Para que brinde altos niveles de seguridad tendría que soportar
IPSec y brindar servicio AAA.
Sería recomendable el soporte de protocolos de enrutamiento como RIP
(Routing Information Protocol), OSPF (Open Shortest Path First), EGP
(Exterior Gateway Protocol) y BGP (Border Gateway Protocol).
2.1.5 Redes Públicas
Las redes públicas que podemos mencionar son Internet y la red
telefónica digital que permite brindar el servicio de DSL (Digital Suscriber
Line), FRAME RELAY y ATM y la analógica que soporte velocidad de hasta
56Kbps.
33
VPNs de Acceso Remoto
2.1.6 Túneles
Estos pueden estar basados en protocolos como PPTP, L2TP, L2F e
IPSec. En este capítulo y en el siguiente se tratarán con más detalle estos
protocolos.
2.2 ARQUITECTURAS
Existen muchas formas de combinar los distintos elementos que
componen una VPN.
Esto origina que existan distintas arquitecturas que se
clasifican de la siguiente manera:
2.2.1 Basadas en software
Es un programa para establecer túneles o cifrado a otro anfitrión.
En el caso de no residir en el firewall, se debe configurar este para que
permita la comunicación hacia y desde el exterior al equipo en que resida el
software.
Este
desventaja que
ser adquirido
seguridad o de
software puede ser abierto (Open Source) o propietario. La
posee el propietario es que el proveedor puede desaparecer o
por otra empresa y se deja de producir actualizaciones de
agregado de funcionalidad.
El Open Source tiene la ventaja de su costo de adquisición, pero
puede ser necesario tener personal capacitado o realizar un contrato anual
para tener soporte con algún proveedor.
2.2.2 Basadas en la Implementación
Dependen de quien es el responsable de la implementación de la VPN y
su administración. Existen dos categorías y una tercera que es una
combinación de las otras dos.
Dependiente
El proveedor del servicio es el responsable de proveer una solución
llave en mano. La principal ventaja es que la organización no debe cambiar su
infraestructura y no necesita personal con conocimientos en administración de
VPN para su gestión.
La mayor desventaja surge en el ámbito de la seguridad. Es
recomendable que la organización use una infraestructura AAA y firewall y
estar a cargo de su administración.
Independiente
En esta categoría toda la responsabilidad de la implementación es de
la organización. La encriptación, autenticación y autorización esta dada por
elementos de la propia Intranet. El proveedor puede dar el servicio de
Internet. Como desventaja se puede mencionar que se debe poseer personal
capacitado en estas tecnologías
34
VPNs de Acceso Remoto
Híbrida
Esta categoría es una combinación de las categorías anteriormente
mencionadas. Una parte de la administración es realizada por la organización
y otra por el proveedor. Una arquitectura que se puede tener en cuenta es la
que muestra la Figura 2-4 en la que se puede observar que existen varios
proveedores de servicios. La ventaja es que si existe problemas con un
proveedor se puede seguir conectado a los sitios que sean administrados por
los otros proveedores. Provee una mejor disponibilidad.
Este acercamiento
administración.
tiene
la
desventaja
de
que
es
compleja
la
Figura 2-4 Basada en la Implementación (Hibrida)
2.2.3 Basada en Seguridad
Se podrían mencionar cuatro categorías:

Router a Router

Firewall a firewall

Túneles bajo demanda

Túneles Multiprotocolo bajo demanda
Router a Router
Túneles bajo demanda: El túnel es establecido entre dos routers que se
encuentran en la conexión en el lado del cliente y en el lado del servidor.
Puede soportar múltiples conexiones simultáneamente y persisten hasta que la
última conexión es terminada. Los routers deben soportar intercambio de
claves y algoritmos de encriptación. La Figura 2-5 muestra como se
relacionan los componentes bajo esta arquitectura.
35
VPNs de Acceso Remoto
Figura 2-5 Túneles bajo demanda (Router a Router)
Túneles multiprotocolo bajo demanda: Es similar a routers bajo demanda con
la particularidad que los routers soportan varios protocolos de túnel. Tiene
la particularidad de que pueden transferir datos no-IP a través de la red
pública.
Sesiones encriptadas bajo demanda: Cada sesión es encriptada en forma
individual. Tiene un túnel distinto para cada pedido entre los routers como
grafica la Figura 2-6. La desventaja es que esto genera una gran sobrecarga.
Figura 2-6 Sesiones encriptadas bajo demanda
Firewall a Firewall
Consta de túneles bajo demanda y túneles
demanda. A continuación daremos un breve detalle.
multiprotocolo
bajo
Túneles bajo demanda
Es similar a router a router con túnel bajo demanda, con la
particularidad que se reemplazan los routers por firewalls. Es más seguro y
permite que se puedan implementar auditorias mas complejas.
36
VPNs de Acceso Remoto
Figura 2-7 Túneles bajo demanda (Firewall a Firewall)
Túneles multiprotocolo bajo demanda
Generalmente se utilizan
característica multiprotocolo.
L2TP
asegurado
con
IPSec
gracias
a
su
2.2.4 Iniciadas por el cliente
Cliente a Firewall/Router
Se negocia la sesión entre el cliente y el firewall/router. Éste
debe soportar el pedido del cliente de inicio de sesión. El cliente debe
poder comunicarse con el sistema operativo correspondiente.
Cliente a Server
El servidor VPN se encuentra dentro de la intranet corporativa, en
vez de cumplir las funciones de servidor VPN y firewall/Router.
Es más seguro que el anterior porque el proveedor de servicios
ignora la existencia del túnel.
2.2.5 Dirigidas
Los datos son encriptados en el capa 5 del Modelo OSI. Es decir en
la capa de sesión. El protocolo más utilizado en socks 5. Los túneles son
unidireccionales. El control de acceso puede utilizar el identificador del
usuario, hora, aplicación y hasta el contenido del paquete.
La capa de sesión soporta una mayor variedad de mecanismos
encriptación. La Figura 2-8 muestra la distribución de los componentes.
de
2.2.6 Basado en la capa
Depende en que capa del modelo OSI se encuentra configurada la Red
Privada Virtual. Puede ser en la capa de red o la capa de enlace.
37
VPNs de Acceso Remoto
Figura 2-8 Dirigida
Capa de Enlace
Se pueden dividir en:

Conexión Frame Relay: La principal ventaja es que provee el CIR
(Committed Information Rate).

Conexiones virtuales ATM.

MultiProtocolo sobre ATM (MPOA)

MPLS
Capa de Red
Estos modelos ya fueron explicados cuando se desarrollo el tema de
la Clasificación de VPNs en el capítulo anterior. Por lo tanto solo las
mencionaremos. Un tipo son las Redes Privadas tipo Peer y el otro son las
Redes Privadas tipo Overlay.
En este nivel se pueden usar los protocolos de capa 2 PPTP y L2TP.
También se puede utilizar IPSec.
2.2.7 Basada en Clases
Estas arquitecturas se basan en la complejidad de la configuración
de la VPN y del tamaño. Existen 5 clases que van de la 0 a la 4. Fue
propuesta por VPN Technologies.
En la Tabla 2-1, podremos observar las clases y sus características.
38
VPNs de Acceso Remoto
2.2.8 Basada en Caja Negra
Consiste en un dispositivo que contiene software de cifrado que se
ejecuta en un equipo del cliente. Se presupone que estos dispositivos de
hardware crean túneles más rápidos bajo demanda y ejecutan el proceso de
cifrado con mayor rapidez. Ofrecen una administración centralizada.
Es aconsejable que soporten los protocolos para establecimiento de
túneles PPTP, L2TP e IPSec. En general este dispositivo se encuentra detrás
del firewall.
2.2.9 Basada en Acceso Remoto
En esta arquitectura existe un software que se ejecuta en un equipo
remoto que quiere establecer una conexión a través de una red pública con un
túnel cifrado al servidor interno de la organización o de una línea de acceso
telefónica hacia un servidor de autenticación. El servidor puede ser un
router, un firewall, una caja negra o un servidor de autenticación
independiente.
2.2.10 VPN múltiple servicios
Son aplicaciones multiservicios que son generadas por proveedores.
Por ejemplo pueden dar el servicio de filtrado de contenido web y la revisión
antivirus. El primero se suele añadir a un firewall para que pueda utilizar
reglas para el acceso basado en el contenido.
39
VPNs de Acceso Remoto
Clase
Nº
0
Software
Como mínimo
sistema
operativo
Windows
95/98
1
Protocolos
Utilizados
PPTP
Seguridad
Acceso
Características
Filtrado de paquetes
ofrecido por un
Gateway, firewall o
router
DSL
T1
No soporta sitio a
sitio
IPSec
DES
IKE
Algún mecanismo de
Autenticación de
Usuarios
1 Gateway
T1
T3
Utiliza Token
5 VPN Gateway o 1
gateway que soporte
500 usuarios
concurrentes
AAA,RADIUS,TACACS,
NAT y firewall
Token y smartcards
20 VPN Gateway o 1
gateway que soporte
1000 sesiones
simultaneas
AAA,RADIUS,TACACS,
NAT y firewall
Servicio de
certificados propio
Soporta:
20 sucursales
250 usuarios remotos
Soporta sitio a sitio
y acceso remoto
Para poder
implementar una
extranet esta debe
soportar IPSec
Soporta:
10 a 100 sitios
remotos
500 usuarios remotos
sitio a sitio y
acceso remoto
Es
necesario
calidad de
servicio en
cuanto a
retardo
ISDN
Xdsl
T1
T3
Soporta:
Cientos de sitios
remotos y miles de
usuarios remotos
Extranet
usuarios remotos y
sitio a sitio
Videoconferencia
Tiene la desventaja
que es compleja la
administración,
configuración e
implementación
Soporta:
Miles de sitios
remotos
10000 usuarios
remotos
Extranet, sitio a
sitio, usuarios
remotos
Comercio electrónico
Audio y video en
tiempo real
Posee la desventaja
que necesita
profesionales
altamente capacitados
2
Soft de
marcación y
de acceso
remoto.
IPSec
3DES
IKE
3
Soft de
marcación y
de acceso
remoto
X.500
LDAP
IPSec
3DES
IKE
4
Soft de
marcación y
de acceso
remoto
LDAP
IPSec
3DES
IKE
Token y smartcards
10 a 20 gateway o 1
que soporte 5000
conexiones
simultaneas
AAA,RADIUS,TACACS,
NAT y firewall
Servicio de
certificados propio
ISDN
Xdls
T3
OC3
Tabla 2-1 VPNs basadas en Clases
40
VPNs de Acceso Remoto
2.3 PROTOCOLOS DE TÚNEL
Un protocolo de túnel es un mecanismo para encapsular un PDU9
denominado de carga o nativo. Se agrega un encabezado al PDU de carga propio
del protocolo de túnel. Finalmente este nuevo PDU se debe entregar a su
destino final mediante un protocolo de transporte o envío, por lo que es
necesario agregar el encabezado correspondiente a este último.
Esta clase de protocolos se utilizan para el envío de datos de un
determinado protocolo a través de una red que soporta uno diferente o
incompatible. También se usan cuando es necesario asegurar los datos de carga
mediante algún método de encriptación. Otro uso extendido es resolver
problemas de espacio de direcciones para los datos a transmitir, por ejemplo
cuando mediante el uso de un espacio de direccionamiento público se envían
paquetes con direcciones privadas.
Figura 2-9 Funcionamiento de un Túnel
Un túnel es un medio para reenviar datos a través de una red desde
un nodo a otro, como si ambos estuvieran conectados en forma directa. Luego
de los encapsulamientos, el PDU resultante es reenviado por nodos intermedios
basados en la información del encabezado externo sin tener en cuenta el
contenido original del paquete.
La Figura 2-9, muestra dos nodos A y B que se comunican mediante
el túnel entre los nodos W y Z. Estos últimos se denominan nodos de ingreso y
de egreso respectivamente. Los datos originales entre A y B son modificados
agregándoles un encabezado que permite reenviarlos a través del túnel. Los
nodos intermedios X e Y solo participan del proceso de transporte, pero no
tienen acceso a la información original propia de la comunicación entre A y
B. Cuando el paquete llega al extremo final o nodo de egreso Z, del túnel,
este le saca el encabezado exterior y reenvía el paquete al destino real, el
nodo B.
La utilización de túneles permite la separación del tráfico de
datos de varias VPNs y del tráfico correspondiente a la red del proveedor o
de Internet. Esto significa que el espacio de direcciones utilizado por los
dispositivos involucrados en la VPN forma parte de los datos que se envían
por los túneles sin modificación, aún si se usa Internet para su transporte.
9
Unidad de datos de protocolo
41
VPNs de Acceso Remoto
2.3.1 Requerimientos de un Túnel
Existen requerimientos deseables en los mecanismos de túnel, pero no
todos los protocolos existentes cumplen con todos ellos. Estos son 10:

Multiplexación

Protocolo de señalización

Seguridad de

Transporte multiprotocolo

Secuenciación de tramas

Mantenimiento

Manejo de grandes MTU

Sobrecarga mínima

Control de congestión y flujo

Manejo de tráfico y Calidad de servicio (QoS)
los datos
Multiplexación
Esto permite el anidamiento de túneles, es decir que puedan existir
múltiples túneles VPN entre dos extremos que han establecido un único túnel
principal, esto implica que cada extremo del mismo puede soportar varios
clientes o VPNs. El tráfico de cada uno se mantendrá separado del otro a
través de la existencia de un campo de multiplexión en los paquetes
transmitidos para distinguir la pertenencia a un determinado túnel.
Compartir un túnel de esta forma, disminuye la demora y el
procesamiento asociado al establecimiento del mismo. Esta característica
representa una ventaja ante los problemas de escalabilidad para un proveedor
de servicios VPN ya que solo tiene que mantener una estructura de túneles de
menor envergadura.
Figura 2-10 Multiplexación de Túneles
10
RFC 2764 – A framework for IP Based VPN
42
VPNs de Acceso Remoto
Protocolo de señalización
Previo al establecimiento de un túnel, se deben configurar una serie
de parámetros que deben ser acordados por los extremos participantes, por
ejemplo la dirección de los extremos, el nivel de seguridad requerido, etc.
Finalmente el túnel se puede establecer. Todo esto es posible por vía manual
o en forma dinámica mediante el uso de un protocolo de señalización.
La utilización de un protocolo de señalización, facilita la tarea de
administración del túnel, tanto su creación, distribución
y manejo de
parámetros o atributos asociados al mismo, mas aún cuando la VPN a la cual
pertenece el o los túneles abarca más de un dominio administrativo. En este
caso simplifica la coordinación de la administración.
También permite que los túneles puedan ser creados bajo demanda,
cuando
los nodos que los constituyen son móviles o requieren estar
interconectados en forma transitoria. Es importante que el protocolo permita
el transporte de un identificador VPN para asociar esta con el túnel
resultante.
El rol de este protocolo debería ser negociar los atributos del
túnel y no transportar información acerca de como utilizar el mismo.
Seguridad de los datos
Un protocolo de túnel debe soportar mecanismos que permitan varios
niveles de seguridad. Esto significa incluir métodos de encriptación y
autenticación de diversas fortalezas.
La seguridad de los datos de la VPN en general no depende únicamente
de las capacidades requeridas del túnel recién mencionadas. Es importante
considerar otros mecanismos, como por ejemplo el manejo de varias instancias
virtuales de tablas de enrutamiento y reenvío. Cada par (enrutamiento y
reenvío) estarán asociadas a una VPN. Un mismo dispositivo en el extremo de
un túnel, podrá manejar varias instancias por lo tanto varias VPNs. Esto
evita el enrutamiento por error del tráfico de una VPN hacia otra, asegurando
de esta manera la separación de los flujos de datos. Otra medida de seguridad
puede ser la autenticación de los extremos del túnel mediante el uso del
protocolo de señalización previo a su creación.
Transporte Multiprotocolo
Muchas aplicaciones de VPN requieren la transmisión de tráfico
multiprotocolo, por lo tanto el protocolo de túnel debería soportar su
transporte. Debe existir alguna forma de identificar el tipo de protocolo que
esta siendo enviado por el túnel.
No todos los protocolos de túnel soportan esta característica, para
estos existen extensiones que lo posibilitan. Otros poseen campos específicos
para esta señalización.
Secuenciación de Tramas
La secuenciación podría ser necesaria para una operación extremo a
extremo eficiente de algún protocolo de túnel o aplicación en particular.
Para esto es necesario un campo de secuencia en el diseño del protocolo, para
garantizar la entrega en orden de los paquetes.
43
VPNs de Acceso Remoto
Mantenimiento
Este requerimiento implica que los extremos
monitoreen el estado
del túnel para determinar si se pierde o no la conectividad y tomar las
medidas adecuadas en caso de corte o falla de la misma.
Las formas de realizar este monitoreo pueden ser dos: a través del
protocolo en si, ejecutando un chequeo en banda en forma periódica y en caso
de pérdida de conexión indicar explícitamente el problema. La otra forma es
mediante mecanismos fuera de banda, por ejemplo el uso de protocolos de
enrutamiento aplicados a una malla de túneles (RIP, OSPF), lo cual permite
detectar cualquier falla en forma automática. Otra herramienta es el uso del
protocolo ICMP a través de mensajes de solicitud de eco para monitorear el
estado del túnel.
Manejo de Grandes MTU
Teniendo en cuenta los dispositivos intermedios que reenvían el
tráfico del túnel, es posible que alguno de ellos maneje un valor de Máxima
Unidad de Transferencia o MTU
menor al valor manejado desde el extremo de
ingreso al túnel. En este caso, es necesaria alguna clase de fragmentación.
Esto traería inconvenientes de perfomance en el nodo donde sucede la
fragmentación, disminuyendo la eficacia general.
Para evitar este inconveniente, el protocolo de túnel puede
incorporar capacidad de segmentación y ensamblado haciendo uso del número de
secuencia y alguna clase de marcador de fin de mensaje.
Sobrecarga Mínima
Es importante este aspecto y más cuando se transporta tráfico de
datos sensible a la demora o al defasaje temporal, como lo es el tráfico de
voz y video. Lo que se persigue con este requerimiento es evitar el
procesamiento innecesario en los dispositivos que establecen el túnel.
Los mecanismos de cifrado y encriptación imponen una sobrecarga. Por
lo tanto se debería minimizar la sobrecarga u overhead tomando en cuenta la
necesidad de aplicar seguridad a los datos. En general el objetivo debería
ser minimizar el overhead alrededor de la necesidad de seguridad del tráfico
de datos.
Cuando se implementan las VPN dial-up, o de acceso remoto discado,
mediante el uso de túneles voluntarios, existe la posibilidad de sobrecarga
significante si se utilizan enlaces de poco ancho de banda.
Control de Congestión y Flujo
Existen
protocolos
de
túnel,
como
L2TP,
que
incorporan
procedimientos para el control de flujo y congestión. Estos fueron pensados
para mejorar la perfomance de la transmisión cuando se utilizaban redes que
podían generar pérdidas de paquetes con la compresión PPP. Otra razón era
crear un buffer al momento de utilizar líneas con menor capacidad de
transferencia. Finalmente estos esquemas se aplicaron a los canales de
control en lugar de aplicarlos al tráfico de datos.
En general no está claro si es conveniente incorporar estas
características en el diseño de los protocolos de túnel, en gran medida por
el hecho de la predominancia del tráfico TCP y el hecho de que TCP posee
sus propios y eficientes mecanismos extremos a extremo de control de flujo y
congestión.
44
VPNs de Acceso Remoto
Manejo de Tráfico y QoS
de
de
de
de
Los usuarios de un servicio de VPN, podrían desear características
Calidad de Servicio como sucede con los demás servicios WAN. Para el caso
las VPN, lograr aplicar QoS va a depender de las características de manejo
tráfico que puedan efectuar los nodos involucrados en la VPN y de la red
acceso o backbone donde se implemente.
2.4 PROTOCOLOS DE TÚNEL CAPA 2
Los túneles mas usuales son los implementados en la capa 2 o capa
enlace del modelo OSI. Entre ellos podemos mencionar Point to Point Tunneling
Protocol (PPTP), Layer 2 Forwarding (L2F) y Layer 2 Tunneling Protocol
(L2TP). Los protocolos de esta capa se basan en otro protocolo denominado
Point to Point Protocol (PPP), por lo que comenzaremos explicando este
protocolo.
2.4.1 Point to Point Protocol (PPP)
Es un protocolo para encapsular que permite transmitir a través de
una línea serie. Este requiere una conexión full-duplex y puede ser
sincrónico o asincrónico. Puede encapsular IP o no IP a través de líneas
series.
Las funciones que realiza son administrar las direcciones IP del
trafico no IP. Configura y realiza las pruebas necesarias para establecer el
enlace, encapsula los datagramas y realiza la detección de errores durante la
transmisión. También realiza la multiplexación de los protocolos de capa 2 y
renegocia parámetros como la compresión de los datos transmitidos.
Para realizar estas funciones se basa en LCP (Link Control Protocol)
para establecer, configurar y probar las conexiones punto a punto y NCP
(Network Control Protocol) para establecer y configurar varios protocolos de
la capa de red y para detectar errores durante la transmisión.
Funciones de LCP11
Realiza las siguientes funciones:
11

Ayuda a establecer el enlace PPP.

Configura
y
establece
el
enlace
para
requerimientos de comunicación de las partes.

Realiza las tareas necesarias para mantener el enlace.

Da por finalizado el enlace cuando se termina el intercambio de
datos entre las partes.
RFC 1661- The Point-to-Point Protocol (PPP)
45
satisfacer
los
VPNs de Acceso Remoto
2.4.2 Point to Point Tunneling Protocol (PPTP)
El protocolo punto a punto (PPTP) se creó para permitir a usuarios
remotos conectarse a su proveedor y establecer un túnel al servidor de la
organización. Permite realizar una conexión por marcación y soporta
protocolos que no sean IP.
PPTP es una extensión de PPP y por lo tanto no soporta múltiples
conexiones. PPTP es el encargado de establecer y terminar las conexiones
físicas entre las partes, autenticar los clientes PPTP, encriptar datagramas
de protocolos no IP e IP para crear datagramas PPP y asegurar el intercambio
de información entre las partes. Esto se puede observar en la Figura 2-11.
Figura 2-11 Funciones del Protocolo PPP en PPTP
En la figura podemos ver los elementos involucrados en una
transacción PPTP. Existe un cliente, el cual es el que inicia la transacción
a través de una conexión realizada con un modem a través de una marcación. Si
el NAS del proveedor acepta la comunicación entonces se puede establecer el
túnel con el dispositivo VPN a través de la red pública. En la Figura 2-12
podemos observar la relación entre PPP y PPTP.
46
VPNs de Acceso Remoto
Figura 2-12 Componentes en una conexión PPTP
El
dispositivo
NAS
debe
poder
soportar
múltiples
clientes
concurrentemente y distintos tipos de cliente, como por ejemplo cliente
WINDOWS, LINUX, Apple, etc. Si se realiza dentro de una red local no es
necesario el dispositivo NAS. El servidor PPTP debe tener capacidad de
enrutamiento.
PPTP utiliza el puerto 1723. Para detectar la pérdida la conexión
realiza una transmisión periódica de echo entre el cliente y el servidor
utilizando la conexión TCP establecida. Brevemente resumiremos como es el
proceso de transmisión los datos basándonos en la Figura 2-13.
Figura 2-13 Encapsulamiento PPTP

Se encapsula y se encripta los datos en un datagrama PPP

Se encapsula dentro de un paquete GRE

Se encapsula de un paquete IP. El encabezamiento contiene
dirección IP de cliente PPTP y la del servidor destino.

La capa de enlace suma un encabezamiento y una cola, el cual
viaja a través del túnel establecido.

Esto es encapsulado dentro del protocolo de transmisión
puede ser por ejemplo ethernet o un protocolo de WAN.

El servidor extrae en orden inverso y termina desencriptando los
datos.
47
la
que
VPNs de Acceso Remoto
Para realizar la encriptación y compresión se utiliza los servicios
brindados por PPP. En cuanto a la autenticación se utiliza MS-CHAP (Microsoft
Challenge-Handshake Authentication Protocol) o PAP (Password Authenticaction
Protocol).
PPTP permite realizar un filtrado en el servidor aceptando
solamente los clientes que fueron aprobados para acceder a la red.
2.4.3 Layer 2 Forwarding Protocolo (L2F)12
Es un protocolo desarrollado por Cisco en el año 1996. El objetivo
era permitir que protocolos no IP pudieran utilizarse sobre Internet. El
usuario hace una conexión PPP al proveedor de marcación y se conectan a sus
organizaciones a través de L2F.
Figura 2-14 Componentes en el Protocolo L2F
L2F provee la encriptación de datos y la autenticación utilizando
CHAP, EAP (Extensible Authentication Protocol) y SPAP (Shiva Password
Authentication Protocol).
También puede emplear RADIUS y TACACS como
servicios adicionales.
Como desventajas se puede mencionar que esta solución requiere un
mantenimiento costoso y son dependientes del proveedor que debe implementar
L2F. No provee control de flujo, lo que resulta en retransmisión de tráfico y
provoca una comunicación más lenta. Es más lento que PPTP debido al proceso
de autenticación y encriptación.
2.4.4 Layer 2 Tunneling Protocolo (L2TP)13
En 1998 las compañías que desarrollaron PPTP y Cisco que trabajó con
L2F acordaron una nueva especificación para el establecimiento de túneles de
nivel 2 (L2TP). Por lo tanto L2TP combina PPTP y L2F en una sola norma.
IPSec se puede utilizar con L2TP para poder brindar una mayor
seguridad. Se recomienda implementar esta configuración para proteger el
trafico L2TP a través de redes IP y no IP.
12
RFC 2341 - Cisco Layer Two Forwarding (Protocol) "L2F"
13
RFC 2661 - Layer Two Tunneling Protocol "L2TP"
48
VPNs de Acceso Remoto
Las ventajas que tiene es que soporta multiprotocolos y tecnologías
como por ejemplo IP, ATM, Frame Relay y PPP. No requiere implementación de
software específico como drivers o soporte en el sistema operativo. Permite
que clientes con IP privadas se comuniquen a través de redes públicas con
sitios remotos. Y por último se puede mencionar que la autorización y
autenticación se realizan en un gateway por lo tanto el proveedor no necesita
implementar y mantener una base de datos de los usuarios remotos y sus
derechos de acceso.
Es necesario definir antes, dos componentes principales en el
funcionamiento de L2TP: LAC (L2TP Access Concentrator) y LNS (L2TP Network
Server). Un LAC es un dispositivo que es uno de los extremos del túnel L2TP y
siendo el LNS el otro extremo. De hecho un LAC se ubica entre un cliente
remoto y el LNS reenviando los paquetes entre ellos. La conexión entre el LAC
y el sistema remoto es mediante un enlace PPP. Un LNS es el otro extremo del
túnel L2TP y representa la terminación lógica de la sesión PPP que es enviada
por el túnel.
Modos de túnel
L2TP soporta los modos de túnel obligatorio y voluntario. En el modo
obligatorio Figura 2-15, el proveedor es el encargado de establecer entre el
LAC y el LNS el túnel y de validar el usuario. Para comunicarse con Internet
es necesario pasar por gateway de la intranet corporativa, brindando una
mayor seguridad.
Figura 2-15 L2TP Túnel obligatorio
En el túnel voluntario Figura 2-16, el usuario remoto actúa de LAC.
El túnel es transparente para el proveedor como ocurre con los túneles
basados en PPTP.
49
VPNs de Acceso Remoto
Entre las ventajas que podemos mencionar esta que es una solución
genérica, independiente de la plataforma. Puede soportar la transmisión a
través de enlaces WAN no IP sin la necesidad de IP. No se requiere
configuración en el proveedor y en el cliente. Permite que la autenticación
sea realizada por la organización y no por el proveedor. Provee control de
flujo. Es más rápida que L2F. Permite que clientes remotos con IP privada
puedan conectarse a su organización a través de redes públicas. Se puede
utilizar IPSec para poder brindar una mayor seguridad.
Como desventajas podemos mencionar que es más lento que PPTP o L2F
cuando se utiliza IPSec para autenticación de cada paquete y es más complejo
de implementar que PPTP.
Figura 2-16 L2TP Túnel voluntario
Característica
Soporta multiprotocolo
Soporta múltiples conexiones
PPP por túnel
Soporta múltiples conexiones
por túnel
Modos de Túnel
PPTP
Si
L2F
Si
L2TP
Si
No
Si
Si
No
Voluntario
Si
Si
Voluntario y
Obligatorio
IP/UDP
IP/FR
IP/ATM
Voluntario y
Obligatorio
IP/UDP
IP/FR
IP/ATM
UDP
Puerto 1701
Protocolo de Entrega
IP/GRE
Protocolo de Control
TCP
Puerto
1723
UDP
Puerto 1701
MS-CHAP
PAP
CHAP
PAP
SPAP
RADIUS
TACACS
MPPE
MPPE
IPSec
Autenticación
Encriptación
Tabla 2-2 Comparativa protocolos Capa 2
50
CHAP
PAP
SPAP
EAP
IPSec
TACACS
MPPE
IPSec
ECP
VPNs de Acceso Remoto
2.5 PROTOCOLOS DE TÚNEL CAPA 3
En la siguiente sección se describirá los principales protocolos de
túnel de capa 3, empezando con IPSec, GRE y finalmente MPLS. Si bien este
último no es en si un protocolo de capa 3, su funcionamiento esta muy ligado
al protocolo de red IP.
2.5.1 IP Security Protocol (IPSec)
IPSec es una extensión del protocolo IP que brinda seguridad a IP y
a los protocolos de capa superior. Fue desarrollado para el nuevo estándar de
IP versión 6 (IPv6) y luego adaptado para implementarlo en la versión 4
(IPv4).
Figura 2-17 Paquete/Datagrama usando IPSec
La Figura 2-17 muestra un paquete con los encabezados de capa 2 que
encapsulan un datagrama IP procesado mediante IPSec. Se puede observar el
encabezamiento IPSec posterior al encabezado IP y un campo Datos de
Autenticación (HMAC) como cola del datagrama. Como resultado surge un nuevo
datagrama IP con nuevos encabezados.
IPSec
utiliza
dos
protocolos
diferentes
para
asegurar
la
autenticidad, integridad y confidencialidad, estos son el protocolo de
Autenticación de Encabezado AH (Authentication Header) y el protocolo de
Encapsulado de Seguridad de Datos o ESP (Encapsulated Security Payload).
IPSec puede proteger todo el datagrama IP o solamente los protocolos
de capa superior mediante los modos túnel y transporte. En el primer caso el
datagrama IP es encapsulado en forma completa en otro. En el modo transporte
solo los datos del datagrama IP original es procesada por IPSec, insertando
el encabezado AH o ESP entre el encabezado IP y los datos.
Para asegurar la integridad del datagrama IP, IPSec utiliza HMAC 14
(Hash Message Authentication Code) o Código de autenticación de mensajes
basados en hash, mediante algoritmos como MD5 y SHA. Lo calcula basado en una
clave secreta
y en el contenido del datagrama. El HMAC se incluye en el
encabezado IPSec. El receptor verifica este HMAC si tiene acceso a la clave
secreta.
14
RFC 2104 - HMAC: Keyed-Hashing for Message Authentication
51
VPNs de Acceso Remoto
IPSec utiliza algoritmos de encriptación simétricos estándar de
elevada fortaleza como 3DES, AES o Blowfish para asegurar la confidencialidad
del tráfico transportado. IPSec protege la comunicación respecto de ataques
de denegación de servicio o ataques de repetición, mediante el mecanismo de
ventana deslizante. Los números de secuencia de los paquetes deben estar
dentro del rango aceptado por la ventana, sino son descartados.
Para encapsular y desencapsular los paquetes IPSec, los extremos
participantes necesitan un mecanismo para mantener información como claves
secretas, algoritmos, direcciones IP utilizadas en la conexión etc. Estos
parámetros se guardan en Asociaciones de Seguridad o SA (Security
Association). Estas a su vez se almacenan en una Base de Datos o SAD. Cada SA
define los siguientes parámetros:

Direcciones IP origen y destino del encabezado IPSec resultante
(direcciones que coinciden con las de los pares que establecen
la comunicación segura).

El protocolo IPSec a utilizar (AH o ESP).

Algoritmo y claves secretas a utilizar.

SPI (Security Parameter Index) de la SA. Es un número de 32 bits
que identifica la SA.
Algunas implementaciones de bases de datos de SA permiten, además,
almacenar estos parámetros:

Modo IPSec (túnel o transporte).

Tamaño de la ventana deslizante.

Tiempo de duración de la SA.
Una SA representa una conexión unidireccional. IPSec requiere que se
definan dos SA para una comunicación bidireccional o full duplex. Las
asociaciones solo determinan como proteger el tráfico. Las Políticas de
Seguridad o SP establecen que tráfico proteger y cuándo. Las SP se almacenan
a su vez en una SPD o base de datos de políticas de seguridad. Una SP define
los siguientes parámetros:

Direcciones IP origen y destino de cada paquete. En modo
transporte estas direcciones coinciden con las IP almacenadas en
la SA. En modo túnel estas podrían diferir.

Puerto y protocolo a proteger. Algunas implementaciones de IPSec
no permiten estos parámetros, en estos casos se aseguran todos
los paquetes.

La SA a utilizar.
La SPD discrimina el tráfico entrante o saliente, de forma tal que
puede descartar el paquete en tránsito, ignorarlo o aplicar el servicio de
seguridad de acuerdo a la asociación de seguridad relacionada con esa entrada
de la SPD.
La SPD debe ser consultada durante el procesamiento de todo el
tráfico, entrante y saliente. Por esta razón esta contendrá entradas
diferentes para uno y otro. Además cada interfaz de red que es protegida por
IPSec tendrá asociada sendas bases, de políticas y de asociaciones, para el
tráfico entrante y saliente.
52
VPNs de Acceso Remoto
Cada implementación IPSec debe tener una interfase administrativa
que permita a un administrador manejar la SPD. Dado que cada paquete entrante
o saliente es procesado por IPSec y donde la SPD especifica la acción a ser
tomada en cada caso, esta interfaz debe permitir al administrador establecer
el procesamiento de seguridad que se aplicará a cada paquete, mediante la
creación de entradas y la definición de los filtros selectores, además deberá
permitir el ordenamiento de las mismas.
Si los valores de un paquete IP corresponden con los selectores de
una entrada en la SPD, entonces se determina que un paquete IP esta
relacionado con la misma y esto dispara un proceso IPSec. A continuación se
determina si existe una Asociación de Seguridad (SA) para la entrada de la
SPD. Si existe, entonces esta indicará el protocolo de seguridad a utilizar,
el modo, el algoritmo de autenticación de encriptación y las claves a
utilizar.
Cuando varios nodos participan de una VPN que utiliza IPSec para
crear los túneles, surge un inconveniente al momento de compartir información
para la comunicación dentro de la VPN. Durante la creación de las
Asociaciones de Seguridad, se deben difundir las claves secretas y los
algoritmos de encriptación a utilizar.
El intercambio de claves es un proceso crítico ya que en esta etapa
aún no hay un medio seguro establecido para transmitir esta información. Para
resolver este problema se diseñó el protocolo de intercambio de claves o IKE
(Internet Key Exchange).
IKE autentica, en una primera fase, a los pares o nodos que
participan en la VPN. En una segunda fase se negocian las SA y se eligen las
claves secretas para la encriptación simétrica mediante el algoritmo Diffie
Hellman de intercambio de claves. Una vez compartidos en forma segura los
datos necesarios, IKE se encarga en forma periódica de regenerar claves que
protegen la confidencialidad de las claves para encriptación simétrica.
Protocolo AH
Este protocolo se encarga de autenticar los datagramas asegurando la
integridad de los datos incluyendo la dirección IP de origen, brindando
además protección contra ataques de repetición de datagramas (replay
attacks). Para establecer la integridad de los datos calcula un código de
autenticación basado en hash o HMAC. Este se realiza utilizando una clave
secreta, los datos del datagrama y el encabezado IP original. El valor
resultante del procedimiento se coloca en el campo Datos de Autenticación del
encabezado AH.
Figura 2-18 Encabezado AH
53
VPNs de Acceso Remoto
Los campos del encabezado AH son:

Próximo Encabezamiento: identifica el tipo de datos de la carga
útil, es decir el protocolo de capa superior. Utiliza 1 byte.

Longitud
del
encabezamiento:
encabezado, utiliza 1 byte.

Reservado: utiliza 2 bytes.

SPI: Identifica la SA a utilizar. Utiliza 4 bytes.

Número de Secuencia: Previene los ataques de repetición (replay)
en forma opcional y además sirve para mantener una recepción
ordenada de paquetes. Este campo almacena un número que se
incrementa en uno cuando un paquete es enviado en forma
consecutiva a la misma dirección y con el mismo SPI. Utiliza 4
bytes.

Datos de Autenticación: Compendio (Digest) calculado mediante el
HMAC, utilizado por el receptor para comparar lo recibido luego
de aplicar la misma operación al datagrama.
identifica
el
tamaño
del
AH puede usarse solo o junto con ESP cuando se usa el modo túnel.
Cuando se utiliza el modo transporte, el encabezado AH se coloca justo detrás
del encabezado IP y antes del encabezado ESP, en caso de funcionar en
conjunto, u otro encabezado de protocolo de mayor nivel como UDP o TCP. Ver
Figura 2-19.
Cuando se usa el modo túnel, se agrega un nuevo encabezado IP y el
encabezado de AH se inserta luego de este y antes del encabezado IP del
datagrama original. Si bien el proceso de autenticación abarca este nuevo
encabezado IP, la norma especifica que no deberá afectar aquellos campos que
puedan variar durante el transporte, por ejemplo el campo de Tiempo de vida
o TTL (Time To Life), que es decrementado en uno cada vez que el datagrama
atraviesa un router. Ver Figura 2-19.
El protocolo AH no es conveniente de utilizar cuando se considera el
uso de traducción de direcciones de red o NAT, debido a que su protección de
integridad abarca campos del encabezado IP como la dirección de origen. Es
adecuado si lo único que se persigue es asegurar la integridad y autenticar
el origen de los datos.
54
VPNs de Acceso Remoto
Figura 2-19 Modos con protocolo AH
Protocolo ESP
Este protocolo provee privacidad o confidencialidad a los
datagramas IP por medio del encriptado de los datos correspondientes.
Adicionalmente puede asegurar la integridad
mediante un HMAC propio. ESP
altera el datagrama IP original en más de un sitio: agrega un encabezado
propio, una cola (CE en la Figura 2-20) y si es necesario rellena el campo de
datos. La cola varía si además de la encriptación se usa autenticación (DA en
la Figura 2-20).
En el modo transporte, de igual manera que AH, el encabezado de
ESP se agrega luego del encabezado IP y antes de otro encabezado de protocolo
de mayor nivel como UDP o TCP. En modo túnel el encabezado de ESP se inserta
delante del encabezamiento IP original pero antes del nuevo encabezado IP
propio de este modo. Esto se muestra en la Figura 2-20, modo túnel.
El proceso de encriptado
incluye todos los campos posteriores al
encabezado ESP, pero no este mismo. La autenticación se aplica a lo
encriptado más el encabezado ESP. El encabezado IP externo no se autentica,
es decir, el encabezado IP original en el modo transporte o el nuevo
encabezamiento IP del modo túnel.
55
VPNs de Acceso Remoto
Figura 2-20 Modos en ESP
Figura 2-21 Encabezado y Cola ESP
De acuerdo a la Figura 2-21 los campos del encabezado ESP son:

SPI: Este indica que SA utilizar para desencapsular el paquete
ESP, igual a AH. Utiliza 4 bytes.

Número de Secuencia: igual que en AH.

Campo de datos IP (payload)
56
VPNs de Acceso Remoto

Vector
de
Inicialización:
utilizado
en
el
proceso
de
encriptación si este requiere datos de sincronización. Este
vector sirve para que dos paquetes con la misma carga resulten
en dos cargas encriptadas diferentes. Los algoritmos de
encriptación simétrica son vulnerables a ataques de frecuencia
si no se utilizaran los vectores de inicialización.

Encabezado TCP

Datos

Cola ESP

Relleno (Padding): Se usa en caso que el algoritmo de encriptado
requiera que el texto a encriptar sea múltiplo de cierta
cantidad de bytes (cifrado en bloques). También es necesario
para lograr un múltiplo impar de 16 bits del encabezamiento
hasta ese punto, de manera que los campos restantes, de 8 bits
cada uno, logren que la longitud total, del encabezado, sea un
número múltiplo par de 16 bits.

Longitud del
anterior.

Siguiente Encabezado (Next Header): indica el tipo de datos de
la carga útil. En Ipv4 identifica el protocolo de capa superior.
Utiliza 1 byte.

Datos de autenticación: Es opcional y solo aparece si se utiliza
ESP con autenticación. Su longitud varía según el algoritmo de
Hash empleado: 16 bytes si es MD5 o 20 bytes si es SHA.
relleno
(Padding
Length):
identifica
el
campo
ESP puede utilizarse solamente con encriptación o incluyendo además
autenticación. Otra alternativa es con encriptado nulo, o sea sin
encriptación pero con autenticación. ESP puede combinarse con AH.
Si bien ESP puede autenticar, no abarca al encabezamiento IP
externo, es decir no lo protege de cualquier alteración en aquellos campos
que no deberían cambiar. Por ejemplo, lo anterior podría derivar en la
fragmentación del datagrama si se alterara el campo correspondiente. Esta
operación podría permitir la inserción de datagramas de ataque.
Protocolo IKE
También conocido como ISAKMP/Oakley (Internet Security Association
and Key Management Protocol), este protocolo resuelve el problema más
importante relacionado con las comunicaciones seguras: la autenticación de
los pares, el intercambio de claves simétricas, creación de las SA y
actualización la Base de Datos que las contiene. IKE se implementa mediante
un demonio en el espacio de usuario. Utiliza el puerto UDP 500.
Su funcionamiento se puede dividir en dos etapas o fases. En la
primera fase IKE establece una Asociación de Seguridad ISAKMP (ISAKMP SA). En
la segunda, esta SA es utilizada para negociar y establecer las SA propias de
la comunicación IPSec (IPSec SA).
57
VPNs de Acceso Remoto
La autenticación de la primera fase puede estar basada en claves
precompartidas (PSK), claves RSA y Certificados X.509. En esta etapa se
pueden utilizar dos modos para la autenticación y establecimiento de la
ISAKMP SA: modo principal o modo agresivo. Este último utiliza la mitad de
los mensajes para lograrlo pero no brinda la protección de la identidad de
los hosts intervenientes. Esto puede permitir un ataque del tipo “hombre del
medio”.
En la segunda fase el
negocia en base a la ISAKMP SA,
operación de ataques del tipo
finalmente son al menos dos, una
protocolo intercambia propuestas de SA y las
la cual brinda la autenticación y protege la
mencionado anteriormente. Las SA negociadas
para cada dirección de la comunicación.
Rendimiento
La utilización de IPSec en las comunicaciones requiere capacidad de
procesamiento. En particular con ESP esta necesidad se evidencia en la
encriptación y desencriptación de los paquetes, considerando la complejidad
de los algoritmos empleados y en la autenticación de su encabezado, el
agregado de este y de la cola al datagrama original.
Inclusive con AH el proceso de calcular un compendio en un extremo y
la posterior verificación en el otro, son tareas mucho más complejas que el
enrutamiento o la traducción de direcciones.
Las principales limitaciones no se originan en Internet, debido a
que por naturaleza es un ambiente heterogéneo donde el transporte y entrega
de las tramas implica una operación con el mejor esfuerzo y no asegura
confiabilidad ni alta velocidad. De todas formas utilizando compresión previa
a la encriptación puede mejorar el rendimiento.
Es el dispositivo o gateway de seguridad donde se ejecuta IPSec,
quien es sensible a limitaciones que afectan la perfomance. Es importante que
un gateway maneje un ancho de banda mayor al de la red a la cual se conecta,
caso contrario deberá descartar paquetes provocando interrupciones en el
tráfico afectando directamente los paquetes transportados mediante UDP e
inclusive el tráfico TCP.
Otro aspecto que afecta la perfomance en un dispositivo es el
retardo, o tiempo adicional de procesamiento en el equipo, previo a la salida
del paquete. En la práctica se considera como asociado al tiempo en que
tardan los datos en viajar desde el origen a su destino. En un dispositivo
que cumple más de una función, incluyendo el procesamiento de IPSec, su
retardo será importante. Es muy diferente procesar solo el encabezado
(firewall de filtrado de paquetes) que sobre todo el datagrama completo con
mecanismos de encriptado, sumado la carga u overhead del tratamiento e
intercambio de claves, que requiere un uso intensivo del CPU.
58
VPNs de Acceso Remoto
2.5.2 Generic Routing Encapsulation protocol (GRE)
El protocolo GRE o de encapsulación genérica de enrutamiento, es un
estándar de facto desarrollado por Cisco. Está diseñado para encapsular
protocolos de capa de red arbitrarios dentro de otro protocolo de capa de red
arbitrario15. Existen al menos tres RFCs referidas directamente con este
protocolo, la RFC 1701 define en forma general el protocolo y el formato de
su encabezado. La RFC 1702 refiere a su uso en conjunto con IP, tanto como
protocolo de carga como de transporte. Finalmente la RFC 2784 es un memo que
actualiza las anteriores, redefiniendo el formato del encabezado y definiendo
como obsoletos a algunos de sus campos. Sin embargo deja establecido las
operaciones con implementaciones anteriores. Esta sección se basa en la
descripción del protocolo de acuerdo a esta última RFC pero con algunas
referencias a las anteriores. En general GRE se ejecuta en la capa IP,
utilizando datagramas IP como carga y como transporte16.
GRE crea un vínculo punto-a-punto con routers en cada extremo sobre
una red IP. Se diferencia de IPSec en que maneja tráfico multicast. De hecho
GRE se utiliza en conjunto con este protocolo para esta tarea debido a la
naturaleza unicast de IPSec. La estructura general de un paquete GRE
encapsulado para el envío es la siguiente:
Figura 2-22 Paquete GRE encapsulado
Cuando se usa IP como protocolo de carga y de entrega, los campos
TTL, TOS y opciones de seguridad IP pueden ser copiados desde el paquete de
carga a los mismos campos en el encabezado del paquete de entrega. El campo
TTL del paquete de carga se decrementa cuando se desencapsula.
Cuando el extremo de egreso del túnel desencapsula un paquete GRE,
el cual contiene un datagrama IP como carga, la dirección destino en el
encabezado IP debe ser utilizado para reenviar dicho datagrama y el campo TTL
debe ser decrementado. Si la dirección IP destino resultara ser del extremo
que encapsuló, entonces deberá descartarse el datagrama para evitar un bucle
o loop.
15
RFC 1701 - Generic Routing Encapsulation (GRE)
16
RFC 1702 - Generic Routing Encapsulation over IPv4 networks
59
VPNs de Acceso Remoto
Operaciones Conjuntas con otros protocolos
La utilización más común y simple de este protocolo, es la creación
de túneles que permiten la utilización de un espacio de direcciones internas,
a través de un espacio público de direccionamiento, para el tráfico de datos.
Esto es posible por la capacidad de GRE de encapsular un datagrama IP y a su
vez integrar la carga de otro datagrama IP que le permitirá atravesar una red
IP hasta su destino.
La desventaja es que la carga que encapsula GRE no está en
condiciones de atravesar una red insegura como Internet ya que los datos no
están encriptados. Por lo tanto hace falta alguna medida de seguridad para
poder utilizar GRE en un entorno VPN. Es en esta situación que se utiliza en
conjunto con IPSec, el cual le suma la seguridad de sus mecanismos de
encriptación y autenticación. Pero esta relación es bilateral, ya que IPSec
falla en aquellos escenarios donde la naturaleza de las comunicaciones es del
tipo multicast: propagación de la actualización de rutas en un entorno de
enrutamiento dinámico, tráfico de voz y video, etc.
La manera de salvar este escollo es mediante la encapsulación del
paquete multicast en un paquete GRE. A continuación este último, se encapsula
en un paquete IPSec (Figura 2-23), para ser enviado a la red destino en forma
segura, donde el extremo remoto del túnel IPSec, desencapsulará el paquete
multicast y lo entregará a los dispositivos que integren el grupo multicast
destino.
Utilizar GRE para crear túneles como mecanismo para una VPN, genera
algunas desventajas principalmente asociadas a la carga en tareas de
administración de la VPN, escalabilidad en cuanto al crecimiento del número
de túneles, perfomance y QoS.
Debido a que los túneles GRE deben ser configurados en forma
manual, existe una relación directa entre la cantidad de túneles a configurar
y la cantidad de tarea administrativa necesaria para
mantener dichos
túneles.
También
la
capacidad
de
procesamiento
requerida
para
la
encapsulación GRE, está en con el número de túneles configurados.
Figura 2-23 Encapsulamiento Multicast con GRE asegurado con IPSec
60
VPNs de Acceso Remoto
2.5.3 Multiprotocol Label Switching (MPLS)
MPLS se dice multiprocolo porque se aplica a cualquier protocolo de
red, pero su uso más habitual es con el protocolo IP. La esencia de MPLS es
la generación de pequeñas etiquetas (labels) de tamaño fijo que cumplen el
rol de un encabezado IP pero con menos información. Esta
etiqueta se usa
para tomar las decisiones de enrutamiento del paquete. MPLS no es un
protocolo de capa 2 ni de capa 3 específicamente, sino un protocolo que
funciona en conjunto con estos.
En un mecanismo de enrutamiento convencional, cada router que recibe
un paquete, verifica el encabezado IP (la dirección destino) para decidir el
siguiente salto. Esta decisión es tomada en forma independiente por cada
router basado en su análisis del encabezado del paquete y de los resultados
de ejecutar algoritmos de enrutamiento. Esto se denomina enrutamiento salto a
salto (hop by hop routing).
La selección del siguiente salto se compone
de dos funciones. La
primera consiste en
clasificar o particionar el conjunto completo de
paquetes en clases de equivalencia, también denominadas FEC (Forwarding
Equivalence Class). La segunda función mapea cada FEC con el siguiente salto.
Los paquetes pertenecerán a una determinada FEC, si la dirección IP destino
de cada uno de ellos coincide, en la manera más exacta, con algún prefijo de
red existente en la tabla de enrutamiento de ese router. A medida que el
paquete atraviesa la red, cada router en su camino lo reexamina y vuelve a
realizar este proceso.
En MPLS, la asignación de un determinado paquete a una determinada
FEC es realizado solo una vez, en el momento que el paquete ingresa a la red
MPLS. La FEC es codificada como un valor de longitud fija
denominada
etiqueta. Cuando el paquete es reenviado se envía la etiqueta también la cual
es utilizada
para indexar una tabla donde figura el siguiente salto y una
nueva etiqueta. Luego de reemplazarla, el paquete es reenviado al siguiente
salto. Cuando el paquete alcanza el último router de la red MPLS, este se
encarga de remover la etiqueta y enrutar a través de los algoritmos
convencionales.
Los routers dentro de una red MPLS se denominan LSR (Label Switched
Routers). Aquellos que se ubican en el ingreso a y egreso de la red, se
denominan LER (Label Edge Router) o dispositivos de borde. Estos últimos son
los encargados de encapsular el paquete, mientras que los routers
pertenecientes al núcleo de la red MPLS, solo se encargan de reenviarlo hasta
el router de borde de egreso de la red.
Este método de reenvío permite que, una vez que el paquete fue
clasificado en una FEC, no se efectúe ningún análisis posterior del
encabezado por parte de los routers que participarán en el transporte del
paquete.
VPNS BGP/MPLS
Una de las aplicaciones mas utilizadas de MPLS es el servicio de VPN
provisto por un proveedor. Esta es una alternativa viable respecto de los
métodos de túneles habituales para implementar VPN.
61
VPNs de Acceso Remoto
No existe un modelo de servicio de VPN único ya que cada cliente
tiene diversos requerimientos, por ejemplo, pueden diferir en los requisitos
de seguridad, cantidad de sitios a interconectar, números de usuarios,
complejidad en el esquema de enrutamiento, aplicaciones críticas, volúmenes
de tráfico, patrones de tráfico, habilidad del propio personal de networking,
etc.
Existen dos opciones: VPN MPLS de capa 3 o capa 2. Uno de los
modelos de mayor aceptación por parte de los proveedores para poder manejar
esta variabilidad de requerimientos, es el propuesto en la RFC 2547 y RFC
2547bis VPN BGP/MPLS. Se trata de una VPN MPLS de capa 3.
Este modelo define un mecanismo que permite a los proveedores de
servicios utilizar su red backbone IP para dar servicio VPN a sus clientes.
El protocolo de enrutamiento de borde BGP (Border Gateway Protocol) es
utilizado para distribuir información de enrutamiento de la VPN a través del
backbone mientras que MPLS se encarga de reenviar el tráfico de la VPN entre
los sitios que la componen.
Las VPN BGP/MPLS buscan cumplir con lo siguiente:

Facilidad de uso

Escalabilidad y flexibilidad para facilitar implementaciones a
gran escala.

Soporte de direcciones IP globalmente únicas
cliente y solapamiento de direcciones privadas.

Soporte de solapamiento de VPN, es decir que un sitio puede
pertenecer a más de una VPN.
para los clientes
en la red del
Las VPNs BGP/MPLS toman un datagrama IP de la red del cliente,
determinan la dirección IP destino buscando en una tabla de reenvío y luego
envían ese datagrama hacia su destino a través de la red del proveedor
mediante un LSP.
2.6 PROTOCOLOS DE TÚNEL CAPA 4
Además de los protocolos de capa 2 y capa 3, se pueden considerar,
además, dos protocolos para crear túneles pero en las capas superiores. En
particular entre la capa de transporte y de aplicación. Se describirán las
generalidades de SSH (Secure Shell) y SSL/TLS (Secure SocketsLayer)/
(Transport Layer Security).
2.6.1 Secure Shell (SSH)
Secure Shell17 es un protocolo cliente-servidor que permite el
servicio de login remoto seguro a través de una red insegura. Si bien su
cometido principal es la creación de una sesión remota mediante un túnel a un
equipo remoto, es posible la transmisión de otra clase de tráfico TCP
mediante la redirección de puertos.
17
RFC 4251 - The Secure Shell (SSH) Protocol Architecture
62
VPNs de Acceso Remoto
Este protocolo consiste de tres componentes principales:

Protocolo de capa de transporte: brinda autenticación del
servidor, confidencialidad e integridad con PFS (Perfect
Forward Secrecy) ejecutándose sobre la conexión TCP/IP.

El protocolo de autenticación del cliente:
protocolo de transporte.

Protocolo de conexión: multiplexa el túnel en varios canales
lógicos y se ejecuta sobre el protocolo anterior.
opera sobre el
SSH utiliza, en un principio, autenticación basada en host para
autenticar el servidor. Este procedimiento es llevado a cabo por la capa de
transporte de SSH. Durante esta etapa se utilizan claves públicas de host
(host key)18. Esta capa no realiza la autenticación basada en usuario, la cual
es relegada a las capas superiores.
Este procedimiento requiere que el cliente confíe en la clave que le
presenta el servidor. Para esto el cliente puede tener un conocimiento previo
de la misma y efectuar una comparación, mediante algún mecanismo de firma o
encriptación de un hash o certificando la validez de la misma a través de una
Autoridad Certificante o CA.
Si bien la segunda alternativa facilita la administración del mapeo
nombre
de
servidor/clave
pública,
requiere
la
presencia
de
una
infraestructura PKI (Public Key Infraestructure), la cual no es simple de
implementar e implica costos económicos importantes para la organización.
El protocolo de capa de transporte de SSH, es el encargado de
autenticar el servidor y negociar el método de intercambio de clave, los
algoritmos de encriptación simétrica, de clave pública, de autenticación de
mensaje (HMAC) y de hash. El método de intercambio de claves es importante ya
que define como generar las claves de sesión a utilizar en la conexión para
encriptar y firmar digitalmente, además de establecer como autenticar al
servidor.
El protocolo de capa de autenticación de SSH19 se encarga de efectuar
la autenticación basada en usuario. SSH soporta autenticación basada en
usuario mediante clave pública, passwords y basada en equipo. En el caso de
usar passwords, estas son encriptadas cuando el paquete de autenticación es
procesado por la capa inferior de transporte. La autenticación basada en
equipo o host, consiste en verificar la identidad del host desde donde el
usuario se conecta, junto con la existencia del nombre de usuario. El cliente
firma un mensaje con su clave privada y el servidor la verifica con la clave
pública del cliente. Luego se verifica que el nombre de usuario enviado por
el cliente tenga autorización. Este método no es aconsejable en escenarios
que requieran seguridad.
18
RFC4253 The Secure Shell (SSH) Transport Layer Protocol
19
RFC 4252 SSH Authentication Protocol
63
VPNs de Acceso Remoto
Finalmente el protocolo de capa de conexión se ejecuta por encima
de los protocolos de transporte y autenticación de SSH. Brinda sesiones
interactivas de login, ejecución remota de comandos, reenvío de tráfico
TCP/IP y de conexiones del servicio de manejo de ventanas X11. Todo estas
conexiones son establecidas mediante canales que son multiplexados a través
de un único túnel establecido por el protocolo de capa de transporte, a esto
se lo denomina multiplexación ascendente20 (upward multiplexing).
2.6.2 Secure Sockets Layer/Transport Layer Security (SSL/TLS)
SSL fue creado originalmente para asegurar el tráfico web, pero se
utiliza también para asegurar protocolos diferentes a
HTTP. Brinda
confidencialidad a la capa de transporte
mediante el uso de criptografía
simétrica mientras que la autenticación
y
manejo de claves se realiza
mediante la criptografía de clave pública.
TLS21 esta basado en la versión 3 de SSL, pero no es el mismo
protocolo. Se trata de un estándar sobre el cual se basan implementaciones
tantos comerciales como abiertas. Brinda privacidad e integridad a los datos
transmitidos en una comunicación entre dos aplicaciones.
La interoperabilidad de SSL/TLS es muy alta, no es común los
problemas en la interacción entre clientes
y servidores de diferentes
fabricantes. Dado que no se utiliza el encabezado IP para el procesamiento,
sino
la conexión autenticada y establecida, SSL/TLS no es afectado por la
presencia de dispositivos que efectúen operaciones de traducción de
direcciones o NAT.
SSL/TLS soporta una variedad de métodos de autenticación, siendo el
más común el uso de certificados digitales para la autenticación tanto del
servidor como del cliente (opcional).
Las VPNs SSL pueden transportar cualquier tráfico TCP inclusive
tráfico UDP. Debido a que SSL/TLS es un servicio de la capa de transporte,
una VPN SSL puede aplicar control de acceso a nivel de aplicación
y por
supuesto de transporte.
A diferencia de IPSec, el cual es un proceso que se ejecuta en modo
kernel o privilegiado, SSL es un protocolo que se ejecuta como proceso a
nivel de usuario. Esta característica hace que una solución VPN SSL sea más
estable y robusta. Cuando existe una dependencia directa con el sistema
operativo, cualquier falla del proceso puede generar inestabilidad a todo el
sistema.
2.7 TOPOLOGÍAS
La topología aplicada a las redes de datos, describe las relaciones
entre los componentes de una red. Su aplicación más simple define como se
interconectan los dispositivos que integran una red. Además, el uso correcto
de la terminología topológica evita confusiones cuando se hace referencia a
esquemas de redes.
20
21
Data & Computer Communications Cap. 2 – William Stallings
RFC 4346 - The Transport Layer Security (TLS) Protocol Version 1.1
64
VPNs de Acceso Remoto
La clasificación más básica de las topologías está en función de la
naturaleza de la relación de conectividad de los componentes de la red. Puede
ser de naturaleza física como un medio
de transmisión (cable tecnología
ethernet, fibra óptica, enlace satelital etc.) o de naturaleza lógica, como
la ruta que utiliza un flujo de bytes para conectar dos host. En este caso se
considerarán las topologías desde una perspectiva lógica, debido a que las
redes privadas virtuales son un objeto lógico, tal como se las define en el
primer capítulo.
Lo más importante al estudiar la topología de una red es el impacto
de esta sobre otros aspectos que influyen en el desempeño de la misma. Uno de
estos aspectos es la escalabilidad la cual es crítica cuando se trata de
redes que tienden a crecer o que el número de nodos a interconectar es
numeroso y variable. La escalabilidad de una red se puede definir en función
de tres características de su diseño22:

Capacidad de manejar mas conexiones

Facilidad de mantenimiento

Costo
En el caso particular de las VPN, existen otros aspectos que están
influenciados por la topología: el mecanismo de distribución de claves para
la autenticación de los nodos y la distribución de la información de
enrutamiento necesaria para permitir la comunicación entre los componentes de
una misma VPN.
2.7.1 Escenarios
En el terreno de las redes privadas virtuales existen básicamente
tres escenarios que describen las relaciones entre los nodos de una VPN. Las
conexiones entre sitios o redes, la conexión entre un
host y una red y la
conexión entre solo un par de hosts.
El escenario red a red (Figura 2-24) presenta la conexión de dos o
más subredes mediante uno o más túneles. Cada subred consiste de un gateway y
al menos un host. EL gateway posee dos interfaces de red, una para conectarse
al túnel y la restante para conectarse con la subred interna. El gateway
realiza el proceso de creación y eliminación del túnel, así cómo la
aplicación de mecanismos de seguridad al tráfico que reenvía.
22
Kolesnikov, Hatch, Davis, Mongol - Building Linux VPN: VPN Fundamentals - Cap 2
65
VPNs de Acceso Remoto
Figura 2-24 Escenario Red a Red
El escenario host a red (Figura 2-25) se puede considerar un caso
especial del anterior donde una de las partes, en lugar de ser una red, es
solo un host y no hay presencia de un gateway. Este esquema se aprecia en las
VPN de acceso remoto, donde los usuarios de una organización se encuentran
físicamente alejados de su lugar de trabajo, pero pueden acceder remotamente
a los recursos de la red de datos local.
Figura 2-25 Escenario Host a Red
Finalmente en el esquema host a host solo dos equipos podrán
establecer una comunicación segura. Este escenario es una reducción del caso
host a red. Si hubiera necesidad de comunicar más hosts, entonces serían más
apropiados los escenarios anteriores.
Estas formas de relación determinan los esquemas topológicos más
habituales en el mundo de las redes: punto a punto, punto multipunto,
estrella (hub and spokes) y malla total o parcial (full or partial mesh),
aunque también es posible combinar alguna de ellas e implementar una
topología híbrida. Su aplicación a las VPNs posee sus ventajas y desventajas.
66
VPNs de Acceso Remoto
2.7.2 Topología Punto a Punto
Esta es la topología más simple, ya que es una conexión directa
entre dos entidades. Esta relación de conectividad directa aún es válida si
en un nivel inferior existen entidades cuya tarea es el reenvío de la
comunicación hasta llegar al destino. Es decir, es una comunicación directa
en la capa N aún cuando en la capa N-1 es necesario atravesar varios nodos
hasta llegar al destino23.
Esta topología se puede encontrar en VPNs, como casos particulares
de otros esquemas más complejos, como en el caso de la estrella (hub and
spoke), donde cada extremo (spoke) tiene un enlace punto a punto con el
centro (hub) para poder comunicarse con los demás extremos.
Los ejemplos mas simples de VPNs con esta topología son las
tradicionales de capa de enlace basadas en servicios ATM o Frame Relay, ya
que establecen una conexión punto a punto entre sitios de una organización.
También se puede considerar los túneles de capa de red basados en IP que se
crean con el mismo fin y conectan dos dispositivos CE, utilizando IPSec o
GRE.
Un caso más específico es el servicio VPWS (Virtual Private Wire
Service). Se trata de un tipo de VPN de capa 2 provista por el proveedor.
Este brinda un servicio de conectividad punto a punto entre los sitios de un
cliente. Este servicio emula enlaces dedicados entre los sitios mediante
túneles IP dentro del backbone del proveedor, manteniendo a la vez la
infraestructura ATM o Frame Relay existente del cliente. Una forma de
realizarlo es utilizando los circuitos virtuales (CV) Frame Relay o ATM entre
los dispositivos CE del cliente y PE del proveedor y mapearlos a túneles MPLS
(LSP) establecidos a través del backbone.
Esta solución presenta problemas de escalabilidad cuando el
proveedor tiene que servir varias VPNs, ya que cada LSP deberá ser
configurado individualmente y mapeado a cada CV de los clientes. Esto
conlleva un gran esfuerzo de administración, además el aumento de los túneles
LSP para satisfacer nuevas demandas impactará en la capacidad del manejo de
estos en los routers y switchs del proveedor, tanto los equipos de borde (PE)
como los pertenecientes al núcleo del backbone (P).
Una mejora al enfoque anterior es el denominado PWE3 (Pseudowire
Emulation Edge-to-Edge) VPWS, como lo muestra la Figura 2-26. En esta
situación se mejora la escalabilidad utilizando un número fijo de LSP entre
los dispositivos PE del backbone del proveedor. Luego se crean conexiones
emuladas punto a punto (pseudowires) entre los PE mediante túneles basados en
los LSP ya establecidos. Estas conexiones simuladas son encapsulaciones de
protocolos de capa 2 (ATM, Frame Relay, Ethernet, etc.) en tramas MPLS24.
Nuevamente es necesario que cada pseudowire sea configurado en forma
individual, afectando la escalabilidad cuando el proveedor sirve varias VPNs.
Sin embargo se reduce la carga de procesamiento a solo los routers de borde
ya que únicamente en estos se definen los pseudowires.
23
Designing Addressing Architectures for Routing & Switching – Howard Berkowitz, Cap. 2
24
draft-ietf-pwe3-atm-encap; draft-ietf-pwe3-frame-relay; draft-ietf-pwe3-ethernet-encap.
67
VPNs de Acceso Remoto
Figura 2-26 Punto a Punto en VPN VPWS
Para mejorar la escalabilidad, se requiere que las conexiones punto
a punto se establezcan mediante un mecanismo automatizado, como por ejemplo
el protocolo BGP. En esta situación cada dispositivo PE usa BGP
multiprotocolo para anunciar las VPN y dispositivos CE que este controla.
Esta información acompaña las etiquetas MPLS utilizadas por los PE para
reenviarse datos entre sí. De esta forma, cuando los CE reciben esta
información, poseen los datos necesarios para crear los pseudowires25 sobre
los PE.
2.7.3 Topología Punto a Multipunto
Esta topología permite establecer más de un camino desde un lugar a
múltiples destinos. Cualquier transmisión de datos, originados en un punto
de conexión central es recibida por todos los puntos de conexión periféricos,
mientras que la comunicación en el otro sentido, desde la periferia, sólo es
recibida por el extremo central.
El servicio de VPN de capa de enlace VPLS (Virtual Private LAN
Service) brinda un servicio multipunto mediante una configuración de malla
completa. Una VPLS es establecida por un proveedor de servicios y emula una
LAN tradicional. Permite conectar varios segmentos de LAN, distantes
geográficamente, sobre una red de conmutación de paquetes de manera que las
redes remotas se comporten como una única LAN. En esta situación los equipos
CE no deben seleccionar el pseudowire para reenviar los datos para un destino
determinado (topología punto a punto); simplemente reenvían todo el tráfico
al dispositivo PE del proveedor, quien se encarga de enviarlo al destino
correspondiente.
25
draft-kompella-ppvpn-l2vpn
68
VPNs de Acceso Remoto
Esto es posible en redes MPLS donde se establece una topología de
malla completa de pseudowires entre los dispositivos PE del proveedor que
integran una determinada VPLS. Gracias a este esquema los PE pueden realizar
replicación de paquetes (inundación por destino desconocido, broadcast,
multicast) y aprendizaje de direcciones MACs tal como lo haría un bridge o
switch ethernet.
Para simplificar la configuración de una VPLS, son necesarios
mecanismos automáticos para obtener información de los integrantes de la
VPLS, como llegar hacia ellos y conectarse finalmente. Esto facilita también
el agregado de nuevos nodos y la administración de las conexiones (manejo de
pseudowires) entre ellos. De lo contrario el manejo y escalabilidad de la VPN
se vería afectada.
2.7.4 Topología Estrella (Hub and Spokes)
Esta es la topología más común en VPNs. Existe un gateway VPN o
concentrador (hub) y una serie de clientes (spokes) que establecen una
conexión punto a punto con este, un túnel de hecho. Para que pueda existir
comunicación entre los clientes remotos, el tráfico de datos deberá ir desde
el cliente emisor hasta el concentrador, luego este retransmitirá esos datos
hacia el cliente receptor. No existe una conexión directa entre los clientes,
toda la comunicación deberá atravesar primero el concentrador.
Esta topología afecta la escalabilidad en cuanto a que está limitada
al desempeño y la capacidad de procesamiento del concentrador. Este deberá
soportar conexiones simultáneas. Por esta razón el desempeño general de la
VPN dependerá fundamentalmente de la capacidad del concentrador. Por otro
lado este esquema presenta un único punto de falla en el concentrador mismo.
La disponibilidad de la VPN dependerá de la falla
de solo uno de sus
componentes. Otra desventaja que presenta es que si dos clientes remotos se
encuentran geográficamente cerca, igual deberán enviar su tráfico al
concentrador en lugar de utilizar una conexión directa entre ellos.
Sin embargo, este esquema tiene la ventaja de una administración
centralizada, respecto del monitoreo, mantenimiento, control de accesos,
registro de eventos. Además el hecho de agregar un nuevo componente a la VPN
es simple debido a que esta operación se centraliza en el hub.
Una forma de paliar la desventaja que significa un único punto de
falla, es una variación de la topología donde exista más de un concentrador,
tanto para brindar redundancia como para balancear la carga relacionada con
las conexiones simultáneas de los clientes. Existe un esquema donde se busca
la redundancia pero en el lado del cliente, duplicando el componente spoke.
Esto permite el balanceo del tráfico emitido desde el cliente a través de la
duplicación de la conexión con el concentrador. Si bien esta organización
brinda la máxima disponibilidad, es prohibitiva en términos de costo en
equipos y en la poca conveniencia de invertir recursos en el extremo del
cliente.
Esta topología y sus variantes se aplican en los escenarios red a
red, tanto para conectar los sitios de una misma organización como así
también
cuando
se
implementan
VPN
extranets
con
sitios
de
otras
organizaciones.
69
VPNs de Acceso Remoto
Las VPN sitio a sitio utilizando IPSec son un ejemplo de la
aplicación de esta topología. Es común considerar el uso del protocolo GRE
para permitir el tráfico multicast entre los sitios de la VPN. En este caso
particular, existen una serie de aspectos relacionados con la escalabilidad
debido al protocolo IPSec:

Escalabilidad SA (Asociaciones de Seguridad): se refiere al
número de asociaciones de seguridad activas a soportar, así como
su detección, eliminación y manejo. Esto es un aspecto
importante en el concentrador y no en el cliente. El primero
debe mantener una base de datos de SA relacionadas con la
conectividad de todos los clientes.

Capacidad de túneles IPSec: Las políticas de seguridad que se
aplican pueden impactar en la perfomance del concentrador. La
selección de algoritmos criptográficos fuertes lleva a una
sobrecarga de la capacidad de cómputo. Hay que balancear el
requerimiento de la política y la carga en el mantenimiento de
los túneles con un cálculo apropiado de las necesidades futuras
de agregaciones de nodos clientes a la VPN.

Capacidad de procesamiento criptográfico: este aspecto esta
relacionado directamente con el anterior, en términos del
throughput de paquetes por segundo que es capaz de procesar el
módulo de encriptación.

Capacidad de mantenimiento de túneles GRE: Si bien la mayoría de
los dispositivos VPN soportan los túneles GRE, no lo implementan
a nivel de hardware. Si se requiere esta encapsulación, la misma
no deberá limitar el throughput o el procesamiento en el
concentrador.
2.7.5 Topología
Mesh)
de
Malla
Completa
o Parcial
(Full
or
Partial
En un diseño de malla completa (full mesh), cada dispositivo se
comunica en forma directa con todos los demás. En el caso de malla parcial
(partial mesh) solo ciertos dispositivos tienen conexión directa entre sí. La
razón de ello radica en que no todos requieren más de una conexión. Solo
aquellos que requieren alta disponibilidad y que la interrupción de una de
sus conexiones no deje al sitio incomunicado con el resto.
Este modelo tiene
beneficios son:
varios
beneficios
y
una
gran desventaja.
Los

No existe un único punto de falla, los dispositivos no dependen
de un concentrador para la comunicación dentro de la VPN

La perfomance general no está limitada a un solo sistema.

Aquellos dispositivos que están próximos geográficamente, pueden
comunicarse directamente sin intermediario.
70
VPNs de Acceso Remoto
La desventaja radica en el incremento del mantenimiento en cuanto a
la distribución de las claves para asegurar las comunicaciones o en la
distribución de información de enrutamiento. En particular si se usa IPSec,
la creación de asociaciones de seguridad necesarias para cada nodo que se
sume a la VPN representa un costo en el mantenimiento. La situación puede
mejorar si se utilizan métodos automáticos para la distribución de claves, o
la transmisión dinámica de rutas.
Nuevamente los escenarios red a red implementan esta topología
cuando hay un requerimiento de alta disponibilidad o bien sea necesario un
servicio multipunto como en el caso de las VPLS, donde se crea una topología
de malla completa de pseudowires entre los dispositivos PE del proveedor y
así los dispositivos del cliente pueden llegar mediante multicast o broadcast
hacia las otras redes integrantes de la misma VPLS.
71
VPNs de Acceso Remoto
CAPÍTULO 3
VPNs DE ACCESO REMOTO
3
72
VPNs de Acceso Remoto
3.1 INTRODUCCIÓN
En un principio el acceso remoto se caracterizaba por la utilización
de la red de telefonía urbana, mediante líneas discadas, para conectarse
hacia la red de datos de la organización. El usuario pertenecía a esta
organización. Estas conexiones se establecían desde la ubicación del usuario
hasta el servidor RAS. Los protocolos utilizados se basaban en PPP y las
funciones AAA es decir Autenticación, Autorización y Auditoría, estaban a
cargo de un servicio específico como RADIUS.
Se asumía que la infraestructura de comunicaciones por donde se
prestaba el servicio de acceso era relativamente segura y por ende no
significaba un entorno hostil que amenazara la confidencialidad ni la
integridad de la comunicación. Teniendo en cuenta esto, la seguridad de la
conexión estaba limitada respecto del control de acceso en el RAS, a un par
usuario/contraseña.
En la actualidad, las tecnologías de acceso a Internet mediante ISP,
como un servicio dial-up o DSL, poseen carácter masivo y relativamente barato
para los usuarios, brindando un servicio por demás adecuado para reemplazar
los accesos discados directos que podían ser extremadamente caros si el
usuario remoto se encontraba fuera de los límites del sistema de telefonía
local. Sin embargo el inconveniente es la naturaleza pública por ende
insegura de Internet.
Figura 3-1 Escenario General
El escenario de las VPN de acceso remoto puede ser definido en
general de forma única (Figura 3-1) si bien hay variaciones particulares del
mismo. En cualquiera de los casos, un cliente desea conectarse en forma
segura a una red remota y poder tener acceso a los recursos disponibles en la
misma. Para esto deberá establecer una conexión con un gateway de seguridad o
servidor de acceso remoto, para luego configurar un túnel por donde fluirán
los datos de la comunicación en forma segura.
Esta
comunicación
generalmente
se
establece
desde
una
red
corporativa diferente a la red destino. Es habitual la utilización de la red
de un proveedor de servicios de Internet o ISP (Internet Service Provider)
con una conexión dial-up o DSL, donde es posible la presencia de dispositivos
intermedios que conectan varias redes entre el cliente remoto y el gateway de
seguridad.
73
VPNs de Acceso Remoto
3.1.1 Requerimientos básicos de seguridad
Existen requerimientos básicos en cuanto a la seguridad, los que
pueden ser clasificados en: autenticación de los extremos de la conexión,
configuración de la política de seguridad (control de acceso y autorización)
y auditoría.
Autenticación de los extremos
Existen dos clases de autenticación: la autenticación del origen de
datos y la autenticación de la entidad. En el primer caso se asegura que los
paquetes de red se originan desde un único sistema, host, usuario o
aplicación, mientras que en el segundo caso se asegura que quien genera
dichos paquetes, es quien dice ser.
Ambos
tipos
de
autenticación
se
relacionan
entre
sí,
la
autenticación del origen de datos depende de la autenticación de la entidad.
Para asegurar que un paquete se origina en un host particular o que provenga
realmente de la red en la cual reside el host, es necesario en principio,
autenticar la entidad y luego asociar la información del origen de datos (IP,
puerto, protocolo de transporte) a esta relación de confianza establecida por
el proceso de autenticación.
La entidad autenticada puede ser un host, un usuario, o ambos. Por
esta razón la autenticación puede ser a nivel de máquina o a nivel de
usuario. Entre los mecanismos utilizados para este proceso se cuentan: clave
compartida o PSK (Pre Shared Key), la firma digital con el uso de
certificados, claves RSA (Rivest Shamir Adleman).
Autenticación a nivel de máquina/usuario
Cuando dos partes se comunican de manera segura, la fase inicial de
ese proceso corresponde a la autenticación del cliente remoto y/o del
servidor. En el caso de que el cliente posea las credenciales para intentar
una autenticación y no requiera la participación de un usuario para poder
utilizar dichas credenciales, la entidad autenticada será el dispositivo
donde se encuentren almacenadas. El nivel de seguridad de este procedimiento
dependerá de cuan fiable sea almacenar y utilizar las credenciales en el
dispositivo.
Si se requiere la intervención de un usuario donde verifique algún
criterio para tener acceso a las credenciales, el servidor no tendrá una
certeza sobre la identidad de este. Para tenerla, son necesarias las
credenciales de usuario.
La autenticación de usuario implica la presentación de alguna
información de autenticación en forma directa hacia el servidor durante la
fase de autenticación. Si el dispositivo desde donde el usuario esta
intentando acceder no presenta sus propias credenciales, entonces la entidad
autenticada será solo el usuario.
Para lograr autenticar ambas entidades, se requiere la interacción
con el usuario mediante una entrada de datos. Esta puede o no complementar a
las credenciales del dispositivo, por ejemplo el ingreso de una passphrase
para desencriptar una clave privada contenida en el dispositivo. En el otro
caso la entrada del usuario es independiente de las credenciales almacenadas
allí.
74
VPNs de Acceso Remoto
En general los requerimientos de autenticación son asimétricos.
Desde la perspectiva del cliente es importante asegurarse que el servidor, en
el otro extremo, sea realmente quien dice ser. Es decir es necesaria una
autenticación a nivel de máquina.
Desde la perspectiva del servidor la situación es un poco diferente.
Es importante determinar que la entidad en este extremo sea la autorizada y
no un programa malicioso o alguien no autorizado que esté utilizando un
dispositivo de la organización. Autenticar a un usuario requiere alguna forma
de entrada por parte de este para el envío de credenciales y este mecanismo
debería ser renovado periódicamente. Este último aspecto debería ser un
equilibrio entre el intervalo de renovación (lo que puede ser molesto para el
usuario) y el riesgo real de compromiso de las credenciales. En este caso es
aconsejable el uso de sistemas de claves de uso único u OTP (One Time
Password).
Este no es el caso cuando se trata de equipamiento provisto por la
organización al usuario móvil. Se asume que el dispositivo es confiable
porque, como equipamiento de la organización, cumple con las políticas de
seguridad de la misma y tendrá el software necesario, tanto el cliente VPN
como antivirus, firewall y demás herramientas de seguridad instaladas y
actualizadas
que
el
staff
de
administración,
con
los
privilegios
correspondientes, se encargaron de incorporar al equipo.
3.1.2 Configuración de las políticas de seguridad
Es posible configurar políticas de acceso tanto en
como en el gateway de seguridad. En el primer caso se puede
acceso a Internet desde el cliente, también se redirija a
con la red de la organización, evitando que el tráfico HTTP
inseguras.
el cliente remoto
considerar que el
través del túnel
lo haga por redes
En cuanto a políticas aplicables al gateway de seguridad, se puede
establecer la asignación dinámica de permisos de acuerdo al usuario o sistema
que establece la conexión. Este esquema puede valerse de un mapeo uno a uno,
respecto de la dirección IP origen de la conexión y los permisos
correspondientes. Una alternativa más escalable sería asociar una serie de
permisos a un conjunto o rango de direcciones.
3.1.3 Auditoría
La auditoría se refiere a la recolección de información de estado de
las conexiones dirigidas al gateway de seguridad por parte de los clientes
remotos. El propósito de esta operación es mantener la seguridad e integridad
de la red destino de la organización. Desde una perspectiva de la seguridad,
es de utilidad tener el registro del tiempo de inicio y fin de una conexión.
Es necesario un método para monitorear el tiempo de conexión de los
clientes y poder manejar los casos en donde estos finalicen su conexión en
forma no explícita. Para estas situaciones se utiliza un mecanismo de
heartbeat por el cual el cliente remoto envía una señal luego de un tiempo
para indicar al gateway que aún se mantiene en línea. Pasado un tiempo
(umbral de reset), sin recibir una nueva señal por parte del cliente, el
gateway da por finalizada la conexión.
75
VPNs de Acceso Remoto
El intervalo de heartbeat puede influir en forma negativa
si es
demasiado corto. Si se presenta congestión en la red, es probable que se
pierdan algunos paquetes de heartbeat del cliente y el gateway finalice la
conexión al alcanzar el umbral de reset rápidamente.
Ambos parámetros
deberían poder ser ajustados mediante configuración o durante la negociación
de la conexión.
3.2 ESCENARIOS
Existen escenarios comunes en las VPNs de acceso remoto:

Tele trabajadores/usuarios móviles operando dispositivos propios

Acceso con
extranet

Acceso desde una extranet con un dispositivo de esta a la red
local

Acceso
un
dispositivo
local
a
la
red
local
desde
una
de usuarios móviles desde dispositivos públicos
Las diferencias se aprecian en los requerimientos
seguridad que se necesitan cumplir en cada escenario.
básicos
de
3.2.1 Tele trabajadores/usuarios móviles operando dispositivos
propios
Este escenario presenta a usuarios de una organización que se
encuentran fuera de los límites de esta y requieren
acceso
a la red de
datos. Estos pueden estar en sus casas o en un sitio geográficamente
distante. En cualquier caso estos usuarios están operando equipos de la
organización o personales, en este último caso deben cumplir con las
políticas de seguridad.
El usuario utiliza la red pública y la de un ISP para establecer la
conexión. Para el caso del gateway VPN, éste debe autenticarse a nivel de
equipo, lo cual es suficiente. En cuanto al cliente es recomendable la
autenticación a nivel de usuario. Para el caso de conexiones permanentes es
conveniente la renovación periódica de las credenciales del usuario. Esto
puede ser opcional en el caso de conexiones discadas de corta duración.
En términos de políticas de seguridad aplicable al cliente, se
destaca el hecho de que si el cliente tiene acceso a Internet, entonces
también es posible un acceso recíproco desde Internet hacia el cliente, todo
esto mientras esta conectado a la red local de la organización. Es
recomendable desestimar el acceso a Internet mientras se utilice el acceso
VPN. Como alternativa se puede derivar el tráfico hacia y desde Internet a
través del túnel de la VPN donde podría estar sujeto a la aplicación de
alguna política de seguridad. Otra opción sería aplicar esa política
directamente en el cliente para el tráfico Internet sin requerir la
derivación de ese flujo hacia la red local.
76
VPNs de Acceso Remoto
3.2.2 Acceso con un dispositivo propio a la red local desde una
extranet
En esta situación, hay una extranet establecida. La extranet puede
reunir
dos
o más
redes
diferentes cuyo
control
administrativo
es
independiente en cada caso. Este escenario plantea el caso de usuario y su
notebook perteneciente la red corporativa A funcionado en la red de B. Dada
la relación entre ambas corporaciones, por la cual se generó tal extranet,
el usuario de la red A se encuentra trabajando en la red corporativa B con su
portátil. Su intención es conectarse a su red local.
Aquí los requerimientos de autenticación en el cliente son a nivel
de usuario ya que es necesario asegurar que quien inició la conexión sea el
mismo usuario activo durante todo el tiempo que dure la misma. Es
recomendable la doble autenticación, tanto a nivel de máquina como de
usuario. Cualquiera sea el caso, la autenticación deberá ser renovada
frecuentemente. El gateway o servidor VPN deberá realizar la autenticación a
nivel de máquina.
Si bien el dispositivo pertenece a la corporación A, no se le puede
aplicar la política para derivar todo su tráfico hacia la red de pertenencia
ya que se encuentra en los dominios de la red B y de hecho posee su
configuración de red. Hay que tener en cuenta que, dada la naturaleza de este
escenario, la notebook necesitará interactuar con los recursos de B. Puede
estar sujeto a estas restricciones el tráfico hacia y desde Internet.
3.2.3 Acceso desde una extranet con un dispositivo propio de
esta, a la red local
Este es un caso similar al anterior, con la excepción que el
dispositivo es externo a la red destino, esta fuera del control de esta.
Nuevamente el tipo de autenticación más importante debe ser a nivel de
usuario ya que a nivel de máquina es difícil de determinar el nivel de
confianza sobre el equipo. Las credenciales del usuario deben renovarse
periódicamente.
3.2.4 Acceso de usuarios móviles desde dispositivos públicos
Los dispositivos de acceso son públicos y no están bajo el control
de la organización. En el caso donde el dispositivo utilizado no sea propio o
no pertenezca a la organización, por ejemplo un usuario remoto móvil operando
una PC en un cyber café, la autenticación a nivel de dispositivo del cliente
carece de sentido. Tampoco es aconsejable el uso de claves estáticas, ya que
pueden ser capturadas mediante un programa de captura de teclas instalado en
dicha PC, aún cuando se este utilizando un smartcard que almacene las
credenciales de usuario.
Existe otro inconveniente en este escenario. Al no estar la PC bajo
el control de la organización, no es posible que el cliente pueda verificar
los datos del servidor o gateway VPN con el cual desea conectarse. Es
imposible el almacenamiento seguro de información que permita autenticar al
servidor, previo a la conexión, por ejemplo una clave precompartida (su uso
no es aconsejable) o un certificado de clave pública de la CA que emitió el
certificado del gateway.
77
VPNs de Acceso Remoto
Esta información se incorpora al dispositivo al momento de la
instalación de un software cliente VPN. Esta operación suele requerir
privilegios de administrador, por lo que sería difícil realizarlo con un
dispositivo público. Peor es la situación donde sí es posible hacerlo, porque
si se obtienen privilegios para la instalación del cliente se tiene que
asumir que un programa malicioso también los tendrá.
En este escenario se aplican soluciones, que si bien no son
verdaderas VPNs, el mercado ha forzado a que se las considere como tales (Web
VPNs). El uso del protocolo SSL, presente en la mayoría de los clientes web o
navegadores, permite un acceso seguro muy limitado, únicamente a aplicaciones
basadas en este protocolo. Esto requiere de un mecanismo de proxy reverso que
permita el manejo de las peticiones, considerando además unos mecanismos de
autenticación.
Como complemento a este acceso limitado se puede implementar lo que
se conoce como un sistema de Evaluación y Validación de la Seguridad del
Extremo (Endpoint Security Posture Assessment and Validation) que permite
analizar el estado del dispositivo remoto y determinar cuan confiable es para
permitirle la conexión. Esto se logra buscando virus o programas maliciosos
mediante un análisis en el dispositivo remoto, determinando si su SO esta
actualizado y si tiene software de seguridad activo y actualizado. Si cumple
con el nivel de confianza esperado se le permite la conexión, caso contrario
se impide el acceso.
Se considera imprudente la utilización de esta clase de dispositivos
si no se tiene un nivel de certeza respecto de la confiabilidad del mismo.
Este escenario no es el adecuado para tener un acceso completo a la red local
mediante la VPN, debido a las limitaciones del entorno respecto a la
integridad del proceso
de autenticación, tanto a nivel de dispositivo como
de usuario.
3.3 ARQUITECTURA DE SEGURIDAD
Cuando desde la propia red local se interactúa con equipos presentes
en redes externas como extranets, o públicas como Internet, se accede a un
entorno fuera del control de la organización, por lo tanto inseguro.
Permitir interactuar equipos situados en estos entornos con los
propios de la organización es un panorama aún más crítico que requiere tener
presente la seguridad considerando:

Las políticas de seguridad de la organización y definir
aplicación tanto a los clientes como al servidor VPN.

Definir claramente los servicios de la red local que estarán
disponibles para los usuarios remotos.

Control del tráfico entrante y saliente.

Un adecuado manejo del servicio de autenticación de los usuarios
remotos.

Una correcta disposición del gateway VPN en el esquema de la red
junto con una adecuada interacción con el firewal.
78
su
VPNs de Acceso Remoto

El nivel de hardening, o cuan seguro es el gateway VPN si este
se ubica directamente en el borde de la red.

Mantener un sistema de auditoría
asociados a los accesos a la VPN.

Asegurar la disponibilidad del servicio de VPN de acceso remoto
que
registre
los
eventos
3.3.1 Gateway VPN y Firewall, seguridad en la frontera
Un firewall es una combinación de hardware y software utilizado para
implementar una política de seguridad que controla el tráfico de datos entre
dos o más redes. La política se aplica solamente sobre la red o redes que
están bajo el control de la organización26.
Al conjunto formado por la red o redes incluidas en el alcance de la
política se lo denomina dominio de seguridad. Es necesario tener claro los
límites de este dominio para evaluar en forma correcta la aplicación de la
política.
La intersección con otros dominios es el escenario donde se
requiere la presencia de un firewall, es decir en el borde o frontera de la
red de la organización.
Un gateway o servidor VPN permite el acceso a usuarios remotos
ubicados fuera del dominio de seguridad de la organización, como Internet, la
red de un proveedor u otra red perteneciente a un dominio de seguridad
diferente. Por esta razón deberá estar ubicado en el mismo ámbito que el
firewall. En general el gateway VPN es parte del conjunto de herramientas y
tecnologías que brindan seguridad a la red de la organización.
Existen diferentes topologías relacionadas con
la ubicación del
gateway VPN, en la mayoría de ellas es aconsejable el diseño basado en DMZ
(Demilitarized Zone) o zona desmilitarizada, ya que brinda mayor seguridad a
la red interna.
Una DMZ es una red donde se ubican
los equipos que brindan los
servicios públicos de una organización. Estos son accedidos desde el
exterior, por esta razón deben estar separados de la red local de la
organización. La DMZ es una red aislada de la red interna mediante un
firewall que se encarga de proteger ésta última y los equipos en la DMZ. Para
lograr esta separación cuenta con al menos tres interfases de red: para la
red externa, la DMZ y la red interna.
Gateway VPN sobre el Firewall
La solución más natural y simple es la implementación del servidor
VPN en el mismo dispositivo donde
funciona el firewall. Es habitual en
dispositivos firewall comerciales, los cuales incluyen funcionalidad de
gateway VPN en sus productos, por ejemplo CISCO en su línea de productos
firewall ASA PIX.
Este diseño permite tener un único punto de entrada a la red de la
organización, donde el firewall autoriza las conexiones salientes hacia el
exterior, previene las conexiones entrantes no autorizadas hacia el interior
y la función de gateway VPN es administrar las conexiones de los usuarios
remotos, autorizando su acceso y encriptando su tráfico.
26
Deploying Firewalls Fithen,Allen,Stoner - Carnige Mellon University
79
VPNs de Acceso Remoto
Las ventajas de este esquema son:

Centraliza el control de toda la seguridad,
disminuye el costo de administración.

La interacción Firewall-Gateway VPN es natural y directa, lo que
facilita la creación dinámica de reglas del firewall aplicadas
al tráfico VPN.

Menos equipamiento.
con
lo
que
se
Figura 3-2 Gateway VPN sobre el Firewall
Las desventajas son:

Único punto de falla.

El protocolo de túnel no es transparente al firewall.

Una configuración incorrecta de las reglas del firewall podrían
permitir el acceso, a través del espacio de direcciones de la
VPN, de tráfico no permitido.

Competencia de recursos de hardware a causa del procesamiento
por parte de los dos servicio. Se requiere un equipo potente en
CPU y memoria.

Escalabilidad limitada si el dispositivo no soporta el agregado
de módulos para des/encriptar. Si se incrementa la cantidad de
clientes remotos, el punto anterior será más evidente.

Costo de entrenamiento para un uso adecuado del dispositivo, si
se trata de una solución propietaria.
80
VPNs de Acceso Remoto
Gateway VPN y Firewall en paralelo
Como en el diseño anterior los servicios se sitúan separados
físicamente en diferentes equipos, pero esta vez la separación del
procesamiento es completa. Este esquema se basa en una DMZ estándar donde
ambos dispositivos tienen acceso a la red interna y a la red externa,
estableciéndose una zona buffer entre el gateway predeterminado de la red
local, el firewall y el Gateway VPN.
Las ventajas son:

Procesamiento en paralelo de tráfico específico sobre los
dispositivos correspondientes. Se desliga completamente al
firewall de atender el tráfico relacionado con la VPN.

Mejor escalabilidad respecto del crecimiento de usuarios
remotos. Se puede agregar mas servidores VPN y distribuir la
carga.

No hay un único punto de falla.

No se requiere procesamiento NAT en el gateway VPN ni en el
firewall.
Figura 3-3 Esquema en paralelo
81
VPNs de Acceso Remoto
Las desventajas son:

El servidor VPN esta conectado directamente a la red externa.
Debe configurarse cuidadosamente (hardening) para evitar que sea
comprometido.

Configurar cuidadosamente ambos equipos para evitar el flujo de
tráfico no permitido.

Incremento en el costo de administración y mantenimiento
configuraciones.

Mayor costo económico por la adquisición de equipos
de las
Este diseño se basa en una DMZ tradicional, donde el dispositivo que
separa la red local es un router de filtrado de paquetes, lo cual lo hace un
esquema poco seguro.
Dependiendo del nivel de seguridad que brinda el servidor VPN, es
recomendable ubicar antes o después de éste
un firewall dedicado para
asegurar el tráfico entrante VPN antes de alcanzar la red interna. Esta
alternativa agrega una demora en el procesamiento de los datos y requiere
compatibilidad con el protocolo de túnel.
Gateway VPN integrado a DMZ única
El gateway VPN se ejecuta en un dispositivo separado del firewall,
una de sus interfaces se conecta a la red externa mientras que la restante se
conecta a la única DMZ compartida con el firewall.
En este caso el tráfico VPN es atendido por el Gateway VPN y es
filtrado por el firewall a través las interfaces de ambos equipos en la DMZ,
para finalmente reenviarlo a la red local interna. Este es un diseño simple y
muy seguro, por lo tanto el más adecuado.
Las ventajas son:

Distribución del procesamiento del tráfico entrante, el gateway
se encarga estrictamente del tráfico VPN.

Menor configuración relacionada al tráfico VPN en el firewall.

Mayor seguridad al tráfico de la VPN que llega a la red interna.

El tráfico VPN puede ser analizado para prevenir ataques en su
paso por la interfaz de la DMZ del firewall.

El
procesamiento
del
tráfico
VPN,
en
el
firewall,
es
independiente del protocolo de túnel utilizado y no se requiere
procesamiento NAT.
82
VPNs de Acceso Remoto
Figura 3-4 Gateway VPN con DMZ única
Las desventajas son:

El servidor VPN esta conectado directamente a la red externa.
Debe configurarse cuidadosamente (hardening) para evitar que sea
comprometido.

El firewall representa un único punto de falla.
Gateway VPN y Firewall con doble DMZ
Este es un esquema de máxima seguridad aplicado al gateway VPN. Se
utilizan dos DMZ para separar el flujo entrante y saliente de la VPN.
Nuevamente los servicios se encuentran en dispositivos separados, pero solo
el firewall se conecta a la red externa. Este filtra el flujo VPN entrante y
saliente a través de dos DMZ establecidas.
Este esquema, si bien es muy seguro, agrega demora al procesamiento
del tráfico ya que se requiere atravesar dos redes además del doble análisis
por parte del firewall, sin embargo el tráfico VPN entrante a la red interna
es confiable.
Las ventajas son:

Acceso remoto hacia la red interna es muy seguro.

Separación del flujo VPN entrante y saliente, lo que
aplicarle reglas de control de forma más específica.
83
permite
VPNs de Acceso Remoto
Figura 3-5 Uso de una doble DMZ
Las desventajas son:

Doble procesamiento del tráfico VPN, proveniente de los clientes
remotos mediante la DMZ Outside y de la red interna a través de
la DMZ Inside.

El firewall es dependiente del protocolo de túnel, al menos
durante el procesamiento en su interfaz conectada en la DMZ
Outside.

Alto costo administrativo de la configuración
3.3.2 Disponibilidad
El servicio de acceso remoto en una organización representa un valor
activo de la misma, ya que permite un mejor desarrollo de las actividades de
sus integrantes. Muchas veces más que por una razón de eficiencia es por una
necesidad estratégica, en concordancia con los objetivos que persigue la
organización. Es decir, la presencia de tal recurso tiene un fundamento y
cumple con un requerimiento importante de la organización.
Es en este marco que asegurar la disponibilidad del servicio de
acceso remoto es un aspecto a considerar. La disponibilidad o Alta
disponibilidad o HA (High Availability) de una VPN de acceso remoto está en
función de los costos que puede asumir la organización ya que implementar HA
no es barato.
84
VPNs de Acceso Remoto
Hay tres esquemas reconocidos que se utilizan para este fin los
cuales son de naturaleza local, es decir se aplican donde se encuentra el
gateway VPN. Estos se basan en el concepto de failover, que significa la
capacidad de cambiar o delegar el control en forma automática a un
dispositivo o equipo redundante para que tome el manejo del servicio o
función para la cual se implementó este mecanismo.
Los esquemas usados para alta disponibilidad son:

Host standby failover: en este esquema hay dos servidores VPN,
uno de los cuales esta inactivo (host standby) respecto de su
función, mientras que el restante está operando como tal. Ante
la falla de este último se activa y toma el control el segundo
servidor. Para que esto suceda deben existir ciertos mecanismos
como protocolos para failover y sincronización entre las
unidades de la información de las sesiones VPN de manera de
minimizar la interrupción durante el failover.

Active-active failover: en este caso ambas unidades están
operando y manejando el tráfico. Mediante el protocolo de
failover se monitorea el estado de ambos equipos. Dado que ambos
equipos están operando la falla de uno de ellos activará el
mecanismo de failover sin interrumpir el servicio.

Mutiunit clustering: similar al esquema anterior pero con más de
dos
unidades.
Si
bien
se
utiliza
para
brindar
alta
disponibilidad,
su
cometido
principal
es
mejorar
la
escalabilidad. Este esquema ofrece redundancia y balanceo de
carga cuando aumenta
el número de clientes remotos. Esta
solución es la más costosa y requiere entrenamiento del personal
para una correcta administración.
Figura 3-6 Alta disponibilidad con Failover Activo
85
VPNs de Acceso Remoto
Figura 3-7 Alta disponibilidad mediante un Cluster
3.3.3 Autenticación, Autorización y Registro (AAA)
El manejo efectivo de los usuarios VPN y de sus privilegios de
acceso es vital en cualquier diseño de VPN de acceso remoto. Existen dos
aspectos principales a considerar:

Una solución segura y escalable para autenticar usuarios

Decisiones basadas en atributos de usuario y de seguridad para
definir los permisos de acceso.
La tecnología AAA permite establecer un esquema de seguridad
dinámico respecto del control de acceso. En la actualidad existe una gran
variedad de mecanismos que permiten autenticar a un usuario, de hecho los
protocolos de VPN se caracterizan por esto. Además es necesaria la asignación
de privilegios en forma dinámica de acuerdo al rol del usuario que intenta
acceder remotamente.
Además de validar al usuario, el proceso de autenticación permite
asignar al usuario a una política de grupo. Esta asignación se realiza en
base a la información de grupo del usuario en la organización y a otros
atributos. Esta política de grupo define los privilegios de acceso del
usuario para la fase de autorización.
Dentro de los protocolos AAA reconocidos está RADIUS cuyas
especificaciones aparecen en la RFC 2058. Éste posee la condición de
protocolo estándar por la IETF27. TACACS es otro conocido protocolo AAA
desarrollado por CISCO. Obviamente se trata de una alternativa propietaria,
que se encuentra y utilizan, por defecto, todos los dispositivos de este
fabricante.
27
Internet Engineering Task Force: Comunidad pública internacional cuyo
mejoramiento constante de Internet. Su misión se documenta en la RFC-3935.
86
objetivo
es
el
VPNs de Acceso Remoto
Componentes Principales
Dentro de una arquitectura AAA existen componentes que interactúan
entre sí. Esta distinción no refiere a dispositivos físicos dedicados sino a
contenedores lógicos de funciones, los cuales suelen estar combinados:

Cliente: es quien intenta acceder a la red y autenticarse a si
mismo o servir como medio para autenticar al usuario que lo
utiliza.

Punto de Aplicación de Política (PEP): también denominado
autenticador. En este caso se trata del gateway VPN, procesa la
solicitud de acceso del cliente y se encarga de aplicar las
restricciones al acceso del cliente.

Punto de Información de Política (PIP): es un repositorio de
información que ayuda a tomar la decisión de permitir o no el
acceso. Se trata de cualquier sistema que almacene datos
relevantes respecto del dispositivo o usuario que requiere
acceso. Por ejemplo servidor LDAP, OTP token server etc.

Punto de Decisión de Política (PDP): es el componente principal
de la arquitectura que toma la decisión de permitir o no el
acceso. Este recibe la solicitud de acceso del cliente a través
del PEP. También consulta al PIP para obtener información
necesaria para tomar la decisión. También puede enviar al PEP
información específica para la autorización del cliente para que
el PEP aplique las restricciones en los privilegios de acceso
correspondientes.

Sistema de Registro y Autenticación: este componente registra
los diferentes eventos relacionados con el acceso de los
clientes remotos. Además permite generar reportes que relacionan
estos eventos para describir el comportamiento de la VPN. Este
puede funcionar en un dispositivo dedicado o ser parte del PDP.
Servidores de autenticación
El diseño de un sistema AAA varía dependiendo del tamaño de la red y
de la disparidad de métodos de acceso que se requieran. En general las
opciones para servidores de autenticación pueden dividirse en dos categorías:

Servidor AAA dedicado ejecutando RADIUS: en este caso el
servidor AAA es la interfase entre el gateway VPN (PEP) y el
servidor de identidad (PIP), servidor LDAP, servidor de Token
OTP, Active Directory. Esta interacción es mediante el protocolo
RADIUS. Esta es una solución flexible ya que el propio protocolo
soporta la interacción con una gran variedad de métodos de
acceso.
87
VPNs de Acceso Remoto

Gateway VPN interactuando con un PIP: en esta situación depende
del gateway interactuar con el servidor de identidad o PIP, por
lo tanto deberá soportar la interacción con diferentes tipos de
servidores de identificación. Un aspecto a tener en cuenta con
este modelo es la capacidad del gateway para obtener información
adicional del cliente o usuario para aplicarlo a la fase de
autorización. Soportar esta característica requiere una mayor
dependencia entre el gateway y el PIP.
3.3.4 Administración y monitoreo
La administración y monitoreo del servicio de VPN son aspectos
importantes a considerar, simplemente porque permiten a los administradores
manejar y conocer el estado del servicio además de su impacto en la red
local. Esto se aplica en forma general para todas las VPNs, no solo a las de
acceso remoto.
Como contrapartida a la importancia de estas actividades, esta el
costo que representa para la organización cumplir con estas. Esto en términos
de equipamiento y el entrenamiento necesario del personal administrativo. En
el escenario general de VPNs, este es el principal motivo para tener que
decidir por un servicio provisto por un proveedor o por la misma
organización.
El monitoreo permite establecer una línea base para referencia de
futuras mediciones y determinar cuando las condiciones son las normales y
cuando se presentan casos atípicos que representan problemas que deberían
generar una alarma. La administración requiere tener las herramientas
necesarias para el cumplimiento de tareas relacionadas al manejo de usuarios,
clientes VPN y del servidor VPN.
La capacidad de administración y monitoreo va a depender de las
herramientas y utilidades que provea la solución implementada.
El monitoreo en una VPN de acceso remoto implica determinar el
estado del gateway VPN y las sesiones establecidas de los usuarios. Entre los
parámetros de importancia a monitorear se pueden distinguir:
Respecto del gateway:

Utilización del Ancho de Banda.

Estadísticas de las interfaces públicas y privadas (Outside vs.
Inside).

Uso del CPU.

Troughtput respecto de cantidad de sesiones en un período de
tiempo.
Respecto de las sesiones de usuario

Ranking de usuarios con mayor actividad en un período de tiempo
respecto de:
o
Throughput
o
Duración de la conexión
o
Tráfico total (Inbound+Outbound)
o
Períodos de tiempo de mayor actividad.
88
VPNs de Acceso Remoto

Intento Fallidos de conexiones.
3.4 PROTOCOLOS
En los escenarios de acceso remoto se destacan algunos protocolos de
túnel tanto de capa 2, 3 y 4. En el capítulo 2 se han descrito la mayoría de
ellos, en particular L2TP, L2F y PPTP de capa 2, mientras que de capa 3 se ha
mencionado IPSec y en capa 4 SSH y SSL.
En la actualidad los más
existentes son IPSec y SSL. Sin
permite establecer un túnel que
transporta tráfico correspondiente
destacados en función de las soluciones VPN
embargo el protocolo SSH o Secure Shell
se utiliza para acceso remoto. SSH solo
a aplicaciones basadas en TCP.
A continuación se describirán los protocolos SSH, IPSec y SSL
mencionando los aspectos más importantes de cada uno, desde una perspectiva
global de implementación para una VPN de acceso remoto.
3.4.1 SSH
Lo más destacado del uso de SSH es la posibilidad de brindar un
canal seguro a aquellos protocolos TCP que no lo son, como los protocolos de
correo electrónico o de terminal remota. A esta funcionalidad se la conoce
como reenvío de puertos (port forwarding).
El concepto es desviar el tráfico asociado a un puerto de una
conexión, hacia un puerto manejado por SSH y transportarlo a través del túnel
SSH hacia el otro extremo en forma encriptada. Es necesario un cliente y un
servidor SSH con una cuenta de usuario válida para el cliente. Existen dos
clases de reenvío de puertos: local y remoto. Estos son establecidos por el
cliente SSH.
Reenvío Local de Puerto (Local Port Forwarding)
También denominado túnel saliente, reenvía el tráfico que llega a un
puerto local en el cliente, hacia un puerto remoto ubicado en el servidor. Es
necesario que el cliente pueda registrarse en el servidor mediante un usuario
válido, por lo tanto el tráfico SSH hacia el servidor deberá estar permitido.
Esto habilita el
acceso a puertos no disponibles en forma directa. La
sintaxis del comando SSH para esta funcionalidad es:
ssh –L local_port:remote_host:remote_port [username]@ssh_server
Este comando reenvía el tráfico destinado a local_port hacia el
remote_port del remote_host luego de la conexión y autenticación en
ssh_server. En general remote_host se refiere al propio ssh_server, pero no
siempre es así. Existen situaciones donde remote_host es otro equipo en la
misma red que ssh_server y donde se ejecuta la aplicación cuyo puerto de
conexión
es
remote_port.
En
esta
circunstancia,
ssh_server
es
el
intermediario de la conexión entre el cliente SSH y remote_host. Es
importante aclarar que esta última parte de la conexión es realizada sin
encriptación.
Un ejemplo práctico del reenvío local de puertos es la conexión al
servicio de correo electrónico mediante un túnel SSH para brindar seguridad
al proceso de autenticación POP3. La Figura 3-8, ilustra la situación de un
usuario móvil conectándose a su red local en forma remota mediante SSH para
procesar su correo electrónico en forma segura.
89
VPNs de Acceso Remoto
Figura 3-8 SSH Reenvío Local de puerto
En la red local existe un servidor SSH y un servidor de correo
electrónico, ambos ejecutándose en equipos diferentes pero en la misma red.
El usuario remoto se autentica en el servidor SSH con una cuenta de usuario
válida y ejecuta en su cliente el comando para reenviar el tráfico POP3
mediante el túnel SSH. A continuación el usuario mediante su aplicación de
correo electrónico o MUA (Mail User Agent) se conecta en forma local al
puerto 1110 donde el tráfico POP3 será manejado por el cliente SSH y
transportado por el túnel hasta el servidor SSH remoto.
En el otro extremo, el servidor SSH reenvía el tráfico del cliente
hacia el servidor de correo, esta última conexión no es encriptada. El
servidor de correo responde al servidor SSH el cual reenvía la respuesta al
cliente SSH. Esto es posible si las políticas de seguridad de la organización
permiten establecer conexiones SSH desde el exterior hacia algún gateway de
la red local.
Reenvío Remoto de Puerto (Remote Port Forwarding)
Denominado también túnel entrante, reenvía el tráfico que arriba a
un puerto remoto en el servidor, hacia un host y puerto local específico en
el cliente, (Figura 3-9). Para esto el cliente inicia una conexión SSH con el
servidor mediante el comando:
ssh –R remote_port:local_host:local_port [username]@ssh_server
Este comando conecta y establece una sesión con el servidor SSH
utilizando username y solicita redireccionar el tráfico que arribe a
remote_port de ssh_server hacia local_port en local_host. Este esquema
habilita el acceso desde el exterior hacia algún servicio interno en
local_host mediante ssh_server como intermediario. Para que esto funcione,
ssh_server deberá ejecutar un proceso que escuche en remote_port.
90
VPNs de Acceso Remoto
Figura 3-9 SSH reenvío Remoto de puerto
Como un ejemplo considerar el servicio de control remoto o VNC, que
permite el control remoto de un equipo. Éste utiliza el puerto TCP 5900, con
lo cual el comando SSH para el reenvío remoto solicita que todo el tráfico
que arribe al puerto remoto 5900 en ssh_server se reenvíe al equipo local al
mismo puerto.
ssh –R 5900:pc_a_controlar:5900 user@ssh_server
Allí estará funcionado el servidor VNC propio del equipo a
controlar. El administrador remoto deberá ejecutar el visor VNC desde su
equipo y entonces podrá visualizar el escritorio de la PC a controlar. Esto
es posible si las políticas de seguridad de la organización permiten
establecer conexiones SHH hacia el exterior.
En la práctica utilizar SSH requiere conocimiento por parte del
usuario para configurar un acceso remoto. Sin embargo existen herramientas
que facilitan su utilización mediante interfaces gráficas. Es una herramienta
útil en situaciones donde el acceso remoto es una excepción y se realiza bajo
determinadas condiciones, como por ejemplo la presencia de un servidor SSH,
políticas de seguridad de la organización que permitan los tipos de
conexiones necesarias. Por lo general es utilizado por los administradores de
redes para el acceso remoto, pero no como una solución corporativa para el
grueso de los usuarios móviles de la misma. Tampoco es una solución
escalable, dado
que es necesaria la instalación del software SSH en cada
cliente y la configuración manual de la conexión con sus particularidades en
cada uno de ellos.
3.4.2 IPSec
Las VPN IPSec extienden el perímetro de seguridad de una red
permitiendo la conexión de hosts individuales o redes enteras. Una VPN segura
verifica la identidad de los extremos del túnel.
A diferencia de las VPN red a red utilizando IPSec, las de acceso
remoto requieren mayor consideración respecto de la autenticación de las
partes que se comunican, en general para evitar establecer túneles con partes
no autorizadas. En particular porque en este escenario, habrá muchos clientes
intentando conectarse a los recursos
de la red local de la organización.
Además porque se tratan de conexiones temporales y el origen de red de las
mismas varía con frecuencia.
91
VPNs de Acceso Remoto
Es importante considerar que en IPSec la autenticación precede el
establecimiento del canal seguro por donde se llevará a cabo la comunicación
entre las partes, por lo tanto, cualquier vulnerabilidad que pueda ser
explotada en esta primera etapa, comprometerá el resto de la comunicación.
El protocolo IPSec encargado de realizar la autenticación de las
partes es IKE. Este protocolo de intercambio de claves presenta dos fases en
su operación, tres modos, una variedad de mecanismos para llevar a cabo la
autenticación, pero más importante aún una nueva versión de este protocolo:
IKEv228, la cual no es interoperable con IKEv1. De manera que son varios
aspectos que hay que considerar para la implementación de una VPN IPSec de
acceso remoto con mecanismos de autenticación seguros.
La primera versión de IKE es la más difundida entre los productos
que implementan IPSec. Su forma de operación trae aparejado riesgos de
seguridad si el mecanismo de autenticación utilizado no es el adecuado. La
segunda versión, ya definida como estándar por el IETF es una mejora de la
anterior poniendo énfasis en la solución a estos problemas. Actualmente se
recomienda utilizar IKEv2 si se requiere implementar una VPN de acceso remoto
IPSec por primera vez. En casos donde ya hubiera una VPN establecida, se
recomienda utilizar los mecanismos de autenticación que eviten el ataque
conocido como “hombre del medio”, como encriptación de clave pública y firma
digital con uso de certificados.
El protocolo IKE se basa en la identificación de los pares que se
conectan como parte del proceso de autenticación. Puede utilizar varios tipos
estándar de identificación: dirección IP (Ipv4 e Ipv6), nombre del host FQDN
(Fullly Qualified Domain Name), una dirección de correo electrónico, o un
nombre distinguido DN (Distinguished Name) X.500 LDAP (Lightweight Directory
Access Protocol). Estas identificaciones necesitan ser comprobadas, para esto
se utilizan los métodos de autenticación.
Los identificadores de los pares pueden encriptarse o no, según el
modo utilizado en la primera fase de IKE. En el modo agresivo el ID de los
hosts se transmite en texto claro. Esto permite que esa información pueda ser
capturada y manipulada para un ataque del tipo mencionado anteriormente. Por
lo tanto una VPN de acceso remoto deberá usar el modo main de IKE el cual si
encripta el ID de los hosts.
Por otro lado, deberá descartarse la autenticación mediante clave
pre compartida (PSK) con el modo main, ya que esta combinación modo/métodoautenticación, requiere usar como ID la dirección IP de quien inicia la
conexión, en este caso el cliente remoto. Dado que se trata de clientes
móviles, la dirección IP origen de estos es de naturaleza dinámica y puede
variar durante una misma sesión.
28
RFC 4306 - Internet Key Exchange (IKEv2) Protocol
92
VPNs de Acceso Remoto
Tal como se menciona en la introducción de este capítulo, es muy
importante en este escenario de VPN, implementar una doble autenticación para
el cliente: basada en host y en usuario. Una desventaja de IKEv1 es la falta
de este último tipo de autenticación. Si bien se han implementado extensiones
a IKEv1 por algunos fabricantes, como la autenticación extendida (XAUTH) de
Cisco, estas no han sido consideradas como estándares por parte de la IETF.
Los gateways VPN que utilizan XAUTH solicitan al usuario un segundo login; si
tiene éxito se continúa con la segunda fase de IKE que prepara la conexión
IPSec, caso contrario se finaliza el intercambio IKE y no se lleva a cabo la
conexión. Una alternativa a XAUTH es la encapsulación L2TP sobre IPSec,
permitiendo la autenticación de un usuario mediante los mecanismos de L2TP
basados en PPP.
IKEv2 fue desarrollado teniendo en cuenta esta desventaja y lograr
resolverla. Introdujo en su diseño lo que se denomina mecanismos de
autenticación heredados (legacy authentication); estos implementan la
autenticación de un usuario sobre un servidor. Es el caso de los mecanismos
de
passwords
e
intercambios
desafíos/respuestas
(Challenge/response
Authentication) (PAP/CHAP).En particular implementa los mecanismos definidos
en la RFC 3748(Extensible Authentication Protocol).
Ambas versiones de IKE no son inter operables, por lo que si se
decide utilizar la última versión sobre una estructura de VPN de acceso
remoto ya existente, deberá migrarse todo el software IPSec de los
componentes de la VPN por aquellas que contengan la versión 2 de IKE.
De acuerdo a la introducción de
acceso remoto va a consistir de un servidor
se conectarán al servidor. El servidor se
borde de la red de la organización. Puede
bien en otro equipo.
este capítulo una VPN IPSec de
VPN y de varios clientes VPN que
ejecutará en un dispositivo de
hacerlo
en el mismo firewall o
Hay que considerar las políticas de seguridad de la organización y
establecer en función de estas los parámetros necesarios para definir las
políticas de seguridad IPSec (SP) a partir de las cuales se derivarán las
asociaciones de seguridad de IKE (IKE SA) e IPSec (IPSec SA).
Estos parámetros tienen que ver con las direcciones IP de los hosts
a los cuales se les brindará el servicio de seguridad, los puertos y
protocolos a proteger y las Asociaciones de seguridad que efectivizarán el
servicio, es decir que seguridad aplicar. Esto último implica determinar los
algoritmos de autenticación, de encriptación, protocolo de seguridad, modo de
operación a usar con esta política. Esta información se almacena en base de
datos.
Como se mencionó en el capítulo anterior, existen dos clases de
bases de datos: la referida a las políticas de
seguridad (SPD) y la de
asociaciones de seguridad (SAD). La primera especifica las políticas que
determinan el tráfico entrante o saliente que debe ser asegurado, si bien
todo el tráfico es procesado por el motor IPSec. La segunda contiene
parámetros relacionados con cada asociación de seguridad activa, que indican
cómo procesar y que servicio de seguridad aplicar.
93
VPNs de Acceso Remoto
Cuando un cliente remoto se conecta debe recibir información de
configuración de red referente a la red de la organización destino de la
conexión. Esto se puede lograr mediante la encapsulación L2TP sobre IPSec,
donde los mecanismos PPP permite obtener la dirección IP local para el host
remoto(PPP IPCP), sin embargo la información dinámica ofrecida es muy escasa
y no es un mecanismo integrado a IPSec. Existe otro método que implementa
IPSec, definido en la RFC 3456 que permite el intercambio de mensajes DHCP v4
luego de la fase dos de IKE o quick mode en modo túnel. Para esto el cliente
define una asociación de seguridad DHCP (DHCP SA) la cual solo es utilizada
para el intercambio de tráfico DHCP. Dicha SA puede ser eliminada o seguir
siendo utilizada entre las partes.
3.4.3 SSL/TLS
Dentro de las VPN SSL de acceso remoto, ha surgido la tendencia,
impuesto por el marketing de los fabricantes, de considerar los navegadores
web con soporte SSL, como una solución VPN SSL sin cliente (clientless),
refiriendo a que no es necesaria la presencia de software cliente VPN
específico para la conexión. En realidad este esquema no representa realmente
una VPN. Se trata de un sistema que implementa tanto un web proxy o un
mecanismo de traducción de protocolos de aplicación (Application Traslation).
En el primer caso, existe un dispositivo servidor que actúa
como
intermediario entre los servicios destino y el cliente remoto.
El proxy
recibe la petición del cliente, la rescribe por completo y la envía al
servidor destino. Antes del reenvío, el proxy puede analizar la correctitud
del requerimiento en busca de solicitudes malformadas creadas con la
intención de un ataque. La respuesta del servidor destino recorre el camino
inverso, hacia el proxy primero y de allí al cliente. Toda la conexión se
realiza en seguro bajo SSL. Este funcionamiento requiere que el proxy soporte
los protocolos para los cuales va a operar.
En
el segundo caso, un protocolo de aplicación se adapta o se
traduce a HTTP y HTML para poder ser visualizado en un navegador. Este método
se aplica sobre la base de protocolos individuales y es necesario un
traductor por cada uno de estos, sin embargo este mecanismo no es aplicable a
cualquier protocolo.
Una VPN SSL verdadera implica la presencia de un software cliente en
el dispositivo que interactúe con el servidor para la creación de un túnel
por el cual se transmite tráfico IP
en forma segura. Los mecanismos
anteriores no proveen esta clase de conectividad.
Existen soluciones VPN SSL verdaderas, donde el túnel creado permite
la comunicación segura independientemente del protocolo de aplicación que se
ejecute. Esto permite, si las políticas de seguridad lo disponen, acceso
completo a la red destino. Sin embargo el mercado ha impuesto las soluciones
clientless o semi-clientless como soluciones bajo la etiqueta de VPN SSL.
3.4.4 Comparativa de las tecnologías de acceso remoto
Este cuadro presenta una comparación entre las tecnologías VPN de
acceso remoto de mayor uso en la actualidad. Cuando se considera implementar
el servicio de acceso remoto las tecnologías a considerar son IPSec y
SSL/TLS.
94
VPNs de Acceso Remoto
En particular la utilización de IPSec es anterior a la aplicación de
SSL/TLS como protocolo para VPNs, principalmente en el contexto de un
escenario sitio a sitio. IPSec se comenzó a utilizar para el acceso remoto,
pero estaba limitado a la utilización de dispositivos bajo el control de la
organización. SSL/TLS permitió salvar estas limitaciones de IPSec.
Los criterios utilizados describen en general las características
(limitaciones y ventajas) presentes en estas tecnologías VPN, independiente
de alguna solución particular.
Criterios
VPNs IPSec
VPNs SSL/TLS
Escalabilidad
Limitada
Buena a Muy buena
Interoperabilidad
Buena
Muy Buena considerando
el uso de navegadores
web como clientes
Funcionalidad
Acceso completo a la red
o restringido
Aplicaciones Web,
Aplicaciones
cliente/servidor
Acceso completo a la red
o restringido,
Seguridad en la transmisión
Muy Buena
Muy Buena
Métodos de autenticación
Clave precompartida,
Claves RSA, Certificados
digitales
Doble autenticación
nativa con IKEv2
Clave precompartida,
Certificados Digitales,
Claves RSA Doble
autenticación
Administrados por la
organización
No administrados Administrados
Soporte Multiprotocolo Nativo
No, solo datagramas IP
No, solo soporta
aplicaciones basadas en
SSL
Capa de Operación
Servicio de capa de Red
Servicio de capa de
transporte
Mecanismo de Acceso
Túnel IP a nivel de capa
de red
Proxy reverso con
Encapsulamiento HTTP,
Traductor de protocolo,
Túnel IP en capa de red
Nivel de Soporte requerido
Medio a Alto, según el
número de usuarios
remotos
Bajo (considerando
navegadores web como
clientes) a Alto
Soluciones Abiertas
Si
Si
Tipos de Dispositivos
soportados
clientes
Tabla 3-1 Comparativa de Tecnologías de Acceso Remoto
95
VPNs de Acceso Remoto
Escalabilidad
Cuando la cantidad de usuarios remotos aumenta, se requiere mayor
capacidad en el servidor VPN en cuanto al procesamiento para el manejo de más
túneles y funciones de des/encriptación. En este caso ambas tecnologías se
pueden valer de hardware especial para estas tareas.
En el lado de los clientes se incrementa el costo de administración
del software cliente VPN si la solución lo utiliza. Desde esa perspectiva, la
escalabilidad de IPSec es limitada. Las soluciones SSL/TLS basados en
clientes web no poseen carga de mantenimiento y administración del software
cliente. Teniendo en cuenta esto SSL/TLS posee mejor escalabilidad que IPSec.
Sin embargo aquellas soluciones que posean clientes VPN para el acceso,
tendrán una carga similar a IPSec.
Interoperabilidad
Las soluciones que implementan el mismo protocolo deberían poder
comunicarse sin problemas, de lo contrario, éstas no podrán interoperar. Esto
ha sucedido con soluciones VPN IPSec, en particular con la elección del
mecanismo de autenticación de las partes. Sin embargo el consorcio VPN 29 ha
establecido pruebas de interoperabilidad, tanto para soluciones basadas en
IPSec como en SSL, que permiten una mejor interacción entre soluciones de
distintos fabricantes.
Las soluciones SSL/TLS no poseen estas limitaciones considerando la
utilización de clientes web con soporte SSL
Funcionalidad
Este criterio se refiere a los recursos a los que puede tener acceso
un usuario en forma remota. Las VPN IPSec pueden brindar acceso completo a
nivel de red, excepto que se establezcan restricciones. En cambio, las VPN
SSL/TLS permiten un acceso diferenciado según el modo de acceso. Se puede
tener acceso solo a aplicaciones Web, o
a aplicaciones cliente-servidor o
bien a toda la red como IPSec.
Seguridad en la transmisión
Ambas tecnologías permiten un excelente nivel de seguridad en la
transmisión de los datos. El servicio de confidencialidad se basa en una
fuerte suite de algoritmos de encriptación, bien probados, utilizando
protocolos como 3DES, AES, IDEA, algoritmos de hash y firma digital como RC4,
SHA.
La autenticación puede estar basada en criptografía de clave pública
mediante el uso de certificados digitales. En este caso IPSec se destaca por
ser más estricto, ya que requiere que ambas partes posean un certificado que
demuestre su identidad para poder usar el método. El diseño de SSL/TLS, en
cambio, es más flexible en este punto, permitiendo que solo el servidor se
autentique. De esta manera no cumple la característica de
no repudio y es
vulnerable a un ataque del tipo “hombre del medio”. Sin embargo, una buena
solución
VPN
SSL/TLS,
debería
requerir
la
autenticación
mediante
certificados, de ambas partes.
29
http://www.vpnc.org
96
VPNs de Acceso Remoto
Otra característica es que ambos protocolos permiten definir una
configuración a nivel criptográfica (algoritmos criptográficos permitidos,
tamaños de claves, regeneración de claves, tiempos de vida de las claves,
etc.) que se aplican como políticas a las conexiones según el nivel se
seguridad requerido para cada caso.
Métodos de Autenticación
En general ambos protocolos brindan los mismos métodos de
autenticación para los extremos o host. Esto es, el uso de certificados
digitales, claves pre compartidas, claves RSA. Sin embargo en un escenario de
acceso remoto, cobra importancia la autenticación del usuario que controla el
dispositivo que se conecta, logrando una autenticación doble: dispositivo y
usuario.
El diseño de SSL/TLS permite esto mediante el mecanismo más simple,
pero menos seguro, de usuario/contraseña hasta métodos más complejos como OTP
(One Time Password) o una infraestructura PKI que valide certificados de
usuario. Por supuesto esta operación se realiza posterior al establecimiento
de un canal seguro.
IPSec ofreció la posibilidad de la doble autenticación luego de la
incorporación de las extensiones al protocolo IKE por parte de Cisco (XAUTH,
HYBRID AUTH) luego de establecer el canal seguro. La nueva versión de IKE
IKEv2 incorpora el soporte nativo de autenticación de usuario mediante EAP.
Lamentablemente la nueva versión de IKE no es interoperable con su
antecesora.
Tipos de dispositivos soportados
Aquí se marca una diferencia entre ambas tecnologías. El uso de
IPSec requiere la instalación de un cliente VPN en el dispositivo móvil. Para
esto es necesario instalar el software cliente, lo que significa hacerlo
sobre un dispositivo confiable y seguro, de manera que su uso posterior para
la conexión no represente una amenaza. Por lo tanto las VPN IPSec de acceso
remoto requieren usar dispositivos bajo el control de la organización. Es
impensable intentar esta operación sobe un equipo ajeno a la organización y
por lo tanto no confiable.
Las VPN SSL/TLS marcaron su
diferencia al incluir el uso de los
dispositivos no confiables, limitando el acceso desde ellos hacia la red
corporativa solo a aplicaciones web, mediante el uso de navegadores web con
soporte SSL/TLS, encapsulando HTTP. Sin embargo si se requiere un acceso
completo a la red es necesario, al igual que IPSec, instalar un software
cliente y de igual manera, esto solo es posible sobre dispositivos
confiables.
Soporte multiprotocolo nativo
Ninguno de los dos protocolos tienen soporte multiprocolo. Sin
embargo esta capacidad se puede lograr, encapsulando otro protocolo como L2TP
o PPP.
97
VPNs de Acceso Remoto
Mecanismos de accesos
Estos son los mecanismos que permiten el acceso de forma segura a la
red corporativa. IPSec utiliza su protocolo ESP en modo túnel para encapsular
datagramas IP. Este túnel IP es el medio de acceso. En el caso de SSL/TLS
existen varias formas de acceder a la red. Utilizando un proxy HTTP reverso,
para acceder a aplicaciones web, mediante traducción de protocolos permite
acceder a servicios cuyos protocolos pueden traducirse y adaptarse a HTTP y
lograr tunelizarlos, finalmente a través de un túnel IP al igual que IPSec.
Esto permite un control de acceso más granular para SSL/TL, es decir
permite mecanismos de autorización más variados y no solo basarse en
parámetros a nivel de red (IP origen, puerto destino etc.)
Nivel de soporte requerido
En el caso de IPSec es de medio a alto en función de la cantidad de
usuarios remotos. Se tiene en cuenta la carga que representa la
administración y mantenimiento de los clientes, las políticas de acceso y
conjuntos de transformación. Esto es similar para SSL/TLS, pero a diferencia
de IPSec, la posibilidad de implementar esquemas donde se utilice un
navegador web como cliente de acceso, minimiza en gran medida la carga en la
administración de los clientes.
Soluciones Abiertas
Ambas tecnologías han sido implementadas mediante soluciones
abiertas y libres pero de gran calidad las cuales se desarrollaron para
plataformas UNIX aunque algunas han sido portadas para su uso con Windows.
Entre las más conocidas están:

OpenVPN: solución VPN SSL/TLS que permite acceso completo a la
red, desarrollada para LINUX. Existe la versión para WINDOWS.

Ipsec-tools30 : conjunto de utilidades para el manejo de la
implementación de IPSec para el kernel de LINUX. Se basa en el
proyecto KAME el cual tiene cumple con el mismo objetivo pero
para FreeBSD. Entre las utilidades se encuentra el demonio IKE
denominado Racoon y setkey una herramienta para el manejo de la
base de políticas de seguridad y la base de asociaciones de
seguridad.

StrongSwan31: Solución VPN basada en IPSec desarrollada para
plataforma
LINUX. Implementa el demonio IKE versión 2, además
de la versión inicial.
30
http://ipsec-tools.sourceforge.net/
31
http://www.strongswan.org/
98
VPNs de Acceso Remoto
3.5 SOLUCIONES VPNs DE ACCESO REMOTO
El mercado de soluciones VPN de acceso remoto presenta una gran
variedad de alternativas en general provenientes de fabricantes muy
relacionados con el ámbito de las redes y comunicaciones de datos, esto es:
Cisco System, Check Point, Juniper Networks, Nortel, Sonic Wall, etc.
Muchas de estas propuestas son en realidad completas soluciones de
alta complejidad para acceso remoto, lo cual implica el equipamiento de
servidores VPN, el software de cliente VPN, software de administración del
servicio y monitoreo, dispositivos móviles con cliente embebido etc. Sin
embargo, existe un costo económico importante a la hora de elegir alguna de
ellas, ya sea en la adquisición de la infraestructura como en la capacitación
del personal.
Además de estas soluciones propietarias, existen alternativas
abiertas y gratuitas, en particular orientadas a plataformas LINUX y FreeBSD
aunque hay casos donde la solución se puede ejecutar también en Windows.
También existen sistemas basados en una solución abierta pero embebidas o
como una imagen de disco que se puede virtualizar o bien instalar en hardware
dedicado con software de administración todo en uno, pero estas no son
gratuitas32.
Una
característica
de
las
soluciones
propietarias
es
la
implementación como firmware de la lógica tanto del servidor VPN como de los
clientes en un hardware dedicado para la tarea. Esto permite alcanzar buenos
niveles de perfomance. Por el contrario las soluciones abiertas, en general,
se basan en software.
La siguiente tabla muestra un conjunto de características básicas
deseable que deberían poseer las soluciones VPNs de acceso remoto según la
tecnología en la cual se basan. Este cuadro es una referencia que incluye
requerimientos establecido por el consorcio VPN o VPNC (VPN Consortium) para
alcanzar buenos niveles de interoperabilidad entre soluciones de distintos
fabricantes.
32
http://www.endian.com, http://www.arrowdot.com
99
VPNs de Acceso Remoto
3.5.1 IPSEC

Cliente para
Windows/Macintosh
Ecapsulamiento L2TP
Soporte de certificados X.509
durante IKE
Soporte de encriptación 3DES
Soporte Failover
Soporte de Clustering
Soporte para Ipv6
VPNC interoperabilidad básica
VPNC interoperabilidad AES
VPNC interoperabilidad básica
para IKEv2
VPNC interoperabilidad
Ipv6
Interfaz de Administración y
monitoreo
Compresión IPPCP
Software IPSec Cliente
para ejecutarse sobre un
sistema monousuario WINDOWS/MACINTOSH.
Ejecutar L2TP para autenticación y enrutamiento
sobre un túnel IPSec
Uso
de
certificados
de
clave
pública
para
autenticación.
Soporte para fuerte encriptación
Soporte para la herencia de sesiones en forma
transparente para el usuario remoto , ante el fallo
de algunos de los dispositivos funcionando como
gateway VPN (disponibilidad)
Habilidad para balancear la carga total de la VPN
sobre varios nodos en un esquema de clustering
presentando una única identidad para los usuarios
remotos.
Soporte para direccionamiento Ipv6.
Creación de un túnel IP con encriptación 3DES, SHA1 para hash, intercambio de claves de 1024 bits y
PSK para autenticación.
Uso de algoritmo AES con claves de 128 bits para
encriptación.
Creación de un túnel IP mediante IKEv2 con AES para
encriptación, SHA-1 para hash, intercambio de
claves de 1024 bits y PSK para autenticación. La
compatibilidad debe ser total con otras soluciones.
Los sistemas deben
interoperar sin problemas
utilizando direcciones IPv6 con redes externas e
internas
Herramientas
y
utilidades
para
facilitar
la
administración del servicio
Uso de compresión estándar para el tráfico IPSec
Tabla 3-2 Características de soluciones IPSec
100
VPNs de Acceso Remoto
3.5.2 SSL/TLS
Soporte LDAP
Soporte RADIUS
Soporte certificados X.509
para usuarios
Soporte Failover
Soporte de Clustering
Acceso completo a la red
mediante plugin SSL
Endpoint Security Checking
VPNC interoperabilidad SSL
Portal
VPNC interoperabilidad SSL
File Access
VPNC interoperabilidad
JAVA Script
SSL
Interfaz de Administración y
monitoreo
Permite comunicarse con un
servidor LDAP para
autenticar los usuarios remotos
Permite comunicarse con un servidor RADIUS para
autenticar los usuarios remotos
Permite utilizar certificados X.509 para autenticar
usuarios remotos.
Soporte para la herencia de sesiones en forma
transparente para el usuario remoto, ante el fallo
de algunos de los dispositivos funcionando como
gateway VPN (disponibilidad)
Habilidad para balancear la carga total de la VPN
sobre varios nodos en un esquema de clustering
presentando una única identidad para los usuarios
remotos.
Permite el acceso total a la red descargando un
plugin para SSL que lo permita.
Soporte para verificación del nivel de seguridad
del extremo remoto del cliente.
El
gateway
debe
funcionar
como
portal
para
aplicaciones web permitiendo a los usuarios remotos
el acceso a sitios web internos.
El gateway debe permitir la lectura y escritura en
servidores CIFS33/SMB34
internos: Windows
2000 y
2003 Servers.
El gateway debe funcionar como Portal con soporte
de JAVA script para el acceso a aplicaciones
internas.
Herramientas
y
utilidades
para
facilitar
la
administración del servicio
Tabla 3-3 características para soluciones SSL/TLS
El consorcio VPN reúne como sus miembros a importantes empresas
destacadas en el ámbito del networking, entre ellas están: AEPNetworks,
Certicom, Cisco Systems, D-Link, Encore Networks, IBM, Juniper Networks,
Microsoft, Nokia, Nortel, SonicWALL, etc.
Una de sus tareas es establecer test de interoperabilidad para
lograr un funcionamiento sin problemas entre soluciones de diferentes
fabricantes. Los cuadros anteriores incluyen algunas de estas pruebas como
requerimiento deseable. Sin embargo no se consideraron todas dado que las
soluciones abiertas y aquellos sistemas basados en estas no integran este
consorcio. Por otro lado, debido al carácter general y abarcativo de esta
caracterización aplicable a cualquier solución VPN.
La selección de los criterios deseables fue definida a partir del
análisis e investigación realizada para el desarrollo y elaboración de este
capítulo y del resto del trabajo en general.
33
Common Internet Filesystem: Protocolo de dominio público para transferencia de archivos en
forma simple y potente
34
Server Message Block: Protocolo para compartir archivos, base de los sistemas de red LAN
Manager y Microsoft Networking .
101
VPNs de Acceso Remoto
CAPÍTULO 4
TRABAJO PRÁCTICO
4
102
VPNs de Acceso Remoto
4.1 INTRODUCCIÓN
Siempre se ha deseado tener la posibilidad de acceder a los
recursos corporativos de información y sistemas desde el hogar u otro
punto geográfico de una manera sencilla; además de contar con las
herramientas
necesarias
para
el
acceso.
En
el
caso
de
un
administrador, estas son las que permiten administrar los equipos y/o
los sistemas de forma remota. En el caso de un usuario corriente,
poder acceder a sus archivos o a su correo.
Actualmente esto se logra mediante las VPNs de acceso
las cuales requieren la instalación de clientes VPNs en los
provistos a los usuarios móviles o tele trabajadores. Este
requiere una dependencia del software VPN cliente con el
operativo anfitrión.
remoto,
equipos
proceso
sistema
La intención de este trabajo es lograr independizar el
cliente VPN del sistema operativo anfitrión, no solo respecto de
aspectos de compatibilidad entre sí sino también de los privilegios
necesarios para la instalación de esta clase de aplicación.
A partir de esta
siguientes características:







idea
la solución
debe
cumplir
con
las
Ser portable es decir que se pueda trasladar en un pendrive o
una memoria flash convencional.
No requerir la instalación de software en el equipo anfitrión y
no utilizarlo para guardar información.
No requerir permisos administrativos en el host anfitrión.
Poder ejecutar la solución sobre la plataforma Windows por ser
la más popular.
Tener acceso a la red sin restricciones, pero poder
establecerlas en forma dinámica si es necesario.
Poder descargar un archivo ubicado en la red corporativa al
pendrive.
Utilizar herramientas y utilidades Open Source.
Para cumplir estos requerimientos se propuso una solución
mediante virtualización, además de brindar las herramientas necesarias
para efectuar la conexión y el software específico para realizar las
tareas. La Figura 4-1 muestra el diseño de la solución propuesta,
donde se aprecia el túnel desde la aplicación virtualizada hasta el
gateway VPN. Para esto se utiliza la conexión a Internet del equipo
anfitrión. El extremo remoto del túnel termina en el gateway VPN el
cual permite el acceso a la red local corporativa a los servicios
disponibles.
103
VPNs de Acceso Remoto
Figura 4-1 Diseño de la solución
4.2 ALCANCES
La solución propuesta está orientada principalmente a su uso
sobre equipos que estén bajo control y administración de la
organización, lo cual establezca cierto nivel de seguridad respecto a
la presencia de software malicioso.
No es una solución pensada para uso masivo por parte de los
usuarios. El sistema operativo anfitrión donde se ejecutará la
solución será Microsoft WINDOWS 2000, XP o Vista.
Es
necesario
hardware
adecuado
para
ejecutar
una
virtualización en el host anfitrión. En particular capacidad de
procesamiento. El pendrive o memoria flash deberá tener una capacidad
de al menos 2GB.
Es necesario software para virtualización, es decir una
máquina virtual que pueda ejecutarse en las versiones de WINDOWS
mencionadas anteriormente.
La solución se implementará en la plataforma
utilizará el sistema OpenVPN35 para establecer la VPN.
LINUX
y
La
solución
incluirá
una
aplicación
externa
a
la
virtualización que tendrá como cometido, transferir los archivos
descargados en la aplicación virtualizada al pendrive, donde quedarán
disponibles para su procesamiento posterior.
35
http://www.openvpn.org
104
VPNs de Acceso Remoto
Del lado del servidor, éste ejecutará el sistema OpenVPN en
modo servidor y atenderá las conexiones de los usuarios. De acuerdo a
ello establecerá en forma dinámica las restricciones para el acceso a
la red.
4.3 FUNCIONAMIENTO
La solución propuesta permite la conexión segura a la red
corporativa mediante un túnel SSL/TLS. La misma es efectuada por un
usuario, el cual deberá
autenticarse previamente en forma local,
mediante un nombre de usuario y contraseña. Una vez autenticado
ejecutará la aplicación que le permitirá establecer la conexión,
habilitando el acceso a las aplicaciones según su rol o perfil.
4.3.1 Perfiles de usuarios
Se implementan dos perfiles de usuarios, uno es el perfil del
usuario estándar que puede realizar ciertas tareas y otro es el de
administrador. Este tendrá acceso total al resto de las aplicaciones,
la mayoría de las cuales son de naturaleza administrativas. El gateway
VPN que recibe la conexión genera las reglas en forma dinámica las
cuales establecen las restricciones para ambos perfiles de usuario.
4.3.2 Esquema de validación
Se definen dos etapas de autenticación. En la primera se
autentica el usuario localmente a través del sistema de validación de
LINUX. Esto le permite ingresar al entorno de trabajo de la solución.
La segunda etapa consiste en la validación del usuario respecto del
Gateway VPN mediante certificado para establecer el túnel. Esto le
permite el acceso a la red corporativa.
4.3.3 Servicios
Los servicios que el usuario tendrá disponible una vez
autenticado y autorizado son los siguientes de acuerdo a su perfil:
Perfil Usuario:

Mail

Mensajería

SMB (Credenciales de sesión Windows)

FTP
Perfil Administrador:

Todas las anteriores

SSH

Escritorio Remoto (RDP/VNC)
105
VPNs de Acceso Remoto
4.3.4 Gateway VPN
El servidor VPN implementado a través del sistema OpenVPN,
establecerá en forma dinámica las restricciones según el usuario que
se conecte. Esto se logra mediante una opción en el archivo de
configuración del servidor. Además es necesario crear un script para
cada perfil donde se definen las restricciones a nivel de puertos
TCP/UDP y a nivel de la dirección origen asignada al usuario.
4.4 TECNOLOGÍAS DE LA SOLUCIÓN
El desarrollo de la solución requirió determinar que
herramientas eran necesarias para cumplir con las características
establecidas. El componente más importante de la solución es la
máquina virtual que permite la ejecución del cliente VPN.
Dado que el cliente se ejecuta en una plataforma LINUX, se
analizó alternativas de distribuciones existentes además de considerar
la creación de una propia. Lo siguiente fue considerar el desarrollo
de la aplicación que controla la lógica del cliente y las aplicaciones
necesarias para acceder a los servicios disponibles, además de la
aplicación para la transferencias de archivos de la maquina virtual al
pendrive.
Para
esto
se
evaluaron
lenguajes
de
programación,
distribuciones LINUX y entornos de virtualización.
4.4.1 Lenguajes de programación
Las características deseables analizadas fueron:

Desarrollo rápido de entornos gráficos.

Soporte para el desarrollo de aplicaciones para networking.

Curva de aprendizaje de crecimiento rápido.

Confiabilidad (Antecedentes
comprobables).

Soporte multiplataforma (LINUX, WINDOWS).

Perfomance.
en
la
utilización
en
casos
Alternativas consideradas
Los lenguajes considerados fueron:

JAVA

PYTHON

RUBY
El lenguaje elegido fue PYTHON. Entre los motivos de la
elección se consideraron la perfomance respecto de los demás, la
posibilidad de correr aplicaciones sin requerir un entorno de
ejecución, ni la instalación en el equipo anfitrión de bibliotecas o
dependencias. También incidió la curva de aprendizaje rápido.
106
VPNs de Acceso Remoto
4.4.2 Entorno de virtualización
Se tuvieron en cuenta las siguientes alternativas:

VIRTUALBOX

QEMU36

VMWARE

VIRTUALPC
VMWARE y VIRTUALPC no tienen una distribución que se pueda
ejecutar desde un pendrive. Por su parte VIRTUALBOX esta basado en
QEMU, posee un mejor rendimiento y existe una versión para ser
ejecutada en un pendrive que no es oficial, pero es necesario contar
con permisos administrativos para poder instalar una biblioteca de
enlace dinámico y un proceso que le permita a la maquina virtual tener
un mejor rendimiento.
La característica principal que determinó la elección de la
máquina virtual QEMU es que se puede ejecutar en un pendrive sin el
requerimiento de tener permisos de administrador sobre el equipo
anfitrión. La limitación que presenta esta opción es su rendimiento ya
que para mejorarlo, al igual que las demás soluciones, es necesaria la
instalación de un módulo para optimización
en el sistema operativo
anfitrión y poseer privilegios de administrador para hacerlo.
Sin embargo, la perfomance de QEMU, lograda sin el módulo
optimizador, en equipos con buena capacidad de procesamiento es
aceptable permitiendo cumplir con la funcionalidad deseada.
4.4.3 Distribución LINUX
La plataforma de ejecución de la aplicación
es el sistema
LINUX. Esta elección se basa en sus características favorables en
cuanto a la seguridad, estabilidad, robustez, disponibilidad del
kernel del sistema operativo para adaptarlo a los requerimientos de la
solución y finalmente por ser una base óptima para aplicaciones
orientadas a las comunicaciones. Si bien el propósito no fue crear una
mini distribución, se trató de minimizar, dentro de las posibilidades,
las instalaciones realizadas.
Se
evaluó
la
utilización
de
versiones
básicas
de
distribuciones conocidas: DEBIAN y FEDORA. Dado que la solución se
basa en una virtualización y además la alternativa elegida para esta
tarea no posee un perfomance destacada, se decidió crear una
distribución propia. Encarar esta tarea asegura la instalación de las
herramientas mínimas para la funcionalidad deseada y sobre todo poseer
un control más estricto sobre este proceso.
El método elegido para la creación se basó en el proyecto
LINUX desde cero o LFS37 (LINUX From Scratch). Este consiste en cumplir
una serie de etapas hasta lograr la distribución final. La versión de
LFS utilizada fue la 6.3. Actualmente la versión estable es la 6.4.
36
http://www.nongnu.org/qemu/
37
http://www.LINUXfromscratch.org
107
VPNs de Acceso Remoto
La primera etapa consiste en utilizar una distribución LINUX
operativa como base para la creación del nuevo sistema, en este caso
una DEBIAN Etch. En particular se seleccionó una partición disponible
para la instalación del nuevo sistema. Luego se utilizó el LiveCD del
proyecto LFS como sistema anfitrión, el cual provee las herramientas
básicas necesarias y las fuentes de los programas que formarán la
estructura del nuevo sistema.
Una vez elegida la partición, ésta se monta luego de iniciar
el LiveCD. Éste además monta su propio sistema de archivo raíz donde
se encuentra todo lo necesario para el proceso de creación.
La segunda etapa consiste en la creación de un sistema mínimo
en la partición dedicada, que contendrá una cadena de herramientas
(toolschain) necesarias para generar el sistema final. Esta cadena
estará
compuesta
por
un
compilador,
ensamblador,
enlazador,
bibliotecas y algunas utilidades. En principio se compilará cada una
de éstas y luego serán utilizadas para compilar e instalar el resto
de los paquetes.
La tercera etapa consiste en crear un entorno chroot o de
jaula sobre la partición dedicada, y a partir de las herramientas
generadas en la etapa anterior se dará forma al sistema final. Esto se
logra mediante la compilación e instalación del resto de los paquetes
utilizando el compilador, ensamblador, enlazador y bibliotecas de la
cadena de herramientas. También es necesario la creación de los
sistemas de archivos virtuales para el kernel (/dev, /proc, /sys),
creación de la estructura de directorios del sistema de archivos raíz,
enlaces dinámicos etc. Es decir instalar el sistema básico.
Luego de esto es necesario que el sistema pueda iniciar. Para
esto se utilizó la herramienta mkbimage que permite crear una imagen
de boot a partir de un sistema de archivos. En este caso se aplicó a
la partición
contenida en el chroot donde se compiló e instaló el
sistema final. Esta imagen es la que utiliza la máquina virtual QEMU
para ejecutar la solución propuesta.
En realidad, el proceso es más extenso. Lo anterior es solo
un resumen general. Para más detalles y consideraciones es mejor
acceder al sitio www.linuxfromscratch.org, donde LFS es una parte de
un proyecto más ambicioso para la creación y personalización de una
distribución LINUX.
Paquetes principales instalados
Luego de la creación de la
distribución propia se fueron
instalando
las
herramientas
y
aplicaciones
necesarias
y
sus
dependencias relacionadas con la solución. Este fue un proceso de
descarga, compilación e instalación de cada una. Las aplicaciones
principales son:
Kernel

Kernel 2.28.5
Desarrollo

PYTHON 2.5

Bibliotecas QT 4.4.3

Gtk+2.14

PyGTK-2.14
108
VPNs de Acceso Remoto
Entorno gráfico

XORG (X11 R7.4)38

Window Manager FLUXBOX 1.0.039

XDM y XSM
(login y session manager)
Para el entorno gráfico Se eligió un Windows Manager en lugar
de un Destktop Manager como GNOME o KDE, considerando el requerimiento
de perfomance debido a la virtualización. Se optó por
el Windows
Manager FLUXBOX debido a que fue desarrollado para ser ejecutado en
entornos de poca capacidad de procesamiento y memoria, brindando
además un entorno agradable y funcional.
4.4.4 Tecnología VPN
Se optó por una VPN SSL/TSL en lugar de una solución basada
en IPSec, principalmente por la flexibilidad en la asignación de
puerto de conexión donde se brinda el servicio VPN de acceso remoto.
Las soluciones IPSec requieren una asignación de puertos bien
conocidas para el demonio IKE el cual gestiona el intercambio de
claves de sesión y las asociaciones de seguridad y para el protocolo
ESP para asegurar los datagramas en modo túnel (Puerto TCP 51 para ESP
y puerto UDP 500 para IKE). Esto representa una restricción que limita
la funcionalidad y la movilidad de la solución.
4.5 LA SOLUCIÓN
El pendrive consta de dos archivos
cuales realizan las siguientes funciones:
de
extensión
bat
los

Vmvpn.bat : Ejecuta la maquina virtual

Penvpncl.bat: Ejecuta el cliente Windows para bajar o
subir archivos a la maquina virtual
4.5.1 Funcionamiento de la Máquina Virtual
Al inicializar la maquina virtual nos encontramos con el
pedido de usuario y clave para la autenticación local como lo muestra
la Figura 4-2:
38
http://www.x.org
39
http://www.fluxbox.org
109
VPNs de Acceso Remoto
Figura 4-2 Pedido de credenciales locales
Al ingresar podemos acceder al menú principal (Figura 4-3)
haciendo click con el botón derecho del Mouse sobre el área de la
pantalla.
Figura 4-3 Menú principal, sesión local del usuario
Al seleccionar la opción Cliente VPN, accedemos a la
aplicación. Al ingresar la única opción habilitada es la que nos
permite conectarnos. Al realizar la conexión se habilitan las opciones
de acuerdo a nuestro perfil de usuario (Administrador o usuario
normal) permitiendo acceder a los servicios de nuestra corporación,
esto se visualiza en la Figura 4-4:
110
VPNs de Acceso Remoto
Figura 4-4 Menú del Cliente VPN
Las
opciones
de
izquierda
a
derecha
son:
conectar,
desconectar, correo electrónico, acceso al servidor de archivos, FTP,
SSH, mensajería instantánea, terminal remota y cliente VNC.
Por ejemplo la Figura 4-5 muestra la pantalla para acceder a
los archivos remotos del usuario. Se solicita las credenciales válidas
del usuario para acceder al servidor que contiene los archivos.
Una vez autenticado el usuario, la conexión con el servidor
se establece montando, mediante el protocolo CIFS, el directorio del
usuario en /media/vpnsmb.
Figura 4-5 Acceso a los archivos remotos
111
VPNs de Acceso Remoto
4.5.2 Aplicación de gestión de archivos
Para poder descargar o subir de la maquina virtual archivos
debemos ingresar usuario y contraseña, siendo estas credenciales las
mismas que para ingresar a la solución. La pantalla de conexión se
muestra en la Figura 4-6.
Para
comunicar
ambas
aplicaciones
se
establece
una
comunicación mediante SSH. Se utiliza la biblioteca de PYTHON
PARAMIKO, la cual implementa la versión 2 del protocolo SSH.
Figura 4-6 Pantalla de conexión a la maquina virtual
En la parte inferior se informa sobre el estado de la
aplicación. Si se desea bajar un archivo se oprime Listar Directorio y
muestra el contenido del directorio VpnFolder del usuario. Al
seleccionar un archivo se habilita la opción para Bajar el Archivo. El
mismo queda en la carpeta VpnFolder del pendrive.
Para ingresar el archivo a la maquina virtual se oprime la
opción subir archivo. Se selecciona un archivo, se tiene la libertad
de poder seleccionar una carpeta del host si se desea. El archivo se
sube a la carpeta VpnFolder del usuario. Si se desea subir el archivo
al servidor se puede hacer a través del FTP.
112
VPNs de Acceso Remoto
4.6 CONCLUSIONES DEL TRABAJO PRÁCTICO
El objetivo inicial del trabajo práctico se ha cumplido. Se
logro concretar el concepto de portabilidad de un cliente VPN de
acceso remoto. La motivación principal del trabajo fue esta, sin
importar en principio que tecnología y protocolo VPN era
más
conveniente usar.
La complejidad de la solución estriba en la elección más
adecuada de sus componentes y en la búsqueda de la optimización de los
mismos en función de
la virtualización requerida. Sin embargo esta
propuesta se puede mejorar para lograr un resultado aún más óptimo en
términos de perfomance y funcionalidad.
Entre estos aspectos se puede mencionar la posibilidad de
lograr una distribución LINUX aún más compacta, mejorar la aplicación
principal para que controle la conexión de manera más precisa, crear
un mecanismo que permita la actualización en forma dinámica de dicha
aplicación además de un mecanismo de actualización de paquetes para la
distribución propia.
Una mejora en la seguridad del cliente VPN sería la
utilización de un mecanismo de doble autenticación al momento de la
conexión. Esta consistiría en autenticar el dispositivo o sistema
mediante un certificado y luego el usuario mediante el mecanismo OTP
o claves de una sola sesión. Este esquema brindaría una mayor
seguridad en cuanto a la validación del usuario. Otro componente para
flexibilizar aún más esta alternativa sería un servidor RADIUS que
permite que un usuario se autentique en forma centralizada y segura
usando varios esquemas posibles mediante el protocolo EAP.
Durante el desarrollo del trabajo se evaluó el uso de un
servidor RADIUS en conjunto con OpenVPN a través de un plugin. Junto
con un certificado para el dispositivo se logró concretar una doble
autenticación, pero con el mecanismo más débil que es el par usuario y
contraseña común. RADIUS es una tecnología compleja, y debido a falta
de tiempo se decidió no continuar con la evaluación de sus
características para una posible aplicación a la solución. Sin embargo
se la evaluó como una valiosa alternativa mejoradora.
El trabajo se centra en el desarrollo de un cliente VPN y
como tal, las soluciones VPN de acceso remota basadas en estos
requieren de una carga administrativa en relación al mantenimiento e
instalación de los mismos. Por esta razón
se considera limitado el
conjunto de usuarios que la utilizarían. En particular puede resultar
útil para personal del tipo administrador, de redes o de sistemas.
La limitante en perfomance de la virtualización es posible
minimizarla gracias al hardware existente de gran capacidad de
procesamiento y virtualización comunes en la actualidad, tanto en
equipos portátiles como en equipos de escritorio. Las tecnologías de
doble, triple y hasta cuádruple núcleo en los CPU, y el soporte de
virtualización de los sistemas operativos actuales, habilitan que esta
sea una solución viable.
Finalmente la posibilidad de adquirir una memoria flash o
dispositivos pendrive de gran capacidad de almacenamiento, descartan
las limitantes de espacio para la instalación, en estos dispositivos
de la solución descripta en este capítulo.
113
VPNs de Acceso Remoto
5
Anexos
114
VPNs de Acceso Remoto
5.1 ÍNDICES DE FIGURAS
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
1-1 Componentes de una VPN .................................. 13
1-2 VPN Provista por el Cliente ............................. 14
1-3 VPN Sitio a Sitio ....................................... 16
1-4 VPN de Acceso Remoto .................................... 16
1-5 Clasificación de las VPN ............................... 18
1-6 Adyacencias del Ruteo ................................... 21
1-7 Infraestructura del proveedor ........................... 22
1-8 VPNs tipo Peer .......................................... 22
2-1 Componentes ............................................. 31
2-2 Firewall ................................................ 32
2-3 Servidores de Autenticación ............................. 33
2-4 Basada en la Implementación (Hibrida) ................... 35
2-5 Túneles bajo demanda (Router a Router) .................. 36
2-6 Sesiones encriptadas bajo demanda ....................... 36
2-7 Túneles bajo demanda (Firewall a Firewall) .............. 37
2-8 Dirigida ................................................ 38
2-9 Funcionamiento de un Túnel .............................. 41
2-10 Multiplexación de Túneles .............................. 42
2-11 Funciones del Protocolo PPP en PPTP .................... 46
2-12 Componentes en una conexión PPTP ....................... 47
2-13 Encapsulamiento PPTP ................................... 47
2-14 Componentes en el Protocolo L2F ........................ 48
2-15 L2TP Túnel obligatorio ................................. 49
2-16 L2TP Túnel voluntario .................................. 50
2-17 Paquete/Datagrama usando IPSec ......................... 51
2-18 Encabezado AH .......................................... 53
2-19 Modos con protocolo AH ................................. 55
2-20 Modos en ESP ........................................... 56
2-21 Encabezado y Cola ESP .................................. 56
2-22 Paquete GRE encapsulado ................................ 59
2-23 Encapsulamiento Multicast con GRE asegurado con IPSec .. 60
2-24 Escenario Red a Red .................................... 66
2-25 Escenario Host a Red ................................... 66
2-26 Punto a Punto en VPN VPWS .............................. 68
3-1 Escenario General ....................................... 73
3-2 Gateway VPN sobre el Firewall ........................... 80
3-3 Esquema en paralelo ..................................... 81
3-4 Gateway VPN con DMZ única ............................... 83
3-5 Uso de una doble DMZ .................................... 84
3-6 Alta disponibilidad con Failover Activo ................. 85
3-7 Alta disponibilidad mediante un Cluster ................. 86
3-8 SSH Reenvío Local de puerto ............................. 90
3-9 SSH reenvío Remoto de puerto ............................ 91
4-1 Diseño de la solución .................................. 104
4-2 Pedido de credenciales locales ......................... 110
4-3 Menú principal, sesión local del usuario ............... 110
4-4 Menú del Cliente VPN ................................... 111
4-5 Acceso a los archivos remotos .......................... 111
4-6 Pantalla de conexión a la maquina virtual .............. 112
115
VPNs de Acceso Remoto
5.2 REFERENCIAS BIBLIOGRÁFICAS
BIBLIOGRAFÍA
BERKOWITZ, HOWARD C.[1999],
Routing and Switching.
Designing
Addressing
Architectures
for
BROWN, STEVEN [2001], Implementación de Redes Privadas Virtuales
COMER, DOUGLAS E.[2000], Internetworking with TCP/IP Vol.1 Principles,
Protocols, and Architectures.
GUPTA, MEETA [2003], Building a Virtual Private Network
STALLINGS, WILLIAM [Junio 2000], Data & Computer Communications 6ta.
Edición.
TANENBAUM, ANDREW S.[1996], Computer Networks 3ra. Edición.
SCOTT, CHARLIE-PAUL WOLFE-MIKE ERWIN [Enero 1999], Virtual Private
Networks, Second edition
PUBLICACIONES
CISCO SYSTEM [Abril 2006], Packet Networking Professionals Magazine.
CISCO SYSTEM [Junio 1998],The Internet Protocol Journal Nº1 Vol 1
CISCO SYSTEM [Septiembre 1998],The Internet Protocol Journal Nº2 Vol 1
CISCO SYSTEM [Marzo 2007],The Internet Protocol Journal Nº1 Vol 10
CISCO SYSTEM [Junio 2007],The Internet Protocol Journal Nº2 Vol 10
NETXIT SPECIALIST Nº13, Elementos Básicos de Criptografía, Algoritmos
de Hash Seguros, El Gran Debate: PASSPHRASES vs. PASSWORDS
NETXIT SPECIALIST Nº14, Elementos Básicos de Criptografía, Algoritmos
de Hash Seguros, El Gran Debate: PASSPHRASES vs. PASSWORDS-Parte 2
NETXIT SPECIALIST Nº27, ABC de VPNs
NETXIT SPECIALIST Nº30, Virtualización
NETXIT SPECIALIST Nº32, Virtualization Technologies
WHITE PAPERS
FINLAYSON,
M.
HARRISON,
Technologies – A Comparison
J.
SUGARMAN,
R.[Febrero
2003],
HTTP://www.dataconnection.com
VPN
SEMERIA, CHUCK [Marzo 2001], RFC 2547bis: BGP/MPLS VPN Fundamentals –
Juniper Networks
HTTP://ftp.utcluj.ro/pub/users/dadarlat/retele_master/TARC_08_09/MPLSVPN/200012.pdf
116
VPNs de Acceso Remoto
CISCO SYSTEMS [2004], Enterprise guide for
Architecture – Comparing MPLS, IPSec, and SSL.
selecting
an
IP
VPN
HTTP://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns465/net_
implementation_white_paper0900aecd801b1b0f.pdf
JUNIPER NETWORKS [Junio 2007], VPN Decision Guide – IPSec vs. SSL VPN
Decision Criteria.
HTTP://www.juniper.net/us/en/local/pdf/whitepapers/2000232-en.pdf
AVOLIO FREDERICK [2000], Security Review: SSL VPNs – Avolio Consulting
HTTP://www.avolio.com/papers/SSLVPN_SecWP.pdf
SCHULTZ, KEITH [Febrero 2005], SSL VPNs Come of Age
HTTP://www.infoworld.com/article/05/02/04/06FEsslvpn_1.html
NCP SECURE COMMUNICATIONS [Abril 2001], Remote Access VPN and IPSec
HTTP://www.symtrex.com/pdfdocs/wp_ipsec.pdf
CARMOUCHE,JAMES
Configurations
H.[Septiembre
2006],
Basic
VPN
Topologies
and
HTTP://www.ciscopress.com/articles
SAARINEN, MIKKO [Febrero 2004], Legacy User Authentiaction with IPSec
HELSINKI UNIVERSITY OF TECHNOLOGY
MASON, ANDREW [Febrero 2002], IPSec Overview: IKE – CiscoPress
HTTP://www.informit.com/articles
JAZIB, F. QIANG, H. [Junio 2008], SSL VPN Design Considerations
HTTP://www.ciscopress.com/articles
SHINDER, DEB [Mayo 2005], Soluction Base: Introduction to SSL VPNs
KOLESNIKOV, OLEG - HATCH, BRIAN – DAVIS, CRHIS
BUILDING LINUX VPNs, VPN FUNDAMENTALS CAPÍTULO 2
HTTP://www.buildinglinuxvpns.net/chapter2.pdf
117
–
MONGOL,
CRHIS