Redes TCP/IP bajo Unix

Conceptos bsicos de Operacin y Administracin.

por Ing. Fernando A. Cuenca (andres@bbs.frc.utn.edu.ar) Laboratorio de Sistemas - UTN Facultad Crdoba

Introduccin
El presente trabajo persigue 2 objetivos: en primer lugar, presentar al lector las posibilidades que ofrece un ambiente de red basado en Unix; en segundo lugar, introducirlo en los conceptos bsicos requeridos para administrar una red TCP/IP bajo el citado sistema operativo1. No obstante lo anterior, se hacen dos aclaraciones al lector: Se asumir que el lector posee conocimientos bsicos de la terminologa empleada en tecnologa de redes (LAN vs WAN, topologas, medios de transmisin, protocolos, conmutacin por paquetes, etc.). "Lo maravilloso de los estndares es que hay muchos de donde elegir" -- Almirante Grace Murray Hooper2. Uno de los grandes mitos acerca de Unix es su nivel de estandarizacin. Si bien todas las diversas variantes (o flavors) de Unix comparten una filosofa comn muy amplia lo cual hace posible un alto grado de similitud entre todas ellas, en el momento de afinar los detalles de la implementacin suelen aparecer discrepancias (en particular, los nombres de los comandos, el formato y nombre de los parmetros, el formato de los resultados que se muestran por pantalla, etc.). Para ste articulo se tomar al sistema operativo Linux (una variante de Unix de distribucin gratuita) como plataforma de referencia; ser tarea del lector identificar las diferencias con su propia plataforma y realizar las adaptaciones del caso.

Cabe aclarar, sin embargo, que la mayora de los conceptos que se desarrollarn en el captulo de Administracin son aplicables a casi todas las implementaciones de TCP/IP bajo otras plataformas. 2 La Almirante Grace Hooper particip en el diseo del lenguaje COBOL, durante la dcada del 60.

Conectndose a Unix
Terminales "bobas", Workstations y PCs
El sistema operativo Unix fue concebido en los aos 70. En aquellos tiempos, el modelo imperante para los sistemas de computacin era el que lleg a conocerse como "de tiempo compartido", en donde un equipo central con capacidad de multiprogramacin (conocido como host) atenda simultneamente a mltiples usuarios conectados al mismo desde terminales remotas ubicadas en el mismo edificio o en otras locaciones conectadas al mismo a travs de una red de
Figura 1: Computador PDP-8

comunicaciones.

Dichas terminales estaban constituidas bsicamente por un teclado, una pantalla y un dispositivo de comunicaciones (usualmente de tipo serial, por ejemplo basado en RS-232), y se denominaban "terminales bobas" (dumb terminals) debido a que carecan por completo de capacidad de procesamiento, mas all de la necesaria para tomar caracteres desde el teclado, enviarlos al equipo central por el vnculo de comunicaciones y recibir desde l nuevos caracteres que desplegar en la pantalla. De esta forma, resultaban meros dispositivos de interface entre el usuario y un proceso en ejecucin en la computadora central.
Figura 2: Terminal VT100

Luego, durante el transcurso de la dcada del 80 y conforme los costos de la tecnologa de computacin disminuan crecientemente, fue creciendo una nueva concepcin tendiente a llevar poder de procesamiento ms cerca del usuario. Por una parte, las PC (Computadoras Personales) aparecieron en escena y rpidamente empezaron a poblar las oficinas y mas tarde los hogares. Aquellas organizaciones que se vieron en la situacin de enfrentar la coexistencia de equipos personales con centralizados encontraron que podan aprovechar lo mejor de ambos mundos permitiendo el acceso desde las PCs a las aplicaciones y datos corporativos corriendo bajo Unix, por medio de conexin de las PCs al host Unix a travs de conexiones seriales y la ejecucin en la PC de un software emulador de terminal. Dichos programas constituyen bsicamente una terminal boba implementada en software, que utiliza el hardware de la PC de manera tal que la misma se comporta como si se tratara de una terminal corriente (es decir, solo procesa entradas y salidas por teclado y pantalla, quedando el procesamiento de la aplicacin en manos del equipo central). Por otra parte, en los ambientes de ingeniera e investigacin, empezaron a aparecer potentes computadoras personales basadas en Unix y construidas, usualmente, con tecnologa RISC, denominadas workstations (estaciones de trabajo). Si bien estos equipos corran bsicamente el mismo Unix que los equipos centralizados, explotaban ms sus capacidades de multiprocesamiento que la de atender mltiples usuarios simultneos; es decir, se trataba de equipos con mucho potencial de clculo, especialmente pensado para aplicaciones de ingeniera o cientficas, operados por un nico usuario desde la consola (pantalla y teclado conectado directamente al equipo), siendo muy poco usual que se las conectara a terminales seriales a ser utilizadas por otros usuarios, a pesar de que el sistema operativo soportaba esta modalidad de trabajo.

Si bien el pasar de equipos centralizados compartidos a equipos personales individuales trajo como beneficio un mayor poder de procesamiento y flexibilidad para los usuarios, se llev consigo una de las ventajas de la computacin centralizada: la posibilidad de compartir recursos. Es por ello que la dcada del 80 no slo es la dcada de la computacin personal, sino tambin la de la popularizacin y crecimiento de las redes de rea local (denominadas LAN). La idea de interconectar equipos en redes no era nueva; sin embargo, los esfuerzos de investigacin y desarrollo en tal sentido se orientaban mas bien a la interconexin de equipos ubicados en locaciones distantes entre s, formando redes de rea amplia (conocidas como WAN), ya que el "rea local" estaba dominada por equipos de conexin centralizada. En el caso particular de Unix, la tcnica de interconexin que se volvi standard fue la basada en una familia de protocolos de comunicaciones denominada TCP/IP, mediante la cual dos equipos Unix interconectados podan intercambiar datos y permitir a usuarios conectados a uno de ellos iniciar nuevas sesiones de trabajo en el otro. Cuando las workstations aparecieron en la escena a mediados de la dcada del 803, result natural que estuvieran preparadas con capacidades de conectividad en red. No obstante, el tipo de conectividad requerida no era a nivel WAN sino a nivel LAN, a fin de que pudieran interactuar con otras workstations y con equipos centralizados de mayor porte disponibles en la organizacin. Se volvi entonces practica standard entre los fabricantes de workstations que las mismas contaran con capacidad de conectividad TCP/IP y hardware para conexin a una red LAN, utilizando la norma Ethernet, que finalmente termin por convertirse en el standard para redes de estas caractersticas. De sta manera, un usuario poseedor de una workstation podra ejecutar localmente sus aplicaciones y al mismo tiempo iniciar sesiones de trabajo remotas Figura 3: en los servidores corporativos (y, por supuesto, en otras Workstation Sun 4 workstations disponibles en la red ). Al mismo tiempo, las PCs fueron ganando terreno en el mbito de las redes LAN (y, de hecho, resultaron finalmente sus principales impulsores). Sin embargo, no fue hasta mediados de los 90 con la masificacin del acceso a servicios Internet (la red TCP/IP por excelencia) que TCP/IP se volvi un componente obligado del software de red de stas computadoras, desplazando a otros protocolos como IPX y NetBIOS, que dominaron la escena de las LAN entre PCs durante aos. Como resultado, hoy puede utilizarse una PC de bajo costo para acceder a servicios de datos y sesin remota sobre servidores Unix, de manera anloga a la que se utilizara desde una workstation.

El Sistema X-Window
Cabe mencionar finalmente otro tipo de conexin a sistemas Unix, para el cual hay que analizar previamente el formato con que esas conexiones pueden realizarse. Tradicionalmente, las terminales bobas fueron dispositivos "de caracteres", que permitan conexiones en modo texto. Las primeras terminales eran extremadamente primitivas; denominadas "ttys de vidrio", bsicamente eran variaciones de los teletipos (de all la denominacin "tty") y nicamente permitan desplegar lneas de caracteres y producir avances de carro, sin que el programador tuviera control alguno sobre el formateo y ubicacin de dichos caracteres en la pantalla. Con el tiempo, fueron evolucionando hasta eliminar esas limitaciones (se transformaron en terminales "de pantalla completa") y agregaron nuevas capacidades como
Figura 4: Terminal "de copia dura" o teletipo
3 4

La primera workstation fue lanzada al mercado por Sun Microsystems en 1983. Esta concepcin del trabajo en red llev a Sun a acuar el slogan "The network is the computer" ("La computadora es la Red").

diferentes estilos (caracteres parpadeantes, remarcados, subrayados, etc.), diferentes juegos de caracteres, caracteres grficos, etc. Pero continuaron siendo terminales capaces de mostrar solamente texto. Mientras esto ocurra en el mbito comercial, el MIT (Instituto de Tecnologa de Massachusetts) se encontraba trabajando en el Proyecto Athena. Uno de los resultados de ese proyecto fue un "sistema de presentacin grfica distribuida". La idea consista en permitirle a un programa, llamado cliente, ejecutarse en una computadora y enviar su salida (ya fuera esta texto o grficos) por medio de enlaces TCP/IP a otro programa, llamado servidor de ventanas (window server), en ejecucin en la misma u otra computadora. Las computadoras del cliente y el servidor podran ser inclusive totalmente diferentes (en hardware y/o sistema operativo), en tanto y en cuanto ambas estuvieran interconectadas de alguna manera por TCP/IP e implementaran un protocolo especial denominado protocolo X. El conjunto resultante se denomin Sistema X-Window, en el cual la funcionalidad de la aplicacin se divide entre el Server-X (o servidor de ventanas) que tiene a cargo la administracin de los recursos fsicos de presentacin (es decir, manipula los recursos del hardware de visualizacin, las entradas por teclado y los eventos del mouse) al cual se conectan mltiples Clientes-X (es decir, las aplicaciones que el usuario ejecuta sobre el equipo central), vinculadas las mismas al Server-X por medio de enlaces TCP/IP. Una de las aplicaciones de X-Window fue permitir la creacin de un nuevo tipo de terminales, conocidas como X-Terminals. Una X-Terminal es bsicamente una terminal boba en el sentido de que no procesa localmente las aplicaciones del usuario, pero la principal diferencia es que le ofrecen una interfaz grfica altamente sofisticada. Para ello, una X-Terminal implementa el protocolo X y cuenta con un window server. Cuando el usuario, por medio de una X-Terminal, lanza una aplicacin, la misma se ejecuta en el host, excepto las operaciones de dibujo sobre la pantalla y la captura de eventos de teclado y mouse, que son ejecutadas por el Server-X localmente en la XFigura 5: Terminal Terminal. En otras palabras, cuando el Cliente-X requiere X de Tektronics desplegar algn tipo de informacin por pantalla, le enva una peticin al Server-X para que la lleve a cabo; de la misma manera, no es la aplicacin la que realiza la lectura de teclado y la captura de eventos del mouse, sino que dicha operacin la realiza en Server-X (sobre la X-Terminal) para luego notificar al Cliente-X (en el host) cuando los eventos eventualmente ocurren. Todo ese dilogo entre el Cliente-X y el Server-X se materializa en forma de mensajes TCP/IP. Por otra parte, X-Window se volvi un componente infaltable de las workstations. XWindow es un sistema de ventanas cliente/servidor. Una de las ventajas del modelo cliente/servidor es que puede ser implementado tanto de manera distribuida (es decir, cliente y servidor ejecutndose en computadoras diferentes) como local (cliente y servidor ejecutndose en la misma computadora), debido a que lo nico que establece es que deben existir dos procesos (el cliente y el servidor) unidos a travs de un canal de comunicaciones. Para el caso de X-Window, esto significa que tanto el Server-X como el Cliente-X podran eventualmente ejecutarse en la misma computadora, tal como ocurre en una workstation. Finalmente, y dado que ya en el espritu inicial de los diseadores de X-Window estaba embebido el concepto de independencia de plataforma entre el Cliente-X y el Server-X, result natural la eventual aparicin de Servidores-X para plataformas completamente diferentes de Unix, tal como MS-Windows. Ello posibilit utilizar una mquina Windows como si fuera una X-Terminal, una estrategia anloga a la utilizada anteriormente por medio de emuladores de terminal.

En resumen...
Se han reseado varias formas para conectarse a un host Unix:

Por medio de una terminal boba conectada al host a travs de un vnculo serial (directo o indirecto -- como por ejemplo, un mdem); Por medio de una PC, un programa emulador de terminal y un vnculo serial al host (nuevamente, directo indirecto); Por medio de conexiones TCP/IP a travs de una red LAN o WAN, desde otro host Unix, una workstation, una PC o cualquier otro tipo de computadora que cuente con software TCP/IP. Desde una X-Terminal o una computadora (PC, workstation, etc.) que implemente el protocolo X5.

Este tipo de conexin es estrictamente otra forma de conexin TCP/IP. Se la menciona por separado debido a que su formato es radicalmente diferente al de las conexiones TCP/IP mas conocidas (como por ejemplo, conexiones va telnet).

Trabajando en una red Unix

Se discutirn a continuacin algunas de las actividades ms usuales que se realizan al trabajar en el entorno de una red TCP/IP bajo Unix:

Sesiones remotas Transferencia de archivos Ejecucin remota Comunicacin entre usuarios

A los fines de la ejemplificacin, se asumir que el entorno en el que est trabajando un usuario cuyo login name es jperez es el que se muestra en la figura siguiente, y que dicho usuario est actualmente conectado al host Antares, y que dispone de acceso a cuentas de usuario en el host Canopus, ambos corriendo alguna versin de Unix:

Canopus Red Local

Antares

Sesiones remotas
Iniciar una sesin remota significa conectarse desde una computadora a otra, a travs de una red de comunicaciones, a los fines de ejecutar procesos a la distancia. En otras palabras, por medio de sesiones remotas es posible trabajar en una computadora operndola remotamente desde otra, ubicada quizs a grandes distancias; a los fines prcticos, resulta equivalente a estar sentado en la consola del sistema remoto. En nuestro ejemplo, si el usuario jperez que se encuentra conectado a la computadora Antares inicia una sesin remota en Canopus, a partir de ese momento todo comando que ejecute lo har en el procesador de Canopus. Cabe aclarar que el acceso a un host Unix desde una terminal serial no se considera una sesin remota, por mas lejana que se encuentre fsicamente ubicada la terminal. Las sesiones remotas entre sistemas Unix se realizan por medio de la ejecucin de programas basados en TCP/IP, como los descriptos en las secciones siguientes.

Arquitectura de una sesin remota

Los programas de sesin remota bajo Unix trabajan segn un esquema cliente/servidor, en el cual el usuario que desea iniciarla ejecuta localmente en su computadora un programa (el cliente) al cual le indica el nombre del host en el cual se iniciar la sesin. Dicho programa se comunica por medio de TCP/IP con otro ejecutndose en background en la computadora de destino (el servidor), el cual, luego de autenticar la identidad del usuario y verificar que tiene permiso para utilizar el servicio, inicia un shell para interpretar los comandos que enve el usuario remoto:

Shell local

Cliente de sesin remota

Servidor de sesin remota

Shell remoto

El servidor de sesin remota asocia el shell remoto con una terminal virtual (o pseudo-tty) cuyas entradas y salidas estn asociadas a una conexin de red. As, todo lo que el usuario teclee en su terminal ser capturado por el cliente de sesin remota y enviado a travs de la red al shell remoto; de manera similar el shell remoto enviar la salida de los comandos al usuario por la misma conexin de red. Cuando el usuario ejecute el comando para terminar el shell (usualmente, exit o Control-D), el shell remoto finaliza y la sesin remota se cierra.

Sesiones remotas utilizando rlogin

rlogin es el comando de sesin remota nativo de Unix. Su sintaxis bsica es la siguiente: rlogin nombre_de_host Al ser invocado de esa forma, rlogin intenta iniciar una sesin remota en el host indicado, bajo el mismo nombre de usuario actual, previo ingreso de la palabra clave: jperez@antares:$ rlogin canopus Password: Last login: Mon Feb 10 15:30:45 from orion. jperez@canopus:$ _

