Redes TCP/IP bajo Unix - frlp.utn.edu.ar · Redes TCP/IP bajo Unix Conceptos básicos de Operación...

Redes TCP/IP bajo UnixConceptos básicos de Operación yAdministración.por Ing. Fernando A. Cuenca ([email protected])Laboratorio de Sistemas - UTN Facultad Córdoba

Introducción

El presente trabajo persigue 2 objetivos: en primer lugar, presentar al lector las posibilidadesque ofrece un ambiente de red basado en Unix; en segundo lugar, introducirlo en losconceptos básicos requeridos para administrar una red TCP/IP bajo el citado sistemaoperativo1.

No obstante lo anterior, se hacen dos aclaraciones al lector:

• Se asumirá que el lector posee conocimientos básicos de la terminología empleada entecnología de redes (LAN vs WAN, topologías, medios de transmisión, protocolos,conmutación por paquetes, etc.).

• "Lo maravilloso de los estándares es que hay muchos de donde elegir" -- AlmiranteGrace Murray Hooper2. Uno de los grandes mitos acerca de Unix es su nivel deestandarización. Si bien todas las diversas variantes (o flavors) de Unix comparten unafilosofía común muy amplia lo cual hace posible un alto grado de similitud entre todasellas, en el momento de afinar los detalles de la implementación suelen aparecerdiscrepancias (en particular, los nombres de los comandos, el formato y nombre de losparámetros, el formato de los resultados que se muestran por pantalla, etc.). Para éstearticulo se tomará al sistema operativo Linux (una variante de Unix de distribucióngratuita) como plataforma de referencia; será tarea del lector identificar las diferenciascon su propia plataforma y realizar las adaptaciones del caso.

1 Cabe aclarar, sin embargo, que la mayoría de los conceptos que se desarrollarán en elcapítulo de Administración son aplicables a casi todas las implementaciones de TCP/IP bajootras plataformas.2 La Almirante Grace Hooper participó en el diseño del lenguaje COBOL, durante la décadadel 60.

2

Figura 1:Computador PDP-8

Figura 2: TerminalVT100

Conectándose a Unix

Terminales "bobas", Workstations y PCsEl sistema operativo Unix fue concebido en los años 70. En aquellos tiempos, el modelo

imperante para los sistemas de computación era el que llegó aconocerse como "de tiempo compartido", en donde un equipocentral con capacidad de multiprogramación (conocido comohost) atendía simultáneamente a múltiples usuarios conectados almismo desde terminales remotas ubicadas en el mismo edificio oen otras locaciones conectadas al mismo a través de una red de

comunicaciones.

Dichas terminales estaban constituidas básicamente por un teclado, una pantalla y undispositivo de comunicaciones (usualmente de tipo serial, porejemplo basado en RS-232), y se denominaban "terminalesbobas" (dumb terminals) debido a que carecían por completode capacidad de procesamiento, mas allá de la necesaria paratomar caracteres desde el teclado, enviarlos al equipo centralpor el vínculo de comunicaciones y recibir desde él nuevoscaracteres que desplegar en la pantalla. De esta forma,resultaban meros dispositivos de interface entre el usuario y un

proceso en ejecución en la computadora central.

Luego, durante el transcurso de la década del 80 y conforme los costos de la tecnología decomputación disminuían crecientemente, fue creciendo una nueva concepción tendiente allevar poder de procesamiento más cerca del usuario.

Por una parte, las PC (Computadoras Personales) aparecieron en escena y rápidamenteempezaron a poblar las oficinas y mas tarde los hogares. Aquellas organizaciones que sevieron en la situación de enfrentar la coexistencia de equipos personales con centralizadosencontraron que podían aprovechar lo mejor de ambos mundos permitiendo el acceso desdelas PCs a las aplicaciones y datos corporativos corriendo bajo Unix, por medio de conexiónde las PCs al host Unix a través de conexiones seriales y la ejecución en la PC de unsoftware emulador de terminal. Dichos programas constituyen básicamente una terminalboba implementada en software, que utiliza el hardware de la PC de manera tal que lamisma se comporta como si se tratara de una terminal corriente (es decir, solo procesaentradas y salidas por teclado y pantalla, quedando el procesamiento de la aplicación enmanos del equipo central).

Por otra parte, en los ambientes de ingeniería e investigación, empezaron a aparecer potentescomputadoras personales basadas en Unix y construidas, usualmente, con tecnología RISC,denominadas workstations (estaciones de trabajo). Si bien estos equipos corríanbásicamente el mismo Unix que los equipos centralizados, explotaban más sus capacidadesde multiprocesamiento que la de atender múltiples usuarios simultáneos; es decir, se tratabade equipos con mucho potencial de cálculo, especialmente pensado para aplicaciones deingeniería o científicas, operados por un único usuario desde la consola (pantalla y tecladoconectado directamente al equipo), siendo muy poco usual que se las conectara a terminalesseriales a ser utilizadas por otros usuarios, a pesar de que el sistema operativo soportaba estamodalidad de trabajo.

3

Figura 3:Workstation Sun

Figura 4: Terminal "de copia dura"o teletipo

Si bien el pasar de equipos centralizados compartidos a equipos personales individualestrajo como beneficio un mayor poder de procesamiento y flexibilidad para los usuarios, sellevó consigo una de las ventajas de la computación centralizada: la posibilidad de compartirrecursos. Es por ello que la década del 80 no sólo es la década de la computación personal,sino también la de la popularización y crecimiento de las redes de área local (denominadasLAN). La idea de interconectar equipos en redes no era nueva; sin embargo, los esfuerzos deinvestigación y desarrollo en tal sentido se orientaban mas bien a la interconexión deequipos ubicados en locaciones distantes entre sí, formando redes de área amplia(conocidas como WAN), ya que el "área local" estaba dominada por equipos de conexióncentralizada. En el caso particular de Unix, la técnica de interconexión que se volvióstandard fue la basada en una familia de protocolos de comunicaciones denominada TCP/IP,mediante la cual dos equipos Unix interconectados podían intercambiar datos y permitir ausuarios conectados a uno de ellos iniciar nuevas sesiones de trabajo en el otro.

Cuando las workstations aparecieron en la escena a mediados de la década del 803, resultónatural que estuvieran preparadas con capacidades de conectividaden red. No obstante, el tipo de conectividad requerida no era a nivelWAN sino a nivel LAN, a fin de que pudieran interactuar con otrasworkstations y con equipos centralizados de mayor porte disponiblesen la organización. Se volvió entonces practica standard entre losfabricantes de workstations que las mismas contaran con capacidadde conectividad TCP/IP y hardware para conexión a una red LAN,utilizando la norma Ethernet, que finalmente terminó por convertirseen el standard para redes de estas características. De ésta manera, unusuario poseedor de una workstation podría ejecutar localmente susaplicaciones y al mismo tiempo iniciar sesiones de trabajo remotasen los servidores corporativos (y, por supuesto, en otrasworkstations disponibles en la red4).

Al mismo tiempo, las PCs fueron ganando terreno en el ámbito de las redes LAN (y, dehecho, resultaron finalmente sus principales impulsores). Sin embargo, no fue hastamediados de los 90 con la masificación del acceso a servicios Internet (la red TCP/IP porexcelencia) que TCP/IP se volvió un componente obligado del software de red de éstascomputadoras, desplazando a otros protocolos como IPX y NetBIOS, que dominaron laescena de las LAN entre PCs durante años. Como resultado, hoy puede utilizarse una PC debajo costo para acceder a servicios de datos y sesión remota sobre servidores Unix, demanera análoga a la que se utilizaría desde una workstation.

El Sistema X-WindowCabe mencionar finalmente otro tipo de conexión a sistemas Unix, para el cual hay queanalizar previamente el formato con que esas conexiones pueden realizarse.

Tradicionalmente, las terminales bobas fuerondispositivos "de caracteres", que permitíanconexiones en modo texto. Las primeras terminaleseran extremadamente primitivas; denominadas "ttysde vidrio", básicamente eran variaciones de losteletipos (de allí la denominación "tty") y únicamentepermitían desplegar líneas de caracteres y producir

avances de carro, sin que el programador tuvieracontrol alguno sobre el formateo y ubicación dedichos caracteres en la pantalla. Con el tiempo, fueronevolucionando hasta eliminar esas limitaciones (se

transformaron en terminales "de pantalla completa") y agregaron nuevas capacidades como

3 La primera workstation fue lanzada al mercado por Sun Microsystems en 1983.4 Esta concepción del trabajo en red llevó a Sun a acuñar el slogan "The network is thecomputer" ("La computadora es la Red").

4

Figura 5: TerminalX de Tektronics

diferentes estilos (caracteres parpadeantes, remarcados, subrayados, etc.), diferentes juegosde caracteres, caracteres gráficos, etc. Pero continuaron siendo terminales capaces demostrar solamente texto.

Mientras esto ocurría en el ámbito comercial, el MIT (Instituto de Tecnología deMassachusetts) se encontraba trabajando en el Proyecto Athena. Uno de los resultados deese proyecto fue un "sistema de presentación gráfica distribuida". La idea consistía enpermitirle a un programa, llamado cliente, ejecutarse en una computadora y enviar su salida(ya fuera esta texto o gráficos) por medio de enlaces TCP/IP a otro programa, llamadoservidor de ventanas (window server), en ejecución en la misma u otra computadora. Lascomputadoras del cliente y el servidor podrían ser inclusive totalmente diferentes (enhardware y/o sistema operativo), en tanto y en cuanto ambas estuvieran interconectadas dealguna 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 laaplicación se divide entre el Server-X (o servidor de ventanas) que tiene a cargo laadministración de los recursos físicos de presentación (es decir, manipula los recursos delhardware de visualización, las entradas por teclado y los eventos del mouse) al cual seconectan múltiples Clientes-X (es decir, las aplicaciones que el usuario ejecuta sobre elequipo central), vinculadas las mismas al Server-X por medio de enlaces TCP/IP.

Una de las aplicaciones de X-Window fue permitir la creación de un nuevo tipo determinales, conocidas como X-Terminals. Una X-Terminal es básicamente una terminalboba en el sentido de que no procesa localmente las aplicacionesdel usuario, pero la principal diferencia es que le ofrecen unainterfaz gráfica altamente sofisticada. Para ello, una X-Terminalimplementa el protocolo X y cuenta con un window server.Cuando el usuario, por medio de una X-Terminal, lanza unaaplicación, la misma se ejecuta en el host, excepto las operacionesde dibujo sobre la pantalla y la captura de eventos de teclado ymouse, que son ejecutadas por el Server-X localmente en la X-Terminal. En otras palabras, cuando el Cliente-X requieredesplegar algún tipo de información por pantalla, le envía unapetición al Server-X para que la lleve a cabo; de la misma manera,no es la aplicación la que realiza la lectura de teclado y la captura de eventos del mouse,sino que dicha operación la realiza en Server-X (sobre la X-Terminal) para luego notificar alCliente-X (en el host) cuando los eventos eventualmente ocurren. Todo ese diálogo entre elCliente-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. X-Window es un sistema de ventanas cliente/servidor. Una de las ventajas del modelocliente/servidor es que puede ser implementado tanto de manera distribuida (es decir, clientey servidor ejecutándose en computadoras diferentes) como local (cliente y servidorejecutándose en la misma computadora), debido a que lo único que establece es que debenexistir dos procesos (el cliente y el servidor) unidos a través de un canal de comunicaciones.Para el caso de X-Window, esto significa que tanto el Server-X como el Cliente-X podríaneventualmente ejecutarse en la misma computadora, tal como ocurre en una workstation.

Finalmente, y dado que ya en el espíritu inicial de los diseñadores de X-Window estabaembebido el concepto de independencia de plataforma entre el Cliente-X y el Server-X,resultó natural la eventual aparición de Servidores-X para plataformas completamentediferentes de Unix, tal como MS-Windows. Ello posibilitó utilizar una máquina Windowscomo si fuera una X-Terminal, una estrategia análoga a la utilizada anteriormente por mediode emuladores de terminal.

5

En resumen...Se han reseñado varias formas para conectarse a un host Unix:

• Por medio de una terminal boba conectada al host a través de un vínculoserial (directo o indirecto -- como por ejemplo, un módem);

• Por medio de una PC, un programa emulador de terminal y un vínculoserial al host (nuevamente, directo ó indirecto);

• Por medio de conexiones TCP/IP a través de una red LAN o WAN, desdeotro host Unix, una workstation, una PC o cualquier otro tipo decomputadora que cuente con software TCP/IP.

• Desde una X-Terminal o una computadora (PC, workstation, etc.) queimplemente el protocolo X5.

5 Este tipo de conexión es estrictamente otra forma de conexión TCP/IP. Se la menciona porseparado debido a que su formato es radicalmente diferente al de las conexiones TCP/IPmas conocidas (como por ejemplo, conexiones vía telnet).

6

Trabajando en una red Unix

Se discutirán a continuación algunas de las actividades más usuales que se realizan altrabajar en el entorno de una red TCP/IP bajo Unix:

• Sesiones remotas• Transferencia de archivos• Ejecución remota• Comunicación entre usuarios

A los fines de la ejemplificación, se asumirá que el entorno en el que está trabajando unusuario cuyo login name es jperez es el que se muestra en la figura siguiente, y quedicho usuario está actualmente conectado al host Antares, y que dispone de acceso a cuentasde usuario en el host Canopus, ambos corriendo alguna versión de Unix:

Antares

Canopus Red Local

Sesiones remotasIniciar una sesión remota significa conectarse desde una computadora a otra, a través de unared de comunicaciones, a los fines de ejecutar procesos a la distancia. En otras palabras, pormedio de sesiones remotas es posible trabajar en una computadora operándola remotamentedesde otra, ubicada quizás a grandes distancias; a los fines prácticos, resulta equivalente aestar sentado en la consola del sistema remoto.

En nuestro ejemplo, si el usuario jperez que se encuentra conectado a la computadoraAntares inicia una sesión remota en Canopus, a partir de ese momento todo comando queejecute lo hará en el procesador de Canopus.

Cabe aclarar que el acceso a un host Unix desde una terminal serial no se considera unasesión remota, por mas lejana que se encuentre físicamente ubicada la terminal. Las sesionesremotas entre sistemas Unix se realizan por medio de la ejecución de programas basados enTCP/IP, como los descriptos en las secciones siguientes.

