tesis.ipn.mxtesis.ipn.mx/jspui/bitstream/123456789/17628/1... · en la ciudad de méxico el día...

InstItuto PolItécnIco nacIonal. EscuEla suPErIor dE IngEnIEría mEcánIca y EléctrIca.

maEstría En cIEncIas En IngEnIEría dE tElEcomunIcacIonEs.

“ARQUITECTURA DE GESTIÓN DE SERVICIOS EN REDES

CONVERGENTES”

TESIS QUE PARA OBTENER EL GRADO DE

MAESTRO EN CIENCIAS EN INGENIERIA DE TELECOMUNICACIONES

PRESENTA

ING. CARLOS MAURICIO GÓMEZ SANDOVAL.

DIRECTORES DE TESIS

DR. SALVADOR ÁLVAREZ BALLESTEROS

M. EN C. CHADWICK CARRETO ARELLANO

México, DF. Junio del 2012

INSTITUTO POLITÉCNICO NACIONAL

SECRETARÍA DE INVESTIGACIÓN Y POSGRADO

CARTA CESIÓN DE DERECHOS

En la Ciudad de México el día 6 del mes Junio del año 2012, el (la) que suscribe

Lic. Carlos Mauricio Gómez Sandoval, alumno del Programa de Maestría en

Ciencias en Ingeniería en Telecomunicaciones con número de registro A100486,

adscrito a la Escuela Superior de Ingeniería Mecánica y Eléctrica, Unidad

Zacatenco, manifiesta que es autor (a) intelectual del presente trabajo de Tesis bajo

la dirección de la Dr. Salvador Álvarez Ballesteros y el M. en C. Chadwick Carreto

Arellano y cede los derechos del trabajo intitulado “ARQUITECTURA DE

GESTIÓN DE SERVICIOS EN REDES CONVERGENTES”, al Instituto

Politécnico Nacional para su difusión, con fines académicos y de investigación.

Los usuarios de la información no deben reproducir el contenido textual, gráficas o

datos del trabajo sin el permiso expreso del autor y/o director del trabajo. Este

puede ser obtenido escribiendo a la siguiente dirección

[email protected]. Si el permiso se otorga, el usuario deberá dar el

agradecimiento correspondiente y citar la fuente del mismo.

LIC. CARLOS MAURICIO GÓMEZ SANDOVAL

D E D I C A T O R I A

Dedico este trabajo de tesis a mi familia, en especial a mi madre que siempre apoya todos mis proyectos y me ha dado las fuerzas para seguir levantándome de los tropiezos u obstáculos que se han presentado en mi camino a encontrar el éxito, a mi hermana por su amistad y cariño que siempre he percibido, y a mi abuelita por la sabiduría que me ha compartido a lo largo de mi vida.

A G R A D E C I M I E N T O S

Agradezco.

A mi madre, que como mi mejor amiga, me ha enseñado a ser una persona de bien y es ella quien me aconseja ver la opción de tomar un posgrado, y así estar mas preparado para el mercado profesional que cada vez es mas competido. Gracias madre por todos tus consejos, por el amor que me das y por apoyar mi plan de vida.

Al Instituto Politécnico Nacional y sus maestros por brindarme los medios y conocimientos para formarme como un profesionista de calidad.

A mi asesores de tesis, Salvador por compartir su experiencia tanto de vida como profesional, a Chadwick por el apoyo que me brindo para realizar este proyecto, por la fe que tuvo en mi trabajo y por su ánimo que a todo mundo contagia.

A mis amigos Gustavo y Luis Enrique que mas bien son mis hermanos que siempre estuvieron al pendiente mio, por su aliento que me dieron durante este tiempo.

A mi amigo Luis Eduardo por los consejos que me dio para la redacción de esta tesis.

A Víctor y Norma por darme su amistad y por compartir esas fiestas, las cuales hicieron que la maestría fuera divertida.

Í N D I C E G E N E R A L

Lista de Figuras.

Lista de Tablas.

Resumen .................................................................................................................................................. i

Abstract ................................................................................................................................................... ii

CAPITULO I.

1. INTRODUCCIÓN.

1.1. Introducción .................................................................................................................................. 1

1.2. Justificación ................................................................................................................................... 2

1.3. Objetivo ......................................................................................................................................... 3

1.3.1. Objetivos específicos .................................................................................................................. 3

1.4. Virtualización. ................................................................................................................................ 4

1.4.1. ¿Por qué la virtualización es útil?. .............................................................................................. 5

1.4.2. Terminología .............................................................................................................................. 6

1.5. La Nube.......................................................................................................................................... 7

1.5.1. Capas del cómputo en la nube. .................................................................................................. 7

1.5.2. Tipos de nubes. ........................................................................................................................... 9

1.6. Calidad del Servicio. .................................................................................................................... 10

1.6.1. Reducción del Jitter. ................................................................................................................. 12

1.6.2. Requerimientos de las Aplicaciones para Calidad del Servicio... ............................................. 12

1.7. Evolución de las estrategias para aprovisionar la Calidad del Servicio ....................................... 14

1.7.1. Historia de la Calidad del Servicio en Internet. ........................................................................ 15

1.8. Ingeniería de Tráfico. .................................................................................................................. 32

1.8.1. Caracterización de la demanda de tráfico. ............................................................................... 33

ÍNDICE GENERAL

1.8.2. Objetivos de Grado de Servicio (GoS). ...................................................................................... 33

1.8.3. Controles de tráfico y dimensionamiento. ............................................................................... 33

1.8.4. Monitoreo del rendimiento. .................................................................................................... 34

1.9. Control de tráfico. ....................................................................................................................... 35

1.9.1. Elementos de Control de tráfico. .............................................................................................. 36

1.9.2. Operaciones básicas del control de tráfico. ............................................................................. 44

1.10. Resumen del capítulo. ................................................................................................................. 46

CAPITULO II.

2. PRESENTACION DEL PROBLEMA Y SOLUCIÓN PROPUESTA.

2.1. Presentación del problema. .......................................................................................................... 47

2.2. Soluciones existentes. ................................................................................................................... 48

2.2.1. Citrix NetScaler. ........................................................................................................................... 49

2.3. Descripción de las características principales de la Solución ........................................................ 51

2.3.1. Prestaciones para la manipulación del tráfico. ........................................................................... 51

2.3.2. Prestaciones de la virtualización. ................................................................................................ 52

2.3.3. Prestaciones de servicios de nube privada. ................................................................................ 55

2.4. Resumen del capítulo. ................................................................................................................... 57

CAPITULO III.

3. DISEÑO DE LA SOLUCIÓN.

3.1. Introducción. ................................................................................................................................. 59

3.2. Arquitectura Propuesta. ............................................................................................................... 59

3.2.1. Hipervisor VirtualBox. ................................................................................................................. 61

3.2.2. Iproute ......................................................................................................................................... 62

3.2.3. HTB (Hierarchical Token Bucket). ................................................................................................ 63

3.2.4. OpenVPN. .................................................................................................................................... 63

ÍNDICE GENERAL

3.2.5. Servidor ISC DHCP3.. ................................................................................................................... 64

3.2.6. Squid. ........................................................................................................................................... 64

3.2.7. Quagga. ....................................................................................................................................... 65

3.2.8. BIND. ............................................................................................................................................ 66

3.2.9. Netfilter. ...................................................................................................................................... 66

3.2.10. Freeradius. .............................................................................................................................. 67

3.2.11. Hostapd. ................................................................................................................................. 67

3.2.12. Wireshark. .............................................................................................................................. 68

3.2.13. LAMPP. ................................................................................................................................... 69

3.3. Control de Tráfico con Linux. ......................................................................................................... 70

CAPITULO IV.

4. CASO DE ESTUDIO.

4.1. Introducción. ................................................................................................................................. 72

4.2. ¿Por qué no funciona bien por defecto?. ..................................................................................... 73

4.3. Descripción de los componentes de la red de prueba. ................................................................. 76

4.3.1. BlackIaaS. ..................................................................................................................................... 76

4.3.2. BlackProxy. .................................................................................................................................. 77

4.3.3. BlackBox. ..................................................................................................................................... 77

4.3.4. BlackLamp. .................................................................................................................................. 78

4.3.5. BlackSar. ...................................................................................................................................... 78

4.3.6. Clientes. ....................................................................................................................................... 79

4.4. Pruebas y mediciones. ................................................................................................................... 80

4.4.1. Cache transparente de web usando Netfilter, iproute2 y Squid. ............................................... 81

4.4.2. Caracterización del tráfico a controlar. ....................................................................................... 83

4.4.3. Control de tráfico. ....................................................................................................................... 86

ÍNDICE GENERAL

CAPITULO V.

5. Resultados, conclusiones y trabajo a futuro.

5.1. Introducción. ................................................................................................................................. 93

5.2. Mediciones. .................................................................................................................................. 95

5.3. Conclusiones. ................................................................................................................................. 99

5.3.1. Trabajo a Futuro. ....................................................................................................................... 101

REFERENCIAS BIBLIOGRÁFICAS ......................................................................................................... 103

ANEXO A: Articulo: Virtualización de dispositivos de Capa 3 y 4 utilizando Linux. Vigesimosegunda

reunión internacional de otoño de comunicaciones, computación, electrónica, automatización,

robótica y exposición industrial ROC&C’2011, celebrada del 29 de noviembre al 3 de diciembre del

2011 en Acapulco, Gro.

ANEXO B: Código para implementación de la solución.

I N D I C E D E F I G U R A S

FIGURA 1.1. Capas del cómputo en la nube. ............................................................................................................... 8

FIGURA 1.2. Relación entre la probabilidad de llegada de los datagramas y los parámetros de QoS ...................... 11

FIGURA 1.3. Fluctuación del retardo “Jitter” ............................................................................................................... 12

FIGURA 1.4. Efectos de la congestión en el tiempo de servicio y el rendimiento. ..................................................... 13

FIGURA 1.5. Cabecera IPv4. ..................................................................................................................................... 16

FIGURA 1.6. Funcionamiento de RSVP en Multicast. ................................................................................................ 18

FIGURA 1.7. Reparto de recursos en IntServ ............................................................................................................ 19

FIGURA 1.8. Problema de escalabilidad de RSVP .................................................................................................... 20

FIGURA 1.9. Cabecera IPv6 ...................................................................................................................................... 21

FIGURA 1.10. Campo DS (RFC 2474) ....................................................................................................................... 22

FIGURA 1.11. Cabecera IPv4 con DiffServ ................................................................................................................ 22

FIGURA 1.12. Cabecera IPv6 con DiffServ ................................................................................................................ 23

FIGURA 1.13. Aparición del campo DS en IPv4 e IPv6 ............................................................................................. 23

FIGURA 1.14. Políticas de Tráfico en el Servicio AF .................................................................................................. 27

FIGURA 1.15. Reparto de recursos en DiffServ ......................................................................................................... 27

FIGURA 1.16. Funcionamiento de DiffServ en Internet .............................................................................................. 28

FIGURA 1.17. Funciones QoS desempeñadas por los enrutadores .......................................................................... 29 FIGURA 1.18. Etiquetado de tramas según 802.1Q. ................................................................................................. 30

FIGURA 1.19. Encolamiento de paquetes en enrutadores y conmutadores (nivel 2 y 3). .......................................... 31

FIGURA 1.20. Clasificación de la Ingeniería de tráfico en 4 categorías. .................................................................... 32

FIGURA 1.21. Escalas de tiempo para las tareas de Gestión y operación de redes. ................................................. 34

FIGURA 1.22. Tareas de la Gestión y operación de Redes ....................................................................................... 35

FIGURA 1.23. Flujos en una videoconferencia. .......................................................................................................... 37

FIGURA 1.24. Cola FIFO............................................................................................................................................ 38

FIGURA 1.25. Cola FIFO-Fast. .................................................................................................................................. 39

FIGURA 1.26. Filtro de Tokens y Buckets. ................................................................................................................. 40

FIGURA 1.27. Filtro de Token Bucket. ....................................................................................................................... 41

FIGURA 1.28. Cola SFQ. ........................................................................................................................................... 42

FIGURA 1.29. Encolamiento con clases. ................................................................................................................... 42

FIGURA 1.30. Encolamiento con priorización ............................................................................................................ 43

ÍNDICE DE FIGURAS

FIGURA 2.1. Escenarios del pasado vs. Arquitectura Propuesta. .............................................................................. 51

FIGURA 3.1. Descripción arquitectura Nivel 1. ........................................................................................................... 60

FIGURA 3.2. Descripción Arquitectura Nivel 2. .......................................................................................................... 60

FIGURA 3.3. Descripción Arquitectura Nivel 3A. ........................................................................................................ 61

FIGURA 3.4. Descripción Arquitectura Nivel 3B. ........................................................................................................ 61

FIGURA 3.5. Interfaz grafica de VirtualBox. ............................................................................................................... 62

FIGURA 4.1. Esquema sencillo del montaje de la red de prueba. .............................................................................. 74

FIGURA 4.2 Esquema general para control de tratico. .............................................................................................. 75

FIGURA 4.3 Diagrama de flujo del tráfico................................................................................................................... 83

FIGURA 4.4. Caracterización tráfico debido al Cliente Remoto 1. Protocolo FTP. ..................................................... 84

FIGURA 4.5. Caracterización tráfico debido al Cliente Remoto 1. Protocolo HTTP. .................................................. 85

FIGURA 4.6. Caracterización tráfico debido al Cliente Remoto 1. Protocolo SSH. .................................................... 85

FIGURA 4.7. Árbol de clases para HTB. .................................................................................................................... 89

FIGURA 4.8. Diagrama de flujo sencillo para los filtros en iptables. ........................................................................... 90

FIGURA 5.1. Representación Grafica del Script Para Control de Ancho de Banda a Nivel de

Protocolos. .................................................................................................................................................................. 94

FIGURA 5.2. Curva de tendencia para el tráfico debido al Cliente Remoto 1. (Protocolo SSH)................................. 95

FIGURA 5.3. Curva de tendencia para el tráfico debido al Cliente Remoto 1. (Protocolo HTTP)............................... 96

FIGURA 5.4. Curva de tendencia para el tráfico debido al Cliente Remoto 1. (Protocolo FTP) ................................. 97

FIGURA 5.5. Control de trafico por hosts en nivel 1 y 2, usando el protocolo ssh. .................................................. 98

FIGURA 5.6. Distribución del tráfico global por protocolos de los Clientes 1 y 2........................................................ 99

Í N D I C E D E T A B L A S

TABLA 1.1. Parámetros de Calidad de Servicio .......................................................................................................... 11

TABLA 1.2. Requerimientos de Calidad de Servicio de las aplicaciones ..................................................................... 14 TABLA 1.3. ¿Reserva o Prioridad? .............................................................................................................................. 15

TABLA 1.4. Significado del campo precedencia .......................................................................................................... 16

TABLA 1.5. Clasificación de las aplicaciones en IntServ ............................................................................................ 17

TABLA 1.6. Tipos de servicio en IntServ .................................................................................................................... 19

TABLA 1.7. Campo DSCP .......................................................................................................................................... 24

TABLA 1.8. Tipos de Servicio en DiffServ ................................................................................................................... 24

TABLA 1.9. Significado de las clases del DSCP .......................................................................................................... 24

TABLA 1.10. Códigos del Servicio AF. ........................................................................................................................ 25

TABLA 1.11. Valores del campo DSCP. ...................................................................................................................... 26

TABLA 1.12. Configuración QoS recomendada en conmutadores Catalyst 3560 para VoIP. ..................................... 31

TABLA 1.13. Mecanismos de Control de Congestión en Internet. ............................................................................... 38

TABLA 2.1. Comparativa Arquitectura Vs. Solución existente. .................................................................................... 50

TABLA 3.1. Relaciones entre Elementos de TC y Operaciones de control. ................................................................ 71

i

R E S U M E N

En el presente trabajo se propone, describe e implementa una infraestructura complementaria que asegura y controla que usuarios obtienen la mejor calidad en los servicios sobre una red convergente y quiénes no. El caso de estudio se realiza en un ambiente de una pequeña empresa, la cual cuenta con un enlace ADSL para su salida a Internet con tasas de transferencias regularmente bajas. Aunado a esto el tráfico sin control generado por los usuarios conlleva a un rendimiento pobre de la red. Este escenario no solamente es propio del ambiente de las PYMES, si no por el contrario es muy común, así esta solución podría aplicarse a diferentes ambientes como lo son el educativo, gubernamental, etc.

A lo largo del trabajo se detallan el diseño e implementación de la arquitectura propuesta, además se especifican las características del control de tráfico y las herramientas que se han utilizado. Cabe mencionar que el desarrollo de la solución esta basado en herramientas de código libre, como el sistema Operativo Ubuntu 11.10, el cual posee gran compatibilidad con el hardware actual, iproute2 soporta varios métodos de clasificación, priorizado, compartición y limitación tanto de trafico entrante como saliente, y Squid para complementar las brechas del anterior.

La solución propuesta se puede implementar en cualquier PC de escritorio, sin tener que desembolsar una cantidad significativa de dinero, lo cual es uno de los objetivos primordiales en las PYMES, que es la reducción de costes de operación.

El caso práctico fue puesto en marcha en un segmento de la red de la ESCOM, que a su vez es un segmento de la red institucional del Instituto Politécnico Nacional (IPN), simulando la red de una PYME donde usuarios y equipos requieren de diferentes servicios. Esta red convergente contempla servicios ofrecidos por una nube privada, servicios de video, voz y datos.

Se hace hincapié en el analisis de las ventajas y desventajas de la infraestructura propuesta, asi como una comparación con plataformas desarrolladas en ambientes de grandes empresas donde los requerimientos son mayores, haciendo la observación que se podría optar por la solución que se propone. Además se describen los objetivos que se pretenden alcanzar al tener la arquitectura en estado operativo.

ii

A B S T R A C T

This paper proposes, describes and implements a complementary infrastructure that secures and controls what users get the best quality services on a converged network and who does not. The case study is conducted in an atmosphere of a small company, which has an ADSL connection for output to the Internet with low transfer rates regularly. Added to this, uncontrolled traffic generated by users leads to poor network performance. This scenario not only is proper environment for SMEs (Small and Medium Enterprises), unless the contrary is very common, so this solution could be applied to different environments such as educational, government, etc.

Throughout the work describes the design and implementation of the proposed architecture also specifies the traffic control features and tools that have been used. It is worth mentioning that the development of the solution is based on open source tools, such as Operating system Ubuntu 11.10, which has great compatibility with existing hardware, iproute2 supports several methods for classifying, prioritizing, sharing, and limiting both traffic incoming and outgoing, and Squid to complement previous gaps that has iproute2.

The proposed solution can be deployed on any desktop without having to spend a significant amount of money, which is one of the primary objectives in SMEs.

The case study was launched on a network segment of the ESCOM, which in turn is a segment of the institutional network of the IPN, simulating an SME network users and devices require different services. This includes converged network services offered by a private cloud services, video, voice and data.

Emphasis is placed on the analysis of the advantages and disadvantages of the proposed infrastructure, and in turn makes a comparison with platforms developed in environments of large enterprises where the requirements are higher; making the observation that one could choose the solution proposed. It also describes the objectives to be achieved by having the architecture in working order.

1

CAPITULO I.

1. INTRODUCCIÓN. El capitulo presenta una breve introducción, justificación, y los objetivos del trabajo de tesis, así como los conceptos básicos que conforman la arquitectura propuesta.

1.1. Introducción. La popularidad y el continuo crecimiento del uso de la World Wide Web han causado que el acceso a Internet sea un recurso imprescindible para las Pequeñas y Medianas Empresas (PYMES). Sin embargo, el aumento del tráfico de manera exponencial y la incapacidad de la infraestructura de Internet para hacer frente a estas exigencias da pie a inconformidades en el grado de servicio (GoS) percibido por los usuarios de la red. El término calidad de servicio se refiere al desempeño observado por un usuario final a través de una red conectada a la Internet. Este desempeño se puede medir en una variedad de formas: tiempo necesario para descargar una página Web, la calidad de audio de una llamada telefónica a través de Internet, o la calidad de una presentación de video en tiempo real. En una Internet que ofrece una buena calidad de servicio, un usuario deberá recibir de forma consistente un nivel razonable de rendimiento, independientemente de la cantidad de tráfico en Internet. En las Pymes, este nivel de rendimiento muchas veces no puede ser apreciado por los usuarios con mayores requerimientos de disponibilidad, ya que en este panorama y en otros existen usuarios que dan uso incorrecto al recurso, de ahí la necesidad de identificarlos y gestionarlos.

CAPÍTULO I. INTRODUCCIÓN.

2

Tradicionalmente, la Internet sólo soporta Calidad de Servicio (QoS) del tipo “mejor-esfuerzo” (best-effort). Idealmente, un paquete cualquiera que inyectado a la Internet es tratado como cualquier otro. Tal equidad funciona para el transporte simple de datos. Sin embargo, lo que es bueno para un tipo de aplicación es potencialmente inaceptable para otras. El control del tráfico es una parte importante para garantizar que la calidad de un servicio solicitado es entregada por la infraestructura de red. La infraestructura de la Internet se compone de diversas tecnologías de capa de enlace y topologías que cuentan con recursos limitados para los flujos de servicio QoS. Debido a que los recursos de red son finitos, se requieren mecanismos para garantizar que el tráfico pueda ser controlado de modo que la QoS pueda ser correctamente aprovisionada. En el trabajo propuesto se diseña e implementa una infraestructura complementaria para cubrir esta necesidad.

1.2. Justificación.

En las PYMES, el acceso a Internet se da por medio de enlaces de velocidad moderada. Algunas veces la tasa de transferencia de estos enlaces se percibe como baja debido al incremento en el uso de este recurso. La integración de nuevas herramientas de trabajo en las redes convergentes, y en particular la nube privada, requiere que se garanticen los servicios ofrecidos por estas.

En el ambiente empresarial tenemos diferentes niveles dentro de la estructura de sus recursos humanos, así como también tenemos diferentes niveles o perfiles de usuario de Internet; de ahí surge la necesidad de identificar y gestionar para así poder controlarlos. Por ejemplo el perfil correspondiente al comprador tiene mayor requerimiento de servicios y de tasa de trasferencia mayores que el contador que solamente necesita checar su correo. En el ambiente educativo también podemos introducir este concepto donde se puede crear un tabulador y a cada nodo o equipo se le asignen los recursos según se requiera.


3

El control de tráfico es el mecanismo del cual se dispone en las redes basadas en paquetes para regular el tráfico de información en la red, asegurando que los diferentes flujos dispongan de los recursos que necesitan para garantizar sus respectivas calidades de servicio: Latencia, tasa de transferencia, fiabilidad, y costo.

El control de tráfico en Linux es uno de los mecanismos para implementar la estrategia de servicios diferenciados1. Conviene recordar que el control del tráfico no resuelve todos los problemas, a veces el problema se resuelve simplemente incrementando el ancho de banda.

1.3. Objetivo.

El objetivo del presente trabajo de tesis es diseñar e implementar una arquitectura dentro de un entorno de red convergente que gestione y asegure la prestación de un conjunto definido de servicios por medio del control de tráfico.

1.3.1. Objetivos Específicos. Gestionar el ancho de banda de descarga mediante un proxy transparente, que limite el recurso por niveles de servicio.

Gestionar el ancho de banda de carga mediante control de tráfico en Linux para asegurar la disponibilidad de los servicios de la red, por priorización de unos paquetes respectos de otros.

Demostrar la mejora del desempeño de la red mediante la gestión eficiente del ancho de banda sobrante gracias a las herramientas de código libre para el control de tráfico.

1 Servicios diferenciados (DiffServ): es un mecanismo de gestión de QoS basada en limitar los flujos que

acceden a la red, y con ello garantizar la disponibilidad de recursos que requiere cada flujo.


4

1.4. Virtualización Como pilar de la arquitectura se hace uso de la virtualización la cual trae ventajas a la solución. La virtualización es la emulación a través de software de algún recurso como: plataformas de hardware, sistemas operativos, dispositivos de almacenamiento y otros recursos de red. [20] Dicho de otra manera, se refiere a la abstracción de los recursos de una computadora, llamada comúnmente Hipervisor que crea una capa de abstracción entre el hardware de la máquina física (anfitrión) y el sistema operativo de la máquina virtual (máquina virtual, invitado), dividiéndose el recurso en uno o más entornos de ejecución. En esta capa de software se manejan y gestionan los cuatro recursos principales de una computadora (CPU, Memoria, Almacenamiento y Conexiones de Red) y de esta manera reparte dinámicamente dichos recursos entre todas las máquinas virtuales. Existen diferentes formas de virtualización, es posible virtualizar: el hardware de servidor, el software de servidor, sesiones de usuario, aplicaciones y también se pueden crear máquinas virtuales en una computadora de escritorio. Entre los principales proveedores de software que han desarrollado tecnologías de virtualización integrales (que abarcan todas las instancias: servidor, aplicaciones, escritorio) se encuentran VMware y Microsoft. Estas compañías han diseñado soluciones específicas para virtualización, como VMware vSphere y Windows Server 2008 Hyper-V para la virtualización de servidores. Dentro del desarrollo del trabajo se escogió el Hipervisor de Oracle llamado VirtualBox ya que en general su utilización es más sencilla y sólo se requiere para la implementación de la nube privada en nuestra red de prueba. Si bien la virtualización no es un invento reciente, con la consolidación del modelo del cómputo en la nube, la virtualización ha pasado a ser uno de los componentes fundamentales, especialmente en lo que se denomina infraestructura de nube privada.


5

1.4.1. ¿Por qué la virtualización es útil? Las características que la virtualización ofrece son útiles para varios escenarios:

• Ejecutar múltiples sistemas operativos simultáneamente. Permitiendo ejecutar más de un sistema operativo a la vez. De esta forma puede ejecutar el software escrito para un sistema operativo en otro (por ejemplo el software de Windows en Linux o Mac) sin tener que reiniciar el equipo para usarlo.

• Fácil instalación de software. Los proveedores de software pueden

utilizar máquinas virtuales para enviar configuraciones completas de software. Por ejemplo la instalación de una solución completa de servidor de correo en una máquina real puede ser una tarea tediosa; esta configuración puede ser empacada en una máquina virtual y posteriormente implementada en el hipervisor (a esto se le llama "appliance").

• Pruebas y recuperación de desastres. Una vez instalada, una máquina

virtual y sus discos duros virtuales pueden ser considerados como un contenedor que puede ser arbitrariamente congelado, restablecido, copiado, respaldado y transportado entre los anfitriones. Además de eso, con el uso de otra de las características de Virtualización llamada snapshots (tomas instantáneas), se puede guardar un estado particular de una máquina virtual y volver a ese estado, si es necesario. De esta manera, se puede experimentar libremente con un entorno informático y si algo sale mal, se puede fácilmente volver a un estado anterior y evitar la necesidad de copias de seguridad frecuentes y restauraciones.

• Consolidación de la infraestructura. La virtualización puede reducir

significativamente los costos de hardware y la electricidad. La mayor parte del tiempo, las computadoras hoy en día sólo utilizan una fracción de su poder potencial y corren con baja carga computacional promedio del sistema. Una gran cantidad de recursos de hardware así como la electricidad se desperdician. Así, en lugar de correr muchos equipos físicos que utilizan parcialmente estos recursos, se pueden empacar muchas máquinas virtuales en pocos anfitriones de gran capacidad y equilibrar las cargas entre ellos.


6

1.4.2. Terminología.

Para hablar de virtualización y nube es necesario conocer algunos términos, los cuales se comentan a continuación:

• Sistema operativo anfitrión (OS host). Este es el sistema operativo del

equipo físico en el que se ha instalado el Hipervisor. Hay diferentes Hipervisores para anfitriones Windows, Mac OS X, Linux y Solaris.

• Sistema operativo invitado (guest OS). Éste es el sistema operativo que se ejecuta en la máquina virtual. En teoría el Hipervisor se puede ejecutar en cualquier sistema operativo compatible x86 (DOS, Windows, OS/2, FreeBSD, OpenBSD, Mac OS X), pero para lograr un rendimiento casi nativo del código de invitado en el equipo, se tiene que pasar por un varios procesos de optimización que son específicos para cada sistema operativo.

