tesis pos grado de ingenieria
TRANSCRIPT
ENRUTADOR IP MULTISERVICIO CON CONFIGURACIÓN VIA WEB(LXROUTER)
TRG 0501
EDGAR ORLANDO BELTRAN HUERTASNELSON ANDRES GUTIERREZ PERDOMO
RAMSES OSIRIS PEDRAZA RINCON
DIRECTOR: ING. FRANCISCO VIVEROS MORENO
BOGOTA D.C.PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERIADEPARTAMENTO DE ELECTRÓNICA
ENRUTADOR IP MULTISERVICIO CON CONFIGURACION VIA WEB(LXROUTER)
EDGAR ORLANDO BELTRAN HUERTASNELSON ANDRES GUTIERREZ PERDOMO
RAMSES OSIRIS PEDRAZA RINCON
Trabajo de Grado presentado como requisito parcial
para optar al título de Ingeniero Electrónico.
Director
Ing. FRANCISCO VIVEROS
BOGOTÁ D.CPONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍADEPARTAMENTO DE ELECTRÓNICA
2
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA ELECTRÓNICA
RECTOR MAGNÍFICO: R.P. GERARDO REMOLINA S.J.
DECANO ACADÉMICO: Ing. FRANCISCO JAVIER REBOLLEDO MÚÑOZ.
DECANO DEL MEDIO UNIVERSITARIO: R.P. ANTONIO JOSÉ SARMIENTO S.J.
DIRECTOR DE CARRERA: Ing. JUAN CARLOS GIRALDO CARVAJAL.
DIRECTOR DE TRABAJO DE GRADO: Ing. FRANCISCO VIVEROS MORENO.
3
Artículo 23 de la resolución número 13 del mes de julio de 1946.
“La universidad no se hace responsable de los conceptos emitidos por sus
alumnos en sus proyectos de grado.
Solo velará porque no se publique nada contrario al dogma y la moral católica y
porque los trabajos no contengan ataques o polémicas puramente personales.
Antes bien, que se vea en ellos el anhelo de buscar la verdad y la justicia.”
4
A mi madre quien en todo momento ha sido apoyo y consorte para cuantameta me he propuesto.
A mi familia por encontrarse presente a lo largo de esta larga empresa quehoy culmina.
Al doctor Enrique Santamaría Hermida por ser la mano invisible que ayudó aforjar mi sueño.
Y por último, pero no por esto menos importante, a mis amigos, sin loscuales cada tarea y cada proyecto habría perdido el tinte de alegría y
solidaridad que ustedes le dieron.A Dios, Gracias.
Edgar Orlando Beltrán Huertas
5
A EL que lo es TODO, me lo ha dado TODO, me ha permitido conocerle yconocer la VERDADERA FELICIDAD.
A mis Padres, su esfuerzo, comprensión y permanente apoyo.
A mis familiares que de una u otra forma me dieron la fuerza para continuaren los momentos buenos y malos.
A mis amigos, los que vinieron, los que se fueron, los que aun están.
Al personal de la Pontificia Universidad Javeriana.
A todos los que de una u otra forma estuvieron ahí.
Gracias.
Ramsés Osiris Pedraza Rincón
6
A Dios que me ha dado la fortuna de contar con los medios y personas paralograr mis metas.
A mi Madre quien supo entender y apoyar mi proceso, en forma constante ycon el amor que siempre la ha caracterizado.
A mi Padre por la paciencia y apoyo constante en este largo de tiempo deestudios satisfactorios, que aun no culminan.
A Claudia Patricia Gómez Garcia, mi novia, quien por su nobleza y pacienciame contagió de la calma y tranquilidad necesarias para seguir luchando.A mis amigos que siempre estuvieron pendientes de mi vida académica
como personal, brindando apoyo y ayuda en los momentos difíciles.A los compañeros que ya disfrutan de los frutos de ser ingenieros
electrónicos.A los empleados de la Facultad que siempre estuvieron ahí, eran
indispensables para un mejor desempeño en mis labores.
Gracias.
Nelson Andrés Gutierrez Perdomo
7
AGRADECIMIENTOS
Los autores expresan sus agradecimientos a:
Ing. Francisco Viveros por su apoyo, guía y preocupación constante por tener los
mejores medios para la realización del trabajo de grado.
Al jefe de sección de Laboratorio del departamento de Electrónica, Ing. Jorge Luis
Sánchez Téllez.
Al Laboratorio por habernos facilitado el equipo para llevar a cabo nuestro trabajo
de grado
Ing. Henry Leonardo Moreno Díaz por su resolución de dudas a cualquier
momento.
Al estudiante Jorge Mario Grimaldos por su resolución de dudas a cualquier
momento.
8
TABLA DE CONTENIDO
2METODOLOGÍA PARA EL DESARROLLO DEL LXROUTER.........................................................5
3ESPECIFICACIONES DEL ENRUTADOR IP (LXROUTER) ............................................................8
4PROBLEMAS ENCONTRADOS......................................................................................................31
5FUTUROS PROYECTOS.................................................................................................................35
6ANÁLISIS DE RESULTADOS..........................................................................................................36
7ANALISIS DE COSTOS...................................................................................................................54
8CONCLUSIONES.............................................................................................................................56
9BIBLIOGRAFIA................................................................................................................................57
10ANEXOS.........................................................................................................................................58
I
TABLA DE FIGURAS
FIGURA 1 DIAGRAMA GENERAL DE FUNCIONAMIENTO...........................................................16
FIGURA 2 DIAGRAMA DE SWITCH................................................................................................17
FIGURA 3 DIAGRAMA DE FIREWALL.............................................................................................20
FIGURA 4 DIAGRAMA FILTRADO DE IP.........................................................................................21
FIGURA 5 DIAGRAMA GENERAL DE NAT......................................................................................23
FIGURA 6 DIAGRAMA GENERAL DE DNAT...................................................................................25
FIGURA 7 DIAGRAMA GENERAL DE SNAT..................................................................................27
FIGURA 8 DIAGRAMA GENERAL DE DHCP...................................................................................28
FIGURA 9 DIAGRAMA GENERAL DE FUNCIONAMIENTO............................................................29
FIGURA 10 RECURSOS DISPONIBLES CON 4000 SOLICITUDES...............................................36
FIGURA 11 RECURSOS DISPONIBLES CON 2000 SOLICITUDES...............................................36
FIGURA 12 RECURSOS DISPONIBLES CON 1000 SOLICITUDES...............................................37
FIGURA 13 RECURSOS DISPONIBLES CON 4000 SOLICITUDES...............................................37
FIGURA 14 RECURSOS DISPONIBLES CON 2000 SOLICITUDES...............................................38
FIGURA 15 RECURSOS CON 1000 SOLICITUDES........................................................................38
FIGURA 16 EJEMPLO SNAT............................................................................................................39
FIGURA 17 EJEMPLO ENMASCARAMIENTO.................................................................................40
FIGURA 18 EJEMPLO DE DNAT......................................................................................................41
FIGURA 19 EJEMPLO DE DNAT......................................................................................................42
FIGURA 20 PING SIN NINGUNA REGLA........................................................................................43
II
FIGURA 21 REGLA PARA RECHAZAR PING..................................................................................44
FIGURA 22 LISTADO DE REGLA PARA RECHAZAR PING...........................................................45
FIGURA 23 RESPUESTA A LA REGLA DE RECHAZAR PING.......................................................45
FIGURA 24 REGLA PARA DESCARTAR PING...............................................................................46
FIGURA 25 LISTADO DE REGLAS PARA DESCARTAR PING......................................................48
FIGURA 26 RESPUESTA A UN PING DESPUÉS DE LA REGLA PARA DESCARTAR.................48
FIGURA 27 FTP SIN SER INTERVENIDO POR EL FIREWALL......................................................49
FIGURA 28 REGLA PARA DESCARTAR FTP.................................................................................50
FIGURA 29 LISTADO DE REGLAS PARA DESCARTAR FTP........................................................51
FIGURA 30 RESPUESTA A INTENTO DE CONEXIÓN FTP............................................................51
FIGURA 31 ASIGNACIÓN DE IP POR MEDIO DEL SERVIDOR DE DIRECCIONES.....................52
FIGURA 32 PRUEBA DEL SERVIDOR PROXY...............................................................................53
III
INDICE DE TABLAS
TABLA 1 TABLA DE COSTOS ACTUALIZADOS............................................................................54
1
INTRODUCCIÓN
En la actualidad, debido a la gran importancia y al posicionamiento fundamental
que han alcanzado las comunicaciones como base para el buen desarrollo y
posterior desempeño de todo tipo de empresas, se hace necesario el uso de
equipos con diferentes tecnologías y funciones que en conjunto proporcionen el
ambiente adecuado para el transporte de información vital para una organización.
En el mercado se ofrecen aparatos independientes para cada etapa del proceso
de creación de una red; como lo son enrutadores, firewall, servidores de
direcciones; generando así, un costo proporcional al tamaño y nivel de tecnología
seleccionados por el usuario o limitado por los recursos disponibles para este fin.
Sin embargo, uno de los inconvenientes que actualmente viven los usuarios de
este tipo de equipos es que para obtener la totalidad de los servicios requeridos,
deben acudir a varios proveedores, los cuales aportan su parte, pero
implícitamente están generando una dependencia de los mismos en caso de
presentarse daños o requerir mantenimiento en general de los dispositivos, ya que
han sido fabricados con componentes y partes patentadas de uso exclusivo de los
proveedores.
Sucede que en las pequeñas y medianas organizaciones, a menudo, se requiere
establecer una red local para la comunicación de los miembros de la empresa o
simplemente es un grupo de usuarios que necesitan el servicio de Internet; para
esto se necesitan dispositivos y servicios en especial que permiten la conección a
varios computadores usando una única conexión a Internet, facilian el crecimiento
de la red, proporcionan seguridad en las conecciones a la vez que permiten tener
un control sobre los sitios y la información transeferida; para ello es necesario
buscar una solución viable, de bajo costo, y de sencillo uso que permita establecer
2
el buen funcionamiento de la red. Una alternativa será la de integrar en un solo
equipo, los servicios y dispositivos, habitualmente encontrados en el esquema de
una red estándar.
En el mercado actual, una solución de este tipo es el Ringdale's Proxy Router and
DHCP Server1 con características similares a la del dispositivo propuesto, esta por
el orden de los $465 dólares, es decir unos $1.030.000 pesos colombianos, sin
vincular gastos por importación o intermediarios, sin contemplar que este
dispositivo es muy aproximado al desarrollado en este trabajo de grado, pero con
ciertos aspectos que no incluye el Ringdales’s Proxy router y que si contempla el
LXRouter como los son fácil configuración vía WEB, acceso a 3 puertos, firewall,
entre otros además de que no existiría problema por las licencias de software ya
que es libre, y todo por un precio apreciablemente menor (observar la tabla de
costos), teniendo en cuenta que esto seria el desarrollo total, se apreciaría
claramente en la comercialización de la solución.
La alternativa que se plantea a este tipo de inconvenientes (como lo son el contar
con varios equipos para solventar las necesidades básicas en la instalación de
una red LAN), es la integración de servicios y funciones en un solo dispositivo,
creado a partir de piezas de fácil obtención en el mercado. Es por esto que se
decide implementar la solución propuesta en un equipo de cómputo convencional.
1 http://www.ringdale.com/products/st/asp/control.wizmoreinfo/id.10213/po./en/default.htm
3
1.1 OBJETIVO GENERAL
Diseñar un prototipo de enrutador fácilmente configurable a través de una interfaz
web, ofreciendo aplicaciones adicionales al encaminamiento de paquetes como lo
son el filtrado de conexiones y la optimización del tráfico web.
1.2 OBJETIVOS ESPECÍFICOS
• Implementar los algoritmos de enrutamiento necesarios para desarrollar
un sistema con capacidad de realizar NAT (Network Address
Translation) en un equipo de cómputo convencional cuyas interfaces de
red sean soportadas por Linux 2.4.
• Diseñar una interfaz cómoda y sencilla para el usuario mediante la cual
se pueda configurar el dispositivo, aprovechando los beneficios y la
claridad que ofrece un entorno web.
• Incorporar el filtrado de paquetes (Statefull Packet Inspection) al
conjunto de funciones desarrolladas para el proyecto.
• Desarrollar un sistema de reset que permita volver a la configuración por
defecto.
4
2 METODOLOGÍA PARA EL DESARROLLO DEL LXROUTER
Para lograr los objetivos planteados desde el principio y avanzar de una manera
adecuada en el desarrollo del trabajo de grado, se debe definir un proceso de
desarrollo de software. Se tomo una metodología de trabajo en la cual se hacen
claras unas etapas:
2.1 Etapa de Ingeniería
2.1.1 Fase de Concepción
Se define una alternativa económica para la administración y seguridad de una
red LAN en una PYME. Se identifica y especifica los requerimientos de uso que
satisfagan las necesidades de red a través de las experiencias laborales, tomando
las más comunes e importantes. Se definen también los posibles inconvenientes
que se podrían presentar a nivel de lenguajes de programación y configuración del
hardware en Linux, junto con simplificar al mínimo la interfaz web para la fácil
utilización por parte del usuario.
Se propone el esquema del sistema en el bloque de firewall, NAT y servicios
adicionales y estos tres en paralelo con la Interfaz Web.
2.1.1.1 Planeación de las Fases y de las Iteraciones
A partir de los usos se determina que NAT es el bloque de más opciones y que
podría presentar mayor dificultad, de esta forma se escogieron que las opciones
principales serán Dirección (Origen, Destino, Cambio), Protocolos (TCP, UDP,
5
ICMP), y Puertos y/o códigos. Para SNAT como para DNAT. Se procederá de la
misma forma para firewall, para los servicios adicionales PROXY (Memoria a
utilizar, Tamaño del cache), DHCP (Dominio, Interfaz y Rango de Direcciones).
Las pruebas planteadas al momento son de funcionamiento más que de
capacidad y valores límite del sistema.
2.1.2 Fase de Elaboración
Se analiza cómo las opciones de uso seleccionadas afectan el desenvolvimiento
de un usuario inexperto en la interfaz web implementando una serie de ayudas
(activación y desactivación de campos) para hacer la correcta configuración del
enrutador.
A pesar de las incertidumbres generadas por los posibles errores que puede
cometer un usuario inexperto, se halló solución a la mayoría, siendo viable el
continuar con el proyecto. Se hace más sencillo desarrollar los demás bloques
dado a que su complejidad es menor y en el caso de firewall los campos y ayudas
de usuario son muy similares a las de NAT.
2.2 Etapa de Producción
2.2.1 Fase de Construcción
6
Los tiempos se fueron reduciendo en comparación a los estimados la comenzar,
junto con los costos de elaboración, principalmente por que se uso código abierto
lo que simplifico la solución de problemas del mismo a través de Internet y las
distintas páginas que ofrecen soporte y ayuda para el código abierto2
2.2.2 Fase de Transición
Mediante la fase de prueba se detectan errores de interpretación de la sintaxis en
Linux, los cuales se corrigen, debido a que generalmente son una línea o un
comando mal utilizado.
Para la prueba de rendimiento del enrutador con el Servidor Proxy funcionando,
se utilizó la herramienta HttpTrafficGenerator3 para generar tráfico http y
monitorear a la vez el rendimiento de la máquina.
El rendimiento de la máquina se monitoreo con la herramienta TOP que viene con
la distribución de Linux que estamos usando.
Las pruebas se hicieron desde dos máquinas conectadas directamente al
enrutador, desde las cuales se corria en simultáneo el programa generador de
tráfico variando la cantidad de paquetes por milisegundo en cada máquina y
obteniendo los casos que se verán descritos en la parte de pruebas.
2 Ver bibliografía3 http://www.nsauditor.com/
7
3 ESPECIFICACIONES DEL ENRUTADOR IP (LXROUTER)
3.1 Generalidades
Este proyecto consiste básicamente en un dispositivo para enrutar tráfico IP4
capaz de ofrecer funcionalidades5 iguales y en algunos casos mejores en relación
a las propuestas comerciales hoy en día existentes, manteniendo un precio
notablemente reducido y teniendo en mente que el mercado objetivo al que se
desea llegar (en el caso hipotético de que se pueda comercializar a plenitud el
producto) son las pequeñas y medianas empresas con necesidades de
comunicación prioritarias a través de Internet y que deseen además obtener
servicios de seguridad como firewall’s6 contando con recursos limitados.
Para este fin, se ha subdividido el proyecto en tres partes principales:
• NAT (Traducción de direcciones de red)7
Básicamente, esta parte consiste en permitir el acceso a Internet de forma
controlada a los clientes ubicados en la red interna, al mismo tiempo que es útil
para regular la forma en la que los usuarios externos usan los servicios
establecidos en la red interna.
• FIREWALL (Cortafuegos)
El modo de operación establecido en este segmento del proyecto se basa en el
rechazo o admisión de paquetes con base en sus direcciones de origen o destino,
o sus puertos. En general se carece de información de contexto, las decisiones
son tomadas sólo con base en la información del paquete en cuestión. En función
del enrutador, el filtrado se puede hacer a la entrada, a la salida o en ambos
lados.
4 Para mayor información ver Anexo 1 Glosario5 NAT, Firewall, Servidor Proxy, configuración vía WEB6 Se explica el término a continuación7 En el numeral 2.2.3 se explica su funcionamiento
8
• SERVICIOS ADICIONALES8 (Servidor DHCP, Servidor Proxy y Módulo
Switch)
3.1.1 Servidor DHCP
La utilidad de este tipo de servidores dentro de este proyecto, se basa en la
posibilidad de suministrar direcciones IP de forma dinámica, a los usuarios
pertenecientes a la red, agilizando así el proceso de configuración de equipos.
3.1.2 Servidor Proxy
Con este servidor se busca optimizar el ancho de banda disponible para el tráfico
de HTTP y HTTPS (Web y Web seguro respectivamente) haciendo uso del
sistema de caché que este servidor proporciona almacenando la información
solicitada con más frecuencia por parte de los usuarios.
3.1.3 Módulo de SwitchCon la implementación de este módulo, que es transparente para los usuarios y
demás dispositivos incluidos en el proyecto, se pretende ampliar la capacidad de
conexiones directas sobre el esquema de red que ofrece este dispositivo.
En la actualidad existen algunos proyectos de los grupos desarrolladores de la
comunidad Linux en Internet, la mayoría en fase de desarrollo, relacionados con el
8 Ver Glosario
9
tema tratado en este trabajo de grado, los cuales vamos a mencionar a
continuación:
LEAF (Linux Embedded Appliance Firewall)9
Los aspectos más llamativos de este proyecto son:
•Usa una versión de Linux muy compacta que puede ser contenida en una unidad
de almacenamiento de 1.44Mb, por lo tanto no requiere disco duro.
•El hardware usado es comercial, de bajo costo y muy fácil de conseguir.
•Se pueden adicionar servicios como VPN y SSH2*.
Dentro de los requerimientos mínimos de esta versión se puede encontrar un
procesador 486DX33 con 16Mb de memoria RAM si deseamos usar la versión
"floppy" o 24Mb si usamos la versión "cdrom"; dos tarjetas de red para usuarios
cable/DSL o una sola tarjeta de red si el usuario usa modem/ISDN para hacer las
conexiones de red necesarias. Lo anterior es lo básico para su funcionamiento, no
necesita teclado ni monitor. Una vez configurado y puesto en funcionamiento el
dispositivo, no es necesario volver a hacer cambios durante mucho tiempo,
únicamente se debe reiniciar si se desea actualizar el sistema.
Para tener una idea de como LEAF puede alcanzar un rendimiento tan alto sin
importar el hardware que se utiliza, es importante tener en cuenta que para los
sistemas 486, la velocidad típica de enrutamiento es de 3 a 6 MBits/s, lo cual es
mas que suficiente para el promedio de una conexión tipo cable-modem/xDSL10,
9 Linux Embedded Appliance Firewallhttp://sourceforge.net/docman/display_doc.php?docid=8794&group_id=13751* Para mayor información ver Anexo 1 Glosario10 Variación de DSL, puede ser ADSL, CDSL, FeeDSL, HDSL, entre otras* Para mayor información ver Anexo 1 Glosario
10
En el caso de los usuarios con conexión PPPoE o una puerta de enlace con
VPN*, la velocidad de transmisión se incrementa si se usan sistemas con
procesador Pentium I, los cuales, además de lo anterior, poseen ranuras PCI* lo
cual permite el uso de MODEM y tarjetas de red económicas y fáciles de
configurar.
La mayor diferencia entre LEAF y las distribuciones corrientes de Linux, es que la
primera corre el sistema en un disco virtual en RAM, lo cual es rápido y seguro
para evitar la perdida de datos en los discos de configuración e inicio si el sistema
llegara a colisionar; si esto llega a ocurrir, bastaría simplemente con reiniciar el
sistema, el cual volvería a su configuración original. En caso de daño en el
hardware, como se utiliza hardware genérico y comercial, su reemplazo es fácil de
obtener.
Actualmente se encuentran dos variaciones derivadas del proyecto LEAF,
Dachtein y Oxygen, además de variaciones que usan como base el LEAF, que
permiten encontrar documentación sobre los aspectos comunes con el dispositivo
propuesto, estos son:
Bering (LEAF-2.4.16 w/Shorewall)
PacketFilter
LRP -The Original
Echowall Firewall
Seattle Firewall
RCF Firewall
Shorewall Firewall
11
12
3.2 IMPLEMENTACIONES DEL ENRUTADOR IP (LXROUTER)
Aunque anteriormente se nombraron las partes fundamentales del proyecto es
necesario hacer énfasis la forma mediante la cual se desarrollaron:
• Para el desarrollo de NAT y FIREWALL se usaron las capacidades
contempladas en el Kernel de Linux V.2.4 a través de la interfaz ofrecida
por el software conocido como IPTABLES11 .
• Para llevar a cabo el Servidor de Direcciones (DHCP), se estudian las
posibles soluciones que ofrecen un mejor compromiso entre sencillez de
implementación y facilidad de uso, teniendo en cuenta que los recursos
disponibles para ser ejecutado son bastante limitados. Se llega a la
conclusión que dicho compromiso se daba casi en su totalidad con el uso
del software de código abierto DNSMASQ12 .
• SQUID13 fue la herramienta seleccionada para la instauración del Servidor
Proxy, debido a que el usuario final no tendrá que intervenir muchos de sus
parámetros de configuración, brindando así, un ambiente amable y
eficiente.
• Para la interfaz Web, se decidió utilizar varios lenguajes de programación
debido a las ventajas que unos ofrecen sobre otros, es el caso de PHP14
para la creación de tablas dinámicas y Apache15 para su hospedaje en el11 http://netfilter.org/12 http://www.thekelleys.org.uk/dnsmasq/doc.html13 http://www.squid-cache.org/ http://squid.visolve.com/squid/sqguide.htm http://www.icewalkers.com/Linux/Software/54580/Squid.html14 http://www.php.net/15 http://apache.org/
13
Enrutador, JavaScript16 para el uso de menús selectivos por parte del
cliente y HTML17 como la base para reunir los mencionados anteriormente,
además de BASH18 y AWK196 para ejecutar los comandos de sistema.
• Dentro de la interfaz WEB se contempló la posibilidad de un pequeño
asistente de configuración, que le permite al usuario nuevo iniciar el uso del
Enrutador IP sin ninguna restricción.
• El Switch se desarrolló a partir de un arreglo de 3 tarjetas de red,
configuradas de manera adecuada, tal que se permitiera el acceso a cada
una de ellas respondiendo a una misma dirección IP y MAC.
• Contemplando la posibilidad de que el usuario configurara de manera
equivocada el Enrutador IP, se desarrolló la forma mediante la cual, la
máquina puede retomar los valores que por defecto utiliza para su normal
funcionamiento, es por esto que se lleva a cabo la programación de un
Script (restaurar_script.sh) que lo que hacen es simplemente descomprimir
los archivos de configuración original previamente guardados y
sobreescribir los archivos de configuración actualmente en uso con la
información contenida en los archivos de configuración original. Este Script
será ejecutado después de ser usada la combinación de las teclas CTRL-
ALT-SUPR.
16 http://www.gamarod.com.ar/javascript/menu.asp http://www.w3schools.com/js17 Ver Glosario18 http://www.gnu.org/19
14
3.3 SÍNTESIS DEL ENRUTADOR IP (LXROUTER)
El Enrutador IP será el encargado de establecer los parámetros de conexión entre
un grupo de computadores comunicados entre sí (LAN) y el acceso a Internet.
Para ello cuenta con módulos como los son el Switch, Firewall, NAT, Servidor de
Direcciones (DHCP) y el Servidor Proxy; los cuales evalúan los criterios de
conexión dados por el usuario administrador del Enrutador IP a través la Interfaz
WEB.
INTERNET
Enrutador IP
SWITCHFIREWALL
NATDHCP
PROXY
LANINTERFAZ
WEB
Módulo de Configuración
Módulo de Funcionamiento
15
Figura 1 Diagrama general de funcionamiento.
3.4 MÓDULO DE CONFIGURACIÓN
En esta parte se encontrará la forma mediante la cual el usuario personalizará la
configuración de los diferentes servicios que presta el Enrutador IP, dependiendo
de las necesidades que presente. Para ello se ha dispuesto un asistente de
configuración rápida y básica.
3.5 MÓDULO DE FUNCIONAMIENTO
En esta parte, básicamente se comentará la forma en que el Enrutador IP ejecuta
las funciones para las cuales fue diseñado.20
3.5.1 SWITCH
El esquema de funcionamiento del Switch consiste en el uso de un programa
(Bridge Utils21) a nivel de sistema operativo con el fin vincular las 3 tarjetas de red
al arreglo que se desea formar, logrando de esta manera que cada uno de los
respectivos puertos por tarjeta se comporten de la misma forma que lo harían en
cualquier otro Switch comercial.
A través de este programa es posible hacer que el arreglo de tarjetas de red
respondan a una misma dirección tanto IP como MAC, logrando de esta manera
que el tráfico destinado a una interfaz de red sea dirigido a ésta y no a todas en
simultáneo evitando así posibles colisiones.
20 Ir al ANEXO: “Manual de Usuario”21 http://bridge.sourceforge.net/
16
Figura 2 Diagrama de Switch.
En la figura se aprecia que si uno de los clientes (MAC 1), desea comunicarse con
otro (MAC 3), el sistema sabe en que localización física se encuentra,
estableciendo de esta forma la conexión directa, a diferencia de un HUB que
enviaría la conexión primero a los clientes intermedios hasta llegar al destino
(MAC 1 a MAC 2 a MAC 3).
3.5.2 FIREWALL
Mediante este módulo es posible filtrar las conexiones originadas tanto de dentro
hacia afuera como de afuera hacia adentro del Enrutador IP basados en
parámetros como el protocolo (TCP22 - UDP23) y su puerto de origen o destino, o
código ICMP24. Permitiendo de esta forma aceptar o descartar dicha conexión.
22 http://es.tldp.org/Tutoriales/doc-servir-web-escuela/doc-servir-web-escuela-html/proto.html
23 http://neo.lcc.uma.es/evirtual/cdd/tutorial/transporte/udp.html
24 http://www.htmlweb.net/redes/tcp_ip/capa_3/red_5.html
IN OUT
17
Tal filtrado consiste en aceptar, descartar o rechazar la conexión descrita a través
de los diferentes parámetros ya mencionados. Vale la pena aclarar que la
diferencia entre los dos últimos consiste en que mientras rechazar envía una señal
de control a quien originó la conexión explicando que ésta no pudo ser realizada,
la acción de descartar simplemente anula dicho intento de conexión sin avisar
previamente a ninguna parte. Por motivos de seguridad, la acción que se debe
elegir si se desea eliminar una conexión es descartar, pues si se escoge rechazar
se está dando conocimiento a un posible atacante sobre la existencia de la red
que se desea proteger, mientras que de la otra forma los paquetes se pierden
aparentemente sin razón alguna, de la misma manera que ocurre si el enrutador
se encuentra apagado o simplemente no existe. Una vez aclarado este aspecto se
desea recordar que la opción rechazar solo ha sido contemplada por motivos de
flexibilidad ante los requerimientos propios de cada usuario.
Ahora bien, para continuar con la configuración del módulo de firewall se presenta
cual es la diferencia entre una regla y una política. Básicamente una regla
describe una conexión en función de ciertos parámetros (dirección de origen, de
destino, protocolo, puerto de origen, de destino o código, según sea necesario) y
establece una acción a ejercer con la misma, es decir, si por ejemplo se adiciona
una regla en la cual se describe una dirección de origen y un puerto de destino, y
existe una conexión que cumpla dichos criterios, entonces el firewall ejerce la
acción que para dicha regla había sido propuesta por el usuario. Sin embargo, si
no existe una regla para dicha conexión, entonces se ejecuta la política. Esta
política consiste en ejecutar la misma acción de una regla, pero al ser la más
general de todas siempre debe ejecutarse de última. Este evento es de notable
importancia, pues de él depende que el firewall funcione de la manera esperada.
Dicha característica es consecuencia de la forma en la cual trabaja el módulo, ya
que este revisa cada una de las reglas en el mismo orden en que fueron
ingresadas y de la misma manera las ejecuta hasta llegar a la política. Sin
embargo, si el usuario desea borrar una regla por estar en desacuerdo con ella, o
por haberla ingresado de manera errónea, puede hacerlo a través de la interfaz
18
Web, la cual a su vez modificará un archivo de texto que posteriormente será
procesado a través de un script en lenguaje AWK25, para finalmente generar las
reglas en lenguaje SHELL26 que serán interpretadas por el sistema.
Dicho proceso se ejecuta usando el software IPTABLES27 versión 1.2.11 para
Kernel 2.4.29 disponible para Slackware Linux v.10.1
A continuación se presenta el diagrama en bloques que describe de una manera
mas clara el funcionamiento del firewall.
25 http://www.gnu.org/software/gawk/gawk.html26 http://www.gnu.org/software/bash/bash.html27 http://netfilter.org/
19
Figura 3 Diagrama de Firewall.
20
Figura 4 Diagrama Filtrado de IP.
21
3.5.3 NAT
Normalmente, los paquetes viajan en una red desde su origen a su destino a
través de varios enlaces diferentes. Ninguno de estos enlaces altera realmente el
paquete: simplemente lo envían un paso adelante.
Si uno de estos enlaces hiciera NAT, podría alterar el origen o destino del paquete
según pasa a través suyo. Normalmente, el enlace que esté haciendo NAT
recordará cómo manipuló el paquete, para hacer la acción inversa con el paquete
de respuesta, de manera que todo funciona como se espera.
Las razones principales para el uso de NAT son:
Conexiones con módem a Internet
La mayoría de los PSI (Proveedor de Servicios de Internet) dan una sola
dirección IP cuando se conecta con ellos. Puede enviar paquetes con
cualquier dirección, pero sólo obtendrá respuesta a los paquetes con esa IP
de origen. Si desea utilizar varias máquinas diferentes (como una red
casera) para conectar a Internet a través de un enlace, necesita NAT.
Este es, el uso más común de NAT hoy en día, conocido normalmente
como “Enmascaramiento” (masquerading) en el mundo de Linux. También
llamado SNAT, porque se cambia la dirección de origen (source) del primer
paquete.
Varios servidores
Puede que se quiera cambiar el destino de los paquetes que entran en su
red, con frecuencia esto se debe, a que sólo tiene una dirección IP, pero se
desea que la gente sea capaz de llegar a las máquinas detrás de la IP que
tiene a la IP «real». Si se rescribe el destino de los paquetes entrantes, se
podrá conseguir.
Una variante común de esto es el balanceo de carga, en la cual se toma un
cierto número de computadores, repartiendo los paquetes entre ellos. Este
22
tipo de NAT se llamó reenvío de puerto (port-forwarding) en anteriores
versiones de Linux.
En los siguientes bloques se ilustra el funcionamiento de la parte de NAT.
Primero se muestra el esquema general y global de NAT:
Figura 5 Diagrama general de NAT.
Aquí los paquetes o en general la información viene del firewall, una vez lo cruza
entra a NAT, específicamente a DNAT, aquí es donde se evalúan los aspectos
concernientes al destino de los paquetes o la conexión; ejecuta las reglas y
políticas que se hayan configurado, incluso también existe la posibilidad de que el
paquete pase sin tocarlo; posteriormente entra a SNAT, y allí es donde se
evalúan los aspectos concernientes al origen de los paquetes o la conexión; y de
23
allí sale a los demás servicios adicionales que se ofrecen y que el usuario a su
gusto configura.
24
Bloque de D-NAT (NAT de Destino) :
Figura 6 Diagrama general de DNAT.
25
Cuando se habla de aplicar una regla, es la que el usuario ha especificado, y
cuando se habla de política, es aquella que se aplica a los paquetes que no se
están especificando y se aplica una configuración por defecto, generalmente es
dejar intacto el paquete.
Posteriormente se evalúa y se pregunta por la Dirección, Puerto y Protocolo. En
las reglas se especifican las tres características, si en algún momento el paquete
no cumple con alguna se descarta la aplicación de la regla que se ha configurado,
y se le aplica la política por defecto, y no se sigue evaluando los demás
parámetros, es decir el paquete tiene que cumplir con todos los aspectos que se
han especificado.
26
Bloque de S-NAT (NAT de Origen) :
Figura 7 Diagrama general de SNAT.
27
Primero se describe una conexión a través de los parámetros IP de origen, puerto
y protocolo. Si esta conexión reune completamente dichos parámetros, se
procede a ejecutar la acción de DNAT la cual consiste en cambiar la dirección de
destino hacia la que se dirigen los paquetes.
3.5.4 SERVIDOR DE DIRECCIONES (DHCP)
Figura 8 Diagrama general de DHCP.
Mediante este servicio se proporcionara al cliente la información de configuración
(dirección IP, Máscara de red, dirección de broadcast) dinámicamente desde un
28
servidor de protocolos. Se utiliza posteriormente la herramienta DNSMASQ, la
cual permite determinar parámetros como autorización para acceder al servicio y
tiempo de asignación además de los anteriormente nombrados.
3.5.5 SERVIDOR PROXY
Figura 9 Diagrama general de funcionamiento.
Básicamente el servicio de PROXY se implementa para disminuir el tiempo de
espera por parte de los usuarios al acceder a algún tipo de información que
recientemente fue solicitada, además de proporcionar un control sobre los
usuarios que acceden a Internet. La herramienta a utilizar será SQUID, mediante
la cual se permite seleccionar el puerto a usar para la conexión, la memoria
destinada al almacenamiento de datos en disco y en memoria RAM, integrar el
servicio de Firewall al proceso en cuestión y establecer reglas de control.
29
En algunas ocasiones es necesario simular que cada paquete que pase por la
máquina Linux esté destinado a un programa en la propia máquina. Esto es lo que
se conoce como proxy transparente. La parte transparente se debe a que la red
nunca tendrá por qué enterarse de que está comunicándose con un proxy, a
menos, claro, que el proxy no funcione.
Se puede configurar Squid para que trabaje de esta manera, y a esto se le llamó
redirección o proxy transparente en anteriores versiones de Linux.
Las reglas específicas para que funcionen en la implementación desarrollada son:
iptables –t nat –A PREROUTING –i br0 –p tcp –dport 80 –j REDIRECT –to-port
3128
iptables –t nat –A PREROUTING –i br0 –p tcp –dport 443 –j REDIRECT –to-port
3128
Con esto se permite que cualquier intento de acceso a los puertos 80 y 443
(protocolo TCP) sean redireccionados al Servidor Proxy, logrando de esta forma la
implementación del Proxy Transparente.
30
4 PROBLEMAS ENCONTRADOS
4.1 NAT
Orden de Reglas y Políticas: Al diseñar la interfaz Web no se tuvo en cuenta que
las reglas que se introducen para la configuración, deben listarse de las más
especifica a la más general, ya que el programa usado (IPTABLES), para efectuar
estos cambios lo requiere así, de otra forma las reglas especificas que estén
después de una mas general, aunque se cargaran y las aceptara el programa, no
tendrán efecto deseado de configuración, y será prácticamente como si no se
hubieran configurado.
Interfaz Web: Al comenzar la programación de la interfaz Web en los lenguajes
htm, php y javascript; se presentaron inconvenientes por falta de conocimiento
más extenso de los lenguajes de programación utilizados, posteriormente, debido
a la sintaxis del interprete de comandos de Linux, no se permitía configurar el
dispositivo si se entraba datos en campos incorrectos.
Debido a esto se hace necesario el desarrollo de una matriz de campos, que
active o desactive los campos que correspondan entre si y al final generen una
configuración satisfactoria, evitando mezclar parámetros que no tienen nada que
ve entre sí, como por ejemplo lo son protocolo TCP y Códigod ICMP.
Sintaxis de Linux: Al querer introducir la dirección por la cual se desea cambiar la
conexión, el intérprete de comandos no aceptaba como correcta la configuración,
por sintaxis.
Como solución; la dirección por la cual se van a cambiar las direcciones de origen
o destino deben entregarse como IP, a la vez debido a esto se debe habilitar los
puertos de DNS para que a través de este se interpreten las demás direcciones
como hostname y la regla se pueda adicionar.
31
Adicionalmente múltiples problemas de menor complejidad, que se corrigieron en
el momento en el que surgían; en aspectos como el orden en que se introducen y
capturan los datos para permitir un proceso más sencillo al momento de manipular
la información y entregarla al intérprete de comandos como una instrucción y que
la sintaxis sea aceptada como válida.
4.2 Tráfico Real
Según se pudo apreciar en las pruebas realizadas con respecto al tráfico HTTP
que aún a 4000 solicitudes por segundo y usando un sistema Proxy para acelerar
el mencionado tráfico, la cantidad de recursos disponibles en el LXRouter nunca
fue inferior al 70%, lo cual indica claramente que la cantidad de usuarios puede
incrementarse de forma notable y el sistema continuará respondiendo de la
manera adecuada (ágil y robusta) antes los requerimientos hechos.
4.3 Servidor de Direcciones DHCP y Modulo Switch
El inconveniente encontrado consistió en que se estaba tratando de asignar
direcciones IP a los clientes que así lo solicitaban, pero estas se encontraban
fuera del rango que se había determinado en el Servidor de Direcciones, razón
por la cual era imposible otorgar las direcciones a quienes las requerían. La
solución fue configurar la interfaz de Switch (arreglo de tarjetas) con una dirección
IP y mascara de red dentro del rango de direcciones que ofrecería el Servidor de
Direcciones. Por esa razón se concluyó que es necesario asignar
automáticamente como dirección IP del Switch la primera dirección IP del rango
de direcciones del Servidor DHCP.
32
4.4 Shell Scripts28 y Servidor WEB
En esta ocasión el problema radicó en que ciertos comandos son de uso
restringido y no cualquier usuario puede ejecutarlos, debido a esto, varios de los
programas realizados (Shell Scripts) no corrían de la manera adecuada, razón por
la cual se busco una alternativa que permitiera ejecutar dichos comandos a
cualquier usuario, en este caso al usuario del Servidor WEB. Dicho programa es
conocido con el nombre de SUDO29 el cual es de libre distribución y viene incluido
por defecto con la versión de Linux que actualmente se esta usando.
4.5 Circuito de Reset
Inicialmente se tenía dispuesta la elaboración de un circuito de reset por
hardware, esto para que el LXROUTER fuera definitivamente solo una torre (sin
periféricos) y diera la verdadera apariencia de un router comercial. Se elaboraron
los Scripts necesarios para la restauración de la maquina a su configuración por
defecto. Después de hacerse la primera restauración, se notó que en el proceso
de inicio de la maquina, aparecía un estado de donde no podía continuar sin el
teclado conectado, propio del procedimiento que realizan la mayoría de Tarjetas
Madre (Board) al iniciar el sistema. Por esta razón se hacia inútil la elaboración del
Circuito de Reset por Hardware y la solución mas viable fue la configuración de
una secuencia de teclas (CTRL+ALT+SUPR) que realizaran la misma función del
circuito de Reset Original, sin el inconveniente de la desconexión de periféricos.
Adicionalmente se pensó en utilizar el Circuito de Reset propio de la torre para el
mismo objetivo, pero nuevamente se caía en el mismo problema de desconexión
de periféricos.
Una tercera alternativa era dar la señal de reset por el puerto serial, siendo en
este caso el empleo de capacidad de procesamiento desperdiciado al estar
28 Programas para ser ejecutados por el interprete de comandos o Shell29 http://www.courtesan.com/sudo/
33
monitoreando continuamente si existía la señal de reset y sin contar con el
persistente problema de desconexión de periféricos.
34
5 FUTUROS PROYECTOS
5.1 VPN
VPN (Virtual Private Network): Es una red privada, fue construida sobre la
infraestructura de una red pública (recurso público, sin control sobre el acceso de
los datos), normalmente Internet. Es decir, en vez de utilizarse enlaces dedicados
(como el X.25 y Frame Relay) para conectar redes remotas, se utiliza la
infraestructura de Internet, una vez que las redes están conectadas es
transparente para los usuarios.
5.2 MANEJO DE ANCHO DE BANDA FRACCIONADO POR IP
Haciendo uso de las facultades contempladas en el kernel de Linux es posible
administrar el ancho de banda a través de la herramienta conocida como TC
(Traffic Control), la cual permite modificar el canal asignado a cada IP, rango de
direcciones IP, o incluso puerto y protocolo según se requiera en un horario
especificado por el usuario. Todo esto partiendo de algoritmos de grafos como
CBQ (Class-Based Queueing30) o HTB (Hierachical Token Bucket31) que facilitan
un poco su implementación, pero que igualmente demandan mucho mas tiempo
en el desarrollo de una interfaz sencilla al usuario poco conocedor.
30 http://www.icir.org/floyd/cbq.html31 http://sourceforge.net/projects/htbinit/
35
6 ANÁLISIS DE RESULTADOS
6.1 PRUEBAS DE SOLICITUDES HTTP SIN EL SERVIDOR PROXYACTIVADO
Recursos disponibles con 4000 solicitudes HTTP por segundo (2 PC´s directamente conectados
2000+2000)
848688909294
1 2 3 4 5 6 7 8 9 10
Tiempo en segundos
Porc
enta
je d
e re
curs
os
disp
onib
les
Series1
Promedio:89.09%
Figura 10 Recursos disponibles con 4000 solicitudes
Recursos disponibles con 2000 solicitudes HTTP por segundo (2 PC´s directamente conectados
1000+1000)
85
90
95
100
1 2 3 4 5 6 7 8 9 10
Tiempo en segundos
Porc
enta
je d
e re
curs
os
disp
onib
les
Series1
Promedio:92.04%
Figura 11 Recursos disponibles con 2000 solicitudes
36
Recursos disponibles con 1000 solicitudes HTTP por segundo (1 PC directamente
conectado)
919293949596
1 2 3 4 5 6 7 8 9 10
Tiempo en segundos
Porc
enta
je d
e re
curs
os
disp
onib
les
Series1
Promedio:94.78%
Figura 12 Recursos disponibles con 1000 solicitudes
6.2 PRUEBAS DE SOLICITUDES HTTP CON EL SERVIDOR PROXYACTIVADO
Recursos disponibles con 4000 solicitudes HTTP por segundo (2 PC´s directamente
conectados 2000+2000)
60
65
70
75
80
1 2 3 4 5 6 7 8 9 10 11
Tiempo en segundos
Por
cent
aje
de
recu
rsos
di
spon
ible
s
Series1
Promedio:70.8%
Figura 13 Recursos disponibles con 4000 solicitudes
37
Recursos disponibles con 2000 solicitudes HTTP por segundo (2 PC´s directamente
conectados 1000+1000)
70
75
80
85
90
1 2 3 4 5 6 7 8 9 10 11
Tiempo en segundos
Porc
enta
je d
e re
curs
os
disp
onib
les
Series1
Promedio:79.63%
Figura 14 Recursos disponibles con 2000 solicitudes
Recursos disponibles con 1000 solicitudes HTTP por segundo (1 PC directamente
conectado)
87888990919293
1 2 3 4 5 6 7 8 9 10 11
Tiempo en segundos
Porc
enta
je d
e re
curs
os
disp
onib
les
Series1
Promedio:91.36%
Figura 15 Recursos con 1000 solicitudes
Como conclusión de éstas pruebas podemos aclarar que obviamente el tiempo de
respuesta para el usuario disminuye, pero lo más importante es que a pesar de
que se ejecuta el Servidor Proxy, el rendimiento de la máquina se mantiene muy
por encima del promedio, o sea, sus recursos no se ven afectados.
38
6.3 NAT
• Se desea que un cliente de la red interna que se dirija a la página de ISTEC
se le reenvié a la página de Triton de ingeniería electrónica, esto se debe
hacer en DNAT:
I. Para este caso se debe agregar una regla en la que se obliga a
enmascarar la conexión y la oriente por el puerto 53, que es el DNS,
debido a que istec.javeriana.edu.co es un nombre y NAT trabaja en
términos de las IP, debemos pasar la conexión por el puerto DNS para
que se encargue de traducir el nombre a IP. Se usa la página de usuarios
avanzados
Figura 16 Ejemplo SNAT.
39
En la grafica se ilustra que en origen se introduce la IP que posee el cliente
de la red interna, en destino se coloca la IP del servidor DNS de la
Javeriana, protocolo UDP o TCP; en ambos el puerto 53 es para DNS, y en
puerto de destino el 53.
II. Ahora se debe enmascarar la conexión para que tenga salida y acceso a
la red. De lo contrario su conexión estaría bloqueada. En origen la IP del
cliente interno, en destino la dirección de la página de triton, y no es
necesario adicionar mas campos.
Figura 17 Ejemplo Enmascaramiento.
III. Ahora si para hacer la traducción deseada: solo es necesario usar los
campos de direcciones, en origen la IP del cliente de red interna, destino
40
la dirección de ISTEC y en cambiar por la dirección IP de
triton.javeriana.edu.co.
Figura 18 Ejemplo de DNAT.
• Dado el caso en el cual se desee abrir el puerto TCP 139 del LXROUTER y
redireccionarlo al puerto 22 TCP de un servidor ubicado dentro de la red
interna, el procedimiento a seguir seria el siguiente:
41
Figura 19 Ejemplo de DNAT.
6.4 FIREWALL
Básicamente se comprobó la funcionalidad del mismo a través de la interfaz Web
usando reglas y comprobando su efectividad al aceptar, descartar o rechazar
conexiones tanto desde la red externa al LXROUTER como desde la red interna.
En este orden de ideas se contemplaron algunos casos de posible ocurrencia;
basados en ellos, se diseñaron los procedimientos que se presentan a
continuación:
42
6.4.1 Rechazar Ping32
Aquí se muestra la respuesta del LXROUTER antes de ejecutar la regla que debe
cancelar el ping (Figura 15).
Figura 20 Ping sin ninguna regla
Ahora bien, se introduce la siguiente regla (Figura No.21): que permite rechazar
todo paquete destinado a lxrouter.javeriana.edu.co con protocolo ICMP y código 8
32 http://www.iana.org/assignments/icmp-parameters
43
Figura 21 Regla para rechazar ping
Se procede a verificar que efectivamente la regla ha sido ejecutada por el
LXROUTER haciendo clic en “Ver Reglas”
44
Figura 22 Listado de regla para rechazar ping
Una vez comprobado esto, se realiza la misma prueba de ping y se observa el
siguiente resultado (Figura No. 23):
Figura 23 Respuesta a la regla de rechazar ping
45
Según se puede apreciar en la Figura No. 23, ahora la respuesta del LXROUTER
es enviar un mensaje de error a quien realizaba el ping y se rehúsa a responderlo
de la manera habitual. Con esto queda comprobado que efectivamente el
dispositivo funciona de la manera esperada bajo el criterio que esta prueba ofrece.
6.4.2 Descartar Ping33
Para realizar esta prueba se borraron todas las reglas existentes en el firewall y se
procedió a verificar que el LXROUTER respondía sin problemas al ping realizado
desde una máquina cliente, obteniendo de esta forma el mismo resultado
favorable presentado en la Figura No.20
Una vez hecho esto, si ingresó una regla mediante la cual fuera posible descartar
todo paquete dirigido hacia lxrouter.javeriana.edu.co con protocolo ICMP y código
8. Quedando esta de la siguiente manera (Figura No. 24):
Figura 24 Regla para descartar ping
33 http://www.iana.org/assignments/icmp-parameters
46
Ahora bien se procede a verificar que efectivamente la regla ha sido ejecutada por
el LXROUTER haciendo clic en “Ver Reglas” (Figura No. 25)
47
Figura 25 Listado de reglas para descartar ping
Finalmente se procede a probar la regla enviando un ping desde la misma
máquina cliente y se revisa la respuesta obtenida (Figura No. 26):
Figura 26 Respuesta a un ping después de la regla para descartar
48
Según se puede observar tras realizar la prueba, el LXROUTER efectivamente
anuló por completo los paquetes descritos por la regla, al grado de ofrecer la
misma respuesta que si el dispositivo se encontrar apagado, lo cual constata que
efectivamente realiza la acción ordenada.
6.4.3 Descartar FTP34
Para este caso se muestra como inicialmente la conexión desde un cliente
funciona sin ningún problema (Figura No. 27) antes de añadir la regla que tendrá
como fin bloquear el acceso a FTP en el LXROUTER:
Figura 27 FTP sin ser intervenido por el firewall
Ahora bien, se procede a ingresar la regla (Figura No. 28):
34 http://www.faqs.org/rfcs/rfc959.html
49
Figura 28 Regla para descartar FTP
Luego de esto, se verifica que efectivamente la regla ha sido ejecutada por el
LXROUTER haciendo clic en “Ver Reglas” (Figura No. 29)
50
Figura 29 Listado de reglas para descartar FTP
Finalmente, se prueba la conexión FTP desde el mismo cliente hacia el
LXROUTER y se obtiene el siguiente resultado (Figura No. 30):
Figura 30 Respuesta a intento de conexión FTP
51
Según se puede apreciar, la conexión falló y no pudo establecerse, tal como era
de esperarse en consecuencia a la regla que previamente se había ingresado.
6.5 SERVIDOR DE DIRECCIONES
Para comprobar la funcionalidad del Servidor de Direcciones (DHCP),
simplemente se conecta un cliente a una de las interfaces configuradas como
Switch. Se solicita una dirección IP y se verifica que la misma este dentro del
rango que previamente se había suministrado a través de la interfaz WEB.
Figura 31 Asignación de IP por medio del Servidor de Direcciones
52
6.6 SERVIDOR PROXY
Para comprobar el correcto funcionamiento de este servicio, se procede a
configurar el uso de Servidor Proxy en el navegador, como se vio en el Manual de
Usuario, y luego se procede a buscar una dirección no existente.
Debido a que no se esta enmascarando por defecto, es decir, esta no es la
política aplicada, la única forma de navegación que resta a los clientes es a través
de servidor Proxy, dado que al navegar hacia una página existente, no se produce
ningún error (como es de esperarse), se hace necesario navegar a una que no
exista para verificar el estado del Proxy. Es esto lo que se presenta a
continuación:
Figura 32 Prueba del Servidor Proxy
53
7 ANALISIS DE COSTOS
Tabla 1 Tabla de costos actualizados
RECURSOSHUMANOS
HORAS XPERSONA
VALORHORA TOTAL
Director trabajo degrado 17 semanas * 2h $50,000 $1,700,000
Desarrolladores17 semanas *40h
*3 $10,000 $20,400,000TOTAL RECURSOS HUMANOS $22,100,000
EQUIPO CANTIDADVALORUNIDAD TOTAL
Componentes Varios Varios - $30,000CPU 1 $700,000 $700,000
Tarjetas de Red PCI 3 $7,000 $21,000Computador en Alquiler 1 - $600,000
TOTAL EQUIPO $1,351,000
PAPELERÍA CANTIDADVALORUNIDAD TOTAL
Papel 2*500 hojas $8,000 $16,000Fotocopias 1000 $35 $35,000Empaste 3 $4,000 $12,000Cartucho 2 $60,000 $120,000
Disco Compacto 10 $1,000 $10,000Diskette 10 $1,000 $10,000
TOTAL PAPELERIA $203,000LICENCIAS DESOFTWARE CANTIDAD
VALORUNIDAD TOTAL
Linux 2.4 1 $0.00 $0.00Apache 1 $0.00 $0.00
PHP 1 $0.00 $0.00SSL 1 $0.00 $0.00
TOTAL LICENCIAS DE SOFTWARE $0.00SERVICIO DEINTERNET
VALORUNIDAD TOTAL
Cablenet 4 Meses $88,000 $352,000TOTAL SERVICIOS INTERNET $352,000
COSTOS INDIRECTOS CANTIDADVALORUNIDAD TOTAL
Energía 1000 horas $161 $161,000Transporte 600 viajes $1,000 $600,000TOTAL COSTOS INDIRECTOS $761,000
OTROS Imprevistos $0
TOTAL OTROS $0
54
TOTAL COSTOS $24,767,000
Los costos tuvieron una reducción significativa del 48.43% al disminuir en el
tiempo planeado para el desarrollo del trabajo de grado, gracias al esfuerzo de los
integrantes y el entusiasmo colocado en el desarrollo del mismo.
Debido a que no se compró la tarjeta multiethernet presupuestada al principio y se
logró desarrollar el proyecto con tarjetas de red PCI facilitadas por el laboratorio
de la carrera de ingeniería electrónica.
55
8 CONCLUSIONES
• Es de vital importancia el orden en que se establezcan las reglas de NAT,
debido a que si se llegara a establecer una regla mas general antes de una
mas especifica, esta ultima pierde toda validez.
• Se alcanzo el objetivo de reducir costos considerablemente a partir del uso
de software de libre distribución, sin comprometer de ninguna manera el
desempeño o la calidad de los servicios prestados.
• Es importante el uso de herramientas adecuadas como PHP, JavaScript,
AWK, Shell y HTML de acuerdo al objetivo que se busca, ya que cada una
de ellas puede aportar de una mayor forma en un campo especifico. No
existen herramientas generales.
• Las limitaciones impuestas por el hardware usado se ven disminuidas, en
gran parte debido al esquema de software propuesto para esta solución,
dando una mayor vida útil a un equipo de arquitectura X86 que en
condiciones de equipo de escritorio resultaría obsoleto, mientras que como
servidor posee una capacidad plenamente vigente.
56
9 BIBLIOGRAFIA
[1] ANÓNIMO, “Linux Máxima Seguridad Edición Especial”
Prentice Hall
[2] BANDEL David, NAPTER Robert, “Linux Edición Especial 6ta Edición”
Prentice Hall
[3]PRESSMAN Roger S, “Ingeniería del Software, Un enfoque práctico” Cuarta
Edición
Mc Graw Hill
[4] TANENBAUN Andrew S, “Computer Networks” Fourth Edition
Prentice Hall PTR
[5] VÀZQUEZ PÉREZ Xosé. IP Masquerade. [artículo de Internet]
http://www.insflug.org/detalle.php3?comoID=7 [consulta: 1 de abril de 2005]
[6] RUSSELL Paul. Netfilter. [artículo de Internet] http://netfilter.org/ [consulta:
10 de abril de 2005]
[7] HUBERT Bert. Linux Advanced Routing and Traffic Control. [artículo de
Internet] http://lartc.org/ [consulta: 15 de abril de 2005]
[8] GNU. The Linux Documentation Project. [artículo de Internet]
http://www.tldp.org/ [consulta: 15 de abril de 2005]
[9] W3SCHOOLS ONLINE WEB TUTORIALShttp://www.w3schools.com/
57
10 ANEXOS
10.1 Codigos ICMP mas usados
ICMP Tipo ICMP Uso del código 0 0 Respuesta de eco 8 0 Solicitud de eco 3 0 Destino no accesible - Red no accesible 3 2 Destino no accesible - Protocolo no accesible 3 3 Destino no accesible - Puerto no accesible
3 4Destino no accesible - Fragmentación necesaria y
establecer el indicador no fragmentar 4 0 Flujo de origen 5 1 Redirigir - Datagramas redirigidos para el host 9 0 Anuncio de enrutador 10 0 Solicitud de enrutador 11 0 Tiempo excedido - Caducidad de TTL
11 1Tiempo excedido - Caducidad de reensamblaje
de fragmentación 12 0 Problema del parámetro
58
10.2 Glosario
DHCP(Protocolo Dinámico de Configuración de Equipo): Es un protocolo de
comunicaciones que permite a los administradores de red gestionar y automatizar
la asignación de direcciones IP en una red. Sin DHCP, cada dirección IP debe
configurarse manualmente en cada computador y, si el computador se mueve a
otro lugar en otra parte de la red, se debe configurar otra dirección IP diferente. El
DHCP le permite al administrador supervisar y distribuir de forma centralizada las
direcciones IP necesarias, y automáticamente asignar y enviar una nueva IP si el
computador es conectado en un lugar diferente de la red.
Dirección IP (Protocolo de Internet): Es la dirección numérica de un computador
en Internet. Cada dirección IP se asigna a un computador conectado a Internet y
por lo tanto es única. Consiste en un número de 32 bits que suele representarse
como cuatro octetos separados por un punto, como 150.214.90.66.
DSL(Línea del Subscriptor Digital): es una tecnología que toma los datos
digitales, no requiere convertirlos a análogos. Los datos digitales se transmiten
directamente al computador tal como se hace con los datos análogos.
Una línea de DSL puede llevar datos y señales de voz.
Ethernet: Protocolo del nivel de enlace originalmente desarrollado por Xerox y
que está muy difundido en las redes de área local y en otros tipos de redes,
permitiendo la transmisión de datos en un rango de 10 Mbit/s a 1Gbit/s.
Gateway: Dispositivo que conecta dos o más redes permitiendo que la
información de una pase a otra (u otras) según algún criterio, realizando las
conversiones de datos que sean necesarias.
HTTP (HyperText Transfer Protocol ): Es el método utilizado para transferir
archivos hipertexto por Internet. En Internet, las páginas escritas en HTML utilizan
59
el hipertexto para enlazar con otros documentos. Al pulsar en un hipertexto, se
salta a otra página Web, archivo de sonido, o imagen.
ISDN(Integrated Services Digital Network): En español, las siglas son RDSI.
Las líneas ISDN son conexiones realizadas por medio de líneas telefónicas
ordinarias para transmitir señales digitales en lugar de análogas, permitiendo que
los datos sean transmitidos más rápidamente que con un módem tradicional. Las
señales a transportar por la red telefónica usando un mismo canal son voz y datos
(textos, gráficas, videoconferencia, etc.)
LAN (Local Area Network): Red de datos de alta velocidad y baja tasa de error
que cubre una pequeña área geográfica. Las redes LAN conectan estaciones de
trabajo, periféricos, terminales y otros equipos dentro de un edificio u otra área
geográfica limitada.
NAT (Traducción de Direcciones de Red): Su función es rescribir encabezados
de paquetes después de pasar por el cortafuegos y haber sido recibidos por el
enrutador, estos encabezados pueden ser escritos a medida que salen o entran al
enrutador e implica el cambio de la dirección original del sistema que inicia la
conexión por la dirección externa del cortafuegos.
PCI (Peripheral Component Interconnect): Especificación creada por Intel para
la conexión de periféricos a computadores personales. Permite la conexión de
hasta 10 periféricos por medio de tarjetas de expansión conectadas a un bus
local. La especificación PCI puede intercambiar información con la CPU a 32 o 64
bits dependiendo del tipo de implementación.
Proxy: Máquina o sistema intermediario que almacena los URI (Uniform Resource
Identifirer) de las últimas peticiones a los recursos mas solicitados y que son
60
almacenadas para posteriores requerimientos, minimizando el acceso a los
recursos remotos y, por tanto, optimizando el rendimiento del conjunto.
Shell: Elemento de software, que puede ser un programa independiente o
constituir un elemento básico de un sistema operativo. Proporciona una
comunicación directa entre el usuario y el propio sistema operativo, facilitando así,
la ejecución de órdenes o comandos del sistema y de los programas que se
ejecutan en él. Con un shell se busca un uso más simple, generalmente mediante
la utilización de menús, cajas de diálogo y ayudas acerca de su uso o de la
sintaxis de órdenes. Se trata, en definitiva, de la parte del sistema que se muestra
al usuario final, para que interactúe con él.
SSH2(Secure Shell): SSH es un protocolo que permite la conexión a sistemas
*NIX (Linux, Unix, etc) de forma segura. Esto se logra estableciendo un canal
encriptado de comunicación entre el cliente y el servidor mediante el modelo de
intercambio de claves públicas y privadas. Ya que el tráfico está encriptado, no
hay manera de robar información utilizando un sniffer o rastreador. Además ofrece
la ventaja de comprimir la comunicación, haciéndola más ágil.
Actualmente hay dos protocolos de SSH, SSH1 y SSH2 siendo SSH1 el más
veloz y SSH2 el más seguro.
Traffic Shaping (Conformado de tráfico) : Es un mecanismo para controlar el
flujo de datos en una interfaz determinada.
VPN (Virtual Private Network): Es una red privada, fue construida sobre la
infraestructura de una red pública (recurso público, sin control sobre el acceso de
los datos), normalmente Internet. Es decir, en vez de utilizarse enlaces dedicados
(como el X.25 y Frame Relay) para conectar redes remotas, se utiliza la
infraestructura de Internet, una vez que las redes están conectadas es
transparente para los usuarios.
61