ENRUTADOR IP MULTISERVICIO CON CONFIGURACIN VIA WEB

(LXROUTER)

TRG 0501

EDGAR ORLANDO BELTRAN HUERTAS

NELSON ANDRES GUTIERREZ PERDOMO
RAMSES OSIRIS PEDRAZA RINCON

DIRECTOR: ING. FRANCISCO VIVEROS MORENO

BOGOTA D.C.
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERIA
DEPARTAMENTO DE ELECTRNICA

ENRUTADOR IP MULTISERVICIO CON CONFIGURACION VIA WEB

(LXROUTER)

EDGAR ORLANDO BELTRAN HUERTAS

NELSON ANDRES GUTIERREZ PERDOMO
RAMSES OSIRIS PEDRAZA RINCON

Trabajo de Grado presentado como requisito parcial

para optar al ttulo de Ingeniero Electrnico.

Director
Ing. FRANCISCO VIVEROS

BOGOT D.C
PONTIFICIA UNIVERSIDAD JAVERIANA
FACULTAD DE INGENIERA
DEPARTAMENTO DE ELECTRNICA

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERA
CARRERA DE INGENIERA ELECTRNICA

RECTOR MAGNFICO: R.P. GERARDO REMOLINA S.J.

DECANO ACADMICO: Ing. FRANCISCO JAVIER REBOLLEDO MOZ.
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.

Artculo 23 de la resolucin nmero 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 catlica y
porque los trabajos no contengan ataques o polmicas puramente personales.
Antes bien, que se vea en ellos el anhelo de buscar la verdad y la justicia.

A mi madre quien en todo momento ha sido apoyo y consorte para cuanta

meta me he propuesto.
A mi familia por encontrarse presente a lo largo de esta larga empresa que
hoy culmina.
Al doctor Enrique Santamara Hermida por ser la mano invisible que ayud a
forjar mi sueo.
Y por ltimo, pero no por esto menos importante, a mis amigos, sin los
cuales cada tarea y cada proyecto habra perdido el tinte de alegra y
solidaridad que ustedes le dieron.
A Dios, Gracias.

Edgar Orlando Beltrn Huertas

A EL que lo es TODO, me lo ha dado TODO, me ha permitido conocerle y

conocer la VERDADERA FELICIDAD.
A mis Padres, su esfuerzo, comprensin y permanente apoyo.
A mis familiares que de una u otra forma me dieron la fuerza para continuar
en los momentos buenos y malos.
A mis amigos, los que vinieron, los que se fueron, los que aun estn.
Al personal de la Pontificia Universidad Javeriana.
A todos los que de una u otra forma estuvieron ah.
Gracias.
Ramss Osiris Pedraza Rincn

A Dios que me ha dado la fortuna de contar con los medios y personas para
lograr mis metas.
A mi Madre quien supo entender y apoyar mi proceso, en forma constante y
con el amor que siempre la ha caracterizado.
A mi Padre por la paciencia y apoyo constante en este largo de tiempo de
estudios satisfactorios, que aun no culminan.
A Claudia Patricia Gmez Garcia, mi novia, quien por su nobleza y paciencia
me contagi de la calma y tranquilidad necesarias para seguir luchando.
A mis amigos que siempre estuvieron pendientes de mi vida acadmica
como personal, brindando apoyo y ayuda en los momentos difciles.
A los compaeros que ya disfrutan de los frutos de ser ingenieros
electrnicos.
A los empleados de la Facultad que siempre estuvieron ah, eran
indispensables para un mejor desempeo en mis labores.
Gracias.

Nelson Andrs Gutierrez Perdomo

AGRADECIMIENTOS
Los autores expresan sus agradecimientos a:
Ing. Francisco Viveros por su apoyo, gua y preocupacin constante por tener los
mejores medios para la realizacin del trabajo de grado.
Al jefe de seccin de Laboratorio del departamento de Electrnica, Ing. Jorge Luis
Snchez Tllez.
Al Laboratorio por habernos facilitado el equipo para llevar a cabo nuestro trabajo
de grado
Ing. Henry Leonardo Moreno Daz por su resolucin de dudas a cualquier
momento.
Al estudiante Jorge Mario Grimaldos por su resolucin de dudas a cualquier
momento.

TABLA DE CONTENIDO
2METODOLOGA PARA EL DESARROLLO DEL LXROUTER.........................................................5
3ESPECIFICACIONES DEL ENRUTADOR IP (LXROUTER) ............................................................8
4PROBLEMAS ENCONTRADOS......................................................................................................31
5FUTUROS PROYECTOS.................................................................................................................35
6ANLISIS DE RESULTADOS..........................................................................................................36
7ANALISIS DE COSTOS...................................................................................................................54
8CONCLUSIONES.............................................................................................................................56
9BIBLIOGRAFIA................................................................................................................................57
10ANEXOS.........................................................................................................................................58

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 DESPUS 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 CONEXIN FTP............................................................51
FIGURA 31 ASIGNACIN 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

INTRODUCCIN

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 desempeo de todo tipo de empresas, se hace necesario el uso de
equipos con diferentes tecnologas y funciones que en conjunto proporcionen el
ambiente adecuado para el transporte de informacin vital para una organizacin.
En el mercado se ofrecen aparatos independientes para cada etapa del proceso
de creacin de una red; como lo son enrutadores, firewall, servidores de
direcciones; generando as, un costo proporcional al tamao y nivel de tecnologa
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
implcitamente estn generando una dependencia de los mismos en caso de
presentarse daos 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 pequeas y medianas organizaciones, a menudo, se requiere