Arquitectura de una sesión remotaLos programas de sesión remota bajo Unix trabajan según un esquema cliente/servidor, enel cual el usuario que desea iniciarla ejecuta localmente en su computadora un programa (elcliente) al cual le indica el nombre del host en el cual se iniciará la sesión. Dicho programase comunica por medio de TCP/IP con otro ejecutándose en background en la computadorade destino (el servidor), el cual, luego de autenticar la identidad del usuario y verificar quetiene permiso para utilizar el servicio, inicia un shell para interpretar los comandos queenvíe el usuario remoto:

7

Cliente de sesiónremota

Shell local

Servidor de sesiónremota

Shell remoto

El servidor de sesión remota asocia el shell remoto con una terminal virtual (o pseudo-tty)cuyas entradas y salidas están asociadas a una conexión de red. Así, todo lo que el usuarioteclee en su terminal será capturado por el cliente de sesión remota y enviado a través de lared al shell remoto; de manera similar el shell remoto enviará la salida de los comandos alusuario por la misma conexión de red. Cuando el usuario ejecute el comando para terminarel shell (usualmente, exit o Control-D ), el shell remoto finaliza y la sesión remota secierra.

Sesiones remotas utilizando rloginrlogin es el comando de sesión remota nativo de Unix. Su sintaxis básica es la siguiente:

rlogin nombre_de_host

Al ser invocado de esa forma, rlogin intenta iniciar una sesión remota en el host indicado,bajo el mismo nombre de usuario actual, previo ingreso de la palabra clave:

jperez@antares:$ rlogin canopusPassword:Last login: Mon Feb 10 15:30:45 from orion.jperez@canopus:$ _

Si la clave es ingresada correctamente, la sesión remota se inicia, rlogin informa la fecha yorigen del último ingreso al sistema y, a partir de ese momento, el usuario puede ejecutarcomandos en la máquina remota, obteniendo la salida de los mismos en el host local. Paracerrar la sesión, basta con ingresar el comando normal para finalizar el shell remoto, porejemplo, exit :

jperez@canopus:$ exitConection closed.jperez@antares:$ _

Si se desea iniciar una sesión remota bajo otra identidad (es decir, entrado como otrousuario), el login name correspondiente puede indicarse utilizando el comando -l:

jperez@antares$ rlogin -l plopez canopusPassword:plopez@canopus$ _

Como ya se dijo, rlogin pide la contraseña de la cuenta remota antes de permitir el acceso alshell. Sin embargo, es posible configurar rlogin de manera que considere equivalentes doscuentas y no pida password para iniciar sesiones. Continuando con el ejemplo anterior, si elusuario jperez tiene cuenta tanto en Antares como en Canopus, para evitar que se le pidapassword al iniciar una sesión remota con rlogin deberá crear en su directorio de login de lamáquina remota un archivo llamado .rhosts, y en el mismo listar los nombres de las

8

computadoras desde donde desea entrar sin password. También podría otorgar acceso libre aotros usuarios, listando los nombres de login a continuación del nombre de máquina.

Por ejemplo, si el archivo .rhosts ubicado en el directorio de conexión de jperez enCanopus contuviera la siguiente información:

antaresorion plopez

ello indicaría que el usuario jperez puede entrar a Canopus sin password desde Antares,mientras que el usuario plopez podrá hacer lo mismo desde Orión.

Cabe destacar que el uso del archivo .rhosts es un serio compromiso a la seguridad de lacuenta y es un recurso que debe ser utilizado con mucha precaución; en el ejemplo anterior,si alguien ganara acceso a la cuenta de jperez en Antares, automáticamente podría entrara la cuenta de Canopus. Como medida extra de seguridad, rlogin solo prestará atención alarchivo .rhosts si el mismo solo puede ser accedido por el usuario (es decir, si su modo esrw------- ó 600 en octal).

Sesiones remotas utilizando telnetEl comando rlogin fue diseñado teniendo en cuenta que tanto el host local como el remotoson máquinas corriendo Unix6. A fin de permitir sesiones remotas entre equipos consistemas heterogéneos, fue diseñado otro protocolo denominado TELNET.

Bajo Unix, puede establecerse una conexión TELNET con el siguiente comando:

telnet nombre_de_host

La principal diferencia entre telnet y rlogin es que el primero de estos siempre pide usuarioy password para iniciar la sesión:

jperez@antares:$ telnet canopusTrying 170.25.1.5Connected to canopus.galaxia.org.arEscape character is '^]'

Login: jperezPassword:Last login: Mon Feb 10 15:30:45 from orion.jperez@canopus:$ _

Aquí puede verse que el usuario jperez inicia una sesión de TELNET hacia Canopus.telnet inicialmente informa que está intentando establecer la conexión con el host remoto(línea Trying.... ) y luego de unos segundos indicará que la conexión se ha establecidocon éxito (línea Connected..... ). Seguidamente, telnet informa al usuario cual es elcarácter de escape, y pide el nombre de usuario y palabra clave para ingresar al host remoto.

El carácter de escape (que usualmente es Control-]) es un carácter que es interceptado por elprograma telnet ejecutándose en el host local, y no es enviado al host remoto como el restode los caracteres tipeados por el usuario. Se utiliza para llamar la atención del programatelnet, 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 conexión de red ejecutan eldemonio identd, que permite identificar el propietario de conexiones TCP.

9

Existen varios comandos que pueden utilizarse aquí, pero el mas usual es el comando exit ,utilizado para cortar la conexión, o ! (signo de admiración) que permite iniciar un subshellen el host local.

Sesiones remotas utilizando sshTanto telnet como rlogin utilizan protocolos de comunicación abiertos, en el sentido de quetodos los datos se transmiten sin ningún tipo de protección por encriptado. Esto significa quecualquier otra persona que tenga acceso al medio físico de transmisión podría (con losconocimientos y herramientas apropiadas) interceptar las transmisiones y eventualmenteobtener todo aquello que el usuario tipea en su terminal (especialmente, el nombre deusuario y la password) y las respuestas que envía el host remoto.

Esto hace que el uso de telnet o rlogin sea inapropiado cuando es necesario un nivel deabsoluta seguridad y privacía, especialmente cuando las comunicaciones se realizan a travésde largas distancias (por ejemplo, a través de la Internet).

Para superar esos inconvenientes, puede utilizarse como alternativa el sistema ssh (porSecure Shell, o Shell Seguro), el cual provee de un esquema de seguridad mucho massofisticado y encripta toda el intercambio de datos entre el host local y el remoto.

La sintaxis básica7 de ssh es igual a la de rlogin, es decir:

ssh [-l nombre_de_usuario] nombre_de_host

en donde la indicación del nombre de usuario (a través del parámetro -l) es opcional y seasume el login name actual por defecto.

Transferencia de archivosLos protocolos para transferencia de archivos permiten copiar archivos entre doscomputadoras, a través de una red. Se verán a continuación tres programas paratransferencia de archivos: ftp, rcp y scp.

Transferencia de archivos por ftpLa principal diferencia entre ftp y los otros comandos radica en el carácter interactivo deéste comando. Esto significa que ftp funciona a la manera de un shell: primeramenteestablece la conexión con el sistema remoto y luego queda a la espera de que el usuario leindique, por medio de un lenguaje de comandos, las operaciones a realizar.

Para iniciar una sesión FTP, debe ejecutarse en comando ftp indicándole como parámetro elnombre de la computadora remota, por ejemplo:

jperez@antares:$ ftp canopusConnected to canopus.galaxia.org.ar220 canopus.galaxia.org.ar FTP server ready.Name(antares:jperez): jperez331 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 deseguridad basado en palabra clave, como frases clave de acceso, certificados de identidad yvarios métodos de autenticación. Para mayores detalles, refiérase a la documentaciónprovista por el software.

10

ftp> _

Aquí, el usuario jperez inicia una conexión FTP a Canopus. Luego de indicar que laconexión se ha establecido y que el servidor FTP se encuentra listo, ftp pide el nombre deusuario con el que se va a ingresar al host remoto, y luego su correspondiente password. Sila misma se ingresa correctamente, el sistema remoto informa su tipo (en este caso, UNIX) yel modo de transferencia de archivos por defecto (en este caso, transferencia binaria) yqueda a la espera de comandos del usuario.

Adicionalmente de permitir la transferencia de archivos hacia cuentas del sistema remoto(esto es, la conexión se establece indicando una identidad de usuario registrada en el hostremoto e ingresando la palabra clave de esa cuenta), ftp fue diseñado para permitir el accesode usuarios anónimos a grandes repositorios de archivos, de acceso público. Usualmente losservidores FTP utilizan el nombre de usuario anonynmous para los accesos del público engeneral, quienes deberán utilizar su dirección de correo electrónico como password:

jperez@antares:$ ftp canopusConnected to canopus.galaxia.org.ar220 canopus.galaxia.org.ar FTP server ready.Name(antares:jperez): anonymous331 Guest login ok, send your complete e-mail address aspassword.Password: [email protected] Guest login ok, access restrictions apply.Remote system type is UNIX.Using binary mode to transfer files.ftp> _

Los dos comandos básicos de FTP para transferencia de archivos son put (para enviar unarchivo al host remoto) y get (para obtener un archivo desde el host remoto). Ambosoperan con un único archivo indicado como parámetro, desde y hacia el directorio actual(tanto local como remoto). Por ejemplo, el siguiente comando:

ftp> put informe.doclocal: informe.doc remote: informe.doc200 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 directoriodesde el cual se invocó al programa ftp en el host local) al directorio actual en lacomputadora remota. Luego de la transferencia, ftp informa la cantidad de bytestransmitidos y la velocidad de la transferencia.

Por otra parte, el comando:

ftp> get informe.doclocal: informe.doc remote: informe.doc200 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> _

11

El directorio actual en la computadora remota puede averiguarse por medio del comandopwd:

ftp> pwd257 "/home/jperez" is current directory.ftp> _

y puede cambiarse utilizando el comando cd , e indicando una trayectoria absoluta o relativa(de manera totalmente análoga al comando cd del shell):

ftp> cd documentos250 CWD command successful.ftp> pwd257 "/home/jperez/documentos" is current directory.ftp> _

FTP cuenta con un extenso juego de comandos, cuya lista puede obtenerse tipeando ?. Seofrece a continuación un resumen de algunos comandos de utilización frecuente:

ls Lista el contenido del directorio actualbinary Fuerza el modo de transferencia a BINARIOascii Fuerza el modo de transferencia a ASCII (poco recomendable!)lcd Cambia (o muestra) el directorio actual localdelete Borra un archivo en el host remotohash Muestra por pantalla una marca cada cierta cantidad de bytes

transmitidosmputmget

Permiten realizar transferencias múltiples, por medio de lautilización de comodines

prompt off Deshabilita la confirmación archivo por archivo en lastransferencias múltiples

La sesión de FTP finaliza cuando el usuario indica el comando bye :

ftp> bye221 Goodbye.jperez@antares:$ _

Transferencia de archivos por rcp y scpLos comandos rcp y scp son utilerías de línea de comandos para transmitir archivos; esto es,no reciben comandos interactivamente desde el usuario, sino que su funcionamiento seindica por medio de parámetros en la línea de comandos del shell. Es esta característica loque, al contrario que ftp, los hace útiles para la programación de scripts que realicentransferencias automáticas de archivos entre computadoras.

rcp pertenece al mismo paquete de comandos que rlogin, mientras que scp pertenece al dessh. Así la diferencia entre ambos radica en el nivel de seguridad: rcp transfiere los archivosen 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 parámetro -l es opcional, sirviendo para acceder al host remoto bajo otronombre de usuario. Los parámetros origen y destino son las especificaciones

12

(expresadas como trayectorias absolutas o relativas) del archivo a transmitir y la ubicaciónfinal del mismo respectivamente; uno de ellos deberá hacer referencia a la computadoralocal, mientras que el otro deberá referirse a la computadora remota. La sintaxis paraarchivos 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 seomite, el archivo transmitido será copiado bajo el mismo nombre en el directorio de logindel usuario en la computadora remota. Si el nombre de archivo se omite, la copia se hará enel directorio remoto indicado bajo el mismo nombre; si la trayectoria especificada esrelativa, se interpretará como relativa al directorio de login del usuario en la computadoraremota.

Por ejemplo, los siguientes comandos transfieren archivos de la maquina local al hostremoto Canopus:

$ scp informe.doc canopus:Copia el archivo informe.doc (ubicado en el directorio actual) aldirectorio de login en Canopus, con el mismo nombre

$ rcp notas/informe.doc canopus:notas/Copia el archivo informe.doc , bajo el directorio notas al directorionotas bajo el directorio de login de la maquina remota

$ scp informe.doc canopus:/usr/informes/info1.docCopia el archivo informe.doc , al directorio remoto /usr/informescon el nombre info1.doc

Para transferir desde el host remoto al host local, los comandos serían 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 elusuario haya configurado su cuenta remota para accederla sin solicitar password, por mediodel archivo .rhosts (tal como se describe en la sección de rlogin)

Ejecución remotaLos comandos para ejecución remota permiten ejecutar un único comando en un hostremoto, obteniendo su salida en el host local.

El comando tradicionalmente utilizado para este tipo de operaciones era rsh. Este comandocompleta la familia formada por rlogin y rcp, y al igual que este último, requiere de laexistencia del archivo .rhosts en el directorio de conexión remoto a fin de poder operar. Susintaxis es la siguiente:

rsh [-l nombre_de_usuario] host comando

Por ejemplo, el siguiente comando obtiene un listado del directorio de conexión de un hostremoto:

jperez@bbs:~$ rsh canopus ls -ltotal 13drwxr-xr-x 5 jperez jperez 1024 Sep 26 11:58 GNUstep-rw-rw-r-- 1 jperez jperez 1376 Sep 28 15:16 Xrootenv.0drwxrwxr-x 2 jperez jperez 1024 Oct 13 16:53 bindrwxrwxr-x 3 jperez jperez 1024 Oct 29 19:48 downloaddrwx------ 2 jperez jperez 1024 Sep 23 12:21 mail

13

drwxrwxr-x 2 jperez jperez 1024 Jul 2 14:34 mntdrwxr-xr-x 3 jperez jperez 1024 Jun 30 19:36 ns_imap-rw-r--r-- 1 jperez jperez 198762 Nov 1 20:46 informe.docdrwxrwxr-x 6 jperez jperez 1024 Oct 22 21:38 tempdrwxrwxr-x 9 jperez jperez 1024 Oct 29 19:49 trabajojperez@bbs:~$ _

