RED DE SERVIDORES

REUNIONES DEL PROYECTO

2008-06-05T05:15:00.000-07:00

MARTES 27 MAYO DIA 1...

Este día se inicio con la reunión de grupo donde se recordaron las metas que se tenían acordadas por servicio, se propuso un cronograma donde mas o menos se acordó lo siguiente:

SEMANA 1 = Se pretende trabajar en el servicio asignado; dejando todo muy claro entre los integrantes pata asi lograr con mayor facilidad la transmisión de lo aprendido.
SEMANA 2 = Se integraran todos los servicios grupo por grupo de la siguiente manera:
MARTES: Ftp y Dns.
MIÉRCOLES: Dhcp
JUEVES: Proxy
VIERNES: Web
SEMANA 3 = Se iniciara el montaje de cada servicio en la red, en un orden especifico o simultáneamente como sea necesario.

En esta reunión se presentaron propuestas en la forma de trabajo y los espacios de practicas y ensayos como fue la utilización del aula 5-7 en un horario de 12m-5pm

Cada grupo se reunio a proyectar tareas y reasignaciones segun el servicio a montar.

RED DE SERVIDORES

2008-05-30T08:42:00.000-07:00

¿ QUE ES REDMAX ?

2008-05-30T07:51:00.000-07:00

REUNIONES

2008-05-29T09:20:00.000-07:00

27 MAYO DE 2008
PRIMERA REUNION

En esta reunión se cito a todos los integrantes del proyecto donde básicamente:

se recordó metas de cada uno de los servicios

pequeño cronograma a corto plazo en la integración de servicios el cual en se sintetizo

1 SEMANA = se pretende trabajar de lleno en el servicio asignado

2 SEMANA= se hara la integración de todos los servicios grupo por grupo.de la siguiente manera:
MARTES: ftp y dns

MIERCOLES: dhcp

JUEVES: proxy

VIERNES: web

3 SEMANA= se comenzara a montar cada servicio en la red real.en el orden que sea necesario se a pensado que se debe hacer simultaneamente.

En esta reunion se presentaron propuestas en la forma de trabajo y los espacios de practicas y ensayos como fue la utilizacion del salon 5-7 en un horario de 12m-5pm

y por ultimo se explico de parte del grupo de estructura de red como quedo la red montada, su direccionamiento y convenio con cada servicio para asignarle los segmentos en que se necesitan trabajar. luego de esto cada grupo se reunio a proyectar tareas y reasignaciones segun el servicio a monta

REQUERIMIENTOS DEL PROYECTO

2008-05-29T06:25:00.001-07:00

OBJETIVO GENERAL

obtener de forma practica y haciendo uso de la metodologia de formacion por proyectos, todas las competencias (tecnicas y transversales) requeridas para culminar el ciclo formativo de configuracion de servidores.

OBJETIVOS ESPECIFICOS

generar un proyecto a partir de los datos (requerimientos) proporcionados por los instructores del area que se encuentran cursando actualmente.

simular el proyecto con el fin de garantizar el funcionamiento en la parte teorica.

realizar el montaje practico del proyecto y exponerlo al finalizar el proyecto.

REQUERIMIENTOS

1. Esquema logico de la red:

2. Infraestructura de red

2 servedores DHCP, uno para hacer relay.

2 servidores DNS, donde uno de los dos funciona como esclavo del otro

1. servidor DNS,que controle una zona diferente al anterior.

3 servidores WEB, que contenga la siguiente informacion:

1. un portal informativo de los grupos 940176 - 78 - 79.
2. blog del proceso de desarrollo del proyecto (imagenes,videos, etc).
3. servidor con informacion aleatoria.

3 servidores FTP configurados asi:

1. servidor para usuarios (todos los aprendices del grupo).
2. servidor de acceso anonimo (todas la herramientas usadas del royecto)
3. servidor para usuario con enjaulamiento.

2 servidores PROXY configurados como hermanos para la salida a internet, con:

todas las lan´s deben navegar sin restrincciones los lunes y viernes.
la lan 4 no puedes salir a internet los dias miercoles.
solo los usuarios de la lan 2 pueden salir a internet.
la lan 1 no puede salir al msn.
existen 5 sitios prohibidos para todas las lan´s, no pueden navegar aellos.
la lan 3 solo puede navegar los jueves de 8:00am-12:00m
la lan 5 puede navegar siempre, pero no puede descargar archivos .mp3,
.avi, .mpge, .ogg, .zip, .exe.

1 servidor NTP que actualize

la fecha y hora automaticamente de todas las maquinas utilizadas en el proyecto.

OTROS REQUISITOS

El proyecto dede recrear el trabajo de una compañia real:

1. identidad empresarial: nombre de empresa, logo, etc...
2. cotizacion del proyecto, mano de obra, equipos, etc...
3. costos totales, parciales, empleados, cargos, etc...
4. tiempo estimado del proyecto, programacion cronologica del trabajo.

se deben respaldar todos los archivos de configuracion de servidores en un FTP.

se deben respaldar todos los archivos de configuracion de switches y routers.

todas las maquinas usadas en el proyecto deben de estar actualizadas a la fecha.

las contraseñas y nombres de usuarios deben de estar correctamente asignados.

se debe respaldar la simulacion de la red.

se deben documentar las experiencias particulares en los blogs personales.

se debe actualizar el blog del grupo de acuerdo a la evolucion del proyecto.

en el diseño de los servidores se debe hacer servidores en windows, linux y solaris.

el particionamiento de discos debe ser seguro para evitar perdidas de datos.

por lo menos un servidor debe ser maquina virtual.

se deben garantizar que los clientes puedan ser maquinas en linux, windows y solaris.

el uso de las vlan´s es opcional.

sincronizar los servidores DHCP y DNS,s para que trabajen en conjunto.

realizar dos cortos acerca de lo que se va a tratar el proyecto, el primero en ingles y el segundo en español.

ESTRUCTURA DE LA RED

2008-05-29T06:24:00.001-07:00

INFRAESTRUCTURA DE LA RED

DOCUMENTACIÓN DE LA RED

Esta es una red wan la cual esta basada en la topología estrella extendida ya que todos los ordenadores no están conectados directamente a un dispositivo central si no a varios puntos subcentrales. Esta conformada por cinco routers los cuales van estructurados de la siguiente manera: El router de Medellín es el principal, en el va directamente conectado el router de bogota y el router de Cali, por medio de enlace serial. El router de Medellín tiene subinterfaces que da salida a vlans, estas vlans están conformadas por tres switch de los cuales cada uno tiene dos subredes, dos de estos switch están conectados por cable de fibra óptica y el otro por cable utp cruzado, cada switch tiene dos vlans, cada subred tiene capacidad para conectarle máximo 14 host. Todas las subredes tiene diferente direccionamiento.Las subredes de Medellin van conectadas al controlador de internet (router).

El controlador se conecta al proveedor de internet (router) y tiene dos vlans las cuales serán asignada para algunos servicios.

El proveeedor es en realidad el que nos permite el acceso a internet.El router de Cali y de Bogota tienen 2 vlans.

DIRECCIONAMIENTO DE LA RED

Identificador de red:192.15.15.0

Mascara por defecto:255.255.255.0

Broadcast:192.168.1.255

Tomamos 4 bits prestados de los host para las subredes y los 4 bits restantes son para los host.

2^4 -2 =16 – 2 = 14 máximo subredes 2^4 -2 =16 – 2 = 14 máximo host

Mascara de subred.
11111111..11111111.11111111.11110000
255.255.255.240

COMBINACION	IDENTIFICADOR DE SUBRED	BROADCAST
0000
0011	192.168.1.00010000 192.168.1.16	192.168.1.000.11111 192.168.1.131
0010	192.168.1. 00100000 192.168.1.32	192.168.1.00101111 192.168.1.47
0011	192.168.1.00110000 192.168.1.48	192.168.1.00111111 192.168.1.63
0100	192.168.1.01000000 192.168.1.64	192.68.1.01001111 192.168.1.79
0101	192.168.1.01010000 192.168.1.80	192.168.1.01011111 192.168.1.95
0110	192.168.1.01100000 192.168.1.96	192.168.1.01101111 192.168.1.111
0111	192.168.1.01110000 192.168.1.112	192.168.1.01111111 192.168.1.127
1000	192.168.1.10000000 192.168.1.128	192.168.1.10001111 192.168.1.143
1001	192.168.1.10010000 192.168.1.144	192.168.1.10011111 192.168.1.159
1010	192.168.1.10100000 192.168.1.160	192.168.1.10101111 192.168.1.175
1011	192.168.1.10110000 192.168.1.176	192.168.1.10111111 192.168.1.191
1100	192.168.1.11000000 192.168.1.192	192.168.1.11001111 192.168.1.207
1101	192.168.1.11010000 192.168.1.208	192.168.1.11011111 192.168.1.223
1110	192.168.1.11100000 192.168.1.224	192.168.1.11101111 192.168.1.239
1111

FTP

2008-05-29T06:23:00.000-07:00

FTP

Es un protocolo de transferencia de archivos entre sistemas conectados a una red TCP basado en la arquitectura cliente-servidor, de manera que desde un equipo cliente nos podemos conectar a un servidor para descargar archivos desde él o para enviarle nuestros propios archivos independientemente del sistema operativo utilizado en cada equipo.

El Servicio FTP es ofrecido por la capa de Aplicación del modelo de capas de red TCP/IP al usuario, utilizando normalmente el puerto de red 20 y el 21. Un problema básico de FTP es que está pensado para ofrecer la máxima velocidad en la conexión, pero no la máxima seguridad, ya que todo el intercambio de información, desde el login y password del usuario en el servidor hasta la transferencia de cualquier archivo, se realiza en texto plano sin ningún tipo de cifrado, con lo que un posible atacante puede capturar este tráfico, acceder al servidor, o apropiarse de los archivos transferidos.