Si la clave es ingresada correctamente, la sesin remota se inicia, rlogin informa la fecha y origen del ltimo ingreso al sistema y, a partir de ese momento, el usuario puede ejecutar comandos en la mquina remota, obteniendo la salida de los mismos en el host local. Para cerrar la sesin, basta con ingresar el comando normal para finalizar el shell remoto, por ejemplo, exit: jperez@canopus:$ exit Conection closed. jperez@antares:$ _

Si se desea iniciar una sesin remota bajo otra identidad (es decir, entrado como otro usuario), el login name correspondiente puede indicarse utilizando el comando -l: jperez@antares$ rlogin -l plopez canopus Password: plopez@canopus$ _

Como ya se dijo, rlogin pide la contrasea de la cuenta remota antes de permitir el acceso al shell. Sin embargo, es posible configurar rlogin de manera que considere equivalentes dos cuentas y no pida password para iniciar sesiones. Continuando con el ejemplo anterior, si el usuario jperez tiene cuenta tanto en Antares como en Canopus, para evitar que se le pida password al iniciar una sesin remota con rlogin deber crear en su directorio de login de la mquina remota un archivo llamado .rhosts, y en el mismo listar los nombres de las

computadoras desde donde desea entrar sin password. Tambin podra otorgar acceso libre a otros usuarios, listando los nombres de login a continuacin del nombre de mquina. Por ejemplo, si el archivo .rhosts ubicado en el directorio de conexin de jperez en Canopus contuviera la siguiente informacin: antares orion plopez ello indicara que el usuario jperez puede entrar a Canopus sin password desde Antares, mientras que el usuario plopez podr hacer lo mismo desde Orin. Cabe destacar que el uso del archivo .rhosts es un serio compromiso a la seguridad de la cuenta y es un recurso que debe ser utilizado con mucha precaucin; en el ejemplo anterior, si alguien ganara acceso a la cuenta de jperez en Antares, automticamente podra entrar a la cuenta de Canopus. Como medida extra de seguridad, rlogin solo prestar atencin al archivo .rhosts si el mismo solo puede ser accedido por el usuario (es decir, si su modo es rw------- 600 en octal).

Sesiones remotas utilizando telnet

El comando rlogin fue diseado teniendo en cuenta que tanto el host local como el remoto son mquinas corriendo Unix6. A fin de permitir sesiones remotas entre equipos con sistemas heterogneos, fue diseado otro protocolo denominado TELNET. Bajo Unix, puede establecerse una conexin TELNET con el siguiente comando: telnet nombre_de_host La principal diferencia entre telnet y rlogin es que el primero de estos siempre pide usuario y password para iniciar la sesin: jperez@antares:$ telnet canopus Trying 170.25.1.5 Connected to canopus.galaxia.org.ar Escape character is '^]' Login: jperez Password: Last login: Mon Feb 10 15:30:45 from orion. jperez@canopus:$ _

Aqu puede verse que el usuario jperez inicia una sesin de TELNET hacia Canopus. telnet inicialmente informa que est intentando establecer la conexin con el host remoto (lnea Trying....) y luego de unos segundos indicar que la conexin se ha establecido con xito (lnea Connected.....). Seguidamente, telnet informa al usuario cual es el carcter de escape, y pide el nombre de usuario y palabra clave para ingresar al host remoto. El carcter de escape (que usualmente es Control-]) es un carcter que es interceptado por el programa telnet ejecutndose en el host local, y no es enviado al host remoto como el resto de los caracteres tipeados por el usuario. Se utiliza para llamar la atencin del programa telnet, el cual responde con un prompt y queda a la espera de comandos: jperez@canopus:$ ^-] telnet> _
6

Estrictamente, rlogin asume que ambos extremos de la conexin de red ejecutan el demonio identd, que permite identificar el propietario de conexiones TCP.

Existen varios comandos que pueden utilizarse aqu, pero el mas usual es el comando exit, utilizado para cortar la conexin, o ! (signo de admiracin) que permite iniciar un subshell en el host local.

Sesiones remotas utilizando ssh

Tanto telnet como rlogin utilizan protocolos de comunicacin abiertos, en el sentido de que todos los datos se transmiten sin ningn tipo de proteccin por encriptado. Esto significa que cualquier otra persona que tenga acceso al medio fsico de transmisin podra (con los conocimientos y herramientas apropiadas) interceptar las transmisiones y eventualmente obtener todo aquello que el usuario tipea en su terminal (especialmente, el nombre de usuario y la password) y las respuestas que enva el host remoto. Esto hace que el uso de telnet o rlogin sea inapropiado cuando es necesario un nivel de absoluta seguridad y privaca, especialmente cuando las comunicaciones se realizan a travs de largas distancias (por ejemplo, a travs de la Internet). Para superar esos inconvenientes, puede utilizarse como alternativa el sistema ssh (por Secure Shell, o Shell Seguro), el cual provee de un esquema de seguridad mucho mas sofisticado y encripta toda el intercambio de datos entre el host local y el remoto. La sintaxis bsica7 de ssh es igual a la de rlogin, es decir: ssh [-l nombre_de_usuario] nombre_de_host en donde la indicacin del nombre de usuario (a travs del parmetro -l) es opcional y se asume el login name actual por defecto.

Transferencia de archivos
Los protocolos para transferencia de archivos permiten copiar archivos entre dos computadoras, a travs de una red. Se vern a continuacin tres programas para transferencia de archivos: ftp, rcp y scp.

Transferencia de archivos por ftp

La principal diferencia entre ftp y los otros comandos radica en el carcter interactivo de ste comando. Esto significa que ftp funciona a la manera de un shell: primeramente establece la conexin con el sistema remoto y luego queda a la espera de que el usuario le indique, por medio de un lenguaje de comandos, las operaciones a realizar. Para iniciar una sesin FTP, debe ejecutarse en comando ftp indicndole como parmetro el nombre de la computadora remota, por ejemplo: jperez@antares:$ ftp canopus Connected to canopus.galaxia.org.ar 220 canopus.galaxia.org.ar FTP server ready. Name(antares:jperez): jperez 331 Password required for jperez. Password: 230 User andres jperez in. Remote system type is UNIX. Using binary mode to transfer files.
7

Ssh ofrece sofisticados mecanismos de seguridad adicionales al tradicional esquema de seguridad basado en palabra clave, como frases clave de acceso, certificados de identidad y varios mtodos de autenticacin. Para mayores detalles, refirase a la documentacin provista por el software.

ftp> _

Aqu, el usuario jperez inicia una conexin FTP a Canopus. Luego de indicar que la conexin se ha establecido y que el servidor FTP se encuentra listo, ftp pide el nombre de usuario con el que se va a ingresar al host remoto, y luego su correspondiente password. Si la misma se ingresa correctamente, el sistema remoto informa su tipo (en este caso, UNIX) y el modo de transferencia de archivos por defecto (en este caso, transferencia binaria) y queda a la espera de comandos del usuario. Adicionalmente de permitir la transferencia de archivos hacia cuentas del sistema remoto (esto es, la conexin se establece indicando una identidad de usuario registrada en el host remoto e ingresando la palabra clave de esa cuenta), ftp fue diseado para permitir el acceso de usuarios annimos a grandes repositorios de archivos, de acceso pblico. Usualmente los servidores FTP utilizan el nombre de usuario anonynmous para los accesos del pblico en general, quienes debern utilizar su direccin de correo electrnico como password: jperez@antares:$ ftp canopus Connected to canopus.galaxia.org.ar 220 canopus.galaxia.org.ar FTP server ready. Name(antares:jperez): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: jperez@canopus.galaxia.org.ar 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> _

Los dos comandos bsicos de FTP para transferencia de archivos son put (para enviar un archivo al host remoto) y get (para obtener un archivo desde el host remoto). Ambos operan con un nico archivo indicado como parmetro, desde y hacia el directorio actual (tanto local como remoto). Por ejemplo, el siguiente comando: ftp> put informe.doc local: informe.doc remote: informe.doc 200 PORT command successful. 150 Opening BINARY mode data connection for informe.doc. 226 Transfer complete. 1908642 bytes sent in 2.34 secs (13.22 Kbytes/sec) ftp> _

transfiere el archivo informe.doc desde el directorio actual local (esto es, el directorio desde el cual se invoc al programa ftp en el host local) al directorio actual en la computadora remota. Luego de la transferencia, ftp informa la cantidad de bytes transmitidos y la velocidad de la transferencia. Por otra parte, el comando: ftp> get informe.doc local: informe.doc remote: informe.doc 200 PORT command successful. 150 Opening BINARY mode data connection for informe.doc. 226 Transfer complete. 1908642 bytes received in 2.34 secs (13.22 Kbytes/sec) ftp> _

10

El directorio actual en la computadora remota puede averiguarse por medio del comando pwd: ftp> pwd 257 "/home/jperez" is current directory. ftp> _

y puede cambiarse utilizando el comando cd, e indicando una trayectoria absoluta o relativa (de manera totalmente anloga al comando cd del shell): ftp> cd documentos 250 CWD command successful. ftp> pwd 257 "/home/jperez/documentos" is current directory. ftp> _

FTP cuenta con un extenso juego de comandos, cuya lista puede obtenerse tipeando ?. Se ofrece a continuacin un resumen de algunos comandos de utilizacin frecuente: ls binary ascii lcd delete hash mput mget prompt off Lista el contenido del directorio actual Fuerza el modo de transferencia a BINARIO Fuerza el modo de transferencia a ASCII (poco recomendable!) Cambia (o muestra) el directorio actual local Borra un archivo en el host remoto Muestra por pantalla una marca cada cierta cantidad de bytes transmitidos Permiten realizar transferencias mltiples, por medio de la utilizacin de comodines Deshabilita la confirmacin archivo por archivo en las transferencias mltiples

La sesin de FTP finaliza cuando el usuario indica el comando bye: ftp> bye 221 Goodbye. jperez@antares:$ _

Transferencia de archivos por rcp y scp

Los comandos rcp y scp son utileras de lnea de comandos para transmitir archivos; esto es, no reciben comandos interactivamente desde el usuario, sino que su funcionamiento se indica por medio de parmetros en la lnea de comandos del shell. Es esta caracterstica lo que, al contrario que ftp, los hace tiles para la programacin de scripts que realicen transferencias automticas de archivos entre computadoras. rcp pertenece al mismo paquete de comandos que rlogin, mientras que scp pertenece al de ssh. As la diferencia entre ambos radica en el nivel de seguridad: rcp transfiere los archivos en su formato original, mientras que scp lo hace de manera encriptada. Ambos comandos tienen la misma sintaxis: rcp [-l nombre_de_usuario] origen destino scp [-l nombre_de_usuario] origen destino en donde el parmetro -l es opcional, sirviendo para acceder al host remoto bajo otro nombre de usuario. Los parmetros origen y destino son las especificaciones
11

(expresadas como trayectorias absolutas o relativas) del archivo a transmitir y la ubicacin final del mismo respectivamente; uno de ellos deber hacer referencia a la computadora local, mientras que el otro deber referirse a la computadora remota. La sintaxis para archivos remotos es la siguiente: nombre_del_host_remoto:[[trayectoria]archivo] Como puede verse, la nica parte mandatoria es el nombre del host remoto; si el resto se omite, el archivo transmitido ser copiado bajo el mismo nombre en el directorio de login del usuario en la computadora remota. Si el nombre de archivo se omite, la copia se har en el directorio remoto indicado bajo el mismo nombre; si la trayectoria especificada es relativa, se interpretar como relativa al directorio de login del usuario en la computadora remota. Por ejemplo, los siguientes comandos transfieren archivos de la maquina local al host remoto Canopus: $ scp informe.doc canopus: Copia el archivo informe.doc (ubicado en el directorio actual) al directorio de login en Canopus, con el mismo nombre $ rcp notas/informe.doc canopus:notas/ Copia el archivo informe.doc, bajo el directorio notas al directorio notas bajo el directorio de login de la maquina remota $ scp informe.doc canopus:/usr/informes/info1.doc Copia el archivo informe.doc, al directorio remoto /usr/informes con el nombre info1.doc Para transferir desde el host remoto al host local, los comandos seran los siguientes: $ rcp canopus:informe.doc . $ rcp canopus:notas/informe.doc notas/ $ scp canopus:/usr/informe.doc info1.doc

scp siempre pide password antes de realizar la copia; rcp, por su parte, requiere que el usuario haya configurado su cuenta remota para accederla sin solicitar password, por medio del archivo .rhosts (tal como se describe en la seccin de rlogin)

Ejecucin remota
Los comandos para ejecucin remota permiten ejecutar un nico comando en un host remoto, obteniendo su salida en el host local. El comando tradicionalmente utilizado para este tipo de operaciones era rsh. Este comando completa la familia formada por rlogin y rcp, y al igual que este ltimo, requiere de la existencia del archivo .rhosts en el directorio de conexin remoto a fin de poder operar. Su sintaxis es la siguiente: rsh [-l nombre_de_usuario] host comando Por ejemplo, el siguiente comando obtiene un listado del directorio de conexin de un host remoto:
jperez@bbs:~$ rsh canopus ls -l total 13 drwxr-xr-x 5 jperez jperez -rw-rw-r-1 jperez jperez drwxrwxr-x 2 jperez jperez drwxrwxr-x 3 jperez jperez drwx-----2 jperez jperez

1024 1376 1024 1024 1024

Sep Sep Oct Oct Sep

26 28 13 29 23

11:58 15:16 16:53 19:48 12:21

GNUstep Xrootenv.0 bin download mail

12

drwxrwxr-x 2 jperez drwxr-xr-x 3 jperez -rw-r--r-1 jperez drwxrwxr-x 6 jperez drwxrwxr-x 9 jperez jperez@bbs:~$ _

jperez jperez jperez jperez jperez

1024 1024 198762 1024 1024

Jul 2 14:34 mnt Jun 30 19:36 ns_imap Nov 1 20:46 informe.doc Oct 22 21:38 temp Oct 29 19:49 trabajo

Se aplican a este comando las mismas consideraciones de seguridad que se discutieron para rlogin, por lo que si la seguridad es crtica, puede ser reemplazado por el comando ssh, que ofrece un modo de funcionamiento similar: ssh [-l nombre_de_usuario] host comando con la diferencia que utiliza mecanismos de seguridad avanzada para autenticar al usuario y realiza conexiones encriptadas.

Comunicacin entre usuarios

Unix es un sistema de naturaleza multiusuaria, es decir, soporta mltiples usuarios conectados simultneamente, ejecutando procesos concurrentemente. En consecuencia, ofrece comandos que permiten a los usuarios comunicarse entre si, ya sea en tiempo real o de manera diferida.

Averiguando quien est conectado: finger

Antes de poder entablar una comunicacin, es necesario saber quin est conectado al sistema. Normalmente, el comando para realizar dicha operacin era who. Sin embargo, este comando solo informa acerca de los usuarios conectados al sistema local. Si se desea saber quin est conectado a un host remoto debe utilizarse el comando finger:
jperez@antares:$ finger @canopus [canopus.galaxia.org.ar] Login Name Tty plopez Pedro Lopez 1 fcuenca Fernando Cuenca p1 arodrig Andrea Rodriguez p2 jperez@antares:$

Idle 20m 20m

Login Feb 1 Feb 1 Feb 1

Time 20:36 14:08 20:36