Se aplican a este comando las mismas consideraciones de seguridad que se discutieron pararlogin, por lo que si la seguridad es crítica, puede ser reemplazado por el comando ssh, queofrece 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 yrealiza conexiones encriptadas.

Comunicación entre usuariosUnix es un sistema de naturaleza multiusuaria, es decir, soporta múltiples usuariosconectados simultáneamente, ejecutando procesos concurrentemente. En consecuencia,ofrece comandos que permiten a los usuarios comunicarse entre si, ya sea en tiempo real ode manera diferida.

Averiguando quien está conectado: fingerAntes de poder entablar una comunicación, es necesario saber quién está conectado alsistema. Normalmente, el comando para realizar dicha operación era who. Sin embargo, estecomando solo informa acerca de los usuarios conectados al sistema local. Si se desea saberquién está conectado a un host remoto debe utilizarse el comando finger:

jperez@antares:$ finger @canopus[canopus.galaxia.org.ar]Login Name Tty Idle Login Timeplopez Pedro Lopez 1 Feb 1 20:36fcuenca Fernando Cuenca p1 20m Feb 1 14:08arodrig Andrea Rodriguez p2 20m Feb 1 20:36

jperez@antares:$

Observar que el nombre del host remoto debe precederse de un signo @. De manera similar,finger permite obtener información sobre un usuario (local o remoto). Por ejemplo, si sequieren conocer los datos del usuario plopez del host local, puede utilizarse el siguientecomando:

jperez@bbs:~$ finger plopezLogin: plopez Name: Pedro LopezDirectory: /home/plopez Shell: /bin/shLast login Fri Oct 30 23:16 (ARDT) on tty1New 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 yubicación de la última conexión al sistema, e información sobre el correo electrónico delusuario.

También pueden obtenerse datos de usuarios de otras computadoras, utilizando la sintaxisusuario@computadora :

jperez@bbs:~$ finger arodrig@canopusLogin: arodrig Name: Andrea RodriguezDirectory: /home/arodrig Shell: /bin/sh

14

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

Comunicándose con talkUnix permite realizar charlas en tiempo real con usuarios conectados al sistema local o asistemas remotos, por medio del comando talk.

Por ejemplo, si el usuario jperez , conectado a Antares, quisiera entablar una charla conarodrig, conectada a Canopus, debería ejecutar el siguiente comando:

talk arodrig@canopus

arodrig recibirá un aviso en su pantalla y, si desea entablar la comunicación, deberá replicarcon el siguiente comando:

talk jperez@antares

tras lo cual la conexión quedará establecida. Ambos verán en sus pantallas lo que el otroescribe, hasta que alguno de ellos finalice la sesión con Control-C.

Correo electrónicoTalk permite comunicaciones en tiempo real; sin embargo, muchas veces es necesarioenviar un mensaje a un usuario que no se encuentra actualmente conectado. Para ello puedeutilizarse el correo electrónico.

El comando standard para enviar correo electrónico entre sistemas Unix es mail, cuyasintaxis es la siguiente:

mail usuario [@computadora]

Obsérvese que la especificación del nombre de la computadora es opcional; si se omite, seasumirá 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 delmensaje, y luego lee desde la entrada standard el texto del mensaje, hasta recibir la marca defin de archivo (Control-D):

jperez@antares:$ mail plopez@canopusSubject: Reunion semanalHola,Le comunico que la reunión semanal tendrá lugar elpróximo miércoles a las 15 el la Sala de Reuniones D.Por favor, concurra con el informe de avance.^Djperez@antares:$ _

Un problema frecuente al trabajar en una red Unix, es que los usuarios normalmente tienencuenta en mas de un host. Ello puede provocar que su correspondencia se vea diseminadaentre sus múltiples casillas de correo (una en cada host en los que se tiene cuenta). Parasolucionar esta situación, es posible redirigir el correo desde múltiples cuentas hacia aquellaque se usa mas frecuentemente.

Para redirigir el correo de una cuenta dada, el usuario deberá crear en el directorio deconexión correspondiente el archivo .forward, conteniendo la dirección de correoelectrónico hacia la cual desea que los mensajes sean redirigidos. Por ejemplo, si jpereztiene cuenta tanto en Antares como en Canopus, pero prefiere leer correo en la primera,

15

deberá crear un archivo .forward en su directorio de login de Canopus, conteniendo lasiguiente línea:

jperez@antares

16

Administración de una red TCP/IP

TCP/IP: una familia de protocolosTCP/IP es un conjunto de protocolos de comunicaciones desarrollado para permitir a unconjunto de computadoras cooperar y compartir recursos a través de una red decomunicaciones. De entre sus muchas características, hay dos que lo han transformado enuno de los protocolos de mayor difusión:

• Es un standard abierto, diseñado independientemente de plataformas de hardware ysoftware específicas. Así, TCP/IP es ideal para interconectar sistemas mas allá de lodiferentes que éstos sean.

• Es independiente de la tecnología física que se utilice para construir la infraestructura dela red. TCP/IP puede montarse sobre Ethernet, Token-Ring, enlaces seriales telefónicos(dial-up links), redes X.25, y virtualmente cualquier otro medio físico de transmisión dedatos.

Arquitectura de TCP/IP8

La familia TCP/IP está formada por múltiples protocolos de diferentes propósitos. Algunosde ellos, tales como IP, TCP y UDP constituyen el mecanismo básico de transmisión dedatos, y serán utilizados por todas las aplicaciones. Otros protocolos permiten realizar tareasmucho más específicas, tales como transferir archivos entre computadoras (FTP), obtenerpáginas o documentos de la Web (HTTP), o sincronizar la hora desde otro equipo (XNTP).

Cualquier aplicación real utilizará varios de esos protocolos. Un caso típico es el envío decorreo electrónico. En primer lugar, existe un protocolo para enviar y recibir correoelectrónico (denominado SMTP), que define una serie de comandos que una máquina envíaa la otra cuando requiere transferirle un mensaje. Esos comandos permiten especificar quienes el autor del mensaje, a quien va dirigido y cual es el texto a enviar. Sin embargo, eseprotocolo (como todos los otros protocolos de aplicación) asume que hay alguna maneraconfiable para comunicar datos entre ambas computadoras, limitándose simplemente adefinir a muy alto nivel los comandos necesarios para manejar la transmisión, pero no losdetalles acerca de como va a efectivizarse la misma. Dichos detalles son dejados en manosde 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 loscomandos trasmitidos lleguen al otro extremo de la comunicación, contabilizando qué hasido transmitido ya y retransmitiendo toda información que no haya llegado exitosamente adestino. Si la información a transmitir es demasiado larga, TCP la segmentará en variospaquetes que se transmitirán individualmente.

Obsérvese que esta funcionalidad se requiere para muchas aplicaciones; es por ello queconforma un protocolo independiente en vez de formar parte de la especificación deprotocolos como SMTP. Desde el punto de vista del programador, TCP es una libraría derutinas que las aplicaciones utilizan cuando necesitan comunicaciones confiables con otracomputadora a través de la red.

De manera similar, TCP utiliza los servicios de IP para efectivamente desplazar los paquetesalrededor de la red. IP constituye un protocolo de red, y es el encargado de determinar querutas deberán 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., NewBrunswick, N.J.) publicado en los newsgroups de Internet el 28 de Junio de 1987, y de otrasfuentes mencionadas en la Bibliografía.

17

Nuevamente, IP se presenta como una librería que utilizan protocolos de transporte comoTCP al momento de enviar la información.

Esta estrategia para construir protocolos en varios niveles se denomina diseño 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 inmediatamenteinferior. En general, la arquitectura de las aplicaciones basadas en TCP/IP presentan 4capas:

• Un protocolo de aplicación, para tareas específicas (por ejemplo, correo electrónico)

• Un protocolo de transporte, que provee servicios de extremo a extremo (como TCP oUDP)

• El protocolo de red IP, que provee el encaminamiento de los paquetes a su destino final

• Un protocolo de enlace físico, que provee acceso al medio físico de transmisión (porejemplo, Ethernet o X.25)

Transmitiendo los paquetesA fin de ejemplificar el proceso completo, supongamos que se desea transmitir un archivode 15000 bytes. El protocolo de aplicación especializado en transferencia de archivosproporciona al protocolo de transporte el contenido del archivo a transmitir. La mayoría delas redes no pueden manejar paquetes de 15000 bytes, por lo que el archivo será segmentadoen, digamos, 30 paquetes de 500 bytes cada uno, que entrega al protocolo de red para quesean enviados individualmente al otro extremo de la comunicación. Allí, los paquetes sereunirán para reensamblar el archivo original. Sin embargo, mientras los paquetes estén entránsito, la red no sabrá que existe algún tipo de relación entre ellos9. Es también posible queel paquete número 15 llegue antes que el 14, o que algunos paquetes se pierdan en el caminoy deban ser retransmitidos. Todas estas tareas (segmentación, retransmisión y reensamblaje)son llevadas a cabo por TCP (abreviatura de Transmission Control Protocol, o Protocolo deControl de Transmisión), mientras que el ruteo de paquetes individuales es responsabilidadde IP (abreviatura de Internet Protocol, o Protocolo de Inter-redes). A simple vista podríaparecer que TCP es quien hace todo el trabajo, sin embargo, el rutear un paquete desde elorigen 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 alusuario la capacidad para acceder a recursos ubicados en cualquiera de esas redes,independientemente de su dispersión geográfica11. Los paquetes frecuentemente atravesaránnumerosas redes para llegar a su destino, pero el ruteo requerido para ello deberá sertotalmente invisible para el usuario final. Todo lo que el usuario debe conocer es ladirección IP del punto de destino, un número que identifica unívocamente a cadacomputadora dentro de la inter-red.

Así, TCP entrega los paquetes a IP especificándole simplemente la dirección IP de destinohacia donde debe enviarlos. Queda en manos de IP determinar la mejor ruta para que laentrega se haga efectiva. Dicha ruta (continuando con el ejemplo anterior, y en el contexto

9 Más aún, la red ni siquiera sabe que los paquetes conforman un archivo.10 En la jerga TCP/IP se denomina gateways a dispositivos que están conectados a mas deuna red, y ofrecen capacidad para rutear paquetes entre esas redes. Es decir, se trata deruteadores (dispositivos de nivel OSI 3) y no estrictamente de gateways (dispositivos denivel OSI superiores, capaces de hacer transformaciones de protocolos, formatos,codificaciones, etc.)11 De hecho, el término internet (con i minúscula) proviene de internetwork y se refiere a unconjunto de redes interconectadas. No debe confundirse con Internet (con I mayúscula), quese refiere a la red de redes de alcance global.

18

de la estructura de la red de la UTN Facultad Córdoba), podría implicar que cada paquetetenga que atravesar varios segmentos de LAN Ethernet dentro de la UTN FC, un enlace demicroondas hasta el nodo de conexión a Internet, otro hasta algún telepuerto en BuenosAires desde donde se establece una conexión satelital hacia los EEUU, y así sucesivamentehasta llegar a la red de destino, en donde deberá ser ruteado internamente hasta lacomputadora de destino.

Finalmente, para transmitir cada paquete, IP utiliza el protocolo de enlace físico que conocelas particularidades para acceder al medio físico de transmisión (por ejemplo, una placa dered Ethernet).

Multiplexación: Puertos y SocketsEn los párrafos anteriores se ha descripto el proceso para transferir información a lo largo deuna conexión TCP/IP. Sin embargo, en un momento dado podrían existir, entre lascomputadoras de origen y destino, múltiples conexiones ocurriendo simultáneamente;pensemos, por ejemplo, en varios usuarios abriendo sesiones remotas o transfiriendosimultáneamente archivos o correo electrónico entre dos máquinas de la red.

Claramente, no es suficiente lograr que los paquetes lleguen al destino correcto; es necesarioademás poder discriminar a cual conexión pertenecen de las múltiples conexionessimultáneas que pueden existir en un momento dado.

Para identificar cada conexión, TCP asigna un número de puerto a cada una. Supongamosque tres personas están transfiriendo archivos entre dos computadoras. TCP asignaría unnúmero de puerto a cada transferencia, por ejemplo, 1000, 1001 y 1002. Todos los paquetesque se envíen como parte de una misma conexión tendrán asignado ese número como puertode origen. El número de puerto de origen permite también establecer una correspondenciadirecta entre una conexión de red y el programa de usuario que interviene en uno de losextremos de la conversación. En el otro extremo, habrá otro programa que recibe los datostransmitidos, que también deberá poder asociarse a dicha conexión. Esa asociación se hacepor medio del puerto de destino que TCP asigna a cada paquete que transmite.

Cuando un programa de usuario (conocido como proceso cliente) abre una conexión de redpor medio de TCP, se le asigna (mas o menos al azar) un número de puerto. Ese programaasume que en la otra computadora estará en ejecución otro programa (conocido comoproceso servidor o, en la jerga Unix, demonio de red) que espera recibir peticiones desde lared. Cuando ese programa fue iniciado, su capa TCP le asignó también un número depuerto. Obviamente, el número de puerto que se asigne a procesos servidores no puede seraleatorio, ya que sería imposible para los clientes saber que número especificar como puertode destino. Los procesos servidores se asocian, entonces, con números de puerto fijos(llamados "números bien conocidos" -- "well-known numbers"), mientras que los procesoscliente obtienen números de puertos aleatorios al iniciar las conexiones12.

Obsérvese que una conexión de red puede entonces identificarse unívocamente por mediode un conjunto de 4 números: las direcciones IP de ambos extremos y los números de puertode origen y destino. Para el caso de las tres transferencias de archivos que se ponían comoejemplo mas arriba, si las direcciones IP de las maquinas de origen y destino son172.16.10.150 y 172.16.8.123, y la transferencia se hace utilizando el protocolo FTP (quetiene asignado el número de puerto 21), cada conexión se puede identificar de la siguientemanera:

12 No es necesario que un proceso cliente obtenga un "numero bien conocido" ya que nadieestá tratando de encontrarlo; por el contrario, es necesario que los servidores tengan esosnúmeros a fin de que los clientes puedan conectarse a ellos.

19

Conexión 1Dirección IP: 172.16.10.150Puerto: 1000

Dirección IP: 172.16.8.123Puerto: 21





No pueden existir dos conexiones que compartan el mismo conjunto de números, pero essuficiente con que al menos uno sea diferente. En el ejemplo anterior, en donde tres usuariostransfieren archivos entre dos computadoras, dado que las computadoras involucradas encada transferencia son las mismas, las direcciones IP son iguales para cada conexión y todosrealizan transferencias vía FTP, por lo que el puerto de destino para las tres conexiones es el21. Lo único que difiere es el número de puerto de origen, que permite diferenciar a los tresusuarios.

