UNIVERSIDAD SIMÓN BOLÍVAR

Decanato de Estudios Profesionales

Coordinación de Ingeniería Electrónica

REINGENIERIA DE RED DE AREA LOCAL DE LA EMPRESA

PROTOKOL GRUPO DE INFORMATICA Y
TELECOMUNICACIONES

Por:
Gabriela Andreina Pérez Flores

Sartenejas, Marzo 2008

 UNIVERSIDAD SIMÓN BOLÍVAR
Decanato de Estudios Profesionales
Coordinación de Ingeniería Electrónica

REINGENIERIA DE RED DE AREA LOCAL DE LA EMPRESA

PROTOKOL GRUPO DE INFORMATICA Y
TELECOMUNICACIONES

Por:
Gabriela Andreina Pérez Flores
Carnet: 0134269

Realizado con la Asesoría de:

Tutor Industrial: Ing. Juan Bozza
Tutor Académico: Ing. Carlos Bianchi

INFORME FINAL DE CURSOS EN COOPERACIÓN TÉCNICA Y DESARROLLO

SOCIAL
Presentado ante la ilustre Universidad Simón Bolívar
Como requisito parcial para optar al título de
Ingeniero Electrónico
Sartenejas, Marzo de 2008
 UNIVERSIDAD SIMÓN BOLÍVAR
Decanato de Estudios Profesionales
Coordinación de Ingeniería Electrónica

REINGENIERIA DE RED DE AREA LOCAL DE LA EMPRESA

PROTOKOL GRUPO DE INFORMATICA Y TELECOMUNICACIONES

INFORME FINAL DE CURSOS EN COOPERACIÓN TÉCNICA Y DESARROLLO

SOCIAL
Presentado por:
Gabriela Andreina Perez Flores
Carnet: 0134269

REALIZADO CON LA ASESORÍA DE:

Tutor Industrial: Juan Bozza
Tutor Académico: Carlos Bianchi.

RESUMEN

En este proyecto se analizó la configuración de la red de área local de la empresa

Protokol Grupo de Informática y Telecomunicaciones, y se evaluaron e implementaron las

modificaciones que, a nivel de hardware y software, eran necesarios realizar para

aprovechar eficientemente todos los recursos con los que cuenta dicho sistema. De igual

forma, se establecieron nuevos servicios para facilitar y mejorar el desempeño de todos los

trabajadores que laboran en la empresa.

Palabras Claves
Redes, red de área local, integración, enlaces, servidores, dominio, monitoreo, telefonía IP.

Aprobado con mención: ___

Postulado para el Premio: ___
Sartenejas, Marzo de 2008
 INDICE GENERAL

INDICE DE FIGURAS V

INDICE DE TABLAS VII

SIMBOLOS Y ABREVIATURAS VIII

CAPÍTULO I. INTRODUCCION 10

1.1 ENTORNO EMPRESARIAL 11

1.1.1 Misión 11
1.1.2 Visión 11
1.1.3 Objetivos de la organización 12
1.1.4 Estructura Organizativa 12

1.2 DESCRIPCION DEL PROYECTO 13

1.2.1 Antecedentes 13
1.2.2 Definición 13
1.2.3 Objetivos 14
1.2.3.1 Objetivos generales 14
1.2.3.2 Objetivos especificos 14
1.2.4 Justificación 15
1.2.5 Alcance 15

CAPÍTULO II. FUNDAMENTOS TEORICOS 16

2.1 REDES DE COMPUTADORAS 17

2.1.1 Clasificación 17
2.1.2.1 Según su localización 17
2.1.2.2 Según su relación funcional 18
2.1.1.3 Según su estructura 22
2.1.1.4 Según su topología 26
2.1.1.5 Según las técnicas de transmisión 29

i
2.2 PROTOCOLOS DE RED 29
2.2.1 Descripción de los protocolos 31
2.2.1.1 Protocolos capa de aplicación 31
2.2.1.2 Protocolos capa de transporte 32
2.2.1.3 Protocolos capa de red (interred) 32

2.3 EQUIPOS 33
2.3.1 Servidores 33
2.3.1.1 Tipos de servidores 33
2.3.2 Dispositivos de enlace 35

2.4 SERVICIOS – CAPA DE APLICACION 37

2.4.1 Sistema de Nombres de Dominio 37
2.4.2 Correo electrónico 40
2.4.3 Directorio Activo o Active Directory 40
2.4.4 World Wide Web 41
2.4.5 Multimedia 42
2.4.5.1 Voz sobre IP 42
2.4.5.2 Webcasting / Webstreaming 44

2.5 INTERCONEXION DE REDES 45

2.5.1 Redes privadas virtuales 46
2.5.2 Redes virtuales de área local 48

2.6 ACCESO A REDES WAN 48

2.7 MONITOREO DE RED 50

CAPÍTULO III. DESARROLLO DEL PROYECTO 52

3.1 SITUACION INICIAL 53

3.2 REQUERIMIENTOS DE DISEÑO 56

3.2.1 Conectividad y requerimientos de banda ancha 56
3.2.1.1 Acceso externo a la red de Protokol 56
3.2.1.2 Enlace de Internet 56
3.2.1.3 Interconexión entre sucursales 57

ii
 3.2.1.4 VPNs para conectividad con clientes 58
3.2.1.5 Segmentacion de redes de voz y datos 58
3.2.1.6 Servidor de correo electrónico 58
3.2.2 Aplicaciones y herramientas de desarrollo 59
3.2.2.2 VoIP 59
3.2.2.3 Monitoreo de red 60
3.2.2.4 Cambio de dominio 61
3.2.2.5 Sistema de gestión de seguridad 61

3.3 IMPLEMENTACION 63
3.3.1 Acceso a Internet 63
3.3.2 Interconexión de sucursales 64
3.3.3 Instalación servidor de correo electrónico 69
3.3.4 Integración de sistemas de telefonía y mensajería 73
3.3.5 Monitoreo de red 75
3.3.6 Sistema de gestión de seguridad 78
3.3.7 Cambio de dominio 79

CAPÍTULO IV. ANALISIS DE RESULTADOS 82

CAPÍTULO V. CONCLUSIONES Y RECOMENDACIONES 91

REFERENCIAS BIBLIOGRAFICAS 95

PAGINAS WEB CONSULTADAS 96

BIBLIOGRAFIA 98

ANEXOS 99

Anexo 1. Instalación y configuración servidor de correo electrónico 100

Anexo 2. Integración sistemas de telefonía 110

Anexo 3. Instalación y configuración sistema de monitoreo de red 119

Anexo 4. Instalación y configuración software de gestión de seguridad 144

iii
Anexo 5. Renombramiento de dominio 149

Anexo 6. Estadísticas Nagios 160

iv
 INDICE DE FIGURAS

Figura 2.1: Red P2P............................................................................................................. 19

Figura 2.2: Red P2P centralizada ........................................................................................ 20
Figura 2.3: Red P2P descentralizada ................................................................................... 21
Figura 2.4: Red P2P híbrida ................................................................................................ 21
Figura 2.5: Capas del modelo OSI ...................................................................................... 22
Figura 2.6: Flujo de datos en modelo OSI........................................................................... 24
Figura 2.7: Formato de datos en el modelo OSI.................................................................. 24
Figura 2.8: Capas del modelo TCP/IP ................................................................................. 25
Figura 2.9: Red en estrella................................................................................................... 27
Figura 2.10: Red en bus....................................................................................................... 27
Figura 2.11: Red en anillo ................................................................................................... 28
Figura 2.12: Red híbrida...................................................................................................... 28
Figura 2.13: Protocolos y redes en el modelo TCP/IP inicialmente.................................... 30
Figura 2.14: Estructura de espacio de nombres de dominio [8] .......................................... 38
Figura 2.15: Integración de redes de telefonía .................................................................... 44
Figura 2.16: Transmisión mediante Frame Relay ............................................................... 49
Figura 3.1: Esquema inicial de red ...................................................................................... 53
Figura 3.2: Propuesta fina de red......................................................................................... 62
Figura 3.3: Puertos de origen y destino ............................................................................... 63
Figura 3.4: Asignación de políticas con origen puerto 1 y destino puerto 2 ....................... 65
Figura 3.5: Asignación de políticas con origen puerto 4 y destino puerto 2 ....................... 65
Figura 3.6: Redes Privadas Virtuales definidas................................................................... 66
Figura 3.7: Red Privada Virtual Caracas ............................................................................. 66
Figura 3.8: Direccionamiento de Red Privada Virtual Caracas........................................... 67
Figura 3.9: Propiedades de Red Privada Virtual Caracas.................................................... 67
Figura 3.10: Red Privada Virtual Puerto Ordaz .................................................................. 68
Figura 3.11: Direccionamiento de Red Privada Virtual Puerto Ordaz ................................ 68
Figura 3.12: Propiedades de Red Privada Virtual Puerto Ordaz ......................................... 69
Figura 3.13: Flujograma de instalación de servidor de correo ............................................ 70
Figura 3.24: Flujograma de integración de sistemas de telefonía IP................................... 74
Figura 3.25: Flujograma de instalación sistema operativo Fedora 7................................... 76
Figura 3.26: Flujograma de proceso de instalación de Nagios............................................ 77

v
Figura 3.42: Flujograma de procesos de renombramiento de dominio ............................... 80
Figura 4.1: Esquema final de red......................................................................................... 83
Figura 4.2: Conexión VPN Comverse – Movilnet .............................................................. 85

vi
 INDICE DE TABLAS

Tabla 2.1: Protocolos de red según modelo OSI ................................................................. 30

Tabla 2.2: Protocolos de red según modelo TCP/IP............................................................ 30
Tabla 2.3: Dominios según su estructura organizativa........................................................ 39
Tabla 2.4: Dominios según su ubicación geográfica........................................................... 39
Tabla 2.5: Asignación de roles FSMO ................................................................................ 41
Tabla 3.1: Servidores conectados en red ............................................................................. 54
Tabla 3.2: Servidores desconectados de la red .................................................................... 54
Tabla 3.3: Dispositivos de enlace ........................................................................................ 54
Tabla 3.4: Consumo de ancho de banda .............................................................................. 55
Tabla 3.5: Requisitos del sistema para las versiones de Windows Server 2003 ................. 72
Tabla 3.6: Requisitos para Windows Server 2003 Enterprise Edition ................................ 73
Tabla 4.1: Servidores dentro de la red definitiva................................................................. 84
Tabla 4.2: Servidores desconectados de la red .................................................................... 84
Tabla 4.3: Dispositivos de enlace en la red definitiva......................................................... 84
Tabla 4.4: Conexiones físicas (Patch Panel vs. Switch)...................................................... 85
Tabla 4.5: Distribución física de equipos ............................................................................ 86
Tabla 4.6: Asignación de direcciones en el segmento de datos........................................... 87
Tabla 4.7: Reseerva de direcciones en el segmento de datos .............................................. 87
Tabla 4.8: Estadísticas de disponibilidad según Nagios...................................................... 89

vii
 SIMBOLOS Y ABREVIATURAS

ABA: Acceso Banda Ancha

AD: Active Directory
ADC: Active Directory Connection
ADSL: Asymmetric Digital Subscriber Line
AIA: Authority Information Access
ASP: Active Server Pages
ASP: Active Service Pages
CDO: Collaboration Data Objects
CDP: Certificate Distribution Point
CGI: Common Gateway Interface
CPU: Central Processing Unit
DC: Domain Controller
DFS: Distributed File System
DHCP: Dynamic Host Configuration Protocol
DMZ: Demilitarized Zone
DNS: Domain Name Server
EAS: Exchange ActiveSync
EBGP: External Border Gateway Protocol
FAT: File Allocation Table
FBA: Form-Based Authentication
FTP: File Transfer Protocol
GAL: Global Address List
GCC: GNU Compiler Collection
GD: Graphics Dra.
GPO: Group Policy Object
GUI: Graphical User Interface
HCL: Hardware Compatibility List
HTML: HyperText Markup Language
HTTP: Hypertext Transfer Protocol
ICS: Internet Connection Sharing
IIS: Internet Information Services

viii
IMAP: Internet Message Access Protocol
IP: Internet Protocol
LAN: Local Area Network
LDAP: Lightweight Directory Access Protocol
MAC: Media Access Control
NIC: Network Interface Card
NNTP: Network News Transfer Protocol
NNTP: Network News Transport Protocol
NTFS: New Technology File System
OMA: Outlook Mobile Access
OSPF: Open Shortest Path First
OWA: Outlook Web Access
PAT: Port Address Translation
POP: Post Office Protocol
POP3: Post Office Protocol (version 3)
RAID: Redundant Array of Independent Disks
RPC: Remote Procedure Call
RUS: Recipient Update Service
SAN: Storage Area Network
SCSI: Small Computer System Interface
SLA: Service Level Agreement
SMTP: Simple Mail Transfer Protocol
SONET: Synchronous Optical Network
SQL: Structured Query Language
SSH: Secure SHell
SSL: Secure Socket Layer
TCP: Transmission Control Protocol
URL: Uniform Resource Locutor
VLAN: Virtual Local Area Network
VPN: Virtual Private Network
WWW: World Wide Web

ix
 Capítulo I.
INTRODUCCION
 Capítulo I. Introducción

En este capitulo se pretende introducir la visión, misión y objetivos de la empresa

Protokol Grupo de Informática y Telecomunicaciones, así como el planteamiento del
problema y los objetivos del proyecto desarrollado.

1.1 ENTORNO EMPRESARIAL

Protokol Grupo de Informática y Telecomunicaciones (Protokol GIT) se define

como una empresa integradora de soluciones, orientada a desarrollar los negocios de sus
clientes a través del uso de la tecnología. Cuenta con una amplia trayectoria y experticia en
el campo de Sistemas de Computación y Telecomunicaciones, ofreciendo servicios que
van desde el suministro de productos de tecnología de punta, servicios post-venta,
ingeniería, consultoría, ejecución de proyectos, hasta el adiestramiento y capacitación de
personal.

Cuentan también con el respaldo de importantes corporaciones como asociados de

negocios: HP, COMPAQ, CISCO, COMMWORKS, COMVERSE, ORACLE.

1.1.1 Misión

“Desarrollar los negocios de nuestros clientes a través del uso estratégico de la

tecnología y la integración de soluciones en las áreas de telecomunicaciones e
informática.”

1.1.2 Visión

“Ser la empresa líder de soluciones y servicios de tecnologías de Información a

nivel nacional, aportando continuamente valor al negocio de nuestros clientes.”

11
1.1.3 Objetivos de la organización

- Ser el Integrador por excelencia para el sector de Telecomunicaciones a nivel

nacional, ofreciendo soluciones eficientes a los clientes.
- Crear y mantener en el tiempo ventajas competitivas basadas en la calidad de los
servicios ofrecidos.
- Responder oportuna y efectivamente a las necesidades y requerimientos del
mercado.
- Maximizar la satisfacción de los clientes, mediante un enfoque de servicio al
consumidor.

1.1.4 Estructura Organizativa

12
1.2 DESCRIPCION DEL PROYECTO

1.2.1 Antecedentes

La red de área local de la empresa Protokol al momento de iniciar el proyecto

presentaba desventajas dadas por la ineficiencia de la red de telefonía IP, las fallas de la
plataforma de correo electrónico, y la desactualización del sistema de seguridad.

Surge así la necesidad de un sistema interno de comunicación más eficiente y

seguro, con el propósito de aumentar la efectividad en la gestión diaria, reducir gastos
internos de comunicación, tener confiabilidad en los recursos disponibles, y mantenerse
permanentemente conectados. En la medida que el funcionamiento interno de la empresa
sea más efectivo y eficiente, será posible dar repuestas más rápidas para constituir un socio
estratégico de tecnología para los clientes en una forma ágil.

1.2.2 Definición

La empresa Protokol GIT, luego de realizar un completo estudio de las condiciones

de su red de área local (LAN), determinó la necesidad de realizar ciertos cambios a nivel
de hardware y software, para aprovechar con mayor eficiencia los recursos con los que
cuenta la empresa en función de mejorar el funcionamiento de los servicios internos.

El proyecto consiste en el rediseño de la red interna, tomando en cuenta el sistema

de computadoras y equipos de transmisión (switches, routers, módems), para la
implementación de nuevos servicios y la optimización en el uso de los recursos existentes.
Comprende el estudio de la topología actual de la red y de la solución propuesta por la
empresa, tomando en cuenta cada uno de los servicios que se requiere integrar, como lo
son servidores de bases de datos, de correo electrónico, controladores de dominio, sistemas
de comunicación y sistemas de seguridad.

13
 También se plantea la implementación de herramientas que permitan optimizar el
funcionamiento interno de la empresa orientado a la colaboración en el manejo de la
información.

1.2.3 Objetivos

1.2.3.1 Objetivos generales

Rediseñar la red interna y el sistema de comunicaciones de la empresa Protokol,

para optimizar el uso de los recursos y permitir la implementación de nuevos servicios que
faciliten el desempeño de los miembros de la organización.

1.2.3.2 Objetivos específicos

- Estudiar el esquema de red de área local en funcionamiento en la empresa

Protokol.
- Estudiar el esquema de red propuesto por la empresa.
- Investigar, seleccionar y estudiar el funcionamiento de los distintos equipos y
servicios requeridos para la actualización de la red.
- Estudiar los detalles técnicos para la integración de servicios de WebCam.
- Planificar los requerimientos de banda ancha para establecer enlaces entre las
sucursales de la empresa.
- Instalar las actualizaciones de las aplicaciones como servidores, firewalls,
herramientas de colaboración e integración, migración del servicio de correo
electrónico, etc.
- Instalar los componentes de cierre de la integración entre Cisco Unity y MS-
Exchange.
- Estudiar e instalar un software de monitoreo de red interna.
- Estudiar e instalar un software de gestión de seguridad de sistemas.
- Llevar a cabo las pruebas de los enlaces instalados entre las sucursales de la
empresa.

14
 - Llevar a cabo las pruebas de la red interna y verificar el funcionamiento integral
de los servicios instalados.

1.2.4 Justificación

Al ser Protokol GIT una empresa orientada a ofrecer soluciones para sectores como
telecomunicaciones, industria y comercio, petrolero, financiero, gobierno y educación, es
un requisito indispensable contar a nivel interno con servicios que le permitan mantener la
vanguardia como asesores en el desarrollo de los objetivos propuestos por los clientes de
manera efectiva y en el menor tiempo posible.

Para alcanzar esta meta, la red local debe funcionar eficaz y eficientemente para
cumplir con los objetivos para los que fue diseñada, por lo que fue necesario realizar
ciertas modificaciones a nivel de software y/o hardware, tanto en servidores como en las
distintas estaciones de trabajo.

En la medida que el funcionamiento interno de la empresa sea más efectivo y

eficiente, será posible dar respuestas más rápidas en función de constituir un socio
estratégico de tecnología para los clientes en una forma ágil.

1.2.5 Alcance

El desarrollo del proyecto comprende desde la configuración de nuevos servidores

y la implantación de un nuevo sistema de enlace, la implementación de nuevos servicios y
la optimización de los ya existentes, hasta la distribución de los equipos en subredes, el
establecimiento de canales privados de comunicación y la unificación de los dominios de
trabajo.

15
 Capítulo II.
FUNDAMENTOS TEORICOS
 Capítulo II. Fundamentos Teóricos

En este capítulo se incluyen los fundamentos teóricos que sustentan el proyecto. Se

describirán los diferentes tipos de redes de computadoras y sus características, los
protocolos que manejan, los equipos que se utilizan para establecer las conexiones, y su
funcionamiento en cuanto a los servicios que son capaces de prestar.

2.1 REDES DE COMPUTADORAS

Una red de computadoras es la interconexión de computadoras o equipos de manera

física o inalámbrica, con el fin de compartir información, recursos y servicios. Esta
comunicación se lleva a cabo tanto a nivel físico (tarjetas de red, cables, antenas, etc.)
como a nivel lógico (protocolos de red), lo que facilita la actualización tecnológica. [1]

2.1.1 Clasificación

Las redes se pueden categorizar de la siguiente manera:

2.1.2.1 Según su localización

Redes de Área Personal (PAN – Personal Area Network)

Están constituidas por dispositivos de uso personal, interconectados en cortas

distancias (unos pocos metros) generalmente mediante enlaces “punto a punto”.

Las nuevas tendencias se inclinan a que estas redes operen de forma inalámbrica.
Estos sistemas proporcionan conectividad usuario a usuario y comunicaciones seguras,
soportando diferentes aplicaciones y escenarios de operación.

17
Redes de Área Local (LAN – Local Area Network)

Redes privadas que ocupan poca extensión geográfica, a través de las cuales se
interconectan equipos o estaciones de trabajo con el fin de compartir e intercambiar
información. Generalmente, la velocidad de transmisión de datos oscila entre 10 y 1000
Mbps, con poca latencia y mínimos errores.

Redes de Área Metropolitana (MAN – Metropolitan Area Network)

Redes de alta velocidad, que surgen como evolución del concepto de Red de Área
Local para cubrir mayor extensión geográfica, abarcando un máximo de 50 Km. Presenta
capacidad de integración con múltiples servicios, sobre medios de transmisión tales como
fibra óptica y par trenzado de cables de cobre a velocidades que van desde 2 Mbit/s hasta
1500 Mbit/s.

Redes de Área Amplia (WAN – Wide Area Network)

Redes que ocupan un área geográfica extensa, presentando generalmente una

topología “punto a punto”. Estas redes son capaces de interconectar equipos a través de
distancias que van desde 100 hasta unos 1000 Km., para lo cual cuentan con una
infraestructura basada en poderosos nodos de conmutación y líneas de transmisión de
grandes prestaciones, caracterizadas por sus grandes velocidades y ancho de banda en la
mayoría de los casos.

2.1.2.2 Según su relación funcional

Cliente-servidor

Esquema de red en el que un equipo o programa llamado cliente hace solicitudes a

otro llamado servidor, quien las procesa y envía respuesta.

El uso de redes bajo este esquema presenta ventajas organizativas, ya que la gestión
de la información se realiza de forma centralizada, de manera que los accesos, los recursos

18
y la integridad de los datos son controlados por el servidor para evitar que clientes
defectuosos o no autorizados puedan corromper el sistema. También representa una ventaja
el hecho de que la capacidad de los procesos se reparte entre los clientes y servidores que
los ejecutan, permitiendo también aumentarlas por separado.

Como desventajas se observan la congestión y la indisponibilidad. Si surgen

solicitudes simultáneas al servidor, se genera gran cantidad de tráfico de datos que pueden
ocasionar desde retrasos en la red hasta pérdidas de paquetes debido a colisiones. En caso
de indisponibilidad del servidor, es decir, que éste se encuentre “caído”, las peticiones de
los clientes no pueden ser satisfechas.

Igual-a-Igual (P2P - Peer-to-Peer)

Estructura de redes formada por un conjunto de nodos que se comportan

simultáneamente como clientes y como servidores. Estos nodos se encuentran
interconectados entre sí como se muestra en la figura 2.1.

Figura 2.1: Red P2P

Dado que cada uno de los nodos puede comunicarse con los demás, la red sigue
funcionando si algún nodo deja de hacerlo, por lo que se utilizan generalmente para
compartir archivos que contienen audio, video, texto, software y datos en cualquier
formato digital.

El ancho de banda de la red depende del número de nodos que la componen, siendo
mayor mientras hay más nodos. Debido a ésto y a la estructura de interconexión, la
transmisión de datos es más eficiente.

