Usos del comando netsh: como modificar la configuracin TCP/IP de una PC de IP esttico a DHCP (y viceversa)

POSTED BY EDDIE ON OCTOBER - 9 - 2009

Es bastante comn en las redes empresariales el tener que cambiar la configuracin TCP/IP de una computadora o servidor, ya sea de IP esttico (en la que la direccin de IP de la mquina es siempre la misma) a DHCP (en la que la direccin de IP es variable, asignada por un servidor DHCP al encender la mquina), o todo lo contrario. Normalmente para hacer esto tiene que ir un tcnico hasta el rea donde se encuentre la PC y hacer el cambio manualmente (buscando las conexiones de red, entrando a sus propiedades, entrando a las propiedades de TCP/IP, haciendo todos los cambios necesarios, aceptando los cambios, y cerrando todas las ventanas que abriste). Tambin se puede conectar remotamente utilizando RDP, VNC, DWMRC, o cualquier otro mtodo de conexin remota, pero adems de ser un mtodo algo tedioso, durante el proceso necesitas renovar la comunicacin IP y perders conexin temporeramente (lo cual puede ser un contratiempo incomodo). Es entonces cuando llegan a nuestra ayuda unos de los mejores amigos de todo administrador de redes: el scripting y la lnea de comando (o comandos de consola de texto). Estos son tus verdaderos amigos, siempre los echamos a un lado para estar con nuestros nuevos amigos GUI y Conexin Remota, sin embargo cuando los necesitamos siempre estn ah para ayudarnos deberamos darle un poco mas de cario a estos viejos amigos. Bueno, volviendo al tema, esta modificacin se puede hacer fcilmente escribiendo el siguiente comando netsh en el Command Prompt:

netsh interface ip set address Local Area Connection dhcp

Este comando cambiara la configuracin TCP/IP de direccin IP esttica a direccin asignada por DHCP. Esto es asumiendo que tu conexin de red tiene como nombre Local Area Connection (que es el que se utiliza por default), si el nombre es otro debes modificar el comando segn sea necesario. Si no sabes el nombre, lo puedes averiguar con el siguiente comando:

netsh interface ip show config

Si fuera todo lo contrario (o sea, que hay que cambiar la configuracin TCP/IP de DHCP a esttica), el comando sera el siguiente:

netsh interface ip set address Local Area Connection static {ip} {subnet}{gateway} {metric}

Por ejemplo, si quieres cambiar la configuracin TCP/IP de DHCP a una direccin IP esttica utilizando la direccin de IP 192.168.0.10 con subnet 255.255.255.0 y gateway 192.168.0.1 con mtrica 1, el comando sera:

netsh interface ip set address Local Area Connection static 192.168.0.10 255.255.255.0 192.168.0.1 1
De esta forma estars haciendo con un solo comando lo mismo que te hubiera tomado abrir mltiples ventanas y escribir varias configuraciones. Y podemos ir mas all, podemos escribir el siguiente batch file en el notepad:

netsh interface ip set dns Local Area Connection dhcp netsh interface ip set wins Local Area Connection dhcp netsh interface ip set address Local Area Connection dhcp ipconfig /renew
Con este bachito podras reconfigurar las opciones de DNS, WINS, y la direccin de IP de TCP/IP; cambiando las direcciones estticas por las asignadas por el servidor DHCP. Y podemos ir aun mas all. Utilizando la aplicacin PSEXEC (parte del conjunto de aplicaciones de administracin PSTOOLS de systernals, mas info aqu: http://technet.microsoft.com/enus/sysinternals/bb897553.aspx) podemos correr nuestro bachito desde la comodidad de nuestro escritorio y desde la consola de comandos de tu PC, sin tan siquiera tener que conectarnos remoto a la maquina. Asumiendo que guardaste el batch file en el directorio system32 de tu PC bajo el nombre IPtoDHCP.bat, solamente escribiras el siguiente comando:

psexec \\{computadora} -d -c IPtoDHCP.bat

Donde {computadora} es el nombre direccin IP de la PC. Nota que el comando ipconfig /renew desconectara la PC temporeramente de la red, por lo que te debes de asegurar de que el usuario no est haciendo nada que requiera una conexin continua a la red. Y tan tan, con un solo comando en tu computadora cambiaste toda la configuracin de TCP/IP de una PC. Este es un ejemplo de las muchas cosas que se pueden hacer por medio de comandos, batch files y scripts. Muchos piensan que son algo anticuados y que no tienen muchos usos, pero en realidad es una herramienta de trabajo muy potente que facilita muchas de las tareas administrativas diarias de una red. Y esto es aun mas cierto con la llegada de PowerShell, pero este ya es otro tema ;o)
1. 1. Conecta tu disco usb a una PC Windows XP o ms reciente. Asegrate de que el sistema operativo reconozca tu disco.

2. Verifica la letra que el sistema operativo le asigno al disco. Esto lo puedes ver fcilmente abriendo My Computer. Para este ejemplo asumiremos que se le asign la letra X:. 3. Abre una ventana de lnea de comando (command prompt) presionando simultneamente las teclas de windows y r, escribes CMD y haces click en el botn de OK.

4. En el command prompt entras el comando convert x: /fs:ntfs donde x: es la letra asignada al disco removible. Es muy importante que no desconectes ni apagues tu disco removible durante este proceso. Y listo, el proceso tardar algunos minutos pero de todo salir bien, tu disco habr sido convertido a new technology file system (NTFS). Espero que le saques provecho a las ventajas que ofrece NTFS, cualquier duda o comentario no olvides dejar tu mensaje.

Firewall Windows con Seguridad Aadida

1. Netsh advfirewall firewall 2. Nuevas Caractersticas de Seguridad en Directorio Activo: Controladores de Dominio de Slo Lectura 3. NAP (NetWork Access Protection) 4. Windows Deployment Services 5. Algunas Notas sobre Servicios en Windows Server LongHorn Por fin ha llegado, y la espera ha merecido la pena. La Beta 3 del nuevo sistema operativo Windows Server LongHorn, como solucin en servidores Microsoft ya est entre nosotros. Windows Server LongHorn tiene tras de s la larga experiencia adquirida por Microsoft en sistemas operativos Windows para servidores e incluye muchas nuevas caractersticas y mejoras tecnolgicas. Estas ayudarn a incrementar la seguridad, productividad, escalabilidad, as como a reducir considerablemente la carga del administrador en el desarrollo de sus tareas habituales. En comparacin con el sistema operativo anterior Ms Windows 2003, LongHorn nos ofrece toda una serie de mejoras as como nuevas caractersticas y funcionalidades. Pasamos a enumerar algunas de las novedades que consideramos como de mayor inters. Entre stas se encuentran el nuevo Server Manager, BitLocker Drive Encryption, Application Server Role, un nuevo Firewall de Windows con seguridad avanzada, NAP (NetWork Access Protection), Terminal Services Gateway, Terminal Services RemoteApp, Server Core, PowerShell, Backup, homogeneizacin de aplicaciones, as como otras muchas. En el presente artculo vamos a comentar y presentar con algo ms de detalle algunas de estas mejoras integradas en Windows Server LongHorn. A diferencia de otros lanzamientos realizados en productos y versiones anteriores, esta beta posee todas las funcionalidades del producto final. Es por ello que las modificaciones que se hagan al producto, tendrn que ver con cuestiones de rendimiento y optimizacin, pero la informacin que a partir de ahora presentemos ser por lo tanto perfectamente vlida.Server Manager. Configuracin inicial del Sistema. Inicialmente lo primero que encontramos en el arranque de Windows Server LongHorn, es la herramienta de configuracin inicial del sistema, en la que se nos muestra una serie de pasos a realizar para finalizar la configuracin de nuestro servidor. Podremos completar tareas de actualizacin del sistema, instalar features o complementos, implementar roles, establecer el horario, adscribir la maquina a un dominio, modificar la password de la cuenta administrativa, configurar la red, etc. En definitiva por lo tanto se observan los primeros pasos que un administrador debe de llevar a efecto a la hora de finalizar la instalacin inicial de un servidor. Mostramos en la siguiente imagen el cuadro correspondiente.

Una de las principales caractersticas que destacaramos inicialmente del nuevo sistema es el concepto de rol, as como su capacidad de implementarlo desde un primer momento. Es posible determinarlo inicialmente en funcin del tipo de servidor o servicio al que vayamos a dedicar la nueva mquina que estamos preparando. Servidores DHCP, controladores de dominio, servidores DNS, servidores de impresin, de Terminal Services, etc En Windows 2003 tenamos una herramienta similar pero que pas un tanto desapercibida. Esta se denominaba Configura tu servidor. Windows Server LongHorn, dando un paso ms, ha sido diseado con mdulos directamente ajustables al rol que necesitemos implementar en nuestros servidores de forma ms clara y directa. Para lograrlo disponemos de un componente del sistema denominado Server Manager, que sirve de base para la administracin del sistema, y que nos ayudar en todo momento a mantener un control estricto y preciso del sistema, todo ello de una forma sencilla y amigable Cuando administramos una red, por pequea que sea, los administradores siempre echamos de menos algo que nos facilite nuestras tareas habituales en cuando a administracin se refiere. A veces tenemos que administrar servidores de antivirus, Firewalls de aplicacin, herramientas del sistema operativo y un sinfn de tareas. Cada tarea requiere de una aplicacin, y cada aplicacin, necesita de su propia interface. En estas circunstancias las tareas se pueden volver algo ms tediosas, y en muchos casos, inseguras, al dejar de prestar la atencin debida o al vernos obligados a atender de forma simultnea varias interfaces de trabajo. Microsoft est apostando fuerte en este tema desde hace tiempo. Como clara demostracin de ello, aparecieron las nuevas consolas de administracin MMC, integrndose en

prcticamente la mayora de aplicaciones de Windows. Estas proporcionan un ambiente homogneo para todas las aplicaciones. Muchos de los administradores que se encuentre leyendo el presente artculo lo habrn comprobado directamente si dentro de sus tareas se encuentra la administracin de Internet Information Server, ISA Server 2006, Microsoft Forefront, etc En Windows 2003 disponamos de la herramienta "Administracin de equipos". Sin embargo se echaba en falta que en la misma consola se pudiesen instalar aplicaciones, extensiones, features, administrar el firewall, etc Para todas estas tareas era necesaria la apertura de otras ventanas, y en algunos casos incluso, necesitbamos otras aplicaciones. Es por ello que en determinados momentos la tarea de administrar varios elementos a la vez poda resultar, cuanto menos, pesada. Con "Server Manager" se resuelve positivamente esta circunstancia, ya que la herramienta se integra en las nuevas consolas de administracin MMC. De ste modo, en una misma consola, estamos capacitados para administrar una parte muy importante de nuestro sistema operativo, como son por ejemplo la administracin de usuarios y grupos, Windows Server Backup, tareas de particionamiento, administracin y redimensionado de discos, Firewall de Windows con seguridad avanzada, Tareas programadas, herramientas de diagnstico, servicios, roles, features, log de sucesos, junto a otras. Todo ello, como podemos observar en la imagen inferior, aparece ahora en una misma consola, sin necesidad de abrir otras aplicaciones o ventanas. Sustituimos as las consolas de Aadir o quitar complementos, Configura tu servidor o Administrar Servidor. De igual modo, desde esta consola de trabajo, podremos redimensionar nuestros discos, a la vez que aadimos reglas a nuestro Firewall, pasando por la creacin de tareas programadas o verificar que la realizacin de las copias de seguridad se est llevando a efecto de la forma adecuada.

Firewall Windows con Seguridad Aadida

Uno de los aspectos ms notables a destacar en materia de seguridad, ha sido la incorporacin del nuevo Firewall de Windows con seguridad aadida. De sus caractersticas novedosas enunciamos ahora algunas de considerable inters: soporte nativo para IPV6, la posibilidad de controlar el trfico tanto entrante como saliente, NAP (Network Access Protect), Hardening de servicios, la integracin con IPSEC, reglas aplicables a perfiles determinados, reglas basadas en directorio activo, usuarios, grupos y computadoras, etc.. De nuevo, y al estar integrada en su totalidad en las nuevas consolas de administracin MMC, se mejora bastante la administracin del mismo, pudindose crear, mediante asistentes grficos, reglas tanto de entrada como de salida, y pudiendo llegar a la personalizacin de estas reglas hasta el ms mnimo detalle.

Dependiendo de las reglas que queramos aplicar, podremos implementarlas en funcin de diversos factores: Nombre de aplicacin.- Es posible restringir o permitir a una aplicacin la conexin con el exterior. Puertos.- Es posible restringir o permitir a todos o a un nmero determinado de puertos la conexin. Direcciones IP.- -Es posible restringir o permitir a una direccin IP o un rango entero de direcciones la conexin con algn tipo de aplicacin o servicio. ICMP o ICMPV6.- Es posible restringir o permitir algn servicio de este tipo, como por ejemplo ping. Configuracin del protocolo Servicios.- Es posible restringir o permitir la conexin al exterior de algn servicio. Usuarios AD, locales, grupos o mquinas.- Es posible restringir o aplicar reglas para un determinado grupo de usuarios, usuarios de directorio activo o locales. Tipos de Interface.- Es posible aplicar o restringir las reglas en funcin del tipo de interface que tengamos en el equipo, ya sea Wireless, Ethernet, u otros. En la parte derecha de la consola del Firewall, disponemos de varias opciones tambin de inters para el administrador. Estas nos van a suministrar la oportunidad de exportar/importar directivas, as como el establecimiento de filtros en funcin del perfil, del estado de la conexin o de la pertenencia a grupos. Igualmente en la parte izquierda de la consola se nos presentan las opciones de configuracin y monitorizacin de reglas. Estas no van a permitir configurar tanto las reglas de entrada como las de salida, y monitorizar el estado de conexiones y actividad del Firewall. Finalmente en la parte central, podremos ver en todo momento el estado en que se encuentra nuestro Firewall. Siendo posible visualizar tambin los perfiles de conexin que nos proporciona por defecto Windows: Perfil de dominio, perfil privado y perfil pblico, as como los accesos para la creacin de reglas de entrada o salida y un apartado de recursos y documentacin. Si pulsamos en la parte izquierda sobre las opciones de reglas de entrada y reglas de salida, stas se nos mostrarn en el centro de la consola. En las propiedades es posible la visualizacin de los 3 tipos de perfiles: Perfil de Domino: Equipo que se conecta a una red corporativa, formando parte del directorio activo. Perfil privado: Equipo que se conecta a una LAN privada, como puede ser una red domstica por ejemplo. Perfil pblico: Equipo que se conecta a una red sobre la que no disponemos de control alguno. Cibercafs, aeropuertos, y otros escenarios similares son claros ejemplos de ello. Refirindonos a servidores podra servirnos como ilustrativa la instalacin de uno de ellos en una zona DMZ. En el momento de incorporar un servidor LongHorn a una red, automticamente se lleva a efecto la deteccin del tipo de red a la que nos estamos conectando. Por defecto, se activa

automticamente el perfil pblico. En funcin de la configuracin de nuestro Firewall, pasarn a aplicarse las reglas establecidas para el perfil en concreto seleccionado. Por ejemplo, si disponemos de una aplicacin a la que conectamos libremente desde casa pero no desde la oficina, podemos llevar a efecto la creacin de una regla que determine que es posible la conexin libremente a internet cuando estemos operando bajo el perfil privado, pero que no sea posible la misma cuando operemos a travs de un perfil de dominio. Con ello se facilita considerablemente la labor a los administradores, creando la misma regla pero con mbitos de accin diferentes en funcin del perfil.

Cada perfil es totalmente configurable, pudiendo desactivarlo o activarlo a nuestro gusto, creando archivos de log para cada uno de ellos, mostrando notificaciones de bloqueo, etc. lo cul evidentemente facilita y mejora las posibilidades de administracin asociadas. Es interesante indicar en este momento que en funcin del mbito de red que escojamos, las reglas configuradas por defecto sern ms o menos estrictas. El perfil ms restrictivo es el perfil pblico. Este debera ser el seleccionado si la instalacin de nuestro servidor se va a realizar en reas no controladas por nosotros al 100%, con una superficie de ataque amplia. Por el contrario, el perfil menos restrictivo es el de dominio. En este escenario la administracin ms centralizada y segura nos permite que las restricciones en funcin del perfil sean menores sin por ello menoscabar el nivel de seguridad deseado. Adicionalmente, y como todo complemento de Windows, el Firewall es tambin administrable 100% a travs de la lnea de comandos. Para ello disponemos de la herramienta netsh. Esta es una aplicacin que opera bajo lnea de comandos y que nos

permite administrar la configuracin de red de un equipo. Este tipo de administracin es posible realizarla tanto de forma local como remota. No olvidemos sin embargo que Netsh no slo sirve para administrar el Firewall de Windows, sino que no capacita tambin para la administracin al 100% de nuestra configuracin de red. Pudiendo as, y a travs de ella, administrar NAP, HTTP, RPC, configuraciones IP, solucionar problemas de WinSock, y otras funcionalidades y caractersticas propias del entorno de red, operando bien en remoto o local.La sintaxis del comando en cuestin es la siguiente:

Netsh advfirewall firewall

Desarrollemos un ejemplo ilustrativo asociado. Ante la necesidad de tener que implantar una aplicacin que cumpla las siguientes condiciones: Salida al exterior de la intranet corporativa. Regla slo aplicable al perfil pblico. El Firewall debe permitir esta conexin, siendo transparente al resto de los perfiles. La sintaxis completa del comando sera la siguiente: Netsh advfirewall firewall add rule name=" Permitir aplicacin Contabilidad" dir=out program="C:\Archivos de programa\Aplicacin de Contabilidad\Contabilidad.exe" profile=public action=allow En donde, el apartado dir refleja la naturaleza de la regla (si es de entrada o de salida), el apartado profile refleja el mbito de la regla (perfil pblico, privado o de dominio) y el apartado action refleja la accin del firewall (permitir o denegar). Con netsh podremos crear y eliminar reglas, hacer backups de las mismas, etcOtra caracterstica novedosa del Firewall Windows es que su total integracin con el protocolo seguro IPSEC. Basndose, como ya indicbamos, toda la administracin en una consola nica. En versiones anteriores de Windows, los administradores tenamos que lidiar con el firewall y las reglas de IPSEC en consolas diferentes. Recuerdo cuando a veces creaba reglas IPSEC que luego me bloqueaba el Firewall. Me volva loco Ya no saba si era del Firewall, las reglas, el equipo, el cable, etc La diversidad de las consolas de trabajo era sin lugar a dudas una posible interferencia en la operativa del administrador que ahora ha sido subsanada. La total integracin del Firewall Windows con IPSEC en el nuevo sistema operativo no permite ver en una nica consola como se estn aplicando nuestras reglas, pudiendo ver con mayor detalle si sta se est efectuando correctamente, y reducir as la superficie de error.

Nuevas Caractersticas de Seguridad en Directorio Activo: Controladores de Dominio de Slo Lectura

Me gustara abordar en este punto otra cuestin que creo que puede tener intrigados a muchos tcnicos, y que planteo desde una pregunta que me hicieron no hace mucho. La pregunta era "Un Controlador de Dominio puede aumentar la seguridad de una corporacin, si ste es administrado correctamente, pero qu pasa con los controladores a los que no podemos garantizar una seguridad fsica?." La respuesta es evidente e incluso inquietante.

Bastara que un hacker comprometiese el controlador de dominio para poder tener acceso a informacin sensible de toda la corporacin.LongHorn se ha pensado y diseado para ser implementado en muchos entornos, entre ellos el mismo escenario que plantebamos en el prrafo anterior. Una corporacin que necesita tener un DC (Domain Crontoler) replicando y situado en una ubicacin de la que no podemos garantizar su seguridad ni fsica, ni lgica. Para atender a esta circunstancia nace una nueva figura, el Controlador de Dominio de solo lectura (RODC Read Only Domain Controller) Este nos permite que podamos implementar un DC con una base de datos del dominio de solo lectura.

Un RODC mantiene los mismos atributos y objetos que un controlador de dominio de escritura, con la excepcin de no poder hacer cambios en la base de datos. En su lugar, si alguna operacin necesita escribir en la base de datos, sta hace la replicacin en un controlador de dominio de escritura que a su vez, replica en el RODC.De este modo evitamos varios problemas, entre ellos dos importantes que anteriormente quedaban expuestos: La replicacin indebida a nuestro bosque, y una posible exposicin de ataque. Adicionalmente reducimos la carga de replicacin a otros servidores, ya que como en un RODC no es posible escribir en la base de datos, ste no puede replicar. Es decir, en un RODC la replicacin siempre es nica y exclusivamente unidireccional. En la arquitectura de un RODC tambin se ha pensado en el almacenamiento de credenciales. Por defecto, en un

sistema basado en Windows, se guardan los 10 ltimos inicios de sesin. Se dise as para poder iniciar una sesin en un equipo miembro de un dominio, incluso si ste fallase por cualquier circunstancia. En escenarios donde no se puede garantizar una seguridad fsica ni lgica, esta cuestin puede representar un serio problema de seguridad. Aplicaciones como cachedump pueden ser utilizadas para recuperar las contraseas almacenadas en la cach del sistema. La opcin de cach del sistema se poda y se puede configurar de forma sencilla en cualquier Windows. Observando lo anterior un RODC no guarda credenciales de usuarios ni de equipos (establecido por defecto), salvo la de sus cuentas locales y la cuenta de sistema que se utiliza para la autenticacin kerberos (krbtgt), buscando de este modo eliminar o al menos minimizar los riesgos expuestos. Sin embargo en estas como en otras cuestiones no siempre llueve al gusto de todos y nos podemos encontrar con que esta limitacin respecto de la cach no sea la ms correcta en determinadas circunstancias. Es por ello que se ha pensado en la posibilidad de asignar cach para aquellas cuentas que precisemos oportunas. Si tenemos un RODC en una oficina externa, y sta oficina tiene 20 usuarios, podremos asignar cach a esos 20 usuarios y denegar al resto. Si por alguna razn, el RODC es comprometido o robado fsicamente, slo tendremos que restablecer las contraseas de estas cuentas. Al tener total seguridad de qu cuentas pueden ser comprometidas, reducimos el tiempo de accin de un administrador para solucionar la brecha de seguridad. Incluso podramos permitirnos el lujo de asignar una cuenta administrativa slo para manejar el RODC, pero sin acceso a los DC centrales con permiso de escritura. Server Core. Windows tambin puede operar sin ventanas. Pasamos en esta apartado a valorar otra novedad de LongHorn. El sistema nos aporta la posibilidad de llevar a efecto una instalacin mnima de servidor, tambin conocida como Server Core. El proceso en este caso es sumamente sencillo. Tan slo tendremos que seleccionar la opcin de Server Core, y se instalar el sistema base sin entorno grfico. Nada de instalaciones complicadas. Toda la instalacin a slo un clic de ratn.Con Server Core podremos realizar la instalacin mnima de un servidor, con slo funciones o roles necesarios que nos permitan desempear aquellas funcionalidades especficas para las que estemos generando el nuevo servidor. Evidentemente la metodologa en esta ocasin es bsica y se ocupa nicamente de atender los mnimos necesarios. La instalacin es mnima, ocupndose exclusivamente del sistema base, y el rol o roles que necesitemos que adicionalmente desempee el equipo. Todo ello sin sistema grfico, operando ntegramente travs de la Shell. Nuestro sistema Windows se ha quedado en esta ocasin sin ventanas. Supongamos, a modo de ejemplo, un escenario en el que necesitamos que un servidor adopte exclusivamente las funciones como DHCP y DNS. En una instalacin Server Code, sta se limitar al sistema base y una Shell de comandos. Posteriormente, a travs de sta, completaremos la instalacin con los servicios adicionales necesarios. Como ya indicbamos, un Windows sin Windows que sin embargo cubre las necesidades que se le demandan. Una vez instalado el sistema base, nos encontramos con un entorno de trabajo bsico. A muchos administradores puede parecerles incluso un tanto hostil, ya que carece de componentes grficos. Como veremos a continuacin, mantener y administrar un servidor de estas caractersticas no es, ni mucho menos, tan complejo como puede parecernos. A los ms veteranos de la administracin les resultar incluso familiar.

Abordemos un ejemplo prctico en mayor detalle para ilustrar este apartado. Una vez instalado el servidor en un modo Server Code, ste presenta una configuracin bsica no operativa y en nuestro ejemplo tendremos que desarrollar por lo tanto todos los procesos manualmente, sin apoyarnos en ningn asistente. De este modo modificaremos la password de administrador, cambiaremos el nombre de equipo, configuraremos la red, activaremos Windows, pasando posteriormente a actualizarlo. Finalmente instalaremos un rol y un complemento. A los ms antiguos del lugar les traer recuerdos sin lugar a dudas.