Cada par formado por una dirección IP y un número de puerto se denomina socket(enchufe), por lo que una conexión TCP puede verse como un canal virtual a través de unared, "enchufada" a un socket en cada extremo. Por otra parte, el utilizar un único canal decomunicaciones para combinar múltiples conexiones de datos se denomina multiplexación;la información que arriba desde la red debe ser demultiplexada a fin de que cada módulo desoftware reciba los paquetes que le corresponden.

De hecho, hay varios niveles de multiplexación en TCP/IP. Por una parte, TCP la utilizapara mantener múltiples conexiones, tal como se describió previamente. Por otra parte, sinembargo, existen otros protocolos (como UDP e ICMP) que utilizan IP como un medio paradistribuir 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 constituyetambién otra forma de demultiplexación, y se realiza por medio de la asignación a cadapaquete, por parte del IP de origen, de un numero de protocolo. Dicho número tiene un rolsimilar al número de puerto, con la diferencia de que no identifica conexión sino elprotocolo de transporte que está administrando esa conexión.

El proceso de multiplexación y demultiplexación de TCP/IP se esquematiza en la siguientefigura:

Aplicaciones(Clientes)

Capa de RedCapa deTransporte

Aplicaciones(Servidores)

Capa de Red Capa deTransporte

TCP

UDP

ICMP

IP

IP

TCP

UDP

ICMP

En resumen...• Una red TCP/IP está formada por múltiples redes interconectadas por medio de

gateways. Dichos gateways pueden ser dispositivos físicos especializados (llamadosrouters) o bien computadoras con múltiples adaptadores de red (llamados multihomedhosts)

• Cada una de esas redes estará formada por máquinas individuales (los hosts de la red) opor subredes interconectadas. Cada máquina de la red recibirá un identificador numéricoúnico, llamado dirección IP.

20

• Las computadoras de la red ejecutarán aplicaciones que establecerán comunicacionesentre ellas por medio de protocolos como TCP ó UDP, los cuales utilizarán el protocoloIP para rutear paquetes de información entre el origen y el destino.

• Algunas computadoras de la red ofrecerán servicios a las demás, estableciéndoserelaciones de tipo cliente/servidor entre ellas. Los roles de cliente y servidor no sonexcluyentes; una misma maquina puede al mismo tiempo ser cliente y servidor. Mas aun,podría ocurrir que la relación cliente/servidor se dé entre dos procesos ejecutándose en lamisma máquina.

• Los procesos servidores reciben peticiones desde la red, usualmente "escuchando" enpuertos fijos de TCP (llamados números bien conocidos). Los clientes, por otra parte,utilizan puertos TCP asignados mas o menos al azar al iniciar la conexión.

• El par formado por una dirección IP y un número de puerto se denomina socket. Unaconexión puede identificarse unívocamente por el par de sockets correspondientes alnodo de origen y al de destino.

Direcciones IP

Clases de direcciones IPUna dirección IP es un número, usualmente expresado por una secuencia de cuatro enterosseparados por puntos:

a.b.c.d

en donde cada uno de esos números asumen valores entre 0 y 255.

De esos cuatro números, algunos se utilizan como dirección de red y los restantes comodirección de host. Todos los hosts que pertenezcan a la misma red deberán tener en comúnla dirección de red y diferir en la dirección de host. La cantidad números que se utilicenpara la dirección de red da lugar a tres clases de direcciones IP:

��

Clase A a b.c.d 16777214Clase B a.b c.d 65534Clase C a.b.c d 254

Este esquema de direccionamiento da lugar a la existencia de unas pocas redes clase A, cadauna con algo mas de 16 millones de computadoras. En el otro extremo, habrá un númeromuy grande de redes clase C, de pequeño tamaño.

Dada una dirección IP, puede determinarse a que clase pertenece examinando el valor de suprimer número:

��

Clase A 1 - 126Clase B 128 - 191Clase C 192 - 224

Así, por ejemplo, una dirección 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 números de la dirección de host puede variarentre 0 y 255, esos dos valores en particular no pueden asignarse como dirección a ninguna

21

máquina; el cero deberá utilizarse para formar la dirección IP de la red en su conjunto,mientras que el 255 es la dirección de broadcast13 (utilizada para enviar un mismo paquete atodos los hosts de la red). Siguiendo con el ejemplo anterior, para la red 172.16, la direcciónIP de la red es 172.16.0.0 y la de broadcast, 172.16.255.255.

Observar además que hay ciertos valores faltantes en la tabla expuesta mas arriba: 0, 127 yel 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 redvirtual (implementada internamente por el software de TCP/IP y no por dispositivos físicos)que conecta a un host directamente consigo mismo. En la red de loopback se asigna siempreuna única dirección IP: 172.0.0.1, que corresponde al host local. Por medio de esa direcciónde loopback, las aplicaciones pueden tratar al host local de la misma manera que a cualquierhost remoto (esto es, desde el punto de vista de las aplicaciones, el host local es otro hostmas de la red y no requiere tratamiento especial).

La dirección 0.0.0.0 es utilizada por el software de ruteo como la ruta por defecto, tal comose discutirá más adelante, mientras que las redes que comienzan con números entre 225 y255 están reservadas para usos especiales14.

Obtención de las direcciones IPComo ya se ha dicho, cada dispositivo conectado a una red TCP/IP debe tener asignado unadirección IP, que lo identifique unívocamente en toda la inter-red, es decir, debe ser únicono solo en la red a la que ese dispositivo pertenece, sino también en todas las demás redes alas cuales esté indirectamente conectado. Como consecuencia de lo anterior se desprendeque a la hora de configurar TCP/IP en una red, su administrador no puede seleccionararbitrariamente los números IP, especialmente si su red se conecta a otras redes TCP/IP.

Si la red en cuestión va a ser conectada a Internet, el juego de direcciones IP a utilizardeberá obtenerse de alguna autoridad centralizadora, usualmente el proveedor de acceso aInternet (conocido como ISP: Internet Service Provider)15. Si la red no tiene vínculos aInternet, se recomienda al administrador que utilice alguna de las direcciones reservadasespecialmente para redes desconectadas, o también llamadas direcciones no anunciables:

��

Clase A 10.0.0.0Clase B 172.16.0.0Clase C 192.168.0.0

SubredesYa sea que las direcciones IP a utilizar en la red se obtengan de una autoridad centralizadorao se utilice una dirección no anunciable, el paso previo es decidir que clase de direcciones seutilizará (A, B o C).

Por lo dicho hasta el momento, podría concluirse que el criterio para tomar esa decisióndebiera basarse en la cantidad de computadoras (presente y estimada a futuro) que se

13 Estrictamente, la dirección de red es aquella en que todos los bits de la porción de host dela dirección IP son cero, mientras que la dirección de broadcast es aquella en que todos losbits son uno.14 Actualmente se utilizan para redes multicast (redes que permiten direccionar grupos decomputadoras al mismo tiempo).15 La autoridad centralizadora mundial de direcciones IP es el Internet Network InformationCenter (o InterNIC). En principio, el InterNIC también recibe solicitudes para la asignaciónde números de red IP, aunque en los últimos años la tarea se ha delegado casi por completoa los proveedores locales. Para mas datos, consultar la dirección http://www.internic.net.

22

conectarán a la red. Obviamente ese es uno de los parámetros a tener en cuenta, pero no esel único.

A los fines del ruteo de los paquetes, la dirección IP debe reflejar además la estructurainterna de la red, es decir, sus subredes. Denominaremos subred a una porción de la red talque todas sus computadoras tienen posibilidad de comunicarse directamente entre sí, sin quesea necesario ningún dispositivo intermediario. Para el caso de redes locales, esto significausualmente que esas computadoras pertenecen al mismo segmento de Ethernet (esto es,están conectadas todas al mismo tramo de coaxil o al mismo concentrador).

Consideremos, por ejemplo, la siguiente red:

Orion

Aldebarán

Antares Rigel Altair

Canopus

Andromeda

Cygn i

La figura muestra que la red está constituida por cuatro segmentos de Ethernet; todas lasmáquinas conectadas al mismo segmento (por ejemplo, Antares y Rigel) pertenecen a lamisma subred. Por otra parte, algunas computadoras (como Andrómeda, Orión y Cygni)pertenecen a más de una subred (de hecho, conectan subredes entre sí, cumpliendofunciones de gateway).

Cuado esta red reciba su dirección de red, el administrador deberá mantener fijos ciertosnúmeros de la dirección IP (la parte de red) y tendrá libertad para variar los restantes (laparte de host) para numerar las computadoras individuales de la red. Sin embargo, dado queexisten subredes, deberá destinar parte de la dirección de host para numerar también lassubredes. Por ejemplo, al usar una dirección clase B, como la 172.16.0.0, es usual utilizar eltercer número para numerar la subred, y el último para numerar la máquina dentro de lasubred:

23

Orion

172.16.1.0 172.16.2.0

172.16.3.0

Aldebarán

Antares Rigel Altair

172.16.4.0

Canopus

And romeda

Cygni

Sin embargo, esta segmentación del espacio de direcciones disponible (ó subnetting) traecomo resultado que disminuya la cantidad de direcciones aprovechables para asignar acomputadoras. En el caso del ejemplo, si bien una dirección clase B (consideradalinealmente) provee de un espacio de mas de 65 mil direcciones, la subdivisión de eseespacio en 4 subredes nos deja con solo cuatro subredes de 254 máquinas cada una,haciendo un total de 1016 direcciones para toda la red. Obviamente, es posible conectarmayor número 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 opción;es posible utilizar solo los primeros bits del tercer byte para la dirección de subred yconformar la dirección de host con los bits restantes sumados al cuarto byte; más aún, esatécnica de segmentación es la única opción cuando se utilizan subredes de una direcciónclase C (donde 3 bytes deben permanecer fijos y solo el cuarto puede variarse). Sinembargo, independientemente de las "artimañas" que se utilicen, siempre habrá ciertapérdida en el espacio de direcciones aprovechables (lo cual puede ser especialmenteproblemático si se usa una dirección clase C).

En conclusión, para seleccionar la clase de dirección IP a utilizar, debe tenerse en cuenta nosolo la cantidad de máquinas de toda la red, sino también su estructura de subredes y ladimensión de cada una, recordando que será necesario contar con un esquema de subnettingque de cabida a la mayor de ellas.

A modo de aclaración, cabe agregar que el subnetting es solo una cuestion administrativaque solo es relevante desde el punto de la administración interna de las direcciones IP y,especialmente, el ruteo interno de paquetes; desde la perspectiva de otras redes, lo únicorelevante es la dirección de red de la red en su conjunto.

En resumen...• Las direcciones IP se forman combinando 4 valores numéricos enteros, y está

estructurada en una parte de red y otra de host.

• La dirección de red refleja también la estructura interna de subredes en que se encuentradividida la red.

24

• Al solicitar o seleccionar la dirección de red a utilizar, debe optarse por una direcciónclase A, B o C, teniendo en cuenta la cantidad de maquinas de la red y,fundamentalmente, la topología lógica de subredes.

• Si van a utilizarse direcciones no anunciables, es recomendable utilizar la clase C192.168.1.0 si la red es de un solo segmento, o bien la clase B 172.16.0.0 si existenmúltiples subredes, utilizando el tercer byte para numerar las subredes.

Asignación de direcciones IPUna vez asignada la dirección de red y definido el esquema para numerar las subredes, sepuede comenzar a asignar direcciones IP a las computadoras de cada subred, configurandocada interfaz de red con los siguientes parámetros: dirección IP, dirección de broadcast ymáscara de subred.

Continuando con el ejemplo iniciado mas arriba, la asignación de direcciones IP podría serla siguiente:

Orion

172.16.1.0 172.16.2.0

172.16.3.0

Aldebarán172.13.3.1

Antares172.16.1.1

Rigel172.16.1.2

Altair172.16.2.1

172.16.4.0

Canopus172.16.4.1

And romeda

172.16.1.254 172.16.2.254

172.16.3.254

172.16.3.253

172.16.4.254

Cygni172.16.4.253

172.16.1.253

Obsérvese que computadoras como Orión y Cygni que estén conectadas a más de unasubred, deberán recibir una dirección IP por cada una de las subredes a las que se encuentrenconectadas16. Computadoras como éstas, que interconectan subredes, jugarán un importantepapel como gateways de la red; el administrador de red está en libertad de asignarlescualquier número de IP dentro del rango válido para cada una de las subredes. Sin embargo,es recomendable adoptar algún tipo de convención al numerar los gateways; de esa forma,dado un número de red cualquiera, resultará más simple identificar la dirección del gatewayde la subred. En el ejemplo, la convención adoptada consiste en numerar los hosts connúmeros crecientes a partir de 1, y los gateways con números decrecientes a partir de 254.

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

25

La dirección de broadcast y la máscara de subred son iguales para todos los hosts dentro deuna subred dada.

La dirección de broadcast se forma poniendo en 1 todos los bits correspondientes a laporción de host de la dirección IP. En nuestro ejemplo, la porción de host es el último bytede la dirección; si todos los bits de ese byte se ponen a 1, el valor en decimal es 255, por loque las direcciones de broadcast serían las siguientes:

��

172.16.1.0 172.16.1.255172.16.2.0 172.16.2.255172.16.3.0 172.16.3.255172.16.4.0 172.16.4.255

La máscara de subred es un número que se utiliza para obtener la dirección de red partir deuna dirección IP. La separación se realiza por medio de una operación lógica AND entre ladirección IP y la máscara de subred, por lo que la máscara de subred deberá tener puestos a1 aquellos bits que corresponden a la dirección de red (incluyendo la parte de la subred) y a0 aquellos que formen la dirección de host. Para el caso en que se usen bytes completos paradirección de red y de host, la máscara de subred se formará poniendo un 255 en los bytesque correspondan a la parte de red, y un 0 en los bytes que correspondan a la parte de host.Por ejemplo:

��

A, sin subredes 10.0.0.0 255.0.0.0A, con subredes 10.x.0.0 255.255.0.0B, sin subredes 172.16.0.0 255.255.0.0B, con subredes 172.16.x.0 255.255.255.0C, sin subredes 192.168.1.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 máscara 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 sintaxisbásica es la siguiente:

ifconfig interfaz dirección_IP netmask máscara broadcast dirección_broadcast

en dónde,