establecer una red local para la comunicacin 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 coneccin a
varios computadores usando una nica conexin 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 informacin transeferida; para ello es necesario
buscar una solucin viable, de bajo costo, y de sencillo uso que permita establecer

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 estndar.

En el mercado actual, una solucin de este tipo es el Ringdale's Proxy Router and
DHCP Server1 con caractersticas similares a la del dispositivo propuesto, esta por
el orden de los $465 dlares, es decir unos $1.030.000 pesos colombianos, sin
vincular gastos por importacin 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 Ringdaless Proxy router y que si contempla el
LXRouter como los son fcil configuracin va WEB, acceso a 3 puertos, firewall,
entre otros adems de que no existira 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 apreciara
claramente en la comercializacin de la solucin.

La alternativa que se plantea a este tipo de inconvenientes (como lo son el contar

con varios equipos para solventar las necesidades bsicas en la instalacin de
una red LAN), es la integracin de servicios y funciones en un solo dispositivo,
creado a partir de piezas de fcil obtencin en el mercado. Es por esto que se
decide implementar la solucin propuesta en un equipo de cmputo convencional.

http://www.ringdale.com/products/st/asp/control.wizmoreinfo/id.10213/po./en/default.htm

1.1

OBJETIVO GENERAL

Disear un prototipo de enrutador fcilmente configurable a travs de una interfaz

web, ofreciendo aplicaciones adicionales al encaminamiento de paquetes como lo
son el filtrado de conexiones y la optimizacin del trfico web.

1.2

OBJETIVOS ESPECFICOS

Implementar los algoritmos de enrutamiento necesarios para desarrollar

un sistema con capacidad de realizar NAT

(Network Address

Translation) en un equipo de cmputo convencional cuyas interfaces de

red sean soportadas por Linux 2.4.

Disear una interfaz cmoda 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 configuracin por

defecto.

METODOLOGA 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 metodologa de trabajo en la cual se hacen
claras unas etapas:

2.1

Etapa de Ingeniera

2.1.1 Fase de Concepcin

Se define una alternativa econmica para la administracin y seguridad de una
red LAN en una PYME. Se identifica y especifica los requerimientos de uso que
satisfagan las necesidades de red a travs de las experiencias laborales, tomando
las ms comunes e importantes. Se definen tambin los posibles inconvenientes
que se podran presentar a nivel de lenguajes de programacin y configuracin del
hardware en Linux, junto con simplificar al mnimo la interfaz web para la fcil
utilizacin 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 Planeacin de las Fases y de las Iteraciones

A partir de los usos se determina que NAT es el bloque de ms opciones y que

podra presentar mayor dificultad, de esta forma se escogieron que las opciones
principales sern Direccin (Origen, Destino, Cambio), Protocolos (TCP, UDP,

ICMP), y Puertos y/o cdigos. Para SNAT como para DNAT. Se proceder de la
misma forma para firewall, para los servicios adicionales PROXY (Memoria a
utilizar, Tamao del cache), DHCP (Dominio, Interfaz y Rango de Direcciones).

Las pruebas planteadas al momento son de funcionamiento ms que de

capacidad y valores lmite del sistema.

2.1.2 Fase de Elaboracin

Se analiza cmo las opciones de uso seleccionadas afectan el desenvolvimiento
de un usuario inexperto en la interfaz web implementando una serie de ayudas
(activacin y desactivacin de campos) para hacer la correcta configuracin del
enrutador.
A pesar de las incertidumbres generadas por los posibles errores que puede
cometer un usuario inexperto, se hall solucin a la mayora, siendo viable el
continuar con el proyecto. Se hace ms sencillo desarrollar los dems 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 Produccin

2.2.1 Fase de Construccin

Los tiempos se fueron reduciendo en comparacin a los estimados la comenzar,

junto con los costos de elaboracin, principalmente por que se uso cdigo abierto
lo que simplifico la solucin de problemas del mismo a travs de Internet y las
distintas pginas que ofrecen soporte y ayuda para el cdigo abierto2
2.2.2 Fase de Transicin
Mediante la fase de prueba se detectan errores de interpretacin de la sintaxis en
Linux, los cuales se corrigen, debido a que generalmente son una lnea o un
comando mal utilizado.
Para la prueba de rendimiento del enrutador con el Servidor Proxy funcionando,
se utiliz la herramienta HttpTrafficGenerator3 para generar trfico http y
monitorear a la vez el rendimiento de la mquina.
El rendimiento de la mquina se monitoreo con la herramienta TOP que viene con
la distribucin de Linux que estamos usando.
Las pruebas se hicieron desde dos mquinas conectadas directamente al
enrutador, desde las cuales se corria en simultneo el programa generador de
trfico variando la cantidad de paquetes por milisegundo en cada mquina y
obteniendo los casos que se vern descritos en la parte de pruebas.

Ver

bibliografa

http://www.nsauditor.com/

ESPECIFICACIONES DEL ENRUTADOR IP (LXROUTER)

3.1

Generalidades