• Máquina virtual (VM). Este es el ambiente especial que crea el Hipervisor para su sistema operativo invitado, mientras que se está ejecutando. En otras palabras, el sistema operativo anfitrión ejecuta el sistema operativo invitado mediante una máquina virtual. Normalmente, una máquina virtual aparecerá como una ventana en el escritorio de la computadora, pero dependiendo de las diversas interfaces del Hipervisor con que se trabaje, el sistema invitado puede ser visualizado en modo de pantalla completa o de forma remota en otro equipo. De una manera más abstracta, a nivel interno, el Hipervisor piensa en una máquina virtual como un conjunto de parámetros que determinan su comportamiento. Estos incluyen la configuración de hardware (la cantidad de memoria de la máquina virtual debe tener, los discos duros que debe virtualizar, los CD montados, etc.) así como la información de estado (si la máquina virtual está en ejecución, guardada, o si se tienen tomas instantáneas, etc.).

• Características adicionales del invitado. Esto se refiere a paquetes de software especiales que envía el Hipervisor, pero diseñados para ser instalados dentro de una máquina virtual para mejorar el rendimiento del sistema operativo invitado y añadir características extra.


7

1.5. La Nube. En este tipo de computación todo lo que un sistema informático puede ofrecer es ofrecido como servicio, de modo que los usuarios puedan acceder a los servicios disponibles en la Internet sin conocimientos en la gestión de los recursos que usan o al menos sin ser expertos en este tema. "El cómputo en la nube" es un nuevo modelo de prestación de servicios de negocio y tecnología, que permite al usuario acceder a un catálogo de servicios estandarizados y responder a las necesidades especificas, de forma flexible y adaptativa, en caso de demandas no previsibles. [20] El cambio paradigmático que ofrece el cómputo en nube es que permite aumentar el número de servicios basados en la red. Esto genera beneficios tanto para los proveedores, que pueden ofrecer de forma más rápida y eficiente un mayor número de servicios, como para los usuarios que tienen la posibilidad de acceder a ellos, disfrutando de la transparencia y de la disponibilidad inmediata del sistema. El cómputo en nube consigue aportar estas ventajas, apoyándose sobre una infraestructura tecnológica dinámica que se caracteriza, entre otros factores, por un alto grado de automatización, una rápida movilización de los recursos, una elevada capacidad de adaptación para atender a una demanda variable así como virtualización avanzada. El concepto de la computación en la nube empezó en proveedores de servicio de Internet a gran escala como Google, Amazon AWS, Microsoft y otros que construyeron su propia infraestructura. De entre todos ellos emergió una arquitectura: un sistema de recursos distribuidos horizontalmente, introducidos como servicios virtuales de TI escalados masivamente y manejados como recursos configurados y mancomunados de manera continua.

1.5.1. Capas del cómputo en la nube.

Existen varias capas que conforman el concepto del computo en la nube sin embargo para contar con una explicación clara y sencilla estas capas se concentran en solo tres.


8

En la figura 1.1 se muestra como se conforman las capas, y cuales son sus bases.

Figura 1.1. Capas del cómputo en la nube

1.5.1.1. Software como Servicio.

El software como servicio (en inglés Software as a Service, SaaS) se encuentra en la capa más alta y caracteriza una aplicación completa ofrecida como un servicio, en demanda, vía multi-hilos que significa una sola instancia del software que corre en la infraestructura propia y sirve a múltiples clientes. El ejemplo de SaaS conocido más ampliamente es Google Apps que ofrece servicios básicos de negocio como el correo electrónico. Por otro lado, está Microsoft, con su plataforma MS Office como servicio SaaS con su denominación de Office 365, que incluye versiones online de la mayoría de las aplicaciones de esta suite ofimática de Microsoft.

1.5.1.2. Plataforma como servicio.

La capa intermedia, es llamada plataforma como servicio (en inglés Platform as a Service, PaaS), y es la abstracción de un ambiente de desarrollo. La carga arquetipo es una imagen Xen2 (parte de Servicios Web Amazon) conteniendo una pila básica Red (por ejemplo, una distribución de Linux, un servidor Red, y un ambiente de programación como Perl o Ruby). Las ofertas de PaaS pueden dar servicio a todas las fases del ciclo de desarrollo y pruebas del software, o pueden estar especializadas en cualquier área en particular, tal como la administración del contenido. 2 Xen es un monitor de máquina virtual de código abierto desarrollado por la Universidad de Cambridge.

http://www.cloud-america.com/ca/wp-content/uploads/2009/12/capas-cc.jpg


9

Los ejemplos comerciales incluyen Google App Engine, que sirve aplicaciones de la infraestructura Google, y también Windows Azure, de Microsoft, una plataforma en la nube que permite el desarrollo y ejecución de aplicaciones codificadas en varios lenguajes y tecnologías como .NET, Java y PHP. Servicios PaaS tales como éstos permiten gran flexibilidad, pero puede ser restringida por las capacidades que están disponibles a través del proveedor.

1.5.1.3. Infraestructura como servicio.

La infraestructura como servicio (Infrastructure as a Service, IaaS) se encuentra en la capa inferior y es un medio de entregar almacenamiento básico y capacidades de cómputo como servicios estandarizados en la red. Servidores, sistemas de almacenamiento, conexiones, enrutadores, y otros sistemas se concentran (por ejemplo a través de la tecnología de virtualización) para manejar tipos específicos de cargas de trabajo. El ejemplo comercial mejor conocido es Amazon Web Services, cuyos servicios EC2 y S3 ofrecen cómputo y servicios de almacenamiento esenciales (respectivamente).

1.5.2. Tipos de nubes. Existen diversos tipos de nube dependiendo de las necesidades de cada empresa, el modelo de servicio ofrecido y la implementación de la misma, pero básicamente existen tres grandes grupos.

1.5.2.1. Nube Pública. Las nubes públicas se manejan por terceras partes, y los trabajos de muchos clientes diferentes pueden estar mezclados en los servidores, los sistemas de almacenamiento y otras infraestructuras de la nube. Los usuarios finales no conocen qué trabajos de otros clientes pueden estar corriendo en el mismo servidor, red o discos duros.


10

1.5.2.2. Nube Privada.

Las nubes privadas son una buena opción para las compañías que necesitan alta protección de datos y ediciones a nivel de servicio. Las nubes privadas están en una infraestructura en demanda manejada por un sólo cliente que controla las aplicaciones que debe correr y dónde debe correrlas. Son propietarios del servidor, red, y discos y pueden decidir qué usuarios están autorizados a utilizar la infraestructura. Dentro del desarrollo de la solución se trabaja sobre una nube privada descrita en el Capitulo IV del Caso de Estudio.

1.5.2.3. Nube Híbrida. La nube híbrida combina los modelos de nube pública y privada. El usuario es propietario de unas partes y comparte otras aunque de una manera controlada. La nube híbrida aprovisionada externamente ofrece la promesa del escalado en demanda, pero añade la complejidad de determinar cómo distribuir las aplicaciones a través de estos ambientes diferentes.

1.6. Calidad del Servicio. La calidad del servicio (QoS) es un concepto algo obvio. Cuando una página web tarda bastante tiempo (alrededor de 20 segundos dependiendo del tipo de contenido) en terminar de cargar completamente, es debido a la calidad de servicio o falta de ello. Actualmente la Internet no brinda la diferenciación de QoS. Sin embargo la industria de la Internet está en desarrollo de nuevos protocolos que permitirán estos servicios, es decir las bondades que ofrece IPv6. Mientras tanto es necesario adaptarse a las prestaciones actuales y una buena opción es controlar los recursos internos. En términos simples, la calidad de servicio en las redes de datos se puede medir con respecto a la tasa a la cual los datos son transmitidos constantemente a través de la red. Esta medición refleja muchas características importantes de la red como su tamaño (distancia y nodos que necesita atravesar) y la capacidad de los enlaces de comunicación. Estas medidas también deben tomar en cuenta los retardos encontrados en varios componentes a lo largo del camino del tráfico de los datos. La habilidad de una red de proveer constantemente una tasa de transmisión de datos mínima y retardos máximos puede determinar su calidad de


11

servicio. Si el tráfico en retardo pertenece a una llamada de voz sobre IP, los participantes de la llamada pueden experimentar huecos intermitentes e interrupciones. Lo que se requiere es una manera de regular el tráfico para que así los paquetes encolados puedan ser enviados con un retardo imperceptible al usuario. A continuación se muestra la tabla 1.1 presentando los parámetros utilizados en la calidad de servicio [RFC 3393, Recomendación ITU-T Y.1541].

TABLA 1.1. Parámetros de Calidad de Servicio

En la figura 1.2 se muestra la densidad de probabilidad de llegada de los datagramas estableciendo los parámetros usados para la medición de la Calidad de Servicio [21].

FIGURA 1.2. Relación entre la probabilidad de llegada de los datagramas y los parámetros de QoS.

La congestión y la falta de QoS son los principales problemas de Internet actualmente. IP fue diseñado para dar un servicio best-effort (de mejor esfuerzo). Sin embargo hoy en día se utiliza para aplicaciones sensibles que no toleran redes sin QoS como videoconferencia, telefonía IP, VoIP (Voz sobre IP), etc. Estas aplicaciones no pueden funcionar en una red best-effort congestionada. Se han hecho modificaciones al protocolo de Internet (IP) para que pueda ofrecer QoS a las aplicaciones. En la figura 1.3 se muestra que cuando existe congestión se presenta una fluctuación del retardo (Jitter).

Parámetro Unidades Significado Ancho de Banda (bandwidth) Kb/s Indica el caudal máximo que se puede

transmitir Retardo (delay) o latencia (latency) ms El tiempo medio que tardan en llegar los

paquetes Jitter (fluctuación del retardo) ms La fluctuación que se puede producir en el retardo Tasa de pérdidas (loss rate) % Proporción de paquetes perdidos respecto de los

enviados


12

FIGURA 1.3. Fluctuación del retardo (Jitter)

Retardo: 70 ms ± 20 ms (retardo: 70 ms, jitter: 40 ms)

1.6.1. Reducción del Jitter.

El jitter puede reducirse si el receptor retrasa la reproducción (buffer “anti-jitter”). Por ejemplo en VoIP lo habitual es enviar un paquete de voz cada 20 ms. Si el receptor reproduce los paquetes tal cual le llegan cualquier fluctuación en la entrega afectará la calidad. Si en vez de eso retrasa 40 ms la reproducción podrá compensar fluctuaciones de hasta 40 ms en el tiempo de entrega. En algunas aplicaciones (video o audio unidireccional) se llegan a introducir retardos de hasta 30 segundos. Pero en estos casos no existe interacción receptor-emisor.

1.6.2. Requerimientos de las Aplicaciones para Calidad del Servicio.

El mayor impedimento para implementar ciertas aplicaciones es la falta de QoS en las redes de computadoras. El tráfico de las aplicaciones de video y audio en tiempo real como las videoconferencias y la radio por internet por ejemplo, requiere de un servicio predecible en términos de ancho de banda dedicado y límites en la cantidad de retrasos experimentados en la comunicación de los datos.


13

En adición aplicaciones de misión crítica como lo es la Planeación de recursos empresariales (ERP, de la sigla del término en inglés Enterprise Resource Planning), la administración basada en la relación con los clientes (CRM, de la sigla del término en inglés Customer Relationship Management), y el comercio electrónico en las Pymes necesitan una calidad de servicio garantizado para asegurar el tiempo de respuesta y proceso de las transacciones del negocio. Teniendo en cuenta el tamaño, el alcance, y la utilidad de la Internet, no se puede esperar cubrir los niveles individuales de QoS necesitados por el conjunto diverso de consumidores y aplicaciones. Sin embargo, la Internet debe evolucionar más allá de su paradigma actual de "atender todo, pero no garantizar nada" a un nuevo paradigma que puede distinguir entre sus usuarios y aplicaciones para proveer un conjunto de servicios diferenciados diseñados para complacer las demandas de las diferentes clases de tráfico. En particular, los protocolos y mecanismos de la Internet deben ser llevados a un nivel donde puedan proveer un rendimiento predecible. Esto resultará en una red integrada que puede permitir nuevas clases de aplicaciones de tiempo real e interactivo. En la figura 1.4 se muestran los efectos de la congestión sobre el rendimiento y tiempo de servicio [21]. De esta manera se identifica cuando es que la diferenciación de los servicios es útil o no.

FIGURA 1.4. Efectos de la congestión en el tiempo de servicio y el rendimiento


14

Para diferenciar el tráfico de la diversidad de aplicaciones se establecen requerimientos de calidad de servicio para cada una de estas. A continuación la tabla 1.2 muestra tales requerimientos [21, ITU-T Y.1541]:

Tipo de aplicación Ancho de

Banda Retardo Jitter Tasa de

Pérdidas Interactivo (telnet, www) Bajo Bajo Medio/alto Media Batch (e-mail, ftp) Alto Alto Alto Alta3 Telefonía Bajo Bajo Bajo Baja Vídeo interactivo Alto Bajo Bajo Baja Vídeo unidireccional (streaming) Alto Medio/alto Bajo Baja Frágil (ej.: emulación de circuitos) Bajo Bajo Medio/alto Nula

TABLA 1.2. Requerimientos de Calidad de Servicio de las aplicaciones.

Antes de pasar a la ingeniería de tráfico se va a tomar una pequeña reseña de los intentos que se han hecho por cubrir las brechas que por diseño tiene el protocolo TCP/IP.

1.7. Evolución de las estrategias para aprovisionar la calidad de servicio.

Existen dos posibles estrategias para dar trato preferente a un usuario o una aplicación en una red:

• Carril BUS: reservar capacidad para su uso exclusivo. A veces se denomina QoS hard.

• Ambulancia: darle mayor prioridad que a otros usuarios. A veces se denomina QoS soft.

La tabla 1.3 muestra las ventajas e inconvenientes que tienen las estrategias de reserva (Carril BUS) y prioridad (Ambulancia).

3 En realidad la aplicación requiere pérdida nula, pero esto lo garantiza el protocolo de transporte TCP.


15

Ventajas Inconvenientes Reserva • Da una garantía casi total

• Los paquetes no necesitan llevar ninguna marca que indique como han de ser tratados, la información la tienen los enrutadores.

• Requiere mantener información de estado sobre cada comunicación en todos los enrutadores por lo que pasa.

• Se requiere un protocolo de señalización para informar a los enrutadores y efectuar la reserva en todo el trayecto.

Prioridad • Los enrutadores no necesitan conservar información de estado.

• Los paquetes han de ir marcados con la prioridad que les corresponde.

• La garantía se basa en factores estadísticos, es menos segura que la reserva de recursos.

TABLA 1.3. ¿Reserva o Prioridad?

1.7.1. Historia de la Calidad del Servicio en Internet. 1981: Octeto ToS (Type of Service) en IPv4 (RFC 791) 1994: Modelo IntServ (Integrated Services RFC 1633 y el protocolo RSVP) 1995: Campos prioridad y etiqueta de flujo en IPv6 (RFC 1883) 1998: Modelo DiffServ (Differentiated Services RFC 2474) En paralelo se desarrollaron otras estrategias como:

• Control de congestión en Internet • Calidad de servicio en redes de área local.

1.7.1.1. Octeto ToS.

En la definición original de la cabecera IPv4 se incluye un octeto que tenía dos partes:

• Tres bits para indicar una prioridad (llamada precedencia). Los enrutadores debían enviar antes los paquetes con mayor precedencia. • Varios bits que actuaban de indicadores bandera o ‘flags’ para indicar que tipo de ruta prefiere el paquete:

• Mínimo retardo. • Máximo rendimiento. • Máxima fiabilidad. • Mínimo costo.


16

La figura 1.5 muestra la estructura de la cabecera IPv4 con el octeto ToS.

FIGURA 1.5. Cabecera IPv4 (RFC 791, 1981)

Precedencia: prioridad (ocho niveles). Mayor es mejor. D, T, R, C: flags para indicar la ruta que se quiere utilizar:

• D: Delay (mínimo retardo) • T: Throughput (máximo rendimiento) • R: Reliability (máxima fiabilidad) • C: Cost (mínimo costo), RFC 1349 • X: bit reservado

La tabla 1.4 muestra el significado para los bits asignados al campo de precedencia

Precedencia (decimal)

Precedencia (binario)

Nombre

Reservados para tráfico de control

7 111 Control de red 6 110 Control de interred

Disponibles para usuario

5 101 Crítico / ECP 4 100 Flash Override 3 011 Flash 2 010 Inmediato 1 001 Prioridad 0 000 Rutina

TABLA 1.4. Significado del campo precedencia

1.7.1.1.1. Inconvenientes del campo TOS Los seis niveles de prioridad disponibles para la configuración del usuario a veces son insuficientes.


17

Solo es posible indicar prioridad de envió, no otros aspectos como prioridad de descarte. Los fabricantes han implementado de forma no consistente el campo precedencia y los flags DTRC. La interoperabilidad entre fabricantes e ISPs es muy limitada por ello la precedencia y los flags DTRC se han usado poco.

1.7.1.2. Modelo IntServ (Servicios Integrados). Se han desarrollado y estandarizado dos modelos de QoS en Internet. Ambos modelos son compatibles y coexisten.

• En el modelo de Servicios Integrados el usuario solicita de antemano los recursos que necesita; cada enrutador del trayecto ha de tomar nota y efectuar la reserva solicitada (modelo carril bus).

• En el modelo de Servicios Diferenciados el usuario marca los paquetes con una determinada etiqueta que marca la prioridad y el trato que deben recibir por parte de los enrutadores; estos no son conscientes de los flujos activos (modelo ambulancia). Este último es en el que esta soportado por la arquitectura propuesta.

Tolerantes a pérdidas Intolerantes a

pérdidas Tolerantes a retardos (Elásticas)

Datos UDP: DNS, SNMP, NTP, etc.

Datos sobre TCP: FTP, Web, e-mail, etc.

No tolerantes a retardos (Tiempo Real)

Flujos Multimedia de todo tipo: video ‘streaming’, videoconferencia, telefonía sobre Internet, etc.

Emulación de circuitos (simulación de líneas dedicadas)

TABLA 1.5. Clasificación de las aplicaciones en IntServ (Integrated Services)

1.7.1.2.1. IntServ y RSVP Para ofrecer QoS IntServ se basa en la reserva previa de recursos en todo el trayecto. Para esa reserva se emplea el protocolo RSVP (Resource reSerVation Protocol), parte esencial del modelo IntServ. La reserva garantiza la QoS solicitada. Si no quedan recursos suficientes se rechaza la petición, es decir se ejerce control de admisión o CAC (Connection Admission Control). Normalmente la reserva se realiza para una secuencia de datagramas relacionados entre sí, que es lo que llamamos un flujo.


18

1.7.1.2.2. RSVP RSVP es un protocolo que reserva la capacidad solicitada por un flujo en todos los enrutadores del camino. Realmente es un protocolo de señalización pues crea información de estado en los enrutadores. Aunque se utilice en IP es un servicio orientado a conexión. Está pensado principalmente para trafico multicast. RSVP no es un protocolo de enrutamiento (de eso se ocuparía OSPF, BGP, PIM-SM, etc.). RSVP reserva la capacidad solicitada en todos los enrutadores del camino. Cada enrutador ha de mantener el detalle de todas las conexiones activas que pasan por él y los recursos que cada una ha reservado. El enrutador mantiene información de estado sobre cada flujo que pasa por él. Si no se pueden asegurar las condiciones pedidas se rechaza la llamada (control de admisión). La Figura 1.6 muestra un ejemplo sencillo del funcionamiento en Multicast.

FIGURA 1.6. Funcionamiento de RSVP en Multicast

Las reservas se agregan a medida que ascienden en el árbol multicast. Así se optimiza el uso de la red (solo se hace la reserva una vez en cada tramo).

1. F pide a C que reserve 1,5 Mb/s del caudal descendente para el flujo que le va a enviar A. C propaga la petición a B quien a su vez la propaga a A.

2. Cuando más tarde E y D realizan sus peticiones no son propagadas hacia arriba por C o B, pues ya no es necesario.


19

A continuación la tabla 1.6 muestra las características asociadas a cada nivel de servicio ofrecido por RSVP y su equivalencia con ATM4 (Asynchronous Transference Mode).

Servicio Características Equivalencia en ATM

Garantizado

• Garantiza un caudal mínimo y un retardo máximo

• Cada enrutador del trayecto debe dar garantías

• A veces no puede implementarse por limitaciones del medio físico. Ej. Ethernet compartida

CBR (Constant Bit Rate), VBR-rt (Variable Bit Rate in

real time)

Carga Controlada ('Controlled Load')

• Calidad similar a la de una red de datagramas poco cargada

• Se supone que el retardo es bajo, pero no se dan garantías

VBR-nrt (Non-Real-Time Variable Bit Rate)