interfaz Es el nombre asignado por el sistema operativo al adaptador dered.

dirección_IP Es la dirección IP que se le asigna a esta interfazmáscara Máscara de subred.broadcast Dirección de broadcast de la subred18.

Antes de poder utilizar ifconfig se deben conocer los nombres que el sistema operativoasigna a los adaptadores de red. El administrador puede obtener esa información de ladocumentación provista por el sistema; en el caso de Red Hat Linux (y de otros sistemas

17 Todos los comandos de configuración deben ejecutarse desde algún usuario consuficientes privilegios; usualmente, solo pueden ser ejecutados por root.18 El parámetro broadcast es opcional, dado que puede calcularse automáticamente dada ladirección IP y la máscara de subred.

26

Unix que implementen el pseudo-filesystem /proc ) pueden conocerse los adaptadores dered detectados por el sistema operativo durante el arranque consultando el archivo/proc/dev/net :

# cat /proc/net/devInter-| 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 deloopback) y eth0 (una placa de red Ethernet).

Así, para configurar la interfaz Ethernet de Antares, se debe ejecutar un comando como elsiguiente:

# ifconfig eth0 172.16.1.1 netmask 255.255.255.0 broadcast 172.16.1.255

Algunos sistemas configuran la dirección de loopback automáticamente, pero en aquellos endonde debe hacerse explícitamente, 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 automática cuando el sistemaoperativo se inicializa al prender el equipo, usualmente invocados desde algún script deinicialización. El administrador debe modificar directamente esos scripts, o algún archivo deconfiguración que los mismos utilizan, a fin configurar las interfaces de red. Red Hat Linuxinicializa las interfaces desde el script /etc/rc.d/init.d/network , obteniendo losparámetros de configuración 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 parámetros de configuración de la interfaz. Porejemplo:

�� DEVICE=eth0IPADDR=172.16.1.1NETMASK=255.255.255.0NETWORK=172.16.1.0BROADCAST=172.16.1.255ONBOOT=yesBOOTPROTO=none

DEVICE=loIPADDR=127.0.0.1NETMASK=255.0.0.0NETWORK=127.0.0.0BROADCAST=127.255.255.255ONBOOT=yesBOOTPROTO=none

Por otra parte, la mayoría de los Unix modernos proveen al administrador de una interfazgráfica para la configuración de las interfaces. En Red Hat Linux 5.0 se denomina netcfg ,y luce de la siguiente forma:

27

Ruteo de paquetes IPComo se describió previamente, la principal responsabilidad del protocolo IP es determinarqué camino deben tomar los paquetes para llegar al punto de destino. La tarea de determinarese camino es lo que se conoce como ruteo (o encaminamiento).

IP asume que la computadora está directamente conectada a una red local (por ejemplo, unaLAN Ethernet) y que puede enviar paquetes directamente a cualquier otra computadorasobre esa misma red; si la dirección de destino es en la red local, IP simplemente accede almedio físico de transmisión y envía el paquete. En la figura siguiente, Antares y Rigel estánsobre la misma red, por lo que pueden comunicarse directamente:

Orion

170.25.1.0 170.25.2.0

170.25.3.0


Antares170.25.1.1

Rigel170.25.1.2

Altair170.25.2.1

170.25.4.0

Canopus170.25.4.1

And romeda

170.25.1.254 170.25.2.254

170.25.3.254

170.25.3.253

170.25.4.254

Cygni170.25.4.253

170.25.1.253

Internet

Centaur i170.25.4.253

28

El problema aparece cuando la dirección de destino queda en otra red, en cuyo caso IPrecurrirá a un gateway para enviar indirectamente los paquetes. Como se recordará, sedenomina gateway19 a un dispositivo (ya sea otra computadora o un dispositivoespecíficamente diseñado a tal efecto) que está conectado a más de una red y tiene lacapacidad para redirigir (forward) paquetes entre esas redes. En la figura, Orión,Andrómeda, Cygni y Centauri son los gateways de la red.

Para determinar a qué gateway deberán enviarse los paquetes, IP extrae la dirección de reddel nodo de destino y consulta una tabla, denominada tabla de ruteo, en la cual se listan lasredes conocidas y los gateways que pueden utilizarse para alcanzarlas. Por ejemplo, la tablade ruteo de Aldebarán contiene la siguiente información:

��

170.25.1.0 170.25.3.254170.25.2.0 170.25.3.254170.25.3.0 *170.25.4.0 170.25.3.253

en donde el asterisco indica que no es necesario ningún gateway para llegar a la red encuestión dado que la máquina tiene conexión directa a la misma. Obsérvese en primer lugarque el ruteo hacia redes remotas se realiza en base a direcciones de red (esto es, la parte dehost de la dirección IP se ignora); además, la tabla de ruteo especifica tanto la red localcomo las remotas, y que para el caso de éstas últimas, indica la dirección IP de algunamáquina en la red local que puede ser utilizada para alcanzarla.

Supongamos, por ejemplo, que Altair requiere enviar datos a Canopus. El módulo IP deAltair determina que la computadora de destino no pertenece a su misma red; consultandosu tabla de ruteo, determina que puede llegarse a la red de Canopus a través de Orión, por loque le envía los paquetes a dicha computadora. El módulo IP residente en Orión, por suparte, sabe que para llegar a Canopus hay dos vías posibles: pasando por Andrómeda o porCygni. Aplicando algún criterio para evaluar ambas rutas y seleccionar la mejor de ellas,Orión envía cada paquete a, por ejemplo, Andrómeda. Esta última determina que ladirección de destino está en una de las redes a las que se encuentra directamente conectada,por lo que los envía diretamente a Canopus.

Es importante observar que la ruta que seguirán los paquetes desde el origen hasta su destinose va decidiendo a medida que los mismos viajan por la red. Cada nodo es responsable dedeterminar cual es el proximo "salto" en dirección al nodo final, en función del contenido desu tabla de ruteo. Este modelo de ruteo asume que si el nodo de destino no pertenece a la redlocal, deberá haber una entrada en la tabla de ruteo que especifique el gateway a utilizar. Enotras palabras, asume que todos los nodos están al tanto de la estructura de la red.

En consecuencia, cada vez que la estructura de la red cambia (por ejemplo, cuando se agregao elimina una subred), el administrador debería actualizar las tablas de ruteo en todos losnodos. Igualmente, si la red se interconectara a otra red, una nueva entrada debería agregarseen las tablas de ruteo de cada máquina.

Siguiendo con este razonamiento, a medida que la red crece y se interconecta a otras redeslas tablas de ruteo se hacen mas largas y complejas; inclusive sería posible que fueranvirtualmente 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 dinámico oadaptativo y las rutas por defecto.

19 La palabra inglesa gateway podría traducirse como "puerta de salida".

29

Ruteo estático vs. ruteo dinámicoLa tabla de ruteo de un host puede construirse de dos maneras. Una posibilidad consiste enque el administrador (por medio de scripts que se ejecutan al inicializar el sistema, o pormedio de comandos ejecutados interactivamente) introduzca manualmente las entradas de latabla. Esta técnica se denomina ruteo estático, debido a que la tabla de ruteo se construyecuando la computadora se prende y no varia con el tiempo.

La otra posibilidad es ejecutar en cada host un programa que actualice automática yperiódicamente la tabla de ruteo. Dichos programas se basan en el hecho de que unacomputadora siempre tiene acceso a otras computadoras conectadas a la red local; esto setraduce en que las tablas de ruteo contienen inicialmente al menos las direcciones de lasredes locales. Si tomamos por caso a Orión, su tabla de ruteo inicialmente contendría lasiguiente información:

��

170.25.1.0 *170.25.2.0 *170.25.3.0 *

De manera similar, la tabla de Andrómeda contendrá lo siguiente:

��

170.25.3.0 *170.25.4.0 *

Si Orión y Andrómeda intercambiaran sus tablas de ruteo, cada una podría "aprender" de laotra qué redes son alcanzables por esa vía. Así, Andrómeda podría concluir lo siguiente:

��

170.25.1.0 170.25.3.254170.25.2.0 170.25.3.254170.25.3.0 *170.25.4.0 *

Así, si todos los nodos de la red ejecutan un programa de estas características (llamadodemonio de ruteo) al cabo de cierto tiempo habrán "descubierto" por si mismas la estructurade la red y construido sus tablas automáticamente. Mas aún, si se produjera algún cambioen la estructura de la red, bastaría con que alguna de las computadoras lo detectara para queen pocos segundos esa nueva información se propagara por toda la red.

Esta estrategia se denomina ruteo dinámico o adaptativo y tiene la ventaja de que, al serautomático, permite eliminar las tareas administrativas relacionadas con el mantenimientode las tablas de ruteo.

En ambientes Unix se dispone de dos programas que implementan este tipo de protocolos deruteo: routed y gated.

Rutas por defectoEl uso de ruteo dinámico elimina la necesidad de modificar las tablas de ruteo cuando la redcambia. Sin embargo, no resuelve el problema de las abultadas tablas de ruteo resultantes deconectar una red a muchas otras.

30

Consideremos la tabla de ruteo que construiría una máquina como Altair:

��

170.25.1.0 170.25.2.254170.25.2.0 *170.25.3.0 170.25.2.254170.25.4.0 170.25.2.254

Como puede verse, Altair ha aprendido las rutas a todas las subredes de la red, pero el únicogateway que puede utilizar es Orión. De manera similar, si fuera posible que todas lascomputadoras de la red del ejemplo aprendieran las direcciones de todas las redes queforman la Internet, Altair eventualmente construiría una tabla de ruteo con miles deentradas, en donde todas tendrían a Orión como gateway. En ambos casos, el resultado esuna tabla de ruteo con información altamente redundante.

Para eliminar este problema, es que puede instalarse en la tabla de ruteo una ruta por defecto(conocida también como default gateway). IP utiliza la ruta por defecto (que se indica con elnúmero 0.0.0.0) cada vez que no se encuentra en la tabla de ruteo una ruta hacia una redespecífica. Aplicando éste criterio, la tabla de Altair se reduciría a lo siguiente:

��

170.25.2.0 *0.0.0.0 170.25.2.254

que sencillamente indica que si la dirección de destino está en la red local, es accesibledirectamente, y que en caso contrario (independientemente de cual sea el destino), lospaquetes deberán enviarse a 170.25.2.254 (es decir, Orión).

Configurando los nodos

Caso 1: Redes sin segmentación internaEn este caso, se tiene una red pequeña, en la que todas las computadoras están ubicadassobre el mismo segmento físico y no hay ninguna conexión a otras redes TCP/IP:

205.12.9.0

Antares205.12.9.1

Rigel205.12.9.2

Altair205.12.9.3

Como se puede ver, todas las computadoras tienen acceso directo a todas las demás. La tablade ruteo será mínima; solo contendrá una referencia a la red local y a la red de loopbackinstaladas automáticamente por ifconfig al inicializar las interfaces correspondientes.

Puede utilizarse el comando route -n para examinar el contenido de la tabla de ruteo (-nindica a route que utilice formato numérico):

# route -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref UseIface127.0.0.0 0.0.0.0 255.0.0.0 U 0 1 298 lo205.12.9.0 0.0.0.0 255.255.255.0 U 0 40 1252 eth0

31