Observar que el nombre del host remoto debe precederse de un signo @. De manera similar, finger permite obtener informacin sobre un usuario (local o remoto). Por ejemplo, si se quieren conocer los datos del usuario plopez del host local, puede utilizarse el siguiente comando: jperez@bbs:~$ finger plopez Login: plopez Name: Pedro Lopez Directory: /home/plopez Shell: /bin/sh Last login Fri Oct 30 23:16 (ARDT) on tty1 New mail received Sun Nov 1 19:08 1998 (ARDT) Unread since Sun Nov 1 17:45 1998 (ARDT) finger informa el nombre completo del usuario, su directorio de login y shell, la fecha y ubicacin de la ltima conexin al sistema, e informacin sobre el correo electrnico del usuario. Tambin pueden obtenerse datos de usuarios de otras computadoras, utilizando la sintaxis usuario@computadora: jperez@bbs:~$ finger arodrig@canopus Login: arodrig Name: Andrea Rodriguez Directory: /home/arodrig Shell: /bin/sh
13

Last login Sun Feb 10 15:09 (ARDT) on tty5 New mail received Mon Nov 1 14:33 1998 (ARDT) Unread since Tue Jan 24 11:14 1998 (ARDT)

Comunicndose con talk

Unix permite realizar charlas en tiempo real con usuarios conectados al sistema local o a sistemas remotos, por medio del comando talk. Por ejemplo, si el usuario jperez, conectado a Antares, quisiera entablar una charla con arodrig, conectada a Canopus, debera ejecutar el siguiente comando: talk arodrig@canopus

arodrig recibir un aviso en su pantalla y, si desea entablar la comunicacin, deber replicar con el siguiente comando: talk jperez@antares

tras lo cual la conexin quedar establecida. Ambos vern en sus pantallas lo que el otro escribe, hasta que alguno de ellos finalice la sesin con Control-C.

Correo electrnico
Talk permite comunicaciones en tiempo real; sin embargo, muchas veces es necesario enviar un mensaje a un usuario que no se encuentra actualmente conectado. Para ello puede utilizarse el correo electrnico. El comando standard para enviar correo electrnico entre sistemas Unix es mail, cuya sintaxis es la siguiente: mail usuario[@computadora] Obsrvese que la especificacin del nombre de la computadora es opcional; si se omite, se asumir que se est enviando correo a otro usuario del sistema local. Al ser ejecutado, el comando mail solicita primeramente al usuario que ingrese el tema del mensaje, y luego lee desde la entrada standard el texto del mensaje, hasta recibir la marca de fin de archivo (Control-D): jperez@antares:$ mail plopez@canopus Subject: Reunion semanal Hola, Le comunico que la reunin semanal tendr lugar el prximo mircoles a las 15 el la Sala de Reuniones D. Por favor, concurra con el informe de avance. ^D jperez@antares:$ _ Un problema frecuente al trabajar en una red Unix, es que los usuarios normalmente tienen cuenta en mas de un host. Ello puede provocar que su correspondencia se vea diseminada entre sus mltiples casillas de correo (una en cada host en los que se tiene cuenta). Para solucionar esta situacin, es posible redirigir el correo desde mltiples cuentas hacia aquella que se usa mas frecuentemente. Para redirigir el correo de una cuenta dada, el usuario deber crear en el directorio de conexin correspondiente el archivo .forward, conteniendo la direccin de correo electrnico hacia la cual desea que los mensajes sean redirigidos. Por ejemplo, si jperez tiene cuenta tanto en Antares como en Canopus, pero prefiere leer correo en la primera,
14

deber crear un archivo .forward en su directorio de login de Canopus, conteniendo la siguiente lnea: jperez@antares

15

Administracin de una red TCP/IP

TCP/IP: una familia de protocolos
TCP/IP es un conjunto de protocolos de comunicaciones desarrollado para permitir a un conjunto de computadoras cooperar y compartir recursos a travs de una red de comunicaciones. De entre sus muchas caractersticas, hay dos que lo han transformado en uno de los protocolos de mayor difusin: Es un standard abierto, diseado independientemente de plataformas de hardware y software especficas. As, TCP/IP es ideal para interconectar sistemas mas all de lo diferentes que stos sean. Es independiente de la tecnologa fsica que se utilice para construir la infraestructura de la red. TCP/IP puede montarse sobre Ethernet, Token-Ring, enlaces seriales telefnicos (dial-up links), redes X.25, y virtualmente cualquier otro medio fsico de transmisin de datos.

Arquitectura de TCP/IP8
La familia TCP/IP est formada por mltiples protocolos de diferentes propsitos. Algunos de ellos, tales como IP, TCP y UDP constituyen el mecanismo bsico de transmisin de datos, y sern utilizados por todas las aplicaciones. Otros protocolos permiten realizar tareas mucho ms especficas, tales como transferir archivos entre computadoras (FTP), obtener pginas o documentos de la Web (HTTP), o sincronizar la hora desde otro equipo (XNTP). Cualquier aplicacin real utilizar varios de esos protocolos. Un caso tpico es el envo de correo electrnico. En primer lugar, existe un protocolo para enviar y recibir correo electrnico (denominado SMTP), que define una serie de comandos que una mquina enva a la otra cuando requiere transferirle un mensaje. Esos comandos permiten especificar quien es el autor del mensaje, a quien va dirigido y cual es el texto a enviar. Sin embargo, ese protocolo (como todos los otros protocolos de aplicacin) asume que hay alguna manera confiable para comunicar datos entre ambas computadoras, limitndose simplemente a definir a muy alto nivel los comandos necesarios para manejar la transmisin, pero no los detalles acerca de como va a efectivizarse la misma. Dichos detalles son dejados en manos de alguno de los protocolos de menor nivel, llamados protocolo de transporte: TCP o UDP. SMTP utiliza a TCP como protocolo de transporte. TCP es responsable de asegurar que los comandos trasmitidos lleguen al otro extremo de la comunicacin, contabilizando qu ha sido transmitido ya y retransmitiendo toda informacin que no haya llegado exitosamente a destino. Si la informacin a transmitir es demasiado larga, TCP la segmentar en varios paquetes que se transmitirn individualmente. Obsrvese que esta funcionalidad se requiere para muchas aplicaciones; es por ello que conforma un protocolo independiente en vez de formar parte de la especificacin de protocolos como SMTP. Desde el punto de vista del programador, TCP es una librara de rutinas que las aplicaciones utilizan cuando necesitan comunicaciones confiables con otra computadora a travs de la red. De manera similar, TCP utiliza los servicios de IP para efectivamente desplazar los paquetes alrededor de la red. IP constituye un protocolo de red, y es el encargado de determinar que rutas debern seguir los paquetes para llegar al punto de destino desde el punto de origen.
8

Adaptado principalmente de un articulo de Charles Hedrick (Rutgers Univ., New Brunswick, N.J.) publicado en los newsgroups de Internet el 28 de Junio de 1987, y de otras fuentes mencionadas en la Bibliografa.

16

Nuevamente, IP se presenta como una librera que utilizan protocolos de transporte como TCP al momento de enviar la informacin. Esta estrategia para construir protocolos en varios niveles se denomina diseo estratificado (o layering). Consiste en considerar a las aplicaciones, a TCP y a IP como diferentes capas, cada una de las cuales hace uso de los servicios ofrecidos por la capa inmediatamente inferior. En general, la arquitectura de las aplicaciones basadas en TCP/IP presentan 4 capas: Un protocolo de aplicacin, para tareas especficas (por ejemplo, correo electrnico) Un protocolo de transporte, que provee servicios de extremo a extremo (como TCP o UDP) El protocolo de red IP, que provee el encaminamiento de los paquetes a su destino final Un protocolo de enlace fsico, que provee acceso al medio fsico de transmisin (por ejemplo, Ethernet o X.25)

Transmitiendo los paquetes

A fin de ejemplificar el proceso completo, supongamos que se desea transmitir un archivo de 15000 bytes. El protocolo de aplicacin especializado en transferencia de archivos proporciona al protocolo de transporte el contenido del archivo a transmitir. La mayora de las redes no pueden manejar paquetes de 15000 bytes, por lo que el archivo ser segmentado en, digamos, 30 paquetes de 500 bytes cada uno, que entrega al protocolo de red para que sean enviados individualmente al otro extremo de la comunicacin. All, los paquetes se reunirn para reensamblar el archivo original. Sin embargo, mientras los paquetes estn en trnsito, la red no sabr que existe algn tipo de relacin entre ellos9. Es tambin posible que el paquete nmero 15 llegue antes que el 14, o que algunos paquetes se pierdan en el camino y deban ser retransmitidos. Todas estas tareas (segmentacin, retransmisin y reensamblaje) son llevadas a cabo por TCP (abreviatura de Transmission Control Protocol, o Protocolo de Control de Transmisin), mientras que el ruteo de paquetes individuales es responsabilidad de IP (abreviatura de Internet Protocol, o Protocolo de Inter-redes). A simple vista podra parecer que TCP es quien hace todo el trabajo, sin embargo, el rutear un paquete desde el origen hacia su destino puede ser una tarea muy compleja. TCP/IP asume que la red est formada por un gran numero de redes independientes, interconectadas entre si por dispositivos denominados gateways10, proporcionando al usuario la capacidad para acceder a recursos ubicados en cualquiera de esas redes, independientemente de su dispersin geogrfica11. Los paquetes frecuentemente atravesarn numerosas redes para llegar a su destino, pero el ruteo requerido para ello deber ser totalmente invisible para el usuario final. Todo lo que el usuario debe conocer es la direccin IP del punto de destino, un nmero que identifica unvocamente a cada computadora dentro de la inter-red. As, TCP entrega los paquetes a IP especificndole simplemente la direccin IP de destino hacia donde debe enviarlos. Queda en manos de IP determinar la mejor ruta para que la entrega se haga efectiva. Dicha ruta (continuando con el ejemplo anterior, y en el contexto
9

Ms an, la red ni siquiera sabe que los paquetes conforman un archivo. En la jerga TCP/IP se denomina gateways a dispositivos que estn conectados a mas de una red, y ofrecen capacidad para rutear paquetes entre esas redes. Es decir, se trata de ruteadores (dispositivos de nivel OSI 3) y no estrictamente de gateways (dispositivos de nivel OSI superiores, capaces de hacer transformaciones de protocolos, formatos, codificaciones, etc.) 11 De hecho, el trmino internet (con i minscula) proviene de internetwork y se refiere a un conjunto de redes interconectadas. No debe confundirse con Internet (con I mayscula), que se refiere a la red de redes de alcance global.
10

17

de la estructura de la red de la UTN Facultad Crdoba), podra implicar que cada paquete tenga que atravesar varios segmentos de LAN Ethernet dentro de la UTN FC, un enlace de microondas hasta el nodo de conexin a Internet, otro hasta algn telepuerto en Buenos Aires desde donde se establece una conexin satelital hacia los EEUU, y as sucesivamente hasta llegar a la red de destino, en donde deber ser ruteado internamente hasta la computadora de destino. Finalmente, para transmitir cada paquete, IP utiliza el protocolo de enlace fsico que conoce las particularidades para acceder al medio fsico de transmisin (por ejemplo, una placa de red Ethernet).

Multiplexacin: Puertos y Sockets

En los prrafos anteriores se ha descripto el proceso para transferir informacin a lo largo de una conexin TCP/IP. Sin embargo, en un momento dado podran existir, entre las computadoras de origen y destino, mltiples conexiones ocurriendo simultneamente; pensemos, por ejemplo, en varios usuarios abriendo sesiones remotas o transfiriendo simultneamente archivos o correo electrnico entre dos mquinas de la red. Claramente, no es suficiente lograr que los paquetes lleguen al destino correcto; es necesario adems poder discriminar a cual conexin pertenecen de las mltiples conexiones simultneas que pueden existir en un momento dado. Para identificar cada conexin, TCP asigna un nmero de puerto a cada una. Supongamos que tres personas estn transfiriendo archivos entre dos computadoras. TCP asignara un nmero de puerto a cada transferencia, por ejemplo, 1000, 1001 y 1002. Todos los paquetes que se enven como parte de una misma conexin tendrn asignado ese nmero como puerto de origen. El nmero de puerto de origen permite tambin establecer una correspondencia directa entre una conexin de red y el programa de usuario que interviene en uno de los extremos de la conversacin. En el otro extremo, habr otro programa que recibe los datos transmitidos, que tambin deber poder asociarse a dicha conexin. Esa asociacin se hace por medio del puerto de destino que TCP asigna a cada paquete que transmite. Cuando un programa de usuario (conocido como proceso cliente) abre una conexin de red por medio de TCP, se le asigna (mas o menos al azar) un nmero de puerto. Ese programa asume que en la otra computadora estar en ejecucin otro programa (conocido como proceso servidor o, en la jerga Unix, demonio de red) que espera recibir peticiones desde la red. Cuando ese programa fue iniciado, su capa TCP le asign tambin un nmero de puerto. Obviamente, el nmero de puerto que se asigne a procesos servidores no puede ser aleatorio, ya que sera imposible para los clientes saber que nmero especificar como puerto de destino. Los procesos servidores se asocian, entonces, con nmeros de puerto fijos (llamados "nmeros bien conocidos" -- "well-known numbers"), mientras que los procesos cliente obtienen nmeros de puertos aleatorios al iniciar las conexiones12. Obsrvese que una conexin de red puede entonces identificarse unvocamente por medio de un conjunto de 4 nmeros: las direcciones IP de ambos extremos y los nmeros de puerto de origen y destino. Para el caso de las tres transferencias de archivos que se ponan como ejemplo mas arriba, si las direcciones IP de las maquinas de origen y destino son 172.16.10.150 y 172.16.8.123, y la transferencia se hace utilizando el protocolo FTP (que tiene asignado el nmero de puerto 21), cada conexin se puede identificar de la siguiente manera:

12

No es necesario que un proceso cliente obtenga un "numero bien conocido" ya que nadie est tratando de encontrarlo; por el contrario, es necesario que los servidores tengan esos nmeros a fin de que los clientes puedan conectarse a ellos.

18

Conexin 1 Conexin 2 Conexin 3

Direccin IP: Puerto: Direccin IP: Puerto: Direccin IP: Puerto:

172.16.10.150 1000 172.16.10.150 1001 172.16.10.150 1002

Direccin IP: Puerto: Direccin IP: Puerto: Direccin IP: Puerto:

172.16.8.123 21 172.16.8.123 21 172.16.8.123 21

No pueden existir dos conexiones que compartan el mismo conjunto de nmeros, pero es suficiente con que al menos uno sea diferente. En el ejemplo anterior, en donde tres usuarios transfieren archivos entre dos computadoras, dado que las computadoras involucradas en cada transferencia son las mismas, las direcciones IP son iguales para cada conexin y todos realizan transferencias va FTP, por lo que el puerto de destino para las tres conexiones es el 21. Lo nico que difiere es el nmero de puerto de origen, que permite diferenciar a los tres usuarios. Cada par formado por una direccin IP y un nmero de puerto se denomina socket (enchufe), por lo que una conexin TCP puede verse como un canal virtual a travs de una red, "enchufada" a un socket en cada extremo. Por otra parte, el utilizar un nico canal de comunicaciones para combinar mltiples conexiones de datos se denomina multiplexacin; la informacin que arriba desde la red debe ser demultiplexada a fin de que cada mdulo de software reciba los paquetes que le corresponden. De hecho, hay varios niveles de multiplexacin en TCP/IP. Por una parte, TCP la utiliza para mantener mltiples conexiones, tal como se describi previamente. Por otra parte, sin embargo, existen otros protocolos (como UDP e ICMP) que utilizan IP como un medio para distribuir paquetes a lo largo de la red. Cuando IP recibe paquetes entrantes desde la red, debe poder determinar a cual protocolo de mayor nivel pasar el paquete. Esto constituye tambin otra forma de demultiplexacin, y se realiza por medio de la asignacin a cada paquete, por parte del IP de origen, de un numero de protocolo. Dicho nmero tiene un rol similar al nmero de puerto, con la diferencia de que no identifica conexin sino el protocolo de transporte que est administrando esa conexin. El proceso de multiplexacin y demultiplexacin de TCP/IP se esquematiza en la siguiente figura:
Aplicaciones (Clientes) Capa de Transporte Capa de Red Capa de Red Capa de Transporte Aplicaciones (Servidores)

