VPN - 131

Investigación e Implementación de Redes Privadas Virtuales
Gustavo Maximiliano Cortez
Nicolás Federico Formoso Requena
2008
´Índice general
1. Introducción 5
1 .1. ¿Qué es una VPN? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1 .1 .1. Autenticidad, integridad y conĮdencialidad. . . . . . . . . . . . . . . . . . . . . . 6
1 .1 .2. Observaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1 .1 .3. Ventajas y desventajas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1 .2. Topologıas de las VPN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1 .2.1. VPN Host a Host. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1 .2.2. VPN Host a Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1 .2.3. VPN Red a Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1 .3. Interacción con el Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1 .3.1 . Servidor VPN y Firewall en el mismo equipo . . . . . . . . . . . . . . . . . . . . . 9
1 .3.2. Servidor VPN en paralelo con el Firewall . . . . . . . . . . . . . . . . . . . . . . . 10
1 .3.3. Servidor VPN detrás del Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1 .4. JustiĮcacion de las VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1 .4.1 . Económico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1 .4.2. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1 .4.3. Transparencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1 .5. Consideraciones importantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1 .5.1 . Comparación con otras tecnologıas . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1 .5.2. PlaniĮcacion de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1 .5.3. Administración de claves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1 .5.4. Motivos de requerir una VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2. Realización del proyecto 16
2.1 . Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1 .1 . EspeciĮcaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1 .2. Conceptos involucrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2. Proceso de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.1 . Alcance del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.2. Limitaciones técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.3. Limitaciones económicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3. Entornos de evaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.1 . Sistemas BSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.2. Caracterısticas de OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.3. Recomendaciones de instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.4. Sistemas Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.5. Sistemas Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3. Conexión a Internet 22
3.1 . ConĮguracion del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1 .1 . PlaniĮcacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1 .2. Las Redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2. ConĮguracion general del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1 . ConĮguracion de PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

ÍNDICE GENERAL 2
3.2.2. Permitir el acceso a Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3. Reglas de Įltrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1 . Funcionamiento básico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.2. ConĮguracion de Packet Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4. Esquema de conexión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5. Automatización del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.1 . Conexión a Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.2. Asociando un nombre de dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5.3. Actualización de la dirección IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5.4. Utilidades de un dominio propio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.6. ConĮguracion de los clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.6.1 . Servidor DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6.2. Finalizando la conĮguración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.7. Recursos utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.7.1 . Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.7.2. Modem ADSL y Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.7.3. Cableado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.8. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4. VPN usando PPTP 37
4.1 . Introducción a PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1 .1 . Funcionamiento de PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1 .2. Autenticación y cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2. PPTP con Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.1 . Modo de conexión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.2. Directivas del Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.3. Aceptar conexiones con Windows Vista . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.4. Cliente PPTP con Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.5. Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3. PPTP con software libre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.1 . Caracter´ısticas de PoPToP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.2. Instalación de PoPToP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.3. ConĮguración de PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.4. Estableciendo conexión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4. Rendimiento de la conexión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.1 . Escritorio virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.2. Transferencia de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4.3. Registro de conexiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.5. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5. VPN usando PPP sobre SSH 49
5.1 . Protocolo PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2. Protocolo y aplicación SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.2.1 . Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.3. Descripción General de la VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.4. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.4.1 . Env´ıo y recepción de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.5. ConĮguración del Servidor VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.5.1 . Directivas de Įrewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.5.2. Activando el Port Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.5.3. Creando un nuevo usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.5.4. ConĮguración de sudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.5.5. Aceptando conexiones SSH provenientes del cliente . . . . . . . . . . . . . . . . . . 54

5.5.6. Lanzando un nuevo demonio SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.6. ConĮguración del Cliente VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
ÍNDICE GENERAL 3
5.6.1 . Creando un nuevo usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.6.2. Generando las claves RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.6.3. ConĮguración de sudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.6.4. Conectando al Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.6.5. Creando un alias para la VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.7. AȂnadiendo seguridad a la VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.7.1 . Bloqueando la Shell de sshvpn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.7.2. Restringiendo las claves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.7.3. Otras opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.8. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6. VPN con IPSec 60
6.1 . ¿Qué es IPSec? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.1 .1 . Componentes de IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.1 .2. Modos de transferencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.1 .3. Protocolos de gestión e intercambio de claves . . . . . . . . . . . . . . . . . . . . . 63
6.1 .4. Funcionamiento de IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.2. Métodos de Autenticación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.2.1 . Pre-Shared Key (PSK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.2.2. CertiĮcados Digitales X.509 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.3. Descripción General de la VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.4. ConĮguración de los nodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.4.1 . ConĮguración del kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.4.2. La interface enc0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.4.3. Directivas de Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.4.4. ConĮguración de isakmpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.4.5. Iniciación de la conexión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.5. Pruebas y mediciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.5.1 . Revisión del tráĮco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.5.2. Comprobación de la ruta de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.5.3. Transferencia de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.5.4. Escritorio remoto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.5.5. Buscando vulnerabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.6. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7. VPN con OpenVPN 80
7.1 . Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.1 .1 . Encriptación y autenticación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.1 .2. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.1 .3. Comparación con IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.1 .4. Seguridad en OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.1 .5. Venta jas y desventa jas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.2. ConĮguración en Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.2.1 . Instalación de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.2.2. Creación de certiĮcados y claves RSA . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.2.3. ConĮguración del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.2.4. ConĮguración del cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.2.5. Directivas del Įrewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.3. Clientes móviles con Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.3.1 . Conexión a la red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.3.2. ConĮguración del cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

7.3.3. ModiĮcación de rutas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.3.4. Pruebas de transferencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.4. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
ÍNDICE GENERAL 4
8. Alternativas y costos de implementación 92
8.1 . Soluciones comerciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
8.2. Soluciones alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
8.2.1 . LogMeIn Hamachi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
8.2.2. DESKTRA Virtual Private Desktops . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8.2.3. VTun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.2.4. cIPe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.2.5. tinc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
8.3. Situación real de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
8.3.1 . Escenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
8.3.2. Relevamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
8.3.3. Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
8.3.4. Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
8.3.5. Comparativa de costos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
8.4. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
9. Conclusión Įnal 107
A. Equipos de prueba 109
A.1 . Ambiente de traba jo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
A.2. Red casa. lan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
A.2.1 . Descripción de equipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
A.3. Red red. lan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
A.3.1 . Descripción de equipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

B. Documentación 114
B .1 . Herramientas de edición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
B .1 .1 . Compilador de LATEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
B .1 .2. Edición con TeXnicCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
B .1 .3. Edición con TexMaker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
B .1 .4. Edición con LEd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
B .1 .5. Diagramas con Edraw Max . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
B .2. Estructura de la documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
B .2.1 . DeĮniendo el esquema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
B .2.2. El Preámbulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
B .3. Control de las versiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
B .3.1 . ¿Qué es Subversion? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
B .3.2. ConĮguración del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
B .3.3. Problemas de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
B .3.4. Clientes de Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Cap´ıtulo 1
Introducción
Las redes privadas virtuales o VPN1 , se están usando de forma masiva tanto por grandes
empresas
como por PyMEs2 , con la Įnalidad de conectar entre las sucursales de manera económica y
segura. En
este cap´ıtulo se va a deĮnir el concepto y las caracter´ısticas más sobresalientes de una VPN.
También se van a desarrollar situaciones de ejemplo en las que conviene utilizar VPN y en cuales
se
puede seguir utilizando el antiguo método de conexión de redes.
Por último se detallarán los fundamentos de utilización en diferentes ámbitos laborales y su

justiĮcación económica y útil para las empresas.
1 .1 . ¿Qué es una VPN?
Una VPN no tiene un término sencillo para auto deĮnirse, dado que involucra tres palabras con
signiĮcado propio que, en conjunto, pueden resumir lo que es una red privada virtual. Por lo tanto,
para
responder esta pregunta ser´ıa conveniente analizar cada término por separado como lo hacen en
[1 ] .
El primero de ellos es el término red. Por ejemplo una red de computadoras interconectadas de
alguna
forma entre s´ı, permite el tráĮco de datos entre las terminales conectadas. Es decir, cuando se
env´ıa
un mensa je de correo electrónico, o cualquier otro tipo de datos desde una computadora a un
destino
determinado, se pretende que solo el destinatario reciba lo enviado; sobre todo si los datos tienen
gran
importancia para la empresa, negocio o institución. Esto en deĮnitiva es posible, porque los
equipos están
͞conectados͟ y forman parte de una red de computadoras.
El segundo término es privada, la cual es motivo de gran preocupación para administradores de
sistemas y consultores de seguridad, ya que es dif´ıcil encontrar un entorno seguro al cien por
ciento, y
todas las personas que se conectan a Internet , pretenden no ser espiadas por ningún tercero. Por
ejemplo,
al enviar un mensa je de correo electrónico, se pretende que la única persona que lo lea sea el
destinatario
elegido. En las VPN el tráĮco de datos via ja cifrado3 , por lo que se puede suponer la privacidad
de la
información que se env´ıa entre computadoras o redes en cuestión.
El término virtual se reĮere a la abstracción de la red f´ısicamente conectada que pueden ͞ver͟
los
usuarios como si de una sola red virtual se tratara. En este caso como las VPN se implementan
sobre la
pila de protocolos TCP/IP (Internet Protocol Suite) , pero los datos se abstraen de manera que los
datos
VPN en bruto no son compatibles con TCP/IP, entonces se puede decir que una red VPN forma una
red
virtual sobre cualquier red que utilice TCP/IP, incluso Internet.
De esta manera se obtiene una red (computadoras interconectadas) privada (datos cifrados) y
virtual
(como si de una red cercana se tratara) . Todo esto es a pesar de que las redes puedan estar a
kilómetros
de distancias.
1 .1 .1 . Autenticidad, integridad y conĮdencialidad
Las VPN fueron diseȂnadas para brindar autenticación, integridad y conĮdencialidad a los datos
transmitidos a través de ellas; de ah´ı lo de Red Privada.
Autenticación: Se sabe quién está del otro lado como destino (puede ser un host o incluso una
red) .
Integridad: Intención de que los datos no lleguen alterados. Para esto se utilizan funciones de
hash.
ConĮdencialidad: Se pretende que los datos sean interpretados solo por el verdadero destino, y
no por quienes (accidentalmente o no) hayan interceptado la información. Para esto se utilizan
algoritmos de encriptación como DES (Data Encryption Standard) o Triple DES (Triple Data
Encryption Standard) .
Para establecer conexiones entre las máquinas de una red, se requieren elementos de hardware y
software. Por ejemplo, en una LAN 4 , se necesitan, además de las computadoras: switches,
cables, routers,
etc. El término Virtual indica, como se ha mencionado anteriormente, que la red privada
propiamente
dicha se establece sobre la infraestructura de otra red; si se sigue el mismo ejemplo de la LAN, una
VPN
puede establecerse sobre ella, es decir, utilizando sus componentes tanto de hardware como de
software.
Un esquema generalizado de lo que se quiere lograr con esta comunicación a nivel usuario
doméstico, se
puede ver en la Figura 1 .1 .
1 .1 .2. Observaciones
Uno de los motivos por lo que se ha extendido la utilización de VPN en las empresas es la facilidad
de poner en práctica una solución estable, segura y en relativamente poco tiempo. Por esta
razón es que
en vez de alquilar un enlace WAN dedicado, es más conveniente económicamente (quizás en

seguridad y
prestaciones) establecer enlaces de tipo VPN entre los extremos, siempre que ambos estén
conectado a
Internet .
Con respecto a las desventa jas en materia de seguridad tanto en una l´ınea dedicada como en una
VPN,
las fallas puede provenir no solo de las imperfecciones de la implementación, sino de la
interacción humana
en el enlace, tanto en una como en otra. Por ejemplo, una l´ınea dedicada puede parecer más
segura por
tener un único enlace punto a punto, pero también pueden ocurrir cortes de los cables a
propósito
perdiendo la conexión entre ambos extremos. En las VPN, un usuario malicioso puede interceptar
las claves durante el proceso de autenticación y luego hacerse pasar por el extremo de conĮanza,
y
as´ı establecer una conexión directa con el extremo de la VPN.
Por otro lado, existe el problema de los clientes móviles, ya que si pierden su equipo, todos los
datos
de enlace con la VPN quedan vulnerables y a disposición del nuevo poseedor del equipo. De esta
manera
no sirve de nada la extrema seguridad que se implemente en el servidor VPN, ya que

teóricamente el
usuario del equipo robado es un ͞usuario de conĮanza͟ .
1 .1 .3. Ventajas y desventajas
Las VPN además de tener muchas venta jas frente a otras alternativas, también tienen sus
desventajas
y a veces su implementación no es la mejor elección, e incluso ser´ıa perjudicial optar por ellas.
Se deben analizar cuáles son los puntos a favor y en contra que poseen. Las venta jas son las
siguientes:
Integridad, conĮdencialidad y seguridad de datos Esto se garantiza mediante la autenticación de
usuarios y encriptación de datos. Depende de cuán seguras sean las claves y de la complej idad
de
los algoritmos de encriptación.
Una VPN reduce costos y son sencillas de usar Al utilizar un VPN no se invierte en infraestruc-
tura de red f´ısica (si se utiliza Internet, por ejemplo) , esto representa un ahorro de varios miles
de
dólares en la conexión de puntos muy distantes.
Facilita la comunicación entre dos usuarios en lugares distantes Un usuario en Par´ıs conectado
a una VPN de Canadá, puede ver los recursos de la red a la que se conecta como si se encontrara
en la misma red local, es decir, las VPN son transparentes a los usuarios Įnales.
Las desventa jas son las siguientes:
Tiempo de respuesta no garantizado Si bien los hosts de una VPN creen que se encuentran en una
misma red local, el tiempo de respuesta depende de la red sobre la que se estableció la
conexión;
en el caso de Internet, y en los horarios pico de uso, el tiempo de respuesta puede ser muy
superior
al deseado, haciéndose dif´ıcil el uso de aplicaciones cr´ıticas.
ConĮabilidad del enlace Una VPN, se establece sobre la infraestructura de otra red, por ejemplo
Internet ; esto hace que nuestra conexión dependa de la estabilidad de los nodos involucrados en
las rutas que comunican nuestros hosts. Por ende, puede perderse la conexión, cuando los puntos
intermedios se caen.
Seguridad Si bien los protocolos que se utilizan para el establecimiento de las VPN son muy
seguros,
tienen sus puntos débiles; si un usuario mal intencionado los encuentra podr´ıa llegar a violar la
privacidad de la comunicación.
1 .2. Topolog´ıas de las VPN
Las topolog´ıas de las VPN se derivan unas de otras e incluso pueden estar combinadas. Las tres
más
generales dependen de la manera en que se conectan los usuarios, que son:
Conexión host a host (máquina a máquina) .
Conexión host a red (máquina a red) .
Conexión red a red.

1 .2.1 . VPN Host a Host
Es el modo de conexión más básico. Involucra únicamente a dos hosts: uno actúa como
servidor y el
otro como cliente VPN (Įgura 1 .2) .
Por un lado se puede pensar que esta topolog´ıa es innecesaria, ya que está incluida en las otras
topolog´ıas que se describen a continuación; pero por otra parte, esta topolog´ıa, al igual que las
otras,
sigue siendo una solución válida. Por ejemplo en una empresa que posee dos redes conectadas a
través de
Internet ; que no se traĮcan datos cr´ıticos entre ambas, pero que cada cierto tiempo se debe
sincronizar
información de valor entre dos servidores, uno en cada red. Para esta situación es conveniente
establecer
un enlace VPN temporal de tipo host a host . Pero si no se tomara alguna medida de seguridad
para
realizar este traba jo, se estar´ıa exponiendo los servidores a ser espiados por cualquiera que sea
capaz de
interceptar los datos. Por otro lado, conĮgurar una VPN red a red ser´ıa demasiado complejo para
este Įn,
debido a que el tráĮco en general no tiene importancia y solo se requiere un tiempo corto para
transmitir
de un servidor a otro, por lo tanto, la mejor solución para estos casos es una VPN Host a Host que
se
establece entre los servidores solo en el momento de la sincronización.
1 .2.2. VPN Host a Red
En empresas de cualquier tamaȂno, casi siempre existen usuarios móviles, es decir, empleados
que salen
de las oĮcinas (o que traba jan desde su casa) , pero que necesitan estar conectados a la red de la
compaȂn´ıa.
Igual que para el caso anterior, se sabe que no es una buena idea permitir el acceso a cualquier
usuario
o compartir información sin protección (sin cifrado) . La Įgura 1 .3 muestra un esquema

simpliĮcado de
este tipo de conexión.
La implementación de una VPN Host a Red es una solución segura para este tipo de situaciones,
ya que posee la venta ja de que todo el tráĮco que circula a través de ella está encriptado; otro
punto a favor de las VPN, es que el host remoto percibirá como si se encontrara dentro de la red
local, pudiendo
utilizar las direcciones IP privadas de la misma para interactuar con cualquier host de la red,
impresora
o dispositivo compartido de la red.
1 .2.3. VPN Red a Red
Cuando se requiere asegurar el tráĮco a través de Internet entre dos redes locales distantes, por
ejemplo
entre una sucursal y la casa central de una empresa, una VPN Red a Red es una solución
disponible. La
Įgura 1 .4 muestra un esquema de este tipo de conexión.
La conexión se establece entre los servidores VPN de cada red, dichos servidores son los que
negocian
todos los parámetros asociados a la VPN, haciéndose totalmente transparente a los hosts
internos de
cada una; tanto es as´ı, que no es necesario reemplazar el software instalado en los equipos, ni
conĮgurar
de manera especial (esta transparencia vale también para las otras topolog´ıas) .
1 .3. Interacción con el Firewall
En casi toda red de computadoras, existe un Įrewall; esto es un equipo (dedicado o no) , cuya
tarea
es bloquear o permitir el tráĮco de paquetes desde o hacia Internet, u otra red vecina.
Es importante que el Įrewall de la red ͞sepa͟ reconocer el tráĮco VPN de los demás, ya que un
error en la conĮguración del mismo, puede dar lugar a que personas mal intencionadas ingresen a
la red
privada.
Vale aclarar que es necesario un servidor VPN solo en los casos de implementación de topolog´ıas
red a
red, o host a red. Para las VPN host a host, deberán crearse reglas expl´ıcitas en el Įrewall que
controlen
el tráĮco de las conexiones, pero la función de servidor la cumple uno de los dos hosts
involucrados en la
VPN. Sobre este tema, véase la Sección 1 .2 en este mismo cap´ıtulo.
Para el traba jo en conjunto de una VPN con el Įrewall, se han encontrado tres maneras de
interactuar:
VPN y Įrewall en el mismo equipo.
VPN en paralelo con el Įrewall.
VPN detrás del Įrewall.
1 .3.1 . Servidor VPN y Firewall en el mismo equipo
Esta opción consta de un solo equipo en el cual conviven el Įrewall y servidor VPN, es decir, por
este
pasa el tráĮco directo a Internet (sin encriptación) , y el de las conexiones VPN (con cifrado) . Este
equipo
debe tener dos tarjetas de red, una conectada a la red local, y la otra hacia Internet (u otra subred)
,
como se muestra en la Figura 1 .5.
Las venta jas de esta solución se listan a continuación:

Al tener todo en un solo equipo, se simpliĮca el mantenimiento, ya que todo está centralizado en
él.
Se pueden crear reglas con el Įrewall, que se apliquen solo al tráĮco de la VPN, con las mismas
herramientas que se utilizan para el tráĮco de Internet .
Las desventa jas son las siguientes:
Se tiene solo un punto que controla toda la seguridad de la red; se debe tener la certeza que está
bien
conĮgurado, ya que cualquier falla puede dejar una puerta abierta a personas mal intencionadas.
El tráĮco normal de Internet y el de VPN competirán por los recursos del equipo, por lo que es
posible que en este caso, sea necesario un equipo más potente.
1 .3.2. Servidor VPN en paralelo con el Firewall
Ciertos Įrewalls no reconocen otros protocolos que no sean los de la suite TCP/IP. Cuando se
implemente la VPN es necesario nuevos protocolos, por ejemplo GRE (Generic Routing
Encapsulation) ,
protocolo de transporte para VPNs con PPTP.

Al tener un Įrewall ya implementado en el sistema, de manera que no se pueda modiĮcar (ya sea
por las diĮcultades que presenta, o porque se ha adquirido algún producto comercial sin
posibilidades de
ampliar servicios) , puede que esta sea una buena opción para no tener que cambiar todos los
equipos.
Con respecto al ruteo, cada host dirige su tráĮco; si es directo a Internet pasa a través del
Įrewall, si
es a una conexión VPN, pasa a través del servidor VPN. No conviene la conĮguración de rutas
estáticas
en los hosts cuando estos son numerosos (o hay posibilidad de que lo sean) , ya que es un traba jo
tedioso
y muy sujeto a errores humanos.
Las posibilidades más simples son, establecer en el Įrewall las rutas hacia el servidor VPN, de
modo
que cualquier paquete VPN que llegue al Įrewall, este lo redirigirá al lugar correcto; también es
posible
conectar un router entre el Įrewall y el servidor VPN, de modo que todos los paquetes se dirijan al
router
y este los env´ıe al sitio correcto. Un esquema ilustrativo de esta situación, puede verse en la
Figura 1 .6.
Con cualquiera de estas dos posibilidades, en los hosts basta conĮgurar la puerta de enlace
predeterminada. Las venta jas de este modo de conexión son:
Con este esquema los Ňujos de paquetes de las VPN no compiten por recursos del mismo equipo
con el resto del tráĮco, con lo que se gana rendimiento.
Se obtiene mayor escalabilidad, ya que si se requiere agregar más servidores VPN para repartir la
carga de las conexiones, solo se deben conectar en paralelo con los equipos ya instalados.
Las desventa jas de este método de conexión pueden ser las siguientes:
Ahora existen dos puntos conectados al router de salida, por lo que aumenta la carga en cuanto al
mantenimiento e inspección de seguridad. Ahora se tienen que controlar dos o mas equipos.
Aumentan los costes en gastos de equipos y el mantenimiento de los mismos.
1 .3.3. Servidor VPN detrás del Firewall
Se pueden centralizar las entradas y salidas a Internet solamente a través del Įrewall, para ganar
en seguridad y simpliĮcar el mantenimiento, conectando el servidor VPN directo a la LAN y directo

al
Įrewall. Esto último puede hacerse con un cable cruzado para evitar el retardo normal de un
switch. Esto
se puede observar en la Figura 1 .7.
Respecto al ruteo, se debe hacer lo mismo que para el servidor VPN en paralelo con el Firewall. Las
venta jas que pueden mencionarse son las siguientes:
Se tiene solo un punto de Ňujo de paquetes desde y hacia la red local, por lo que se simpliĮca el
mantenimiento.
Las restricciones del tráĮco VPN están ubicadas únicamente en el servidor VPN.
Se gana en seguridad para la VPN, ya que el servidor no está conectado directamente a Internet.
Las desventa jas son:
Todo el tráĮco VPN debe pasar por el Įrewall, lo que introduce cierta latencia en las
comunicaciones.
El Įrewall debe soportar protocolos distintos a los de la suite TCP/IP, ya que los paquetes VPN
circulan encapsulados con, por ejemplo, el protocolo GRE, en una VPN PPTP.
1 .4. JustiĮcación de las VPN
En esta sección se tienen en cuenta aspectos que llevan a tomar la importante decisión de
implementar
o no un VPN en la empresa.
Resulta imprescindible tener en cuenta el aspecto económico, ya que cuanto menos costosa la
implementación, más viable resulta el proyecto. También se tienen en cuenta los aspectos de
seguridad,
ya que siempre es necesario transmitir datos conĮdenciales que requieren especial cuidado para
que no
caigan en manos no autorizadas.
Finalmente se debe tener en cuenta que la implementación de una VPN no deber´ıa cambiar la
infraestructura de la empresa, ni elmodo de traba jar de los usuarios. Por eso es necesario que la
instalación
y uso de la misma sea transparente a los usuarios.
1 .4.1 . Económico
Una VPN es el modo barato de conectar dos redes (que pueden estar distantes) y de forma segura.
Suponiendo que una empresa quiera unir sus oĮcinas de Argentina y EspaȂna, en una sola ͞Gran
Red͟ , unas
l´ıneas alquiladas o un enlace satelital supondr´ıan varios miles de dólares tanto para la
implementación,
como para el mantenimiento de los mismos; algo muchas veces dif´ıcil de justiĮcar, y afrontar para
las
empresas.
La conĮguración de una VPN, ser´ıa la solución más económica en este caso, ya que el gasto es
signiĮcativamente menor en infraestructura, mantenimiento y capacitación del personal.
1 .4.2. Seguridad
Si bien es cierto que datos conĮdenciales de nuestra empresa pueden estar via jando, en el caso
de una
VPN, a través de la red pública, estos son cifrados en el origen con algoritmos muy complejos, de
modo
que puedan ser des-cifrados únicamente por el destino deseado.
Una VPN permite asegurar de una sola vez distintos protocolos: HTTP, POP3, SMB, etc. Lo cual
representa una gran venta ja en tiempo y dinero, ante la idea de asegurar cada protocolo por
separado.
Vale aclarar que las VPN, no aseguran todo el tráĮco hacia Internet, sino solo el que Ňuye a
través
de ella.
1 .4.3. Transparencia
La implementación de una nueva tecnolog´ıa, trae como consecuencia, una gran resistencia por
parte
de los empleados que se ven obligados a utilizarla.
No es este el caso de las VPN, ya que es transparente a los usuarios. Continuando con el ejemplo
visto
anteriormente, al unir las oĮcinas de Argentina y EspaȂna, los empleados percibirán como si se
encontraran
en una misma red.
Se puede decir entonces, que la implementación de la VPN, no requiere nuevos conocimientos

por parte
de la mayor´ıa de los usuarios de la misma. Otra venta ja es que no se necesita reemplazar el

software que
se está utilizando.
1 .5. Consideraciones importantes
En esta sección se van a plantear las diferentes tecnolog´ıas que en un tiempo fueron
competidores
directos de las VPN, aunque mucho antes de que éstas existieran, eran las únicas opciones para
asegurar
dos o más redes.
También se mencionará la importancia de planiĮcar un buen diseȂno de la VPN para no

comprometer
la seguridad de la empresa, y además, de algunos aspectos de administración de las claves.
Por último se listarán los casos en que la implementación de una VPN se considera una buena
opción
y en los que pueden ser una verdadera pérdida de tiempo.
1 .5.1 . Comparación con otras tecnolog´ıas
Las VPN se pueden comparan con tecnolog´ıas RAS (Remote Access Service) y con las l´ıneas
dedicadas.
La primera permit´ıa a las personas traba jar desde su hogar y conectarse a la empresa por
módem mediante
marcado telefónico por tonos. Esta tecnolog´ıa presentaba un problema de seguridad, que
permit´ıa la
conexión a cualquier persona que conociera el número telefónico del sistema, que luego fue
resuelto
mediante el sistema de re-llamada. Otra limitación de este sistema es su velocidad, que rondaba
los
54 Kbps, y además, por cada conexión se requer´ıa de un módem receptor. Por esta razón es
que su
implementación resultaba muy costosa cuando se deb´ıa conectar un gran número de clientes.
Las l´ıneas dedicadas pueden resultar recomendables en algunas aplicaciones. Por ejemplo si se
tiene
una base de datos que replica datos regularmente y que además se realizan consultas
constantemente
y actualizaciones de forma intensiva, entonces se requiere del mayor ancho de banda posible, lo
cual se
consigue con l´ıneas dedicadas o con tecnolog´ıas MPLS (Multiprotocol Label Switching) .
Algunas empresas de telecomunicaciones ofrecen conectividad mediante Frame Relay, cuyo

cometido
es la transmisión de información a alta velocidad entre puntos geográĮcamente distantes,

mediante una
red de alta velocidad, con una máxima seguridad y calidad. Esta conexión se realiza a través de
circuitos
virtuales permanentes (PVC) , con ancho de banda ba jo demanda y con un throughput

garantizado que
permite alcanzar la velocidad convenida, que va de los 64 Kbps hasta los 2 Mbps, dependiendo del
carrier.
Esta tecnolog´ıa soporta cualquier aplicación que requiera alto grado de conectividad tipo malla o
tráĮco de datos tipo ráfaga, con caracter´ısticas de ba jo retardo y calidad de servicio incluida. En
este
apartado, cabe aclarar, que mediante la conexión a Internet no se consigue calidad de servicio
como lo
permiten las l´ıneas dedicadas.
Otra de las tecnolog´ıas que utilizan los ISP para interconectar sitios de una empresa, es la
recientemente mencionada MPLS , que dispone (según el plan de contrato) de velocidades hasta
1 Gbps.
Además el servicio se encuentra subdividido de acuerdo a lo cr´ıtico que sea la transmisión, tanto
para
aplicaciones en tiempo real, de misión cr´ıtica o estándar. Por su parte, esta tecnolog´ıa es un
poco más
económica que las l´ıneas dedicadas, pero aún as´ı mucho más costosa que una solución VPN
propuesta en
este traba jo.
Una desventa ja importante de las l´ıneas dedicadas, es su elevado costo. Una instalación
completa por
aȂno puede llegar a valer unos 40000 dólares; sin contar los costos de mantenimiento. En
deĮnitiva, este es
un gasto casi imposible de afrontar por una empresa mediana o en crecimiento, por lo que esta
solución
para unir dos redes de la empresa no es viable.
De esta manera, se han dado los créditos a la implementación de una VPN con software libre,
que
permite la transmisión de datos de manera segura (como el caso de Frame Relay o MPLS) y a ba
jo costo.
Por ejemplo, el primer aȂno de implementación y funcionamiento de una VPN puede llegar a
costar unos
6000 dólares, que incluye un enlace punto a punto, soporte a clientes móviles y mantenimiento
mensual
moderado (ver más detalles en 8.3.5) , limitándose los aȂnos siguientes solamente a costos
administrativos.
Además no ser´ıa necesario invertir en otras l´ıneas dedicadas (en caso de querer unir otras redes)
, ni en
migraciones o en escalabilidad.
A pesar de ello, las grandes empresas optan generalmente por soluciones heterogéneas, donde
en
algunas aplicaciones y sectores se pueden implementar VPN con software libre, mientras que en
otras
áreas más cr´ıticas, se utilizan soluciones comerciales como l´ıneas dedicadas, MPLS o VPN con
hardware
propietario.
1 .5.2. PlaniĮcación de seguridad
Para que las VPN funcionen bien dependen de muchos factores, no solo de la elección del mejor
cifrado
ni el Įrewall más robusto y seguro que existe5 . Si no se planiĮca cuidadosamente el diseȂno de

una VPN,
la red entera puede ser vulnerable aún con la VPN en funcionamiento.
Para planiĮcar se debe involucrar a toda la gente que tenga que ver con el funcionamiento del
sistema
y con los servicios que ya se estaban utilizando. Por eso se requiere una buena comunicación
entre las
personas que traba jen implementando la VPN y además se debe asegurar que los
administradores de
sistemas, de redes y base de datos revisen el diseȂno.
Además se debe tener documentada la red completa, y cualquier cambio que se realice para la
implementación de la VPN, debe ser también documentado. El diseȂno es un aspecto clave antes
de
poner en práctica el sistema, en donde también se incluyen aspectos como la estrategia de

administración
de claves, los métodos de cifrado utilizados, la pol´ıtica de seguridad del Įrewall, entre otros.
1 .5.3. Administración de claves
La estrategia de administración de claves es un punto importante en la planiĮcación de una VPN

para
las empresas. Por ejemplo se deben tener en cuenta las claves que utiliza un usuario móvil, ya
que si su
portátil es robada, dichas claves deber´ıan ser revocadas inmediatamente, para no comprometer
a toda la
red de la empresa.
En algunos casos se utilizan más de una clave, y hasta se generan claves cada cierto tiempo, de
manera
que si una clave es comprometida, automáticamente se negocie otra distinta. De esta manera se
evitan
algunos problemas de seguridad, pero para esto, se debe tener una planiĮcación rigurosa en
cuanto a los
métodos de revocación de claves y a otras fallas en la VPN.
Por otro lado, para asegurar la conĮdencialidad y autenticación se deben generar las claves
correctamente. Algunos sistemas criptográĮcos son vulnerables a ataques de análisis

criptográĮco porque
las claves no se han generado de forma que sean seguras y no fácilmente discernibles. En este
caso se
utiliza OpenSSL para la generación de las claves.
En ambos extremos de una VPN se necesitan claves para cifrar y descifrar, que deben ser
transmitidas
entre los sitios de forma segura. Se pueden hacer manualmente o mediante mecanismos de
privacidad como
PGP (Pretty Good Privacy) . Si la VPN utiliza clave pública, se requieren dos pares de claves, por lo
que
se necesitar´ıa de un tercero de conĮanza para generar las claves. Este tercero puede no resultar
un medio
Įable para conĮar la VPN, por lo que dicha parte debe también tener una buena pol´ıtica de
seguridad
para evitar estos problemas de conĮanza.
1 .5.4. Motivos de requerir una VPN
En algunos casos, utilizar un VPN puede resultar la mejor opción, mientras que en otros ser´ıa una
pérdida de tiempo y dinero. En el siguiente listado se resume en qué casos el uso de una VPN es
la mejor
opción:
Asegurar un cierto número de recursos e información que atraviesan varias redes.
Hacer que todos los host parecieran estar en una misma red, aunque se encuentren a kilómetros
de
distancia.
Si se cuenta con usuarios móviles que requieren tener acceso transparente a la red de la empresa.
CAPÍTULO 1 . INTRODUCCIÓN 15
Se requiere administrar los servidores de forma remota por un canal seguro.
Estos casos que requieren de una VPN, hacen que una empresa separada f´ısicamente, pueda
tener
una infraestructura de red segura, pero sin perder interacción con los clientes y usuarios móviles.
En este
caso, una VPN puede asegurar todos los servicios que se utilicen en la empresa.
Por otro lado, si lo que se requiere es solamente asegurar ciertos protocolos o servicios entre un
par
de hosts, la implementación de una VPN requerir´ıa un gran esfuerzo para un problema simple.
Por eso
para asegurar dos hosts basta con utilizar software de tunelado de un puerto a otro a través de
un canal
cifrado y autenticado como SSH (Secure SHell) .
Cap´ıtulo 2
Realización del proyecto
En este cap´ıtulo se describen los ob jetivos y los pasos a seguir durante la investigación,
documentación
y evaluación de las diferentes soluciones VPN.
Además se especiĮca el alcance del proyecto, tanto en la práctica como en los fundamentos
teóricos
que se van a incluir.
2.1 . Ob jetivos
Los ob jetivos planteados para la tesis de investigación e implementación Redes Privadas

Virtuales
son los siguientes:
DeĮnir una VPN (Virtual Private Network, o Red Privada Virtual en castellano) , los tipos de
conexiones y aplicaciones en la vida real.
Presentar soluciones para la interconexión segura de computadoras y/o redes de computadoras,
teniendo en cuenta el equilibrio entre los costos y beneĮcios en contraste a las alternativas
comerciales.
Detallar los métodos actuales de conexión a Internet para empresas que pretendan tener su
portal
comercial siempre disponible en l´ınea, junto a otros servicios dentro de la red local.
Redactar los aspectos teóricos y prácticos de las conĮguraciones VPN para concretar una
transferencia de información segura, rápida, privada y de conĮanza.
Tener en cuenta que el diseȂno e implementación de las soluciones sean acordes a los
estándares
más utilizados en la actualidad, de manera que permitan el fácil crecimiento de la infraestructura
y as´ı también el mantenimiento de las redes.
Requerir que elmodo de conexión sea transparente al sistema operativo de las terminales de
usuarios,
por más que los servidores traba jen con sistemas diferentes.
2.1 .1 . EspeciĮcaciones
Se estudian las diversas topolog´ıas de comunicación utilizando técnicas de VPN, que permiten el
tráĮco de información asegurada y garantizada entre redes, terminales de usuarios o ambos

entre s´ı. Para
esto se utilizan herramientas de software libre como OpenVPN, ISAKMP (Internet Security
Association
and Key Management Protocol) , PoPtoP, entre otros, que permiten la comunicación entre dos
puntos
remotos utilizando la misma infraestructura de Internet ba jo protocolos como IPSec (Internet

Protocol
Security) , PPTP (Point to Point Tunneling Protocol) , etc. Además las pruebas desde el lado del
usuario
consisten en la utilización de sistemas operativos propietarios y libres, por lo que se tiene en

cuenta el
soporte de varios servicios VPN, para evitar el cambio de parámetros o conĮguraciones en el

momento de conectarse con un sistema operativo y luego con otro.
La conexión a Internet se realiza de tal manera que permita facilidad en el registro de conexiones,
recursos y hasta en posibles problemas de seguridad. Para esto se utilizan Modem ADSL que se
conectan
al proveedor y a su vez el servidor OpenBSD que provee acceso a los clientes de la red local. Este
servidor se encarga de establecer la conexión propiamente dicha a Internet, de conĮgurar los

parámetros
de seguridad y de ofrecer servicios adicionales como correo electrónico con SendMail, DNS con
Bind,
DHCP con DHCP Server, Firewall con PF, repositorio de control de versiones con Subversion,
terminal
remota con OpenSSH, entre otros servicios. Por otro lado, para obtener un dominio Įjo con
direcciones
IP dinámicas se utilizan servicios como ZoneEdit , para automatizar los cambios de direcciones IP
del
proveedor manteniendo el nombre de dominio Įjo y as´ı no se pierdan los enlaces VPN que
dependen del
dominio.
Finalmente se analiza el costo de implementación en los servidores, que en cuanto a licencias de
software se reĮere, se tiene un gasto nulo; esto representa una gran venta ja si se lo compara con
soluciones
comerciales, las cuales van de los cientos a los miles de dólares (en hardware, software y soportes
técnico) .
Por otro lado, al utilizar una VPN ba jo la infraestructura de Internet, no se invierte dinero en
l´ıneas
dedicadas, cuya instalación y mantenimiento representa un gasto imposible de afrontar para

muchas
empresas e instituciones. La investigación de las soluciones con software libre, van desde la
instalación
del sistema operativo servidor hasta las pruebas de velocidad, seguridad y estabilidad de la red,
pasando
por la conĮguración de conexión de banda ancha, conĮguración del Firewall y de las aplicaciones
extras
que se utilizan durante el proceso de autenticación entre los sistemas remotos.
2.1 .2. Conceptos involucrados
Las materias relacionadas con el tema de esta tesis se podr´ıan resumir de la siguiente manera:
Redes de Área Local
Redes de Área Extendida
Protocolo de Comunicación TCP/IP
Sistemas Operativos
Seguridad y encriptación
2.2. Proceso de desarrollo
La Figura 2.1 muestra de forma generalizada el proceso que se lleva a cabo para la realización de
esta tesis. Para comenzar, se hicieron propuestas de los temas que se pod´ıan incluir e investigar.
Luego
se evaluaban si se pod´ıan realizar y Įnalmente quedaban como propuestas válidas para incluirlas
en el
proyecto.
El siguiente paso es la puesta en práctica de la propuesta, en la que se tiene en cuenta la

posibilidad
de escalabilidad de la solución y además se mide el rendimiento para comprobar si es aceptable

o no para
determinados Įnes.
Finalmente se documentan todos los detalles de las pruebas realizadas, teniendo en cuenta la
redacción
utilizada para referirse al lector. Para la presentación del informe se utiliza el formato estándar
PDF junto
a las fuentes LaTeX del mismo.
2.2.1 . Alcance del proyecto
El alcance del proyecto se deĮne de acuerdo a las necesidades que surgen y a medida que se va
avanzando en el tema. De esta manera, se comienza con casos sencillos, evaluando el rendimiento
y la
máxima utilidad posible en ámbitos empresariales, pasando por esquemas alternativos de

conexión y
terminando por esquemas tan complejos como seguros y óptimos para entornos de gran cantidad
de
conexiones simultáneas1 .
Además se tienen en cuenta aspectos como la conĮguración de la conexión a Internet de las
redes
locales, que más tarde establecen un enlace VPN entre las mismas simulando una gran red
separadas por
la nube de Internet .
2.2.2. Limitaciones técnicas
Para no entrar en demasiados detalles de los protocolo utilizados (dado que alguno de ellos puede
llegar
a ser tan complejo como el mismo IPSec (Internet Protocol Security) ) , se realizan breves
descripciones
de los mismos, tales como su origen, funcionamiento, venta jas y desventa jas, entre otros
fundamentos.
No se describen detalles como los elementos de las tramas (números de bits) o el traba jo que se
realiza
a ba jo nivel (o nivel del kernel) , sino que se rescatan los puntos importantes que pueden ser
manejados
por el administrador de la VPN o de la red en el espacio de usuario.
Otra limitación del proyecto, que se encuentra fuera del alcance técnico propio, es el ancho de
banda
de la conexión a Internet (establecida por el proveedor de acceso o ISP en el momento de adquirir

el
servicio)2 . Además, las pruebas que se realizan, generalmente son efectuadas en rangos horarios
de ba jo
tráĮco de datos, que pueden ser en horarios matutinos o diurnos.
En cuanto a las pruebas realizadas, las limitaciones se basan en la cantidad de servicios que
puedan
ser instalados en los sistemas y probados por ambos extremos de la VPN, tales como sistemas de
voz
sobre IP (utilizando Asterisk) , servicios de música o radio en vivo (Icecast) , servicios Web para
todas las
redes conectadas a la VPN, entre otros. Otra limitación es la diĮcultad que presentan algunos
servicios
para su conĮguración y puesta en marcha, ya sea porque no estan totalmente adaptados para
funcionar
en determinado sistemas o porque requieren de un alto nivel de conocimientos, que en deĮnitiva,

alejar´ıan
al ob jetivo de este proyecto.
2.2.3. Limitaciones económicas
Algunos problemas que surgieron durante la conĮguración de la conexión a Internet estaban

más
relacionados con la calidad de los dispositivos utilizados, o que no cumplen con lo especiĮcado por
el
fabricante, como el caso del modem Aztech DSL600EW (Apéndice A.2.1) . Esto se debe al
reducido costo
de los materiales que se utilizan, produciendo un producto de ba ja calidad.
El uso de dispositivos dedicados (ca jas negras) para establecer redes privadas virtuales, tiene un
costo
elevado y es justiĮcable en entornos empresariales con gran cantidad de usuarios y conexiones.
El l´ımite económico se reĮere a la diĮcultad en adquirir tanto hardware como software pre
conĮgurados
para establecer una VPN con lam´ınima intervención del administrador. Se consideran también
los equipos
servidores y terminales que se pueden utilizar para simular conexiones múltiples, y todo lo que
hace a la infraestructura de conexión a Internet en el hogar, como la implementación en
máquinas virtuales antes
de su instalación en equipos reales.
2.3. Entornos de evaluación
Los escenarios en que se realizaron las pruebas y evaluaciones no constituyen un ambiente

empresarial,
sino que se tratan de hogares de familia en los que se disponen generalmente de equipos
modestos, no de
supercomputadoras ni grandes servidores, sino simplemente equipos que se pueden adquirir por
precios
muy ba jos. Los equipos utilizados se describen con más detalles en el Apéndice A.
En esta sección se van a tratar los sistemas operativos utilizados para las conexiones y pruebas,
además
de otras herramientas de software que permite comprobar y registrar las comunicaciones

establecidas.
2.3.1 . Sistemas BSD
La elección de OpenBSD como sistema principal para proveer acceso a Internet no se basa en un
análisis riguroso de costo y rendimiento, sino más bien en la posibilidad de utilizar un sistema
gratuito,
robusto y que puede ejecutarse en equipos antiguos.
Existen muchas variantes de sistemas BSD , cada una orientada a determinado tipo de usuarios y
funcionalidades. Por ejemplo FreeBSD esta más orientado a usuarios de escritorio como intenta
ser
cualquier distribución de Linux.

En las siguientes secciones se describirán brevemente cada uno de estos sistemas, con el Įn de
concluir
el motivo de la elección de OpenBSD como servidor de Internet .
FreeBSD
La idea de FreeBSD es producir un sistema operativo utilizable para cualquier propósito, como
Ubuntu,
Tuquito, Fedora, SuSE, es decir, un sistema de propósitos generales. Se intenta que sea fácil de
usar y
contenga una gran cantidad de paquetes (programas) para instalar.
OpenBSD
OpenBSD esta orientado a la seguridad más que nada. Las pol´ıticas de seguridad son muy
estrictas
en el desarrollo, ya que cada código que incluyen son auditados exaustivamente para corregir la
mayor
cantidad de bugs3 posibles.
NetBSD
NetBSD esta diseȂnado como sistema operativo que puede ser distribuido gratuitamente a
profesionales,
entusiastas e investigadores, para que lo usen como quieran. El ob jetivo principal de este sistema
es la
portabilidad a través de la mayor cantidad de equipos, tanto de 32 como de 64 bits. También

acentúan
la buena escritura del código, la estabilidad y eĮciencia del sistema.
2.3.2. Caracter´ısticas de OpenBSD
El proyecto OpenBSD es un sistema operativo libre tipo Unix, multiplataforma, basado en 4.4BSD .
Los esfuerzos de desarrollo se concentran en la portabilidad, cumplimiento de normas y

regulaciones,
corrección del código, seguridad proactiva y criptograf´ıa integrada.
A continuación se exponen algunas razones por las que OpenBSD es un sistema operativo de gran
utilidad para la realización de este proyecto:
Es reconocido por profesionales de la seguridad informática como el sistema operativo tipo UNIX
más seguro; esto es el resultado de una intensa e interminable auditor´ıa de seguridad sobre el
código
fuente.
Es un sistema operativo con todas las funcionalidades de UNIX que se puede adquirir de forma
gratuita.
Integra las últimas tecnolog´ıas en seguridad para la implementación de cortafuegos (Įltros de

IP)
y redes privadas virtuales (VPN) dentro de un entorno distribuido.
Estas son las caracter´ısticas ĮlosóĮcas del sistemas; las caracter´ısticas prácticas se dejaron de
lado
porque en el transcurso de esta tesis se van a describir detalladamente los puntos sólidos del
sistema.
2.3.3. Recomendaciones de instalación
Las recomendaciones para una instalación limpia e inteligente se pueden enumerar a

continuación:
Ba jar siempre la última versión e instalarla en un disco vac´ıo.
Realizar un particionado inteligente, aprovechando el espacio en disco y asegurando la raiz,

evitando
que usuarios malintencionados copen la unidad completa.
Si se va a instalar un servidor, evitar compartir el sistema con otro sistema operativo
Si se usa como servidor, no instalar el entorno gráĮco y mucho menos los grandes paquetes de
KDE
o Gnome
Si se van a realizar pruebas, primero se debe intentarlo con una máquina virtual
2.3.4. Sistemas Linux
Linux es un sistema operativo multitarea, multiusuario, multiplataforma y multiprocesador,

desarrollado inicialmente por Linus Torvalds en el aȂno 1991 , y actualmente mantenido por una
gran
comunidad de usuarios y programadores.
Como la correcta deĮnición y descripción de este sistema operativo no es el cometido de esta

tesis,
solamente se va a indicar que Linux en s´ı, se reĮere al kernel o núcleo del sistema que es el que
se encarga
de la intercomunicación entre el hardware del equipo y los programas de usuarios. Pero para que
Linux sea
un sistema operativo completo (con las herramientas necesarias para su administración) se debe
hacer uso
de muchas aplicaciones que permitan su administración y uso. Por esta razón, ha habido una
controversia
en el nombre de solo Linux, y la inclusión de GNU/Linux para referenciar a todo el sistema

operativo.
Aqu´ı se va a hacer referencia a Linux como si fuera todo el sistema operativo, pero si se requiere
indicar
otros componentes de GNU, se harán mención expl´ıcitamente.
En cuanto a las distribuciones de Linux, hay una gran cantidad para casi todos los propósitos
espec´ıĮcos y de propósito general. Las más conocidas son Fedora, OpenSuSE, Ubuntu, Debian,
Gentoo, entre otras.
Las empresas que traba jan con software libre idearon un modelo de negocios totalmente
diferente al
que se conoc´ıa hasta el momento, y es el de los servicios. En algunos casos, el producto se vende
a un
precio determinado (como RedHat o SuSE) , mientras que en otros casos, las ganancias para las
empresas
radican en los servicios post venta (o post distribución) .
Para la realización de esta tesis se han utilizado distribuciones armadas de Linux, como Ubuntu
Server,
que es una versión orientada a servidores desarrollada por la empresa Canonical Ltd. , que
encabeza el
desarrollo de una de las distribuciones más utilizadas por su simplicidad y facilidad de uso.
Ubuntu Server en comparación con la versión de escritorio del mismo fabricante, se caracteriza
por la
falta de entorno gráĮco, la optimización del sistema, la seguridad en los servicios, entre otros
aspectos.
Esto es principalmente, porque en un equipo servidor no es necesario un entorno gráĮco, ni el

uso de
procesos que hacen buena la experiencia del usuario, pero son totalmente inútiles en servidores.
El sistema viene con conĮguraciones predeterminadas y servicios adicionales con la posibilidad de
agregarlos durante la instalación del sistema. Por ejemplo, los servicios que pueden agregarse en
la
instalación son OpenSSH, para permitir el acceso remoto por SSH (Secure SHell) , servidor Web,
Samba
(servidor de archivos) , correo electrónico (con TLS) , entre otros.
La utilización de Linux ͞Ubuntu Server͟ como servidor VPN, es más por cuestiones prácticas que
técnicas, ya que hoy en d´ıa casi cualquier distribución de Linux cuenta con las mismas
caracter´ısticas y posibilidades de expansión. Vale aclarar que algunas distribuciones vienen mejor
preparadas que otras
para utilizarlas en servidores.
En particular, Ubuntu Server ha sido modiĮcado para que funcione como servidor, consumiendo
pocos
recursos (solamente los necesarios) , optimizando la seguridad del sistema y servicios como DNS ,
correo
electrónico, SSH, Samba, etc.
2.3.5. Sistemas Windows
El sistema operativo Windows es la denominación de una familia de productos desarrollados por
Microsoft tanto para uso de escritorio como para servidores. La primera versión fue liberada en el
aȂno
1985 y a partir de entonces se realizaron gran cantidad de modiĮcaciones en el núcleo y otros
componentes
como las implementaciones y soporte a dispositivos de red, impresoras, entre otros periféricos.
En la realización de esta tesis, se han utilizado dos versiones de Windows, XP y Vista. Ambas solo
cumpl´ıan el papel de entornos de escritorio y en algunos casos se han utilizado las herramientas
que
vienen incluidas como el registro del sistema, la conĮguración de conexiones entrantes y

salientes, los
comandos de ruteo y estad´ısticas de la conexión.
Cap´ıtulo 3
Conexión a Internet
La conexión a Internet es un requisito muy importante en el mundo de los negocios de hoy en

d´ıa, y
como era de esperar, las VPN se mueven por esos ámbitos inseguros, creando canales de datos
que solo
pueden entender los extremos autorizados y asegurando la información. Es por eso que para la
realización
de esta tesis es importante contar con una buena conexión a Internet, aunque sea con el perĮl de
servidor
hogareȂno, basta para lograr el ob jetivo de establecer una VPN.
En este cap´ıtulo se darán a conocer los detalles de la conexión a Internet de los equipos
utilizados para
las pruebas que requieran una conexión real para probar una VPN. En este caso se utilizará el
sistema
operativo OpenBSD en el servidor de acceso a Internet entre otros servicios adicionales.
También se detallarán los parámetros de conĮguración del Įrewall y algunos aspectos a tener
en cuenta
para automatizar el proceso de inicio.
3.1 . ConĮguración del servidor

Hace algunos aȂnos las necesidades de comunicación en un hogar se limitaban al uso de la l´ınea
telefónica
(sea Įja o móvil) , dejando de lado la conexión a Internet que en la mayor´ıa de los casos, se
trataban de
terminales que se conectaban a la red y no se compart´ıa el ancho de banda con otras

computadoras,
utilizando el limitado enlace telefónico para la transferencia de datos.
Con la llegada de la banda ancha y el abaratamiento del hardware, las familias pod´ıan contar con
más
de una computadora personal, ya que vender la vieja PC , luego de comprar un equipo más
potente, no
generaba más ganancias de las que se podr´ıa aprovechar conectándola en red y compartiendo la
costosa
banda ancha que hab´ıa en aquella época. Pero aún as´ı, no se dispon´ıa de una PC libre para que
realizara
la conexión, sino que se la usaba como una terminal de traba jo más.
Luego con la disminución de precios de la banda ancha y de las PC , los usuarios hogareȂnos ya
pod´ıan
contar con pequeȂnas redes domésticas en las que compartir documentos, música, fotos y hasta
la conexión
a Internet por banda ancha, no resultaba muy costoso. Además, se pod´ıa disponer de la PC más
vieja
como ͞servidor͟ de Internet . Por eso es que, compartir la conexión, ya no necesitaba depender
de la PC
principal (o la más ͞grande͟ o nueva) sino que se comenzaba a pensar en una pol´ıtica más
inteligente
para ofrecer servicio continuado y seguro a toda la familia. Esto es ni más ni menos que utilizar
una PC
de recursos moderados para que ofrezca servicios a toda la red interna con todas las venta jas que
supone
un sistema libre, seguro y Ňexible como OpenBSD .

3.1 .1 . PlaniĮcación
A continuación se detallan los pasos que se siguieron para dejar a punto el servidor OpenBSD de
cada
red. Como se verá más adelante, este cumple funciones de servidor DHCP, DNS, Firewall,
Conexión a
Internet , entre otras cosas.
Al ser las nuestras redes de no más de cinco hosts, podemos darnos el lujo de poner todos los
servicios
en un solo ordenador. Pero en una empresa mediana, esto es irrealizable, ya que son necesarios
servidores
separados de casi todas estas cosas.
Los pasos para la instalación y conĮguración de nuestros servidores fueron:
CAPÍTULO 3. CONEXIÓN A INTERNET 23
Instalación base de OpenBSD ,
ConĮguración de la conexión a Internet,
Asociación de un dominio propio,
ConĮguración de Packet Filter (Įrewall) ,
Correo interno con SendMail,
Servidor DHCP,
Retoques en la conĮguración general del sistema,
Automatización del sistema de arranque,
Utilización de algunas herramientas de red y del sistema.
El orden de estos pasos es cronológico, pero en algunos casos, el punto siguiente no depende del
anterior.
3.1 .2. Las Redes
Ambas redes utilizan el protocolo TCP/IP para la comunicación entre sus respectivos hosts, con IP
versión 4 (IPv4) ; los rangos de direcciones ip privadas utilizados en las redes locales son: para la
red 1
192.168.1 .0, y para la red 2 192.168.0.0; la máscara de red en ambos casos es la misma:
255.255.255.0.
En las dos redes hay solo una puerta de enlace a la red pública; dicha puerta establece una
conexión
PPPoE con el Proveedor de Servicios de Internet (o ISP) . A través de ellas se traĮcan todos los
paquetes
entre la red pública y cada una de las redes locales, y es por donde Ňuirán los paquetes que
pertenezcan
a la conexión VPN.
Cada una de las redes cuenta con un Įrewall a la entrada, que en el caso de la red donde se
encuentra
el host que hará las veces de servidor VPN, dicho Įrewall deberá ser conĮgurado
apropiadamente, como
se ve en los cap´ıtulos 4 y 5. Un resumen de este esquema en un extremo de la red se muestra en

la Įgura
3.1 .
El primer elemento (desde la derecha) de la Įgura 3.1 es una PC con dirección IP 192.168.0.35
que ha sido asignada por el segundo elemento (la puerta de enlace OpenBSD con dirección
192.168.0.1)
previamente conĮgurado por el administrador del sistema para brindar servicios de DHCP sobre la
interfaz
de red correspondiente. El siguiente elemento es el Įrewall, este se encarga de Įltrar el tráĮco no
deseado
que quiera ingresar a nuestra red local. Por último, el Modem ADSL realiza la conversión de
interfaz que
utiliza el servidor (Ethernet) hacia la l´ınea telefónica que previamente detecta el enlace con el
proveedor
y obtiene un enlace WAN a través de la boca tipo RJ11 estándar de las l´ıneas de teléfono.
En la sección 3.4 se verá con más detalles el esquema de conexión de la red.
3.2. ConĮguración general del sistema
Suponiendo que se tiene instalado correctamente OpenBSD en el equipo servidor, solo resta
conĮgurar
el sistema en general para poder realizar la conexión a Internet propiamente dicha.
Luego de conectar la placa de red libre a la interfaz ethernet del modem ADSL, se tiene que
conĮgurar
el archivo /etc/hostname. if, donde ͞if͟ se reemplaza por la interfaz de red. Por ejemplo al
ejecutar el
comando ifconĮg se obtiene:
las cuales, la primera se conecta al switch y tiene asignada una dirección IP (192.168.0.1) ; la
segunda
interfaz (ne1) esta conectada directamente al modem ADSL. La última no esta conectada, pero
podr´ıa
utilizarse para conĮgurar zonas DMZ .

Para conectar la interfaz ne1 con el modem ADSL, en el archivo /etc/hostname.ne1 se escribe
solamente:
up
De esta manera se inicia la placa de red para ser utilizada con el Modem ADSL.
3.2.1 . ConĮguración de PPP
Para establecer la conexión se utiliza un protocolo de comunicación punto a punto sobre

ethernet
(PPPoE) . Básicamente, lo que hace este protocolo, implementar la capa IP sobre el protocolo PPP,
que
es encapsulado en una trama ethernet y transmitida al ISP a través de la l´ınea telefónica.

Logrando de
esta forma, transmitir paquetes IP por una conexión serial punto a punto establecida por dos
puertos
ethernet .
El archivo a modiĮcar para realizar la conexión a Internet desde OpenBSD es /etc/ppp/ppp.conf

que
lleva todos los parámetros necesarios para la comunicación, incluyendo el nombre de usuario y
contraseȂna,
por lo que es muy recomendable que solamente pueda ser le´ıdo por el administrador (root) . Un
ejemplo
de conĮguración se puede ver en el listado 1 .
Luego para realizar la conexión se ejecuta desde la l´ınea de comandos lo siguiente:
Si al ejecutar sudo ppp -ddial proveedor obtenemos la salida mostrada en el listado de arriba,
signiĮca
que se ha creado la interfaz tun0 pero no que se haya conectado aún. Para comprobar la
conexión, se
puede ver en los procesos del sistema con el comando ͞px ax͟ y localizar que los siguientes dos
procesos
aparezcan:
28682 ?? Is 0: 00. 23 ppp -ddial arnet
25835 ?? I 0: 00. 08 /usr/sbin/pppoe -i ne1
ConĮguración 1 Ejemplo de conĮguración de ppp. conf .
1 de f aul t :
2 s e t log Phas e Chat LCP I PCP CCP tun c ommand
4 prove edo r :
5 s e t redial 1 5 0
6 s e t re c onne c t 1 5 1 0000
7 s e t devi ce " ! / usr / sbin/ pppo e - i ne 1 "
8 s e t s pe ed sync
9 di sabl e ac f c omp pro t o c omp
10 deny ac f c omp
11 enable lqr
12 s e t lqrpe ri od 5
13 s e t dial
14 s e t login
15 s e t t ime out 0
16 s e t aut hname " nombre @arne t _ o _ cualqui e ra - tuc - xxx "
17 s e t aut hke y " SuP3rP@ s Sw0rd "
18 add ! de f aul t HI SADDR
Y para saber la dirección IP que ha asignado el proveedor, al ejecutar ͞ifconĮg͟ nuevamente, se

puede
ver el nuevo dispositivo túnel tun0 que ha creado PPP :
tun0: flags=8051<UP, POINTOPOINT, RUNNING, MULTICAST> mtu 1492
groups: tun egress
inet 190. 137. 64. 32 --> 200. 3. 60. 15 netmask 0xffffffff
De esta manera, se asegura que la conexión a Internet se ha establecido y que la dirección IP

asignada
por el proveedor es 190.137.64.32. En la última l´ınea del archivo ppp.conf vemos que luego de
establecer
la conexión con el proveedor, se agregó la ruta por defecto a la dirección del gateway del
proveedor:
Si en este momento se intenta obtener respuesta de algún dominio (por ejemplo con el comando
͞ping
google.com͟ ) , no se obtendrá respuesta alguna, pues todav´ıa se conĮguró el servidor DNS .

OpenBSD se
instala con un servidor de DNS preconĮgurado y casi listo para usar con direcciones de Internet, se
lo
puede iniciar con el comando ͞named͟ y editar el archivo /etc/resolv.conf como se indica en el
listado
2.
ConĮguración 2 Servidor de nombre en /etc/resolv. conf .
1 lookup file bind
2 s earch red . lan
3 name s e rve r 1 9 2 . 1 6 8 . 0 . 1
4 name s e rve r 2 00 . 45 . 1 9 1 . 3 5
La primera l´ınea (lookup) especiĮca dónde buscar para resolver nombres. En este caso, busca
primero
en el archivo /etc/hosts y si no lo encuentra all´ı, utiliza el servidor DNS local y luego el remoto. A
veces
es buena práctica agregar el DNS del proveedor por si aún no se ha ejecutado o conĮgurado Bind
en el
sistema.
Luego de esto, es posible acceder a Internet desde el servidor, pero aún los demás equipos de la
red
no pueden hacerlo.
3.2.2. Permitir el acceso a Internet
Para permitir el acceso a Internet de los demás equipos de la red, a través del servidor OpenBSD ,
se deben habilitar algunos parámetros del kernel; esto se hace con el archivo ͞/etc/sysctl.conf͟ .
Algunas
l´ıneas de este archivo se muestran en el listado 3.
ConĮguración 3 Algunas l´ıneas de /etc/sysctl. conf .
1 # $ OpenBSD : sys c t l . conf , v 1 . 46 2008/ 0 1 / 0 5 1 8 : 38 : 37 mbalme r Exp $
2#
3 # Thi s f ile c ont ains a li s t of s ys c t l o pt i ons the us er want s se t at
4 # boo t t ime . See sys c t l ( 3 ) and s ys c t l ( 8 ) f or more inf o rmat i on on
5 # the many avai lable variabl e s .
6#
7 net . ine t . ip . f o rwarding =1 # 1= Pe rmi t f o rwardi ng ( rout ing ) of I Pv4 packe t s
8 # ne t . ine t . ip . mf o rwardi ng =1 # 1 = Pe rmi t f o rwarding ( rout ing ) of I Pv4
mul t i cas t packe t s
9 # ne t . ine t . ip . mul t i pat h =1 # 1 = Enable IP mul t i pat h rout ing
10 net . ine t 6 . ip6 . f o rwarding =1 # 1= Pe rmi t f o rwardi ng ( rout ing ) of I Pv6 packe t s
11 # ne t . ine t 6 . ip6 . mf o rwarding =1 # 1 = Pe rmi t f o rwarding ( rout ing ) of I Pv6
mul t i cas t packe t s
12 # ne t . ine t 6 . ip6 . mul t i pat h =1 # 1 = Enable I Pv6 mul t i pat h rout ing
13 # ne t . ine t 6 . ip6 . ac c e pt _ r t adv =1 # 1 = Pe rmi t I Pv6 aut o c onf ( f o rwarding mus t be 0

)
14 # ne t . ine t . t cp . r f c 1 323 =0 # 0= Di sabl e TCP RFC 1 323 e xt e ns i ons ( f or if t cp
is s low )
15 # ne t . ine t . t cp . r f c 3390 =0 # 0= Di sabl e RFC3390 f or TCP window inc re as ing
16 net . ine t . esp . enabl e =1 # 0= Di sabl e the ESP I Ps e c pro t o c o l
17 net . ine t . ah . enabl e =1 # 0= Di sabl e the AH I Ps e c pro t o c o l
Tal como se muestra en el listado anterior, las l´ıneas descomentadas (las que no tienen el
s´ımbolo #)
son las que lee el kernel para habilitar (si tiene un 1) o deshabilitar (si tiene un 0) al inicio del
sistema.
Luego se debe activar el Įrewall Packet Filter del OpenBSD , en el archivo ͞/etc/rc.conf͟ para que
se ejecute en el inicio del sistema. También se pueden habilitar otros servicios útiles tal como
Bind. Una
parte de este archivo de conĮguración aparece en el listado 4.
Sólo resta conĮgurar el PF para que realice las operaciones de NAT (traducción de direcciones de
red) , esto, para que los equipos de la red local puedan acceder a Internet con la IP pública
asignada por
el proveedor. Lo que se verá con más detalles en la sección 3.3.
3.3. Reglas de Įltrado
A partir de la versión 3.0 de OpenBSD , luego de una disputa en la licencia utilizada en la
implementación del Įrewall, se comenzó el desarrollo de un nuevo software para que realizara
las mismas y
otras funciones más que el anterior. A esta implementación se la ha denominado Packet Filter
(abreviado
como PF) .
PF es el programa que maneja un conjunto de instrucciones a nivel de kernel, que permite la

gestión
del tráĮco entrante y saliente del sistema. Además realiza funciones de Įltrado del tráĮco
TCP/IP, NAT,
control de ancho de banda y priorización de paquetes, entre otras cosas.
ConĮguración 4 Algunas l´ıneas de /etc/rc. conf .
1 # ! / bin/ sh -
2#
3 # $ OpenBSD : rc . conf , v 1 . 1 28 2008/ 0 1 / 3 1 1 4 : 1 8 : 03 reyk Exp $
5 # s e t t he s e t o " NO " t o turn t hem o f f . o t he rwi s e , they ͛ re us ed as f lags
6 s shd_ f lags =" " # f or normal us e : " "
7 named_ f lags =" " # f or normal us e : " "
9 # s e t the f o ll owing t o " YES " t o t urn t hem on
10 pf = YES # Packe t f i l t e r / NAT
11 i ps e c = YES # I Ps e c
12 po rt map = NO # No t e : ine t d ( 8 ) rpc s e rvi c e s ne ed port map t oo
13 ine td= YES # almo s t always ne eded
14 che c k_quo t as = YES # NO may be de s i rabl e in s ome YP e nvi ronme nt s
15 ac c ount i ng = NO # pro c e s s ac c ount i ng ( us ing / var / ac c ount / acc t )
3.3.1 . Funcionamiento básico
Cuando se habilita el sistema de Įltrado de PF ʹsea al arranque o manualmenteʹ se carga el

archivo
͞/etc/pf.conf͟ , donde se conĮguraron las directivas del Įrewall, entre otras cosas. Este archivo es
le´ıdo y
se carga en orden secuencial, de modo que existe dependencia entre las reglas. Dicho archivo
consta de
siete partes, y sigue un orden predeterminado como se enumera aqu´ı:
1 . Macros: son las variables deĮnidas por el usuario que pueden contener direcciones IP, nombres
de
hosts, interfaces de red, etc.
2. Tablas: es una estructura que se usa para deĮnir un conjunto de direcciones IP y puertos.
3. Opciones: son las opciones para el funcionamiento de PF.
4. Normalización (Scrub) : realiza el reprocesamiento de paquetes para su normalización y
defragmentación.
5. Formación de colas: para proporcionar control de ancho de banda y priorización de paquetes.
6. Traducción de direcciones: controla la traducción de direcciones de red (NAT) y el
redireccionamiento de paquetes.
7. Reglas de Įltrado: permite el Įltrado selectivo o el bloqueo de paquetes según van pasando
por
las interfaces de red deĮnidas.
Durante el procesamiento del archivo de PF es importante la ubicación de las sentencias de

bloqueo
y apertura de puertos y protocolos, ya que si la l´ınea que bloquea los puertos se encuentra
después de la
l´ınea que abre un conjunto de puertos determinados, PF entenderá que la sentencia posterior es
la que
vale y anula la anterior, provocando un funcionamiento diferente al esperado (se supone abrir los
puertos
deĮnidos) . Por esto, a excepción de los macros y tablas, el archivo debe mantener el orden de los
pasos
anteriores. También se puede obviar algún punto para una aplicación espec´ıĮca.
Anchors
Una de tantas otras caracter´ısticas que posee este Įrewall, es un concepto que se denomina
anchor.
Un anchor es un contenedor dentro del cual se pueden agregar y quitar reglas de Įltrado on the
Ňy,
es decir, en tiempo de ejecución. Con ellos, Se puede por ejemplo, agregar un conjunto de
restricciones
sin tener que recargar el PF completo.
Packet Filter da la posibilidad de anidar anchors, pudiendo luego ser invocados con la misma
notación
que se utiliza en el Įlesystem de unix: separando los nombres de los anchors (de mayor a menor
nivel) con una barra ͚/͛ .
Si se encuentra que un paquete corresponde con una regla que está marcada con la opción quik,
dentro
de un anchor, no se continúa con las reglas subsiguientes, sino que se termina la evaluación.
Un ejemplo de la utilización de anchors, puede verse en la sección 6.4.3.
3.3.2. ConĮguración de Packet Filter
Ahora un ejemplo de conĮguración de Packet Filter para dejar salir a Internet a los equipos de una
red local, se puede ver en el listado 5.
ConĮguración 5 Reglas de PF para permitir conexión a Internet .
1 # I nt e r f ac e s de red
2 e xt _ i f =" tun0 "
3 int _ i f =" rl0 "
5 # Po l i t i cas
6 s et block - po li cy re t urn
7 s et l ogint e r f ac e $ e xt _ i f
9 # No rmal i zac i on
10 s crub in all
11
12 # Rut eo , NAT y r e di re c c i onami e nt o
13 nat on $ e xt _ i f f rom $ int _ i f : ne t work t o any -> ( $ e xt _ i f )
14
15 # Reglas de f i l t rado
16 blo ck all
17 pas s qui ck on $ int _ i f all
18 pas s qui ck on lo0 all
19
20 # Pe rmi t e el t raf i c o de sde la red int e rna
21 pas s in on $ int _ i f f rom $ int _ i f : ne t work to any ke ep s t at e
22 pas s out on $ int _ i f f rom any to $ int _ i f : ne t wo rk ke ep s t at e
23
24 # Pe rmi t e sal ida de paque t e s tcp , udp , i cmp
25 pas s out on $ e xt _ i f pro t o t cp all modulat e s t at e f lags S / SA
25 pas s out on $ e xt _ i f pro t o t cp all modulat e s t at e f lags S / SA
26 pas s out on $ e xt _ i f pro t o { udp , i cmp } all kee p s tat e
27
28 # Re s ponde a I CMP
29 pas s in on $ e xt _ i f pro t o i cmp all kee p s t at e
La interfaz interna (int if) no es más que la placa de red que ha detectado el sistema durante el
arranque y está conectada a la red local. En este caso se le ha asignado el nombre ͞rl0͟ ; este
var´ıa de
acuerdo al tipo de placa que se utilice (por ejemplo, para placas NE2000 o compatibles, se le
asigna el
dispositivo ͞ne0͟ , ͞ne1͟ y as´ı sucesivamente) .
Una vez cargados, estos parámetros de conĮguración permiten la navegación libre por Internet,
con
todos los puertos del servidor bloqueados. Para recargar las directivas del PF, ejecutamos lo
siguiente:
pfctl -f /etc/pf.conf.
El Įrewall crea una interfaz para monitorear su funcionamiento, se la puede ver con el comando
ifconĮg:
Por ejemplo, para monitorear los mensa jes que env´ıa PF ejecutamos el comando ͞tcpdump -i
pŇog0͟ .
3.4. Esquema de conexión
Para dar acceso a Internet a una pequeȂna red local hogareȂna, se utiliza un equipo con funciones
de
ruteo y Įrewall, cuyo esquema general se puede resumir en la Įgura 3.2.

Figura 3.2: Esquema de la red donde está el servidor con OpenBSD .
Para conocer detalles de los hosts, véase el Apéndice A. El equipo servidor de uno de los
extremos
de la conexión, funciona ba jo OpenBSD y tiene instaladas tres placas de red; una de ellas se
conecta a
la interfaz Ethernet del Modem/Router ADSL. Esta última, y la interfaz WAN de dicho router
están
conĮguradas como bridge; la otra se conecta con el Switch. Y la tercera se reserva para conĮgurar
zonas
DMZ 1 .
El Firewall también realiza funciones de NAT (Network Address Translation) , necesario para
compartir el acceso a Internet con todos los hosts de la red local; el servidor también brinda
servicios
de DHCP, para la asignación dinámica de direcciones. Además se ha conĮgurado un conjunto de

reglas
de Įltrado para determinados puertos, direcciones IP y MAC , para evitar el uso del Įrewall
cuando se
realicen transferencias de datos dentro de la red local.
En este caso, como se trata de una red hogareȂna, se permite el libre acceso hacia Internet, pero
para
establecer un nivel de seguridad adecuado, se bloquea cualquier conexión proveniente de

Internet que no
haya sido solicitada por un equipo que pertenezca a la red local.
En la Įgura 3.3 se pueden ver con más detalles de los elementos que participan en la conexión a
Internet, y también los dos PCs que comparten el acceso. Las mismas están conectadas a un
switch que
se encarga de ͞repartir͟ los datos entre los emisores y receptores de la red.
En la Įgura 3.3, puede verse un esquema detallado de una de nuestras redes locales, conectada a
Internet, a través del proveedor de servicios.

Figura 3.3: Esquema de conexión detallada de varios equipos de escritorio con el servidor
OpenBSD .
3.5. Automatización del sistema
En esta sección se detallarán los pasos necesarios para realizar una conexión a Internet
automatizada;
con todos los servicios que se brindarán sin necesidad de interacción con el terminal del servidor.
Es
decir, cuando se encienda el equipo se ͞levantarán͟ automáticamente los servicios

correspondientes y la
conexión a Internet.
También se mostrará la manera de mantener un dominio asociado a la dirección IP asignada por

el
proveedor con el Įn de facilitar la conexión necesaria entre los servidores de nuestras redes
locales.
3.5.1 . Conexión a Internet
Para que no sea necesario acceder al servidor cada vez que se quiera conectar a Internet, sino que,
con solo encender el equipo se efectúe dicha conexión de forma automática, se deben crear y/o
modiĮcar
algunos archivos de conĮguración.
En primer lugar el archivo ͞/etc/rc. local͟ contiene los scripts que se ejecutan en el arranque del
sistema, después de los servicios como Bind, DHCP, etc. En el listado de ConĮguración 6 se puede
ver una
sección que permite la conexión a Internet mediante la ejecución del comando ͞ppp -ddial
proveedor͟ y en
el que espera unos segundos antes de ejecutar el comando que comprueba si la conexión se ha
establecido
o no.
Lo que hace el script 6 es llamar al comando ppp para que se conecte con ͞proveedor͟ deĮnido en
/etc/ppp/ppp.conf y esperar unos segundos (sleep) por diez veces, hasta que otro script (adsl-
status)
ConĮguración 6 Script para el inicio automático de la conexión a Internet.
1 e cho -n ͛ Es t abl e c i e ndo PPPoE DSL : ͛ ; ppp - ddial prove edo r
2 e cho -n ͛ Es t abl e c i e ndo c one xi on : ͛
3 f or i in 1 0 9 8 7 6 5 4 3 2 1 0 ; do
4 s l e ep 3
5 e cho -n " $i "
6 if / usr / local / s bin / adsl - s tat us > / dev / null ; t hen
7 break
8fi
9 done
10 e cho -n ͛ \ nEs t ado : ͛ ; / usr / local / sbin / adsl - s tat us
devuelva verdadero, es decir que devuelva la dirección IP asignada por el proveedor. A este
último script
se lo debe crear y darle permisos de ejecución
$ sudo t ouch / us r / l o cal / s bin / adsl - s t at us
$ sudo c hmod + x / usr / l ocal / s bin / ads l - s t at us
Luego se lo edita como aparece en el listado de ConĮguración 7.
ConĮguración 7 Script para obtener la dirección IP que asigna el proveedor.
1 # ! / bin/ sh
3 IP =$ ( / sbin/ i f c onf i g t un0 | awk ͛ / ne t mas k /{ print $2 } ͛ )
5 if [ - z " $I P " ] ; then
6 e cho " Enlac e ADSL no es ta c one c t ado . "
7 e xi t 1
8 e ls e
9 e cho " ADSL c one c t ado , Di re c c i on IP $ I P "
10 e xi t 0
11 f i
De esta manera, cada vez que arranque el sistema, se iniciarán los servicios por defecto (como
SSH,
Inetd, etc. ) , junto a los servicios que se han indicado manualmente para que se iniciaran como
Packet
Filter y el script de conexión a Internet .

Aunque en realidad OpenBSD ejecuta automáticamente todos los comandos que se introduzcan
en
͞/etc/rc. local͟ , por eso se debe que tener especial cuidado al editar el archivo, sino pueden
ocurrir errores
al inicio y si no se monitorea el arranque para ver los mensa jes del sistema, ser´ıa dif´ıcil conocer
el error
que se produzca. Por eso es recomendable al principio monitorear todos los mensa jes de
arranque del
sistema.
3.5.2. Asociando un nombre de dominio
En primer lugar es necesario tener un dominio registrado en , cuyos pasos se pueden resumir
como
sigue:
1 . Registrar persona,
2. Registrar entidad,
3. Registrar dominio.
El trámite a veces es un poco largo, pero lo más importante a la hora de registrar el dominio, es
ya
que se deben agregar como servidores DNS a los que provee el servicio de DNS gratuito para
asociar la
IP al dominio. De los servicios más conocidos se pueden encontrar a:
Zoneedit ,
DnsExit,
Entre otros.
El que se va a utilizar para esta tesis es Zoneedit, que es gratuito y permite asociar hasta 5
dominios
sin costo. Luego del registro, se debe indicar nombre de dominio inicial, y a continuación se
obtiene los
DNS necesarios para ingresarlos en nic.ar.

3.5.3. Actualización de la dirección IP
Para actualizar el dominio a la dirección IP que asigna el proveedor existen varios métodos que
se
pueden utilizar con Linux u OpenBSD . Los más sencillos son usando la l´ınea de comandos, con los
programas Lynx o Wget con las siguientes sintaxis:
# lynx - s ourc e - aut h = us e rname : pas s word ͛ ht t p : / / dynami c . zone e di t . com/ aut h /
dynami c . ht ml ? ho s t = www .
mydomai n . com ͛
# wge t - O - -- ht tp - us er = us e rname -- ht tp - pas s wd = pas s word ͛ ht t p : // dynami c . zone

e di t . com / aut h / dynami c . ht ml
? hos t = www . mydomai n . com ͛
Como OpenBSD no viene con wget de serie y para no instalar ningún programa adicional, es
mejor
usar Lynx (que por cierto, no es mucho problema) . A ejecutar algún comando anterior, se
deber´ıa obtener
el mensa je de que ha sido actualizado el dominio a la dirección IP que ha asignado el proveedor

al equipo
servidor.
Como se quiere automatizar todo el proceso, lo mejor es instalar el paquete ddclient mediante el
comando (suponiendo que se utiliza los repositorios de Argentina) :
# sudo pkg_add - v ht t p : / / ope nbsd . md5 . c om . ar / pub / OpenBS D /4 . 3/ package s / i 386 /

ddc l i ent - 3 . 7 . 2 . tgz
Luego de la instalación, se crea el directorio y archivo de conĮguración en /etc/ddclient. Para

terminar
la conĮguración se tiene que modiĮcar, con los datos de la cuenta en Zoneedit, el archivo
ddclient. conf
que debe contener como m´ınimo lo que se muestra en el listado de ConĮguración 8.
ConĮguración 8 Resumen de conĮguración para ZoneEdit .

1 daemon =300 # che ck eve ry 300 s e c onds
2 s ys log = yes # log updat e msgs t o sys log
3 mai l = gus t avo # mai l all msgs t o ro ot
4 mail - f ai lure = gus t avo # mai l f ai l ed updat e msgs t o ro ot
5 pid =/ var / run/ ddc l i ent . pid # re c o rd PI D in f i le .
6 s sl = ye s # use ssl - support . Works wi th ssl - l i brary
7 use = web # via web
8 ##
9 ## Zone Edi t ( z one edi t . com )
10 ##
11 s e rver = www . z one edi t . com , \
12 pro t o c o l = zone edi t 1 , \
13 login= nomre _cuent a , \
14 pas s wo rd = SuP 3rS 3c r3 t P @ s S \
15 nombrede domi ni o . com . ar
Ahora es necesario ejecutar ddclient y probar su funcionamiento. Los parámetros que utiliza son
muy
sencillos, pero si ya se ha editado el archivo de conĮguración, no harán falta parámetros

adicionales, pero por ejemplo para ejecutarlo como ͞daemon͟ , que env´ıe información a Syslog y
cualquier otra información
a una cuenta de correo local, se deber´ıa ejecutar ddclient con los siguientes argumentos:
# ddc l i ent - daemon =0 - s ys l og - qui e t re t ry - mai l gus t avo
De otra manera, con solo ejecutar ͞ddclient͟ sin argumentos, se deber´ıa ver un proceso similar a
este:
8776 C0- I 2: 49. 43 perl: ddclient - sleeping for 280 seconds (perl)
Como se hab´ıa indicado en el archivo de conĮguración, ddclient se ejecuta (en busca de cambios
en
la dirección IP) cada 300 segundos. Además para saber que el dominio se ha actualizado, ddclient
env´ıa
un mensa je al usuario designado con la información siguiente (por ejemplo) :
SUCCESS: updating nombrededominio. com. ar: IP address set to 190. 226. 158. 2
(200: Update succeeded. )
regards,
ddclient@superhij itus. red. lan (version 3. 7. 1)
Si ocurre algún error, también se notiĮca por correo. Además OpenBSD env´ıa información
diaria del
estado del sistema, si se han modiĮcado archivos de conĮguraciones, el promedio de uso del
equipo, y
otra información con respecto al uso del disco r´ıgido y sus particiones. Por esta razón es
importante tener
bien conĮgurado Sendmail al menos para usuarios locales.
En cuanto a ddclient, se lo puede agregar al archivo /etc/rc. local para que inicie
automáticamente
con el sistema, pero antes se debe tener en cuenta de estar conectado a Internet, por eso se lo
ejecuta
posteriormente al script de conexión, agregando la l´ınea a continuación:
echo -n ͛ Estableciendo dominios. . . ͛ ;
/usr/local/sbin/ddclient -file /etc/ddclient/ddclient. Conf
3.5.4. Utilidades de un dominio propio
El interés de tener un dominio asociado a la dirección IP que es asignada por el proveedor, puede
provenir de que se quiera alo jar un servidor Web, por ejemplo, para poder acceder a él desde
otro sitio
f´ısico. También puede resultar importante para establecer una conexión por SSH para realizar
tareas
administrativas.
En el caso de las VPN, para establecer una conexión entre dos redes a través de Internet, el
hecho
de tener un nombre de dominio asociado a nuestra dirección IP resulta útil, ya que para
establecer la
conexión debemos conocer dicha dirección. Asociar un nombre a una dirección IP resulta
también muy
económico para las empresas que no puedan afrontar los costos de una solución VPN comercial
ni de
direcciones IP Įjas; pero a su vez es peligroso, debido a que se corre el riesgo de perder la
conexión,
cuando el nombre de dominio no esté apuntando a la dirección IP correcta.
3.6. ConĮguración de los clientes
Hasta ahora solamente se ha hablado de establecer la conexión a Internet con el servidor

OpenBSD
y que permite la conexión de los clientes a Internet a través de la puerta de enlace del mismo.
Pero si la conĮguración en los clientes no se ha realizado adecuadamente es posible que nunca se
pueda conectar a Internet desde un terminal. Por esto, hay que conĮgurar a los clientes para que
tengan
dirección IP Įja y que pertenezcan a la red del servidor (por ejemplo a la red 192.168.0.0) .
Además su
puerta de enlace debe apuntar a la dirección IP de servidor y los DNS pueden ser del servidor local
(si
es que se brinda dicho servicio) o del proveedor.
Si se tienen varios equipos terminales, con diferentes sistemas operativos, la mejor solución es
conĮgurar un servidor DHCP en el servidor, para evitar asignar direcciones IP manualmente a cada
computadora. En BSD el cliente de DHCP se denomina dhclient y se puede conĮgurar para iniciar
en el
arranque. En Linux y Windows también se tiene por defecto un cliente DHCP, por lo que en la
mayor´ıa de los casos no se requiere ninguna conĮguración manual.
3.6.1 . Servidor DHCP

Un servidor DHCP permite asignar automáticamente direcciones IP de determinado rango a los
terminales clientes (equipos de la red local) . Esta funcionalidad permite ahorrar mucho tiempo y
esfuerzo
en lo que ser´ıa conĮgurar manualmente direcciones IP y Gateway en cada equipo nuevo que se
una a la
red.
Para que el servicio se inicie durante el arranque del sistema, se tiene que cambiar el parámetro
͞NO͟
por lo siguiente:
dhcpd_flags=" "
Luego se tiene que editar la conĮguración del servidor DHCP donde se indica el rango de
direcciones
IP y los servidores de nombre (DNS) que se les va a transmitir utilizar a los usuarios. El primer
archivo
es el ͞/etc/dhcpd.conf͟ que deber´ıa contener lo siguiente (por ejemplo) lo que se muestra en el

listado
de ConĮguración 9.
ConĮguración 9 Ejemplo de conĮguración de un servidor DHCP.
1 shared - ne t work LOCAL - NET {
2 o pt i on domain - name " red . lan " ;
3 o pt i on domain - name - s e rve rs 1 9 2 . 1 6 8 . 0 . 1 ;
5 subne t 1 9 2 . 1 6 8 . 0 . 0 ne t mas k 2 5 5 . 2 5 5 . 2 5 5 . 0 {
6 opt i on rout e rs 1 9 2 . 1 68 . 0 . 1 ;
8 range 1 9 2 . 1 6 8 . 0 . 32 1 9 2 . 1 6 8 . 0 . 1 2 7 ;
9}
10
11 }
El otro archivo de conĮguración es donde se indica la interfaz por la que ͞entrarán͟ los cliente a
solicitar la información de la red. Este archivo es ͞/etc/dhcpd. interfaces͟ y por ejemplo puede
contener
solamente el dispositivo de red que este conectado al switch:
rl0
De esta manera se tiene conĮgurado un servidor DHCP para que acepte conexiones a través de la
red
local (interfaz rl0) y asigne un rango de direcciones IP que van de 192.168.0.32 a 192.168.0.127, lo
cual
permite a 95 clientes simultáneamente. Los clientes solo deben saber que tienen que buscar un
servidor
DHCP.
3.6.2. Finalizando la conĮguración
Ahora que se tiene un sistema robusto, seguro y muy Ňexible en cuanto a la conĮguración del
mismo,
se puede proceder a realizar unos retoques Įnales en algunos parámetros de conĮguración.
Para listar los servicios que se están ejecutando en el sistema se utiliza el comando ͞ps ax͟ , que
puede generar una salida como la siguiente:
En el listado anterior se pueden ver los servicios que se han conĮgurado para iniciar junto a los
argumentos con que se ejecutan. También se pueden ver otros servicios como los dos servidores
de
Subversion (Sección B .3 de la página 122) e Inetd.
El servicio Inetd es un conjunto de servicios que se inician de acuerdo a la demanda o solicitud de
un servicio determinado. En muchos casos es conveniente desactivar estos servicios para no abrir
puerto
innecesarios, ya que los servicios básicos que ofrece (como ftp, Įnger, ident, pop3, daytime, entre
otros)
traba jan en texto claro, en el que por ejemplo el servicio POP3 que utiliza autenticación para
funcionar,
env´ıa los datos de usuarios sin encriptar, de manera que con un simple sniīer de paquetes se
pueden
obtener nombres de usuarios y contraseȂnas en texto claro.
Si por otro motivo se requiere utilizar alguno de estos servicios, los datos de los mismos se
encuentran
en /etc/inetd.conf y para habilitarlos basta con quitar el comentario de una l´ınea o comentarla
para
deshabilitar el servicio.
Por otro lado, las conexiones de terminales se pueden limitar a solamente una terminal virtual, de
manera que se libera memoria innecesaria (para administrar el sistema, pocas veces se puede
llegar a usar
más de un terminal) . El archivo de terminales se encuentre en /etc/ttys, y solo es necesario que

cambiar
el valor ͞on͟ por el valor ͞oī͟ :
console "/usr/libexec/getty std. 9600" vt220 off secure
ttyC0 "/usr/libexec/getty std. 9600" vt220 on secure
ttyC1 "/usr/libexec/getty std. 9600" vt220 off secure
Para mejorar la seguridad del sistema, se puede quitar la contraseȂna del usuario root para evitar
cualquier intrusión o intento de hacking a esta cuenta. Para esto, se debe suponer que un usuario
normal pueda tener permisos de ejecución del comando ͞sudo͟ para poder realizar las
operaciones de
administración del sistema. Para agregar un usuario al grupo wheel (para poder ejecutar ͞sudo͟ )
, es
necesario el comando ͞gpasswd -a ¡usuario¿wheel͟ . Además es necesario asegurar de que al

ejecutar visudo
para editar el archivo de conĮguración de sudo, éste contenga la l´ınea:
%wheel ALL=(ALL) SETENV: ALL
Y luego quitar la contraseȂna de root , eliminando la cadena de texto extraȂno del archivo master.
passwd
de manera que quede como sigue:
root: : 0: 0: daemon: 0: 0: Root &: /root: /bin/ksh
De esta manera, nadie va a poder ingresar como root. Pero a pesar de que esto puede suponer
una
mejora para la seguridad del sistema, por otro lado se debe tener en cuenta que el usuario del
sistema
con permisos en el grupo wheel, no puede tener una contraseȂna débil, ya que puede ser
descifrada y
utilizada como si del usuario root se tratara (ya que en la conĮguración de visudo se ha
especiĮcado
que el usuario que pertenezca a wheel pueda ejecutar cualquier comando como administrador) .
Otra
manera de asegurar el sistema ser´ıa especiĮcar que los usuarios wheel solo tengan permiso de
administrar
determinados archivos y entornos, que también se consigue editando la conĮguración con

visudo.
3.7. Recursos utilizados
En esta sección se describen los aspectos superĮciales y económicos de los componentes

utilizados
para la conexión a Internet de la red local. Para más detalles en la descripción de equipos de
toda la
VPN, ver el Apéndice A
3.7.1 . Servidor
El servidor debe ser una máquina medianamente potente y en buen funcionamiento. Debe tener
su
gabinete en buenas condiciones y con los ventiladores correspondientes y en buen estado. Es

importante
mantener estas caracter´ısticas, ya que el equipo debe estar encendido siempre, por lo que la
refrigeración
es punto clave para mantener un buen servicio y funcionamiento del servidor, además de alargar
la
usabilidad del mismo. Si no se dispone de un PC para el servidor, hoy en d´ıa existe la posibilidad
de
comprar equipos de marca muy económicos, con respecto a la utilidad que se le dará.
3.7.2. Modem ADSL y Switch
El modem ADSL y Switch son componentes que hay que elegirlos en ca jas cerradas, ya que no se
pueden ͞fabricar͟ , pero se deben tener muy en cuenta de la calidad de lo que se adquiere.
En cuanto al modem ADSL, debe contar con una interfaz Ethernet para conectar la placa de red
del servidor, que en general son más costoso que los modem con solo puerto USB . El precio de
estos
dispositivos no superan los 200 pesos, cumpliendo la única función de ͞bridge͟ entre la interfaz
Ethernet
y la l´ınea telefónica.
El switch también es un elemento muy común usado en redes de cualquier tamaȂno y se pueden
conseguir a un precio muy económico.
3.7.3. Cableado
El cableado es un componente importante que afecta en el rendimiento de la red. Muchas veces la

deĮciente comunicación entre hosts se debe a una mala instalación de los cables de red. Para ver
que la
velocidad de conexión es adecuada, basta con una simple transmisión de archivos entre las
terminales. Si
se trata de una red a 100 Mbps, la velocidad teórica a alcanzar deber´ıa ser de 12,5MB/s, aunque
si se
alcanza un 75 o 90 por ciento está muy bien también.
Hoy en d´ıa, como todos los switch soportan las normas de cableado 568-B (normal) y 568-A
(cruzado) ,
lo más conveniente es armar directamente cables cruzados, por si alguna vez deja de funcionar el
switch
o se necesita hacer pruebas conectando solo dos hosts.
La categor´ıa del cable a utilizar también es importante, y actualmente es fácil conseguir Cat-5e a
precios razonables (menos de 2 pesos el metro) .
3.8. Conclusión
Hoy en d´ıa la conexión a Internet es un requisito casi imprescindible para el funcionamiento y
crecimiento de una empresa. Por esta razón es que se ha dedicado todo un cap´ıtulo a la
conĮguración de
la misma.
Si bien se podr´ıan haber planteado alternativas para la conexión a Internet , se considera que la
mejor solución es dedicar un equipo completo que realizara tal función, ya que permite la
Ňexibilidad
de conĮguración del sistema, el considerable aumento de la seguridad al tener Įrewall robustos y
la posibilidad de incluir servicios adicionales como servicios de direcciones IP dinámicas,

asignación
automática de dirección IP local, administración remota, entre otros.
Además los ba jos requisitos de los equipos hacen muy económica su adquisición, ya que no
requiere
potencia en gráĮcos, ni grandes cantidades de espacio de almacenamiento. Pero lo más
importante y a
veces costoso se reĮere al mantenimiento de los equipos, ya que si se mantiene la conexión las 24
horas
al d´ıa, el equipo levanta temperatura, y puede daȂnar los componentes. Por eso la importancia de
tener
una buena refrigeración.
En cuanto a los sistemas operativos que pueden instalarse en los equipos, se cuenta con una gran
variedad (entre Linux, BSD , Solaris, etc.) , pero se ha elegido OpenBSD en particular por su elevada
seguridad y ba jos requerimientos para un funcionamiento Ňuido. También tiene una gran
cantidad de
información en Internet para resolver los distintos problemas que se vayan presentando.
Cap´ıtulo 4
VPN usando PPTP
PPTP es un protocolo diseȂnado para establecer comunicaciones seguras entre dos terminales,
que
luego se terminaron usando para establecer una VPN de tipo host a host (o en algunos casos, host
a red) .
En este cap´ıtulo se describirá brevemente el protocolo junto a sus venta jas y desventa jas de
uso.
También se explicará la conĮguración de PPTP a través de Internet (utilizando tanto Windows

como
Linux y OpenBSD) , teniendo en cuenta que el usuario se encuentra en una red local, por lo que se
mostrarán los detalles de conĮguración del Įrewall y los parámetros necesarios para establecer
una VPN
con PPTP.
4.1 . Introducción a PPTP
El protocolo PPTP (Point to Point Tunneling Protocol) ha sido desarrollado por Microsoft , U.S .
Robotics, Ascend Communications, 3Com/Primary Access, ECI Telematics conocidas
colectivamente
como PPTP Forum, para implementar redes privadas virtuales y asegurar conexiones punto a
punto.
PPTP se utiliza de manera más espec´ıĮca para crear sesiones VPN para usuarios móviles en
conĮguraciones host a red o host a host . La integración que tiene PPTP conWindows es nativa,
pero con
otros sistemas operativos, se utilizan portes o adaptaciones que siguen las especiĮcaciones del
protocolo.
El único motivo por el que se requiere de una implementación del protocolo para sistemas Linux
o
BSD, es para dar soporte a la gran cantidad usuarios móviles que utilizanWindows, ya que para
establecer
una conexión host a host con el mismo sistema operativo, el proceso de conĮguración no resulta
para
nada complicado.
4.1 .1 . Funcionamiento de PPTP
PPTP utiliza para establecer conexiones VPN seguras. Primero, realiza el encapsulado de los
paquetes
de datos dentro de paquetes PPP. Luego se encapsulan estos paquetes usando el protocolo GRE
(Generic
Routing Encapsulation) y se los env´ıa al otro extremo del enlace.
Además de los paquetes GRE, que comprimen los datos PPTP reales, se utiliza un segundo canal
de
control para la conexión. Esta es una conexión TCP (Transmission Control Protocol) sencilla desde
el
cliente al puerto 1723 del servidor. Se la utiliza para enviar información de seȂnalización y para
comprobar
el estado de la conexión PPTP.
Por otro lado, PPTP no especiĮca qué algoritmos de cifrado o autenticación utilizar, sino que esta
tarea queda para la sesión PPP subyacente.
4.1 .2. Autenticación y cifrado
Para permitir autenticación y cifrado en la sesión PPTP, se han tenido que aȂnadir unos cuantos
algoritmos a PPP. Para la autenticación, se ha aȂnadido una variante de CHAP (Challenge

Handshake
Authentication Protocol) , llamadaMS-CHAP (Microsoft Challenge Handshake Authentication

Protocol) .
Este se basa en dos métodos de Microsoft utilizados para la autenticación y compartimiento de

archivos:
el algoritmo de dispersión LAN Manager (basado en el cifrado DES) y el algoritmo de

dispersiónWindows
NT (basado en la función de dispersión MD4) .
La segunda extensión de PPP es el protocoloMPPE (Microsoft Point-to-Point Encryption) que

maneja
el cifrado real de los paquetes. Utiliza el cifrado de Ňujo RC4 para cifrar los datos con una clave de
40
a 128 bits. La clave de cifrado utilizada para el cifrado deriva parcialmente de la contraseȂna del
usuario
mediante el algoritmo LAN Manager o el algoritmo NT. Las claves de sesión utilizadas para el
cifrado se
cambian periódicamente, normalmente después de cada 256 paquetes.
4.2. PPTP con Windows
En esta sección se mostrará cómo conĮgurar un servidor VPN en Windows Vista, de la manera
más
simple posible, que permite varias conexiones entrantes mediante autenticación por nombre de
usuario y
contraseȂna.
Como no se trata de un servidor dedicado, sino más bien de una estación de traba jo que se
conĮgura
para aceptar conexiones de otros clientes, la puesta a punto de lamisma puede estar al alcance de
cualquier
usuario de oĮcina. Esto podr´ıa considerarse una falla de seguridad, ya que al permitir conexiones
entrantes
a jenas a la red interna sin considerar una pol´ıtica de seguridad adecuada, puede suceder que la
conexión
permitida no sea quien dice ser (es decir, sea un hacker con malas intenciones) .
Para solventar este problema, se realizarán retoques en la conĮguración del Įrewall de la red,
para
permitir conexiones entrantes solamente a los equipos supervisados y autorizados para dicha
función.
4.2.1 . Modo de conexión
Para comunicar dos equipos utilizando el protocolo PPTP se realiza una conexión de tipo host a
host,
entre terminales con el sistema operativo Windows.
Una VPN host a host (o punto a punto) involucra únicamente a dos equipos, donde uno actúa
como servidor y el otro como cliente. Estos pueden estar ubicados en puntos muy distantes o en
subredes distintas. Solamente si se puede establecer una ruta de comunicación entre ambos
terminales,
se podrá realizar la conexión VPN.
Este tipo de conexiones, en apariencia tan limitadas, encuentran su Įn práctico cuando dos
servidores
de una empresa necesitan sincronizar datos conĮdenciales, y deben hacerlo a través de redes de
acceso
público donde se corre el riesgo de que los datos sean interceptados por destinos no deseados.
De esta
manera, los datos via jan seguros a través de un medio hostil. Un esquema simpliĮcado de este
tipo de
conexión se puede ver en la Figura 4.1 .
4.2.2. Directivas del Firewall

Para aceptar conexiones entrantes del cliente se debe abrir el puerto 1723 (PPTP) tanto para
paquetes
TCP como para UDP, y además de permitir paquetes que utilicen el protocolo GRE, tanto a la
entrada
como a la salida de datos.
ConĮguración 10 Aceptar conexiones PPTP y GRE.
1 # Re di r e c c i onami e nt o de paque t e s al s e rvido r VPN
2 rdr pas s on $ e xt _ i f pro t o t cp f rom any to any port ppt p -> $ s e rve r_ vpn
3 rdr pas s on $ e xt _ i f pro t o gre f rom any to any -> $ s e rve r_vpn
5 # Reglas de f i l t rado para la ent rada y salida de c one xi one s VPN .
6 pas s in qui ck on $ e xt _ i f pro t o t cp f rom any t o any port ppt p \
7 f lags S / FSRA ke e p s t at e
9 # Paque t e s GRE para c one xi on VPN sal i ent e
10 pas s on $ ext _ i f pro t o gre f rom any to any

Figura 4.1 : Esquema de conexión de las redes utilizadas.
Estas directivas requieren pequeȂnas modiĮcaciones en el Packet Filter, tal como se muestra en el
Código 10. Luego de agregar estas l´ıneas, se debe volver a recargar PF con pfctl -f /etc/pf.conf.
4.2.3. Aceptar conexiones con Windows Vista
La conĮguración de un servidor VPN en Windows Vista resulta más sencilla cuando se trata de
una
comunicación simple de tipo host a host. En primer lugar lo que se crea es una conexión
entrante, que
permita el ingreso de conexiones desde el exterior a la red virtual.
Para que esta comunicación pueda establecerse, hay que conĮgurar el Įrewall del equipo, ya que
hoy
en d´ıa todas las computadoras personales disponen de algún antivirus con Įrewall incorporado
con el Įn
de evitar el ingreso de intrusos que pongan en peligro los datos personales, que desde el punto de
vista del
usuario son más importantes que los fallos del sistema (que puede solucionarse en la mayor´ıa de
los casos
con una simple reinstalación) , pero como administrador de una red local, en la que no solo se
considera
importante la pérdida de datos de un usuario, sino también de la seguridad del sistema y de toda
la red,
al establecerse una comunicación VPN se la realiza con el Įrewall activado y conĮgurado para
bloquear
todas las conexiones entrantes y evitar que clientes poco precavidos pongan en riesgo la seguridad
de
toda la red.
La conĮguración del Įrewall consta en habilitar el compartir archivos de Windows y el puerto

PPTP
que se utiliza en las conexiones punto a punto entre equipos con sistemas de Microsoft. Luego,
entra
en acción el equipo servidor de VPN, el cual realiza la negociación de la conexión estableciendo

el tipo
de encriptación, de protocolos que se van a utilizar y del método que se env´ıa la contraseȂna.
Una vez
establecidos estos parámetros, el sistema le asigna una dirección IP (puede ser cualquier
dirección IP
privada válida, siempre que no interĮera con los rangos ya seleccionados) al cliente,
estableciendo la
conexión propiamente dicha.
En Windows Vista el asistente para crear una conexión entrante resulta sencillo e intuitivo de
usar,
ya que las opciones por defecto son en general la mejor elección. Al abrir la ventana de
administración
de interfaces de red, se visualizan las conexiones establecidas, en la que se muestran detalles

como la
dirección asignada, máscara de red, servidor DNS primario y secundario asignados, direcciones
MAC , entre otros.
La elección de un usuario para que se conecte con el equipo servidor puede ser muy cr´ıtica a la
hora
de mantener la seguridad del sistema (y por qué no, de toda la red) , ya que dar a alguien
privilegios
de administrador y contraseȂna fácil de romper, puede signiĮcar un gran problema de seguridad

(Figura
4.2) . En este caso, se crea un usuario espec´ıĮco para la conexión VPN, al cual se le asignan los
permisos
necesarios para las acciones m´ınimas en la red (como copiar archivos del servidor) .
El asistente de conĮguración de conexiones entrantes también pregunta por el software de red

que se
le habilitará a los usuarios que se conecten a la VPN, seleccionando por defecto las opciones de
TCP
(Transmission Control Protocol)/IPv4 (Internet Protocol versión 4) , de compartir archivos e
impresoras
y de calidad de servicio. Pero para que funcionen estos servicios se debe conĮgurar el Įrewall local
para
aceptar este tipo de conexiones.
Como última opción del asistente, se pueden conĮgurar las direcciones IP que se les dar´ıan a los
usuarios, permitiendo asignar direcciones que pertenezcan a otra red y as´ı diferenciar la red local
de la
red VPN. En la Figura 4.3 se puede ver que el total de conexiones es de 5 usuarios, pero uno de
ellos
representa el servidor de VPN, que establece un puente virtual entre el sistema local y la nueva
interfaz
de red (que se crea automáticamente) .
Si se escribiera un grupo de direcciones IP que pertenecen a una subred diferente (por ejemplo:
192.168.1 .0) , el asistente de conĮguración de conexión entrante, conĮgurará

automáticamente la tabla de
ruteo para exista una comunicación entre la red actual y la creada para la VPN.
Por otro lado es importante seȂnalar, que a la primera conexión entrante, el sistema crea una
nueva
entrada en la tabla de ruteo que dirige el tráĮco de la VPN hacia la puerta de enlace (servidor de
Internet)
para todos los paquetes que no pertenezcan a la red local o a la red creada para la VPN. Es decir
que
además de crear una conexión segura entre dos enlaces, también se puede acceder a Internet
sin temer
que los mismos miembros de la red registren los paquetes y descubran información personal del
usuario.
Figura 4.3: Direcciones IP habilitadas para asignar a los usuarios.
4.2.4. Cliente PPTP con Windows
El proceso de conĮguración del cliente es sencillo y contiene pocos elementos para conĮgurar, ya
que
solo realiza la conexión al servidor y es éste quien negocia los parámetros establecidos
necesarios. En
deĮnitiva, la mayor diĮcultad en cuanto a conĮguración se encuentra en el servidor.
Para conectar al servidor de VPN, se debe crear en el cliente una nueva conexión. Como Microsoft
diseȂna la mayor´ıa de sus sistemas operativos para que sus usuarios Įnales no necesiten
conocimientos
profundos sobre los mismos, las opciones que se muestran a medida que avanza el asistente de
conĮguración, no contiene muchas especiĮcaciones, como se puede ver en la Figura 4.4.
Posteriormente, se debe especiĮcar si el establecimiento de la conexión estará precedido por el

de otra,
es decir, si para establecer la ruta entre el cliente y el servidor de la VPN, es necesario tener una
conexión
a Internet ya establecida, o a otra red.

En general la conexión a Internet ya está establecida por el servidor de la red local, por lo que en
el
menú correspondiente se selecciona la opción de no utilizar la conexión inicial.
Luego se debe especiĮcar el nombre de dominio o la dirección IP del servidor VPN. Esto implica
que
el cliente siempre que quiera conectarse a la VPN deberá conocer la IP del servidor. Por lo que,
dicha
dirección, no debe ser variable, o en su defecto debe existir un nombre de dominio que pueda
seguir los
cambios de la misma. En la sección 3.5 se explica cómo obtener un nombre de dominio

permanente, aún
teniendo una dirección IP variable.
Terminado el asistente, se puede ver que dentro de ͞Conexiones de red͟ que se ha creado una
nueva
conexión, que es la que se utiliza para conectar al servidor de la red privada virtual.
4.2.5. Resultado
Establecida la conexión VPN, ambos hosts tendrán la impresión de que están en una misma
subred
privada (distinta a la que cada uno de ellos está conectado realmente) ; además, los datos
transmitidos
entre ellos a través de la VPN, serán invisibles a los demás usuarios.
El protocolo de autenticación de claves utilizado es MS-CHAP (Microsoft Challenge Handshake
Authentication Protocol) v2; y el algoritmo de cifrado para los mensa jes es MPPE (Microsoft Point-
to-Point Encryption) , de 128 bits.
El esquema resultante de la VPN se muestra en la Figura 4.5.

Figura 4.4: ConĮguración Cliente, tipo de conexión.
4.3. PPTP con software libre
Con la popularidad de Windows y su protocolo PPTP para establecer enlaces punto a punto
seguros,
era necesario integrar otros sistemas operativos para permitir este tipo de conexiones, ya que la
mayor´ıa
de los clientes de escritorios contaban con Windows como sistema principal.
De esta manera, se ha iniciado el desarrollo de un clon del protocolo de código fuente abierto en
conjunto con Microsoft para permitir la integración de equipos Windows con cualquier otro
sistema
operativo mediante un enlace seguro y compatible con el original PPTP. Este desarrollo se ha
denominado
PoPToP 1 .
4.3.1 . Caracter´ısticas de PoPToP
PoPToP se ha portado a la mayor´ıa de los sistemas operativos, incluyendo Linux y OpenBSD .

Gracias
a esto, se pueden integrar sistemas heterogéneos (incluyendo equipos con Windows) mediante
un enlace
común y asegurado por PPTP. Entre las caracter´ısticas técnicas que tiene PoPToP se pueden
listar las
siguientes:
Autenticación y encriptación compatible con Microsoft (MSCHAPv2, MPPE 40 - 128 bit RC4
encryption) .
Soporte para múltiples conexiones.
Mediante el uso de plugin se pueden integrar entronos de redes (LDAP, SAMBA) .
Es compatible con el cliente PPTP de Linux.
Es totalmente gratuito ba jo licencia GNU (General Public Licence) .
1Juego de palabras que, en deĮnitiva, signiĮca PPTP. http://www.poptop.org/
Figura 4.5: Esquema básico de un enlace host a host .
4.3.2. Instalación de PoPToP
En Linux (Ubuntu Server 8.04) se han realizado las pruebas de conexión e interacción con
sistemas
Windows XP y Vista. La instalación de PoPToP no requiere gran intervención por el

administrador; se
realiza mediante el comando:
gus t avo @was a : ~ $ sudo apt - ge t i ns t al l ppt pd
...
gus t avo @was a : ~ $
De esta manera, se instala el daemon PPTP y se inicia automáticamente.
Para establecer una conexión Įable, se necesitan modĮciar algunos parámetros de

conĮguración, como
el rango de direcciones IP que puede aceptar (que limita también la cantidad de clientes que
pueden
acceder simultáneamente) , los certiĮcados (si es que se utilizan) , entre otros.
4.3.3. ConĮguración de PPTP
Los archivos necesarios para conĮgurar PoPToP correctamente son los siguientes:
1 . /etc/pptpd. conf
2. /etc/ppp/pptpd-options. conf
3. /etc/ppp/chap-secrets
El primer archivo es el utilizado por PoPToP para lanzar el daemon PPTPD , además de las
direcciones
IP del servidor y las que se asignan a los clientes. En la ConĮguración 11 se puede ver un ejemplo
básico
de funcionamiento.
ConĮguración 11 Ejemplo de conĮguración básica de PoPToP.
1 o pt i on / e t c / ppp / pptpd - o pt i ons
2 de bug
3 logwt mp
4 lo cali p 1 9 2 . 1 68 . 2 . 1
5 remo t e i p 1 9 2 . 1 68 . 2 . 2 - 9
En la primera l´ınea se debe indicar el archivo secundario de conĮguración del daemon PPTPD ,
que en
este caso se encuentra en /etc/ppp/pptpd-options . La segunda l´ınea indica que se muestren

todos los mensa jes en el archivo de registro. La tercera indica que se registren todas las
conexiones y desconexiones
de los clientes para PPP, ya que por defecto se encuentra habilitada para las otras interfaces
(como
pts/0 o tty1) y es bastante útil para saber en qué horarios se conectaron, por cuanto tiempo y
cuando se
desconectaron los clientes.
Finalmente las últimas dos l´ıneas indican la dirección IP del servidor y el rango de direcciones
que se
les asignan a los clientes respectivamente. Si se supera este rango, no se aceptan más conexiones,
por lo
que en este caso solo se permiten ocho clientes simultáneamente.
ConĮguración 12 Ejemplo de opciones en pptp-options.
1 name ppt pd
2 domain red . lan
3 re f use - pap
4 re f use - chap
5 re f use - ms chap
6 require - ms chap - v2
7 require - mppe - 1 28
8 ms - dns 1 9 2 . 1 6 8 . 0 . 1
9 pro xyarp
10 lock
11 no bs dc omp
En el archivo de ConĮguración 12 se indican el método de encriptación utilizado, los servidores

DNS , el
gateway, entre otras opciones. También se puede observar que se rechazan conexiones utilizando
el método
de autenticación antiguo de Microsoft, el MS-CHAP (Microsoft Challenge Handshake

Authentication
Protocol) versión 1 (pero se acepta la versión 2) , ya que presenta problemas de seguridad

debido a que
env´ıa la contraseȂna del cliente utilizando el algoritmo LAN Manager que es muy débil y luego un
hash
Windows NT que depend´ıa de la primera. Por lo tanto se podr´ıa quebrar el algoritmo fácilmente
con la
herramienta L0phtcrack2 .
El último archivo es un simple archivo de texto que deber´ıa tener permisos limitados solo para el
propietario (0600) , ya que contiene el nombre de usuario y contraseȂna de los clientes. Además
se incluyen
las direcciones IP de los hosts desde los que pueden efectuar la conexión, que pueden ser
sustituidas por
un asterisco para indicar que el usuario puede conectarse desde cualquier equipo.
4.3.4. Estableciendo conexión
Para establecer la conexión con el servidor PPTP, se utiliza la misma conĮguración descripta
anteriormente en la Sección 4.2.4.
Cuando el sistema detecta una conexión entrante, realiza el proceso de intercambio de

información,
entre los que se encuentra el env´ıo de las claves del usuario, y Įnalmente se acepta o rechaza la
conexión.
En caso aĮrmativo, se muestra la siguiente salida en el registro del sistema:
Oc t 1 7 09 : 23 : 1 1 wasa ppt pd [5 5 20 ] : CTRL : Cl i ent 1 90 . 1 3 7 . 6 7 . 6 8 c ont ro l c o nne c t

i on s t art ed
Oc t 1 7 09 : 23 : 1 1 wasa ppt pd [5 5 20 ] : CTRL : S t ar t i ng cal l ( launchi ng pppd , openi ng GRE

)
Oc t 1 7 09 : 23 : 1 1 wasa pppd [5 5 2 1 ] : Plugi n / us r / li b / ppt pd / ppt pd - l ogwt mp . so l
oaded .
Oc t 1 7 09 : 23 : 1 1 wasa pppd [5 5 2 1 ] : pppd 2 . 4 . 4 s t art ed by root , uid 0
Oc t 1 7 09 : 23 : 1 1 wasa pppd [5 5 2 1 ] : Us ing i nt e r f ac e ppp1
Oc t 1 7 09 : 23 : 1 1 wasa pppd [5 5 2 1 ] : Conne c t : ppp1 < - - > / dev / pt s /3
Oc t 1 7 09 : 23 : 1 1 wasa ppt pd [5 5 20 ] : GRE : Bad che cks um f rom pppd .
Oc t 1 7 09 : 23 : 1 1 wasa ppt pd [5 5 20 ] : CTRL : I gno red a SET LI NK I NFO packe t wi t h real

ACCMs !
Oc t 1 7 09 : 23 : 1 1 wasa pppd [5 5 2 1 ] : MPPE 1 28 - bi t s t at e l e s s c ompre s s i on enabl e d
Oc t 1 7 09 : 23 : 1 3 wasa pppd [5 5 2 1 ] : Canno t de t e rmi ne e t he rne t addre s s f or proxy

ARP
Oc t 1 7 09 : 23 : 1 3 wasa pppd [5 5 2 1 ] : l o cal I P addre s s 1 9 2 . 1 6 8 . 2 . 1
Oc t 1 7 09 : 23 : 1 3 wasa pppd [5 5 2 1 ] : remo t e I P addre s s 1 9 2 . 1 6 8 . 2 . 3
En este caso se establecen las direcciones IP local (del servidor) y la asignada a la nueva conexión.
Tambien se puede ver que se utiliza una encriptación MPPE (Microsoft Point-to-Point Encryption)
de
128 bit con compresión habilitada.
2http://es.wikipedia.org/wiki/L0phtCrack
Los dispositivos que crea cada conexión remota PPTP, se denominan por defecto pppX, donde X
es
un número que se incrementa por cada conexión, comenzando en cero. Por ejemplo la siguiente
salida se
obtiene del comando ifconĮg :
ppp0 Link encap : Point - to - Po i nt Pr o t o c o l
ine t addr : 1 9 2 . 1 6 8 . 2 . 1 P - t - P : 1 9 2 . 1 6 8 . 2 . 2 Mask : 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5
UP P O I NTO PO I NT RUNNI NG NOARP MULTI CAS T MTU : 1 39 6 Me t r i c : 1
RX packe t s : 64 e rro rs : 0 dropped : 0 ove rruns : 0 f rame : 0
TX packe t s : 1 7 e rro rs : 0 dropped : 0 ove rruns : 0 carri e r : 0

c o l l i s i ons : 0 t xque ue l en : 3
RX byt e s : 56 1 0 ( 5 . 4 KB ) TX byt e s : 628 ( 6 28 . 0 B )
ppp1 Link encap : Point - to - Po i nt Pr o t o c o l
ine t addr : 1 9 2 . 1 6 8 . 2 . 1 P - t - P : 1 9 2 . 1 6 8 . 2 . 3 Mask : 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5
UP P O I NTO PO I NT RUNNI NG NOARP MULTI CAS T MTU : 1 39 6 Me t r i c : 1
RX packe t s : 36 e rro rs : 0 dropped : 0 ove rruns : 0 f rame : 0
TX packe t s : 1 1 e rro rs : 0 dropped : 0 ove rruns : 0 carri e r : 0
c o l l i s i ons : 0 t xque ue l en : 3
RX byt e s : 36 67 ( 3 . 5 KB ) TX byt e s : 288 ( 2 88 . 0 B )
En la salida anterior se puede observar que se han establecido dos conexiones remotas y que se
encuentran activas en ese instante. El primer campo de ͞inet addr͟ corresponde a la dirección IP
del
servidor, mientras que ͞P-t-P͟ reĮere a la dirección IP asignada a la conexión entrante. Luego se
utiliza
esta dirección IP para establecer las tablas de ruteo:
gus t avo @was a : / e t c / ppp$ rout e
Kerne l IP rout i ng tabl e
De s t i nat i on Gat eway Genmas k Flags Me t ri c Re f Us e I f ac e
1 9 2 . 1 6 8 . 2 . 2 * 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5 UH 0 0 0 ppp0
1 9 2 . 1 6 8 . 0 . 0 * 2 5 5 . 2 5 5 . 2 5 5 . 0 U 0 0 0 e t h1
de f aul t 1 9 2 . 1 6 8 . 0 . 1 0 . 0 . 0 . 0 UG 1 00 0 0 e th1
gus t avo @was a : / e t c / ppp$
De lo anterior se puede observar que hay solamente una conexión activa (en ppp0) donde se ha
establecido la dirección IP 192. 168. 2. 2 al equipo remoto. Pero se ha especiĮcado que no cambie
el ruteo
͞default gateway͟ , por lo que se mantiene el servidor anterior ( es decir, la IP 192. 168. 0. 1 como
pasarela
predeterminada) .
4.4. Rendimiento de la conexión
Mientras se realizaban las pruebas de conexión, se utilizaron sistemas de monitoreo que

permiten
visualizar gráĮcamente el rendimiento antes y durante la conexión VPN establecida. En el

servidor, el
software se llama Monitor de conĮabilidad y rendimiento y viene integrado al sistema operativo.
En la Figura 4.6 se puede observar el rendimiento de la CPU y consumo de memoria al momento

de
establecerse la conexión entrante del primer usuario al servidor VPN.
Para evaluar la comunicación se realizaron varios experimentos, aunque para poder comprobar el
rendimiento y comportamiento de la VPN en un entorno de conexión real, se necesitan muchas

conexiones
simultáneas de las que no se dispone, por lo que se realizarán las evaluaciones con una sola
conexión activa.
La distancia entre los hosts no supera los 5 saltos (obtenidos mediante el comando tracert) .
Además
el horario en el que se realizan dichas pruebas tiene gran inŇuencia en el rendimiento, por lo que
se ha
optado por una franja horaria de testeo entre las 9 y 10 de la maȂnana.
4.4.1 . Escritorio virtual
Una de las aplicaciones utilizadas para la conexión a un escritorio remoto y tener control total del
equipo es UltraVNC.
El sistema de escritorio compartido VNC (Virtual Network Computing) fue desarrollado

inicialmente
por AT&T para la gestión de escritorio remotos. Por su parte microsoft ha desarrollado su propio
sistema
de administración de escritorio remoto, pero para estas pruebas, se ha utilizado UltraVNC , que es
software
libre y sirve para el mismo propósito. VNC utiliza el protocolo RFB (Remote Framebuīer) para
traer la
interfaz gráĮca del servidor al cliente, de manera que se visualice en pantalla lo que esta viendo el
otro.
Figura 4.6: Rendimiento del sistema (con el servicio de VPN)
UltraVNC tiene dos modos de ejecución, el modo cliente y el modo servidor. En el modo servidor
se
establece una contraseȂna de tipo pre compartida, que es necesaria para establecer la conexión.
Además,
en el servidor se deĮnen los parámetros tales como interfaz de ͞escucha͟ , puertos, posibilidad de
usar
el navegador mediante el plugin de Java, entre otras opciones más. El cliente, por su parte solo
permite
elegir la velocidad de conexión (además de la dirección IP) . Cuanto mayor es la velocidad de
conexión,
se incluyen más detalles y cantidad de colores del escritorio remoto.
En la Figura 4.7 se muestra una sesión de UltraVNC a una velocidad de conexión media (unos 20
Kbytes por segundo) , por lo que no se obtienen todas las caracter´ısticas gráĮcas ni los colores
para una
imagen n´ıtida. Esto se debe a dos factores, uno es el ancho de banda de la conexión a Internet
establecida
por el proveedor de servicios (para la subida de datos que es de 256 Kbps) , y la otra por el mismo
retardo
y consumo de recursos del protocolo PPTP.
4.4.2. Transferencia de archivos
Para la transferencia de archivos usando los sistemas Windows como se han descripto
anteriormente,
se procede de la manera tradicional, como si de una red local se tratara, es decir, compartiendo
archivos
mediante el protocolo SMB de Microsoft. La Figura 4.8 muestra la tasa de transferencia medida en
Bytes
por segundos de un archivo de música con compresión mpeg-layer3.
4.4.3. Registro de conexiones
Para realizar el registro de conexiones y veriĮcar que el tráĮco de información se realiza de forma
segura, se recurre a herramientas que monitorean el tráĮco de datos de una interfaz de red
determinada.
En el servidor y cliente se ha utilizado el software Wireshark antes y después de establecer la
conexión
y transferir datos, con una salida similar a la que se muestra en el Registro 1 .
Cuando se ha experimentado error en la conexión, como se puede observar en el Registro 2, se

debe
a la mala conĮguración de los Įrewall en ambos extremos, de manera que si el cliente se

conectaba al
servidor, este último no pod´ıa devolver el recibo de conexión al cliente, por lo que este nunca se
enteraba
si el servidor hab´ıa aceptado su petición.
También se puede observar que si no se utilizara PPTP para transferir la información, y en alguno
de los casos se env´ıa texto plano, el programa Wireshark mostrar´ıa el texto tal cual, aunque sea
una
contraseȂna o número de tarjeta de crédito. Por esto la importancia de utilizar PPTP a la hora de
enviar
información sensible, de forma rápida y segura entre dos equipos.
4.5. Conclusión
PPTP es un protocolo que lleva muchos aȂnos funcionando en sistemas Windows, y debido a la
gran
cantidad de usuarios que realizaron pruebas de seguridad y rendimiento, han terminado por
decantar
poco a poco su utilización en entornos de producción. Aún as´ı, se sigue utilizando en gran
medida para
conexiones simples de tipo host a red (entre equipos hogareȂnos principalmente) , y hasta ha sido
portado
a sistemas libres (o de código abierto) para su interacción con múltiples plataformas.
Esto reŇeja que, a pesar de todos los problemas de seguridad que ten´ıa el protocolo en la primera
versión (que han sido solucionados parcialmente en la segunda versión) , todav´ıa existe una gran
cantidad
de usuarios móviles que se conectan a la red corporativa por PPTP mediante servidoresWindows,
Linux,
BSD, Solaris, entre otros, sin importar la plataforma.
Por esta razón es que el protocolo deb´ıa ser probado y conĮgurado para ambos sistemas,
concluyendo
Source Destination Protocol Info
200. 45. 35. 51 192. 168. 0. 35 TCP scanstat-1 > pptp [SYN] Seq=0 Win=65535 Len=0 MSS=1440
192. 168. 0. 35 200. 45. 35. 51 TCP pptp > scanstat-1 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0
MSS=1460
200. 45. 35. 51 192. 168. 0. 35 PPTP Start-Control-Connection-Request
192. 168. 0. 35 200. 45. 35. 51 PPTP Start-Control-Connection-Reply
200. 45. 35. 51 192. 168. 0. 35 PPTP Outgoing-Call-Request
192. 168. 0. 35 200. 45. 35. 51 PPTP Outgoing-Call-Reply
200. 45. 35. 51 192. 168. 0. 35 PPTP Set-Link-Info
200. 45. 35. 51 192. 168. 0. 35 PPP LCP Configuration Request
192. 168. 0. 35 200. 45. 35. 51 PPP LCP Configuration Ack
200. 45. 35. 51 192. 168. 0. 35 PPP LCP Configuration Rej ect
200. 45. 35. 51 192. 168. 0. 35 PPP LCP Configuration Ack
200. 45. 35. 51 192. 168. 0. 35 PPP LCP Identification
192. 168. 0. 35 200. 45. 35. 51 PPP CHAP Challenge (NAME=͛ NIPPUR͛ , VALUE=0x515E1AE701 . . . )
200. 45. 35. 51 192. 168. 0. 35 PPP CHAP Response (NAME=͛ remoto͛ , VALUE=0xDFA67872B6F . . .
)
192. 168. 0. 35 200. 45. 35. 51 GRE Encapsulated PPP
192. 168. 0. 35 200. 45. 35. 51 TCP pptp > scanstat-1 [ACK] Seq=213 Ack=373 Win=64584 Len=0
192. 168. 0. 35 200. 45. 35. 51 PPP CHAP Success (MESSAGE=͛

S=817B882E753E7CC2732C41D78E34FAD05D59C59B͛ )
192. 168. 0. 35 200. 45. 35. 51 PPP CBCP Callback Request
200. 45. 35. 51 192. 168. 0. 35 PPP CBCP Callback Response
192. 168. 0. 35 200. 45. 35. 51 PPP CBCP Callback Ack
200. 45. 35. 51 192. 168. 0. 35 PPP CCP Configuration Request

200. 45. 35. 51 192. 168. 0. 35 PPP IPCP Configuration Request
192. 168. 0. 35 200. 45. 35. 51 PPP CCP Configuration Request
192. 168. 0. 35 200. 45. 35. 51 PPP IPCP Configuration Request
200. 45. 35. 51 192. 168. 0. 35 PPP Comp Compressed data
...
Registro 1 : Establecimiento de la conexión host a host.
que lo más dif´ıcil de esta implementación ha sido la conĮguración del Įrewall de la red local y
del
establecimiento de un ruteo adecuado.
La pol´ıtica de seguridad para los usuarios móviles es hoy en d´ıa un tema de gran importancia, ya
que se debe evitar que al extraviar el equipo personal, la red corporativa se vea comprometida.
Esto se
soluciona con el uso de usuarios y contraseȂnas no almacenados en el sistema y evitar tener

certiĮcados
que se auto conecten al servidor de la empresa. Aún as´ı, este es un apartado importante para
tener en
cuenta cuando se crean las pol´ıticas de seguridad y la infraestructura de la red.
Finalmente se puede recalcar que PPTP se va a seguir usando por mucho tiempo más, debido
al soporte que existe en varias plataformas y a la gran cantidad de usuarios que tiene, como se ha
mencionado anteriormente. Además, los equipos portátil vienen con sistemas Windows que
tienen por
defecto implementado el protocolo PPTP, lo hacen ideal para las empresas con empleados que via
jan con
frecuencia, ya que no requieren de instalar ningún software adicional.
Source Destination Protocol Info

192. 168. 0. 35 200. 45. 153. 14 TCP 62944 > pptp [SYN] Seq=0 Win=8192 Len=0 MSS=1460
200. 45. 153. 14 192. 168. 0. 35 TCP pptp > 62944 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0
MSS=1440
192. 168. 0. 35 200. 45. 153. 14 TCP 62944 > pptp [ACK] Seq=1 Ack=1 Win=64800 Len=0
192. 168. 0. 35 200. 45. 153. 14 PPTP Start-Control-Connection-Request
200. 45. 153. 14 192. 168. 0. 35 PPTP Start-Control-Connection-Reply
192. 168. 0. 35 200. 45. 153. 14 PPTP Outgoing-Call-Request
200. 45. 153. 14 192. 168. 0. 35 PPTP Outgoing-Call-Reply
200. 45. 153. 14 192. 168. 0. 35 TCP pptp > 62944 [ACK] Seq=189 Ack=349 Win=65187 Len=0
192. 168. 0. 35 200. 45. 153. 14 PPTP Call-Clear-Request
192. 168. 0. 35 200. 45. 153. 14 PPTP [TCP Retransmission] Call-Clear-Request
...
Registro 2: Error al establecer una conexión.
Cap´ıtulo 5
VPN usando PPP sobre SSH
En este cap´ıtulo se describirá un modo de establecer una VPN entre dos redes distantes de forma
segura. Para esto se utiliza el protocolo PPP y la herramienta SSH, de las cuales se darán una
breve
introducción teórica.
Además se detallarán los procesos de creación y distribución de las claves utilizadas para
ingresar en
el sistema mediante SSH, la conĮguración de ruteo y del Įrewall de cada red.

5.1 . Protocolo PPP
El protocolo PPP (Point to Point Protocol) permite establecer una comunicación a nivel de enlace
entre dos computadoras. Utilizado comúnmente para establecer la conexión a Internet de un

particular con
su proveedor de acceso a través de un módem telefónico. También utilizado sobre conexiones

de banda
ancha (como PPPoE o PPPoA) . Además del simple transporte de datos, PPP facilita dos funciones
importantes:
Autenticación. Generalmente mediante una clave de acceso (que en nuestro caso no será
necesario) .
Asignación dinámica de IP. Los proveedores de acceso cuentan con un número limitado de
direcciones IP y cuentan con más clientes que direcciones. Naturalmente, no todos los clientes
se conectan al mismo tiempo. As´ı, es posible asignar una dirección IP a cada cliente en el
momento
en que se conectan al proveedor. La dirección IP se conserva hasta que termina la conexión por
PPP. Posteriormente, puede ser asignada a otro cliente.
PPP soporta, entre otros, los tipos de autenticación PAP y CHAP. La primera, es la más insegura,
ya
que env´ıa nuestro usuario y contraseȂna en texto claro a través de la red; la segunda encripta
estos datos,
para que no puedan ser le´ıdos.
Una gran desventa ja de este protocolo, es que no proporciona cifrado de datos, por lo que todo el
Ňujo de información de una conexión PPP es enviada en claro, de modo que si alguien está
capturando
los paquetes transmitidos, puede leer toda la carga que se env´ıa y recibe, teniendo acceso a
nuestra
información privada.
5.2. Protocolo y aplicación SSH
SSH (Secure SHell) o int érprete de comandos seguro es el nombre de un protocolo y el programa
que lo implementa. Sirve para acceder a máquinas remotas a través de una red. Permite manejar
por
completo la computadora mediante un intérprete de comandos, y también puede redirigir el

tráĮco de X
para poder ejecutar programas gráĮcos si se tiene un Servidor X1 .
Además de la conexión a otras máquinas, SSH permite copiar datos de forma segura (tanto
archivos
sueltos como simular sesiones FTP cifradas) , gestionar claves RSA para no escribir claves al
conectar a
las máquinas y pasar los datos de cualquier otra aplicación por un canal seguro tunelizado
mediante SSH.
1Sistema gráĮco utilizado en sistemas Unix
La primera versión del protocolo y el programa eran libres, pero su licencia fue cambiando y
terminó apareciendo la compaȂn´ıa SSH Communications Security, que lo ofrec´ıa gratuitamente

para uso
doméstico y académico, pero exig´ıa el pago a otras empresas.
La implementación libre por excelencia, llamada OpenSSH, es la que se va a utilizar en este

proyecto;
debido a que -según sus desarrolladores (los mismos que desarrollaron OpenBSD) - es más
segura que la
original.
5.2.1 . Seguridad
SSH traba ja de forma similar a como se hace con telnet . La diferencia principal es que SSH usa
técnicas de cifrado que hacen que la información que via ja por el medio de comunicación vaya
de manera
no legible y ninguna tercera persona pueda descubrir el usuario y contraseȂna de la conexión ni lo

que se
escribe durante toda la sesión.
5.3. Descripción General de la VPN

La topolog´ıa seleccionada para esta implementación, es de red a red; esto nos permite hacer que
las
redes locales involucradas tengan la impresión de que están unidas simplemente por un router,
mientras
que en realidad, puede que se encuentren a kilómetros de distancia. La Figura 5.1 muestra las dos
redes,
y la VPN establecida entre ellas.
En cada una de las subredes hay un solo punto de entrada/salida a Internet , donde se implementa
el
Įrewall. Detrás de este se encuentra toda la red local, y el Servidor VPN, que puede deĮnir sus
propias
reglas de Įltrado de paquetes para sus conexiones.
Todo el Ňujo de datos que se dirige a Internet, va directo por la puerta de enlace; los paquetes que
pertenecen a la conexión VPN, se dirigen primero al servidor VPN, para luego salir por la puerta
de
enlace.
En la realidad, para este modo de establecer una VPN, no se utiliza ningún protocolo espec´ıĮco
para
redes privadas virtuales. A lo que se denomina servidor VPN, y cliente VPN ʹen este casoʹ, en
realidad
ser´ıan el servidor SSH y el cliente SSH, ya que este es el protocolo que establece la conexión
entre ambos
puntos.
Los servidores VPN se implementan sobre GNU/Linux Ubuntu Server 8.04. Para saber más
detalles
sobre las redes que se utilizaron para las pruebas, véase el Apéndice A.
5.4. Funcionamiento
El servidor VPN (ubicado en la red casa.lan) , espera conexiones SSH en un p uerto distinto al 22 ʹ
que
es el estándar para este protocoloʹ, tomado para evitar que se mezclen los paquetes SSH de las
Shells
estándar, con los de las conexiones VPN; esto, a Įnes de un mayor control sobre quién se
conecta a la
red local.
Debido a que este servidor se encuentra detrás del Įrewall/puerta de enlace, se debe hacer una
redirección hacia dicho servidor, de todos los paquetes que quieran entrar o salir por el puerto en
el que
se están escuchando las conexiones VPN.
Por su parte, el cliente (ubicado en la red red.lan) que desea efectuar una conexión VPN, debe
utilizar
los protocolos ppp y ssh, para lograrlo.
En la puerta de enlace de la red cliente, no es necesario hacer ningún cambio adicional (a nivel de
reglas de Įrewall, redireccionamiento o nat) para que funcione esta VPN.
Cuando se establece la conexión, en ambos servidores se crea una nueva interfaz, por ejemplo
ppp0,
a través de la cual se env´ıa y recibe el Ňujo de datos de la red contraria. A esta interfaz se asocia
una
dirección IP ; para esto se ha elegido 192. 168. 254. 1 para el servidor, 192. 168. 254. 2 para el
cliente. La
máscara de subred de estas direcciones es 255. 255. 255. 255 , por lo que pueden crearse cuantos
pares de
direcciones se deseen para distintas VPN, siempre que no haya solapamiento.
Vale aclarar, que las denominaciones cliente y servidor VPN, cobran sentido solo para el
establecimiento de la conexión, ya que solo el cliente puede solicitarlo. Cuando la conexión está
establecida, los datos pueden requerirse indistintamente de una red, como de la otra; no existe
jerarqu´ıa entre ellos.
Es por este motivo se llama servidor VPN también al cliente.

El enrutamiento
El establecimiento de las rutas, luego de la conexión, es importante para que las redes puedan
traĮcar datos entre ellas; de otro modo, por más que la conexión esté establecida, no podrán
compartir
información.
Hay más de una forma de deĮnir las rutas entre las redes, pero no todas permiten que la VPN sea
transparente, ya que requieren modiĮcaciones en los terminales de usuarios. En este caso se

requiere que
en los hosts internos no tengan que agregar o quitar nada para que la conexión VPN funcione, por
lo
tanto, se establecen las rutas solo en el servidor VPN y en la puerta de enlace. Esta situación se ve
reŇejada en la Figura 5.1 .
Suponiendo que la puerta de enlace predeterminada en casa.lan tiene la dirección 192. 168. 1. 2 y
el Servidor VPN 192. 168. 1. 3. Del otro lado, en red.lan, el gateway por defecto tiene la dirección
192. 168. 0. 1 y el servidor VPN 192. 168. 0. 2 .
De esta manera se pretende que los hosts de las redes se vean entre s´ı, es decir, que cuando el
nodo
192. 168. 0. 20 quiera conectarse con 192. 168. 1. 7 (aunque estén en redes diferentes) pueda
hacerlo sin
modiĮcación alguna de sus rutas. Por esto, se debe establecer en la puerta de enlace de casa.lan
que
cuando llegue un paquete dirigido a la red 192. 168. 0. 0/24 lo env´ıe al servidor VPN local, ya que
este
conoce la ruta. Se puede hacer mediante el siguiente comando (como superusuario) :
# route add 192. 168. 0. 0/24 192. 168. 1. 3
La puerta de enlace enviará al servidor VPN todos los paquetes que tienen como destino la red
contraria, por lo tanto, se debe especiĮcar por dónde deberán llegar a la misma. Cuando se ha
establecido
la conexión VPN, se ha creado en cada servidor, una nueva interfaz llamada ppp0, asociada a una
dirección
IP. Esta interfaz es la que comunica una red con la otra a través del túnel SSH, y en la red casa.lan
tiene
la dirección 192. 168. 254. 1 . Con la siguiente l´ınea todos los paquetes que llegue al servidor con
destino
la red 192. 168. 0. 0/24 se enviarán por la interfaz ppp0 a dicha red.
# rout e add - ne t 1 9 2 . 1 6 8 . 0 . 0 / 24 gw 1 9 2 . 1 68 . 2 5 4 . 1
Ahora en red.lan, se debe hacer lo mismo, es decir, en el gateway por defecto se agrega la
dirección
del servidor VPN:
# rout e add 1 9 2 . 1 6 8 . 1 . 0/ 2 4 1 9 2 . 1 68 . 0 . 2
Y luego la ruta que lleva a la otra red por la interfaz ppp0:
# rout e add - ne t 1 9 2 . 1 6 8 . 1 . 0 / 24 gw 1 9 2 . 1 68 . 2 5 4 . 2
Nótese que la sintaxis del comando ͞route͟ var´ıa entre las puertas de enlace y en los servidores
VPN,
esto se debe a que poseen sistemas operativos distintos: OpenBSD y GNU/Linux respectivamente.
En
cada caso, ver la página del manual para más información [4] .
5.4.1 . Env´ıo y recepción de paquetes
Si se tiene una VPN establecida entre el cliente y el servidor mencionados anteriormente, y ahora
el
host 192. 168. 0. 20 de la red red.lan desea probar si el host 192. 168. 1. 7 se encuentra activo, se
ejecuta
el comando ping 192. 168. 1. 7, que env´ıa paquetes ICMP Echo Request al destino especiĮcado, y
este último responderá con paquetes ICMP Echo Replay para notiĮcar al origen positivamente.
El host 192. 168. 0. 20 tiene conĮgurado en su tabla de ruteo solamente el gateway por defecto,
por
lo que al ejecutar el comando ping 192. 168. 1. 7 y no encontrar en la tabla una ruta directa hacia
la red
192. 168. 1. 0/24 (o a dicho host) , env´ıa los paquetes por la ruta predeterminada.
Esta ruta predeterminada es la puerta de enlace al mundo exterior, la que deberá conocer el
camino
hacia la red 192. 168. 1. 0/24, y que no es precisamente enviando los paquetes a través de
Internet ʹya
que son direcciones de una red privada ʹ, sino enviándolos al servidor VPN. Por lo tanto, el
gateway por
defecto debe tener expl´ıcitamente una ruta hacia el la red contraria.
Cuando los paquetes ICMP Echo Request enviados por el host 192. 168. 0. 20 llegan al servidor
VPN
de la red, este conoce el camino hacia la otra red: a través de la interfaz ppp0 mencionada
anteriormente,
y que es el enlace PPP encapsulado en la conexión SSH.

Por lo tanto, lo que el servidor hace, es aȂnadir a los paquetes ICMP Echo Request las
correspondientes
cabeceras PPP (que son de nivel de enlace de datos) , donde se encuentra la dirección IP destino
(asociada
con la interfaz ppp0) .
Estas tramas PPP son encapsuladas en paquetes SSH, cuya dirección origen es el servidor VPN (la
dirección local) , y dirección destino la dirección pública de la red donde se encuentra el

servidor VPN
destino.
Cuando los paquetes llegan a la puerta de enlace de la red destino, este los env´ıa al servidor VPN
local, analiza el contenido y lo env´ıa al host destino.
Para que la VPN sea realmente transparente a los usuarios Įnales de cada red, el encaminamiento
es
un punto muy importante. En la Figura 5.2 se muestra el diagrama de red que los hosts percibirán
luego
de establecer la conexión VPN.
El esquema de direcciones de red.lan es 192. 168. 0. 0/24 y el de casa.lan es 192. 168. 1. 0/24; a
partir
de la Figura 5.2, si el usuario 192. 168. 0. 20 ejecuta el comando ping 192. 168. 1. 7 ʹy los caminos
en el router están bien conĮgurados ʹ, el host 192. 168. 0. 20 deber´ıa recibir la respuesta de sus
ICMP ECHO
REQUESTs del host solicitado.

5.5. ConĮguración del Servidor VPN
Es importante ser cauteloso a la hora de conĮgurar un servicio que se brindará hacia afuera, ya
que
no hay que dejar huecos o puertas traseras que puedan ser utilizadas para introducirse en el
sistema local,
y poner en riesgo a toda red.
La venta ja de utilizar como servidor VPN un sistema derivado de Unix ʹGNU/Linux en este caso ʹ
es
que son muy Ňexibles en lo que se reĮere a conĮguración de seguridad, y están (desde su
concepción)
dotados de varias capas de seguridad, y preparados para funcionar como verdaderos servidores.
En esta sección se describirá cómo poner a punto el servidor VPN, con un grado de seguridad
más
elevado.
5.5.1 . Directivas de Įrewall
Como se ha mencionado anteriormente, el servidor VPN escuchará las conexiones SSH que
ingresen
por el puerto 9876. Pero debido a que dicho servidor se encuentra detrás del Įrewall, esta
escucha se
limita a la red local. Para que se pueda escuchar incluso las conexiones que provengan desde
internet , se
debe redireccionar en el Įrewall a dicho puerto.
Esto se logra agregando una l´ınea en el archivo de conĮguración del Įrewall, como se muestra en
la
ConĮguración 13.
ConĮguración 13 L´ıneas en el archivo /etc/pf. conf
1 rdr pas s on $ e xt _ i f pro t o t cp f rom any to any port 9876 -> $ s e rve r_ vpn
De la ConĮguración 13, $ext if es la interfaz conectada al proveedor de internet, y $server vpn es
deĮne la dirección IP de dicho servdidor.

Para refrescar las directivas del Packet Filter sin tener que reiniciar el equipo se ejecuta el
siguiente
comando:
$ sudo pf c t l - f / e t c / pf . conf
Para que se accione cada vez que se inicia el equipo, se debe agregar la siguiente l´ınea en el
archivo
/etc/sysctl. conf :
net. ipv4. ip_forward=1
5.5.3. Creando un nuevo usuario
Cuando el cliente VPN2 intenta establecer la conexión, debe conectarse a través de SSH al
servidor
VPN y levantar el demonio PPPD ; para estos Įnes es que se crea un nuevo usuario del lado del
servidor.
Este usuario estará restringido en casi todo aspecto.
2El servidor VPN que actúa como cliente al momento de la conexión
Antes de crear el usuario, se crea un grupo para el mismo de igual nombre:
$ sudo addgr oup s s hvpn
$ sudo addus e r -- home / home / s s hvpn -- i ngroup s shvpn -- di sabl ed - l ogin s shvpn
Nótese que ambas l´ıneas comienzan con sudo, este comando se utiliza para que un usuario que
no posee
privilegios de administrador, pero si permiso para ejecutar comandos que requieren estos
privilegios, a
través de este programa, pueda hacerlo. Por ejemplo, los comandos addgroup y adduser solo
pueden ser
ejecutados por el usuario administrador, y por quienes hayan sido autorizados para hacerlo a
través del
comando sudo. (Ver más detalles en [4] ) .

La primera l´ınea, sencillamente lo que hace es aȂnadir un nuevo grupo al sistema, llamado
sshvpn.
La segunda l´ınea aȂnade nuestro usuario. Este tendrá como directorio de traba jo /home/sshvpn
; como
grupo sshvpn ; no podrá ser accedido directamente como una cuenta local, por lo que no
poseerá password
(ʹdisabled-login) , y su nombre será sshvpn.
5.5.4. ConĮguración de sudo
El nuevo usuario del servidor, debe ser capaz de levantar el demonio pppd, a Įnes de establecer la
conexión. Como los demonios solo pueden ser ejecutados por el administrador, se deben dar
permiso a
nuestro usuario para que lo haga a través del programa sudo, sin darle permisos de superusuario.
Para
modiĮcar la conĮguración del sudo, debe editarse el archivo /etc/sudoers (más detalles en [4] ) ,
con el
programa visudo , y se agrega la l´ınea:
sshvpn ALL=NOPASSWD: /usr/sbin/pppd
Luego el usuario sshvpn ya tiene permisos para ejecutar el demonio pppd, y sin necesidad de
introducir
una contraseȂna. Esto es importante ya que se pretende que la conexión se establezca

automáticamente
por s´ı misma, con la menor (o nula) intervención posible de una persona. En Linux, el demonio
pppd
está ubicado en /usr/sbin, pero esto puede variar en otras distribuciones.
Cabe aclarar que el hecho de que sshvpn tenga la posibilidad de levantar un demonio sin ser
administrador, no va en desmedro de la seguridad, lo cual será aclarado a medida que se vayan

analizando
la conĮguraciones.
5.5.5. Aceptando conexiones SSH provenientes del cliente

El protocolo SSH tiene la posibilidad de establecer conexiones entre hosts sin necesidad de
introducir
contraseȂnas de modo interactivo, gracias a un sistema de claves que permite al servidor

reconocer de
forma un´ıvoca al cliente.
En este se deben generar un par de claves a simétricas RSA (véase Sección 5.6.2) , la clave
privada
permanece en el cliente, y la clave pública la debemos llevar al servidor VPN. Supongamos que
nuestra
clave pública está en un archivo llamado id rsa key cliente.pub.
Ahora debemos permitir las conexiones a través de SSH para el usuario sshvpn, de la siguiente
forma:
# cd / home / s s hvpn
# mkdi r . s sh /
# cd . s sh/
# mv / cami no / a/ i d_r s a_ke y_ c l i e nt e . pub .
# cat i d_ r s a_ke y_ c l i e nt e . pub >> aut ho r i z e d_keys
El archivo /home/sshvpn/.ssh/authorized keys contiene todas las claves públicas de los distintos
clientes que están permitidos ingresar al sistema como este usuario. Luego de esto, el cliente
podrá ingresar
al servidor VPN, sin necesidad de contraseȂna, únicamente con el comando ssh

el.servidor.com.ar.
5.5.6. Lanzando un nuevo demonio SSH
Como se ha mencionado anteriormente, no se va a utilizar el mismo puerto para conectar las

shells
SSH y la VPN. Por lo tanto se ejecutará otro demonio SSH, conĮgurado para que escuche en un
puerto
espec´ıĮco, y para que solo sean aceptados los que desean establecer una VPN.
Nótese que esta es una de las capas de seguridad. Se esta denegando el acceso por el puerto
determinado
a los usuarios que no tienen permisos para establecer una conexión VPN.
sshd al ejecutarse, lee un archivo de conĮguración generalmente /etc/ssh/sshd config. Como
no se pretende modiĮcar las opciones del demonio que escucha por el puerto 22, no se modiĮca
ese
archivo. Se Crea un nuevo archivo de conĮguración y se lo ubica en /home/sshvpn/etc/ , con el

nombre
sshppp config, que se muestra en la ConĮguración 1 .
Detalle 1 Archivo /home/sshvpn/etc/sshppp conĮg.
1 Pi dF i l e / var / run / s shvpn . pid
2 Port 9876
3 Pro t o c o l 2
5 Ho s t Key / e t c / s sh / s s h_ ho s t _ rs a_ ke y
6 Ho s t Key / e t c / s sh / s s h_ ho s t _ ds a_ ke y
8 # Pri vi l e ge S e parat i on i s t urned on f or s e curi t y
9 Us e Pri vi l e ge S e parat i on yes
10
11 # L i f e t i me and s i ze of e pheme ral ve rs i on 1 s e rve r key
12 Ke yRe ge ne rat i onI nt e rval 3600
13 S e rve rKe yBi t s 768
14
15 # Loggi ng
16 Sys l ogFac i l i t y AUTH
17 LogLeve l I NFO
18
19 # Aut hent i c at i o n :
20 Lo gi nGrac e Ti me 1 20
21 Pe rmi t Ro o t L ogi n no
22 S t ri c t Mo de s yes
23
24 RS AAut he nt i cat i on ye s
25 Pubke yAut hent i cat i on ye s
26
27 Al l o wUs e rs s s hvpn
28
29 # Aut ho ri z e dKe ys Fi l e %h/ . s sh/ aut ho ri z ed_ke ys
30 I gno reRho s t s ye s
31 Rho s t s RS AAut hent i c at i on no
32 Ho s t bas e dAut hent i c at i on no
33 P e rmi t Empt yPas s wo rds no
34 Chal l e nge Re s pons e Aut he nt i c at i on no
35 Pas s wo rdAut he nt i c at i on yes
36
37 X1 1 Fo rwardi ng no
38 X1 1 D i s p layO f f s e t 1 0
39 Pri nt Mo t d no
40 Pri nt Las t Log ye s
41 TCPKe e pAl i ve ye s
42
43 Subs ys t em s f t p / usr / l ib / o pens s h / s f tp - s e rve r

44 Us e PAM ye s
Lo más importante que se puede destacar de 1 , son las primeras opciones en la que el archivo
PID
del demonio será /var/run/sshvpn. pid. El puerto en el que escuchará es el 9876 y el protocolo
SSH
utilizado es la versión 2.
También es importante notar la opción AllowUsers sshvpn. Esto permite que solo pueda ingresar
por
este puerto el usuario sshvpn, y ningún otro.
Todas las demás opciones son restricciones de seguridad para evitar ingresos no deseados; a
estas se
las puede encontrar en la página del manual del archivo en [4] .
Para lanzar el demonio, solo basta ejecutar como superusuario el comando:
# / s bin / s shd - f / home / s s hvpn / e t c / s s hppp_ c onf i g
5.6. ConĮguración del Cliente VPN
En esta sección se detallan los pasos necesarios para conĮgurar el extremo cliente de una
conexión
PPP y SSH. Lo parámetros van desde la creación del usuario único permitido para conectarse con
el
servidor, hasta la deĮnición de los alias de red, pasando por la generación de claves RSA y una
muestra
de la conexión realizada.
5.6.1 . Creando un nuevo usuario
En el cliente VPN también se crea un usuario que será el encargado de establecer la conexión
VPN
con el servidor, y a efectos de simplicidad, este usuario tendrá el mismo nombre que el usuario
creado en
el servidor.
Antes de crear el usuario, se crea un grupo con el mismo nombre de la siguiente manera:
$ sudo addgr oup s s hvpn
$ sudo addus e r -- home / home / s s hvpn -- i ngroup s shvpn s s hvpn
$ sudo pas swd s s hvpn
Esto es similar a lo que se hace en el servidor (Sección 5.5.3) . La diferencia es que aqu´ı es
necesario
acceder al usuario sshvpn, por lo que se omite la opción --disable-login en la creación del usuario.
Con el comando passwd sshvpn se establece una contraseȂna para poder ingresar como usuario
sshvpn.
5.6.2. Generando las claves RSA
Ahora es necesario generar el par de claves pública/privada en el cliente; guardar la privada y

pasar al
servidor la clave pública para poder acceder a él sin necesidad de contraseȂna. Esto se hace de la
siguiente
forma:
# su - s s hvpn
# mkdi r . s sh /
# cd . s sh/
# ssh - ke ygen - t rsa -N ͛ ͛
Primero se debe cambiar al usuario sshvpn (con el comando ͞su - sshvpn͟ ) ; luego en el directorio
. ssh
se generan las claves con el comando ssh-keygen. Los archivos generados son id rsa (la clave
privada que
se guarda en el cliente) e id rsa. pub (la clave pública que se env´ıa al servidor, véase Sección
5.5.5) . Para
enviarla, se escribe lo siguiente (utilizando SCP (Secure Copy) ) :
# s cp . / i d_rs a . pub s s hvpn@e l . s e rvi dor . com . ar : / home / s shvpn / . s sh / i d_ rs a_ke y_

c l i e nt e . pub
5.6.3. ConĮguración de sudo

Como este paso se realiza de la misma manera que en 5.5.4) , solamente se mostrará la l´ınea que
se
debe agregar con visudo :
sshvpn ALL=NOPASSWD: /usr/sbin/pppd
En el cliente también es necesario que el usuario sshvpn pueda levantar el demonio pppd, para
que se
pueda establecer las conexión.
5.6.4. Conectando al Servidor
La conexión al servidor se efectúa desde el cliente con una simple l´ınea ejecutada como el nuevo
usuario sshvpn que se a creado anteriormente. El comando es el siguiente 3 :
sudo /usr/sbin/pppd updetach noauth pty "sudo -u sshvpn ssh -p 9876 -t -t servidor \
sudo /usr/sbin/pppd noauth 192. 168. 254. 1: 192. 168. 254. 2"
Como sshvpn debe ejecutar el demonio pppd a través del comando sudo, se ejecuta dicho
demonio
con las siguientes opciones:
updetach : Desvincula a pppd de la terminal donde se lo ejecuta, para que pueda seguir usándose
dicha terminal.
noauth : Como en este caso la autenticación está a cargo del protocolo SSH, no se necesita
autenticar
al momento de conectar pppd.
pty ͞. . .͟ : Ejecuta el comando encerrado entre comillas antes de conectarse.
Luego se ejecuta el pppd local, antes de proceder a conectarse. Debido a que el primer pppd se
ejecuta
con sudo, el comando ssh dentro de pty ͞. . .͟ , también se ejecutar´ıa con permisos del usuario
raiz, y por
lo tanto buscar´ıa el archivo authorized keys en el directorio . ssh/ del directorio de root.
Como se requiere que busque el directorio de sshvpn, lo que se hace es ejecutar el ssh como
sshvpn
mediante el comando: sudo -u sshvpn.
A ssh se le pasan los siguientes parámetros:
-p 9876 : EspeciĮca el puerto del servidor al que debe intentar conectarse.
-t -t: Obliga al otro extremo alo jar en una tty (terminal del sistema) al comando que se ejecuta.
Esto es necesario para ejecutar pppd.
servidor: Es el nombre de dominio del servidor al cual se va a conectar.
sudo /usr/sbin/pppd noauth 192.168.254.1:192.168.254.2 : Esta l´ınea se ejecuta en el servidor a
través de ssh. Lo que hace es levantar el demonio pppd en el servidor, con la opción noauth, y
otorgándole como parámetros las direcciones IP que utilizarán el cliente y el servidor.
5.6.5. Creando un alias para la VPN
Con el ob jeto de simpliĮcar un poco las cosas para el cliente, ssh permite crear aliases para
distintas
conexiones; esto es, asociar a un nombre fácil de recordar, un nombre de dominio, puerto,
usuario, etcétera.
El archivo que permite esto es . ssh/config del directorio personal de sshvpn, cuyo contenido se
muestra en la ConĮguración 14.
ConĮguración 14 Archivo /home/sshvpn/ .ssh/conĮg
1 # Es t e archi vo se encuent ra en ~ s shvpn / . s sh/
2#
3 # UN ALI AS para la VPN s sh+ ppp con el domini o ni c o las f o rmo s o . com . ar
4 Ho s t vpn_ s shppp
5 Ho s t name ni c o las f o rmo s o . com . ar
6 Us er s shvpn
7 Port 9876
8 I dent i t yFi l e ~ / . ssh/ id_ rsa
A partir de ahora, cuando se escriba ssh vpn sshppp, se establecerá una conexión SSH con el
dominio
nicolasformoso.com.ar, por el puerto 9876 y con el usuario sshvpn. En este archivo pueden
deĮnirse tantos
aliases como se necesiten, en forma secuencial.
3La barra invertida (\)en el comando indica corte de l´ınea
5.7. AȂnadiendo seguridad a la VPN
En esta sección se mostrarán consejos simples que hacen a la conexión VPN un poco más
segura,
ya sea restringiendo el acceso al servidor SSH, como limitando el uso de ciertos comandos que no
son
necesarios para establecer la conexión.
5.7.1 . Bloqueando la Shell de sshvpn
Como no se pretende que el usuario sshvpn tenga acceso al servidor a través de una shell, sino
que
solo pueda establecer la conexión VPN, se agrega antes de la clave pública lo siguiente:
command="sudo /usr/sbin/pppd noauth 192. 168. 254. 1: 192. 168. 254. 2"
De estamanera cuando sshvpn intente ingresar por el puerto 9876, lo único que podrá hacer es
ejecutar
pppd.
Ahora el comando para conectar con la VPN se simpliĮca, quedando:
$ sudo / usr / sbi n / pppd upde t ach noaut h pt y " sudo -u s shvpn ssh vpn_ s s hppp "
Donde vpn sshppp es el nombre del alias creado para la VPN en cuestión.
5.7.2. Restringiendo las claves
Si se tiene la posibilidad de conocer la dirección IP pública de la red donde se encuentra el cliente
VPN, restringir el uso de una clave pública para esa dirección IP anteponiendo a la clave, es una
buena
opción para evitar el inconveniente del robo de claves.
from="dirección ip del cliente"

5.7.3. Otras opciones
Para que no se pueda ingresar al servidor X, ni utilizar Agent Forwarding, se agrega a la clave:
no-X11-forwarding, no-agent-forwarding
-X11-forwarding, no-agent-forwarding
Existen otras opciones que también se pueden agregar en el archivo authorized keys que pueden
obtenerse de [4] ; todas ellas deben ir separadas por una coma entre s´ı, y por un espacio en
blanco de la
clave.
Luego que se haya aȂnadido a las opciones del archivo authorized keys , se muestra en la
ConĮguración
2.
Detalle 2 Archivo /home/sshvpn/ .ssh/authorized keys
1 c ommand =" sudo / usr / sbin / pppd noaut h 1 9 2 . 1 6 8 . 2 54 . 1 : 1 9 2 . 1 6 8 . 2 5 4 . 2 " , no -

X1 1 -
f orwarding , no - agent - f o rwarding ssh - rsa
AAAAB3NzaC 1 yc 2 EAAAAB I wAAAQ EAnpyZ 5 B i L j 5 Yb8 bW3 e L f 7CwGR . . . yRSvYf i I OdwHk

+
FFNp0 JkS t MEg4s hVMXQ == s s hvpn@no t e bo o k
5.8. Conclusión
Para establecer una red privada virtual utilizando el conjunto de protocolos PPP y SSH, se tiene
que
contar con una conĮguración muy bien detallada, porque sino se pueden generar agujeros de
seguridad
que implicar´ıan en accesos no autorizados a la red
Esta tecnolog´ıa se la utiliza para la topolog´ıa red a red de una VPN, y a pesar de que se puede
conĮgurar para múltiples clientes, su complej idad puede llegar a ser tan alta que se tendr´ıa que
buscar
alternativas. Por esta razón es que se realizan conexiones punto a punto, en donde un servidor y
cliente,
cuentan con sus propias redes privadas. La idea es conectar dichas redes utilizando protocolos
muy seguros
y probados.
La combinación de PPP y SSH permite utilizar los conceptos y archivos de conĮguración ya

conocidos
de estos servicios para luego juntarlos y tener una infraestructura de red segura y estable. La
diĮcultad
de su conĮguración y el tener en cuenta los detalles de seguridad en cuanto a las conexiones SSH
y el
puerto a utilizar, hacen que sea una opción algo complicada de llevar a la práctica.
Pero aún as´ı, con las rutas conĮguradas y los numerosos archivos involucrados, se puede tener
un
enlace red a red altamente seguro y en un tiempo razonable si ya se tiene experiencia previa.
Cap´ıtulo 6
VPN con IPSec
IPSec es un conjunto de protocolos que se ha extendido a grandes empresas y se ha vuelto casi un
estándar para su utilización con redes privadas virtuales. Además se han portado
implementaciones de
IPSec para casi todos los sistemas operativos, tales como OpenSWAN para Linux y KAME para los
sistemas BSD .
En este cap´ıtulo se describirán los conceptos teóricos de IPSec, los métodos de autenticación y
además
se mostrará la conĮguración de los archivos más importantes.
También se realizará el proceso de generación de certiĮcados digitales utilizando OpenSSL y la
distribución de los mismos. Finalmente se comprobará la conexión establecida y se realizarán

pruebas de
rendimiento y monitoreo de paquetes.
6.1 . ¿Qué es IPSec?
IPSec (Internet Protocol Security) es una extensión al protocolo IP que proporciona seguridad a IP
y a los protocolos de capas superiores. Fue desarrollado para el estándar IPv6 (Internet Protocol
versión
6) y después fue portado a IPv4 (Internet Protocol versión 4) . La arquitectura IPsec se describe
en las
RFC 24011 -2412, y se pueden conseguir copias traducidas al castellano de gran candidad de RFC
en [11 ] .
El conjunto de protocolos de IPSec opera en la capa de red (capa 3 del modelo OSI) y aȂnade
protección
a los paquetes IP. La Įgura 6.1 tomada de [13 ] , muestra una lista de protocolos y sus capas con
respecto
al modelo TCP/IP.
Los protocolos que emplea IPSec comunmente son AH (Authentication Header) y ESP
(Encapsulating
Security Payload) , que en conjunto sirven para asegurar autenticación, integridad, protección
contra
repetición y conĮdencialidad de la comunicación. Las funciones espec´ıĮcas para cada

caracter´ıstica son
las siguientes:
as siguientes:
Autenticación. VeriĮca la identidad del remitente de un paquete.
Protección de la integridad. Asegura que los datos no se han cambiado en el transcurso de la
comunicación.
Protección contra la repetición. Evita que un atacante pueda guardar paquetes cifrados y luego
repetir los mismos sin ser detectado; obteniendo as´ı, acceso al tráĮco encriptado.
ConĮdencialidad. Oculta la información que se esta transmitiendo con cifrado mediante claves
compartidas entre remitente y destinatario.
Estas caracter´ısticas se pueden obtener combinando ambos protocolos (ESP y/o AH) dependiendo
del nivel de seguridad que se requiere para la transferencia de datos. Por ejemplo, si se utiliza solo
AH se
obtienen las tres primeras caracter´ısticas pero no ofrece conĮdencialidad. En cambio ESP puede
proveer
de todas las caracter´ısticas.
1http://www.rfc-es.org/rfc/rfc2401-es.txt
Figura 6.1 : En este esquema se puede ver claramente el puesto en la pila que opera IPSec.
Otro protocolo que puede emplear IPSec para el transporte de información es IPCOMP (IP
Payload
Compression Protocol) , que permite comprimir los datos que se van a transferir para aprovechar
el
ancho de banda de la conexión. Vemos entonces que se pueden deĮnir diferentes modos para
transmitir
información utilizando uno o varios de los protocolos mencionados, cada uno con sus venta jas y
desventa jas:
Solo AH: Autenticación avanzada, integridad y antirrepetición.
Solo ESP : Autenticación (opcional) , integridad, antirrepetición y cifrado.
ESP y AH: Autenticación avanzada, integridad, antirrepetición y cifrado.
ESP e IPCOMP : Autenticación, integridad, antirrepetición, cifrado y compresión.
AH, ESP e IPCOMP : Autenticación avanzada, integridad, antirrepetición, cifrado y compresión.
Tal como se puede presentir, cuanto más tecnolog´ıas se utilizan, se obtiene una mejora de la
seguridad
en el tráĮco de información, pero esto lleva a una alta utilización de procesamiento para las
tareas de
cifrado y compresión principalmente. Por esta razón no siempre es conveniente utilizar todas las
opciones
juntas, sino las que se adecúan a nuestras necesidades.
6.1 .1 . Componentes de IPSec
Como se ha mencionado anteriormente, IPSec esta basado en varios protocolos. Estos se pueden
dividir en dos grupos según su función: los relacionados con la gestión de claves y los
relacionados con la
manipulación de los datos. La parte de gestión de claves esta comprendida por IKE que esta
basado
en los protocolos siguientes:
ISAKMP
Oakley Key Determination Protocol
En la manipulación de datos se encuentran los protocolos que permiten compresión, cifrado,
autenticación y manipulación de paquetes, que ya se han listado anteriormente (y aqu´ı

nuevamente) :
AH (Authentication Header)
ESP (Encapsulating Security Payload)
IPCOMP (IP Payload Compression Protocol)

Los protocolos de gestión de claves son los que realizan la negociación entre las partes y
almacenan
las claves. Además ayudan a establecer las SA de IPSec.
Por otro lado, los protocolos de manipulación de paquetes utilizan las SA para agregar
caracter´ısticas
de seguridad a los paquetes.
6.1 .2. Modos de transferencia
IPSec puede utilizar dos modos de transferencia, por lo que puede crear paquetes en dos formatos
soportados: transporte y túnel. De esta manera se puede proteger el datagrama IP completo o

sólo los
protocolos de capas superiores.
En modo túnel el datagrama IP se encapsula completamente dentro de un nuevo datagrama IP

que
emplea el protocolo IPsec. En modo transporte IPsec sólo maneja la carga del datagrama IP,
insertándose
la cabecera IPsec entre la cabecera IP y la cabecera del protocolo de capa superior. La Įgura 6.2
muestra
el diagrama de los diferentes modos.

En otras palabras, en el modo transporte, IPSec protege los paquetes, encriptando el payload del
datagrama IP agregando cabeceras IPSec y los tipos de protección solicitados, entre la

información útil,
y la cabecera IP original.
En el modo túnel, IPSec trata al paquete entero como un bloque de datos, en el que aȂnade una
nueva
cabecera y protege los datos haciendo que formen parte de la información útil cifrada del
paquete nuevo.
En la práctica se utiliza generalmente el modo transporte para las conexiones de host a host,
mientras
que si se tratan de puertas de enlaces (conexión red a red) es conveniente utilizar el modo túnel.
6.1 .3. Protocolos de gestión e intercambio de claves
Cuando se utilizan bases de datos de asociaciones de seguridad y de normativas de seguridad, se

puede
pretender conĮgurarlas tanto manual como automáticamente. El modo automático es el más

utilizado y
se lo lleva a cabo con protocolos de gestión e intercambio de claves para IPSec.

El protocolo IKE resuelve el problema más importante del establecimiento de comunicaciones
seguras
que es la autenticación de los participantes y el intercambio de claves simétricas. Para lograr este
cometido
crea las SA (Security Association) y rellena la SAD (Security Associations Database) . Además este
protocolo combina elementos, deĮniciones y funcionalidades de otros protocolos como ISAKMP

(Internet
Security Association and Key Management Protocol) , SKEME (Secure Key Exchange Mechanism) y
Oakley (Oakley Key Determination Protocol) para intercambiar y gestionar claves y SA.
IKE
El protocolo IKE permite negociar SA automáticamente y suele implementarse a través de

servidores
en espacio de usuario, y no en el sistema operativo. Este funciona sobre UDP y emplea el puerto
500 para
su comunicación.
IKE ha sido desarrollado para ofrecer protección ante atacantes que pretendan repetir, eliminar o
cambiar mensa jes. Además soporta PFS (Perfect Fordward Secrecy) . Sin esta caracter´ıstica, si
una clave
esta comprometida, las otras claves y SA pueden resultar afectadas también, por lo tanto, todos
los datos
cifrados con esa clave. Por eso es recomendable activar esta opción.
El protocolo IKE funciona en dos fases. La Fase I establece una SA de ISAKMP con el propósito de
crear un canal seguro para proteger las siguientes negociaciones. En esta fase las negociaciones
tienen
lugar con menos frecuencia (una vez a la hora o quizás una vez al d´ıa) que en la Fase II (una vez
cada
minuto o cada 1024K de datos cifrados) .
En la Fase II, se deben negociar las SA de IPSec utilizadas para proteger el tráĮco IP. Todo los
mensa jes intercambiados en esta fase están protegidos por la Fase I.

Métodos de autenticación
La autenticación de los participantes en la Fase I se realiza mediante claves compartidas o Įrmas
digitales.
La autenticación mediante PSK (Pre-Shared Key) utiliza una clave compartida que deben tener
todas las partes que intervienen en el proceso de autenticación. Este método tiene problemas de
seguridad
y escalabilidad, ya que el transporte de claves en texto claro a los servidores que estan
distanciados
f´ısicamente, hacen que la seguridad dependa de terceros (correo electrónico, correo tradicional,
mensa jer´ıa,
etc.) . Si la clave cae en manos inapropiadas, la seguridad del sistema puede estar muy
comprometida, por
más que se utilicen los mejores métodos de encriptación y cifrado de datos, ya que el atacante
simular´ıa
ser un nodo de conĮanza. Por otro lado, si se disponen de numerosos nodos y se mantiene un plan
de
cambio de claves de forma regular, distribuir las claves por tantos servidores, tiene un costo
agregado en
la administración de VPN de gran tamaȂno.
El uso de Įrmas digitales (RSS o RSA) permite Įrmar los datos con la clave privada, que luego es
veriĮcada mediante la clave pública del par. De esta manera se veriĮca la identidad de quien
solicita la
conexión. Con este método se mejora el problema de la distribución de claves, mediante la

utilización de
certiĮcados digitales sabiendo que se puede conĮar en un tercero para que asocie la identidad del
par con
su clave pública. Se considera este método mejor que el de intercambio directo de claves
públicas.
En la Sección 6.2 se detallan estos métodos y se proporcionan ejemplos concretos.
Fundamentos de la Fase I
El protocolo IKE realiza varias operaciones importantes, como la de negociar los parámetros y
protocolos criptográĮcos que se utilizan para la autenticación y cifrado. Además se autentican

los
equipos mediante los algoritmos negociados. Por último se establece un secreto compartido
basado en la
información intercambiada. De esta manera se consigue un canal seguro al Įnalizar la Fase I. Los
modos
posibles en esta fase son:
Modo principal.
Modo agresivo.
Modo base.
En el se intercambian seis datagramas UDP, y si los host A y B son los que dicen ser, el primer
mensa je hace una propuesta y ofrece una lista de protocolos alternativos para que B elija. En el
segundo
mensa je, B devuelve los protocolos que quiere utilizar junto con otra información.
En los siguientes mensa jes, los hosts intercambian material clave y establecen las claves
compartidas, y
por último se autentican mutuamente utilizando el método de autenticación seleccionado en los

primeros
mensa jes.
En el se transmiten tres datagramas UDP, por lo que hacen falta menos paquetes para establecer
una
SA de ISAKMP en la Fase I que en el Modo principal. Entre las venta jas de este modo se
encuentran:
Disminución del número de mensa jes.
Posibilidad de asociar identidad (no solo dirección IP) con una clave precompartida espec´ıĮca o
con
una normativa de seguridad.
El inconveniente de este modo es que realiza cálculos que consumen recursos del sistema
inmediatamente, en respuesta al primer mensa je. Esto signiĮca que un atacante puede enviar una
cantidad
considerable de propuestas con direcciones IP falsas, lo que podr´ıa afectar al rendimiento del
sistema y
conducir a una denegación de servicio. Además cabe seȂnalar que el grupo de traba jo de IPSec
esta
considerando eliminar este modo.
Por último, el fue desarrollado para sacar partido a las venta jas del modo agresivo y subsanar
sus desventa jas. En este modo se envian cuatro datagramas UDP. Además, este modo propone el
establecimiento de claves computacionalmente intensivas hasta que se recibe una respuesta de la

parte
iniciadora para conĮrmar su existencia.
Sin embargo, el modo base no trata todos los problemas del modo agresivo, por ejemplo, a menos
que
se utilice cifrado de clave pública, la identidad de las partes comunicantes no esta protegida. Esto
es as´ı,
porque las claves compartidas se calculan después de que los hosts hayan intercambiado y
veriĮcado su
información de identidad.
Fundamentos de la Fase II
Luego de haber Įnalizado las negociaciones en la Fase I, los hosts deben compartir una SA de
ISAKMP
nueva, para proteger las subsecuentes negociacioes de la Fase II.
El protocolo de negociación de esta fase se denomina (QM) , que consta de tres mensa jes y
permite
negociar una o más SA de IPSec. Cualquier host puede iniciar las negociaciones, pero después
todos los
involucrados compartirán las SA de IPSec negociada y las almacenarán en sus respectivas SAD
(Security
Associations Database) .
En el modo rápido, ambas partes tienen que negociar una combinación de uno o más
protocolos, que
son enviados como propuestas (al igual que la Fase I) , por cada SA de IPSec. Por ejemplo se
pueden usar
estas combinaciones:
ESP-3DES-MD5
ESP-3DES-SHA-PFS
AH-3DES-MD5-PFS
AH-3DES-SHA-PFS
Además, con cada propuesta se env´ıa la siguiente información adicional:
Tiempo de vida de la SA de IPSec propuesta.
Grupo DH.
Indicador de modo transporte o túnel.
Información de claves.
De esta manera queda establecido el intercambio de claves una vez concluida la Fase II. Lo que
sigue
es la descripción de los protocolos de intercambio de claves.
6.1 .4. Funcionamiento de IPSec
El procesamiento de paquetes entrantes y salientes en IPSec pueden variar poco y son casi
simétricos.
Por ejemplo, el procesamiento para un paquete IP saliente se describe de la siguiente manera:
1 . Para saber qué hacer con el paquete saliente, se comprueba su SPD (Security Policy Database)
deĮnida por el administrador del sistema.
2. IPSec agrega la regla establecida en el punto anterior (AH, ESP o IPCOMP2 ) .
3. Ahora el módulo IPSec determina qué parámetros utilizar para proteger el paquete, deĮnidos
en
las SA (Security Association) que seȂnala a una entrada concordante de la SPD.

El procesamiento del tráĮco de paquetes entrantes se realiza de la siguiente manera:
1 . Se determina la SA (asociación de seguridad) en la base de datos SA del host destino.
2. Se obtiene el SPI (Security Parameters Index) , dirección IP del destino y protocolo de

manipulación
de datos IPSec (AH o ESP) .
3. Se realiza la autenticación y descifrado correspondientes.
4. Luego se obtiene la SPD con la información necesaria para realizar la operación adecuada con
el
paquete.
Una de las razones por las que no se obtiene primero la SPD es porque el paquete IP puede tener
una
cabecera cifrada, y que esta contenga información como número de puerto, el cual resulte
necesario para
pasar las reglas SPD .
6.2. Métodos de Autenticación
Antes de iniciar una transferencia de datos entre dos hosts en una red, se requiere de un paso
previo
que se llama autenticación. El host solicitado por un determinado servicio, pide al solicitante, que
se
identiĮque, que demuestre que está autorizado para establecer dicha transferencia.
IPSec provee autenticación mutua, es decir, que no es solo el host solicitante el que se identiĮca,
sino
también el solicitado. Esto esto ayuda a incrementar el nivel de seguridad de nuestras VPNs.
El proceso de identiĮcación es lo que se denomina autenticación, y existen diferentes métodos

para
hacerlo. En esta sección se explicará en que consisten algunos de ellos, y se analizarán las venta
jas y
desventa jas de los mismos.
6.2.1 . Pre-Shared Key (PSK)

El método de autenticación mediante pre-shared key (clave compartida previamente, en
castellano) ,
es el más simple de todos. Consiste en una clave (o llave) secreta conocida únicamente por los
hosts que
desean establecer la conexión VPN. La clave consta de una consecución de caracteres, como por
ejemplo
͞estaeslaclavesecreta͟ .
Cuando dos hosts concuerdan autenticar utilizando este método, transmiten al otro la clave para
comprobar que sea lamisma en ambos. Para hacer esto de forma segura, se utiliza ʹen generalʹel
protocolo
Diĸe-Hellman 3 de [6 ] .
2Estos protocolos se describen con más detalles en las siguientes secciones.
3El protocolo Diĸe-Hellman permite el intercambio secreto de claves entre dos partes que no han
tenido contacto previo,
utilizando un canal inseguro, y de manera anónima (no autenticada) .
La seguridad de la autenticación mediante PSK, radica en el compartimiento seguro de las claves.

Por
ejemplo, en la casa central de una empresa se instala un servidor VPN que utiliza IPSec y utiliza
PSK
como método de autenticación. El encargado de la instalación también tiene a cargo la

conĮguración de
los extremos opuestos del servidor, que se encuentran en las sucursales de dicha empresa. Al
momento
de conĮgurar el ISAKMP (manejador de claves) de la casa central, ha realizado una PSK que tiene
que
llevar a las sucursales de manera segura; de modo tal que ningún intruso pueda obtenerlas, y
establecer
una VPN con la casa central.
El modo más seguro para transportarlas, es que este empleado se traslade f´ısicamente hasta las
sucursales y las conĮgure él mismo. Cuando las distancias son muy grandes, esto se hace
imposible, por
lo que hay que volver a conĮar en la tecnolog´ıa. Utilizar una conexión segura (encriptada) puede
ser una
opción; por ejemplo puede conĮgurar las sucursales a través de una sesión SSH (Secure SHell) ,
enviarlas
al administrador remoto v´ıa ftps, https, entre otros protocolos seguros.
De esta manera surge una desventa ja, que es si alguien llegara a conocer la PSK, los datos ʹe
incluso la
integridad de la empresa ʹcorre peligro; por lo que es conveniente que no se la conf´ıe a cualquier
persona,
ni que la contraseȂna sea de fácil deducción.
6.2.2. CertiĮcados Digitales X.509
Con el ob jeto de comprender los certiĮcados X. 509, previamente se verán algunos conceptos
necesarios
para incrementar la seguridad de la VPN.
CertiĮcados Digitales
Un CertiĮcado Digital es un documento digital mediante el cual un tercero conĮable (una

autoridad
de certiĮcación) garantiza la vinculación entre la identidad de un sujeto o entidad y su clave

pública.
Existen varios formatos para certiĮcados digitales, pero los más comúnmente empleados se rigen
por
el estándar UIT-T X.509. El certiĮcado contiene usualmente el nombre de la entidad certiĮcada,

número
de serie, fecha de expiración, una copia de la clave pública del titular del certiĮcado (utilizada
para la
veriĮcación de su Įrma digital) y la Įrma digital de la autoridad emisora del certiĮcado de forma
que el
receptor pueda veriĮcar que esta última ha establecido realmente la asociación.

Cualquier persona o institución puede generar un certiĮcado digital, pero si éste no es
reconocido por
quienes interactúen con el propietario del certiĮcado, el valor del mismo es prácticamente nulo.
Para que
los certiĮcados emitidos por una entidad sean Įables los emisores deben acreditarse. Ver más en
[7] .
Autoridad de CertiĮcación
Una Autoridad de certiĮcación o certiĮcadora (de [8 ] ) es una entidad de conĮanza, responsable

de
emitir y revocar los certiĮcados digitales, para lo cual se emplea la criptograf´ıa de clave pública.
Para este caso no se requiere de los servicios de una CA externa, se puede Įrmar por uno mismo
los certiĮcados, ya que no se necesita reconocimiento público para este traba jo; e incluso a la
hora de
implementar una VPN en una empresa, se puede tener su propia autoridad de certiĮcación.
El estándar X.509
X.509 ʹen su versión 3 ʹes un formato estándar, internacionalmente aceptado, para certiĮcados
digitales. Dichos certiĮcados pueden contener información espec´ıĮca de la organización a la cual

pertenece,
que puede ser utilizada para una mejor identiĮcación de la organización en las operaciones.
La estructura general interna de un certiĮcado X.509 puede verse en la conĮguración 3.
El primer campo ʹluego de la validez ʹes el subject (sujeto) , que contiene los datos que identiĮcan
al sujeto titular. Estos datos están expresados en notación DN (Distinguished Name) , donde un
DN se
compone a su vez de diversos campos, siendo los más frecuentes los siguientes; CN (Common
Name) , OU
(Organizational Unit) , O (Organization) y C (Country) . Un ejemplo para identiĮcar un usuario

mediante
el DN, es el siguiente:
CN=nicolasformoso.com.ar
O=Proyecto Final
Detalle 3 Estructura de un certiĮcado X.509
1 * Ce rt i f i cado
2 o Ve rs i ón
3 o N úme ro de s eri e
4 o I D de l al go ri t mo
5 o Emi s or
6 o Val i de z
7 + No ant e s de ( f e cha )
8 + No de s pué s de ( f e cha )
9 o Suj e t o
10 o I nf o rmac i ón de c lave p úbl i ca del s uj e t o
11 + Algo ri t mo de c lave p úbl i ca
12 + Clave p úbl i ca de l s uj e t o
13 o I de nt i f i c ado r úni c o de e mi s or ( o pc i onal )
14 o I de nt i f i c ado r úni c o de s uj e t o ( o pc i onal )
15 o Ext e ns i one s ( o p t i onal )
16 + . . .
17 * Algo ri t mo usado para f i rmar el c e r t i f i c ado
18 * Fi rma di gi t al del c e rt i f i c ado
OU=VPN
C=AR
Además del nombre del sujeto titular (sub ject) , el certiĮcado también contiene datos asociados
al
propio certiĮcado digital, como la versión del certiĮcado, su identiĮcador (serialNumber) , la CA

Įrmante
(issuer) , el tiempo de validez (validity) , etc.
La versión X.509.v3 también permite utilizar campos opcionales (nombres alternativos, usos
permitidos para la clave, ubicación de la CRL y de la CA, etc. ) .
Luego el certiĮcado contiene la clave pública, que consta de dos campos, el que muestra el
algoritmo
utilizado para crear la clave (ej . RSA) , y la propia clave pública.
Por último, la CA ha aȂnadido la secuencia de campos que identiĮcan la Įrma de los campos
previos.
Esta secuencia contiene tres atributos, el algoritmo de Įrma utilizado, el hash de la Įrma, y la
propia
Įrma digital como se puede ver en [9] .
6.3. Descripción General de la VPN
Nuevamente, como en VPN usando PPP sobre SSH (Cap´ıtulo 5) la topolog´ıa seleccionada para la
VPN que implementaremos es Red a Red.
La diferencia fundamental con la implementación anterior, es que aqu´ı, el Servidor VPN

comparte el
mismo hardware que el Firewall, es decir, se encuentran en el mismo equipo; esto reŇeja una
venta ja,
dado que pueden crearse reglas para el tráĮco VPN con las mismas herramientas que para el
resto del
tráĮco de la red; aunque también se tienen algunas desventa jas desventa jas (Sección 1 .3) .
La topolog´ıa red a red, permite que las redes involucradas en la conexión, tengan la impresión
de
que se encuentran unidas solamente por un router; pero en realidad pueden estar separadas por
grandes
distancias. Las dos redes conectadas a través de Internet y la conexión virtual privada establecida
entre
ellas, se pueden ver en la Figura 6.3.
El Servidor VPN se ha implementado en el Firewall. Dicho equipo funciona también como default
gateway (en castellano, puerta de enlace predeterminada) , que es la única puerta de
entrada/salida de
datos a Internet. Esto ayuda a que la auditor´ıa de seguridad sea sencilla, ya que la misma se
reduce a un
solo punto de conexión.
El sistema operativo de dicho servidor es OpenBSD , que tiene la cualidad de ser sumamente
estable y
optimizado en cuestiones de seguridad. Véase la Sección 2.3 para más detalles de los sistemas
utilizados.
Finalmente, el protocolo que utilizará el Servidor VPN es IPSec, ya descrito anteriormente en este
mismo cap´ıtulo. El intercambio de claves será automático, por lo que se requerirá para el
mismo, el protocolo IKE, que utiliza ISAKMP/Oakley.
Figura 6.3: El servidor VPN en el mismo equipo que el Firewall
6.4. ConĮguración de los nodos
Gracias a la transparencia de este tipo de VPN, los únicos nodos que necesitan ser conĮgurados
son
los que establecen la conexión. El resto de los nodos ʹen ambas redes ʹsolo deben tener
conĮgurado como
puerta de enlace predeterminada al Servidor VPN; esto es as´ı, ya que dicho servidor se
implementa en el
mismo Default Gateway.
Como los nodos que establecen la VPN tienen el mismo Sistema Operativo ʹOpenBSDʹy los
mismos
demonios, las conĮguraciones son similares. Por lo tanto, todo lo que se encuentra explicado en el
resto
de esta sección, es válido para ambos nodos, caso contrario se harán notar las diferencias.
6.4.1 . ConĮguración del kernel
A diferencia de GNU/Linux, OpenBSD maneja los módulos del kernel a través de un comando
llamado
sysctl, que permite agregar, modiĮcar y eliminar ciertos parámetros del kernel. En una consola, y
con
privilegios de superusuario se deben escribir los siguientes comandos para habilitar las opciones
de IPSec:
$ sudo sys c t l ne t . ine t . ip . f o rwardi ng =1
$ sudo sys c t l ne t . ine t . e sp . enabl e =1
$ sudo sys c t l ne t . ine t . ah . e nabl e =1
$ sudo sys c t l ne t . ine t . i pc omp . enabl e =1
Con las l´ıneas anteriores el kernel habilita los parámetros especiĮcados, pero si el servidor se
apagara
por alguna razón, habr´ıa que escribirlas de nuevo. Para evitar esta incomodidad, se las deben
especiĮcar
en un archivo que las cargará automáticamente durante el arranque. Este es /etc/sysctl. conf ,
que
debe contener las l´ıneas que aparecen en la ConĮguración 15.
En general, /etc/sysctl. conf ya posee las l´ıneas 1 , 2, 3 y 4 de 15 (y otras más) pero se encuentran
comentadas, por lo que habrá que quitar el caracter numeral (#) . El siguiente listado detalla cada
l´ınea
del archivo en cuestión:
ConĮguración 15 L´ıneas necesarias para habilitar el soporte a IPSec.
1 net . ine t . ip . f o rwarding =1
2 net . ine t . esp . enabl e =1
3 net . ine t . ah . enabl e =1
4 net . ine t . i pcomp . enabl e =1
1 . net.inet.ip.forwarding=1 : Como se esta traba jando en una puerta de enlace, esta l´ınea esta
habilitada. La misma permite que los hosts internos de la red puedan acceder a Internet.
2. net.inet.esp.enable=1 : Habilita en el kernel el protocolo ESP de IPSec.
3. net.inet.ah.enable=1 : Habilita en el kernel el protocolo AH de IPSec.
4. net.inet.ipcomp.enable=1 : Habilita en el kernel el protocolo de compresión IPComp, de IPSec.
6.4.2. La interface enc0
Para poder inspeccionar el tráĮco VPN que pasa por nuestro Servidor, se requiere levantar una
interfaz
llamada encX, donde X se reemplaza por un número entero. Para levantar la interfaz se ejecuta
ifconĮg
enc0 up ; pero para que se levante cada vez que se encienda el equipo, se edita y guarda el archivo
/etc/hostname. enc0, conteniendo en su interior únicamente el comando up.
La funcionalidad de esta interfaz, viene dada por el hecho de que permite leer los datos antes de
ser
encriptados, de los paquetes IPSec que se env´ıan; as´ı como permite leer los datos de los
paquetes IPSec
que llegan, luego de ser desencriptados.
6.4.3. Directivas de Firewall
Cada una de las redes está protegida por el Įrewall propio de OpenBSD . Por lo tanto, es
necesario
habilitar los puertos y permitir el tráĮco de los protocolos utilizados por IPSec, de lo contrario el
Packet
Filter no lo dejará salir, y descartará los paquetes. Para comprender mejor el funcionamiento
véase la
Sección 3.3.
Luego se crea un anchor, que será el que contenga todas las reglas necesarias para establecer
VPN.
La venta ja de los anchors es que se pueden recargar las reglas contenidas en ellos, sin tener que
recargar
las reglas principales de PF, ni la de los otros anchors.
Para crear un anchor llamado vpn isakmpd, simplemente se agrega al archivo /etc/pf. conf , la
l´ınea:
anchor vpn_isakmpd
Luego se deben recargar las reglas del PF con el comando pfctl -f /etc/pf. conf . Luego, para ver
si el anchor se ha creado satisfactoriamente, se ejecuta pfctl -s rules ; esto devuelve todas las
reglas
cargadas en el Įrewall, y los anchors si es que los hay.
La siguiente salida en pantalla es un ejemplo del uso de este comando:
# pf c t l - s rul e s
s c rub in all f ragment reas s embl e
bl ock re t urn all
pas s qui ck on xl0 al l f lags S / SA ke ep s t at e
pas s qui ck on lo0 al l f lags S / SA ke ep s t at e
pas s qui ck on ppp0 all f lags S / SA ke ep s tat e
anchor " vpn_ i s akmpd " all
pas s in on t un0 ine t pro t o t cp f rom any t o ( t un0 ) port = s sh f lags S / SA ke ep s t at e
pas s in on t un0 ine t pro t o t cp f rom any t o ( t un0 ) port = www f lags S / SA ke ep s t at e
pas s in on t un0 ine t pro t o t cp f rom any t o ( t un0 ) port = aut h f lags S / SA ke ep s t at e
pas s in on xl0 ine t f rom 1 9 2 . 1 6 8 . 1 . 0 / 24 t o any f lags S / SA ke ep s t at e

pas s out on xl0 ine t f rom any to 1 9 2 . 1 6 8 . 1 . 0 / 24 f lags S / SA ke ep s tat e
pas s out on t un0 pro t o t cp all f lags S / SA modulat e s tat e
pas s out on t un0 pro t o udp all ke ep s t at e
pas s out on t un0 pro t o i cmp al l keep s tat e
Dicho sea de paso, esta es la salida original del comando, de uno de los servidores durante las
pruebas.
La regla necesaria es anchor ͚ ͚ vpn isakmpd all" ; esto quiere decir, que el Įrewall también leerá
todas
las reglas que se encuentren es el anchor.
Naturalmente, en el anchor recién creado, no hay reglas deĮnidas. Por esto se crea un archivo
nuevo
que contiene las reglas necesarias para cargar en el anchor; el archivo es: /etc/pf. conf. isakmpd,
cuyo
contenido se puede ver en la ConĮguración 16, que esta ubicado en una de las puertas de enlace
(más
espec´ıĮcamente, en nicolasformoso. com. ar) .
ConĮguración 16 Archivo /etc/pf.conf. isakmpd
1 # I nt e r f ac e s
2 e xt _ i f =" tun0 "
4 # Variabl e s
5 GUS _DN = " gus t avo c o rt e z . com . ar "
6 LO CAL_ DN = " ni c o las f o rmo s o . com . ar "
7 GUS _NET = " 1 9 2 . 1 6 8 . 0 . 0 / 24 "
8 LO CAL_NET = " 1 9 2 . 1 6 8 . 1 . 0 / 24 "
10 ## P e rmi t i e ndo la ent rada / salida del t r áf i c o encript ado ,

11 # s olo de la di re c c i ón que de s eamo s
12 pas s in pro t o esp f rom $ GUS _DN t o $ LO CAL_ DN
13 pas s out pro t o esp f rom $ LO CAL_ DN to $GUS _ DN
14 pas s in pro t o ah f rom $ GUS _ DN to $ LO CAL_ DN
15 pas s out pro t o ah f rom $ LO CAL_ DN t o $GUS _ DN
16
17 # Ne c e s i t amo s pe rmi t i r el t r áf i c o " i pencap " en la int e r f az enc0
18 pas s in on enc0 pro t o i pencap f rom $GUS_ DN t o $ LO CAL_ DN
19
20 ## P e rmi t imo s el t r áf i c o de paque t e s ent re las subrede s locales ,
21 # por la int e r f az " enc0 "
22 pas s in on enc0 f rom $ GUS _NET to $ LO CAL_NET
23 pas s out on enc0 f rom $ LO CAL_ NET t o $GUS _NET
24
25 ## P e rmi t imo s el t r áf i c o por el pue rt o 500 ( i sakmpd ) , pero s olo
26 # con un de s t ino e s pe c i f i cado ( $GUS _DN ) .
27 pas s in on $ e xt _ i f pro t o udp f rom $GUS _DN port = 500 t o $ LO CAL_ DN port = 500
28 pas s out on $ e xt _ i f pro t o udp f rom $ LO CAL_ DN port = 500 to $GUS _DN port = 500
2 9 #$
Básicamente lo que se hace, con estas reglas de Įrewall, es permitir el Ňujo de paquetes entre las
puertas de enlace de las respectivas redes. Al momento de cargarse estas l´ıneas en el Įrewall, se
resuelven
los nombres de dominios y se los reemplaza por la dirección IP correspondiente; por lo que si en
algún
momento el ISP cambia la IP asignada anteriormente, es necesario volver a recargar las reglas. Por
el contrario, en una empresa que posee direcciones IP públicas estáticas (o Įjas) , no tienen el
mismo
problema.
Se utiliza la interfaz enc0 para transmitir el tráĮco encapsulado, por lo que se permite el tráĮco a
través de ella, desde y hacia el par remoto. También se da paso al Ňujo de paquetes encriptados
con
IPSec, con ESP y/o AH.
En la siguiente salida en pantalla de la consola se puede observar la ejecución de los comandos

para
cargar las reglas de anchor y para visualizarlas:
$ sudo pf c t l -a vpn_ i s akmpd - f / e t c / pf . c onf . i sakmpd
$ sudo pf c t l -a vpn_ i s akmpd - s rul e s
pas s in ine t pro t o e sp f rom 1 90 . 1 3 7 . 6 4 . 3 1 to 1 9 0 . 1 37 . 6 7 . 6 8 ke ep s t at e
pas s in ine t pro t o ah f rom 1 9 0 . 1 37 . 6 4 . 3 1 t o 1 9 0 . 1 3 7 . 6 7 . 6 8 ke ep s t at e
pas s in on enc0 ine t pro t o i pencap f rom 1 9 0 . 1 37 . 6 4 . 3 1 to 1 9 0 . 1 37 . 67 . 6 8 ke ep s t at

e
pas s in on t un0 ine t pro t o udp f rom 1 90 . 1 3 7 . 6 4 . 3 1 port = i sakmp t o 1 9 0 . 1 37 . 6 7 . 6

8 port = i s akmp ke ep
s t at e
pas s in on enc0 ine t f rom 1 9 2 . 1 6 8 . 0 . 0 / 2 4 to 1 9 2 . 1 6 8 . 1 . 0 / 24 f lags S / SA ke ep s tat

e
pas s out ine t pro t o e sp f rom 1 90 . 1 37 . 6 7 . 6 8 to 1 9 0 . 1 37 . 64 . 3 1 ke ep s t at e
pas s out ine t pro t o ah f rom 1 9 0 . 1 37 . 67 . 6 8 t o 1 9 0 . 1 3 7 . 6 4 . 3 1 ke ep s tat e
pas s out on t un0 ine t pro t o udp f rom 1 90 . 1 3 7 . 6 7 . 68 port = i sakmp to 1 9 0 . 1 37 . 64 . 3

1 port = i sakmp ke ep
s t at e
pas s out on enc0 ine t f rom 1 9 2 . 1 68 . 1 . 0/ 2 4 t o 1 9 2 . 1 6 8 . 0 . 0 / 2 4 f lags S / SA ke ep s

tat e
$
6.4.4. ConĮguración de isakmpd
El intercambio de claves y la negociación de otros parámetros necesarios para la VPN, se hace en
el establecimiento de la misma. Estas gestiones pueden realizarse de forma manual, o

automática. En
este caso se ha optado por el modo automático, debido a que, la conĮguración es más sencilla y
resuelve
problemas del intercambio manual de claves, como los ͞ataques por repetición de paquetes͟ .
Toda la conĮguración de este demonio se guarda por defecto en un archivo llamado isakmpd.
conf , en
el directorio /etc/isakmpd. Además de dicha conĮguración, existen otros archivos que también
se tienen
que analizar y modiĮcar.
Análisis de isakmpd. conf
En el archivo de ConĮguración 4 se puede ver un ejemplo del contenido del archivo.
Este archivo se divide en secciones, cuyos nombres se encuentran encerrados entre corchetes. Por
ejemplo, [General] es la primera sección; en ella se deĮnen parámetros globales para todas las
conexiones
que se puedan deĮnir a continuación. La opción Listen-on=, permite especiĮcar una lista
separadas por
comas de las direcciones IP locales y/o interfaces de red, a través de las cuales se establecerán
las VPN.
Las secciones [Phase 1] y [Phase 2] se utilizan durante el establecimiento de la conexión en las
respectivas fases. En la primera se deĮne el parámetro 190. 225. 230. 254=, que es una dirección
IP
pública con la cual se va a conectar; a la derecha del s´ımbolo igual, se deĮne el nombre de la
sección que
tiene los parámetros para lograr establecer la conexión con el equipo remoto. En la segunda
sección, el
parámetro Connections=, es el que deĮne una lista de posibles secciones a utilizar para establecer
las SA
de IPSec.
La sección [peer-gustavo] ʹrelacionada en [Phase 1 ] con una dirección IP ʹ, deĮne los

parámetros
que se utilizarán para la fase 1 para establecer la conexión con dicho host . Lo parámetros que
merecen
ser destacados son Configuration= que contiene el nombre de la sección donde se deĮnen el
modo, que
puede ser Principal (ID PROT) o agresivo (AGRESSIVE) , y los algoritmos de encriptación y Hash
que se
utilizarán (en este caso, 3DES y SHA respectivamente) . El nombre de esta sección es Default-
main-mode.
El siguiente parámetro a ser destacado es Authentication=; este se utiliza solo cuando el método
de
autenticación es mediante clave PSK (Pre-Shared Key) , y lo que se especiĮca al lado es dicha
clave. Este
parámetro debe ser el mismo en los dos nodos que desean establecer la conexión
La sección [VPN-GUSTAVO] ʹespeciĮcada en [Phase 2 ] ʹ, contiene los parámetros para la

creación
de las SA; en el que se tiene ISAKMP-peer=, donde se especiĮca la sección que contiene los
parámetros
para la fase 1 de la conexión, luego Configuration=, que contiene la sección donde encuentran
los
parámetros para establecer la fase 2, en el modo (QUICK MODE) , y por último las Suites=, que
son
una lista de conjuntos de protocolos utilizados para la protección del tráĮco IP (en este caso, se
utilizan
ESP+3DES+SHA) .
En las secciones Local-ID= y Remote-ID= se deĮnen los nombres de las secciones que contienen las
deĮniciones de las redes local y remota respectivamente.
ConĮguración de CertiĮcados Digitales X.509

En el ejemplo del archivo /etc/isakmpd/isakmpd. conf dado anteriormente, el modo de
autenticación
utilizado es PSK (Pre-Shared Key) .
Ahora se va a conĮgurar un certiĮcado digital X.509 para la autenticación, a Įn de tener mayor

control
de quienes se conectan a la VPN.
Los certiĮcados digitales, para que funcionen, deben ser Įrmados por una entidad llamada
Autoridad
de CertiĮcación, que es un tercero que da garant´ıa de que el certiĮcado es de la persona que lo

posee,
Detalle 4 Archivo isakmpd. conf (con autenticación mediante PSK)
1 [ Gene ral ]
2 Li s t en - On= t un0
4 [ Phas e 1 ]
5 1 9 0 . 2 2 5 . 2 30 . 2 54= peer - gus t avo
7 [ Phas e 2 ]
8 Conne c t i ons = VPN - GUSTAVO
10 [ peer - gus t avo ] # 
11 Phas e = 1
12 Addre s s = 1 9 0 . 2 2 5 . 2 30 . 2 5 4
13 Conf i gurat i o n = De f aul t - main - mode
14 Aut he nt i cat i on = c lave s upe rs e c re t a
15
16 [VPN - GUSTAVO ] # 

17 Phas e = 2
18 I SAKMP - pe er = peer - gus t avo
19 Conf i gurat i o n = De f aul t - qui ck - mode
20 Local - I D = ni c olas - int e rnal - ne t work
21 Remot e - I D = gus tavo - int ernal - ne t work
22
23 [ gus tavo - int e rnal - ne t wo rk ] # 
24 ID - t ype = I PV4_ ADDR_ SUBNET
25 Ne t work = 1 9 2 . 1 68 . 0 . 0
26 Ne t mas k = 2 5 5 . 2 5 5 . 2 5 5 . 0
27
28 [ ni c olas - int e rnal - ne t wo rk ] # 
29 ID - t ype = I PV4_ ADDR_ SUBNET
30 Ne t work = 1 9 2 . 1 68 . 1 . 0
31 Ne t mas k = 2 5 5 . 2 5 5 . 2 5 5 . 0
32
33 [ De f aul t - main - mode ]
34 EXCHANGE_ TYPE = I D_PRO T
35 Trans f o rms = 3 DES - SHA , BLF - SHA
36
37 [ De f aul t - qui ck - mode ]
38 EXCHANGE_ TYPE = QUI CK_MO DE
39 Sui t e s = QM - ESP -3 DES - SHA - SUI TE
y es válido. Para evitar la incomodidad y la demora de estas terceras partes, se creará una
autoridad
de certiĮcación propia, que consiste únicamente en crear una clave privada con la cual se
Įrmarán los
certiĮcados que necesarios 4 .
En la siguiente salida por pantalla de la terminal, se puede ver la l´ınea necesaria para hacer este
traba jo:
4La CA, no necesariamente debe ser uno de los equipos involucrados en la conexión, sino que
puede ser cualquier otro
con las herramientas para hacerlo.
S t at e or Provi nc e Name ( f ul l name ) [ ] : TUC
Lo cal i t y Name ( eg , c i t y ) [ ] : SMT
Organi zat i on Name ( eg , c ompany ) [ ] : Pro ye c t o Final
O rgani zat i onal Uni t Name ( eg , s e c t i on ) [ ] : CA_TEST
Common Name ( eg , f ul l y qual i f i ed hos t name ) [ ] : ni c o las f o rmo s o . com . ar
Emai l Addre s s [ ] : c a@ni c o las f o rmo s o . com . ar
HO S T_CA #
El siguiente paso, es la creación de las solicitudes de Įrma de certiĮcados (los CSR, CertiĮcate
Signing
Request) :
HO ST_VPN1 # o pens s l req - new - key / e t c / i sakmpd / pri vat e / l o cal . key \
> - out / e t c / i s akmpd / pri vat e / gus t avo c o r t e z . c om . ar . c sr
You are about t o be as ked t o ent e r i nf ormat i on t hat wi l l be i nc orpo rat e d

int o your c e rt i f i cat e reque s t .
What you are about t o ent er is what i s cal l e d a D i s t i ngui s hed Name or a DN .
There are qui t e a f ew f i e l ds but you can l eave s ome blank
For s ome f i e lds t here wi l l be a de f aul t value ,
If you ent e r ͛ . ͛ , the f i e ld wi l l be l e f t blank .
-----
Count ry Name ( 2 l e t t e r c ode ) [ ] : AR
St at e or Provi nc e Name ( f ul l name ) [ ] : TUC
Lo cal i t y Name ( eg , c i t y ) [ ] : SMT
Organi zat i on Name ( eg , c ompany ) [ ] : Proye c t o Final
O rgani zat i onal Uni t Name ( eg , s e c t i on ) [ ] : VPN_ I P S e c
Common Name ( eg , f ul l y qual i f i ed ho s t name ) [ ] : gus t avo c or t e z . com . ar
Emai l Addre s s [ ] : vpn@gus t avo c o r t e z . com . ar
Pl eas e ent e r t he f o l l owi ng ͛ ext ra ͛ at t r i but e s
to be s ent wi t h your c e r t i f i c at e reque s t
A chal l enge pas s word [ ] : < ent er >
An opt i onal c ompany name [ ] : < ent er >
HO ST_VPN1 #
El paso anterior debe realizarse en los dos hosts que pretendan conectarse en la VPN. Este
devuelve el
CSR para el respectivo host en el archivo private/gustavocortez. com. ar. csr. Luego, las CSR deben
ser enviadas a la CA, para ser Įrmadas por la misma.
La autoridad de certiĮcación, Įrmará los certiĮcados X.509 de la siguiente forma:
HO S T_CA # env CERTFQ DN = gus t avo c o r t e z . com . ar opens s l x509 - req - days 365 - in gus
t avo c o rt e z . c om . ar . csr -
out \
> gus t avo c o rt e z . com . ar . crt - CA / e t c / s s l / ca . crt - CAke y / e t c / s sl / pri vat e / ca .
key \
> - CAc reat e s e ri al - e xt f i l e / e t c / s s l / x5 09v3 . cnf - e xt e ns i ons x5 09v3 _FQ DN
S i gnat ure ok
s ub j e c t =/ C= AR/ ST= TUC / L= SMT / O = Proye c t o Final / OU= VPN_ I PS e c / CN = gus t avo c
or t e z . com . ar / e mai lAddre s s =
vpn@gus t avo c o r t e z . c om . ar
Ge t t i ng CA Privat e Key
Ent er pas s phras e f or / e t c / s s l / pri vat e / ca . key : < pas s phras e >
HO S T_CA #
Esto generará el certiĮcado X.509 Įrmado, a partir de la solicitud CS
R. Dichos certiĮcados deben ser
llevados hacia el respectivo host, y deben ser ubicados en el directorio /etc/isakmpd/cert ; la ruta
al
certiĮcado ser´ıa: /etc/isakmpd/cert/gustavocortez. com. ar. También es necesario que la CA

otorgue
a los hosts el archivo donde se encuentra la Įrma, es decir, /etc/ssl/ca. crt , que en los hosts debe
guardarse en /etc/isakmpd/ca.
Ya están dispuestos los certiĮcados en cada host, ahora se debe modiĮcar el archivo isakmpd.
conf ,
para que funcionen. En la ConĮguración 5 se muestra un ejemplo de dicho archivo para que
funcione con
certiĮcados X.509.
Se muestran únicamente las secciones que requieren modiĮcación o se agregan, todas las
demás quedan
como estaban en el caso anterior.
Las únicas modiĮcaciones necesarias para que funcionen estos certiĮcados, son las que se ven en
las
secciones [peer-gustavo] y [Default-main-mode]. En la primera se agrega el parámetro ID=, que
deĮne
una sección de la que se obtiene el FQDN local. Este sirve para encontrar el respectivo certiĮcado;
en
la segunda se cambia 3DES-SHA por 3DES-SHA-RSA SIG , en el que el primero es para

autenticación
mediante PSK y el segundo especiĮca que se debe buscar un certiĮcado (RSA Signature) .
La sección [X509-certiĮcates] deĮne los directorios donde se ubicarán las claves y los certiĮcados,
si
se utilizan los que se deĮnen por defecto, no hace falta especiĮcarla.
Detalle 5 Secciones del archivo /etc/isakmpd/isakmpd.conf (para autenticación con X.509)
1 [ peer - gus t avo ] # 
2 Phas e = 1
3 Addre s s = 1 90 . 1 37 . 64 . 3 1
4 Conf i gurat i o n = De f aul t - main - mode
5 I D = ni c olas - phas e 1 - id
7 [ ni c olas - phas e 1 - id ] # < phas e 1 - ID >
8 ID - t ype = FQDN
9 Name = ni c o las f o rmo s o . com . ar
10
11 [ De f aul t - main - mode ]
12 EXCHANGE_ TYPE = I D_PRO T
13 Trans f o rms = 3 DES - SHA - RSA_SI G , BLF - SHA
14
15 [ De f aul t - qui ck - mode ]
16 EXCHANGE_ TYPE = QUI CK_MO DE

17 Sui t e s = QM - ESP - DES - MD5 - AH - MD5 - SUI TE
18
19 [ QM - ESP - DES - MD5 - AH - MD5 - SUI TE ]
20 Pro t o c o l s = QM - ESP - DES - MD5 , QM - AH - MD5
21
22 [ X509 - c e rt i f i c at e s ]
23 CA - di re c t o ry = / e t c / i sakmpd / ca/
24 Cert - di re c t o ry = / e t c / i s akmpd / c e rt s /
25 Privat e - key = / e t c / i s akmpd / pri vat e / lo cal . key
Una diferencia entre los dos archivos isakmpd. conf ʹque no tiene que ver con el modo de
autenticación
ʹ, es la que hay en la sección [Default-quick-mode], se cambió el modo de protección de tráĮco

IPSec de
QM-ESP-3DES-SHA-SUITE a QM-ESP-DES-MD5-AH-MD5-SUITE. Con esta nueva suite de protocolos,
no solo se agrega la protección que ofrece ESP, sino también la de AH.
El archivo isakmpd. policy
Este archivo es mucho más corto que el anterior, pero también es necesario, por que ayuda a
deĮnir
la pol´ıtica para la autenticación, el método, y otras condiciones para agregar seguridad a la VPN
con
IPSec.
Detalle 6 Archivo isakmpd. policy (para autenticación con X.509)
1 Keyno t e - ve rs i on : 2
2 Aut ho ri z e r : " POLI CY "
3 Li c e ns e e s : " DN : / C= AR/ ST = TUC / L= SMT / O = Proye c t o Final / CN = ni c o las f o rmo s o

. com . ar "
4 Condi t i ons : app_domai n == " I Ps e c po l i cy " &&

5 e s p_ pre s ent == " ye s " &&
6 e s p_ e nc _alg ! = " null " -> " t rue " ;
Un ejemplo de este archivo ser´ıa como en la ConĮguración 6. A continuación se detallan los

parámetros:
Authorizer:, siempre llevará el parámetro ͞POLICY͟ , que indica que no hay delegación de
autenticación.
Conditions: permite agregar condiciones tanto para los protocolos utilizados en la encriptación,
hashing, como para las direcciones de los nodos remotos. En el manual se muestra una lista
interminable
de parámetros que se pueden especiĮcar aqu´ı.
Lecensees: es el que se usará para indicar cómo será la autenticación. Si esta ausente, esta se
hará mediante PSK (especiĮcada en el archivo isakmpd. conf ) ; si está presente, se puede indicar
una
PSK, una CA para certiĮcados X.509, o ambas cosas. Por ejemplo, para indicar una PSK, esta l´ınea
deber´ıa ser de la siguiente forma:
Licensees: "passphrase: clavesupersecreta"
Pero si se quieren utilizar los certiĮcados creados anteriormente, es necesario agregar la

identiĮcación
de la CA, para admitir los certiĮcados Įrmados por la misma. Esta identiĮcación se obtiene de la
siguiente
forma:
$ cd / e t c / i s akmpd
$ opens s l x509 - in ca/ ca . crt - no out - s ub j e c t
Sub j e c t : / C= ar / ST= tuc / L= smt / O = Proye c t o Final / CN= ni c o l as f ormo s o . com . ar
Por lo que en el archivo isakmpd. policy, se debe agregar la l´ınea:
Licensees: "DN: /C=AR/ST=TUC/L=SMT/O=Proyecto Final/CN=nicolasformoso. com. ar"
Donde DN signiĮca Distinguished Name, y es sucedido por la identiĮcación de la CA.

6.4.5. Iniciación de la conexión
Para activar las conexiones, lo único necesario es hacer correr el demonio; con permisos de
superusuario
se escribe en una consola simplemente el comando isakmpd. El demonio se ejecutará

independiente de una
terminal, si el otro extremo está activo, se establecerá automáticamente la conexión, sino se

esperará a
que se solicite el establecimiento de la misma.
Para ver las rutas creadas por IPSec, en la consola se ejecuta el siguiente comando:
$ ne t s t at - rn - f encap
Rout i ng t abl e s
Encap :
S ourc e Port De s t i nat i on Port Pro t o SA ( Addre s s / Pro t o / Type / Di re c t i on )
1 9 2 . 1 68 . 1 / 2 4 0 1 9 2 . 1 6 8 . 0/ 24 0 0 1 9 0 . 3 0 . 8 8 . 1 84/ es p / us e / in
1 9 2 . 1 68 . 0 / 2 4 0 1 9 2 . 1 6 8 . 1 / 24 0 0 1 9 0 . 3 0 . 8 8 . 1 84/ es p / requi re / out
La salida del comando netstat son las rutas creadas entre las redes que establecen la conexión, a
través de la interfaz enc0 . Para poder usarlas, hay que crear (en ambas redes) una ruta de la
familia inet;
con esto se deĮne la interfaz de entrada/salida de los paquetes encapsulados, que en este caso,
será la
interfaz de red local. La Figura 6.4 reŇeja esta situación.

Figura 6.4: ConĮguración de ruteo en nodo isakmpd
Cuando se establece la conexión con IPSec se crean asociaciones de seguridad (SA) y pol´ıticas de
seguridad. Para ver las bases de datos correspondientes (SAD y SPD) se utiliza el comando ipsecctl
,
que también se utiliza cuando las SA son creadas manualmente
El comando siguiente devuelve el contenido de la SAD y de la SPD (llamada aqu´ı FLOWS) :
$ sudo i ps e c c t l -s all
FLOWS :
f l ow e sp in f rom 1 9 2 . 1 6 8 . 1 . 0 / 24 to 1 9 2 . 1 6 8 . 0 . 0 / 24 pe er 1 9 0 . 30 . 88 . 1 84 s rc id
1 9 0 . 3 0 . 8 2 . 2 5 1 / 32 ds t i d
1 9 0 . 3 0 . 8 8 . 1 84/ 3 2 t ype us e
f l ow e sp out f rom 1 9 2 . 1 68 . 0 . 0/ 2 4 t o 1 9 2 . 1 6 8 . 1 . 0/ 2 4 pe er 1 9 0 . 30 . 8 8 . 1 84 s rc
i d 1 9 0 . 30 . 82 . 2 5 1 / 3 2 ds t id
1 9 0 . 3 0 . 8 8 . 1 84/ 3 2 t ype requi re
SAD :
esp t unne l f rom 1 90 . 30 . 8 2 . 2 5 1 to 1 9 0 . 30 . 8 8 . 1 8 4 s pi 0 xa2aa4aaa auth hmac - sha1

enc 3 des - cbc
esp t unne l f rom 1 90 . 30 . 8 8 . 1 84 to 1 9 0 . 30 . 8 2 . 2 5 1 s pi 0 xf c d76 7 54 auth hmac - sha1
enc 3 des - cbc
VeriĮcación de la conexión
Por último, para ver si hay contacto entre los hosts internos de las redes, se pueden realizar unas
simples pruebas. En el host 192. 168. 1. 2 se escribe:
# ping - c 2 1 9 2 . 1 68 . 0 . 3 2
PI NG 1 9 2 . 1 6 8 . 0 . 32 ( 1 9 2 . 1 6 8 . 0 . 3 2 ) : 56 data byt e s
64 byt e s f rom 1 9 2 . 1 6 8 . 0 . 3 2 : i cmp_ s eq =0 t t l =1 27 t ime =37 . 79 7 ms
64 byt e s f rom 1 9 2 . 1 6 8 . 0 . 3 2 : i cmp_ s eq =1 t t l =1 27 t ime =33 . 2 5 2 ms
- - - 1 9 2 . 1 6 8 . 0 . 3 2 ping s t at i s t i c s -- -
2 packe t s t rans mi t t ed , 2 pac ke t s re c e i ved , 0. 0 % packe t l os s
round - t ri p min / avg / max / std - dev = 33 . 2 5 2 / 3 5 . 5 2 4/ 3 7 . 7 9 7 / 2 . 2 80 ms
# s sh 1 9 2 . 1 68 . 0 . 3 2
s sh : c onne c t t o hos t 1 9 2 . 1 6 8 . 0 . 32 port 22 : Conne c t i o n re f us ed
C on el comando ping se comprueba si hay respuesta desde la dirección 192. 168. 0. 32 ; por lo
que se
puede ver en la salida anterior, es que s´ı hay respuesta. Seguidamente se puede intentar
establecer una
conexión SSH con dicho host (cuyo puerto 22 está cerrado a propósito) .
Al mismo tiempo de realizadas estas pruebas, en el servidor VPN del lado del host testeado, se
estaba
ejecutando un sniīer de paquetes (tcpdump) sobre la interfaz enc0; la salida que se obtuvo es la
siguiente:
$ sudo t c pdump - i enc0
t c pdump : l i s t eni ng on enc0 , link - t ype ENC

1 1 : 3 9 : 1 8 . 88 2 7 5 7 ( aut hent i c , c o nf i dent i al ) : SPI 0 xc f c 4e e 73 : 1 9 2 . 1 6 8 . 1 . 2 > 1
9 2 . 1 6 8 . 0 . 3 2 : i cmp : e cho
reque s t ( encap )
1 1 : 3 9 : 1 8 . 883 9 5 9 ( aut hent i c , c o nf i dent i al ) : SPI 0 xb1 1 a0 f 9 1 : 1 9 2 . 1 6 8 . 0 . 3 2 >

1 9 2 . 1 6 8 . 1 . 2 : i cmp : e cho reply
( encap )

9 2 . 1 6 8 . 0 . 3 2 : i cmp : e cho
reque s t ( encap )
1 1 : 3 9 : 1 9 . 88 6 1 6 9 ( aut hent i c , c o nf i dent i al ) : SPI 0 xb1 1 a0 f 9 1 : 1 9 2 . 1 6 8 . 0 . 3 2 >

1 9 2 . 1 6 8 . 1 . 2 : i cmp : e cho reply
( encap )
1 1 : 3 9 : 3 8 . 1 83 9 45 ( aut hent i c , c o nf i dent i al ) : SPI 0 xc f c 4e e 73 : 1 9 2 . 1 6 8 . 1 . 2 . 3

3 2 0 9 > 1 9 2 . 1 6 8 . 0 . 3 2 . s sh : S
3 1 348 9 5 5 3 6 : 3 1 348 9 5 5 3 6 ( 0 ) win 1 6384 < ms s 1460 , nop , nop , sackOK , nop , ws cal e
0 , nop , nop , t i me s t amp
3 588245 5 5 3 0 > ( DF ) ( encap )
1 1 : 3 9 : 3 8 . 1 8 5 0 6 6 ( aut hent i c , c o nf i dent i al ) : SPI 0 xb1 1 a0 f 9 1 : 1 9 2 . 1 6 8 . 0 . 3 2 .

s sh > 1 9 2 . 1 6 8 . 1 . 2 . 3 3 2 09 : R
0 : 0 ( 0 ) ack 3 1 3489 5 5 37 win 0 ( encap )
^C
6 packe t s re c e i ved by f i l t e r
0 packe t s dropped by ke rne l
Se pueden observar los paquetes ICMP hacia y desde la dirección 192. 168. 0. 32 . Luego se ve el
intento
de conexión SSH. Más pruebas se pueden ver en la Sección 6.5.
Al Įnal de cada l´ınea en la salida del sniīer (que detalla un paquete) dice (encap), lo que sifniĮca
que
el tráĮco está encapsulado con IPSec.
6.5. Pruebas y mediciones
En esta sección se van a detallar las aplicaciones utilizadas para comprobar que la comunicación
se
ha establecido correctamente y que la información llega a todos los puntos de la red interna.
También se
va mostrar el Ňujo de información que atraviesa la VPN de un extremo a otro
Por último se realizan mediciones en la velocidad de transferencia de archivos y en en las

conexión
a escritorios remoto. Además se van a realizar comprobaciones de la vulnerabilidad del sistema

con un
software especializado.
6.5.1 . Revisión del tráĮco
Una manera de ver si llegan los paquetes a destino o simplemente si atraviesan el Įrewall, es
utilizar
un Įltro de paquetes. En OpenBSD se tiene TCPdump en modo texto y en Windows (o cualquier

otro
sistema operativo) se puede utilizar el software libre Wireshark en modo gráĮco.
La siguiente salida por pantalla muestra el tráĮco de paquetes que llegan de un host remoto, que
han
pasando por el proceso de encapsulado, autenticación y cifrado de IPSec:
$ sudo t c pdump - i enc0
t c pdump : l i s t eni ng on enc0 , link - t ype ENC

9 2 . 1 6 8 . 0 . 3 2 : i cmp : e cho
reque s t ( encap )
1 1 : 3 9 : 1 8 . 883 9 5 9 ( aut hent i c , c o nf i dent i al ) : SPI 0 xb1 1 a0 f 9 1 : 1 9 2 . 1 6 8 . 0 . 3 2 >

1 9 2 . 1 6 8 . 1 . 2 : i cmp : e cho reply
( encap )
9 2 . 1 6 8 . 0 . 3 2 : i cmp : e cho
reque s t ( encap )
1 1 : 3 9 : 1 9 . 88 6 1 6 9 ( aut hent i c , c o nf i dent i al ) : SPI 0 xb1 1 a0 f 9 1 : 1 9 2 . 1 6 8 . 0 . 3 2 >

1 9 2 . 1 6 8 . 1 . 2 : i cmp : e cho reply
( encap )
1 1 : 3 9 : 3 8 . 1 83 9 45 ( aut hent i c , c o nf i dent i al ) : SPI 0 xc f c 4e e 73 : 1 9 2 . 1 6 8 . 1 . 2 . 3

3 2 0 9 > 1 9 2 . 1 6 8 . 0 . 3 2 . s sh : S
3 1 348 9 5 5 3 6 : 3 1 348 9 5 5 3 6 ( 0 ) win 1 6384 < ms s 1460 , nop , nop , sackOK , nop , ws cal e
0 , nop , nop , t i me s t amp
3 588245 5 5 3 0 > ( DF ) ( encap )
1 1 : 3 9 : 3 8 . 1 8 5 0 6 6 ( aut hent i c , c o nf i dent i al ) : SPI 0 xb1 1 a0 f 9 1 : 1 9 2 . 1 6 8 . 0 . 3 2 .

s sh > 1 9 2 . 1 6 8 . 1 . 2 . 3 3 2 09 : R
0 : 0 ( 0 ) ack 3 1 3489 5 5 37 win 0 ( encap )
^C
6 packe t s re c e i ved by f i l t e r
0 packe t s dropped by ke rne l
De esta manera se ha comprobado que por la interfaz enc0 via jan los datos encapsulados desde
una
red a la otra.
6.5.2. Comprobación de la ruta de paquetes
Para comprobar el recorrido de los paquetes transmitidos por la red se ha utilizado traceroute en
los sistemas BSD y Linux, y tracert en Windows. La siguiente salida en pantalla desde un equipo
con
Windows (cliente DHCP) que se le ha asignado la dirección IP 192.168.0.35, efectúa la traza hasta
un
equipo de otra red, a través de la VPN, cuya dirección de destino es 192.168.1 .3.
C : \\ Us e rs \\ Gus tavo > t rac e r t 1 9 2 . 1 68 . 1 . 3

Traza a la di re c c i ón PONCHO [ 1 9 2 . 1 68 . 1 . 3 ]
s obre un máximo de 30 s al t o s :
1 <1 ms <1 ms <1 ms 1 9 2 . 1 6 8 . 0 . 1
2 70 ms 42 ms 39 ms 1 9 2 . 1 6 8 . 1 . 2
3 38 ms 39 ms 39 ms PONCHO [1 9 2 . 1 6 8 . 1 . 3 ]
Traza c ompl e t a .
C : \\ Us e rs \\ Gus tavo >
Se puede observar del listado anterior que el paquete primero llega a la puerta de enlace
predeterminada del sistema local (es decir, 192.168.0.1) , y luego el servidor que previamente ha
establecido
las rutas para interconectar las redes mediante la VPN, reenv´ıa este paquete a la puerta de enlace
remota
(del otro extremo de la VPN) de dirección IP 192.168.1 .2, que a su vez reenv´ıa el paquete al
equipo
destino que pertenece a su red. En el siguiente listado se puede ver la operación invertida.
C : \\ Do cume nt s and S e t t i ngs \\ Admin > t rac e rt 1 9 2 . 1 6 8 . 0 . 3 2
Traza a 1 9 2 . 1 6 8 . 0 . 3 2 s obre cami no s de 30 sal t o s c omo máxi mo .
1 <1 ms <1 ms <1 ms 1 9 2 . 1 6 8 . 1 . 2
2 38 ms 1 50 ms 77 ms 1 9 2 . 1 6 8 . 0 . 1
3 352 ms 1 94 ms 361 ms 1 9 2 . 1 6 8 . 0 . 3 2
Traza c ompl e t a .
C : \\ Do cument s and S e t t i ngs \\ Admin >
En esta situación, el equipo con dirección IP 192.168.1 .3 realiza la traza de paquetes hacia un
equipo
de otra red, pasando por la VPN, y Įnalmente llegando a destino (de IP 192.168.0.32) .
6.5.3. Transferencia de archivos

La transferencia de archivos se realiza a una velocidad aceptable, pero que depende de la
capacidad
de subida del enlace. El proveedor actual (ISP) permite una subida de 256 Kbps, por lo que se
aproxima
a casi 30 Kbytes por segundos teórico. En la Figura 6.5 se puede observar que la transferencia
ronda los
24 Kbytes por segundo; esto resulta aceptable para las condiciones en que se realiza la
transmisión, es
decir, el retardo de las puertas de enlace, la franja horaria, distancia, entre otras condiciones.
Figura 6.5: Captura de pantalla de una transferencia de archivo mediante IPSec.
Además se tiene en cuenta que la transferencia se realiza mediante el protocolo SMB (Server
Message
Block) que utiliza Windows para la transferencia de archivo mediante el explorador de archivos, y
que
este no es el método más rápido para transferir archivos. Aún as´ı, los resultados mediante FTP
(File
Transfer Protocol) fueron similares.
6.5.4. Escritorio remoto
También se ha evaluado el rendimiento mediante conexiones VNC (Virtual Network Computing) al
escritorio remoto de un equipo de cada red, separada por la VPN. La Figura 6.6 muestra la
velocidad de
conexión entre dos equipos de subred diferente, de ambos extremos de la VPN.

Finalmente, se ha comprobado que la conexión se manten´ıa estable, pero el rendimiento del
escritorio
remoto se hac´ıa cada vez más ͞pesado͟ a medida que se acercaba a la franja horaria pico en
cuanto a
cantidad de conexiones al ISP. A pesar de esto, la comunicación en ningún momento se ha

perdido.
6.5.5. Buscando vulnerabilidades
En la comprobación de seguridad de un sistema (en realidad de toda la red) , se pueden utilizar

varias
herramientas que por lo general tienen un costo bastante elevado. Por esta razón es que para
estas pruebas
se ha utilizado un programa gratuito propiedad de Tenable Network Security denominado Nessus.
Nessus traba ja en modo cliente y servidor, donde el primero genera el informe y muestra al
usuario
los resultados del escaner, el segundo realiza el monitoreo en el servidor residente.

Figura 6.7: Captura de pantalla del programa top en OpenBSD .
En la Figura 6.7 se puede ver que el consumo de recursos que utiliza el servidor Nessus para
comprobar
las vulnerabilidades de los sistemas, es excesivamente elevado, llegando a consumir casi el 99 por
ciento
de microprocesador durante un largo proceso de escaneo. Además utiliza mucha cantidad de

memoria, a
tal punto que requiere, en la mayor´ıa de los casos, utilizar la memoria de intercambio Swap.
6.6. Conclusión
El uso de IPSec para establecer una VPN presenta un gran desaf´ıo para los administradores de
sistemas. Esto se debe a la diĮcultad propia de la tecnolog´ıa que muchas veces pueden llegar a
hacer
tomar decisiones incorrectas. Como se menciona en [1 ] , según los criptógrafos, la complej idad
es un
enemigo de la seguridad.
Por esta razón, es necesario establecer una buena pol´ıtica de seguridad previa a la conĮguración
y
puesta en funcionamiento de IPSec. Esto implica que si la seguridad del sistema esta
comprometida,
la implementación de IPSec no va a subsanar el problema. De hecho, las normativas de seguridad

son
impuesta por los administradores del sistema, IPSec solamente ofrece los mecanismos para
asegurarlo.
Nuevamente la utilización de sistemas complejos como IPSec requieren de mucho estudio y

práctica
en entornos reales. La gran cantidad de conceptos que maneja, pueden llevar a los
administradores a
Įltrar detalles o a pasar por alto normativas que estan fuera del alcance de IPSec.
Por otro lado, si se realiza una buena combinación de protocolos y métodos de autentiĮcación
cuidadosamente distribuidos, IPSec puede llegar a ser la mejor solución para mantener enlaces
seguros
entre las partes.
Además se puede decir que IPSec se encuentra dentro de los protocolos y sistemas más seguros
que puedan utilizarse para establecer una VPN red a red entre dos o más enlaces. Pero como se
ha
mencionado anteriormente, IPSec no protege los gateway ni los ataques de denegación de

servicios, por lo
que su conĮguración y puesta en funcionamiento se encuentra estrechamente relacionada con la

pol´ıtica
de seguridad y de las directivas de un buen Įrewall protegiendo el equipo y las redes involucradas.
Finalmente el grupo de desarrollo de IPSec esta considerando disminuir la complej idad del mismo,
eliminando algunos componentes tales como el modo transporte, el modo agresivo e incluso el
protocolo
AH. Esto se realiza con el ob jetivo de simpliĮcar la tarea de los administradores y para que no sea
necesario estudiar todas las RFC para aprender a manejar IPSec.
Cap´ıtulo 7
VPN con OpenVPN
OpenVPN es una implementación de una VPN de código abierto, utilizado para crear túneles
encriptados entre hosts. Se pueden establecer enlaces directos entre los equipos involucrados, a
pesar
que estén detrás de un Įrewall, utilizando NAT. Fue inicialmente escrito por James Yonan y
publicado
ba jo licencia GPL.
En este cap´ıtulo se introducirá a la tecnolog´ıa de OpenVPN; se describirán sus fundamentos y

caracter´ısticas importantes, que hacen de esta, una buena alternativa de IPSec (Internet Protocol
Security) , para usuarios móviles. También se realizarán pruebas de comprobación de

funcionamiento
y de transferencia de archivos.
7.1 . Introducción
OpenVPN permite autenticar los pares utilizando claves pre compartidas, certiĮcados o nombre de
usuario y contraseȂna. Un servidor que acepta múltiples clientes, puede autenticar a cada cliente
utilizando
Įrmas y certiĮcados autorizados.
OpenVPN incorpora OpenSSL como librer´ıa de encriptación. No es compatible con IPSec (Internet
Protocol Security) y con ninguna otra solución VPN expuesta en este traba jo. Los paquetes de
instalación
constan de archivos binarios para la conexión entre el cliente y el servidor.
Según [10] esta solución se ha ideado para simpliĮcar la conĮguración de VPN dejando atrás los
tiempos de soluciones complejas como IPSec.
7.1 .1 . Encriptación y autenticación
OpenVPN utiliza OpenSSL para proveer de encriptación a los datos. Este paquete realiza todo el
traba jo de encriptación y autenticación.
OpenVPN puede utilizar las caracter´ısticas de autenticación de HMAC (keyed-Hash Message
Authentication Code) para agregar otra capa de seguridad a la conexión. También se puede
utilizar
aceleración por hardware para mejorar la performance de la encriptación.
Existen tres métodos de autenticación para conectar entre las partes, mediante el uso de claves
pre
compartidas, con certiĮcados o con nombre de usuario y contraseȂna.
7.1 .2. Funcionamiento
OpenVPN puede traba jar sobre UDP (lo hace por defecto) o TCP. Multiplexando las
comunicaciones
sobre un simple puerto TCP o UDP. Puede funcionar a través de servidores proxy y NAT
atravesando
Įrewalls.
El méto do de conexión se realiza via las interfaces TUN/TAP, donde la primera esta basada en
túnel
IP de capa 3 y la segunda en Ethernet TAP de capa 2. También se pueden utilizar librer´ıas de

compresión
de datos como LZO (Lempel-Ziv-Oberhumer) .
El puerto que utiliza OpenVPN de forma oĮcial es el 1194. Además el uso de protocolos de red
comunes
(TCP/UDP) hacen una buena alternativa a IPSec en situaciones donde el ISP bloquee protocolos
VPN
espec´ıĮcos con la Įnalidad de suscribir a los clientes a soluciones costosas para beneĮcio propio.
7.1 .3. Comparación con IPSec
El Cuadro 7.1 muestra un resúmen comparativo de OpenVPN frente a IPSec.
IPSec OpenVPN
Estandar VPN Aún desconocido y no compatible con IPSec
Hardware variado Solo en computadoras
Tecnolog´ıa conocida y probada Tecnolog´ıa nueva y en crecimiento
ModiĮcación compleja de la pila IP Tecnolog´ıa sencilla
Requiere modiĮcaciones al kernel Interfaces de red y paquetes estandar
Permisos de administrador Se ejecuta en espacio de usuario
Problemas con direcciones dinámicas Traba ja con servidor DNS dinámicos
Varios puertos y protocolos de uso Utiliza un solo puerto del Įrewall
Cuadro 7.1 : Comparación entre IPSec y OpenVPN
El Cuadro 7.1 es una comparativa entre OpenVPN e IPSec. La mayor venta ja del primero respecto
al segundo, es la facilidad de uso y puesta en marcha.

7.1 .4. Seguridad en OpenVPN
Para encriptar datos se usan contraseȂnas o claves de encriptación. OpenVPN tiene dos modos
considerados seguros, uno basado en claves estáticas pre compartidas y otro en SSL/TLS usando
certiĮcados y claves RSA.
Cuando ambos lados usan la misma clave para encriptar y desencriptar los datos, se esta usando el
mecanismo conocido como ͞clave simétrica͟ y dicha clave debe ser instalada en todos los equipos
que
formarán parte en la conexión VPN.
Si bien las claves asimétricas RSA son la opción más segura, las claves estáticas cuentan con la
venta ja
de ser mucho más simples.
Encriptación simétrica y claves pre compartidas
Siempre quien posea la clave puede desencriptar el tráĮco de paquetes, por lo que si esta resulta
comprometida, el tráĮco completo de la organización se ver´ıa afectado, ya que identiĮcar´ıa al

intruso
como un integrante más de la VPN.
Es por ello que los mecanismos que utiliza IPSec cambian las claves cada cierto per´ıodo de tiempo
asociando a las mismas un ͞tiempo de vida͟ , como se ha visto en el Cap´ıtulo 6.
Encriptación asimétrica con SSL/TLS
SSL/TLS usa una de las mejores tecnolog´ıas de encriptación para asegurar la identidad de los
integrantes de la VPN. Cada integrante tiene dos claves, una pública y otra privada.
La pública es distribuida y usada por cualquiera para encriptar los datos que serán enviados a la
contraparte quien conoce la clave privada, que es la única que sirve para desencriptar los datos. El
par
de claves pública y privada, se generan a partir de algoritmos matemáticos que aseguran que
solo con la
clave privada es posible leer los datos originales.

Seguridad SSL/TLS
Las bibliotecas SSL/TLS son parte del sofware OpenSSL, que viene instalado por defecto en
casi todas las distribuciones de Linux y OpenBSD , e implementan mecanismos de encriptación y
autenticación basados en certiĮcados. Los certiĮcados generalmente son emitidos por entidades
de reconocida conĮabilidad aunque también se pueden emitir unos propios (ver Sección 6.2.2
para más
detalles) y usarlos en la VPN. Con un certiĮcado Įrmado, el dueȂno del mismo es capaz de probar
su
identidad a todos aquellos que conf´ıen en la autoridad certiĮcadora que lo ha emitido.
7.1 .5. Ventajas y desventajas
OpenVPN provee seguridad, estabilidad y comprobados mecanismos de encriptación sin tener la
complej idad de otras soluciones VPN como IPsec, por ejemplo. Además ofrece ventajas que van
más
allá que cualquier otra solución como se listan a continuación:
Posibilidad de implementar dos modos básicos en capa 2 o capa 3 con lo que se logran túneles
capaces de enviar información en otros procolos no-IP como IPX o broadcast (NETBIOS) .
Protección de los usuarios remotos. Una vez que OpenVPN ha establecido un túnel el Įrewall de
la
organización protegerá el equipo remoto aun cuando no es un equipo de la red local.
Las conexiones con OpenVPN pueden ser realizadas a través de casi cualquier Įrewall. Si se posee
acceso a Internet y se puede acceder a sitios HTTPS , entonces un túnel OpenVPN deber´ıa
funcionar
sin ningún problema.
Soporte para proxy. Funciona a través de proxy y puede ser conĮgurado para ejecutar como un
servicio TCP o UDP y además como servidor (simplemente esperando conexiones entrantes) o
como cliente (iniciando conexiones) .
Solo un puerto en el Įrewall debe ser abierto para permitir conexiones, dado que desde OpenVPN
2.0 se permiten múltiples conexiones en el mismo puerto TCP o UDP.

Las interfaces virtuales (tun0, tun1 , etc.) permiten la implementación de reglas de Įrewall muy
espec´ıĮcas.
Todos los conceptos de reglas, restricciones y reenv´ıo pueden ser utilizados con túneles
OpenVPN.
Alta Ňexibilidad y posibilidades de extensiónmediante scripting. OpenVPN ofrece numerosos

puntos
para ejecutar scripts individuales durante su arranque.
Soporte transparente para IPs dinámicas. Se elimina la necesidad de usar direcciones IP estáticas
en ambos lados del túnel.
Ningún problema con NAT. Tanto los clientes como el servidor pueden estar en la red usando
solamente IPs privadas.
Instalación sencilla en cualquier plataforma. Tanto la instalación como su uso son simples.
DiseȂno modular. Se basa en un buen diseȂno modular con un alto grado de simplicidad tanto en
seguridad como en red.
Se puede tomar como una desventaja que no es IPSec-compatible siendo que justamente IPSec es
el
estándar para soluciones VPN. Además existe aún poca gente que conoce cómo usar OpenVPN.
No posee
interfaz gráĮca. Todav´ıa no existen soluciones en ca ja cerrada, solo se pueden establecer

conexiónes entre
computadoras, pero ya se están desarrollando soluciones de este tipo, que separan las
conexiones VPN
de los hosts.
7.2. ConĮguración en Linux
A pesar de que existe una versión de OpenVPN para sistemas Windows, incluso con una interfaz
gráĮca que simpliĮca un poco las cosas, en esta sección se explicarán los pasos para la
conĮguración ba jo
Linux, ya que son semejantes en cualquier sistema.

Primero se describirán los paquetes de software necesarios la instalación de OpenVPN, para la
generación de claves para el servidor y los clientes. Finalmente se detallarán los archivos de
conĮguración
para ambos extremos.
7.2.1 . Instalación de software
Para tener todos los componentes necesarios para conĮgurar OpenVPN, se deben instalar los
siguientes
paquetes de software (algunos sistemas los traen instalados) :
OpenSSL.
LZO (opcional si se requiere compresión) .
OpenVPN.
Controlador tun/tap (ya vienen incluidos en el kernel a partir de la versión 2.4.7) .
7.2.2. Creación de certiĮcados y claves RSA
Existen dos formas de conseguir seguridad en una VPN con OpenVPN, uno basado en SSL/TLS
mediante certiĮcados y claves RSA y otro en mediante claves estáticas pre compartidas.
Se utilizará OpenSSL para contruir los certiĮcados y claves RSA. Además, se creará un certiĮcado
raiz propio, por lo que la SA (Security Association) será el mismo servidor local. Los pasos para
crearlos
se resumen en el listado siguiente:
1 . Crear un certiĮcado CA con el cual se Įrmarán y/o revocarán certiĮcados de clientes.
2. Crear un certiĮcado y una clave pública para los clientes.
3. Firmar ese certiĮcado usando el certiĮcado CA.
4. Distribuir la clave y certiĮcados a los clientes.
5. ConĮgurar los scripts del servidor y de los clientes.
Para empezar, OpenVPN cuenta con varias herramientas y scripts que permiten cumplir con los
primeros tres pasos, pero antes se deben crear los directorios y copiar los archivos de ejemplo y
scripts.
gus t avo @was a : ~ $ sudo mkdi r / e t c / ope nvpn
gus t avo @was a : ~ $ sudo mkdi r / e t c / ope nvpn / keys
gus t avo @was a : ~ $ sudo cd / e t c / openvpn /
gus t avo @was a : / e t c / o penvpn$ sudo cp / usr / share / doc / openvpn / e xampl e s / easy -
rsa / 2 . 0/ / e t c / openvpn /
Luego editar el archivo ͞vars͟ solo cambiando las opciones siguientes que aparecen en la
ConĮguración
17.
ConĮguración 17 Parámetros que deben modiĮcarse en el archivo ͞vars͟ .
1 e xport KEY_ COUNTRY =" AR "
2 e xport KEY_PRO VI NCE =" TUCUMAN "
3 e xport KEY_ CI TY =" SMT "
4 e xport KEY_ ORG =" Proye c t o "
5 e xport KEY_EMAI L =" gus t avo @ s upe rhi j i t us . red . lan "
Luego se debe obtener permiso de superusuario y ejecutar el script (o establecer los permisos
adecuados
para que el usuario pueda escribir en todo el directorio) . Hacemos lo siguiente:
gus t avo @was a : / e t c / o penvpn$ sudo su
ro o t @was a : / e t c / ope nvpn # s ourc e . / vars
NOTE : I f you run . / clean - all , I wi l l be do ing a rm - rf on / e t c / ope nvpn / keys
ro o t @was a : / e t c / ope nvpn # . / clean - all
ro o t @was a : / e t c / ope nvpn # exi t
gus t avo @was a : / e t c / o penvpn$
Ahora se intenta crear la clave Diĸe-Hellman con el script ͞build-dh͟ lo cual tardará varios
minutos:
ro o t @was a : / e t c / ope nvpn # . / bui ld - dh
Gene rat i ng DH parame t e rs , 1 024 bi t l ong saf e prime , gene rat o r 2

Thi s is go ing t o take a l ong t ime
. . . . . . . . . . . . . . . . . . . . . . . . + . . . . . . . . . . . . . . . . . . ++* ++* ++ *
ro o t @was a : / e t c / ope nvpn #
Luego se crea el certiĮcado para la CA:
ro o t @was a : / e t c / ope nvpn # . / bui ld - ca
Gene rat i ng a 1 024 bi t RSA pri vat e key
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . + +++ ++
. . . . . . . . . . ++++++
wri t i ng new pri vat e key t o ͛ ca . key ͛
-----
-----
Count ry Name ( 2 l e t t e r c ode ) [ AR ] :
St at e or Provi nc e Name ( f ul l name ) [ TUCUMAN ] :
Lo cal i t y Name ( eg , c i t y ) [ SMT ] :
Organi zat i on Name ( eg , c ompany ) [ Proye c t o ] :
O rgani zat i onal Uni t Name ( eg , s e c t i on ) [ ] :
Common Name ( eg , your name or your s erver ͛ s ho s t name ) [ Proye c t o CA ] :
Emai l Addre s s [ gus t avo @ s upe rhi j i t us . red . lan ] :
De esta manera se han creado los siguientes archivos en el directorio ͞keys͟ :

ca.crt
ca.key
dh1024.pem
Para generar el par CertiĮcado/Clave del servidor, se utiliza el siguiente comando:
ro o t @was a : / e t c / ope nvpn # . / bui ld - key - s e rve r openvpn - s e rve r
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ++++++
. . . ++++++
wri t i ng new pri vat e key t o ͛ openvpn - s e rve r . key ͛
-----
-----
Common Name ( eg , your name or your s erver ͛ s ho s t name ) [ openvpn - s e rver ] :

A chal l enge pas s word [ ] :
An opt i onal c ompany name [ ] :
Us ing c onf i gurat i on f rom / e t c / openvpn / o t ro / opens s l . cnf
Che ck t hat t he reque s t mat che s t he s i gnat ure
S i gnat ure ok
The Sub j ec t ͛ s Di s t i ngui s hed Name i s as f o l l ows
c o unt ryName : PRI NTABLE : ͛ AR ͛
s t at e OrP ro vi nc e Name : PRI NTABLE : ͛ TUCUMAN ͛
l o cal i t yName : PRI NTABLE : ͛ SMT ͛
o rgani zat i onName : PRI NTABLE : ͛ Proye c t o ͛
c ommonName : PRI NTABLE : ͛ openvpn - s erver ͛
emai lAddre s s : I A5 STRI NG : ͛ gus t avo @ s upe rhi j i t us . red . lan ͛
Ce rt i f i cat e i s to be c e rt i f i ed unt i l Oc t 22 02 : 34 : 42 201 8 GMT ( 3650 days )
Sign t he c e r t i f i c at e ? [y/ n ] : y
1 out of 1 c e r t i f i c at e reque s t s c ert i f i ed , c ommi t ? [ y/ n ] y
Wri t e out dat abas e wi t h 1 new ent ri e s
Dat a Bas e Updat ed
El parámetro que importa es el Common Name, dado que el mismo será utilizado en la
conĮguración
de los clientes. El script anterior ha creado los siguientes archivos:
openvpn-server.crt
openvpn-server.csr
openvpn-server.key
Ahora se debe crear el par CertiĮcado/Clave de los clientes, de la siguiente manera:
ro o t @was a : / e t c / ope nvpn # . / bui ld - key openvpn - c l i e nt

. . . . . . . . . ++++++
. . . ++++++
wri t i ng new pri vat e key t o ͛ openvpn - c l i ent . key ͛
-----
-----
Common Name ( eg , your name or your s erver ͛ s ho s t name ) [ openvpn - c l i e nt ] :
A chal l enge pas s word [ ] :
An opt i onal c ompany name [ ] :
Us ing c onf i gurat i on f rom / e t c / openvpn / o t ro / opens s l . cnf
Che ck t hat t he reque s t mat che s t he s i gnat ure
S i gnat ure ok
The Sub j ec t ͛ s Di s t i ngui s hed Name i s as f o l l ows
c o unt ryName : PRI NTABLE : ͛ AR ͛
s t at e OrP ro vi nc e Name : PRI NTABLE : ͛ TUCUMAN ͛
l o cal i t yName : PRI NTABLE : ͛ SMT ͛
o rgani zat i onName : PRI NTABLE : ͛ Proye c t o ͛
c ommonName : PRI NTABLE : ͛ openvpn - cl i ent ͛
emai lAddre s s : I A5 STRI NG : ͛ gus t avo @ s upe rhi j i t us . red . lan ͛
Ce rt i f i cat e i s to be c e rt i f i ed unt i l Oc t 22 03 : 0 1 : 24 201 8 GMT ( 3650 days )
Sign t he c e r t i f i c at e ? [y/ n ] : y
1 out of 1 c e r t i f i c at e reque s t s c ert i f i ed , c ommi t ? [ y/ n ] y
Wri t e out dat abas e wi t h 1 new ent ri e s
Dat a Bas e Updat ed
De esta manera se obtienen los siguientes archivos:
openvpn-client.crt
openvpn-client.csr
openvpn-client.key
Ahora queda determinar qué archivos quedan en el servidor y cuales deben ser enviados a los
clientes.
En la tabla 7.2 se muestran los archivos generados y la ubicación de los mismos

Cuadro 7.2: Archivos generados y ubicaciones para una conexión con OpenVPN.
7.2.3. ConĮguración del servidor
Para realizar la conĮguración del servidor, se debe crear un archivo llamado ͞server.conf͟ en el
mismo
directorio que se ha traba jado para generar las claves, cuyo contenido puede ser el de la
ConĮguración
18.
ConĮguración 18 Ejemplo de server.conf para OpenVPN.
1 port 1 1 94
2 pro t o udp
3 dev tun
4 ca keys / ca . crt
5 c ert keys / openvpn - s e rve r . crt
6 key keys / openvpn - s e rve r . key
7 dh keys / dh1 024 . pem
8 s e rver 1 0 . 8 . 0 . 0 2 5 5 . 2 5 5 . 2 5 5 . 0
9 i f conf ig - pool - pe rs i s t ipp . t xt
10 ke e pal i ve 1 0 1 20
11 comp - lzo
12 pers i s t - key
13 pers i s t - tun
14 verb 3
7.2.4. ConĮguración del cliente
Para la conĮguración del cliente se utiliza el archivo de conĮguración ͞client.conf͟ que se

muestra en
la ConĮguración 19.
7.2.5. Directivas del Įrewall
Para dejar pasar el tráĮco de datos de OpenVPN, se debe habilitar el paso por las nuevas
interfaces
que se crean al iniciar el servidor y recibir una conexión de algún cliente. En este caso se van a
crear
interfaces tunX, donde X representa el número de la interfaz o nueva conexión de un cliente. Los
siguientes
comandos permiten que iptables deje circular la información que pase por estas interfaces:
ro o t @was a : / e t c / ope nvpn # i pt abl e s -A I NPUT - i t un+ - j ACCEPT
ro o t @was a : / e t c / ope nvpn # i pt abl e s -A FORWARD -i t un+ - j ACCEPT
ro o t @was a : / e t c / ope nvpn # i pt abl e s -A OUTPUT - o tun+ - j ACCEPT
ro o t @was a : / e t c / ope nvpn # i pt abl e s -A FORWARD -o t un+ - j ACCEPT
Solo queda iniciar los servicios correspondientes en el servidor y el cliente, para establecer las
conexiones. En el servidor ejecutamos /etc/init.d/openvpn start, para levantar el demonio.
Supongamos el caso, que tenemos dos clientes, en el servidor deber´ıamos ver dos túneles
parecidos a
estos, al ejecutar el comando ifconĮg :
ConĮguración 19 Ejemplo de client.conf para OpenVPN.
1 c li ent
2 dev tun
3 pro t o udp
4 remo t e 1 0 . 8 . 0 . 1 1 1 94
5 res olv - re t ry inf ini t e
6 nobind
7 pers i s t - key
8 pers i s t - tun
9 ca keys / ca . crt
10 c ert keys / openvpn - c li ent . crt
11 key keys / openvpn - c l i ent . key
12 comp - lzo
13 verb 3
t un0 Link encap : UNSPEC HWaddr 00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00
ine t addr : 1 0 . 8 . 0 . 1 P - t - P : 1 0 . 8 . 0 . 2 Mask : 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5
UP P O I NTO PO I NT RUNNI NG NOARP MULTI CAS T MTU : 1 500 Me t r i c : 1
RX packe t s : 0 e rrors : 0 dropped : 0 ove rruns : 0 f rame : 0
TX packe t s : 0 e rrors : 0 dropped : 0 ove rruns : 0 carri e r : 0
c o l l i s i ons : 0 t xque ue l en : 1 00
RX byt e s : 0 ( 0 . 0 B ) TX byt e s : 0 ( 0 . 0 B )
t un1 Link encap : UNSPEC HWaddr 00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00
ine t addr : 1 0 . 8 . 0 . 6 P - t - P : 1 0 . 8 . 0 . 5 Mask : 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5
UP P O I NTO PO I NT RUNNI NG NOARP MULTI CAS T MTU : 1 500 Me t r i c : 1
RX packe t s : 0 e rrors : 0 dropped : 0 ove rruns : 0 f rame : 0
TX packe t s : 0 e rrors : 0 dropped : 0 ove rruns : 0 carri e r : 0
c o l l i s i ons : 0 t xque ue l en : 1 00
RX byt e s : 0 ( 0 . 0 B ) TX byt e s : 0 ( 0 . 0 B )
7.3. Clientes móviles con Windows
En esta sección se describen algunos detalles de conĮguración y ejecución. Además se

comprueba
la comunicación establecida entre un cliente móvil (con el sistema operativo Windows) y el
servidor
OpenVPN con Linux.
El esquema de conexión para los clientes móviles se muestra en la Figura 7.1 .
7.3.1 . Conexión a la red
Existe una versión compilada para Windows de OpenVPN, tanto el servidor como el cliente. Pero
además, se cuenta con una versión con interfaz gráĮca que provee al usuario de un ´ıcono de
conexión al
servidor en el área de notiĮcación, como se muestra en la Figura 7.2.
A través de esta herramienta es posible conectar con la red remota simplemente haciendo clic en
͞Conectar͟ . Luego se muestra la dirección IP asignada, el nombre de la red a la que se conecta

(que
puede ser conĮgurada por uno mismo) y la fecha y hora que se ha realizado la conexión.
7.3.2. ConĮguración del cliente
De la misma manera que en la conĮguración del cliente en la Sección 7.2.4, cada usuario requiere
un m´ınimo de conĮguración, que por cierto, se pueden extraer los ejemplos que provee el
paquete de
instalación.
Los archivos de ejemplo tanto para cliente como para servidor llevan la extensión .ovpn y se los
obtiene
del directorio ͞conĮg-examples͟ . El contenido del archivo de conĮguración del cliente puede
contener el
listado de la ConĮguración 20.
Como se indica en la ConĮguración 20, se utilizan certiĮcados para conectar al servidor, que
deben
ser generados y distribuidos como en la Sección 7.2.2

ConĮguración 20 Ejemplo de client.ovpn para OpenVPN en Windows.
1 c li ent
2 dev tun
3 pro t o udp
4 remo t e 1 9 2 . 1 6 8 . 0 . 2 1 1 94
5 res olv - re t ry inf ini t e
6 nobind
7 pers i s t - key
8 pers i s t - tun
9 ca ca . crt
10 c ert openvpn - c l i ent 1 . crt
11 key openvpn - c li ent 1 . key
12 comp - lzo
13 verb 3
Por lo tanto, los archivos que deben copiarse al directorio de conĮguración son los siguientes:
ca.crt
openvpn-client1 .key
openvpn-client1 .crt
Luego, al realizar la conexión, el cliente muestra un registro de los pasos que realiza desde el
intercambio de claves hasta la asignación de la dirección IP (Registro 3) .
Aunque el registro 3 muestra solo una parte de la salida en la interfaz gráĮca del cliente, se puede
ver
en el listado que se permite compresión de paquetes, luego se realiza el intercambio de claves y

Įnalmente
se establecen las direcciones IP y rutas correspondientes.
7.3.3. ModiĮcación de rutas
Para poder hacer pruebas de ͞ping͟ entre el equipo remoto y el servidor OpenVPN junto a la red
local, es necesario establecer las rutas correspondientes en el Įrewall, es decir en el equipo con
OpenBSD .
Wed Oct 29 14: 39: 33 2008 OpenVPN 2. 0. 9 Win32-MinGW [SSL] [LZO] built on Oct 1 2006
Wed Oct 29 14: 39: 33 2008 LZO compression initialized
Wed Oct 29 14: 39: 33 2008 Control Channel MTU parms [ L: 1542 D: 138 EF: 38 EB: 0 ET: 0 EL: 0 ]
Wed Oct 29 14: 39: 33 2008 Data Channel MTU parms [ L: 1542 D: 1450 EF: 42 EB: 135 ET: 0 EL: 0
AF: 3/1 ]
Wed Oct 29 14: 39: 33 2008 Local Options hash (VER=V4) : ͛ 41690919͛
Wed Oct 29 14: 39: 33 2008 Expected Remote Options hash (VER=V4) : ͛ 530fdded͛
Wed Oct 29 14: 39: 33 2008 UDPv4 link local: [undef]
Wed Oct 29 14: 39: 33 2008 UDPv4 link remote: 190. 30. 82. 251: 1194
Wed Oct 29 14: 39: 33 2008 TLS: Initial packet from 190. 30. 82. 251: 1194, sid=f0f3ce6e b77f8414
Wed Oct 29 14: 39: 33 2008 VERIFY OK: depth=1,
/C=AR/ST=Tucuman/L=SMT/O=Cissu/CN=Cissu_CA/emailAddress=gustavo@superhij itus. red. lan
Wed Oct 29 14: 39: 33 2008 VERIFY OK: depth=0,
/C=AR/ST=Tucuman/L=SMT/O=Cissu/CN=Cissu_CA/emailAddress=gustavo@superhij itus. red. lan
Wed Oct 29 14: 39: 34 2008 Data Channel Encrypt: Cipher ͛ BF-CBC͛ initialized with 128 bit key
Wed Oct 29 14: 39: 34 2008 Data Channel Encrypt: Using 160 bit message hash ͛ SHA1͛ for HMAC
authentication
Wed Oct 29 14: 39: 34 2008 Data Channel Decrypt: Cipher ͛ BF-CBC͛ initialized with 128 bit key
Wed Oct 29 14: 39: 34 2008 Data Channel Decrypt: Using 160 bit message hash ͛ SHA1͛ for HMAC
authentication
Wed Oct 29 14: 39: 34 2008 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA,
1024 bit RSA
Wed Oct 29 14: 39: 34 2008 [Cissu_CA] Peer Connection Initiated with 190. 30. 82. 251: 1194
Wed Oct 29 14: 39: 35 2008 SENT CONTROL [Cissu_CA] : ͛ PUSH_REQUEST͛ (status=1)
Wed Oct 29 14: 39: 35 2008 PUSH: Received control message: ͛ PUSH_REPLY, route 192. 168. 0. 0
255. 255. 255. 0,
route 192. 168. 2. 1, topology net30, ping 10, ping-restart 120, ifconfig 192. 168. 2. 6 192. 168. 2.
5͛
...
Registro 3: Estableciendo la conexión desde el cliente OpenVPN.
Para esto se ejecuta el siguiente comando:

$ sudo rout e add 1 9 2 . 1 6 8 . 2 . 0 / 24 1 9 2 . 1 6 8 . 0 . 2
De esta manera se agrega una nueva entrada a la tabla de ruteo que se puede ver a continuación:
En una terminal de Windows también se puede ver que el cliente móvil alcanza la red local a la
cual
se ha conectado mediante el servidor OpenVPN. En la Figura 7.3 se puede ver una captura de
pantalla
que muestra el comando ͞ipconĮg͟ con la dirección IP asignada (junto a la dirección local) , y el
comando
͞ping͟ al Įrewall con OpenBSD donde se han asignado las rutas.

Figura 7.3: Prueba del alcance del equipo remoto a la nueva red.
Puede verse entonces, que el equipo remoto no solo puede alcanzar al servidor OpenVPN que
asigna
la dirección a la red 192.168.2.0 sino que también puede acceder a la red 192.168.0.0 mediante
un simple
ruteo.
Esta normativa de asignar direcciones de red diferentes sirve para distinguir a los usuarios
remotos
de los usuarios de la red local, pero aún as´ı permitiendo a los primeros, el acceso a todo o parte
de la red
de la empresa.
7.3.4. Pruebas de transferencia
Para las pruebas de transferencia se ha utilizado el protocolo SMB (Server Message Block) ,
mediante
el monta je de una unidad virtual del servidor con el contenido compartido del equipo remoto.
Luego se
copia un archivo de música al directorio personal del servidor como se muestra en la Figura 7.4,
en el que
se muestra la ubicación de origen, destino y velocidad de transferencia.
El cliente móvil puede utilizar todos los servicios de la red local como si de un usuario de la misma
se tratara.
7.4. Conclusión
OpenVPN es un producto de software diseȂnado y desarrollado para simpliĮcar los problemas que
se tienen con protocolos complejos como IPSec. Esto hace que se convierta en una solución
alternativa
al estándar, y gracias a que es de código abierto, se encuentra siempre en constante

actualización y
desarrollo.
Otra venta ja, es que OpenVPN se convirtió en una alternativa a PPTP (Point to Point Tunneling
Protocol) , ya que permite la conexión de usuarios móviles utilizando el software cliente que
además esta
disponible para cualquier sistema operativo, y salvando los problemas de seguridad de PPTP (Ver
más
detalles en Sección 4.1) .
Finalmente se puede decir que OpenVPN presenta una muy buena alternativa de fácil
administración
y conĮguración para establecer conexiones seguras. Aunque no supera la seguridad y robustez

que tiene
IPSec, la simplicidad de uso ha impulsado que este desarrollo de libre distribución vaya
adquiriendo cada
vez más adeptos.
Cap´ıtulo 8
Alternativas y costos de
implementación
Ningún paquete de software que se ha visto a lo largo de este informe puede afrontar todos los
problemas y requisitos posibles que se pueden encontrar al implementar una red privada virtual.
En este
cap´ıtulo se plantean y describen brevemente las soluciones alternativas (o complementarias en

algunos
casos) a los estándares descriptos y probados anteriormente.
Además se plantearán los criterios que se utilizan al evaluar la mejor solución VPN para una
determinada empresa, junto a los costos de instalación y mantenimiento del sistema. Esto puede
variar
con el pa´ıs, región, tamaȂno de la empresa, alcance de la VPN, seguridad requerida, entre
muchos otros
factores que intervienen en cada caso. También se evaluarán las diferentes soluciones en cuanto
a costos
y las mejoras que implicar´ıan su implementación.
8.1 . Soluciones comerciales
Dentro de la amplia gama de posibilidades que existen para implementar seguridad en las redes
utilizando VPNs, existen por supuesto, las soluciones comerciales de hardware propietario.
VPNC 1 , es el Consorcio VPN. Un grupo de fabricantes que analiza y certiĮca los productos VPN
comerciales. Básicamente, VPNC ofrece informes de compatibilidad de los productos de sus

miembros.
Este consorcio ha sido de gran ayuda para la cooperación entre las empresas, y para que dichos
productos
sean diseȂnados en base a los estándares de internet.
En las siguientes secciones se describirán brevemente los equipos que ofrecen soluciones VPN de
las
empresas más importantes en cuanto a redes y seguridad.
Cisco ASA 5500 Series SSL/IPsec VPN Edition
Es un servidor VPN que ofrece acceso a la red corporativa tanto a usuarios móviles, oĮcinas
remotas,
clientes, etc. Se integra en el equipo funcionalidad de Įrewall, que detecta usuarios no

autorizados y
seguridad a la red.
Existen varios modelos dentro de la serie; diferenciándose en el número de conexiones

simultáneas
admitidas, que van desde 10 hasta 10.000. Por supuesto que el costo de los equipos, también
crece con el
número de usuarios que admiten al mismo tiempo.
Por ejemplo, la licencia para un equipo que admite veinticinco conexiones VPN (modelo ASA5500-
SSL-25) , llega a US$ 2,682.53 (precio de Estados Unidos) .
Cisco VPN 3002 Hardware Client - pasarela VPN
Es un dispositivo separado del computador, que funciona con todos los sistemas operativos, ya
que
no interĮere con el procesamiento del ordenador. Se utiliza para comunicar a los clientes VPN con
la red
1Más información: http://www.vpnc.org
corporativa de su empresa. Este equipo está preparado para conectar desde estaciones de traba
jo, hasta
servidores, impresoras, etc.
El coste de este producto es de US$598,00.
Linksys RV082
Ruteador con conexión a Internet compartida de alta Įabilidad y conmutador de ocho puertos
para negocios pequeȂnos; Consta de puertos de Internet duales para el equilibrio de carga y
conexiones
redundantes. Conecta de forma segura hasta cincuenta usuarios (de QuickVPN) remotos o
itinerantes a
la red de su oĮcina mediante una VPN. Soporta también cinco conexiones PPTP.
El coste en Argentina de este router es de US$514,00.
Router Draytek Vigor 2930
Un equipo similar al anterior. Posee 4 puertos LAN y 2WAN para balanceo de carga. Tiene
capacidad
para soportar hasta cien túneles VPN; soporta protocolos IPSec/PPTP/L2TP. Posee Įrewall, entre
otras
caracter´ısticas.
El coste en Argentina de este router es de US$375,00.
8.2. Soluciones alternativas
Actualmente existen varias soluciones alternativas a las escritas en este informe y a las soluciones
comerciales de grandes empresas. En esta sección se harán mención de dichas soluciones que
pueden ser
gratuitas o de libre distribución, pero no estándar en el mundo de las redes privadas virtuales.
En cuanto a las aplicaciones gratuitas que existen para establecer una VPN entre dos puntos, la
más
conocida por los amantes de los juegos en red, es LogMeInHamachi. Otra solución que se puede
encontrar,
más orientado al acceso a escritorio remoto es DESKTRA (Virtual Private Desktop) .
Finalmente se pueden rescatar algunos proyectos de código abierto que intentan implementar
una
red privada virtual minimizando la tarea de conĮguración y administración, sacriĮcando

importantes
caracter´ısticas en cuanto a performance y seguridad de una red corporativa.
8.2.1 . LogMeIn Hamachi
Hamachi es un servicio de VPN basado en paquetes UDP que se instala cada equipo (funciona en
Windows, MacOSX y Linux) y permite la conexión rápida y segura de los mismos de manera que
parezcan
estar en una misma red.
De las caracter´ısticas que tiene, la que más se destaca es su facilidad de uso. Nada más crear una
red
e invitar a otros equipos (mediante contraseȂna) a unirse, o directamente ingresar en una red
previamente
creada por algún otro usuario. Por su parte, la lista oĮcial de caracter´ısticas son las siguientes:
Permite compartir archivos y carpetas mediante SMB (Server Message Block) .
Funciona sin tener que conĮgurar Įrewall.
Utiliza cifrado y autenticación.
Gratuito para uso no comercial.
Funcionamiento
En el momento de instalar el software, se crea una interfaz de red virtual en el sistema, que va a
realizar el tunelado de la información que se env´ıe por la VPN (o a través del software en este
caso) .
Cada cliente establece una conexión de control con el cluster servidor, en el que realiza una
secuencia
de identiĮcación de usuario, seguida de un proceso de descubrimiento y sincronización de

estado. El
descubrimiento es utilizado para determinar la topolog´ıa de la conexión a Internet del cliente, es

decir,
si se encuentra tras un Įrewall o servidor NAT. El paso de sincronización se realiza para ver los
clientes
conectados a la misma red.
Cuando se conectan o desconectan clientes, el servidor emite instrucciones a los otros nodos de la
red
para que inicien o detengan túneles con el cliente. Cuando se establecen túneles entre los nodos,
Hamachi
utiliza una técnica de NAT transversal asistido por servidor, similar a ͞UDP hole punching͟
(perforadora
de agujeros UDP) .
En algunas conĮguraciones NAT no esta garantizado el funcionamiento de Hamachi, que según su
desarrollador, atraviesa con éxito el 95 por ciento de conexiones P2P.
Hamachi asigna a cada cliente una dirección IP de la red 5.0.0.0/8, que al autenticarse por
primera
vez se le asigna una dirección única y luego se la asociada con la clave de cifrado pública del
cliente.
Utilidad
Como se ha mencionado anteriormente, Hamachi se utiliza habitualmente para juegos en red y

para la
administración remota. De esta manera, cada usuario que se conecte mediante el cliente, puede
crear una
nueva red, para jugar partidas en l´ınea con juegos que solamente funcionan en redes LAN. La
Figura 8.1
muestra la interfaz de usuario para crear una nueva red. La interfaz para conectarse a una red
existente
es similar
La utilización de contraseȂna solamente se usa para evitar conexiones no deseadas, de manera
que se
puede distribuir la contraseȂna (como si de una clave pública se tratara) entre los usuarios de
conĮanza
para que puedan acceder a la red.
8.2.2. DESKTRA Virtual Private Desktops
Este software que se distribuye de forma gratuita para usos no comerciales, permite la conexión a
escritorios remotos utilizando técnicas que se utilizan en las VPN.
Se puede considerar DESKTRA como un software VNC (Virtual Network Computing) , pero diĮere
en las siguientes caracter´ısticas principales (algunas comunes a VNC) :
Protección por contraseȂna.

Encriptación mediante AES (Advanced Encryption Standard) .
No requiere modiĮcación en el Įrewall ni en el sistema.
La desventa ja de este sistema es que solamente funciona en equipos conWindows y que además
deben
instalarse dos paquetes de software, el cliente en un extremo y el servidor en otro. Esto puede
resultar
poco práctico, ya que si se quiere conectar a un escritorio remoto, la mejor solución estándar es
utilizar
VNC .
Su difusión es muy limitada, principalmente por la desventa ja descripta anteriormente y además

por
las mejores alternativas que existen en el mercado.
8.2.3. VTun
VTun o túnel virtual es una solución VPN escrita por Maxim Krasnyansky, que utiliza interfaces de
túneles en los que los datos se cifran al entrar en el túnel y se descifran al salir por el túnel del
otro
extremo.
Su funcionamiento se basa en encapsular paquetes dentro de paquetes IP y utilizar redes IP para
encaminar dichos paquetes encapsulados de una extremo a otro del túnel. Cada extremo tiene
información
sobre el otro, como la dirección de red legible y la red que esta detrás. De esta manera, si un
paquete
llega con destino a la red que se encuentra del otro lado del túnel, se lo encamina por la interfaz
del túnel
local.
El kernel es el encargado de encapsular y redireccionar el nuevo paquete a la dirección conocida

del
otro extremo del túnel.
Funcionamiento
VTun utiliza el driver TUN/TAP como punto de acceso lógico al túnel. De esta manera, los
paquetes
encaminados al driver creado, en realidad via jan al otro extremo del túnel. La siguiente salida en
pantalla
muestra la denominación de la interfaz que crea el sistema para realizar este tipo de conexiones:
t un0 : f lags =8051 < UP , PO I NTO PO I NT , RUNNI NG , MULTI CAST > mt u 1 492
groups : tun egre s s
ine t 1 90 . 30 . 8 2 . 2 5 1 - - > 2 0 0 . 3 . 60 . 1 5 ne t mas k 0 xf f f f f f f f
En el ejemplo anterior se puede ver que la interfaz utilizada recibe la dirección IP local y del
router,
que se utiliza al establecer una conexión con el proveedor de acceso a Internet . Esto no
representa una
creación de VTun pero es un ejemplo aproximado.
VTun utiliza un daemon de ejecución denominado vtund que es el responsable de la inicialización
y recepción de las conexiones de los túneles, además del mantenimiento de cualquier túnel
establecido.
Puede traba jar en modo servidor o cliente, según sea su conĮguración. Si se lo conĮgura en
modo servidor,
este espera conexiones entrantes de los clientes y enviará los parámetros de túnel conĮgurados
de vuelta
al cliente. Si en cambio se lo conĮgura en modo cliente, el daemon intentará iniciar una conexión
de túnel
con el servidor especiĮcado.
Métodos de cifrado
En cualquier implementación de VPN, es importante que tener presente tanto el cifrado como la
autenticación de los datos para asegurar el máximo nivel de seguridad e integridad de dichos
datos.
VTun utiliza OpenSSL para implementar el cifrado y la autenticación, aunque para el cifrado
espec´ıĮcamente se utiliza el algoritmo BlowĮsh (desarrollado por Bruce Schneier) , diseȂnado
para ser
muy rápido y eĮciente. Esto lo hace ideal para VTun, porque los paquetes deben cifrarse y
descifrarse
rápidamente, sin introducir latencia adicional en una conversación entre redes.
BlowĮsh es un algoritmo simétrico, lo que signiĮca que utiliza la misma clave para cifrar y para
descifrar los datos.
Para la protección de la integridad, VTun utiliza md5 para crear una dispersión de clave de 128
bits
a partir de una frase clave (los datos) .
Para mejorar la seguridad, cuando un cliente se autentica en el servidor, se utiliza la autenticación
basada en desaf´ıos, que utiliza una secuencia como sigue:
1 . El cliente inicia la conexión con el servidor.
2. El servidor realiza un desaf´ıo que consiste en cifrar algunos datos aleatorios con la clave secreta
que
ambos comparten, y se los env´ıan al cliente.
3. El cliente lo recibe y descifra con la clave secreta, calcula una dispersión de los datos aleatorios
y
se la env´ıa al servidor.
4. El servidor recibe estos datos y los compara con un hash de los datos enviados originalmente. Si
coinciden, el cliente queda autenticado, sino lo rechaza.
Túneles soportados
VTun soporta cuatro diferentes tipos de túneles, que dependen del tipo de VPN que se quiera
implementar, los túneles IP, ethernet, en serie y pipe.
Los túneles pueden utilizar TCP o UDP para el transporte. Si se utiliza TCP se tiene más
sobrecarga de
conexión, pero garantiza la entrega de datos. Esto se puede solucionar aȂnadiendo algún tipo de
compresión.
Por otra parte, si se utiliza UDP se tienen túneles más rápido que con TCP y utilizan menos ancho
de banda. El problema es que no garantizan la entrega de paquetes, ni tiene mecanismos de

control de
Ňujo, por lo que los paquetes VPN deber´ıan implementar estas caracter´ısticas sobre UDP.
Los túneles IP transportan sólo tráĮco IP, y se los puede utilizar para establecer conexiones red a
red y host a red. En cambio los túneles ethernet se utilizan para crear túneles que transportan
tramas
ethernet, de manera que no solo pueden enviar paquetes IP, sino cualquier otro protocolo que se
ejecute
de forma nativa sobre ethernet, como IPX. Los túneles IP utilizan la interfaz TUN, mientras los
túneles
ethernet utilizan TAP.
Los túneles en serie utilizan PPP (Point to Point Protocol) o SLIP para ofrecer conexión PPP virtual
de un extremo del túnel al otro. En este modo no es necesario utilizar el soporte TUN/TAP del
kernel,
ya que PPP provee de su propia interfaz de red.
Los túneles pipe son una especie de implementación similar al pipe de los sistemas Unix, que se
utilizan
sin necesidad de levantar una interfaz de red, y pueden ser útiles para transportar archivos
directamente
entre dos equipos VTun.
Finalmente se puede decir que VTun es una buena solución para establecer rápidamente una
VPN
red a red o host a red, con poca utilización de recursos del sistema y además compatible con
varias
plataformas (Linux, OpenBSD , Solaris, etc. ) . Sin embargo, a pesar de estar basado en varios
estándares,
VTun no es compatible con los demás protocolos de túnel, que se debe a la forma en que el
cliente y el
servidor inician las conexiones.

8.2.4. cIPe
El paquete cIPe (Crypto IP Encapsulation) es sencillo y rápido, y ofrece la posibilidad de crear

túneles
para enviar paquetes IP cifrados sobre UDP.
cIPe consta de un módulo del kernel y una utilidad de administración a nivel de usuario como
daemon
(ciped) .
El módulo del kernel realiza varias operaciones relacionadas con la manipulación de los paquetes
IP,
como su transmisión y recepción y su cifrado utilizando cifrado simétrico. El módulo crea un

dispositivo
de red virtual que se puede conĮgurar y rutear de la misma manera que los demás dispositivos.
La utilidad a nivel de usuario sirve para realizar el intercambio de claves y conĮgurar el paquete
cIPe.
Este soporta dos cifrados simétricos, BlowĮsh e IDEA, y además se puede encapsular IP sobre IP o
como
túnel de paquetes OSI de capa 2 (ethernet, por ejemplo) .
Entre las desventa jas de cIPe se encuentra su ba jo nivel de utilización debido a su complej idad
de
uso y conĮguración, además que solo implementa dos algoritmos simétricos, uno de ellos
patentado. Por
otro lado, al no tener tanta información sobre la implementación, ni medidas de rendimiento y

análisis
de seguridad, hacen que su utilización sea muy limitada y poco seria para entornos profesionales
que
requieren de un determinado grado de seguridad en sus redes.
Sin embargo, cIPe se considera un proyecto de código abierto en crecimiento y con una buena
integración con los sistemas operativos Linux, que de alguna manera (si se mejoran los aspectos
negativos)
puede llegar a ser utilizado de forma masiva.

8.2.5. tinc
tinc es un paquete ligero que ofrece funcionalidad VPN básica, disponible para Linux, BSD y
Solaris,
que se distribuye de forma libre ba jo licencia GPL de GNU. Fue diseȂnado para traba jar
totalmente en el
espacio del usuario, de manera que los errores en la implementación no causarán que el kernel
falle.
tinc utiliza BlowĮsh en modo CBC como cifrado simétrico, y para obtener las claves para este
cifrado,
utiliza algoritmos asimétricos de clave pública (como RSA) .
Los protocolos subyacentes que utiliza para el transporte son TCP y UDP, en el que transmite
información de control y datos, respectivamente.
Una de las caracter´ısticas interesantes de tinc es el soporte de ruteo automático entre las
distintas
subredes que componen la VPN, ahorrando el traba jo que se tendr´ıa que hacer para conĮgurar
las rutas.
Nuevamente, al tratarse de un paquete en constante desarrollo por entusiastas en sus tiempos

libres,
se carecen de muchas caracter´ısticas como para competir con grandes jugadores como IPSec.
Además
resulta poco documentado y con poca información sobre su rendimiento y análisis de seguridad.
8.3. Situación real de ejemplo
En esta sección, una empresa Įcticia desea incrementar la seguridad de sus redes. Durante el
análisis se
detallarán los factores a tener en cuenta. Entre ellos se encontrarán la dispersión de las redes, la
necesidad
de clientes móviles, la disponibilidad de conexión a Internet por banda ancha, entre otros.
Además se plantearán situaciones reales que pueden presentarse al conĮgurar una VPN para la
empresa de ejemplo. Los costos y alternativas económicas son también parte de esta sección.
8.3.1 . Escenario
La empresa Empresa Ejemplo S.A. posee una casa central, ubicada en San Miguel de Tucumán, y
dos
sucursales; SucursalUno que se encuentra en Salta (capital) , y Sucursal Dos emplazada en San
Fernando
del Valle de Catamarca. También tiene empleados itinerantes, que se conectan al sistema de
gestión de
la central y a la base de datos de alguno de los tres puntos Įjos.
Luego de que la empresa sufriera ingresos no autorizados en una de sus redes, se dispuso
contratar a
una consultora para encontrar una solución a sus comunicaciones.
Los encargados de evaluar el funcionamiento de las redes de Empresa Ejemplo S.A. , se

encontraron
con los siguientes problemas:
La seguridad de la empresa no está totalmente consolidada. Se siguen utilizando algunos

protocolos
no seguros para la comunicación entre los empleados de las sucursales, por ejemplo SMTP y POP,
con el servidor de correo de la casa central.
Empresa Ejemplo S.A. tiene muchos puertos de servicios abiertos hacia internet , que solo son
utilizados por sus empleados itinerantes, o clientes. Esto eleva el nivel de vulnerabilidad.
Los datos de los clientes de Empresa Ejemplo S.A. están dispersos entre la casa central y sus
sucursales (no hay centralización de datos) , por lo que los empleados necesitan mucho tiempo
para
realizar su traba jo, ya que a veces requieren información que se encuentra en otra sucursal.
El número de empleados itinerantes creció en el último aȂno, por lo que algunos de ellos tienen
problemas para conectarse a la empresa, debido a una sobrecarga del servidor. Sumado a esto, el
protocolo que utilizan para la comunicación no es seguro

La Figura 8.2 muestra el modo actual de conexión de las sucursales y de los usuarios móviles; que
se
conectan a través de Internet.
8.3.2. Relevamiento
Al realizar el relevamiento de Empresa Ejemplo S .A. se obtuvo información de la situación, luego
se presentaron las opciones para la solución o mejora de las fallas encontradas; también se
procedió a
documentar el proceso.
Equipamiento
Se puede comenzar con el equipamiento de la casa central y las sucursales. En la casa central se
cuenta con terminales Workstation HP xw8600 y dos servidoHP ProLiant ML100 que se utilizan
para
servidor de archivos y aplicaciones, y para servicios Web y correo electrónico. Los terminales de
usuarios
cuentan con el sistema operativo Microsoft Windows Vista Home Premiun preinstalado, mientras
que los
servidores tienen Windows Server 2007 en cada equipo.
Las otras dos sucursales, cuentan con los mismos equipos para terminales de usuarios, pero con
un
solo servidor HP ProLiant ML100 en cada local. Cada servidor se utiliza para la conexión a Internet
y
para el reparto de correo electrónico local.
Los usuarios móviles de Empresa Ejemplo S .A. generalmente se conectan a la casa central
mediante la
interfaz Web en busca de información para los clientes, dado que rara vez se puede utilizar la
conexión a
escritorio remoto, porque se trata de un servicio que no deber´ıa estar disponible en Internet las
24 horas
del d´ıa.
Comunicaciones
En cuanto al esquema de conexión, la casa central cuenta con ADSL simétrico de 3 Mbps, y las
sucursales con ADSL común de 1 Mbps, porque no se consideraba que iba a ser necesario
comunicarse
entre las sucursales, nada más con consultar el servicio Web principal era suĮciente.
Para la comunicación se utilizaba un modem router ADSL provisto por el ISP (un Tainet CA81R)
para los tres locales. Este aparato cumple la función de NAT y de Įrewall para la toda la red, y se
conecta
a un Switch 3Com de 24 bocas en la casa central y de 16 en cada sucursal.
En algunos casos era necesario supervisar la utilización del acceso a Internet de cada empleado,
ya
que en determinados horarios resultaba imposible traba jar por el alto consumo de ancho de
banda que
tomaban las terminales con programas P2P durante las descargas.
Servicios
En la casa central se tienen servicios básicos de Web y correo electónico en un equipo, mientras
que
en el otro equipo se cuenta con servidor de archivos, utilizado para la documentación importante
de la
empresa y limitado a cada usuario protegiéndolo con contraseȂna.
Si un usuario móvil requiere de un archivo alo jado en el servidor, debe solicitar mediante
teléfono
o correo electrónico que se habilite el servicio por un per´ıodo de tiempo limitado. Esto es para
evitar
ingreso de intrusos a la red, ya que es servicio de acceso a escritorio remoto se encontrar´ıa

disponible
para toda la Internet.
En las sucursales se cuentan con servicio de correo electrónico y de archivos en un mismo equipo,
ya
que no hay tantos terminales conectados al mismo tiempo.
Para obtener acceso a la casa central se ha creado un formulario Web (en el servidor) en el que
cada usuario puede modiĮcar y obtener información de productos de la empresa, mediante su

nombre y
contraseȂna. Es decir, que el sitio web utilizado por la empresa para mostrar a los clientes, tiene la
misma
interfaz que la que utilizan sus empleados para obtener y modiĮcar información importante de
productos
y servicios.
8.3.3. Problemas encontrados
Luego de realizar el relevamiento de Empresa Ejemplo S .A. se encontraron algunos problemas en
cuanto a la estructura de la red de la empresa y el manejo de información vital.
En primer lugar se tiene en cuenta que la distancia de la casa central y de las sucursales es tal que
produce gran dispersión de la información, como si de varias empresas se trataran. La idea
general es
uniĮcar este tipo de información para que la empresa se vea identiĮcada por su casa central para
mejorar
la imagen corporativa.
En segundo lugar, en el acceso a la red, los empleados móviles tienen diĮcultades para encontrar
información precisa para distribuir a sus clientes, ya que no siempre pueden acceder a la red de la
empresa, y el formulario Web es demasiado limitado para la mayor´ıa de los casos. Por eso es
necesario
establecer una pol´ıtica de acceso para los terminales móviles, ya sea mediante el uso de equipos
portátiles
como de teléfonos móvil.
Finalmente, la administración de los equipos, los servicios y de la red, se hace muy dif´ıcil por la
dispersión que existe en el sistema de Empresa Ejemplo S .A. Por ejemplo, el correo electrónico
de
cada sucursal deber´ıa uniĮcarse con el servidor central (es decir, cada sucursal tiene su correo,
pero
son redireccionados al servidor central) , de la misma manera que el servidor de archivos, para que
la
seguridad sea fortalecida en un solo lugar. De esta manera se evita la redundancia de la

información, que
se repite en las sucursales y en la casa central, y la actualización de los mismos deben hacerse
mediante
copias de los archivos a cada sucursal, haciendo el traba jo menos dinámico y más tedioso.
8.3.4. Recomendaciones
Luego de conocer la situación actual de Empresa Ejemplo S .A. se procede con el listado de
recomendaciones realizadas por expertos en seguridad e infraestructura de red.
Infraestructura y equipos
En cuanto al equipamiento de Empresa Ejemplo S .A. se cuenta con equipos relativamente nuevos,
tanto en las terminales como en los servidores, por lo que no es necesaria la adquisición de
nuevas
máquina.
En la casa central y en las sucursales, se utilizan Switches y cables de buena calidad; se tiene una
buena distribución de los cables por sus correspondientes cable-canal. Es decir, en cuanto a
materiales,
se cuenta con las mejores opciones; el problema esta en la arquitectura funcional de la red y
distribución
de servicios.
Información vital
Para proteger la información cr´ıtica para el funcionamiento de la empresa, se han planteado las
siguientes opciones:
Opción 1: Centralizar la información en la base de datos de la casa central. Instalar un servidor de
backup en cada sucursal. Todos los empleados ʹincluso los de las sucursales ʹingresarán a la base
de datos de la casa central para obtener la información que necesitan.
Opción 2: Centralizar la información en la base de datos de la casa central. Pero crear servidores
espejo en ambas sucursales, para ahorrar tiempo en el acceso a los datos necesarios por los
empleados.
De entre ambas opciones, se escoge la primera, ya que la segunda tiene la desventa ja que al
momento
de la sincronización se consume mucho ancho de banda, por que la frecuencia de actualización

de los
servidores espejo debe ser mayor que la de los servidores backup.
Servicios de red
Crear en la casa central una DMZ (DeMilitarized Zone) , donde se ubiquen los servicios al público
en
general: servicio web por el momento. Quitar todos los que puedan ofrecer algún tipo de
vulnerabilidad.
Los servicios necesarios para los empleados, como por ejemplo el servicio de correo, Web, el
sistema
de gestión, y demás, serán accedidos desde dentro de la red local, o desde una conexión no
accesible al
público en general. En la Figura 8.3 vemos cómo ser´ıa el esquema de red de la casa central.
Figura 8.3: Infraestructura de la red de la casa central
Las sucursales no poseerán servicios públicos, estos solo se brindarán desde la central.
Conexión a Internet
Cada una de los puestos Įjos accederá a Internet a través de un proveedor local. La casa central
debe
tener dirección IP Įja, mientras que en las sucursales esto no es necesario.
El servidor Dynamic DNS de la central resolverá los nombres de de las sucursales (si es necesario) .
Conexión con la Casa central
Cada una de las sucursales se comunicarán directamente con la casa central, pero entre ellas no
habrá comunicación directa, ya que esto provocar´ıa una sobrecarga administrativa de la red,
que es
mayor al aprovechamiento que se le da. La conexión inalámbrica no es una opción en este caso
debido
a la distancia que hay entre los lugares a comunicar, por lo que queda descartada. Las opciones
son las
siguientes:
Opción 1: Alquilar dos l´ıneas, para conectar la central con cada una de las sucursales. Con esto se
gana en privacidad y seguridad.
Opción 2: Establecer conexiones VPN sobre las conexiones a Internet existentes, entre la central y
cada una de las sucursales. El tráĮco via jará por la red pública, pero encriptado; si se
implementan
bien los servidores VPN, no habrá mayores problemas con respecto a la seguridad.
La opción que se adopta, es la segunda. Debido a que, si bien la primera ofrece mayor seguridad,
por
otro lado es mucho más costosa, y posee la desventa ja que si el enlace se corta en algún punto
entre los
nodos, puede haber gran retardo en restablecer la comunicación.
La Figura 8.4 muestra detalles de la infraestructura de red de las sucursales.

La Figura 8.4 muestra detalles de la infraestructura de red de las sucursales.
Empleados itinerantes y remotos
Se hizo un estudio para averiguar cuántos empleados se conectaban remotamente a la casa

central y
cuántos a las sucursales. Se halló que en la primera el máximo de conexiones simultáneas es de

diez (en
promedio) , y en las sucursales es de cinco (también en promedio) .
Debido a que ahora los datos estarán centralizados en la oĮcina principal de la empresa, las
conexiones
VPN de los empleados remotos se establecerán solo con este lugar.
Se implementará soporte para veinticinco conexiones VPN para usuarios remotos,

simultáneamente a
la central. Con esto se da un margen de cinco conexiones extra.

Recursos compartidos a clientes
Los clientes necesitan acceder a la empresa v´ıa web para obtener información de sus estados de
cuentas, pagos, entre otra información cr´ıtica. Dicha información es privada, y necesita de un
modo
seguro de transmisión, para que no pueda ser obtenida por un curioso. Las opciones que se
proponen son
las siguientes:
Opción 1: Habilitar conexiones VPN host-red para cada uno de los clientes que necesiten acceder
a
nuestra red de forma segura.
Opción 2: Aprovechando que en la DMZ hay un servidor web público, y que los clientes solo
necesitan acceso www, puede habilitarse soporte HTTPS en dicho servidor, esto es, tráĮco HTTP
encriptado con SSL, de modo que el tráĮco de paquetes no circule en texto claro.
La mejor opción en este caso, es la segunda, ya que se evita una sobrecarga de conexiónes VPN
innecesarias y poco productivas, y que solo provocar´ıan una baja en el rendimiento de los
servidores.
También se aprovecha algo que existe, de un modo muy sencillo: el servidor web público.
Administración de las redes
Suprimir la administración de red individual de las sucursales. Establecer una administración cen-
tralizada de los tres puntos Įjos en la casa central, para simpliĮcar el control y mantenimiento de
las
redes.
Cada una de las sucursales poseerá una puerta de acceso VPN únicamente para acceso
administrativo
de esta ´ındole.
8.3.5. Comparativa de costos
Para realizar una comparativa de costos, antes se deben conocer las opciones disponibles para
ofrecer
lo mismo, pero con diferentes soluciones.
En cuanto a las opciones, no existe tanta variedad para el mismo costo de instalación y
mantenimiento,
ya que puede variar para el tamaȂno de una empresa como en la complej idad de la red que se
quiera
implementar. Además como las entidades buscan en general disminuir gastos, se optan por
soluciones
económicas que pueden estar relacionadas con software libre o con aparatos de gama media de
Linksys
o 3Com. Por el contrario, si la empresa puede gastar más dinero, entonces buscan la misma
solución en
compaȂn´ıas como Cisco.
En cuanto a los requisitos m´ınimos para implementar una solución VPN, no se van a incluir
dentro
del costo de la conĮguración y mantenimiento de la VPN propiamente dicha, sino que se

considera que
es un gasto que la empresa debe asumir para poder invertir en una mejor solución. De esta
manera, se
van a plantear solamente los costos de la instalación, conĮguración y mantenimiento de una

VPN, que
en algunos casos puede ir incluido con el equipamiento, pero en Empresa Ejemplo S .A. no será
necesario
porque ya disponen de equipos suĮciente.
En algunos casos en los que se pretende gastar menos dinero en implementación, se puede optar
por
soluciones h´ıbridas. Es decir, en la casa central se instala un equipo medianamente potente,

mientras
en las sucursales se opta por routers que sean compatibles con la implementación de IPSec con
Linux u
OpenBSD .
Costos de comunicación
Hace un tiempo, el reino de las comunicaciones las ten´ıan las l´ıneas telefónicas tradicionales de
cable
de cobre. Luego los requerimientos fueron cambiando y las comunicaciones se volvieron

inalámbricas o
satelitales, sin la intervención de cables.
En la actualidad, se sigue utilizando la l´ınea telefónica tradicional pero con una nueva tecnolog´ıa
que
permit´ıa la conexión a Internet a alta velocidad, es el ADSL. De esta manera, nace una nueva
alternativa
a las l´ıneas ͞dedicadas͟ , que se empleaban para la conexión de redes privadas virtuales
mediante un canal
independiente y de ancho de banda ba jo demanda, que es la VPN a través de Internet.
En cuanto a los costos de la comunicación, se tiene una gran variedad de soluciones, que van
desde
l´ıneas dedicadas con framerelay a muy alto precio, hasta la conexión a Internet hogareȂna
bastante más
económica.
Una opción media que se utiliza actualmente y que es la requerida en casa central de Empresa
Ejemplo
S .A. , es el denominado ADSL simétrico. Esta tecnolog´ıa permite la misma tasa de transferencia
de subida
como de ba jada de datos. Por ejemplo un servicio de 1 Mbps con direcciones IP Įjas puede tener
un costo
de US$300,00 aproximadamente, que es mucho más que un ADSL común de 5 Mbps, pero
bastante menos
que una l´ınea dedicada, que puede superar los US$900,00.
Costos con software libre
Como en general los clientes que solicitan un servicio requieren una solución completa, en este
caso,
luego del relevamiento correspondiente y del análisis de la infraestructura de la red, no es

necesario proveer
de equipamiento, por lo que el costo se reducir´ıa solamente a la instalación de los sistemas y
conĮguración
de la VPN.
Los precios por la instalación de un concentrador VPN con software libre, van desde los $2
.000,00
(pesos argentino) como base aproximadamente, dependiendo de la complej idad del sistema y de
la
importancia del tráĮco a transmitir (con respecto a la disponibilidad) . Esto se mide de acuerdo a
si
es necesario que la VPN se encuentre activa las 24 horas del d´ıas, todos los d´ıas de la semana,
etc.
En este caso, para la Empresa Ejemplo S .A. que requiere conectividad con las demás sucursales
para
realizar el backup diario, de las transferencias realizadas durante la jornada laboral, se debe tener
en
cuenta la disponibilidad del sistema.
De esta manera, los elementos importantes a tener en cuenta para realizar un presupuesto ser´ıan
los
siguientes:
Instalación y conĮguración del sistema (Linux u OpenBSD) .
Seguridad adicional por software.
Disponibilidad del sistema.
Cantidad de enlaces punto a punto.
Soporte a usuario móviles.
Cantidad de servicios para administrar.
Copias de seguridad en horarios que no se utilice el servidor.
Como los servicios que se pueden administrar son numerosos, en el siguiente listado se muestran
los
requeridos por Empresa Ejemplo S .A

Servicio Web.
Servicio de Base de Datos.
Servidor DNS .
Servicio de correo electrónico.
Servidor de archivos.
Por consiguiente, es posible calcular el costo total, a partir del precio base, que incluye:
ConĮguración de un enlace punto a punto (extremo servidor) .
Soporte a usuarios móviles (cuya cantidad depende de la capacidad del equipo) .
Servidor DNS .
Al agregar los servicios Web, de correo electrónico, base de datos y de archivos, el costo se
incrementa
a $2.000,00, mientras que la conĮguración de copias de seguridad diaria suman $1 .000,00.
Por otra parte, el tema de la disponibilidad del sistema, tiene que ver con el soporte y
mantenimiento
mensual de la VPN, que puede variar (dependiendo del grado de disponibilidad) entre $1 .000,00 y
$3.000,00.
La Tabla 8.1 muestra detalladamente el costo estimado de cada servicio junto al monto total.
En cuanto al costo mensual, la variación del precio esta fuertemente relacionada con la
disponibilidad
del servicios y las copias de seguridad que se realicen. Por esta razón, como se ha mencionado
anteriormente, el costo de mantenimiento mensual puede variar entre $1 .000,00 y $3.000,00.
Este es el caso para la casa central. En las sucursales, el gasto siempre es menos, ya que los
servicios
que se administran, se encuentran en la casa central.
Para cada sucursal de Empresa Ejemplo S .A. ya se ha calculado el precio por los enlaces, por lo
que
solamente se suma en el precio la instalación y conĮguración del sistema, junto al

mantenimiento del
mismo. De esta manera se adiciona $1 .000,00 para cada servidor de cada sucursal.
De esta manera se estima que el costo total de una solución VPN con software libre ser´ıa de
$10.500,
que incluye el primer mes de soporte y mantenimiento. Los meses siguientes, se tendr´ıa que
incluir el
mantenimiento de la VPN, de acuerdo a la disponibilidad (que en este caso se considera una

disponibilidad
media) , y las copias de seguridad, con un total de $3.000 mensuales.
Costos con hardware dedicado
En cuanto al cálculo de una solución con hardware comercial, el precio var´ıa solamente en el
servicio de
conĮguración e instalación de los equipos adquiridos. Los demás servicios tienen elmismo costo
establecido
anteriormente, es decir, se reemplaza la instalación y conĮguración del servidor VPN por la

solución con
hardware propietario.
Para llevar a cabo esta implementación, se utilizan equipos marca Cisco, cuyos modelos y precios
son
los siguientes:
1 . Cisco ASA 5510 SSL/IPsec VPN Edition for 50 concurrent SSL VPN users (US$ 4.500,00) .
2. 2 Cisco VPN 3002 Hardware Client (US$ 598,00) .
El primer modelo de la lista anterior es un concentrador VPN que se utiliza como servidor para las
conexiones entrantes. Permite por medio de la virtualización, a 250 sesiones concurrentes, 250
sesiones
SSL y 50 usuarios concurrentes. Además tiene funciones de Įrewall para proteger la red de
ataques de
hackers, malware, troyanos, e incluye bloqueo de aplicaciones P2P para evitar el intercambio de
archivos.
El segundo equipo es un dispositivo que funciona en modo cliente junto al concentrador principal,
estableciendo la comunicación con el mismo y haciendo funciones de NAT en la red interna, que
en este
caso, se trata de las sucursales de Empresa Ejemplo S .A. El equipo soporta conexión con el ISP
mediante PPPoE, además de NAT transparente para IPSec. De esta manera, se puede obtener un
servicio completo
de conexión a Internet, además de la conexión segura al servidor VPN mediante el protocolo

IPSec.
Volviendo a los costos, cada equipo Cisco mencionados anteriormente, se le tienen que sumar los
siguientes servicios:
Instalación y conĮguración de los equipos Cisco.
Seguridad adicional por software.
Disponibilidad del sistema.
Cantidad de servicios para administrar.
Copias de seguridad en horarios que no se utilice el servidor.
En cuanto a la seguridad adicional por hardware se reĮere a la utilización de un Įrewall ba jo

OpenBSD
o Linux, el cual adhiere Ňexibilidad a la conĮguración y permite un mayor control de la red

interna. Esto
se realiza en la casa central, donde la seguridad de los equipos y la utilización de DMZ
(DeMilitarized
Zone) hacen que la opción por software para el Įrewall sea la más indicada.
De los servicios para administrar, se incluyen los siguientes:
Servicio Web.
Servicio de Base de Datos.
Servidor DNS .
Servicio de correo electrónico.
Servidor de archivos.
Estos servicios se implementan en casa central, pero no signiĮca que se integra el mantenimiento
del
sitioWeb corporativo ni el contenido de la base de datos, sino que se cuenta la instalación y

conĮguración
de los servicios. El tema de la migración, si se utiliza un sistema diferente en aplicaciones Web y

de base
de datos, es un caso aparte, que requiere otro proceso de planiĮcación y por lo tanto un precio
adicional.
En esta situación de ejemplo, se considera que el sitioWeb anterior y la base de datos, son fácil
de migrar
al nuevo sistema.
La Tabla 8.2 muestra el cálculo de costos utilizando esta solución por hardware de una VPN, que
además se incluyen servicios con software libre.

Cuadro 8.2: Costos de la implementación de una VPN con software libre.
Por otro lado, el costo de mantenimiento es el mismo que en el caso anterior, pero no se incluye el
soporte que se pueda necesitar en los equipos Cisco, ya que para esto se requiere de agente
especializados
de dicha empresa. El gasto inicial total con un mes de soporte es de $23.666,00, con un mensual
de
$3.000,00.
8.4. Conclusión
Elegir una solución VPN adecuada no es tarea fácil. Requiere de mucho tiempo de planiĮcación y
análisis, ya que se trata de una inversión importante que puede salir muy bien o deĮnitivamente
puede
ser una pérdida de tiempo y mucho dinero. Esto ocurre, si no se toman todas las precauciones
debidas ni
se documenta o se entiende el problema; la inversión puede resultar un completo fracaso.
Por esta razón es que al elegir una solución VPN adecuada se debe tener en cuenta una gran
cantidad
de factores como el económico, la escalabilidad, la transparencia para los usuarios, la mejora de

la imagen
corporativa, la solución a un problema cr´ıtico, etc.

En cuanto a las diferentes soluciones VPN, tanto los equipos comerciales, como las
implementaciones
en sistemas libres pueden ser muy buenas respecto a su funcionamiento; la diferencia se

encuentra
en que las implementaciones libres poseen una gran Ňexibilidad y precio más ba jo en
comparación
con las comerciales; pero estas últimas poseen la venta ja de la optimización del hardware para
mejor
funcionamiento de las VPN.
En general, las grandes entidades, al implementar VPN para su tráĮco utilizan equipos
comerciales, ya
que el gasto en un buen equipo se justiĮca; mientras que las empresas más pequeȂnas, optan por
soluciones
libres debido a que la cantidad de recursos con los que cuentan es menor. Es bueno remarcar que,
por lo
menos en este caso, menor precio no implica necesariamente menor calidad, ya que las
implementaciones
VPN mediante software pueden competir perfectamente en casi todos los aspectos con las
comerciales;
incluso siendo una mejor opción a igual precio, en algunos casos.
Conclusión Įnal
La información es lo que da vida a una empresa, por tanto, es importante que sea resguardada.
Esto implica que deberán tomarse las medidas necesarias para que cuando haya que transmitirla
entre
sucursales, empleados, etc, no sea expuesta al mundo exterior, ya que si la información corre
riesgo, se
compromete la vida de la entidad. Por esto, mientras mayor sea el riesgo, mayor será la
justiĮcación del
gasto en la seguridad de nuestros datos.
Teniendo en cuenta lo anterior, una empresa grande optará por soluciones como l´ıneas
dedicadas,
enlaces inalámbricos o MPLS , para el tráĮco más cr´ıtico; e implementaciones de redes privadas
virtuales
para el tráĮco de menor importancia. Ahora si se trata del mismo caso, pero en una empresa
mediana o
pequeȂna, que posee menos recursos, probablemente la implementación de VPNs será la

óptima.
En materia de redes privadas virtuales no existe la certeza de que utilizar lo más nuevo o lo
considerado
más ͞seguro͟ , sea la mejor solución para una empresa. Aunque, en principio, la mayor´ıa de los
sistemas
VPN funcionan de forma similar, en realidad, la diferencia entre ellos es lo suĮcientemente

signiĮcativa
como para elegir uno sobre otro. Antes de hacer una opción hay que analizar las variables más
importantes:
cuán delicada es la información que se transmitirá a través de la VPN, disponibilidad necesaria

de la
conexión, ancho de banda requerido, etc.
Con respecto a cuán delicados son nuestros datos, no es lo mismo la necesidad que tiene un
banco que
maneja dinero a través de sus redes, que la que tiene un servidor de juegos online. No tiene
sentido pasarse
d´ıas, semanas o hasta meses conĮgurando (y entendiendo) el protocolo IPSec (Internet Protocol
Security)
si solo se va a utilizar la red para transferir música o compartir juegos en l´ınea. Algunas
alternativas,
permiten con poco esfuerzo y pocas horas hombre, obtener una red privada virtual segura,
conĮable y
rápida.
No obstante, a la hora de implementar una VPN ʹy como ya vimosʹ, la primera opción que
debemos
hacer es: hardware dedicado (ca jas negras) o software implementado en un ordenador.
Las empresas dedicadas a ofrecer soluciones para redes como Cisco, 3Com, SSH.com, entre otras,
brindan servicios y equipos de muy alto rendimiento, pero de elevado costo en comparación con
las
alternativas libres. Dichos equipos no tienen ʹen la mayor´ıa de los casosʹ una conĮguración
Ňexible, por
lo que si la necesidad de conexión de la empresa var´ıa en cuanto a conĮguración, protocolos,

número de
conexiones, etc, y el equipo adquirido no brinda soporte para ello, será necesario invertir en otro
nuevo.
En estos casos se cumple la regla: ͞A menor costo, menor Ňexibilidad, escalabilidad, etc.͟ .
En cuanto a las soluciones VPN mediante software implementadas en sistemas libres, podemos
decir
que en materia de seguridad, están muy bien dotadas, ya que cuentan con los más avanzados
sistemas de
autenticación, encriptación y encapsulación, por lo que en dicho ámbito pueden competir

perfectamente
con las soluciones comerciales. En cuanto a Ňexibilidad, las soluciones mediante software son las
que
llevan la delantera; estas brindan la posibilidad de conĮgurar los servidores VPN en todos los
aspectos
posibles, implementar Įrewalls exclusivos para el tráĮco VPN sin invertir en hardware adicional, y
si la
red está bien diseȂnada, la escalabilidad se convierte en algo muy sencillo de llevar a cabo.
Puede decirse que el costo de la implementación de una VPN con sistemas libres es mayor al
costo
que tiene la implementación con hardware dedicado; esto se debe a que la instalación y
conĮguración del
servidor VPN por software, en el peor de los casos se hace desde cero, en cambio un equipo
comercial, solo
requiere ser conectado y conĮgurado. Si bien es cierto que el costo de la implementación de una
VPN en sistemas libres es mayor, hay otros parámetros a tener en cuenta que equilibran la
situación: la Ňexibilidad
que obtenemos con sistemas libres, no la encontraremos en los equipos comerciales económicos,
ni en los
de un rango medio; y la segunda, es que comprar un servidor VPN comercial es más caro que
comprar
un buen ordenador, o mejor aún, que reutilizar el hardware que ya poseemos.
Cuando nuestra opción para las comunicaciones son las redes privadas virtuales, y nuestro tráĮco
encriptado via jará entre los destinos atravesando Internet, debemos saber que, sea cual fuere
nuestra
elección (si equipos comerciales, o servidores por software) , el rendimiento de las

comunicaciones será poco
predecible, y dependerá mucho del ancho de banda que hayamos contratado con nuestro ISP. Es
por esto,
que muchas empresas optan por una conexión de salida a Internet para el tráĮco normal, y otra
exclusiva
para las conexiones VPN. Esta es otra de las cuestiones importantes a analizar.
Finalmente se puede concluir que a la hora de elegir una solución VPN no solo se tiene que
pensar
soluciones comerciales de empresas como Cisco, Lucent, etc, sino también en las alternativas
libres. Ya
que estas tienen para ofrecernos grandes venta jas: ba jo costo, gran Ňexibilidad (al punto de
adaptarse
perfectamente a la necesidad real) , alto grado de seguridad y escalabilidad en nuestras redes.
Apéndice A
Equipos de prueba
En este Apéndice se detallan las caracter´ısticas de las redes y equipos utilizados para las pruebas
durante el desarrollo del proyecto. La intensión delmismo es proveer información de los

requisitos m´ınimos
del hardware necesario para obtener resultados similares (o superiores) a los que se han podido
llegar.
Además se plantean los esquemas de conexión a nivel general que cada red utiliza para el acceso
a
Internet , que por su parte, se profundiza en el Cap´ıtulo 3 de la página 22.
A.1 . Ambiente de trabajo
Debido a que la naturaleza del proyecto as´ı lo requiere, para las pruebas, se utilizaron dos redes
LAN (Local Area Network) distantes. La comunicación entre ellas se realiza a través de la red
pública
(Internet) . Las redes locales se describen más adelante en las secciones A.2 y A.3 de las páginas
110 y
111 respectivamente.
Cada red se conecta a su ISP (Internet Service Provider) , el cual provee un entorno de
comunicación
ideal en cuanto a cantidad de tráĮco e información que circula por la misma, de manera que se
puede
tener un entorno real de comunicación por un medio inseguro entre las dos redes locales. Un
esquema
simpliĮcado, que muestra la conexión lógica entre las redes, se puede ver en la Figura A.1 .
Figura A.1 : Conexión a Internet de ambas redes y el enlace lógico creado por la VPN.
Ambas redes locales utilizan, para el tráĮco de datos, el protocolo de capa dos Ethernet y el
conjunto
de protocolos TCP/IP. Esto hace que no sean necesarias aplicaciones o dispositivos de conversión
entre
dos o más protocolos, dejando esta tarea para que la realicen los respectivos sistemas operativos.
A.2. Red casa. lan
Esta subred cuenta con tres hosts interconectados entre s´ı por un router que posee funciones de
switch
y WAP (Wireless Access Point) .
El rango de direcciones IP que se utiliza es 192. 168. 1. 0/24, es decir, de la dirección 192. 168. 1. 1
a
la dirección la 192. 168. 1. 254.
El rango 192. 168. 1. 1 a 192. 168. 1. 9 está reservado para direcciones asignadas estáticamente,
y el
rango 192. 168. 1. 10 a 192. 168. 1. 254, se asigna dinámicamente a hosts clientes por DHCP.
En la tabla A.1 se resumen las caracter´ısticas de hardware de los equipos de la red:
A.2.1 . Descripción de equipos
A continuación se describen las caracter´ısticas más importantes de los equipos involucrados.
Modem/Router Aztech DSL600EW
Este equipo posee 4 puertos Lan (RJ45) , 1 puertoWan (RJ11) ,WAP (Wireless Access Point) .
Conecta
y permite el tráĮco de datos entre los hosts de esta red.
Brinda servicios de DHCP. Y posee funciones de bridge 1 .

Tiene asignada la dirección IP 192. 168. 1. 1 .
Hostname: agnus
Este host establece una conexión pppoe con el ISP, y brinda acceso a internet a la red. Cumple
también
funciones de servidor DNS , SSH y VPN. A seguir, su descripción detallada:
Procesador: Cyrix 6x86MX 201 MHz
Memoria RAM (real) : 133787648 (127MB)
Disco R´ıgido 1 : 6105MB
Disco R´ıgido 2: 19092MB
Sistema Operativo: OpenBSD 4.2
Adaptador de Red 1 : 3Com 3c905B 100Base-TX
Dirección de Hardware (Mac) : 00:50:04:7c:b3:e7
Dirección IP: 192.168.1 .2
Máscara de Red: 255.255.255.0
Adaptador de Red 2: NE2000 (RTL8019)
Dirección de Hardware (Mac) : ʹ
Dirección IP: (no tiene)
Máscara de Red: ʹ
1Tanto este dispositivo como los demás, poseen otras funcionalidades.
Hostname: poncho
Este host funciona solo como cliente. A seguir, su descripción detallada:
Procesador: x86 Family AuthenticAMD 1599 MHz
Memoria RAM (real) : 256 MB
Disco R´ıgido: 153,38 GB
Sistema Operativo: Microsoft Rm Windows XPTM Professional
Adaptador de Red 1 : VIA Rhine II Fast Ethernet Adapter

Dirección de Hardware (Mac) : 00:14:2A:E4:21 :01
Dirección IP: 192.168.1 .3
Hostname: notebook
Este host funciona solo como cliente. A seguir, su descripción detallada:
Procesador: x86 Family AuthenticAMD 1808 MHz
Disco R´ıgido: 120 GB
Adaptador de Red 1 : WLAN Broadcom 802.11b/g
Dirección de Hardware (Mac) : 00:1A:73:5D :AE:79
Dirección IP: (dinámica)
Máscara de Red: ʹ
A.3. Red red. lan
Esta red esta compuesta por cuatro computadoras que cumplen diferentes funciones dentro de un
entorno hogareȂno. Las funciones que cumplen son diversas, comenzando por un servidor de
acceso a
Internet para la red local, y terminando en estaciones de traba jo y ocio familiar.
Las caracter´ısticas resumidas de las computadoras con sus respectivos nombres para identiĮcarlas
se
pueden ver en la Tabla A.2. Las caracter´ısticas más detalladas se pueden ver en A.3.1 .
A.3.1 . Descripción de equipos
A continuación una descripción más detallada de los equipos involucrados.
Modem/Router ADSL (modo bridge)
Este equipo realiza la conexión a Internet propiamente dicha mediante un puente entre la LAN y
la
WAN del proveedor. Marca y modelo del dispositivo es: Amigo Tainet CA81R.
Switch 3COM (8 bocas)
Este dispositivo permite conectar entre s´ı a varios clientes de la red y as´ı también compartir el
acceso
a Internet . A seguir, su descripción detallada:
Hostname: superhijitus
Procesador: Intel Pentium (P54C) (GenuineIntel 586-class) 166 MHz
Memoria RAM (real) : 100233216 (95MB)
Disco R´ıgido: 4134MB
Sistema Operativo: OpenBSD 4.3 (GENERIC)
Adaptador de Red 1 : Realtek 8139
Dirección de Hardware (MAC) : 00:08:54:b2:48:b6
Dirección IP: 192.168.0.1
Dirección de Hardware (MAC) : 00:c0:df:ab:2e:f1
Máscara de Red: (no tiene)
Dirección de Hardware (MAC) : 00:c0:df:ab:0b:e9

Hostname: wasa
Equipo servidor utilizado para proveer de acceso PP TP (Point to Point Tunneling Protocol) ,
OpenVPN, entre otros. A seguir, su descripción detallada:
Procesador: Intel Pentium III (866 Mhz)
Disco R´ıgido: 40020 MB
Sistema Operativo: Ubuntu 8.04 LTS
Adaptador de Red 1 : RealTek RTL8139
Dirección de Hardware (Mac) : 00:08:54:a4:0a:62
Dirección IP: 192.168.0.2
Adaptador de Red 1 : RealTek RTL8139
Dirección de Hardware (Mac) : 00:08:54:a4:0a:6e
Hostname: nippur
Equipo de escritorio que solo cumple funciones de cliente, salvo cuando se realizan pruebas con
PPTP
(Point to Point Tunneling Protocol) . A seguir, su descripción detallada:
Procesador: AMD Athlon(tm) X2 Dual Core BE2300, 1900 Mhz
Memoria RAM (real) : 1 GB
Sistema Operativo: Microsoft Rm Windows VistaTM Home Premium
Adaptador de Red 1 : NVIDIA nForce Networking Controller
Dirección de Hardware (Mac) : 00:1E:90:22:26:1C

Máscara de Red: (dinámica)
Hostname: supermaquina
Servidor que se conecta a Internet y provee del nombre de usuario y contraseȂna al ISP. Este
equipo es
el que asigna direcciones IP dinámica a los clientes y permite el acceso a Internet mediante NAT a
toda
la red local. A seguir, su descripción detallada:
Procesador: Intel Pentium 4 630, 3.0 Ghz
Adaptador de Red 1 : Networking Controller
Dirección de Hardware (Mac) : 00:13:8f:48:a2:cf
Máscara de Red: (dinámica)
Apéndice B
Documentación
Para la realización del informe de esta tesis se utilizaron una serie de herramientas que facilitaron
la
organización, escritura y formato del resultado Įnal del mismo.
La Įnalidad de utilizar software libre para el procesamiento de la documentación, fue el de tener

fácil
acceso al código fuente, permitiendo la visualización desde cualquier editor de texto y además
de generar
archivos con formato PDF que se ha convertido en estándar ISO para la impresión en papel y en
pantalla
de cualquier tipo de documento. Por esta razón se ha utilizado, para el proceso de ͞compilación͟
, el
software de composición de documentos profesionales Latex, que permite una terminación más
profesional
en lo que respecta al formato de la documentación. La Figura B .1 muestra la pirámide de

componentes
más importantes de Latex para generar el documento, en el que se destaca como elemento
central al
repositorio de paquetes adicionales de CTAN1 , que permite incluir gran cantidad de funciones
adicionales
y estándar del lengua je.
Figura B .1 : Pirámide uniforme de los componentes principales para generar documentos Latex.
En las siguientes secciones se describen con más detalles las herramientas utilizadas, que van de
los
editores de texto a los paquetes de software de Latex y una breve descripción del mismo.
Además se hace
mención a los métodos de traba jo en equipo mediante el uso del software Subversion para el
control de
versiones de la documentación y en la organización de la estructura básica del informe.
1Comprehensive TeX Archive Network, o Red de Archivos TeX comprensibles
B.1 . Herramientas de edición
Para la edición de la tesis se han utilizado herramientas de composición de textos que

permitieron
una salida por pantalla e impresión elegantes y a su vez de carácter profesional y estructurado. El
autor
principal de generar esta documentación es Latex, que es software libre ba jo licencia LPPL, por lo
que
resulta ideal para el propósito de realizar una tesis de grado.
Las herramientas que más cambiaron durante la investigación fueron los editores de texto, ya
que
a medida que iban surgiendo las necesidades, se probaban software de diferentes desarrolladores
hasta
encontrar la conformidad. El siguiente listado muestra los paquetes de software utilizados alguna
vez
durante el proceso de documentación:
pdfTeX, Version 3.141592-1 .40.4 (MiKTeX 2.7)
LEd (Latex EDitor)
TeX Maker 1 .7
TeXnicCenter 1 beta 7.50
Emacs 22
El primer ´ıtem es el compilador de Latex propiamente dicho, que se encarga de generar

directamente
la salida en formato PDF, y además toma las imágenes en formatos PNG, JPG, entre otros que no
sean
vectoriales.
B.1 .1 . Compilador de LATEX
LATEXes un lengua je demarcado para documentos, formado por un gran conjunto de macros de
TeX
que fueron escritos inicialmente por Leslie Lamport en 1984, con la intención de facilitar el uso
del
lengua je de composición tipográĮca creado por Donald Knuth. Es muy utilizado para la
composición de
art´ıculos académicos, tesis y libros técnicos, dado que la calidad tipográĮca de los documentos
realizados
con LaTeX es comparable a la de una editorial cient´ıĮca de primera l´ınea.
Este compilador de documentos se puede utilizar mediante la l´ınea de comandos o a través del
mismo
software de edición que incorpora los comandos necesarios para generar el archivo DIV, PDF o PS
según
sea cada caso. La siguiente l´ınea de código muestra la salida al ejecutar ͞pdftex͟ en una terminal
de
Windows:
Mi c ro s o f t Wi ndows [ Ve rs i ón 6 . 0 . 6 00 1 ]
Copyri ght ( c ) 2006 Mi c ro s o f t Corpo rat i on . Re s e rvado s t odos los de re cho s .
C : \ Us ers \ Gus tavo > pdf t e x
Thi s is pdf TeX , Ve rs i on 3 . 1 41 5 92 - 1 . 40 . 4 ( Mi KTe X 2 . 7 )
**
Luego solicita ingresar el nombre del archivo .tex a compilar. Si no se ingresa ninguno, devuelve
mensa jes de error.
El uso de esta terminal suele ser muy complicado y dif´ıcil de controlar, depurar código, etc. Para
esto
es más recomendado utilizar el nombre del archivo .tex luego del comando ͞pdftex͟ o bien dejar
este
proceso en manos de un IDE espec´ıĮco para documentos Latex.

La Įlosof´ıa de traba jo de LATEXes un tanto diferente a la de los procesadores de texto habituales
(conocidos como WYSIWYG, es decir, lo que ves es lo que obtienes) ; dicha Įlosof´ıa se basa en
comandos
como se ha mencionado anteriormente. Este modo de traba jo permite a quien escribe un

documento,
centrarse exclusivamente en el contenido y sin tener que preocuparse de los detalles del formato
de salida.
Por otro lado Latex ofrece independencia del dispositivo (impresora, pantalla, etc.) o del sistema
operativo (Windows, MacOS , Unix, Linux, etc. ) en el que se haya compuesto el documento,
permitiendo
además exportar a los formatos:
Postscript,
PDF
SGML,
HTML,
RTF,
entre otros.
El formato que se ha utilizado para la realización de esta tesis es PDF, ya que es el más extendido
de
todos y su visualizador oĮcial de Adobe se puede ejecutar en cualquier plataforma.
B.1 .2. Edición con TeXnicCenter
Una de las herramientas que mejor se ha adaptado a la edición, depuración y composición de la
documentación fue el software libre versión 1 beta 7.50 (Figura B .2) . Este posee numerosas
caracter´ısticas
que hacen más fácil la escritura y organización de la tesis de grado, tales como:
Resaltado de sintaxis,
Barra de herramientas con formatos rápidos,
Acceso directo a la ecuaciones básicas,

Teclas de acceso rápido a la compilación y previsualización del documento,
Botones de navegación por los errores de sintaxis, advertencias y errores de margenes,
Posibilidad de incluir diccionarios de espaȂnol para la corrección ortográĮca,
Entre otros.
Una de las caracter´ısticas pobres de este editor son los modos de navegación por los cap´ıtulos y
secciones de la documentación. Y a pesar de que se pueden crear proyectos con estas

caracter´ısticas,
se pierde la independencia en el uso de cualquier editor de texto que mejor se adapte a los gustos
y
necesidades de cada uno. Por esta razón, no se crean proyectos con ningún editor Latex para
evitar
introducir archivos propios de cada software.
Por otra parte, TeXnicCenter ofrece un alto grado de personalización tanto de la interfaz de
usuario
como de los programas externos que puedan utilizarse (visor de PDF de Adobe, compilador de
Latex
propietario, etc) . Aunque esta caracter´ıstica puede dar un aspecto de complej idad al programa,
después
de un tiempo de utilización resulta dif´ıcil dejarlo.
B.1 .3. Edición con TexMaker
Otra de las herramientas de edición de documentos Latex es TexMaker (Figura B .3) , que se
caracteriza
por la amigable interfaz de usuario, con iconos grandes y colores llamativos. Este software libre
hace que la
experiencia escribiendo la tesis de grado sea realmente agradable y sin nada que envidiar a los
procesadores
de textos actuales.
TeXMaker tiene muchas caracter´ısticas interesantes que ayudan a la escritura de documentos

Latex,
entre ellas se listan a continuación:
Autocompletado de los comandos predeĮnidos,
Muestra las referencias del archivo abierto (como un navegador de cap´ıtulos, secciones, etc.) ,
Entre otros
B.1 .4. Edición con LEd
LEd (de Latex Editor) es un software gratuito que permite la edición de documentos Latex con
previsualización incorporada si se esta traba jando con formato DVI. El entorno visual es muy
completo
y ofrece la mayor´ıa de los botones de acceso directo a las operaciones más utilizadas en la barra
de
herramientas, como se puede observar en la Figura B .4.
Las caracter´ısticas más destacadas de LEd se listan a continuación:
Autocompletado de los comandos Latex más importantes,
Previsualización instantánea del documento en DVI,
Gran cantidad de botones con funciones rápidas para Latex,
Entre otros.
LEd es software gratuito, pero existe una versión comercial con soporte técnico incluido. Para el
propósito de esta tesis, se utiliza la versión gratuita que es más que suĮciente.
B.1 .5. Diagramas con Edraw Max
Edraw Max es un software comercial que se utiliza para hacer todo tipo de diagramas, que van
desde el
diseȂno de viviendas (simples) hasta los diagramas UML, electrónicos y de red, entre varios otros
modelos.
Además incluye una serie de ejemplos para cada tipo de diagramas, lo que facilita el diseȂno y
muestra un
panorama general del potencial del programa.
Las caracter´ısticas más destacadas de la versión 4.0 son las siguientes:
Gran cantidad de modelos predeĮnidos de alta calidad;
Interfaz similar a la de Microsoft Oĸce 2007;
Permite exportar el diagrama a varios formatos, entre ellos PDF y PNG ;
Posibilidad de importar modelos o gráĮcos;
Diagramas de ejemplo para todos los casos.
Esta versión de Edraw Max se ha conseguido mediante el sitio web Give Away of the Day2 , que
ofrece
diariamente programas comerciales de forma gratuita por un d´ıa. Una captura de pantalla se
puede ver
en la Figura B .5.
B.2. Estructura de la documentación
Para que la realización de esta tesis de grado sea lo más organizada posible, antes de comenzar a
pasar las notas, experiencias y pruebas, se detallaron las normas a seguir en cuanto a la estructura
de la
documentación. De esta manera, se plantearon inicialmente los puntos claves que se iban
incluyendo a
medida que avanzaba la investigación.
En esta sección se describen en detalles los parámetros de conĮguración del documento Latex y
los
motivos de su utilización. Además se incluye el esquema de la tesis y su forma de escritura.
B.2.1 . DeĮniendo el esquema
La estructura de la documentación cuenta con cap´ıtulos, secciones y subsecciones que permiten

la
ubicación rápida de determinadas temáticas que se incluyen como traba jo de esta tesis.
Además se
utilizan archivos separados para disminuir el tiempo de actualización del contenido, y con las
mismas
venta jas que ofrece la programación modular.
De esta manera se han separado lógica y f´ısicamente los archivos de cada cap´ıtulo de la
siguiente
manera:
informe.tex Contiene las deĮniciones de formato de salida del documento e incluye todos los
cap´ıtulos.
nota facultad.tex Es un documento independiente con la nota que se presenta para la aprobación
del
proyecto.
apendice.tex Herramientas utilizadas para las pruebas y redacción del informe Įnal.
bibliograĮa.tex Libros, revistas, sitios web o cualquier otro material al que se haya recurrido
durante
el aprendiza je del tema y realización de la tesis.
Un punto importante a destacar es la organización de los cap´ıtulos, que se realizan en archivos
separados que no están incluidos en el listado anterior, pero se encuentran incluidos en el archivo
informe.tex.
B.2.2. El Preámbulo
El preámbulo es una sección especial de LATEX, donde se deĮnen todas las directivas generales
del
documento, utilizadas en tiempo de compilación; esta sección está comprendida entre el inicio
del archivo
principal .tex, y la sentencia
begindocument. Luego, todo lo que se encuentre entre las siguientes cláusulas, pertenece al
documento
propiamente dicho.
\begin{document}
...
\end{document}
Como Latex se encarga del formato del documento de salida, se ha considerado importante incluir
el
encabezado principal, con comentarios de cada l´ınea para demostrar lo que hace cada paquete
incluido.
1 \ do cument c las s [a4 paper , 1 2 pt ] { re port }
2 \ us e package [ s pani sh ] { babe l }
3 \ us e package [ lat in 1 ] { input enc }
4 \ us e package { f loat }
5 \ us e package { lat e xs ym }
6 \ us e package { graphi cx }
7 \ us e package [ pdf t e x = true , c o l o rl i nks = t rue , plai npage s = t rue ] { hype rr e f }
8 \ us e package { anys i z e }
9 \ us e package { make idx }
10 \ us e package [ no t t o c ] { t o c bi bind }
11 \ us e package { c olor }
12 \ us e package { l i s t ings }
13 \ us e package { array }
14 \ us e package { all t t }
15 \ us e package { f ancyhdr }
16 \ us e package { gl o s sari e s }
Código 1 : Tipo de documento y paquetes Latex adicionales.
La primera l´ınea del Código 1 indica el tipo de documento que en este caso es un ͞reporte͟ , que
no
es mas que un término medio entre el tipo art´ıculo y el tipo libro. También se indica el tamaȂno
de la
tipograf´ıa y el papel utilizado, que en este caso es de tamaȂno A4 estándar. Las l´ıneas 2 y 3
indican el idioma
en que se escribe el documento y además permite la escritura directamente con caracteres
acentuados,
tildes y demás, sin usar comandos Latex que los reemplacen y diĮculten la lectura del código
fuente. La
l´ınea 4 permite el uso de s´ımbolos, mientras que la l´ınea 5 la inclusión de gráĮcos en el

documento. La
l´ınea 6 agrega hiperv´ınculos a las referencias y tablas de contenidos del documento, as´ı
también como
direcciones Web o de correo electrónico mediante comandos especiales. La l´ınea 7 por su parte,
permite
modiĮcar los márgenes, que a pesar de ya estar deĮnidos por el tipo de documento. La l´ınea 8
aȂnade
soporte para ´ındice alfabético. La l´ınea 9 agrega bibliograf´ıa, tablas de contenidos de tablas,
imágenes,
etc, a la tabla de contenidos principal. Las l´ıneas 10, 11 y 12, permiten incluir color al documento,
listas
de códigos enumerados (como el Código 1) y arreglos de varias dimensiones respectivamente. La

l´ınea 13
aȂnade una extensión al entorno ͞verbatim͟ con la posibilidad de truncar las palabras cuando se
llegan al
Įnal del margen.
Por último, las l´ıneas que incluyen los paquetes fancyhdr y glossaries permiten incluir, en primer
lugar,
encabezados complejos y personalizados, en el que se encuentran gráĮcos, l´ıneas horizontales,

número de
página, nombre del cap´ıtulo, sección, entre otras opciones. El segundo paquete, como su
nombre lo indica,
permite incluir una sección aparte que se reĮera a los términos que requieran una deĮnición
concreta y
de fácil ubicación en el documento.

Luego de deĮnir el encabezado con los paquetes adicionales de Latex que permiten ampliar y
mejorar el
resultado Įnal, se procede con la conĮguración de algunos comandos como el listado enumerado,
deĮnición
de colores y los entornos Ňotantes, como aparece en el fragmento de Código 2.
1 %% Codigo s Lat e x
2 \ f l oat s t yl e { plain }
3 \ ne wf l oat { c odigo }{ thb }{ lop }
4 \ f l oat name { c odigo }{ C ódigo }
5 %% Codigo s de c onf i gurac i ón
6 \ f l oat s t yl e { rul ed }
7 \ ne wf l oat { c onf i gurac i on }{ thb }{ lop }
8 \ f l oat name { c onf i gurac i on }{ Conf i gurac i ón }
9 %% Cuadro s de re gi s t ro s ( logs )
10 \ f l oat s t yl e { boxed }
11 \ ne wf l oat { logs }{ thb }{ lop }
12 \ f l oat name { logs }{ Re gi s t ro }
Código 2: DeĮnición de los códigos, conĮguraciones y registros Ňotantes.
De esta manera se pueden escribir listados de códigos y conĮguraciones enumerados por l´ıneas
para ser
referenciados posteriormente. El código con sus respectivos comentarios por l´ınea de la lista
personalizada
se puede ver en el Código 3.
1 \ ls t s e t { %
2 language = TeX , % Lenguaj e ut i l i zado
3 bas i c s t yl e =\ f o o t no t e s i z e , % Tama~no de las f uent e s
4 numbe rs = le f t , % Donde pone r los núme ro de l ´ınea

5 numbe rs t yl e =\ f o o t no t e s i ze , % Tama~no de f uent e s de lo s núme ro s de l ´ınea
6 s t e pnumbe r =1 , % Es pac i o ent re cada l ´ınea
7 numbe rs e p =5 pt , % Di s t anc ia ent re el núme ro y el c ódigo
8 bac kgroundc o l o r =\ c olor { whi t e } , % Color de f ondo
9 s hows pac e s = false , % Mo s t rar e s pac i o s
10 s hows t ri ngs pac e s = false , % Es pac i o de las l ´ıneas
11 showt abs = f als e , % Agre gar t abulac i one s
12 f rame = s ingle , % Re cuadro alrededo r del c ódi go
13 t abs i z e =2 , % Tabulac i ón por de f e c t o
14 capt i onpo s =b , % Po s i c i ón del t ext o capt i on
15 breakl ine s = true , % Fin de l ´ınea
16 bre akat whi t e s pac e = false , % Fin de l ´ınea por e s pac i os en blanc o
17 e s cape ins i de ={\ %* } { * } % Si se qui ere agre gar c oment ari o s de l c ódigo .
18 %e s cape ins i de ={\ %* } { * ) } % Si s e qui e re agre gar c ome nt ari o s del c ódigo .
19 }
Código 3: ConĮguración de la lista personalizada.
Antes de terminar el preámbulo, se escribe el t´ıtulo, los autores y la fecha que son generados
automáticamente con los valores preestablecidos por el tipo de documento.
También se puede agregar un ´ındice alfabético con el comando makeindex ; con maketitle y
tableofcontent se escriben el t´ıtulo y la tabla de contenido de todo el informe, pero deben estar
dentro de
las cláusulas de inicio del documento. Además se pueden agregar páginas independientes del
documento
principal, que quedan sin indexar y en la primera ho ja como por ejemplo una carátula o portada.
B.3. Control de las versiones
En esta sección se describen las caracter´ısticas que convirtieron Subversion en el sistema más
conocido
para manejar grandes proyectos de software con cientos de usuarios editando simultáneamente.
As´ı como
se detalla la importancia y utilidad que tuvo, usar un software de control de versiones de la

documentación
durante el desarrollo de esta tesis.
También se explican los pasos de instalación y conĮguración rápida del repositorio que se ha
utilizado
al momento de comenzar a escribir el informe de este proyecto.
B.3.1 . ¿Qué es Subversion?
Subversion es un software libre que permite el control de versiones de archivos, que fue creado
principalmente para reemplazar al popular CVS .
Una caracter´ıstica importante de Subversion es que, a diferencia de CVS , los archivos

͞versionados͟
no tienen cada uno un número de revisión independiente, sino que todo el repositorio tiene un
único
número de versión que identiĮca un estado común de todos los archivos del repositorio en
cierto punto
en la l´ınea de tiempo de edición de los archivos en cuestión.
Las venta jas que se obtuvieron al traba jar con este sistema para la composición de este informe,
son
las siguientes:
Como se trata de un traba jo en grupo, la edición modular y controlada a la última versión hace
mucho mas fácil la edición y corrección de errores;
No se dispone del mismo tiempo para editar la documentación, por lo que permite editar por
separado siempre con la última versión;
Permite revisar el historial con comentarios de los cambios efectuados y discutir sobre los mismos;
Se mantiene la última versión para todos los editores o usuarios que tengan acceso al
repositorio.
De esta manera Subversion cumple un rol muy importante en el traba jo en equipo durante la
documentación, aunque solo se use una pequeȂna parte de la potencia que tiene, y se utiliza para
grandes
proyectos de desarrollo de software.
B.3.2. ConĮguración del servidor
El servidor de Subversion corre ba jo el sistema operativo OpenBSD 4.4 y al momento de escribir

este
informe, se encuentra disponible lamayor parte del tiempo para acceso remoto protegido por
autenticación
de usuario. La conĮguración consta de un solo repositorio de versiones que se utiliza para

mantener
actualizada esta documentación.
Para la instalación se utiliza el siguiente comando en OpenBSD
$ sudo pkg_add - v ht t p : / / ope nbsd . md5 . c om . ar / pub / OpenBS D /4 . 3/ package s / i 386 /

subvers i on - 1 . 4 . 4 . tgz
...
$ sudo s vnadmi n c reat e / var / svn/
Luego de la instalación se tiene que crear el repositorio, que en este caso se encuentra en
/var/svn/, y
por último se realiza la importación de lo que ser´ıa la primera versión del documento. Pero
antes, según
[15 ] , se recomienda la creación de tres directorios de traba jo:
branches: Para armar ramas de la documentación. Versión de Testeo.
tags: Cuando se completa el testeo, se copia de branches aqu´ı.
trunk: Donde se encuentra el informe Įnal.
De esta manera se puede traba jar con versiones Įnales y prueba de manera separada, hasta que
se las caliĮque como ͞estable͟ ; para este propósito, de mantener la documentación lo más
actualizada
posible (no se traba ja con software) , no son necesarios más que el directorio trunk ; no se
utilizan ramas
adicionales que la principal y estable.
Para importar por primera vez un proyecto, se procede de la siguiente manera:
$ svn i mpo rt / tmp / vpn f i l e : / // var / svn/ vpn -m " Pri me ra ver s i on "
Addi ng / tmp / mypro j e c t / branche s
Addi ng / tmp / mypro j e c t / t ags
Addi ng / tmp / mypro j e c t / t runk
Addi ng / tmp / mypro j e c t / t runk / inf orme . t ex
...
Commi t t e d revi s i on 1 .
A partir de este momento, los clientes, programadores o usuarios pueden acceder al repositorio y
modiĮcar si se tiene los permisos adecuados. Esta lista usuarios con permisos determinados se
controlan
en los archivos authz y passwd dentro del directorio conĮg del repositorio principal. Luego solo
cuenta
editar los archivos y subir las modiĮcaciones con comentarios correspondientes, que se realizan
desde el
lado cliente como se explica a continuación.
B.3.3. Problemas de acceso
Como Subversion puede traba jar de varias maneras, el primer desaf´ıo fue elegir el que mejor se
adapte
a los requisitos de documentación y traba jo remoto. Para esto se ha elegido que el repositorio
traba je como
servidor dedicado y permita tanto las conexiones externas (desde Internet) como las conexiones
internas
(desde la red local) , ya que al usar otros métodos de conexión como inetd o via http se
presentaban
problemas para que cualquier usuario remoto al servidor pudiera acceder al repositorio y además
el
servidor Web de OpenBSD es bastante limitado en cuanto al agregado de módulos de acceso por
SVN
(llamado WebSVN) .
Para conseguir que su funcionamiento sea constante, ya que la dirección IP externa, que permite
el acceso al repositorio a través de Internet, puede cambiar de un momento a otro dejando al

servidor
Subversion inaccesible desde el exterior. Una solución a este problema ha sido la creación de un
script que
realizara el monitoreo de la dirección IP actual y en caso de que cambie, reinicie el servidor

Subversion
con la nueva dirección. El archivo ejecutable se muestra en el detalle 7.
Detalle 7 Script para actualizacion de IP en SVN server
1 # ! / bin/ sh
2 # Guardando di re c c i ón I P ac t ual en / tmp / i p_addre s s . tmp .
3 # $ ( ne t s t at - rn | grep tun0 | grep ^ [0 -9 ] | awk ͛ { print $ 2 } ͛ ) > / tmp / i p_addre s s .
tmp
5 # Variabl e $ I P_ o ld con la ip ant e ri or .
6 I P_ o ld = $ ( cat / tmp / i p_addre s s . tmp )
7 IP =$ ( ne t s t at - rn | gre p t un0 | grep ^ [0 -9 ] | awk ͛ { print $ 2 } ͛ )
9 if [ $ I P ! = $ I P_ o ld ] ; t hen
10 / usr / bin/ pki ll s vns e rve
11 s le ep 5
12 / usr / lo cal / bin/ s vns e rve -d - - li s t en - hos t 1 9 2 . 1 6 8 . 0 . 1 -r / var / svn/
13 / usr / lo cal / bin/ s vns e rve -d - - li s t en - hos t $I P -r / var / svn/
14 e cho $I P > / tmp / i p_addre s s . tmp

15 f i
Para que el sistema monitoree este cambio de dirección cada cierto tiempo, se agrega una l´ınea
al
Cron del sistema para que se ejecute cada hora (en el archivo /etc/crontab) :
0 * * * * / roo t / s vn_ re s t art . sh
De estamanera se consigue un servidor Subversion dedicado lamayor parte del tiempo online,
mientras
la conexión a Internet sea estable y sin importar los cambios de dirección IP.
B.3.4. Clientes de Subversion
Existen varios clientes de Subversion que permiten su utilización más sencilla e intuitiva, pero
todas
ellas cuentan con lasmismas operaciones básicas que el sistema por defecto que utiliza la l´ınea
de comandos
del terminal en la mayor´ıa de los sistemas operativos.
El cliente para l´ınea de comandos por excelencia es el CollabNet Subversion Client, disponible en
sistemas Linux/Unix al momento de instalar el servidor Subversion o en sistemas Windows

mediante la
instalación del cliente desde el sitio Web oĮcial3 .
Para obtener por primera vez todo el contenido del repositorio de un determinado proyecto, se
utiliza
el siguiente comando:
# svn che ckout s vn : / / s e rvi do rs vn / vpn -u us uari o
Si se ingresa la opción -u el sistema solicita la contraseȂna, pero si no se agrega ningún

parámetro,
el sistema primero utiliza el usuario local del equipo, y si no concuerda, se pregunta por el usuario
y
contraseȂna. Para actualizar a posibles cambios en los repositorios del proyecto en cuestión, se
utiliza:
# svn updat e s vn : / / s e rvi do r s vn / vpn

De esta manera se trae al sistema local, la versión más resiente del repositorio. Al realizar
modiĮcaciones en cualquier archivo que pertenezca al repositorio, se utiliza el siguiente comando

para
actualizar los cambios:
# svn c ommi t s vn : / / s e rvi do r s vn / vpn -m " c oment ari o s "
Mientras ningún usuario se encuentre modiĮcando la misma l´ınea de un archivo en particular,
Subversion no notiĮcará conŇictos. Pero si esto llegase a ocurrir, se pueden recurrir a

herramientas
de comparación de versiones como ͞WinMerge͟ para sistemas Windows o el que viene incluido
en
TortoiseSVN.
El cliente de Subversion para Windows más usado y de código abierto es TortoriseSVN, que traba
ja
en conjunto con el explorador de archivos como un submenú contextual. Las caracter´ısticas que
incluye
se encuentran todas juntas en el menú principal, entre ellas:
Funciones estándar de SVN a un solo clic (commit , update, checkout) ,
Explorador del repositorio,
Estad´ısticas de las versiones, por autor y por fecha,
Generación de una gráĮca con las revisiones para las distintas ramas de desarrollo.
Para Įnalizar esta sección, es importante destacar que, el hecho de llevar el control de versiones
de
lo que se esta desarrollando a lo largo de la tesis, tiene un valor incalculable en cuanto a

información
estad´ıstica y profesional, ya que resume cada paso del traba jo que se ha realizado y muestra el
tiempo
que se lleva investigando sobre la temática en cuestión.
Bibliograf´ıa
[1 ] Oleg Kolesnikov y Brian Hatch. Gu´ıa Avanzada Redes Privadas Virtuales con Linux. PEARSON
EDUCACI ÓN, S .A. , Madrid, 2003.
[2 ] Alex Withers. OpenBSD as a VPN Solution. Sys Admin, the journal for UNIX and Linux systems
administrators (http://www.samag.com) .
[3 ] Marcelo Guazzardo. VPN, Túneles en el ciber espacio. Revista TuxInfo, AȂno 1 , Número 2,
Diciembre
de 2007.
[4] Manual en OpenBSD o Linux según corresponda. Sintaxis: ͚man comando ͛ .
[5 ] The oĸcial IPSec Howto for Linux (http://www. ipsec-howto.org) .
[6 ] Diĸe-Hellman - Wikipedia (http://es.wikipedia.org/wiki/Diĸe-Hellman)
[7] CertiĮcados Digitales - Wikipedia (http://es.wikipedia.org/wiki/CertiĮcado digital)
[8 ] Autoridad de CertiĮcación - Wikipedia (http://es.wikipedia.org/wiki/Autoridad de

certiĮcación)
[9 ] El estándar X.509 - Wikipedia (http://es.wikipedia.org/wiki/X.509)
[10] OpenVPN de Wikilibros (http://es.wikibooks.org/wiki/OpenVPN)
[11 ] Grupo de traducción al castellano de RFC (http://www.rfc-es.org/) .
[12 ] Microsoft MSN Encarta (http://es.encarta.msn.com) .
[13 ] Wikipedia en inglés (http://en.wikipedia.org/) .
[14] Wikipedia en castellano (http://en.wikipedia.org/) .
[15 ] Ben Collins-Sussman, Brian W. Fitzpatrick y Michael Pilato. Control de versiones con
Subversion.
[16 ] Wikilibros: Manual de LATEX.
[17] Gabriel Valiente Feruglio. Composición de textos cient´ıĮcos con LATEX. 1999.
[18] átopos. LATEXpara Humanidades. 28 de Noviembre de 2005.
[19 ] Joaqu´ın Ataz López. Creación de Įcheros LATEXcon GNU Emacs. 2004.
Glosario
AH (Authentication Header)
Parte del conjunto de protocolos de IPSec que ofrece servicios de autenticación de los paquetes
IP. .
61 , 63
CHAP (Challenge Handshake Authentication Protocol)
Es un protocolo de autenticación por desaf´ıo mutuo, que se usaba en comunicaciones PPP con el
proveedor de servicios de Internet (ISP) . . 38
DES (Data Encryption Standard)
Es un método de encriptación de información considerado inseguro para varias aplicaciones, el

cual
se ha reemplazado por AES (Advanced Encryption Standard) . . 6
DMZ (DeMilitarized Zone)
Una zona desmilitarizada es una red local que se ubica entre la red interna de una organización
e Internet . El ob jetivo es que las conexiones desde la red interna y la externa a la DMZ estén
permitidas, mientras que las conexiones desde la DMZ sólo se permitan a la red externa; los hosts
en
la DMZ no pueden conectar con la red interna. Esto permite que los equipos de la DMZ puedan dar
servicios a la red externa a la vez que protegen la red interna en el caso de que intrusos
comprometan
la seguridad de los servidores de la zona desmilitarizada. La DMZ se usa habitualmente para ubicar
servidores que es necesario que sean accedidos desde fuera, como servidores de e-mail, Web y
DNS . .
101 , 106
ESP (Encapsulating Security Payload)
Parte del conjunto de protocolos IPSec que permite el encapsulado de información útil,
obteniendo
servicios como conĮdencialidad y autenticación de paquetes IP. . 61 , 63
Ethernet
EspeciĮcación de red de área local (LAN) desarrollada en 1976 por Xerox, en cooperación con
DEC
e Intel, originalmente para conectar los miniordenadores del Palo Alto Research Center (EEUU).
Frame Relay
Es una técnica de comunicación mediante retransmisión de tramas, que consiste en una forma
simpliĮcada de tecnolog´ıa de conmutación de paquetes que transmite una variedad de tamaȂnos

de
tramas para datos, ideal para la transmisión de grandes cantidades de datos. Se utiliza para la
transmisión de voz y datos a alta velocidad entre dos o más redes LAN separadas
geográĮcamente. .
13
FTP (File Transfer Protocol)
Protocolo de transferencia de archivos que se utiliza para enviar y recibir archivos en texto plano o
binario entre dos terminales. . 79
GNU
Acrónimo recursivo que signiĮca ͞GNU is Not Unix͟ , cuya Įlosof´ıa, encabezada por Richard
Stallman, permitió la utilización de software liberado por licencias de tipo GPL que permiten
copiar, distribuir y modiĮcar el código fuente. . 20
GRE (Generic Routing Encapsulation)
Es un protocolo (número 47) destinado al establecimiento de túneles a través de Internet. Se

utiliza
en para establecer conexiones VPN con PPTP o PPP. . 10, 38
HMAC (keyed-Hash Message Authentication Code)
En criptograf´ıa, es un tipo de código de autenticación de mensa jes, que se calcula utilizando un
algor´ıtmo espec´ıĮco que incluye la función criptográĮca hash para combinarla con la clave
secreta.
Se utiliza para veriĮcar la integridad de datos y autenticidad del mensa je. . 81

IPCOMP (IP Payload Compression Protocol)
Es un protocolo de compresión de ba jo nivel para datagramas IP deĮnido en la RFC 3173. Se

utiliza
para reducir el tamaȂno de datos transmitidos y ahorrar ancho de banda o mejorar conexiones de
ba ja velocidad. . 62, 63
IPSec (Internet Protocol Security)
Es la abreviación de IP Security (seguridad IP) , que es un conjunto de protocolos diseȂnados para
asegurar el tráĮco sobre el protocolo IP. . 16, 18, 61 , 81 , 108
IPv4 (Internet Protocol versión 4)
Versión 4 del protocolo IP que se utiliza en Internet y permitió el crecimiento del mismo. Este
protocolo utiliza direcciones de 32 bits, asignadas a cada equipo conectado. Además se tienen
direcciones espec´ıĮcas para uso en redes de area local. . 41 , 61
IPv6 (Internet Protocol versión 6)
Es la nueva versión del protocolo IP, que entre otras mejoras, utiliza direcciones de 128 bits
permitiendo mayor cantidad de conexiones simultáneas. Además en IPv6 se tiene IPSec como
tecnolog´ıa obligatoria. . 61
ISAKMP (Internet Security Association and Key Management Protocol)
Protocolo de gestión de claves y asociación de seguridad de Internet que se utiliza para gestionar
el intercambio de claves entre equipos de una VPN con IPSec. . 16, 64
kernel
Es el núcleo de un sistema operativo que permite la intercomunicación entre procesos,
administración de memoria, control del hardware, entre otras funciones. . 20
LAN (Local Area Network)
Es la tecnolog´ıa usada en redes internas que permiten comunicar múltiples sistemas a un medio
compartido. Entre sus caracter´ısticas se pueden destacar el ancho de banda total elevado, ba jo
retardo de transmisión, ba ja tasa de error y además se trata de una red de propiedad privada. .
110
LZO (Lempel-Ziv-Oberhumer)
Es un algor´ıtmo de compresión de datos de menor pérdida enfocado en la velocidad de
descompresión. Fue escrito originalmente en ANSI C , pero luego portado a Perl, Python y Java. .
81
MPLS (Multiprotocol Label Switching)
Es un mecanismo de transporte de datos estándar que opera entre la capa de enlace de datos y la
capa de red del modelo OSI. Fue diseȂnado para uniĮcar el servicio de transporte de datos para las
redes basadas en circuitos y las basadas en paquetes, por lo que puede transportar distinto tipo de
tráĮco, incluso voz y paquetes IP. . 13
MPPE (Microsoft Point-to-Point Encryption)
Es un protocolo utilizado para encriptar comunicaciones a través de PPP y establecer enlaces VPN.
Utiliza el algoritmo de encriptación RSA RC4 y soporta llaves de 40, 56 y 128 bits, que se cambian
regularmente para aumentar la seguridad. . 39, 42, 45
MS-CHAP (Microsoft Challenge Handshake Authentication Protocol)
Es la versión desarrollada por Microsoft del protocolo CHAP con numerosas diferencias. Existen
dos versiones, la primera ha sido eliminada en Windows Vista, y la segunda versión, denominada
MS-CHAPv2 fue introducida a partir de Windows 2000. . 38, 42, 45
Nessus
Software multiplataforma que escanea vulnerabilidades en redes y sistemas, distribuido de forma
gratuita para usuarios Įnales pero de pago para empresas. Su desarrollador es la empresa Tenable
Network Security. . 80
Oakley (Oakley Key Determination Protocol)
Protocolo que permite el intercambio de claves entre partes mediante el algoritmo Diĸe-Hellman,
utilizado para establecer VPN con IPSec. . 64

OpenBSD
Sistema Operativo (monol´ıtico) tipo Unix basado en el sistema 4.4BSD proveniente de NetBSD a
raiz de discuciones ĮlosóĮcas. . 17
OpenSSL
Es una implementación de código abierto de los protocolos SSL y TLS , que soporta varios
algor´ıtmos
criptográĮcos y se utiliza para la generación de claves en una VPN (o donde sea necesario) . . 14
PFS (Perfect Fordward Secrecy)
Secreto de env´ıo perfecto es una caracter´ıstica que implementa IKE para evitar que todos datos
cifrados esten comprometidos cuando la clave lo esté. En este caso solamente estarán
comprometidos
los datos cifrados con esa clave, no los demás. . 64
PGP (Pretty Good Privacy)
Es un programa que provee de privacidad criptográĮca y autenticación, utilizado para Įrmar,

cifrar
y descifrar mensa jes de correo electrónico, para saber que el remitente es quien dice serlo. . 14
PPP (Point to Point Protocol)
El protocolo punto a punto permite establecer una conexión a nivel de enlace entre dos nodos.
Las funciones más básicas que ofrece son: autenticación y asignación dinámica de dirección IP.
Su
desventa ja es que no encripta el tráĮco de paquetes. . 50, 97
PPTP (Point to Point Tunneling Protocol)
El protocolo punto a punto mediante túnel ha sido desarrollado por un conjunto de empresas
cuyo
ob jetivo consist´ıa en utilizar el viejo protocolo conocido PPP para realizar conexiones punto a
punto
seguras ba jo el protocolo TCP/IP. . 16, 38, 92, 113
PSK (Pre-Shared Key)

Clave pre-compartida es un método de autenticación utilizado en la Fase I por el protocolo IKE
para establecer una comunicación VPN con IPSec. . 64, 72
RAS (Remote Access Service)
Es un conjunto de herramientas que combinan hardware y software para habilitar el acceso

remoto
a una red. Fue utilizado inicialmente por sistemas Windows que permit´ıan el acceso mediante
conexión por modem utilizando cualquier cliente RAS o un cliente PPP. . 13
SA (Security Association)
La asociación de seguridad determina qué parámetros espec´ıĮcos utilizar para proteger los
paquetes.
Se pueden conĮgurar de forma manual o automática (mediante IKE) , siendo esta última la mejor
opción cuando se tiene una red muy grande. . 64, 66, 84
SAD (Security Associations Database)
La base de datos de asociaciones de seguridad forma parte de IPSec y contiene información
conĮdencial como claves, números de secuencia, etc. . 64, 65
SCP (Secure Copy)
Es una aplicación de transferencia segura de archivos entre un host local y otro remoto, que
utiliza
el protocolo SSH. . 57
SKEME (Secure Key Exchange Mechanism)
Mecanismo de intercambio de claves seguras, cuya funcionalidad se utiliza en el protocolo IKE

para
el establecimiento de VPN con IPSec. . 64
SMB (Server Message Block)
Es un protocolo utilizado para compartir archivos, impresoras, puertos otros tipos de

comunicaciones
a través de dos o más nodos de una red. Este opera en el nivel de aplicación. . 79, 91 , 94
SPD (Security Policy Database)
Es una base de datos con normativas de seguridad que utiliza IPSec para comprobar qué hacer
con
paquetes IP salientes. . 66
SPI (Security Parameters Index)Índice de parámetros de seguridad es solo un número de 32 bits

que se uiliza de ´ındice en la recepción
de paquetes IP mediante IPSec. . 66
SSH (Secure SHell)
Es un protocolo de red que permite el intercambio de datos mediante un canal seguro entre dos
dispositivos de red. SSH es un reemplazo al antiguo Telnet que enviaba datos en texto plano. . 15,
20, 50, 67
Subversion
Sistema de control de versiones para el desarrollo colectivo de software o documentación. . 115
Swap
Es el término en inglés del espacio de intercambio de una zona del disco r´ısido (archivo o
partición)
que se utiliza para guardar los bloques que estaban en memoria y que no se utilizan para liberar la
misma para otros procesos. . 80
TCP (Transmission Control Protocol)
Es un protocolo de comunicación orientado a la conexión que traba ja en el nivel de transporte

(capa
4) del modelo OSI. TCP aȂnade las funciones necesarias para prestar un servicio libre de errores,
sin
pérdidas y con seguridad en la comunicación de dos sistemas. . 38, 41
TCP/IP (Internet Protocol Suite)
Es un conjunto de protocolos de comunicación que se utiliza en In ternet y en otras redes

similares.
Sus componentes más importantes son TCP e IP, y se encuentran en representados en un modelo
de
capas, que van desde la capa de enlace hasta la capa de aplicación, pasando por la capa de
Internet
y la de transporte. . 5
TCPdump
Software en modo texto que permite monitorear los paquetes que entran y salen de una interfaz
de red. Fue desarrollado por Van Jacobson, Craig Leres and Steven McCanne. Esta herramienta es
muy utilizada por administradores de red para la depuración de errores y control de una red. . 78
TortoriseSVN
Cliente Subversion para Windows que se agrega al menú contextual del sistema cuando se traba
ja
con el explorador. . 125
traceroute
Es un software libre desarrollado para sistemas tipo Unix que permite seguir el rastro de un
paquete
entre host origen y host destino. . 78
tracert
Es un software que viene con Windows (versión 2000 en adelante) que permite seguir el rastro de
un paquete entre host origen y host destino. . 78
Triple DES (Triple Data Encryption Standard)
Es un método de encriptación de información basado en DES que se utiliza tres veces. . 6
VNC (Virtual Network Computing)
Es un sistema de visualización y control de escritorio remoto desarrollado por AT&T, que
actualmente hasta permite la transferencia de archivos. . 46, 79, 96
VPN
Virtual Private Network, que en castellano se traduce a Red Privada Virtual o RPV, que se reĮere
a la conexión de redes locales en una sola gran red a través de un canal seguro y Įable,
atravezando
un medio hostil como Internet . . 5
Wireshark
Es una aplicación de Įltrado de paquetes de libre distribución, con una amigable intrefaz gráĮca
que
permite monitorear el tráĮco de datos que entran y salen de una interfaz de red determinada.
Esta
es una derivación de Ethereal desarrollado inicialmente por Lyle Roussel, y actualmente

mantenido
por una gran comunidad de usuarios y desarrolladores. . 78

VPN - 131

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

VPN - 131

Загружено:

Авторское право:

Доступные форматы

Investigación e Implementación de Redes Privadas Virtuales

Gustavo Maximiliano Cortez

Nicolás Federico Formoso Requena

1 .1. ¿Qué es una VPN? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1 .1 .1. Autenticidad, integridad y conĮdencialidad. . . . . . . . . . . . . . . . . . . . . . 6

1 .1 .3. Ventajas y desventajas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1 .2. Topologıas de las VPN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1 .2.1. VPN Host a Host. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1 .2.2. VPN Host a Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1 .2.3. VPN Red a Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1 .3. Interacción con el Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1 .3.1 . Servidor VPN y Firewall en el mismo equipo . . . . . . . . . . . . . . . . . . . . . 9

1 .3.2. Servidor VPN en paralelo con el Firewall . . . . . . . . . . . . . . . . . . . . . . . 10

1 .3.3. Servidor VPN detrás del Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1 .4. JustiĮcacion de las VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1 .5. Consideraciones importantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1 .5.1 . Comparación con otras tecnologıas . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1 .5.2. PlaniĮcacion de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1 .5.3. Administración de claves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1 .5.4. Motivos de requerir una VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2. Realización del proyecto 16

2.2. Proceso de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.1 . Alcance del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.2. Limitaciones técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.3. Limitaciones económicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3. Entornos de evaluación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.1 . Sistemas BSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.2. Caracterısticas de OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.3. Recomendaciones de instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.4. Sistemas Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.5. Sistemas Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 . ConĮguracion del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1 .2. Las Redes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2. ConĮguracion general del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.1 . ConĮguracion de PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.2. Permitir el acceso a Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3. Reglas de Įltrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.1 . Funcionamiento básico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3.2. ConĮguracion de Packet Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4. Esquema de conexi´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5. Automatizaci´on del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.5.1 . Conexión a Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.5.2. Asociando un nombre de dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5.3. Actualizaci´on de la direcci´on IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.5.4. Utilidades de un dominio propio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.6. ConĮguracion de los clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.6.1 . Servidor DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.6.2. Finalizando la conĮguraci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.7. Recursos utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.7.2. Modem ADSL y Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4. VPN usando PPTP 37

4.1 . Introducci´on a PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1 .1 . Funcionamiento de PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1 .2. Autenticaci´on y cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2. PPTP con Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.1 . Modo de conexi´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.2. Directivas del Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2.4. Cliente PPTP con Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.3. PPTP con software libre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3.1 . Caracter´ısticas de PoPToP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3.2. Instalaci´on de PoPToP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3.3. ConĮguraci´on de PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3.4. Estableciendo conexi´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44