Para solucionar este problema son de gran utilidad aplicaciones como scp y sftp, incluidas en el paquete SSH, que permiten transferir archivos pero cifrando todo el tráfico.

Modelo del FTP

Servidor FTP

Un servidor FTP es un programa especial que se ejecuta en un equipo servidor normalmente conectado a Internet (aunque puede estar conectado a otros tipos de redes, LAN, MAN, etc.). Su función es permitir el intercambio de datos entre diferentes servidores/ordenadores.

Por lo general, los programas servidores FTP no suelen encontrarse en los ordenadores personales, por lo que un usuario normalmente utilizará el FTP para conectarse remotamente a uno y así intercambiar información con él.

Las aplicaciones más comunes de los servidores FTP suelen ser el alojamiento web, en el que sus clientes utilizan el servicio para subir sus páginas web y sus archivos correspondientes; o como servidor de backup (copia de seguridad) de los archivos importantes que pueda tener una empresa. Para ello, existen protocolos de comunicación FTP para que los datos se transmitan cifrados, como el SFTP (Secure File Transfer Protocol).

Cliente ftp

Cuando un navegador no está equipado con la función FTP, o si se quiere cargar archivos en un ordenador remoto, se necesitará utilizar un programa cliente FTP. Un cliente FTP es un programa que se instala en el ordenador del usuario, y que emplea el protocolo FTP para conectarse a un servidor FTP y transferir archivos, ya sea para descargarlos o para subirlos.

Para utilizar un cliente FTP, se necesita conocer el nombre del archivo, el ordenador en que reside (servidor, en el caso de descarga de archivos), el ordenador al que se quiere transferir el archivo (en caso de querer subirlo nosotros al servidor), y la carpeta en la que se encuentra.

Algunos clientes de FTP básicos en modo consola vienen integrados en los sistemas operativos, incluyendo Windows, DOS, Linux y Unix. Sin embargo, hay disponibles clientes con opciones añadidas e interfaz gráfica. Aunque muchos navegadores tienen ya integrado FTP, es más confiable a la hora de conectarse con servidores FTP no anónimos utilizar un programa cliente

Acceso anónimo

Los servidores FTP anónimos ofrecen sus servicios libremente a todos los usuarios, permiten acceder a sus archivos sin necesidad de tener un 'USERID' o una cuenta de usuario. Es la manera más cómoda fuera del servicio web de permitir que todo el mundo tenga acceso a cierta información sin que para ello el administrador de un sistema tenga que crear una cuenta para cada usuario.

Acceso de usuario

Si se desea tener privilegios de acceso a cualquier parte del sistema de archivos del servidor FTP, de modificación de archivos existentes, y de posibilidad de subir nuestros propios archivos, generalmente se suele realizar mediante una cuenta de usuario. En el servidor se guarda la información de las distintas cuentas de usuario que pueden acceder a él, de manera que para iniciar una sesión FTP debemos introducir un login y un password que nos identifica unívocamente.

Acceso de invitado

El acceso sin restricciones al servidor que proporcionan las cuentas de usuario implica problemas de seguridad, lo que ha dado lugar a un tercer tipo de acceso FTP denominado invitado (guest), que se puede contemplar como una mezcla de los dos anteriores.

La idea de este mecanismo es la siguiente: se trata de permitir que cada usuario conecte a la máquina mediante su login y su password, pero evitando que tenga acceso a partes del sistema de archivos que no necesita para realizar su trabajo, de esta forma accederá a un entorno restringido, algo muy similar a lo que sucede en los accesos anónimos, pero con más privilegios.

Como instalar un servidor ftp en windows:

Cuando estamos en windows server 2003 entramos por inicio, panel de control, agregar o quitar programas, agregar o quitar componentes de windows, en esta lista buscamos servidor de aplicaciones y sin seleccionar el check box lo señalamos y damos clic en detalles luego instalar internet information server (IIS), los seleccionamos sin chequear el check box y damos clic en detalles alli seleccionamos el check box de administrador de servicios de internet information server (por defecto el check box de archivos comunes se activa), también activamos servicio de protocolo de transferencia de archivos (ftp), luego le damas aceptar, aceptar y siguiente luego de haber empezado con la instalación nos va a pedir el cd de instalación de windows, lo ingresamos y le damos aceptar y ya tenemos instalado nuestro servicio ftp.

Configuracion del servidor ftp

Inicio, panel de control, herramientas administrativas, y seleccionamos administrador de internet information services (IIS). en este menú procedemos a configurar nuestro servidor ftp.

Desplegamos en el lado izquierdo de la pantalla el servidor, allí aparece una carpeta llamada sitios FTP, la desplegamos, nos aparece un sitio FTP predeterminado, le damos clic derecho y luego en propiedades. en esta ventana podemos cambiar la descripcion en la pestañas sitio FTP, también asignarle una dirección ip (recuerda que para un mejor funcionamiento, los servidores deben tener una dirección ip estatica), también se puede poner el puerto por el cual va a correr nuestro FTP (puerto 21 por defecto).

En la pestaña "cuentas de seguridad" puedes señalar el check box de permitir conexiones anónimas para que cualquier persona ingrese a nuestro sitio FTP a quitarlo para que solo ingresen los usuarios del sistema.

En la pestaña "directorio particular" cuando ya estamos en el menú señalamos la opción servicios de internet information server, tambien puedes cambiar la ruta de acceso local la cual es donde van a estar alojados los archivos de FTP.

Después de que utilices y organices tu sitio FTP puedes aplicar los cambios dando clic en aceptar.

Para crear los usuarios que quieres que accedan a tu sitio FTP.

Inicio, clic derecho en mi pc, clic derecho en administrar, desplegamos usuarios y grupos locales y en usuarios damos clic derecho y usuario nuevo. allí llenamos los espacios con la información correcta y damos clic en crear.
Después de crear todos los usuarios cerramos todo.

DNS

2008-05-29T06:22:00.002-07:00

(DOMAIN NAME SISTEM)

DHCP

2008-05-29T06:22:00.001-07:00

(DINAMIC HOST PROTOCOL)

DHCP (sigla en inglés de Dynamic Host Configuration Protocol) es un protocolo de red que permite a los nodos de una red IP obtener sus parámetros de configuración automáticamente. Se trata de un protocolo de tipo cliente/servidor en el que generalmente un servidor posee una lista de direcciones IP dinámicas y las va asignando a los clientes conforme éstas van estando libres, sabiendo en todo momento quién ha estado en posesión de esa IP, cuánto tiempo la ha tenido y a quién se la ha asignado después.

Características
Provee los parámetros de configuración a las computadoras conectadas a la red informática con la pila de protocolos TCP/IP (Máscara de red, puerta de enlace y otros) y también incluyen mecanismo de asignación de direcciones de IP.
Este protocolo se publicó en octubre de 1993, estando documentado actualmente en la RFC 2131. Los últimos publicados como RFC 3415.

Asignación de direcciones IP
Sin DHCP, cada dirección IP debe configurarse manualmente en cada computadora y, si la computadora 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 la computadora es conectado en un lugar diferente de la red.

El protocolo DHCP incluye tres métodos de asignación de direcciones IP:

Asignación manual o estática: Asigna una dirección IP a una máquina determinada. Se suele utilizar cuando se quiere controlar la asignación de dirección IP a cada cliente, y evitar, también, que se conecten clientes no identificados.

Asignación automática: Asigna una dirección IP de forma permanente a una máquina cliente la primera vez que hace la solicitud al servidor DHCP y hasta que el cliente la libera. Se suele utilizar cuando el número de clientes no varía demasiado.

Asignación dinámica: el único método que permite la reutilización dinámica de las direcciones IP. El administrador de la red determina un rango de direcciones IP y cada computadora conectada a la red está configurada para solicitar su dirección IP al servidor cuando la tarjeta de interfaz de red se inicializa. El procedimiento usa un concepto muy simple en un intervalo de tiempo controlable. Esto facilita la instalación de nuevas máquinas clientes a la red.
Algunas implementaciones de DHCP pueden actualizar el DNS asociado con los servidores para reflejar las nuevas direcciones IP mediante el protocolo de actualización de DNS establecido en RFC 2136 (Inglés).
El DHCP es una alternativa a otros protocolos de gestión de direcciones IP de red, como el BOOTP (Bootstrap Protocol). DHCP es un protocolo más avanzado, pero ambos son los usados normalmente.
En Windows 98 o posterior, cuando el DHCP es incapaz de asignar una dirección IP, se utiliza un proceso llamado "Automatic Private Internet Protocol Addressing".

Parámetros configurables
Un servidor DHCP puede proveer de una configuración opcional a la computadora cliente. Dichas opciones están definidas en RFC 2132 (Inglés)
Lista de opciones configurables:

* Dirección del servidor DNS
* Nombre DNS
* Puerta de enlace de la dirección IP
* Dirección de Publicación Masiva (broadcast address)
Máscara de subred
* Tiempo máximo de espera del ARP (Protocolo de Resolución de Direcciones según siglas en inglés)
* MTU (Unidad de Transferencia Máxima según siglas en inglés) para la interfaz
* Servidores NIS (Servicio de Información de Red según siglas en inglés)
* Dominios NIS
* Servidores NTP (Protocolo de Tiempo de Red según siglas en inglés))
* Servidor SMTP
* Servidor TFTP
* Nombre del servidor WINS

Implementaciones
Microsoft introdujo el DHCP en sus Servidores NT con la versión 3.5 de Windows NT a finales de 1994. A pesar de que la llamaron una nueva función no fue inventada por ellos.
El Consorcio de Software de Internet (ISC: Internet Software Consortium) publicó distribuciones de DHCP para Unix con la versión 1.0.0 del ISC DHCP Server el 6 de diciembre de 1997 y una versión (2.0) que se adaptaba mejor al RFC el día 22 de junio de 1999.

Otras implementaciones importantes incluyen:

* Cisco: un servidor DHCP habilitado en Cisco IOS 12.0 en el mes de febrero de 1999
* Sun: añadió el soporte para DHCP a su sistema operativo Solaris el 8 de julio de 2001.
Además, varios routers incluyen soporte DHCP para redes de hasta 255 computadoras.

Anatomía del protocolo
Esquema de una sesión típica DHCP
(Autoridad de Números Asignados en Internet según siglas en inglés) en BOOTP: 67/UDP para las computadoras servidor y 68/UDP para los clientes.

DHCP Discovery
El cliente envía un paquete DHCPDISCOVER. Las direcciones IP origen y destino de dicho paquete serán 0.0.0.0 y 255.255.255.255 (broadcast) respectivamente. El servidor almacena los campos del paquete CHADDR (dirección Ethernet origen, MAC) y el de identificación del cliente.

DHCP Offer
El servidor determina la configuración basándose en la dirección del soporte físico de la computadora cliente especificada en el registro CHADDRvbnv. El servidor especifica la dirección IP en el registro YIADDR. Como la cual se ha dado en los demás parámetros.

DHCP Request
El cliente selecciona la configuración de los paquetes recibidos de DHCP Offer. Una vez más, el cliente solicita una dirección IP específica que indicó el servidor

DHCP Acknowledge
Cuando el servidor DHCP recibe el mensaje DHCPREQUEST del cliente, que inicia la fase final del proceso de configuración. Esta fase implica el reconocimiento DHCPACK el envío de un paquete al cliente. Este paquete incluye el arrendamiento de duración y cualquier otra información de configuración que el cliente pueda tener solicitada. En este punto, la configuración TCP / IP proceso se ha completado.
El servidor reconoce la solicitud y la envía acuse de recibo al cliente. El sistema en su conjunto espera que el cliente para configurar su interfaz de red con las opciones suministradas.

DHCP Release
Los clientes envían una petición al servidor DHCP para liberar su dirección IP. Como los clientes generalmente no de broadcast. El router puede ser configurado para redireccionar los paquetes DHCP a un servidor DHCP en una subred diferente. La implementación cliente crea un paquete UDP (Protocolo de Datagramas de Usuario según siglas en inglés) con destino 255.255.255.255 y requiere también su última dirección IP conocida, aunque esto no es necesario y puede llegar a ser ignorado por el servidor.

DHCP ACK
El servidor DHCP responde a la DHCPREQUEST con un DHCPACK, completando así el ciclo de iniciación. La dirección origen es la dirección IP del servidor de DHCP y la dirección de destino es todavía 255.255.255.255. El campo YIADDR contiene la dirección del cliente, y los campos CHADDR y DHCP: Client Identifier campos son la dirección física de la tarjeta de red en el cliente. La sección de opciones del DHCP identifica el paquete como un ACK.

DHCP Inform
El cliente envía una petición al servidor de DHCP: para solicitar más información que la que el servidor ha enviado con el DHCPACK original; o para repetir los datos para un uso particular - por ejemplo, los browsers usan DHCP Inform para obtener la configuración de los proxies a través de WPAD. Dichas peticiones no hacen que el servidor de DHCP refresque el tiempo de vencimiento de IP en su base de datos.

VLAN

Una VLAN (acrónimo de Virtual LAN, ‘red de área local virtual’) es un método de crear redes lógicamente independientes dentro de una misma red física. Varias VLANs pueden coexistir en un único conmutador físico o en una única red física. Son útiles para reducir el dominio de colisión y ayudan en la administración de la red separando segmentos lógicos de una red de área local (como departamentos de una empresa) que no deberían intercambiar datos usando la red local (aunque podrían hacerlo a través de un enrutador).

Una 'VLAN' consiste en una red de ordenadores que se comportan como si estuviesen conectados al mismo cable, aunque pueden estar en realidad conectados físicamente a diferentes segmentos de una red de área local. Los administradores de red configuran las VLANs mediante software en lugar de hardware, lo que las hace extremadamente flexibles. Una de las mayores ventajas de las VLANs surge cuando se traslada físicamente algún ordenador a otra ubicación: puede permanecer en la misma VLAN sin necesidad de ninguna reconfiguración hardware.

WEB

2008-05-29T06:21:00.005-07:00

DIA 1

Desde hoy comenzo la cuenta regresiva; nos reunimos el grupo con nuestro coordinador richard y acordamos que tareas teniamos para este dia; como no todos estabamos actualizados y de que era lo que exactamente debiamos hacer concordamos con documentarnos sobre el tema del servidor web; que herramientas necesitabamos y como era la configuracion del servicio en el sistema operativo solaris express. La tension comenzo a hacerse sentir en todos pero de igual manera todos nos comprometimos.

DIA 2

En este dia cada uno de los integrantes del grupo comento lo investagado y aclaramos algunas dudas.Tambien le comentamos al profesor fernando que nos sentiamos demasiado perdidos en el servidor web,el profe nos aclaro un poco algunas dudas.Despues nos quedemos por la tarde en el salon del otro grupo y tambien subimos a averiguar con algunos profesoresellos nos aclaron unas dudas pero casi todos no entendian mucho de sistema operativo solaris. Quedamos en investigar mas para poder entender del servidor web.Tambien intentamos instalarlo pero los comandos que teniamos no se reconocian.

DIA 3

En este dia hablamos con el profesor porque nos sentiamos demasiado perdidos y teniamos muchas dudas, y el nos dijo que no era nada dificil. Luego el profesor camilo nos explico algunos pasos para instalar el servidor web. Despues estudiamos un poco de la instalacion pero en debian y paso por paso lo instalamos y nos dio y nos parecio facil pero la pagina no nos dio porque no teniamos un servidor dns. Pero ya hoy entendimos un pco mas, Tambien subimos a tecnoparque y instalamos el sistema operaivo solaris en un computador de tecnoparque para poder hacer practicas alli.

DIA 4

Hoy practicamos un poco de la instalacion y tambien le preguntamos a unos estudiantes de programacion sobre los programas que podemos utilizar para montar una pagina web,un portal y un blog, y nos dieron ejemplo de dos programs pero no nos explicaron muy bien porque ellos no han llegado hasta ese punto.

DIA 5

Hoy sabado comenzamos a programar una pagina web en codigo html con cosas de la empresa la pagina no esta terminada porque solo es un intento. Luego hablamos con el profesor de que programas podiamos utilizar para el portal nos hablo de dos de mambo y joomla pero obtamos por joomla, este solamente seria como la plantilla porque nosotros tenemos que programarlo con las cosas que nesecitamos lo dificil esque nosotros no sabemos manejar este programa pero bueno todo se puede.

DIA 6

En este dia comenzamos a mirar como se puede trabajar en el programa de joomla para entenderlo y utilizarlo. Tambien hablamos con camilo que es uno de los encargados para explicar a los apredices sena que esten en tecnoparque y el nos dijo que en el dia de mañana nos explicarialos servicios pero cada uno pr acticando.

DIA 7

En este dia primero subimos a tecnoparque para mirar de que manera estara estructurada la red y se presenatron algunos problemas pero que se pueden solucionar. Luego el profesor explico el dhcp y nos dijo que es la manera mas facil de hacerlo en el proyecto, Luego subimos a tecnoparque para atender a la explicacion de los servicios.

DIA 8

E este dia nos encontramos en tecnoparque para la explicacion del servidor ftp en windows server 2003 el cual explicaron paso por paso la instalacion y configuracion,luego cada grupito se dividio para trabajar en lo que le corresponde.

DIA 9

En este dia nos explicaron la instalacion y configuracion del servidor ftp en linux el cual nos quedo muy claro pero tenemos que seguier bucando mas informacion. despues hablamos sobre el proyecto ara que cada quien buscara mas informacion y en el dia de mañana organizar todo lo que encontraramos para poder arrancar con mas bases.

DIA 10

En este dia cuando llegamos practicamos la instalacion del sevidor web en solaris nos parecio un poco complicado porque ni las rutas ni los comandos son iguales entonces se nos complico todo. pero averiguaos con algunas personas y nos dieron aclararon algunas dudas pero no muchas porque las personas en realidad no saben mucho de solaris.

DIA 11

En este dia y creo que toda la semana estaremos ocupados practicando los servicios porque tenemos examen final y los del otro salon tambien entonces creo que esta semana ensi con el proyecto poco, aunque practicar sevicios es del proyecto.

DIA 12

Hoy buscamos mas cosas de joomla porque en realidad no entendemos de como comenzar a hacer este porat y tampoco de como subirlo al servidor web esto se nos esta complicando y lo peor esque el sistema operativo solaris no es muy conocido por las personas que le hemos preguntado.

DIA 13

En este dia en realidad no hicimos mucho del proyecto porque realizamos el examen practico de los servicios y en realidad a los que lo hicieron no les fue nada bien solo a uno. y del proyecto pues cada quien investigo cosas porque en realidad solo teniamos cabeza para el examen.

DIA 14

PROXY

2008-05-29T06:21:00.003-07:00

Servidor Proxy:

Conocido también como servidor intermediario es una computadora o dispositivo que permite el ingreso de manera indirecta a las paginas Web, es decir, el trabaja como un muro de seguridad puesto que en el administrador ingresa todas aquellas paginas que no deseamos que se ejecuten.

Durante el proceso ocurre lo siguiente:

Cliente se conecta hacia un Servidor Intermediario (Proxy).

Cliente solicita una conexión, fichero u otro recurso disponible en un servidor distinto

Servidor Intermediario (Proxy) proporciona el recurso ya sea conectándose hacia el servidor especificado o sirviendo éste desde un caché.

En algunos casos el Servidor Intermediario (Proxy) puede alterar la solicitud del cliente o bien la respuesta del servidor para diversos propósitos.