En el listado anterior, la primera columna indica dirección de red (que debe interpretarse deacuerdo a la mascara de la tercera columna) y la segunda columna indica el gateway autilizar (0.0.0.0 se utiliza para indicar que hay conexión directa a la red en cuestión. Routetambién muestra información adicional sobre cada ruta:

Flag: Se compone de una serie de caracteres que indican las características de laruta. Por ejemplo, U indica que la ruta está operacional (por Up), G que es unaruta a un gateway, H que es una ruta a un host, etc.

Metric: Valor utilizado para cuantificar la ruta. IP utiliza este valor para seleccionar lamejor de dos o más rutas alternativas a la misma red.

Ref: Cantidad de veces que ésta ruta fue utilizada para establecer una conexión.

Use: Cantidad de paquetes trasmitidos a través de esa ruta.

Si esta misma red se conectara a otras redes (por ejemplo, la Internet), sería necesarioindicar en cada uno de los hosts de la red una ruta estática por defecto hacia el gateway a lasotras redes:

205.12.9.0

Antares205.12.9.1

Rigel205.12.9.2

Altair205.12.9.3

Or ión

Internet

205.12.9.254

150.104.3.21

Las rutas por defecto puede instalarse en las estaciones por medio del siguiente comandoroute:

# route add -net default 205.12.9.254

Si ahora se reexaminara la tabla de ruteo en dichas estaciones, se obtendría el siguienteresultado:

# route -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref UseIface127.0.0.0 0.0.0.0 255.0.0.0 U 0 1 298 lo205.12.9.0 0.0.0.0 255.255.255.0 U 0 40 1252 eth00.0.0.0 205.12.9.254 0.0.0.0 UG 0 0 0 eth0

Obsérvese que Orión interconecta nuestra red con el exterior, por lo que tiene una direcciónen la red local (170.25.9.254) y otra en la red del proveedor de acceso a la otra red (en estecaso, la Internet). A fin de lograr la conectividad, deberá instalarse en Orión una ruta por

32

defecto hacia el exterior, utilizando como gateway una dirección que el proveedorespecifique, por ejemplo:

# route add -net default 150.104.3.254

Por otra parte, el proveedor deberá instalar en sus ruteadores alguna ruta que indique quenuestra red es alcanzable a través de la dirección 150.104.3.21, cerrando así el ciclo deentrada y salida a nuestra red.

Caso 2: Redes segmentadasEn este caso, la red está compuesta por varios segmentos unidos entre sí por gateways. Unaprimera opción sería ejecutar un demonio de ruteo dinámico en todas las computadoras, ydejar que las tablas se actualicen automáticamente. Sin embargo si tal programa no estuvieradisponible (o por alguna razón se decide no emplearlo) bastaría con instalar en lascomputadoras de cada segmento una ruta estática por defecto hacia el gateway Orión, talcomo se muestra en la siguiente figura:

Orion

170.25.1.0 170.25.2.0


Antares170.25.1.1

Rigel170.25.1.2

Altair170.25.2.1

170.25.1.254 170.25.2.254

Para obtener esta configuración, en Antares y Rigel habría que ejecutar el siguientecomando:

# route add -net default gw 170.25.1.254

mientras que en Altair y Aldebarán el comando sería:


No es necesario instalar manualmente ninguna ruta en Orión, debido a que todas lasnecesarias serán instaladas automáticamente por ifconfig.

Sería diferente si la red tuviera más subredes:

33

Orion

170.25.1.0 170.25.2.0

170.25.3.0


Antares170.25.1.1

Rigel170.25.1.2

Altair170.25.2.1

170.25.4.0

Canopus170.25.4.1

And romeda

170.25.1.254 170.25.2.254

170.25.3.254

170.25.3.253

170.25.4.254

En éste caso, sería necesario informar a Orión acerca de la existencia de la red 170.25.4.0, ya Andrómeda acerca de las redes 170.25.1.0 y 170.25.2.0. Una vez mas, puede utilizarse elcomando route para instalar las rutas, utilizando la siguiente sintaxis:

# route add -net red netmask máscara gw gateway

Por ejemplo, en Andrómeda habría 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 quedaría conformada de la siguiente manera:

# route -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref UseIface127.0.0.0 0.0.0.0 255.0.0.0 U 0 1 298 lo170.25.3.0 0.0.0.0 255.255.255.0 U 0 105 11252 eth0170.25.4.0 0.0.0.0 255.255.255.0 U 0 55 1976 eth1170.25.1.0 170.25.3.254 255.255.255.0 UG 0 20 841 eth0170.25.2.0 170.25.3.254 255.255.255.0 UG 0 33 976 eth0

Finalmente, si la red tuviera conexión a redes externas, sería necesario instalar en losgateways una ruta por defecto que conduzca hacia el gateway al exterior:

34

Orion

170.25.1.0 170.25.2.0

170.25.3.0


Antares170.25.1.1

Rigel170.25.1.2

Altair170.25.2.1

170.25.4.0

Canopus170.25.4.1

And romeda

170.25.1.254 170.25.2.254

170.25.3.254

170.25.3.253

170.25.4.254

Internet

Centaur i170.25.4.253

En Orión:


En Andrómeda:


Opciones al comando routeEn todos los ejemplos anteriores se utilizó el comando route para instalar rutasmanualmente en la tabla de ruteo. Sin embargo, al igual que ocurre con ifconfig, usualmenteel administrador no instala las rutas introduciendo comandos manualmente (o modificandoscripts de inicialización del sistema), sino que se limita a modificar archivos deconfiguración o utilizar alguna herramienta gráfica.

En el caso de Red Hat Linux, la utilidad netcfg que se mencionó con anterioridad puedeutilizarse para configurar la ruta por defecto e instalar rutas estáticas. También puedenrealizarse estas tareas modificando manualmente archivos de configuración network ystatic-routes respectivamente, ubicados ambos bajo /etc/sysconfig .

35

Resolución de NombresUna vez que se han configurado las direcciones IP y el ruteo, una red TCP/IP se encuentratotalmente operativa. Sin embargo, a los fines prácticos hay que cumplimentar un pasoadicional: la configuración de la resolución de nombres.

Un servicio de resolución de nombres permite a las computadoras de una red transformarnombres en direcciones numéricas y viceversa.

Sabemos que, a fin de acceder a servicios a través de la red, es necesario hacer referencia aaquellas computadoras que los ofrecen, las cuales se conectan a una o más redes por mediode interfaces. Como se ha visto, cada interfaz de red conectada a una red TCP/IP seidentifica con una dirección IP numérica, por lo que para hacer referencia a la misma, esnecesario conocer dicho número.

Si bien los protocolos de comunicaciones y las aplicaciones informáticas se sienten a gustoutilizando números, no ocurre lo mismo con las personas, quienes prefieren utilizar nombrespara designar a las computadoras de la red, ya que son más fáciles de recordar. Seguramentees más probable que el nombre del sitio web de la UTN Facultad Córdoba(www.frc.utn.edu.ar) esté mas presente en la memoria de sus usuarios que su dirección IP(170.210.248.211).

Otra razón para utilizar nombres en lugar de números es el aislar a los usuarios de posiblescambios en la distribución de las direcciones IP. Por ejemplo, si el programa quehabitualmente se utiliza para leer correo electrónico está configurado para obtener mensajesa partir de la dirección IP 172.16.4.205, el administrador de red necesitará notificar a todoslos usuarios que deberán reconfigurarlo si el servidor de correo se muda a otro equipo, o sila dirección IP del equipo en el que reside se cambia por alguna razón. Por medio de lautilización del servicio de resolución de nombres, el programa de correo electrónico puedeconfigurarse para obtener los mensajes de una máquina llamada, por caso, mailhost,independientemente de dónde se ubique físicamente.

La tabla de HostsPara implementar un servicio de nombres es necesario confeccionar una lista en la que serelacionen nombres con direcciones IP; cuando un programa necesita resolver un nombre(esto es, dado un nombre encontrar la dirección IP), debe consultar dicha lista.

En un principio, la resolución de nombres se implementó por medio de un archivo ubicadoen cada máquina de la red que contenía dicha lista. En el caso de Unix, ese archivo es el/etc/hosts y tiene el siguiente formato:

#

# Tabla de resolución 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 líneas que comienzan con # se consideran comentarios y son ignoradas, mientras que lasdemás asocian un número de IP con el nombre asociado a la computadora.

36

Así, cuando el usuario ejecuta un comando como

$ telnet aldebaran

el programa telnet antes de iniciar la conexión transforma el nombre aldebaran en ladirección IP 170.25.3.1, según se consigna en la tabla de hosts.

Obsérvese además que los gateways de la red figuran varias veces en el listado, según lacantidad de interfaces que posean. También es posible asignar mas de un nombre a unamisma 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 resolución denombres. Sin embargo, a medida que la red crece y debido a que la información estáduplicada en cada host de la red, su mantenimiento se hace cada vez más trabajoso. Lasituación se complica si varias redes TCP/IP se interconectan, en cuyo caso, a las tareas desincronización de tablas entre diferentes hosts hay que sumar el control de nombresduplicados para máquinas diferentes.

Para solucionar estos problemas de escalabilidad, el mecanismo de resolución de nombresevolucionó hacia uno mucho más sofisticado: el Servicio de Nombres de Dominio, o DNS(Domain Name Service).

Sin embargo, aún cuando se utilice DNS, es necesario contar con una tabla de hosts mínimaa ser utilizada por el sistema operativo durante el arranque, con información suficiente pararesolver el nombre de la máquina y el nombre "localhost" asociado con la dirección deloopback. Por ejemplo, la tabla de hosts de Canopus debiera contener mínimamente losiguiente:

127.0.0.1 localhost

170.25.4.1 canoups

Servicio de Nombres de Dominio (DNS)La tabla de hosts fue reemplazada por un esquema mucho más potente y flexible, adecuadopara 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 unnombre se contacta vía TCP/IP20 con otro proceso, llamado servidor de nombres, quienrealiza el proceso de resolución y retorna una respuesta. Como en todo sistemacliente/servidor, ambos procesos pueden ejecutarse sobre la misma maquina o en máquinascompletamente diferentes.

Un servidor DNS mantiene la lista de direcciones y nombres de una o más agrupaciones decomputadoras, llamadas dominios. Dichas agrupaciones se forman de manera conceptual(por área geográfica, motivos organizacionales, por proyectos, etc.) y no tienennecesariamente que tener un correlato con direcciones de red o estructura de subredes.

20 Estrictamente, la comunicación entre el cliente y el server DNS se realiza medianteconexiones UDP.

37

Además de contener computadoras, un dominio puede particionarse en otros subdominios.Este particionamiento se realiza a los fines de permitir la delegación de tareasadministrativas. El administrador de un subdominio puede cambiar datos de lascomputadoras del mismo e incluso crear nuevos subdominios que delegar a terceros.

Esto da como resultado una estructura jerárquica, similar a un árbol invertido, en donde parallegar a un dominio en particular, se debe seguir una trayectoria de dominios encadenados apartir de un dominio raíz.

Inmediatamente por debajo del dominio raíz, se encuentran los dominios de alto nivel.Inicialmente, los diseñadores de ARPANET (la red predecesora de Internet) concibieron losdominios de alto nivel como dominios organizacionales:

• com : organizaciones comerciales;• edu : organizaciones educativas;• gov: organizaciones gubernamentales;• mil: organizaciones militares;• net: organizaciones administradoras de redes globales;• org: organizaciones sin fines de lucro;• int: organizaciones internacionales (como la OTAN, la ONU, etc.).

Mas tarde, en vistas a la expansión de la Internet por todo el mundo, se crearon nuevosdominios de alto nivel, uno por cada país: los dominios regionales. Los dominios regionalesse designan según un estándar internacional llamado ISO 3166, que asigna a cada país uncódigo de dos letras21. Por ejemplo:

• ar: Argentina• us: Estados Unidos• es: España• mx: México• uk: Gran Bretaña22

La administración del DNS a escala global recae en un organismo llamado Internet NetworkInformation Center (o InterNIC), al cual debe recurrirse para solicitar la creación de unsubdominio de los dominios de alto nivel. El InterNIC, por su parte, delega laadministración de los dominios regionales a las autoridades del país correspondiente; en elcaso de la Argentina, es responsabilidad de la Cancillería.

Dichas organizaciones son las responsables de decidir la forma en que particionarán eldominio regional. Usualmente, tal como ocurre en Argentina, deciden hacer un paralelo delos dominios organizacionales de alto nivel. Así, por ejemplo, existen los dominios com.ar,org.ar, gov.ar, edu.ar, etc. Sin embargo, algunos países deciden seguir algún otro tipo deesquema; por ejemplo, algunos de los subdominios de Gran Bretaña son co.uk (por"corporations"), ac.uk (por "academic community"), etc.

Cuando una organización 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 loadministre la delegación de un subdominio. Si dicho organismo considera pertinente la

21 A pesar de esto, y por tradición histórica, las organizaciones norteamericanas no seinscriben en el dominio regional de los EE.UU sino directamente en los dominiosorganizacionales de alto nivel.

22 En "DNS and BIND" de Albitz & Cricket se hace la siguiente aclaración: "La excepciónes Gran Bretaña. De acuerdo a ISO 3166 el dominio de la Gran Bretaña debiera ser gb,pero en su lugar, Gran Bretaña e Irlanda del Norte utilizan uk (por United Kingdom).También conducen los automóviles del lado equivocado de la calle"

38

solicitud, creará el dominio solicitado y a partir de ese momento la organización solicitanteserá la responsable de administrarlo, pudiendo agregar máquinas al dominio o inclusoparticionarlo en mas subdominios.

Por ejemplo, la Universidad Tecnológica Nacional gestionó en Cancillería el dominioutn.edu.ar al cual pertenecen las computadoras del Rectorado (en Buenos Aires); luegodecidió crear un subdominio para cada una de sus Facultades Regionales. Así, por ejemplo,existen los dominios frc.utn.edu.ar (Facultad Córdoba), frba.frc.utn.edu.ar (FacultadBuenos Aires), frlp.frc.utn.edu.ar (Facultad La Plata), etc.

Dentro de un dominio, sus administradores están en libertad de crear nombres para suscomputadoras. El nombre que se asigne a cada máquina se combinará con el nombre deldominio 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 máquinas con el mismo nombre, siempre seráposible distinguirlas por medio del FQDN23.

En síntesis, la estructura del DNS puede reflejarse de la siguiente manera (con el dominioraíz representado por un punto):

.

com edu org gov mil net ar

com edu org gov mil net

utn

frba frc frlp

Resolución de nombres basada en DNSSupongamos que un programa ejecutándose en una máquina en el dominio frc.utn.edu.arrequiere iniciar una conexión con otra computadora. Dado que el primer paso es obtener sudirección IP, dicha aplicación deberá realizar una petición de resolución a algún server denombres.

Como se mencionó anteriormente, un server de nombres posee las tablas de direcciones ynombres referentes a uno o más dominios. Si la petición de resolución hace referencia a unamáquina perteneciente a alguno de los dominios administrados localmente (en cuyo caso sedice que el server tiene autoridad sobre ese dominio), el server consulta la tabla respectiva ycontesta la petición. En caso contrario deberá realizar una serie de consultas siguiendo lajerarquía de dominios a partir del dominio raíz, hasta encontrar el server que tiene autoridadsobre el dominio al cual pertenece el nombre buscado.

Supongamos, por ejemplo, que se intenta resolver el nombre andromeda.galaxia.org.ar. Elserver 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 desu FQDN.

39

dominio raíz, los cuales le contestan con la dirección IP del server DNS del dominio ar. Elserver local realiza una nueva consulta, esta vez al server de ar, quien responde con ladirección del server que tiene autoridad sobre org.ar. Tras una nueva consulta, el serverlocal recibe la dirección del servidor de nombres de galaxia.org.ar, que al ser consultadoretorna la dirección IP de la computadora andrómeda.

Esta estrategia de consulta se denomina iterativa, debido a que el server de nombres localrecibe como respuesta la dirección de otro server de nombres, por lo que debe repetir laoperación (esto es, iterar) hasta que reciba la dirección IP del nombre a resolver. Existe otraposible configuración, llamada recursiva, según la cual un server de nombres puede serconfigurado de tal forma que retorne siempre la dirección final buscada; si, por ejemplo, elserver de nombres de ar fuera recursivo, en vez de retornar la dirección de org.ar para queluego el server que inició la consulta continúe iterando, realizaría la iteración él mismo.

Cualquiera sea la estrategia utilizada, puede observarse que una única resolución implicamúltiples consultas a través de la Internet. Para minimizar demoras en las comunicaciones,el diseño del DNS incluye la posibilidad de que los servidores de nombres guardentemporalmente las respuestas a las consultas que se han recibido, es decir, mantienen uncache de consultas previas que pueden ser reutilizadas si la consulta se repite.

El Dominio de ReversaUn server DNS permite también realizar operaciones de resolución inversa, esto es, obtenerun nombre a partir de una dirección IP. Para ello, existe un dominio especial llamadoin-addr.arpa y conocido como dominio de reversa, cuyos subdominios se forman a partir delos valores numéricos de las direcciones IP, tomados en orden inverso.

Por ejemplo, la dirección IP 170.25.3.1, pertenece al dominio de reversa1.3.25.170.in-addr.arpa.

Cuando a una red se le asigna un número de red, usualmente también se le delega laadministración de su correspondiente dominio de reversa. Por ejemplo, el dominio dereversa correspondiente a 170.25 sería 25.170.in-addr.arpa, quedando en manos de suadministrador la decisión de crear subdominios para cada una de sus subredes (por ejemplo,1.25.170.in-addr.arpa, 2.25.170.in-addr.arpa, etc.)

Configuración de un servidor DNS usando BINDLa implementación estándar de DNS para Unix es BIND (Berkely Internet Name Domain) yconsiste en un módulo cliente llamado "resolver" que se integra a las aplicaciones, y undemonio llamado named, que debe ejecutarse en aquella computadora que se designe comoserver de nombres del dominio.

Si bien el tratamiento completo de la configuración de éste paquete de software escapa alalcance de éste trabajo, se discutirán a continuación los aspectos básicos de suconfiguración.

Tipos de Servidores de NombresBIND soporta tres modos de configuración para el servidor de nombres:

Primario: fuente autorizada de información sobre un determinado dominio, lo cualsignifica que un servidor de nombres primario es quien tiene la informacióncompleta y más actualizada sobre los nombres de computadoras pertenecientesal dominio. Dicha información se obtiene a partir de archivos de datosconstruidos por el administrador de la red (llamados archivos de zona).

Secundario: mantiene una copia de la información sobre un determinado dominio,transfiriéndola periódicamente desde un server de nombres primario(operación llamada transferencia de zona). También se considera fuenteautorizada de información sobre ese dominio.

40

Cache: responde consultas haciendo peticiones a otros servidores de nombres, y lasalmacena localmente para agilizar futuras consultas por la misma información.Sin embargo, no mantiene la base de datos de ningún dominio (esto es, notiene autoridad sobre ningún dominio en particular).

Archivos de configuraciónnamed requiere un archivo de configuración llamado /etc/named.boot y variosarchivos de zona, según los dominios que se vayan a administrar.

El archivo /etc/named.boot define parámetros generales para la configuración delservidor, en especial el modo de operación (primario, secundario o cache) y la ubicación ynombres de los archivos de zona.

El archivo /etc/named.boot típico para configurar el server de nombres primario deuna red como la del dominio galaxia.org.ar contendrá la siguiente información:

;

; 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 línea del archivo /etc/named.boot especifica una directiva de configuración,excepto aquellas que comiencen con punto y coma (; ), que se consideran comentarios y sonignoradas.

La directiva directory indica el directorio donde named podrá encontrar los archivos dedatos que se mencionen a continuación.

La directiva primary configura el server de nombres para ser servidor primario deldominio que se indica a continuación, obteniendo la lista de nombres y direcciones desde elarchivo que figura como último parámetro. En ejemplo anterior, puede verse que el serverde nombres será server primario de los dominios galaxia.org.ar (el dominio asignado a laorganización), 25.170.in-addr.arpa (el dominio de reversa correspondiente a la direcciónasignada 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 contenidoinicial del cache de direcciones y nombres. Es en este archivo donde se indican lasdirecciones IP de los servidores de nombres del dominio raíz.

La configuración de un server secundario resulta similar:

;

; Server de nombres secundario de galaxia.org.ar

;

directory /etc

secondary galaxia.org.ar 170.25.4.254 named.hosts

secondary 25.170.in-addr.arpa 170.25.4.254 named.rev

primary 0.0.127.in-addr.arpa named.local

cache . named.cache

En lugar de la directiva primary se utiliza la directiva secondary , cuyos argumentosson el nombre del dominio, la dirección IP del server primario desde donde transferir losarchivos de datos y el nombre del archivo local donde almacenarlos. Dichos archivos serán

41

creados automáticamente la primera vez que el server se inicie, y serán actualizadosperiódicamente.

Archivos de ZonaAl definir un server primario, utilizando la directiva primary , el administrador indica elnombre del archivo de zona desde donde obtener los datos.

La diferencia entre zona y dominio es sutil: una zona contiene la información sobre undominio y todos aquellos subdominios que no han sido delegados a otro server. La particiónen subdominios se realiza fundamentalmente para agrupar conceptualmente computadorasrelacionadas, idealmente con el objetivo de delegar en sus usuarios la administración de lainformación sobre las mismas. Sin embargo, puede ocurrir que los mismos no estén encondiciones de hacerse cargo de esas tareas (por falta de equipamiento, capacitación, etc.),en cuyo caso el administrador de la red puede optar por crear los subdominios, pero nodelegarlos. Obviamente, en un dominio cuyos subdominios han sido todos delegados, lazona y el dominio coinciden.

Un archivo de zona está compuesto por registros, cuya sintaxis es la siguiente (los camposentre 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 alvalor del campo nombre del registro anterior.

ttl: es un valor numérico (en segundos) que indica cuanto tiempo ese registro debeconservarse en el cache antes de ser refrescado (es la abreviatura de Time ToLive). Si se omite, se considera igual al ttl por defecto de la zona (ver registroSOA, mas adelante).

tipo: identifica el tipo de registro:

Tipo FunciónSOA Start Of Authority. Indica el inicio de la zona, y define

parámetros generales para la mismaNS Name Server. Define el nombre del server de nombres del

dominio.A Address. Define la dirección IP asociada a un nombre.

PTR Pointer. Define el nombre asociado a una dirección IP.MX Mailer Exchange. Define el nombre del host que recibe el

correo electrónico para un determinado nombre del dominio.CNAME Canonical Name. Define un alias para un host.

datos: información específica, dependiente del tipo de registro.

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

42

;; server de nombres primario de galaxia.org.ar;@ IN SOA cygni.galaxia.org.ar. root.cigni.galaxia.org.ar.(

1998062202 ; nro de serie43200 ; refresco cada 12 horas3600 ; reintentar despues de 1 hora3600000 ; expirar despues de 1000 horas360000 ; ttl por defecto en 100 horas)

galaxia.org.ar. IN NS cygni.galaxia.ar.galaxia.org.ar. IN MX 10 andromeda.galaxia.ar.

localhost IN A 127.0.0.1

antares IN A 170.25.1.1rigel IN A 170.25.1.2cygni IN A 170.25.1.253orion IN A 170.25.1.254altair IN A 170.25.2.1orion IN A 170.25.2.254aldebaran IN A 170.25.3.1orion IN A 170.25.3.254andromeda IN A 170.25.3.253canopus IN A 170.25.4.1cygni IN A 170.25.4.252centauri IN A 170.25.4.253andromeda IN A 170.25.4.254

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

Como puede verse, el archivo comienza con un registro SOA que declara el inicio de unazona. El símbolo @ en el registro SOA hace referencia al dominio actual, esto es, el que seindica en la directiva primary del archivo named.boot . El primer nombre que figuracontinuación es el nombre de la computadora que contiene este archivo, seguido de ladirección de correo del administrador del DNS (obsérvese que no contiene un @ sino unpunto luego del nombre del usuario). Seguidamente aparecen entre paréntesis valores deconfiguración generales de la zona, como el ttl por defecto y el período de refresco de losdatos (esto es, cada cuanto named deberá releer el archivo de zona para verificar si hahabido cambios en el mismo).

Particularmente importante es el número de serie del archivo de zona (primer parámetronumérico del registro SOA). Este número deberá ser incrementado por el administrador cadavez que introduzca un cambio en los datos de la zona. Por medio de ese valor, un servidorsecundario sabrá que debe pedir una transferencia de zona a fin de actualizar su copia localdel archivo. Es práctica común escribir ese número como una codificación de la fecha enque se realizo el cambio (en formato Año/Mes/Día), seguida de un numero de versión, por sise realiza más de un cambio en la misma fecha.

Obsérvese que ninguno de los registros posteriores especifica un valor de ttl; todos ellostoman el valor por defecto especificado en el registro SOA. Además los registros NS y MXno especifican el campo nombre.

A continuación del registro SOA aparece el registro NS, que define que el nombre delservidor de nombres de galaxia.org.ar es la computadora llamada cygni. Lo sigue unregistro MX, que indica que el correo electrónico destinado a éste domino deberá ser

43

enviado a la computadora andrómeda (obsérvese que el nombre que se especifica debeterminar con punto; si no fuera así, se asumiría que ese nombre debe completarse con elnombre del dominio actual).

Finalmente, se listan los registros A, que establecen la relación entre un nombre y unadirección 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 reversaEl archivo named.boot indicaba que se administrarían dos dominios de reversa: uno paralas direcciones correspondientes a la dirección de red y otro para la red de loopback.

Los archivos de zona de un dominio de reversa contienen registros de tipo PTR. En dichosregistros se utilizan los bytes de la parte de host de la dirección IP para el campo nombre,tomándolos en orden inverso. El dato asociado a cada registro es el nombre correspondientea esa dirección IP.

El archivo de zona para la red de loopback es virtualmente idéntico en todas lasconfiguraciones:

@ IN SOA cygni.galaxia.org.ar. root.cigni.galaxia.org.ar.(


galaxia.org.ar. IN NS cygni.galaxia.ar.

1 IN PTR localhost

El contenido del archivo named.rev es similar:

@ IN SOA cygni.galaxia.org.ar. root.cigni.galaxia.org.ar.(


galaxia.org.ar. IN NS cygni.galaxia.ar.

1.1 IN PTR antares2.1 IN PTR rigel253.1 IN PTR cygni254.1 IN PTR orion1.2 IN PTR altair254.2 IN PTR orion1.3 IN PTR aldebaran254.3 IN PTR orion253.3 IN PTR andromeda1.4 IN PTR canopus252.4 IN PTR cygni253.4 IN PTR centauri254.4 IN PTR andromeda

44

Archivo de inicialización del cacheComo se mencionó anteriormente, el archivo named.cache contendrá las direcciones IPde los servidores de nombres del dominio raíz, y se utilizará como el contenido inicial delcache.

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.4B.ROOT-SERVERS.NET. 99999999 IN A 128.9.0.107C.ROOT-SERVERS.NET. 99999999 IN A 192.33.4.12D.ROOT-SERVERS.NET. 99999999 IN A 128.8.10.90E.ROOT-SERVERS.NET. 99999999 IN A 192.203.230.10F.ROOT-SERVERS.NET. 99999999 IN A 192.5.5.241G.ROOT-SERVERS.NET. 99999999 IN A 192.112.36.4H.ROOT-SERVERS.NET. 99999999 IN A 128.63.2.53I.ROOT-SERVERS.NET. 99999999 IN A 192.36.148.17

Como se puede apreciar, el archivo contiene registros NS que definen los nombres de losservidores de nombre del dominio raíz, y registros A con sus direcciones IP. Una listacompleta y actualizada de estos servidores puede obtenerse por FTP anónimo, desdeftp://nic.ddn.mil/netinfo/root-servers.txt.

Configuración del "resolver"Como ya se dijo, las aplicaciones que utilizan los servicios de un server DNS lo hacen pormedio de un módulo del sistema operativo llamado resolver.

En Unix, el resolver se configura por medio del archivo /etc/resolv.conf , cuyocontenido mínimo consta de las siguientes directivas:

domain galaxia.org.arnameserver 170.25.1.253

La directiva domain indica cual es el dominio por defecto, mientras que la directivanameserver especifica la dirección IP del servidor de nombres a utilizar para peticionesde resolución. Pueden indicarse varias de estas directivas, para utilizar servidores denombres alternativos.

45

Consultando interactivamente un servidor de nombresEl paquete BIND provee una herramienta de depuración llamada nslookup que puedeutilizarse para hacer consultas interactivamente a un servidor de nombres.

Al ser ejecutada desde la línea de comandos, nslookup informa cual es el server de nombresque se utilizará y queda a la espera de comandos del usuario:

$ nslookupDefault server: cygni.galaxia.org.arAddress: 170.25.1.253> _

Si se escribe el nombre de una computadora, nslookup realizará la consulta al server denombres y nos mostrará el resultado:

$ nslookupDefault server: cygni.galaxia.org.arAddress: 170.25.1.253> rigel

Server: cygni.galaxia.org.arAddress: 170.25.1.253

Name: andromeda.galaxia.org.arAddress: 170.25.1.2

De manera similar, es posible utilizar nslookup para hacer consultas sobre otro dominio:

$ nslookupDefault server: cygni.galaxia.org.arAddress: 170.25.1.253> bbs.frc.utn.edu.ar

Server: cygni.galaxia.org.arAddress: 170.25.1.253

Name: bbs.frc.utn.edu.arAddress: 170.210.248.214

46

Diagnóstico de una red TCP/IPUna vez que la red ha sido diseñada y configurada, sus usuarios comienzan a trabajar sobreella y a utilizar sus servicios. Es un hecho que, tarde o temprano, alguno de ellos tendráalguna dificultad para acceder a algún servicio y recurrirá al administrador de la red a fin deobtener una solución. Sin embargo, antes de poder ofrecer alguna, el administrador deberádiagnosticar el problema, esto es, hallar sus causas.

Mensajes de error usualesHay ciertas condiciones de error que son usuales en una red TCP/IP. Si bien los mensajes deerror con que las aplicaciones informan al usuario acerca de las mismas son altamentedependientes de la plataforma, la mayoría de las veces son similares a los siguientes:

Unknown host: El nombre de host utilizado por el usuario no pudo resolverse; es decir, nopudo obtenerse su dirección IP. Puede ser indicativo de un error en elacceso al servidor de nombres: quizás es errónea la dirección IP indicadaen el archivo /etc/resolv.conf , o el demonio named no se encuentaactivo en esa computadora, o el módulo TCP/IP de la misma no seencuentra funcionando correctamente. Sin embargo, también puededeberse a un error en el tipeo del nombre (esto es, podría no existir unacomputadora con el nombre indicado).

Network unreachable: El sistema local no tiene una ruta que conduzca a la red a la quecorresponde la dirección IP de la máquina remota. Puede debersea un error en la configuración de la tabla de ruteo, a que la ruta sehaya vuelto inalcanzable (por ejemplo, porque el gateway o losvínculos de comunicación que conectan con ella están fuera delínea) o a que la dirección IP utilizada es errónea.

No answer from host: El sistema remoto no contesta las peticiones realizadas desde elhost local. En este caso, usualmente la dirección IP es correcta yexisten rutas a la red a la cual pertenece, pero el host no puedeser contactado debido a que, por ejemplo, se encuentra apagado odesconectado de la red.

Connection refused by peer:Este error indica que, si bien pudo contactarse al hostremoto, el mismo denegó la conexión. Puede deberse amedidas de seguridad (es decir, la computadora remota poralguna razón de seguridad no permite el acceso desde lacomputadora local al servicio que se le requiere) o a que nohay un servicio "escuchando" en el puerto TCP indicadodesde la computadora local (por ejemplo, se desea acceder aldemonio named en la computadora remota, y el mismo no seencuentra ejecutándose allí).

Herramientas de diagnósticoAlgunas de las herramientas ofrecidas por Unix para diagnosticar problemas de red (yusualmente disponibles también en otras plataformas) son las siguientes:

ping: Es la herramienta básica para verificar la conectividad de la red. Permitedeterminar si un host es alcanzable y proporciona estadísticas sobre lostiempos de respuesta de la red.

traceroute24: Muestra la ruta que los paquetes seguirán desde un host de origen hasta otrohost de destino. Permite, entonces, diagnosticar problemas de ruteo.

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

47

nslookup: Permite hacer consultas interactivas a un servidor DNS, tal como se discutióen el capítulo anterior.

netstat: Despliega información sobre la tabla de ruteo, las interfaces y los socketsactivos.

ifconfig: Si bien es básicamente una herramienta de configuración, puede utilizarsetambién como herramienta de diagnóstico, para detectar errores en la direcciónIP, mascara de subred o dirección de broadcast (ver capítulo sobre asignaciónde direcciones IP).

Testeo de alcanzabilidadEl primer paso para diagnosticar un problema en una red TCP/IP es verificar laalcanzabilidad de un host, esto es, si es posible enviar paquetes al mismo a través de la red.

La herramienta primordial para testear alcanzabilidad es ping, cuya sintaxis básica es lasiguiente:

ping nombre_de_host_o_dirección_IP

Por ejemplo, para verificar si el host Rigel es alcanzable, habría que ejecutar el siguientecomando:

$ ping rigelPING rigel.galaxia.org.ar (170.25.1.2): 56 data bytes64 bytes from 170.25.1.2: icmp_seq=0 ttl=64 time=0.1 ms64 bytes from 170.25.1.2: icmp_seq=1 ttl=64 time=0.1 ms64 bytes from 170.25.1.2: icmp_seq=2 ttl=64 time=0.1 ms64 bytes from 170.25.1.2: icmp_seq=3 ttl=64 time=0.1 ms64 bytes from 170.25.1.2: icmp_seq=4 ttl=64 time=0.1 ms64 bytes from 170.25.1.2: icmp_seq=5 ttl=64 time=0.1 ms64 bytes from 170.25.1.2: icmp_seq=6 ttl=64 time=0.1 ms64 bytes from 170.25.1.2: icmp_seq=7 ttl=64 time=0.1 ms64 bytes from 170.25.1.2: icmp_seq=8 ttl=64 time=0.1 ms64 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 lossround-trip min/avg/max = 0.1/0.1/0.1 ms

ping envía paquetes al host remoto utilizando el protocolo ICMP, los cuales, de serrecibidos por dicho host, generan un paquete similar de respuesta para el host local. Cuandoel host local los recibe, muestra una línea de información por pantalla, y el ciclo continúahasta que el usuario lo cancele con Control-C.

Al terminar, ping muestra un reporte estadístico, en el que informa la cantidad de paquetestransmitidos y recibidos, y el porcentaje de pérdida de paquetes. También se informa sobrelos tiempos mínimo, promedio y máximo que toma el recorrido de ida y vuelta entre amboshosts.

Como puede verse, ping permite además determinar el nivel de carga de la red: si elporcentaje de perdida de paquetes o los tiempos de ida y vuelta es muy alto, podría ser unindicio de sobrecarga de tráfico, interferencias en el medio de comunicación, o inclusiveproblemas de hardware.

Verificación del estado de las interfacesComo se recordará el comando ifconfig, al ser invocado sin argumentos, muestra el estadoactual de las interfaces de red configuradas:

48

$ ifconfiglo 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:0eth0 Link encap:Ethernet HWaddr 00:10:4B:38:27:BA

inet addr:170.25.2.254.216 Bcast:170.25.2.244Mask:255.255.255.0UP 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:81inet addr:170.25.3.254 Bcast:170.25.3.254Mask:255.255.255.0UP 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 lógica deloopback). En todos los casos, se muestra la dirección de IP asignada, así también como ladirección de broadcast y la máscara de subred.

En el caso de las placas Ethernet, se informa también la dirección física del adaptador (oMAC Address), y características de configuración del adaptador (número de interrupción ydirección base de I/O).

Las líneas que comienzan con RX y TX presentan un informe del funcionamiento de lainterfaz en términos de cantidad de paquetes recibidos y transmitidos, respectivamente.También se informa en cada caso la cantidad de paquetes erróneos detectados por lainterfaz.

Información similar en un formato mas compacto puede obtenerse con el comando netstat-i:

$ netstat -iKernel Interface tableIface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flaglo 3584 0 331036 0 0 0 331036 0 0 0 BLRUeth0 1500 0 4563766 1 0 0 5864531 0 0 0 BRUeth1 1500 0 4279043 3 0 0 2940848 0 0 0 BRU

Verificación de las rutasPor medio de los comandos ifconfig y netstat -i podemos determinar el estado de lasinterfaces locales, a fin de determinar si son capaces de enviar y recibir paquetes. Usandoping podemos verificar si el host remoto "es visible" desde el host local a través de la red.

Si la comprobación de las interfaces muestra que su estado es el correcto, pero ping no daresultados positivos, el siguiente paso en el diagnóstico de un problema de conectividad conun 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 aun host remoto, y de esa manera detectar errores en la configuración de las tablas de ruteo:

$ traceroute canopus

49

tracing to canopus.galaxia.org.ar (170.25.4.1), 30 hops max, 40bytes packets1 orion (170.225.1.254) 0.361 ms 0.302 ms 0.296 ms2 andromeda (170.25.3.253) 44.366 ms 38.533 ms 13.282 ms3 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 comoresultado todos los gateways intermedios que se atraviesan hasta llegar a destino. Lainformación se recaba por medio del envío de paquetes ICMP; si alguno de ellos se perdieraen el camino, traceroute mostrará una serie de asteriscos.

Por ejemplo, supongamos que el usuario de la computadora Antares reporta la imposibilidadpara conectarse a Canopus. El primer paso en el diagnóstico sería revisar la configuraciónde las interfaces con ifconfig y luego verificar si realmente no hay conectividad, utilizandoping. Si ese fuera el caso, puede deberse tanto a que Canopus esté fuera de línea como a queexista algún problema en algún punto intermedio de la red. Por medio de traceroute puededeterminarse cual es el caso.

Supongamos que la salida de traceroute es la siguiente:

$ traceroute canopustracing to canopus.galaxia.org.ar (170.25.4.1), 30 hops max, 40bytes packets1 orion (170.225.1.254) 0.361 ms 0.302 ms 0.296 ms2 andromeda (170.25.3.253) 44.366 ms 38.533 ms 13.282 ms3 * * *4 * * *5 * * *

traceroute continuará mostrando asteriscos hasta llegar a los 30 intentos o hasta que elusuario lo cancele con Ctrl-C. La conclusión aquí es que la falta de conectividad se debe aque Canopus está fuera de línea o bien los enlaces desde Andrómeda estan fallando. Podríaprobarse, por ejemplo, el utilizar ping para intentar llegar a otra computadora sobre lamisma subred de Canopus (por ejemplo, ping centauri); si la respuesta es negativa setrataría de un problema de red, mientras que si es positiva, la respuesta es que Canopus estáfuera de línea.

Si el resultado de traceroute fuera el siguiente:

$ traceroute canopustracing to canopus.galaxia.org.ar (170.25.4.1), 30 hops max, 40bytes packets1 orion (170.225.1.254) 0.361 ms 0.302 ms 0.296 ms2 * * *3 * * *4 * * *5 * * *

entonces o bien hay un problema en el gateway o en las líneas de comunicación hacia él. Lacuestión puede zanjarse procediendo de manera similar al caso anterior.

50

Compartiendo archivos: NFSNFS (Network File System) permite el acceso transparente a archivos y directorios ubicadosen computadoras remotas, es decir, permite que usuarios y programas traten archivosremotos como si fueran locales.

La computadora remota (llamada server NFS) pone ciertos directorios de su propio sistemade archivos a disposición de otras computadoras exportándolos hacia la red. Para acceder alos archivos remotos, las computadoras que los utilizan (los clientes NFS) previamentedeben montar alguno de los directorios exportados por el servidor en algún punto de susistema de archivos (de la misma forma que los sistemas de archivos residentes en discosduros locales deben ser montados antes de poder ser utilizados).

Andrómeda(server NFS)

/

Altair(cliente NFS)

/

bin usr etc tmp net bin usr etc tmp

localbinbin etc apps

A modo de ejemplo, en el gráfico anterior se muestra que Andrómeda, actuando comoservidor NFS, exporta a la red el directorio /net, y que un cliente NFS, en éste caso Altair, lomonta 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 estánubicados en Andrómeda.

NFS fue desarrollado originariamente por Sun Microsystems, y se transformó en el standardpara compartir archivos bajo plataforma Unix; también existen actualmenteimplementaciones de NFS para otros sistemas operativos.

Los demonios de NFSPara ofrecer servicios NFS, una computadora debe ejecutar los siguientes demonios:

rpc.nfsd: Es el demonio principal de NFS, responsable de manejar las peticiones de losclientes 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 lossiguientes:

biod: Demonio de E/S por bloques. Gestiona el lado del cliente de las peticiones deEntrada/Salida vía NFS. Este demonio solo es necesario en el cliente NFS.

rpc.lockd: Demonio de bloqueo. Este demonio se ejecuta tanto en el cliente como en elserver, y gestiona las peticiones de acceso en modo exclusivo.

rpc.statd: Demonio de control de estado. Este demonio es requerido por rpc.lockd paramonitorear las operaciones de E/S por NFS.

51

Exportando directoriosPara 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 elsubdirectorio se encuentre en otro dispositivo físico; tampoco se pueden exportardirectorios ubicados por arriba de un directorio exportado, a menos que pertenezcan adiferentes dispositivos físicos.

• Solo es posible exportar directorios locales.

El archivo /etc/exports contendrá una línea por cada directorio exportado, en la quese indicará la ruta completa al mismo, seguida por ciertos parámetros que configurarán elmodo en que se exporta el directorio, los cuales permiten especificar cuales computadorastienen derecho a montar remotamente el directorio exportado, y de que manera:

/net *.galaxia.org.ar(rw)/home/jperez canopus.galaxia.org.ar(rw)/datos/ftp/public (ro)

En el ejemplo anterior, el server NFS exporta tres directorios:

/net Accesible desde cualquier computadora del dominio galaxia.org.ar, enmodo de lectura/escritura (rw = read/write).

/home/jperez Accesible sólo desde la computadora Canopus, también en modo delectura/escritura.

/datos/ftp/public Accesible desde cualquier computadora (de cualquier dominio), pero enmodo de sólo lectura (ro = read only).

Montando directoriosLos directorios remotos se montan localmente de la misma manera que otro sistema dearchivos: manualmente por medio del comando mount, o listándolos en /etc/fstabpara que se monten automáticamente 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 Andrómeda en /usr/local deAltair, se debe ejecutar el siguiente comando:

# mount andromeda:/net /usr/local

Alternativamente, se podría agregar la siguiente línea en /etc/fstab :

andromeda:/net /usr/local nfs rw,bg 0 0

Obsérvese que al montar un directorio remoto pude indicarse la opción bg a fin de realizarla operación de montura en background.

Si al momento de solicitar la montura el server NFS no se encuentra disponible, el clientepermanecerá reintentando hasta que el server lo esté. La opción bg premite que esosreintentos continúen en background y así no detener las demás operaciones del cliente queno 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).

52

Por defecto, las monturas de directorios NFS son duras, lo cual significa que el clientepermanecerá reintentando indefinidamente hasta recibir respuesta del server. Si la monturaes blanda (en cuyo caso deberá utilizarse la opción soft en /etc/fstab o al montarmanualmente con mount), al cabo de cierto número de reintentos la operación fallará yretornará un mensaje de error al usuario, indicando que el server es inaccesible.

Administración centralizada de hosts: NISUno de los aspectos que puede volverse mas problemático en la administración de una redUnix es el mantenimiento de la consistencia en ciertos archivos de configuración.

Supóngase que en una red como la de galaxia.org.ar se desea que todos los usuarios puedanutilizar cualquier computadora de la red, utilizando en todas ellas el mismo nombre de loginy 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 cadacambio (por ejemplo, al agregar un nuevo usuario o cuando un usuario cambia supassword), dicho cambio deberá ser propagado a todas las demás computadoras de la red.

Si la red tiene pocas computadoras, la consistencia de los archivos replicados puedemantenerse manualmente, pero, a medida que la red crece, el trabajo y la probabilidad decometer errores crece desmedidamente.

NIS (sigla de Network Information Service, o Servicio de Información de Red) fue diseñadopara solucionar este problema, proveyendo los medios para administrar centralizadamentearchivos de datos y diseminarlos luego en un grupo de computadoras que forman parte de undominio NIS25.

NIS es también un sistema cliente/servidor, en donde ciertas computadoras (denominadasservidores NIS) mantienen los archivos de datos (llamados mapas NIS) y respondenconsultas de otras computadoras (los clientes NIS) acerca de información contenida en esosarchivos.

Un dominio NIS puede contar con varios servidores NIS. Uno de ellos, el servidor NISmaestro, contiene la copia original de los archivos de datos y es responsable de manteneractualizado un grupo de servidores NIS esclavos, los cuales responden peticiones de losclientes, pero no modifican sus archivos de datos directamente.

La arquitectura general de un dominio NIS se esquematiza en la siguiente figura:

ServerNIS

Maestro

ServerNIS

Esclavo

ServerNIS

Esclavo

ClienteNIS

ClienteNIS

ClienteNIS

ClienteNIS

Transferencia de Mapa Petición NIS

25 Un dominio NIS no tiene ninguna relación con un dominio DNS, aunque muchas veces eladministrador decide que ambos coindan.

53

Ejecutando NISLos detalles de configuración de un dominio NIS varían según la implementación y estánmas allá de los alcances del presente trabajo. No obstante, y a manera de referencia, cabemencionar 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 computadorasque 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 conocía bajo el nombre Yellow Pages(Paginas Amarillas)

54

Bibliografía 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: diseño e implementación" , por Andrew S. Tanenbaum

• "The Unix-Haters Handbook", por Simson Garfinkel, Daniel Weise & Steven Strassman

Redes TCP/IP bajo Unix - frlp.utn.edu.ar · Redes TCP/IP bajo Unix Conceptos básicos de Operación...

Documents

Transcript of Redes TCP/IP bajo Unix - frlp.utn.edu.ar · Redes TCP/IP bajo Unix Conceptos básicos de Operación...