reingenieria de red de area local de la empresa protokol grupo de
Anuncio
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 MSExchange. - 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 ASN.1, MIME, SSL/TLS, XDR Nivel de presentación NetBIOS, ONC RPC, DCE/RPC Nivel de sesión Nivel de transporte SCTP, SPX, TCP, UD AppleTalk, IP, IPX, NetBEUI, X.25 Nivel de red ATM, Ethernet, Frame Relay, HDLC, PPP, Token Ring, Wi-Fi, Nivel de enlace STP Cable coaxial, Cable de fibra óptica, Cable de par trenzado, Nivel físico 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) DNS, HTTP, SMTP, FTP, TELNET Nivel de aplicación UDP, TCP Nivel de transporte IP Nivel de red Nivel de acceso a red Ethernet, Token Ring Cable coaxial, Cable de par trenzado Nivel físico 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 "Storeand-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 com net org edu gov Significado Organizaciones comerciales Redes Otras organizaciones Instituciones educativas Organizaciones gubernamentales Tabla 2.3: Dominios según su estructura organizativa Geográficamente: Nombre de dominio es tw fr ve Significado España Taiwán Francia 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 [email protected], 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 Nombres de Dominio 1 por bosque Controla adiciones o remociones de dominios al bosque. Emulador PDC Proporciona compatibilidad a clientes NT4 para operaciones de PDC (como cambios de contraseña). El PDC también 1 por dominio corre procesos específicos de dominio como Security Descriptor Propagator (SDPROP), y representa el servidor principal de tiempo dentro del dominio. Maestro RID 1 por dominio Maestro de Infraestructura Sincroniza cambios en membresías de grupos en dominios cruzados. El maestro de infraestructura no puede correr en 1 por dominio un servidor de catálogo global, a menos que todos los controladores de dominio sean también catálogos globales. Asigna conjuntos de identificadores únicos a controladores de dominio para su uso al crear objetos. los 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 Exchange + Website EXCHWEB ML 350 10.10.10.2 DIRECCION MAC File Server PTKFILE ML 350 192.168.0.201 000E7FFF0290 Lan Services - Print Spooler PTKPDC 000802F0FE9D APLICACIONES Servidor de correo Servidor web ML 350 192.168.0.202 HP LP 1000r 192.168.0.203 PTKFLEX ML 150 192.168.0.206 Operaciones PTKOPERACIONES ML 350 CallManager Callmanager MCS Carry IN Flexline Sun AAA FTP 001321B40623 Flexline 192.168.0.208 0003BA02A857 Pruebas AAA 192.168.0.205 000BCDCB6BB7 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 HP-UX Physical Access ALIAS HP-UX ACCESS MODELO DIRECCION IP 192.168.0.207 192.168.0.209 DIRECCION MAC 0008C709718E APLICACIONES HP-UX 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 Data System Backup Unit Core Switch Switch Catalyst 2 Switch Catalyst 3 Switch Catalyst 4 Access Point PB Access Point 1 Router 2800 Firewall ABA CANTV MODELO Data Protector 1/8 Tape Autoloader Cisco # Cisco WS-C2950G-24-EI Cisco WS-C2950T-24 Cisco WS-C2950G-48-EI Cisco 2801 Fortinet 300A ABA DIRECCION IP DIRECCION MAC 192.168.0.235 192.168.0.236 192.168.0.237 192.168.0.238 192.168.0.243 192.168.0.244 192.168.0.250 192.168.0.251 200.44.32.12 00169D05EA80 0014A844CD80 0016C88FE580 0016C7B51C00 000BBE2DE825 00121760AE47 00146960F389 00090F03B7BE 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 Aplicaciones Voz Video Aplicaciones Email Web Total (Kbytes) Puerto Ordaz Aplicaciones Kbytes Voz 1320 Video 768 Aplicaciones 150 Email 270 Web 1800 Total (Kbytes) 4308 Kbytes 22000 12800 2500 4500 30000 71800 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 email 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 Windows Server 2003 Exchange Server 2003 Configurar discos (RAID5) Ejecucuón asistente de instalación del sistema operativo Configuración y formato de particiones ¿Existen particiones? Eliminar particiones existentes Si No OWA 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 regional e idioma Exchange Server 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: Requirement Standard Edition Enterprise Edition Datacenter Edition 133 MHz for x86- 400 MHz for x86based computers based computers 733 MHz for 733 MHz for Itanium-based Itanium-based computers* computers* Web Edition Minimum CPU Speed 133 MHz Recommended CPU Speed 550 MHz 733 MHz 733 MHz 550 MHz Minimum RAM 128 MB 128 MB 512 MB 128 MB Recommended Minimum RAM 256 MB 256 MB 1 GB 256 MB Maximum RAM 4 GB 32 GB for x86based computers 512 GB for Itanium-based computers* 64 GB for x86based computers 512 GB for Itanium-based computers* 2 GB Multiprocessor Support ** Up to 4 Up to 8 Minimum 8 required Maximum 64 Up to 2 1.5 GB 1.5 GB for x86based computers 2.0 GB for Itanium-based computers* 1.5 GB for x86based computers 2.0 GB for Itanium-based computers* 1.5 GB Disk Space for Setup 133 MHz Tabla 3.5: Requisitos del sistema para las versiones de Windows Server 2003 72 Component Requirement Computer and processor 133-MHz or faster processor for x86-based PCs; 733-MHz for Itanium-based PCs; up to eight processors supported on either the 32-bit or the 64-bit version Memory 128 MB of RAM minimum required; maximum: 32 GB for x86based PCs with the 32-bit version and 64 GB for Itanium-based PCs with the 64-bit version Hard disk 1.5 GB of available hard-disk space for x86-based PCs; 2 GB for 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 Other Windows Server 2003 Enterprise Edition, 64-bit version is 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 configuración de SELinux getenforce 1 Setenforce 0 Service httpd restart 0 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 E-Mail PTKMAIL ML 350 10.10.10.2 WebSite WEBSITE ML 350 10.10.10.4 Servidor web Unity UNITY MCS 10.10.10.5 Cisco IP Unity Call Manager CALLMANAGER MCS Sun AAA AAA File Server PTKFILE ML 350 192.168.0.203 000E7FFF0290 Operaciones PTKOPERACIONES ML 350 192.168.0.205 000BCDCB6BB7 Nagios NAGIOS ML 150 192.168.0.210 Finanzas PTKFLEX ML 150 192.168.0.206 Antivirus / Antispam ePO ML 150 192.168.0.200 McAfee ePO Lan Services PTKPDC ML 350 192.168.0.202 Servicios de impresión 192.168.0.242 DIRECCION MAC APLICACIONES Servidor de correo 000D60ECD692 Cisco IP CallManager 192.168.0.208 Pruebas AAA Archivos Nagios 001321B40623 Flexline 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 HP-UX Physical Access ALIAS HP-UX ACCESS MODELO DIRECCION IP 192.168.0.207 192.168.0.209 DIRECCION MAC 0008C709718E APLICACIONES HP-UX 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 Data System Backup Unit Core Switch Switch Catalyst 2 Switch Catalyst 3 Switch Catalyst 4 Access Point PB Access Point 1 Router 2800 Firewall Frame Relay ABA CANTV MODELO Data Protector 1/8 Tape Autoloader Cisco WS-C2950G-24-EI Cisco WS-C2950T-24 Cisco WS-C2950G-48-EI Cisco WS-C2950G-48-EI Cisco 2801 Fortinet 300A ABA DIRECCION IP DIRECCION MAC 192.168.0.235 192.168.0.236 192.168.0.237 192.168.0.238 192.168.0.243 192.168.0.244 192.168.0.250 192.168.0.251 200. 200.44.32.12 00169D05EA80 0014A844CD80 0016C88FE580 0016C7B51C00 000BBE2DE825 00121760AE47 00146960F389 00090F03B7BE 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 Servidores 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 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 / servidores Dispositivos de red Impresoras 192.168.1.29 Core Switch 192.168.1.30 Switch Catalyst 2 192.168.1.31 Switch Catalyst 3 192.168.1.32 Switch Catalyst 4 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 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 Access Point 1 Access Point PB CANTV - Puerto Serial CANTV DNS Core Switch Desarrollo 2 Exchange Firewall Call Manager Unity PTK DMZ PTKFILE PERIODO Nov Dic Ene Nov Dic Ene Nov Dic Ene Nov Dic Ene Nov Dic Ene Nov Dic Ene Nov Dic Ene Nov Dic Ene Nov Dic Ene Nov Dic Ene Nov Dic Ene Nov 88 UP 98,354% 99,978% 99,845% 98,427% 100,000% 99,979% 98,403% 100,000% 99,899% 96,759% 96,995% 97,346% 98,468% 100,000% 100,000% 98,434% 100,000% 99,875% 98,348% 99,975% 99,929% 98,381% 100,000% 100,000% 98,440% 99,995% 99,990% 98,392% 100,000% 99,990% 98,488% 100,000% 100,000% 98,382% DOWN 1,646% 0,022% 0,155% 1,573% 0,000% 0,021% 1,597% 0,000% 0,101% 3,241% 3,005% 2,654% 1,532% 0,000% 0,000% 1,566% 0,000% 0,125% 1,652% 0,025% 0,071% 1,619% 0,000% 0,000% 1,560% 0,005% 0,010% 1,608% 0,000% 0,010% 1,512% 0,000% 0,000% 1,618% PTKFLEX PTKPDC PTKSERVICES ROUTER 2900 SUN SERVER SWITCH CATALYST 2 SWITCH CATALYST 3 SWITCH CATALYST 4 WEB SERVER ePO Dic Ene Nov Dic Ene Nov Dic Ene Nov Dic Ene Nov Dic Ene Nov Dic Ene Nov Dic Ene Nov Dic Ene Nov Dic Ene Nov Dic Ene Nov Dic Ene 100,000% 99,964% 98,397% 73,919% 91,769% 98,445% 100,000% 99,964% 98,376% 100,000% 99,979% 98,409% 100,000% 99,913% 93,476% 99,979% 100,000% 98,415% 100,000% 99,984% 98,433% 100,000% 99,990% 98,439% 99,979% 99,838% 98,481% 100,000% 99,972% 98,458% 100,000% 99,975% 0,000% 0,036% 1,603% 26,081% 8,231% 1,555% 0,000% 0,036% 1,624% 0,000% 0,021% 1,591% 0,000% 0,087% 6,524% 0,021% 0,000% 1,585% 0,000% 0,016% 1,567% 0,000% 0,010% 1,561% 0,021% 0,162% 1,519% 0,000% 0,028% 1,542% 0,000% 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/installguide/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-9d81106ae3a715491033.mspx?mfr=true Microsoft TechNet, “Rename a Domain Controller”, http://technet2.microsoft.com/windowsserver/en/library/aad1169a-f0d2-47d5-b0ea989081ce62be1033.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/quickstartfedora.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(**) <host group name> first_notification <first notification to be escaled> last_notification <last notification to be escaled> notification_interval <minutes> escalation_period 24x7 contact_groups <contact group name> } (*) O serviceescalation según se necesite (**) O host_name según se necesite 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 [email protected] (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 msDSAdditionalDnsHostName. 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