19
Clasificación de redes P2P:

Una posible clasificación de las redes P2P pudiera ser acorde a su grado de
centralización:

a. Redes P2P centralizadas

Presentan un nodo central que enlaza a los demás nodos, a través del cual se accede
al contenido y se gestionan todas las transacciones, tal como se muestra en la figura 2.2.

Figura 2.2: Red P2P centralizada

Sus principales desventajas radican en la poca privacidad y falta de escalabilidad al

depender de un solo servidor.

b. Redes P2P "puras" o totalmente descentralizadas

No utilizan la figura de nodo central, sino que los usuarios se comunican entre sí de
manera directa, como se observa en la figura 2.3.

20
 Figura 2.3: Red P2P descentralizada

De esta manera, los equipos de la red actúan como clientes y servidores de manera
simultánea; al no requerir ningún tipo de gestión centralizada, estas redes son más
versátiles.

Redes P2P híbridas, semi-centralizadas o mixtas

Presentan, como se muestra en la figura 2.4, servidores centrales que interactúan

con los demás nodos enrutando la información y administrando los recursos de banda
ancha, sin necesidad de identificarlos ni almacenar información.

Figura 2.4: Red P2P híbrida

En caso de fallas en estos nodos centrales, los demás elementos de la red tienen la
capacidad de comunicarse entre sí tal como en el caso de las estructuras descentralizadas.

21
2.1.1.3 Según su estructura

Redes OSI o Modelo OSI (Open System Interconnection)

El modelo OSI, que no es considerado una arquitectura de red como tal, define una
estructura de capas indicando las responsabilidades de cada una de ellas, mas sin
especificar los servicios y protocolos exactos que se utilizaran en cada capa.

En esta estructura de red, cada capa del modelo utiliza una abstracción diferente, y
realiza una función bien definida, con límites fijados a fin de minimizar el flujo de
información a través de las interfaces. En la figura 2.5 se observa la distribución de las
capas de este sistema.

Figura 2.5: Capas del modelo OSI

Capa física: En ésta se lleva a cabo la transmisión de información, en forma de bits

puros, a través de un canal de comunicaciones; este proceso incluye asegurar que no haya
errores en la transmisión y que los datos que se envíen se reciban como tales. [2]

Capa de enlace de datos: Establece una línea de comunicación que no presente

errores, transmitiendo los datos en tramas de manera secuencial. Debe recibir una
confirmación de recepción. En esta capa se define el direccionamiento físico, que permite a
los hosts identificar las tramas destinadas a ellos. [2]

22
 Capa de red: Esta capa controla el enrutamiento de los paquetes, bien de manera
estática o dinámica, utilizando un direccionamiento lógico. También es capaz de manejar
los problemas de congestión. [2]

Capa de transporte: Maneja los datos, los entrega y se asegura de que lleguen
correctamente a la siguiente capa. También determina el tipo de servicio que debe
proporcionar a la capa de sesión y finalmente a los usuarios de red. [2]

Capa de sesión: Esta capa establece conexiones lógicas entre puntos de la red,
permitiendo que usuarios en máquinas diferentes establezcan sesiones entre ellos. Se
encarga de ofrecer servicios como control de diálogo, administración de token, y
sincronización. [2]

Capa de presentación: Maneja los datos de la aplicación y ajusta su sintaxis y

semántica en un formato que pueda ser transmitido en la red. [2]

Capa de aplicación: Aloja los protocolos y programas de red que interactúan con
el usuario, como el protocolo HTTP (Protocolo de Transferencia de HiperTexto o
HyperText Transfer Protocol). [2]

La figura 2.6 muestra la transmisión o el flujo de los datos a través de las capas del
modelo de referencia OSI. [3]

23
 Figura 2.6: Flujo de datos en modelo OSI

La figura 2.7, por su parte, muestra cómo se manejan los datos dentro de cada una
de las capas del modelo OSI.

Figura 2.7: Formato de datos en el modelo OSI

24
 En la figura se distinguen los siguientes elementos:

APDU: Unidad de datos en la capa de aplicación.

PPDU: Unidad de datos en la capa de presentación.
SPDU: Unidad de datos en la capa de sesión.
TPDU:(segmento) Unidad de datos en la capa de transporte.
Paquete: Unidad de datos en el nivel de red.
Trama: Unidad de datos en la capa de enlace.
Bits: Unidad de datos en la capa física.

Se observa entonces que cada capa del modelo OSI maneja los datos según los
esquemas de comunicación de cada una de ellas, colocando bits de encabezado,
dividiéndolos en subconjuntos de datos o agrupándolos, para ser transmitidos a su destino.

Redes TCP/IP (Transmission Control Protocol / Internet Protocol)

Arquitectura de red organizada en capas, de manera similar al modelo OSI, como se

observa en la figura 2.8. Se diferencian en el número de capas y en la forma de
estructurarlas, ya que en el modelo TCP/IP se definen claramente los protocolos a
utilizarse. La estructura del modelo TCP/IP otorga a las redes capacidad para
interconectarse de manera sólida.

Figura 2.8: Capas del modelo TCP/IP

Capa física (host a red): Puntualiza que el host debe conectarse a la red mediante
el mismo protocolo para poder enviar y recibir paquetes IP.

25
 Capa de interred: Permite el acceso de los paquetes desde la red de origen hasta la
red de destino. Aquí se define el protocolo IP (Protocolo de Internet o Internet Protocol)
para los paquetes que van a ser entregados.

Capa de transporte: De manera similar a la capa de transporte del modelo OSI,

permite que las entidades iguales en los hosts de origen y destino puedan llevar a cabo una
conversación. Los datos se transmiten bajo el protocolo TCP (Protocolo de Control de
Transmisión o Transmisión Control Protocol), el cual proporciona un flujo fiable de bytes,
que asegura que los datos llegan completos, sin daños y en orden.

Capa de aplicación: Contiene los programas o aplicaciones que permiten las

comunicaciones entre usuarios. Los datos se adaptan a los formatos individuales de las
aplicaciones y se codifican de acuerdo a protocolos estándar. Entre los programas que se
ejecutan en esta capa se encuentran transferencia de archivos bajo protocolo FTP
(Protocolo de Transmisión de Archivos o File Transfer Protocol) y correo electrónico bajo
protocolo SMTP (Protocolo Simple de Transferencia de Correo o Simple Mail Transfer
Protocol), entre otros.

Los protocolos asociados con el modelo OSI ya casi no se usan, pero el modelo en
si es muy general y muy valido. Por el contrario, el modelo TCP/IP no se usa mucho como
tal, pero sus protocolos si.

2.1.1.4 Según su topología [4]

Topología en Estrella

En este tipo de redes, todos los equipos se conectan a un nodo central sin estar
conectados entre sí. El nodo central (constituido por un concentrador o por un switch) se
encarga de gestionar el tráfico de paquetes entre los demás nodos, de manera que su
principal ventaja radica en que el mal funcionamiento de un nodo no afecta el desempeño
del resto de la red, mientras que su mayor desventaja se basa en la falla de la red entera en
caso de una posible falla en el nodo central. La figura 2.9 muestra el esquema de
conexiones de los equipos en esta topología.

26
 Figura 2.9: Red en estrella

Esta red crea una mayor facilidad de supervisión y control de información ya que
para pasar los mensajes deben pasar por el hub o concentrador, el cual gestiona la
redistribución de la información a los demás nodos. La fiabilidad de este tipo de red
consiste en que el malfuncionamiento de un computador no afecta en nada a la red entera,
puesto que cada ordenador se conecta independientemente del hub.

Topología en Bus

En este tipo de redes, los equipos se interconectan directamente a través de un

único canal o cable común, como se muestra en la figura 2.10. Esto permite que cada
equipo pueda tener acceso potencial a todo los paquetes que viajan por el cable común, lo
cual presenta como ventaja la accesibilidad de la información, y como desventaja los
problemas de tráfico y colisiones que puedan presentarse. Los switches o concentradores
se conectan en alguno de los extremos del canal.

Figura 2.10: Red en bus

Topología en Anillo

Estas redes presentan equipos conectados con sus adyacentes en forma de bucle
cerrado o anillo. En la figura 2.11 se muestra un ejemplo de este tipo de redes.

27
 Figura 2.11: Red en anillo

El flujo de información se lleva a cabo en un solo o ambos sentidos, utilizando el

método del token, que se describirá posteriormente. En el caso de la comunicación
unidireccional la comunicación en todo el anillo se pierde si algún nodo de la red deja de
funcionar, mientras que en el caso bidireccional los datos aún pueden transmitirse.

Topologías híbridas

Se derivan de la combinación de topologías “puras”: estrella-estrella, bus-estrella,

etc. Un ejemplo de este tipo de redes se muestra en la figura 2.12.

Figura 2.12: Red híbrida

Para las topologías de redes descritas anteriormente se puede aplicar la siguiente

sub-clasificación:

28
2.1.1.5 Según las técnicas de transmisión

Redes de difusión (broadcast)

Presentan un único canal de comunicación, compartido por todos los usuarios. Los
paquetes que se transmiten a través de estas redes son recibidos por todas las máquinas,
pero los campos de dirección que lo identifican permiten que el destinatario lo reconozca y
lo procese, mientras que los demás usuarios lo descartan. Los mensajes también pueden ser
enviados a un subconjunto de máquinas, lo cual se conoce como multidifusión
(multicasting).

Redes punto a punto

Presentan múltiples conexiones entre pares de máquinas. Los paquetes podrían

tener que pasar por varias máquinas en su camino hacia el destinatario final.

2.2 PROTOCOLOS DE RED

Los protocolos de red establecen las reglas comunicacionales a ejecutarse durante

el intercambio de datos. Estos pueden implementarse tanto en hardware (tarjetas de red)
como en software (controladores).

Para el modelo OSI, se utilizan distintos protocolos inherentes a las capas de red del
mismo, entre los cuales se destacan los mencionados en la tabla 2.1:

29
 Tecnologías y protocolos de red (según modelo OSI)
DNS, FTP, HTTP, IMAP, IRC, NFS, NNTP, NTP, POP3,
Nivel de aplicación
SMB/CIFS, SMTP, SNMP, SSH, Telnet, SIP
Nivel de ASN.1, MIME, SSL/TLS, XDR
presentación
Nivel de sesión NetBIOS, ONC RPC, DCE/RPC
Nivel de transporte SCTP, SPX, TCP, UD
Nivel de red AppleTalk, IP, IPX, NetBEUI, X.25
Nivel de enlace ATM, Ethernet, Frame Relay, HDLC, PPP, Token Ring, Wi-Fi,
STP
Nivel físico Cable coaxial, Cable de fibra óptica, Cable de par trenzado,
Microondas, Radio, RS-232

Tabla 2.1: Protocolos de red según modelo OSI

Para el modelo TCP/IP, los principales protocolos de cada capa son los siguientes:

Tecnologías y protocolos de red (según modelo TCP/IP)

Nivel de aplicación DNS, HTTP, SMTP, FTP, TELNET
Nivel de transporte UDP, TCP
Nivel de red IP
Nivel de acceso a red Ethernet, Token Ring
Nivel físico Cable coaxial, Cable de par trenzado

Tabla 2.2: Protocolos de red según modelo TCP/IP

Esquemáticamente, la distribución de los protocolos en el modelo TCP/IP sería

como se muestra en la figura 2.13:

Figura 2.13: Protocolos y redes en el modelo TCP/IP inicialmente

30
2.2.1 Descripción de los protocolos [5]

2.2.1.1 Protocolos capa de aplicación

TELNET: Protocolo implementado por el cliente que permite acceder a equipos

remotos, generalmente a través del puerto 23. Se genera comunicación bidireccional entre
los equipos, ofreciendo la capacidad de correr programas y administrar equipos.

FTP: Protocolo utilizado para el servicio de transferencia de archivos entre equipos

conectados a redes TCP (no necesariamente la misma red local). Este sistema está basado
en la arquitectura cliente-servidor, y ofrece altas velocidades de conexión pero bajos
niveles de seguridad, ya que los datos, incluyendo nombres de usuario y contraseñas, no se
transmiten cifrados, es decir, la información no se protege a través de claves, lo que supone
que cualquiera podría entenderla.

SMTP: Protocolo utilizado por los servidores de servicio de correo electrónico para
intercambiar mensajes, que establece el formato y la transferencia de datos en el envío de
los mismos. Esta comunicación normalmente se lleva a cabo utilizando el puerto 25, y se
basa en el modelo cliente-servidor.

DNS (Sistema de Nombres de Dominio Domain Name System): Protocolo de

comunicación entre un cliente y el servidor de DNS (Domain Name System), el cual
contiene una base de datos jerárquica y distribuida que almacena información sobre los
nombres de dominio de las redes y los asocia con sus direcciones IP. También es llamado
“protocolo de resolución de nombres”.

HTTP: Protocolo basado en el modelo cliente-servidor, que establece la semántica

y la sintaxis en la comunicación vía web, utilizada por clientes, servidores, y proxies
(computadores que interceptan las conexiones de red que un cliente ejecuta contra un
servidor de destino [6]). Este protocolo no almacena información acerca de las conexiones
que realiza, pero puede generar “cookies” o archivos temporales en las máquinas clientes
para permitir a las aplicaciones web llevar el control de usuarios y contraseñas, almacenar
sus preferencias, etc.

31
 Con el tiempo se han ido agregando otros protocolos tales como NNTP, USENET,
entre otros.

2.2.1.2 Protocolos capa de transporte

TCP: Protocolo confiable, orientado a la conexión, que permite que un flujo de

bytes que se origina en una maquina se entregue sin errores en cualquier otra maquina en la
interred. Divide el flujo de bytes entrantes en mensajes discretos y pasa cada uno de ellos a
la capa de interred. También maneja el control de flujo para que los equipos puedan
comunicarse eficientemente sin importar sus velocidades de transmisión.

UDP (Protocolo de Datagramas de Usuario o User Datagram Protocol):

Protocolo no confiable y no orientado a la conexión, para aplicaciones que no desean la
secuenciación o el control de flujo de TCP, debido a su complejidad. Se usa principalmente
cuando no importa el orden de envío y llegada de los paquetes de datos, o cuando la
información puede agruparse en un único paquete. En el direccionamiento de los paquetes,
se añaden campos para indicar el puerto de origen y el puerto de destino.

RPC (Llamada a Procedimiento Remoto o Remote Procedure Call): Protocolo

que permite realizar llamadas a procedimientos situados remotamente, como si fuesen
procedimientos locales. Es muy utilizado bajo el esquema cliente-servidor, cuando el
cliente envía una solicitud al servidor y éste le responde.

2.2.1.3 Protocolos capa de red (interred)

IP: Protocolo utilizado para encaminar o direccionar datos, utilizando direcciones

numéricas en los equipos de origen y destino, switches y routers, para indicar la trayectoria
de los paquetes.

32
2.3 EQUIPOS

2.3.1 Servidores

Un servidor es un equipo, proceso o aplicación que ejecuta un programa en

beneficio de otra aplicación llamada cliente. Un equipo puede cumplir simultáneamente las
funciones de servidor y cliente.

Los servicios prestados por estos equipos generalmente son de almacenamiento de

archivos y de ejecución de aplicaciones. [7]

2.3.1.1 Tipos de servidores

Servidor de correo

Aplicación que permite enviar y recibir mensajes de correo electrónico, a través de

protocolos específicos, a los usuarios tanto de una misma red como de redes distintas.

Los protocolos de servicio de correo electrónico se definen de la siguiente manera:

SMTP: Protocolo basado en texto, utilizado para el intercambio de mensajes entre

dos servidores de correo electrónico.

POP (Protocolo Post Oficina o Post Office Protocol): Protocolo que descarga los
mensajes desde el servidor a la máquina del usuario. No necesita una conexión permanente
a Internet; ésta es necesaria únicamente al momento de hacer la solicitud al servidor de
correo de transferir los mensajes almacenados. También permite la posibilidad de acceder
a los mensajes vía web.

IMAP (Protocolo de Acceso a Mensajes de Internet o Internet Message Access

Protocol): De manera similar al POP, es un protocolo de acceso a mensajes almacenados
en un servidor, pero, a diferencia del anterior, éste permite acceder a los mensajes

33
instantáneamente, sin necesidad de descargarlos. Al utilizar IMAP, los clientes
permanecen conectados el tiempo que su interfaz permanezca activa y descargan los
mensajes bajo demanda.

Estos protocolos presentan un bajo nivel de seguridad, ya que los mensajes se

transmiten sin ningún tipo de cifrado. Para solucionar esto, se añade un método de cifrado
a implementar tanto en el servidor como en el cliente, mediante el protocolo criptográfico
SSL (Secure Socket Layer), el cual proporciona autenticación y privacidad a la
información.

Servidor Web

Aplicación que implementa el protocolo HTTP para proveer de contenido estático a

un navegador a través de la red. Generalmente los contenidos se transmiten bajo códigos
HTML (HyperText Markup Language), interpretados por el cliente para mostrar, por
ejemplo, los colores, las fuentes y los objetos en la página.

También pueden utilizarse aplicaciones web que se ejecuten bajo ciertas peticiones
o respuestas HTTP. Estas aplicaciones pueden estar tanto del lado del servidor como del
cliente, siendo estas por ejemplo las que corren bajo Java 1 . Aquellas del lado del servidor
se ejecutan y generan un código HTML que es enviado al cliente mediante el protocolo
HTTP, de manera que cualquier cliente pueda utilizarlas, sin necesitar capacidades
adicionales de software.

Servidor de aplicaciones

Equipo que proporciona servicios de aplicaciones a los clientes, gestionando la

mayor parte de las funciones de acceso a los datos. Utilizando este método, se centraliza el
manejo de la información para facilitar el desarrollo de las aplicaciones.

Estos servidores pueden incluir middleware o software de conectividad, para

utilizar servicios de confiabilidad y seguridad, así como una interfaz para programación de

1
Java: lenguaje de programación orientado a objetos.

34
aplicaciones (API) para permitir compatibilidad con los diferentes sistemas operativos o
interfaces web.

Servidor de Medios (Media Server)

Equipo que almacena contenido multimedia para proporcionarlo “bajo demanda” a

los usuarios. Su principal requerimiento es contar con un método de almacenamiento y una
conexión de red con suficiente velocidad para permitir acceso a los contenidos.

Dependiendo de los usos y aplicaciones presentes en el servidor, éste puede

requerir gran cantidad de memoria RAM, o un CPU Multicore. Para proporcionar mayor
capacidad de almacenamiento y prevenir pérdidas accidentales de información, pueden ser
utilizados arreglos RAID (Redundant Array of Independent Disks).

Muchos Media Servers también tienen la capacidad de capturar la data a través de

hardware especializado como tarjetas de sintonización de televisión o TV tuner cards y de
software para codificación y digitalización.

2.3.2 Dispositivos de enlace

Repetidores

Equipos que se encargan de retransmitir o repetir las señales eléctricas de un

segmento a otro de la red, a nivel de la capa 1 del modelo de referencia OSI. Hay que
tomar en cuenta que, al retransmitir todas las señales de un segmento a otro, también
retransmitirán las colisiones. Estos equipos sólo aíslan entre los segmentos los problemas
eléctricos que pudieran existir en algunos de ellos.

Concentrador conmutado o switch

Equipo que se encarga de reenviar paquetes de datos a los equipos para los que van
destinados, reconociéndolos según los campos de las direcciones IP.

35
 Los switches de red presentan dos arquitecturas básicas: "Cut-Through" y "Store-
and-Forward".

Los switches Cut-Through examinan únicamente el campo de dirección de destino

del paquete que ingresa, antes de enviarlo al segmento correspondiente. Esto representa
una ventaja de velocidad, ya que el proceso es sencillo y rápido.

Un switch Store-and-Forward, por el contrario, acepta y analiza el paquete entero

antes de enviarlo a su dirección de destino. Este proceso toma más tiempo, pero le permite
determinar posibles errores o daños en los paquetes y detener su propagación a través de la
red.

Puentes o bridges

Equipos utilizados para interconectar segmentos de red, con el fin de aislar las
colisiones que se produzcan en los segmentos interconectados entre si aunque el tráfico no
sea excesivamente alto.

Los bridges trabajan a nivel de la capa 2 del modelo de referencia OSI, con
direcciones físicas para comunicar los segmentos, filtrando tráfico. No filtra los
broadcasts, que son paquetes genéricos que lanzan los equipos a la red para que algún otro
les responda (aunque puede impedir el paso de determinados tipos de broadcast), por lo
que, al interconectar segmentos de red con bridges, podemos tener problemas de tormentas
de broadcasts, de saturación del puente por sobrecarga de tráfico, etc.

Enrutadores o routers

Equipos que interconectan tanto segmentos de red como redes diferentes entre sí,
eligiendo el mejor camino para enviar la información, al tiempo que balancean el tráfico
entre las líneas. Estos equipos trabajan a nivel de la capa 3 del modelo de referencia OSI,
siendo capaces de filtrar protocolos y direcciones a la vez.

36
 Poseen una entrada con múltiples conexiones a segmentos remotos, garantizan la
fiabilidad de los datos y permiten un mayor control del tráfico de la red. Su método de
funcionamiento es el encapsulado de paquetes.

Puertas de enlace o gateways

También llamados traductores de protocolos, son equipos que se encargan, como su

nombre indica, de servir de intermediario entre los distintos protocolos de comunicaciones
para facilitar la interconexión de equipos distintos entre sí.

Reciben los datos encapsulados de un protocolo, los van desencapsulando hasta el

nivel más alto, para posteriormente ir encapsulando los datos en el otro protocolo desde el
nivel más alto al nivel más bajo, y vuelven a dejar la información en la red, pero ya
traducida.

2.4 SERVICIOS – CAPA DE APLICACION

2.4.1 Sistema de Nombres de Dominio

Un nombre de dominio es una secuencia de nombres separados un punto como

carácter delimitador, cada uno de ellos gestionado generalmente por un servidor distinto.
El sistema de nombres de dominio asocia información a los llamados “nombres de
dominio”, traduciéndolos en direcciones IP; de la misma manera, almacena información
como listas de servidores de correo que aceptan mensajes de ciertos dominios. Esta
asignación es transparente al usuario, es decir, los nombres se asignan independientemente
de la jerarquía de enrutamiento físico representada por las direcciones IP y de las máquinas
que en efecto hospedan la información relacionada con las páginas web o direcciones de
correo electrónico. [8]

El espacio que abarcan dichos nombres de dominio está conformado por una
estructura de árbol, donde cada nodo presenta uno o más registros de recursos que
contienen información asociada a los nombres de dominio.

37
 Para su funcionamiento, el DNS utiliza tres componentes principales:

Clientes DNS (resolvers)

Envían las peticiones de resolución de nombres a un servidor DNS, donde se espera

obtener la dirección IP correspondiente a nombres de la forma nombre.dominio. Los
clientes DNS buscan información asociada a los nodos del espacio de nombres de dominio,
y tienen la capacidad de establecer comunicación con los servidores enviando solicitudes y
atendiendo respuestas.

Servidores DNS (name servers)

Contestan a las peticiones de los clientes consultando su base de datos. Si no

disponen de la dirección solicitada pueden reenviar la petición a otro servidor.

Espacio de nombres de dominio (domain name space)

Base de datos distribuida entre distintos servidores. Funciona bajo una estructura
jerárquica con forma de árbol que clasifica los distintos dominios en niveles, como se
muestra a en la figura 2.14:

Figura 2.14: Estructura de espacio de nombres de dominio [8]

38
 Diferentes porciones de los espacios de nombres de dominio se encuentran bajo
responsabilidad de servidores DNS, las cuales reciben el nombre de “Zonas de Autoridad”.
La zona de autoridad de estos servidores abarca al menos un dominio y también pueden
incluir subdominios; aunque generalmente los servidores de un dominio delegan sus
subdominios en otros servidores.

Los dominios de primer nivel (Top-Level Domains) han sido clasificados tanto en
función de su estructura organizativa como geográficamente, como en los siguientes
ejemplos:

En función de su estructura organizativa:

Nombre de dominio Significado

com Organizaciones comerciales
net Redes
org Otras organizaciones
edu Instituciones educativas
gov Organizaciones gubernamentales

Tabla 2.3: Dominios según su estructura organizativa

Geográficamente:

Nombre de dominio Significado

es España
tw Taiwán
fr Francia
ve Venezuela

Tabla 2.4: Dominios según su ubicación geográfica

Cuando se solicita una consulta a cualquier nombre de dominio, los servidores raíz
pueden al menos proporcionar los nombres y direcciones de los servidores de nombres
autoritarios para el dominio de primer nivel al que pertenece el nombre de dominio
buscado, mientras que los servidores de nombres de primer nivel pueden proporcionar la
lista de servidores de nombres autoritarios para el dominio de segundo nivel al que
pertenece el nombre de dominio buscado. De esta forma, cada servidor de nombres
consultado va proporcionando la información más próxima a la respuesta buscada, o
proporciona la propia respuesta.

39
2.4.2 Correo electrónico

El servicio de correo electrónico o e-mail permite el envío y recepción de mensajes

mediante sistemas electrónicos y protocolos de comunicación tales como SMTP y POP3.
Esta comunicación se establece entre clientes que posean cuentas de correo electrónico,
suministradas por proveedores de correo, quienes ofrecen el servicio de envío y recepción.
Las direcciones de correo electrónico son únicas para cada usuario.

El formato de direcciones electrónicas consta de dos partes: el nombre de usuario y

el dominio, separadas entre sí por el símbolo arroba. De esta manera, las direcciones de
correo electrónico son de la forma persona@servicio.com, y están asociadas a un nombre
de usuario y contraseña, y registradas con algún proveedor de servicios de este tipo.

Los mensajes de correo electrónico se almacenan en un servidor, y pueden ser

visualizados a través de web browsers o descargados a las computadoras personales a
través de programas denominados clientes de correo, que permiten leerlos sin necesidad de
conexión permanente a Internet.

2.4.3 Directorio Activo o Active Directory

Servicio de directorio en una red distribuida de computadores, que establece una

estructura jerárquica para relacionar entre sí los objetos de dicha red, tales como usuarios,
equipos, y sus correspondientes permisos, recursos y políticas de acceso. Físicamente, el
directorio activo está contenido dentro de cada Controlador de Dominio, donde también se
configura la función de servidores de Catálogo Global o Global Catalog (GC), que se
utilizan para proporcionar listados globales de todos los objetos del directorio.

Es una implementación de servicios de directorio del protocolo LDAP (Protocolo

de Acceso Ligero a Directorios o Lightweight Directory Access Protocol) para proveer
servicios centralizados de autenticación y autorización a los usuarios. Permite también a
los administradores de red asignar políticas, desplegar software y aplicar actualizaciones a
la organización.

40
 La estructura organizativa del directorio activo está conformada por tres elementos
fundamentales: bosques, árboles y dominios. Los bosques están constituidos por todos los
objetos del directorio, junto con sus atributos y reglas. Contienen uno o más árboles,
vinculados entre sí a través de relaciones de confianza. Cada árbol a su vez contiene uno o
más dominios que también se encuentran vinculados entre sí a través de jerarquías de
confianza transitivas. Los dominios se identifican a partir de su estructura de DNS.

FSMO Roles

Los roles Flexible Single Master Operations (FSMO) o roles de Maestro de Operaciones
son funciones asignadas a los controladores de dominio para realizar las actualizaciones en
el esquema del directorio, como se muestra en la tabla 2.5:

Nombre del Rol Scope Descripción

Maestro de Esquema 1 por bosque Controla actualizaciones del esquema.
Maestro de
1 por bosque Controla adiciones o remociones de dominios al bosque.
Nombres de Dominio
Proporciona compatibilidad a clientes NT4 para operaciones
de PDC (como cambios de contraseña). El PDC también
Emulador PDC 1 por dominio corre procesos específicos de dominio como Security
Descriptor Propagator (SDPROP), y representa el servidor
principal de tiempo dentro del dominio.
Asigna conjuntos de identificadores únicos a los
Maestro RID 1 por dominio
controladores de dominio para su uso al crear objetos.
Sincroniza cambios en membresías de grupos en dominios
Maestro de cruzados. El maestro de infraestructura no puede correr en
1 por dominio
Infraestructura un servidor de catálogo global, a menos que todos los
controladores de dominio sean también catálogos globales.

Tabla 2.5: Asignación de roles FSMO

2.4.4 World Wide Web

El World Wide Web o WWW es un sistema de documentos basado en el lenguaje

HTML y en el protocolo HTTP, cuyo contenido es visualizable a través de navegadores o
páginas web. Estos contenidos pueden abarcar texto, imágenes, video, etc. También
pueden contener hipertextos, que constituyen enlaces o conexiones con otros documentos
web.

41
 Cada página web tiene asociada una única dirección URL (Uniform Resource
Locator o Localizador Uniforme de Recursos) que permite que los navegadores las
encuentren y las muestren. A su vez, esta dirección está asociada a una dirección IP,
traducida por el DNS para contactar al servidor web que contiene la información e
intercambiar los paquetes de datos.

Estos procesos se basan básicamente en tres estándares: el URI (Uniform Resource

Identifier o Identificador de Recursos Uniforme) como sistema para referenciar recursos, el
HTTP como protocolo que establece la comunicación entre el navegador y el servidor, y el
HTML como lenguaje utilizado para definir la estructura y el contenido de los documentos.

2.4.5 Multimedia

Multimedia constituye toda combinación de contenido audiovisual (texto,

imágenes, video, sonido) en la composición de una aplicación informática dotada de cierta
interactividad [9]. En este caso, el término se refiere a contenido presentado a través de un
computador y transmitido por lo general a través de Internet. El contenido puede ser
“interactivo” cuando el usuario tenga cierto control sobre aspectos como cúando verlo y
cómo verlo, y se conoce como “multimedia no lineal”. Los contenidos que se presentan sin
que el usuario tenga control sobre los mismos se conocen como “multimedia lineal”.

En general, este sistema está caracterizado por el control por computadora,

producción integrada, manipulación, presentación, almacenamiento y transmisión de
información, la cual es codificada tanto a través de medios continuos (dependientes del
tiempo) como discretos (independientes del tiempo). [10]

2.4.5.1 Voz sobre IP

Los últimos desarrollos en el área de telefonía y telecomunicaciones han dado paso

a la transmisión de señales de voz, en formato de datos, sobre el protocolo de Internet,
llamado comúnmente VoIP (Voice over Internet Protocol). Estos paquetes de datos pueden
transitar por cualquier red basada en el protocolo IP, tales como redes de área local.

42
 Este sistema es compatible con los sistemas telefónicos tradicionales de la Red
Pública de Telefonía Conmutada o Public Switched Telephone Network (PSTN), utilizando
los dispositivos adecuados. Las llamadas entre dos usuarios de telefonía VoIP son
gratuitas, mientras que entre usuarios de PSTN y de VoIP generan costos para este último.

Los sistemas VoIP permiten establecer comunicaciones a través de cualquier

conexión a Internet, y generalmente incluyen servicios como llamadas en conferencia e
identificación de llamadas, que en el caso de PSTN generan cargos adicionales.

Existen dos tipos de servicio de PSTN a VoIP: Llamadas Locales Directas (Direct
Inward Dialling o DID) y Números de acceso. DID conecta a quien hace la llamada
directamente al usuario VoIP mientras que los Números de Acceso requieren que se
introduzca el número de extensión del usuario de VoIP. Los Números de acceso son
usualmente cobrados como una llamada local para quien hizo la llamada desde la PSTN y
gratis para el usuario de VoIP.

Los equipos terminales, que para el sistema PSTN son los teléfonos, en VoIP
pueden implementarse también mediante software, como es el caso del IP SoftPhone de
Cisco. Es importante tomar en cuenta que el uso de éstos depende de su conexión a la red,
ya que si no están conectados no puede establecerse comunicación.

Las desventajas de este sistema de comunicaciones radican en la calidad del

servicio. Al transmitirse las señales como paquetes de datos, es posible que los paquetes
lleguen con retrasos debido a la latencia de la línea de transmisión, que se generen
colisiones o que se pierdan los paquetes en el recorrido.

Recomendación H.323

La recomendación H.323 es un conjunto de estándares establecidos por la ITU

(International Telecommunication Union) que definen los componentes, protocolos y
procedimientos para suministrar servicios de comunicación multimedia sobre redes de
conmutación de paquetes, incluyendo a las redes que usan el protocolo IP. [11]

43
 Su uso en aplicaciones de VoIP se basa en establecer normas referentes a
codificación de voz, establecimiento de llamadas, señalización, transporte de datos,
terminales y equipos, a la vez que permite el control de tráfico de la red, lo cual disminuye
las posibilidades de que se produzcan caídas importantes en el rendimiento; sin embargo,
no es posible garantizar calidad de servicio, dadas las características de las redes IP.

La figura 2.15 ilustra el modelo general de integración de telefonía VoIP, donde la

puerta de enlace o gateway interconecta Internet (manejando los protocolos H.323) con la
red telefónica (manejando los protocolos PSTN o ISDN).

Figura 2.15: Integración de redes de telefonía

2.4.5.2 Webcasting / Webstreaming

Un webcast consiste en distribuir archivos multimedia (contenido de audio y video)

a través de Internet utilizando tecnología streaming media para hacerlos llegar a muchos
usuarios simultáneamente. De la misma manera que las transmisiones de multidifusión o
broadcast, el webcast puede transmitirse en vivo o pregrabado, por lo que se define
“webcasting” como “broadcasting a través de Internet”.

Este sistema se utiliza en aspectos del sector comercial tales como presentaciones,
conferencias, aprendizaje vía web o E-Learning, entre otros.

44
 El concepto de streaming media se basa en presentar multimedia continuamente a
los usuarios a medida que es enviada. El nombre hace referencia al método de entrega más
que a la media en sí. En general, el contenido multimedia necesita mucho espacio
disponible para su almacenamiento, por lo que los costos de almacenamiento transmisión
son significativos, utilizando diversos métodos de compresión.

El media stream puede ser en vivo o bajo demanda. Para la transmisión “bajo
demanda”, los contenidos se almacenan en servidores por largos periodos de tiempo y
están disponibles para ser transmitidos bajo solicitud de los usuarios. Para la transmisión
“en vivo”, los contenidos se encuentran disponibles únicamente en un momento
determinado. La aplicación cliente puede ir presentando o utilizando los datos sin
necesidad de descargar la información completamente.

2.5 INTERCONEXION DE REDES

Distintas redes pueden conectarse entre sí de manera física o inalámbrica,

independientemente de sus características individuales, a través de protocolos
estandarizados. De esta manera, usuarios en distintas redes tienen capacidades de acceso y
comunicación con las demás.

Las redes presentan capacidades de intercomunicación en cada nivel de las

aplicaciones, mediante diversos dispositivos:

Dispositivos de capa de enlace: puentes y conmutadores. Aceptan tramas,

reconocen las direcciones MAC y reenvían las tramas a otra red, con capacidad de traducir
protocolos.

Dispositivos de capa de red: enrutadores. Puede ser compatible con los distintos
formatos de paquetes, y manejar múltiples protocolos.

Dispositivos de capa de transporte: puertas de enlace (gateways) de transporte.

Interactúan entre dos conexiones de transporte, soportando que presenten protocolos
diferentes.

45
 Dispositivos de capa de aplicación: puertas de enlace (gateways) de aplicación.
Traducen semánticas del mensaje.

2.5.1 Redes privadas virtuales

Las redes privadas virtuales (VPN) son conexiones virtuales creadas utilizando la
infraestructura de otras redes para permitir el tráfico de datos de manera segura entre los
dos extremos, en un entorno privado y confidencial. [12]

Para esto es necesario establecer procedimientos de autenticación y autorización,

donde se debe verificar la identidad de los usuarios y permitir el acceso a aquellos con
permisología para hacerlo y restringir a quienes no estén autorizados. También debe
garantizarse integridad y confidencialidad de la comunicación, logrado a través de
protocolos de seguridad, codificación de datos y administración de claves.

Es posible establecer redes privadas virtuales bajo dos tipos de arquitectura de

conexión:

VPN de acceso remoto: establece conexiones entre equipos remotos utilizando Internet
como vínculo de acceso.

VPN punto a punto: establece conexiones entre equipos remotos a través de una sede
central.

Por otra parte, la implementación de estas redes virtuales puede categorizarse de la

siguiente manera:

Implementación basada en hardware: ofrecen mayor rendimiento y facilidad de

configuración.

Implementación basada en cortafuegos (firewall): ofrecen altos niveles de seguridad

debido a que utilizan la protección que generan los firewall.

46
Implementación basada en software: son más configurables, y permiten mayor
compatibilidad debido a la posibilidad de actualización. Actualmente, las tendencias se
inclinan hacia los productos de código abierto.

En cualquier caso, estas conexiones se efectúan bajo el protocolo IPSec (Internet

Protocol Security), que añade cifrado a los datos y permite el uso de servicios de
autenticación. También pueden utilizarse otros protocolos como PPTP (Point-to-Point
Tunneling Protocol), L2F (Layer-2 Forwarding), L2TP (Layer-2 Tunneling Protocol),
SSL/TLS (Secure Socket Layer/Transport Layer Security), SSH (Secure SHell), entre
otros.

IPSec

Protocolo que añade sistemas de protección de los datos transferidos y garantiza

que la información del emisor del paquete coincida con la suministrada por la dirección IP.
Provee confidencialidad, integridad, autenticidad y protección a repeticiones mediante los
protocolos AH (Authentication Protocol) y ESP (Encapsulated Security Payload).

PPTP

Como protocolo de túnel, PPTP encapsula datagramas de cualquier protocolo de

red en datagramas IP, que luego son tratados como cualquier otro paquete IP. De esta
manera, cualquier protocolo puede ser enrutado a través de una red IP, como Internet.

PPTP fue diseñado para permitir a los usuarios conectarse a un servidor RAS
(Remote Access Server - Servidor de Acceso Remoto) desde cualquier punto en Internet
para tener la misma autenticación, encriptación y los mismos accesos de LAN como si
discaran directamente al servidor.

L2TP

Este protocolo facilita la creación de un túnel para los paquetes a través de una red,
de manera tal que sea lo más transparente posible a los usuarios de ambos extremos del
túnel y para las aplicaciones que éstos corran.

47
 Se requiere que el protocolo de transporte de L2TP tenga la posibilidad de brindar
servicios de encriptación, autenticación e integridad para el paquete L2TP en su totalidad.
Como tal, L2TP sólo se preocupa por la confidencialidad, autenticidad e integridad de los
paquetes L2TP entre los puntos extremos del túnel, no entre los extremos físicos de la
conexión.

2.5.2 Redes virtuales de área local

Las redes virtuales de área local (VLAN) son redes lógicas definidas dentro de
redes físicas, independientemente de si la comparten o no, mediante el uso de software.
Estos segmentos lógicos no pueden intercambiar información entre si utilizando la red
física, mas podrían hacerlo a través de un router.

Estas redes se configuran como un dominio de broadcast dentro de un conjunto

definido de switches. Los puertos de un switch pueden agruparse en VLANs para limitar el
tráfico de datos y dejar pasar sólo a los que pertenezcan a esas redes, y enviar los demás
paquetes a un router.

La segmentación de redes en VLANs produce mayor escalabilidad, seguridad,

integridad de datos y mejor manejo de la red.

2.6 ACCESO A REDES WAN

Frame Relay es una técnica de comunicación mediante retransmisión de tramas,

cuya aplicación resulta de gran utilidad si se desean de transmitir grandes cantidades de
datos, en casos tales como transmisión de voz y datos a alta velocidad. [13]

Ofrece un alto rendimiento y confiabilidad, además de un mejor aprovechamiento

del ancho de banda de las redes debido a su capacidad para adaptarse a las necesidades de
las aplicaciones, pudiendo usar una mayor velocidad de la contratada en momentos
puntuales, adaptándose muy bien al tráfico en ráfagas. [13]

48
 Al contratar un servicio Frame Relay, se contrata un ancho de banda determinado
en un tiempo determinado, o ancho de banda promedio, llamado CIR (Commited
Information Rate), garantizado por el Proveedor de Servicios de Internet (Internet Service
Provider o ISP) bajo condiciones normales de operación. Suele presentarse una asignación
adicional de ancho de banda llamada EIR (Excess Information Rate o Tasa de Exceso de
Información) que se utiliza para controlar la velocidad de transmisión de datos cuando no
existe congestión en la red.

El valor resultante de sumar el CIR más el EIR es igual o menor a la velocidad del
puerto de acceso a la red, como lo ilustra la figura 2.16 [14].

Figura 2.16: Transmisión mediante Frame Relay

Originalmente, la tecnología Frame Relay fue diseñada para ser utilizada a través
de las ISDN (Interfaces de la Red Digital de Servicios Integrados). Hoy en día, se utiliza
también a través de una gran variedad de interfaces de otras redes.

Frame Relay es un ejemplo de tecnología de conmutación de paquetes. En las redes

que utilizan esta tecnología, las estaciones terminales comparten el medio de transmisión

49
de la red de manera dinámica, así como el ancho de banda disponible. Los paquetes de
longitud variable se utilizan en transferencias más eficientes y flexibles. Posteriormente,
estos paquetes se conmutan entre los diferentes segmentos de la red hasta que llegan a su
destino. [15]

2.7 MONITOREO DE RED

Los software de monitoreo de red se utilizan para detectar y solucionar problemas

en equipos y servicios de la red. En general, el esquema de monitoreo de red de estas
aplicaciones se basa en recoger información de la red, almacenarla en una base de datos,
analizar el estado y los datos de los eventos, y generar reportes en tablas y gráficos al
tiempo que envía notificaciones de dichos eventos a los administradores de red.

Una aplicación de monitoreo correctamente implementada debe lograr que se

reduzcan los tiempos de inactividad o downtime en los equipos y servicios de la red, se
genere una rápida detección y solución de problemas de red sin interrupción de los
servicios, se obtenga mayor habilidad para monitorear datos y anticipar problemas, y para
ejecutar acciones al ocurrir algún evento predeterminado.

Estas aplicaciones se implementan con el fin de aumentar el desempeño y la

disponibilidad de la red, aumentar la eficiencia del equipo de trabajo y disminuir los gastos
operativos que se generan debido a fallas de los sistemas de red.

SNMP (Simple Network Management Protocol o Protocolo de Simple

Administración de Redes)

SNMP es un protocolo utilizado por sistemas de gestión de red, que comunica los
elementos de red entre sí y permite tener datos concretos del tráfico que se produce en la
red, así como quien lo produce. Para que esto funcione, los elementos de red deberán estar
equipados con un agente SNMP que debe ser activado y configurado para comunicarse con
el sistema de gestión de red (por lo general vienen integrados y preconfigurados).

50
 Un equipo monitoreado es un nodo de red que contiene un agente SNMP, que
recopilan y almacenan información para ponerla a disposición de los sistemas de gestión.
Estos equipos pueden ser routers, servidores de acceso, switches, bridges, hubs, teléfonos
IP, impresoras, entre otros.

Un agente es un software de red o módulo que reside en los equipos monitoreados,

que tiene conocimiento local del manejo de información y la traduce a un formato
compatible con SNMP.

Un sistema de gestión de red o Network Management System (NMS) ejecuta

aplicaciones que controlan los equipos monitoreados, proporcionando información a los
usuarios acerca de las capacidades de memoria y procesamiento de los mismos.

51
 Capítulo III.
DESARROLLO DEL PROYECTO

52
 Capítulo III. Desarrollo del proyecto

En este capítulo se explica la metodología utilizada para cumplir con los objetivos.
Se describe la situación inicial de la empresa, los requerimientos de software y hardware
indispensables para cumplir con los objetivos propuestos y la implementación de los
cambios necesarios para dicho fin.

3.1 SITUACION INICIAL

Inicialmente, la red de la empresa Protokol estaba estructurada según el diagrama

mostrado en la figura 3.1:

Figura 3.1: Esquema inicial de red

53
 Esta red presenta una topología híbrida y en cuanto al método de transmisión de
datos se considera una red de difusión, con una relación funcional cliente-servidor.

Esta red contaba con 12 servidores, organizados como lo muestra la tabla 3.1:

SERVIDOR ALIAS MODELO DIRECCION IP DIRECCION MAC APLICACIONES

Exchange + Website EXCHWEB ML 350 10.10.10.2 Servidor de correo
Servidor web
File Server PTKFILE ML 350 192.168.0.201 000E7FFF0290 FTP
Lan Services - Print Spooler PTKPDC ML 350 192.168.0.202 000802F0FE9D
Carry IN HP LP 1000r 192.168.0.203
Flexline PTKFLEX ML 150 192.168.0.206 001321B40623 Flexline
Sun AAA 192.168.0.208 0003BA02A857 Pruebas AAA
Operaciones PTKOPERACIONES ML 350 192.168.0.205 000BCDCB6BB7
CallManager Callmanager MCS 192.168.0.242 000D60ECD692 Cisco CallManager

Tabla 3.1: Servidores conectados en red

Dentro de la estructura de la empresa, los servidores que no se encontraban

conectados a la LAN están enumerados en la tabla 3.2:

SERVIDOR ALIAS MODELO DIRECCION IP DIRECCION MAC APLICACIONES

HP-UX HP-UX 192.168.0.207 HP-UX
Physical Access ACCESS 192.168.0.209 0008C709718E SW Acceso

Tabla 3.2: Servidores desconectados de la red

Los demás dispositivos conectados inicialmente a la red se muestran en la tabla 3.3:

EQUIPO MODELO DIRECCION IP DIRECCION MAC

Data Protector 1/8 Tape
Data System Backup Unit
Autoloader
Core Switch Cisco # 192.168.0.235 00169D05EA80
Switch Catalyst 2 Cisco WS-C2950G-24-EI 192.168.0.236 0014A844CD80
Switch Catalyst 3 Cisco WS-C2950T-24 192.168.0.237 0016C88FE580
Switch Catalyst 4 Cisco WS-C2950G-48-EI 192.168.0.238 0016C7B51C00
Access Point PB 192.168.0.243 000BBE2DE825
Access Point 1 192.168.0.244 00121760AE47
Router 2800 Cisco 2801 192.168.0.250 00146960F389
Firewall Fortinet 300A 192.168.0.251 00090F03B7BE
ABA CANTV ABA 200.44.32.12

Tabla 3.3: Dispositivos de enlace

54
 Inicialmente, la red contaba con dos enlaces de banda ancha ABA de 2084 Kbps de