El servidor intermediario opera en el nivel de red como filtro de paquetas y en el nivel de aplicación como controlador de diversos servicios. Trabaja como una memoria cache del contenido de red principalmente http, proporcionando al cliente un cache de páginas y ficheros disponibles y un acceso de forma rápida y confiable. Cuando se recibe una petición para un recurso de Red especificado en un URL (Uniform Resource Locator) el Servidor Intermediario busca el resultado del URL dentro del caché. Si éste es encontrado, el Servidor Intermediario responde al cliente proporcionado inmediatamente el contenido solicitado. Si el contenido solicitado no estuviera disponible en el caché, el Servidor Intermediario lo traerá desde servidor remoto, entregándolo al cliente que lo solicitó y guardando una copia en el caché. El contenido en el caché es eliminado luego a través de un algoritmo de expiración de acuerdo a la antigüedad, tamaño e historial de respuestas a solicitudes (hits)

Squid:

Es un servidor intermediario utilizado en sistemas operativos como GNU/Linux y derivado de Unix. Es muy confiable, robusto y versátil y se distribuye bajo los términos de la Licencia Pública General GNU (GNU/GPL).

Squid puede funcionar como Servidor Intermediario (Proxy) y caché de contenido de Red para los protocolos HTTP, FTP, GOPHER y WAIS, Proxy de SSL, caché transparente, WWCP, aceleración HTTP, caché de consultas DNS y otras muchas más como filtración de contenido y control de acceso por IP y por usuario.

GOPHER: es un servicio de Internet consistente en el acceso a la información a través de menús. La información se organiza de forma arborescente: sólo los nodos contienen menús de acceso a otros menús o a hojas, mientras que las hojas contienen simplemente información textual. En cierto modo es un predecesor de la Web, aunque sólo se permiten enlaces desde nodos-menús hasta otros nodos-menús o a hojas, y las hojas no tienen ningún tipo de hiperenlaces.

WAIS: Siglas de Wide Area Information Servers. El WAIS es un servicio de búsqueda de información en la red por palabra clave o frases. Contrariamente a Gopher, que busca ficheros por sus títulos, los motores WAIS buscan en el texto completo de cada fichero y devuelve una lista de todos los documentos que contengan la palabra clave indicada. La mayor parte de los buscadores en el Web utiliza el método WAIS.

El squid consiste en un programa principal como servidor que proporciona la búsqueda en servidores DNS, contiene programas opcionales para reescribir solicitudes y autenticación y herramienta para administración y cliente. La búsqueda en servidores DNS reduce el tiempo de espera al cliente.

NOTA ESPECIAL: Squid no debe ser utilizado como Servidor Intermediario (Proxy) para protocolos como SMTP, POP3, TELNET, SSH, IRC, etc. Si se requiere intermediar para cualquier protocolo distinto a HTTP, HTTPS, FTP, GOPHER y WAIS se requerirá implementar obligatoriamente un enmascaramiento de IP o NAT (Network Address Translation) o bien hacer uso de un servidor SOCKS como Dante.

Por medio del parámetro cache_replacement_policy squid incluye soporte para los siguientes algoritmos para cache:

LRU: Acrónimo de Least Recently Used - Menos Recientemente Utilizado; este algoritmo elimina los accesos menos utilizado dejando en la cache las mas recientes.

LFUDA: Acrónimo de Least Frequently Used with Dynamic Aging – Menos Frecuentemente Utilizado con Envejecimiento Dinámico; en este algoritmos los mas utilizado permanecen en la cache sin importar su tamaño, de modo que un objeto grande que se solicite con mayor frecuencia impedirá que se pueda hacer caché de objetos pequeños que se soliciten con menor frecuencia.

GDSF: Acrónimo de GreedyDual Size Frequency - Frecuencia de tamaño GreedyDual (codicioso dual); este algoritmo optimiza la eficiencia permitiendo que en la cache se mantengan los objetos pequeños mas frecuentes, es decir, trabaja tiene una eficiencia por octeto menor al LFUDA por ello elimina los objetos mas grandes de la cache.

Para la utilización de squid se necesita la versión 2.5.STABLE6 ninguna anterior porque se considera que no son seguras. Squid no se instala de manera predeterminada a menos que especifique lo contrario durante la instalación del sistema operativo, sin embargo viene incluido en casi todas las distribuciones actuales. El procedimiento de instalación es exactamente el mismo que con cualquier otro sustento lógico.

Configuración:

Squid utiliza el fichero de configuración localizado en /etc/squid/squid.conf, y podrá trabajar sobre este utilizando su editor de texto simple preferido. Existen un gran número de parámetros, de los cuales recomendamos configurar los siguientes:

• http_port

• cache_dir

• Al menos una Lista de Control de Acceso

• Al menos una Regla de Control de Acceso

• httpd_accel_host

• httpd_accel_port

• httpd_accel_with_proxy

Parámetro http_port:

Según las asignaciones por IANA los Puertos Registrados para el servidor intermediario son 3128 o 8080 a través de TCP. Por defecto squid maneja el puerto 3128 para atender peticiones sin embargo se puede definir cualquier otro puerto u otros puertos disponibles.

Para servidores intermediarios transparente utiliza los puertos 80 o el 8000 se valdrá del re-direccionamiento de peticiones de modo tal que no habrá necesidad alguna de modificar la configuración de los clientes HTTP para utilizar el Servidor Intermediario (Proxy), esto bastara con utilizar en al puerta de enlace el servidor pero no se puede olvidar que le servidor http también utiliza dichos puertos por lo tanto será necesario volver a configurar el servidor http para asignarle otros puertos disponibles. En la actualidad los servidores intermediarios transparentes no son muy convenientes, por ello puede resultar mas conveniente configurar un servidor intermediario con restricciones por clave de acceso lo cual no puede realizarse con un servidor intermediario transparente debido a que se requiere un diálogo de nombre de usuario y clave de acceso.

Regularmente algunos programas que utilizan los usuarios comúnmente traen por defecto el puerto 8080 (servicio de cache WWW), podemos especificar que squid escuche peticiones en dicho puerto también utilizando http_port y se especifica lo siguiente:

# Default: http_port 3128

http_port 3128

http_port 8080

Si desea incrementar la seguridad, puede vincularse el servicio a una IP que solo se pueda acceder desde la red local. Así:
#default: http_port 3128

http_port (dirección IP):3128

http_port (dirección IP):8080

Parámetro cache_men:

Establece la cantidad ideal de memoria para lo siguiente:

• Objetos en tránsito.

• Objetos frecuentemente utilizados (Hot).

• Objetos negativamente almacenados en el caché.

Los datos se almacenan en bloque de 4 Kb; y este parámetro especifica el límite del máximo del tamaño de los bloque acomodados, donde los objetos en tránsito tienen mayor prioridad, pero los objetos de los host utiliza la cache mientras que ese espacio no se necesite; en caso si un objeto en tránsito es mayor a la capacidad de la cache squid excederá lo que sea necesario para satisfacer la petición.

Si se posee un servidor con al menos 128 MB de RAM, establezca 16 MB como valor para este parámetro:

Cache_mem 16 MB

Parámetro cache_dir:

Este parámetro se utiliza para establecer que tamaño se desea que tenga el caché en el disco duro para Squid. Se puede incrementar el tamaño del caché hasta donde lo desee el administrador. Mientras más grande sea el caché, más objetos se almacenarán en éste y por lo tanto se utilizará menos el ancho de banda. Se utiliza el siguiente parámetro:

Cache_dir ufs/var/spool/squid 100 16 256

Los números 16 y 256 significan que el directorio del caché contendrá 16 directorios subordinados con 256 niveles cada uno. No modifique esto números, no hay necesidad de hacerlo. Es muy importante considerar que si se especifica un determinado tamaño de caché y éste excede al espacio real disponible en el disco duro, Squid se bloqueará inevitablemente. Sea cauteloso con el tamaño de caché especificado.

Parámetro ftp_user:

Al acceder a un servidor FTP de manera anónima, de modo predefinido Squid enviará como clave de acceso Squid@. Si se desea que el acceso anónimo a los servidores FTP sea más informativo, o bien si se desea acceder a servidores FTP que validan la autenticidad de la dirección de correo especificada como clave de acceso, puede especificarse la dirección de correo electrónico que uno considere pertinente.

ftp_user proxy@su-dominio. Net

Controles de acceso:

Es necesario establecer Listas de Control de Acceso que definan una red o bien ciertas máquinas en particular. A cada lista se le asignará una Regla de Control de Acceso que permitirá o denegará el acceso a Squid.

Lista de control de acceso: Regularmente una lista de control de acceso se establece con la siguiente sintaxis:

acl (nombre de la lista) src (lo que compone a la lista)

Si se desea establecer una lista de control de acceso que abarque a toda la red local, basta definir la IP correspondiente a la red y la máscara de la sub-red.

acl miredlocal src (dirección ip)/(mascar de subred)

También puede definirse una Lista de Control de Acceso especificando un fichero localizado en cualquier parte del disco duro, y la cual contiene una lista de direcciones IP.

acl permitidos src “/etc/squid/permitidos”

El fichero /etc/squid/permitidos contendría algo como siguiente:

        192.168.1.1

               192.168.1.2

               192.168.1.3

               192.168.1.15

               192.168.1.16

               192.168.1.20

               192.168.1.40

      Reglas de control de acceso:

Estas definen si se permite o no el acceso hacia Squid. Se aplican a las Listas de Control de Acceso. Deben colocarse en la sección de reglas de control de acceso definidas por el administrador, es decir, a partir de donde se localiza la siguiente leyenda:

INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS

La sintaxis básica es la siguiente:

http_access  (deny o allow)  (lista de control de acceso)

Nota: También pueden definirse reglas valiéndose de la expresión !, la cual significa no. Este tipo de reglas son útiles cuando se tiene un gran grupo de IP dentro de un rango de red al que se debe permitir acceso, y otro grupo dentro de la misma red al que se debe denegar el acceso.

Parámetro cache_mgr:

De modo predefinido, si algo ocurre con el caché, como por ejemplo que muera el procesos, se enviará un mensaje de aviso a la cuenta webmaster del servidor. Puede especificarse una distinta si acaso se considera conveniente.