T C P U D P I C M P I P I P

T C P U D P I C M P

Una red TCP/IP est formada por mltiples redes interconectadas por medio de gateways. Dichos gateways pueden ser dispositivos fsicos especializados (llamados routers) o bien computadoras con mltiples adaptadores de red (llamados multihomed hosts) Cada una de esas redes estar formada por mquinas individuales (los hosts de la red) o por subredes interconectadas. Cada mquina de la red recibir un identificador numrico nico, llamado direccin IP.
19

En resumen...

 Las computadoras de la red ejecutarn aplicaciones que establecern comunicaciones entre ellas por medio de protocolos como TCP UDP, los cuales utilizarn el protocolo IP para rutear paquetes de informacin entre el origen y el destino. Algunas computadoras de la red ofrecern servicios a las dems, establecindose relaciones de tipo cliente/servidor entre ellas. Los roles de cliente y servidor no son excluyentes; una misma maquina puede al mismo tiempo ser cliente y servidor. Mas aun, podra ocurrir que la relacin cliente/servidor se d entre dos procesos ejecutndose en la misma mquina. Los procesos servidores reciben peticiones desde la red, usualmente "escuchando" en puertos fijos de TCP (llamados nmeros bien conocidos). Los clientes, por otra parte, utilizan puertos TCP asignados mas o menos al azar al iniciar la conexin. El par formado por una direccin IP y un nmero de puerto se denomina socket. Una conexin puede identificarse unvocamente por el par de sockets correspondientes al nodo de origen y al de destino.

Direcciones IP

Clases de direcciones IP
Una direccin IP es un nmero, usualmente expresado por una secuencia de cuatro enteros separados por puntos: a.b.c.d en donde cada uno de esos nmeros asumen valores entre 0 y 255. De esos cuatro nmeros, algunos se utilizan como direccin de red y los restantes como direccin de host. Todos los hosts que pertenezcan a la misma red debern tener en comn la direccin de red y diferir en la direccin de host. La cantidad nmeros que se utilicen para la direccin de red da lugar a tres clases de direcciones IP:


Clase A Clase B Clase C

 
  
a a.b a.b.c

 
  
b.c.d c.d d

   
16777214 65534 254

Este esquema de direccionamiento da lugar a la existencia de unas pocas redes clase A, cada una con algo mas de 16 millones de computadoras. En el otro extremo, habr un nmero muy grande de redes clase C, de pequeo tamao. Dada una direccin IP, puede determinarse a que clase pertenece examinando el valor de su primer nmero:


Clase A Clase B Clase C

 

1 - 126 128 - 191 192 - 224

As, por ejemplo, una direccin IP como 172.16.4.205 pertenece a la red clase B 172.16, cuyo rango de direcciones va desde 172.16.1.1 hasta 172.16.255.254. Debe hacerse notar que, si bien cada uno de los nmeros de la direccin de host puede variar entre 0 y 255, esos dos valores en particular no pueden asignarse como direccin a ninguna

20

mquina; el cero deber utilizarse para formar la direccin IP de la red en su conjunto, mientras que el 255 es la direccin de broadcast13 (utilizada para enviar un mismo paquete a todos los hosts de la red). Siguiendo con el ejemplo anterior, para la red 172.16, la direccin IP de la red es 172.16.0.0 y la de broadcast, 172.16.255.255. Observar adems que hay ciertos valores faltantes en la tabla expuesta mas arriba: 0, 127 y el rango comprendido entre 225 y 255. En el caso de la red 127.0.0.0, la misma se denomina red de loopback y constituye una red virtual (implementada internamente por el software de TCP/IP y no por dispositivos fsicos) que conecta a un host directamente consigo mismo. En la red de loopback se asigna siempre una nica direccin IP: 172.0.0.1, que corresponde al host local. Por medio de esa direccin de loopback, las aplicaciones pueden tratar al host local de la misma manera que a cualquier host remoto (esto es, desde el punto de vista de las aplicaciones, el host local es otro host mas de la red y no requiere tratamiento especial). La direccin 0.0.0.0 es utilizada por el software de ruteo como la ruta por defecto, tal como se discutir ms adelante, mientras que las redes que comienzan con nmeros entre 225 y 255 estn reservadas para usos especiales14.

Obtencin de las direcciones IP

Como ya se ha dicho, cada dispositivo conectado a una red TCP/IP debe tener asignado una direccin IP, que lo identifique unvocamente en toda la inter-red, es decir, debe ser nico no solo en la red a la que ese dispositivo pertenece, sino tambin en todas las dems redes a las cuales est indirectamente conectado. Como consecuencia de lo anterior se desprende que a la hora de configurar TCP/IP en una red, su administrador no puede seleccionar arbitrariamente los nmeros IP, especialmente si su red se conecta a otras redes TCP/IP. Si la red en cuestin va a ser conectada a Internet, el juego de direcciones IP a utilizar deber obtenerse de alguna autoridad centralizadora, usualmente el proveedor de acceso a Internet (conocido como ISP: Internet Service Provider)15. Si la red no tiene vnculos a Internet, se recomienda al administrador que utilice alguna de las direcciones reservadas especialmente para redes desconectadas, o tambin llamadas direcciones no anunciables:


Clase A Clase B Clase C

 
10.0.0.0 172.16.0.0 192.168.0.0

Subredes
Ya sea que las direcciones IP a utilizar en la red se obtengan de una autoridad centralizadora o se utilice una direccin no anunciable, el paso previo es decidir que clase de direcciones se utilizar (A, B o C). Por lo dicho hasta el momento, podra concluirse que el criterio para tomar esa decisin debiera basarse en la cantidad de computadoras (presente y estimada a futuro) que se Estrictamente, la direccin de red es aquella en que todos los bits de la porcin de host de la direccin IP son cero, mientras que la direccin de broadcast es aquella en que todos los bits son uno. 14 Actualmente se utilizan para redes multicast (redes que permiten direccionar grupos de computadoras al mismo tiempo). 15 La autoridad centralizadora mundial de direcciones IP es el Internet Network Information Center (o InterNIC). En principio, el InterNIC tambin recibe solicitudes para la asignacin de nmeros de red IP, aunque en los ltimos aos la tarea se ha delegado casi por completo a los proveedores locales. Para mas datos, consultar la direccin http://www.internic.net.
13

21

conectarn a la red. Obviamente ese es uno de los parmetros a tener en cuenta, pero no es el nico. A los fines del ruteo de los paquetes, la direccin IP debe reflejar adems la estructura interna de la red, es decir, sus subredes. Denominaremos subred a una porcin de la red tal que todas sus computadoras tienen posibilidad de comunicarse directamente entre s, sin que sea necesario ningn dispositivo intermediario. Para el caso de redes locales, esto significa usualmente que esas computadoras pertenecen al mismo segmento de Ethernet (esto es, estn conectadas todas al mismo tramo de coaxil o al mismo concentrador). Consideremos, por ejemplo, la siguiente red:

Antares

Rigel

Altair

Orion

Cygni

Andromeda

Aldebarn

Canopus

La figura muestra que la red est constituida por cuatro segmentos de Ethernet; todas las mquinas conectadas al mismo segmento (por ejemplo, Antares y Rigel) pertenecen a la misma subred. Por otra parte, algunas computadoras (como Andrmeda, Orin y Cygni) pertenecen a ms de una subred (de hecho, conectan subredes entre s, cumpliendo funciones de gateway). Cuado esta red reciba su direccin de red, el administrador deber mantener fijos ciertos nmeros de la direccin IP (la parte de red) y tendr libertad para variar los restantes (la parte de host) para numerar las computadoras individuales de la red. Sin embargo, dado que existen subredes, deber destinar parte de la direccin de host para numerar tambin las subredes. Por ejemplo, al usar una direccin clase B, como la 172.16.0.0, es usual utilizar el tercer nmero para numerar la subred, y el ltimo para numerar la mquina dentro de la subred:

22

Antares

Rigel

Altair

172.16.1.0

172.16.2.0

Orion

172.16.3.0
Cygni

Andromeda

Aldebarn

172.16.4.0

Canopus

Sin embargo, esta segmentacin del espacio de direcciones disponible ( subnetting) trae como resultado que disminuya la cantidad de direcciones aprovechables para asignar a computadoras. En el caso del ejemplo, si bien una direccin clase B (considerada linealmente) provee de un espacio de mas de 65 mil direcciones, la subdivisin de ese espacio en 4 subredes nos deja con solo cuatro subredes de 254 mquinas cada una, haciendo un total de 1016 direcciones para toda la red. Obviamente, es posible conectar mayor nmero de estaciones agregando hasta 254 subredes, pero ninguna de ellas podr superar las 254 computadoras. Estrictamente, utilizar el tercer byte completo para numerar la subred no es la nica opcin; es posible utilizar solo los primeros bits del tercer byte para la direccin de subred y conformar la direccin de host con los bits restantes sumados al cuarto byte; ms an, esa tcnica de segmentacin es la nica opcin cuando se utilizan subredes de una direccin clase C (donde 3 bytes deben permanecer fijos y solo el cuarto puede variarse). Sin embargo, independientemente de las "artimaas" que se utilicen, siempre habr cierta prdida en el espacio de direcciones aprovechables (lo cual puede ser especialmente problemtico si se usa una direccin clase C). En conclusin, para seleccionar la clase de direccin IP a utilizar, debe tenerse en cuenta no solo la cantidad de mquinas de toda la red, sino tambin su estructura de subredes y la dimensin de cada una, recordando que ser necesario contar con un esquema de subnetting que de cabida a la mayor de ellas. A modo de aclaracin, cabe agregar que el subnetting es solo una cuestion administrativa que solo es relevante desde el punto de la administracin interna de las direcciones IP y, especialmente, el ruteo interno de paquetes; desde la perspectiva de otras redes, lo nico relevante es la direccin de red de la red en su conjunto.

Las direcciones IP se forman combinando 4 valores numricos enteros, y est estructurada en una parte de red y otra de host. La direccin de red refleja tambin la estructura interna de subredes en que se encuentra dividida la red.

En resumen...

23

 Al solicitar o seleccionar la direccin de red a utilizar, debe optarse por una direccin clase A, B o C, teniendo en cuenta la cantidad de maquinas de la red y, fundamentalmente, la topologa lgica de subredes. Si van a utilizarse direcciones no anunciables, es recomendable utilizar la clase C 192.168.1.0 si la red es de un solo segmento, o bien la clase B 172.16.0.0 si existen mltiples subredes, utilizando el tercer byte para numerar las subredes.

Asignacin de direcciones IP
Una vez asignada la direccin de red y definido el esquema para numerar las subredes, se puede comenzar a asignar direcciones IP a las computadoras de cada subred, configurando cada interfaz de red con los siguientes parmetros: direccin IP, direccin de broadcast y mscara de subred. Continuando con el ejemplo iniciado mas arriba, la asignacin de direcciones IP podra ser la siguiente:

Antares 172.16.1.1

Rigel 172.16.1.2

Altair 172.16.2.1

172.16.1.0

172.16.1.254 172.16.3.254 Orion

172.16.2.0
172.16.2.254

172.16.1.253 172.16.3.253

172.16.3.0

172.16.4.253 Cygni Andromeda 172.16.4.254 Aldebarn 172.13.3.1

172.16.4.0

Canopus 172.16.4.1

Obsrvese que computadoras como Orin y Cygni que estn conectadas a ms de una subred, debern recibir una direccin IP por cada una de las subredes a las que se encuentren conectadas16. Computadoras como stas, que interconectan subredes, jugarn un importante papel como gateways de la red; el administrador de red est en libertad de asignarles cualquier nmero de IP dentro del rango vlido para cada una de las subredes. Sin embargo, es recomendable adoptar algn tipo de convencin al numerar los gateways; de esa forma, dado un nmero de red cualquiera, resultar ms simple identificar la direccin del gateway de la subred. En el ejemplo, la convencin adoptada consiste en numerar los hosts con nmeros crecientes a partir de 1, y los gateways con nmeros decrecientes a partir de 254.

16

Esto muestra que en realidad quienes tienen direcciones IP no son las computadoras sino las interfaces de red.

24

La direccin de broadcast y la mscara de subred son iguales para todos los hosts dentro de una subred dada. La direccin de broadcast se forma poniendo en 1 todos los bits correspondientes a la porcin de host de la direccin IP. En nuestro ejemplo, la porcin de host es el ltimo byte de la direccin; si todos los bits de ese byte se ponen a 1, el valor en decimal es 255, por lo que las direcciones de broadcast seran las siguientes:


172.16.1.0 172.16.2.0 172.16.3.0 172.16.4.0

 
   
172.16.1.255 172.16.2.255 172.16.3.255 172.16.4.255

La mscara de subred es un nmero que se utiliza para obtener la direccin de red partir de una direccin IP. La separacin se realiza por medio de una operacin lgica AND entre la direccin IP y la mscara de subred, por lo que la mscara de subred deber tener puestos a 1 aquellos bits que corresponden a la direccin de red (incluyendo la parte de la subred) y a 0 aquellos que formen la direccin de host. Para el caso en que se usen bytes completos para direccin de red y de host, la mscara de subred se formar poniendo un 255 en los bytes que correspondan a la parte de red, y un 0 en los bytes que correspondan a la parte de host. Por ejemplo:


A, sin subredes A, con subredes B, sin subredes B, con subredes C, sin subredes

 
  
10.0.0.0 10.x.0.0 172.16.0.0 172.16.x.0 192.168.1.0

   

255.0.0.0 255.255.0.0 255.255.0.0 255.255.255.0 255.255.255.0

Para el caso de la red del ejemplo, se trata de una red con direcciones clase B con subredes, por lo que la mscara de subred a utilizar es 255.255.255.0.

Configurando un sistema Unix17

En Unix las interfaces de red se configuran por medio del comando ifconfig, cuya sintaxis bsica es la siguiente:
ifconfig interfaz direccin_IP netmask mscara broadcast direccin_broadcast

en dnde, interfaz direccin_IP mscara broadcast Es el nombre asignado por el sistema operativo al adaptador de red. Es la direccin IP que se le asigna a esta interfaz Mscara de subred. Direccin de broadcast de la subred18.

Antes de poder utilizar ifconfig se deben conocer los nombres que el sistema operativo asigna a los adaptadores de red. El administrador puede obtener esa informacin de la documentacin provista por el sistema; en el caso de Red Hat Linux (y de otros sistemas Todos los comandos de configuracin deben ejecutarse desde algn usuario con suficientes privilegios; usualmente, solo pueden ser ejecutados por root. 18 El parmetro broadcast es opcional, dado que puede calcularse automticamente dada la direccin IP y la mscara de subred.
17

25

Unix que implementen el pseudo-filesystem /proc) pueden conocerse los adaptadores de red detectados por el sistema operativo durante el arranque consultando el archivo /proc/dev/net:
# cat /proc/net/dev Inter-| Receive | Transmit face |packets errs drop fifo frame|packets errs drop fifo colls carrier lo: 39 0 0 0 0 39 0 0 0 0 0 eth0: 0 0 0 0 0 0 0 0 0 0 0

El listado anterior muestra que las interfaces detectadas son lo (la interfaz a la red de loopback) y eth0 (una placa de red Ethernet). As, para configurar la interfaz Ethernet de Antares, se debe ejecutar un comando como el siguiente:
# ifconfig eth0 172.16.1.1 netmask 255.255.255.0 broadcast 172.16.1.255

Algunos sistemas configuran la direccin de loopback automticamente, pero en aquellos en donde debe hacerse explcitamente, puede hacerse corriendo el comando:
# ifconfig lo 127.0.0.1 netmask 255.0.0.0 broadcast 127.255.255.255