velocidad de transmisión de datos. Estos enlaces presentaban mucha inestabilidad, siendo
la caída del servicio de correo electrónico la consecuencia más crítica. Los enlaces no
proporcionaban suficiente ancho de banda para el tráfico de datos que generaban los
usuarios de la red, y el servicio presentaba constantes fallas o intermitencias que afectaban
la conectividad, por lo que se plantea instalar un enlace de Internet dedicado basado en la
tecnología Frame Relay, el cual constituye un servicio que cubre eficientemente los
requerimientos de confiabilidad y estabilidad de conexión.

El consumo de ancho de banda en las sucursales de la empresa en Venezuela

correspondía a los datos que se presentan en la tabla 3.4:

Caracas Puerto Ordaz

Aplicaciones Kbytes Aplicaciones Kbytes
Voz 22000 Voz 1320
Video 12800 Video 768
Aplicaciones 2500 Aplicaciones 150
Email 4500 Email 270
Web 30000 Web 1800
Total (Kbytes) 71800 Total (Kbytes) 4308

Tabla 3.4: Consumo de ancho de banda

En cuanto a los servicios de telefonía IP, Protokol, al ser socio estratégico

certificado de Cisco Systems, adquirió toda la plataforma de comunicaciones que incluye
el Cisco CallManager como componente de procesamiento de llamadas y el Cisco Unity
como sistema de mensajería unificada.

La disponibilidad de la conexión a Internet es fundamental para el funcionamiento

de la empresa. A través del correo electrónico se manejan muchas transacciones como
solicitudes, notificaciones, transacciones bancarias, entre otras, por lo cual es
imprescindible contar con una conexión estable.

55
3.2 REQUERIMIENTOS DE DISEÑO

Luego de llevar a cabo un estudio detallado de la estructura y el funcionamiento de

la red, se plantearon las siguientes necesidades:

3.2.1 Conectividad y requerimientos de banda ancha

3.2.1.1 Acceso externo a la red de Protokol

La DMZ o Zona Desmilitarizada2 presente en la red local como una subred que
contiene únicamente servidores que necesitan acceso desde redes externas, contenía las
aplicaciones de correo electrónico y servidor web en una sola máquina, siendo la principal
desventaja de esta configuración que la probabilidad de fallas a nivel de hardware afectaría
a dos aplicaciones importantes de la red.

Dada la necesidad de estar altamente disponibles para el acceso público, se decide

colocar cada una de estas aplicaciones en dos servidores distintos. Esta separación facilita
entonces identificar las fallas y llevar a cabo procedimientos correctivos, mantenimiento
del equipo, al mismo tiempo que aumenta la confiabilidad de las aplicaciones.

3.2.1.2 Enlace de Internet

Dada la necesidad de una conexión de Internet dedicado, se decide implementar un

enlace Frame Relay. Este tipo de enlace se utiliza para la transmisión de datos a altas
velocidades. Está pensado para aplicaciones que generen tráfico cuyo comportamiento es
en forma de ráfaga (burst traffic) de altos volúmenes de datos y de transmisión frecuente,
para lo cual se establece una conexión virtual permanente entre el origen y el destino.

2
Zona Desmilitarizada: subred ubicada entre la red interna de una organización y la red externa, aislándolas
para proteger el acceso hasta la red interna.

56
 En el caso de Protokol, se decidió colocar un Frame Relay de 648/512 Kbps
dedicados (siendo 648 Kbps la velocidad máximo y 512 la mínima). Este equipo otorga 8
direcciones IP públicas y fijas, que permiten crecimiento a nivel de servicios de red
accesibles, tales como DNS externo, establecimiento de túneles VPN,
Webcasting/Webstreaming, y herramientas de colaboración en línea.

Este equipo se conectó directamente al router Cisco, mientras que el Firewall

controla el tráfico de salida y entrada de conexiones de Internet.

Se planteó colocar un enlace de redundancia basado en ABA, para que, en caso de

presentarse fallas en el Frame Relay, la red se mantenga disponible. Se pretende que este
equipo pueda soportar únicamente los servicios de correo electrónico y acceso a Internet
para los usuarios. Los demás servicios no son considerados prioritarios, por lo que
permanecerían “caídos” hasta reanudar la operación del Frame Relay.

3.2.1.3 Interconexión entre sucursales

Como se comentó anteriormente, la empresa Protokol cuenta con una sucursal

principal en Caracas, una en Puerto Ordaz, Edo. Bolívar, y otra en Santo Domingo,
República Dominicana. En el alcance de este proyecto se plantea interconectar las dos
sucursales de la empresa presentes en Venezuela a través de túneles VPN, para reducir los
costos relacionados con llamadas telefónicas aprovechando los recursos de telefonía IP
(equipos y licencias) con los que cuenta la empresa. El establecimiento de éste túnel VPN
constituye una conexión segura y garantiza acceso WiFi a los usuarios de la sucursal de
Puerto Ordaz.

Para unificar las dos redes en cuanto a esquema y equipos, se colocaron Firewall
Fortinet en cada sede. A través de éstos se establecen túneles VPN que permiten establecer
conexiones directas, Lan-to-Lan, compartiendo así los anchos de banda de las redes. De
esta manera, es posible incluso hacer llamadas IP asignando a los usuarios de la sede de
Puerto Ordaz un número de extensión telefónica dentro del mismo rango de la sede de
Caracas, reduciendo costos en llamadas de larga distancia.

57
3.2.1.4 VPNs para conectividad con clientes

También surge la necesidad de permanecer conectados o establecer conexiones

seguras con clientes a los que se les prestan servicios de soporte, como lo son Movilnet y
CANTV.

En el caso de Movilnet, es necesario establecer túneles VPN a través de los routers

Cisco, para ofrecer más eficientemente el servicio de soporte a la plataforma de Real Time
Billing. Con CANTV, el TAC (Technical Assistance Center) de plataformas Comverse de
Protokol requiere la una conexión VPN para el servicio de soporte a la plataforma de
mensajería de voz.

3.2.1.5 Segmentación de redes de voz y datos

Debido a las condiciones de estructura, ancho de banda y velocidades de

transmisión de la red, se propone establecer una separación lógica de los paquetes para
diferenciar los de voz y los de datos, aplicándoles “etiquetas” que, dándole más prioridad a
los paquetes de voz, permitan un mejor aprovechamiento de los canales de comunicación y
asegurar mejor calidad de servicio.

3.2.1.6 Servidor de correo electrónico

En la estructura inicial de la red se observó que el servicio de correo electrónico y

el servidor web de la empresa se encontraban instalados en un mismo equipo, lo cual era
muy ineficiente, generando problemas considerables a la hora de comunicarse con los
clientes a través del servicio de e-mail, y ocasionando una bloqueo del acceso temporal a la
página web.

Siendo uno de los principales problemas de la red de Protokol las fallas en el

servidor de correo, se decide que cada una de las aplicaciones debe instalarse en servidores
independientes, con el fin de aumentar la eficiencia en el cumplimiento de sus funciones
individuales, y disminuir el número de fallas.

58
 Se decidió instalar el nuevo servidor de correo basado en el sistema operativo
Microsoft Windows Server 2003 y el software Microsoft Exchange 2003 Server para la
creación y administración de los buzones de correo electrónico, debido a que tanto el
sistema operativo como el software eran de ampliamente conocidos para los
administradores de la red, además de ser sistemas bastante estables.

3.2.2 Aplicaciones y herramientas de desarrollo

3.2.2.2 VoIP

Inicialmente, la empresa contaba con equipos y licencias para la implementación de

telefonía IP mediante la aplicación Cisco CallManager, y la unificación de ésta con un
servicio de mensajería de voz integrado con notificaciones vía correo electrónico a través
de la aplicación Cisco Unity. La primera se encontraba en estado funcional, mientras que la
segunda estaba instalada mas no configurada. Fue necesario entonces configurar la
aplicación para integrarla con el Cisco CallManager y aprovechar estos recursos que
permiten mejorar las comunicaciones tanto internas como externas de la empresa.

El software Cisco Unified CallManager es el componente para el procesamiento de

llamadas del sistema de Comunicaciones Unificadas de Cisco, el cual gestiona las
funciones de telefonía IP y permite mayor eficacia en las comunicaciones.

Incluye la consola de Cisco Unified CallManager Attendant, una aplicación para

realizar conferencias ad-hoc, la herramienta de administración por lotes de Cisco Unified
CallManager, la herramienta de análisis y creación de informes de CDR (registro de
detalles de llamada) de Cisco Unified CallManager, la herramienta de supervisión en
tiempo real de Cisco Unified CallManager y la aplicación Cisco Unified CallManager
Assistant.

El acceso a estas herramientas se lleva a cabo a través de una interfaz web, con
posibilidad de acceso remoto. Todas las actividades de administración del sistema, como el
control del espacio en el disco, la supervisión del sistema y las actualizaciones, están

59
automatizadas o se controlan a través de una GUI (Graphic User Interface o interfaz
gráfica de usuario).

Este software debe instalarse en un servidor Cisco Media Convergence Server

(MCS), como en efecto se encuentra en la empresa.

3.2.2.3 Monitoreo de red

Dadas las frecuentes fallas de conectividad en la red, se propone instalar un sistema

de monitoreo que contribuya a la rápida detección de la falla y su origen, anticipar
problemas en caso de ser posible (análisis predictivo), con el fin de generar una solución
eficiente, sin necesidad de interrumpir los servicios.

En consecuencia, al implementar una herramienta de monitoreo, se esperaría un

aumento en el desempeño y la disponibilidad de la red, aumento en la eficiencia del equipo
de trabajo y reducción de gastos operativos.

Nagios es una aplicación de monitoreo de red, que chequea equipos y servicios

especificados en la configuración de la misma. Posee un sistema de alertas que envía
notificaciones a los administradores de la red en cuestión (previa configuración de la lista y
los grupos de contactos), para informarles cuando se suscitan problemas y cuando éstos
son solucionados. De esta manera, el programa permite hacer seguimiento al status de la
red.

Se puede acceder a la aplicación a través una interfaz web, que permite observar el
estado actual de la red, registros, historiales y reportes.

Algunos de beneficios de la aplicación de Nagios incluyen:

- Monitoreo de servicios de redes (SMTP, POP3, HTTP, NNTP, PING, etc.).

- Monitoreo de recursos de servidores (processor load, disk usage, etc.).
- Notificaciones de fallas (vía email, pager, u otros métodos).
- Habilidad de definir y programar eventos.

60
 - Soporte para implementación de servidores redundantes.
- Interfaz web para revisar el estado de la red, notificaciones, historial,
archivos de registro, etc.
- Licenciamiento de Uso Gratis.

3.2.2.4 Cambio de dominio

En el esquema de red inicial, los servidores, las aplicaciones y los equipos de la red
pertenecían al dominio público protokolgroup.com, mientras que las estaciones de trabajo
pertenecían al dominio local protokol.com. Ésta configuración no causaba problemas,
pero no era la más eficiente, ya que los usuarios se registraban al dominio local al acceder
a las máquinas, pero también debían autenticarse contra el directorio activo del dominio
público al momento de descargar correo electrónico o acceder a las carpetas compartidas,
por ejemplo. En muchos casos, las contraseñas de acceso de cada usuario eran diferentes
para cada dominio.

Para unificar entonces el comportamiento de los usuarios ante la red, se decidió

renombrar el dominio protokol.com para que pasara a ser parte del dominio
protokolgroup.com.

3.2.2.5 Sistema de gestión de seguridad

El software McAfee ePolicy Orchestrator (ePO) es una plataforma que permite

administrar las políticas de seguridad de datos y equipos de la red mediante un control
centralizado.

El sistema genera alertas de riesgo en los equipos, permite detectar e instalar

actualizaciones de seguridad antivirus de manera programada, y distribuirlas a todos los
equipos conectados. De esta manera se garantiza que los usuarios no comprometan la
seguridad de sus equipos, disminuyendo el riesgo de infección y vulnerabilidad de toda la
red debido a sistemas que no cumplen con las reglas.

61
 En resumen, esta aplicación realiza una revisión periódico de la red (la frecuencia
con la que se realiza es fijada por el administrador de la misma), se asegura de que todos
los equipos tengan sus antivirus actualizados, y repara o remueve aquellos archivos y
aplicaciones que son potencialmente dañinas para la red. Asimismo, envía reportes vía e-
mail a los administradores de la red, advirtiendo de amenazas en esta, o simplemente
informando sobre el status de la misma.

Entonces, para cubrir los requerimientos descritos anteriormente, se estableció

como primer objetivo reestructurar la red bajo el esquema que se ilustra en la figura 3.2:

Figura 3.2: Propuesta fina de red

Para obtener esta configuración, se implementaron los cambios que se describen a

continuación:

62
3.3 IMPLEMENTACION

3.3.1 Acceso a Internet

La salida a Internet, que antes se lograba a través de dos módems ABA, ahora se
lleva a cabo a través de un Frame Relay de y un módem ABA de redundancia. Para ésto,
una vez establecido el enlace Frame Relay desde el Core Switch, se especificaron reglas en
el Firewall para permitir que los usuarios utilicen la ruta del Frame Relay para conectarse a
Internet, y en caso de fallas en este equipo, accedan a través del módem ABA.

El establecimiento de las reglas de conexión depende del origen y destino de las

solicitudes. La asignación de puertos en el Firewall se muestra en la figura 3.3:

Figura 3.3: Puertos de origen y destino

63
 Estos puertos corresponden a:

Puerto 1 Red privada (Segmento 192.168.X.X)

Puerto 2 Frame Relay
Puerto 3 ABA
Puerto 4 DMZ
Puerto 5 Frame Relay

De esta manera, la regla establece que las conexiones salientes de los miembros de
la red privada se realizan a través del Frame Relay, de la misma manera que el servidor de
correo electrónico tanto en conexiones entrantes como salientes. En caso de fallas, las
conexiones pasarían a través del puerto 3 destinado al ABA.

3.3.2 Interconexión de sucursales

Como se describió anteriormente, las sucursales de la empresa presentes en

Venezuela (Caracas y Puerto Ordaz) se comunican directamente a través de un cliente
VPN instalado en el Firewall Fortinet de cada oficina. En este equipo se estableció un
direccionamiento que permite las conexiones directas Lan-to-Lan, dando acceso total y
mutuo a los usuarios de ambas redes.

El equipo tiene la posibilidad de establecer túneles VPN bajo los protocolos IPSEC,
PPTP y/o SSL. En este caso, el túnel VPN que conecta las sucursales de Protokol se
estableció bajo el protocolo IPSEC.

Para el establecimiento de las políticas de conexión en el Firewall, se configuran

las direcciones IP de los puertos de origen y destino, siendo éste último dentro de la red
interna el módem a través del cual se establecen las conexiones a Internet. También es
necesario incluir las direcciones IP específicas de los equipos de la red de Puerto Ordaz
para otorgar el acceso necesario, que en este caso fue total para permitir comunicación
plena y bidireccional. Así se muestra en las figuras 3.4 y 3.5:

64
 Figura 3.4: Asignación de políticas con origen puerto 1 y destino puerto 2

Figura 3.5: Asignación de políticas con origen puerto 4 y destino puerto 2

Para la creación del túnel VPN, se crearon dos directivas agrupadas para cada
sucursal, donde se establecen las conexiones seguras entre ellas, como se muestra en las
figuras 3.6 a 3.12:

65
Figura 3.6: Redes Privadas Virtuales definidas

Figura 3.7: Red Privada Virtual Caracas

66
Figura 3.8: Direccionamiento de Red Privada Virtual Caracas

Figura 3.9: Propiedades de Red Privada Virtual Caracas

67
 Figura 3.10: Red Privada Virtual Puerto Ordaz

Figura 3.11: Direccionamiento de Red Privada Virtual Puerto Ordaz

68
 Figura 3.12: Propiedades de Red Privada Virtual Puerto Ordaz

Esta configuración permite entonces establecer conexiones directas, bidireccionales

y seguras entre las dos sucursales de la empresa.

3.3.3 Instalación servidor de correo electrónico

En el esquema inicial de red de la empresa, el Exchange Server se encontraba

instalado en el mismo equipo que contenía las aplicaciones de la página web. Se decidió
migrar la aplicación de correo a otro equipo con la finalidad de aprovechar mejor los
recursos de la máquina, y asegurar un mejor funcionamiento del servicio.

Para instalar y configurar el nuevo servidor de correo electrónico, los procesos

involucrados fueron los descritos por el diagrama mostrado en la figura 3.13:

69
 Instalación Exchange Server
Windows Server 2003
2003

Ejecucuón
Configurar discos asistente de
(RAID5) instalación del
sistema operativo

Configuración y Eliminar OWA

¿Existen Si
formato de particiones
particiones?
particiones existentes

No Activar
Form-based
Authentication
Dividir disco duro
en dos particiones
de igual tamaño
Comprobar
servicios Web del
servidor
“Formatear la
partición utilizando
el sistema de
archivos NTFS”
RPC sobre HTTP

Detección e
instalación de
dispositivos Comprobar
servicio

Establecer
configuración Exchange Server
regional e idioma Activo

Introducir de clave
de producto y
modo de licencia
(por plaza)

Establecer
nombre de equipo
y contraseña

Sistema
operativo
instalado

Figura 3.13: Flujograma de instalación de servidor de correo

El nuevo servidor se configuró entonces para uso exclusivo de aplicaciones de

mensajería, es decir, servicios de correo electrónico y Active Directory. Para esta
aplicación específica se instaló Microsoft Exchange Server 2003, Enterprise Edition, bajo
sistema operativo Windows Server 2003.

70
 El equipo cuenta con una tarjeta Smart Array 6 (controladora de discos), que
permite almacenar la información en arreglos de discos externos denominados RAID
(Redundant Array of Independent Disks o conjunto redundante de discos independientes).
El servidor de correo Exchange 2003 debe ser capaz de almacenar bases de datos y
archivos de procedimientos de manera confiable, por lo cual se deben usar configuraciones
RAID1 o RAID5 para asegurar la data en caso de fallas de disco duro.

En este caso se utilizó una configuración RAID5 mediante tres discos de 32 GB,
donde la unidad lógica de redundancia tiene capacidad de 32 GB, mientras que los 64 GB
restantes se ven como una sola unidad. Esta configuración se llevó a cabo utilizando el
aplicativo SmartStart® de HP.

Para la configuración del disco duro del servidor se establecieron dos particiones,
cada una de las cuales está dispuesta para trabajar bajo el sistema de archivos NT (NTFS).
El programa de instalación de Windows Server 2003 crea las particiones del disco en el
equipo, da formato a la unidad y copia los archivos de instalación del CD al servidor. De
esta manera, el primer disco o partición contiene Windows Server 2003, archivos de la
infraestructura común (como los paquetes de Windows Installer) y los archivos de registro
de Active Directory, mientras que la segunda partición contiene los archivos de instalación
de Exchange 2003 Server.

71
 Requisitos del sistema:

Enterprise Datacenter
Requirement Standard Edition Web Edition
Edition Edition
133 MHz for x86- 400 MHz for x86-
based computers based computers
Minimum CPU
133 MHz 733 MHz for 733 MHz for 133 MHz
Speed
Itanium-based Itanium-based
computers* computers*
Recommended
550 MHz 733 MHz 733 MHz 550 MHz
CPU Speed
Minimum RAM 128 MB 128 MB 512 MB 128 MB
Recommended
256 MB 256 MB 1 GB 256 MB
Minimum RAM
32 GB for x86- 64 GB for x86-
based computers based computers
Maximum RAM 4 GB 512 GB for 512 GB for 2 GB
Itanium-based Itanium-based
computers* computers*
Minimum 8
Multiprocessor
Up to 4 Up to 8 required Up to 2
Support **
Maximum 64
1.5 GB for x86- 1.5 GB for x86-
based computers based computers
Disk Space for
1.5 GB 2.0 GB for 2.0 GB for 1.5 GB
Setup
Itanium-based Itanium-based
computers* computers*

Tabla 3.5: Requisitos del sistema para las versiones de Windows Server 2003

72
 Component Requirement
133-MHz or faster processor for x86-based PCs; 733-MHz for
Computer and
Itanium-based PCs; up to eight processors supported on either the
processor
32-bit or the 64-bit version
128 MB of RAM minimum required; maximum: 32 GB for x86-
Memory based PCs with the 32-bit version and 64 GB for Itanium-based PCs
with the 64-bit version
1.5 GB of available hard-disk space for x86-based PCs; 2 GB for
Hard disk Itanium-based PCs; additional space is required if installing over a
network
Drive CD-ROM or DVD-ROM drive
Display VGA or hardware that supports console redirection required
Windows Server 2003 Enterprise Edition, 64-bit version is
Other compatible only with 64-bit Intel Itanium-based systems and cannot
install on 32-bit systems

Tabla 3.6: Requisitos para Windows Server 2003 Enterprise Edition

El proceso detallado de instalación y configuración de los componentes necesarios

para poner en funcionamiento el nuevo servidor de correo corresponde al Anexo 1 de este
documento.

3.3.4 Integración de sistemas de telefonía y mensajería

Para instalar y configurarlos servicios de telefonía IP, se llevó a cabo el proceso que
se observa en la figura 3.24:

73
Figura 3.24: Flujograma de integración de sistemas de telefonía IP

74
 Para integrar los sistemas de Cisco Unity y Cisco CallManager es necesario contar
con la versión 4.1.3 de este último. Hasta el momento de la verificación, la versión
instalada era 4.1.2, por lo que se ejecutó la herramienta Cisco Upgrade Unity, ubicada en la
ruta Inicio/Programas/Cisco Systems, Inc. Esta herramienta permite determinar si el
servidor Callmanager cumple con los requisitos de hardware y software indispensables
para ejecutar el upgrade a la versión 4.1.3.

El proceso detallado de instalación y configuración de los componentes necesarios

para la integración de los sistemas de telefonía corresponde al Anexo 2 de este documento.

3.3.5 Monitoreo de red

Para instalar y configurar el sistema de monitoreo de red, los procesos involucrados

fueron los descritos por los siguientes diagramas:

Instalación del sistema operativo, tal como se muestra en la figura 3.25:

75
 Figura 3.25: Flujograma de instalación sistema operativo Fedora 7

Instalación de Nagios, tal como se muestra en la figura 3.26:

76
 Nagios

Instalar servidor
web, compilador
C, librería GD

Crear cuenta de
usuario y
contraseña

Crear grupo para

uso de comandos
sobre interfaz web

Descargar
paquetes de
instalación

Compilar archivos
de instalación

Reiniciar el
servicio web
(Apache)

Comprobar
Service httpd
configuración de getenforce 1 Setenforce 0
restart
SELinux

Service nagios
start

Nagios iniciado

Figura 3.26: Flujograma de proceso de instalación de Nagios

Para llevar a cabo la instalación del sistema, es necesario que el equipo corra bajo
ambiente Linux y con un compilador C. En nuestro caso, el servidor destinado para correr
la aplicación utiliza Fedora 7 como sistema operativo y compilador GCC, además del
servidor web Apache, y la librería GD versión 1.6.3.

77
 El sistema operativo también debe tener configurado TCP/IP, ya que la mayoría de
los chequeos de servicios se llevan a cabo sobre protocolos de red.

El proceso detallado de instalación y configuración de los componentes necesarios

para poner en funcionamiento el sistema de monitoreo corresponde al Anexo 3 de este
documento.

3.3.6 Sistema de gestión de seguridad

Para la implementación del sistema McAfee ePolicy Orchestrator (ePO) fue

necesario revisar los requisitos del mismo, los cuales se enumeran a continuación:

Requisitos de servidor y consola