Para cambiar la password de la cuenta Administrator, utilizaremos el comando: Net user Administrator * El comando nos solicitar que introduzcamos una password, y posteriormente nos la volver a pedir para su verificacin. El asterisco se suele poner para no tipear la password en texto plano. Con esto evitamos a posibles "voyeur" que estn intentando visualizar lo que escribamos en pantalla. Posteriormente pasamos a modificar el nombre de equipo de la mquina, ya que tal vez el nos haya asignado la instalacin, no corresponda a la poltica corporativa de nomenclatura de mquinas. Cambiar el nombre de mquina es tan sencillo como formular adecuadamente el comando cuya sintaxis reflejamos a continuacin:Netdom renamecomputer /newname: Ejemplo:Netdom renamecomputer QFGPH-345P /newname: Sevw2k3prb01 Una vez que la password se ha modificado y el nombre de equipo se encuentra dentro de la poltica de nomenclatura de la empresa, procederemos a comprobar si el cliente DHCP y el cliente DNS estn en funcionamiento. Para ello bastar con teclear un query de servicios con el comando SC. Sc query DHCP Sc query DNS

Comprobado que tenemos estos servicios iniciados y en funcionamiento, es hora de asignar una direccin IP a nuestro adaptador Ethernet. Para ello utilizaremos el comando netsh. Primeramente tendremos que averiguar el nombre de nuestra interfaz. Para hacerlo teclearemos el siguiente comando: Netsh int show interface Este comando nos devolver el nombre de interface, informacin necesaria si posteriormente tuvisemos que modificar su direccin IP. Para establecer la direccin IP de un adaptador, existen dos posibilidades: direccionamiento dinmico (DHCP) o direccionamiento esttico. La operativa para recibir la direccin IP desde un servidor DHCP es bien sencilla. Simplemente tendremos que teclear el comando siguiente: Netsh int ip set address name="Local Area Connection" source=d.C. Para direccionamiento esttico, imaginemos que necesitamos asignar la direccin IP 192.168.4.120/Clase C y la puerta de enlace 192.168.4.250 a nuestro servidor. El nombre de la interfaz es Local Area Connection. El comando resultante sera el siguiente: Netsh int ip set address name="Local Area Connection" source=static address=192.168.4.120 mask=255.255.255.0 gateway=192.168.4.250 1 gwmetric=1 Una vez configurada la red, debemos realizar una comprobacin de conectividad que verifique que el proceso de configuracin se ha finalizado con xito.

Una vez realizado el test de conectividad procederemos a activar Windows. Para realizarlo, utilizaremos el siguiente comando: Slmgr.vbs ato Una vez activado Windows Server LongHorn, el sistema nos presenta una ventana informativa mostrndonos el estado de la actualizacin.

Avanzando en nuestro proceso de configuracin, y antes de instalar cualquier rol, podemos actualizar nuestro Windows Server LongHorn con las ltimas actualizaciones de seguridad. Para ello debemos de seguir una serie de pasos, que detallamos a continuacin: Lo primero que debemos hacer es configurar nuestro servidor para que se descargue actualizaciones cada cierto tiempo. En nuestro caso cada 3 horas. Estos trminos podemos establecerlos con el comando siguiente: Cscript C:\windows\system32\scregedit.wsf /AU /4

Una vez que hayamos configurado las actualizaciones, procederemos a parar y reiniciar el servicio de actualizaciones, para que ste recoja el cambio. Teclearemos los siguientes comandos: Net stop Wuauserv Net start Wuauserv Existen multitud de comandos que podemos emplear a travs de la Shell de Windows. Las posibilidades son amplias. Los lmites son nuestra imaginacin y conocimientos.Instalar un componente o algn rol no es muy distinto de lo que ya hemos explicado. La operativa a travs de la lnea de comandos es la misma, siendo la nica particularidad que tendremos que hacerlo a travs de una aplicacin denominada ocsetup.exe.

Si por ejemplo necesitsemos instalar un servidor DHCP en nuestro Windows Server LongHorn, ejecutaramos el siguiente comando: Ocsetup.exe DHCPServerCore Automticamente el sistema instalara un servidor DHCP en nuestro equipo. Actualmente la herramienta ocsetup es sensible a maysculas y minsculas, con lo que tendramos que escribir el comando exactamente como ha sido reflejado con anterioridad. Bitloker. Cifrado de Datos

Windows Server LongHorn incorpora una nueva funcionalidad en el campo de cifrado de datos. BitLocker. Este nuevo sistema garantiza la seguridad y la confidencialidad de los datos almacenados en el disco mediante cifrado. BitLocker va a ser el encargado de realizar los procesos de cifrado y descifrado de una forma totalmente transparente. Adicionalmente y a diferencia de Windows Vista, podemos extender el cifrado de datos a otros volmenes que utilicemos para tal fin. Este mismo mecanismo interviene tambin cuando el equipo entra en el modo de hibernacin o para garantizar tambin la seguridad del fichero de paginacin, los ficheros temporales y todos aquellos elementos que puedan contener informacin sensible. Los mecanismos de seguridad implementados por BitLocker se complementan mediante unas nuevas especificaciones de seguridad hardware llamada Trusted Platform Module (TPM). Este nuevo chip TPM proporciona una plataforma segura para el almacenamiento de claves, password o certificados, haciendo ms difcil el ataque contra las mismas. Una vez que el mecanismo de cifrado ha sido puesto en marcha, la clave de cifrado es eliminada del disco y posteriormente almacenada en el Chip TPM. Con objeto de defendernos de un posible ataque al sistema hardware que intente explotar posibles vulnerabilidades, se proporcionan mecanismos de autentificacin mediante sistemas adicionales tales como el uso de Token (llave USB) o una password (PIN) para evitar esta posibilidad. Cabe decir en este punto que aunque nuestros equipos no dispusieran de este mecanismo de seguridad, las especificaciones de BitLocker admiten su funcionalidad sin el chip TPM. El uso combinado de mecanismos hardware y software aumenta sensiblemente el porcentaje de posibilidades de xito a la hora de protegernos de aquellos ataques que tengan como objetivo la modificacin o alteracin de datos. Estos aunque cifrados podran ser manipulados mediante la explotacin de vulnerabilidades para poder posteriormente acceder a ellos. La implementacin de BitLocker requiere de la existencia de condiciones determinadas para poderla llevar a efecto. Un factor a considerar es que el sistema debe disponer al menos de dos particiones NTFS. Una de ellas, la particin activa, albergar el sistema de arranque y no se encontrar cifrada. Es por ello que BitLocker tambin proporciona mecanismos para garantizar que no se han producido modificaciones en el sistema de arranque del sistema, tales como los que pueden provenir de ataques tipo malware que pudieran producir un ataque colateral o el control del acceso al sistema. Los mecanismos de implementacin pueden variar en funcin del escenario que necesitemos implantar. Dependiendo del mismo son diversas las posibilidades. De este modo podremos utilizar BitLocker slo con TPM, con algn dispositivo de validacin (USB), TPM ms PIN, o TPM con dispositivo de validacin (USB). La implementacin de esta tecnologa depender fundamentalmente si nuestro hardware presenta o no el chip TPM. Si no lo llevase, la nica opcin posible sera el almacenamiento de clave bajo dispositivo USB. Para todos aquellos que necesiten utilizar el cifrado y no posean el Chip TPM, Windows Server LongHorn presenta una directiva de seguridad bajo la cul podemos condicionar el

uso de BitLocker sin el citado Chip. Por defecto el sistema slo admite la configuracin de BitLocker si el equipo cuenta con el Chip.

NAP (NetWork Access Protection)

Sin lugar a dudas podemos afirmar que en la actualidad las redes corporativas y las no corporativas son cada da ms complicadas de administrar y securizar. Los escenarios presentan cada vez circunstancias de mayor dificultad: comerciales que conectan sus PDAs a los porttiles o equipos de sobremesa, conexin permanente por parte de los usuarios de dispositivos de almacenamiento externo, usuarios que presentan necesidades operativas en distintas redes de forma habitual son, junto a otros, claros ejemplos de ello. Desgraciadamente estas circunstancias incrementan considerablemente las mltiples amenazas de seguridad posibles como pueden ser malware, exploits, spyware, DOS, ScriptKiddies y otros. Estas aplicaciones pueden tomar el control de nuestro sistema, realizando acciones malvolas de forma totalmente transparente. Lo peor de todo, an as, es que adems pueden utilizar el sistema comprometido como puerta de entrada de otras amenazas. La caracterstica NAP (NetWork Access Protection) es otra de las novedades que nos ofrece Windows Server Longhorn en cuanto a la securizacin del sistema. Podemos utilizar NAP para paliar el impacto de situaciones como las antes indicadas, y optimizar el nivel de proteccin de la red corporativa y la informacin contenida en la misma.Esta tecnologa se pens en un principio para que estuviese presente en Microsoft Windows Server 2003 R2, pero finalmente en su lugar apareci NAQS (Network Access Quarantine Control)

integrndose con IAS (Internet Authentication Service) como solucin de control de acceso para clientes de acceso remoto. Esta implementacin a travs de una validacin del modelo de seguridad va vbscripting, fue algo que ms tarde apareci integrado en la solucin de Microsoft ISA Server 2004 a travs de una caracterstica conocida como VPN Quarantine. En el siguiente enlace podemos encontrar ms informacin al respecto: http://go.microsoft.com/fwlink/?LinkId=56447. La implementacin de NAP en Windows Server Longhorn nos permite especificar cul es la poltica de salud de nuestra red. De este modo se establecen una serie de condiciones que ayudarn a los administradores a determinar que equipos de los que se conecten a nuestra red desde cualquier medio (VPN, Internet, Wireless junto a otros) cumplen con una poltica de salud aceptable y acorde a las directrices de la seguridad corporativa. Si para nosotros una buena poltica de salud pasa por defendernos de las enfermedades, hacer ejercicio de forma constante, una buena alimentacin, etc., para un equipo una buena poltica de salud pasara por disponer de un antivirus a pleno funcionamiento y con las firmas actualizadas, tener instaladas todas las actualizaciones de seguridad, junto a otras medidas de securizacin que puedan considerarse como imprescindibles. Para los equipos que no cumpliese con la poltica de seguridad establecida, podran ser dos las circunstancias: en primer lugar que no fuese posible la conexin a nuestra red corporativa o como alternativa que esta fuese limitada. En este segundo caso la conexin se realizara pero en una red aislada de toda la corporacin, con acceso slo a algunos recursos, y a la espera de poder cumplir con los mnimos requisitos de salud.Con NAP podremos: Asegurar una poltica de salud en nuestros equipos que se configuren para DHCP, equipos que se conecten a travs de mecanismos de autenticacin 802.1X, VPN, y equipos que tengan una poltica de seguridad NAP IPSEC aplicadas a sus comunicaciones. Reforzar la poltica de seguridad y de salud en equipos porttiles, cuando stos vuelvan a conectarse a nuestra red Restringir el acceso a nuestra red a todo equipo que no cumpla con la poltica de salud de la compaa NAP tambin incluye una API (Aplication Programming Interface) para desarrolladores. A travs de ella ser posible la generacin de componentes de seguridad realizados a medida de las necesidades del sistema corporativoUna infraestructura NAP requiere de un servidor Windows Server LongHorn para su despliegue, y los clientes soportados son Windows Server LongHorn, Windows Vista y Windows XP SP2. Para ste ltimo, necesitamos instalar el cliente NAP para Windows XP, y que actualmente se puede descargar desde la Web http://connect.microsoft.com/.Estas tecnologas puede ser utilizadas en de forma independiente o junto a otras en funcin del modelo de seguridad y la infraestructura a utilizar. La implementacin de polticas de salud se realiza a travs de un NPS (Network Policy Server) disponible en Microsoft Windows Server LongHorn.y que reemplaza a IAS (Internet Authentication Service) presente en Microsoft Windows Server 2000/2003. NAP se va a responsabilizar de llevar a efecto una serie de acciones: Validacin de la poltica Aplicacin de NAP Restriccin (cuando sta es necesaria) Establecer las pautas para adecuar el nivel de salud de un cliente

 Supervisin NPS (Network Policy Server) utiliza SHVs (System Health Validators) para analizar el estado de salud del equipo. SHVs viene incorporado dentro de las polticas de red, y determina la accin a tomar basndose en el estado de salud del equipo que se conecta. Como indicbamos las acciones que se pueden desencadenar son varias: conceder el acceso a toda la red en aquellas situaciones en que se cumplen las demandas de seguridad establecidas o por el contrario denegar el acceso o limitar el mismo a una red de cuarentena en caso contrario. El estado de salud de un equipo es monitorizado por una parte del cliente NAP, denominada SHAs (System Health Agent). La proteccin de acceso a la red utiliza en definitiva SHAs y SHVs para monitorizar, reforzar y remediar la configuracin de seguridad-salud de un equipo. Windows Security Health Validation y Windows Security Health Agent se encuentran incluidos en Windows Server LongHorn y Windows Vista. Ellos refuerzan las siguientes configuraciones en un entorno NAP protegido: El PC cliente tiene el Firewall instalado y en funcionamiento El PC cliente tiene el antivirus instalado y en funcionamiento El PC cliente tiene las ltimas bases de virus instaladas El PC cliente tiene el software anti-spyware instalado y en funcionamiento El PC cliente tiene las ltimas bases anti-spyware instaladas El PC cliente tiene habilitado Microsoft Update Services Si a todo esto aadimos un servidor WSUS, el cliente NAP puede verificar que las ltimas actualizaciones de seguridad estn instaladas en el equipo, basndose en uno de los cuatro niveles de seguridad establecidos por la plataforma Microsoft Security Response Center (MSRT). Como mencionbamos con anterioridad NAP puede ser configurado para denegar totalmente el acceso a la red, o permitir acceso slo a una red de cuarentena. En una red de cuarentena podremos encontrar servicios NAP, tales como servidores de certificados de salud (HRA), necesarios para la obtencin de certificados provenientes de una entidad certificadora (CA) o remediation servers (RS). Estos ltimos disponen los recursos necesarios para que aquellos clientes que no tengan un nivel de salud ptimo, puedan realizar ciertas tareas. Como opcin podemos disponer tambin en la red de cuarentena de recursos que permitan actualizar los equipos con las ltimas actualizaciones de seguridad, bases de virus, bases anti-spyware, y otros.Una breve descripcin del proceso sera la siguiente. El agente de salud del sistema (SHAs) contiene la informacin de salud de los equipos. ste pasa la informacin a un servidor NPS. El validador de salud (SHVs) del servidor de polticas de red (NPS) realiza el proceso de validacin de la poltica de salud del equipo cliente, y determina si cumple los requisitos para poder conectarse a la red. Si no los cumple, manda a este equipo a una red de cuarentena, en donde dispondr de los recursos necesarios para que se pueda actualizar acorde a la poltica de salud de la red corporativa.Con NAP tambin nos es posible configurar los servicios de remediacin, para que stos automticamente actualicen los equipos en funcin de la poltica de salud de la empresa. Analicemos un ejemplo de posible intervencin

de estos servicios. En una poltica de seguridad donde los equipos deban disponer del Firewall Windows activado, si habilitamos la opcin en automtico (servicios de remediacin), aquel cliente que no tenga disponga del firewall de Windows activado, sera enviado a un segmento de red de cuarentena, y los componentes NAP del cliente habilitaran el firewall de Windows sin intervencin del usuario. La operativa de NAP es posible en diversos escenarios. Algunas posibilidades podran ser los siguientes: trfico protegido con IPSEC, 802.1X, VPN con acceso remoto, DHCP IPV4 (tanto para renovacin como concesin de direcciones). Describamos con algo ms de detalle estos escenarios. NAP para entornos IPSEC. Para la implementacin de NAP en entornos con IPSEC es necesario implantar una entidad certificadora de salud (HRA Server), un NPS Server y un cliente IPSEC. El HRA publica los certificados de salud X.509 para los clientes NAP. Estos certificados son utilizados para autenticar los clientes NAP cuando stos inician una comunicacin basada en IPSEC con otros clientes NAP de la intranet. Este es el mtodo ms seguro de aplicar NAP. NAP para entornos 802.1X. Para implementar esta solucin, necesitamos desplegar un servidor NPS y un componente (EAP). El servidor NPS enva la autenticacin basada en 802.1X a un punto de acceso de la red interna. Si el equipo cliente no cumpliese con alguna regla establecida, el servidor NPS limitara el acceso al cliente mandando al punto de acceso un filtro basado en direccin IP o identificador virtual. NAP para entornos VPN (Virtual Private Network). En esta ocasin necesitamos de un servidor y un cliente VPN. Usando NAP para entornos VPN, los servidores VPN pueden forzar el cumplimiento de la poltica de salud de la empresa cuando los clientes externos se conecten a nuestra intranet. Esta solucin proporciona los mecanismos necesarios para establecer una comunicacin segura entre un cliente externo y la red interna. NAP para entornos de configuracin dinmica de direcciones (DHCP). Para implementar esta solucin, necesitamos el componente NAP de un servidor DHCP y un servidor NAP. Usando DHCP, podemos cumplir con la poltica de salud de la empresa a travs de NPS y DHCP. Cuando un equipo intente renovar o solicitar una direccin IP (IPV4). El servidor limitara el acceso a los equipos que no cumpliesen con la poltica de salud de la empresa asignando direcciones IP reservadas para tal fin.Cada uno de estos mtodos de implementacin NAP tiene sus ventajas e inconvenientes, por lo que implantar una plataforma de este tipo en una corporacin depender en gran medida de las necesidades de servicio y condiciones operativas de sta. NAP adicionalmente proporciona una API para desarrolladores que necesiten integrar su software a las necesidades de la empresa. Con ello las posibilidades de personalizacin de las soluciones es an mucho mayor.

Windows Deployment Services

Respecto al despliegue de sistemas, en anteriores versiones de Windows disponamos de la herramienta RIS (Remote Installation Services). Con Windows Server LongHorn, esta herramienta se ha actualizado, denominndose ahora Windows Deployment Services. Se nos presenta como una serie de componentes que podremos utilizar para llevar a efecto con xito un despliegue masivo de equipos. Estos componentes estn organizados en tres categoras:

 Componentes de servidor: Estos incluyen un entorno de pre-arranque (Pre-Boot Execution Environment o PXE) y un TFTP (Trivial File Transfer Protocol), componentes que necesitaremos para poder arrancar un cliente con soporte de red, y posteriormente instalar el sistema operativo. Tambin se incluyen directorios compartidos, repositorio de imgenes y los ficheros necesarios para poder realizar un despliegue. Componentes de cliente: Estos componentes incluyen un interfaz grfico que arranca con el Windows Preinstallation Environment (Windows PE). ste se comunica con el servidor de componentes para poder seleccionar e instalar la imagen del sistema operativo. Componentes de mantenimiento: Son una serie de herramientas que nos ayudarn a mantener el servidor, las imgenes de los sistemas operativos, junto a otras posibilidades. Gracias a esta tecnologa de despliegue podemos mantener e instalar equipos a travs de la red, sin que tengamos que estar fsicamente en el equipo. Al poder automatizar estas tareas, la corporacin gana en tiempo, mejora el mantenimiento y reduce el esfuerzo humano, con las consiguientes ventajas econmicas que ello supone. Si antiguamente, para implantar una oficina de 100 equipos con Windows XP, necesitbamos 3 administradores y 25 CD de instalacin, gracias a estas soluciones, ahorraramos coste humano y dejara de ser una necesidad el disponer de soporte de medios para el almacenamiento de esos sistemas operativos.

Algunas Notas sobre Servicios en Windows Server LongHorn

En el campo de los servicios, Windows Server LongHorn ampla su uso del principio del mnimo privilegio mediante una reduccin, an mayor, de los privilegios y el acceso a los archivos y claves del Registro. Windows Server LongHorn crea una nueva cuenta de grupo, denominada Identificador de seguridad del servicio (SID), la cual es exclusiva de cada servicio. Un servicio puede establecer permisos en todos sus recursos, pero de forma que slo tenga acceso su SID de servicio. Esto impide que los servicios que se ejecutan bajo la misma cuenta de usuario puedan tener acceso si un servicio se ve en peligro. El SID de un servicio lo podemos ver tecleando en el intrprete de comandos o en Windows PowerShell el comando sc showsid seguido del nombre del servicio.Los SID de servicio protegen el acceso a los recursos que son propiedad de un servicio especfico, aunque de manera predeterminada los servicios continan pudiendo acceder a todos los objetos para los que la cuenta de usuario en la que se ejecutan tenga privilegios. Windows Server LongHorn introduce un nuevo tipo de servicio restringido denominado servicio restringido de escritura, que concede un acceso de escritura de servicio slo a aquellos objetos accesibles a su SID de servicio, al grupo Todos y al SID asignado a la sesin de inicio. Para ello se utilizan SID restringidos, un tipo de SID introducido en Windows 2000. Cuando el proceso que abre un objeto es un servicio restringido de escritura, el algoritmo de comprobacin de acceso cambia para que un SID que no se haya sido asignado a un proceso, no se pueda usar para conceder al proceso acceso de escritura a un objeto. Ahora, con Windows Server LongHorn, es ms sencillo que un servicio impida que otros servicios que se ejecutan en la misma cuenta tengan acceso a los objetos que ste servicio crea. En versiones anteriores de Windows, el autor de un objeto es tambin propietario de l, y como propietario del mismo, es capaz de leer y cambiar los permisos de sus objetos, concediendo acceso completo a sus propios objetos. Windows Server LongHorn introduce el nuevo SID de derechos de propietario, el cual, si existe en los permisos de un objeto, puede

limitar los accesos que un propietario tiene a su propio objeto, incluso eliminando el derecho de establecer y consultar los permisos.Cundo el Administrador de control de servicio inicia un proceso que hospeda uno o varios servicios de Windows, ste crea un token de seguridad (que incluye la cuenta de usuario de un proceso, las pertenencias a grupos y los privilegios de seguridad) para el proceso que contiene slo los privilegios necesarios para los servicios del proceso.Si un servicio especifica un privilegio que no est disponible para la cuenta en que se ejecuta, el servicio no se puede iniciar. Si ninguno de los servicios que se ejecutan en un proceso de cuenta de servicio local necesita algn tipo de privilegio, el Administrador de control de servicio elimina dicho privilegio del token de seguridad del proceso. Un cdigo malicioso no podr utilizar los privilegios no solicitados por los servicios que se ejecutan en el proceso. En Windows Server LongHorn, la elevacin de privilegios mediante inyecciones dll o suplantacin de tokens, es todava, si cabe, mucho ms difcil. Mantener el control de los servidores en una corporacin, y que los clientes puedan acceder a los recursos alojados en los servidores en una red, son prioridades fundamentales para los administradores. Partiendo de esta premisa, Windows Server LongHorn actualiza su rea de funcionalidad Internet Information Services 7.0 (IIS 7.0), que nos va a ayudar a los administradores a maximizar el control sobre los accesos a los servidores de red. Windows Server LongHorn ofrece una plataforma unificada para la publicacin web que integra IIS 7.0, ASP .NET, Windows Communication Foundation, Windows Workflow Foundation, y Windows SharePoint Services 3.0. Podemos presentar IIS 7.0 como una de las principales mejoras que se han introducido en esta nueva versin de sistema operativo servidor Windows. Juega un papel clave en la integracin de tecnologas Web. Ayuda a los desarrolladores y administradores a maximizar el control sobre las interfaces de Internet y de red. Para ello hace uso de sus potentes caractersticas, como son la administracin delegada, una seguridad mejorada, un rea de superficie menor para un posible ataque, aplicacin integrada y gestin del rendimiento para servicios web, as como herramientas mejoradas de administracin.Para aquellas empresas que tengan usuarios remotos, Windows Server LongHorn aade una serie de mejoras e innovaciones en los servicios de terminal (Terminal Services Web Access y Terminal Services Gateway). Con ello se facilita la integracin de aplicaciones remotas y locales en los equipos cliente, el acceso a estos mismos programas a travs de un navegador web, y el acceder a terminales y aplicaciones remotas a travs de firewalls. Esta nueva funcionalidad de Terminal Services Web Access ofrece una gran flexibilidad en el acceso a aplicaciones remotas a travs de un navegador web, aceptando una amplia variedad de formas en que el usuario puede hacer uso de los programas desde terminales remotos. Por su parte, Terminal Services Gateway permite al usuario acceder a terminales remotos y a programas de terminales remotos de una manera tipo firewall. Y todo ello sin tener que configurar nada en el cliente. Son otras muchas las novedades y mejoras que incorpora Windows Server LongHorn. Evidentemente no es posible analizarlas ntegramente en un simple artculo. Una mayor flexibilidad a la hora de controlar dominios que se encuentren en localizaciones no seguras, el uso y facilidad de integracin de aplicaciones de negocio junto a otros son claros ejemplos de ello y que por el momento no abordaremos de forma directa en el presente artculo. . Hemos pretendido con estas breves lneas en torno a Windows Server LongHorn realizar un breve acercamiento a alguna de las nuevas caractersticas y funcionalidades del sistema tanto