Comandos como stos se ejecutan normalmente de manera automtica cuando el sistema operativo se inicializa al prender el equipo, usualmente invocados desde algn script de inicializacin. El administrador debe modificar directamente esos scripts, o algn archivo de configuracin que los mismos utilizan, a fin configurar las interfaces de red. Red Hat Linux inicializa las interfaces desde el script /etc/rc.d/init.d/network, obteniendo los parmetros de configuracin desde archivos ubicados en el directorio /etc/sysconfig/network-scripts. All existe un archivo por cada interfaz de red (incluida la interfaz de loopback), cuyo nombre es de la forma ifcfg-nombre_de_la_interfaz y que contiene una serie de variables con los parmetros de configuracin de la interfaz. Por ejemplo:
   

DEVICE=eth0 IPADDR=172.16.1.1 NETMASK=255.255.255.0 NETWORK=172.16.1.0 BROADCAST=172.16.1.255 ONBOOT=yes BOOTPROTO=none

DEVICE=lo IPADDR=127.0.0.1 NETMASK=255.0.0.0 NETWORK=127.0.0.0 BROADCAST=127.255.255.255 ONBOOT=yes BOOTPROTO=none

Por otra parte, la mayora de los Unix modernos proveen al administrador de una interfaz grfica para la configuracin de las interfaces. En Red Hat Linux 5.0 se denomina netcfg, y luce de la siguiente forma:

26

Ruteo de paquetes IP
Como se describi previamente, la principal responsabilidad del protocolo IP es determinar qu camino deben tomar los paquetes para llegar al punto de destino. La tarea de determinar ese camino es lo que se conoce como ruteo (o encaminamiento). IP asume que la computadora est directamente conectada a una red local (por ejemplo, una LAN Ethernet) y que puede enviar paquetes directamente a cualquier otra computadora sobre esa misma red; si la direccin de destino es en la red local, IP simplemente accede al medio fsico de transmisin y enva el paquete. En la figura siguiente, Antares y Rigel estn sobre la misma red, por lo que pueden comunicarse directamente:

Antares 170.25.1.1

Rigel 170.25.1.2

Altair 170.25.2.1

170.25.1.0

170.25.1.254 170.25.3.254 Orion

170.25.2.0
170.25.2.254

170.25.1.253 170.25.3.253

170.25.3.0

170.25.4.253 Cygni 170.25.4.254 Andromeda Aldebarn 170.25.3.1

170.25.4.0

Internet Canopus 170.25.4.1 Centauri 170.25.4.253

27

El problema aparece cuando la direccin de destino queda en otra red, en cuyo caso IP recurrir a un gateway para enviar indirectamente los paquetes. Como se recordar, se denomina gateway19 a un dispositivo (ya sea otra computadora o un dispositivo especficamente diseado a tal efecto) que est conectado a ms de una red y tiene la capacidad para redirigir (forward) paquetes entre esas redes. En la figura, Orin, Andrmeda, Cygni y Centauri son los gateways de la red. Para determinar a qu gateway debern enviarse los paquetes, IP extrae la direccin de red del nodo de destino y consulta una tabla, denominada tabla de ruteo, en la cual se listan las redes conocidas y los gateways que pueden utilizarse para alcanzarlas. Por ejemplo, la tabla de ruteo de Aldebarn contiene la siguiente informacin:
 

170.25.1.0 170.25.2.0 170.25.3.0 170.25.4.0

170.25.3.254 170.25.3.254 * 170.25.3.253

en donde el asterisco indica que no es necesario ningn gateway para llegar a la red en cuestin dado que la mquina tiene conexin directa a la misma. Obsrvese en primer lugar que el ruteo hacia redes remotas se realiza en base a direcciones de red (esto es, la parte de host de la direccin IP se ignora); adems, la tabla de ruteo especifica tanto la red local como las remotas, y que para el caso de stas ltimas, indica la direccin IP de alguna mquina en la red local que puede ser utilizada para alcanzarla. Supongamos, por ejemplo, que Altair requiere enviar datos a Canopus. El mdulo IP de Altair determina que la computadora de destino no pertenece a su misma red; consultando su tabla de ruteo, determina que puede llegarse a la red de Canopus a travs de Orin, por lo que le enva los paquetes a dicha computadora. El mdulo IP residente en Orin, por su parte, sabe que para llegar a Canopus hay dos vas posibles: pasando por Andrmeda o por Cygni. Aplicando algn criterio para evaluar ambas rutas y seleccionar la mejor de ellas, Orin enva cada paquete a, por ejemplo, Andrmeda. Esta ltima determina que la direccin de destino est en una de las redes a las que se encuentra directamente conectada, por lo que los enva diretamente a Canopus. Es importante observar que la ruta que seguirn los paquetes desde el origen hasta su destino se va decidiendo a medida que los mismos viajan por la red. Cada nodo es responsable de determinar cual es el proximo "salto" en direccin al nodo final, en funcin del contenido de su tabla de ruteo. Este modelo de ruteo asume que si el nodo de destino no pertenece a la red local, deber haber una entrada en la tabla de ruteo que especifique el gateway a utilizar. En otras palabras, asume que todos los nodos estn al tanto de la estructura de la red. En consecuencia, cada vez que la estructura de la red cambia (por ejemplo, cuando se agrega o elimina una subred), el administrador debera actualizar las tablas de ruteo en todos los nodos. Igualmente, si la red se interconectara a otra red, una nueva entrada debera agregarse en las tablas de ruteo de cada mquina. Siguiendo con este razonamiento, a medida que la red crece y se interconecta a otras redes las tablas de ruteo se hacen mas largas y complejas; inclusive sera posible que fueran virtualmente imposibles de construir o mantener, en especial si la red se conecta a Internet (formada por miles de redes independientes). Por supuesto, existen previsiones para enfrentar estos problemas: el ruteo dinmico o adaptativo y las rutas por defecto.

19

La palabra inglesa gateway podra traducirse como "puerta de salida".

28

Ruteo esttico vs. ruteo dinmico

La tabla de ruteo de un host puede construirse de dos maneras. Una posibilidad consiste en que el administrador (por medio de scripts que se ejecutan al inicializar el sistema, o por medio de comandos ejecutados interactivamente) introduzca manualmente las entradas de la tabla. Esta tcnica se denomina ruteo esttico, debido a que la tabla de ruteo se construye cuando la computadora se prende y no varia con el tiempo. La otra posibilidad es ejecutar en cada host un programa que actualice automtica y peridicamente la tabla de ruteo. Dichos programas se basan en el hecho de que una computadora siempre tiene acceso a otras computadoras conectadas a la red local; esto se traduce en que las tablas de ruteo contienen inicialmente al menos las direcciones de las redes locales. Si tomamos por caso a Orin, su tabla de ruteo inicialmente contendra la siguiente informacin:
 

170.25.1.0 170.25.2.0 170.25.3.0

* * *

De manera similar, la tabla de Andrmeda contendr lo siguiente:

 

170.25.3.0 170.25.4.0

* *

Si Orin y Andrmeda intercambiaran sus tablas de ruteo, cada una podra "aprender" de la otra qu redes son alcanzables por esa va. As, Andrmeda podra concluir lo siguiente:
 

170.25.1.0 170.25.2.0 170.25.3.0 170.25.4.0

170.25.3.254 170.25.3.254 * *

As, si todos los nodos de la red ejecutan un programa de estas caractersticas (llamado demonio de ruteo) al cabo de cierto tiempo habrn "descubierto" por si mismas la estructura de la red y construido sus tablas automticamente. Mas an, si se produjera algn cambio en la estructura de la red, bastara con que alguna de las computadoras lo detectara para que en pocos segundos esa nueva informacin se propagara por toda la red. Esta estrategia se denomina ruteo dinmico o adaptativo y tiene la ventaja de que, al ser automtico, permite eliminar las tareas administrativas relacionadas con el mantenimiento de las tablas de ruteo. En ambientes Unix se dispone de dos programas que implementan este tipo de protocolos de ruteo: routed y gated.

Rutas por defecto

El uso de ruteo dinmico elimina la necesidad de modificar las tablas de ruteo cuando la red cambia. Sin embargo, no resuelve el problema de las abultadas tablas de ruteo resultantes de conectar una red a muchas otras.

29

Consideremos la tabla de ruteo que construira una mquina como Altair:

 

170.25.1.0 170.25.2.0 170.25.3.0 170.25.4.0

170.25.2.254 * 170.25.2.254 170.25.2.254

Como puede verse, Altair ha aprendido las rutas a todas las subredes de la red, pero el nico gateway que puede utilizar es Orin. De manera similar, si fuera posible que todas las computadoras de la red del ejemplo aprendieran las direcciones de todas las redes que forman la Internet, Altair eventualmente construira una tabla de ruteo con miles de entradas, en donde todas tendran a Orin como gateway. En ambos casos, el resultado es una tabla de ruteo con informacin altamente redundante. Para eliminar este problema, es que puede instalarse en la tabla de ruteo una ruta por defecto (conocida tambin como default gateway). IP utiliza la ruta por defecto (que se indica con el nmero 0.0.0.0) cada vez que no se encuentra en la tabla de ruteo una ruta hacia una red especfica. Aplicando ste criterio, la tabla de Altair se reducira a lo siguiente:
 

170.25.2.0 0.0.0.0

* 170.25.2.254

que sencillamente indica que si la direccin de destino est en la red local, es accesible directamente, y que en caso contrario (independientemente de cual sea el destino), los paquetes debern enviarse a 170.25.2.254 (es decir, Orin).

Configurando los nodos

Caso 1: Redes sin segmentacin interna

En este caso, se tiene una red pequea, en la que todas las computadoras estn ubicadas sobre el mismo segmento fsico y no hay ninguna conexin a otras redes TCP/IP:

Antares 205.12.9.1

Rigel 205.12.9.2

Altair 205.12.9.3

205.12.9.0

Como se puede ver, todas las computadoras tienen acceso directo a todas las dems. La tabla de ruteo ser mnima; solo contendr una referencia a la red local y a la red de loopback instaladas automticamente por ifconfig al inicializar las interfaces correspondientes. Puede utilizarse el comando route -n para examinar el contenido de la tabla de ruteo (-n indica a route que utilice formato numrico):
# route -n Kernel IP routing table Destination Gateway Iface 127.0.0.0 0.0.0.0 205.12.9.0 0.0.0.0

Genmask 255.0.0.0 255.255.255.0

Flags Metric Ref U U 0 0 1 40

Use 298 lo 1252 eth0

30