• Espacio libre en disco: 500 MB como mínimo (primera instalación); 650 MB como
mínimo (actualización); se recomienda 2 GB
• Memoria: 512 MB de RAM disponible; se recomienda 1 GB
• Procesador: Intel® Pentium® II o superior; 450 Mhz o superior
• Servidor dedicado recomendado: si administra más de 250 computadores cliente,
McAfee recomienda usar un servidor dedicado
• Microsoft® Windows® 2000 Server/Advanced Server con Service Pack 3 o
superior, Microsoft Windows 2003 Enterprise/Standard/Web

Requisitos de software de base de datos

• Microsoft SQL Server 2000 Desktop Engine (MSDE 2000) con Service Pack 3,
Microsoft SQL Server Standard/Enterprise Edition con Service Pack 3
• SQL2005 SP1

Requisitos de la consola remota

• Espacio libre en disco: 250 MB

• Memoria: 128 MB de RAM disponible
• Procesador: Intel Pentium II o superior
• Microsoft Internet Explorer 6.0 o superior

78
 • Microsoft Windows 2000 Server/Advanced/Professional/Terminal con Service
Pack 3 o superior, Microsoft Windows Server 2003 Standard/Enterprise/Web,
Microsoft Windows XP Professional con Service Pack 1.

Habiendo confirmado que el servidor cumple con los requisitos, el siguiente paso
previo a la instalación del software fue asegurarse de haber instaladas todas las
actualizaciones para Windows 2003 Server. Se evitó utilizar el puerto 80 para cualquier
comunicación HTTP vía ePO, ya que dicho puerto puede ser desactivado en caso de un
ataque de virus. Uno de los requerimientos indispensables para instalar ePO con éxito, es
instalar un software de base de datos, que en este caso fue SQL 2000 Server.

El proceso detallado de instalación y configuración de los componentes necesarios

para poner en funcionamiento el sistema de gestión de seguridad corresponde al Anexo 4
de este documento.

3.3.7 Cambio de dominio

La ejecución del renombramiento del dominio local de la empresa para estandarizar

el acceso a las aplicaciones incluye los procesos que se muestran en la figura 3.42:

79
Figura 3.42: Flujograma de procesos de renombramiento de dominio

80
 Estos procedimientos incluyen la creación de relaciones de confianza entre el
dominio a ser renombrado y el dominio principal (que se desea mantener), y la revisión de
los procesos previos y posteriores al renombramiento.

Al finalizar las acciones mencionadas en el flujograma anterior, el dominio

protokol.com deja de existir, convirtiéndose todos sus miembros parte del dominio
protokolgroup.com.

El proceso detallado de instalación y configuración de los componentes necesarios

para realizar el renombramiento de dominio corresponde al Anexo 5 de este documento.

81
 Capítulo IV.
ANALISIS DE RESULTADOS
 Capítulo IV. Análisis de resultados

En este capítulo se presentan los resultados obtenidos durante el desarrollo del

proyecto, así como el análisis de los mismos.

Luego de la implementación de los cambios descritos anteriormente, la estructura

de la red interna de la empresa Protokol quedó de la manera que se muestra en la figura
4.1:

Figura 4.1: Esquema final de red

83
 SERVIDOR ALIAS MODELO DIRECCION IP DIRECCION MAC APLICACIONES
E-Mail PTKMAIL ML 350 10.10.10.2 Servidor de correo
WebSite WEBSITE ML 350 10.10.10.4 Servidor web
Unity UNITY MCS 10.10.10.5 Cisco IP Unity
Call Manager CALLMANAGER MCS 192.168.0.242 000D60ECD692 Cisco IP CallManager
Sun AAA AAA 192.168.0.208 Pruebas AAA
File Server PTKFILE ML 350 192.168.0.203 000E7FFF0290 Archivos
Operaciones PTKOPERACIONES ML 350 192.168.0.205 000BCDCB6BB7
Nagios NAGIOS ML 150 192.168.0.210 Nagios
Finanzas PTKFLEX ML 150 192.168.0.206 001321B40623 Flexline
Antivirus / Antispam ePO ML 150 192.168.0.200 McAfee ePO
Lan Services PTKPDC ML 350 192.168.0.202 Servicios de impresión

Tabla 4.1: Servidores dentro de la red definitiva

Dentro de la estructura de la empresa, los servidores que se mantienen

desconectados de la LAN son los enumerados en la tabla 4.2:

SERVIDOR ALIAS MODELO DIRECCION IP DIRECCION MAC APLICACIONES

HP-UX HP-UX 192.168.0.207 HP-UX
Physical Access ACCESS 192.168.0.209 0008C709718E SW Acceso

Tabla 4.2: Servidores desconectados de la red

Los demás dispositivos conectados a la red se enumeran en la tabla 4.3:

EQUIPO MODELO DIRECCION IP DIRECCION MAC

Data Protector 1/8 Tape
Data System Backup Unit
Autoloader
Core Switch Cisco WS-C2950G-24-EI 192.168.0.235 00169D05EA80
Switch Catalyst 2 Cisco WS-C2950T-24 192.168.0.236 0014A844CD80
Switch Catalyst 3 Cisco WS-C2950G-48-EI 192.168.0.237 0016C88FE580
Switch Catalyst 4 Cisco WS-C2950G-48-EI 192.168.0.238 0016C7B51C00
Access Point PB 192.168.0.243 000BBE2DE825
Access Point 1 192.168.0.244 00121760AE47
Router 2800 Cisco 2801 192.168.0.250 00146960F389
Firewall Fortinet 300A 192.168.0.251 00090F03B7BE
Frame Relay 200.
ABA CANTV ABA 200.44.32.12

Tabla 4.3: Dispositivos de enlace en la red definitiva

La conexión del túnel VPN entre Protokol y su cliente final Movilnet se ilustra en
la figura 4.2:

84
 Figura 4.2: Conexión VPN Comverse – Movilnet

La distribución física de los puertos del switch principal se muestra a continuación:

Tabla 4.4: Conexiones físicas (Patch Panel vs. Switch)

85
 Por otra parte, las conexiones de cada uno de los equipos al switch se presentan en
la tabla 4.5:

Tabla 4.5: Distribución física de equipos

En la tabla anterior se enumeran los puertos de los switches de la red de la empresa,

y se indica cuál equipo está conectado a cada uno de ellos. En el switch principal o Core
Switch se conectaron los servidores, los módems de enlace, el router y el firewall, mientras
que las máquinas de los usuarios y las impresoras compartidas se distribuyeron en los
puertos de los tres switches restantes.

Para separar los segmentos de datos de los segmentos de voz, se dividió la red
lógica en dos redes virtuales de área local, siendo la distribución definitiva la mostrada en
las tablas 4.6 y 4.7:

86
 Grupo Sub-grupo IP Address Equipo
192.168.1.0
192.168.1.1 PTKSERVICES
192.168.1.2 PTKFILE
192.168.1.3 PTKBDC
192.168.1.4 PTKPDC
192.168.1.5 DESARROLLO2
192.168.1.6 PTKFLEX
192.168.1.7 Exchange
192.168.1.8 Web
Servidores 192.168.1.9 IP Unity
192.168.1.10 IP CallManager
192.168.1.11 ePO
192.168.1.12 Nagios
192.168.1.13 SunServer_P
192.168.1.14
192.168.1.15
…
192.168.1.28
Direcciones
fijas / 192.168.1.29 Core Switch
servidores 192.168.1.30 Switch Catalyst 2
192.168.1.31 Switch Catalyst 3
192.168.1.32 Switch Catalyst 4
Dispositivos
de red 192.168.1.33 Access Point PB
192.168.1.34 Access Point 1
192.168.1.35 Router 2900
192.168.1.36 Firewall
192.168.1.37 Camaras
192.168.1.39 HP LaserJet 4250
192.168.1.40 HP LaserJet 4250-1
192.168.1.41 Xerox Phaser 8200 DP
Impresoras 192.168.1.42 HP LaserJet 3700
192.168.1.43 HP LaserJet 4250-2
192.168.1.44 HP LaserJet 2420
192.168.1.45 HP LaserJet 4250-3
192.168.1.46
…
192.168.1.50

Tabla 4.6: Asignación de direcciones en el segmento de datos

Pool IP Reservado
192.168.1.51 192.168.1.60 Usuarios VPN
192.168.1.61 192.168.1.160 Usuarios Laptop
192.168.1.161 192.168.1.190 Usuarios Desktop
192.168.1.191 192.168.1.254 Libres

Tabla 4.7: Reserva de direcciones en el segmento de datos

87
 Las pruebas más importantes acerca del funcionamiento del nuevo esquema de red
se llevaron a cabo utilizando el sistema de monitoreo Nagios, cuya implementación se
mencionó anteriormente. Dicho sistema se configuró para realizar chequeos de
disponibilidad de equipos y servicios cada 90 segundos, indicando si se presentaban
pérdidas de paquetes o retrasos en las respuestas. El almacenamiento de estos resultados en
la base de datos del servidor, integrada con Nagios, permite generar estadísticas con
respecto al funcionamiento de la red.

Partiendo de los datos presentados por Nagios, se pudo generar la tabla 4.8 que
contiene las estadísticas de disponibilidad de equipos entre los meses de noviembre y
enero:

HOST PERIODO UP DOWN

Nov 98,354% 1,646%
Access Point 1 Dic 99,978% 0,022%
Ene 99,845% 0,155%
Nov 98,427% 1,573%
Access Point PB Dic 100,000% 0,000%
Ene 99,979% 0,021%
Nov 98,403% 1,597%
CANTV - Puerto
Serial Dic 100,000% 0,000%
Ene 99,899% 0,101%
Nov 96,759% 3,241%
CANTV DNS Dic 96,995% 3,005%
Ene 97,346% 2,654%
Nov 98,468% 1,532%
Core Switch Dic 100,000% 0,000%
Ene 100,000% 0,000%
Nov 98,434% 1,566%
Desarrollo 2 Dic 100,000% 0,000%
Ene 99,875% 0,125%
Nov 98,348% 1,652%
Exchange Dic 99,975% 0,025%
Ene 99,929% 0,071%
Nov 98,381% 1,619%
Firewall Dic 100,000% 0,000%
Ene 100,000% 0,000%
Nov 98,440% 1,560%
Call Manager Dic 99,995% 0,005%
Ene 99,990% 0,010%
Nov 98,392% 1,608%
Unity Dic 100,000% 0,000%
Ene 99,990% 0,010%
Nov 98,488% 1,512%
PTK DMZ Dic 100,000% 0,000%
Ene 100,000% 0,000%
PTKFILE Nov 98,382% 1,618%

88
 Dic 100,000% 0,000%
Ene 99,964% 0,036%
Nov 98,397% 1,603%
PTKFLEX Dic 73,919% 26,081%
Ene 91,769% 8,231%
Nov 98,445% 1,555%
PTKPDC Dic 100,000% 0,000%
Ene 99,964% 0,036%
Nov 98,376% 1,624%
PTKSERVICES Dic 100,000% 0,000%
Ene 99,979% 0,021%
Nov 98,409% 1,591%
ROUTER 2900 Dic 100,000% 0,000%
Ene 99,913% 0,087%
Nov 93,476% 6,524%
SUN SERVER Dic 99,979% 0,021%
Ene 100,000% 0,000%
Nov 98,415% 1,585%
SWITCH CATALYST
2 Dic 100,000% 0,000%
Ene 99,984% 0,016%
Nov 98,433% 1,567%
SWITCH CATALYST
3 Dic 100,000% 0,000%
Ene 99,990% 0,010%
Nov 98,439% 1,561%
SWITCH CATALYST
4 Dic 99,979% 0,021%
Ene 99,838% 0,162%
Nov 98,481% 1,519%
WEB SERVER Dic 100,000% 0,000%
Ene 99,972% 0,028%
Nov 98,458% 1,542%
ePO Dic 100,000% 0,000%
Ene 99,975% 0,025%

Tabla 4.8: Estadísticas de disponibilidad según Nagios

Las gráficas correspondientes a éstos datos se observan en el Anexo 6 de éste

documento.

El hecho de contar con una herramienta que tenga la capacidad de mostrar los datos
históricos del desempeño de los equipos de la red constituye una ventaja significativa con
respecto a la situación inicial de la red. Se observaron mejoras en el proceso de atención y
solución de las fallas ya que es posible conocer con certeza el equipo y el servicio que las
presenta, ahorrando tiempo y recursos.

Por otra parte, éstos datos indican que, a pesar de que equipos como el módem
ABA o el PTKFLEX (que aloja el sistema de contabilidad, el cual presentó desconexiones

89
y fallas técnicas en el mes de diciembre) presentaron menos de 98% de disponibilidad, los
demás sistemas se mantuvieron por encima de ese valor.

Luego de implementar el enlace de Frame Relay y de migrar el servidor de correo

electrónico, el servicio se estabilizó, permitiendo así el mejor desempeño de los usuarios.
Luego de la instalación del sistema de seguridad McAfee ePO, los correos basura que
llegaban al servidor se redujeron en un 98%, garantizando de esta manera la integridad de
los sistemas de la red.

En cuanto al sistema de telefonía, su integración con el servicio de correo permite

que los usuarios reciban los mensajes de voz a través de sus computadoras, lo cual les
permite mantenerse comunicados aunque estén fuera de la oficina.

La integración entre las sucursales de la empresa ha sido satisfactoria, generando

muchos beneficios técnicos y económicos: el gasto en llamadas de larga distancia nacional
se eliminó completamente, las dos oficinas tienen acceso a los archivos y servicios
presentes en su par, de manera que se reducen significativamente las barreras geográficas.

90
 Capítulo V.
CONCLUSIONES Y RECOMENDACIONES
 Capítulo V. Conclusiones y recomendaciones

Este capítulo contiene las conclusiones extraídas luego del desarrollo del proyecto.
También se formulan recomendaciones para darle continuidad a las actividades realizadas.

La evolución de los sistemas informáticos en las últimas décadas ha sido muy

acelerada, siendo uno de los sucesos más críticos para la conexión en red la aparición y la
rápida difusión de las redes de área local (LAN) como forma de normalizar las conexiones
entre las máquinas utilizadas en sistemas de información. A pesar de la diversidad de
topologías, métodos de acceso y protocolos posibles para ser implementados en las redes,
todas las LAN comparten la característica de poseer un alcance limitado y deben tener una
velocidad suficiente para que la red de conexión resulte transparente para los equipos que
la utilizan.

En este sentido, durante el desarrollo del proyecto se comprobó la importancia de

conocer las herramientas que contribuyen al óptimo funcionamiento de las redes,
entendiéndose como sistemas que permiten mantener la disponibilidad, operabilidad,
control y seguridad de las mismas. Esto permite a los administradores de red ser más
eficientes en su labor, al tiempo que proporciona beneficios económicos a la empresa
cuando cuenta con un sistema competente y fiable para el desempeño de sus funciones.

Otro argumento en favor de este nuevo modelo de redes se basa en la gran

presencia actual de las infraestructuras IP en los entornos corporativos de datos, ya que es
posible emplear el ancho de banda inutilizado para soportar el tráfico de voz y fax.
Además, al permitir que los datos viajen por separado a través de la red (datos y voz), se
aumenta la eficiencia global de la red, así como las sinergias entre su diseño, despliegue y
gestión. En el caso particular de este proyecto, la implementación de los sistemas de
telefonía IP contribuye al mejor aprovechamiento del ancho de banda de la red, y su
integración con el sistema de mensajería de voz facilita a los usuarios sus procesos de
comunicación e información.

92
 Los resultados obtenidos en el transcurso del proyecto confirmaron que para la
empresa es fundamental mantener los sistemas informáticos actualizados, garantizar su
seguridad y ejercer controles permanentes. El mantenimiento de las condiciones de la red
no sólo depende de la capacidad o estabilidad de los equipos conectados a la misma, sino
de saber hacer adecuado seguimiento a su funcionamiento.

La instalación del enlace de Frame Relay, al proporcionar una velocidad de

transmisión dedicada, constituyó un elemento clave en las mejoras de la red en cuanto a
estabilidad de las conexiones y disponibilidad de los servicios. Por su parte, el enlace ABA
fue el que más fallas presentó según los datos arrojados por la herramienta de monitoreo
Nagios, por lo que hay que continuar prestando atención a su desempeño y buscar el origen
de las fallas para evitar inconvenientes al momento de utilizar este equipo.

La implementación del sistema de gestión de seguridad ePO de McAfee ha

permitido estandarizar las políticas en las máquinas de cada usuario y mantenerlas
actualizadas contra posibles intrusiones o ataques maliciosos, de manera automatizada.

Para la empresa, la implementación del sistema de monitoreo basado en Nagios ha

sido fundamental en el desempeño de la red, ya que ha permitido optimizar los servicios de
acuerdo a las estadísticas obtenidas, y brinda la posibilidad de conocer y atender las fallas
que se presentan de manera oportuna. De esta implementación también se deriva una
oportunidad de negocio para la empresa, que actualmente está implementando este
monitoreo para uno de sus clientes. Partiendo de los datos suministrados por la herramienta
se observa que es posible incrementar los porcentajes de disponibilidad discutidos
anteriormente, siendo necesaria la unificación de criterios por parte de los administradores
de red para fijar los valores que se quieren alcanzar.

Como recomendaciones a la empresa, se pueden puntualizar las siguientes:

a. Estudiar todas las soluciones de comunicaciones que surgen cada día para evaluar
aquellas que permitan un mayor aprovechamiento de la infraestructura implantada,
en particular las actualizaciones de los sistemas de telefonía y de sistemas de
seguridad antivirus.

93
b. Estimar las ventajas de utilizar aplicaciones para la supervisión de las estaciones de
trabajo de los operadores de la red en los distintos departamentos que conforman la
empresa, para llevar un mejor control de las mismas en cuanto a políticas de
seguridad y actualizaciones de software.

c. Hacer pruebas rutinarias del servicio de protección de red que fue instalado en la
empresa.

d. Efectuar una revisión periódica (al finalizar cada mes) de las estadísticas de
disponibilidad de equipos y servicios de la red, con el fin de dar seguimiento a las
posibles fallas y generar soluciones oportunas y permanentes a las mismas.

e. Llevar un registro de todas las modificaciones que le sean realizadas a la red y

documentar todos los procesos.

f. Estudiar la posibilidad de instalar herramientas de colaboración que permitan la

interacción de los grupos de trabajo de las organizaciones que componen la
empresa para facilitar el soporte técnico a los mismos.

g. Considerar la revisión de las capacidades de los equipos de enlace, para la mejorar

la transmisión de datos desde y hacia las redes externas a la empresa y dar prioridad
a servicios como correo electrónico que necesitan permanecer disponibles al menos
en un 99%.

h. Involucrar de manera activa a los miembros de los departamentos de la empresa en

la búsqueda de mejoras a los sistemas existentes, según las necesidades de los
usuarios y los requerimientos de la empresa para mantener o incrementar el nivel
de socio estratégico de las marcas a las que representan, al tiempo que el
departamento de Operaciones, encargado del soporte técnico a nivel interno,
participe en la evaluación de la factibilidad de las propuestas.

94
 REFERENCIAS BIBLIOGRAFICAS

[1] Groth, D., Skandier, T., “Guía del estudio de redes”, Sybex, Inc., 4ta. Edición (2005).

[2] Tanenbaum, A. “Redes de Computadoras”, Prentice Hall, 4ta. Edición (2003).

Turnbull, J., “Pro Nagios 2.0”, Apress (2006).

[3] De La Fuente R., A., “Metodología de Desarrollo de Aplicaciones Multimedia” (2007).

[4] “Sistemas Multimedia”,

http://creaweb.ei.uvigo.es/creaweb/jsp/crearAsignatura.jsp?codigo=0127110

[5] http://es.wikipedia.org/wiki/TCP/IP

[6] http://es.wikipedia.org/wiki/Proxy

[7] Microsoft TechNet, “Software de Servidores”.

[8] Mata, M., “El estándar H.323 para comunicación multimedia”, CTI Magazine (1998).

[9] http://www.geocities.com/txmetsb/el_modelo_de_referencia_osi.htm

[10] http://es.wikipedia.org/wiki/Arquitectura_de_red

[11] Smaldone, J., “Domain Name System”, (2006).

[12] http://es.wikipedia.org/wiki/Red_privada_virtual

[13] http://en.wikipedia.org/wiki/List_of_network_protocols

[14] Kessler, G., “Frame Relay: CIR and billing issues”, Network VAR (1995).

[15] Spanier, S., Stevenson, T., “Tecnologías de Interconectividad de Redes”, Prentice

Hall, Cisco Press.

95
 PAGINAS WEB CONSULTADAS

AccessGrid, “Installation of Fedora 7”, http://www.accessgrid.org/node/776

Cisco Systems, “Cisco 1841 Integrated Services Router”,

http://www.cisco.com/en/US/products/ps5875/index.html

Cisco Systems, “Cisco 2800 Series Integrates Services Router”,

http://www.cisco.com/en/US/prod/collateral/routers/ps5854/ps5882/product_data_sheet09
00aecd8016fa68_ps5854_Products_Data_Sheet.html

Cisco Systems, “Cisco 7800 Series Media Convergence Servers”,

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/ps5748/ps378/product_data_
sheet0900aecd805e6f87.html

Cisco Systems, “Cisco Aironet 1200 Series”,

http://www.cisco.com/en/US/products/hw/wireless/ps430/products_data_sheets_list.html

Cisco Systems, “Cisco CallManager Administration Guide”,

http://cisco.com/en/US/docs/voice_ip_comm/cucm/admin/4_1_2/ccmcfg/b02dtgrp.html

Cisco Systems, “Cisco Catalyst 2950 Series Switches with Standard Image SW”,
http://www.cisco.com/en/US/products/hw/switches/ps628/products_data_sheet09186a0080
1cfb71.html

Cisco Systems, “Cisco Unity: Ventajas para los profesionales de TI”,

http://www.cisco.com/web/LA/soluciones/comercial/unity.html

Fedora Project, “Fedora 7 Installation Guide”, http://docs.fedoraproject.org/install-

guide/f7/en_US/

Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T.,
“Hypertext Transfer Protocol — HTTP/1.1”, Information Sciences Institute. (June 1999).

96
Fortinet Knowledge Center, http://kc.forticare.com/default.asp?id=0&Lang=1&SID=

HP, “HP Proliant Servers”,

http://h18004.www1.hp.com/products/servers/platforms/index.html

Microsoft Developer Network, “Restoring an Active Directory Server”,

http://msdn2.microsoft.com/en-us/library/aa746425.aspx

Microsoft TechNet, “How Domain Rename works”,

http://technet2.microsoft.com/windowsserver/en/library/4d0c3b6e-e6f5-4ab3-9d81-
106ae3a715491033.mspx?mfr=true

Microsoft TechNet, “Rename a Domain Controller”,

http://technet2.microsoft.com/windowsserver/en/library/aad1169a-f0d2-47d5-b0ea-
989081ce62be1033.mspx?mfr=true

Microsoft TechNet, “Using Multiple Forests with Exchange”,

http://technet.microsoft.com/en-us/library/aa998404.aspx

Nagios Org., “Fedora Quickstart”, http://nagios.sourceforge.net/docs/3_0/quickstart-

fedora.html

97
 BIBLIOGRAFIA

Holme, D., Thomas, O., “Managing and maintaining a Microsoft Windows Server 2003
Environment”, Microsoft Press (2003).

Mackin, J.C., McLean I., “Implementing, managing and maintaining a Microsoft Windows
Server 2003 Network Infrastructure”, Microsoft Press (2003).