cache_mgr joseperez@midominio.net

Parámetro cache_peer:

El parámetro cache_peer se utiliza para especificar otros Servidores Intermediarios (Proxies) con caché en una jerarquía como padres o como hermanos. Es decir, definir si hay un Servidor Intermediario (Proxy) adelante o en paralelo. La sintaxis básica es la siguiente:

Cache_peer (servidor) (tipo) (http_port) (icp_port) (opciones)

Para configurar como padre se utiliza:

Cache_peer (dirección ip) parent 8080 3128 proxy-only

Para configurar como hermano se utiliza:

Cache_peer (dirección ip) sibling 8080 3128 proxy-only

Cache con aceleración:

Cuando un usuario hace petición hacia un objeto en Internet, este es almacenado en el caché de Squid. Si otro usuario hace petición hacia el mismo objeto, y este no ha sufrido modificación alguna desde que lo accedió el usuario anterior, Squid mostrará el que ya se encuentra en el caché en lugar de volver a descargarlo desde Internet.

Esta función permite navegar rápidamente cuando los objetos ya están en el caché de Squid y además optimiza enormemente la utilización del ancho de banda.

En la sección HTTPD-ACCELERATOR OPTIONS deben habilitarse los siguientes parámetros:

httpd_accel_host virtual

httpd_accel_port 0

httpd_accel_with_proxy on

Idioma:

Squid incluye traducción a distintos idiomas de las distintas páginas de error e informativas que son desplegadas en un momento dado durante su operación. Dichas traducciones se pueden encontrar en /usr/share/squid/errors/. Para poder hacer uso de las páginas de error traducidas al español, es necesario cambiar un enlace simbólico localizado en /etc/squid/errors para que apunte hacia /usr/share/squid/errors/Spanish en lugar de hacerlo hacia /usr/share/squid/errors/English.

Elimine primero el enlace simbólico actual:

rm-f  /etc/squid/errors

Coloque un nuevo enlace simbólico apuntando hacia el directorio con los ficheros correspondientes a los errores traducidos al español.

ln -s /usr/share/squid/errors/Spanish /etc/squid/errors

Iniciando, reiniciando y añadiendo el servicio al arranque del sistema.

Una vez terminada la configuración, ejecute el siguiente mandato para iniciar por primera vez Squid:

               Service squid start

      Si necesita reiniciar para probar cambios hechos en la configuración, utilice lo siguiente:

               Service squid restart

      Si desea que Squid inicie de manera automática la próxima vez que inicie el sistema, utilice lo siguiente:

chkconfig squid on

Depuración de errores:

Puede realizar diagnóstico de problemas indicándole a Squid que vuelva a leer configuración, lo cual devolverá los errores que existan en el fichero /etc/squid/squid.conf.

service squid reload

Cuando se trata de errores graves que no permiten iniciar el servicio, puede examinarse el contenido del fichero /var/log/squid/squid.out con el mandato less, more o cualquier otro visor de texto:

less /var/log/squid/squid.out

Parámetro VISIBLE_HOSTNAME

En este parámetro se configura un nombre, no es muy relevante el nombre pero si es importante configurarlo, porque si no causara un error

parametro icp_port

Este parámetro define el puerto en que el servidor squid recibe solicitudes ICP (Inter-Cache Protocol). Si se desea desacivar se le asigna el valor de cero en le parámetro,

parametro cache_swap_low.

Indica el nivel en porcentaje de capacidad mínima aceptada por squid, es decir, los objetos se mantendrán en el cache hasta que se cope el límite mínimo

Parámetro cache_swap_high

Parámetro que especifica en porcentaje el límite máximo que utiliza squid para mantener objetos en el cache.

Parametro cache_access_log

Especifica en que directorio se realizará el registro de accesos al squid.

Parametro cache_log.

Define en donde se almacenan los mensajes del sistema

Parámetro cache_store_log

Este parámetro especifica la ubicación del archivo de registro de objetos sacados del cache. No es necesario activarlo. Es mejor desactivarlo para ahorrar espacio en disco

Parámetro emulate_httpd_log

Este parámetro define si se desea utilizar emulación de logs del servidor web (httpd).

parametro reference_age.

Este parámetro determina cuanto tiempo permanece el objeto en el cache. Se recomiendo que sea un mes

Parámetro quick_abort

Este parámetro define si un objeto debe almacenarse en el cache cuando el usuario ha interrumpido una solicitud: si el objeto tiene el valor especificado en min o falta más del valor expecificado en max se abortará la transferencia. Si se ha realizado una transferencia mayor del valor en porcentaje especificado en pct, no se abortará el almacenamiento del objeto. Se recomienda utilizar los valores por defecto (16kb tanto para min como para max y 95 para pct)

Parámetro negative_ttl.

Este parámetro se utiliza para definir cuanto tiempo debe esperar squid para procesar nuevamente una página que no ha sido encontrada. Se recomiendan 5 minutos.

Parámetro positive_dns_ttl.

Este parámetro especifica el tiempo que squid mantendrá la dirección de un sitio visitado exitosamente. El valor por defecto es de 6 horas

Parámetro negative_dns_ttl

Especifica el tiempo que espera squid antes de intentar nuevamente determinar la dirección de un sitio solicitado y que no ha sido encontrado. Por defecto 5 minutos.

Parámetro http_access e icp_access

Define una serie de permisos para acceso al servidor squid. Recomendamos utilizar la siguiente configuración:

http_access allow manager localhost
http_access deny manager
http_access allow CONNECT !SSL_ports
http_access allow all
icp_access allow all
miss_access allow all

parametro httpd_accel_uses_host_header.

Este parámetro se utiliza para activar el proxy transparente, necesario para controlar el acceso a Internet desde las estaciones.

Parámetro httpd_accel_host y httpd_accel_port.

Este parámetro también es necesario para activar el proxy transparente. Al configurar squid de esta manera no es necesario realizar configuración de los navegadores del centro de acceso con servidor proxy lo que se constituye en una ventaja

Parámetro dns_testnames

Este parámetro define que hosts se utilizan para chequear el servidor de nombres

Parámetro append_domain

Este parámetro indica a squid que dominio debe añadirse a solicitudes que vengan sin dominio completo, se debe empezar con un punto.

Parámetro cachemgr_passwd

Squid es posible ser administrado desde una página web una vez instalado (no documentado aquí). Este parametro define la clave de acceso para tener acceso a esta función.

AVANCES DIARIOS DEL PROYECTO

2008-05-29T06:21:00.001-07:00

PROXY

Día 1

Se lee sobre como funciona el servidor Proxy sus características y algunos manuales de instalación y configuración de este.

El software que utilizaremos se llama squid, el día de hoy lo instalamos en el sistema operativo Linux Debían, el archivo que se va a configurar es squid.conf este archivo se respaldo en un directorio creado en el temporal que se llama Proxy. Luego procedimos a investigar la configuración correspondiente para este.

dia 2

El día de hoy procedimos a configurara el servidor Proxy y tratamos de restringir la pagina google para el equipo donde se instalo el servidor pero no nos funciono. Esperamos que para el día de mañana lo podamos lograr corrigiendo los posibles errores de configuración que tuvimos hoy.

Día 3

Después de una breve explicación del profesor sobre la configuración de squid, de cómo deben ir las líneas acl y las http_accsess procedimos a realizar las sintaxis con las restricciones que deben ir en el proyecto en una hoja para luego configurar el archivo de tal manera.

Dia 4

En el dia de hoy el profesor Fernando nos ayudo con un problema que presentaba el squid, luego procedimos a configurar el proxy con dos equipos pero solo se logro denegar google.

Dia 5

Hoy trabajamos de nuevo en la configuracion del squid como en el dia anterior con los dos compuradores, pero de nuevo fue imposible lograr su funcinamiento, por lo que no sabiamos interpretar el archivo /var/log/syslog.

Dia 6

Hoy de nuevo le intentamos todo la mañana a la configuracion de los dias anteriores pero como siempre se seguia presentando el mismo problema, pero con la ayuda del profesor concluimos que no era problema de configuracion, entonces mas tarde subimos a tecnoparque para hablar con el accesor Camilo Cartajena que nos dijo que teniamos que hacer una red independiente de la sena para que no nos causara problema.

Dia 7

Hoy seguimos con la configuracion de proxy pero cuando tratabamos de restringir las paginas squid las filtraba, entonces la utilizamos la herramienta de red Wireshark para detectar las fallas, y al parecer lo que estaba pasando era que el proxy del sena no estaba sirviendo las peticiones.

Dia 8

Hoy tratamos de instalar el sistema operativo Debian para hacer las practicas alli, pero al comenzar con la instalacion del sistema fallo la parte del reconocimiento del cd, lo intentamos en un portatil pero no nos reconocia la tarjeta inalambrica bajamos algunos drives pero no nos sirvio.

Dia 9

Hoy de nuevo subimos a tecnoparque para configurar el proxy pero de nuevo se nos presentaron problemas ya que las computadoras de tecnoparque no dejaban instalar Debian porque no reconocian los contraladores del cd de intalacion y tampoco nos reconocia la tarjeta de red porque necesitaba dos tarjetas de red, decidimos conseguir otra pc que la encontramos en el aula 5-4, pero sin disco duro, pero el asesor de tecnoparque Juan David Mauri nos facilito una tarjeta de red y un disco duro pero esto no fue suficiente para solucionar los diversos problemas que se nos presentaba porque aun con todo esto no nos instalo Debian.

Dia 10

Hoy de nuevo intentamos instala el proxy en tecnoparque pero no nos funciono decidimos intentarlo en el salon pero aun asi no nos dio, al parecer el servidor proxy del sena esta filtrando y por eso no nos da la salida a internet.

Dia 11

Hoy configuramos el servidor DNS para mirar si el problema del proxy dependia de este, puesto que el problema que tenemos es que no nos quieren resolver las paginas a las que hacemos peticion.