`Best Effort' • Ninguna garantía (como antes sin QoS) UBR (Unspecified Bit Rate) TABLA 1.6. Tipos de servicio en IntServ.

La figura 1.7 muestra como es el reparto de los recursos en el modelo de servicios integrados [21], mientras aumenta la demanda se da prioridad a cierto tráfico de información.

FIGURA 1.7. Reparto de recursos en IntServ

4 ATM es una tecnología de telecomunicación desarrollada en los años 60 para hacer frente a la gran

demanda de capacidad de transmisión para servicios y aplicaciones (ATM simulaba los estados ofrecidos por la conmutación de circuitos).


20

1.7.1.2.3. Problemas de IntServ/RSVP RSVP produjo una euforia inicial (1996-1997) que luego dio paso a la decepción. La razón principal fueron problemas de escalabilidad debidos a la necesidad de mantener información de estado en cada enrutador. Esto hace inviable usar RSVP en grandes redes, por ejemplo en el core de Internet como se muestra a continuación en la figura 1.8.

FIGURA 1.8. Problema de escalabilidad de RSVP.

Los fabricantes de enrutadores no han desarrollado implementaciones eficientes de RSVP, debido al elevado costo que tiene implementar en hardware los algoritmos necesarios para mantener gran cantidad de información de estado. Sin embargo recientemente se han desarrollado mejoras en RSVP que resuelven algunos de estos inconvenientes. Además también ha resurgido el interés por RSVP para aplicarlo en MPLS (Multi-Protocol Label Switching). En estos casos el número de flujos no suele ser muy grande [RFC 51515 en Febrero 2008].

5 Inter-Domain MPLS and GMPLS Traffic Engineering --Resource Reservation Protocol-Traffic Engineering

(RSVP-TE).


21

1.7.1.3. Campos de prioridad y etiqueta de flujo en IPv6. Al desarrollar IPv6 estaba claro que los flags del octeto ToS no eran útiles. En cambio la precedencia sí que tenía cierta aceptación entre los fabricantes y usuarios. Por otro lado la aparición del modelo IntServ por las mismas fechas llevo a diseñar en IPv6 algún mecanismo que simplificara la identificación de los flujos. La figura 1.9 muestra la incorporación de los campos de prioridad y etiqueta de flujo en la cabecera de IPv6.

FIGURA 1.9. Cabecera IPv6 [RFC 1883, 1995].

• Prioridad (4 bits): hasta 16 niveles posibles. Mayor es mejor. • Etiqueta de flujo (24 bits): el host emisor incluye aquí una etiqueta que

identifica de forma única cada flujo que genera. Esto permite a los enrutadores distinguir más fácilmente los paquetes que pertenecen al mismo flujo (no tienen que inspeccionar tantos campos). Aun no se han desarrollado aplicaciones que hagan uso del campo etiqueta de flujo.

1.7.1.4. Modelo DiffServ (Servicios Diferenciados). Intenta evitar los problemas de escalabilidad que plantea IntServ/RSVP. Consiste en marcar los paquetes con una etiqueta y acordar con todos los enrutadores un tratamiento según la etiqueta:

• No hay reserva de recursos por flujo (los enrutadores no “ven” los flujos). • No hay protocolo de señalización. • No hay información de estado en los enrutadores.


22

Las garantías de calidad de servicio no son tan estrictas como en IntServ, pero en muchos casos son suficientes. Puesto que los paquetes se clasifican en clases a veces a esto se le denomina CoS (Class of Service). A cada clase le corresponde un Nivel de Servicio Acordado SLA (Service Level Agreement). Los usuarios pueden contratar unos determinados valores de los parámetros QoS para cada clase. El número de clases posibles es limitado e independiente del número de flujos o usuarios; por tanto la complejidades constante, no proporcional al número de usuarios. La arquitectura es escalable. La información de QoS viaja montada en los datagramas en un campo nuevo de Servicios Diferenciados llamado DS (Differentiated Services). Los enrutadores solo han de saber qué tratamiento deben dar a cada clase. Esto lo saben por configuración (no es información de estado). La figura 1.10 muestra a continuación la estructura del octeto DS.

FIGURA 1.10. Campo DS [RFC 2474]

DSCP: Código de servicios diferenciados (Differentiated Services CodePoint). Seis bits que indican el tratamiento que debe recibir este paquete en los enrutadores. CU: Actualmente sin uso (Currently Unused). Este campo se utiliza actualmente para control de congestión [ECN, RFC 3168]. La figura 1.11 muestra el campo DS en la cabecera IPv4 con la implementación del modelo de Servicios Diferenciados.

FIGURA 1.11. Cabecera IPv4 con DiffServ.


23

La figura 1.12 muestra el campo DS en la cabecera IPv6 con la implementación del modelo de Servicios Diferenciados.

FIGURA 1.12. Cabecera IPv6 con DiffServ.

La figura 1.13 muestra la compatibilidad de los tres primeros bits en IPv4 y IPv6

FIGURA 1.13. Aparición del campo DS en IPv4 e IPv6


24

1.7.1.4.1. Campo DSCP

Los 6 bits equivalen a 64 categorías de tráfico posibles. De momento se han dividido en 3 grupos como se muestra en la tabla 1.7:

Codepoint Valores Uso cccyy0 32 Estándar xxxx11 16 Local/experimental xxxx01 16 Reservado

TABLA 1.7. Campo DSCP La tabla 1.8 muestra los tres primeros bits (ccc) del grupo estándar que indican la clase.

Servicio Características Equivalencia en ATM

“Expedited Forwarding” o “Premium”

• Es el que da más garantías. Equivale a una línea dedicada.

• Lo garantiza todo: Caudal, tasa de pérdidas, retardo y jitter.

CBR VBR-rt

“Assured Forwarding”

• Asegura un trato preferente, pero sin fijar garantías (no hay SLA)

• Se definen cuatro clases y en cada una tres niveles de descarte de paquetes

VBR-nrt

“Best Effort” • Ninguna garantía, obtiene solo las migajas UBR

TABLA 1.8. Tipos de Servicio en DiffServ La tabla 1.9 muestra el significado de las clases DSCP y su equivalente con los bits de precedencia del octeto ToS.

Rango (decimal)

Valor (binario)

Significado Equivalente precedencia

56-63 111xxx Control de la red 7 48-55 110xxx Control de la red 6 40-47 101xxx Expedited Forwarding 5 32-39 100xxx Assured Forwarding clase 4 4 24-31 011xxx Assured Forwarding clase 3 3 16-23 010xxx Assured Forwarding clase 2 2 8-15 001xxx Assured Forwarding clase 1 1 0-7 000xxx Best effort (default) 0

TABLA 1.9. Significado de las clases del DSCP


25

1.7.1.4.2. Servicio EF (Expedited Forwarding) o Premium. Es el que proporciona mayor seguridad al servicio. Ofrece un SLA (Service Level Agreement) que lo garantiza todo:

• Ancho de banda mínimo • Tasa máxima de pérdida de paquetes • Retardo máximo • Jitter máximo

Se garantiza el caudal, pero no se toleran excesos. Le corresponde el DSCP “10 1110” (46 en decimal).

1.7.1.4.3. Servicio AF (Assured Forwarding). El nombre es engañoso pues no asegura el envío sino que asegura un trato preferente (respecto al Best Effort y los AF de clase inferior), pero no garantiza parámetros (no hay SLAs).Se definen cuatro clases: 4, 3, 2, 1 (más es mejor). En los enrutadores se puede asignar recursos (ancho debanda y espacio en buffers) independientemente para cada clase. En cada clase se definen tres categorías de descarte de paquetes: alta, media y baja. Le corresponden 12 diferentes DSCP: “cccdd0” (ccc =clase, dd = descarte). Mayor probabilidad de descarte. Menor probabilidad de descarte.

Precedencia de descarte “dd” Mayor prioridad. Menor prioridad.

Clase “ccc”

Alta “11”

Media “10”

Baja “01”

4 “100”

100110 AF43 38

100100 AF42 36

100010 AF41 34

Binario Nombre Decimal

3 “011”

011110 AF33 30

011100 AF32 28

011010 AF31 26

2 “010”

010110 AF23 22

010100 AF22 20

010010 AF21 18

1 “001”

001110 AF13 14

001100 AF12 12

001010 AF11 10

TABLA 1.10. Códigos del Servicio AF.


26

Mientras que en la clase más es mejor en la probabilidad de descarte más es peor. En el servicio AF el usuario puede contratar con el ISP un caudal para cada clase. El ISP puede aplicar políticas sobre el tráfico del usuario y si se excede jugar con los bits de precedencia de descarte, usándolos de forma parecida al bit DE de Frame Relay o al CLP de ATM. La tabla 1.11 muestra el significado del campo DSCP.

Decimal Binario Significado 62 111110 Reservado 60 111100 Reservado 58 111010 Reservado 56 111000 Precedencia 7

(enrutamiento y control) 54 110110 Reservado 52 110100 Reservado 50 110010 Reservado 48 110000 Precedencia 6

(enrutamiento y control) 46 101110 EF (Premium) 44 101100 Config. Usuario 42 101010 Config. Usuario 40 101000 Precedencia 5 38 100110 AF43 36 100100 AF42 34 100010 AF41 32 100000 Precedencia 4 30 011110 AF33 28 011100 AF32 26 011010 AF31 24 011000 Precedencia 3 22 010110 AF23 20 010100 AF22 18 010010 AF21 16 010000 Precedencia 2 14 001110 AF13 12 001100 AF12 10 001010 AF11 8 001000 Precedencia 1 6 000110 Config. Usuario 4 000100 Config. Usuario 2 000010 Config. Usuario 0 000000 Precedencia 0

(Best Effort, default) TABLA 1.11. Valores del campo DSCP


27

Existen tres niveles de prioridad de descarte, el ISP puede utilizar uno u otro en función de lo grave que sea la infracción. Normalmente se utiliza el algoritmo del pozal agujereado (leaky bucket). La figura 1.14 muestra el manejo de los paquetes cuando se rebasan los niveles de servicio contratados con el proveedor de servicios de Internet [1].

FIGURA 1.14. Políticas de Trafico en el Servicio AF

La figura 1.15 muestra como es el reparto de los recursos en el modelo de servicios diferenciados, mientras aumenta la demanda se da prioridad a cierto tráfico de información.

FIGURA 1.15. Reparto de recursos en DiffServ.


28

1.7.1.4.4. Implementación del Modelo de Servicios Diferenciados.

El DSCP (la clase) se asigna según alguna característica del paquete: IP origen/destino o puerto origen/destino. Se puede incluso identificar y clasificar paquetes que pertenecen a protocolos que utilizan puertos dinámicos por el patrón de tráfico que generan (p. ej. peer-to-peer). Las políticas de tráfico solo se ejercen en los enrutadores de entrada a la red del ISP y en los que atraviesan fronteras entre ISPs (normalmente en las fronteras entre sistemas autónomos). El enrutador de ingreso al dominio DiffServ se encarga de marcar el campo DSCP (de acuerdo con la política de QoS). Los siguientes sólo han de realizar el tratamiento que corresponde según el DSCP. La figura 1.16 muestra los llamados dominios en el modelo de servicios diferenciados.

FIGURA 1.16. Funcionamiento de DiffServ en Internet.

El acuerdo entre los dominios de dos ISPs (peering) puede, o no, incluir QoS. Si dos ISP acuerdan intercambiar tráfico manteniendo la QoS han de establecer si los DSCP se mantienen inalterados, o si se realiza una conversión de acuerdo con determinada equivalencia, para mantener la semántica.


29

En la entrada de cada “Dominio de Servicios diferenciados” un enrutador frontera se encargará del marcado o remarcado de los paquetes, de acuerdo con la política de QoS. La figura 1.17 muestra la cronología que siguen los enrutadores en el manejo de los paquetes.

FIGURA 1.17. Funciones QoS desempeñadas por los enrutadores.

Todas las funciones mostradas en la figura 1.17 se describirán a detalle más adelante, y son parte fundamental de la arquitectura propuesta.

1.7.1.5. IntServ vs DiffServ. IntServ fue desarrollado con anterioridad a DiffServ. Sin embargo DiffServ se ha extendido más que IntServ. DiffServ permite agregar flujos, el modelo es escalable. Debido a estas diferencias muchos fabricantes de enrutadores implementan versiones eficientes de DiffServ, pero no de IntServ. Actualmente muchos ISP implementan DiffServ. Qbone (red experimental de QoS en Internet 2) utiliza el modelo DiffServ.


30

1.7.1.6. Calidad del Servicio en las Redes de Área Local. Desarrollada en 802.1p y 802.1Q. Campo prioridad de tres bits. Hasta ocho niveles o clases posibles (modelo sin información de estado, similar a DiffServ). La prioridad va anotada en la etiqueta de VLAN, como consecuencia sólo puede utilizarse QoS en enlaces trunk6. El interés es limitado dada la posibilidad en la LAN de sobredimensionar a bajo costo. Normalmente la QoS de LAN va asociada a la QoS a nivel de red, haciendo una equivalencia de prioridades 802.1p a tipos de servicio IntServ o DiffServ (más fácil con DiffServ).

FIGURA 1.18. Etiquetado de tramas según 802.1Q

Pri: Prioridad (8 niveles posibles) CFI: El Indicador de formato canónico (Canonical Format Indicator) revela el formato de direcciones MAC. VLAN Ident.: Identificador VLAN (máximo 4096 en una misma red)

1.7.1.6.1. QoS: Implementación Normalmente los conmutadores y enrutadores que soportan QoS tienen varias colas de salida por interfaz (a veces también de entrada) en las que pueden usar diferentes algoritmos.

6 Los enlaces troncales (trunk) pertenecen a más de una VLAN.


31

Las colas pueden implementarse por software o por hardware. Cuando son por hardware el número suele estar entre dos y cinco. Los mecanismos hardware son los mismos para nivel 2 (802.1 q) que para nivel 3 (DiffServ). No hay reservas estrictas si no asignaciones aproximadas. La tabla 1.12 muestra la configuración QoS para diferentes tipos de tráfico, se les asigna una etiqueta DSCP, prioridad y tipo de encolamiento recomendado.

Tipo de tráfico Etiqueta DSCP

Clase Prior. 802.1 p/Q

Cola salida Caudal salida

Tamaño buffer

Datos VoIP 46 (EF) 5 5 1(Priority) 10% 10% Control Voz y video 26 (AF31) 3 3 2 (WRR) 10 % 10% Prot. Enrutamiento 48 6 6 Spanning Tree 56 7 7 Video tiempo real 34 (AF41) 4 4 3 (WRR) 60% 26% Datos oro (1a) 16 2 2 Datos plata (2a) 8 1 1 4 (WRR) 20% 54% Datos resto (3a) 0 (BE) 0 0

WRR: Weighted Round Robin TABLA 1.12. Configuración QoS recomendada en conmutadores Catalyst 3560 para VoIP

La figura 1.19 muestra el caudal de salida asignado a cada cola y se muestran los algoritmos de encolamiento recomendados en la tabla 1.12.

FIGURA 1.19. Encolamiento de paquetes en enrutadores y conmutadores (nivel 2 y 3)

PQ: Priority Queue. Siempre va la primera, pero no recibe más de lo asignado. WRR: Weighted Round Robin. Cada cola obtendrá al menos su parte, y si hay caudal libre obtendrá más.


32

1.8. Ingeniería de Trafico.

Las recomendaciones de la ITU-T con respecto a los componentes de la ingeniería de tráfico se clasifican en 4 categorías [21]:

• Caracterización de la demanda de tráfico • Objetivos de Grado de Servicio (GoS) • Controles de tráfico y dimensionamiento • Monitoreo del rendimiento

La figura 1.20 muestra la clasificación para la ingeniería de tráfico. Aquí es donde se puede ubicar el trabajo que se realizó en la tesis atendiendo el área de control de tráfico. Observemos que el control de tráfico implementado en el trabajo de tesis solo es parte del conjunto de la ingeniería de tráfico.

FIGURA 1.20. Clasificación de la Ingeniería de tráfico en 4 categorías. [21]


33

1.8.1. Caracterización de la demanda de tráfico.

El objetivo es obtener modelos matemáticos que describan aproximadamente el comportamiento aleatorio del tráfico de los usuarios.

• Se requiere hacer supuestos que simplifican los complicados procesos de tráfico.

• Parámetros de los modelos: media, mediana, varianza, desviación estándar, etc.

1.8.2. Objetivos de Grado de Servicio (GoS). El Grado de Servicio es un conjunto de parámetros de ingeniería de tráfico usados para proveer una medida de la adecuación de la red a las condiciones especificadas en el diseño. Ejemplos:

• Probabilidad de bloqueo • Probabilidad de retardo

Estas probabilidades expresan la posibilidad de que ocurra el bloqueo o el retardo (o ambas) debido a que los recursos de la red son finitos (y por tanto la capacidad), mientras que la demanda de tráfico de los usuarios es aleatoria por naturaleza y puede exceder las capacidades de la red en algún momento.

1.8.3. Controles de tráfico y dimensionamiento. Son herramientas de la ingeniería de tráfico, dentro de las cuales se emplean métodos de diseño y mecanismos de gestión para la operación de la red. El diseño requiere de herramientas de dimensionamiento. El dimensionamiento busca que la red tenga suficientes recursos para cumplir con la demanda de tráfico de los usuarios (recursos físicos y lógicos). La gestión y operación requiere de métodos de control de tráfico. Los mecanismos de control de tráfico se requieren para asegurar que se cumplan los objetivos de GoS. Y es aquí donde precisamente se encuentra todo el desarrollo para el aprovisionamiento de los servicios dentro de la arquitectura propuesta. Se retomará el control de tráfico más adelante.


34

Los controles de tráfico posibles son: Enrutamiento de tráfico Controles de gestión de tráfico de red Métodos de protección del servicio Controles de tráfico a nivel de paquetes

La figura 1.21 muestra las escalas de tiempo relacionadas con la ingeniería de tráfico y sus categorías, las secciones marcadas por los círculos rojos son atendidas por el control de tráfico implementado en el presente trabajo.

FIGURA 1.21. Escalas de tiempo para las tareas de Gestión y operación de redes

1.8.4. Monitoreo del rendimiento. Mientras la red esté operando, se requiere el monitoreo del GoS. Soluciona posibles problemas:

• A pesar de que la red esté dimensionada correctamente, hay situaciones de sobrecarga y fallos no considerados en el dimensionamiento.

• Se requiere tomar acciones de corta duración (minutos, horas) para atacar tales situaciones.

• También podría haber errores en el dimensionamiento debidos a supuestos incorrectos en los modelos, lo que llevaría a un GoS diferente del esperado.

Otras situaciones que requieren monitoreo: • Caracterización del tráfico. • Diseño de la red.


35

Consecuencias del monitoreo (término de semanas, meses): • Reconfiguración de elementos de la red. • Reconfiguración del enrutamiento. • Ajuste en los parámetros de control de tráfico.

La figura 1.22 muestra la retroalimentación que aporta el monitoreo del rendimiento.

FIGURA 1.22. Tareas de la Gestión y Monitoreo del rendimiento.

1.9. Control de Tráfico. El control de tráfico es un conjunto de herramientas las cuales permiten al administrador de la red tener control granular sobre estas colas y mecanismos de encolamiento de un dispositivo de red. El poder de reorganizar el flujo de tráfico y paquetes con estas herramientas es tremendo y puede ser complicado, pero no hay substituto para adecuar el ancho de banda.


36

El termino Calidad de Servicio (QoS) es frecuentemente usado como sinónimo de control de tráfico. El control de trafico abarca un conjunto de mecanismos y operaciones por los cuales, los paquetes son puestos en una cola para su transmisión o recepción en una interfaz de red. Las operaciones incluyen encolamiento (queuing), clasificación (classifying), planeación (scheduling), provisión de políticas (policing), conformación (shaping) y supresión (dropping).

1.9.1. Elementos de Control de Tráfico.

1.9.1.1. Concepto de flujo.

Un flujo es una conexión o sesión de comunicación entre dos aplicaciones [1]. En un sistema los flujos se encuentran caracterizados, y llevan asociados requisitos de QoS de acuerdo con su naturaleza. Un flujo es la entidad más pequeña a la que los enrutadores pueden aplicar una determinada QoS. Un flujo es simplex (unidireccional). Un flujo se identifica por los siguientes cinco parámetros:

• Dirección IP de origen • Puerto de origen • Dirección IP de destino • Puerto de destino • Protocolo de transporte utilizado (TCP o UDP)

La figura 1.23 muestra como ejemplo una videoconferencia que está formada por cuatro flujos: audio y video de ida, audio y video de vuelta. Los flujos pueden agruparse en clases; todos los flujos dentro de una misma clase reciben la misma QoS.


37

FIGURA 1.23. Flujos en una videoconferencia

1.9.1.2. Colas. Las colas son los mecanismos básicos que se utilizan en la planificación y organización de los paquetes. Son los elementos en los que los paquetes se reordenan, reagrupan, retrasan descartan o priorizan.

1.9.1.2.1. Cola FIFO. Disciplina de encolamiento de cola simple sin clases

Son aquellas que, mayormente, aceptan datos y se limitan a reordenarlos, retrasarlos o descartarlos; ajustando el tráfico de la interfaz entera sin subdivisiones. Transmite los mensajes en el orden First In First Out, esto es, en el orden exacto en que se han recibido. Es la más simple, pero lleva estadística de la longitud del buffer. Es un buen medio de conocer el nivel de carga de la cola.


38

FIGURA 1.24. Cola FIFO.

1.9.1.2.2. Disciplina de cola FIFO-Fast Es la cola utilizada por defecto en el kernel de Linux y como su nombre lo indica, el primero que entre es el primero que sale, ningún paquete recibe un tratamiento especial. Utiliza 3 bandas y dentro de cada banda se aplican las reglas (Prioridades) FIFO (0 más prioritaria, 1 y 2 menos prioritaria), sin embargo no procesara la banda 1 mientras haya paquetes esperando en la banda 0. Lo mismo aplica para las bandas 1 y 2. • La distribución de los paquetes en las tres colas se realiza de acuerdo con el

campo de servicios diferenciados del paquete y tiene cuidado de insertar los paquetes de mínimo retraso en la banda 0.

• No tiene parámetros de configuración, por defecto es fija.


39

FIGURA 1.25. Cola FIFO-Fast.

Parámetros y forma de uso. Priomap.- Determina las prioridades de los paquetes, esta correspondencia se basa en el octeto servicios diferenciados del paquete

1.9.1.2.3. Disciplina de encolamiento Token Bucket Filter (TBF)

El modelo del Filtro de Tokens y Buckets (TBF) es el mecanismo simple y eficiente que se utiliza para limitar de forma flexible el flujo de información. Un token representa un turno, y el bucket es un contenedor de tokens.


40

FIGURA 1.26. Filtro de Tokens y Buckets

El algoritmo puede ser explicado como sigue:

• Un token es añadido al bucket a una tasa. • El bucket sólo puede contener un número limitado de tokens. Si un token

llega cuando el bucket está lleno, se descarta. • Cuando un paquete con n bytes llega de una aplicación, se retiran n tokens

del bucket, y el paquete se envía por la red. • Si hay menos de n tokens en el bucket, solo se extraen los tokens y el

envío de paquete se retrasa hasta que se hayan acumulados suficientes tokens en el bucket.

Una variación de este algoritmo es el que usa la arquitectura (HTB), agrega jerarquización y préstamos en diferentes clases. Permite limitar el proceso de desencolado de la información utilizando el algoritmo Token Bucket Filter. Parámetros configuración:

• limit: Nº de byte que pueden ser encolados a la espera de token. • burst: Tamaño del bucket. • mpu: Tamaño mínimo del paquete • rate: Tasa de generación de token. • peakrate: Velocidad a la que se envía los bytes cuando hay tokens. • mtu: tamaño máximo de la trama.


41

FIGURA 1.27. Filtro Token Bucket.

1.9.1.2.4. Disciplina de encolamiento estocástico justo SFQ (Stochastic Fairness Queuing).

Utiliza múltiples colas a fin de distribuir la capacidad de transmisión entre todas las conexiones que transmiten. Utiliza una tabla hash para distribuir conexiones con colas. Una tabla hash o tabla de dispersión es una estructura de datos que asocia llaves o claves con valores. Parámetros de configuración: • perturb: Tiempo entre reasignaciones de la tabla hash. • quantum: Cantidad de bytes que se sacan de una cola antes de pasar a la

siguiente. • limit: Total de bytes que pueden ser encolados


42

FIGURA 1.28. Cola SFQ.

1.9.1.2.5. Disciplina de encolamiento con clases.

A una disciplina de encolamiento se le pueden definir clases. Cada una de ellas representa una división interna a la que se pueden redirigir paquetes. Una clase a su vez puede contener otras clases. A la clase que no tiene definidas clases internas se denomina clase terminal. Las clases terminales tienen definida una disciplina de encolamiento interna.

FIGURA 1.29. Encolamiento con clases.


43

1.9.1.2.6. Disciplina de encolamiento con priorización.

La disciplina de encolamiento con priorización no realiza ajustes. Cada paquete que recibe lo reenvía a una clase hija de acuerdo con la configuración de sus filtros. Cada cola tiene varias clases internas la x:1, la x:2 .... Cuando recibe una orden de desencolar, primero pregunta a la x:0, y si esta tiene paquete es el que se desencola. En caso contrario pregunta a las otras por orden. Las clases internas tienen por defecto una disciplina de encolamiento FIFO pero su disciplina se puede cambiar. Los filtros pueden basarse en diferentes características de los paquetes y no sólo de DSCP. Parámetros de una disciplina de encolamiento PRIO: • Bands: Numero de bandas a crear. • Priomap: Si no hay filtros se define un mapa de prioridades para interpretar el

octeto de servicios diferenciados. La figura 1.30 muestra un ejemplo de configuración de una disciplina de encolamiento PRIO

FIGURA 1.30. Encolamiento con priorización.


44

1.9.1.3. Paquetes y Datagramas.

En los sistemas de comunicación hay dos unidades de información:

• El paquete (packet) es una unidad de información del nivel del transporte (capa 3ª de la pila OSI). Su longitud es variable, aunque puede estar limitada.

• El datagrama (frame) es una unidad de información del nivel de enlace (capa 2º de la pila OSI). Su longitud es definida por la interfaz que se utiliza. En el caso de Ethernet, hay cabecera, y datos útiles entre 0 y 1500 bytes.

1.9.2. Operaciones básicas del control de tráfico.

1.9.2.1. Ajuste (Shaping). Es el mecanismo por el que un paquete es retrasado en la cola para ajustar el flujo de transmisión a la salida en una tasa establecida.

• Es la operación básica para limitar el ancho de banda que utiliza el flujo que se transmite.

• Es una operación no conservativa y por tanto requiere de un buffer (cola) para soportarlo.

• Conlleva el incremento de la latencia del flujo sobre el que opera, a cambio sirve para garantizar la latencia del resto de los flujos.

1.9.2.2. Planificación (Scheduling).

Reorganiza los paquetes de la cola de acuerdo con una cierta política de planificación:

• FIFO: First Input first output. • SFQ (Stochastic Fair Queuing): Planifica los paquetes de forma que se

transmitan equitativamente entre todos los flujos • WRR (Wide Round-Robin): Asigna a los paquetes de cada flujo tiempos

iguales de transmisión. • ESFQ: (Extended Stochastic Fair Queuing): Permite modificar las tablas

hash.


45

1.9.2.3. Clasificador (Classifying). El clasificador ordena o clasifica el flujo en diferentes flujos que son gestionados con diferentes características.

• La clasificación se puede realizar por diferentes criterios: por las marcas que llevan los paquetes, por la dirección de destino, por la dirección de origen, etc.

• En control de tráfico, la clasificación se realiza mediante cascadas de filtros.

1.9.2.4. Supervisión (Policing). En esta operación se ejecutan medidas y en función de ellas se limita el tráfico en las colas.

• Es un mecanismo que acepta tráfico a una cierta tasa. El tráfico que sobrepasa el valor especificado o bien se reclasifica, o bien se elimina.

• Se utiliza para garantizar que los flujos entre interlocutores se mantienen a las tasas que admiten el más lento.

• Son operaciones de alternativas sin capacidad de retrasar los paquetes.

1.9.2.5. Eliminación (Dropping). Es la operación de eliminar, paquetes, flujos y clasificaciones.

1.9.2.6. Marcado (Marking).

Es la operación a través de la que se modifica el contenido de un paquete.

• Modificando el campo DSCP se logra gestionar el flujo ya que este campo es utilizado por otros elementos de la red.


46

1.10. Resumen del capítulo. El Capítulo pretende dar una idea general de los conceptos involucrados con la arquitectura propuesta y la justificación de ésta. Se desarrolla el tema de modelos de calidad en el servicio, de manera que se entienda por que se escoge el modelo de Servicios Diferenciados. En el capítulo se desarrolló el tema de control de tráfico, sus elementos y los conceptos de ingeniería de tráfico; con esto se pretende dar una introducción de los elementos que se utilizaron para dar solución al problema descrito en el Capítulo 2. Se tocó el tema de virtualización y las características que ofrece esta, ya que la arquitectura está montada en desarrollos virtuales (appliances) como se mostrará en el Capítulo 3. Se tocó el tema de nube, ya que la arquitectura está montada en una red de prueba que pretende proveer los servicios soportados por la nube privada como se mostrará en el Capítulo 4.

CAPITULO II.

2. PRESENTACIÓN DEL PROBLEMA Y SOLUCIÓN PROPUESTA.

En el capítulo se presenta el escenario en el cual se detecta la necesidad de implementar la solución propuesta, atendiendo los problemas que representa la congestión y el uso inadecuado del enlace de carga de los enlaces a la Internet en las Pymes. Se describen las características de una solución comercial utilizada por las grandes empresas para atender el problema descrito anteriormente y también se presenta como se cubre cada característica con herramientas de código libre.

2.1. Presentación del Problema. La centralización de las aplicaciones y el almacenamiento de los datos origina una interdependencia de los proveedores de servicios. La disponibilidad de las aplicaciones está ligada a la disponibilidad de acceso a Internet. La confiabilidad de los servicios depende de la salud tecnológica y financiera de los proveedores de servicios de internet. La disponibilidad de servicios altamente especializados podría tardar meses o incluso años para que sean factibles de ser desplegados en la red. En cuanto a la seguridad, la información de la empresa debe recorrer diferentes nodos para llegar a su destino, cada uno de ellos (y sus canales) son un foco de inseguridad. Si se utilizan protocolos seguros HTTPS o VPNs, por ejemplo, la velocidad total disminuye debido a la sobrecarga que estos requieren.

CAPÍTULO II. PRESENTACIÓN DEL PROBLEMA Y SOLUCIÓN PROPUESTA.

48

Sumado a todo esto a medida que más usuarios empiecen a compartir la infraestructura de la nube, la sobrecarga en los servidores de los proveedores aumentará. Si la empresa no posee un esquema de crecimiento óptimo puede llevar a degradaciones en el servicio o tasas de jitter altas. Las redes de conmutación de paquetes difieren de las redes basadas en circuitos en un aspecto muy importante, una red de conmutación de paquetes carece de estados por sí misma. Una red basada en circuitos (como la red telefónica) debe mantener un estado dentro de la red. Las redes IP y redes de conmutación de paquetes carecen de estados por diseño; de hecho, el carecimiento de estados es una de las grandes fuerzas de IP. La debilidad de este carecimiento es la falta de diferenciación entre los tipos de flujos. En términos simples, el control de tráfico permite a un administrador diferenciar los paquetes en cola basándose en atributos del paquete. Puede ser usado para simular el comportamiento de una red basada en circuitos. Esto introduce el concepto de estados en una red que carecía de estados. Hay mucha razones prácticas para considerar el control de tráfico, y muchos diferentes escenarios en los cuales, el usarlo tiene mucho sentido. En entornos educativos cuando hay horas pico o en una Pyme donde los recursos son limitados y existen diferentes perfiles para su uso.

2.2. Soluciones existentes. En la actualidad existen varias soluciones a la administración y control de tráfico dentro del mercado, estas soluciones se enfocan en su mayoría a las grandes empresas. La razón es simple: son empresas que cuentan con los recursos suficientes para invertir en estos desarrollos. En las Pymes, Pequeñas Universidades y Entidades de gobierno municipales por razones de reducción de costos de operación, optan por carecer de los servicios de control de tráfico, y muchas veces no se dan a la tarea de encontrar solución a las prestaciones y ventajas del control de tráfico dentro de su Intranet.


49

2.2.1. Citrix NetScaler.

Las soluciones NetScaler de la Empresa Citrix Systems, Inc. ayudan a las organizaciones a crear redes de nubes privadas con las características y capacidades que definen las infraestructuras en la nube pública, como elasticidad, capacidad de expansión y simplicidad. NetScaler ofrece a las empresas varias tecnologías avanzadas que estaban disponibles anteriormente solo para grandes proveedores de nube pública.

Como líder indiscutido de entrega de servicios y aplicaciones, las soluciones de Citrix NetScaler se implementan en cientos de redes del mundo para optimizar, proteger y controlar la entrega de todos los servicios de nube y empresariales. Ofrecen un 100 % de disponibilidad de aplicaciones, descarga del servidor de base de datos y aplicaciones, aceleración y protección avanzada contra ataques. Con implementación directa en el nivel inicial de servidores web y de bases de datos, las soluciones de NetScaler combinan el balanceo de la carga, el almacenamiento en caché de contenido, la aceleración de SSL, la visibilidad del flujo de aplicación y un potente firewall de aplicación en una única plataforma fácil de usar.

NetScaler ayuda a las empresas a:

•Crear redes de nubes privadas que garanticen el mejor rendimiento y la mejor disponibilidad para todas las aplicaciones. •Aumente el control y la confianza con la seguridad y la visibilidad absolutas de la aplicación.

Una appliance ofrecida por Citrix a las grandes empresas es NetScaler VPX, la cual llega a costar 8000 dlls y se asemeja a la arquitectura propuesta y sus características. En la tabla 2.1 se presenta una tabla comparativa de una solución comercial más completa ofrecida para las grandes empresas y la arquitectura propuesta en el trabajo de tesis, se describen la característica de Citrix NetScaler y la solución dentro del núcleo de Linux.


50

Característica de Citrix NetScaler Demonio Utilizado1 AAA (Authentication, Authorization, Accounting) para control de trafico y administración FreeRadius

TCP buffering HTB

DHCP DHCP3 server

Balance de Carga en capa 4 Squid

Protocolos de enrutamiento dinámico QUAGGA routing daemon

Asesor de contenidos “Proxy” Squid

Firewall y NAT Netfilter (iptables)

DNS BIND

Host de maquinas Virtuales VirtualBox

SSL/TLS VPN OpenVPN

TABLA 2.1. Comparativa Solución existente Citrix NetScaler Vs. Arquitectura propuesta. Algunas de las características aquí descritas están disponibles dentro de Linux mas no fueron implementadas completamente en la arquitectura de este trabajo, ya que el objetivo principal consiste en el Control del Tráfico. Otra característica propia de la arquitectura propuesta en este trabajo consiste en proveer acceso inalámbrico a la red (Demonio Hostapd). Varias de las características son soportada vía un explorador web y por manejadores de bases de datos, en este caso se utiliza Apache, MySQL y PHP 5 para su interacción (LAMP). Muchas de estas soluciones integrales tienen una relación directa en su desempeño y hardware: a mayor recurso, mayores prestaciones. De forma similar en la arquitectura propuesta a mayor recurso de hardware, mejor desempeño se obtiene. A continuación la figura 2.1 presenta el escenario en el pasado cuando en los años 90s se introduce el Internet comercialmente y los escenarios que se presentan actualmente.

1 Un demonio, daemon o dæmon (de sus siglas en inglés Disk And Execution MONitor), es un tipo especial de proceso informático no interactivo, es decir, que se ejecuta en segundo plano en vez de ser controlado directamente por el usuario.

http://es.wikipedia.org/wiki/Idioma_ingl%C3%A9s

http://es.wikipedia.org/wiki/Proceso_(inform%C3%A1tica)


51

FIGURA 2.1. Escenarios del pasado vs. Arquitectura Propuesta

2.3. Descripción de las características principales de la Solución.

Linux ofrece un conjunto muy rico de herramientas para el manejo y manipulación de la transmisión de paquetes. En el entorno Linux es posible encontrar herramientas para el manejo y administración de firewall tal como “Netfilter”, así como también cientos de servicios de red que pueden correr en el sistema operativo. Los administradores de red están conscientes del tremendo poder que tienen los subsistemas de control de tráfico dentro de Linux, aun así estas herramientas carecen de documentación y algunas veces es difícil integrarlas. Es por esta razón que el presente trabajo puede servir de guía para tal implementación además de cubrir los objetivos presentados.

2.3.1. Prestaciones para la manipulación del tráfico. A continuación se presenta una lista de soluciones disponibles y las posibles aplicaciones que tienen estas herramientas. Se mencionan problemas comunes y se presentan soluciones para hacer eficiente el uso de los recursos de la red:

• Limitar el total de ancho de banda a una tasa conocida; solución: TBF, HTB con clase(s) hija(s).


52

• Limitar el ancho de banda de un usuario, servicio o cliente determinado; solución: HTB con clases y clasificación de tráfico con filtros.

• Maximizar el rendimiento TCP en un enlace asimétrico; solución: priorizando la transmisión de los paquetes ACK (Acknowledgment).

• Reservar ancho de banda para una aplicación o usuario determinado; solución: HTB con clases hijas y clasificación.

• Dar preferencia al tráfico sensible a la latencia; solución: PRIO (priorización dentro de una clase en HTB).

• Manejo del ancho de banda con exceso de solicitudes/peticiones; solución: HTB con préstamos.

• Permitir la distribución equitativa del ancho de banda no reservado; solución: HTB con préstamos.

• Asegurar que un tipo particular de tráfico es suprimido; solución: policer (proveedor de políticas) agregado a un filtro con la acción de descarte.

Como se mencionó anteriormente en algunos escenarios es necesario adquirir más ancho de banda. Puede que la solución propuesta no resuelva todos los problemas.

2.3.2. Prestaciones de la virtualización. Adicionalmente la virtualización ofrece prestaciones a la arquitectura y están relacionadas directamente con las características ofrecidas por el Hipervisor. He aquí un breve resumen de las principales características:

2.3.2.1. Portabilidad. La herramienta de virtualización que se utiliza es VirtualBox y se ejecuta en un gran número de sistemas operativos anfitriones de 32 bits y 64 bits. VirtualBox es llamado hipervisor hospedado (a veces referido como un hipervisor "tipo 2"). Mientras que un hipervisor bare-metal o "tipo 1" se ejecuta directamente en el hardware, el hipervisor hospedado requiere de un sistema operativo existente para ser instalado. Por lo tanto puede funcionar junto con las aplicaciones existentes en ese anfitrión. La virtualización es funcionalmente idéntica en todos los sistemas operativos anfitrión y se utilizan los mismos formatos de archivos e imagen. Esto nos permite ejecutar máquinas virtuales creadas en un anfitrión a otro anfitrión con un sistema


53

operativo diferente, por ejemplo, se puede crear una máquina virtual en Windows y luego ejecutarlo en Linux. Además, las máquinas virtuales pueden ser fácilmente importadas y exportadas con el Formato Abierto de Virtualización (OVF, un estándar de la industria creada para este propósito). Puede incluso importar OVFs que fueron creados con un software de virtualización diferente.

2.3.2.2. Virtualización de hardware no requerido.

El hipervisor que se utilizó en la arquitectura no requiere las características integradas de los procesadores con el nuevo hardware Intel VT-x o AMD-V, a diferencia de muchas otras soluciones de virtualización. Por lo tanto se puede instalar incluso en hardware antiguo, donde estas características no están presentes.

2.3.2.3. Gran soporte de hardware. Entre otros, el hipervisor que se utilizó soporta:

• Multiprocesamiento en el Sistema Operativo Invitado (SMP). Da soporte

hasta 32 CPUs virtuales en cada máquina virtual, independientemente del número de núcleos de CPU que estén físicamente presentes en el host.

• Compatibilidad con dispositivos USB. Utiliza un controlador virtual USB que permite conectar dispositivos USB a sus máquinas virtuales sin tener que instalar los controladores específicos del dispositivo en el anfitrión. La compatibilidad con USB no se limita a ciertas categorías de dispositivos.

• Compatibilidad de hardware. Se da soporte a una amplia gama de dispositivos virtuales, entre ellos muchos dispositivos típicamente proporcionados por otras plataformas de virtualización. Eso incluye interfaces IDE, SCSI y SATA, varias tarjetas de red y sonido virtuales, puerto serie y paralelo virtual y un controlador avanzado de interrupciones programable de entrada/salida (I/O APIC), que se encuentra en muchos sistemas PC modernos. Esto facilita la clonación de Computadoras Personales en imágenes de las máquinas reales y la importación de máquinas virtuales de terceros.

• Compatibilidad completa con ACPI. La configuración avanzada e interfaz de energía (ACPI) es totalmente compatible. Esto facilita la clonación de imágenes de PC de las máquinas reales o las máquinas virtuales de terceros. Con el soporte del estado de energía ACPI, se puede incluso mantener informado al ACPI de los sistemas operativos invitados el estado


54

de alimentación de la máquina anfitrión. Para los sistemas móviles que funcionan con batería, el invitado puede por lo tanto activar el ahorro de energía y notificar al usuario de la energía restante (por ejemplo, en modos de pantalla completa).

• Resoluciones multi-pantalla. Las máquinas virtuales admiten resoluciones de pantalla mayores que la de una pantalla física, lo que les permite extenderse a un gran número de pantallas conectadas al sistema anfitrión.

• Soporte con iSCSI. Esta característica única le permite conectar una máquina virtual directamente a un servidor de almacenamiento iSCSI2, sin pasar por el sistema host. La máquina virtual accede directamente al destino iSCSI, sin la sobrecarga adicional que se requiere para virtualizar los discos duros en los contenedores de los archivos.

• Arranque vía Red PXE. Las tarjetas virtuales de red integradas son totalmente compatibles con el inicio remoto a través del entorno de ejecución de pre-arranque (PXE).

2.3.2.4. Ramificado multi-generacional de tomas instantáneas.

Se pueden guardar arbitrariamente tomas instantáneas del estado de la máquina virtual. Se puede ir atrás en el tiempo y revertir la máquina virtual a cualquier toma instantánea o empezar una configuración alternativa de la VM a partir de ahí, creando un árbol de instantáneas.

2.3.2.5. Arquitectura Limpia; modularidad sin precedentes.

VirtualBox tiene un diseño extremadamente modular con interfaces bien definidas de programación interna y una separación limpia del código cliente y servidor. Esto hace que sea fácil de controlar desde varias interfaces a la vez: por ejemplo, puede iniciar una VM, simplemente haciendo clic en un botón en la interfaz de usuario gráfica de VirtualBox y luego controlar esa máquina desde la línea de comandos, o incluso de forma remota.

2 iSCSI (Abreviatura de Internet SCSI) es un estándar que permite el uso del protocolo SCSI sobre redes TCP/IP. iSCSI es un protocolo de la capa de transporte definido en las especificaciones SCSI-3. Otros protocolos en la capa de transporte son SCSI Parallel Interface y canal de fibra. La adopción del iSCSI en entornos de producción corporativos se ha acelerado en estos momentos gracias al aumento del Gigabit Ethernet. La fabricación de almacenamientos basados en iSCSI es menos costosa y está resultando una alternativa a las soluciones SAN (red de área de almacenamiento) basadas en Canal de fibra.


55

2.3.2.6. Pantalla de la máquina remota. La Extensión del Escritorio Remoto (VRDE) permite acceso remoto de alto rendimiento a cualquier máquina virtual en ejecución. Esta extensión es compatible con el protocolo de escritorio remoto (RDP), originalmente integrado en Microsoft Windows, con adiciones especiales para el cliente con soporte completo para USB. El VRDE no se basa en el servidor RDP que está integrado en Microsoft Windows, sino que está conectado directamente a la capa de virtualización. Como resultado de ello, se trabaja con los sistemas operativos invitados que no sean Windows (incluso en modo de texto) y tampoco requiere soporte de aplicaciones en la máquina virtual. En la parte superior de esta capacidad especial, se ofrecen más características únicas:

• Autenticación RDP extensible. VirtualBox ya soporta Winlogon en

Windows y PAM en Linux para la autenticación para RDP. Adicionalmente, incluye un kit de desarrollo de software fácil de usar el cual permite poder crear interfaces arbitrarias para otros métodos de autenticación.

• Soporte para dispositivos USB sobre el protocolo de escritorio remoto. Vía el soporte del canal virtual de RDP, VirtualBox permite conectar dispositivos USB localmente a la maquina virtual la cual esta ejecutándose remotamente en un servidor RDP de VirtualBox.

2.3.3. Prestaciones de servicios de nube privada.

2.3.3.1. Integración probada de servicios Red. Por su naturaleza, la tecnología de Cloud Computing se puede integrar con mucha mayor facilidad y rapidez con el resto de sus aplicaciones empresariales. El acceso a los recursos locales son provistos por enlaces VPN y toda la información está disponible desde un Servidor FTP o desde un escritorio remoto.


56

2.3.3.2. Prestación de servicios a nivel mundial. Las infraestructuras de Cloud Computing proporcionan mayor capacidad de adaptación, recuperación de desastres completa y reducción al mínimo de los tiempos de inactividad. Una infraestructura 100% de Cloud Computing elimina la instalación de cualquier tipo de hardware, ya que éste es provisto por nosotros desde la creación del Escritorio Remoto Virtual. El administrador se ocupará de dar mantenimiento a las máquinas virtuales desde una toma instantánea de la misma. La simplicidad de la tecnología de Cloud Computing y el hecho de que requiera mucha menor inversión para empezar a trabajar son algunas de sus mayores ventajas.

2.3.3.3. Implementación más rápida y con menos riesgos. Se podrá empezar a trabajar muy rápidamente gracias a una infraestructura de Cloud Computing. No habrá necesidad de volver a esperar meses o años e invertir grandes cantidades de dinero antes de que un usuario inicie sesión en su nueva solución. Se pueden migrar los equipos físicos a máquinas virtuales.

2.3.3.4. Contribuye al uso eficiente de la energía. En este caso, a la energía requerida para el funcionamiento de la infraestructura. En los datacenters tradicionales, los servidores consumen mucha más energía de la requerida realmente. En cambio, en las nubes, la energía consumida es sólo la necesaria, reduciendo notablemente el desperdicio. Por ejemplo, cuando se tienen dispositivos físicos realizando tareas de firewall, proxy, servidores web, servidores de aplicaciones, etc, el consumo de estos es mayor que si un solo servidor de maquinas virtuales hospeda estos desarrollos virtualmente.


57

2.4. Resumen del capítulo. En el capítulo se presentaron el problema y una solución comercial enfocada a las grandes empresas. Se muestra como está conformada la arquitectura adecuándola a una PyME3. También se muestran los alcances del control de tráfico en Linux, las prestaciones de la virtualización y la nube privada. En el Capítulo 3 se mostrara el diseño de la arquitectura.

3 PyME, por las siglas de Pequeña y Mediana empresa, definida en México por una empresa conformada desde un empleado hasta 150 empleados. En Medianas empresas de rubro manufacturero definida hasta por 250 empleados.

CAPITULO III.

3. DISEÑO DE LA SOLUCIÓN. 3.1. Introducción. En el presente Capitulo se muestra la estructura de la arquitectura, comparando en principio con el modelo OSI, posteriormente se presentan cada una de las herramientas que conforman la solución y finalmente se explica la aportación del control de trafico que se ofrece en los Sistemas Linux. 3.2. Arquitectura Propuesta. La arquitectura esta soportada sobre una plataforma Linux y como satélites agregando funcionalidades se encuentran diferentes demonios, que al ser integrados en desarrollos virtuales (virtual appliances) conforman una poderosa y robusta solución. A continuación se mencionan los demonios y herramientas implementados, se da una breve explicación de lo que aporta cada uno. En las figuras 3.1 y 3.2 se muestra cómo se conforma la arquitectura a diferentes niveles comparándolo con el modelo OSI.

CAPÍTULO III. DISEÑO DE LA SOLUCIÓN.

60

FIGURA 3.1. Descripción arquitectura Nivel 1.

FIGURA 3.2. Descripción Arquitectura Nivel 2.

A continuación las figura 3.3 muestra la arquitectura, describiendo los protocolos y las herramientas utilizadas para su desarrollo. Primero el segmento de la red publica.


61

FIGURA 3.3. Descripción Arquitectura Nivel 3A.

La figura 3.4 muestra la arquitectura vista desde el enfoque de la red Privada.

FIGURA 3.4. Descripción Arquitectura Nivel 3B.

A continuación se presentan los demonios o herramientas que conforman la arquitectura. 3.2.1. Hipervisor VirtualBox. VirtualBox es una aplicación de virtualización multi-plataforma. ¿Qué significa eso? Por un lado, se instala en un ordenador basado en arquitecturas Intel o AMD, ejecutando sistemas operativos Windows, Mac, Linux o Solaris. En segundo lugar, amplía las capacidades del equipo para que pueda ejecutar múltiples sistemas operativos (máquinas virtuales), al mismo tiempo. Así, por ejemplo, se puede ejecutar Windows y Linux en una Mac, ejecutar Windows Server 2008 en


62

un servidor Linux, ejecutar Linux en una PC con Windows, y así sucesivamente, todo junto con sus aplicaciones existentes. Se pueden instalar y ejecutar las máquinas virtuales que se requieran, los únicos límites prácticos son el espacio en disco y memoria. VirtualBox es engañosamente simple, pero también un herramienta muy poderosa. Puede funcionar en todas partes, desde pequeños sistemas embebidos o máquinas de escritorio de toda clase hasta implementaciones de centros de datos e incluso en entornos de nube como es el caso. La figura 3.5 muestra cómo VirtualBox, instalado en un ordenador Mac, está ejecutando Windows 7 en una ventana de la máquina virtual. Los diferentes demonios utilizados en la arquitectura propuesta se montan en diferentes maquinas virtuales como se mostrara en el Capitulo IV del Caso de Estudio.

FIGURA 3.5. Interfaz grafica de VirtualBox.

3.2.2. Iproute Iproute versión 2 es un paquete de utilidades que conjunta herramientas muy potentes para administrar interfaces de red y conexiones en sistemas Linux. Este paquete extiende y remplaza completamente las funcionalidades y características provistas por dispositivos dedicados al ruteo y control de tráfico. Aquí se aplica QoS priorizando distintos tipos de tráfico. El control de tráfico está compuesto por varias operaciones distintas, entre ellas: un mecanismo de


63

clasificación en el cual se identifican los paquetes y se colocan en distintas clases o flujos, políticas en donde se limita el número de paquetes o bytes que pueden ser utilizados en un flujo particular, además se tienen decisiones de planificación en donde se decide el orden. Se pueden manejar múltiples tablas de ruteo por diferentes puertas de enlaces conectadas a distintos dispositivos, aplicando el balanceo de carga, asignándole pesos a cada una de las NICs existentes dentro de la máquina. Se pueden crear túneles que encapsulan paquetes en un formato IPv4 y se envían por la infraestructura IP. En el Capitulo IV se muestra el caso de estudio donde se manipula esta herramienta y se definen los parámetros para cada uno de los mecanismos de control de trafico. 3.2.3. HTB (Hierarchical Token Bucket). El algoritmo de token bucket es usado en las redes de conmutación de paquetes para delimitar las tasas de transferencia definidas para un ancho de banda predeterminado a medida que el flujo de tráfico varia. HTB “Hierarchical Token Bucket” (HTB) es un demonio disponible en Linux, más rápido que token bucket dentro las disciplinas de encolamiento con clases. HTB ayuda a controlar el uso del ancho de banda de salida en un determinado nodo. Permite usar un simple enlace físico para simular múltiples enlaces más lentos y enviar diferentes tipos de tráfico en los diferentes enlaces simulados. En ambos casos, como administrador de la red se tiene que especificar como dividir el enlace físico en los enlaces simulados y decidir en cuál de ellos deberá de ser mandado un paquete dado. En otras palabras, HTB es de gran ayuda para limitar las tasas de carga y descarga de un cliente de la red ya sea una aplicación, un equipo, o un servicio determinado montado dentro de la red privada. Es así como los clientes de la red de prueba no pueden saturar el total del ancho de banda disponible. 3.2.4. OpenVPN. OpenVPN tiene todas las funciones de una VPN (Red Privada Virtual) con SSL (Protocolo de capa de conexión segura) el cual implementa las extensiones de red segura en Capa 2 y 3 del modelo OSI usando los protocolos estándares en la industria SSL/TLS (Seguridad de la capa de Transporte), soporta métodos de


64

autentificación de clientes flexible basado en certificados, tarjetas inteligentes, o por credenciales simples usuario/contraseña, y permite implementar políticas de control de acceso ya sea un usuario o grupo específico usando reglas de firewall aplicadas a la interface virtual de la VPN. Utiliza el Puerto 1194/udp. 3.2.5. Servidor ISC DHCP3. El protocolo de configuración dinámica de host DHCP (Dynamic Host Configuration Protocol) es un estándar TCP/IP que simplifica la administración de la configuración IP haciéndola automática. Un servidor gestiona la concesión de direcciones IP de un determinado segmento de red y mantiene una lista actualizada de la correspondencia entre estas direcciones IP y las direcciones MAC de los equipos que las han solicitado. En el protocolo DHCP, el servidor utiliza el puerto 67/udp y el cliente el 68/udp. DHCP3 server es la solución dentro del ambiente de desarrollo de Linux y es utilizado ampliamente. En la arquitectura propuesta ayuda a identificar las direcciones MAC con una dirección IP privilegiada, en contexto con los niveles de servicios caracterizados por las clases definidas en el control de trafico con IPROUTE/Squid. 3.2.6. Squid. Squid es un asesor de contenidos con soporte HTTP, HTTPS, FTP, etc. También reduce y controla el ancho de banda y mejora los tiempos de respuesta para el acceso a páginas web de uso frecuente almacenando temporalmente su contenido. Posee controles de acceso robustos y lo hace un gran acelerador web. Corre en múltiples sistemas operativos, incluyendo Windows y en entornos desarrollados bajo licencia GNU GPL. Hace más por la conexión a Internet, y es usado por miles de proveedores de Internet en todo el mundo para proveer a sus usuarios con el mejor acceso posible a la Web. Optimiza el flujo de datos entre cliente y servidor limitando las tasas a determinado margen para mejorar el desempeño y almacena el contenido de uso frecuente para ahorrar ancho de banda. Los sistemas con Squid implementado, pueden llegar a cuadriplicar la capacidad en las tasas de acceso de los Servidores Apache atrás de ellos, esto se hace visible cuando una gran fuente de tráfico es solicitado a una página web en particular desde otro sitio y se tiene montado un servidor de almacenamiento


65

secundario y se redirige este tráfico a este, la eficiencia de esa página es casi del 200%, gracias al balance de carga soportado por Squid. En la arquitectura propuesta ayuda a limitar las tasas de transferencia del enlace de descarga identificando el flujo por rangos de direcciones IP y asignándoles un ancho de banda correspondiente a su nivel de servicio. 3.2.7. Quagga Quagga es una suite de software para el ruteo, proveyendo implementaciones de OSPFv2, OSPFv3, RIP v1 y v2 a plataformas Unix, particularmente a FreeBSD, Linux, Solaris y NetBSD. La arquitectura de Quagga consiste en un demonio del núcleo Zebra, el cual actúa como una capa abstracta al kernel Linux y se presenta como una aplicación (Zserv API) sobre el flujo TCP a los clientes Quagga. Son los clientes de Zserv los cuales implementan los protocolos de ruteo y comunican las actualizaciones de las rutas al demonio Zebra. Los clientes Zserv existentes son: • Ospfd: implementa OSPFv2 • Ripd: implementa RIP v1 y V2 • Ospf6d: implementa OSPFv3 (IPv6) • Ripngd: implementa RIPng (IPv6) • Bgpd: implementa BGPv4+ (incluye soporte a la familia de direcciones para

multicast e IPv6). Un sistema con Quagga instalado actúa como un enrutador dedicado. Con Quagga, la maquina intercambia información de ruteo con otros enrutadores usando protocolos de ruteo. Quagga usa esta información para actualizar la tabla de ruteo del kernel para que así los datos adecuados lleguen al lugar correcto. Se puede cambiar dinámicamente la configuración y se podría ver la información de la tabla de ruteo desde la interfaz terminal de Quagga. Adicionalmente al soporte del protocolo de ruteo, Quagga puede configurar flags en las interfaces, direcciones a las interfaces y rutas estáticas. Si se tiene una pequeña red o una conexión xDSL, configurar el software de ruteo de Quagga es muy fácil. Lo único que se tiene que hacer es configurar las interfaces y poner unos pocos comandos acerca de rutas estáticas y/o rutas por default. Si la red es muy grande, o si la estructura de la red cambia frecuentemente, se podría sacar ventaja a el protocolo de ruteo dinámico ofrecido por Quagga como lo son los protocolos RIP, OSPF o BGP.


66

3.2.8. BIND. BIND (Berkeley Internet Name Domain, anteriormente: Berkeley Internet Name Daemon) es el servidor de DNS más comúnmente usado en Internet, especialmente en sistemas Unix, en los cuales es un Estándar de facto. Es patrocinado por la Internet Systems Consortium. BIND fue creado originalmente por cuatro estudiantes de grado en la University of California, Berkeley. Una nueva versión de BIND (BIND 9) fue escrita desde cero en parte para superar las dificultades arquitectónicas presentes anteriormente para auditar el código en las primeras versiones de BIND, y también para incorporar DNSSEC (DNS Security Extensions). BIND incluye entre otras características importantes: TSIG, notificación DNS, nsupdate (actualización de nombres de dominio), IPv6, vistas, procesamiento en paralelo, y una arquitectura mejorada en cuanto a portabilidad. Es comúnmente usado en sistemas GNU/Linux. Utiliza el Puerto 53/UDP/TCP. 3.2.9. NETFILTER Netfilter está disponible en el núcleo Linux, el cual permite interceptar y manipular paquetes de red. Permite realizar el manejo de paquetes en diferentes estados del procesamiento. Netfilter también se encarga de ofrecer herramientas libres para cortafuegos basados en Linux. El componente más popular construido sobre Netfilter es iptables, una herramienta de cortafuegos que permite no solamente filtrar paquetes, sino también realizar traducción de direcciones de red (NAT) para IPv4 o mantener registros de log. El proyecto Netfilter no sólo ofrece componentes disponibles como módulos del núcleo sino que también ofrece herramientas de espacio de usuario y librerías. El nombre iptables se utiliza frecuentemente de forma errónea para referirse a toda la infraestructura ofrecida por el proyecto Netfilter. Sin embargo, el proyecto ofrece otros subsistemas independientes de iptables tales como el “connection tracking system” o sistema de seguimiento de conexiones, que permite encolar paquetes para que sean tratados desde espacio de usuario. Iptables es un software disponible en prácticamente todas las distribuciones de Linux actuales.


67

3.2.10. Freeradius RADIUS (acrónimo en inglés de Remote Authentication Dial-In User Server). Es un protocolo de autenticación y autorización para aplicaciones de acceso a la red o movilidad IP. Utiliza el puerto 1812/UDP para establecer sus conexiones. Cuando se realiza la conexión con un ISP mediante módem, DSL, cablemódem, Ethernet o Wi-Fi, se envía una información que generalmente es un nombre de usuario y una contraseña. Esta información se transfiere a un dispositivo Network Access Server (NAS) sobre el protocolo PPP (Protocolo Punto a Punto), quien redirige la petición a un servidor RADIUS sobre el protocolo RADIUS. El servidor RADIUS comprueba que la información es correcta utilizando esquemas de autenticación como PAP (Protocolo de Autentificación por contraseña), CHAP (Protocolo de autenticación por desafío mutuo) o EAP (Protocolo de autenticación extensible). Si es aceptado, el servidor autorizará el acceso al sistema del ISP y le asigna los recursos de red como una dirección IP, y otros parámetros como L2TP (Protocolo de túnel en capa 2), etc. Una de las características más importantes del protocolo RADIUS es su capacidad de manejar sesiones, notificando cuando comienza y termina una conexión, así que al usuario se le podrá determinar su consumo y facturar en consecuencia; los datos se pueden utilizar con propósitos estadísticos. RADIUS está definido en los RFC 2865 (autentificación y autorización) y RFC 2866 (accounting); existen muchos servidores RADIUS, tanto comerciales como de código abierto. Las prestaciones pueden variar, pero la mayoría pueden gestionar los usuarios en archivos de texto, servidores LDAP, bases de datos varias, etc. A menudo se utiliza SNMP para monitorear remotamente el servicio. En la arquitectura se implemento FreeRADIUS y este ayuda proporcionando una capa adicional para la autorización del uso de los recursos, se utilizo para interactuar con los demonios Hostapd y OpenVPN para la autenticación de los usuarios. 3.2.11. Hostapd Hostapd es un demonio de espacio de usuario para Punto de Acceso y servidor de autentificación. Implementa la administración del punto de acceso IEEE 802.11, servidor de autentificación IEEE 802.1X/WPA/WPA2/EAP, cliente RADIUS,


68

servidor EAP, y servidor de autenticación RADIUS. La versión actual soporta los controladores HostAP, Madwifi y mac80211 en Linux y net80211 en FreeBSD. Hostapd está diseñado para ser un programa “demonio” que corre en Segundo plano y actúa como un componente control de autentificación. Características WPA/IEEE 802.11i/EAP/IEEE 802.1X soportadas: • WPA-PSK ("WPA-Personal"). • WPA con EAP (con un servidor EAP integrado o con un servidor de

autentificación RADIUS externo) ("WPA-Enterprise"). • Administrador de llaves CCMP, TKIP, WEP104, WEP40. • Soporte completo para WPA y IEEE 802.11i/RSN/WPA2. • RSN (Robust Security Network): almacenamiento en cache para PMKSA

(Pairwise Master Key Security Association), pre-autenticación. • IEEE 802.11r, para la conectividad inalámbrica en movimiento. • IEEE 802.11w, para la gestión de claves, cifrado y autenticación extendida

como WPA2. • Tarificación (RADIUS accounting) • Servidor de autenticación RADIUS con EAP • WPS (Wi-Fi Protected Setup)

En la arquitectura propuesta participa dando acceso inalámbrico a los equipos móviles de forma que estos sean identificados como les corresponde. Hostapd interactúa con el demonio de FreeRADIUS, si este ultimo rechaza las credenciales el punto de acceso inalámbrico proporcionara los datos que se utilizaron para autenticarse y se guardaran en una base de datos montada en MySQL para su posterior análisis. 3.2.12. Wireshark Wireshark, antes conocido como Ethereal, es un analizador de protocolos utilizado para realizar análisis y solucionar problemas en redes de comunicaciones, para desarrollo de software y protocolos, y como una herramienta didáctica para educación. Cuenta con todas las características estándar de un analizador de protocolos. La funcionalidad que provee es similar a la de tcpdump1, pero añade una interfaz gráfica y muchas opciones de organización y filtrado de información.

1 tcpdump es una herramienta en línea de comandos cuya utilidad principal es analizar el tráfico que circula por la red. Existe una adaptación de tcpdump para los sistemas Windows que se llama WinDump.

http://es.wikipedia.org/wiki/Windows


69

Así, permite ver todo el tráfico que pasa a través de una red (usualmente una red Ethernet, aunque es compatible con algunas otras) estableciendo la configuración en modo promiscuo. También incluye una versión basada en texto llamada tshark. Permite examinar datos de una red en vivo o de un archivo de captura salvado en disco. Se puede analizar la información capturada, a través de los detalles y sumarios por cada paquete. Wireshark incluye un completo lenguaje para filtrar lo que queremos ver y la habilidad de mostrar el flujo reconstruido de una sesión de TCP. Wireshark es software libre, y se ejecuta sobre la mayoría de sistemas operativos Unix y compatibles, incluyendo Linux, Solaris, FreeBSD, NetBSD, OpenBSD, y Mac OS X, así como en Microsoft Windows. En la arquitectura propuesta se utilizo para monitorear el tráfico de la red de prueba con el propósito de demostrar el optimo desempeño de la gestión del enlace de carga. 3.2.13. LAMPP El acrónimo “LAMPP” se refiere a un conjunto de subsistemas de software necesarios para alcanzar una solución global, en este caso configurar sitios web o servidores dinámicos con un esfuerzo reducido. LAMPP se consigue mediante la unión de las siguientes tecnologías: • Linux, el sistema operativo; En algunos casos también se refiere a LDAP. • Apache, el servidor web; • MySQL, el gestor de bases de datos; • Perl, PHP, o Python, los lenguajes de programación.

La combinación de estas tecnologías es usada primariamente para definir la infraestructura de un servidor web, utilizando un paradigma de programación para el desarrollo. A pesar de que el origen de estos programas de código abierto no han sido específicamente diseñado para trabajar entre sí, la combinación se popularizó debido a su bajo coste de adquisición y ubicuidad de sus componentes (ya que vienen pre-instalados en la mayoría de las distribuciones Linux). Cuando son combinados, representan un conjunto de soluciones que soportan servidores de aplicaciones.


70

3.3. Control de Tráfico con Linux. Control de tráfico es el nombre que se le da al conjunto de sistemas y mecanismos de encolamiento por los cuales los paquetes son recibidos y transmitidos en un enrutador. Esto incluye decidir cuales paquetes aceptar y a que tasa en la entrada de una interfaz y determinar que paquetes transmitir, en qué orden y a que tasa en la salida de la interfaz. En otras palabras con el encolamiento se determina la manera en que se envían los datos, solo se puede dar forma a lo se transmite. No se tiene control directo sobre lo que se envía desde fuera. TCP/IP no tiene la habilidad de saber la capacidad de la red entre 2 sistemas, empieza a enviar datos más y más rápido y cuando se pierden paquetes, reduce la marcha. Si se desea evitar que ciertos equipos dentro de la red descarguen demasiado rápido, se le da forma (shaping) a la interfaz interna del enrutador; la cual envía los datos a las computadoras. También se asegura que se controla el cuello de botella del enlace. Si se tiene una NIC Ethernet de 100 Mbit/s y un enrutador con un enlace de 768 kbit/s, se asegura de que no se envíen más datos de los que el enrutador pueda manejar. En la mayoría de los casos, el control de tráfico consiste en un encolamiento sencillo, el cual colecta los paquetes entrantes y los entrega tan rápido como el hardware (un dispositivo subyacente) pueda aceptarlos. Este tipo de cola es una FIFO (First-in First-out). Hay ejemplos de encolamiento en todo tipo de software. El encolamiento es la manera de organizar tareas pendientes o datos. Ya que los enlaces de red transportan típicamente datos de forma serializada, una cola es requerida para manejar los paquetes de datos de salida. En el caso de un equipo de escritorio y un eficiente servidor web que comparten el mismo enlace de subida a la Internet, la contienda por el ancho de banda podría ocurrir. El servidor web podría ser capaz de llenar el encolamiento de salida del enrutador más rápido que los datos puedan ser transmitidos a través del enlace, en ese momento el enrutador empieza a tirar paquetes (su buffer se llena). Ahora, el equipo de escritorio (con una aplicación interactiva) puede enfrentarse a la perdida de paquetes y a una alta latencia. Al separar las colas usadas para dar servicio a estas dos diferentes clases de aplicación, puede que haya un mejor compartimiento del recurso de red entre estas dos aplicaciones.


71

A continuación la tabla 3.1 muestra las diferentes operaciones para el control de tráfico y la instrucción o componente dentro de Linux que cubre con la tarea.

Operación Componente de Linux TC

Shaping class ofrece las capacidades de clasificación.

Scheduling qdisc es un planificador. Los planificadores pueden ser simples como FIFO o complejos conteniendo clases y otras disciplinas de encolamiento.

Classifying Los filters realizan la clasificación a través de un agente interno.

Policing Existe un policier en Linux que se implementa como parte de un filter.

Dropping Se realiza a través de un filter con un agente policer que ejecuta la acción drop.

Marking El dsmark qdisc puede utilizarse para marcar paquetes.

TABLA 3.1. Relaciones entre Elementos de TC y Operaciones de control

CAPITULO IV.

4. CASO DE ESTUDIO 4.1. Introducción. En los capítulos anteriores se presentaron las bases teóricas, los conceptos relacionados con la arquitectura, virtualización, redes privadas virtuales, control de autenticación-autorización, control de tráfico, enrutamiento dinámico, y la teoría de su implementación por medio del sistema operativo Ubuntu. La implementación de la red de prueba quedo documentada en el anexo B de este trabajo de tesis. El caso de estudio fue puesto en marcha en un segmento de la red de la ESCOM, que a su vez es un segmento de la red institucional del Instituto Politécnico Nacional (IPN), simulando la red de una PYME donde sus usuarios y equipos requieren de diferentes servicios. Esta red convergente contempla servicios ofrecidos por una nube privada, servicios de video, voz y datos. En este capitulo se presenta un escenario de prueba sobre una red privada, donde el proveedor de servicios de infraestructura es una maquina con sistema operativo Ubuntu en donde se montaron equipos virtuales y los roles correspondientes a cada uno como se mostrara mas adelante. Las mediciones y ejemplos usados nos dan evidencia del potencial existente en las áreas de virtualización y control de tráfico usando herramientas de código abierto. Al final se obtiene una arquitectura que cubre los siguientes puntos: • Mantener una latencia baja todo el tiempo para el tráfico interactivo. Esto

significa que descargar o enviar ficheros no debería molestar a SSH. • Permitir la "navegación" a velocidades razonables mientras se envía o

descarga información. Incluso pensando que http es tráfico masivo, el resto de tráfico no debería ahogarlo demasiado.

CAPÍTULO IV. CASO DE ESTUDIO.

73

• Asegurarse de que los envíos no dañan las descargas, y viceversa. Se observa a menudo el fenómeno de que el tráfico de salida destruye la velocidad de descarga.

La razón de que los envíos, descargas y SSH se maten entre ellos es la presencia de grandes colas en muchos dispositivos de acceso como los cable-módems y los ADSL. 4.2. ¿Por qué no funciona bien por defecto? Los ISP saben que se les compara solamente según lo rápido que puede descargar la gente. Aparte del ancho de banda disponible, la velocidad de descarga viene muy influenciada por la pérdida de paquetes, que obstaculiza seriamente el rendimiento de TCP/IP. Las colas grandes pueden ayudar a evitar la perdida de paquetes, y acelera las descargas. De manera que los ISP configuran colas grandes. Sin embargo, estas grandes colas dañan la interactividad. Una pulsación tiene que pasar primero por la cola de envío, lo que puede tardar varios segundos y llegar a la máquina remota. Entonces se muestra, lo que genera un paquete de vuelta, que debe atravesar otra cola, situada en el ISP, antes de aparecer en la pantalla. La cola del ISP está completamente fuera de nuestros límites, mientras que la cola de envío probablemente reside en el cable módem o en el dispositivo ADSL. Puede ser o no que haya posibilidad de configurarla, lo más probable es que no. De manera que, es posible controlar esas colas con la arquitectura. Los usuarios hacen uso indiscriminado de programas "peer to peer", de manera que es esencial un control de tráfico adecuado. En la figura 4.1 se presenta el esquema de red utilizado: Se tienen dos segmentos de red diferentes, la red pública a la cual esta conectada directamente la arquitectura y el otro segmento tenemos a nuestra red privada 10.127.127.0/24 donde se ubican los servidores y clientes locales de los servicios implementados. Entre las dos redes se tiene el equipo que sirve de Puerta de Enlace y que a su vez servirá como dispositivo de control de tráfico. Los resultados que se obtengan a partir de este esquema, a pesar de su sencillez, pueden hacerse extensivos a otro tipo de configuraciones, en donde se tiene un conjunto de clientes accediendo a los servicios ubicados en la red desde un servidor de red privada virtual.


74

FIGURA 4.1. Esquema sencillo del montaje de la red de prueba.

Para la implementación que se muestra en la figura 4.2, se hará control de trafico sobre la interfaz eth0 del equipo físico, es decir el equipo no es virtual y es el que da soporte de hipervisor y controlara el trafico entre la internet y nuestra red privada que esta conectada en la interfaz br0 (eth1+wlan0). Esto de la siguiente manera. Para el enlace de carga:

1. Control de tráfico sobre la red virtual, es aprovisionado por el switch virtual del Hipervisor.

2. Control de tráfico sobre la red física, originado por nuestros clientes físicos de nuestra red privada que es concentrada por un switch físico.

3. Control de tráfico sobre la Interfaz tun0, donde los clientes son remotos y los identificamos con el puerto 1194 y nuestra dirección IP de origen (La publica).

4. Control de tráfico dependiendo del tipo de trafico, protocolo y de su origen. 5. Limitando la tasa de transferencia de carga a poco menos de la verdadera

tasa disponible, no se crean colas en el ISP. La cola se ha trasladado a la arquitectura.


75

Lo que queda por hacer es asegurar de que el tráfico interactivo pase al nivel 1 de la cola del enlace de carga. Para asegurar de que los envíos no obstaculizan las descargas, también se pasan los paquetes ACK al nivel 1. Esto es lo que normalmente produce la gran reducción de velocidad cuando se genera tráfico masivo en ambas direcciones. Las confirmaciones (ACKnowledgements) del tráfico de descarga deben competir con el tráfico de envío, y quedan retrasados en el proceso. Para el enlace de descarga: Esto tiene algo más de truco, ya que no se puede influenciar realmente lo rápido que internet entrega los datos. Sin embargo, se pueden descartar paquetes según su URL, contenido, etc. Como no se desea descartar tráfico innecesariamente, se configura el tamaño de la "ráfaga" que permite altas velocidades. Esto se puede lograr con lo siguiente:

1. Control de tráfico por medio de un servidor Proxy transparente. 2. Bloqueo de URL y extensiones de archivo. 3. Reparto del recurso en 3 niveles de servicio, por rangos de ip.

FIGURA 4.2 Esquema general para control de tratico.


76

4.3. Descripción de los componentes de la red de prueba. A continuación se muestra la convención de nombres que se utilizaron en este trabajo de tesis para describir los componentes de la red de prueba, estos fueron escogidos según los servicios hospedados por cada servidor. También se indican las direcciones IP de cada componente en el caso de estudio. 10.127.127.0/24 red principal. 4.3.1. BlackIaaS: (VirtualBox, Hostapd, Quagga, OpenVPN). Para facilitar su uso posterior este servidor se denominara BlackIaaS el cual trabaja como Servidor Anfitrión y hospeda los servidores virtuales, también tiene las funciones de punto de acceso inalámbrico, enrutador dinámico y servidor de red privada virtual. Hardware: Procesador Core i7 2600k a 3.4 GHz, 4 núcleos con 8 líneas de procesamiento 8GB de RAM DDR3 a 1600Mhz 1TB de disco duro con 64MB en cache a 7200RPM. 1 Tarjeta de red Inalámbrica con soporte 802.11n. 2 Tarjetas de red Gigabit integradas en la tarjeta madre. Software: Sistema Operativo Ubuntu Server 11.10 64-bit (Oneiric Ocelot). Versión del Kernel 3.0.0-12.20. Servidor de Maquinas Virtuales (Hipervisor): VirtualBox versión 4.1. Emulador de punto de acceso inalámbrico: Hostapd versión 1:0.7.3-2build1 Servidor SSH: OpenSSH versión 1:5.8p1-7. Servidor de red privada virtual: OpenVPN versión 2.2.0-2. Emulación de enrutamiento dinámico: Quagga versión 0.99.18-2. Traducción de direcciones de red: iptables versión 1.4.10-1. Control de tráfico: iproute versión 20110315_1build1 Configuración de red: br0: Dirección IP->10.127.127.254/24 eth0: dirección pública asignada dinámicamente por nuestro ISP. tun1: Dirección IP->10.8.0.1/24


77

4.3.2. BlackProxy: (Servidor Squid) El Servidor Virtual que funciona como Proxy adopta el nombre BlackProxy. Hardware asignado: Procesador de 1 núcleo. 1GB de RAM 320GB de disco duro, es en su gran mayoría para la cache de almacenamiento de nuestros sitios favoritos. 1 Tarjetas de red Gigabit en modo puente con la interfaz del anfitrión br0. Software: Sistema Operativo Ubuntu Server 11.10 64-bit (Oneiric Ocelot). Versión del Kernel 3.0.0-12.20. Servidor SSH: OpenSSH versión 1:5.8p1-7. Traducción de direcciones de red: iptables versión 1.4.10-1. Control de enlace descendente (puerto 80) y asesor de contenidos: Squid versión 2.7.STABLE9-4 Configuración de red. eth0: Dirección IP->10.127.127.253/24, Puerta de Enlace->10.127.127.254 4.3.3. BlackBox: (Netfilter, FreeRADIUS, ISC DHCP, ISC DNS) El Servidor Virtual que hospeda el Servidor DHCP, DNS, RADIUS y realiza el control de tráfico se le designo el nombre de BlackBox. (Proxy-nivel 1) Hardware asignado: Procesador de 1 núcleo. 1GB de RAM 8GB de disco duro. 1 Tarjetas de red Gigabit en modo puente con la interfaz del anfitrión br0. Software: Sistema Operativo Ubuntu Server 11.10 64-bit (Oneiric Ocelot). Versión del Kernel 3.0.0-12.20. Servidor SSH: OpenSSH versión 1:5.8p1-7. Traducción de direcciones de red: iptables versión 1.4.10-1.


78

Servidor RADIUS: FreeRadius versión 2.1.10+dfsg-3 Servidor DHCP: ISC dhcp server versión 4.1.1-P1-17 Servidor DNS: BIND9 versión 1:9.7.3.dfsg-1 Configuración de red: eth0: Dirección IP->10.127.127.252/24, Puerta de Enlace->10.127.127.254 4.3.4. BlackLamp: (Servidor FTP, LAMP) EL servidor virtual que hospeda la pila LAMPP es nombrado BlackLamp. (Proxy-nivel 3) Hardware asignado: Procesador de 1 núcleo. 1GB de RAM, 250GB de disco duro, asignado para el hosting web, bases de datos y el servidor ftp. 1 Tarjetas de red Gigabit en modo puente con la interfaz del anfitrión br0. Software: Sistema Operativo Ubuntu Server 11.10 64-bit (Oneiric Ocelot). Versión del Kernel 3.0.0-12.20. Servidor SSH: OpenSSH versión 1:5.8p1-7. Servidor HTTP: Apache versión 2.2.20-1 Servidor FTP: pure-ftpd versión 1.0.32-1 Servidor de bases de datos: Mysql 5.1.61-0 Compilador PHP5 versión 5.3.6-13 Configuración de red: eth0: Dirección IP->10.127.127.251/24, Puerta de Enlace->10.127.127.252 4.3.5. BlackSar: (Servidor de Acceso Remoto) El servidor virtual que hospeda los servicios de escritorio remoto tomo el nombre de BlackSar. (cliente Proxy-nivel 1). Hardware asignado: Procesador de 1 núcleo. 1GB de RAM, 250GB de disco duro, asignado para la ofimática, ERP’s etc. 1 Tarjetas de red Gigabit en modo puente con la interfaz del anfitrión br0.


79

Software: Sistema Operativo Windows Server 2008 R2, con escritorio remoto habilitado y el rol de Servicios de Escritorio Remoto instalado. Configuración de red: eth0: Dirección IP->10.127.127.250/24, Puerta de Enlace->10.127.127.252 4.3.6. Clientes 4.3.6.1. Cliente local. Cliente (Proxy-nivel 2). Hardware: Procesador Intel Core i5 quad-core a 2.7 GHz 4GB de RAM DDR3 a 1600Mhz 1TB de disco duro. 1 Tarjeta de red Inalámbrica con soporte 802.11n. 1 Tarjeta de red Gigabit integradas en la tarjeta madre. Software: Sistema Operativo Mac OS X 10.7.3 Cliente SSH: integrado en S.O. vía terminal. Navegador: Safari versión 5.1.4 Analizador de protocolos de Internet: Wireshark versión 1.6.5 Configuración de red: en1: Dirección IP->10.127.127.121/24 4.3.6.2. Cliente Remoto 1. Cliente. Hardware: Procesador AMD Athlon a 2.2 GHz 2GB de RAM DDR2 a 800Mhz, 160GB de disco duro. 1 Tarjeta de red Gigabit integrada en la tarjeta madre. Software: Sistema Operativo Windows 7 x64 Cliente SSH: Putty Navegador: Internet Explorer versión 9.0.8112.16421 Analizador de protocolos de Internet: Wireshark versión 1.6.5


80

Configuración de red: Dirección IP->192.168.0.x tun1: Dirección IP->10.8.0.2/24 4.3.6.3. Cliente Remoto 2. Cliente (remoto). Hardware: Procesador Intel Core 2 Dúo 2.4 GHz 8GB de RAM DDR3, 250GB de disco duro. 1 Tarjeta de red Inalámbrica con soporte 802.11n. 1 Tarjeta de red Gigabit integradas en la tarjeta madre. Software: Sistema Operativo Mac OS X 10.7.3 Cliente SSH: integrado en S.O. vía terminal. Navegador: Safari versión 5.1.4 Analizador de protocolos de Internet: Wireshark versión 1.6.5 Cliente VPN: Tunnelblick 3.2.3 (build 2891.2932) Configuración de red: Dirección IP-> tun1: Dirección IP->10.8.0.3/24 4.4. Pruebas y mediciones. A continuación se describe una configuración común donde se tienen muchos usuarios en una red privada conectada a la Internet mediante un enrutador con una dirección IP pública que está haciendo traducción de direcciones de red (NAT). Extenderlo a varias direcciones IP públicas debería ser sencillo, añadiendo un par de reglas de iptables. Se muestra una descripción detallada, incluyendo el software necesario para capturar los datos y verificar los resultados del control de tráfico implementado. Dado que se hará control de trafico sobre la interfaz eth0 de BlackIaaS, se requiere tener en la red como herramienta de monitoreo a Wireshark que reportara la cantidad de trafico que pasa por dicha interfaz.


81

Wireshark se comporta como un Sniffer que procesa la información recogida de la interfaz eth0 en BlackIaaS. Wireshark analiza los paquetes IP que se cursan por la interfaz, identificando campos en dichos paquetes, tales como direcciones IP, y puertos tanto origen como destino, lo que le permite desplegar información tal como:

• Promedio de trafico entrante y saliente que se cursa por dirección IP. • Promedio de trafico entrante y saliente que se cursa por protocolo.

Los datos extraídos de Wireshark son procesados y graficados en Kaleida, y corresponden a datos resultados del análisis del tráfico que se cursa por la interfaz eth0. Básicamente en dichos gráficos se observa el resumen del trafico que pasa por dicha interfaz, discriminado por dirección IP, Wireshark analiza los paquetes de acuerdo a su dirección IP y los contabiliza, pudiendo dar una idea de la cantidad de trafico que se esta cursando en la red. 4.4.1. Cache transparente de web usando netfilter, iproute2, y Squid Esto se implemento usando Netfilter para marcar los paquetes con puerto de destino 80 e iproute2 para encaminar los paquetes marcados al servidor Squid. Primero, se hizo pasar todo el tráfico a través de BlackBox, se aseguro de que fuera la pasarela por defecto excepto para BlackProxy. La pasarela por defecto de BlackProxy se asigno estáticamente y es BlackIaaS (10.127.127.254), si no se configurara así se crearía un bucle de tráfico. 4.4.1.1. Configuración de BlackProxy Se configuro el Servidor Squid, y se aseguro el soporte al cache transparente; el puerto por defecto suele ser 3218, de manera que se tiene que redirigir localmente todo el tráfico hacia el puerto 80 al puerto 3128. Para ello se edito el fichero del servidor correspondiente en la ruta /etc/iptables.conf en la sección de nateo: -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128


82

Se aseguro de que el servidor tiene activo el renvío de ip (forwarding) y de que su puerta de enlace por defecto sea BlackIaaS. 4.4.1.2. Configuración de BlackBox. Se marcaron con el valor 2 los paquetes con destino al puerto 80: -A PREROUTING -i eth0 -p tcp --dport 80 -j MARK --set-mark 2

Se configuro iproute2 para que envíe los paquetes con la marca 2 a BlackProxy. Para ello se sigue el siguiente procedimiento: cmgomez@BlackBox:$ sudo su # echo 202 www.out >> /etc/iproute2/rt_tables

Se activa el bit de ejecución al archivo /etc/rc.local # chmod ugo+rwx /etc/rc.local

Se agregan las siguientes líneas incluyendo las líneas send_redirects # nano /etc/rc.local ip rule add fwmark 2 table www.out ip route add default via 10.127.127.253 dev eth0 table www.out ip route flush cache

Si BlackIaaS y BlackBox están en la misma subred entonces BlackBox no debería enviar mensajes icmp REDIRECT. En este caso, se desactivaron los mensajes icmp REDIRECT como sigue: echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects

4.4.1.3. Diagrama de flujo del tráfico tras la implementación. Se debe de tomar en cuenta que la red es asimétrica ya que hay un salto extra en la ruta general de salida. A continuación se muestra el camino seguido por los paquetes que atraviesan la red desde BlackSar hacia y desde Internet.

• Consulta web/http (http://www) Tráfico de BlackSar-> BlackBox-> BlackProxy-> BlackIaaS-> Internet

respuestas http desde Internet-> BlackIaaS-> BlackProxy-> BlackSar • Consultas no web/http (ej.: telnet) Datos salientes de BlackSar-> BlackBox-> BlackIaaS-> Internet datos

entrantes de Internet-> BlackIaaS-> BlackSar


83

FIGURA 4.3 Diagrama de flujo del tráfico

4.4.2. Caracterización del tráfico a controlar. Con el fin de establecer un punto de referencia, se realizo un análisis de la red propuesta, en donde se monitoreo el comportamiento de la misma al generar tráfico sobre la red sin tener ninguna tarea de control de tráfico ejecutándose. Dicho análisis permite establecer:

• Capacidad de la red para las aplicaciones y servicios implementados. • Comparación de la utilización de la red de los diversos servicios. • Comparación de la utilización de la red de las maquinas cliente.

Para esto se utilizo un archivo residente en nuestros servidores. Por medio de tres protocolos diferentes se hizo el monitoreo hacia los clientes remotos. Los protocolos usados fueron: HTTP, FTP y SSH.


84

El procedimiento usado consistió en observar el comportamiento de la red en los siguientes casos:

• Un cliente a la vez haciendo uso de cada protocolo. • Los dos clientes haciendo uso a la vez de un protocolo. • Un cliente a la vez haciendo uso de los tres protocolos.

4.4.2.1. Cliente Remoto 1. En las figuras 4.4, 4.5 y 4.6 se puede apreciar el comportamiento del tráfico cuando este cliente hace uso de un solo protocolo en la red. Se observa que optimiza el uso de ancho de banda disponible, independiente del protocolo usado, el tráfico alcanzo valores alrededor de 624kbit/s.

FIGURA 4.4. Caracterización tráfico debido al Cliente Remoto 1. Protocolo FTP.


85

FIGURA 4.5. Caracterización tráfico debido al Cliente Remoto 1. Protocolo HTTP.

FIGURA 4.6. Caracterización tráfico debido al Cliente Remoto 1. Protocolo SSH.


86

Después del análisis de la red sin ningún tipo de control de tráfico, se puede concluir que la capacidad máxima observada para los tres protocolos fue en HTTP a una tasa 636kbit/s, y que se presentan diferencias en la distribución por protocolos. 4.4.3. Control de tráfico. En esta sección se presenta y describe el código empleado para realizar el control del ancho de banda basado en el protocolo empleado por cada host de servicio, en este caso se utilizan los protocolos HTTP, SSH y FTP, definiéndose un porcentaje para cada uno según el ancho de banda asignado a cada host, lo cual ocurre cuando el cliente esta haciendo uso de todos los protocolos a la vez. 4.4.3.1. Definición de Colas. Primero se necesita configurar algunas disciplinas de encolamiento en las que clasificara el tráfico. Se crea tal disciplina con el algoritmo de Token Bucket Jerárquico con “3” clases de prioridad ascendente. Entonces se tienen clases que siempre obtendrán la tasa establecida, pero se puede usar el ancho de banda que no necesitan las otras clases. Recordando que se asignará primero el exceso de ancho de banda a las clases con mayor prioridad. La conexión de la red de prueba es una conexión ADSL con 6Mb de descarga y 768kbit/s para la carga, utilizada típicamente por las PyMES. Se utilizaron 640kbit/s como tasa superior solo porque es lo más alto que se puede configurar antes de que la latencia aumente, esto debido a llenados de búfer en algún sitio entre la red de prueba y la máquina remota que accede a ella. Este parámetro deberá medirse de forma experimental, aumentándolo y haciéndolo bajar si se observa latencia entre máquinas cercanas. Para empezar con las pruebas, se edita el fichero ubicado en la ruta /etc/rc.local, al final de todas las líneas se agrega lo siguiente: tc qdisc add dev eth0 root handle 1: htb default 29

Con lo anterior se define la disciplina para el enlace de carga de tipo HTB. tc class add dev eth0 parent 1: classid 1:1 htb rate 640kbit ceil 640kbit


87

Ahora se creo la clase principal para la disciplina de encolamiento HTB, limitando el ancho de banda a 640kbps. Así es como se crea el cuello de botella en la interfaz de red. Con lo siguiente se asigna el recurso a cada nivel de servicio: Para el nivel 1 tc class add dev eth0 parent 1:1 classid 1:10 htb rate 256kbit ceil 640kbit prio 0

Para el nivel 2 tc class add dev eth0 parent 1:1 classid 1:11 htb rate 192kbit ceil 640kbit prio 1

Para el nivel 3 tc class add dev eth0 parent 1:1 classid 1:12 htb rate 192kbit ceil 640kbit prio 2

4.4.3.2. Definición de Clases

Aquí se definen las clases para cada nivel de servicio, todas ellas compartiendo 640kbps y asegurando solamente su ancho de banda correspondiente. A continuación se definen las bandas para cada nivel. Banda 1 para nivel 1 tc class add dev eth0 parent 1:10 classid 1:20 htb rate 128kbit ceil 640kbit

Esta es la clase de mayor prioridad. Los paquetes de esta clase tendrán el menor retraso y será la primera en cargar cuando exista congestión. Mediante esta clase se envían los paquetes que se benefician de una latencia baja, como el tráfico interactivo: ssh, OpenVPN, dns, y paquetes con la etiqueta SYN.

Banda 2 para nivel 1 tc class add dev eth0 parent 1:10 classid 1:21 htb rate 64kbit ceil 640kbit

En esta clase se acomoda el tráfico masivo. En la red de prueba se tiene tráfico de un servidor web local: puerto de origen 80.


En esta clase se acomoda el tráfico de la red de prueba que viene del procesamiento local del Servidor FTP hacia la Internet.


88


Aquí va el trafico de correo (SMTP, POP3)







A continuación se declararan las disciplinas de encolamiento para cada clase final. tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10 tc qdisc add dev eth0 parent 1:21 handle 21: sfq perturb 10 tc qdisc add dev eth0 parent 1:22 handle 22: sfq perturb 10 tc qdisc add dev eth0 parent 1:23 handle 23: sfq perturb 10 tc qdisc add dev eth0 parent 1:24 handle 24: sfq perturb 10 tc qdisc add dev eth0 parent 1:25 handle 25: sfq perturb 10 tc qdisc add dev eth0 parent 1:26 handle 26: sfq perturb 10 tc qdisc add dev eth0 parent 1:27 handle 27: sfq perturb 10 tc qdisc add dev eth0 parent 1:28 handle 28: sfq perturb 10 tc qdisc add dev eth0 parent 1:29 handle 29: sfq perturb 10

Con lo anterior se consigue crear un árbol jerarquizado por clases como se muestra en la figura 4.7.


89

FIGURA 4.7. Árbol de clases para HTB. 4.4.3.3. Definición de Filtros. Con lo anterior se ha creado la configuración de la disciplina de encolamiento pero no se ha realizado la clasificación de paquetes, de manera que todos los paquetes salientes están pasando por la clase 1:29. Ahora es necesario indicar que paquetes van dónde. Esta es la parte más importante. Ahora se establecen los filtros de manera que iptables clasifique los paquetes. Para ello se ejecutan las siguientes instrucciones: tc filter add dev eth0 parent 1:10 protocol ip handle 1 fw classid 1:20 tc filter add dev eth0 parent 1:10 protocol ip handle 2 fw classid 1:21 tc filter add dev eth0 parent 1:10 protocol ip handle 3 fw classid 1:22 tc filter add dev eth0 parent 1:10 protocol ip handle 4 fw classid 1:23 tc filter add dev eth0 parent 1:11 protocol ip handle 5 fw classid 1:24 tc filter add dev eth0 parent 1:11 protocol ip handle 6 fw classid 1:25 tc filter add dev eth0 parent 1:11 protocol ip handle 7 fw classid 1:26 tc filter add dev eth0 parent 1:12 protocol ip handle 8 fw classid 1:27 tc filter add dev eth0 parent 1:12 protocol ip handle 9 fw classid 1:28

Se acaba de indicar al núcleo de control de tráfico que los paquetes marcados con un valor específico de renvió (FWMARK handle x fw) sean manejados por la clase indicada (classid x:x). Lo siguiente que se vera es cómo marcar estos paquetes con iptables.

root 1:

class 1:1

1:10 1:11 1:12

1:20 1:21 1:22 1:23 1:24 1:25 1:26 1:27 1:28 1:29


90

La red privada de prueba es de clase A con dirección 10.127.127.0/24 y la IP pública es proporcionada por el ISP en la interfaz eth0. A manera de establecer los niveles de servicio por origen de ip se utiliza la notación CIDR (Classless Inter Domain Routing).

• El nivel 1 corresponde a la notación 10.127.127.224/27 y contiene el rango de direcciones ip desde la 10.127.127.224-10.127.127.255.

• El nivel 2 esta conformado por las notaciones 10.127.127.128/26 y 10.127.127.192/27, y contiene las direcciones 10.127.127.128-10.127.127.191, y 10.127.127.192-10.127.127.223 correspondientemente.

• El nivel 3 que corresponde a la notación 10.127.127.0/25 y contiene el rango de direcciones ip desde la 10.127.127.0-10.127.127.127.

En la figura 4.8 se muestra la trayectoria que los paquetes siguen en los filtros de iptables.

FIGURA 4.8. Diagrama de flujo sencillo para los filtros en iptables

Con la siguiente instrucción se comprueba que hay paquetes pasando por la clase terminal 1:29: tc -s class show dev eth0

Aquí se empieza a marcar los paquetes añadiendo reglas a la cadena PREROUTING, para ello se edita el fichero ubicado en la ruta /etc/iptables.conf (sección nateo): Nivel 1 Banda 1 -A PREROUTING –p tcp –s 10.127.127.224/27 -m dscp –dscp-class EF -j MARK --set-mark 0x1 -A PREROUTING –p tcp –s 10.127.127.224/27 -m dscp –dscp-class EF -j RETURN -A PREROUTING –p tcp –s 10.127.127.224/27 --sport 22 -j MARK --set-mark 0x1 -A PREROUTING –p tcp –s 10.127.127.224/27 --sport 22 –j RETURN


91

Banda 2 -A PREROUTING –p tcp –s 10.127.127.224/27 -m dscp –dscp-class AF++ -j MARK --set-mark 0x2 -A PREROUTING –p tcp –s 10.127.127.224/27 -m dscp –dscp-class AF++ -j RETURN -A PREROUTING –p tcp –s 10.127.127.224/27 --sport 80 -j MARK --set-mark 0x2 -A PREROUTING –p tcp –s 10.127.127.224/27 --sport 80 –j RETURN

Banda 3 -A PREROUTING –p tcp –s 10.127.127.224/27 -m dscp –dscp-class BE -j MARK --set-mark 0x3 -A PREROUTING –p tcp –s 10.127.127.224/27 -m dscp –dscp-class BE -j RETURN -A PREROUTING –p tcp –s 10.127.127.224/27 --sport 20 -j MARK --set-mark 0x3 -A PREROUTING –p tcp –s 10.127.127.224/27 --sport 20 –j RETURN -A PREROUTING –p tcp –s 10.127.127.224/27 --sport 21 -j MARK --set-mark 0x3 -A PREROUTING –p tcp –s 10.127.127.224/27 --sport 21 –j RETURN

Banda 4 -A PREROUTING -p icmp -j MARK --set-mark 0x4 -A PREROUTING -p icmp -j RETURN -A PREROUTING -p tcp --tcp-flags SYN,RST,ACK -j MARK --set-mark 0x4 -A PREROUTING -p tcp --tcp-flags SYN,RST,ACK -j RETURN

Nivel 2 Banda 1 -A PREROUTING –p tcp –s 10.127.127.192/27 -m dscp –dscp-class EF -j MARK --set-mark 0x5 -A PREROUTING –p tcp –s 10.127.127.192/27 -m dscp –dscp-class EF -j RETURN -A PREROUTING –p tcp –s 10.127.127.192/27 --sport 22 -j MARK --set-mark 0x5 -A PREROUTING –p tcp –s 10.127.127.192/27 --sport 22 –j RETURN -A PREROUTING –p tcp –s 10.127.127.128/26 -m dscp –dscp-class EF -j MARK --set-mark 0x5 -A PREROUTING –p tcp –s 10.127.127.128/26 -m dscp –dscp-class EF -j RETURN -A PREROUTING –p tcp –s 10.127.127.128/26 --sport 22 -j MARK --set-mark 0x5 -A PREROUTING –p tcp –s 10.127.127.128/26 --sport 22 –j RETURN

Banda 2 -A PREROUTING –p tcp –s 10.127.127.192/27 -m dscp –dscp-class AF++ -j MARK --set-mark 0x6 -A PREROUTING –p tcp –s 10.127.127.192/27 -m dscp –dscp-class AF++ -j RETURN -A PREROUTING –p tcp –s 10.127.127.192/27 --sport 80 -j MARK --set-mark 0x6 -A PREROUTING –p tcp –s 10.127.127.192/27 --sport 80 –j RETURN -A PREROUTING –p tcp –s 10.127.127.128/26 -m dscp –dscp-class AF++ -j MARK --set-mark 0x6 -A PREROUTING –p tcp –s 10.127.127.128/26 -m dscp –dscp-class AF++ -j RETURN -A PREROUTING –p tcp –s 10.127.127.128/26 --sport 80 -j MARK --set-mark 0x6 -A PREROUTING –p tcp –s 10.127.127.128/26 --sport 80 –j RETURN

Banda 3 -A PREROUTING –p tcp –s 10.127.127.192/27 -m dscp –dscp-class BE -j MARK --set-mark 0x7 -A PREROUTING –p tcp –s 10.127.127.192/27 -m dscp –dscp-class BE -j RETURN -A PREROUTING –p tcp –s 10.127.127.192/27 --sport 20 -j MARK --set-mark 0x7 -A PREROUTING –p tcp –s 10.127.127.192/27 --sport 20 –j RETURN -A PREROUTING –p tcp –s 10.127.127.192/27 --sport 21 -j MARK --set-mark 0x7 -A PREROUTING –p tcp –s 10.127.127.192/27 --sport 21 –j RETURN -A PREROUTING –p tcp –s 10.127.127.128/26 -m dscp –dscp-class BE -j MARK --set-mark 0x7 -A PREROUTING –p tcp –s 10.127.127.128/26 -m dscp –dscp-class BE -j RETURN -A PREROUTING –p tcp –s 10.127.127.128/26 --sport 20 -j MARK --set-mark 0x7


92

-A PREROUTING –p tcp –s 10.127.127.128/26 --sport 20 –j RETURN -A PREROUTING –p tcp –s 10.127.127.128/26 --sport 21 -j MARK --set-mark 0x7 -A PREROUTING –p tcp –s 10.127.127.128/26 --sport 21 –j RETURN

Nivel 3 Banda 1 -A PREROUTING –p tcp –s 10.127.127.0/25 -m dscp –dscp-class EF -j MARK --set-mark 0x8 -A PREROUTING –p tcp –s 10.127.127.0/25 -m dscp –dscp-class EF -j RETURN -A PREROUTING –p tcp –s 10.127.127.0/25 --sport 22 -j MARK --set-mark 0x8 -A PREROUTING –p tcp –s 10.127.127.0/25 --sport 22 –j RETURN

Banda 2 -A PREROUTING –p tcp –s 10.127.127.0/25 -m dscp –dscp-class AF++ -j MARK --set-mark 0x9 -A PREROUTING –p tcp –s 10.127.127.0/25 -m dscp –dscp-class AF++ -j RETURN -A PREROUTING –p tcp –s 10.127.127.0/25 --sport 80 -j MARK --set-mark 0x9 -A PREROUTING –p tcp –s 10.127.127.0/25 --sport 80 –j RETURN

Se hace la operación -j RETURN de manera que los paquetes no atraviesen todas las regla, de esta manera no se comprobarán otras reglas por debajo de RETURN.

CAPITULO V.

5. RESULTADOS, CONCLUSIONES Y TRABAJO A FUTURO.

5.1. Introducción. En el capitulo anterior se mostro el caso de estudio de la caracterización del tráfico para establecer referencias que permitan posteriormente verificar que efectivamente se realiza un control del tráfico en la red de prueba, cuando se implementa una disciplina de cola mediante IPROUTE/Netfilter. En capítulos anteriores se explico esta utilidad, se definió de manera general su sintaxis y se introdujeron los conceptos presentes en el tema de encolamiento, en el capitulo anterior se presento el código relacionado con las configuraciones definidas para controlar el trafico en la red de prueba, el control se basa en la disciplina de cola HTB, esta gestión se realiza teniendo en cuenta los parámetros definidos para emplear este tipo de disciplina de encolamiento, y consta de tres partes: la primera define la disciplina de cola raíz en este caso HTB, en la segunda se establecen las diferentes clases y finalmente se implementan los filtros.

CAPÍTULO V. RESULTADOS, CONCLUSIONES Y TRABAJO A FUTURO.

94

En la figura 5.1 se aprecia como se relacionan las diferentes clases en el proceso de control de ancho de banda por protocolos y permite entender de manera grafica como funciona el script planteado para dicho control, se debe tener en cuenta que a cada clase final existe un filtro asociado.

FIGURA 5.1. Representación Grafica del Script Para Control de Ancho de Banda a Nivel de

Protocolos.


95

5.2. Mediciones.

FIGURA 5.2. Curva de tendencia para el tráfico debido al Cliente Remoto 1.

Protocolo SSH con control de trafico y con un filtro de decimo grado.


96


Protocolo HTTP con control de trafico y con un filtro de decimo grado.


97


Protocolo FTP con control de trafico y con un filtro de decimo grado. Se puede apreciar en estas 3 graficas anteriores que se maximizo el flujo tal y como se propuso en uno de los objetivos de mejorar el desempeño de la red de prueba en las diferentes transmisiones para los protocolos HTTP, FTP, SHH. Esto se logro transfiriendo las colas de salida del enrutador del ISP a la arquitectura propuesta.


98

FIGURA 5.5. Control de trafico por hosts en nivel 1 y 2, usando el protocolo ssh.

La figura 5.5 permite apreciar el comportamiento del trafico desde los hosts 1 y 2, en donde al revisar el script para el control del ancho de banda, al hosts 1 se le asigna un ancho de banda de 128-256kbps, con un máximo posible de 640kbps, de igual manera al hosts 2 tiene un ancho de banda de 96-192kbps, con la posibilidad de llegar a 640kbps, para poder llegar a este máximo se requiere que no existan otros clientes en la red con los cuales se deba compartir el ancho de banda.


99

FIGURA 5.6. Distribución del tráfico global por protocolos de los Clientes 1 y 2


100

5.3. Conclusiones.

Los conceptos básicos de teoría de colas vistos en el capitulo 4, permiten tener una base para la comprensión de los mecanismos involucrados en los procesos de envió y recepción de datos en los dispositivos de una red de comunicaciones. La posibilidad que se tenga de administrar las colas en los diferentes dispositivos de una red, puede afectar el rendimiento de la misma, de manera que dicho rendimiento, no solo dependerá de factores como Hardware, Ancho de Banda disponible y cantidad de tráfico cursado, sino también de la correcta gestión de colas en la red. Las herramientas de código libre utilizadas permiten implementar tareas basadas en la gestión de colas. Dichas herramientas permiten definir clases, políticas y filtros que pueden usarse para convertir una maquina de gama media en un enrutador que podrá realizar tareas de control de tráfico, dignas de cualquier solución comercial, tales como:

• Posibilidad de manejar variedad de algoritmos de encolamiento. • Priorizar trafico. • Distribución equitativa de ancho de banda • Reserva de ancho de banda.

Mediante el montaje práctico realizado, a fin de verificar el desempeño de la arquitectura como dispositivo de control de tráfico, se realizaron las tareas antes mencionadas. Cada una de estas tareas se implemento utilizando la disciplina de colas HTB, lo cual permitió que dichas tareas se aplicaran a nivel de direcciones IP y protocolos (flujos). Los scripts presentados para control de tráfico pueden ser implementados tan flexiblemente como se quiera, por ejemplo se puede usar variables para facilitar el cambio de parámetros y automatizar su ejecución. Existen mas disciplinas de colas y otros tipos de filtros. Según la necesidad específica se podrán determinar cuales son los más adecuados para implementar. En el capitulo 4 se monto un Proxy transparente para la explotación del enlace de descarga y donde se configuro la priorización de paquetes a nivel de ip, se uso como auxiliar al servidor DHCP para la identificación de las direcciones MAC (control de acceso al medio).


101

El objetivo de esta tesis era implementar un enrutador con prestaciones para el de tráfico en una misma máquina, utilizando únicamente herramientas libres. Es asombroso ver la cantidad de soluciones que fueron integradas finalmente, gracias a esto se ha conseguido crear un producto con muchas posibilidades. La integración del hipervisor presenta grandes ventajas de escalabilidad y abstracción de prestaciones sin afectar un entorno productivo, al tratarse de un producto abierto cualquier administrador de red puede implementar esa función que tanto necesita para que el producto se ajuste a las necesidades de su entorno. A continuación se presentan las ventajas puntuales de la arquitectura que se propone:

• Cuando se emplea correctamente, la solución debe dirigir a un uso predecible de los recursos de la red y así reducir la volatilidad de los mismos. Es así como la red alcanza las metas propuestas de control de tráfico.

• Al tráfico de carga se le puede asignar un ancho de banda razonable aunque exista tráfico interactivo con alta prioridad simultáneamente requerido. Aun los datos de baja prioridad son transferidos, como el protocolo ftp donde en la red de prueba se le asigna un ancho de banda sin afectar gravemente a otras clases de tráfico.

El crecimiento desmesurado de las aplicaciones web rebasa por mucho el nivel de servicio ofrecido por los proveedores, así que muchas de las veces es menos costoso invertir en gestión, monitoreo de los recursos de la red y su tráfico, que adquirir mas ancho de banda.

5.3.1. Trabajo a Futuro. Este trabajo abre posibilidades de usarse como base para integrar escenarios de prueba de mayor complejidad como lo son balance de carga, administración web de servicios, clusters de información, bases de datos y maquinas virtuales distribuidas.


102

La complejidad es quizás la desventaja mas grande que tiene la arquitectura en cuestión de trafico, es que no hay formula que prediga los usuarios concurrentes, o la disponibilidad del acceso a internet, existen varios escenarios los cuales no se pueden controlar, ya que se trata de una configuración estática, esta se debe monitorear y estar en continuo cambio según los requerimientos de los usuarios y aplicaciones en la red. No es difícil familiarizarse con las herramientas para el control de trafico, aprender su lenguaje y algoritmos es sencillo, pero identificar una mala configuración llega a ser muy difícil, por ello se necesitan herramientas de monitoreo especificas para cada escenario. La solución cuando es usada correctamente, conlleva a la distribución equitativa u optima de los recursos de red; contrario al caso cuando está es implementada incorrectamente lo cual desemboca en un desaprovechamiento total de los recursos de la red. Para que esto no ocurra se podría desarrollar un lenguaje integral que intérprete comandos y de forma automática traduzca estas instrucciones correctamente. Los recursos de cómputo requeridos por un enrutador que soporte control de tráfico son exigentes, necesita ser capaz de manejar el incremento del costo de mantener las estructuras de control de tráfico funcionales. Afortunadamente este incremento es pequeño, pero puede llegar a ser significativo cuando la configuración de la red crezca en complejidad y tamaño. Para uso personal, no hay costo de entrenamiento asociado al uso de las herramientas, pero en una Pyme podría ser que un Dir. Administrativo sin visión encuentre mas barato comprar mas ancho de banda que capacitar a su gente del Depto. de Sistemas, de ahí que es imprescindible que se concientice a la gente.

R E F E R E N C I A S B I B L I O G R Á F I C A S .

[1] David Durham and Raj Yavatkar.: Inside the Internet’s Resource Reservation Protocol: Foundations for Quality of Service. Wiley, 1999. 384 p. ISBN 0-471-32214-8. [2] Richard Petersen.: DHCP Server - Ubuntu 11.10 Server: Administration and Reference eBook. Surfing Turtle Press, 2011. 574 p. [3] Manual para la configuración de Quagga <http://www.nongnu.org/quagga/docs/quagga.pdf> [consulta: 23 mayo 2012] [4] OpenVPN Technologies, Inc. Manual para la configuración de OpenVPN [en línea] <http://openvpn.net/index.php/open-source/documentation/howto.html> [consulta: 23 mayo 2012] [5] Oracle Corporation. Manual para la configuración de VirtualBox <http://download.virtualbox.org/virtualbox/UserManual.pdf> [consulta: 23 mayo 2012] [6] Internet Systems Consortium. Manual para la configuración de BIND <https://deepthought.isc.org/article/AA-00499/0/BIND-9.8.1-Administrator-Reference-Manual.html> [consulta: 23 mayo 2012] [7] The Netfilter webmaster. Filtrado de Paquetes <http://netfilter.org/documentation/HOWTO/es/packet-filtering-HOWTO.a4.ps> [consulta: 23 mayo 2012] [8] The Netfilter webmaster. Traducción de direcciones de red (NAT) <http://netfilter.org/documentation/HOWTO/es/NAT-HOWTO.a4.ps> [consulta: 23 mayo 2012] [9] Manual para la configuración de Iptables <http://www.frozentux.net/iptables-tutorial/spanish/iptables-tutorial.ps.gz> [consulta: 23 mayo 2012] [10] Configuración de ejemplo de Hostapd <http://hostap.epitest.fi/gitweb/gitweb.cgi?p=hostap.git;a=blob_plain;f=hostapd/hostapd.conf> [consulta: 23 mayo 2012]

104

[11] Manual para la configuración de SQUID <http://tuxjm.net/docs/Manual_de_Instalacion_de_Servidor_Proxy_Web_con_Ubuntu_Server_y_Squid/html-onechunk/> [consulta: 23 mayo 2012] [12] Wireshark Foundation. Manual para la configuración y uso de Wireshark <http://www.wireshark.org/download/docs/user-guide-a4.pdf> [consulta: 23 mayo 2012] [13] Manual practico para el control de tráfico en Linux con iproute-tc <http://www.gulic.org/almacen/lartc/lartc.pdf> [consulta: 23 mayo 2012], <http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html> [consulta: 23 mayo 2012] [14] Network RADIUS Inc. Manual para la configuración de Freeradius. [en línea] <http://freeradius.org/doc/> [consulta: 23 mayo 2012] [15] Frank Denis Open Project. Manual para la configuración de Pureftpd. [en línea] <http://www.pureftpd.org/project/pure-ftpd/doc> [consulta: 23 mayo 2012] [16] Frank Denis Open Project. Manual para la configuración de Pureftpd con usuarios virtuales. [en línea] <http://download.pureftpd.org/pub/pure-ftpd/doc/README.Virtual-Users> [consulta: 23 mayo 2012] [17] The Apache Software Foundation. Manual para la configuración de Apache. [en línea] <http://httpd.apache.org/docs/2.4/install.html> [consulta: 23 mayo 2012] [18] Oracle Corporation. Manual de MySQL. [en línea] <http://dev.mysql.com/doc/refman/5.6/en/> [consulta: 23 mayo 2012] [19] Manual de phpmyadmin [en línea] <http://www.phpmyadmin.net/localized_docs/es/Documentation.html> [consulta: 23 mayo 2012] [20] Microsoft Virtual Academy. “La Nube Privada” [en línea] <http://www.microsoftvirtualacademy.com/tracks/nube-privada> [consulta: 23 mayo 2012] [21] Villy B. Iversen: Teletrafic Engineering and Network Planning. Technical University of Denmark. http://www.fotonik.dtu.dk. 2011. 583 p. <http://oldwww.com.dtu.dk/education/34340/telenook.pdf> [consulta: 23 mayo 2012]

ANEXO A.

Articulo: Virtualización de dispositivos de Capa 3 y 4 utilizando Linux. Vigesimosegunda reunión internacional de otoño de comunicaciones, computación, electrónica, automatización, robótica y exposición industrial ROC&C’2011, celebrada del 29 de noviembre al 3 de diciembre del 2011 en Acapulco, Gro.

Virtualización de dispositivos de Capa 3 y 4 utilizando Linux

Carlos Mauricio Gómez Sandoval1, M. en C. Chadwick Carreto Arellano

2, Salvador Álvarez

Ballesteros3.

1,2,3 Instituto Politécnico Nacional. Escuela Superior de Ingeniería Mecánica y Eléctrica,

Zacatenco. Sección de Estudios de Posgrado e Investigación. Departamento de

Telecomunicaciones. [email protected],

[email protected],

[email protected]

Resumen

Los diferentes desarrollos aislados dentro de Linux

en realidad son envolturas realmente delgadas

alrededor de la poderosa infraestructura que puede

llegar a ser al integrarse. Linux ofrece una perspectiva

muy atractiva en cuestión de aprovechamiento de

recursos en cualquier ámbito; en este articulo

pretendemos informar brevemente de las diferentes

herramientas que están a la mano para implementar

una arquitectura que provee las prestaciones de

dispositivos de capa enlace, red, transporte y mas.

Además se muestra parte de la evolución de los

dispositivos de red, de ser entidades separadas a

soluciones totalmente integradas, haciendo por último

una comparativa de una solución comercial que

provee estas funcionalidades y una que se construye

con los diferentes demonios disponibles dentro la

comunidad de software libre.

1. Introducción

A finales del siglo pasado cada fabricante de

dispositivos de red quería su pedazo del pastel y con

eso cada quien perfeccionaba su dispositivo según lo

mejor sabían hacer, como quien dice zapatero a sus

zapatos. Es así que nos encontrábamos con un

escenario parcialmente integrado ya que se basaban en

estándares para lograr su interoperabilidad. En paralelo

algunos de estos fabricantes pensaban ya en

soluciones integrales que ofrecieran gran parte de las

funcionalidades ofrecidas en esos tiempos; no era raro

que nos encontráramos con un rack lleno de estos

dispositivos: servidores que proporcionaban funciones

de DHCP, DNS, Servidor WEB, Servidor FTP, otro

hacia la función de Firewall, un dispositivo Proxy, un

Servidor de correo y aplicaciones de monitoreo,

enrutadores, conmutadores y uno para proveer

servicios de VPN; en resumen teníamos soluciones

aisladas pero integradas.

Fig. 1. Soluciones anteriores vs desarrollos actuales

Actualmente las cosas han cambiado y los fabricantes

pretenden, si no cubrir todo el panorama, la mayoría

de las características desarrollando soluciones

integrales. A continuación en la Tabla I se muestran las

características presentadas por la solución Citrix

Netscaler ADC que actualmente se considera líder en

este mercado, y también se listan los demonios dentro

de Linux que cubren estas funciones.

Como todo lo bueno cuesta y bastante. Estas

soluciones presentan varios esquemas, uno por ejemplo

el cual consiste en equipos complejos y de mayor

capacidad, dependiendo de los usuarios concurrentes,

que asegura la disponibilidad de los servicios. Otro que

consiste en desarrollos modulares.

Estas soluciones comerciales son adquiridas por

grandes entidades, sea en el ámbito empresarial,

educacional o gubernamental, ya que poseen grandes

recursos y tienen un presupuesto dedicado a su

infraestructura de comunicaciones. Muchas de las

pequeñas y medianas empresas con estas mismas

necesidades en vez de invertir en su propia

infraestructura prefieren carecer de ella, optando por

rentar servicios de hosting y clouding. Linux y los

desarrollos que se dan alrededor de él son capaces de

proveer de tales herramientas a dichas entidades.

RROOCC&&CC’’22001111 –– CCPP--6655 PONENCIA RECOMENDADA

POR EL CCOOMMIITTÉÉ DDEE CCOOMMPPUUTTAACCIIÓÓNN DEL

IIEEEEEE SSEECCCCIIÓÓNN MMÉÉXXIICCOO Y PRESENTADA EN LA

RREEUUNNIIÓÓNN DDEE OOTTOOÑÑOO,, RROOCC&&CC’’22001111, ACAPULCO, GRO.,

DEL 27 DE NOVIEMBRE AL 3 DE DICIEMBRE DEL 2011.

CP-65

PON 113

Tabla I. Funciones disponibles dentro de Linux

Característica Demonio

Utilizado

AAA (Accounting, Authentication,

Authorization)

FreeRADIUS

TCP buffering HTB

SMNP (Simple Network

Management Protocol)

Net-SMNP

Servidor FTP PureFTPd

Funcionalidad de enrutador Iproute2

Servidor de Base de Datos MySQL

Servidor de Correo SMTP/POP3

WebMail

Postfix,

Courier,

Squirremail

Monitor de Red / Sniffer Wireshark

Funcionalidad de Punto de Acceso HostAPD

Servidor WEB Apache2

Algoritmos de encolamiento para

gestión de trafico de aplicaciones

HTB

(Hierarchy

Token

Bucket)

DHCP DHCP3

server

Balance de Carga en capa 4 Squid

Protocolos de ruteo dinámico QUAGGA

Asesor de contenidos “Proxy” Squid

Firewall, NAT y Balance de Carga Netfilter

(iptables)

DNS BIND

SSL/TLS VPN OpenVPN

2. Presentación del escenario.

Supongamos una red común en el ámbito de las

PyMES donde tenemos usuarios locales y remotos de

los servicios de la red. Los usuarios locales acceden a

los servicios WEB, FTP, SMTP/POP3, Servidor de

Bases de Datos dispuestos para diferentes aplicaciones

y aparte gozan de los servicios DHCP, DNS, Proxy,

Firewall, AP inalámbrico [5], y de servicios intrínsecos

de la red como Ruteo dinámico, conmutación [1], NAT

[7], Balance de Carga, ARP, etc. Los usuarios remotos

comparten algunos de los servicios presentados

localmente y adicionalmente servicios como SSL/TLS

VPN. La figura 2 muestra el escenario descrito.

Fig. 2 Escenario con oficina central y sucursal.

Todos los servicios anteriormente mencionados son

propios de dispositivos de capa 3, 4 y superiores, y

están disponibles dentro del abrigo de Linux. Estos

servicios deben ser gestionados, es decir jerarquizados,

ya que cada uno tiene peso diferente dentro del

desempeño de la red. De manera general tenemos 2

vías: la local y su acceso al internet donde disponemos

del ancho de banda en el enlace descendente (E.D), y

la remota con acceso a la infraestructura principal

disponiendo del enlace ascendente (E.A) de la

conexión a Internet de la red.

Para asegurar que ambos tipos de usuarios gocen de

estos servicios, Linux dispone de diferentes

herramientas, una de ellas es SQUID [3], que asigna un

ancho de banda para los usuarios locales mediante las

llamadas delay pools. Los usuarios locales son

identificados por su IP, que es proporcionada por un

DHCP [8] que asigna IP’s reservadas. Inmediatamente

SQUID identifica el tráfico y de acuerdo a las políticas

de administrador se asigna el ancho de banda requerido

y permitido, reservando así recursos del E.D. Para los

servicios desarrollados a nivel de aplicación que

dispone de recursos de E.A. se implementa HTB [2] el

cual es un desarrollo para control de tráfico. La figura

3 presenta las funciones de control de tráfico básicas.

Esta misma herramienta permite dar prioridad al

servicio de SSL/TLS VPN [9] para los usuarios

remotos.

Para terminar se dispone de DSMARK [6], una

instrucción dentro de IPROUTE2 [7] que marca los

paquetes que salen hacia la Internet para que

dispositivos con capacidades de Servicios

Diferenciados, que se encuentran a lo largo de la ruta

de destino, le den el trato correspondiente según su

DSCP (Differentiated Services CodePoint).

Fig. 3 Funciones de control de trafico.

Agradecimientos. Los autores agradecen a

CONACYT y al Instituto Politécnico Nacional, en

particular a la ESIME y ESCOM el apoyo para la

realización de este trabajo.

Referencias

[1] lartc.org: Linux Advanced Routing & Traffic

Control.

[2] http://luxik.cdi.cz/~devik/qos/htb/: Hierarchy

Token Bucket.

[3] http://www.squid-cache.org/: Delay Pools.

[4] David Durham, Raj Yavatkar, Inside the Internet's

resource reSerVation protocol: foundations for quality

of service, John Wiley, 1999.

[5] http://hostap.epitest.fi/hostapd/ : IEEE 802.11 AP,

IEEE 802.1X / WPA / WPA2 / EAP / RADIUS

Authenticator

[6] http://opalsoft.net/qos/DS-29.htm: DSMARK

queuing discipline.

[7] http://www.policyrouting.org/iproute2.doc.html:

IPROUTE2 How to.

[7] http://www.netfilter.org/: iptables.

[8] https://help.ubuntu.com/community/dhcp3-server:

Reservas de direcciones según MAC.

[9] http:// openvpn.net/ index.php/ open-source/

documentation/ howto.html: SSL/TLS VPN

Biografía técnica:

Carlos Mauricio Gómez Sandoval Ingeniero en Sistemas por parte de la

Universidad del Valle de México

(UVM), en San Luis Potosí, México.

Actualmente es estudiante de la

Maestría en Ciencias en Ingeniería de

Telecomunicaciones, en el Instituto

Politécnico Nacional. Sus áreas de

interés son las comunicaciones inalámbricas, redes

celulares, redes de datos, así como la seguridad en

redes.

Chadwick Carreto Arellano

Profesor – Investigador de la Sección de Estudio de

Posgrado e Investigación en la Escuela Superior de

Cómputo (ESCOM) y del Centro de Investigación en

Computación (CIC) del Instituto Politécnico Nacional.

Candidato a Doctor en Ciencias Computacionales y

Maestro en Ciencias Computacionales (2004) por parte

del CIC del IPN e Ingeniero en Sistemas

Computacionales por parte del Instituto Tecnológico

de Estudios Superiores de Morelia (ITM) (1998).

http://luxik.cdi.cz/~devik/qos/htb/

http://www.squid-cache.org/

http://www.google.com/search?hl=es&tbo=p&tbm=bks&q=inauthor:%22David+Durham%22

http://www.google.com/search?hl=es&tbo=p&tbm=bks&q=inauthor:%22Raj+Yavatkar%22

http://opalsoft.net/qos/DS-29.htm

http://www.policyrouting.org/iproute2.doc.html

http://www.netfilter.org/

B-1

ANEXO B.

1. IMPLEMENTACIÓN DE LA SOLUCIÓN. 1.1. Plataforma de Desarrollo. Para hacer reproducible la implementación de la arquitectura y a modo de presentar la estructura interna de la misma, se presenta como, paso a paso se integran los diferentes demonios mencionados en el capitulo 3, y damos una breve explicación de cómo participan en la red de prueba presentada en el capitulo 4. Utilizamos la distribución de Linux Ubuntu de 64 bits, por el soporte que ofrece canonical, la versión utilizada fue 11.10, actualmente la documentación es escasa ya que es la última versión, pero nos basamos en configuraciones probadas y de altas prestaciones de versiones anteriores, para cada demonio implementado utilizamos la documentación que ofrecen los desarrolladores propietarios. Esta versión de Linux utiliza el kernel 3, el cual integra los demonios casi a la perfección. A manera de retroalimentación probamos con otras distribuciones de Linux y otras versiones de Ubuntu, hubo dificultades para integrarlos correctamente ya que cada combinación de Distribución y versión arrancaba los servicios con diferente orden y se tenía que reiniciar unos servicios para que funcionara correctamente. A modo informativo, durante la instalación de Ubuntu 11.10 de 64 bits usamos la versión de escritorio, esto debido a que se necesitaba monitorear el trafico de la red con Wireshark, y el entorno grafico es mas atractivo para trabajarlo, esto lo menciono por que no recomiendo usar el entorno grafico ya que este utiliza mas recursos y el monitoreo se puede hacer desde otra estación de trabajo, la configuración optima será trabajarlo con la versión de servidor y así no entorpecer el funcionamiento. El hardware donde se emulo la arquitectura consta de lo siguiente y a mayores recursos mejor rendimiento, mayores capacidades de procesamiento, y soporte a más usuarios concurrentes. • Intel Core i7 2600k • 8GB RAM DDR3 16000Mhz • 2 Tarjetas de Red Gigabit Ethernet • 1 Tarjeta de Red Inalámbrica con soporte 802.1x • Disco duro 250GB + 1TB • Unidad de DVD, solo para instalación después no se necesita.

B-2

A continuación muestro una cronología para la implementación de la arquitectura en el anfitrión y maquinas virtuales hospedadas por este. Instalaciones BlackIaaS BlackProxy BlackBox BlackLamp Ubuntu Desktop 11.10 x VirtualBox x Ubuntu Server 11.10 x x x Apache x Openssl x x x x Mysql-server x Mysql-client x x x Phpmyadmin x Openssh-server x x x x Bridge-utils x Hostapd x Quagga x Openvpn x Bind x Isc dhcp server x Pure-ftpd x Squid x

Cronología de Implementación. En los siguientes puntos presento las líneas de código que utilice para la instalación de los diferentes servicios prestados por la arquitectura. 1.2. Servicios de soporte para la estructura principal. Empecemos por instalar algunas dependencias, como utilizamos Ubuntu y restringe algunas instrucciones a uso exclusivo de súper usuario, usaremos sudo (súper-user-do). Necesitamos un editor de texto para editor el código de los diferentes archivos de configuración, un descompresor y un compilador para hacer que los servicios se ejecuten al arrancar, esto ultimo solo para ciertos desarrollos fuera del alcance de soporte de Ubuntu. Abrimos una terminal y utilizamos los siguientes comandos. sudo apt-get install gedit unzip chkconfig En vez de utilizar “gedit” podemos utilizar “nano” que es un editor de texto para línea de comando, en caso de haber realizado la instalación sin entorno grafico (recomendado). Continuando con la implementación, empezaremos instalando la Pila LAMP, en la cual varios demonios interactúan; aclaramos durante la implementación van a ir cambiando parámetros en los archivos de configuración de Apache y MySQL, estos archivos y demás archivos de configuración solo describimos el código adicionado o modificado.

B-3

Instalamos nuestro servidor web y OpenSSL el cual nos da soporte a SSL (Secure Sockets Layer) y TLS (Transport Layer Security) para proveer un acceso seguro a nuestra comunicación y crear certificados para la comunicación confidencial. sudo apt-get install apache2 openssl ssl-cert Para almacenar nuestras bases de datos utilizadas por nuestras diferentes herramientas por ejemplo el demonio de Freeradius, escogimos MySQL, ampliamente conocido y con un soporte basto. Usamos los esquemas servidor y cliente para acceder a otras bases de datos para dar soporte a sistemas distribuidos o panoramas de redundancia. sudo apt-get install mysql-server mysql-client mysql-common Al terminar la instalación, el servidor de base de datos nos pide ingresar la contraseña para el usuario root de MySQL en este caso utilizamos “BlackLampMySql”. Modificamos la línea bind-address = 10.127.127.251 en el fichero /etc/mysql/my.cnf, que corresponde a la dirección ip del servidor BlackLamp que hospeda MySQL, así los clientes remotos tendrán acceso a recurso. Algunas de las aplicaciones/demonios utilizados utilizan el lenguaje de programación de entorno Web PHP y ahora es buen momento de instalarlo junto con sus demás dependencias y librerías de desarrollo para tecleamos en la consola: sudo apt-get install php5 libapache2-mod-php5 php5-cli php5-mysql Para administrar las bases de datos de manera sencilla y remota recomendamos utilizar phpmyadmin, la cual usa una interfaz vía web, para esto tecleamos en la terminal: sudo apt-get install phpmyadmin Al terminar nos pedirá que servidor web utilizamos seleccionamos apache2 con barra espaciadora y aceptamos, seleccionamos dbconfig-common para instalar la base de datos phpmyadmin y tecleamos la contraseña del usuario root de MySQL para tener control sobre las demás bases de datos que emplearemos mas adelante. Adicionalmente nos pide una contraseña para la aplicación, en nuestro caso utilizamos la misma para poder recordarla fácilmente. Ahora para poder acceder remotamente al servidor que alberga nuestros servicios vía línea de comando instalare un demonio que funge como protocolo a nivel de aplicación para una comunicación segura de datos llamado en Linux OpenSSH. Se instalaran las librerías correspondientes a SSH (secure shell): sudo apt-get install openssh-server libssh2-*

B-4

Lo siguiente seria activar los servicios de apache server al arranque de Linux, y arrancarlos por primera vez junto con los demás demonios. Para hacerlo tecleamos en una terminal sudo chkconfig apache2 on Antes de arrancar el servicio vamos a editar nuestro archivo de configuración /etc/apache2/httpd.conf, agregando la línea ServerName localhost, para esto tecleamos en la terminal sudo gedit /etc/apache2/httpd.conf y agregamos la línea, después guardamos el archivo y cerramos para continuar con el arranque de nuestro demonio apache2. sudo service apache2 restart 1.3. Servicios de virtualización de dispositivos de capa 3 (Modo Gateway, Enrutador, NAS, Punto Acceso Inalámbrico, Servidor VPN). Teniendo lo base empezaremos a configurar el equipo a modo que funcione como, Gateway, enrutador, punto de acceso inalámbrico y servidor de acceso a la red para su interacción con Radius. 1.3.1. Reenvío de Paquetes. Para activar el reenvío de paquetes entre nuestras diferentes interfaces tenemos que editar el fichero sysctl.conf, y eliminamos el comentario la línea net.ipv4.ip_forward=1, para hacerlo tecleamos en la terminal sudo gedit /etc/sysctl.conf Y hacemos la modificación anteriormente mencionada. Por condición a nuestra configuración eth0 va conectado nuestra WAN (Internet), se puede identificar ejecutando el comando ifconfig y checar la dirección MAC para ver si le pertenece a la NIC Gigabit-Ethernet incluida en la tarjeta madre, o la NIC Gigabit-Ethernet adicional.

B-5

1.3.2. Ruta por Default y Nateo. Configurar iptables nos permitirá enviar todo el tráfico no perteneciente a nuestra LAN (10.127.127.0/24) a nuestra interfaz conectada a nuestra WAN (Internet). Debemos configurar también la encapsulación de estos paquetes para que se traten posteriormente por un enrutador o enrutadores correspondientes para ello configuramos las reglas NAT (Network Address Translation). Para ello tecleamos en una terminal sudo gedit /etc/iptables.conf Agregamos las líneas *filter -A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j LOG --log-prefix "NEW_HTTP_CONN:” -A FORWARD -s 10.127.127.0/24 -o eth0 -j ACCEPT -A FORWARD -d 10.127.127.0/24 -m state --state ESTABLISHED,RELATED -i eth0 -j ACCEPT COMMIT *nat -A POSTROUTING -s 10.127.127.0/24 -o eth0 -j MASQUERADE COMMIT Y guardamos. 1.3.3. Inicialización de Interfaces. Para evitar conflictos con el administrador de red incluido en Ubuntu, lo desinstalaremos, para ello tecleamos en la terminal sudo apt-get remove network-manager Para cargar estas reglas al arranque de las interfaces de red editamos el fichero /etc/network/interfaces, tecleamos en terminal sudo gedit /etc/network/interfaces Agregamos las líneas auto lo iface lo inet loopback #Inicialización de interface WAN auto eth0 iface eth0 inet dhcp pre-up iptables-restore </etc/iptables.conf

B-6

Ahora es cuando definimos nuestra interfaz puenteada la cual consta de una interfaz alámbrica y una inalámbrica como se describió en el capitulo anterior, para hacer este puenteo necesitamos una utilidad llamada bridge-utils, que se instala de la siguiente manera, en una terminal tecleamos sudo apt-get install bridge-utils Como convención eth1 y wlan0 se van a puentear y trabajaran como enlace a nuestra LAN (Intranet). Para inicializar la interfaz en modo puente modificaremos el fichero /etc/network/interfaces sudo gedit /etc/network/interfaces Agregaremos estas líneas al final del fichero #Inicialización de interfaces que pertenecen al puente auto eth1 iface eth1 inet static address 0.0.0.0 auto wlan0 iface wlan0 inet static address 0.0.0.0 #Inicialización de nuestro puente auto br0 iface br0 inet static bridge_ports eth1 address 10.127.127.254 netmask 255.255.255.0 1.3.4. Inicialización de Punto de acceso inalámbrico. Después de que inicializamos nuestras interfaces, notaremos que solamente agregamos eth1 al puente, la tarea de agregar wlan0 al puente se la dejaremos al demonio hostapd, para instalarlo tecleamos en la terminal sudo apt-get install hostapd Para configurarlo tenemos que editar la línea DAEMON_CONF = para indicarle donde esta nuestro archivo de configuración para ello tecleamos en la terminal sudo gedit /etc/init.d/hostapd Editamos la línea para que quede como sigue DAEMON_CONF = /etc/hostapd/hostapd.conf

B-7

Guardamos y salimos y editamos el fichero antes mencionado, para ello tecleamos en terminal sudo gedit /etc/hostapd/hostapd.conf Introducimos el siguiente código: #Nombre de la Interfaz a Utilizar para el Broadcasting inalámbrico interface=wlan0 #Nombre del puente al que pertenece bridge=br0 #Driver que soporta la tarjeta de red inalámbrica driver=nl80211 #Opciones de Broadcasting ssid=sepi-posgrado-e #Modo de Hardware 802.11g hw_mode=g #Canal preferente channel=8 #Opciones de configuración según la capacidad de tu NIC #Para ver las capacidades de tu Tarjeta usamos iw list wmm_enabled=1 ieee80211n=1 ht_capab=[HT40-][SHORT-GI-40][DSSS_CCK-40][MAX-AMSDU-7935] #Filtrado de direcciones MAC 0 acepta a todos menos #a los que están en la lista hostapd.deny macaddr_acl=0 accept_mac_file=/etc/hostapd/hostapd.accept deny_mac_file=/etc/hostapd/hostapd.deny #Usar autenticación 802.1X auth_algs=1 ieee8021x=1 # WEP rekeying # Longitudes para la llave default/broadcast y llave individual/unicast: # 5 = 40-bit WEP (conocido también como 64-bit WEP con 40 bits encriptados) # 13 = 104-bit WEP (conocido también como 128-bit WEP con 104 bits encriptados) wep_key_len_broadcast=13 wep_key_len_unicast=13 # Periodo para el rekeying en segundos wep_rekey_period=300 # Configuración de NAS para Radius # Dirección IP del Punto de Acceso usado como NAS own_ip_addr=10.127.127.254 # Identificador único del punto de acceso NAS

B-8

nas_identifier=ap.sepi-posgrado.com # Configuración del Servidor de Autenticación RADIUS auth_server_addr=10.127.127.252 auth_server_port=1812 auth_server_shared_secret=BlackBoxHostApd # Configuración del Servidor para el Manejo de Cuentas RADIUS acct_server_addr=10.127.127.252 acct_server_port=1813 acct_server_shared_secret=BlackBoxHostApd Guardamos y cerramos. Para inicializar los servicios al arranque tecleamos en la terminal sudo chkconfig hostapd on Ahora inicializamos nuestros ficheros para el filtrado de direcciones MAC, tecleamos en la terminal sudo touch /etc/hostapd/hostapd.deny sudo touch /etc/hostapd/hostapd.accept Arrancamos el demonio para nuestro AP-NAS sudo service hostapd start Estos ficheros nos serán utiles cuando detectemos un usuario no grato y basta con agregar su dirección MAC separada por guiones. Arrancamos el demonio para nuestro AP-NAS sudo service hostapd start Para ver las capacidades adicionales de la tarjeta de red inalámbrica y activarlas necesitamos instalar la herramienta iw, para ello tecleamos en la terminal. sudo apt-get install iw Las líneas de configuración para activar nuestro NAS están incluidas y mas adelante serán utilizadas dentro de la configuración de Freeradius.1 1 Nota: las líneas que comienzan con # son comentarios, y no participan en la configuración, estas líneas se

agregaron a modo explicativo.

B-9

1.3.5. Configuración de Ruteo Dinámico. Para terminar de configurar el equipo en sus diferentes modos adicionaremos el soporte de enrutador dinámico con la suite Quagga, para ello tecleamos en una terminal sudo apt-get install Quagga Situando la red de prueba en un ambiente de menos de 100 enrutadores se recomienda implementar OSPFv2 por su rápida convergencia y RIPv2 para redes pequeñas y dejar a los ISPs la implementación de BGPv4 en el backbone. Para el caso de estudio solo se implementaran los demonios RIP y OSPF. Para activar los demonios modificaremos el fichero daemons como sigue, tecleamos en una terminal sudo gedit /etc/Quagga/daemons Y modificamos las líneas zebra = yes ospfd = yes ripd =yes Todos los anteriores funcionando sobre la versión 4 del protocolo de internet; haciendo observación que Quagga esta listo con los protocolos de ruteo dinámico para ipv6 pero no serán implementados en la arquitectura ya que no tendría caso. Los archivos de configuración de ejemplo están localizados en /usr/share/doc/Quagga/examples/, a continuación copiaremos los archivos para zebra rip ospf vtysh contenidos en la carpeta, los demás demonios no aplican para la red de prueba, para ello tecleamos en la terminal sudo cp /usr/share/doc/Quagga/examples/zebra.conf.sample /etc/Quagga/zebra.conf sudo cp /usr/share/doc/Quagga/examples/ospfd.conf.sample /etc/Quagga/ospfd.conf sudo cp /usr/share/doc/Quagga/examples/ripd.conf.sample /etc/Quagga/ripd.conf sudo cp /usr/share/doc/Quagga/examples/vtysh.conf.sample /etc/Quagga/vtysh.conf Todos los demonios trabajan independientemente y si el hardware tiene multi-threading para hilos de procesamiento en paralelo los demonios serán ejecutados en diferentes hilos. Los puertos utilizados por default de cada demonio se encuentran descritos en el fichero /etc/services, esto es importante saberlo ya que por medio del telnet podremos acceder a su interfaz de terminal o vty (virtual teletype) y tenemos que permitir el acceso en el firewall, se presentan como sigue: zebrasrv 2600/tcp zebra 2601/tcp ripd 2602/tcp ospfd 2604/tcp

B-10

Se pueden configurar los diferentes protocolos de ruteo dinámico en un solo equipo, todos estos demonios compartirán sus tablas de ruteo con el demonio principal zebra y es este el que decide que rutas conformaran la tabla productiva de ruteo. Si se quiere afectar directamente la tabla de ruteo para dar de alta una ruta por default o estática se tendrá que hacer directamente a zebra. Lo que sigue es dar los permisos a los usuarios y grupos como se muestra a continuación, tecleamos en una terminal sudo usermod –a –G quaggavty cmgomez Así agregamos al usuario cmgomez para que pueda interactuar con la línea vty y configurar remotamente al enrutador. Ahora los permisos de los ficheros de configuración, para ello tecleamos en una terminal sudo chown quagga:quagga /etc/Quagga/zebra.conf sudo chown quagga:quagga /etc/Quagga/ospfd.conf sudo chown quagga:quagga /etc/Quagga/ripd.conf sudo chgrp quaggavty /etc/Quagga/vtysh.conf De modo que los ficheros tengan los permisos adecuados, tecleamos en la terminal sudo chmod u=rw, g=r, o= /etc/Quagga/zebra.conf sudo chmod u=rw, g=r, o= /etc/Quagga/ospfd.conf sudo chmod u=rw, g=r, o= /etc/Quagga/ripd.conf sudo chmod ug=rw, o= /etc/Quagga/vtysh.conf De modo que cuando utilicemos nuestro virtual teletype secure shell y este haga las modificaciones directamente al demonio que corresponda y no utilice un archivo adicional modificamos el fichero de configuración, para ello tecleamos en la terminal sudo gedit /etc/Quagga/vtysh.conf Comentamos la línea como sigue ! service integrated-vtysh-config Ahora empezaremos por la configuración inicial del demonio principal zebra, para ello tecleamos en la terminal sudo gedit /etc/Quagga/zebra.conf Agregamos o modificamos las siguientes líneas de comando ! hostname BBoxZebra password BlackBoxZebra enable password BlackBoxRouter service password-encryption service advanced-vty !

B-11

interface br0 description Enlace a LAN-WLAN link-detect ipv6 nd suppress-ra ! interface eth0 description Enlace a WAN link-detect ipv6 nd suppress-ra ! interface eth1 ipv6 nd suppress-ra ! interface lo description Local Loopback link-detect ! interface mon.wlan0 ipv6 nd suppress-ra ! interface wlan0 ipv6 nd suppress-ra ! ip forwarding ! ! line vty ! Ahora el demonio para el protocolo Rip, para ello tecleamos en la terminal sudo gedit /etc/Quagga/ripd.conf Agregamos o modificamos las siguientes líneas de comando ! hostname BBoxRip password 8 otY2sXmkPh0jA enable password 8 S8aefM4DFA7J6 log stdout service advanced-vty service password-encryption ! key chain BlackBox key 1 key-string BlackBoxMD5

B-12

! interface br0 ip rip authentication mode md5 auth-length old-ripd ip rip authentication key-chain BlackBox ! interface eth0 ip rip authentication mode md5 auth-length old-ripd ip rip authentication key-chain BlackBox ! router rip version 2 redistribute kernel redistribute connected redistribute static redistribute ospf network 10.127.127.0/24 network eth0 distribute-list publica in br0 distribute-list privada in eth0 ! access-list privada permit 148.204.56.0/22 access-list privada deny any access-list publica permit 10.127.127.0/24 access-list publica deny any ! line vty ! Como observaremos las direcciones de red son acorde a la red de prueba, mas adelante se describirá en el próximo capitulo. 1.3.6. Inicialización de Servidor de Red Privada Virtual Para los servicios soportados por la nube, y la integración con los escritorios remotos virtuales necesitamos crear los túneles para que nuestros usuarios localizados fuera de nuestra red local tengan acceso a través de internet de nuestra infraestructura (IaaS), para ello utilizamos el demonio de OpenVPN el cual proporciona tales prestaciones. Para su instalación tecleamos en la línea de comandos lo siguiente: sudo apt-get install openvpn

B-13

Para proteger nuestro canal de comunicación utilizamos Certificados y Llaves privadas (X509 Public Key Infrastruction). Utilizamos la configuración por defecto y nuestro servidor VPN trabajara en modo enrutador. Para reforzar la seguridad vamos a utilizar una llave pública, una llave privada para el servidor, llaves privadas para cada cliente, un certificado maestro de autoridad (CA), y una llave para firmar los certificados del servidor y clientes (dh). Para la creación de certificados tecleamos en la línea de comando lo siguiente: cp –R /usr/share/doc/openvpn/examples/easy-rsa /etc/openvpn chmod ug=rwx /etc/openvpn/easy-rsa cd /etc/openvpn/easy-rsa/2.0/ Inicializamos nuestra llave pública (PKI) . ./vars ./clean-all ./build-ca Creamos nuestra llave y certificado del servidor ./build-key-server BlackIaaS A continuación llenamos los datos según corresponda y cuando nos solicite llenar el campo de “Common Name” nos aseguramos de usar el mismo nombre de la llave. Ahora creamos los certificados de los clientes ./build-key remoto1 ./build-key remoto2 ./build-key remoto3 Al igual que el servidor el nombre de la llave debe corresponder al campo de nombre común. Ahora generaremos la llave que con los parámetros Diffie Hellman, para ello tecleamos en la línea de comandos: ./build-dh

B-14

La ubicación de los certificados y llaves quedo en la ruta /etc/openvpn/easy-rsa/2.0/keys, las llaves y certificados deben ser distribuidos como se indica en la siguiente tabla:

Nombre Archivo

Usado por Propósito Secreto

ca.crt servidor + todos los clientes Certificado raíz CA NO ca.key La maquina que firma los

certificados (servidor) Llave raíz CA SI

dh{n}.pem Únicamente el servidor Parámetros Diffie Hellman NO BlackBox.crt Únicamente el servidor Certificado del servidor NO BlackBox.key Únicamente el servidor Llave del servidor SI remoto1.crt La primer maquina remota

únicamente Certificado del cliente remoto NO

remoto1.key La primer maquina remota únicamente

Llave del cliente remoto SI

remoto2.crt La segunda maquina remota únicamente

Certificado del cliente remoto NO

remoto2.key La segunda maquina remota únicamente


remoto3.crt La tercer maquina remota únicamente

Certificado del cliente remoto NO

remoto3.key La tercer maquina remota únicamente


Propósitos de las llaves y certificados usados por Openvpn. Como punto de partida utilizaremos los archivos de configuración ejemplo, su ubicación en Linux es /usr/share/doc/openvpn/examples/sample-config-files/, para el servidor utilizamos el fichero server.conf.gz, y para los clientes el fichero client.conf.gz, estas ubicaciones varían en instalaciones de Windows “nuestros principales clientes”, para configurar los clientes en Windows lo hacemos desde el menú inicio -> Todos los programas -> OpenVPN -> Archivos de configuración de ejemplo de OpenVPN. El archivo de configuración de los clientes en Windows se guarda con la extensión .ovpn, y es en la misma ubicación de este archivo que se colocan los certificados y llaves de los clientes. Para el servidor, tecleamos en la línea de comandos lo siguiente: cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn cd /etc/openvpn gunzip server.conf.gz En el archivo de configuración debemos de indicar los certificados y laves usados para ello modificamos como sigue: sudo nano /etc/openvpn/server.conf

B-15

Editamos las líneas correspondientes ca ca.crt dh dh1024.pem cert BlackIaaS.crt key BlackIaaS.key La configuración por defecto que utilizamos necesita que se habilite el renvío de paquetes dentro del túnel, para ello editamos nuestro fichero iptables.conf y agregamos las siguientes líneas como se muestra a continuación: sudo nano /etc/iptables.conf Insertamos las líneas en el área de filtros –A INPUT –i tun+ -j ACCEPT –A FORWARD –i tun+ -j ACCEPT Por aquello que el usuario llegara a compartir sus llaves y certificados, de manera adicional y mejorando la autenticación, agregamos un plugin de Radius. Para su instalación y configuración tecleamos en la línea de comandos lo siguiente: sudo apt-get install openvpn-auth-radius cp /usr/lib/openvpn/radiusplugin.so /etc/openvpn/ cp /usr/share/doc/openvpn-auth-radius/examples/radiusplugin.cnf /etc/openvpn/ Para activar el plugin necesitamos agregar unas líneas al fichero de configuración de openvpn del servidor para ello tecleamos en la línea de comando lo siguiente: sudo nano /etc/openvpn/server.conf Al final del script agregamos: plugin /etc/openvpn/radiusplugin.so /etc/openvpn/radiusplugin.cnf Editamos el fichero de configuración en la línea de comandos como sigue: sudo nano /etc/openvpn/radiusplugin.cnf

B-16

De acuerdo a nuestra red de prueba editamos los siguientes datos: NAS-Identifier=OpenVpn Service-Type=5 Framed-Protocol=1 NAS-Port-Type=5 NAS-IP-Address=127.0.0.1 OpenVPNConfig=/etc/openvpn/server.conf overwriteccfiles=true server { acctport=1813 authport=1812 name=10.127.127.252 retry=1 wait=1 sharedsecret=BlackBoxOpenVpn } Antes de arrancar el servidor VPN debemos de copiar los certificados y llaves correspondientes para ello tecleamos en la línea de comandos lo siguiente: cp /etc/openvpn/easy-rsa/2.0/keys/ca.crt /etc/openvpn/ cp /etc/openvpn/easy-rsa/2.0/keys/BlackIaaS.crt /etc/openvpn/ cp /etc/openvpn/easy-rsa/2.0/keys/BlackIaaS.key /etc/openvpn/ cp /etc/openvpn/easy-rsa/2.0/keys/ca.key /etc/openvpn/ cp /etc/openvpn/easy-rsa/2.0/keys/dh1024.pem /etc/openvpn/ Y arrancamos el servidor en la línea de comandos tecleamos lo siguiente: sudo /etc/init.d/openvpn start Ahora por parte de los clientes, los cuales pueden tener diferentes sistemas operativos, encontramos que los archivos de configuración se encuentran en diferentes rutas pero contienen las mismas líneas de código. Las únicas líneas que se tienen que modificar en el fichero client.ovpn ó client.conf son las siguientes: remote “Nuestra IP Publica” 1194 ca ca.crt key remoto?.key cert remoto?.crt

B-17

Para clientes Ubuntu la instalación es como sigue: sudo apt-get install openvpn cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf.gz /etc/openvpn cd /etc/openvpn gunzip client.conf.gz En la ruta /etc/openvpn se deben de ubicar las llaves y certificados correspondientes. Para Clientes de Windows y Mac OSX, debemos descargar los instaladores desde las rutas que se muestras a continuación: http://tunnelblick.googlecode.com/files/Tunnelblick_3.2.3.dmg http://swupdate.openvpn.org/community/releases/openvpn-2.2.2-install.exe Los archivos ejemplo en Windows se encuentran en la ruta Archivos de Programa-> OpenVPN->sample-config->client.ovpn y para que entre en el entorno productivo se debe de ubicar en la ruta Archivos de Programa-> OpenVPN->config->client.ovpn, es en esta ultima ruta donde se ubican también las llaves y certificados. En el entorno de Mac OSX, la interfaz grafica del programa Tunnelblick te guía paso a paso. 1.4. Servicios de Provisión de Recursos de Red (DNS, DHCP, RADIUS). A continuación se presentan los servicios que proporcionaran a la red el reparto de recursos para que mas adelante teniéndolos identificados, poder gestionarlos. 1.4.1. Servidor DNS. Ahora instalaremos nuestro servidor dns BIND, para ello tecleamos en la terminal sudo apt-get install bind9 Para editar el archivo de configuración empezamos por editar el fichero named.conf.local para ello tecleamos en la terminal sudo gedit /etc/bind/named.conf.local

B-18

Agregamos o modificamos las líneas como sigue include "/etc/bind/zones.rfc1918"; // Aquí definimos las Zonas. En mi caso mi dominio se llama sepi-posgrado.com zone "sepi-posgrado.com" { type master; file "/etc/bind/zones/sepi-posgrado.com.db"; }; // Aquí definimos las zonas de búsqueda inversa. En nuestro caso la red 10.127.127 zone "127.127.10.in-addr.arpa" { type master; notify no; file "/etc/bind/zones/rev.127.127.10.in-addr.arpa"; }; Ahora editamos las opciones de nuestro servidor DNS para ello tecleamos en la terminal sudo gedit /etc/bind/named.conf.options

Aquí agregamos servidores adicionales, los cuales procesaran las peticiones que el servidor no pueda atender, utilizaremos los servidores públicos DNS de Google, las líneas son las siguientes forwarders { 8.8.8.8; 8.8.4.4; }; Ahora editaremos la resolución de direcciones de búsqueda directa, para ello tecleamos en una terminal cd /etc/bind sudo mkdir zones sudo gedit /etc/bind/zones/sepi-posgrado.com.db

B-19

Agregamos o modificamos las líneas para que quede como sigue $TTL 604800 @ IN SOA BlackBox.sepi-posgrado.com. cmgomez.sepi-posgrado.com. ( 201111241; Serial 604800; Refresh 86400; Retry 2419200; Expire 604800); Negative Cache TTL ; @ IN NS BlackBox.sepi-posgrado.com. BlackSar IN A 10.127.127.250 BlackLamp IN A 10.127.127.251 BlackBox IN A 10.127.127.252 BlackProxy IN A 10.127.127.253 BlackIaaS IN A 10.127.127.254 Ahora editaremos la resolución de direcciones para búsqueda inversa, para ello tecleamos en la terminal sudo gedit /etc/bind/zones/rev.127.127.10.in-addr.arpa Agregamos o modificamos las líneas para que quede como sigue $TTL 604800 @ IN SOA BlackBox.sepi-posgrado.com. cmgomez.sepi-posgrado.com. ( 201111242; Serial 604800; Refresh 86400; Retry 2419200; Expire 604800); Negative Cache TTL ; @ IN NS BlackBox.sepi-posgrado.com. 250 IN PTR BlackSar.sepi-posgrado.com. 251 IN PTR BlackLamp.sepi-posgrado.com. 252 IN PTR BlackBox.sepi-posgrado.com. 253 IN PTR BlackProxy.sepi-posgrado.com. 254 IN PTR BlackIaaS.sepi-posgrado.com. En nuestra red de prueba tenemos en una interfaz DHCP como cliente, para que la resolución de nombres sea correcta y tengamos como servidor DNS el nuestro, y se mantenga estático debemos hacer unas modificaciones. La primera de ellas es crear nuestro fichero imagen, para ello tecleamos en una terminal sudo nano /etc/resolv.conf.ok

B-20

Agregamos las siguientes líneas domain sepi-posgrado.com search sepi-posgrado.com nameserver 127.0.0.1 Ahora para actualizar nuestra información, tecleamos en nuestra terminal sudo cp –R /etc/resolv.conf.ok /etc/resolv.conf Y a continuación para que cada vez que se quiera actualizar el fichero sea a nuestro gusto debemos modificar la función make_resolv_conf() dentro del fichero /sbin/dhclient-script, para ello tecleamos en la terminal sudo gedit /sbin/dhclient-script Y suplantamos el código entre corchetes de la función por el siguiente { rm -f /etc/resolv.conf if [ -n "/etc/resolv.conf.nuevo" ]; then cat /etc/resolv.conf.nuevo > /etc/resolv.conf else if [ -n "$new_domain_name" ]; then echo search $new_domain_name > /etc/resolv.conf fi if [ -n "$new_domain_name_servers" ]; then for nameserver in $new_domain_name_servers; do echo nameserver $nameserver >> /etc/resolv.conf done fi fi [[ -x /sbin/update-resolvrdv ]] && /sbin/update-resolvrdv } 1.4.2. Servidor RADIUS. Lo que sigue es darle funcionalidad de servidor RADIUS (Remote Authentication Dial-In User Server), para comodidad y gestión del servidor montaremos todo en MySQL para eso instalamos los siguientes paquetes sudo apt-get install freeradius freeradius-mysql libdate-manip-perl Ahora vamos a crear la base de datos para el soporte con MySQL y a dar los permisos correspondientes, para ello tecleamos en la terminal mysql –uroot –p

B-21

Tecleamos la contraseña de root para mysql, estando en la consola de mysql tecleamos la siguiente sentencia CREATE DATABASE radius; GRANT ALL ON radius.* TO ‘radius’@’localhost’ IDENTIFIED BY “BlackBoxFreeRadius”; exit Creamos el esquema por default, para ello tecleamos en la terminal cd /etc/freeradius/sql/mysql/ sudo su Tecleamos la contraseña del súper-usuario local “cmgomez”, y continuamos mysql –uroot –p radius < schema.sql Tecleamos la contraseña del usuario root de MySQL mysql –uroot –p radius < nas.sql Tecleamos la contraseña del usuario root de MySQL mysql –uroot –p radius < cui.sql exit A continuación haremos unas ligeras modificaciones a los ficheros para integrar las funcionalidades escogidas. Para ello tecleamos lo siguiente sudo gedit /etc/freeradius/radiusd.conf Quitamos el comentario a las líneas $INCLUDE sql.conf $INCLUDE sql/mysql/counter.conf Y comentamos las líneas siguientes #$INCLUDE proxy.conf #$INCLUDE clients.conf Modificamos la siguiente línea como se muestra proxy_requests = no En el fichero sql.conf editaremos las líneas para poder acceder a la base de datos antes construida con los parámetros que configuramos anteriormente, para ello tecleamos en una terminal sudo gedit /etc/freeradius/sql.conf

B-22

Modificamos las siguientes líneas server = “BlackLamp” password = “BlackBoxFreeRadius” Quitamos el comentario a las líneas read_groups = yes readclients = yes Guardamos y cerramos. A continuación modificaremos el fichero para dar soporte al protocolo de autenticación (eap), para ello tecleamos en la terminal sudo gedit /etc/freeradius/eap.conf En la sección eap modificamos la siguiente línea default_eap_type = peap En las secciones ttls y peap comentamos la línea #virtual_server = “inner-tunnel” En el fichero /etc/freeradius/sites-available/default eliminamos el comentario las líneas para la gestión sobre “sql”, en las secciones authorize, session, accounting, post-auth, Post-Auth-Type. Comentaremos la línea “digest” en las secciones authorize y authenticate. También necesitamos comentar la línea “files” en la sección authorize. Comentamos la línea “radutmp” en las secciones de accounting y session. Y por ultimo comentamos la línea “unix” en las secciones authenticate y accounting. Tenemos que modificar algunos módulos los cuales están ubicados en la carpeta /etc/freeradius/modules, para ello tecleamos en la terminal sudo gedit /etc/freeradius/modules/xxx Para el modulo “pap” editamos la siguiente línea para que quede como sigue auto_header = yes Para el modulo “preprocess” editamos la siguiente línea para que quede como sigue with_ntdomain_hack=yes Para el modulo “exec” editamos la siguiente línea para que quede como sigue wait = yes Para el modulo “mschap” editamos las siguientes líneas para que quede como sigue authtype = MS-CHAP use_mppe = yes require_encryption = yes require_strong = yes with_ntdomain_hack = yes

B-23

Para hacer un link a los certificados entramos a la carpeta cd /etc/freeradius/certs y tecleamos en el terminal el comando sudo c_rehash. 1.4.3. Servidor DHCP Para agregar soporte de Servidor DHCP a la arquitectura en una terminal, escribimos el siguiente comando y así instalaremos el demonio dhcpd: sudo apt-get install isc-dhcp-server Comúnmente se desea asignar direcciones IP dinámicamente, para ello editamos el fichero dhcpd.conf ubicado en la ruta /etc/dhcp/, en la línea de comando escribimos lo siguiente: sudo nano /etc/dhcp/dhcpd.conf y editamos las siguientes líneas acorde a nuestra red de prueba. # Definiciones para todas las redes... default-lease-time 600; max-lease-time 7200; authoritative; # Declaracion basica de la subred. subnet 10.127.127.0 netmask 255.255.255.0 { range 10.127.127.1 10.127.127.120; option domain-name "sepi-posgrado.com"; option domain-name-servers 10.127.127.252; option routers 10.127.127.252; } También necesitamos asignar recursos estáticos a nuestros servidores virtuales, para ello necesitamos saber las Mac de las tarjetas de red virtuales, esta información la obtenemos ya sea tecleando en la línea de comandos de la maquina virtual la instrucción ifconfig, o desde la consola de administración de VirtualBox seleccionando la VM correspondiente y editando su configuración de red. Los recursos estáticos se especifican en el fichero anterior agregando el siguiente código: # Declaracion de IP estaticas host BlackPaaS { hardware ethernet 00:11:22:33:44:55; fixed-address BlackPaaS.sepi-posgrado.com; } host BlackSaaS { hardware ethernet 55:44:33:22:11:00; fixed-address BlackSaaS.sepi-posgrado.com; }

B-24

Adicionalmente tenemos que habilitar la interfaz por la cual el servidor DHCP prestara el servicio para ello desde la línea de comando escribimos sudo nano /etc/default/isc-dhcp-server Editamos la siguiente línea con la interfaz correspondiente INTERFACES=”eth0” Para ver el log de las direcciones ip asignadas, escribimos en la línea de comandos lo siguiente sudo nano /var/lib/dhcp/dhcpd.leases 1.5. Servicios de Infraestructura de la Arquitectura (FTP, Hypervisor, Proxy). A continuación se presentan los servicios que interactúan con los usuarios y proporcionan el acceso remoto virtual de sus recursos reservados. 1.5.1. Servidor FTP Vamos a continuar instalando un servidor FTP para ello tecleamos en la línea de comandos lo siguiente: sudo apt-get install pure-ftpd pureadmin Agregamos un grupo de usuarios para ftp, y un tipo de usuario para el grupo sudo groupadd ftpgroup sudo useradd –g ftpgroup –d /dev/null –s /etc ftpuser Los usuarios locales tendrán acceso a su perfil desde el servicio ftp, ahora no todos los usuarios tendrán cuentas locales, sin embargo podrán gozar del servicio ya que a estos usuarios se les creara una cuenta virtual, para ello crearemos una carpeta donde se hospedaran sus archivos: sudo mkdir /home/ftpusers Y para un usuario en específico: sudo mkdir /home/ftpusers/johndoe

B-25

Se tendrá que crear una carpeta personal por usuario, y asignarlo a su carpeta, para ello tecleamos en la línea de comandos lo siguiente: sudo pure-pw useradd johndoe –u ftpuser –d /home/ftpusers/johndoe A continuación tecleamos la contraseña y repetimos para confirmar, también se necesita agregar a la base de datos y crear enlaces simbólicos, para ello tecleamos en la línea de comandos: sudo pure-pw mkdb sudo ln –s /etc/pure-ftpd/pureftpd.passwd /etc/pureftpd.passwd sudo ln –s /etc/pure-ftpd/pureftpd.pdb /etc/pureftpd.pdb sudo ln –s /etc/pure-ftpd/conf/PureDB /etc/pure-ftpd/auth/PureDB Creamos el archivo para los logs de pureftpd, y cambiamos el propietario y grupo al directorio de usuarios virtuales, para ello tecleamos en la línea de comandos: sudo touch /var/log/messages sudo chown –R ftpuser:ftpgroup /home/ftpusers Para administrar pureftp vía interfaz grafica utilizamos pureadmin, para cargarlo tecleamos lo siguiente en la línea de comandos: gksudo pureadmin 1.5.2. Hipervisor Para la instalación del hipervisor de VirtualBox y sus prerrequisitos necesitamos agregar primero algunos repositorios a las fuentes para ello utilizamos las siguientes líneas de comando: sudo nano /etc/apt/sources.list Agregamos la siguiente ruta: deb http://download.virtualbox.org/virtualbox/debian oneiric contrib Guardamos y salimos, a continuación descargamos la llave y la registramos wget -q http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc sudo apt-key add oracle_vbox.asc sudo apt-get update sudo apt-get install dkms sudo apt-get install virtualbox-4.1 Agregamos a nuestro usuario principal “cmgomez” al grupo de administradores de maquinas virtuales, para ello tecleamos en la línea de comandos: sudo usermod –a –G vboxusers cmgomez

B-26

Cerramos y abrimos sesión para que se apliquen los cambios, para que las maquinas virtuales tengan una comunicación directa con el hipervisor se necesitan las herramientas de integración, para instalarlas tecleamos en la línea de comandos lo siguiente: cd /etc/vbox sudo wget http://dlc.sun.com.edgesuite.net/virtualbox/4.1.8/Oracle_VM_VirtualBox_Extension_Pack-4.1.8-75467.vbox-extpack sudo VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-4.1.8-75467.vbox-extpack A manera de ejemplo presento a continuación un script para levantar una maquina virtual vía línea de comandos, la cual es la forma que utilice para no demandar recursos de computo en la interfaz grafica. Creamos y registramos la maquina virtual sudo VBoxManage createvm –name “Windows XP” --ostype WindowsXP --register Asignamos memoria, activamos la administración de energía avanzada, declaramos la unidad de arranque y agregamos su interfaz de red sudo VBoxManage modifyvm “Windows Xp” --memory 256 --acpi on --boot1 dvd --nic1 nat Para crear el disco duro virtual y asignar su tamaño de unidad en MB sudo VBoxManage createhd --filename “Windows XP.vdi” --size 10000 Agregar el controlador de disco duro sudo VBoxManage storagectl “Windows XP” --name “Controlador IDE” --add ide –controller PIIX4 Asignar el disco duro creado a la maquina virtual y unidad de disco óptico sudo VBoxManage storageattach “Windows XP” --storagectl “Controlador IDE” --port 0 –device 0 --type hdd --medium “Windows XP.vdi” sudo VBoxManage storageattach “Windows XP” --storagectl “Controlador IDE” --port 0 –device 1 --type dvddrive --medium /media/PORTATIL/Windows_XP_SP3.iso Esta última ruta corresponde a la ubicación de la imagen ISO del disco de instalación del sistema operativo, para continuar con la instalación remotamente desde un escritorio remoto tecleamos en la línea de comandos sudo VBoxManage modifyvm “Windows XP” –vrdeport 5010-5012 sudo VBoxHeadless --startvm “Windows XP”

B-27

O también sudo VBoxManage startvm “Windows XP” –type headless A continuación maestro algunos comandos útiles: VBoxManage list vms -> muestra las maquinas virtuales disponibles. VBoxManage list runningvms -> muestra las maquinas virtuales activas VBoxManage controlvm “Windows XP” poweroff -> apaga la maquina virtual con el nombre de Windows XP VBoxManage showvminfo “Windows XP” -> muestra la información de la maquina virtual, dispositivos de red, discos duros, memoria asignada, etc. VBoxManage clonehd “Windows XP” “Windows XP2” --format VDI --variant Fixed -> copia el disco duro de la maquina virtual Windows XP a la VM de Windows XP2 de formato de tamaño fijo. Esto anterior es muy práctico para hacer plantillas de discos duros para su uso posterior en la restauración de información o creación de una nueva maquina virtual. 1.5.3. Servidor Proxy. Squid no solo hará la función de servidor Proxy, además de eso controlara el ancho de banda de bajada, para instalarlo tecleamos en la línea de comandos lo siguiente: sudo apt-get install squid Para su configuración inicial y en adelante que se van ir incorporando líneas de configuración utilizamos lo siguiente: sudo nano /etc/squid/squid.conf A continuación creamos las reglas de acceso y permitimos nuestra red interna, para ello ya sea que modifiquemos o agregamos las siguientes líneas: http_port 3128 transparent acl localhost src 127.0.0.1/32 acl localnet src 10.127.127.0/24 http_access allow localhost http_access allow localnet http_access deny all Para crear una lista de URL bloqueadas tecleamos lo siguiente en la línea de comandos: sudo touch /etc/squid/block_list.txt sudo chmod 444 /etc/squid/block_list.txt sudo nano /etc/squid/block_list.txt

B-28

y agregamos los sitios bloqueados, por ejemplo www.youtube.com. Ahora agregamos la siguiente regla de acceso en el archivo de configuración: acl block-list url_regex “/etc/squid/block_list.txt” http_access deny block_list Como ejemplo podemos bloquear sitios que tengan una cadena de caracteres en específico o descargas de extensiones de archivo, para ello acl palabraxxx url_regex sxx acl bloqueo_mp3 url_regex .*\.mp3$ y a continuación denegaríamos el acceso por ejemplo http_access deny bloqueo_mp3 Para agregar una capa mas de acceso al recurso, podemos activar la autenticación en el Proxy, para ello tecleamos en la línea de comandos lo siguiente: htpasswd –c /etc/squid/squid_passwd cmgomez A continuación tecleamos la contraseña del usuario y cambiamos los permisos al fichero de contraseñas correspondiente. chmod o+r /etc/squid/squid-passwd y en el archivo de configuración creamos las reglas auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squid_passwd acl ncsa_user proxy_auth REQUIRED http_access allow ncsa_user 1.6. Servicios de Gestión (delay pools y tc). A manera de controlar el trafico en el enlace de bajada utilizaremos Squid y sus llamadas delay pools. Dentro de las versiones de Linux posteriores al kernel 2.2 tienen integrado en su núcleo las herramientas iproute2 que integran tc (Traffic-Control) y es con el que administraremos nuestro enlace de subida.

B-29

1.6.1. Control enlace de descarga (squid-delay pools, solo puerto 80). El procedimiento para asignar ancho de banda de descarga consta de asignar las ip que solicitan el recurso a cierto nivel, posteriormente crear niveles de clasificación, y finalmente permitirles el acceso. En la red de prueba utilizamos 3 clasificaciones y asignamos un rango de direcciones ip a cada nivel. Para ello editamos el archivo de configuración y agregamos las siguientes líneas: acl nivel1 src 10.127.127.225-10.127.127.254/24 acl nivel2 src 10.127.127.193-10.127.127.222/24 acl nivel2 src 10.127.127.129-10.127.127.190/24 acl nivel3 src 10.127.127.1-10.127.127.126/24 delay_pools 3 delay_class 1 2 delay_class 2 2 delay_class 3 2 delay_access 1 allow nivel1 delay_access 1 deny all delay_access 2 allow nivel2 delay_access 2 deny all delay_access 3 allow nivel3 delay_access 3 deny all Nuestros usuarios del nivel1 corresponden al rango donde situaremos a nuestros servidores y equipos de uso critico, en el nivel2 a los equipos de los usuarios identificados que consideremos de mayor prioridad dentro nuestra empresa, y en el nivel 3 todos los demás. Como se vio en capítulos anteriores esta asignación será por medio del servidor DHCP usando asignaciones dinámicas y fijas. Utilizamos el tipo “2” para nuestras delay pools ya que solo estamos usando una subred, si se quisiera utilizar mas subredes utilizaríamos el tipo “3” y se tendrían que agregar ciertos parámetros. La gestión de trafico es critica y necesaria en horas pico donde encontramos congestión, fuera de este horario no es tan necesario controlar el recurso. Supongamos un ancho de banda disponible para la descarga hasta 6Mbps según nuestro ISP, haciendo mediciones y auditando en horas pico obtenemos que realmente tengamos 3.6Mbps disponibles, debido a esto ajustaremos nuestra configuración a este último parámetro. Los parámetros deben ser introducidos en unidades bytes/seg, de ahí obtenemos que 3,600,000 bps equivalen a 450,000 bytes/seg. Usando la siguiente formula:

Ancho de Banda(bytes/seg)= 1,000,000

8 Ancho de Banda(Mbps)

B-30

Este ancho de banda de bajada se distribuirá entre nuestras 3 clasificaciones, para cada nivel asignaremos una tercera parte, haciendo la observación que cada nivel tiene asignado un numero diferente de usuarios o equipos posibles y es de este numero que se hará la obtención de privilegio o discriminación según corresponda. Para el nivel1 tenemos un ancho de banda instantáneo disponible de 450,000 bytes/seg y solo tenemos 150,000 bytes/seg promedio disponibles, para 30 usuarios o equipos tenemos una cache de 150,000 bytes/seg y si todos son concurrentes tenemos 5000 bytes/seg aproximadamente por usuario. Haciendo como observación que el ancho de banda será distribuido por los usuarios que soliciten el recurso concurrentemente, si hay 8 se ajustara la tasa. Los parámetros quedan como sigue: delay_parameters 1 150000/450000 5000/150000 De igual forma para los otros niveles los parámetros quedan como sigue: delay_parameters 2 150000/450000 1630/150000 delay_parameters 3 150000/450000 1190/150000 Si quisiéramos asignar un horario activo para esta gestión añadiríamos las siguientes reglas de acceso: acl work_day time M-F acl work_time time 09:00-18:00 delay_access 1 allow work_day work_time nivel1 delay_access 2 allow work_day work_time nivel2 delay_access 3 allow work_day work_time nivel3 1.6.2. Control enlace de carga (netfilter-tc) La herramienta tc contiene todas las configuraciones del núcleo requeridas para el control de tráfico. “tc” se puede gestionar desde la línea de comandos LARTC (Linux Advanced Routing Traffic Control) con una sintaxis anticuada que refleja la evolución histórica de la herramienta. Ejemplo sencillo que usa tc para añadir una disciplina de cola a la cola de un dispositivo: > tc qdisc add \ Agrega una disciplina de cola. La instrucción podría ser también “del” para eliminar. > dev eth0 \ Especifica el dispositivo en el cual se agregara la nueva disciplina. > root \ La palabra root significa “egreso” (en el enlace de salida) para tc. > handle 1:0 \ Este número sirve para especificar la prioridad que toma dicha disciplina de la forma mayor:menor. > htb Es la disciplina de encolamiento escogida, por ejemplo HTB.

B-31

Ejemplo de configuración de una qdisc PRIO # tc qdisc add dev eth0 root handle 1: prio ## Esto crea *instantáneamente las clases 1:1, 1:2, 1:3 # tc qdisc add dev eth0 parent 1:1 handle 10: sfq # tc qdisc add dev eth0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600 limit 3000 # tc qdisc add dev eth0 parent 1:3 handle 30: sfq Ejemplo de clasificación de paquetes con filtro. # tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match ip dport 22 0xffff flowid 10:1 # tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match ip sport 80 0xffff flowid 10:1 # tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2 Coloca tres filtros en la qdisc 10:0:

• El flujo que se dirija hacia el puerto 22 se renvía hacia la clase 10:1 • El flujo que se dirija proviene del puerto 80 se renvía hacia la clase 10:1 • El resto del flujo hacia la clase 10:2

Ordenes típicas de marcado La mayoría tiene una sintaxis: # tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 .. Hacen referencia a u32 y pueden hacer referencia a cualquier parte de un paquete.

• Sobre la dirección de origen/destino: o Máscara de origen «match ip src 1.2.3.0/24» o Máscara de destino «match ip dst 4.3.2.0/24»

• Sobre puerto de origen/destino, todos los protocolos de IP o Origen: «match ip sport 80 0xffff» o Destino: «match ip dport 0xffff»

• Sobre protocolo IP (tcp, udp, icmp, gre, ipsec) o Use los números de /etc/protocols. o Por ejemplo, icmp es 1: «match ip protocol 1 0xff».

Existen otros muchos tipos de protocolos.

tesis.ipn.mxtesis.ipn.mx/jspui/bitstream/123456789/17628/1... · en la ciudad de méxico el día...

Documents