Microsoft Corporation, “Step-by-Step Guide to Implementing Domain Rename” (2004)

Microsoft Official Course, “Implementing and managing Microsoft Exchange Server

2003”, Vol. I y II.

Polo, L., “World Wide Web Technology Architecture: A Conceptual Analysis”, New
Devices (2003).

Scott, C., Wolfe, P., Erwin, M., “Virtual Private Networks”, O´Reilly & Associates, 2da.
Edición (1999).

Smith, P., “Frame Relay: Principles and Applications”, Addison-Wensley Publishers

(1993).

Spealman, J., Hudson, K., Craft, M., “Planning, implementing and maintaining a Microsoft
Windows Server 2003 Active Directory Infrastructure”, Microsoft Press (2003).

Zacker, C., “Planning and maintaining a Microsoft Windows Server 2003 Network
Infrastructure”, Microsoft Press (2003).

98
ANEXOS
 Anexo 1. Instalación y configuración servidor de correo electrónico

Instalación de Windows Server 2003

Para comenzar el proceso, se introduce el CD de instalación, el cual iniciará

automáticamente el asistente. Una de las primeras acciones a ejecutar es la configuración
de las particiones. Se procede a eliminar manualmente las particiones existentes hasta que
el disco tenga la etiqueta “Espacio no particionado”, para proceder a crear una que cumpla
con los requerimientos de nuestra aplicación. Se escogió dividir el espacio en disco por la
mitad, para crear dos particiones de igual tamaño, y se selecciona “Formatear la partición
utilizando el sistema de archivos NTFS <rápido>”.

El programa de instalación de Windows Server 2003 da formato a la partición y

copia los archivos del CD de Windows Server 2003 a la unidad de disco duro. Así, hasta el
momento sólo una de las particiones queda formateada.

Para completar la instalación, el Asistente detecta e instala los dispositivos, se

realizan los cambios necesarios para establecer la configuración regional y el idioma
adecuados, se personaliza el software, se introduce la clave del producto, se selecciona el
modo de licencia (en este caso, del tipo “Por plaza”), se introduce el nombre del equipo y
se establece una contraseña de administrador. Una vez completado este proceso, el sistema
operativo queda completamente instalado en el servidor, y puede accederse a él mediante
un inicio de sesión.

Ahora, el espacio no particionado del disco debe recibir formato para que el sistema
operativo pueda tener acceso a él, lo cual se lleva a cabo en Administración de equipos,
dentro de Herramientas administrativas del menú Inicio.

En Administración de discos, se selecciona la partición restante y se selecciona la

opción de dar formato rápido utilizando el sistema NTFS.

100
 Figura A.1: Administración de discos

Para poder continuar con la correcta configuración del servidor, copiar los usuarios
de Active Directory y proceder con la instalación de Exchange, debemos asegurarnos de
tener instalados todos los servicios necesarios de Windows. En Panel de control, entramos
a Agregar o quitar programas, y luego a Agregar o quitar componentes de Windows, donde
debemos seleccionar y comprobar los siguientes ítems:

5 Servicios de red:
… DHCP
5 RPC sobre HTTP
5 Autenticación de Internet
5 Cuarentena de acceso remoto
5 WINS
5 TCP/IP
5 DNS
5 Servidor de aplicaciones:
5 ASP.NET
5 COM+
5 IIS:
5 Administrador de servicios de IIS
5 Archivos comunes
5 NNTP

101
 5 FTP
5 SMTP
5 World Wide Web

Este servidor debe actuar como controlador de dominio para responder a las
solicitudes de autenticación de los usuarios del servicio de correo electrónico, para lo cual
es necesario contar con una partición NTFS con suficiente espacio libre, una cuenta de
Administrador, una NIC (Network Interface Card o tarjeta de interfaz de red), una
configuración apropiada de TCP/IP (dirección IP, máscara de subred y gateway), una
conexión de red, un servidor DNS (Domain Name Server) y un nombre de Dominio.

Para instalar DNS y Active Directory mediante las herramientas manuales, se

ejecuta DCPROMO y se selecciona la opción de incorporar el servidor a un dominio
existente, el cual en nuestro caso es protokolgroup.com. En la pantalla Diagnósticos de
registro de DNS, se oprime Instalar y configurar el servidor DNS en este equipo.

Figura A.2: Resumen de las opciones de instalación de Active Directory

A continuación se escribe la dirección IP, máscara de subred y gateway

correspondientes al servidor, y por último se reinicia el equipo.

En el menú de Usuarios y equipos de Active Directory, al cual se accede a través de

Herramientas administrativas, se muestran paneles que contienen menús y sub-menús

102
desplegables, así como íconos de opciones, que permiten agregar unidades organizativas,
cuentas de usuarios, agregar usuarios a grupos existentes, entre otros.

Figura A.3: Crear unidades organizativas

Figura A.4: Estructura final de unidades organizativas

103
 Figura A.5: Agregar un usuario

Figura A.6: Lista de usuarios de la unidad organizativa “Oficinas centrales”

Figura A.7: Lista de miembros del grupo de seguridad “Administración”

104
 En este caso, se copiaron los usuarios de Active Directory desde el servidor de
correo existente al servidor nuevo. Esto se lleva a cabo automáticamente al momento de
configurar el DNS e incorporar el servidor al dominio, mediante el protocolo RPC (Remote
Procedure Call).

Instalación de Exchange Server 2003

Para comenzar la instalación, se introduce el CD y se inicia el asistente, donde debe

introducirse la clave del producto, y posteriormente seleccionar instalación típica.

Figura A.8: Instalación de componentes de Microsoft Exchange 2003

En la pantalla de Tipo de Instalación, debe escogerse la opción de incorporarse a

una organización existente.

105
 Figura A.9: Incorporar a una organización existente de Exchange

Para finalizar, se comprueban en la ventana de Resumen de Instalación los

componentes a instalar y sus directorios asignados.

Figura A.10: Resumen de instalación

106
Configuración del Outlook Web Access

Outlook Web Access (OWA) es una herramienta importante de Exchange, que

permite a los usuarios acceder al correo electrónico desde cualquier lugar a través de un
Web browser.

Para esto, se debe activar la FBA (Form-based Authentication), entrando al

Administrador del sistema de Exchange. Se deben desplegar los sub-menús Grupos
Administrativos, Primer grupo administrativo y Servidores, donde debe estar listado el
servidor sobre el cual se está trabajando (en nuestro caso PTKMAIL2). Al desplegar ese
ícono, se accede a Protocolos, luego a HTTP, y se selecciona Servidor Virtual de Exchange
para revisar sus Propiedades. En la pestaña Configuración, se marca “Habilitar
autenticación basada en formularios”, con el nivel de compresión en “Ninguno”. Después
de esta acción es necesario reiniciar el servicio de IIS, ejecutando IISReset.

Para configurar la FBA para trabajar sin SSL (Secure Socket Layer), es decir, para
poder utilizar OWA sin necesidad de establecer una conexión segura, se abre el Editor de
registros ejecutando “regedit”. En el directorio
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb se
crea una nueva variable de tipo DWORD con el nombre de AllowRetailHTTPAuth y valor
decimal 1.

Por último, se debe comprobar la configuración de los servicios Web del servidor, a
través del Administrador de IIS. Al entrar a dicho administrador, en la carpeta Sitios Web
del servidor local, se encuentra el Sitio Web Predeterminado, en cuyas Propiedades se debe
comprobar:

- Filtro ISAPI:
OwaLogon debe estar UP

- Seguridad de directorios:
- Autenticación y control de acceso:
- Modificar…:
… Habilitar el acceso anónimo

107
 5 Autenticación de Windows integrada

Al desplegar Sitio Web Predeterminado, se chequean las propiedades de cada uno

de los sub-ítems que allí se encuentran, para asegurar que los más importantes estén
configurados correctamente:

- ExchWeb Propiedades:
- Seguridad de directorios:
- Autenticación y control de acceso:
- Modificar…:
5 Habilitar el acceso anónimo

- Public Propiedades:
- Seguridad de directorios:
- Autenticación y control de acceso:
- Modificar…:
… Habilitar el acceso anónimo
5 Autenticación básica

- Rpc Propiedades:
- Seguridad de directorios
- Autenticación y control de acceso:
- Modificar…:
… Habilitar el acceso anónimo
5 Autenticación de Windows integrada

Configuración de Remote Procedure Call (RPC) sobre HTTP

Durante el proceso de instalación de Windows Server se instalaron todos los

servicios que se necesitarían posteriormente. Debido a que OWA trabaja bajo el protocolo
de RPC sobre HTTP, debemos comprobar que el servicio está instalado. Para comprobar
ésto:

- Panel de control:

108
- Agregar o quitar programas:
- Agregar o quitar componentes de Windows:
5 Servicios de red:
5 RPC sobre el proxy http

109
 Anexo 2. Integración sistemas de telefonía

Instalación del Sistema Operativo para Cisco Unity Server

De la misma manera que para el Cisco CallManager, el Cisco Unity debe instalarse
en un servidor Cisco Media Convergence Server (MCS). En nuestro caso, se disponen de
dos servidores MCS, para instalar cada una de las aplicaciones por separado.

Inicialmente, se debe revisar la configuración de hardware del servidor. En caso de

tener múltiples discos duros, se realiza la configuración de los mismos utilizando el
software de Cisco Unity RAID Configuration.

Se llevó a cabo la instalación del software del Sistema Operativo para Cisco Unity
Server utilizando el Cisco Unity Platform Configuration Disc For MCS-7815I-3.0-ECS1,
que inicia un asistente de instalación.

En Modo de Licenciamiento se eligió la opción Per Server. Se introdujo un nombre

para el servidor, que en nuestro caso fue UNITY, y se especificó una contraseña.

En la ventana de Network Settings, se seleccionó Typical Settings, y

posteriormente la opción No, this computer is not on a network, or is on a network
without a domain, para seleccionar el dominio al cual va a pertenecer el servidor
posteriormente.

Una vez finalizada la instalación, se accedió al servidor haciendo uso de una cuenta
de usuario miembro del grupo de Administradores Locales del equipo.

Se introdujo el CD de etiqueta Cisco Unity Service Packs CD 1, para luego acceder

al directorio Cuspa, el archivo Cuspa.vbs.

En la ventana de lenguaje, se seleccionó English. En la página Cisco Unity Server

Characteristics, se seleccionó Unified Messaging en el campo de Configuration. En el
campo de Failover, se seleccionó This Is a Primary or Secondary Failover Server, y en
el campo de Number Of Ports, se introdujo 32. Este campo es utilizado por el asistente de

110
instalación para determinar si se requiere de la instalación de MSDE o de SQL 2000 Sever
como sistema de gestión de base de datos. En nuestro caso, debido a las opciones
seleccionadas, se instaló SQL 2000.

Posteriormente, se instaló la herramienta Data Store utilizando el disco Cisco Unity

Data Store 2000 for use with the Cisco Unity Preparation Assistant.

Instalación de SQL 2000 Server

El proceso de instalación del sistema de gestión de base de datos SQL 2000 Server
es ejecutado a través de un asistente de instalación, que inicialmente muestra una ventana
de bienvenida.

En la ventana de Computer Name, se seleccionó la opción predeterminada Local

Computer. En la ventana de Setup Type, se seleccionó Typical, y posteriormente se
seleccionó la ruta de destino sobre la que se instalaría el software

En la ventana de Settings se seleccionaron las opciones Use the Same Account for
Each Service y Use the Local System Account, y finalmente en la ventana de
Authentication Mode, se escogió Windows Authentication Mode.

Para el correcto funcionamiento del sistema, es necesario tener instalada la última

versión o actualización, que en este caso es el Service Pack 3. Para esta instalación también
se ejecuta un asistente, donde es la ventana de Authentication Mode se seleccionó
Windows Authentication Mode, para luego elegir la opción Upgrade Microsoft Search
And Apply SQL 2003 SP3 [Required]

También fue necesario ejecutar el programa Cisco Unity 4.0.(4) Post-Install para
instalar las últimas actualizaciones del software de telefonía.

Una vez finalizados los procedimientos anteriores, es posible unir al servidor al

dominio de la empresa, para que efectivamente forme parte de la red.

111
 Para esto, se ingresó a la ruta Settings>Control Panel>System. Dentro de la
pestaña de Network Configuration se seleccionó Propiedades, y en la ventana de
Identification Changes, en el campo Domain, se introdujo el dominio al cual se deseaba
unir el servidor, que en nuestro caso es protokolgroup.com.

Como se mencionó anteriormente, este software tiene la capacidad de integrarse

con el sistema de correo electrónico para enviar notificaciones a los usuarios de los correos
de voz recibidos, bajo la modalidad denominada Partner Exchange Server del Cisco Unity
Server. Para configurar esta utilidad, se instalaron las Herramientas Administrativas de
Exchange Microsoft Exchange 2003 Server, teniendo cuidado en no seleccionar la opción
Instalar en Servicios de Colaboración y Mensajería de Exchange.

Extensión del Esquema de Active Directory para Cisco Unity

Para completar la configuración de las funcionalidades de integración entre

Microsoft Exchange y Cisco Unity, es importante que este último forme parte del esquema
de Active Directory contenido en Exchange.
Fue necesario entonces comprobar que los Controladores de Dominio presentes en
la red se encontraran en línea, para proceder a ejecutar en el servidor de Cisco Unity la
herramienta ADSchemaSetup.exe del directorio ADSchemaSetup contenido en el disco
de instalación del software de Cisco Unity.

En las opciones de configuración, se seleccionó instalar Exchange 2000 or

Exchange 2003 Directory Monitor. Luego, el asistente de instalación completa el
proceso. Al finalizar la instalación aparecen automáticamente en el escritorio los archivos
de registros Ldif.log y Ldif.err, en los cuales pudimos comprobar que el procedimiento se
llevó a cabo exitosamente.

Un requisito indispensable para el uso óptimo de Cisco Unity consiste en la

creación de 4 cuentas con derechos y permisos específicos para realizar sus funciones
predeterminadas. Estas cuentas son: UnityAdmin, UnityInstall, UnityDirSvc y
UnityMsgStoreSvc. La primera debe tener los permisos y derechos para administrar Cisco
Unity, y hacer los cambios pertinentes en la configuración siempre que sean necesarios.
UnityInstall es la cuenta que se utilizará posteriormente para realizar la instalación de

112
Cisco Unity. Las dos últimas son las cuentas que utilizará Cisco Unity para prestar los
servicios de directorio y los servicios de almacenamiento de mensajes.

La creación de estas cuentas se llevó a cabo accediendo al directorio

Start>Programs>Microsoft Exchange>Active Directory Users and
Computers>Operaciones>Telefonia.

Al seleccionar New>User se inicia un asistente donde se ingresarán las cuentas a

crear. Este procedimiento debe repetirse para cada cuenta.

Posteriormente, se añadió al usuario UnityAdmin al grupo de Administradores del

Equipo, a través de Start>Programs>Administrative Tools>Computer Management.

En el panel izquierdo de Computer Management MMC, expandiendo System

Tools>Local System and Groups>Groups>Administrators y luego ingresando en sus
Propiedades, se añade el usuario UnityAdmin.

A través de la herramienta Asistente de Permisos de Cisco Unity pueden

gestionarse los permisos y derechos de cada usuario del sistema. Ésta herramienta se
ejecuta a través del archivo PermissionsWizzard.exe, que se encuentra dentro del disco de
instalación de Cisco Unity en el directorio Utilities\Permissions Wizzard.

En la página de bienvenida del asistente, se seleccionó Microsoft Exchange 2003

como sistema a configurar para el manejo de los usuarios. En la página de Installation
Account, se seleccionó Change como opción para las cuentas, para luego buscar la cuenta
UnityInstall. De esta manera, la cuenta queda activa para ser utilizada en la instalación del
software de Cisco Unity. Se repitió el mismo procedimiento con las cuentas restantes.
Al finalizar el procedimiento, el asistente genera una pantalla donde se pudo
verificar la concesión exitosa de los permisos.

Para conceder permisos de Exchange para las cuentas de instalación y de Servicios

de Directorio, se ingresó a Programs>Microsoft Exchange>System Manager. Al
presionar con el botón derecho sobre el nombre de la organización, se seleccionó Delegate

113
Control para luego, en la ventana Users or Groups, seleccionar Add. Se agregaron los
usuarios creados anteriormente y se les concedió el permiso de Exchange Administrator.

Instalación y Configuración del software de Cisco Unity

Una vez completados los requisitos previos, se instaló el software de Cisco Unity,
ingresando al equipo con la cuenta de instalación de Cisco Unity UnityInstall.

El archivo de instalación se encuentra en el disco bajo el nombre de Setup.exe. Este

ejecutable inicia un asistente de instalación, donde debe seleccionarse la opción Install
Cisco Unity en la ventana Select Features. En la ventana de configuración se seleccionó
Spanish como lenguaje predeterminado de los teléfonos.

Para finalizar la instalación, se reinició el equipo en el momento que lo indicó el

asistente, para posteriormente instalar el archivo de licenciamiento a través de la opción
Run the Cisco Unity Install License File Wizzard en la ventana Cisco Unity Install.

Posteriormente, en la misma ventana, se seleccionó la opción Run the Cisco Unity

Services Configuration para configurar los servicios, donde se eligió Microsoft Exchange
2003 como tipo de Partner Server de Cisco Unity.

Para completar la integración de Cisco Unity con el servicio de correo electrónico,

se ingresó a la opción Run Unity Message Store Configuration Wizzard a través de la
página Configure Cisco Unity Message Store.

Se accedió utilizando la cuenta UnityInstall con su respectivo password, para luego

seleccionar la cuenta UnityAdmin como cuenta predeterminada de administración.
En la ventana Partner Message Store, se seleccionó la opción Microsoft Exchange
2003. El servidor de correo al que se asoció el sistema de Cisco Unity fue, en nuestro caso
particular, PTKMAIL2.

114
Integración de Cisco Unity con el Sistema Telefónico

Para llevar a cabo la integración del sistema Cisco Unity con el sistema de telefonía
de la empresa, fue necesario cambiar ciertos parámetros de configuración en el servidor de
Cisco Callmanager. Lo primero a verificar fue la instalación de todos los patches y
upgrades para Windows 2000 Server y para Cisco Callmanager.

Para comenzar con la integración, se debieron añadir las particiones y el Calling

Search Space o Espacio de Búsqueda para Llamadas que van a contener a los puertos de
correo de voz.

Este proceso se inició accediendo al servidor de Callmanager con la cuenta de

Administrador local de dicho equipo. En la página de CallManager Administration,
ubicada en el escritorio, se ingresó a la ruta Route Plan>Class of Control>Partition. En
el apartado Find and List Partitions, se seleccionó Add a New Partition, en cuya página
de configuración se debió indicar el nombre y la descripción de la partición que contendría
las extensiones de los puertos de correo de voz. En nuestro caso, el nombre de la partición
es VMPortDirectory. Posteriormente se añadió la partición que contendría a la extensión
correspondiente al número piloto del correo de voz, es decir, el número al cual los usuarios
llaman para ingresar a su respectivo buzón de voz. En nuestro caso, el nombre de la
partición es VMhuntPilot.

Para agregar el Espacio de Búsqueda para Llamadas se ingresó a la ruta Route

Plan>Class of Control>Calling Search Space, para luego seleccionar Add a New
Calling Search Space. Se introdujo un nombre para el Calling Search Space que incluye a
las dos particiones creadas anteriormente. En nuestro caso, el nombre es CCSVM. En el
campo Available Partitions, se seleccionaron los nombres de las dos particiones creadas
anteriormente para finalizar su adición haciendo clic en Insert.

Por último, se seleccionó Back to Find/List Calling Search Spaces. Haciendo clic
en Find, se agregó la partición VMhuntPilot en todas los Calling Search Spaces, con la
finalidad de que todos los usuarios sean capaces de conectarse con el servidor Unity a
través del número piloto. El proceso finalizó al hacer clic en Update.

115
 El siguiente paso fue añadir una Device Pool para los puertos de voz que se van a
crear. En la página de CallManager Administration, se ingresó a la ruta System>Device
Pool, donde se seleccionó Add a New Device Pool. En la página de configuración, se
introdujeron las siguientes modificaciones:

- Device Pool Name: Cisco Unity Voice Mail.

- Date/Time Group: TIME_PTK_CCS.
- Region: PTK_CCS.

Para añadir los puertos de correo de voz, se accedió a Feature>Voice Mail>Voice

Mail Port Wizzard. En la página What Would You Like To Do, seleccione Create a
New Cisco Voice Mail Server and Add Ports to It. En la siguiente página se seleccionó
el número de puertos a agregar, que en nuestro caso fueron 16.

En el campo Begining Directory Number se introdujo el valor 6002, ya que las

extensiones 6000 y 6001 se reservaron como Message Waiting Indicador o Indicador de
Mensaje en Espera (MWI). En el campo Partition se introdujo VMPortDirectory, y en
Display se introdujo Voicemail (este es el nombre que se mostrará en la pantalla del
teléfono cuando se esté marcando al correo de voz).

Una vez finalizado el asistente de instalación, se seleccionó Line Group en la

página Cisco Voice Mail Wizzard Results. Se seleccionó posteriormente Add a New
Line Group. En la lista Route Partition, se seleccionó VMPortDirectory y luego Find.
Se añadieron todas las extensiones correspondientes a los 16 puertos creados
recientemente, haciendo clic en Insert para finalizar.

Posteriormente se ingresó en Route Plan>Route/Hunt/Hunt List. Al seleccionar

Add a New Hunt List se introdujo Cisco Puertos de Voz Protokol como nombre,
haciendo clic en Insert. Luego se seleccionó Add Line Group, añadiendo el Line Group
que se creo recientemente.

Fue necesario también añadir el Hunt Pilot Number, ingresando a Route

Plan>Route/Hunt>Hunt Pilot. Al seleccionar Add a New Hunt Pilot, se introdujo 6019
como numero Hunt Pilot, VMhuntPilot en el campo de partición, y en el campo Hunt List

116
se seleccionó el nombre de la Hunt List creada anteriormente. Además, se desmarcó la
casilla Provide Outside Dial Tone.

Se agregaron también las dos extensiones para MWI, que indican que el usuario
tiene mensajes de voz sin escuchar. Para esto, se accedió a la ruta Feature>Voice
Mail>Message Waiting para después seleccionar Add a New Message Waiting Number.
En la pagina de configuración, se introdujo la extensión para la cual el MWI se enciende
en Message Waiting Number (6000), se indicó en la descripción que esa extensión se
encarga de encender el MWI, se colocó la marca de Message Waiting Indicator en On, se
seleccionó VMhuntPilot en Partition, y se seleccionó CCSVM en el campo Calling
Search Space. Para finalizar, se hizo clic en Insert. Este procedimiento se repitió para
crear la extensión para la cual se apaga el MWI, teniendo cuidado de seleccionar Off en el
campo Message Waiting Indicator, y colocando la extensión 6001.

Se agregó una extensión como Voice Mail Pilot Number, asignando así un número
al cual los usuarios llamarán para acceder a sus respectivos buzones. Para esto, se ingresó a
Feature>Voice Mail>Voice Mail Pilot, se seleccionó Add a New Voice Mail Pilot, y se
introdujo 6019 en el campo Voice Mail Pilot Number de la página de configuración,
CCSVM en el campo Calling Search Space, y se marcó la casilla Make This the Default
Voice Mail Pilot for the System.

Para configurar el perfil de correo de voz se ingresó a Feature>Voice Mail>Voice