Este proyecto consiste bsicamente en un dispositivo para enrutar trfico IP4

capaz de ofrecer funcionalidades5 iguales y en algunos casos mejores en relacin
a las propuestas comerciales hoy en da existentes, manteniendo un precio
notablemente reducido y teniendo en mente que el mercado objetivo al que se
desea llegar (en el caso hipottico de que se pueda comercializar a plenitud el
producto) son las pequeas y medianas empresas con necesidades de
comunicacin prioritarias a travs de Internet y que deseen adems obtener
servicios de seguridad como firewalls6 contando con recursos limitados.
Para este fin, se ha subdividido el proyecto en tres partes principales:

NAT (Traduccin de direcciones de red)7

Bsicamente, 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 operacin establecido en este segmento del proyecto se basa en el

rechazo o admisin de paquetes con base en sus direcciones de origen o destino,
o sus puertos. En general se carece de informacin de contexto, las decisiones
son tomadas slo con base en la informacin del paquete en cuestin. En funcin
del enrutador, el filtrado se puede hacer a la entrada, a la salida o en ambos
lados.
4

Para mayor informacin ver Anexo 1 Glosario

NAT, Firewall, Servidor Proxy, configuracin va WEB

Se explica el trmino a continuacin

En el numeral 2.2.3 se explica su funcionamiento