En el listado anterior, la primera columna indica direccin de red (que debe interpretarse de acuerdo a la mascara de la tercera columna) y la segunda columna indica el gateway a utilizar (0.0.0.0 se utiliza para indicar que hay conexin directa a la red en cuestin. Route tambin muestra informacin adicional sobre cada ruta: Flag: Se compone de una serie de caracteres que indican las caractersticas de la ruta. Por ejemplo, U indica que la ruta est operacional (por Up), G que es una ruta a un gateway, H que es una ruta a un host, etc. Valor utilizado para cuantificar la ruta. IP utiliza este valor para seleccionar la mejor de dos o ms rutas alternativas a la misma red. Cantidad de veces que sta ruta fue utilizada para establecer una conexin. Cantidad de paquetes trasmitidos a travs de esa ruta.

Metric:

Ref: Use:

Si esta misma red se conectara a otras redes (por ejemplo, la Internet), sera necesario indicar en cada uno de los hosts de la red una ruta esttica por defecto hacia el gateway a las otras redes:

Antares 205.12.9.1

Rigel 205.12.9.2

Altair 205.12.9.3

205.12.9.0
205.12.9.254

150.104.3.21
Orin
Internet

Las rutas por defecto puede instalarse en las estaciones por medio del siguiente comando route:
# route add -net default 205.12.9.254

Si ahora se reexaminara la tabla de ruteo en dichas estaciones, se obtendra el siguiente resultado:

# route -n Kernel IP routing table Destination Gateway Iface 127.0.0.0 0.0.0.0 205.12.9.0 0.0.0.0 0.0.0.0 205.12.9.254

Genmask 255.0.0.0 255.255.255.0 0.0.0.0

Flags Metric Ref U U UG 0 0 0 1 40 0

Use 298 lo 1252 eth0 0 eth0

Obsrvese que Orin interconecta nuestra red con el exterior, por lo que tiene una direccin en la red local (170.25.9.254) y otra en la red del proveedor de acceso a la otra red (en este caso, la Internet). A fin de lograr la conectividad, deber instalarse en Orin una ruta por

31

defecto hacia el exterior, utilizando como gateway una direccin que el proveedor especifique, por ejemplo:
# route add -net default 150.104.3.254

Por otra parte, el proveedor deber instalar en sus ruteadores alguna ruta que indique que nuestra red es alcanzable a travs de la direccin 150.104.3.21, cerrando as el ciclo de entrada y salida a nuestra red.

Caso 2: Redes segmentadas

En este caso, la red est compuesta por varios segmentos unidos entre s por gateways. Una primera opcin sera ejecutar un demonio de ruteo dinmico en todas las computadoras, y dejar que las tablas se actualicen automticamente. Sin embargo si tal programa no estuviera disponible (o por alguna razn se decide no emplearlo) bastara con instalar en las computadoras de cada segmento una ruta esttica por defecto hacia el gateway Orin, tal como se muestra en la siguiente figura:

Antares 170.25.1.1

Rigel 170.25.1.2

Altair 170.25.2.1

Aldebarn 170.25.2.2

170.25.1.0
170.25.1.254 170.25.2.254

170.25.2.0

Orion

Para obtener esta configuracin, en Antares y Rigel habra que ejecutar el siguiente comando:
# route add -net default gw 170.25.1.254

mientras que en Altair y Aldebarn el comando sera:

# route add -net default gw 170.25.2.254

No es necesario instalar manualmente ninguna ruta en Orin, debido a que todas las necesarias sern instaladas automticamente por ifconfig. Sera diferente si la red tuviera ms subredes:

32

Antares 170.25.1.1

Rigel 170.25.1.2

Altair 170.25.2.1

170.25.1.0

170.25.1.254 170.25.3.254 Orion

170.25.2.0
170.25.2.254

170.25.3.0
170.25.3.253

170.25.4.254 Andromeda

170.25.4.0

Aldebarn 170.25.3.1

Canopus 170.25.4.1

En ste caso, sera necesario informar a Orin acerca de la existencia de la red 170.25.4.0, y a Andrmeda acerca de las redes 170.25.1.0 y 170.25.2.0. Una vez mas, puede utilizarse el comando route para instalar las rutas, utilizando la siguiente sintaxis:
# route add -net red netmask mscara gw gateway

Por ejemplo, en Andrmeda habra que ejecutar los siguientes comandos:

# route add -net 170.25.1.0 netmask 255.255.255.0 gw 170.25.3.254 # route add -net 170.25.2.0 netmask 255.255.255.0 gw 170.25.3.254

con lo que la tabla de ruteo quedara conformada de la siguiente manera:

# route -n Kernel IP routing table Destination Gateway Iface 127.0.0.0 0.0.0.0 170.25.3.0 0.0.0.0 170.25.4.0 0.0.0.0 170.25.1.0 170.25.3.254 170.25.2.0 170.25.3.254

Genmask 255.0.0.0 255.255.255.0 255.255.255.0 255.255.255.0 255.255.255.0

Flags Metric Ref U U U UG UG 0 0 0 0 0 1 105 55 20 33

Use 298 11252 1976 841 976 lo eth0 eth1 eth0 eth0

Finalmente, si la red tuviera conexin a redes externas, sera necesario instalar en los gateways una ruta por defecto que conduzca hacia el gateway al exterior:

33

Antares 170.25.1.1

Rigel 170.25.1.2

Altair 170.25.2.1

170.25.1.0

170.25.1.254 170.25.3.254 Orion

170.25.2.0
170.25.2.254

170.25.3.0
170.25.3.253

170.25.4.254 Andromeda

170.25.4.0

Aldebarn 170.25.3.1

Internet Canopus 170.25.4.1 Centauri 170.25.4.253

En Orin:
# route add -net default gw 170.25.3.253

En Andrmeda:
# route add -net default gw 170.25.4.253

Opciones al comando route

En todos los ejemplos anteriores se utiliz el comando route para instalar rutas manualmente en la tabla de ruteo. Sin embargo, al igual que ocurre con ifconfig, usualmente el administrador no instala las rutas introduciendo comandos manualmente (o modificando scripts de inicializacin del sistema), sino que se limita a modificar archivos de configuracin o utilizar alguna herramienta grfica. En el caso de Red Hat Linux, la utilidad netcfg que se mencion con anterioridad puede utilizarse para configurar la ruta por defecto e instalar rutas estticas. Tambin pueden realizarse estas tareas modificando manualmente archivos de configuracin network y static-routes respectivamente, ubicados ambos bajo /etc/sysconfig.

34

Resolucin de Nombres
Una vez que se han configurado las direcciones IP y el ruteo, una red TCP/IP se encuentra totalmente operativa. Sin embargo, a los fines prcticos hay que cumplimentar un paso adicional: la configuracin de la resolucin de nombres. Un servicio de resolucin de nombres permite a las computadoras de una red transformar nombres en direcciones numricas y viceversa. Sabemos que, a fin de acceder a servicios a travs de la red, es necesario hacer referencia a aquellas computadoras que los ofrecen, las cuales se conectan a una o ms redes por medio de interfaces. Como se ha visto, cada interfaz de red conectada a una red TCP/IP se identifica con una direccin IP numrica, por lo que para hacer referencia a la misma, es necesario conocer dicho nmero. Si bien los protocolos de comunicaciones y las aplicaciones informticas se sienten a gusto utilizando nmeros, no ocurre lo mismo con las personas, quienes prefieren utilizar nombres para designar a las computadoras de la red, ya que son ms fciles de recordar. Seguramente es ms probable que el nombre del sitio web de la UTN Facultad Crdoba (www.frc.utn.edu.ar) est mas presente en la memoria de sus usuarios que su direccin IP (170.210.248.211). Otra razn para utilizar nombres en lugar de nmeros es el aislar a los usuarios de posibles cambios en la distribucin de las direcciones IP. Por ejemplo, si el programa que habitualmente se utiliza para leer correo electrnico est configurado para obtener mensajes a partir de la direccin IP 172.16.4.205, el administrador de red necesitar notificar a todos los usuarios que debern reconfigurarlo si el servidor de correo se muda a otro equipo, o si la direccin IP del equipo en el que reside se cambia por alguna razn. Por medio de la utilizacin del servicio de resolucin de nombres, el programa de correo electrnico puede configurarse para obtener los mensajes de una mquina llamada, por caso, mailhost, independientemente de dnde se ubique fsicamente.

La tabla de Hosts
Para implementar un servicio de nombres es necesario confeccionar una lista en la que se relacionen nombres con direcciones IP; cuando un programa necesita resolver un nombre (esto es, dado un nombre encontrar la direccin IP), debe consultar dicha lista. En un principio, la resolucin de nombres se implement por medio de un archivo ubicado en cada mquina de la red que contena dicha lista. En el caso de Unix, ese archivo es el /etc/hosts y tiene el siguiente formato:
# # Tabla de resolucin de nombres # 127.0.0.1 localhost 170.25.1.1 antares 170.25.1.2 rigel 170.25.1.254 orion 170.25.2.1 altair 170.25.2.254 orion 170.25.3.1 aldebaran 170.25.3.253 andromeda 170.25.3.254 orion 170.25.4.1 canoups 170.25.4.253 centauri 170.25.4.254 andromeda

Las lneas que comienzan con # se consideran comentarios y son ignoradas, mientras que las dems asocian un nmero de IP con el nombre asociado a la computadora.

35

As, cuando el usuario ejecuta un comando como

$ telnet aldebaran

el programa telnet antes de iniciar la conexin transforma el nombre aldebaran en la direccin IP 170.25.3.1, segn se consigna en la tabla de hosts. Obsrvese adems que los gateways de la red figuran varias veces en el listado, segn la cantidad de interfaces que posean. Tambin es posible asignar mas de un nombre a una misma interfaz (denominados alias):
170.25.1.254 orion mailhost

De esta manera, el comando

$ telnet orion

resulta totalmente equivalente al comando

$ telnet mailhost

La tabla de hosts provee de un mecanismo sencillo para implementar la resolucin de nombres. Sin embargo, a medida que la red crece y debido a que la informacin est duplicada en cada host de la red, su mantenimiento se hace cada vez ms trabajoso. La situacin se complica si varias redes TCP/IP se interconectan, en cuyo caso, a las tareas de sincronizacin de tablas entre diferentes hosts hay que sumar el control de nombres duplicados para mquinas diferentes. Para solucionar estos problemas de escalabilidad, el mecanismo de resolucin de nombres evolucion hacia uno mucho ms sofisticado: el Servicio de Nombres de Dominio, o DNS (Domain Name Service). Sin embargo, an cuando se utilice DNS, es necesario contar con una tabla de hosts mnima a ser utilizada por el sistema operativo durante el arranque, con informacin suficiente para resolver el nombre de la mquina y el nombre "localhost" asociado con la direccin de loopback. Por ejemplo, la tabla de hosts de Canopus debiera contener mnimamente lo siguiente:
127.0.0.1 170.25.4.1 localhost canoups

Servicio de Nombres de Dominio (DNS)

La tabla de hosts fue reemplazada por un esquema mucho ms potente y flexible, adecuado para las necesidades de escalabilidad y tolerancia a fallas de grandes redes como la Internet. El DNS es un servicio cliente/servidor, en el cual cuando un proceso necesita resolver un nombre se contacta va TCP/IP20 con otro proceso, llamado servidor de nombres, quien realiza el proceso de resolucin y retorna una respuesta. Como en todo sistema cliente/servidor, ambos procesos pueden ejecutarse sobre la misma maquina o en mquinas completamente diferentes. Un servidor DNS mantiene la lista de direcciones y nombres de una o ms agrupaciones de computadoras, llamadas dominios. Dichas agrupaciones se forman de manera conceptual (por rea geogrfica, motivos organizacionales, por proyectos, etc.) y no tienen necesariamente que tener un correlato con direcciones de red o estructura de subredes.
20

Estrictamente, la comunicacin entre el cliente y el server DNS se realiza mediante conexiones UDP.

36

Adems de contener computadoras, un dominio puede particionarse en otros subdominios. Este particionamiento se realiza a los fines de permitir la delegacin de tareas administrativas. El administrador de un subdominio puede cambiar datos de las computadoras del mismo e incluso crear nuevos subdominios que delegar a terceros. Esto da como resultado una estructura jerrquica, similar a un rbol invertido, en donde para llegar a un dominio en particular, se debe seguir una trayectoria de dominios encadenados a partir de un dominio raz. Inmediatamente por debajo del dominio raz, se encuentran los dominios de alto nivel. Inicialmente, los diseadores de ARPANET (la red predecesora de Internet) concibieron los dominios de alto nivel como dominios organizacionales: com edu : gov: mil: net: org: int: : organizaciones comerciales; organizaciones educativas; organizaciones gubernamentales; organizaciones militares; organizaciones administradoras de redes globales; organizaciones sin fines de lucro; organizaciones internacionales (como la OTAN, la ONU, etc.).

Mas tarde, en vistas a la expansin de la Internet por todo el mundo, se crearon nuevos dominios de alto nivel, uno por cada pas: los dominios regionales. Los dominios regionales se designan segn un estndar internacional llamado ISO 3166, que asigna a cada pas un cdigo de dos letras21. Por ejemplo: ar: us: es: mx: uk: Argentina Estados Unidos Espaa Mxico Gran Bretaa22

La administracin del DNS a escala global recae en un organismo llamado Internet Network Information Center (o InterNIC), al cual debe recurrirse para solicitar la creacin de un subdominio de los dominios de alto nivel. El InterNIC, por su parte, delega la administracin de los dominios regionales a las autoridades del pas correspondiente; en el caso de la Argentina, es responsabilidad de la Cancillera. Dichas organizaciones son las responsables de decidir la forma en que particionarn el dominio regional. Usualmente, tal como ocurre en Argentina, deciden hacer un paralelo de los dominios organizacionales de alto nivel. As, por ejemplo, existen los dominios com.ar, org.ar, gov.ar, edu.ar, etc. Sin embargo, algunos pases deciden seguir algn otro tipo de esquema; por ejemplo, algunos de los subdominios de Gran Bretaa son co.uk (por "corporations"), ac.uk (por "academic community"), etc. Cuando una organizacin poseedora de una red desea que se le asigne un dominio, deber primero decidir bajo que dominio desea ubicarse, para luego solicitar al organismo que lo administre la delegacin de un subdominio. Si dicho organismo considera pertinente la
21

A pesar de esto, y por tradicin histrica, las organizaciones norteamericanas no se inscriben en el dominio regional de los EE.UU sino directamente en los dominios organizacionales de alto nivel. En "DNS and BIND" de Albitz & Cricket se hace la siguiente aclaracin: "La excepcin es Gran Bretaa. De acuerdo a ISO 3166 el dominio de la Gran Bretaa debiera ser gb, pero en su lugar, Gran Bretaa e Irlanda del Norte utilizan uk (por United Kingdom). Tambin conducen los automviles del lado equivocado de la calle"

22

37

solicitud, crear el dominio solicitado y a partir de ese momento la organizacin solicitante ser la responsable de administrarlo, pudiendo agregar mquinas al dominio o incluso particionarlo en mas subdominios. Por ejemplo, la Universidad Tecnolgica Nacional gestion en Cancillera el dominio utn.edu.ar al cual pertenecen las computadoras del Rectorado (en Buenos Aires); luego decidi crear un subdominio para cada una de sus Facultades Regionales. As, por ejemplo, existen los dominios frc.utn.edu.ar (Facultad Crdoba), frba.frc.utn.edu.ar (Facultad Buenos Aires), frlp.frc.utn.edu.ar (Facultad La Plata), etc. Dentro de un dominio, sus administradores estn en libertad de crear nombres para sus computadoras. El nombre que se asigne a cada mquina se combinar con el nombre del dominio para formar el Nombre de Dominio Totalmente Calificado (conocido como FQDN, por Fully Qualified Domain Name), tal como: khitomer.frc.utn.edu.ar De esta manera, aunque dos dominios tengan mquinas con el mismo nombre, siempre ser posible distinguirlas por medio del FQDN23. En sntesis, la estructura del DNS puede reflejarse de la siguiente manera (con el dominio raz representado por un punto):
.

com

edu

org

gov

mil

net

ar

com

edu

org

gov

mil

net

utn

frba

frc

frlp

Resolucin de nombres basada en DNS

Supongamos que un programa ejecutndose en una mquina en el dominio frc.utn.edu.ar requiere iniciar una conexin con otra computadora. Dado que el primer paso es obtener su direccin IP, dicha aplicacin deber realizar una peticin de resolucin a algn server de nombres. Como se mencion anteriormente, un server de nombres posee las tablas de direcciones y nombres referentes a uno o ms dominios. Si la peticin de resolucin hace referencia a una mquina perteneciente a alguno de los dominios administrados localmente (en cuyo caso se dice que el server tiene autoridad sobre ese dominio), el server consulta la tabla respectiva y contesta la peticin. En caso contrario deber realizar una serie de consultas siguiendo la jerarqua de dominios a partir del dominio raz, hasta encontrar el server que tiene autoridad sobre el dominio al cual pertenece el nombre buscado. Supongamos, por ejemplo, que se intenta resolver el nombre andromeda.galaxia.org.ar. El server de nombres local (frc.utn.edu.ar) redirige la consulta a los servidores de nombres del
23

De hecho, la nica forma de referenciar una computadora desde otra red es por medio de su FQDN.

38

dominio raz, los cuales le contestan con la direccin IP del server DNS del dominio ar. El server local realiza una nueva consulta, esta vez al server de ar, quien responde con la direccin del server que tiene autoridad sobre org.ar. Tras una nueva consulta, el server local recibe la direccin del servidor de nombres de galaxia.org.ar, que al ser consultado retorna la direccin IP de la computadora andrmeda. Esta estrategia de consulta se denomina iterativa, debido a que el server de nombres local recibe como respuesta la direccin de otro server de nombres, por lo que debe repetir la operacin (esto es, iterar) hasta que reciba la direccin IP del nombre a resolver. Existe otra posible configuracin, llamada recursiva, segn la cual un server de nombres puede ser configurado de tal forma que retorne siempre la direccin final buscada; si, por ejemplo, el server de nombres de ar fuera recursivo, en vez de retornar la direccin de org.ar para que luego el server que inici la consulta contine iterando, realizara la iteracin l mismo. Cualquiera sea la estrategia utilizada, puede observarse que una nica resolucin implica mltiples consultas a travs de la Internet. Para minimizar demoras en las comunicaciones, el diseo del DNS incluye la posibilidad de que los servidores de nombres guarden temporalmente las respuestas a las consultas que se han recibido, es decir, mantienen un cache de consultas previas que pueden ser reutilizadas si la consulta se repite.

El Dominio de Reversa
Un server DNS permite tambin realizar operaciones de resolucin inversa, esto es, obtener un nombre a partir de una direccin IP. Para ello, existe un dominio especial llamado in-addr.arpa y conocido como dominio de reversa, cuyos subdominios se forman a partir de los valores numricos de las direcciones IP, tomados en orden inverso. Por ejemplo, la direccin 1.3.25.170.in-addr.arpa. IP 170.25.3.1, pertenece al dominio de reversa

Cuando a una red se le asigna un nmero de red, usualmente tambin se le delega la administracin de su correspondiente dominio de reversa. Por ejemplo, el dominio de reversa correspondiente a 170.25 sera 25.170.in-addr.arpa, quedando en manos de su administrador la decisin de crear subdominios para cada una de sus subredes (por ejemplo, 1.25.170.in-addr.arpa, 2.25.170.in-addr.arpa, etc.)

Configuracin de un servidor DNS usando BIND

La implementacin estndar de DNS para Unix es BIND (Berkely Internet Name Domain) y consiste en un mdulo cliente llamado "resolver" que se integra a las aplicaciones, y un demonio llamado named, que debe ejecutarse en aquella computadora que se designe como server de nombres del dominio. Si bien el tratamiento completo de la configuracin de ste paquete de software escapa al alcance de ste trabajo, se discutirn a continuacin los aspectos bsicos de su configuracin.

Tipos de Servidores de Nombres

BIND soporta tres modos de configuracin para el servidor de nombres: Primario: fuente autorizada de informacin sobre un determinado dominio, lo cual significa que un servidor de nombres primario es quien tiene la informacin completa y ms actualizada sobre los nombres de computadoras pertenecientes al dominio. Dicha informacin se obtiene a partir de archivos de datos construidos por el administrador de la red (llamados archivos de zona).

Secundario: mantiene una copia de la informacin sobre un determinado dominio, transfirindola peridicamente desde un server de nombres primario (operacin llamada transferencia de zona). Tambin se considera fuente autorizada de informacin sobre ese dominio.

39

Cache:

responde consultas haciendo peticiones a otros servidores de nombres, y las almacena localmente para agilizar futuras consultas por la misma informacin. Sin embargo, no mantiene la base de datos de ningn dominio (esto es, no tiene autoridad sobre ningn dominio en particular).

Archivos de configuracin
named requiere un archivo de configuracin llamado /etc/named.boot y varios archivos de zona, segn los dominios que se vayan a administrar. El archivo /etc/named.boot define parmetros generales para la configuracin del servidor, en especial el modo de operacin (primario, secundario o cache) y la ubicacin y nombres de los archivos de zona. El archivo /etc/named.boot tpico para configurar el server de nombres primario de una red como la del dominio galaxia.org.ar contendr la siguiente informacin:
; ; Server de nombres primario de galaxia.org.ar ; directory /etc primary galaxia.org.ar named.hosts primary 25.170.in-addr.arpa named.rev primary 0.0.127.in-addr.arpa named.local cache . named.cache

Cada lnea del archivo /etc/named.boot especifica una directiva de configuracin, excepto aquellas que comiencen con punto y coma (;), que se consideran comentarios y son ignoradas. La directiva directory indica el directorio donde named podr encontrar los archivos de datos que se mencionen a continuacin. La directiva primary configura el server de nombres para ser servidor primario del dominio que se indica a continuacin, obteniendo la lista de nombres y direcciones desde el archivo que figura como ltimo parmetro. En ejemplo anterior, puede verse que el server de nombres ser server primario de los dominios galaxia.org.ar (el dominio asignado a la organizacin), 25.170.in-addr.arpa (el dominio de reversa correspondiente a la direccin asignada a la red) y 0.0.127.in-addr.arpa (el dominio de reversa de la red de loopback). Finalmente, con la directiva cache se indica a named el archivo a utilizar como contenido inicial del cache de direcciones y nombres. Es en este archivo donde se indican las direcciones IP de los servidores de nombres del dominio raz. La configuracin de un server secundario resulta similar:
; ; Server de nombres secundario de galaxia.org.ar ; directory secondary galaxia.org.ar 170.25.4.254 secondary 25.170.in-addr.arpa 170.25.4.254 primary 0.0.127.in-addr.arpa cache .

/etc named.hosts named.rev named.local named.cache

En lugar de la directiva primary se utiliza la directiva secondary, cuyos argumentos son el nombre del dominio, la direccin IP del server primario desde donde transferir los archivos de datos y el nombre del archivo local donde almacenarlos. Dichos archivos sern

40

creados automticamente la primera vez que el server se inicie, y sern actualizados peridicamente.

Archivos de Zona
Al definir un server primario, utilizando la directiva primary, el administrador indica el nombre del archivo de zona desde donde obtener los datos. La diferencia entre zona y dominio es sutil: una zona contiene la informacin sobre un dominio y todos aquellos subdominios que no han sido delegados a otro server. La particin en subdominios se realiza fundamentalmente para agrupar conceptualmente computadoras relacionadas, idealmente con el objetivo de delegar en sus usuarios la administracin de la informacin sobre las mismas. Sin embargo, puede ocurrir que los mismos no estn en condiciones de hacerse cargo de esas tareas (por falta de equipamiento, capacitacin, etc.), en cuyo caso el administrador de la red puede optar por crear los subdominios, pero no delegarlos. Obviamente, en un dominio cuyos subdominios han sido todos delegados, la zona y el dominio coinciden. Un archivo de zona est compuesto por registros, cuya sintaxis es la siguiente (los campos entre corchetes son opcionales):

[nombre] [ttl] IN tipo datos

en donde: nombre: es el nombre de la entidad que el registro define (direcciones, nombres, etc.). Dicho nombre es relativo al dominio actual y si se omite, se considera igual al valor del campo nombre del registro anterior. es un valor numrico (en segundos) que indica cuanto tiempo ese registro debe conservarse en el cache antes de ser refrescado (es la abreviatura de Time To Live). Si se omite, se considera igual al ttl por defecto de la zona (ver registro SOA, mas adelante). identifica el tipo de registro: Tipo SOA NS A PTR MX CNAME Funcin Start Of Authority. Indica el inicio de la zona, y define parmetros generales para la misma Name Server. Define el nombre del server de nombres del dominio. Address. Define la direccin IP asociada a un nombre. Pointer. Define el nombre asociado a una direccin IP. Mailer Exchange. Define el nombre del host que recibe el correo electrnico para un determinado nombre del dominio. Canonical Name. Define un alias para un host.

ttl:

tipo:

datos:

informacin especfica, dependiente del tipo de registro.

El archivo de zona para un dominio como galaxia.gov.ar, llamado named.hosts como se indic en named.boot, tendr el siguiente contenido:

41

; ; ; @ (

server de nombres primario de galaxia.org.ar IN SOA cygni.galaxia.org.ar. 1998062202 43200 3600 3600000 360000 ) ; ; ; ; ; root.cigni.galaxia.org.ar.

nro de serie refresco cada 12 horas reintentar despues de 1 hora expirar despues de 1000 horas ttl por defecto en 100 horas

galaxia.org.ar. IN galaxia.org.ar. IN localhost antares rigel cygni orion altair orion aldebaran orion andromeda canopus cygni centauri andromeda mailhost www IN A IN IN IN IN IN IN IN IN IN IN IN IN IN A A A A A A A A A A A A A

NS MX 10 127.0.0.1

cygni.galaxia.ar. andromeda.galaxia.ar.

170.25.1.1 170.25.1.2 170.25.1.253 170.25.1.254 170.25.2.1 170.25.2.254 170.25.3.1 170.25.3.254 170.25.3.253 170.25.4.1 170.25.4.252 170.25.4.253 170.25.4.254

IN CNAME andromeda.galaxia.org.ar. IN CNAME orion.galaxia.org.ar

Como puede verse, el archivo comienza con un registro SOA que declara el inicio de una zona. El smbolo @ en el registro SOA hace referencia al dominio actual, esto es, el que se indica en la directiva primary del archivo named.boot. El primer nombre que figura continuacin es el nombre de la computadora que contiene este archivo, seguido de la direccin de correo del administrador del DNS (obsrvese que no contiene un @ sino un punto luego del nombre del usuario). Seguidamente aparecen entre parntesis valores de configuracin generales de la zona, como el ttl por defecto y el perodo de refresco de los datos (esto es, cada cuanto named deber releer el archivo de zona para verificar si ha habido cambios en el mismo). Particularmente importante es el nmero de serie del archivo de zona (primer parmetro numrico del registro SOA). Este nmero deber ser incrementado por el administrador cada vez que introduzca un cambio en los datos de la zona. Por medio de ese valor, un servidor secundario sabr que debe pedir una transferencia de zona a fin de actualizar su copia local del archivo. Es prctica comn escribir ese nmero como una codificacin de la fecha en que se realizo el cambio (en formato Ao/Mes/Da), seguida de un numero de versin, por si se realiza ms de un cambio en la misma fecha. Obsrvese que ninguno de los registros posteriores especifica un valor de ttl; todos ellos toman el valor por defecto especificado en el registro SOA. Adems los registros NS y MX no especifican el campo nombre. A continuacin del registro SOA aparece el registro NS, que define que el nombre del servidor de nombres de galaxia.org.ar es la computadora llamada cygni. Lo sigue un registro MX, que indica que el correo electrnico destinado a ste domino deber ser
42

enviado a la computadora andrmeda (obsrvese que el nombre que se especifica debe terminar con punto; si no fuera as, se asumira que ese nombre debe completarse con el nombre del dominio actual). Finalmente, se listan los registros A, que establecen la relacin entre un nombre y una direccin IP y un par de registros CNAME, que definen aliases para ciertas computadoras (por ejemplo, especifican que www.galaxia.org.ar es equivalente a orion.galaxia.org.ar).

Archivos de zona para dominios de reversa

El archivo named.boot indicaba que se administraran dos dominios de reversa: uno para las direcciones correspondientes a la direccin de red y otro para la red de loopback. Los archivos de zona de un dominio de reversa contienen registros de tipo PTR. En dichos registros se utilizan los bytes de la parte de host de la direccin IP para el campo nombre, tomndolos en orden inverso. El dato asociado a cada registro es el nombre correspondiente a esa direccin IP. El archivo de zona para la red de loopback es virtualmente idntico en todas las configuraciones: @ ( IN SOA cygni.galaxia.org.ar. 1 43200 3600 3600000 360000 ) galaxia.org.ar. 1 IN IN ; ; ; ; ; root.cigni.galaxia.org.ar.

nro de serie refresco cada 12 horas reintentar despues de 1 hora expirar despues de 1000 horas ttl por defecto en 100 horas

NS PTR

cygni.galaxia.ar. localhost

El contenido del archivo named.rev es similar: @ ( IN SOA cygni.galaxia.org.ar. 1998102305 43200 3600 3600000 360000 ) galaxia.org.ar. IN 1.1 2.1 253.1 254.1 1.2 254.2 1.3 254.3 253.3 1.4 252.4 253.4 254.4 IN IN IN IN IN IN IN IN IN IN IN IN IN PTR PTR PTR PTR PTR PTR PTR PTR PTR PTR PTR PTR PTR ; ; ; ; ; root.cigni.galaxia.org.ar.

nro de serie refresco cada 12 horas reintentar despues de 1 hora expirar despues de 1000 horas ttl por defecto en 100 horas

NS

cygni.galaxia.ar.

antares rigel cygni orion altair orion aldebaran orion andromeda canopus cygni centauri andromeda
43

Archivo de inicializacin del cache

Como se mencion anteriormente, el archivo named.cache contendr las direcciones IP de los servidores de nombres del dominio raz, y se utilizar como el contenido inicial del cache. El archivo tendr el siguiente aspecto: ; ; Nombres de los servidores del dominio raiz ; . 99999999 IN NS A.ROOT-SERVERS.NET. 99999999 IN NS B.ROOT-SERVERS.NET. 99999999 IN NS C.ROOT-SERVERS.NET. 99999999 IN NS D.ROOT-SERVERS.NET. 99999999 IN NS E.ROOT-SERVERS.NET. 99999999 IN NS F.ROOT-SERVERS.NET. 99999999 IN NS G.ROOT-SERVERS.NET. 99999999 IN NS H.ROOT-SERVERS.NET. 99999999 IN NS I.ROOT-SERVERS.NET. ; ; Direcciones de los servidores del dominio raiz ; A.ROOT-SERVERS.NET. 99999999 IN A 198.41.0.4 B.ROOT-SERVERS.NET. 99999999 IN A 128.9.0.107 C.ROOT-SERVERS.NET. 99999999 IN A 192.33.4.12 D.ROOT-SERVERS.NET. 99999999 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 99999999 IN A 192.203.230.10 F.ROOT-SERVERS.NET. 99999999 IN A 192.5.5.241 G.ROOT-SERVERS.NET. 99999999 IN A 192.112.36.4 H.ROOT-SERVERS.NET. 99999999 IN A 128.63.2.53 I.ROOT-SERVERS.NET. 99999999 IN A 192.36.148.17

Como se puede apreciar, el archivo contiene registros NS que definen los nombres de los servidores de nombre del dominio raz, y registros A con sus direcciones IP. Una lista completa y actualizada de estos servidores puede obtenerse por FTP annimo, desde ftp://nic.ddn.mil/netinfo/root-servers.txt.

Configuracin del "resolver"

Como ya se dijo, las aplicaciones que utilizan los servicios de un server DNS lo hacen por medio de un mdulo del sistema operativo llamado resolver. En Unix, el resolver se configura por medio del archivo /etc/resolv.conf, cuyo contenido mnimo consta de las siguientes directivas: domain galaxia.org.ar nameserver 170.25.1.253

La directiva domain indica cual es el dominio por defecto, mientras que la directiva nameserver especifica la direccin IP del servidor de nombres a utilizar para peticiones de resolucin. Pueden indicarse varias de estas directivas, para utilizar servidores de nombres alternativos.

44

Consultando interactivamente un servidor de nombres

El paquete BIND provee una herramienta de depuracin llamada nslookup que puede utilizarse para hacer consultas interactivamente a un servidor de nombres. Al ser ejecutada desde la lnea de comandos, nslookup informa cual es el server de nombres que se utilizar y queda a la espera de comandos del usuario: $ nslookup Default server: cygni.galaxia.org.ar Address: 170.25.1.253 > _ Si se escribe el nombre de una computadora, nslookup realizar la consulta al server de nombres y nos mostrar el resultado: $ nslookup Default server: cygni.galaxia.org.ar Address: 170.25.1.253 > rigel Server: cygni.galaxia.org.ar Address: 170.25.1.253 Name: andromeda.galaxia.org.ar Address: 170.25.1.2

De manera similar, es posible utilizar nslookup para hacer consultas sobre otro dominio: $ nslookup Default server: cygni.galaxia.org.ar Address: 170.25.1.253 > bbs.frc.utn.edu.ar Server: cygni.galaxia.org.ar Address: 170.25.1.253 Name: bbs.frc.utn.edu.ar Address: 170.210.248.214

45

Diagnstico de una red TCP/IP

Una vez que la red ha sido diseada y configurada, sus usuarios comienzan a trabajar sobre ella y a utilizar sus servicios. Es un hecho que, tarde o temprano, alguno de ellos tendr alguna dificultad para acceder a algn servicio y recurrir al administrador de la red a fin de obtener una solucin. Sin embargo, antes de poder ofrecer alguna, el administrador deber diagnosticar el problema, esto es, hallar sus causas.

Mensajes de error usuales

Hay ciertas condiciones de error que son usuales en una red TCP/IP. Si bien los mensajes de error con que las aplicaciones informan al usuario acerca de las mismas son altamente dependientes de la plataforma, la mayora de las veces son similares a los siguientes: Unknown host: El nombre de host utilizado por el usuario no pudo resolverse; es decir, no pudo obtenerse su direccin IP. Puede ser indicativo de un error en el acceso al servidor de nombres: quizs es errnea la direccin IP indicada en el archivo /etc/resolv.conf, o el demonio named no se encuenta activo en esa computadora, o el mdulo TCP/IP de la misma no se encuentra funcionando correctamente. Sin embargo, tambin puede deberse a un error en el tipeo del nombre (esto es, podra no existir una computadora con el nombre indicado). El sistema local no tiene una ruta que conduzca a la red a la que corresponde la direccin IP de la mquina remota. Puede deberse a un error en la configuracin de la tabla de ruteo, a que la ruta se haya vuelto inalcanzable (por ejemplo, porque el gateway o los vnculos de comunicacin que conectan con ella estn fuera de lnea) o a que la direccin IP utilizada es errnea. El sistema remoto no contesta las peticiones realizadas desde el host local. En este caso, usualmente la direccin IP es correcta y existen rutas a la red a la cual pertenece, pero el host no puede ser contactado debido a que, por ejemplo, se encuentra apagado o desconectado de la red. Este error indica que, si bien pudo contactarse al host remoto, el mismo deneg la conexin. Puede deberse a medidas de seguridad (es decir, la computadora remota por alguna razn de seguridad no permite el acceso desde la computadora local al servicio que se le requiere) o a que no hay un servicio "escuchando" en el puerto TCP indicado desde la computadora local (por ejemplo, se desea acceder al demonio named en la computadora remota, y el mismo no se encuentra ejecutndose all).

Network unreachable:

No answer from host:

Connection refused by peer:

Herramientas de diagnstico
Algunas de las herramientas ofrecidas por Unix para diagnosticar problemas de red (y usualmente disponibles tambin en otras plataformas) son las siguientes: ping: Es la herramienta bsica para verificar la conectividad de la red. Permite determinar si un host es alcanzable y proporciona estadsticas sobre los tiempos de respuesta de la red.

traceroute24: Muestra la ruta que los paquetes seguirn desde un host de origen hasta otro host de destino. Permite, entonces, diagnosticar problemas de ruteo.

24

Bajo Windows NT, este comando est disponible bajo el nombre de tracert.

46

nslookup:

Permite hacer consultas interactivas a un servidor DNS, tal como se discuti en el captulo anterior. Despliega informacin sobre la tabla de ruteo, las interfaces y los sockets activos. Si bien es bsicamente una herramienta de configuracin, puede utilizarse tambin como herramienta de diagnstico, para detectar errores en la direccin IP, mascara de subred o direccin de broadcast (ver captulo sobre asignacin de direcciones IP).

netstat:

ifconfig:

Testeo de alcanzabilidad
El primer paso para diagnosticar un problema en una red TCP/IP es verificar la alcanzabilidad de un host, esto es, si es posible enviar paquetes al mismo a travs de la red. La herramienta primordial para testear alcanzabilidad es ping, cuya sintaxis bsica es la siguiente:
ping nombre_de_host_o_direccin_IP

Por ejemplo, para verificar si el host Rigel es alcanzable, habra que ejecutar el siguiente comando:
$ ping rigel PING rigel.galaxia.org.ar (170.25.1.2): 56 data bytes 64 bytes from 170.25.1.2: icmp_seq=0 ttl=64 time=0.1 ms 64 bytes from 170.25.1.2: icmp_seq=1 ttl=64 time=0.1 ms 64 bytes from 170.25.1.2: icmp_seq=2 ttl=64 time=0.1 ms 64 bytes from 170.25.1.2: icmp_seq=3 ttl=64 time=0.1 ms 64 bytes from 170.25.1.2: icmp_seq=4 ttl=64 time=0.1 ms 64 bytes from 170.25.1.2: icmp_seq=5 ttl=64 time=0.1 ms 64 bytes from 170.25.1.2: icmp_seq=6 ttl=64 time=0.1 ms 64 bytes from 170.25.1.2: icmp_seq=7 ttl=64 time=0.1 ms 64 bytes from 170.25.1.2: icmp_seq=8 ttl=64 time=0.1 ms 64 bytes from 170.25.1.2: icmp_seq=9 ttl=64 time=0.1 ms ^C --- rigel.galaxia.org.ar ping statistics --10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 0.1/0.1/0.1 ms

ping enva paquetes al host remoto utilizando el protocolo ICMP, los cuales, de ser recibidos por dicho host, generan un paquete similar de respuesta para el host local. Cuando el host local los recibe, muestra una lnea de informacin por pantalla, y el ciclo contina hasta que el usuario lo cancele con Control-C. Al terminar, ping muestra un reporte estadstico, en el que informa la cantidad de paquetes transmitidos y recibidos, y el porcentaje de prdida de paquetes. Tambin se informa sobre los tiempos mnimo, promedio y mximo que toma el recorrido de ida y vuelta entre ambos hosts. Como puede verse, ping permite adems determinar el nivel de carga de la red: si el porcentaje de perdida de paquetes o los tiempos de ida y vuelta es muy alto, podra ser un indicio de sobrecarga de trfico, interferencias en el medio de comunicacin, o inclusive problemas de hardware.

Verificacin del estado de las interfaces

Como se recordar el comando ifconfig, al ser invocado sin argumentos, muestra el estado actual de las interfaces de red configuradas:

47

$ ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0 UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1 RX packets:331036 errors:0 dropped:0 overruns:0 TX packets:331036 errors:0 dropped:0 overruns:0 eth0 Link encap:Ethernet HWaddr 00:10:4B:38:27:BA inet addr:170.25.2.254.216 Bcast:170.25.2.244 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4563766 errors:1 dropped:0 overruns:1 TX packets:5864531 errors:0 dropped:0 overruns:0 Interrupt:11 Base address:0x6100 eth1 Link encap:Ethernet HWaddr 00:10:4B:62:45:81 inet addr:170.25.3.254 Bcast:170.25.3.254 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4279043 errors:3 dropped:0 overruns:1 TX packets:2940848 errors:0 dropped:0 overruns:0 Interrupt:10 Base address:0x6200

En el listado anterior, se muestran 3 interfaces (dos placas Ethernet y la interfaz lgica de loopback). En todos los casos, se muestra la direccin de IP asignada, as tambin como la direccin de broadcast y la mscara de subred. En el caso de las placas Ethernet, se informa tambin la direccin fsica del adaptador (o MAC Address), y caractersticas de configuracin del adaptador (nmero de interrupcin y direccin base de I/O). Las lneas que comienzan con RX y TX presentan un informe del funcionamiento de la interfaz en trminos de cantidad de paquetes recibidos y transmitidos, respectivamente. Tambin se informa en cada caso la cantidad de paquetes errneos detectados por la interfaz. Informacin similar en un formato mas compacto puede obtenerse con el comando netstat -i:
$ netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR lo 3584 0 331036 0 0 0 eth0 1500 0 4563766 1 0 0 eth1 1500 0 4279043 3 0 0

TX-OK TX-ERR TX-DRP TX-OVR Flag 331036 0 0 0 BLRU 5864531 0 0 0 BRU 2940848 0 0 0 BRU

Verificacin de las rutas

Por medio de los comandos ifconfig y netstat -i podemos determinar el estado de las interfaces locales, a fin de determinar si son capaces de enviar y recibir paquetes. Usando ping podemos verificar si el host remoto "es visible" desde el host local a travs de la red. Si la comprobacin de las interfaces muestra que su estado es el correcto, pero ping no da resultados positivos, el siguiente paso en el diagnstico de un problema de conectividad con un host remoto es determinar que tan lejos llegan los paquetes. El comando traceroute permite verificar cual es la ruta que los paquetes siguen para llegar a un host remoto, y de esa manera detectar errores en la configuracin de las tablas de ruteo:
$ traceroute canopus

48

tracing to canopus.galaxia.org.ar (170.25.4.1), 30 hops max, 40 bytes packets 1 orion (170.225.1.254) 0.361 ms 0.302 ms 0.296 ms 2 andromeda (170.25.3.253) 44.366 ms 38.533 ms 13.282 ms 3 canopus (170.25.4.1) 28.743 ms 50.976 ms 39.28 ms

Como puede verse, traceroute se invoca con el nombre de un host remoto, y muestra como resultado todos los gateways intermedios que se atraviesan hasta llegar a destino. La informacin se recaba por medio del envo de paquetes ICMP; si alguno de ellos se perdiera en el camino, traceroute mostrar una serie de asteriscos. Por ejemplo, supongamos que el usuario de la computadora Antares reporta la imposibilidad para conectarse a Canopus. El primer paso en el diagnstico sera revisar la configuracin de las interfaces con ifconfig y luego verificar si realmente no hay conectividad, utilizando ping. Si ese fuera el caso, puede deberse tanto a que Canopus est fuera de lnea como a que exista algn problema en algn punto intermedio de la red. Por medio de traceroute puede determinarse cual es el caso. Supongamos que la salida de traceroute es la siguiente:
$ traceroute canopus tracing to canopus.galaxia.org.ar (170.25.4.1), 30 hops max, 40 bytes packets 1 orion (170.225.1.254) 0.361 ms 0.302 ms 0.296 ms 2 andromeda (170.25.3.253) 44.366 ms 38.533 ms 13.282 ms 3 * * * 4 * * * 5 * * *

traceroute continuar mostrando asteriscos hasta llegar a los 30 intentos o hasta que el usuario lo cancele con Ctrl-C. La conclusin aqu es que la falta de conectividad se debe a que Canopus est fuera de lnea o bien los enlaces desde Andrmeda estan fallando. Podra probarse, por ejemplo, el utilizar ping para intentar llegar a otra computadora sobre la misma subred de Canopus (por ejemplo, ping centauri); si la respuesta es negativa se tratara de un problema de red, mientras que si es positiva, la respuesta es que Canopus est fuera de lnea. Si el resultado de traceroute fuera el siguiente:
$ traceroute canopus tracing to canopus.galaxia.org.ar (170.25.4.1), 30 hops max, 40 bytes packets 1 orion (170.225.1.254) 0.361 ms 0.302 ms 0.296 ms 2 * * * 3 * * * 4 * * * 5 * * *

entonces o bien hay un problema en el gateway o en las lneas de comunicacin hacia l. La cuestin puede zanjarse procediendo de manera similar al caso anterior.

49

Compartiendo archivos: NFS

NFS (Network File System) permite el acceso transparente a archivos y directorios ubicados en computadoras remotas, es decir, permite que usuarios y programas traten archivos remotos como si fueran locales. La computadora remota (llamada server NFS) pone ciertos directorios de su propio sistema de archivos a disposicin de otras computadoras exportndolos hacia la red. Para acceder a los archivos remotos, las computadoras que los utilizan (los clientes NFS) previamente deben montar alguno de los directorios exportados por el servidor en algn punto de su sistema de archivos (de la misma forma que los sistemas de archivos residentes en discos duros locales deben ser montados antes de poder ser utilizados).

Andrmeda (server NFS) / bin usr etc tmp net bin etc apps

Altair (cliente NFS) / bin usr etc tmp

bin

local

A modo de ejemplo, en el grfico anterior se muestra que Andrmeda, actuando como servidor NFS, exporta a la red el directorio /net, y que un cliente NFS, en ste caso Altair, lo monta en /usr/local. Esto significa que para los usuarios de Altair existen los directorios /usr/local/bin, /usr/local/etc y /usr/local/apps, pero en realidad dichos directorios estn ubicados en Andrmeda. NFS fue desarrollado originariamente por Sun Microsystems, y se transform en el standard para compartir archivos bajo plataforma Unix; tambin existen actualmente implementaciones de NFS para otros sistemas operativos.

Los demonios de NFS

Para ofrecer servicios NFS, una computadora debe ejecutar los siguientes demonios: rpc.nfsd: Es el demonio principal de NFS, responsable de manejar las peticiones de los clientes para acceder a archivos remotos.

rpc.mountd: Procesa las peticiones de montura de los clientes NFS. Algunas implementaciones de NFS requieren demonios auxiliares adicionales como los siguientes: biod: Demonio de E/S por bloques. Gestiona el lado del cliente de las peticiones de Entrada/Salida va NFS. Este demonio solo es necesario en el cliente NFS. Demonio de bloqueo. Este demonio se ejecuta tanto en el cliente como en el server, y gestiona las peticiones de acceso en modo exclusivo. Demonio de control de estado. Este demonio es requerido por rpc.lockd para monitorear las operaciones de E/S por NFS.

rpc.lockd:

rpc.statd:

50

Exportando directorios
Para exportar directorios desde un server NFS, el administrador debe listarlos en el archivo /etc/exports, teniendo en cuenta las siguientes consideraciones: No se pueden exportar subdirectorios de un directorio exportado, a menos que el subdirectorio se encuentre en otro dispositivo fsico; tampoco se pueden exportar directorios ubicados por arriba de un directorio exportado, a menos que pertenezcan a diferentes dispositivos fsicos. Solo es posible exportar directorios locales. El archivo /etc/exports contendr una lnea por cada directorio exportado, en la que se indicar la ruta completa al mismo, seguida por ciertos parmetros que configurarn el modo en que se exporta el directorio, los cuales permiten especificar cuales computadoras tienen derecho a montar remotamente el directorio exportado, y de que manera: /net /home/jperez /datos/ftp/public *.galaxia.org.ar(rw) canopus.galaxia.org.ar(rw) (ro)

En el ejemplo anterior, el server NFS exporta tres directorios: /net Accesible desde cualquier computadora del dominio galaxia.org.ar, en modo de lectura/escritura (rw = read/write). Accesible slo desde la computadora Canopus, tambin en modo de lectura/escritura.

/home/jperez

/datos/ftp/public Accesible desde cualquier computadora (de cualquier dominio), pero en modo de slo lectura (ro = read only).

Montando directorios
Los directorios remotos se montan localmente de la misma manera que otro sistema de archivos: manualmente por medio del comando mount, o listndolos en /etc/fstab para que se monten automticamente al inicializar el sistema operativo. En ambos casos, la sintaxis para especificar un directorio remoto es la siguiente: nombre_del_host:directorio_remoto Por ejemplo, para montar manualmente el directorio /net de Andrmeda en /usr/local de Altair, se debe ejecutar el siguiente comando: # mount andromeda:/net /usr/local Alternativamente, se podra agregar la siguiente lnea en /etc/fstab: andromeda:/net /usr/local nfs rw,bg 0 0 Obsrvese que al montar un directorio remoto pude indicarse la opcin bg a fin de realizar la operacin de montura en background. Si al momento de solicitar la montura el server NFS no se encuentra disponible, el cliente permanecer reintentando hasta que el server lo est. La opcin bg premite que esos reintentos continen en background y as no detener las dems operaciones del cliente que no dependen del acceso a ese recurso compartido. Cuanto tiempo el cliente permanecer reintentando depende de si la montura es dura (hard mounts) o blanda (soft mounts).

51

Por defecto, las monturas de directorios NFS son duras, lo cual significa que el cliente permanecer reintentando indefinidamente hasta recibir respuesta del server. Si la montura es blanda (en cuyo caso deber utilizarse la opcin soft en /etc/fstab o al montar manualmente con mount), al cabo de cierto nmero de reintentos la operacin fallar y retornar un mensaje de error al usuario, indicando que el server es inaccesible.

Administracin centralizada de hosts: NIS

Uno de los aspectos que puede volverse mas problemtico en la administracin de una red Unix es el mantenimiento de la consistencia en ciertos archivos de configuracin. Supngase que en una red como la de galaxia.org.ar se desea que todos los usuarios puedan utilizar cualquier computadora de la red, utilizando en todas ellas el mismo nombre de login y password. Ello implica que la base de datos de usuarios (esto es, el archivo /etc/passwd) deber ser igual en todas las computadoras de la red y que ante cada cambio (por ejemplo, al agregar un nuevo usuario o cuando un usuario cambia su password), dicho cambio deber ser propagado a todas las dems computadoras de la red. Si la red tiene pocas computadoras, la consistencia de los archivos replicados puede mantenerse manualmente, pero, a medida que la red crece, el trabajo y la probabilidad de cometer errores crece desmedidamente. NIS (sigla de Network Information Service, o Servicio de Informacin de Red) fue diseado para solucionar este problema, proveyendo los medios para administrar centralizadamente archivos de datos y diseminarlos luego en un grupo de computadoras que forman parte de un dominio NIS25. NIS es tambin un sistema cliente/servidor, en donde ciertas computadoras (denominadas servidores NIS) mantienen los archivos de datos (llamados mapas NIS) y responden consultas de otras computadoras (los clientes NIS) acerca de informacin contenida en esos archivos. Un dominio NIS puede contar con varios servidores NIS. Uno de ellos, el servidor NIS maestro, contiene la copia original de los archivos de datos y es responsable de mantener actualizado un grupo de servidores NIS esclavos, los cuales responden peticiones de los clientes, pero no modifican sus archivos de datos directamente. La arquitectura general de un dominio NIS se esquematiza en la siguiente figura:
Server NIS Maestro

Server NIS Esclavo

Server NIS Esclavo

Cliente NIS

Cliente NIS

Cliente NIS

Cliente NIS

Transferencia de Mapa

Peticin NIS

25

Un dominio NIS no tiene ninguna relacin con un dominio DNS, aunque muchas veces el administrador decide que ambos coindan.

52

Ejecutando NIS
Los detalles de configuracin de un dominio NIS varan segn la implementacin y estn mas all de los alcances del presente trabajo. No obstante, y a manera de referencia, cabe mencionar que hay tres piezas de software esenciales para ejecutar NIS: domainname, ypserv e ypbind26. El comando domainname permite asignar el nombre de dominio NIS a las computadoras que lo forman. ypserv, por otra parte, es el demonio que se ejecutar en el servidor NIS, mientras que ypbind deber ejecutarse tanto en el servidor como en los clientes.

26

El prefijo yp se debe a que anteriormente NIS se conoca bajo el nombre Yellow Pages (Paginas Amarillas)

53

Bibliografa recomendada
"Essential System Administration", por Aeleen Frisch "TCP/IP Network Administration", por Craig Hunt "DNS and BIND", por Paul Albitz & Cricket Liu "Managing NFS and NIS", por Hal Stern "Sistemas Operativos: diseo e implementacin" , por Andrew S. Tanenbaum "The Unix-Haters Handbook", por Simson Garfinkel, Daniel Weise & Steven Strassman

54