Mail Profile, se seleccionó Add a New Voice Mail Profile, se introdujo un nombre para
el perfil, marcando la casilla Make This the Default Voice Mail Profile for the System
para convertirlo en predeterminado.

También fue necesario cambiar los parámetros del servidor de correo de voz. Se
accedió a Service>Parameters, seleccionando el nombre del servidor CallManager en la
pagina de configuración. En Service List, se seleccionó Cisco Unified CallManager, con
lo cual aparece la lista de parámetros. Se ubicó el parámetro Multiple Tenant MWI
Modes para colocarlo en True, y se finalizó haciendo clic en Update.

Para continuar con la integración en el servidor Cisco Unity, se ingresó a dicho

equipo a través de la cuenta UnityInstall, y se accedió a la página Integrate Phone System

117
with Cisco Unity, para seleccionar Run the Cisco Telephony Integration Manager. Se
selecciona Create Integration y posteriormente CallManager Integration, donde se
introdujo la dirección IP del servidor CallManager(192.168.0.242 en nuestro caso), y las
extensiones elegidas para el MWI, que en nuestro caso son 6000 y 6001 para encender y
apagar respectivamente.

Para finalizar con la integración, en el Cisco Unity Configuration and Installation

Assistant se seleccionó Do Not Set Up Cisco Personal Communications Assistant To
Use SSL. De esta manera, la integración quedó finalizada.

118
 Anexo 3. Instalación y configuración sistema de monitoreo de red

Instalación Sistema Operativo Fedora 7

Al comenzar la instalación del sistema operativo, se presenta una pantalla con tres
opciones: Fedora 7 KDE LiveCD, Install to Hard Drive and Trash, tal como lo muestra la
figura #. De estas tres opciones, se escoge Install to Hard Drive.

Figura A.11: Pantalla inicial de instalación

Aparece una interfaz gráfica o GUI (graphical user interface), como se muestra en
la figura 2, donde el siguiente paso es seleccionar el idioma de teclado apropiado para el
sistema, ilustrado en la figura 3.

119
 Figura A.21: Interfaz gráfica de instalación

Figura A.13: Selección del idioma del teclado

Ahora, una ventana de información indica que en el siguiente paso se borrará toda
la data del disco duro. Si la instalación se está llevando a cabo en un disco duro vacío, se
continúa seleccionando la opción "Remove Linux partitions on selected drives and create
default layout". En nuestro caso, la instalación se llevó a cabo en un equipo sobre el que ya
corría Windows, pero de igual manera se seleccionó la opción anterior. Estos pasos se
ilustran en las figuras 4 y 5.

120
 Figura A.14: Confirmación de borrado de data.

Figura A.15: Confirmación de eliminación de particiones de Linux

El paso siguiente, como se muestra en la figura 6, es configurar la red: si se están

utilizando direcciones IP estáticas, se introduce la información al hacer clic en el botón de
“Edit”. En caso de contar con un servidor de DHCP en la red, como lo es el nuestro, se

121
continúa. En cualquier caso, luego se deben introducir los datos del servidor de DNS y del
dominio.

Figura A.16: Asignación de dirección IP mediante DHCP

A continuación, se selecciona la ubicación (país/ciudad) y la zona horaria, y

posteriormente se pide introducir una contraseña para el administrador del sistema, que
hemos llamado “root” (figura 7).

Figura A.17: Asignación de contraseña para usuario “root”

122
 Para finalizar, se ejecuta una instalación personalizada, donde hay que asegurarse
de integrar todos los paquetes del sistema operativo, para evitar necesitar algo que no haya
sido instalado. En la figura 8 se muestra la pantalla que da inicio al proceso de instalación.

Figura A.18: Comenzar instalación

Para comenzar a trabajar con Fedora, se introducen el nombre de usuario y

contraseña definidos en la instalación para acceder a la interfaz del sistema operativo.

Instalación Nagios

Con acceso al sistema operativo como usuario “root”, se deben primero instalar los
paquetes del servidor web, el compilador C y la librería GD, ejecutando los siguientes
comandos:

yum install httpd

yum install gcc
yum install glibc glibc-common
yum install gd gd-devel

123
 Posteriormente, se debe crear una cuenta de usuario con su correspondiente
contraseña. El nuevo usuario será “nagios”, creado de la siguiente manera:

/usr/sbin/useradd nagios
passwd nagios

También se crea un nuevo grupo para permitir el uso de comandos externos a través
de la interfaz web. El nuevo grupo será “nagcmd”, creado de la siguiente manera:

/usr/sbin/groupadd nagcmd
/usr/sbin/usermod -G nagcmd nagios
/usr/sbin/usermod -G nagcmd apache

Se añade un nuevo directorio para albergar las descargas del programa y sus
plugins:

mkdir ~/downloads
cd ~/downloads

Para obtener los paquetes, se ejecutan los siguientes comandos:

wget http://osdn.dl.sourceforge.net/sourceforge/nagios/nagios-2.9.tar.gz
wget http://osdn.dl.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.9.tar.gz

También pueden descargarse directamente de la pagina web:

http://www.nagios.org/download, y colocarse en el directorio creado anteriormente.

Para descomprimir los paquetes, se accede al directorio donde se encuentran y se

ejecutan los siguientes comandos:

cd ~/downloads
tar xzf nagios-2.9.tar.gz
cd nagios-2.9

124
 Debe correrse el archivo de configuración de Nagios, pasando como parámetro el
nombre del grupo creado anteriormente, de la siguiente manera:

./configure --with-command-group=nagcmd

Para compilar el código fuente:

make all

Para instalar los archivos de inicio y configuración, y dar permisología al directorio

de comandos externos, se ejecutan:

make install
make install-init
make install-config
make install-commandmode

Para instalar los plugins, se debe extraer el código fuente de la misma manera en
que se llevó a cabo con el paquete de instalación:

cd ~/downloads
tar xzf nagios-plugins-1.4.9.tar.gz
cd nagios-plugins-1.4.9

Para compilar e instalar los plugins:

./configure --with-nagios-user=nagios --with-nagios-group=nagios

make
make install

Para instalar la interfaz web, se debe correr el archivo de configuración web de

Nagios, en el directorio conf.d de Apache:

make install-webconf

125
 Se crea una cuenta de administrador de Nagios, llamada en este caso
“nagiosadmin” para entrar a la interfaz web:

htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

Para que los nuevos ajustes entren en vigencia, es necesario reiniciar el servicio de
Apache:

service httpd restart

Para finalizar, se revisa la configuración de SELinux (Security Enhanced Linux), la

cual se encuentra en modo “enforcing” por defecto. Esto se comprueba al ejecutar el
comando:

getenforce

En caso de que devuelva “enforcing”, debe colocarse en modo “permissive”

ejecutando el comando:

setenforce 0

Con este procedimiento se evitan errores internos del servidor al momento de

acceder al CGI de Nagios. Para que este cambio sea permanente, debe modificarse la
configuración en /etc/selinux/config y reiniciar el servidor.

Configuración Nagios

A continuación se describen cada uno de los archivos que deben ser modificados
para que la herramienta entre en funcionamiento.

126
Main Configuration File

El archivo principal de configuración de Nagios, nagios.cfg, contiene directivas que

afectan la operación de la aplicación. Este archivo es leído tanto por Nagios como por el
Common Gateway Interface o CGI.

A continuación se describen las directivas más importantes a ser configuradas en

este archivo:

Object Configuration File:

Format: cfg_file=<file_name>
cfg_file=/usr/local/nagios/etc/hosts.cfg
Example: cfg_file=/usr/local/nagios/etc/services.cfg
cfg_file=/usr/local/nagios/etc/commands.cfg

Aquí se especifican los archivos de configuración que contienen las definiciones de

los objetos que Nagios debe utilizar para monitorear la red. Estos archivos contienen
definiciones de hosts, grupos de hosts, contactos, grupos de contactos, servicios,
comandos, etc.

Para que Nagios opere en función de las necesidades particulares de nuestra red,
deben existir los siguientes archivos de configuración:

cfg_file=/usr/local/nagios/etc/contactgroups.cfg
cfg_file=/usr/local/nagios/etc/contacts.cfg
cfg_file=/usr/local/nagios/etc/dependencies.cfg
cfg_file=/usr/local/nagios/etc/escalations.cfg
cfg_file=/usr/local/nagios/etc/hostgroups.cfg
cfg_file=/usr/local/nagios/etc/hosts.cfg
cfg_file=/usr/local/nagios/etc/services.cfg
cfg_file=/usr/local/nagios/etc/timeperiods.cfg
cfg_file=/usr/local/nagios/etc/servicegroups.cfg

127
cfg_file=/usr/local/nagios/etc/hostextinfo.cfg

Status File Update Interval:

Format: status_update_interval=<seconds>
Example: status_update_interval=15

Este parámetro determina con qué frecuencia (en segundos) Nagios actualizará su
status en el archivo de configuración correspondiente. El intervalo mínimo es 1 segundo,
pero en nuestro caso se colocó en 15 segundos.

Notifications Option:

Format: enable_notifications=<0/1>
Example: enable_notifications=1

Esta opción determina si el programa enviará o no notificaciones. Si esta opción

está desactivada, Nagios no enviará notificaciones para ningún host o servicio. En caso
contrario, lo hará según la configuración de notificaciones para cada objeto, especificada
en sus archivos particulares de configuración. Los valores de este parámetro se interpretan
de la siguiente manera:

0 = Deshabilitar notificaciones
1 = Habilitar notificaciones (predeterminado)

En nuestro caso, nos interesa mantener las notificaciones habilitadas.

Service Check Execution Option:

Format: execute_service_checks=<0/1>
Example: execute_service_checks=1

128
 Esta opción determina, cada vez que Nagios inicia o reinicia, si ejecutará o no
chequeos de servicio. Si está deshabilitada, Nagios no ejecutará activamente ningún
chequeo de servicios, y permanecerá en cierto modo “dormido”. Los valores de esta opción
se interpretan de la siguiente manera:

0 = No ejecutar chequeo de servicios

1 = Ejecutar chequeo de servicios (predeterminado)

En nuestro caso, dejaremos activada la opción predeterminada.

Log Rotation Method:

Format: log_rotation_method=<n/h/d/w/m>
Example: log_rotation_method=d

Este parámetro determina el método que utilizará Nagios para rotar los archivos de
registro. Los valores de esta opción se interpretan de la siguiente manera:

n = None (No rotar el archivo – opción predeterminada)

h = Hourly (rotar el archivo al inicio de cada hora)
d = Daily (rotar el archivo a medianoche cada día)
w = Weekly (rotar el archivo a medianoche cada Sábado)
m = Monthly (rotar el archivo a medianoche cada último día del mes)

En nuestro caso, se definió “n”, para evitar inconvenientes al momento de revisar la

configuración del archivo.

External Command Check Option:

Format: check_external_commands=<0/1>
Example: check_external_commands=1

129
 Esta opción determina si se chequeará el archivo de comandos externos para
determinar cuáles serán ejecutados. Esta opción debe estar habilitada si se tiene planeado
utilizar el CGI para ejecutar comandos desde la interfaz web, llamados comandos externos.
Los valores de esta opción se interpretan de la siguiente manera:

0 = No permitir chequeo de comandos externos

1 = Permitir chequeo de comandos externos (predeterminado)

En nuestro caso, este parámetro permanecerá configurado con valor 1.

Notification Logging Option:

Format: log_notifications=<0/1>
Example: log_notifications=1

Esta variable determina si los mensajes de notificación se registrarán o no. Esta

opción permite que los contactos permanezcan registrados a las notificaciones.

0 = No registrar notificaciones
1 = Registrar notificaciones

Para nuestra aplicación, se activa el registro de notificaciones, colocando la variable

en valor 1.

Service Check Retry Logging Option:

Format: log_service_retries=<0/1>
Example: log_service_retries=1

Esta variable determina si las recomprobaciones de chequeo de servicios se

registran o no. Estas recomprobaciones ocurren cuando un chequeo de servicio arroja
resultados negativos, pero Nagios se ha configurado para verificar el estado del servicio en

130
cuestión más de una vez antes de responder al error. Se considera que los servicios en esta
situación están en estado “suave”.

0 = No registrar recomprobaciones de chequeo de servicios

1 = Registrar recomprobaciones de chequeo de servicios

En nuestro caso, este valor permanecerá en 1.

Host Check Retry Logging Option:

Format: log_host_retries=<0/1>
Example: log_host_retries=1

Este parámetro funciona de manera similar al anterior, pero en vez de trabajar sobre
el chequeo de servicios, se ajusta sobre el chequeo del status de los hosts.

0 = No registrar recomprobaciones de chequeo de hosts

1 = Registrar recomprobaciones de chequeo de hosts

Este valor también permanecerá en 1 en nuestra configuración.

Resource File

El archivo resource.cfg puede ser utilizado para almacenar macros definidos por el
usuario. El interés principal de tener este archivo es utilizarlo para almacenar información
de configuración, como por ejemplo contraseñas, sin que estén disponibles para los
registros del CGI.

CGI Configuration File

El archivo de configuración cgi.cfg contiene cierto número de directivas que

afectan la operación de los CGI. También contiene referencias al archivo principal de

131
configuración, por medio de las cuales el CGI se relaciona directamente con la manera en
la que se ha configurado Nagios y con el almacenamiento de las definiciones de objetos.

El parámetro más importante a configurar dentro de este archivo es el de

autenticación de uso, el cual controla si el CGI utilizará las funcionalidades de
autenticación y autorización al momento de determinar el acceso de los usuarios a la
información y a los comandos. En nuestro caso, se requiere que esta funcionalidad esté
habilitada.

Format: use_authentication=<0/1>
Example: use_authentication=1

0 = No utilizar funcionalidad de autenticación

1 = Utilizar autenticación y autorización (predeterminado).

Esto genera que deban habilitarse los siguientes parámetros:

System/Process Information Access:

Format: authorized_for_system_information =<users>

Example: authorized_for_system_information=nagiosadmin,theboss,jdoe

Esta opción otorga permisología de acceso a la información de los procesos de

Nagios a los usuarios enumerados en la lista. Por defecto, nadie tiene acceso a esto a
menos que se haya escogido no utilizar autorizaciones.

Configuration Information Access:

Format: authorized_for_configuration_information =<users>

Example: authorized_for_configuration_information=nagiosadmin,theboss,jdoe

132
 Esta opción otorga permisología de acceso a la información de configuración de
Nagios (hosts, comandos, etc.) a los usuarios enumerados en la lista. Por defecto, los
usuarios sólo pueden ver la configuración de los hosts y servicios para los cuales son
contactos de notificaciones.

System/Process Command Access:

Format: authorized_for_system_commands =<users>

Example: authorized_for_system_commands=nagiosadmin

Esta opción otorga permisología para detener o reiniciar comandos de Nagios vía CGI a los
usuarios enumerados en la lista. Por defecto, nadie tiene acceso a esto a menos que se haya
escogido no utilizar autorizaciones.

Global Host/Service View Access:

Format: authorized_for_all_services=<users>
Example: authorized_for_all_services=nagiosadmin,guest

Format: authorized_for_all_hosts=<users>
Example: authorized_for_all_hosts=nagiosadmin,guest

Esta opción otorga permisología para ver la información de todos los hosts y
servicios que están siendo monitoreados a los usuarios enumerados en la lista. Por defecto,
los usuarios sólo pueden ver la información de los hosts y servicios para los cuales son
contactos de notificaciones.

Golbal Host/Service Command Access:

Format: authorized_for_all_service_commands=<users>
Example: authorized_for_all_service_commands=nagiosadmin

133
Format: authorized_for_all_host_commands=<users>
Example: authorized_for_all_host_commands=nagiosadmin

Esta opción otorga permisología para ejecutar comandos relacionados con hosts o
servicios a través del CGI a los usuarios enumerados en la lista. Por defecto, los usuarios
sólo pueden ejecutar comandos sobre los hosts y servicios para los cuales son contactos de
notificaciones.

Object Definition Files

Los archivos de definición de objetos se usan para configurar los elementos que
participan en el proceso de monitoreo de la red ejecutado por Nagios, entre los cuales se
encuentran hosts, grupos de hosts, contactos, grupos de contactos, comandos, etc. En otras
palabras, se define qué hacer y cómo hacerlo.

Como ya se describió, se pueden especificar varios archivos de definición de

objetos mediante la directiva cfg_file en el archivo principal de configuración.

A continuación se describen cada uno de los objetos a ser definidos dentro de la

configuración de Nagios:

Hosts: son el objeto principal en la lógica de monitoreo. Sus principales atributos se

describen a continuación:

- Usualmente son dispositivos físicos presentes en la red (servidores,

estaciones de trabajo, routers, switches, impresoras, entre otros).
- Presentan direcciones de algún tipo (direcciones IP o MAC).
- Tienen uno o más servicios asociados a ellos.
- Pueden tener relaciones de parentesco con otros hosts, frecuentemente
representando conexiones de red reales, usadas en la lógica de
alcanzabilidad de la red.

134
Grupos de hosts: son agrupaciones de uno o mas hosts, que se organizan según sus
características comunes para facilitar la visualización del status de cada uno de ellos en la
interfaz web de Nagios y simplificar la configuración de la aplicación.

Servicios: uno de los objetos centrales en la lógica de monitoreo. Están asociados con los
hosts, y pueden ser:

- Atributos de un host (carga de CPU, uso de disco, uptime, entre otros).

- Servicios proporcionados por el host (HTTP, POP3, FTP, SSH, entre otros).
- Otras actividades asociadas a los hosts (datos de DNS, etc.).

Grupos de servicios: son agrupaciones de uno o más servicios, organizados para facilitar
la visualización del status de servicios similares en la interfaz web de Nagios y simplificar
la configuración de la aplicación.

Contactos: personas involucradas en el proceso de notificación.

- Tienen uno o más métodos de notificación (teléfono móvil, buscapersonas,

email, mensajería instantánea, etc.).
- Reciben notificaciones de los hosts y servicios de los que son responsables.

Grupos de contactos: agrupaciones de uno o más contactos, para facilitar las definiciones
de todas las personas que reciben notificaciones cuando ciertos hosts o servicios presentan
problemas.

Períodos de tiempo: son utilizados para controlar:

- Cuándo son monitoreados los hosts y sus servicios.

- Cuándo son enviadas las notificaciones a los contactos

Comandos: son utilizados para indicar a la aplicación cuáles programas o instrucciones

debe ejecutar, como chequeo de hosts y servicios, envío de notificaciones, entre otros.

135
Configuración de archivos de definición de objetos:

Hosts.cfg

En este archivo se definen cada uno de los hosts a ser monitoreados, mediante un
nombre, un alias y su dirección IP. También se especifican comandos, intervalos de
monitoreo, contactos a los cuales serán enviadas las notificaciones inherentes a su
funcionamiento.

define host{
host_name <host name>
hostgroups <group name>
alias <host alias>
address <IP address>
check_command check-host-alive
max_check_attempts <number of attempts>
check_period 24x7
contact_groups <contact groups>
notification_interval <minutes>
notification_period 24x7
notification_options d,u,r,f
}

Hostgroups.cfg

En este archivo se agrupan los hosts según sus características comunes. En nuestro
caso, los servidores fueron agrupados según el sistema operativo bajo el cual funcionan, y
los demás equipos según su naturaleza, sean routers, switches, impresoras, etc.

define hostgroup{
hostgroup_name <host group name>
alias <host group alias>
members <host group members>
}

136
Hostextinfo.cfg

Este archivo contiene las definiciones de los íconos que muestra la interfaz gráfica
para cada uno de los equipos a monitorear. Su configuración es opcional, pero facilita el
uso de la herramienta permitiendo una rápida identificación visual.

define hostextinfo{
host_name <host name>
icon_image <image name>
icon_image_alt <host name>
vrml_image <image name>
statusmap_image <image name>
2d_coords 100,250
3d_coords 100.0,50.0,75.0
}

Importante: debe especificarse que el archivo que contiene la configuración extra es

hostextinfo.cfg, añadiendo al archivo cgi.cfg la siguiente línea:

xedtemplate_file_config=/usr/local/nagios/etc/hostextinfo.cfg

Los iconos a los cuales hace referencia este archivo deben estar localizados en el
directorio /usr/local/nagios/share/images/logos

Services.cfg

Este archivo contiene la definición de los servicios que van a ser monitoreados en
cada uno de los hosts. Es importante que se revisen las definiciones de los comandos en el
archivo commands.cfg, para configurar adecuadamente los servicios y sus parámetros.

define service{
hostgroup_name(*) <host group name>
service_description <service description>
check_command <command>

137
 max_check_attempts <number of attempts>
normal_check_interval <minutes>
retry_check_interval <minutes>
check_period 24x7
notification_interval <minutes>
notification_period 24x7
notification_options w,u,c,r,f
contact_groups <contact groups>
}
(*) O host_name según se necesite

Contacts.cfg

En este archivo se enumeran los administradores de red que recibirán las

notificaciones acerca del estado de los hosts y se determina el método de notificación, que
en nuestro caso se realiza únicamente vía correo electrónico.

define contact{
contact_name <contact name>
alias <contact alias>
host_notification_period 24x7
service_notification_period 24x7
host_notification_options d,u,r
service_notification_options w,u,c,r
host_notification_commands host-notify-by-email
service_notification_commands notify-by-email
email <email address>
}

Contactgroups.cfg

Dentro de este archivo se agrupan los contactos según los hosts de los cuales están
encargados.

138
define contactgroup{
contactgroup_name <contact group name>
alias <contact group alias>
members <contact group members>
}

Escalations.cfg

Luego de que se envían las notificaciones a los administradores de red, si el

problema no es solucionado en un periodo de tiempo determinado, las notificaciones se
escalan a un nivel superior de administración de red, lo cual se configura dentro de este
archivo.

define hostescalation(*){
hostgroup_name(**)
first_notification
last_notification
notification_interval
escalation_period
contact_groups
}
(*) O serviceescalation según se necesite
(**) O host_name según se necesite
<host group name>
<first notification to be escaled>
<last notification to be escaled>
<minutes>
24x7
<contact group name>

Activación de Acceso Web

Para configurar el acceso Web a la aplicación debemos modificar el archivo

httpd.conf ubicado en el directorio /etc/httpd/conf, añadiendo el siguiente texto:

ScriptAlias /nagios/cgi-bin /usr/local/nagios/sbin

<Directory "/usr/local/nagios/sbin">
Options ExecCGI
AllowOverride None
Order allow,deny

139
Allow from all
AuthName "Nagios Access"
AuthType Basic
AuthUserFile /usr/local/nagios/etc/htpasswd.users
Require valid-user
</Directory>
Alias /nagios /usr/local/nagios/share
<Directory "/usr/local/nagios/share">
Options None
AllowOverride None
Order allow,deny
Allow from all
AuthName "Nagios Access"
AuthType Basic
AuthUserFile /usr/local/nagios/etc/htpasswd.users
Require valid-user
</Directory>

Para aplicar este cambio se debe reiniciar el servicio web ejecutando:

Service httpd restart

Inicio de Nagios

Luego de editar los archivos de configuración necesarios para que la aplicación

corra bajo nuestros requerimientos específicos, debemos añadir Nagios a la lista de
servicios del sistema para que inicie automáticamente.

chkconfig --add nagios

chkconfig nagios on

Finalmente, se ejecuta el siguiente comando para verificar que los archivos estén
configurados correctamente y sean coherentes entre si:

140
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