Dia 12

Hoy nos dimos cuenta de que el problema que nos presentaba squid, es que le proxy del sena esta filtrando las maquinas que nosotros tratamos de filtrar.

Dia 13

Hoy no pudimos hacer mucho por lo que teniamos que presentar unos examenes, entonces seguimos averiguando dudas que teniamos.

Dia 14

Hoy seguimos estudiando y resolviendo las dudas que tenemos sobre la configuracion del proxy.

Dia 15

Hoy leimos un manual sobre el servidor proxy y aclaramos muchas dudas.

Dia 16

Hoy el profesor Fernando nos explico los diversos problemas que se no presento al instalar y configurar los difernetes servicios.

Dia 17

---------------------------------

WEB

---------------------------------

DHCP

DIA 1

Hoy martes 27 de mayo trabajamos en el proyecto, hablando de la ubicacion del servidor DHCP de acuerdo con la estrutura de la red, asi que decidimos colocar el servidor de relay en el router cetral de la red y de este se le dara IPs a 2 LAN, y la otra LAN se le colocara otro servidor, ya teniendo en cuenta la ubicacion pasamos a investigar sobre la confiuracion del servidor en un router, ya que debido al lugar es necesario para darle una buena comunicacion a las 3 LAN. Este mismo dia los que estan encargado de la configuracion del servidor DNS nos informaron que ambos servidores trabajaran en conjunto (Actulizando DHCP y DNS). Asi que empezamos a investigar como es la configuracion de este servicio.

DIA 2

Hoy miercoles 27 de mayo hubo un cambio de planes ya que el servidor DHCP se configuraria en el sistema oprativo de linux (debian), debido a que este servidor trabajara en conjunto con el servidor DNS, este servidor estara configurado en windows, asi que para que puedan trabajan en conjunto es preferible que ambos esten en el mismo sistema operativo, por lo tanto hoy empesamos a leer como se hace y como es la configuracion en este sistema oprativo para moder adelantar y montarlo si es posible mañana mismo.

DIA 3

Hoy jueves 28 de mayo nos reunimos con el subgrupo de los que estan encargados del DNS para trabajar en conjunto y configurar ambos, empesamos montandolo en windows, nos fue bien en este proceso, pero el dilema era como hacer las actualizaciones de DHCP y DNS en windows asi que empesamos a investigar para que el viernes lo hicieramos, este mismo dia hablamos de como configurar los router en relay, asi que investigamos en una pagina de cisco, encontramos un manual muy bueno donde esta toda la informacion que necesitamos para comenzar el dia de mañana ya que por la hora nos nos da el tiempo.

DIA 4

hoy viernes 29 de mayo hablamos con el grupo de DNS y decidimos quedarnos toda la tarde para montar ambos servidores y configurar para hacer las actualizaciones, despues de tantos intentos por fin nos dio ya lo unico que faltaba era montar el DHCP con el relay para complir con el requisito que pide el proyecto.

DIA 5

hoy sabado 30 de mayo tuvimos clase, este dia nos dedicamos para montar servicios y el profe nos hiba ayudar con las dudas que se presentaran en el proceso, este dia comenzamos hacer la pratica de configurar los router como relay, pero a la mita de la configuracuion el profe nos interrunpio por motivos personales asi que nos toco dejarlo para el martes.

DIA 6

hoy martes 3 de junio retomando la plactica pendiente del sabado, empesamos con la configuracion, se nos ha presentado dificultades con el router, por el direccionamiento ya que no lo estamos haciendo con la verdadera configuracion de enrutamiento que tiene el proyecto, debido a esto la compañera yuli quirros que esta encargada de la infraestructura nos dio la mano para solucionar el problema que tenemos con la configuracion, aparte de esto como ya no nos podemos quedar en el aula del lado, tomamos la desicion de hacer la practica en ternoparque aprovechando que ya tiene el enrrutamiento que se va utilizar en el procyeto, asi que vamosa montar el servidor y agregarle a la configuracion de los router el comando "ip herper address" para que funcione como DHCP RELAY .

DIA 7
Hoy miercoles 4 de junio se nos presento un problema sobre la configuracion del servidor DHCP ya que este servidor solo reparte IPs para un mismo rango, la LANs tienen diferente enrrutamiento y por lo tanto es complicado para el servidor dar las direcciones, es por esta razon que es necesario hacer las VLANs en el servidor y en toda la red para que el servidor reconosca las peticiones dependiendo de los rangos de las LANs y no tenga conflitos con las demas.
para esta nueva configuracion es necesario que el servidor tengan tres interfaces para que por cada una de ellas escuche la peticion del rango configurado en ellas de las LAN correspondientes .
Este mismo dia se comenzo con la explicacion de algunos servicios uno por cada dia.
Se comenzo con el servidor de DNS, explicando su configuracion y parte de los requerrimientos que pide el proyecto que debe tener.

DIA 8
hoy jueves 5 de junio debido a los cambios presentados el dia anterior nos dedicamos a investigar hacerca de como hacer tarjetas virtuales en el servidor DHCP, la verdad es que por mas que investigamos no encontramos nada que tuviera relacion de lo que nesecitamos, se le pregunto al profesor fernando y èl tampoco lo ha hecho en windows y no sabe como hacerlo, en este momento nos sentimos perdido y no sabemos que hacer, no queremos perjudicar a los demas.
Este mismo dia se continuo con la explicacion de la configuracion de los servicios y el turno fue para el FTP que nos explico como funciona el servidor de usuario, anonimo y enjaulamiento.

DIA9

Hoy viernes 6 de junio estuvimos trabajando con el profesor vajando el programa para hacer tarjetas virtuales, ademas nos estaba explicando como se utilizan, aparte de eso se configuro un swtich con vlan para probar si, si funcionaba.

DIA10

Hoy sabado 7 de junio la verdad de mi parte no trabaje con mis compañeros en la configuracion por estaba en clase de linux, pero lo que me explicaron fue que configuraron un swtich con troncales y crearon interfaces virtuales, tambien el servidor DHCP, pero no sabian como hacer para que repartieran en los rangos diferentes.

DIA 11

Hoy lunes 9 de junio estuve muy poco con mis compañeros trabajando ya que me encontraba terminando unos detalles del trabajo del "pre-plan", pero ellos me explicaban lo que estaban haciendo y los problemas que se les presentaban en el transcurso del proceso.

DIA 12

Hoy martes 10 de junio no trabajamos en el proyecto ya que nos encontravamos trabajando los demas servicios en linux y en windows y otros como yo nos encontrabamos sustentando el trabajo de pre-plan.

DIA 13

Hoy miercoles 11 de junio en las primeras horas de la mañana, el profesor las utilizo para hablar acerca de la forma de actual de èl con respectos a unos compañeros, fue un momento donde todos podiamos hablar y decir que pensabamos acerca de esta formacion, despues de esta charla volvimos a preparar el examen teorico y practico que tenemos pendiente para esta semana, por lo tanto no avanzamos en el proyecto.

DIA 14

Hoy jueves 12 de junio toda la mañana estuvimos en el examen, unos en practico y otros teoricos y por lo tanto tampoco avanzamos en el proyecto.

DIA 15

Hoy vienes 13 de junio se cambiaron los papeles, los que el dia anterior les toco pratico este dia les tocaba teorico y asi con los de teoria y tampoco avanzamos en el proyecto.

DIA 16

Hoy sabado 14 de junio yo me encontraba en clase de linux como todos los sabado, pero no se trabajo en el proyecto ya que nos encontravamos hablando de lo mal que nos fue en el examen prantico para mirar que podiamos hacer al respecto.

DIA 17

Hoy lunes 16 de junio despues de hablar el sabado el profesor nos dio una oportunidad de volver a presentar el examen practico pero en grupos segun los resultados del examen teorico, y tampoco se trabajo en el proyecto.

DIA 18

Hoy martes 17 de junio fue el primer dia que trabajamos sin el profe, hoy retomamos el proyecto, volvimos a configurar las vlan en el swtich, pero decidimos que era mejor montar el servidor en linux debian ya que ya tenemos conocimiento en la configuracion de este servicio, asi que se configuro las interfaces en el servidor, pero todavia no sabemos como hacer la configuracion de los rangos en el servidor.

DIA 19

Hoy miercoles 18 de junio volvimos a estar en el mismo punto de ayer, la verdad es que no es facil estar sin profesor, pero investigamos y preguntamos al profesor camilo y quedo en explicarnos mañana, mientras tanto se adelanto actualizando el blog en el seguimiento del proyecto.

DIA 20

Hoy jueves 19 de junio volvimos con la configuracion de las vlan, las interfaces y el servidor DHCP, pero nada que nos funcionava, porque todo junto no sabiamos donde podia estar el problema, asi que el profesor camilo nos dijo que primero empesaramos con la configuracion de las vlan y las interfaces, despues que la comunicacion nos funcionara volvieramos con el servidor y lo bueno de todo esto es que por fin se dio la comunicacion entre las vlan y las interfaces, pero no alcaso el tiempo para mira si funcionaba con el servidor.

DIA 21

Hoy viernes 20 de junio retomamos la configuracion de lo de ayer, la tarea de hoy era que funcionara con el servidor, pero se nos presento un problema que era, que las interfaces ya nos funcionaba con las vlan y era por que la interfaz fisica se encontraba en el mismo rango que las virtuales y por lo tanto las vlan no reconocia las virtuales, asi que organizamos esta confucion y por fin se volvieron a comunicar, pero todavia estamos en la confucion del servidor que no nos da direccion ip los las vlan y lo probamos normalmente y nos dio una vez y las otras veces no, por mas que hemos buscado no encontramos el problema, pero seguimos intentando hasta que nos de.

DIA 22

Hoy lunes 23 de junio no se trabajo en la configuracion del servidor DHCP, porque estuvimos consentrados en la explicacion del servidor PROXY.