en el mbito de la seguridad, como en el nivel de aplicacin. Hemos simplemente destacado y mencionado alguna de las muchas innovaciones que hemos considerado de especial inters. En ningn trmino nuestro planteamiento ha sido generar con el presente artculo informacin tcnica de referencia, y bajo esta panormica deben ser asimilados los datos aqu recogidos. Ser necesario que administradores y tcnicos del sistema sigan trabajando y estudiando caractersticas y funcionalidades del nuevo entorno servidor Windows. Pero sin lugar a dudas este nuevo sistema les proporcionar mejores condiciones y herramientas para el correcto desarrollo de sus tareas habituales.

Curso de Redes y Windows 2008 Server

1.4 Componentes IP Claves
Para que los dispositivos se puedan comunicar, los dispositivos emisores necesitan tanto las direcciones IP como las direcciones MAC de los dispositivos destino. Cuando tratan de comunicarse con dispositivos cuyas direcciones IP conocen, deben determinar las direcciones MAC. El conjunto TCP/IP tiene un protocolo, denominado ARP, que puede detectar automticamente la direccin MAC. ARP permite que un equipo descubra la direccin MAC del ordenador que est asociado con una direccin IP. No vamos a ver parmetros de este protocolo pero por ejemplo en una red local con varios equipos tenemos que con el comando ARP nos puede mostrar esta equivalencia de direccin IP <-> direccin fsica. Por ejemplo:

La unidad bsica de transferencia de datos en IP es el paquete IP. El procesamiento de datagramas se lleva a cabo en el software, lo que significa que el contenido y el formato no dependen del hardware. El datagrama se divide en dos componentes principales: el encabezado,

que incluye las direcciones origen y destino, y los datos. Ya lo hemos comentado otras veces la informacin bsicamente se compone en el destinatario por un lado y el contenido...

Funciones del protocolo de resolucin de direcciones

Los protocolos de Capa 3 determinan si los datos se transportan ms all de la capa de red hacia los niveles superiores del modelo OSI. Un paquete de datos debe contener una direccin MAC destino y una direccin IP destino. Si le falta una u otra direccin, los datos no se transportan desde la Capa 3 hacia las capas superiores. De esta manera, las direcciones MAC y las direcciones IP cumplen una funcin de equilibrio mutuo. Una vez que los dispositivos determinan las direcciones IP destino de los dispositivos destino, pueden agregar las direcciones MAC destino a los paquetes de datos. Hay muchas maneras en que los dispositivos pueden determinar las direcciones MAC que se deben agregar a los datos encapsulados. Algunos mantienen tablas que contienen todas las direcciones MAC y direcciones IP de los otros dispositivos que estn conectados a la misma LAN. Estas se denominan tablas de Protocolo de resolucin de direcciones (ARP), y asignan direcciones IP a las direcciones MAC correspondientes. Las tablas ARP son secciones de la memoria RAM, en las cuales la memoria cach se mantiene automticamente en cada uno de los dispositivos. Es raro que se deba efectuar una entrada en la tabla ARP manualmente. Cada ordenador de una red mantiene su propia tabla ARP. Siempre que un dispositivo de red desee enviar datos a travs de una red, usa la informacin que le suministra su tabla ARP. Ya hemos visto antes un ejemplo de cmo ver esta memoria de asignaciones ARP. Cuando un origen determina la direccin IP de un destino, el origen consulta su tabla ARP a fin de ubicar la direccin MAC del destino. Si la fuente ubica una entrada en su tabla (direccin IP destino para direccin MAC destino), enlaza o relaciona la direccin IP con la direccin MAC y la usa para encapsular los datos.

Operacin ARP dentro de una subred

Es la situacin fcil: estamos en la misma red o subred. Si un equipo desea enviar datos a otro debe conocer la direccin IP destino. Si no puede encontrar la direccin MAC del destino en su propia tabla ARP, comienza un proceso denominado peticin ARP. La peticin ARP le permite descubrir la direccin MAC destino.

Un host genera un paquete de peticin ARP y lo enva a todos los dispositivos de la red. Para asegurarse de que todos los dispositivos vean la peticin ARP, el origen usa una direccin de broadcast MAC. La direccin de broadcast de un esquema de direccionamiento MAC tiene F hexadecimales en todas las posiciones. De este modo, una direccin de broadcast MAC tendra el formato FF-FF-FF-FF-FF-FF.) Como los paquetes de peticiones ARP se desplazan en un modo de broadcast, todos los dispositivos de una red local reciben los paquetes y los pasan a la capa de red donde se les realiza un examen ms amplio. Si la direccin IP de un dispositivo concuerda con la direccin IP destino de la peticin ARP, ese dispositivo responde enviando su direccin MAC al origen. Esto se denomina respuesta ARP. Ejemplo: El dispositivo origen 197.15.22.33 pide la direccin MAC del destino con la direccin IP 197.15.22.126, El dispositivo destino 197.15.22.126 recibe la peticin ARP y responde con una respuesta ARP que contiene su direccin MAC. Una vez que el dispositivo origen recibe la respuesta ARP, extrae la direccin MAC del encabezado MAC y actualiza su tabla ARP. Entonces el dispositivo origen puede direccionar los datos correctamente, con la direccin MAC destino y la direccin IP destino. El dispositivo usa esta nueva informacin para ejecutar encapsulamientos de Capa 2 y Capa 3 de los datos antes de enviarlos nuevamente a travs de la red Cuando los datos llegan a destino, la capa de enlace de datos verifica si hay concordancia, elimina el encabezado MAC, y transfiere los datos a la capa de red. La capa de red examina los datos y detecta que la direccin IP concuerda con la direccin IP destino que se transporta en el encabezado IP. La capa de red elimina el encabezado IP y transfiere los datos encapsulados hacia la siguiente capa superior del modelo OSI, la capa de transporte (Capa 4). Este proceso se repite hasta que el resto de los datos parcialmente desencapsulados del paquete llegan a la aplicacin, donde se pueden leer los datos del usuario No est nada mal, no? Acabamos de definir cmo funciona el trfico de una red, pero claro, es una red muy sencilla porque el origen y destino estn en la misma red. Pero para redes que no estn directamente conectadas... que pasa? Cmo descubre la MAC de mi amigo (que tiene el Messenger encendido) y me conecto con l para enviarle un archivo? Ahora veremos cmo realizar los saltos para encontrar estos datos...

Gateway (o pasarela) por defecto

Para que un dispositivo se pueda comunicar con otro dispositivo de la red, debe suministrarle un gateway por defecto. Un gateway por defecto es la direccin IP de la interfaz en el router que se conecta con el segmento de red en el cual se encuentra ubicado el host origen. La direccin IP del gateway por defecto debe encontrarse en el mismo segmento de red que el host origen. Es decir, como hemos dicho antes, el Gateway es la IP de un dispositivo que nos permite conectar con otras redes. Anotacin Al gateway se le llama tambin pasarela o puerta de enlace porque precisamente es el sitio (direccin de un dispositivo) por el que pasaremos para conectaremos con otra red. Si no se ha definido ningn gateway por defecto, la comunicacin slo se puede realizar en el propio segmento de red lgica del dispositivo. Est claro, le decimos que no hay ningn dispositivo que nos conecte con otras redes por lo tanto slo funcionarn las direcciones IP de la

misma red. El ordenador que enva los datos realiza una comparacin entre la direccin IP destino y su propia tabla ARP. Si no encuentra coincidencias, debe tener una direccin IP por defecto que pueda utilizar. Si no hay un gateway por defecto, el ordenador origen no tiene ninguna direccin IP destino y el mensaje no se puede enviar.

Problemas por el envo de datos a nodos de diferentes redes

Uno de los principales problemas de las redes es cmo comunicarse con dispositivos que no se encuentran en el mismo segmento de red fsica. El problema puede dividirse en dos partes. La primera consiste en obtener la direccin MAC del host destino y la segunda consiste en transferir los paquetes de datos de un segmento de red a otro, a fin de obtener el equipo destino. ms que problema es la "grandeza" de nuestro protocolo que sabe cmo encontrar otro equipo en redes separadas a miles de kilmetros, que tiene su mrito...

Cmo ARP enva datos a las redes remotas

ARP utiliza paquetes de broadcast para lograr su funcin. Sin embargo, como hemos dicho en varias ocasiones los routers no envan paquetes de broadcast. Para que un dispositivo enve datos a la direccin MAC de un dispositivo que est ubicado en otro segmento de la red, el dispositivo origen enva los datos a un gateway por defecto. El gateway por defecto es la direccin IP del la interfaz del router conectada al mismo segmento de red fsica que el host origen. El host origen compara la direccin IP destino con su propia direccin IP para determinar si las dos direcciones IP se encuentran ubicadas en el mismo segmento. Si el dispositivo receptor no est ubicado en el mismo segmento, el dispositivo origen enva los datos al gateway por defecto Lee por favor el anterior prrafo otra vez, comprenders cmo se las ingenia para ir encontrando la MAC del destino y es que va utilizando los "gateways" o pasarelas como mtodo de conexin entre las redes... veamos dos esquemas de las preguntas que se hace en los dos casos: si el equipo est en la red local o no:

Destino TCP/IP local:

Destino TCP/IP no local

Protocolo ARP Proxy

El protocolo ARP proxy es una variante del protocolo ARP. En este caso, un dispositivo intermedio (por ej., un router) enva una respuesta ARP, de parte de un nodo final, hacia el host que realiza la peticin. Los routers que ejecutan el protocolo ARP proxy capturan paquetes ARP. Responden enviando sus direcciones MAC a aquellas peticiones en las que la direccin IP no se ubica dentro la gama de las direcciones de la subred local. En la descripcin anterior acerca de cmo se envan los datos a un host que se encuentra en una subred diferente, se configura el gateway por defecto. Si el host origen no tiene configurado un gateway por defecto, enva una peticin ARP. Todos los hosts del segmento, incluyendo el router, reciben la peticin ARP. El router compara la direccin IP destino con la direccin IP de subred para determinar si la direccin IP destino se encuentra en la misma subred que el host origen. Si la direccin de subred es la misma, el router descarta el paquete. El motivo por el cual se descarta el paquete es que la direccin IP destino est en el mismo segmento que la direccin IP origen. Esto significa que otro dispositivo del segmento debe responder a la peticin ARP. La excepcin a esto es que la direccin IP destino no est actualmente asignada, lo que puede generar una respuesta con error en el host origen.

Si la direccin de subred es distinta, el router responder con su propia direccin MAC a la interfaz que se encuentra directamente conectada al segmento en el cual est ubicado el host origen. Este es el protocolo ARP proxy. Dado que la direccin MAC no est disponible para el host destino, el router suministra su direccin MAC para obtener el paquete. Luego el router puede enviar la peticin ARP (basndose en la direccin IP destino) a la subred adecuada para que se realice la entrega

El equipo A le enva una peticin ARP al equipo F. El router procesa y contesta con su direccin MAC para asignarla a la direccin IP de F.

1.5 Protocolos y el enrutamiento

El protocolo Internet (IP) es un protocolo de capa de red, y como tal se puede enrutar a travs de una red. Los protocolos que suministran soporte para la capa de red se denominan protocolos enrutados o enrutables. Recuerda que el enrutamiento es la capacidad de los protocolos de red para localizar redes que estn en otros segmentos.

Otros protocolos enrutados

El enfoque de esta introduccin es concentrarse en el protocolo enrutable ms comnmente utilizado, es decir, protocolo IP. Aunque nos ocuparemos principalmente del protocolo IP, es importante saber que existen otros protocolos enrutables. Otros dos protocolos son IPX/SPX (el antiguo utilizado en las redes Novell) y AppleTalk (de los equipos Apple). Mira este ejemplo de cmo se identifica una red y un equipo con TCP/IP y con Novell IPX:

Tipo General TCP/IP Novell

Red 1 10. 1aceb0b