La ejecución de dicho comando genera la siguiente salida en pantalla si la

configuración es correcta y coherente:

Nagios 2.9
Copyright (c) 1999-2007 Ethan Galstad (http://www.nagios.org)
Last Modified: 04-10-2007
License: GPL

Reading configuration data...

Running pre-flight check on configuration data...

Checking services...
Checked 56 services.
Checking hosts...
Checked 31 hosts.
Checking host groups...
Checked 8 host groups.
Checking service groups...
Checked 4 service groups.
Checking contacts...
Checked 9 contacts.
Checking contact groups...
Checked 10 contact groups.
Checking service escalations...
Checked 22 service escalations.
Checking service dependencies...
Checked 0 service dependencies.
Checking host escalations...
Checked 21 host escalations.
Checking host dependencies...

141
 Checked 0 host dependencies.
Checking commands...
Checked 22 commands.
Checking time periods...
Checked 4 time periods.
Checking extended host info definitions...
Checked 30 extended host info definitions.
Checking extended service info definitions...
Checked 0 extended service info definitions.
Checking for circular paths between hosts...
Checking for circular host and service dependencies...
Checking global event handlers...
Checking obsessive compulsive processor commands...
Checking misc settings...

Total Warnings: 0
Total Errors: 0

Things look okay - No serious problems were detected during the pre-flight check

Si no arroja errores, entonces se puede iniciar el servicio Nagios, mediante el

comando:

service nagios Start

Es importante resaltar que, en caso de realizarse modificaciones posteriores a los

archivos de configuración, éstas entraran en vigencia una vez que se reinicien los servicios
de Nagios y httpd, ejecutando los siguientes comandos:

service httpd restart

service nagios restart

Para acceder a la interfaz web de Nagios, se debe colocar en el browser la siguiente

dirección:

142
http://localhost/nagios/

En caso de querer acceder desde un equipo remoto, la dirección a insertar sería:

http://<dirección-ip-servidor-nagios>/nagios

Se pedirá ingresar el nombre de usuario y contraseña, que en nuestro caso

corresponden a “nagiosadmin” y a la contraseña suministrada durante la configuración.

Una vez iniciada la sesión, es posible observar con detalle el status de cada uno de
los equipos y servicios de la red, y luego de transcurrido cierto tiempo a partir de la
primera vez que se inició se observarán historiales de eventos, de cambios de estado de
equipos y servicios, de notificaciones, etc.

143
 Anexo 4. Instalación y configuración software de gestión de seguridad

Instalación de SQL 2000 Server

Al instertar el disco de instalación de SQL 2000 Server, se inicia un asistente. Al

llegar a la ventana de Computer Name, se seleccionó la opción predeterminada Local
Computer, y posteriormente se siguieron las instrucciones de la pantalla para introducir la
licencia, seleccionar en Setup Type la opción Typical y la ruta de destino de la
instalación. Luego se seleccionó la opción Use the Same Account for Each Service, y
Use the Local System Account. En la ventana de Authentication Mode se seleccionó
Windows Authentication Mode y en Licensing Mode se escogió Processor License For,
colocando 5 procesadores.

Para instalar la actualización del software de base de datos, también se inicia un

asistente sobre el cual se siguieron las instrucciones hasta llegar a la ventana de
Authentication Mode, donde se seleccionó Windows Authentication Mode.
Posteriormente se elige la la opción Upgrade Microsoft Search And Apply SQL 2003
SP3 [Required] y se siguieron las demás instrucciones hasta finalizar la instalación.

Instalación de ePO 3.6 Server

Para instalar el software de ePO 3.6 Server fue necesario acceder al servidor con la
cuenta de Administrador Local del equipo. Se verificó que el servicio MSSQL estuviese
corriendo y que el protocolo TCP/IP estuviese activado en el Server Network Utility de
SQL.

Al ejecutar el asistente de instalación que se inicia al insertar el disco de ePO, se

seleccionó Install ePolicy Orchestrator 3.6. En la ventana Installation Options se
escogió la opción Install Server and Console y el directorio de instalación mostrado por
defecto.

144
 Figura A.19: Opciones de Instalación

Posteriormente, en la ventana Set Administrator Password, se introdujo el

password de administrador que se utilizará para acceder al sistema de ePO.

 
Figura A.20: Establecimiento de Contraseñas de Administrador

En la ventana Select Database Server, se seleccionó como base de datos deseada

la instalada anteriormente, SQL.

145
 Figura A.21: Selección de Tipo de Servidor de Base de Datos

En la ventana Database Server Account, se eligió la opción This is a SQL

account, y se introdujo el nombre de usuario y contraseña.

Figura A.22: Selección del servidor de base de datos

146
 Se especificaron los números de los puertos que se utilizarían para la comunicación
hacia y desde el servidor ePO, como se muestra a continuación.

Figura A.23: Configuración de Puertos de Comunicación HTTP

En la ventana Set E-mail Address, se introdujo la cuenta de correo a la cual desea

que sean enviadas las notificaciones del servidor ePO.

En la ventana Ready To Install, se escogió Install para finalizar el proceso.

Para configurar el sistema, se accede a ePO Policy Orchestrator 3.6.1 Console,

donde se seleccionó Log On to Server y se iintrodujo el nombre de usuario
Administrador y la contraseña.

En la pantalla se muestra la opción de actualizar el repositorio del sistema. Esta

opción también aplica para la primera configuración, por lo que se hizo clic en Repository
para luego seleccionar Pull Now.

147
 Figura A.24: Pantalla Principal de Manejo de ePO

Para agregar nuevos equipos al ePO, se abrió el submenú de la carpeta Directory,

en el panel izquierdo de la ventana, y se seleccionó New>Group y luego New>Computer.
En la ventana emergente se buscaron los equipos a agregar, y se programó una tarea para
ejecutar este procedimiento.

Figura A.25: Pantalla de Distribución de Agentes ePO

148
 Anexo 5. Renombramiento de dominio

Creación de relaciones de confianza entre dos dominios:

Una relación de confianza es un vínculo lógico que se establece entre dominios

para permitir autenticación de usuarios entre ellos. En este esquema se observan dos
dominios: el que confía y en el cual se confía.

Figura A.26: Relaciones de confianza entre dominios

En el caso particular de nuestra empresa, se trabaja con dos dominios:

protokol.com, en el cual están creadas las cuentas de usuario con acceso a los equipos
(inicios de sesión en computadoras personales), y protokolgroup.com, en el cual se
encuentran las mismas cuentas de usuario con sus correspondientes buzones de correo
electrónico.

Se pretende entonces que estos dominios confíen el uno en el otro, para permitir
que los usuarios puedan acceder tanto a los equipos como a los servicios de correo a través
de la misma cuenta, y posteriormente renombrar el dominio protokol.com para que todos
los equipos relacionados con éste pasen a formar parte de protokolgroup.com y así
unificar la estructura de dominios de la empresa.

El único requisito para ejecutar los procedimientos de creación de relaciones de

confianza es que los controladores de dominio de ambos bosques trabajen con sistema
operativo Windows Server 2003. Además, es necesario que el usuario forme parte del

149
grupo de Administradores del dominio o del grupo de Administradores de organización en
Active Directory, o bien debe tener delegada la autoridad correspondiente.

Requisitos previos:

Eliminación de Controlador de Dominio de Respaldo: Fue necesario establecer un

único servidor como controlador de dominio para manejar la estructura deseada. Para el
momento del cambio, se contaba con dos controladores de dominio, uno de ellos PDC
(Primary Domain Controller o Controlador de Dominio Principal), y el otro BDC (Backup
Domain Controller o Controlador de Dominio de Respaldo).

Se eliminó el servidor BDC ejecutando el comando dcpromo /forceremoval, y

posteriormente se procedió a ejecutar la transferencia de funciones FSMO desde el
servidor BDC hacia el servidor PDC mediante la utilidad Ntdsutil.

Transferencia de funciones FSMO: Para llevar a cabo este procedimiento, se siguieron

los siguientes pasos:

- Se inició una sesión en el controlador de dominio al que se esté asignando las

funciones FSMO, como un usuario miembro del grupo de administradores de la
organización o del dominio.
- Se ejecutó el comando ntdsutil.
- Se ejecutó el comando roles.
- Nota:
Para ver una lista de comandos disponibles en cualquiera de los símbolos del
sistema de la utilidad Ntdsutil, se escribe ? y, a continuación, se presiona
ENTRAR.
- Se ejecutó el comando connections.
- Se ingresó connect to server nombre del servidor, donde nombre del servidor es el
nombre del controlador de dominio al que se desea asignar la función FSMO.
- Se escribió q en el símbolo del sistema server connections para salir de ese menú
de conexiones.

150
 - Se ejecutó transfer función, donde función es la función que se desea transferir.
Para ver la lista de funciones que se pueden transferir, se escribe ? en el símbolo
del sistema fsmo maintenance.
- Se repitió el procedimiento para transferir el resto de las funciones FSMO.
Para asumir las funciones FSMO usando la utilidad Ntdsutil, se llevó a cabo el
siguiente procedimiento:

- Se ejecutó el comando ntdsutil.

- Se ejecutó el comando roles.
- Se ejecutó el comando connections.
- Se escribió connect to server nombre del servidor, donde nombre del servidor es
el nombre del controlador de dominio al que se desea asignar la función FSMO.
- Se escribió q en el símbolo del sistema server connections para salir de ese menú
de conexiones.
- Se escribió seize función, donde función es la función que se desea asumir.
- Se repitió el procedimiento para asumir todas las funciones FSMO.

Elevar el nivel funcional del dominio y bosque: Los niveles funcionales de un dominio
permiten activar funciones de Active Directory a través de todo el dominio, dentro del
ambiente de red.

Los niveles funcionales de dominio disponibles de describen a continuación:

- Windows 2000 mixed: permite a un controlador de dominio en Windows Server

2003 interactuar con controladores de dominio que corran Microsoft Windows NT
4, Windows 2000 o Windows Server 2003.
- Windows 2000 native: permite a un controlador de dominio en Windows Server
2003 interactuar con controladores de dominio que corran Windows 2000 o
Windows Server 2003.
- Windows Server 2003: permite a un controlador de dominio en Windows Server
2003 interactuar con controladores de dominio que corran Microsoft Windows NT
4 o Windows Server 2003.

151
 - Windows Server 2003: permite a un controlador de dominio en Windows Server
2003 interactuar únicamente con controladores de dominio que corran Windows
Server 2003.

Una vez con acceso adecuado al servidor, se procedió a abrir Dominios y

confianzas de Active Directory, haciendo clic en Inicio, en Panel de control, y doble clic
en Herramientas administrativas.

En el árbol de la consola Dominios y confianzas de Active Directory, se ingresó a

Elevar el nivel funcional del bosque. El nivel funcional del bosque se muestra en Nivel
funcional del bosque actual.

En Seleccione un nivel funcional del bosque disponible, se desplega la lista de las

opciones de niveles funcionales disponibles para ser aplicados. Se seleccionó la opción de
Windows Server 2003.

Finalmente, se verificaron los valores de los siguientes atributos del ADSIEdit:

- Para la configuración del nivel del bosque: msDS-Behavior-Version en el objeto

CN=Particiones, CN=Configuración, DC=DomRaízBosque, DC=tld:

Valor 0 o no está establecido = bosque de nivel mixto

Valor 1 = nivel del bosque de Windows Server 2003 provisional
Valor 2 = nivel del bosque de Windows Server 2003

- Para la configuración del nivel funcional del dominio: msDS-Behavior-Version en

la raíz del encabezado NC de cada objeto DC=Midominio, DC=DomRaízBosque,
DC=tld del dominio:

Valor 0 o no está establecido = dominio de nivel mixto

Valor de 1 = nivel del dominio de Windows Server 2003
Valor de 2 = nivel del dominio de Windows Server 2003

152
 Es importante tomar en consideración que, para elevar el nivel funcional del bosque
a Windows Server 2003, el requisito mínimo de funcionalidad del dominio es Windows
2000 nativo. Por otra parte, una vez que el nivel funcional del dominio se eleva no hay
manera de degradarlo, es decir, no puede cambiarse nuevamente al nivel funcional
anterior.

Creación de relaciones de confianza: El sistema operativo Windows Server 2003 soporta

los siguientes tipos de relaciones de confianza:

- Tree-root trust (confianza de árbol raíz): se establece implícitamente cuando se

añade un nuevo dominio de “árbol raíz” a un bosque. Esta confianza es transitiva y
bidireccional.
- Parent-child trust (confianza padre-hijos): se establece implícitamente cuando se
añade un nuevo dominio “hijo” a un árbol.
- Shortcut trust (confianza de acceso directo): se crea explícitamente entre dos
dominios en un bosque para optimizar el inicio de sesión de los usuarios en cuanto
a tiempos de acceso.
- Realm trust (confianza de territorio): se crea para interactuar con otros dominios
bajo ambientes no Windows que utilicen el protocolo Kerberos V5 para la
autenticación de usuarios.
- External trust (confianza externa): se crea explícitamente entre dominios bajo el
sistema operativo Windows Server 2003 pertenecientes a diferentes bosques, o
entre dominios bajo Windows Server 2003 y otros cuyo controlador de dominio
opera bajo ambiente Windows NT o anterior.
- Forest trust (confianza de bosque): se crea explícitamente entre dos “bosques”. Si
una confianza de bosque es bidireccional, permite efectivamente las solicitudes de
autenticación desde un bosque hacia el otro.

En nuestro caso, establecimos entre protokol.com y protokolgroup.com una

confianza de bosque de la siguiente manera:

153
 Para crear una relación de confianza de bosque, se ingresó a Dominios y
confianzas de Active Directory a través de Inicio, Panel de control, Herramientas
administrativas.

Al entrar en Propiedades del nodo de dominio raíz del bosque en el cual se está
trabajando, se editaron los parámetros de la ficha Confía haciendo clic en Nueva
Confianza… y siguiendo las instrucciones del asistente. Éste va solicitando insertar el
nombre del dominio en el que se quiere confiar, el tipo de confianza y la dirección de la
confianza.

El nombre de confianza del otro bosque puede introducirse como nombre DNS o
NetBIOS. En Tipo de confianza se eligió Confianza de bosque. En dirección de
confianza se escogió Bidireccional, lo que permite que los usuarios de ambos bosques
tengan acceso a los recursos del otro. También fue necesario seleccionar Autenticación en
todo el bosque, para asegurarnos de que todos los equipos pertenecientes al dominio
ejecuten la confianza.

Finalmente, una vez creada la confianza, se accedió a las Propiedades de las

Confianzas de salida, y se seleccionó Validar. Se realizó este mismo procedimiento para
las Confianzas de entrada, quedando así la confianza totalmente creada y funcional.

Desactivar las cuentas de usuario / Proceso de aprovisionamiento: Una vez que los
dominios confían uno en el otro, fue necesario desactivar las cuentas de usuario en el
dominio de Exchange (protokolgroup.com) y asociar los buzones a la cuenta de usuario
externa (en el dominio protokol.com). Esto causará que el acceso a los buzones de correo
sea a través de la cuenta nombre_apellido@protokol.com (o simplemente
nombre_apellido), con las claves correspondientes. Así, los dominios presentarán la
siguiente estructura:

154
 Figura A.27: Relación de confianza entre bosques

Preparar las zonas DNS: Debe configurarse el dominio a ser renombrado para permitir el
uso de sufijos DNS principales que no coincidan con el nombre de dominio, cambiando el
valor del atributo msDS-AllowedDNSSuffixes en las propiedades del contenedor del
dominio a través de la herramienta ADSIEdit. Se debe editar dicho atributo añadiendo el
sufijo DNS en el cuadro de dialogo Multi-valued string editor.

Habilitar las políticas de grupo para el dominio a ser renombrado: en las Propiedades
de la unidad organizacional que contiene a los usuarios en Usuarios y Equipos de Active
Directory. En la ficha de Directivas de grupo, se selecciona el objeto donde se desea
crear la nueva directiva para editarla, entrando por la ruta Configuración del equipo,
Plantillas administrativas, Red, Cliente DNS. Habilitar el elemento Sufijo DNS
principal y añadir el nuevo nombre de sufijo DNS con el cual se va a renombrar el
dominio.

Procedimiento para renombramiento de dominio

• Respaldar los controladores de dominio.

• Establecer una unidad de control: en un equipo perteneciendo al dominio (que

NO sea el controlador de dominio), que corra Windows Server 2003, con
permisología de administrador del grupo.

155
 - Crear un directorio X:\DomainRename
- Insertar el CD de Windows Server 2003 y ejecutar
copy M:\valueadd\msft\mgmt\domren\*.* X:\domren
Verificar que rendom.exe y gpfixup.exe se hayan copiado
- Instalar las Herramientas de Soporte desde la carpeta Support\Tools del
CD. Verificar que repadmin.exe y dfsutil.exe estén instalados.

• Generar la descripción actual del bosque: crea un archivo con una descripción
textual de la estructura del bosque, lista de particiones de directorios y de
particiones de aplicaciones.
- En la estación de control, abrir un Command Prompt y entrar al directorio
X:\DomainRename
- Ejecutar rendom /list
- Guardar una copia de la descripción del bosque actual ejecutando el
siguiente comando
copy domainlist.xml domainlist-save.xml

• Especificar la descripción del nuevo bosque: se sobrescribirá el archivo

domainlist.xml generado anteriormente.
- Abrir el archivo domainlist.xml con cualquier editor de texto (notepad).
- Sustituir los nombres DNS o NetBios del dominio actual por los del nuevo
dominio.
- Para chequear la nueva descripción, ejecutar
rendom /showforest

• Generar las instrucciones de renombramiento de dominio: se traduce la

descripción anterior en una secuencia de actualización de directorios a ser ejecutada
individual y remotamente en cada controlador de dominio.
- En la estación de control, abrir un Command Prompt.
- Desde el directorio X:\DomainRename, ejecutar
rendom /upload
- Verificar que la herramienta de renombramiento de dominio genere el
archivo de estado dclist.xml en el directorio X:\DomainRename. El archivo
debe contener una entrada para cada controlador de dominio en el bosque.

156
• Forzar las instrucciones de renombramiento de dominio a los controladores de
dominio y verificar la preparación del DNS:
- En la estación de control, abrir un Command Prompt, y ejecutar
Dsquery Server –hasfsmo name
Para forzar a replicar los cambios realizados en los pasos anteriores a los
controladores de dominio.
- Ejecutar
repadmin /syncall /d /e /P /q DomainNamingMaster
Donde DomainNamingMaster es el nombre DNS del controlador de
dominio que actúa como Naming Master para el dominio.

• Verificar la preparación de los controladores de dominio:

- En la estación de control, abrir un Command Prompt.
- Desde el directorio X:\DomainRename, ejecutar
rendom /prepare
- Luego de que se ejecute, revisar el archivo dclist.xml para determinar si los
controladores de dominio han alcanzado el estado “preparados”. En caso de
no ser así, repetir la ejecución del comando anterior.

• Ejecutar las instrucciones de renombramiento de dominio:

- En la estación de control, abrir un Command Prompt.
- Ejecutar
rendom /execute
- Luego de que se ejecute, revisar el archivo dclist.xml para determinar si los
controladores de dominio han alcanzado el estado “listo” o, por el contrario,
“error”. En caso de no ser así, repetir la ejecución del comando anterior.
- Los controladores de dominio en los que se ejecute con éxito se reiniciarán
automáticamente. En caso de que reporten un estado de “error”, se puede
editar el archivo dclist.xml para activar el campo de “reintentar, y ejecutar el
comando de nuevo.

• “Descongelar” la configuración del bosque:

157
 - Reiniciar la estación de control dos veces para asegurar que todos los
servicios carguen el nuevo nombre de dominio.
- En la estación de control, abrir un Command Prompt.
- Desde el directorio X:\DomainRename, ejecutar
rendom /end

• Re establecer las confianzas externas:

- Deben borrarse y re-crearse todas las relaciones de confianza externas.

• Arreglar los objetos de directivas de grupo y sus links: cualquier link de

directivas de grupo entre dominios debe ser roto y reconfigurado manualmente. Los
miembros del dominio que alberguen Software Distribution Points deben ser
reiniciados dos veces.
- En la estación de control, abrir un Command Prompt, y ejecutar
Gpfixup /olddns:OldDomainDNSName
/newdns:NewDomainDNSName
/oldnb:OldDomainNetBIOSName
/newnb:NewDomainNetBIOSName
/dc:DcDnsName 2>&1 >gpfixup.log

Donde:

OldDomainDNSName es el antiguo nombre DNS del dominio renombrado.

NewDomainDNSName es el nuevo nombre DNS del dominio.

OldDomainNetBIOSName es el antiguo nombre NetBIOS del dominio

renombrado.

NewDomainNetBIOSName es el nuevo nombre NetBIOS del dominio.

DcDnsName es el nombre DNS de un controlador de dominio,

preferiblemente el emulador PDC, que haya completado exitosamente la
operación de renombramiento.

158
 - Para forzar la replicación de estos cambios, ejecutar
repadmin /syncall /d /e /P /q DcDnsName NewDomainDN

El comando gpfixup solo debe correrse una vez para cada dominio renombrado.

Acciones a tomar después del renombramiento de dominio

• Respaldar los controladores de dominio: para garantizar un respaldo del servidor

que contenga la nueva configuración del dominio en cuanto a Active Directory,
registros del sistema y políticas de grupo.

• Reiniciar equipos miembros del dominio: para que reconozcan los cambios y los
nuevos nombres del dominio se propaguen a sus aplicaciones y servicios.
o Reiniciar las computadoras miembros del dominio dos veces (excluyendo
los controladores de dominio).
Si están conectadas a la LAN a través de un cable, reiniciar dos
veces.
Si están conectadas de manera inalámbrica, la tarjeta de red
inalámbrica debe ser extraída y reinsertada luego de hacer “logon”,
antes de cada reinicio.
o Si hay miembros que se conectan al dominio renombrado mediante
conexiones remotas como dial-up o VPNs, deben separarse del viejo
dominio y luego unirse al nuevo.

• Clean-up:
o Abrir un command prompt en la estación de control
o Desde el directorio X:\DomainRename, ejecutar
rendom /clean

• Renombrar controladores de dominio: deben estar instaladas las herramientas de

soporte de Windows Server 2003, que se encuentran en la carpeta \Support\Tools
en el CD de instalación.
o Abrir un command prompt en el controlador de dominio

159
 o Ejecutar:
netdomcomputernameCurrentComputerName/add:NewComputerName
o Asegurar que las actualizaciones y los registros de DNS se han completado,
chequeando los atributos en ADSIEdit, en particular el msDS-
AdditionalDnsHostName. El nuevo nombre debe aparecer en las
propiedades del atributo.
o Ejecutar:
netdomcomputernameCurrentComputerName/makeprimary:NewComputer
Name.
De nuevo, chequear el ADSIEdit. En este caso, hay que verificar las
propiedades del atributo msDS-AdditionalDnsHostName, donde debe
aparecer el nombre anterior del equipo.
o Reiniciar el equipo
o Desde el command prompt, ejecutar:
netdomcomputernameNewComputerName/remove:OldComputerName

Al finalizar todos los procedimientos mencionados en el diagrama anterior, el

dominio protokol.com deja de existir, convirtiéndose todos sus miembros parte del
dominio protokolgroup.com.

Anexo 6. Estadísticas Nagios

Disponibilidad de equipos Protokol

160
161
162
163
164
165
166
167
168
169
170
171