DIA23

Hoy martes 24 de junio por fin de tantos trabajo nos dio el DHCP con las VLAN, la verdad no se que nos nos daba y despues de buscar nos dimos cuenta que habia varios servicios corriendo en la misma maquina, y esto nos demoraba el proceso de ejecucion, despues de desantivar estos servicios nos funciono.

DIA24

Hoy miercoles 25 de junio despues que nos funciono el servidor con las vlan les explicamos a todos los compañeros como se configuraba las subnet y las interfaces, ademas de la configuracion del switch, de los paquetes que se necesita para hacer ambas configuraciones; estos paquetes se llaman DHCP3-SERVER y VLAN.

DIA25

Hoy jueves 26 de junio se comenzo a configurar los dispositivos como los router y los switch, a formatiar los computadores e instala los sistemas operativos que necesitamos para cada servicio, ademas de ponchar los cables que vamos a utilizar, y se comenzo como el montaje, pero no se pudo por que no habiamos pedido permiso para dejar los dispositivos por fuera de las cajas correspondientes.

DIA26

Hoy viernes 27 de junio ahora si se pudo comenzar con el montaje y dejarlo asi el tiempo que fuera necesario hasta el dia de la sustentacion, porque ya habiamos pedido permiso, asi todos empesamos a trabajar en la distribucion y el montaje de los servicios, este dia no hubo problema en la configuracion del DHCP por que todas las VLAN se vieron y daba las IPs a los clientes.

DIA27

Hoy sabado 28 de junio continuamos con el montaje y este dia ya habia varios servicios montados y funcionando, como el DHCP, DNS, FTP y hacia falta terminar la configuracion del PROXY y del WEB y que la red saliera a internet.

DIA28

Hoy martes 1 de julio ya era hora de presentar el proyecto sin embargo todavia hacia falta algunos aspectos como que saliera a internet, que el PROXY y el WEB funcionara y que algunos equipos se dieran ping con los servicios ya montados.

DIA29

Hoy miercoles 2 julio por fin se termino con el proyecto, hoy se sustento nos evaluaron por grupos en el salon con los profes fernando, camilo y felipe y consistia en preguntas de todo el proyecto y tambien de todo lo que se vio el semestre, la verdad no se sabe como nos fue si todos quedamos en plan o algunos se salvan, solo hay que esperar a que conclusion llegan los profes de acuerdo con los resustados de la sustentacion.
---------------------------------

DNS

MIÉRCOLES 28 MAYO DIA 2...

Este día me propuse configurar el Dns básico para así tener mas claro la configuración del esclavo mientras mis compañeros buscaban documentación e instalación de otros aplicativos de este servicio, después de insistirle un poco y con la ayuda de Fernando lo logre, hice que el esclavo copiara toda la configuración de Dns máster y que igualmente me resolviera en la intranet por el momento, ahora nos resta empezar con el directorio activo, las actualizaciones dinámicas, entre otros... mas las dificultades que se nos presenten...

JUEVES 29 MAYO DIA 3...

Estuvimos reunidos instalando y explicando la configuración del dns esclavo para que los integrantes estuvieran enterados de como se hace esta, después de que ya sabíamos como transferir la zona; también se supo finalmente como era la configuración necesaria para que este hiciera una búsqueda recursiva y no solo en su base de datos, en esta búsqueda recursiva se le deben dar los servidores a los que irá; para que así se guardara en su cache y tenga sus propios registros (claro esta que la cache debe ser borrada periódicamente para hacer actualización de su base de datos) , teniendo esto muy claro seguimos con el directorio activo (Active Directory), aclarando conceptos y tratando de configurarlo, todavía nos quedaban dudas y faltaba claridad acerca del funcionamiento de este por lo mismo este día este quedo incompleto, pero ya nos sentiemos mas ubicados sobre el tema...

VIERNES 30 MAYO DIA 4...

Como había escrito en la entrada anterior(jueves 29 mayo) nos faltaba mas claridad sobre el directorio activo (Active directory), por lo menos ahora estábamos mas confiados de lo que hacíamos, pero teníamos una responsabilidad mas ¿como hacer la actualización dinámica del DNS?, bueno hablamos con los compañeros que están montando DHCP para hacer posible la actualización del DNS y empezamos a trabajar en conjunto para completar dicha meta "terminar y entender el funcionamiento del servicio al finalizar la semana".

Al finalizar este día no logramos que el DNS se actualizara dinamicamente del DHCP pero teníamos mas claro que era lo que teníamos que configurar tanto del DHCP como del DNS y el directorio activo para lograr que tuvieran comunicación directa por así llamarlo. Este día no pudimos concluir esto pero teníamos al día siguiente teníamos clase entonces significaba seguir intentando y concluir la primera fase de la meta propuesta...

SABADO 31 MAYO DIA 5...

Esta día seguíamos intentando la configuración dinámica del DNS, unos integrantes de los servicios ya mencionados (DNS y DHCP), buscamos la ayuda de Jorge Esteban Valencia donde resolvimos las dudas que teníamos y empezamos con las practicas, montamos nuevamente los servidores DNS, DHPC y el directorio activo (Active Directory) empezamos a hacer pruebas con la ayuda de Jorge, le mostramos hasta donde habíamos llegado para que nos supervisara, corrigiera y diera recomendaciones... después de todo esto, insistirle e intentando !!!LO LOGRAMOS HICIMOS QUE EL DNS SE ACTUALIZARA POR MEDIO DEL DHCP¡¡¡ matriculamos el dhcp y un cliente en el dominio y en el DNS aparecieron los registros A y PTR, por supuesto también CUMPLIMOS con la META...

MARTES 3 JUNIO DIA 8...

Pues como siempre mantuvimos nuestro empeño en seguir ensayando, montando nuestro servicio y explorando mas sobre este... pero de algo inesperado nos enteramos, después de haber logrado entender la funcionalidad del directorio activo y haber hecho pruebas con la actualización dinámica del DNS junto con el DHCP !!!NO TENÍAMOS QUE MONTAR EL DIRECTORIO ACTIVO¡¡¡ !!!Ahora que rayos vamos a hacer¡¡¡, bueno después de enterarnos de esto seguimos trabajando e intentando la actualización dinámica del DNS; se supone que seria mas sencillo pues el directorio activo es algo complejo de manejar... pero no, no fue mas sencillo para nosotros...este día los intentos fueron fallidos, aún así seguimos realizando un arduo trabajo para finalizar esto..

MIÉRCOLES 9 MAYO DIA 9...

Este día nos reunimos en la horas de la mañana en tecnoparque, siguiendo el cronograma para así cumplir con nuestras metas; Yuly Quiroz nos explico la estructura de la red, el subneting y la forma en como estaba distribuida físicamente en el espacio facilitado en tecnoparque para el montaje de esta, después de esta explicación de yuly llegamos a varias conclusiones, donde tendrán que ser cambiados algunas configuraciones ya que se presentaban algunos errores...

En las horas de la tarde se llevo a acabo la explicación de la configuración del servicio DNS (básico sin actualización dinámica) en windows server 2003, presentada por Natalia valencia y yo (Katherine), después de varias intervenciones y bastante tiempo se logro que la mayoría de los integrantes y los interesados entendieran el funcionamiento y configuración de nuestro servicio, en este explicamos la configuración del DNS máster (creación de zonas tanto directas como inversas, registros A, PTR,CNAME) esclavo (transferencia de zona, inicio de autoridad(SOA)) y reenviadores (búsqueda recursiva); de esta manera finalizo mi día académico, prometiendo ser cada día mejor...

---------------------------------

FTP

Día 1
27 de mayo

Hoy tuvimos una reunión para hablar sobre los pocos días que teníamos para entregar elproyecto. Después nos asignaron un nueva servicio el servidor de tiempo, lo decidimos hacer en Linux disque por que era mas fácil.También estuve en el tecnoparque viendo como había quedado la red.

Día 2

28 de mayo

hoy estuvimos intentándolo el FTP para mostrarle a los compañeros como es la instalación y la configuracion de esta servicio, después estuvimos reunidos para hablar sobre los servicios

Día 3
29 de mayo

Hoy actualizamos el blog del proyecto con la información del servidor ftp.

Día 4
30 de mayo

En este dia estuvimos con el FTP como crear usuarios y contraseñas y algunas dudas que teníamos. Nos reunimos para bajar de nuevo el servidor del tiempo (NTP) para configurarlo de nuevo con la ayuda de otro compañero y configuramos el servidor con unos comandos que nos bajamos de Internet y el cliente lo montamos en otro equipo pero tuvimos otro problema y no pudimos solucionarlo.Nos dedicamos a solucionar el problema que teníamos con el servidor del tiempo.

Dia 5
31 de mayo

El profesor Fernando Quintero nos dijo que durante toda la clase del día podiamos realizar todo lo que quisieramos y decidímos ponernos a montar el servicio ftp para practicar.

Dia 6
3 de junio

Nuevamente el profesor Fernando Quintero nos dijo que nos pusieramos a trabajar en el proyecto, y nos pusimos a practicar sobre los servidores especialmente a montar un servidor de tiempo sobre.

Dia 7
4 de junio

En este dia estuvimos en el TecnoParque escuchando la explicación acerca de como estaba montada la red del proyecto, para que asi nos quedara claro a todos.

Dia 8
5 de junio

Durante la clase, el profesor Fernando Quintero nos dijo que la próxima semana; el 12 y 13 de junio se iban a hacer las evaluaciones teoricay practicas acerca de todo lo que habíamos aprendido, principalmente acerca del montaje de Sistemas Operativos y de Servicios,entonces nos pusimos a estudiar.

Día 9

6 de junio

En este dia nos dedicamos mas que todo a escuchar la exposición de la red, en donde el profe Fernando nos estaba dando algunas soluciones para hacer el proyecto. Y la mejor solución fue que creáramos VLAN.

En la tarde se explico en el tecnoparque el DNS, la instalación y configuracion básica del maestro y el esclavo.