Nodo 1 8.2.48 (mscara 255.0.0.0 0000.0c00.6e25

Protocolos enrutables y no enrutables

Los protocolos como, por ejemplo, IP, IPX/SPX y AppleTalk suministran soporte de Capa 3 as que son enrutables. Sin embargo, hay protocolos que no soportan Capa 3, que se clasifican como protocolos no enrutables. El ms comn de estos protocolos no enrutables es NetBEUI. NetBEUI es un protocolo pequeo, veloz y eficiente que est limitado a ejecutarse en un segmento. Era el que utilizbamos en las redes de Microsoft antes de establecerse TCP/IP como el estndar.

Caractersticas de un protocolo enrutable

Para que un protocolo sea enrutable debe tener la capacidad de asignar un nmero de red y un nmero de equipo a cada dispositivo (debemos distinguir el equipo y la red). Algunos protocolos como el protocolo IPX (el que utilizaba las redes Novell, un sistema muy extendido antes...), slo necesitan que se le asigne un nmero de red; estos protocolos utilizan una direccin MAC de host como el nmero de host. Otros protocolos como IP, requieren que se suministre una direccin completa y la mscara de red. (La direccin de red se obtiene mediante una operacin AND de la direccin con la mscara de subred) Los protocolos de enrutamiento (ojo, no los confundas con los protocolos enrutables) determinan las rutas que siguen los protocolos enrutados hacia los destinos. Entre los ejemplos de protocolos de enrutamiento tenemos: Protocolo de Informacin de Enrutamiento (RIP) Protocolo de enrutamiento de gateway interior (IGRP) Protocolo de enrutamiento de gateway interior mejorado (EIGRP) Protocolo de primero la ruta libre ms corta (OSPF).

Las caractersticas de estos protocolos las veremos ahora con ms detalle, algunos son mejores y ms eficientes que otros... eso es lo que veremos ahora. Los protocolos de enrutamiento permiten que los routers conectados creen un mapa interno de los dems routers de la red o de Internet. Esto permite que se produzca el enrutamiento: la seleccin de la mejor ruta. Estos mapas forman parte de la tabla de enrutamiento de cada router.

Qu es un protocolo de enrutamiento?
Los routers usan protocolos de enrutamiento para intercambiar tablas de enrutamiento y compartir informacin sobre stas. Dentro de una red, el protocolo ms comn que se usa para transferir la informacin de enrutamiento entre routers ubicados en la misma red, es el Protocolo de informacin de enrutamiento (RIP). Este Protocolo de gateway interior (IGP) calcula las distancias hasta el equipo destino en trminos de cuntos saltos (es decir, cuntos routers) debe atravesar un paquete. El RIP permite que los routers actualicen sus tablas de enrutamiento a

intervalos programables, generalmente cada 30 segundos. Una de las desventajas de los routers que usan RIP es que se conectan constantemente con sus vecinos para actualizar las tablas de enrutamiento, generando as una gran cantidad de trfico de red. Date cuenta que en una red muy grande con muchos routers mantener todas las tablas de rutas de todos sera realmente complejo para el administrador y un error podra dejar zonas de las redes a "oscuras". Por eso existen estos protocolos para que si en un router aado una nueva ruta porque he conectado otra red (por ejemplo otra delegacin) automticamente le va a comunicar estos cambios a los dems routers... El RIP permite que los routers determinen cul es la ruta que se debe usar para enviar los datos. Esto lo hace mediante un concepto denominado vector-distancia. Se contabiliza un salto cada vez que los datos atraviesan un router es decir, pasan por un nuevo nmero de red, esto se considera equivalente a un salto. Una ruta que tiene un nmero de saltos igual a 4 indica que los datos que se transportan por la ruta deben atravesar cuatro routers antes de llegar a su destino final en la red. Si hay mltiples rutas hacia un destino, la ruta con el menor nmero de saltos es la ruta seleccionada por el router. Como el nmero de saltos es la nica mtrica de enrutamiento utilizada por el RIP, no necesariamente selecciona la ruta ms rpida hacia su destino. La mtrica es un sistema de medidas que se utiliza para la toma de decisiones. luego veremos otros protocolos de enrutamiento que utilizan otras mtricas adems del nmero de saltos, para encontrar la mejor ruta a travs de la cual se pueden transportar datos. Sin embargo, RIP contina siendo muy popular y se sigue implementando ampliamente. La principal razn de esto es que fue uno de los primeros protocolos de enrutamiento que se desarrollaron. Otro de los problemas que presenta el uso del RIP es que a veces un destino puede estar ubicado demasiado lejos como para ser alcanzable. RIP permite un lmite mximo de quince para el nmero de saltos a travs de los cuales se pueden enviar datos. La red destino se considera inalcanzable si se encuentra a ms de quince saltos de router. As que resumiendo, el RIP: Es un protocolo de enrutamiento por vector de distancia La nica medida que utiliza (mtrica) es el nmero de saltos El nmero mximo de saltos es de 15 Se actualiza cada 30 segundos No garantiza que la ruta elegida sea la ms rpida Genera mucho trfico con las actualizaciones

Secuencia de encapsulamiento de enrutamiento

En la capa de enlace de datos, el datagrama IP se encapsula en una trama. El datagrama, incluyendo el encabezado IP, se maneja como si fuera datos. El router recibe la trama, elimina el encabezado de la trama, luego verifica la direccin IP destino del encabezado IP. El router luego busca esa direccin destino en la tabla de enrutamiento, encapsula los datos en una trama de capa de enlace de datos y la enva hacia la interfaz correspondiente. Si no encuentra la direccin IP destino, el router descarta el paquete Esto es ya algo mas complejo y no hace falta que tengamos tantos conocimientos pero es una lectura muy interesante para los que queris meteros en el mundo de los servidores que obligatoriamente implica amplios conocimientos de redes.

1.6 Servicios de red orientados o no a conexin

La mayora de los servicios de red usan un sistema de entrega no orientado a conexin. Estos servicios manejan cada paquete por separado y lo envan a travs de la red. Los paquetes pueden tomar distintas rutas para atravesar la red, pero se vuelven a ensamblar cuando llegan a su destino. En un sistema no orientado a conexin, no se hace contacto con el destino antes de que se enve el paquete. Una buena analoga para un sistema de entrega no orientado a conexin es el sistema de correos. No se hace contacto con el destinatario antes de que la carta se enve desde un destino a otro. La carta se enva hacia su destino y el destinatario se entera de su existencia cuando la recibe. Suponemos (Correos mediante) que la carta llega a su destino.

Servicios de red orientados a conexin

En los sistemas orientados a conexin, se establece una conexin entre emisor y receptor antes de que se transfieran los datos. Un ejemplo de una red orientada a conexin es el sistema telefnico. Se hace una llamada, se establece una conexin y luego se produce la comunicacin.

Comparacin de los procesos de red no orientados a conexin y orientados a conexin

Los procesos de redes no orientados a conexin se definen como conmutados por paquetes. En estos procesos, a medida que los paquetes se transportan desde el origen hasta el destino, se pueden pasar a distintas rutas, as como tambin (posiblemente) llegar fuera del orden correcto. Los dispositivos realizan la determinacin de ruta para cada paquete basndose en diversos criterios. Algunos de los criterios como, por ejemplo, el ancho de banda disponible, puede variar de un paquete a otro. Los procesos de red orientados a conexin a menudo se denominan conmutados por circuito. Estos procesos establecen en primer lugar una conexin con el receptor y luego comienza la transferencia de datos. Todos los paquetes se transportan de forma secuencial a travs del mismo circuito fsico, o ms comnmente, a travs del mismo circuito virtual. Internet es una enorme red no orientada a conexin en la cual la entrega de paquetes es manejada por IP. TCP (Capa 4) agrega servicios orientados a conexin en la parte superior de IP (Capa 3). Los segmentos TCP se encapsulan en paquetes IP para ser transportados a travs de Internet. TCP proporciona servicios orientados a conexin para permitir una entrega fiable de los datos

Fjate bien en los dos grficos para que veas la diferencia, en un caso slo utiliza una va de comunicacin y en la otra utiliza varias.

Como agregar rutas estaticas en Centos/ClearOS

Por mas que busque dentro del administracion web de ClearOs no logre encontrar como agregar rutas estaticas a las tablas de ruteo. Segun he leido la ruta especifica se debe de asociar a una interfaz de red (NIC) directamente. Luego la ruta se habilita o deshabilita cuando la interfaz a su vez se enciende o apaga.

Configuracion de eth1
Como ejemplo digamos que necesito configurar la interface de LAN eth1 para que pueda conocer la red 192.168.1.x. Para amarrar esta red necesito configurar una ruta estatica para que las PCs clientes dentro de mi LAN puedan conectarse, para lo cual creamos el archivo /etc/sysconfig/network-scripts/route-eth1, con la siguiente informacion:
192.168.99.0/24 via 192.168.1.100

Luego de guardar el archivo, activamos la ruta al levantar la interfaz de red tecleando desde la terminal el comando:
/sbin/ifup eth1

Si ya existiera el archivo con rutas, tan solo nos desplegara mensajes de error indicando que dichas rutas ya existen. Para cambiar o eliminar una ruta ya definida, es necesario re-cargar la tabla de ruteo:

/sbin/ifdown eth1 /sbin/ifup eth1

Como agregar rutas TcpIP a la tabla de ruteo de Windows

24/01/2011 By fher98 En todo sistema operativo la tabla de rutas es la encargada de dirigir hacia donde deben continuar los paquetes para llegar a su destino. Dichos paquetes al ser enviados por el sistema deben de ser forwardeados hacia un swich o router y luego al ISP hasta el internet. Cuando tenemos un entorno de pruebas o estamos desarrollando una nueva red para una empresa o quizas por el deseo puro por aprender y obtener conocimiento, sera necesario, en media que la red vaya creciendo mas y mas compleja, el agregar a nuestra topologia las rutas adicionales necesarias para la comunicacion de los servicios propios de nuestra internetworking. Para agregar rutas estaticas a nuestra maquina abrimos la consola de Windows o el D.O.S y escribimos;
C:\> route ADD 192.168.1.0 MASK 255.255.255.0 10.0.1.100

Donde,

192.168.1.0 es la red o destino final al cual deseamos conectarnos. 255.255.255.0 es la mascara de la red destino 10.0.1.100 es el host que nos sirve de pasarela de red para conectarnos a las 192.168.1.0.

Como hacer la ruta estatica en Windows permanente

Ahora bien, ya realizamos nuestras pruebas con el ruteo y fueron exitosas. Pero al reiniciar la computadora con windows, esta ruta se pierde. Para configurar la nueva ruta permanentemente y que sea cargada automaticamente cada vez que arranque Windows, le debemos de agregar la bandera -p, de la siguiente manera;
C:\> route -p ADD 192.168.1.0 MASK 255.255.255.0 10.0.1.100

Este comando me ha funcionado como lo he descrito anteriormente en Windows XP, Windows 2003 y 2008 server, en Windows 7 no lo he probado.

Introduccin a la Administracin de una Red Local basada en Internet

1 - El problema
Este trabajo trata fundamentalmente sobre los aspectos "lgicos"de la arquitectura de red. Lo que puede o no puede hacer una red est generalmente determinado por los protocolos que dicha red soporta y la calidad de sus implementaciones, ms que por la tecnologa concreta de red usada, como Ethernet, Token Ring, etc. Adems, en la prctica, la eleccin de la tecnologa de red est basada en decisiones puramente pragmticas: qu tipo de red soporta el tipo de ordenadores que queremos conectar, las distancias entre los equipos, las caractersticas del cableado, etc. Por regla general, se suele usar Ethernet para sistemas de media escala, Ethernet o una red basada en el cableado de par trenzado para pequeas redes, o redes de alta velocidad (tpicamente Token Ring) para la red principal de un campus y para redes de superordenadores, que ejecutan aplicaciones de altas prestaciones. Por tanto, vamos a asumir que hemos llegado a conectar "fsicamenteunas redes individuales, del tipo Ethernet o Token Ring. Ahora nos enfrentamos a los siguientes problemas interrelacionados: ~- configurar el software necesario, ~- conectar las distintas Redes Ethernet, Token Ring, etc, para formar una nica red de forma coherente, ~- conectar las redes al mundo exterior, o sea, Internet. Las anteriores decisiones requieren un pequeo anlisis. De hecho, la mayora de las redes necesitan una arquitectura", que determina la manera en que se asignan las direcciones, cmo se hace el enrutado y otras elecciones, sobre cmo los ordenadores interaccionan con la red. Estas decisiones deben hacerse para la red en su conjunto, preferiblemente cuando se esta procediendo a su instalacin inicial. Terminologa Vamos a usar el trmino IP para referirnos a las redes diseadas para trabajar con TCP/IP. IP es el protocolo a nivel de red de la familia de protocolos TCP/IP, usados en Internet. Es una prctica comn usar el trmino IP cuando nos referimos a direcciones, enrutamiento y otros elementos a nivel de red. La distincin muchas veces no es lo suficientemente clara. As que, en la prctica, los trminos Internet TCP/IP e IP pueden parecer incluso intercambiables. Los trminos paquete y datagrama tambin suelen parecer intercambiables. Conceptualmente, un paquete es la unidad fsica de ms bajo nivel, mientras que datagrama se rere a la unidad de datos a nivel IP. Sin embargo, en la mayora de las redes no se pueden distinguir porque coinciden, as que la gente suele usar los dos trminos indistintamente. Otro trmino conflictivo es el de pasarela (gateway) y enrutador (router). Pasarela es el trmino original usado en Internet. Sin embargo, la comunidad OSI empez a usar esta palabra con un significado distinto, as que la gente empez a usar enrutador para evitar dicha ambiguedad. Nosotros, no obstante, seguiremos usando el trmino gateway.

2 - Asignacin de direcciones y enrutamiento

Muchas de las decisiones que se necesitan para la configuracin de una red IP depende del enrutamiento. En general, un datagrama IP pasa a travs de numerosas redes mientras se desplaza entre el origen y el destino. Veamos un ejemplo tpico: Red 1 Red 2 Red 3 128.6.4 128.6.21 128.121

============================== ========== ==================== ||||||| _| _| || || _| 128.6.4.2 128.6.4.3 128.6.4.1 128.6.21.1 128.121.50.2 128.6.21.2 128.121.50.1 _ ordenador A ordenador B gateway R gateway S ordenador C Este grfico muestra tres ordenadores, 2 gateways y tres redes. Las redes pueden ser Ethernet, Token Ring o de cualquier otro tipo. La red 2 podra ser una lnea punto a punto que conecta los gateways R y S. El ordenador A puede enviar datagramas al B directamente, usando la red 1. Sin embargo, no puede llegar al ordenador C directamente, puesto que no estn en la misma red. Hay varias maneras de conectar redes. En el grfico asumimos el uso de gateways (ms adelante veremos otras alternativas). En este caso, los datagramas que van desde A a C deben ser enviados a travs del gateway R, red 2 y gateway S. Todos los ordenadores que usan TCP/IP necesitan que se les suministre la informacin y algoritmos apropiados para que puedan saber cundo un datagrama debe ser enviado a travs de un gateway, y elegir el gateway apropiado. El enrutado est ntimamente relacionado con la asignacin de direcciones. Podemos apreciar que la direccin de cada ordenador comienza con el nmero de la red a la que pertenece. Por tanto, 128.6.4.2 y 128.6.4.3 se encuentran en la red 128.6.4. Luego los gateways, cuyo trabajo es conectar dos redes, tienen una direccin de ambas redes. Por ejemplo, el gateway R conecta la red 128.6.4 y 128.6.21. Su conexin a la red 128.6.4 tiene la direccin 128.6.4.1. Su conexin a la red 128.6.21 tiene la direccin 128.6.21.2. Debido a esta relacin entre direcciones y redes, las decisiones de enrutado deben basarse estrictamente en el nmero de red de destino. La informacin de enrutamiento del ordenador A tendr el siguiente aspecto: red gateway mtrica -128.6.4 - 0 128.6.21 128.6.4.1 1 128.121 128.6.4.1 2 En esta tabla, el ordenador A puede enviar datagramas a los ordenadores de la red 128.6.4 directamente, y para los datagramas a los ordenadores de las redes 128.6.21 y 128.121 es necesario usar el gateway R. La "mtrica"ser usada por algn tipo de algoritmo de enrutamiento, como medida de la lejana del destinatario. En nuestro caso, la mtrica simplemente indica cuantos diagramas tiene que atravesar para llegar a su destino (conocida como "cuenta de saltos").

Cuando el ordenador A est listo para enviar un datagrama se examina la direccin del destinatario. Comparamos el inicio de dicha direccin de red con las direcciones de la tabla de enrutamiento. Las distintas entradas de la tabla indican si el datagrama debe ser enviado directamente, o a un gateway. Un gateway consiste simplemente en un ordenador conectado a dos redes diferentes, y est habilitado para enviar datagramas entre ellos. En muchos casos es ms eficiente usar un equipo especialmente diseado para desempear el papel de gateway. Sin embargo, es perfectamente posible usar un ordenador, siempre y cuando tenga ms de un interfaz de red y un software capaz de enviar datagramas. Un gateway tiene varias direcciones, una para cada red a la que est conectado. Aqu encontramos una diferencia entre IP y otros protocolos de red: cada interface de un ordenador tiene una direccin. Con otros protocolos, cada ordenador tiene una nica direccin, aplicable a todos sus interfaces. Un gateway entre las redes 128.6.4 y 128.6.21 tendr una direccin que comience por 128.6.4 (por ejemplo, 128.6.4.1). Esta direccin se rere a su conexin a la red 128.6.4. Tambin tendr una direccin que comience con 128.6.21 (por ejemplo, 128.6.21.2). Esta se rere a su conexin a la red 128.6.21. El trmino "red"generalmente se suele identificar a dispositivos del tipo Ethernet, en la cual varias mquinas estn conectadas. Sin embargo, tambin se aplica a lneas punto a punto. En el grfico anterior, las redes 1 y 3 podran estar en ciudades distintas; la red 2 podra ser una lnea serie, un enlace satlite, u otro tipo de conexin punto a punto. Una lnea punto a punto es tratada como una red que consta slo de dos ordenadores. Como cualquier otra red, una lnea punto a punto tiene una direccin de red (en este caso, 128.6.21). Los sistemas conectados por la lnea (gateways R and S) tienen direcciones en dicha red (en este caso, 128.6.21.1 y 128.6.21.2). Es posible disear software que no necesite distintos nmeros de red para cada lnea punto a punto. En este caso, el interface entre el gateway y la lnea punto a punto no tiene una direccin. Esta solucin es apropiada cuando la red es tan grande que peligra el hecho de que nos quedemos sin direcciones. Sin embargo, tales "interfaces annimas"pueden dificultar bastante el manejo de la red. Puesto que no tienen direccin, el software de red no tiene manera de referirse a dicho interface, y, por tanto, no es posible obtener informacin sobre el ujo y los errores de la interface.

3 - Eligiendo una estructura de direcciones

Antes de comenzar a montar una estructura de IP, necesitamos uno o ms nmeros de red oficiales. Una direccin IP tiene un aspecto como el siguiente: 128.6.4.3. Esta direccin slo podr ser usada por un 3. Eligiendo una estructura de direcciones. 5 ordenador de la Universidad de Marx. La primera parte de dicha direccin, 128.6, es un nmero de red asignado a dicha Universidad por una autoridad central. Por tanto, antes de asignar direcciones a nuestros ordenadores, deberemos obtener una direccin oficial de red. Sin embargo, alguna gente configura sus redes usando, o bien una direccin aleatoria o usando una direccin genrica suministrada por defecto en el equipo. Esta forma de trabajar podra funcionar en pequeas redes, pero seguramente no lo har en una mayor. Adems, es posible que quisiramos conectar nuestra red con la red de otra organizacin. Incluso si nuestra organizacin tuviese un gran control de seguridad, es posible que tuviramos un ordenador dedicado a la investigacin que estuviese conectado a una universidad u otra organizacin investigadora. Esta universidad o entidad estara seguramente conectada a una red de nivel nacional. Tan pronto como uno de nuestros datagramas salga de nuestra red local va a provocar un estado de confusin en la organizacin con la que nos comuniquemos, porque la direccin que aparece en nuestros datagramas est probablemente asignada oficialmente a alguien distinto. La solucin es simple: obtener una direccin propia desde el principio. Adems, no cuesta nada. La decisin ms importante que tenemos que hacer para configurar una red es, sin lugar a dudas,

cmo asignar las direcciones IP a los ordenadores. Esta eleccin debe de hacerse desde el punto de vista de cmo nuestra red puede crecer. Si no se hiciese as, es casi seguro que tendremos que cambiar las direcciones en un futuro. Y cuando tengamos varios cientos de ordenadores, cambiar tantas direcciones es casi imposible. Las direcciones son muy importantes porque los datagramas IP son enrutados en base a dicha direccin. Por ejemplo, las direcciones de la Universidad Rutgers tienen una estructura de dos niveles. Una direccin tpica puede ser 128.6.4.3. La direccin 128.6 es la asignada a dicha Universidad. Visto desde el exterior, 128.6 es una simple red. Cualquier datagrama enviado desde el exterior, que comience por 128.6, se dirigir al gateway ms cercano de la Universidad Rutgers. Sin embargo, dentro de Rutgers dividimos el espacio de direcciones en "subredes". Usamos los siguientes 8 bits de direccin para indicar a qu subred pertenece el ordenador. As, 128.6.4.3 pertenece a la subred 128.6.4. Generalmente, las subredes se corresponden con redes "fsicaso reales, por ejemplo una red Ethernet; sin embargo, veremos algunas excepciones ms adelante. Los sistemas dentro de Rutgers, a diferencia de los de fuera, contienen informacin sobre la estructura de subredes de Rutgers. As, una vez que un datagrama para 128.6.4.3 llega a Rutgers, la red de Rutgers lo enrutar hacia la Ethernet, Token Ring o cualquier otro tipo de red del departamento que tiene asignado la subred 128.6.4. Cuando queremos configurar una red, hay varias decisiones de direccionamiento que debemos afrontar: Dividimos nuestro espacio de direcciones? Si lo hacemos, usamos subredes o direcciones de clase C? Cmo debe ser de grande el espacio de direcciones que necesitamos? Debemos subdividir nuestro espacio en direcciones No es absolutamente necesario usar subredes. Hay mecanismos que permiten actuar a un campus o compaa completa como una simple y gran Ethernet, as que no es necesario un enrutamiento interno. Si usamos estas tecnologas, entonces no necesitaremos dividir nuestro espacio de direcciones. En este caso, la nica decisin que tenemos que tomar es la de qu clase de direccin debemos de usar. Sin embargo, recomendamos usar un enfoque de subredes o cualquier otro mtodo de subdividir nuestro espacio de direccin en varias redes: fi En la seccin 6.2. discutiremos que los gateways internos son recomendables para todas las redes, ms all de su simplicidad. fi Incluso si no necesitamos gateways en estos momentos, podemos descubrir que tarde o temprano necesitaremos usarlos. De esta manera, probablemente tiene sentido asignar direcciones como si cada 3. Eligiendo una estructura de direcciones. 6 Ethernet o Token Ring fuera una subred separada. Esto permitir hacer conversiones a subredes reales, si esto es necesario. fi Por razones de mantenimiento, es conveniente tener direcciones cuya estructura corresponda con la estructura de la red. Por ejemplo, si vemos un datagrama extraviado procedente del sistema 128.6.4.3, es de bastante ayuda saber que todas las direcciones que comienzan por 128.6.4 se en cuentran en un determinado edificio. Subredes y mltiples numeros de red Supongamos que estamos convencidos de que es una buena idea imponer alguna estructura en nuestras direcciones. La siguiente cuestin es cul es la ms adecuada. Hay dos enfoques bsicos: subredes y mltiples nmeros de red. Los estndares de Internet especifican el formato de las direcciones. Para las direcciones que comienzan entre 128 y 191 (las ms usadas actualmente), los dos primeros octetos forman el nmero de red; por ejemplo, en 140.3.50.1, 140.3 es el nmero de red. Los nmeros de red estn asignados a una organizacin particular. Qu hacemos con los dos siguientes octetos que le siguen?. Podramos optar por hacer al siguiente octeto un nmero de subred, u otro esquema completamente distinto. Los gateways dentro de nuestra organizacin deben configurarse para conocer qu esquema de divisin de redes estamos usando. Sin embargo, fuera de la organizacin nadie sabr si 140.3.50 es una subred y 140.3.51 es otra; simplemente, fuera se sabe que 140.3 es una organizacin. Desafortunadamente, esta habilidad de aadir una estructura adicional a las direcciones, mediante el uso de subredes, no estaba presente en las especificaciones originales y, por tanto, un software antiguo sera incapaz de trabajar con subredes. Si una parte importante del

software que hemos de usar tiene este problema, entonces no podremos dividir nuestra red en subredes. Algunas organizaciones usan un enfoque distinto. Es posible que una organizacin use varios nmeros de red. En lugar de dividir un simple nmero de red, por ejemplo 140.3, en varias subredes, como de 140.3.1 a 140.3.10, podramos usar 10 nmeros distintos de red. De esta manera haramos una asignacin desde 140.3 hasta 140.12. Todo el software IP sabr que estas direcciones se corresponden con redes distintas. A pesar de que usando nmeros de red distintos todo funciona correctamente dentro de la organizacin, hay dos serias desventajas. L a primera, y menos importante, es que se malgasta un gran espacio de direcciones. Hay solamente sobre unas 16.000 posibles direcciones de clase B. No queremos malgastar diez de ellas en nuestra organizacin, a no ser que sea bastante grande. Esta objeccin es menos seria, porque podramos pedir una direccin C para este propsito y hay sobre 2 millones de direcciones C. El problema ms serio para usar varias direcciones de red, en lugar de subredes, es que sobrecarga las tablas de enrutamiento en el resto de Internet. Como comentamos anteriormente, cuando dividimos nuestro nmero de red en subredes, esta divisin slo es conocida dentro de la organizacin, pero no fuera. Los sistemas externos a la organizacin slo necesitan una entrada en sus tablas para ser capaces de llegar. Por tanto, otras Universidades tienen entradas en sus tablas de enrutamiento para 128.6, similar al nmero de la red de Rutgers. Si usa un rango de redes en lugar de subredes, dicha divisin ser visible en todo Internet. Si usamos los nmeros 128.6 a 128.16, en lugar de 128.6, las otras universidades necesitaran tener una entrada para cada uno de estos nmeros de red en sus tablas de enrutamiento. La mayora de los expertos de TCP/IP recomiendan el uso de subredes, en lugar de mltiples redes. La nica razn para considerar mltiples redes es el uso de un software que no puede manejar subredes. Esto era un problema hace algunos aos, pero actualmente es poco frecuente. Una ltima indicacin sobre subredes: Las subredes deben ser adyacentes". Esto significa que no podemos conectar la subred 128.6.4 con la subred 128.6.5 mediante otra red, como la 128.121. Por ejemplo, Rutgers tiene campus en Simon City y Garfunken City. Es perfectamente posible conectar redes en ciudades distintas que sean subred de 128.6. Sin embargo, en este caso, las lneas entre Simon City y Garfunken City deben ser parte de 128.6. Supongamos que decidimos usar una red regional como la RegionaLnet para comunicarnos 3. Eligiendo una estructura de direcciones. 7 entre dos campus, en lugar de usar su propia lnea. Puesto que RegionaLnet tiene de nmero de red 128.121, los gateways y lneas de serie que usaran empezaran por 128.121. Esto viola las reglas. No est permitido tener gateways o lneas que son parte de 128.121 conectando dos partes de 128.6. As, si queremos usar RegionaLnet entre nuestros dos campus, tendramos que obtener diferentes nmeros de red para los dos campus. (Esta regla es un resultado de las limitaciones de la tecnologa de enrutamiento. Eventualmente podra desarrollarse un software para un gateway para manejar configuraciones cuyas redes no son contiguas). Cmo asignar las subredes o los numeros de red Ahora, una vez decidido si vamos a usar subredes o mltiples nmeros de red, tenemos que asignarlos. Normalmente es bastante fcil. Cada red fsica, ya sea Ethernet o Token Ring, ..., se le asigna un nmero distinto de subred. Sin embargo, existen otras opciones. En algunos casos, puede que tenga sentido asignar varios nmeros de subred a una nica red fsica. En Rutgers hay una nica Ethernet que ocupa tres edificios, usando repetidores. Est claro que a medida que vayamos aadiendo ordenadores a esta Ethernet se ir dividiendo en varias Ethernets separadas. Para evitar tener que cambiar de direcciones cuando esto suceda, hemos asignado tres nmeros de red distintas a esta Ethernet, una por edificio. (Esto podra ser til, incluso, si no hubisemos dividido la Ethernet con el fin de ayudar a localizarlos). Pero, antes de hacer esto, debemos estar muy seguros de que el software de todos los ordenadores puede manejar una red que tiene tres nmeros de red. Esta prctica se ver ms detalladamente en

la seccin 3.4. Tambin hemos de elegir una "mscara de subred", que ser usada por el software del sistema para separar la parte de subred del resto de la direccin. Hasta ahora hemos asumido que los dos primeros octetos son el nmero de red y el siguiente es el nmero de subred. Para las direcciones de clase B, el estndar especifica que los dos primeros octetos pertenecen al nmero de red. Y, por otro lado, tenemos libertad para establecer el lmite del nmero de subred y el resto de la direccin. Es bastante usual utilizar un octeto de nmero de subred, pero no es la nica posibilidad. Veamos de nuevo esta direccin de clase B, 128.6.4.3. Es fcil deducir que, si el tercer octeto es usado como nmero de subred, entonces habr 256 posibles subredes y, en cada subred, habr 256 posibles direcciones. (En realidad es ms acertado decir que disponemos de 254, ya que no es buena idea usar 0 255 como nmeros de subred o direccin). Supongamos que sabemos que nunca vamos a tener ms de 128 ordenadores por subred, pero es probable que necesitemos ms de 256 subredes (por ejemplo, un campus con una gran cantidad de pequeos edificios). En ese caso, podramos establecer 9 bits como nmero de red, dejando 7 bits para el direccionamiento de cada subred. Esta decisin queda plasmada en una mscara de bits, usando unos para los bits usados por los nmeros de red y de subred y ceros para los bits usados para el direccionamiento individual. La mscara de red ms comn es 255.255.255.0. Si elegimos 9 bits para el nmero de subredes y 7 para las direcciones, la mscara de subred sera 255.255.255.128. Generalmente, es posible especificar la mscara de subred como parte de la configuracin del software IP. Los protocolos IP tambin permiten a los ordenadores que enven un mensaje preguntando cul es su mscara de subred. Si nuestra red soporta el envo de estos mensajes, y hay, al menos, un ordenador o gateway de la red que conoce dicha mscara de subred, posiblemente ser innecesario especificarlo en cada uno de los restantes ordenadores. Pero esta posibilidad puede traer muchos problemas. En caso de que nuestra implementacin TCP/IP diera una mscara de subred errnea, se causara una mala configuracin en toda la red. Por lo tanto, es ms seguro poner cada mscara de subred explcitamente en cada sistema. Trabajar con mltiples subredes "virtuales"en una red La mayora del software est desarrollado bajo el supuesto de que cada red local tiene el mismo nmero de subred. Cuando existe un ujo hacia una mquina con un distinto nmero de subred, el software espera encontrar un gateway que pueda dirigirlo hacia esa subred. Veamos detalladamente qu ocurre en este caso. Supongamos que tenemos las subredes 128.6.19 y 128.6.20 en la misma Ethernet. Consideremos las cosas que ocurren desde el punto de vista de un ordenador con direccin 128.6.19.3. Dicho ordenador no tendr problemas para comunicarse con las mquinas de direccin 128.6.19.x. Estas mquinas estn en la misma subred, y nuestro ordenador simplemente deber enviar los datagramas al 128.6.20.2. Puesto que esta direccin indica que est en una subred distinta, la mayora del software esperar encontrar un gateway que haga de puente entre ambas subredes. Por supuesto, no existe un gateway entre las "subredes"128.6.19 y 128.6.20, puesto que estn en la misma Ethernet. De aqu se deduce que tenemos que encontrar una manera de indicarle al software que el 128.6.20 se encuentra realmente en la misma Ethernet. La mayora de las implementaciones TCP/IP pueden manejar ms de una subred en la misma red. Por ejemplo, el Berkeley Unix nos permite hacerlo usando una ligera modificacin del comando usado para definir gateways. Si, por ejemplo, queremos que para pasar de la subred 128.6.19 a la subred 128.6.4 se use el gateway con direccin 128.6.19.1, podemos usar el comando route add 128.6.4.0 128.6.19.1 1 Esto indica que para llegar a la subred 128.6.4 el ujo debe ser enviado a travs del gateway 128.6.19.1. El "1"se rere a la "mtrica de enrutamiento". Si usamos la mtrica "0", estamos diciendo que la subred de destino est en la misma red y, por consiguiente, no se necesita ningn gateway. En nuestro ejemplo, deberemos

usar en el sistema 128.6.19.3 route add 128.6.20.0 128.6.19.1 0 La direccin usada en el lugar de 128.6.19.1 es irrelevante. La mtrica "0"nos informa de que no va a usarse ningn gateway, luego no se usar dicha direccin. Sin embargo, deber ampliarse una direcin legal de la red local. Otra forma de trabajar con mltiples subredes Hay otro modo de manejar varias subredes sobre una red fsica. Este mtodo supone la desconfiguracin de nuestros anfitriones o hosts y, por ello, es potencialmente peligrosa, si no sabemos exactamente lo que estamos haciendo. Sin embargo, puede resultar ms cmodo cuando trabajamos con una gran cantidad de subredes en una red fsica. Un ejemplo de este tipo sera una instalacin que use bridges, y usa subredes simplemente por facilidades de administracin. El truco est en configurar el software de nuestros hosts como si no usasen subredes. As, nuestros hosts no harn ninguna distincin entre las distintas subredes y, por tanto, no habr problemas para trabajar con todas ellas. Ahora, el nico problema es cmo comunicarnos con subredes que no estn en esta red de mltiples subredes. Pero, si nuestros gateways manejan proxy ARP, ellos resolvern este problema por nosotros. Este enfoque est especialmente indicado cuando la misma red contiene mltiples subredes y, particularmente, si se van a aadir algunas ms en un futuro. Desgraciadamente, tiene dos problemas: 1. Si tenemos hosts con mltiples interfaces, deberemos ser muy cuidadosos. En primer lugar, slo debera haber mquinas con un interface en la red con mltiples subredes. Por ejemplo, supongamos que disponemos de una red que consta de varias Ethernets conectadas mediante bridges; no podemos tener una mquina con interfaces en dos de estas Ethernets, pero podemos tener un sistema con un interface en esta red de subredes mltiples y otra en otra subred apartada de sta. En segundo lugar, cualquier mquina con mltiples interfaces deber conocer la verdadera mscara de subred, y necesitar estar informada explcitamente de cules de las subredes estn en la red de mltiples subredes. Estas restricciones son consecuencia de que un sistema con mltiples interfaces tiene que conocer qu interface ha de usar en cada caso. 2. Tambin deberemos prestar atencin a la facilidad ICMP de la mscara de subredes. Esta facilidad permite a los sistemas emitir una consulta para conocer cul es la mscara de subred. Si la mayora de los hosts piensan que la red no est dispuesta en subredes, pero los gateways y los hosts con varias interfaces piensan lo contrario, tenemos aqu un foco potencial de confusin. Si un gateway o hosts con varios interfaces enva una rplica a una ICMP de mscara de red, dando la verdadera mscara de subred, alguno de los restantes hosts puede interceptarlo. La situacin contraria tambin sera posible. Esto significa que tendremos que: fi deshabilitar las rplicas a las ICMP de mscara de subred en todos aquellos sistemas que conocen la mscara real de subred (esto es especialmente fcil si solamente los gateways lo conocen); fi asegurar que nuestros hosts ignoran las rplicas ICMP. A medida que establecemos una mscara de subred explcitamente, se supone que los hosts ignoran los ICMP de mscara de subred, as que deberemos ser capaces de establecer diferentes mscaras en diferentes hosts sin causar ningn problema, siempre y cuando podamos establecer la mscara explcitamente en todos ellos. Sin embargo, existen implementaciones IP que cambiarn su mscara de subred cuando vean una rplica de ICMP de mscara de subred. Mltiples subredes: Consecuencias en el Broadcasting Cuando tenemos ms de una subred en una misma red fsica, hay que tener cuidado respecto a las direcciones de broadcasting. De acuerdo con los ltimos estndares, hay dos formas distintas para que un host de la subred 128.6.20 pueda enviar un broadcast en la red local. Una es usar la direccin 128.6.20.255. La otra es usar la direccin 255.255.255.255. La direccin 128.6.20.255 dice, explcitamente, "todos los hosts de la subred 128.6.20"; la 255.255.255.255 expresa "todos los hosts de mi red local". Normalmente, ambas tienen el mismo efecto. Pero no lo tienen cuando hay varias subredes en una red fsica. Si la red 128.6.19 est en la misma red, tambin recibir el mensaje enviado a 255.255.255.255. Sin embargo, los hosts con nmeros 128.6.19.x no escucharn los mensajes enviados a 128.6.20.255. El resultado es que ah tenemos dos tipos distintos de direcciones de broadcast con dos significados distintos. Esto

conlleva que debemos tener cuidado configurando el software de red, para asegurarnos de que nuestros broadcasting llegan a donde queremos que lo hagan. Eligiendo una clase de direccin Cuando solicitamos un nmero oficial de red se nos preguntar qu clase de nmero de red necesitamos. Las posibles respuestas son A, B y C. La decisin elegida limitar nuestro espacio de direcciones a usar. Las direcciones de clase A ocupan un octeto; las de clase B, dos octetos, y la clase C, tres octetos. Luego, hay ms direcciones de clase C que direcciones de clase A, pero las de clase C no pueden tener muchos hosts. La idea que podemos sacar de lo anterior es que debera haber pocas grandes redes, un nmero moderado de redes de tamao mediano y bastantes pequeas redes. En la siguiente tabla observamos dicha distincin: Clase Rango 1er. octeto red resto direcciones posibles A 1 - 126 p q.r.s 16777214 B 128 - 191 p.q r.s 65534 C 192 - 223 p.q.r s 254 Por ejemplo, la red 10 es de la clase A y por tanto tiene direcciones entre 10.0.0.1 y 10.255.255.254. Esto signfica 2543, que son sobre unos 16 millones de posibles direcciones (realmente, la red 10 tiene algunas direcciones con octetos a cero, as que habr algunas direcciones posibles ms). La red 192.12.88, una 3. Eligiendo una estructura de direcciones. 10 direccin de clase C, tendr sus hosts entre el 192.12.88.1 y el 192.12.88.254 y, por lo tanto, habr 254 posibles hosts. En general, deberemos elegir la clase menor que nos proporcione suficientes direcciones capaces de direccionar nuestra red, con sus posibles futuras ampliaciones. Aquellas organizaciones que usan ordenadores en varios edificios, probablemente necesitarn una direccin de clase B, suponiendo que vamos a usar subredes. (Y si vamos a tratar con distintos nmeros de red, deberamos solicitar varias direcciones de clase C). Las direcciones de clase A, normalmente, slo se usan en grandes redes pblicas y algunas pocas redes de grandes corporaciones. En la asignacin de Direcciones IP, la autoridad mxima es la IANA (Internet Assigned Number Authority). A escala continental, la IANA delega grandes bloques de direcciones IP a los denominados registros regionales, de los que, de momento, existen tres en el mundo: fi El RIPE NCC (RIPE Network Coordination Center) es el registro delegado de Internet a nivel europeo y se encarga, entre otras tareas, de la asignacin de bloques de direcciones IP a los proveedores de servicios Internet en Europa y su rea de inuencia. fi El AP-NIC lleva a cabo la tarea de asignacin de bloques de direcciones IP a los proveedores de la regin del Asia-Pacfico. - El InterNIC se encarga de la asignacin de bloques de direcciones IP a los proveedores de Internet en Amrica del Norte y, de momento, en el resto del mundo. Las organizaciones y usuarios finales han de obtener las direcciones IP necesarias para conectarse a Internet a travs de su proveedor de acceso a Internet, quien a su vez las habr obtenido bien de su proveedor de trnsito, bien del registro regional correspondiente.

4 - Servicios a nivel de red, nombres

Si vamos a tener una red TCP/IP, hay algunas tareas importantes que realizar. Algunas de ellas son simplemente de tipo administrativo. La ms importante es crear un registro central de nombres y direcciones IP. Existen organizaciones que realizan esta labor para toda la red Internet. Si estamos conectados a Internet, el administrador de nuestro sistema necesita registrarse a una de estas organizaciones, para que cualquier demanda por parte de otra institucin sobre nuestros hosts sean dirigidos a nuestros servidores. Queremos mantener una base de datos que contenga la informacin de cada sistema de la red. Como mnimo, necesitaremos el nombre y la direccin IP de cada sistema. Probablemente, el registro central ser el encargado de asignar las direcciones IP. Si nuestra red est estructurada en subredes, o si usamos varios nmeros de clase C, el registro posiblemente asignar los nmeros de red a las nuevas redes o subredes. Pero, habitualmente, se permitir que los propios administradores de los hosts elijan el nombre del host. Sin embargo, el registro debe de, al menos, verificar que

no haya nombres duplicados. Si estamos trabajando con una gran red, puede que sea buena idea delegar algunas de estas tareas a subregistros, posiblemente uno para cada departamento. Se recomienda asignar las direcciones de la forma ms simple: empezando por 1. As, si nuestra red es la 128.6, podramos asignar como 128.6.1 a la primera subred; 128.6.2, a la segunda, etc. La asignacin de direcciones IP para hosts individuales podran empezar por 2. De esta manera reservamos la direccin 1 de cada subred para que sea usada por el gateway correspondiente. Por consiguiente, el primer host de la subred 128.6.4 sera el 128.6.4.2; el siguiente sera 128.6.4.3, y as sucesivamente. Hay una razn bsica para mantener las direcciones tan cortas como sean posibles. Si tenemos una gran organizacin, podramos quedarnos sin nmeros de subred. Si esto ocurriera, y nuestros hosts tienen nmeros de red bajos, podramos asignar otro bit para el direccionamiento de las subredes. Si, por ejemplo, usamos el tercer octeto como nmero de subred, en tanto en cuanto nuestros hosts tengan unos nmeros inferiores a 128, podremos ampliar el nmero de red a 9 bits. As, por ejemplo, la subred 128.6.4 podra dividirse en dos subredes distintas: 128.6.4.0 y 128.6.4.128. Si hubisemos asignado a los hosts nmeros por encima de 128, la divisin habra sido imposible. La asignacin de nombres de los hosts no es tan sistemtica. Pueden ser cualquier expresin compuesta de letras, nmeros y guiones. Es ms seguro que el primer carcter sea una letra. Y, desde el punto de vista de los usuarios, es recomendable que los nombres sean lo ms cortos posibles (incluso hay software que tiene problemas trabajando con nombres ms largos de 16 caracteres). Muchas veces, los departamentos o proyectos eligen un tema o nombre relacionado con ellos. Por ejemplo, las mquinas usadas por los estudiantes de Informtica de Rutgers tienen nombres de bandas de rock: OASIS, BLUR, IRONMAIDEN, SAVOY, etc. Nuestro departamento de Matemticas usa el nombre de famosos matemticos: GAUSS, FERMAT, etc. Si la institucin no tiene ninguna relacin con el mundo exterior, cualquier nombre es adecuado. Si estamos conectados a Internet, nuestra organizacin necesitar un "nombre de dominio"(domain name). Al igual que en el caso del espacio de direcciones IP, la autoridad mxima del espacio de nombres de Internet (DNS, Domain Name System) es la IANA (Internet Assigned Number Authority). La raz del DNS es gestionada por el InterNIC por delegacin de la IANA. Bajo la raz se encuentran los distintos dominios de primer nivel (Top Level Domains o TLD's) gestionados por distintos registros delegados de Internet. Algunos de ellos son: Dominios "especiales"como COM, ORG, NET, EDU,... controlados por InterNIC ( nodo central del Network Internet Center ); y dentro de los dominios nacionales, el dominio ES, correspondiente a Espaa, est delegado a ES-NIC. A diferencia del nmero de red, podremos arreglrnosla sin l si la red est aislada. Si posteriormente lo necesitamos, es fcil de aadir un nombre de dominio. (Recomendamos usar un nmero de red desde el principio, porque cambiar nmeros de red posteriormente puede ser traumtico). Los nombres de dominio, normalmente, terminan en .EDU para las instituciones educativas, .COM, para las compaas, etc. Por ejemplo, la Universidad de Rutgers tiene como nombre de dominio RUTGERS.EDU. El formato de los nombres completos de dominio consiste en un nombre interno, seguido del nombre de dominio de la organizacin. As, si un ordenador es conocido internamente como GAUSS, su nombre completo ser AUSS.RUTGERS.EDU. Si tenemos una gran organizacin, es posible tener subdominios. Por ejemplo, puede que haya un subdominio para cada departamento; esto aadira otro trmino en los nombres. Si, por ejemplo, el departamento de Matem ticas decide crear su subdominio, el anterior ordenador se llamara GAUSS.MATHS.RUTGERS.EDU. Una vez asignado el nombre de dominio, se procede a cambiar los ficheros de configuracin donde aparece la forma completa del nombre. En algunos casos, se pueden usar apodos o nombres cortos, de manera que no ser necesario incluir el nombre completo. Si tenemos ms

de uno o dos sistemas, necesitaremos tener algn mecanismo para tener al da la informacin de los distintos hosts. El software TCP/IP necesita ser capaz de traducir nombres de hosts en direcciones IP. Cuando un usuario intenta conectarse con otro sistema, generalmente se referir a l usando su nombre. El software tendr que traducir el nombre en una direccin IP, para poder abrir la conexin. La mayora del software incluye dos vias para hacer esta traduccin: una tabla esttica o un servidor de nombres. La solucin de la tabla est indicada para pequeas organizaciones, siempre y cuando no estn conectadas a otra red. Simplemente se crea un fichero que lista los nombres y direcciones de todos los hosts. Veamos parte de una tabla de este tipo: HOST: 128.6.4.2, 128.6.25.2: ARAMIS.RUTGERS.EDU, ARAMIS: SUN-3-280: UNIX :: HOST: 128.6.4.3: GAUSS.RUTGERS.EDU, GAUSS: SUN-3-180: UNIX :: HOST: 128.6.4.4, 128.6.25.4: ATHOS.RUTGERS.EDU, ATHOS: SUN-4280: UNIX :: Como se puede apreciar, el formato es el siguiente: una lnea para cada sistema y listar sus direcciones, nombres y otra informacin sobre l. En el ejemplo, tanto ARAMIS como ATHOS estn en dos redes, as que tienen dos direcciones. Adems, ambos tienen un nombre principal, por ejemplo ARAMIS.RUTGERS.EDU, y apodos, por ejemplo ARAMIS. En caso de estar conectados a Internet, el nombre principal ser el nombre de dominio completamente especificado. Se incluyen apodos cortos, para facilitar la tarea a nuestros usuarios. Hay otro formato muy frecuente para las tablas de hosts. Veamos un ejemplo: 128.6.4.2 aramis.rutgers.edu aramis 128.6.25.2 aramis.rutgers.edu aramis 128.5.4.3 gauss.rutgers.edu gauss 128.6.4.4 athos.rutgers.edu athos 128.6.25.4 athos.rutgers.edu athos En este formato, cada lnea representa una direccin IP. Si el sistema tiene dos interfaces, hay dos lneas de l en la tabla. Se debe procurar poner, en primer lugar, aquellas direcciones de uso ms comn. La documentacin de su sistema le informar sobre el formato usado por l. En la configuracin ms simple, cada ordenador tiene su propia copia de la tabla de hosts en /etc/hosts. En caso de elegir esta configuracin, deberemos establecer procedimientos para asegurarnos que todas las copias son actualizadas regularmente. En una red pequea no es difcil mantener una tabla /etc/hosts en cada mquina, y modificarla al agregar, eliminar o modificar nodos. Aunque resulta complicado cuando hay muchas mquinas, ya que, en principio, cada una necesita una copia de /etc/hosts. Una solucin a esto es compartir sta y otras bases de datos con el NIS, o sistema de informacin de red ( Network Information System ), desarrollado por Sun Microsystems y conocido tambin como pginas amarillas o YP. En este caso, las bases de datos como la de /etc/hosts se mantienen en un servidor NIS central y los clientes accedern a ellas de forma transparente al usuario. En todo caso, esta solucin slo es aconsejable para redes pequeas o medianas, ya que implican mantener un fichero central /etc/hosts que puede crecer mucho, y luego distribuirlo entre los servidores NIS. En redes grandes, y todos aquellos que estn conectados a Internet, debemos adoptar un nuevo sistema, el DNS o sistema de nombres por dominios (Domain Name System) diseado por Paul Mockapetris. Tcnicamente, el DNS es una inmensa base de datos distribuda jerrquicamente por toda la Internet; existen infinidad de servidores que interactan entre si para encontrar y facilitar a las aplicaciones clientes que los consultan la traduccin de un nombre a su direccion de red IP asociada, con la que poder efectuar la conexin deseada. Cada parte de la base de datos est replicada en, al menos, dos servidores, lo que asegura una debida redundancia. Un servidor de nombres es un programa que se ejecuta en algunos de nuestros sistemas para tener conocimiento de los nombres. Cuando un programa necesita buscar un nombre, en lugar de hacerlo en una copia de la tabla de host, enva una peticin al servidor de nombres. Este enfoque tiene dos ventajas: fi Para los grandes sistemas, es ms fcil tener al da las tablas en algunos servidores de nombres que en todo el sistema. fi Si nuestra red est conectada a Internet, nuestro servidor de nombres ser capaz de dialogar con los servidores de nombres de otras organizaciones, para buscar nombres de cualquier sitio. Usar un servidor de nombres es el nico camino para tener un acceso completo a la informacin del resto de los hosts de Internet. Es importante comprender la diferencia entre un servidor de nombres y un

resolvedor. Un servidor de nombres es un programa que tiene acceso a una base de datos de hosts, y responde peticiones de otros programas. Un resolvedor es un conjunto de subrutinas que pueden cargarse con un programa. El resolvedor genera las peticiones que se enviarn al servidor de nombres, y procesa sus correspondientes respuestas. Cada sistema debera usar un resolvedor (en general, el resolvedor es cargado por cada programa que va a hacer uso de la red, puesto que slo es un conjunto de subrutinas). Hay que recalcar que slo se necesitarn unos pocos servidores de nombres. Mucha gente confunde los dos enfoques y llega a creer que es necesario tener un servidor de nombres en cada ordenador. Para usar un resolvedor, cada ordenador necesitar un fichero de configuracin, u otro mtodo, para especi ficar la direccin del servidor de nombres al que enviar nuestras peticiones. Por regla general, se pueden declarar varios servidores de nombres, para el caso de que alguno de ellos no funcione correctamente. En el caso de que nuestro sistema no pudiera contactar satisfactoriamente con ningn servidor, la mayora de nuestro software empezara a fallar. Por tanto, hay que ser muy cuidadoso y declarar tantos servidores como podamos para intentar asegurar un buen funcionamiento. Los servidores de nombres, generalmente, tienen un conjunto de opciones para su configuracin. En lugar de dar algunos consejos sobre cmo configurar un servidor de nombres, vamos a recomendar dos documentos oficiales de los estndares de Internet. El RFC 1032 contiene las instrucciones sobre cmo conseguir un nombre de dominio del Centro de Informacin de Red, incluyendo los formularios necesarios. El RFC 1033 contiene las instrucciones sobre cmo configurar un servidor de nombres. Todos estos documentos son de tipo conceptual. Seguramente, tambin necesitar documentacin sobre el software especfico de su servidor de nombres. En algunos casos, puede que se necesiten, a la vez, tablas y servidores de nombres. Si tenemos alguna implementacin de TCP/IP que no incluyan resolvers, estamos obligados a instalar tablas de hosts en estos sistemas. Si nuestra red est conectada a Internet, vamos a tener problemas con aquellos sistemas que no dispongan de resolvers, ya que Internet es demasiado grande para tener unas tablas de hosts de todos sus hosts. Por lo tanto, lo que se puede hacer es incluir una tabla de hosts con los hosts que realmente se tiene pensado usar. InterNIC tiene a su cargo una tabla de host que puede ser un buen punto de comienzo, aunque no es completa de ningn modo. As que tendremos que aadir los hosts favoritos de los usuarios. Los sistemas que usan resolvers no tendrn este problema, puesto que un servidor de nombres es capaz de traducir cualquier nombre legal de host. Los nombres de hosts y la asignacin de nmeros son los nicos elementos que deben de tener una estructura centralizada. Sin embargo, puede haber otros elementos susceptibles de centralizacin. Es bastante frecuente tener uno o dos ordenadores que se hagan cargo de todo el correo electrnico. Si estamos conectados a Internet, es bastante simple establecer comunicaciones con otros ordenadores de Internet. No obstante, hay muchas instituciones que quieren comunicarse con sistemas de otras redes, como Bitnet o Usenet. Hay gateways entre varias de estas redes. Pero la eleccin del gateway correcto, y transformar la direccin de correo electrnico correctamente, es una tarea muy especializada. Por esto, en muchas ocasiones se configura el software apropiado slo en un lugar, y todo el correo externo (o todo el correo externo a hosts que no estn en Internet) se dirige a este sistema.

5 - Configurando el enrutamiento de cada ordenador

Todas las implementaciones TCP/IP necesitan alguna configuracin en cada host. En algunos casos, esto se hace durante la instalacin del sistema de forma casi automtica. En otros casos, mediante la configuracin de ciertos programas o ficheros. Y, por ltimo, otros sistemas obtienen la informacin de configuracin a travs de la red de un "servidor". A pesar de que los detalles de la configuracin pueden diferir bastante, existen ciertos datos que deben incluirse en todos los casos. Entre ellos:

parmetros que describan a una mquina en particular, como su direccin IP; parmetros que describan la red, como su submscara de red (si hubiera); software de enrutamiento y las tablas que use; otros programas necesarios para el funcionamiento de otras tareas de red. Antes de que se instale un ordenador en una red, un coordinador deber asignarle un nombre de red y su direccin IP, como describimos anteriormente. Una vez otorgado un nombre y una direccin estamos en disposicin de configurarlo. En numerosas ocasiones, lo que debemos hacer es poner la direccin y el nombre en un fichero de configuracin. Sin embargo, algunos ordenadores (especialmente aquellos que no disponen de un disco propio en el que dicha informacin pueda ser almacenada) deben obtener esta informacin a travs de la red. En el momento en que un sistema arranca, se realiza un broadcast a la red con la peticin ">quin soy?". En el caso de poseer ordenadores de este tipo, debemos asegurarnos de que nuestra red est preparada para responder adecuadamente. La pregunta lgica es: cmo otro sistema sabe quin eres?. Generalmente, esto se soluciona haciendo uso de las direcciones Ethernet (o las direcciones anlogas para otro tipo de redes). Las direcciones Ethernet son asignadas por los fabricantes hardware. Est garantizado que slo una mquina en todo el mundo tiene una determinada direccin Ethernet. Por lo general, dicha direccin est grabada en una ROM en la tarjeta Ethernet de la mquina. La mquina, probablemente, no conozca su direccin IP, pero sin duda conoce su direccin Ethernet. Por esta razn, la peticin ">quin soy?"incluye la direccin Ethernet. Y habr sistemas configurados para responder a estas peticiones, buscando en una tabla que hace corresponder a cada direccin Ethernet su direccin IP. Pero, por desgracia, deberemos configurar y actualizar esta tabla periodicamente. Para este fin se usa el protocolo de RARP (Reverse Address Resolution Protocol); existe adems otro protocolo, el BOOTP o protocolo de arranque. En general, los ordenadores estn diseados de tal manera que muestran su direccin Ethernet por pantalla, tan pronto como se enciende el mismo. Y, en la mayora de los casos, disponemos de un comando que muestra esta informacin del interfaz Ethernet. Generalmente, la mscara de subred debe especificarse en un determinado archivo (en los sistemas Unix, el comando ifconfig , donde "if"significa interface, se usa para especificar tanto la direccin Internet como la mscara de subred). No obstante, hay previsiones en los protocolos IP para permitir un broadcast de un ordenador, preguntando por la mscara de red. La submscara de red es un atributo de la red y, por ello, es el mismo para todos los ordenadores de una determinada subred. No hay una tabla de subred independiente de la tabla de las correspondencias Ethernet/Internet, usada para consulta de direcciones. Idealmente, slo determinados ordenadores contestan peticiones de la mscara de red, pero, en muchas implementaciones TCP/IP, estn diseadas de tal manera que si un ordenador cree conocer la mscara de red debe contestar, y, por tanto, en estas implementaciones, la mala configuracin de la mscara de subred en un solo ordenador puede causar un mal funcionamiento de la red. Por regla general, los ficheros de configuracin hacen, a grosso modo, las siguientes cosas: fi Cargar un driver especial para los dispositivos que sean necesarios (esto es bastante usual en los PC's, donde los accesos a red son controlados por una tarjeta controladora y un software que no forma parte del sistema operativo). - Habilitar cada interfaz de red (Ethernet, lneas serie, etc.). Normalmente, esto conlleva la especificacin de una direccin Internet y una mscara de red para cada uno, as como otras opciones especiales de cada dispositivo. - Establecimiento de la informacin de enrutamiento de la red, tanto por comandos que establecen rutas, como ejecucando un programa que las obtiene dinmicamente. - Activar el sistema de dominios (usado para buscar nombres y encontrar la correspondiente direccin Internet -mirar la seccin del sistema de dominio, en la Introduccin al TCP/IP-). Los detalles depender n del sistema de dominios usado. En la mayora de los casos, slo algunos hosts debern ejecutar el servidor de nombres de dominios. Los otros hosts, simplemente,

necesitan ficheros de configuracin, que especifican dnde se encuentra el servidor ms cercano. - Establecer otro tipo de informacin necesaria para el sistema software, como, por ejemplo, el nombre del propio sistema. - Lanzar varios demonios (daemons). Hay programas que proveen de servicios de red a otros sistemas de la red, y a los usuarios de estos sistemas. En el caso de los PC's, que en muchos casos no soportan el multiproceso, y dichos servicios, se establecen mediante los llamados "TSR", o mediante los drivers del dispositivo. Como enrutar los datagramas Si nuestro sistema consiste en una simple Ethernet, o un medio similar, no ser necesario prestar demasiada atencin al enrutamiento. Pero, para sistemas ms complejos, cada una de las mquinas necesita una tabla que contenga el gateway y el interfaz necesario para cada posible destino. Vimos un ejemplo simple en una seccin anterior, pero ahora es necesario describir el modo como funciona el enrutamiento, con un poco ms de detalle. En la inmensa mayora de los sistemas, la tabla de enrutamiento tendr un aspecto similar (este ejemplo ha sido tomado de un sistema con Berkeley Unix, usando el comando "netstat -n -r" ; algunas columnas que contienen informacin estadstica han sido omitidas): Destino Gateway Bandera Interface 128.6.5.3 128.6.7.1 UHGD il0 128.6.5.21 128.6.7.1 UHGD il0 127.0.0.1 127.0.0.1 UH lo0 128.6.4 128.6.4.61 U pe0 128.6.6 128.6.7.26 U il0 128.6.7 128.6.7.26 U il0 128.6.2 128.6.7.1 UG il0 10 128.6.4.27 UG pe0 128.121 128.6.4.27 UG pe0 default 128.6.4.27 UG pe0 El sistema del ejemplo est conectado a dos Ethernet: Controlador Red Direccion Otras Redes il0 128.6.7 128.6.7.26 128.6.6 pe0 128.6.4 128.6.4.61 ninguna La primera columna muestra el nombre de la interface Ethernet; la segunda, es el nmero de red para esa Ethernet; la tercera columna es la direccin Internet de esa red, y, la ltima muestra otras subredes que comparten la misma red fsica. Estudiemos la tabla de enrutamiento; por el momento, ignoraremos las tres primeras lneas. La mayor parte de la tabla consiste en un conjunto de entradas describiendo las redes. Para cada red, las otras tres columnas muestran a dnde deben ser enviados los datagramas destinados a dicha red. Si aparece la bandera "G"en la tercera columna, los datagramas tienen que enviarse a travs de un gateway; en caso de no aparecer, el ordenador est directamente conectado a la red en cuestin. As que los datagramas para dichas redes deben enviarse usando el controlador especificado en la cuarta columna. La bandera U", de la tercera columna, slo indica que la ruta especificada por esa lnea est activa (generalmente, se asume que estar abierta, a no ser que se produzcan errores tras varios intentos). Las tres primera lneas muestran "rutas a hosts", indicndose con "H"en la tercera columna. Las tablas de enrutamiento, normalmente, tienen entradas para redes o subredes. Por ejemplo, la entrada 128.6.2 128.6.7.1 UG il0 indica que un datagrama para cualquier ordenador de la red 128.6.2 (es decir, direcciones desde 128.6.2.1hasta 128.6.2.254) debe enviarse al gateway 128.6.7.1, para llevarlo a cabo. En algunas ocasiones, se establecen rutas para un ordenador especfico, en lugar de una red entera. En este caso, se usa una ruta al host. En la primera columna aparece una direccin completa, y la bandera "H"est presente en la columna tres; por ejemplo, la entrada 128.6.5.21 128.6.7.1 UHGD il0 indica que un datagrama, dirigido en concreto a la direccin 128.6.5.21, debe ser enviado al gateway 128.6.7.1. Al igual que en los enrutamientos a redes, la bandera "G"se usa cuando en el enrutamiento se ve involucrado un gateway, y la bandera "D"indica que el enrutamiento fue aadido dinmicamente, usando un mensaje ICMP de redireccin desde un gateway (ms adelante daremos ms detalles). El siguiente enrutamiento es especial: 5. Configurando el enrutamiento de cada ordenador 19 127.0.0.1 127.0.0.1 UH lo0 donde, 127.0.0.1 es el dispositivo de "lazo cerrado", o loopback. Cualquier datagrama enviado a travs de este dispositivo aparece inmediatamente como

entrada. Es muy til para hacer pruebas. Las direcciones de "lazo cerrado"pueden, tambin, ser usadas para comunicar aplicaciones que estn en el propio ordenador. (>Por qu molestarnos en usar la red para comunicarnos con programas que se encuentran en la misma mquina?). Por ltimo, hay una ruta por defecto ("default"), como es default 128.6.4.27 UG pe0 Esta ruta ser seguida por aquellos datagramas que no se correspondan con ninguna de las anteriores. En nuestro ejemplo, se enviarn a un gateway de direccin 128.6.4.27. Como ltimo ejemplo veamos la tabla de enrutamiento de un sistema Linux conectado a Internet mediante una linea PPP, usando el comando "netstat -n -r"; algunas columnas que contienen informacin estadstica han sido omitidas. Destino Gateway Bandera Interface 172.16.1.33 0.0.0.0 UH ppp0 128.0.0.1 0.0.0.0 U l0 0.0.0.0 172.16.1.33 UG ppp0 Hay que aclarar que 0.0.0.0 representa al enrutamiento por defecto, es el valor numrico de default. En este ejemplo, al sistema se le ha asignado la direccin IP 172.16.1.3 de forma dinmica, de manera que usa la linea PPP para conectarse con Internet, y 127.0.0.1 es el dispositivo loopback. Antes de la conexin PPP solamente estaba activo el dispositivo de "lazo cerrado", pero una vez establecida la conexin PPP se activa el interface ppp0 ( 0 indica un identificativo de interface ppp; es decir, si hubiera otra lnea ppp se etiquetara como ppp1, etc), se usa el sistema del otro lado de la linea como un gateway por defecto, como se puede apreciar en la ltima linea. En muchos sistemas, los datagramas son enrutados consultando la direcin de destino en una tabla como la que acabamos de describir. Si la direccin se corresponde con una ruta especfica a un host, sta ser usada; en otro caso, si se corresponde con un enrutamiento a red, se usar sta; y, si nada de lo anterior acontece, se usar el enrutamiento por defecto. En caso de no existir uno por defecto, aparecera un mensaje de tipo "red inalcanzable"("network is unreachable"). En las siguientes secciones describiremos varias maneras de configurar estas tablas de enrutamiento. Generalmente, la operacin de enviar datagramas no depende del mtodo usado en la configuracin de estas tablas. Cuando un datagrama va a ser enviado, su destino es consultado en la tabla. Los distintos mtodos de enrutamiento son simplemente, ms o menos, una serie de sofisticadas formas de configurar y mantener las tablas. Rutas fijas La forma ms fcil de configurar el enrutamiento es usar comandos que lo fijan. Nuestros archivos de inicializacin contienen comandos que configuran el enrutamiento. Si es necesario algn cambio, deber hacerse, normalmente, usando comandos que aaden y borran entradas de la tabla de enrutamiento (cuando se realice un cambio, no debemos olvidar actualizar el fichero de inicializacin tambin). Este mtodo es prctico para redes relativamente pequeas, especialmente cuando los cambios no son muy frecuentes. Muchos ordenadores configuran automticamente algunas entradas de enrutamiento por nosotros. Unix aade una entrada para las redes a las que estamos directamente conectados. Por ejemplo, un fichero de inicializacin podra ser ifconfig ie0 128.6.4.4 netmask 255.255.255.0 ifconfig ie1 128.6.5.35 netmask 255.255.255.0 Este especifica que hay dos interfaces de red y sus direcciones en ellas. El sistema crea automticamente estas entradas en la tabla de enrutamiento 128.6.4 128.6.4.4 U ie0 128.6.5 128.6.5.35 U ie1 y, en sta, se especifica que los datagramas para las redes locales 128.6.4 y 128.6.5 deben ser enviados a las corespondientes interfaces. Adems de stos, el fichero de inicializacin podra contener comandos para definir rutas a cualquier otra red a la que queramos acceder. Por ejemplo, route add 128.6.2.0 128.6.4.1 1 route add 128.6.6.0 128.6.5.35 0 Estos comandos determinan que para alcanzar la red 128.6.2 debemos usar el gateway de direccin 128.6.5.1, y esa red 128.6.6 es, realmente, un nmero de red adicional para una red fsica conectada al interface 128.6.5.35. Otro tipo de software puede usar comandos distintos a estos casos. Unix se diferencia de ellos por el uso de una mtrica, que es el nmero final del comando. La mtrica indica cuntos gateways tiene que atravesar un datagrama para alcanzar su destino. Rutas de mtrica 1 ms indican que hay en el camino slo un gateway hasta el destino. Rutas de mtrica 0 indican que no hay ningn gateway implicado -es un nmero de red adicional para la red local-. En ltimo lugar, podemos definir un enrutamiento por defecto, usado cuando el

destino no est listado explcitamente. Normalmente, se suele acompaar de la direccin de un gateway que tiene suficiente informaci n como para manejar todos los posibles destinos. Si nuestra red slo dispone de un gateway, entonces slo necesitaremos una sola entrada por defecto. En este caso, no deberemos preocuparnos ms de la configuracin del enrutamiento de los hosts (el gateway, en s, necesitar ms atencin, como veremos). Las siguientes secciones nos ayudarn para configurar redes donde hay varios gateways. Reconducir el enrutamiento La mayora de los expertos recomiendan dejar las decisiones de enrutamiento a los gateways. Por tanto, probablemente, ser una mala idea tener largas tablas estticas de enrutamiento en cada ordenador. El problema est en que cuando algo cambia en la red tenemos que actualizar las tablas en demasiados ordenadores. Si el cambio ocurre debido a que cae una lnea, el servicio no se restablecer hasta que alguien se de cuenta del problema y cambie todas las tablas de enrutamiento. La manera ms fcil de tener actualizado el enrutamiento es depender slo de un nico gateway y actualizar su tabla de enrutamiento. Este gateway debe fijarse como gateway por defecto. (En Unix esto significa usar un comando como "route add default 128.6.4.27 1", donde 128.6.4.27 es la direccin del gateway). Como describimos anteriormente, el sistema enviar todos aquellos datagramas a dicho gateway cuando no haya una ruta mejor. En principio, parece que esta estrategia no es demasiado buena cuando poseemos ms de un gateway; mxime, cuando todo lo que tenemos es slo la entrada por defecto. >Cmo usaremos los otros gateways en los casos en los que stos sean ms recomendables? La respuesta es que los datagramas correspondientes sern redirigidos a estos gateways en estos casos. Un "redireccionamiento"es una clase especfica de mensaje ICMP (Internet Control Message Protocol), que contiene informacin del tipo "En el futuro, para llegar a la direccin XXXXX, intenta usar YYYYY en lugar de m". Las implementaciones 5. Configurando el enrutamiento de cada ordenador 21 que cumplen completamente los protocolos TCP/IP usan estas tcnicas de redireccionamiento para aadir entradas a las tablas de enrutamiento. Supongamos que una tabla inicialmente es como sigue: Destino Gateway Bandera Interface + + | 127.0.0.1 | 127.0.0.1 | UH | lo0 | + --+ --+ + --+ | 128.6.4 | 128.6.4.61 | U | pe0 | + --+ --+ + --+ | default | 128.6.4.27 | UG | pe0 | + + donde hay una entrada para la red local 128.6.4, y una entrada por defecto del gateway 128.6.4.27. Supongamos que hay tambin un gateway 128.6.4.30, que es el mejor camino para acceder a la red 128.6.7. >Cmo podemos llegar a usar este camino? Supongamos que tenemos unos datagramas para enviar a 128.6.7.23. El primer datagrama llegar al gateway por defecto, puesto que es el nico que aparece en la tabla de enrutamiento, y el gateway se dar cuenta de que el mejor camino debe pasar por 128.6.4.30 (Hay distintos mtodos para que un gateway determine que debe usarse otro para un mejor enrutamiento). Por tanto, 128.6.4.27 contestar con un mensaje de redireccionamiento especificando que los

datagramas para 128.6.7.23 deben enviarse a travs del gateway 128.6.4.30. El software TCP/IP aadir una entrada a la tabla de enrutamiento 128.6.7.23 128.6.4.30 UDHG pe0 De esta manera, los restantes datagramas al 128.6.7.23 se enviarn directamente al gateway apropiado. Esta estrategia sera perfecta si no fuera por los siguientes tres problemas: fi Necesita que cada ordenador contenga la direccin de un gateway por defecto en los ficheros de confi- guracin. fi En caso de que un gateway falle, las entradas de las tablas de enrutamiento que usan dicho gateway no se eliminan. fi Si la red usa subredes y la implementacin TCP/IP usada no las maneja, esta estrategia no podr emplearse. El alcance del problema depende del tipo de red de la que disponemos. Para redes pequeas, apenas supondr un problema cambiar los ficheros de configuracin de algunas mquinas. Sin embargo, para algunas organizaciones este trabajo es difcil de llevar a cabo. Si, por ejemplo, la topologa de la red cambia y un gateway es eliminado, cualquier sistema que tenga dicho gateway por defecto deber ser ajustado. Este problema ser especialmente grave si el personal encargado del mantenimiento de la red es distinto del encargado de mantener a los sistemas individualmewnte. La solucin ms simple consiste en asegurarnos de que la direccin por defecto nunca cambiar. Por ejemplo, podramos adoptar el convenio de que la direccin 1 de cada subred se corresponde con el gateway por defecto de cada subred; as, en la subred 128.6.7, el gateway por defecto sera siempre el 128.6.7.1. Si dicho gateway es eliminado, habr que asignarle dicha direccin a algn otro gateway (siempre tendr que haber, al menos, un gateway, puesto que si no es as estaremos completamente incomunicados). Hasta ahora hemos visto cmo aadir rutas, pero no cmo deshacernos de ellas. >Qu ocurre si un gateway no funciona correctamente?. Nuestro deseo sera que se recondujera a un gateway operativo, pero desgraciadamente, un gateway en mal funcionamiento no tendr en general esta capacidad de redireccionamiento. La solucin ms obvia es usar gateways bles. El redireccionamiento puede usarse para controlar distintos tipos de fallos. La mejor estrategia para controlar gateways averiados es que nuestra implementacin TCP/IP detecte las rutas que no tienen xito. TCP mantiene varios contadores que permiten al software detectar cundo una conexin se ha roto. Cuando esto ocurre, se puede marcar esta ruta como fallida y volver al gateway por defecto. Una solucin similar puede usarse para manejar fallos en el gateway por defecto. Si configuramos dos gateways

6 - Puentes y gateways
En esta seccin vamos a tratar con ms detalle la tecnologa usada para construir grandes redes. Vamos a centrarnos especialmente en cmo conectar varias Ethernet, token rings, etc. Hoy da la mayora de las redes son jerrquicas. Los hosts estn includos en una red de rea local, como una Ethernet o un token ring. Estas redes se conectan entre s mediante alguna combinacin de redes principales o enlaces punto a punto. Una universidad puede tener una red como se muestra, en parte, a continuacin: | red 1 red 2 red 3 | red 4 red 5 6. Puentes y gateways 29 | X X -- | --- | | | | | | Edificio A | | | | |

-X --X --X | | red principal del campus : | : lnea : serie : -X -- red 6 Las redes 1, 2 y 3 estn en un edificio. Las redes 4 y 5 estn en edificios distintos del campus. La red 6 puede estar en una localizacin ms distante. El diagrama anterior nos muestra que las redes 1, 2 y 3 estn conectadas directamente, y los mecanismos que manejan las conexiones se marcan con "X". El edificio A est conectado a otros edificios en el mismo campus por una red principal. El trfico desde la red 1 a la red 5 tomar el siguiente camino: fi de 1 a 2 a travs de la conexin entre estas redes; fi de 2 a 3 a travs de su conexin directa; fi de 3 a la red principal; fi a travs de la red principal, desde el edificio A al edificio donde la red 5 est emplazada; fi de la red principal a la red 5. El trfico hacia la red 6 debera pasar adicionalmente a travs de la lnea serie. Con la misma configuracin, se usara la misma conexin para conectar la red 5 con la red principal y con la lnea serie. As, el trfico de la red 5 a la red 6 no necesita pasar a travs de la red principal, al existir esa conexin directa entre la red 5 y la lnea serie. En esta seccin vamos a ver qu son realmente estas conexiones marcadas con "x". Diseos alternativos Hay que hacer constar que hay distintos diseos alternativos al mostrado anteriormente. Uno de ellos es usar lneas punto a punto entre los hosts, y otro puede ser usar una tecnologa de red a un nivel capaz de manejar tanto redes locales como redes de larga distancia. Una red de lneas punto a punto En lugar de conectar los hosts a una red local como una Ethernet, y luego conectar dichas Ethernets, es posible conectar directamente los ordenadores a travs de lneas serie de largo alcance. Si nuestra red consiste primordialmente en un conjunto de ordenadores situados en localizaciones distintas, esta opcin tiene sentido. Veamos un pequeo diseo de este tipo: ordenador 1 ordenador 2 ordenador 3 | | | | | | | | | ordenador 4 ordenador 5 -- ordenador 6 En el primer diseo, la tarea de enrutamiento de los datagramas a travs de red era realizada por unos mecanismos de propsito especfico que marcbamos con "x". Si hay lneas que conectan directamente un par de hosts, los propios hosts harn esta labor de enrutamiento, al mismo tiempo que realizan sus actividades normales. A no ser que haya lneas que comuniquen directamente todos los hosts, algunos sistemas tendrn que manejar un trfico destinado a otros. Por ejemplo, en nuestro diseo, el trfico de 1 a 3 deber pasar a travs de 4, 5 y 6. Esto es perfectamente posible, ya que la inmensa mayora de las implementaciones TCP/IP son capaces de reenviar datagramas. En redes de este tipo podemos pensar que los propios hosts actan como gateways. Y, por tanto, deberamos configurar el software de enrutamiento de los hosts como si se tratase de un gateway. Este tipo de configuraciones no es tan comn como podra pensarse en un principio debido, principalmente, a estas dos razones: fi la mayora de las grandes redes tienen ms de un ordenador por localizacin. En estos casos es menos caro establecer una red local en cada localizacin que establecer lneas punto a punto entre todos los ordenadores; fi las unidades de propsito especial para conectar redes son ms baratas, lo que hace que sea ms lgico descargar las tareas de enrutamiento y comunicaciones a estas unidades. Por supuesto, es factible tener una red que mezcle los dos tipos de tecnologas. As, las localizaciones con ms equipos podra manejarse usando un esquema jerrquico, con redes de rea local conectadas por este tipo de unidades, mientras que las localizaciones

lejanas con un slo ordenador podran conectarse mediante lneas punto a punto. En este caso, el software de enrutamiento usado en los ordenadores lejanos deber ser compatible con el usado por las unidades conmutadoras, o bien tendr que haber un gateway entre las dos partes de la red. Las decisiones de este tipo generalmente se toman tras estudiar el nivel de trfico de la red, la complejidad de la red, la calidad del software de enrutamiento de los hosts y la habilidad de los hosts para hacer un trabajo extra con el trfico de la red. Tecnologa de los circutos de conmutacin Otro enfoque alternativo al esquema jerrquico LAN/red principal es usar circutos conmutadores en cada ordenador. Realmente, estamos hablando de una variante de la tcnica de las lneas punto a punto, donde ahora el circuto conmutador permite tener a cada sistema aparentar que tiene lnea directa con los restantes. Esta tecnologa no es usada por la mayora de la comunidad TCP/IP debido a que los protocolos TCP/IP suponen que el nivel ms bajo trabaja con datagramas aislados. Cuando se requiere una conexin continuada, el nivel superior de red la implementa usando datagramas. Esta tecnologa orientada al datagrama no coincide con este sistema orientado a los circutos de forma directa. Para poder usar esta tecnologa de circutos conmutadores, el software IP debe modificarse para ser posible construir circutos virtuales de forma adecuada. Cuando hay un datagrama para un destino concreto se debe abrir un circuto virtual, que se cerrar cuando no haya trfico para dicho destino por un tiempo. Un ejemplo de este enfoque es la DDN (Defense Data Network). El protocolo principal de esta red es el X.25. Esta red parece desde fuera una red distribuda X.25. El software TCP/IP trata de manejar la DDN mediante el uso de canales virtuales. Tcnicas similares podran usarse con otras tecnologas de circutos de conmutacin, como, por ejemplo, ATT's DataKit, aunque no hay demasiado software disponible para llevarlo a cabo. Redes de un slo nivel En algunos casos, los adelantos en el campo de las redes de larga distancia pueden sustituir el uso de redes jerrquicas. Muchas de las redes jerrquicas fueron configuradas as para permitir el uso de tecnologas tipo Ethernet y otras LAN, las cules no pueden extenderse para cubrir ms de un campus. As que era mecesario el uso de lneas serie para conectar las distintas LANs de varios lugares. Sin embargo, ahora hay tecnologas de caractersticas similares a Ethernet, pero que pueden abarcar ms de un campus y, por tanto, pensar en una sola red de larga distancia que no hace uso de una estructura jerrquica. Las principales limitaciones de este tipo de redes son cuestiones de rendimiento y flexibilidad. Si una sola red es usada por todo el campus es muy fcil que se sobrecargue. Las redes jerrquicas pueden manejar un volumen de trabajo mucho mayor que las redes de un solo nivel. Adems, el trfico dentro de los departamentos tiende a ser mayor que el trfico entre departamentos. Veamos un ejemplo concreto. Sumpongamos que hay diez departamentos, cada uno de los cuales genera 1 Mbit/seg de trfico. Supongamos que el 90% del trfico se realiza entre sistemas del mismo departamento y el 10% restante hacia los dems departamentos. Si cada departamento tiene su propa red, stas deberan ser capaces de manejar 1 Mbit/seg, al igual que la red principal que las maneja, para poder posibilitar el 10% que cada departamento destina a otros departamentos. Para resolver la misma situacin con una red de un solo nivel, puesto que debe manejar simultneamente los diez departamentos, se resuelve con una red que soporte 10 Mbit/seg. Est claro que el ejemplo anterior est pensado para que el sistema jerrquico sea ventajoso o, al menos, que sea ms fcil de llevar a cabo. Si el trfico destinado a los otros departamentos fuese mayor, el ancho de banda de la red principal deber ser mayor. Por ejemplo, si en un campus hay algunos recursos centraliza dos, como mainframes u otros grandes sistemas en un centro de clculo. Si la mayora del trfico procede de pequeos sistemas que intentan comunicarse con el sistema central, entonces el argumento anterior no es vlido. Aunque un enfoque jerrquico puede que todava sea til, sin embargo no reduce el ancho de banda requerido. Siguiendo con el ejemplo dado, si los diez departamentos se

comunicasen primordialmente con los sistemas del ordenador central, la red principal deber ser capaz de manejar 10 Mbit/seg. El ordenador central debera de conectarse directamente a la red principal, o tener una red "departamental"con una capacidad de 10 Mbist/seg, en lugar de los 1 Mbit/seg de los otros departamentos. La segunda limitacin se refieren a consideraciones respecto a la fiabilidad, mantenibilidad y seguridad. Las redes de rea amplia son ms difciles de diagnosticar y mantener que las redes de rea local, porque los problemas pueden localizarse en el edificio donde la red se ubica. Adems, hacen que el trfico sea ms fcil de controlar. Por estas razones es ms lgico manejar un trfico local dentro del edificio y usar las redes de rea amplia slo para el trfico entre edificios. No obstante, si se da el caso de que en cada localizacin hay slo uno o dos ordenadores, no tiene sentido montar una red local en cada lugar y s usar una red de un solo nivel. Diseos mixtos En la prctica, pocas redes se permiten el lujo de adoptar un diseo tericamente puro. Es poco probable que una red grande sea capaz de evitar el uso de un diseo jerrquico. Supongamos que la configuramos como una red de un solo nivel. Incluso si la mayora de los edificios tienen slo uno o dos ordenadores, habr alguna localizacin donde haya bastantes ordenadores para justificar el uso de una red local. El resultado es una mezcla entre una red de un solo nivel y una red jerrquica. En la mayora de los edificios sus ordenadores estn conectados directamente a una red de rea amplia, como una red de un solo nivel, pero en un edificio hay una red de rea local usando su red de rea amplia como red principal, a la cul se conecta a travs de unidades conmutadoras. Por otro lado, incluso los diseadores de redes que defienden el uso de una enfoque jerrquico, en muchas ocasiones encuentran partes de redes donde simplemente no resulta econmico instalar una red de rea local, as que algunos hosts se enganchan directamente a la red principal, o bien se usa una lnea serie. Adems de las razones econmicas de la instalacin en s, hay que tener en cuenta que a la larga hay que valorar aspectos de mantenimiento, de manera que a veces es mejor hacer un desembolso econmico en el diseo para ahorrarnos dinero en el mantenimiento futuro. Por tanto, el diseo ms consistente ser aqul que podamos ser capaces de mantener ms fcilmente. Introduccin a las distintas tecnologas de conmutacin En esta seccin discutiremos las caractersticas de varias tecnologas usadas para intercambiar datagramas entre redes. En efecto, trataremos de dar ms detalles sobre esas "cajas negras"que hemos visto en las anteriores secciones. Hay tres tipos bsicos de conmutadores, como repetidores, bridges (o puentes) y gateways (o pasarelas), o, alternativamente, switches de nivel 1, 2 y 3 (basndonos en el nivel del modelo OSI en el que operan). Tambin hay que aclarar que hay sistemas que combinan caractersticas de ms de uno de estos dispositivos, especialmente bridges y gateways. Las diferencias ms importantes entre estos tipos de dispositivos residen en el grado de aislamiento a fallos, prestaciones, enrutamiento y las facilidades que ofrecen para la administracin de la red. Ms adelante examinaremos esto con ms detalle. La diferencia mayor se encuentra entre los repetidores y los otros dos tipos de switches. Hasta hace relativamente poco tiempo, los gateways proporcionaban unos servicios muy distintos a los ofrecidos por los bridges, pero ahora hay una tendencia a unificar estas dos tecnologas. Los gateways estn empezando a adoptar un hardware de propsito especfico que antes era caracterstico de los bridges. Los bridges estn empezando a adoptar un enrutamiento ms sofisticado, caractersticas de aislamiento y de administracin de redes que antes slo se podan encontrar en los gateways. Incluso hay sistemas que pueden funcionar como bridges y gateway. Esto significa que la decisin crucial no es decidir si tenemos que usar un bridge o un gateway, sino qu caractersticas necesitamos en un switch y cmo ste afecta el diseo global de la red. Repetidores Un repetidor es un equipo que conecta dos redes que usan la misma tecnologa. Recibe los paquetes de datos de cada red y los retransmite a la otra red. La red resultante se caracteriza por tener la unin de los paquetes de ambas redes. Para las redes Ethernet, o que cumplen el protocolo IEEE 802.3, hay dos tipos de repetidores (otras tecnologas de red no hacen estas

distinciones). Un repetidor trabaja a muy bajo nivel. Su objetivo principal es subsanar las limitaciones de la longitud del cable que provocan prdidas de seal, dispersin temporal, etc. Nos permiten construir redes ms grandes y liberarnos de las limitaciones de la longitud del cable. Podramos pensar que un repetidor se comporta como un amplificador a ambos lados de la red, pasando toda la informacin contenida en la seal (incluso las colisiones) sin hacer ningn procesamiento a nivel de paquetes. No obstante, hay un nmero mximo de repetidores que pueden introducirse en una red. Las especificaciones bsicas de Ethernet requieren que las seales lleguen a su destino dentro de un lmite de tiempo, lo que determina que haya una longitud mxima de la red. Poniendo varios repetidores en el camino se introducen dificultades para estar dentro del lmite (de hecho, cada repetidor introduce un retraso, as que de alguna manera se introducen nuevas dificultades). Un "repetidor con buffer"trabaja a nivel de paquetes de datos. En lugar de pasar la informacin contenida en la seal, almacena paquetes enteros de una red en un buffer interno y, luego, lo retranstime a la otra red, por lo que no deja pasar las colisiones. Debido a que los fenmenos de bajo nivel, como las colisiones, no son repetidos, se puede considerar como si las dos redes continuasen separadas en lo que se refiere a las especificaciones Ethernet. Por tanto, no hay restricciones respecto al nmero de repetidores con buffer que se pueden usar. De hecho, no es necesario que ambas redes sean del mismo tipo, pero han de ser suficientemente similares, de manera que tengan el mismo formato de paquete. Generalmente, esto significa que se emplean repetidores con buffer entre redes de la familia IEEE 802.x (asumiendo que elegimos la misma longitud para las direcciones y el mismo tamao mximo para los paquetes), o entre dos redes de otra familia. Adems, un par de repetidores con buffer pueden usarse para conectar dos redes mediante una lnea serie. Los repetidores con buffer y los repetidores bsicos tienen una caracterstica en comn: repiten cada paquete de datos que reciben de una red en la otra. Y as ambas redes, al final, tienen exactamente el mismo conjunto de paquetes de datos. Bridges y gateways Un bridge se diferencia principalmente de un repetidor en que realiza algn tipo de seleccin de qu datagramas se pasan a las otras redes. Persiguen alcanzar el objetivo de aumentar la capacidad de los sistemas, al mantener el trfico local confinado a la red donde se originan. Solamente el trfico destinado a otras redes ser reenviado a travs del bridge. Esta descripcin tambin podra aplicarse a los gateways. Bridges y gateways se distinguen por la manera de determinar qu datagramas deben reenviarse. Un bridge usa slo las direcciones del nivel 2 de OSI; en el caso de las redes Ethernet, o IEEE 802.x, nos referimos a las direcciones de 6 bytes de Ethernet o direcciones del nivel-MAC (el trmino "direcciones del nivel MAC"es ms general. Sin embargo, con la intencin de aclarar ideas, los ejemplos de esta seccin se referirn a redes Ethernet y as slo deberemos reemplazar el trmino "direccin Ethernet"por el equivalente de direccin de nivel MAC en cualquier otra tecnologa). Un bridge no examina el datagrama en s, as que no usa las direcciones IP, o su equivalente para tomar las decisiones de enrutamiento. Como contraste, un gateway basa sus decisiones en las direcciones IP, o su equivalente en otros protocolos. Hay varias razones por las que importa el tipo de direccin usada para tomar una decisin. La primera de ellas afecta a cmo interactan dichos dispositivos conmutadores con los niveles superiores del protocolo. Si el reenvo se hace a nivel de las direcciones de nivel- MAC (bridge), dicho dispositivo ser invisible a los protocolos. Si se hace a nivel IP, ser visible. Veamos un ejemplo en el que hay dos redes conectadas por un bridge: Red 1 Red 2 128.6.5 128.6.4 =================== ============================== | | | | | fi|fi || fi|fi | 128.6.5.2 bridge 128.6.4.3 128.6.4.4 fi fi fi ordenador A ordenador B ordenador C Hay que decir que un bridge no tiene una direccin IP. En lo que se refiere a los ordenadores A,

B y C, hay una sola Ethernet a la que estn conectados. Esto se traduce en que las tablas de enrutamiento deben configurarse de manera que los ordenadores de ambas redes se traten como si fuesen locales. Cuando el ordenador A abre una conexin con el ordenador B, primero se enva una peticin ARP preguntando por la direccin Ethernet del ordenador B. El bridge debe dejar pasar esta peticin de la red 1 a la red 2. (En general, los bridges deben atender todas las peticiones). Una vez que ambos ordenadores conocen las direcciones Ethernet del otro, las comunicaciones usarn las direcciones Ethernet en el destino. Llegados a este punto, el bridge puede empezar a ejecutar alguna seleccin, y dejar pasar aquellos datagramas cuya direccin Ethernet de destino se encuentren en una mquina de la otra red. De esta manera un datagrama desde A hasta Bpasar de la red 2 a la red 1, pero un datagrama desde B hasta C se ignorar. Con objeto de hacer esta seleccin, el bridge necesita saber en qu red est cada mquina. La mayora de los bridges modernos construyen una tabla para cada red a la que se conecta, listando las direcciones Ethernet de las mquinas de las que se sabe en qu red se encuentran, y para ello vigilan todos los datagramas de cada red. Cuando un datagrama aparece primero en la red 1 es razonable pensar que la direccin del remitente corresponde a una mquina de la red 1. Un bridge debe examinar cada datagrama por dos razones: la primera, para usar la direccin de procedencia y aprender qu mquinas estn en cada red, y, la segunda, para decidir si el datagrama ha de ser reenviado o no en base a la direccin de destino. Como mencionamos anteriormente, por regla general los bridges dejan pasar las peticiones de una red a la otra. Frecuentemente se usan las peticiones para localizar algn recurso. Una peticin ARP es un tpico ejemplo de lo anterior. Debido a que un bridge no tiene manera de saber si un host va a responder a dicha peticin, deber dejarla pasar a la otra red. Algunos bridges tienen filtros definidos por el usuario, que les posibilita dejar pasar algunos y bloquear a otros. Podemos permitir peticiones ARP (que son esenciales para que el protocolo IP funcione) y restringir otras peticiones menos importantes a su propia red de origen. Por ejemplo, podemos elegir no dejar pasar las peticiones rwhod, que usan algunos sistemas para conocer los usuarios conectados en cualquier otro sistema, o podemos decidir que rwhod slo pueda tener acceso a una parte de la red. Ahora veamos un ejemplo de dos redes conectadas por un gateway: Red 1 Red 2 128.6.5 128.6.4 ====================== ============================== | | | | | | | fi|fi| ||fi | 128.6.5.2 128.6.5.1 128.6.4.1 128.6.4.3 128.6.4.4 fi fi fi ordenador A gateway ordenador B ordenador C Los gateways tienen asignada una direccin IP por cada interface. Las tablas de enrutamiento de los ordenadores debern configurarse para hacer los envos a las direcciones adecuadas. As, por ejemplo, el ordenador A tiene una entrada especificando que debe usarse el gateway 128.6.5.1 para alcanzar la red 128.6.4. Debido a que los ordenadores tienen conocimiento de la existencia del gateway, el gateway no necesita inspeccionar todos los paquetes de la Ethernet. Los ordenadores le enviarn datagramas cuando sea apropiado. Por ejemplo, supongamos que el ordenador A necesita enviar un mensaje al ordenador B. En la tabla de enrutamiento de A se indica que deberemos usar el gateway 128.6.5.1, y entonces se enviar una peticin ARP para esa direccin, respondindonos el gateway a la peticin como si se tratase de un host cualquiera. A partir de entonces, los datagramas destinados a B sern enviados a la direccin Ethernet del gateway. Ms sobre bridges Hay varias ventajas para usar direcciones del nivel MAC, como lo hace un bridge. La primera es que cada paquete en una Ethernet, o en una red IEEE, usa dichas direcciones, y la direccin se localiza en el mismo lugar en cada paquete, incluso si es IP, DECnet, o de cualquier otro protocolo. De tal manera que es relativamente rpido obtener la direccin de cada paquete.

Por otro lado, un gateway debe decodificar toda la cabecera IP y, si soporta otros protocolos distintos a IP, debe tener un software distinto para cada protocolo. Esto significa que un bridge soporta automticamente cualquier protocolo posible, mientras que un gateway debe preveer qu protocolo debe soportar. Sin embargo, tambin hay desventajas. La principal se refiere al diseo de un puente fi Un puente debe mirar cada paquete de la red, no solo aqullos a los que se le destinan. Esto hace posible que haya sobrecargas en el bridge si se coloca en una red muy concurrida, incluso si el trfico que atraviesa el bridge es pequeo. No obstante, existe otra desventaja basada en la manera como los bridges estn diseados. Sera posible, en principio, disear bridges sin estas desventajas, pero no hay indicios de que se cambie. La desventaja se debe al hecho de que los bridges no tienen una tabla de enrutamiento completa con todos los sistemas de las redes, ya que slo tienen una simple lista con las direcciones Ethernet que se encuentran en sus redes. Lo que significa que fi Las redes que usan bridges no pueden tener bucles en su diseo. Si hubiera un bucle, algunos bridges veran el trfico procedente de una misma direccin Ethernet 6. Puentes y gateways 36 venir de ambas direcciones, por lo que le sera imposible decidir en qu tabla debe poner dicha direccin. Hay que aclarar que un camino paralelo en la misma direccin constituye un bucle y, por tanto, no se podrn usar mltiples caminos con el fin de descargar el trfico de la red. Hay algunos mtodos para afrontar el problema de los bucles. Muchos puentes permiten configuraciones con conexiones redundantes, pero desactivando enlaces de manera que no haya bucles. Si un enlace falla, uno de los desactivados entra en servicio. As, los enlaces redundantes nos proporcionan una fiabilidad extra, pero nos proporcionan nuevas capacidades. Tambin es posible construir un bridge capaz de manejar lneas punto a punto paralelas, en un caso especial donde dichas lneas tienen en sus extremos un bridge. Los bridges trataran las dos lneas como una nica lnea virtual y usarlas alternativamente, siguiendo algn algoritmo aleatorio. El proceso de desactivar conexiones redundantes hasta que no queden bucles es conocido como un algoritmo de expansin de rboles". Este nombre se debe a que un rbol se define como un patrn de conexiones sin bucles. Lo que se hace es ir desactivando conexiones, ya que las conexiones restantes en el rbol incluyen a todas las redes del sistema. Para llevarlo a cabo, todos los bridges del sistema de redes deben comunicarse entre ellos. Hay una tendencia a que los rboles de expansin resultantes cargan demasiado a la red en alguna parte del sistema. Las redes cercanas a la "raiz del rbol"manejan todo el trfico entre las distintas partes de la red. En una red que usa gateways, sera posible poner enlaces extras entre partes de la red que tengan un gran trfico, pero dichos enlaces extras no pueden ser usados por un conjunto de bridges. Ms sobre gateways Los gateways tienen sus propias ventajas y desventajas. En general, un gateway es ms complejo de disear y administrar que un bridge. Un gateway debe participar en todos los protocolos para los que est diseado para reenviar. Por ejemplo, un gateway IP debe responder a peticiones ARP. El estndar IP tambin necesita estudiar por completo las cabeceras IP, decrementando el tiempo para activar campos y obedecer cualquier opcin IP. Los gateways son diseados para manejar topologas de redes ms complejas que las que son capaces de manejar los bridges. Y, como ya hemos mencionado, tienen diferentes (y ms complejas) decisiones que estudiar. En general, un bridge tiene decisiones ms fciles que tomar: si se debe reenviar un datagrama y, en caso de que deba hacerse, qu interface hemos de elegir. Cuando un gateway reenva un datagrama, debe decidirse a qu host o gateway hay que enviarlo a continuacin. Si un gateway enva un datagrama de vuelta a la red de donde procede, tambin debe enviar una redireccin al emisor del datagrama indicando que use una mejor ruta. Muchos gateways pueden tambin manejar caminos paralelos. Si hay varios caminos igual mente buenos para un destino, el gateway usar uno de ellos determinado por algn tipo de algoritmo aleatorio.

(Esto se hace tambin en algunos bridges, pero no suele ser lo usual. En ambos casos, se elige uno de ellos mediante algn tipo de algoritmo aleatorio. Esto tiende a hacer que la llegada de los datagramas tenga un orden distinto al que fueron enviados. Lo que puede complicar la labor de procesamiento de los datagramas de los hosts de destino, e, incluso, hay viejas implementaciones TCP/IP que tienen errores a la hora de ordenar los datagramas). Para poder analizar todas estas decisiones, un gateway tendr una tabla de enrutamiento muy similar a la de los hosts. Al igual que las tablas de enrutamiento, las tablas de los gateways contienen una entrada por cada posible nmero de red. Para cada red hay, o 6. Puentes y gateways 37 bien una entrada indicando que la red est conectada directamente al gateway, o hay una entrada indicando que el trfico para esa red debe reenviarse hacia algn otro gateway o gateways. Describiremos posteriormente los "protocolos de enrutamientousados para elaborar esta informacin, en la discusin sobre cmo configurar un gateway. Comparando las tecnologas de conmutacin Los repetidores, repetidores con buffer, bridges y gateways forman un espectro. Los dispositivos del principio de la lista son mejores para redes pequeas, adems son ms baratos y fciles de configurar aunque tienen menos servicios. Los del final de la lista son apropiados para construir redes ms complejas. Muchas redes usan mezclas de dispositivos, con repetidores para conectar pequeos segmentos de red, bridges para algunas reas grandes y gateways para enlaces de larga distancia. Hasta ahora hemos asumido que slo usan gateways. La seccin de cmo configurar un host describe cmo configurar una tabla de enrutamiento, listando los gateways que se deban usar para alcanzar a distintas redes. Los repetidores y bridges son invisibles a IP, y, en lo que a las anteriores secciones se refiere, las redes conectadas mediante ellos se deben considerar como una nica red. En la seccin 3.4. se describe cmo configurar un host en el caso en que varias subredes se traten como una nica red fsica; la misma configuracin debera usarse cuando varias subredes se conectan mediante repetidores o bridges. Como ya mencionamos, las caractersticas a tener en cuenta en un dispositivo conmutador son: aislamiento, rendimiento, enrutamiento y las facilidades de mantenimiento de la red. Aislamiento Generalmente, los dispositivos conmutadores se usan para conectar redes. As que, normalmente, pensamos en ganar conectividad, no en el aislamiento. Sin embargo, el aislamiento es algo digno de tener en cuenta. Si conectamos dos redes y no tenemos en cuenta el aislamiento para nada, entonces cualquier problema en otras redes aparecer en la nuestra tambin. Asimismo, dos redes juntas pueden tener suficiente trfico como para saturar la nuestra. Es por lo tanto conveniente elegir un nivel apropiado de proteccin. El aislamiento puede llegar de dos maneras: aislamiento frente al mal funcionamiento y frente al trfico. Con el objeto de discutir el aislamiento debido a errores de funcionamiento, vamos a sealar una clasificacin de malfunciones: fi Fallos elctricos, como por ejemplo una bajada de tensin o algn tipo de fallo que distorsiona la seal. Todos los tipos de dispositivos debern confinarlo a un lado del dispositivo (repetidor, repetidor con buffer, bridge, gateway). fi Problemas con los transceiver y controladores que, en general, generan seales elctricamente correctas, pero de contenido errneo (por ejemplo, paquetes de tamao infinito o demasiado grandes, falsas colisiones, portadora continua). Todos, excepto el repetidor, nos protegen de estos problemas, que no son muy comunes. fi Errores en el software que provocan un excesivo trfico entre algunos hosts (no nos referimos a mensajes de tipo broadcoast). Los bridges y gateways pueden aislarnos de estos errores. (Este tipo de fallos son bastante raros. La mayor parte de los problemas del software y de protocolos generan broadcoasts). fi Errores en el software que provocan un excesivo trfico de broadcast. Los gateways se aislan de estos problemas.

Generalmente, los bridges no lo hacen, porque deben dejar las peticiones ARP y otros broadcasts. Los bridges con filtros definidos por el usuario podran protegernos contra algunos de estos errores de sobrecarga de broadcast. Sin embargo, en general, los bridges deben dejar pasar ARP y la mayora de estos errores se deben a ARP. Este problema no es tan grave en redes donde el software tiene un cuidadoso control, pero tendremos regularmente problemas de este tipo en redes complejas o con software experimental. El aislamiento al trfico es proporcionado por bridges y gateways. La decisin ms importante al respecto es conocer el nmero de ordenadores que podemos poner en una red sin sobrecargarla. Esto requiere el conocimiento de la capacidad de la red, y el uso al que se destinarn los hosts. Por ejemplo, una Ethernet puede soportar cientos de sistemas si se van a destinar para logins remotos y, ocasionalmente, para transferencia de ficheros. Sin embargo, si los ordenadores carecen de disco, y usamos la red para swapping, una Ethernet podra soportar entre 10 y 40, dependiendo de su velocidad y sus caractersticas de E/S. Cuando ponemos ms ordenadores en una red de los que es capaz de manejar, deberemos dividirla en varias redes y poner algn dispositivo conmutador entre ellos. Si esto se hace correctamente, la mayora del trfico deber realizarse entre mquinas de la misma parte de la divisin, lo que significa poner los clientes en la misma red que su servidor, poner los servidores de terminales en la misma red que los hosts a los que se accede ms frecuentemente. Bridges y gateways, generalmente, suministran el mismo grado de aislamiento al trfico. En ambos casos, slo el trfico destinado a los hosts del lado de la unidad conmutadora se pasar. Veremos esto ms detalladamente en la seccin del enrutamiento. Prestaciones Los lmites de las prestaciones empiezan a ser menos claros, puesto que las tecnologas de conmutacin estn mejorando continuamente. Generalmente, los repetidores pueden manejar todo el ancho de banda de la red (por su propia naturaleza, un repetidor bsico ha de ser capaz de hacer esto). Los bridges y gateways frecuentemente tienen limitaciones en sus prestaciones de varios tipos. Los bridges tienen dos estadsticos de inters: la tasa de paquetes analizados y el rendimiento. Como explicamos anteriormente, los bridges deben analizar cada paquete que se encuentra en la red, incluso aquellos que no van a ser reenviados. El nmero de paquetes analizados por segundo es la unidad usada para medir la tasa de paquetes analizados. El rendimiento se puede aplicar tanto a bridges como a gateways, y refleja la parte del trfico que ha sido reenviada; generalmente, depende del tamao del datagrama. As, el nmero de datagramas por segundo que una unidad puede manejar ser mayor cuanto haya ms datagramas pequeos que grandes. Normalmente, un bridge puede manejar desde algunos cientos de datagramas hasta unos 7.000. Se puede obtener mayor capacidad de procesamiento con equipos que usan una hardware de propsito especfico para acelerar la labor de anlisis de paquetes. La primera generacin de gateways podan procesar entre algunos cientos de datagramas por segundo hasta unos 1.000 ms; sin embargo, los gateways de segunda generacin, ampliamente extendidos, usan un hardware de propsito especfico igual de sofisticado que el usado en los bridges y con ellos se pueden manejar alrededor de 10.000 datagramas por segundo. Debido a que en este momento los bridges y gateways de altas prestaciones pueden manejar casi todo el ancho de banda de una Ethernet, las prestaciones no son una 6. Puentes y gateways 39 razn para elegir entre un tipo u otro de dispositivo. Sin embargo, para un tipo dado de dispositivo, hay todava grandes diferencias entre los distintos modelos, sobre todo en la relacin precio/prestaciones. Esto es especialmente cierto en los modelos de la gama baja. Los bridges ms baratos cuestan menos de la mitad que los gateways ms baratos. Desgraciadamente, no hay un nico estadstico para poder estimar las prestaciones de un dispositivo. No obstante, el que ms se usa es el de paquetes por segundo. Hay que tener en cuenta que la mayora de las empresas cuentan los datagramas una sola vez, cuando pase por el gateway; hay una compaa importante que cuenta los datagramas 2 veces,

y, por tanto, deben dividirse por 2 para poder comparar. Tambin hay que asegurarse, para hacer una comparacin correcta, que los datagramas son del mismo tamao. Un modelo para poder comparar prestaciones es tiempofidefiprocesamiento = tiempoficonmutacin + tamaofidatagrama * tiempofiporfibyte Aqu, el tiempo de conmutacin suele ser una constante; representa la interrupcin latente, el procesamiento de las cabeceras, buscar en la tabla de enrutamiento, etc., ms un componente proporcional al tamao del datagrama, representando el tiempo necesario para hacer cualquier copia de datagrama. Un enfoque razonable para estudiar las prestaciones es dar los datagramas por segundo por los tamaos mnimos y mximos de los datagramas. Otra forma de conocer los lmites de un dispositivo es conociendo la velocidad de los datagramas por segundo y el rendimiento en bytes por segundo, y aplicando la frmula anterior. Enrutamiento Vamos a estudiar las tecnologas usadas para decidir hacia dnde debe enviarse un datagrama. Por supuesto, no haremos esto para los repetidores, ya que stos reenvan todos los paquetes. La estrategia de enrutamiento de un bridge conlleva tomar dos decisiones: fi activar o desactivar los enlaces de manera que se mantenga el rbol de expansin; y, fi decidir si debemos reenviar un paquete en particular y a travs de cul interface (si el puente es capaz de manejar ms de dos interfaces). La segunda decisin se toma en base a una tabla de direcciones del nivel-MAC. Como ya hemos descrito anteriormente, esta tabla se construye analizando el trfico que pasa por cada interface. El objetivo es reenviar aquellos paquetes cuyo destino se encuentre a otro lado del bridge. Este algoritmo requiere tener una configuracin de red que no contenga bucles o lneas redundantes. Los bridges menos sofisticados dejan esta tarea al diseador de la red, y debemos disear y configurar una red sin bucles. Los bridges ms sofisticados permiten una topologa cualquiera, pero ir desactivando enlaces hasta que no haya bucles; adems, nos proporciona una fiabilidad extra, ya que, en caso de fallo de un enlace, se activar automticamente un enlace alternativo. Los bridges que funcionan de este modo tienen un protocolo que les permite detectar cundo una unidad debe desactivarse o activarse, de manera que el conjunto activo de enlaces abarquen el rbol de expansin. Si necesitamos la fiabilidad proporcionada por los enlaces redundantes, debemos asegurarnos que nuestros bridges sean capaces de trabajar de esta manera. Actualmente no hay un protocolo estndar para este tipo de bridges, pero est en camino. En caso de comprar bridges de ms de una marca, debemos asegurarnos que sus protocolos para trabajar con los rboles de expansin pueden entenderse. Por otro lado, los gateways permiten cualquier tipo de topologa, incluyendo bucles y enlaces redundantes. Debido a que tienen algoritmos ms generales de enrutamiento, los gateways deben mantener un modelo de toda la red. Diferentes tcnicas de enrutamiento mantienen modelos de redes con ms o menos complejidad, y usan esta informacin con distinto tipo de sofisticacin. Los gateways que pueden manejar IP, normalmente soportan los dos protocolos estndares de Internet: RIP (Routing Information Protocol) y EGP (External Gateway Protocol). El EGP es un protocolo de propsito especfico usado en redes donde hay una red principal, y permite intercambiar informacin de "cmo llegar"con la red principal. Por regla general, es bastante recomendable que nuestros gateways soporten EGP. RIP es un protocolo diseado para manejar rutas en redes pequeas o medianas, donde la velocidad de las lneas no difieren demasiado. Sus principales limitaciones son: - No puede usarse con redes donde los caminos pasan por ms de 15 gateways. Se puede, incluso, reducir este nmero en el caso de que usemos una opcin de dar un paso mayor de uno a una lnea lenta. - No puede compartir el trfico entre lneas paralelas (algunas implementaciones permiten hacer esto si dichas lneas se encuentran entre el mismo par de gateways).

- No puede adaptarse a la sobrecarga de redes. fi No es adecuada para situaciones en las que hay rutas alternativas a travs de lneas con muy distinta velocidad. fi No es estable en redes donde las lneas o los gateways cambian con frecuencia. Algunas compaas venden modificaciones de RIP que mejoran su funcionamiento con EGP, o que incrementan la longitud del camino mximo ms all de 15, pero no incluyen otro tipo de modificaciones. En caso de que nuestra red disponga de gateways de ms de una marca, en general necesitaremos que soporten RIP, puesto que suele ser el nico protocolo de enrutamiento disponible. Si vamos a trabajar, adems, con otro tipo de protocolo, pueden sernos tiles gateways que traduzcan su propio protocolo y RIP. Sin embargo, para redes muy grandes o complejas no nos queda otro remedio que usar otros protocolos. Tambin existen otros protocolos ms sofisticados. Los principales son IGRP y los basados en los algoritmos SPF (el camino ms corto primero - short path fist). Usualmente, estos protocolos han sido diseados para redes ms grandes o complejas y, en general, son estables bajo una gran variedad de condiciones, pudiendo manejar lneas de cualquier velocidad. Algunos de ellos permiten tener en cuenta la sobrecarga de algunos caminos, pero hasta el moemento no conozco un gateway que sea capaz de hacer esto. (Hay serios problemas para mantener un enrutamiento estable para realizarlo). Hay numerosas variantes de tecnologas de enrutamiento, y stas se estn modificando rpidamente, as que deberemos tener en cuenta la topologa de nuestra red para elegir un producto en concreto; tenemos que asegurarnos que puede manejar nuestra topologa y que puede soportar otros requerimientos especiales, como compartir el trfico entre lneas paralelas, o ajustar la topologa ante fallos. A largo plazo, se espera que aparezcan nuevos protocolos que estandaricen estos trabajos. Pero, por el momento, no se usa otra tecnologa de enrutamiento que la RIP. Otro asunto concerniente al enrutamiento es la politica en la que se basa el enrutamiento. En general, los protocolos de enrutamiento pretenden encontrar el camino ms corto o ms rpido posible para cada datagrama. En algunos casos, esto no es lo deseable; a veces, por razones de seguridad, razones econmicas, etc, puede que deseemos reservar algunos caminos para algn uso especfico. La mayora de los gateways tienen la capacidad de controlar la propagacin de la informacin de enrutamiento, lo que nos da algunas facilidades de administracin sobre la forma en que estas rutas se usan, y el grado de control que soportan vara de un gateway a otro. Administracin de Redes La administracin de redes abarca un amplio nmero de asuntos. En general, se suelen tratar con muchos datos estadsticos e informacin sobre el estado de distintas partes de la red, y se realizan las acciones necesarias para ocuparse de fallos y otros cambios. La tcnica ms primitiva para la monitorizacin de una red es hacer "pinginga los hosts crticos; el "pinging"se basa en un datagrama de "echo"(eco), que es un tipo de datagrama que produce una rplica inmediata cuando llega al destino. La mayora de las implementaciones TCP/IP incluyen un programa (generalmente, llamado "ping") que enva un echo a un host en concreto. Si recibimos rplica, sabremos que host se encuentra activo, y que la red que los conecta funciona; en caso con

7 - Configurando gateways
Vamos a ver algunos aspectos especficos de la configuracin de gateways. Aquellos gateways que entienden el protocolo IP son, al mismo tiempo, hosts de Internet y, por tanto, podemos poner en prctica lo visto para configurar las direcciones y el enrutamiento en los hosts. No obstante, la forma exacta de cmo debemos configurar un gateway depende del modelo en concreto. En algunos casos, deberemos editar algunos ficheros includos en un disco del propio gateway. Sin embargo, por razones de fiabilidad, la mayora de los gateways no tienen discos propios; en su lugar, esta informacin se almacena en una memoria no voltil o en ficheros que se cargan desde uno o varios hosts de la red.

Como mnimo, para configurar el gateway hay que especificar la direccin IP y la mscara de cada interface, y activar un protocolo de enrutamiento adecuado. Normalmente ser deseable configurar otros parmetros. Un parmetro importante a tener en cuenta es la direccin de broadcast. Como explicamos con anterioridad, hay cierto software antiguo que no funciona bien cuando se envan broadcasts usando los nuevos protocolos de direcciones de broadcast. Por esta razn, algunos modelos nos permiten elegir una direccin broadcast para cada interface. Por tanto, en ese caso, se debern configurar teniendo en cuenta los ordenadores que hay en la red. En general, si los ordenadores soportan los actuales estndares, podr usarse una direccin del tipo 255.255.255.255. No obstante, antiguas implementaciones deben comportarse mejor con otro tipo de direcciones, especialmente con aquellas direcciones que usan ceros para los nmeros del host (para la red 128.6 sta tendra que ser 128.6.0.0. Para mantener la compatibilidad con redes que no soportan sub-redes deberamos usar 128.6.0.0 como direccin de broadcast, incluso para una subred del tipo 128.6.4). Podemos observar nuestra red con un monitor de red y ver los resultados de las distintas elecciones de direciones de broadcast; en caso de que hagamos una mala eleccin, cada vez que hagamos un broadcast para actualizar el enrutamiento, muchas mquinas de nuestra red nos responderan con errores ARP o ICMP. Hay que hacer notar que cuando cambiamos las direcciones de broadcast en el gateway, necesitaremos cambiarla tambin en cada uno de los ordenadores. Lo que se suele hacer es cambiar la direccin de aquellos sistemas que podemos configurar, para hacerlos compatibles con los otros sistemas que no podemos configurar. Hay otros parmetros de la interface que pueden que sea necesario configurar para trabajar con las peculiaridades de la red a la que se conectan. Por ejemplo, muchos gateways comprueban sus interfaces a Ethernet para asegurarse de que el cable al que se conectan y el transceiver funcionan correctamente. Algunos de estos tests no funcionan correctamente con la antigua versin 1 de transceiver Ethernet. En caso de que usemos un transceiver de este tipo, deberemos desactivar este tipo de test. De forma similar, los gateways conectados a lneas en serie normalmente hacen este tipo de test para verificar su buen funcionamiento, y tambin hay situaciones en las que necesitaremos deactivar el test. Es bastante usual que tengamos que activar las opciones necesarias para el software que tengamos que usar. Por ejemplo, muchas veces es necesario activar explcitamente el protocolo de administracin de red, y dar el nombre o la direccin del host donde se ejecuta el software que acepta traps (mensajes de error). La mayora de los gateways tienen opciones relacionadas con la seguridad. Como mnimo, hay que indicar un password para poder hacer cambios de forma remota (y una "session name"para SGMP). Si queremos controlar el acceso a ciertas partes de la red, tambin deberemos definir una lista de control de accesos, o cualquier otro mecanismo que use el gateway en cuestin. Los gateways cargan la informacin de la configuracin a travs de la red. Cuando un gateway arranca, enva una peticin broadcast de varias clases, intentando conocer su direccin Internet para luego cargar su configuracin. As, hay que asegurarse que haya algunos ordenadores capaces de responder a dichas peticiones. En algunos casos, hay algn micro dedicado ejecutando un software especial. Otras veces, hay un software genrico que podemos ejecutar en varias mquinas. Por razones de fiabilidad, debemos comprobar que hay ms de un host con la informacin y los programas que necesita. En algunos casos tendremos que mantener varios archivos distintos. Por ejemplo, los gateways usados en Groucho usan un programa llamado "bootp"para que le proporcione su direccin Internet, y luego cargan el cdigo y la informacin de la configuracin usando TFTP. Esto significa que tenemos que mantener un archivo para "bootp"que contiene las direcciones Ethernet e Internet para cada gateway, y un conjunto de archivos para la restante informacin de cada uno de ellos. Si una red es muy grande, podemos tener problemas para asegurarnos de que esta informacin permanece consistente. Podemos mantener copias nuestras de todas las configuraciones en un nico ordenador y que se distribuya a otros sistemas cuando haya algn cambio, usando las facilidades make y rdist de Unix. Si nuestro gateway tiene la opcin de almacenar la informacin de la configuracin en una memoria no voltil, podremos eliminar todos estos problemas logsticos, pero presenta sus propios problemas. El contenido de esta memoria debera almacenarse en alguna localizacin central, porque de todas maneras es difcil para el

personal de administracin de la red revisar la configuracin si se encuentra distribuda entre los distintos gateways. Arrancar un gateway que carga la informacin de su configuracin desde una localizacin distante es especialmente arriesgado. Los gateways que necesitan cargar su informacin de configuracin a travs de la red, generalmente emiten una peticin broadcast a todas las redes que conectan. Si algn ordenador de una de esas redes es capaz de responder, no habr ningn problema. Sin embargo, algunos gateways que se encuentren a gran distancia donde los ordenadores de su alrededor no soportan los protocolos necesarios, en cuyo caso es necesario que las respuestas le lleguen a travs de una red donde haya unos ordenadores apropiados. Desde un punto de vista estricto, esto va en contra de la filosofa de trabajo de los gateways, ya que normal mente un gateway no permite que un broadcast procedente de una red pase a travs de una red adyacente. Para permitir que un gateway obtenga informacin de un ordenador en una red distinta, al menos uno de los gateways que est entre ellos tendr que configurarse para que pase una clase especial de broadcast usado para recuperar este tipo de informacin. Si tenemos este tipo de configuracin, tendremos que comprobar este proceso peridicamente, ya que no es raro que nos encontremos con que no podamos arrancar un gateway tras un fallo de energa, debido a un cambio en la configuracin en otro gateway que hace imposible cargar esta informacin. Configurando el enrutamiento de los gateways Por ltimo, vamos a tratar cmo configurar el enrutamiento. Este tipo de configuracin es ms difcil para un gateway que para un host. La mayora de los expertos TCP/IP recomiendan dejar las cuestiones de enrutamiento a los gateways. As, los hosts simplemente tienen una ruta por defecto que apunta al gateway ms cercano (por supuesto, los gateways no pueden configurarse de esta manera. Ellos necesitan tablas completas de enrutamiento). Para entender cmo configurar un gateway, vamos a examinar con un poco ms de detalle cmo los gateways se comunican las rutas. Cuando encendemos un gateway, la nica red de la que tiene informacin es aqulla a la que est directamente conectado (lo que se especifica en la configuracin). Para llegar a saber cmo se llega a partes ms distantes de la red, marca algn tipo de "protocolo de enrutamiento", que simplemente es un protocolo que permite a cada gateway anunciar a qu redes tiene acceso, y extender esa informacin de un gateway a otro. Eventualmente, cada gateway debera saber cmo llegar a cada red. Hay distintos tipos de protocolos de enrutamiento; en el ms comn, los gateways se comunican exclusivamente con los ms cercanos; en otra clase de protocolos, cada gateway construye una base de datos describiendo cada gateway del sistema. No obstante, todos estos protocolos encuentran cmo llegar a cualquier destino. Una mtrica es un nmero, o conjunto de nmeros, usado para comparar rutas. La tabla de enrutamiento se construye recogiendo informacin de otros gateways. Si dos gateways son capaces de llegar a un mismo destino, debe de haber algn mtodo para decidir cul usar. La mtrica se usa para tomar esta decisin. Todas las mtricas indican de alguna forma lo "costoso"de una ruta. Podra ser cuntos dlares costara enviar un datagrama por una ruta, el retraso en milisegundos, o cualquier otra medida. La mtrica ms simple es el nmero de gateways que hay hasta el destino ("cuenta de saltos"), y es la que generalmente se encuentra en los ficheros de configuracin. Como mnimo, una configuracin de enrutamiento consistira en un comando para activar el protocolo de enrutamiento que vayamos a usar. La mayora de los gateways estn orientados para usar un protocolo; a no ser que tengamos razones para usar otro, es recomendable usar dicho protocolo. Una razn habitual para elegir otro protocolo es para hacerlo compatible con otros gateways. Por ejemplo, si nuestra red est conecta da a una red nacional que nos exige usar EGP ("exterior gateway protocol") para que se pueda intercambiar rutas con ella, EGP slo es apropiado para este caso especfico. No deberemos usar EGP dentro de nuestra propia red, sino slo para comunicarnos con la red nacional. Si tenemos varias clases de gateways, necesitaremos usar un protocolo entendible por todos ellos. En muchas ocasiones este protocolo ser RIP (Routing Information Protocol). A veces podremos usar protocolos ms

complejos entre los gateways que los soporten, y usar RIP slo cuando nos comuniquemos con gateways que no entiendan estos protocolos. Si ya hemos elegido un protocolo de enrutamiento y lo hemos puesto en marcha, todava nos quedan por tomar algunas decisiones. Una de las tareas mas bsicas de configuracin que tenemos que completar es uministrar la informacin de la mtrica. Los protocolos ms simples, como RIP, normalmente usan "cuenta de saltos", de manera que una ruta que pasa a travs de dos gateways es mejor que una que pasa por tres. Por supuesto, si la ltima ruta usa lneas de 1'5 Mbps y la primera lneas de 9.600 bps, sera una mala eleccin. La mayora de los protocolos de enrutamiento tienen medios para tomar esto en cuenta. Con RIP, podramos tratar las lneas de 9.600 bps como si fueran "saltosadicionales, de manera que la mejor lnea (la ms rpida) tenga una mtrica menor. Otros protocolos ms sofisticados tendrn en cuenta la velocidad de la lnea de forma automtica. Generalmente, estos parmetros debern asociarse a una interface en particular. Por ejemplo, con RIP deberemos establecer explcitamente el valor de la mtrica, si se est conectado con una lnea de 9.600 bps. Con aquellos protocolos que tienen en cuenta la velocidad de las lneas, deberemos de especificar la velocidad de las lneas (si el gateway no los puede configurar automticamente). La mayor parte de los protocolos de enrutamiento han sido dise~nados para que cada gateway se aprenda la topologa de toda la red, y elegir la mejor ruta posible para cada datagrama. En algunos casos no estaremos interesados en la mejor ruta; por ejemplo, puede que estemos interesados en que el datagrama se desplace por una parte de la red por razones de seguridad o econmicas. Una manera de tener este control es especificando opciones de enrutamiento. Dichas opciones varan mucho de un gateway a otro, pero la estrategia bsica es que si el resto de la red no conoce dicha ruta, no ser utilizada. Estos controles limitan la forma en la que se van a usar las rutas. Hay mtodos para que el usuario ignore las decisiones de enrutamiento hechas por los gateways. Si realmente necesitamos controlar el acceso a ciertas redes, podemos hacer dos cosas: los controles de enrutamiento nos aseguran que los gateways usan slo las rutas que queremos; usar listas de control de acceso en los gateways adyacentes a las redes controladas. Estas dos opciones trabajan a distinto nivel. Los controles de enrutamiento afectan a lo que ocurre a la mayora de los datagramas: aqullos en los que el usuario no ha especificado manualmente una ruta. Nuestro mecanismo de enrutamiento ha de ser capaz de elegir una ruta aceptable para ellos. Una lista de control de acceso anade una limitacin adicional, preservndonos de usuarios que incluyesen su propio enrutamiento y pasasen nuestros controles. Por razones de fiabilidad y seguridad, puede que tambin haya controles con listas de gateways de las que podemos aceptar informacin. Tambin es posible hacer una clasificacin de prioridad. Por ejemplo, podemos decidir hacer antes los enrutamientos de nuestra propia organizacin antes que los de otras organizaciones, u otras partes de la organizacin. Esto tendr el efecto de dar preferencia al trfico interno frente al externo, incluso si el externo parece ser mejor. Si usamos varios protocolos distintos de enrutamiento, probablemente tendremos que afrontar algunas decisiones respecto a la informacin que se pasan entre ellos. Puesto que el uso de varios protocolos de enrutamiento est frecuentemente asociado a la existencia de varias organizaciones, deberemos de tomar la precaucin de hacer estas decisiones consultando con los administradores de las redes de dichas organizaciones. Este tipo de decisiones puede tener consecuencias en las otras redes bastante difciles de detectar. Podramos pensar que la mejor forma de configurar un gateway es que fuese capaz de entender todos los protocolos, pero hay algunas razones por las que esto no es recomendable: Las mtricas usadas por los distintos protocolos no son compatibles en muchas ocasiones. Si estamos conectados a dos redes externas distintas, podemos especificar que una siempre debe

usarse preferentemente a la otra, o que la ms cercana es la que debe usarse, en lugar de comparar la mtrica recibida de las dos redes para ver cul tiene la mejor ruta. EGP es especialmente delicado, ya que no admite bucles. Por esto hay unas reglas estrictas para regular la informacin que hay que intercambiar para comunicarse con una red principal usando EGP. En aquellos casos en que se use EGP, el administrador de la red principal debera ayudarnos a configurar el enrutamiento. Si tenemos lneas lentas en nuestra red (9.600 bps o menos)

NAT- Conversin de direcciones de red, habilitacin de puertos y

El principio de NAT
La conversin de direcciones de red o NAT se desarroll para resolver la falta de direcciones IP con el protocolo IPv4 (dentro de poco tiempo el protocolo IPv6 resolver este problema). De hecho, en las direcciones IPv4 la cantidad de direcciones IP enrutables (que son nicas en el mundo) no es suficiente para permitir que todos los equipos que lo requieran estn conectados a Internet. Por lo tanto, el principio de NAT consiste en utilizar una conexin de pasarela a Internet, que tenga al menos una interfaz de red conectada a la red interna y al menos una interfaz de red conectada a Internet (con una direccin IP enrutable) para poder conectar todos los equipos a la red.

Es cuestin de crear, al nivel de la pasarela, una conversin de paquetes desde la red interna hacia la red externa. Por lo tanto, se configura cada equipo en la red que necesite acceso a Internet para que utilice una pasarela de NAT (al especificar la direccin IP de la pasarela en el campo

"Gateway" [Pasarela] con sus parmetros TCP/IP). Cuando un equipo de red enva una solicitud a Internet, la pasarela hace la solicitud en su lugar, recibe la respuesta y la enva al equipo que hizo la solicitud.

Debido a que la pasarela oculta completamente las direcciones internas en la red, el mecanismo de conversin de direcciones de red brinda una funcin segura. De hecho, para un observador externo de la red, todas las solicitudes parecen provenir de la direccin IP de pasarela.

Espacio de la direccin
La organizacin que administra el espacio de direcciones pblicas (direcciones IP enrutables) es la Agencia de Asignacin de Nmeros de Internet (IANA, Internet Assigned Number Authority). RFC 1918 define un espacio de direccin privada que permite que cualquier organizacin asigne direcciones IP a equipos en su red interna sin correr el riesgo de entrar en conflicto con una direccin IP pblica asignada por la IANA. Estas direcciones conocidas como no enrutables corresponden a las siguientes series de direcciones:

Clase A: desde 10.0.0.0 hasta 10.255.255.255; Clase B: desde 10.16.0.0 hasta 172.31.255.255; Clase C: desde 192.168.0.0 hasta 192.168.255.55

Todos los equipos de una red interna, conectados a Internet a travs de un router y que no posean una direccin IP pblica, deben utilizar una direccin que se encuentre dentro de estas series. Para redes domsticas pequeas, generalmente se utiliza la serie de direcciones comprendidas entre 192.168.0.1 y 192.168.0.255.

Conversin esttica
El principio de NAT esttica consiste en vincular una direccin IP pblica con una direccin IP interna privada en la red. Por lo tanto, el router (o ms precisamente la pasarela) permite que una direccin IP privada (por ejemplo 192.168.0.1) est vinculada con una direccin IP enrutable pblica en Internet y lleva a cabo la conversin, en cualquier direccin, al cambiar la direccin en el paquete IP.

Por consiguiente, la conversin de direcciones de red esttica permite que equipos de una red interna estn conectados a Internet de manera transparente, pero no resuelve el problema de falta de direcciones, en la medida en que n direcciones IP enrutables son necesarias para conectar n equipos a la red interna.

Conversin dinmica
La NAT dinmica permite que diversos equipos con direcciones privadas compartan una direccin IP enrutable (o un nmero reducido de direcciones IP enrutables). Entonces visto desde afuera, todos los equipos de la red interna prcticamente poseen la misma direccin IP. sta es la razn por la cual a veces se utiliza el trmino "enmascaramiento IP" para indicar la conversin de direcciones de red dinmica. Para poder "multiplexar" (compartir) las diferentes direcciones IP en una o varias direcciones IP enrutables, la NAT dinmica utiliza la Conversin de direcciones por puerto (PAT, Port Address Translation), es decir, la asignacin de un puerto de origen diferente para cada solicitud, de manera que se pueda mantener una correspondencia entre las solicitudes que provienen de la red interna y las respuestas de los equipos en Internet, todas enviadas a la direccin IP del router.

Habilitacin de puertos
La conversin de direcciones de red slo permite solicitudes provenientes de la red interna hacia la red externa, con lo cual es imposible que un equipo externo enve un paquete a un equipo de la red interna. En otras palabras, los equipos de la red interna no pueden funcionar como un servidor con respecto a la red externa. Por esta razn, existe una extensin NAT llamada "habilitacin de puertos" o mapeo de puertos que consiste en configurar la pasarela para enviar todos los paquetes recibidos en un puerto particular a un equipo especfico de la red interna. Por lo tanto, si la red externa necesita acceder a un servidor Web (puerto 80) que funciona en un equipo 192.168.1.2, ser necesario definir una regla de habilitacin de puertos en la pasarela, con lo cual se redirigirn todos los paquetes TCP recibidos en el puerto 80 al equipo 192.168.1.2.

Activacin de puertos
La mayora de las aplicaciones cliente-servidor realiza una solicitud a travs de un host remoto en un puerto determinado y a su vez abre un puerto para recuperar los datos. Sin embargo, ciertas aplicaciones utilizan ms de un puerto para intercambiar datos con el servidor. ste es el caso, por ejemplo, del FTP, para el que se establece una conexin por el puerto 21, pero los datos se transfieren por el puerto 20. Por lo tanto, con NAT, despus de una solicitud de conexin en el puerto 21 de un servidor FTP remoto, la pasarela espera una conexin en un solo puerto y rechazar la solicitud de conexin en el puerto 20 del cliente.

Existe un mecanismo derivado de la NAT llamado "activacin de puertos" que permite autorizar la conexin con determinados puertos (habilitacin de puertos) si se completa una condicin (solicitud). Por lo tanto, se trata de una habilitacin de puertos condicional que permite que un puerto se abra slo cuando una aplicacin lo solicita. De esta manera, el puerto no permanece permanentemente abierto.

Ms informacin
Para obtener ms informacin, se aconseja que consulte este artculo que trata la conversin de las direcciones de red:

Translation d'adresse - Conversin de direcciones de red (NAT)

RFC 1918 y 3022 describen el principio del espacio de direcciones internas y la conversin de direcciones de red en detalle:

RFC 3022 - Conversor de direcciones de red IP tradicional (NAT tradicional) RFC 1918 - Asignacin de direcciones para Internets privadas

Como configurar un gateway simple con Linux Debian

11/06/2007 By fher98 Cuando una empresa cuenta con una conexin de banda ancha hacia Internet y se busca compartir dicha conexin entre las diferentes oficinas, muchas veces se piensa que es necesario comprar un equipo de firewall dedicado, lo cual es un error. En este articulo demostraremos que con el minimo de inversion y utilizando Linux Debian podemos ofrecer a nuestra red mejores servicios que al adquirir un equipo de firewall. La adquisicin de dicho hardware puede ser demasiado costosa para muchas empresas guatemaltecas, en cambio al utilizar una maquina dedicada con un Linux Debian instalado y sirviendo como gateway para la LAN, nos ofrece muchos beneficios al compararlo contra un equipo de firewall dedicado. Para empezar, es mucho mas flexible y adems nos permite ofrecer muchos servicios extras a nuestras red. Para correr una gateway (pasarela) con Debian es necesario una maquina con dos tarjetas de red, y que la tarjeta externa pueda rutear correctamente hacia el ISP. (ver articulo) En esta oportunidad, tomaremos la interfaz de red eth0 para que sirva directamente a la red interna, esta tarjeta que tendr una direccin IP clase C mas o menos as: 192.168.1.1, la cual sera la que utilizaremos como default gateway para nuestras maquinas internas. Esto nos deja la eth1 para la direccin externa de la maquina.

Para que dicha maquina funcione como un gateway y rutee los paquetes desde nuestra LAN hacia el mundo exterior y de regreso, necesitamos que tenga habilitado el bit de IP forwarding, adems de las reglas necesarias para que pueda enrutar paquetes. Esto se hace va iptables. Bsicamente necesitamos tener tres juegos de reglas:

Denegar las conexiones entrantes en eth1 (la interfaz de red externa) Permitir los paquetes salientes desde nuestra LAN, va eth0 Permitir que las conexiones establecidas regrese.

Con este fin creamos el siguiente script:

archivo: 00-firewall #Publicado bajo licencia GPL by www.guatewireless.org #!/bin/sh PATH=/usr/sbin:/sbin:/bin:/usr/bin # # borrando todas las reglas existentes. # iptables -F iptables -t nat -F iptables -t mangle -F iptables -X # Siempre acepte el trafico desde loopback iptables -A INPUT -i lo -j ACCEPT # Permitir conexiones establecidas, y las que no vengan desde fuera. iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -m state --state NEW -i ! eth1 -j ACCEPT iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT # Permitir conexiones salientes desde adentro de la LAN. iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT # Enmascarar. iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE # No forward de afuera hacia adentro. iptables -A FORWARD -i eth1 -o eth1 -j REJECT # Habilite ruteo. echo 1 > /proc/sys/net/ipv4/ip_forward

Es necesario que este script corra al arrancar el sistema y tan pronto como las interfaces de red se levanten. Para este propsito se puede guardar en el directorio /etc/network/ifup.d/. Todo lo que se encuentre en ese directorio es ejecutado cuando una interfase se levanta, siempre y cuando el archivo sea ejecutable. Debido a que los contenidos del directorio son ejecutados en orden, nombraremos el script 00-firewall. Esto nos proveer con un gateway bsico. Ahora cualquier maquina dentro de la LAN deber ser capaz de accesar Internet, mientras el gateway se mantiene seguro. Ahora debemos pensar en agregar servicios extras para nuestra LAN, desde el gateway claro. Existen un par de cosas interesantes que se pueden agregar para hacernos la vida mas fcil, por ejemplo en lugar de asignar una direccin IP fija a cada maquina dentro de la LAN, podemos utilizar una asignacin dinmica utilizando DHCP. As mismo podemos instalar un servidor de nombres local, con esto podremos reconocer nuestras maquinas en la red interna. Un excelente paquete para eso es dnsmasq. El cual se puede instalar va apt-get y se configura va un simple archivo /etc/dnsmasq.conf. Una vez este paquete de software este corriendo, podremos observar que las maquinas cliente pueden buscar cualquier host en la red que este incluido en el archivo /etc/hosts dentro del servidor. Con lo anterior podremos nombrar con aliases las maquinas de la red y sern resueltas fcilmente. Por ejemplo, al instalar un servidor proxy en el gateway podemos crearle un nombre:
archivo: /etc/hosts # 127.0.0.1

localhost

# # Maquinas locales. # 192.168.1.1 gateway gateway.guatewireless.net proxy proxy.guatewireless.net

Esto nos asignara el nuevo nombre proxy para la maquina anteriormente conocida como prince, digo gateway.-

Script para limpiar todas las reglas de IPTables

28/02/2011 By fher98 Les voy a pasar un programita o script de Linux para poder botar o eliminar las reglas el firewall local. Es algo sencillo y practico para no estar tecleando cada linea de iptables. Dentro del directorio /scripts creamos un archivo llamado, clear_iptables.sh con el siguiente contenido;
#!/bin/sh echo "Deteniendo el corta fuegos y permitiendo todo el trafico..." /sbin/iptables -P INPUT ACCEPT /sbin/iptables -P FORWARD ACCEPT /sbin/iptables -P OUTPUT ACCEPT /sbin/iptables -F /sbin/iptables -X /sbin/iptables -t nat -F /sbin/iptables -t nat -X /sbin/iptables -t mangle -F /sbin/iptables -t mangle -X /sbin/iptables -L -n

Ahora lo hacemos ejecutable y listo, ya podemos darle flush rapidamente a las reglas de iptables en un solo comando.
root@gateway:~# chmod +x /scripts/clear_iptables.sh root@gateway:~# ./scripts/clear_iptables.sh Chain INPUT (policy ACCEPT) target prot opt source Chain FORWARD (policy ACCEPT) target prot opt source Chain OUTPUT (policy ACCEPT) target prot opt source destination destination destination