SERVICIOS ADICIONALES8 (Servidor DHCP, Servidor Proxy y Mdulo

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 dinmica, a los usuarios
pertenecientes a la red, agilizando as el proceso de configuracin de equipos.

3.1.2 Servidor Proxy

Con este servidor se busca optimizar el ancho de banda disponible para el trfico
de HTTP y HTTPS (Web y Web seguro respectivamente) haciendo uso del
sistema de cach que este servidor proporciona almacenando la informacin
solicitada con ms frecuencia por parte de los usuarios.

3.1.3 Mdulo de Switch

Con la implementacin de este mdulo, que es transparente para los usuarios y
dems 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 mayora en fase de desarrollo, relacionados con el

Ver Glosario

tema tratado en este trabajo de grado, los cuales vamos a mencionar a

continuacin:

LEAF (Linux Embedded Appliance Firewall)9

Los aspectos ms llamativos de este proyecto son:
Usa una versin 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 fcil de conseguir.
Se pueden adicionar servicios como VPN y SSH2*.

Dentro de los requerimientos mnimos de esta versin se puede encontrar un

procesador 486DX33 con 16Mb de memoria RAM si deseamos usar la versin
"floppy" o 24Mb si usamos la versin "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 bsico 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 tpica de enrutamiento es de 3 a 6 MBits/s, lo cual es
mas que suficiente para el promedio de una conexin tipo cable-modem/xDSL10,
9

Linux Embedded Appliance Firewall

http://sourceforge.net/docman/display_doc.php?docid=8794&group_id=13751
* Para mayor informacin ver Anexo 1 Glosario
10

Variacin de DSL, puede ser ADSL, CDSL, FeeDSL, HDSL, entre otras

* Para mayor informacin ver Anexo 1 Glosario

10

En el caso de los usuarios con conexin PPPoE o una puerta de enlace con
VPN*, la velocidad de transmisin se incrementa si se usan sistemas con
procesador Pentium I, los cuales, adems de lo anterior, poseen ranuras PCI* lo
cual permite el uso de MODEM y tarjetas de red econmicas y fciles 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 rpido y seguro
para evitar la perdida de datos en los discos de configuracin e inicio si el sistema
llegara a colisionar; si esto llega a ocurrir, bastara simplemente con reiniciar el
sistema, el cual volvera a su configuracin original. En caso de dao en el
hardware, como se utiliza hardware genrico y comercial, su reemplazo es fcil de
obtener.

Actualmente se encuentran dos variaciones derivadas del proyecto LEAF,

Dachtein y Oxygen, adems de variaciones que usan como base el LEAF, que
permiten encontrar documentacin 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 travs 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
implementacin y facilidad de uso, teniendo en cuenta que los recursos
disponibles para ser ejecutado son bastante limitados. Se llega a la
conclusin que dicho compromiso se daba casi en su totalidad con el uso
del software de cdigo abierto DNSMASQ12 .

SQUID13 fue la herramienta seleccionada para la instauracin del Servidor

Proxy, debido a que el usuario final no tendr que intervenir muchos de sus
parmetros de configuracin, brindando as, un ambiente amable y
eficiente.

Para la interfaz Web, se decidi utilizar varios lenguajes de programacin

debido a las ventajas que unos ofrecen sobre otros, es el caso de PHP14
para la creacin de tablas dinmicas y Apache15 para su hospedaje en el

11

http://netfilter.org/

12

http://www.thekelleys.org.uk/dnsmasq/doc.html

13

http://www.squid-cache.org/
http://squid.visolve.com/squid/sqguide.htm
http://www.icewalkers.com/Linux/Software/54580/Squid.html

14

http://www.php.net/

15

http://apache.org/

13

Enrutador, JavaScript16 para el uso de mens selectivos por parte del

cliente y HTML17 como la base para reunir los mencionados anteriormente,
adems de BASH18 y AWK196 para ejecutar los comandos de sistema.

Dentro de la interfaz WEB se contempl la posibilidad de un pequeo

asistente de configuracin, que le permite al usuario nuevo iniciar el uso del
Enrutador IP sin ninguna restriccin.

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 direccin 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
mquina puede retomar los valores que por defecto utiliza para su normal
funcionamiento, es por esto que se lleva a cabo la programacin de un
Script (restaurar_script.sh) que lo que hacen es simplemente descomprimir
los

archivos

de

configuracin

original

previamente

guardados

sobreescribir los archivos de configuracin actualmente en uso con la

informacin contenida en los archivos de configuracin original. Este Script
ser ejecutado despus de ser usada la combinacin de las teclas CTRLALT-SUPR.

16

http://www.gamarod.com.ar/javascript/menu.asp
http://www.w3schools.com/js

17

Ver Glosario

18

http://www.gnu.org/

19

14

3.3

SNTESIS DEL ENRUTADOR IP (LXROUTER)

El Enrutador IP ser el encargado de establecer los parmetros de conexin entre

un grupo de computadores comunicados entre s (LAN) y el acceso a Internet.
Para ello cuenta con mdulos como los son el Switch, Firewall, NAT, Servidor de
Direcciones (DHCP) y el Servidor Proxy; los cuales evalan los criterios de
conexin dados por el usuario administrador del Enrutador IP a travs la Interfaz
WEB.
Mdulo
de Configuracin

LAN

INTERFAZ
WEB

I
Enrutador

IP

T
E
R

SWITCH
FIREWALL
NAT
DHCP
PROXY
Mdulo
de Funcionamiento

15

N
E
T

Figura 1 Diagrama general de funcionamiento.

3.4

MDULO DE CONFIGURACIN

En esta parte se encontrar la forma mediante la cual el usuario personalizar la

configuracin de los diferentes servicios que presta el Enrutador IP, dependiendo
de las necesidades que presente. Para ello se ha dispuesto un asistente de
configuracin rpida y bsica.

3.5

MDULO DE FUNCIONAMIENTO

En esta parte, bsicamente se comentar la forma en que el Enrutador IP ejecuta

las funciones para las cuales fue diseado.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 haran en
cualquier otro Switch comercial.
A travs de este programa es posible hacer que el arreglo de tarjetas de red
respondan a una misma direccin tanto IP como MAC, logrando de esta manera
que el trfico destinado a una interfaz de red sea dirigido a sta y no a todas en
simultneo evitando as posibles colisiones.

20

Ir al ANEXO: Manual de Usuario

21

http://bridge.sourceforge.net/

16

IN

OUT

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 localizacin fsica se encuentra,
estableciendo de esta forma la conexin directa, a diferencia de un HUB que
enviara la conexin primero a los clientes intermedios hasta llegar al destino
(MAC 1 a MAC 2 a MAC 3).
3.5.2 FIREWALL
Mediante este mdulo es posible filtrar las conexiones originadas tanto de dentro
hacia afuera como de afuera hacia adentro del Enrutador IP basados en
parmetros como el protocolo (TCP22 - UDP23) y su puerto de origen o destino, o
cdigo ICMP24. Permitiendo de esta forma aceptar o descartar dicha conexin.

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

17

Tal filtrado consiste en aceptar, descartar o rechazar la conexin descrita a travs

de los diferentes parmetros ya mencionados. Vale la pena aclarar que la
diferencia entre los dos ltimos consiste en que mientras rechazar enva una seal
de control a quien origin la conexin explicando que sta no pudo ser realizada,
la accin de descartar simplemente anula dicho intento de conexin sin avisar
previamente a ninguna parte. Por motivos de seguridad, la accin que se debe
elegir si se desea eliminar una conexin 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 razn 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 opcin rechazar solo ha sido contemplada por motivos de
flexibilidad ante los requerimientos propios de cada usuario.
Ahora bien, para continuar con la configuracin del mdulo de firewall se presenta
cual es la diferencia entre una regla y una poltica. Bsicamente una regla
describe una conexin en funcin de ciertos parmetros (direccin de origen, de
destino, protocolo, puerto de origen, de destino o cdigo, segn sea necesario) y
establece una accin a ejercer con la misma, es decir, si por ejemplo se adiciona
una regla en la cual se describe una direccin de origen y un puerto de destino, y
existe una conexin que cumpla dichos criterios, entonces el firewall ejerce la
accin que para dicha regla haba sido propuesta por el usuario. Sin embargo, si
no existe una regla para dicha conexin, entonces se ejecuta la poltica. Esta
poltica consiste en ejecutar la misma accin de una regla, pero al ser la ms
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 caracterstica es consecuencia de la forma en la cual trabaja el mdulo, 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 poltica. Sin
embargo, si el usuario desea borrar una regla por estar en desacuerdo con ella, o
por haberla ingresado de manera errnea, puede hacerlo a travs de la interfaz

18

Web, la cual a su vez modificar un archivo de texto que posteriormente ser

procesado a travs de un script en lenguaje AWK 25, para finalmente generar las
reglas en lenguaje SHELL26 que sern interpretadas por el sistema.
Dicho proceso se ejecuta usando el software IPTABLES27 versin 1.2.11 para
Kernel 2.4.29 disponible para Slackware Linux v.10.1
A continuacin 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.html

26

http://www.gnu.org/software/bash/bash.html

27

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
travs de varios enlaces diferentes. Ninguno de estos enlaces altera realmente el
paquete: simplemente lo envan un paso adelante.
Si uno de estos enlaces hiciera NAT, podra alterar el origen o destino del paquete
segn pasa a travs suyo. Normalmente, el enlace que est haciendo NAT
recordar cmo manipul el paquete, para hacer la accin 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 mdem a Internet
La mayora de los PSI (Proveedor de Servicios de Internet) dan una sola
direccin IP cuando se conecta con ellos. Puede enviar paquetes con
cualquier direccin, pero slo obtendr respuesta a los paquetes con esa IP
de origen. Si desea utilizar varias mquinas diferentes (como una red
casera) para conectar a Internet a travs de un enlace, necesita NAT.
Este es, el uso ms comn de NAT hoy en da, conocido normalmente
como Enmascaramiento (masquerading) en el mundo de Linux. Tambin
llamado SNAT, porque se cambia la direccin 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 slo tiene una direccin IP, pero se
desea que la gente sea capaz de llegar a las mquinas detrs de la IP que
tiene a la IP real. Si se rescribe el destino de los paquetes entrantes, se
podr conseguir.
Una variante comn de esto es el balanceo de carga, en la cual se toma un
cierto nmero de computadores, repartiendo los paquetes entre ellos. Este

22

tipo de NAT se llam reenvo 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 informacin viene del firewall, una vez lo cruza
entra a NAT, especficamente a DNAT, aqu es donde se evalan los aspectos
concernientes al destino de los paquetes o la conexin; ejecuta las reglas y
polticas que se hayan configurado, incluso tambin existe la posibilidad de que el
paquete pase sin tocarlo; posteriormente entra a SNAT, y all es donde se
evalan los aspectos concernientes al origen de los paquetes o la conexin; y de

23

all sale a los dems 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 poltica, es aquella que se aplica a los paquetes que no se
estn especificando y se aplica una configuracin por defecto, generalmente es
dejar intacto el paquete.
Posteriormente se evala y se pregunta por la Direccin, Puerto y Protocolo. En
las reglas se especifican las tres caractersticas, si en algn momento el paquete
no cumple con alguna se descarta la aplicacin de la regla que se ha configurado,
y se le aplica la poltica por defecto, y no se sigue evaluando los dems
parmetros, 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 conexin a travs de los parmetros IP de origen, puerto

y protocolo. Si esta conexin reune completamente dichos parmetros, se
procede a ejecutar la accin de DNAT la cual consiste en cambiar la direccin 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 informacin de configuracin

(direccin IP, Mscara de red, direccin de broadcast) dinmicamente desde un

28

servidor de protocolos. Se utiliza posteriormente la herramienta DNSMASQ, la

cual permite determinar parmetros como autorizacin para acceder al servicio y
tiempo de asignacin adems de los anteriormente nombrados.
3.5.5 SERVIDOR PROXY

Figura 9 Diagrama general de funcionamiento.

Bsicamente el servicio de PROXY se implementa para disminuir el tiempo de

espera por parte de los usuarios al acceder a algn tipo de informacin que
recientemente fue solicitada, adems 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 conexin, la memoria
destinada al almacenamiento de datos en disco y en memoria RAM, integrar el
servicio de Firewall al proceso en cuestin y establecer reglas de control.

29

En algunas ocasiones es necesario simular que cada paquete que pase por la
mquina Linux est destinado a un programa en la propia mquina. 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 comunicndose 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
redireccin o proxy transparente en anteriores versiones de Linux.
Las reglas especficas para que funcionen en la implementacin 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
implementacin del Proxy Transparente.

30

4
4.1

PROBLEMAS ENCONTRADOS
NAT

Orden de Reglas y Polticas: Al disear la interfaz Web no se tuvo en cuenta que

las reglas que se introducen para la configuracin, deben listarse de las ms
especifica a la ms general, ya que el programa usado (IPTABLES), para efectuar
estos cambios lo requiere as, de otra forma las reglas especificas que estn
despus de una mas general, aunque se cargaran y las aceptara el programa, no
tendrn efecto deseado de configuracin, y ser prcticamente como si no se
hubieran configurado.
Interfaz Web: Al comenzar la programacin de la interfaz Web en los lenguajes
htm, php y javascript; se presentaron inconvenientes por falta de conocimiento
ms extenso de los lenguajes de programacin utilizados, posteriormente, debido
a la sintaxis del interprete de comandos de Linux, no se permita 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
configuracin satisfactoria, evitando mezclar parmetros que no tienen nada que
ve entre s, como por ejemplo lo son protocolo TCP y Cdigod ICMP.
Sintaxis de Linux: Al querer introducir la direccin por la cual se desea cambiar la
conexin, el intrprete de comandos no aceptaba como correcta la configuracin,
por sintaxis.
Como solucin; la direccin 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 travs de este se interpreten las dems direcciones
como hostname y la regla se pueda adicionar.

31

Adicionalmente mltiples problemas de menor complejidad, que se corrigieron en

el momento en el que surgan; en aspectos como el orden en que se introducen y
capturan los datos para permitir un proceso ms sencillo al momento de manipular
la informacin y entregarla al intrprete de comandos como una instruccin y que
la sintaxis sea aceptada como vlida.

4.2

Trfico Real

Segn se pudo apreciar en las pruebas realizadas con respecto al trfico HTTP
que an a 4000 solicitudes por segundo y usando un sistema Proxy para acelerar
el mencionado trfico, 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 haba determinado en el Servidor de Direcciones, razn
por la cual era imposible otorgar las direcciones a quienes las requeran. La
solucin fue configurar la interfaz de Switch (arreglo de tarjetas) con una direccin
IP y mascara de red dentro del rango de direcciones que ofrecera el Servidor de
Direcciones.

Por

esa

razn

se

concluy

que

es

necesario

asignar

automticamente como direccin IP del Switch la primera direccin IP del rango

de direcciones del Servidor DHCP.

32

4.4

Shell Scripts28 y Servidor WEB

En esta ocasin 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 corran de la manera adecuada, razn 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 distribucin y viene incluido
por defecto con la versin de Linux que actualmente se esta usando.

4.5

Circuito de Reset

Inicialmente se tena dispuesta la elaboracin de un circuito de reset por

hardware, esto para que el LXROUTER fuera definitivamente solo una torre (sin
perifricos) y diera la verdadera apariencia de un router comercial. Se elaboraron
los Scripts necesarios para la restauracin de la maquina a su configuracin por
defecto. Despus de hacerse la primera restauracin, se not que en el proceso
de inicio de la maquina, apareca un estado de donde no poda continuar sin el
teclado conectado, propio del procedimiento que realizan la mayora de Tarjetas
Madre (Board) al iniciar el sistema. Por esta razn se hacia intil la elaboracin del
Circuito de Reset por Hardware y la solucin mas viable fue la configuracin de
una secuencia de teclas (CTRL+ALT+SUPR) que realizaran la misma funcin del
circuito de Reset Original, sin el inconveniente de la desconexin de perifricos.
Adicionalmente se pens en utilizar el Circuito de Reset propio de la torre para el
mismo objetivo, pero nuevamente se caa en el mismo problema de desconexin
de perifricos.
Una tercera alternativa era dar la seal 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 Shell

29

http://www.courtesan.com/sudo/

33

monitoreando continuamente si exista la seal de reset y sin contar con el

persistente problema de desconexin de perifricos.

34

FUTUROS PROYECTOS

5.1

VPN

VPN (Virtual Private Network): Es una red privada, fue construida sobre la
infraestructura de una red pblica (recurso pblico, 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 estn 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 travs 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 segn 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 implementacin, 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.html

31

http://sourceforge.net/projects/htbinit/

35

PRUEBAS

DE

SOLICITUDES

HTTP

SIN

EL

SERVIDOR

ACTIVADO
Recursos disponibles con 4000 solicitudes HTTP
por segundo (2 PCs directamente conectados
2000+2000)
Porcentaje de
recursos
disponibles

6.1

ANLISIS DE RESULTADOS

Promedio:
89.09%

94
92
90
88
86
84

Series1

10

Tiempo en segundos

Figura 10 Recursos disponibles con 4000 solicitudes

Recursos disponibles con 2000 solicitudes HTTP

por segundo (2 PCs directamente conectados
1000+1000)
Porcentaje de
recursos
disponibles

Promedio:
92.04%

100
95

Series1
90
85
1

10

Tiempo en segundos

Figura 11 Recursos disponibles con 2000 solicitudes

36

PROXY

Recursos disponibles con 1000 solicitudes

HTTP por segundo (1 PC directamente
conectado)
Promedio:
94.78%

Porcentaje de
recursos
disponibles

96
95
94

Series1

93
92
91
1

10

Tiempo en segundos

Figura 12 Recursos disponibles con 1000 solicitudes

PRUEBAS DE SOLICITUDES HTTP CON EL SERVIDOR PROXY

ACTIVADO
Recursos disponibles con 4000 solicitudes
HTTP por segundo (2 PCs directamente
conectados 2000+2000)
Promedio:
70.8%

80
Porcentaje de
recursos
disponibles

6.2

75
70

Series1

65
60
1

10 11

Tiempo en segundos

Figura 13 Recursos disponibles con 4000 solicitudes

37

Recursos disponibles con 2000 solicitudes

HTTP por segundo (2 PCs directamente
conectados 1000+1000)
Promedio:
79.63%

Porcentaje de
recursos
disponibles

90
85
80

Series1

75
70
1

10 11

Tiempo en segundos

Figura 14 Recursos disponibles con 2000 solicitudes

Porcentaje de
recursos
disponibles

Recursos disponibles con 1000 solicitudes

HTTP por segundo (1 PC directamente
conectado)
93
92
91
90
89
88
87

Promedio:
91.36%
Series1

10 11

Tiempo en segundos

Figura 15 Recursos con 1000 solicitudes

Como conclusin de stas pruebas podemos aclarar que obviamente el tiempo de

respuesta para el usuario disminuye, pero lo ms importante es que a pesar de
que se ejecuta el Servidor Proxy, el rendimiento de la mquina 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 pgina de ISTEC

se le reenvi a la pgina de Triton de ingeniera electrnica, esto se debe
hacer en DNAT:
I. Para este caso se debe agregar una regla en la que se obliga a
enmascarar la conexin 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
trminos de las IP, debemos pasar la conexin por el puerto DNS para
que se encargue de traducir el nombre a IP. Se usa la pgina 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 conexin para que tenga salida y acceso a
la red. De lo contrario su conexin estara bloqueada. En origen la IP del
cliente interno, en destino la direccin de la pgina de triton, y no es
necesario adicionar mas campos.

Figura 17 Ejemplo Enmascaramiento.

III. Ahora si para hacer la traduccin deseada: solo es necesario usar los
campos de direcciones, en origen la IP del cliente de red interna, destino

40

la

direccin de ISTEC y en cambiar por la direccin 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

Bsicamente se comprob la funcionalidad del mismo a travs 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 disearon los procedimientos que se presentan a
continuacin:

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 cdigo 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

Segn 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 rehsa 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 responda sin problemas al ping realizado
desde una mquina 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 cdigo
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

mquina cliente y se revisa la respuesta obtenida (Figura No. 26):

Figura 26 Respuesta a un ping despus de la regla para descartar

48

Segn 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 accin ordenada.
6.4.3 Descartar FTP34

Para este caso se muestra como inicialmente la conexin desde un cliente

funciona sin ningn problema (Figura No. 27) antes de aadir 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 conexin FTP desde el mismo cliente hacia el

LXROUTER y se obtiene el siguiente resultado (Figura No. 30):

Figura 30 Respuesta a intento de conexin FTP

51

Segn se puede apreciar, la conexin fall y no pudo establecerse, tal como era
de esperarse en consecuencia a la regla que previamente se haba ingresado.

6.5
Para

SERVIDOR DE DIRECCIONES
comprobar

la

funcionalidad

del

Servidor de

Direcciones

(DHCP),

simplemente se conecta un cliente a una de las interfaces configuradas como

Switch. Se solicita una direccin IP y se verifica que la misma este dentro del
rango que previamente se haba suministrado a travs de la interfaz WEB.

Figura 31 Asignacin 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 direccin no existente.
Debido a que no se esta enmascarando por defecto, es decir, esta no es la
poltica aplicada, la nica forma de navegacin que resta a los clientes es a travs
de servidor Proxy, dado que al navegar hacia una pgina existente, no se produce
ningn 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
continuacin:

Figura 32 Prueba del Servidor Proxy

53

ANALISIS DE COSTOS
Tabla 1 Tabla de costos actualizados

RECURSOS
HUMANOS
Director trabajo de
grado

HORAS X
PERSONA

17 semanas * 2h
17 semanas *40h
Desarrolladores
*3
TOTAL RECURSOS HUMANOS

EQUIPO
CANTIDAD
Componentes Varios
Varios
CPU
1
Tarjetas de Red PCI
3
Computador en Alquiler
1
TOTAL EQUIPO
PAPELERA
CANTIDAD
Papel
2*500 hojas
Fotocopias
1000
Empaste
3
Cartucho
2
Disco Compacto
10
Diskette
10
TOTAL PAPELERIA
LICENCIAS DE
SOFTWARE
CANTIDAD
Linux 2.4
1
Apache
1
PHP
1
SSL
1
TOTAL LICENCIAS DE SOFTWARE
SERVICIO DE
INTERNET
Cablenet
4 Meses
TOTAL SERVICIOS INTERNET
COSTOS INDIRECTOS CANTIDAD
Energa
1000 horas
Transporte
600 viajes
TOTAL COSTOS INDIRECTOS
OTROS
Imprevistos
TOTAL OTROS

54

VALOR
HORA

TOTAL

$50,000

$1,700,000

$10,000

$20,400,000
$22,100,000

VALOR
UNIDAD
$700,000
$7,000
VALOR
UNIDAD
$8,000
$35
$4,000
$60,000
$1,000
$1,000
VALOR
UNIDAD
$0.00
$0.00
$0.00
$0.00
VALOR
UNIDAD
$88,000
VALOR
UNIDAD
$161
$1,000

TOTAL
$30,000
$700,000
$21,000
$600,000
$1,351,000
TOTAL
$16,000
$35,000
$12,000
$120,000
$10,000
$10,000
$203,000
TOTAL
$0.00
$0.00
$0.00
$0.00
$0.00
TOTAL
$352,000
$352,000
TOTAL
$161,000
$600,000
$761,000
$0
$0

TOTAL COSTOS

$24,767,000

Los costos tuvieron una reduccin 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 ingeniera electrnica.

55

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 distribucin, sin comprometer de ninguna manera el
desempeo 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 solucin,
dando una mayor vida til a un equipo de arquitectura X86 que en
condiciones de equipo de escritorio resultara obsoleto, mientras que como
servidor posee una capacidad plenamente vigente.

56

BIBLIOGRAFIA

[1] ANNIMO, Linux Mxima Seguridad Edicin Especial

Prentice Hall
[2] BANDEL David, NAPTER Robert, Linux Edicin Especial 6ta Edicin
Prentice Hall
[3]PRESSMAN Roger S, Ingeniera del Software, Un enfoque prctico Cuarta
Edicin
Mc Graw Hill
[4] TANENBAUN Andrew S, Computer Networks Fourth Edition
Prentice Hall PTR
[5] VZQUEZ PREZ Xos. IP Masquerade. [artculo de Internet]
http://www.insflug.org/detalle.php3?comoID=7 [consulta: 1 de abril de 2005]
[6] RUSSELL Paul. Netfilter. [artculo de Internet] http://netfilter.org/ [consulta:
10 de abril de 2005]
[7] HUBERT Bert. Linux Advanced Routing and Traffic Control. [artculo de
Internet] http://lartc.org/ [consulta: 15 de abril de 2005]
[8] GNU. The Linux Documentation Project. [artculo de Internet]
http://www.tldp.org/ [consulta: 15 de abril de 2005]
[9] W3SCHOOLS ONLINE WEB TUTORIALS
http://www.w3schools.com/

57

10 ANEXOS
10.1 Codigos ICMP mas usados

ICMP
0
8
3
3
3

Tipo ICMP
0
0
0
2
3

4
5
9
10
11

0
1
0
0
0

11

12

Uso del cdigo

Respuesta de eco
Solicitud de eco
Destino no accesible - Red no accesible
Destino no accesible - Protocolo no accesible
Destino no accesible - Puerto no accesible
Destino no accesible - Fragmentacin necesaria y
establecer el indicador no fragmentar
Flujo de origen
Redirigir - Datagramas redirigidos para el host
Anuncio de enrutador
Solicitud de enrutador
Tiempo excedido - Caducidad de TTL
Tiempo excedido - Caducidad de reensamblaje
de fragmentacin
Problema del parmetro

58

10.2 Glosario
DHCP(Protocolo Dinmico de Configuracin de Equipo): Es un protocolo de
comunicaciones que permite a los administradores de red gestionar y automatizar
la asignacin de direcciones IP en una red. Sin DHCP, cada direccin 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 direccin IP diferente. El
DHCP le permite al administrador supervisar y distribuir de forma centralizada las
direcciones IP necesarias, y automticamente asignar y enviar una nueva IP si el
computador es conectado en un lugar diferente de la red.
Direccin IP (Protocolo de Internet): Es la direccin numrica de un computador
en Internet. Cada direccin IP se asigna a un computador conectado a Internet y
por lo tanto es nica. Consiste en un nmero de 32 bits que suele representarse
como cuatro octetos separados por un punto, como 150.214.90.66.
DSL(Lnea del Subscriptor Digital): es una tecnologa que toma los datos
digitales, no requiere convertirlos a anlogos. Los datos digitales se transmiten
directamente al computador tal como se hace con los datos anlogos.
Una lnea de DSL puede llevar datos y seales 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 transmisin de datos en un rango de 10 Mbit/s a 1Gbit/s.
Gateway: Dispositivo que conecta dos o ms redes permitiendo que la
informacin de una pase a otra (u otras) segn algn criterio, realizando las
conversiones de datos que sean necesarias.
HTTP(HyperText Transfer Protocol ): Es el mtodo utilizado para transferir
archivos hipertexto por Internet. En Internet, las pginas escritas en HTML utilizan

59

el hipertexto para enlazar con otros documentos. Al pulsar en un hipertexto, se

salta a otra pgina Web, archivo de sonido, o imagen.
ISDN(Integrated Services Digital Network): En espaol, las siglas son RDSI.
Las lneas ISDN son conexiones realizadas por medio de lneas telefnicas
ordinarias para transmitir seales digitales en lugar de anlogas, permitiendo que
los datos sean transmitidos ms rpidamente que con un mdem tradicional. Las
seales a transportar por la red telefnica usando un mismo canal son voz y datos
(textos, grficas, videoconferencia, etc.)
LAN (Local Area Network): Red de datos de alta velocidad y baja tasa de error
que cubre una pequea rea geogrfica. Las redes LAN conectan estaciones de
trabajo, perifricos, terminales y otros equipos dentro de un edificio u otra rea
geogrfica limitada.
NAT (Traduccin de Direcciones de Red): Su funcin es rescribir encabezados
de paquetes despus 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 direccin original del sistema que inicia la
conexin por la direccin externa del cortafuegos.
PCI(Peripheral Component Interconnect): Especificacin creada por Intel para
la conexin de perifricos a computadores personales. Permite la conexin de
hasta 10 perifricos por medio de tarjetas de expansin conectadas a un bus
local. La especificacin PCI puede intercambiar informacin con la CPU a 32 o 64
bits dependiendo del tipo de implementacin.
Proxy: Mquina 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 bsico de un sistema operativo. Proporciona una
comunicacin directa entre el usuario y el propio sistema operativo, facilitando as,
la ejecucin de rdenes o comandos del sistema y de los programas que se
ejecutan en l. Con un shell se busca un uso ms simple, generalmente mediante
la utilizacin de mens, cajas de dilogo 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 interacte con l.
SSH2(Secure Shell): SSH es un protocolo que permite la conexin a sistemas
*NIX (Linux, Unix, etc) de forma segura. Esto se logra estableciendo un canal
encriptado de comunicacin entre el cliente y el servidor mediante el modelo de
intercambio de claves pblicas y privadas. Ya que el trfico est encriptado, no
hay manera de robar informacin utilizando un sniffer o rastreador. Adems ofrece
la ventaja de comprimir la comunicacin, hacindola ms gil.
Actualmente hay dos protocolos de SSH, SSH1 y SSH2 siendo SSH1 el ms
veloz y SSH2 el ms seguro.
Traffic Shaping (Conformado de trfico): 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 pblica (recurso pblico, 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 estn conectadas es
transparente para los usuarios.

61