Día 10
7 de junio

En este dia estuvimos reunidos tratando de solucionar un problema que teniamos sobre el servidor del tiempo,en la tarde estuvimos reunidos en el tecnoparque escuchando la explicacìon del ftp,

nos explicaron sobre el enjaulamiento, la creación de los usuarios y la instalación del servicio.

Dia 11
8 de junio

En este dia estuvimos en el tecnoparque creando las cuentas de los usuarios que estaran el servidor ftp.

Día 12
9 de junio

Hoy asistimos a la clase del sábado en donde el profe Fernando nos explico sobre el servidor proxy ya que este es el que mas oroblemas tiene a la hora de configurar.

Dia 13
10 de junio

En este dia estuvimos tratando de montar el servidor de tiempo, ya que todavia no teniamos muy claro como hacerlo.

Día 14
11 de junio

En este dia casi todo el grupo estuvo practicando todos los servicioos ya que para los dias 12 y13 de junio se realizaran los examenes.

Día 15
12 de junio

En este dia estuvimos montando los servicios y consultando un poco sobre el servidor web porque hay cosa que no nos quedan claras,porque todavia no nos han explicado sobre este.

Día 16
13 de junio

Hoy continuamos imformandos un poco mas del servidor web para que cuando nos explique no nos queden dudas sobre este.

Día 17
14 de junio.

En esta dia el profesor Fernando le hizo a la mitad del grupo el examen practico y a la otra mitad el teorico,por ese motivo todos estuvimos ocupados en el examen.

Día 18
15 de juno.

Hoy Fernando le hizo a la otra mitad del grupo el examen teórico,por lo tanto no estuvimos pendientes del proyecto.

Día 19

16 de junio

Hoy asistimos en la clase del sábado en donde el profe Fernando nos estaba explicando sobre los errores y las complicaciones que tuvimos al presentar el examen práctico y teórico.
También se le ocurrió una idea y era que dependiendo de como nos hubiera ido en el examen teórico volvíamos hacer una practica de servicios el lunes.

Dia 20
17 de junio

En este dia todos estuvimos trabajando en el proyecto para que se notara el avanze.

Día 21
18 de junio

Hoy el profe Fernando llego a calificar los examenes, después dijo que iba hacer tres grupos; en el grupo A iban a quedar los compañeros que mejor les fue en el examen teórico, en el grupo B a los que les fue bien, y en el C a los que peor les fue, ya cuando estaban todos los grupos formados el profe puso los ejercicios, y nos pusimos a trabajar, cuando se llego la hora de calificar Fernando dijo que ya nos nos iba a revisar yo no le creí por que el tenia una risa muy maliciosa, pero en fin al final dijo que no iba a calificar y que ninguno queda en plan de mejoramiento, de una nos pusimos muy contentos por que el hecho de uno no quedar en plan le hace la diferencia ya que la presión que se tiene es demasiada.

Hasta ese día estábamos con el profe por que al otro día se tenia que ir para bogota a organizar lo de la campus party.

Día 22
19 de junio

Hoy empezamos a estudiar solos pues nos dedicamos al proyecto,ya que todavia nos faltan muchas cosas por terminar.

Dia 23
20 de junio

En este dia estuvimos preparando como ivamos a trabajar los dias que el profesor no estaria con nosotros.

Dia 24

21 de junio

Hoy tratamos de lococarnos de acuerdo como ivamos a trabajar en el proyecto con el otro grupo,para que todos se enteraran de lo que estabamos asiendo.

Día 25
22 de junio

Hoy por fin se decidieron a explicar el servidor web en solaris, aunque la exposición no era como todos esperaban, pensando que como se habían demorado tanto la exposición nos iba a dejar deslumbrados o al menos iba a cumplir las espectativas de todos nosotros pero no fue así.

falto que nos explicaran la instalación de solaris, y la web como tal estuvo medio explicada, tampoco se explico como crear los hosts virtuales disque por que el no sabia.

Dia 26

22 de junio

En este dia todos estuvimos trabajando en el proyecto porque lastimosamente todavia nos falta mucho.

Dia 27

23 de junio

nuevamente seguimos trabajando en el proyecto,pero alugunos compañeros trabajaron en el blog ya que esteaban un poco atrasados.

Dia 28
23 de junio

Hoy los compañeros encargados del proxy lo explicaron, estuvo muy bien, pues todos entendimos bastante, nos explicaron paso por paso cuales eran las lineas que habian que cambiar, la prueva no se pudo realizar por que habia un dhcp en la red dando direcciones IP y le impedia hacer la prueva al proxy.

ESTRUCTURA DE RED

DÍA 1

Hoy, 27 de mayo de 2008, nosotros, los encargados del montaje de la infraestructura de la red, fuimos al Tecnoparque, allí está situada la simulación de la red, revisamos que la conectividad estuviera funcionando correctamente, lastimosamente habían equipos con la configuración cambiada y cables trocados; solucionamos el inconveniente y finalmente quedó en perfecto estado.

DÍA 2

El día de hoy, instalamos, en algunas estaciones de trabajo, el Sistema Operativo Linux; además, asesoramos al equipo encargado de montar el servicio DNS, no se pudo instalar y configurar el servicio por motivos personales de los integrantes de este equipo.

DÍA 3

Hoy, 29 de mayo de 2008, instalamos el Sistema Operativo Solaris en una de las máquinas, ya que en este S.O se debe montar el servicio Web. También, hicimos las entradas al Blog del Proyecto (Admón de Redes) sobre la infraestructura de la red.

DÍA 4

Realizamos el montaje de la infraestructura de la red de la empresa RedMax en Microsoft Office Visio 2003, pero no con medidas exactas, ya que no tenemos claro cuáles son los parámetros necesarios para el montaje de la red entre el aula 5-4 y la 5-7.

DÍA 5

Hoy, actualizamos las entradas al blog del proyecto, acerca de la infraestructura de la red.

DÍA 6

Fueron algunos de los integrantes del equipo encargado del montaje de los servicios, a simular la configuración de su respectivo servicio montandolos en la red.

DÍA 7

Nos quedamos investigando una forma en la cual quedara mejor estructurada la red, como la reducción de dispositivos, creación de vlans, entre otras posibilidades; también presenciamos la exposición del equipo del servicio DNS.

DÍA 8

Hoy, estuvimos en la sustentación de equipo de FTP, que al igual que los de DNS explicaron la instalación y configuración de su servicio.

DÍA 9

Estuvimos hablando con otros estudiantes de Administración de Redes, para que nos asesorarán y aclararán algunos conceptos que aún no tenemos claros para el montaje de la red.

DÍA 10

Revisamos la simulación de la red en Packet Tracer, pero nos encontramos con una sorpresa, ya que habian unas fallas en la conectividad de las subredes, porque no hacian ping entre ellas.

DÍA 11

Hoy, nos hablaron sobre las Vlans, y nos recomendaron que la infraestrutura de la red quedaría mejor con la implementación de estas para el montaje de RedMax.

DÍA 12

Intentamos simular de nuevo la red pero ya con la creación de Vlans, probamos conectividad entre todas estas, pero hubo fallas entre las redes de Cali y Bogotá al dar ping con la red de Medellín.

DÍA 13

Debido a la implementación de Vlans se deben crear subinterfaces en los routers, pero todavía no lo hemos conseguido, ya que no sabemos como configurarlas para que dé conectividad entre todas las Vlans.

DÍA 14

No trabajamos en la red del Proyecto.

DÍA 15

Estuvimos buscando soluciones al montaje de la red, con la creación de las subinterfaces, aunque tenemos la idea de como se hacen, no hemos podido solucionar el problema de la conectividad.

DÍA 16

Hoy no trabajamos en la infraestructura de la red, ya que Nando nos estuvo explicando algunas dudas sobre la configuración de los servicios .

DÍA 17

Estuvimos buscando alternativas para solucionar el problema de la conectividad en la red con la implementación de las subinterfaces.

DÍA 18

Hoy, fue el primer día que estuvimos solos, seguimos buscando la salida al problema dela conectividad entre las Vlans.

DÍA 19

Le entregamos la documentación de lo que llevamos sobre la configuración de Vlans al profesor Camilo, para que nos asesorará y nos dijera que problemas y fallas tenemos en la configuración de la red.

DÍA 20

Nos dedicamos a buscar soluciones para la conectividad de la red, ya que todavía no hemos encontrado la forma de cómo resolvereste inconveniente.

DÍA 21

Nos dimos cuenta de que con el enrutamiento dinámico (router rip), la conectividad de las Vlans con una conexión WAN no se logra, ya que para esto el tipo de enrutamiento debe ser estático (ip route).

DÍA 22

Empezamos a trabajar en la red utilizando el enrutamiento estático y lograr así la comunicación WAN, para que todas las Vlans de cada ciudad se comuniquen de forma exitosa.

DÍA 23

Verificamos la conectividad de Vlan a Vlan, entre las ciudades, como habían algunas conexiones incorrectas, nos encargamos de solucionarlas.

DÍA 24

Probamos conectividad entre cada uno de las ciudades, con el fin de evitar inconvenientes de última hora.

DÍA 25

Nos reúnimos los 2 grupos (940176 y 940178) para establecer los puntos de la infraestructura de la red donde irán y se configurarán los servicios que deben cumplirse en el Proyecto de la empresa RedMax. Hoy, también configuramos todos los dispositivos activos necesarios para el montaje de la red.

DÍA 26

Hoy, nos encargamos del montaje físico de la infraestructura de la red, en el salón 5-4, logramos la conectividad entre todas las Vlans de todas las ciudades (Medellín, Cali, Bogotá), las conexiones se realizaron sin inconvenientes; de esta manera los equipos encargados del montaje y configuración de los servidores pueden empezar a cumplir con sus respectivas tareas.

CRONOGRAMA DEL PROYECTO

2008-05-29T06:17:00.000-07:00