La idea de red es probablemente tan vieja como la de las telecomunicaciones. Consideremos a la gente que vivía en la edad de piedra, donde los tambores se habrían utilizado para transmitir mensajes entre individuos. Suponga que el cavernícola A quiere invitar al cavernícola B a un partido de lanzamiento de rocas contra el otro, pero viven demasiado lejos como para que B oiga a A golpear su tambor. ¿Cuales son las opciones de A? Podría

Claro, que ya ha pasado un tiempo desde los primeros intentos de nuestros antepasados.

Hoy en día tenemos ordenadores que hablan entre sí a través de vastas conexiones de cables, fibras ópticas, microondas, y otros medios parecidos, para quedar para el partido del sábado.

A continuación trataremos sobre las maneras en que esto se realiza, pero olvidándonos de los cables, así como de la parte del partido.

En esta Guía escribiremos sobre dos tipos de redes: las basadas en UUCP, y las basadas en TCP/IP. Estos son conjuntos de protocolos y paquetes de software que proporcionan medios para transportar datos entre dos ordenadores. En este capítulo veremos ambos tipos y discutiremos sus principios fundamentales.

Definiremos una red como un conjunto de nodos que son capaces de comunicarse entre sí, a menudo contando con los servicios de varios nodos especializados que conmutan datos entre los participantes. Los nodos suelen ser ordenadores, aunque no es necesario; podemos considerar también terminales X o impresoras inteligentes como nodos. Pequeñas aglomeraciones de nodos también se llaman instalaciones.1

La comunicación seria imposible sin algún tipo de lenguaje o código. En las redes de ordenadores, estos lenguajes son llamados colectivamente protocolos. Sin embargo, no debería pensar en protocolos escritos, sino más bien en el código de comportamiento altamente formalizado que se observa cuando se encuentran los jefes de estado. De un modo muy similar, los protocolos usados por las redes de ordenadores no son sino normas muy estrictas para el intercambio de mensajes entre dos o más nodos.

UUCP es una abreviatura de Unix-to-Unix Copy (Copia de Unix a Unix). Comenzó siendo un paquete de programas para transferir ficheros sobre líneas serie, programar esas transferencias, e iniciar la ejecución de programas en el lugar remoto. Ha experimentado grandes cambios desde su primera implementación a finales de los setenta, pero aun es bastante espartano en los servicios que ofrece. Su principal aplicación es todavía en redes de área metropolitana (WAN) basadas en enlaces telefónicos.

 UUCP comenzó a desarrollarse por los Laboratorios Bell en 1977 para la comunicación entre sus laboratorios de desarrollo de Unix. A mediados de 1978, esta red ya conectaba a mas de 80 centros. Se ejecutaban aplicaciones de correo electrónico, así como de impresión remota; sin embargo, el uso principal del sistema era distribuir software nuevo y mejoras.2 Hoy día, UUCP ya no está confinado en el entorno UNIX. Hay versiones comerciales disponibles para diversas plataformas, incluyendo AmigaOS, DOS, TOS de Atari, etc.

Una de las principales desventajas de las redes UUCP es su bajo ancho de banda. Por un lado, el equipo telefónico establece un limite rígido en la tasa máxima de transferencia. Por otro lado, los enlaces UUCP raramente son conexiones permanentes; en su lugar, los nodos se llaman entre sí a intervalos regulares. Es por ello, que la mayoría del tiempo que le lleva a un mensaje viajar por una red UUCP permanece atrapado en el disco de algún nodo, esperando al establecimiento de la próxima conexión.

A pesar de estas limitaciones, aun hay muchas redes UUCP funcionando en todo el mundo, utilizado principalmente por aficionados, ya que ofrecen acceso de red a usuarios privados a precios razonables. La razón fundamental de la popularidad del UUCP es que es baratísimo comparado con tener el ordenador conectado al Gran Cable de Internet. Para hacer de su ordenador un nodo UUCP, todo lo que necesita es un módem, software UUCP, y otro nodo UUCP que desee suministrarle correo y noticias.

_____________________________________________
1 N. del T.: Del inglés site
2 No parece que con el tiempo haya cambiado mucho esto. . .

La idea que hay detrás de UUCP es bastante simple: como su nombre indica, básicamente copia ficheros de un nodo a otro, pero también permite realizar ciertas acciones en el nodo remoto.

Suponga que le esta permitido que su máquina acceda a un nodo hipotético llamado swim, y le va ha hacer ejecutar el comando de impresión lpr para Ud. Entonces, podría escribir lo siguiente en su línea de comandos para que le imprima este libro en swim:3

Esto hace que uux, un comando del repertorio UUCP, planifique un trabajo para swim. Este trabajo consta del fichero de entrada, netguide.dvi, y la petición de enviar este fichero a lpr. La opción -r indica a uux que no llame al sistema remoto inmediatamente, sino que almacene el trabajo hasta que se establezca la próxima conexión. A esto se le llama spooling, o almacenamiento en la cola.

Otra propiedad de UUCP es que permite reenviar trabajos y ficheros a través de varios nodos, suponiendo que éstos colaboren. Asumiremos que swim, el nodo del ejemplo anterior, tiene un enlace UUCP con groucho, el cual mantiene un gran numero de aplicaciones UNIX. Para transferir el fichero tripwire-1.0.tar.gz hasta su máquina debería indicarlo así:

El trabajo creado pedirá a swim que traiga el fichero desde groucho, y lo envíe hasta su máquina, donde UUCP lo almacenara en trip.tgz y le notificará por correo la llegada del fichero. Esto ocurrirá en tres pasos. Primero, su máquina envía el trabajo a swim.

La siguiente vez que swim establezca contacto con groucho, se transferirá el fichero de groucho a swim. El último paso es la transferencia del mismo desde swim hasta su máquina.

Los servicios más importantes que proporcionan las redes UUCP hoy en día son el correo electrónico y las noticias. Lo introduciremos brevemente y después lo veremos en mas detalle.

El correo electrónico - e-mail4 para abreviar - le permite intercambiar mensajes con usuarios de nodos remotos sin tener realmente que saber como acceder a estos nodos. La tarea de dirigir un mensaje desde su máquina destino la realiza enteramente el sistema de manejo de correo. En un entorno UUCP, el correo generalmente se transporta ejecutando el comando rmail en el nodo vecino, pasándole la dirección del receptor y el mensaje. Rmail reenviará entonces el mensaje a otro nodo, y seguirá así, hasta que alcance el nodo destino.

_____________________________________________
3 Si usa bash, la shell GNU Bourne Again SHell, tendría que quitar los signos de exclamación, porque los usa como su carácter de histórico.
4 En el idioma castellano comienzan a aparecer adaptaciones mas o menos afortunadas, como e-milio

Veremos esto en detalle en el capítulo 13.

La mejor forma de definir el servicio de noticias es considerarlo como un sistema de tablón de anuncios distribuido. Muy a menudo, este termino se refiere a las noticias de Usenet, que es, con mucho, la mas conocida red de intercambio de noticias, con un número de nodos participantes estimado en 120.0005. Los orígenes de Usenet se remontan a 1979, cuando, tras la aparición del UUCP con el nuevo Unix V7, tres estudiantes graduados tuvieron la idea de un intercambio de información general entre la comunidad Unix. Estos escribieron algunos scripts, creando el primer sistema de noticias en red. En 1980, esta red conectaba duke, unc, y phs, y dos Universidades de Carolina del Norte, de forma aislada. Usenet creció más todavía posteriormente. Aunque su origen fue como una red basada en UUCP, ya no esta limitada a un único tipo de redes.

La unidad básica de información es el articulo, que puede ser enviado a una jerarquía de grupos de noticias dedicadas a temas específicos. La mayoría de los nodos reciben únicamente una selección de todos los grupos de noticias, que transportan una media de 60Mb6 de artículos por día.

En el mundo UUCP, las noticias generalmente se envían a través de un enlace UUCP, recolectando todos los artículos de los grupos de noticias solicitados, y empaquetándolos en varios lotes7 . Estos se envían al lugar receptor, donde se pasan al comando rnews que los desempaqueta y procesa posteriormente.

Finalmente, UUCP es también el medio elegido por muchos servidores de ficheros que ofrecen acceso publico. Generalmente podrá acceder a ellos llamando con UUCP, accediendo como usuario invitado, y transferiéndose los archivos desde un área de ficheros públicamente accesible. Estas cuentas de invitado tienen, a menudo, un nombre de acceso y password como UUCP/nuucp o algo similar.

Aunque UUCP puede resultar una elección razonable para enlaces de red mediante llamada de bajo coste, hay muchas situaciones en las que su técnica de almacenamiento y reenvío se muestra demasiado inflexible, por ejemplo en Redes de Area Local (LANs, o RALs). Estas redes están compuestas generalmente por un pequeño numero de maquinas localizadas en el mismo edificio, o incluso en la misma planta, que están interconectadas para proporcionar un entorno de trabajo homogéneo. Es típico que se quiera compartir ficheros entre estos nodos, o ejecutar aplicaciones distribuidas en diferentes máquinas.

_____________________________________________
5 Teniendo en cuenta que hace tiempo que se escribió este libro, es seguro que son muchos más.
6 De nuevo son datos no actualizados
7 N. del T.: Del inglés batches

Estas tareas requieren una aproximación completamente diferente a las redes. En lugar de reenviar ficheros completos con una descripción del trabajo, todos los datos se fragmentan en pequeñas unidades (paquetes), que se envían inmediatamente al nodo destino, donde son reensamblados. Este tipo de redes son llamadas redes de intercambio de paquetes. Entre otras cosas, esto permite ejecutar aplicaciones interactivas a través de la red. El coste de esto supone, por supuesto, una complejidad adicional al software.

La solución que han adoptado los sistemas UNIX _ y muchos no-un?x _ es conocida como TCP/IP. En esta sección echaremos un vistazo a sus conceptos básicos.

El TCP/IP tiene sus orígenes en un proyecto de investigación fundado en Estados Unidos por el DARPA (Defense Advanced Research Projects Agency, Agencia de Proyectos Avanzados de Investigación en Defensa) en 1969. Esta fue una red experimental, la red ARPANET, que paso a ser operativa en 1975, después de haber demostrado ser un éxito.

En 1983, fue adoptado como estándar el nuevo conjunto de protocolos TCP/IP, y todos los nodos de la red pasaron a utilizarlo. Cuando ARPANET por fin dio paso a Internet (con la propia ARPANET integrándose en su existencia en 1990), el uso del TCP/IP se había extendido a redes más allá de la propia Internet. Las más destacables son las redes locales UNIX, pero con la llegada de los equipos telefónicos digitales rápidos, como la RDSI, también tiene un futuro prometedor como transporte en redes telefónicas.

Para ilustrar las explicaciones que demos en las siguientes secciones, tomaremos como ejemplo una red típica: la de una universidad, concretamente la hipotética Universidad Groucho Marx (GMU) situada, por ejemplo, en algún lugar de Libertonia. En esta universidad, la mayoría de los departamentos mantienen sus propias redes de área local, mientras que algunos comparten una, y otros poseen varias. Todos ellos están interconectados, y están enganchados a Internet a través de un solo enlace de alta velocidad.

Supongamos una máquina Linux conectada a una LAN de nodos UNIX en el Departamento de Matemáticas, y su nombre es erdos. Para acceder a un nodo del Departamento de Físicas, por ejemplo quark, introducirá el siguiente comando:

En la línea de comandos, introducirá su nombre de acceso, pongamos que es Andrés, y su clave. Entonces dispondrá de una shell de quark, sobre la que puede escribir como si estuviera sentado en la consola del sistema. Tras salir de la shell volverá a tener la línea de comandos de su propia máquina. Acaba de utilizar una de las aplicaciones de interactividad instantánea que proporciona TCP/IP: el acceso remoto.

Mientras este conectado a quark, podría también desear ejecutar una aplicación X, como un programa de dibujo de funciones, o un visor de Postscript. Para indicar a esta aplicación que desea ver las ventanas en su monitor local, debe modificar la variable de entorno DISPLAY:

Si pone en marcha ahora su aplicación, esta contactara con su servidor X en lugar del de quark, y mostrara todas las ventanas en su monitor. Por supuesto, esto requiere que este ejecutando X11 en erdos. La clave esta en que TCP/IP permite a quark y a erdos enviarse paquetes X11 en ambos sentidos para darle a Ud. la impresión de que esta en un único sistema. La red es casi transparente en este caso.

Otra aplicación muy importante en redes TCP/IP es NFS, abreviatura de Network File System (Sistema de Ficheros de Red). Es otra forma de hacer trasparente la red, porque básicamente permite montar jerarquías de directorios de otras maquinas, de modo que aparezcan como sistemas de ficheros locales. Por ejemplo, todos los directorios "home", o personales, de los usuarios pueden estar en una máquina servidor central, desde la cual montan los directorios el resto de maquinas de la LAN. El efecto de esto es que los usuarios pueden acceder a cualquier máquina, y encontrarse a sí mismos en el mismo directorio.

De forma similar, es posible instalar aplicaciones que requieren gran cantidad de espacio en disco (tales como TEX) en una única máquina, y exportar estos directorios a otras maquinas.

Volveremos sobre NFS en el capítulo 11.

Por supuesto, esto son solo ejemplos de lo que se puede hacer en un entorno de redes TCP/IP: las posibilidades son casi ilimitadas.

Ahora echaremos una mirada mas de cerca al modo en que trabaja TCP/IP. Esto es necesario para comprender como y por que tiene que configurar su máquina. Comenzaremos examinando el hardware, y poco a poco recorreremos todo el camino.

El tipo de hardware mas utilizado en LANs es lo que comúnmente conocemos como Ethernet. Consta de un solo cable con los nodos colgando de él a través de conectores, clavijas o transceptores. Las ethernet simples, son baratas de instalar, lo que unido a un flujo de transferencia neto de 10 Megabits por segundo avala gran parte de su popularidad.

Hay tres tipos de Ethernet, en función de su cable, llamadas gruesas, finas y de par trenzado. Tanto el fino como el grueso utilizan cable coaxial, difiriendo en el grosor y el modo de conectar este cable a los nodos. El Ethernet fino emplea conectores "BNC" con forma de T, que se pinchan en el cable y se enganchan a los conectores de la parte trasera del ordenador. El Ethernet grueso requiere que realice un pequeño agujero en el cable, y conecte un transceptor utilizando un "conector vampiro". Entonces se pueden conectar uno o más nodos al transceptor. Los cables Ethernet fino y grueso pueden alcanzar una distancia de 200 y 500 metros, respectivamente, y es por ello que se les llama también 10base-2 y 10base-5. El par trenzado usa un cable hecho de dos hilos de cobre como las que se encuentran en las instalaciones telefónicas ordinarias, pero generalmente necesitan hardware adicional. También se conoce como 10base-T.

A pesar de que añadir un nodo a una Ethernet gruesa es un poco lioso, eso no tirará abajo la red; sin embargo, para añadir un nodo en una instalación de cable fino, se debe interrumpir el servicio de red al menos por unos minutos ya que se debe cortar el cable para insertar el conector.

La mayoría de gente prefiere el Ethernet fino porque es barato: las tarjetas de PC pueden encontrarse por unos 50 dólares americanos (unas 5000 pesetas), o incluso menos, y el cable esta por unos centavos el metro. Sin embargo, para instalaciones de gran escala, es más apropiado el Ethernet grueso. Por ejemplo, la Ethernet del Departamento de Matemáticas de la GMU utiliza Ethernet gruesa, de modo que no se interrumpe el tráfico cada vez que se añade un nodo a la red.

Uno de los inconvenientes de la tecnología Ethernet es su limitada longitud de cable, que imposibilita cualquier uso fuera de las LANs. Sin embargo, pueden enlazarse varios segmentos de Ethernet entre sí utilizando repetidores, puentes o encaminadores8. Los repetidores simplemente copian las señales entre dos o más segmentos, de forma que todos los segmentos juntos actúan como si fuese una única Ethernet. Debido a requisitos de tiempos, no puede haber mas de cuatro repetidores entre cualquier par de nodos de la red. Los puentes y encaminadores son mas sofisticados, analizan los datos de entrada y los reenvían solo si el nodo receptor no esta en la Ethernet local.

Ethernet funciona como un sistema de bus, donde un nodo puede mandar paquetes (o tramas) de hasta 1500 bytes a otro nodo de la misma Ethernet. Cada nodo se direcciona por una dirección de seis bytes grabada en el firmware de su tarjeta Ethernet. Estas direcciones se especifican generalmente como una secuencia de números hexadecimales de dos dígitos separados por dos puntos, como en aa:bb:cc:dd:ee:ff.

_____________________________________________
8 N. del T.: Respectivamente, repeaters, bridges y routers

Una trama enviada por una estación la ven todas las estaciones conectadas, pero solo el nodo destinatario la toma y la procesa. Si dos estaciones intentan emitir al mismo tiempo, se produce una colisión, que se resuelve por parte de las dos estaciones abortando el envío, y reintentándolo al cabo de un rato.

En instalaciones mayores, como la Universidad de Groucho Marx, Ethernet no es el único tipo de red que puede utilizarse. En la Universidad de Groucho Marx cada LAN de un departamento esta enlazada a la troncal del campus, que es un cable de fibra óptica funcionando en FDDI (Fiber Distributed Data Interface). FDDI emplea un enfoque totalmente diferente para transmitir datos, que básicamente implica el envío de un numero de testigos, de modo que una estación solo pueda enviar una trama si captura un testigo. La principal ventaja de FDDI es una velocidad de hasta 100 Mbps, y una longitud de cable máxima de hasta 200 km.

Para enlaces de red de larga distancia, se utiliza frecuentemente un tipo distinto de equipos, que se basa en el estándar X.25. Muchas de las llamadas Redes Publicas de Datos, como Tymnet en Estados Unidos, Datex-P en Alemania, o Iberpac en España, ofrecen este servicio. X.25 requiere un hardware especial, llamado Ensamblador/Desensamblador de Paquetes o PAD. X.25 define un conjunto de protocolos de red de derecho propio, pero sin embargo se usa frecuentemente para conectar redes bajo TCP/IP y otros protocolos. Ya que los paquetes IP no se pueden convertir de forma simple en X.25 (y viceversa), estos deben ser encapsulados en paquetes X.25 y enviados a través de la red.

Frecuentemente, los radioaficionados usan sus propios equipos de radio para conectar sus ordenadores en red; esto se llama packet radio o ham radio. El protocolo utilizado por el packet radio es el llamado AX.25, que deriva del X.25.

Otras técnicas implican el uso de las lentas pero baratas líneas serie para acceder bajo demanda. Esto requiere aun otros protocolos para la transmisión de paquetes, como SLIP o PPP, que se describen mas adelante.

Por supuesto, Ud. no querrá que su red este limitada a una Ethernet. Idealmente, Ud. desearía poder acceder a la red sin importarle ni el hardware del que dispone ni el número de subestaciones. Por ejemplo, en instalaciones grandes como la Universidad de Groucho Marx, habrá varias Ethernets separadas, que han de conectarse de alguna manera. En la GMU, el departamento de matemáticas tiene dos Ethernets: una red de maquinas rápidas para profesores y graduados, y otra con maquinas mas lentas para estudiantes. Ambas redes están colgadas de la red troncal FDDI del campus.

Esta conexión se gestiona con un nodo dedicado, denominado pasarela, o gateway, que maneja los paquetes entrantes y salientes copiándolos entre las dos Ethernets y el cable de fibra óptica. Por ejemplo, si se encuentra en el Departamento de Matemáticas, y quiere acceder a quark situada en la LAN del Departamento de Físicas desde su máquina Linux, el software de red no puede mandar paquetes a quark directamente, porque no esta en la misma Ethernet. Por tanto, tiene que confiar en la pasarela para que actúe como retransmisor. La pasarela (llamémosla sophus) reenvía entonces estos paquetes a su pasarela homologa niels del Departamento de Físicas, usando la troncal, y por fin niels los entrega a la máquina destino. El flujo de datos entre erdos y quark se muestra en la figura 1.1 (con disculpas a Guy L. Steele).

Este esquema de envío de datos al nodo remoto se llama encaminamiento, y en este contexto a los paquetes se les denomina a menudo datagramas. Para facilitar las cosas, el intercambio de datagramas esta gobernado por un único protocolo que es independiente del hardware utilizado: IP, o Internet Protocol. En el capítulo 2, trataremos el IP y el encaminamiento en mayor detalle.

El principal beneficio del IP es que convierte a redes físicamente distintas en una red aparentemente homogénea. A esto se le llama internetworking (interconexión de redes), y a la resultante "meta-red" se la denomina Internet. Observe aquí la sutil diferencia entre una Internet y La Internet. El último es el nombre oficial de una Internet global particular.

Claro que el IP también necesita un esquema de direccionamiento independiente del hardware. Esto se consigue asignando a cada nodo un número único de 32 bits, que define su dirección IP. Una dirección IP se escribe normalmente como 4 números en decimal, uno por cada división de 8 bits, y separados por puntos. Por ejemplo, quark podría tener una dirección IP 0x954C0C04, que se escribiría como 149.76.12.4. A este formato se le llama notación de puntos.

Se dará cuenta de que ahora tenemos tres tipos distintos de direcciones: primero, tenemos el nombre del nodo, quark, después tenemos las direcciones IP, y por fin están las direcciones hardware, como la dirección Ethernet de 6 bytes. De alguna forma todas ellas deben relacionarse, de modo que cuando escriba rlogin quark, se le pueda pasar la dirección IP al software de red; y cuando el nivel IP envíe datos a la Ethernet del Departamento de Físicas, de algún modo tiene que encontrar a que dirección Ethernet corresponde la dirección IP. Lo cual no resulta trivial.

Figura 1.1: Los tres pasos para enviar un datagrama desde erdos a quark.

No entraremos en esto aquí, sino que lo dejamos para el capítulo 2. De momento, es suficiente con indicar que estos pasos para encontrar las direcciones se llaman resolución de nombres, para mapear nombres de nodo con direcciones IP, y resolución de direcciones, para hacer corresponder estas últimas con direcciones hardware.

Para líneas serie se usa frecuentemente el estándar "de facto" conocido como SLIP o Serial Line IP (IP sobre línea serie). Una modificación del SLIP es el CSLIP, o SLIP Comprimido, que realiza compresión de las cabeceras IP para aprovechar el bajo ancho de banda que proporcionan los enlaces serie.9 Un protocolo serie distinto es el PPP, o Point-to-Point Protocol (Protocolo Punto a Punto). PPP dispone de muchas mas características que SLIP, incluyendo una fase de negociación del enlace. Su principal ventaja sobre SLIP es, sin embargo, que no se limita a transportar datagramas IP, sino que se diseño para permitir la transmisión de cualquier tipo de datagramas.

Pero la historia no se acaba con el envío de datagramas de un nodo a otro. Si desea acceder a quark, necesita disponer de una conexión fiable entre su proceso rlogin en erdos y el proceso de shell en quark. Para ello, la información enviada en uno y otro sentido debe dividirse en paquetes en el origen, y ser reensamblada en un flujo de caracteres por el receptor. Esto que parece trivial, implica varias tareas complejas.

Una cosa importante a saber sobre IP es que, por si solo, no es fiable. Suponga que diez personas de su Ethernet comienzan a transferirse la última versión de XFree86 del servidor de FTP de GMU. La cantidad de trafico generada por esto podría ser excesiva para que la maneje la pasarela, porque es demasiado lenta, y anda escasa de memoria. Si en ese momento Ud. envía un paquete a quark, sophus podría tener agotado el espacio del buffer durante un instante y por tanto no seria capaz de reenviarlo. IP resuelve este problema simplemente descartándolo. El paquete se pierde irrevocablemente. Lo cual traslada la responsabilidad de comprobar la integridad y exactitud de los datos a los nodos extremos, y su retransmisión en caso de error.

_____________________________________________
9 SLIP está descrito en la norma RFC 1055. La compresión de cabeceras CSLIP, basada en el, se describe en la RFC 1144.

De esto se encarga otro protocolo, TCP, o Transmission Control Protocol (Protocolo de Control de la Transmisión), que construye un servicio fiable por encima de IP. La propiedad esencial de TCP es que usa IP para darle la impresión de una conexión simple entre los procesos en su equipo y la máquina remota, de modo que no tiene que preocuparse de como y sobre que ruta viajan realmente sus datos. Una conexión TCP funciona básicamente como una tubería de doble sentido en la que ambos procesos pueden escribir y leer; puede imaginarla como una conversación telefónica.

TCP identifica los extremos de tal conexión por las direcciones IP de los dos nodos implicados, y el numero de los llamados puertos de cada nodo. Los puertos se pueden ver como puntos de enganche para conexiones de red. Si vamos a explotar el ejemplo del teléfono un poco mas, uno puede comparar las direcciones IP con los prefijos de área (los números representarían ciudades), y los números de puerto con los códigos locales (números que representan teléfonos de personas concretas).

En el ejemplo de rlogin, la aplicación cliente (rlogin) abre un puerto en erdos, y se conecta al puerto 513 de quark, en el que se sabe que esta escuchando el servidor rlogind.

Esto establece una conexión TCP. Usando esta conexión, rlogind realiza el procedimiento de autorización, y entonces muestra la shell. La entrada y salida estándar de la shell se redirigen a la conexión TCP, de modo que cualquier cosa que escriba a rlogin en su máquina será pasado a través del canal TCP y entregado a la shell como entrada estándar.

También es cierto que TCP no es el único protocolo de usuario en redes TCP/IP. Aunque adecuado para aplicaciones como rlogin, la sobrecarga que impone es prohibitiva para aplicaciones como NFS. Por contra, éste usa un protocolo derivado de TCP llamado UDP, o User Datagram Protocol (Protocolo de Datagramas de Usuario). De igual modo que TCP, UDP también permite que una aplicación contacte con un servicio en un puerto concreto de la máquina remota, pero no establece una conexión para ello. En cambio, puede usarlo para enviar paquetes sueltos al servicio destino - de ahí su nombre.

Suponga que ha montado la jerarquía del directorio TEX del servidor de NFS central del departamento, galois, y desea ver un documento que describe como usar LATEX. Arranca su editor, y lee el fichero completo. Sin embargo, le llevaría demasiado tiempo establecer una conexión TCP con galois, enviar el fichero, y liberarla de nuevo. En cambio, se hace una petición a galois, que envía el fichero en un par de paquetes UDP, que es mucho mas rápido. Sin embargo, UDP no se hizo para controlar la perdida o corrupción de paquetes. Es responsabilidad de la aplicación - en este caso NFS - tener en cuenta esto.

Los puertos se pueden ver como puntos de anclaje para conexiones de red. Si una aplicación quiere ofrecer un cierto servicio, se engancha a un puerto y espera a los clientes (a esto también se le llama escuchar en un puerto). Un cliente que quiera usar este servicio consigue un puerto libre en su nodo local, y se conecta al puerto del servidor en el nodo remoto.

Una propiedad importante de los puertos es que una vez que se ha establecido una conexión entre el cliente y el servidor, otra copia del servidor puede engancharse al puerto servidor y esperar a mas clientes. Esto permite, por ejemplo, varios accesos remotos simultáneos al mismo nodo, usando todos ellos el mismo puerto 513. TCP es capaz de distinguir unas conexiones de otras, ya que todas ellas provienen de diferentes puertos o nodos. Por ejemplo, si accede dos veces a quark desde erdos, entonces el primer cliente rlogin usara el puerto local 1023, y el segundo usara el puerto numero 1022; sin embargo, ambos se conectaran al mismo puerto 513 de quark.

Este ejemplo muestra el uso de puertos como puntos de encuentro, donde un cliente contacta con un puerto especifico para obtener un servicio especifico. Para que un cliente sepa el numero de puerto adecuado, se ha tenido que llegar a un acuerdo entre los administradores de los dos sistemas para asignar estos números. Para servicios ampliamente usados, como rlogin, estos números tienen que administrarse centralmente. Esto lo realiza el IETF (o Internet Engineering Task Force), que regularmente publica un RFC (Request For Comment) denominado Assigned Numbers (Números Asignados). Describe, entre otras cosas, los números de puerto asignados a servicios reconocidos. Linux utiliza un fichero que mapea nombres con números, llamado /etc/services. Se describe en la sección 9.3.

Merece la pena indicar que aunque las conexiones TCP y UDP se basan en puertos, estos números no entran en conflicto. Esto significa que el puerto TCP 513, por ejemplo, es diferente del puerto UDP 513. De hecho, estos puertos sirven como puntos de acceso para dos servicios diferentes, como rlogin (TCP) y rwho (UDP).

En sistemas operativos UNIX, el software que realiza todas las tareas y protocolos descritos anteriormente es generalmente parte del kernel, y por tanto también del de Linux. El interface de programación más común en el mundo UNIX es la Librería de Socket de Berkeley, Berkeley Socket Library. Su nombre proviene de una analogía popular que ve los puertos como enchufes, y conectarse a un puerto como enchufarse. Proporciona la llamada bind(2) para especificar un nodo remoto, un protocolo de transporte, y un servicio al que un programa pueda conectarse o escuchar (usando connect(2), listen(2), y accept(2)). La librería de sockets, sin embargo, es algo mas general, ya que proporciona no solo una clase de sockets basados en TCP/IP (los sockets AF_INET ), sino también una clase que maneja conexiones locales a la máquina (la clase AF_UNIX ). Algunas implementaciones pueden manejar también otras clases, como el protocolo XNS ((Xerox Networking System), o X.25.

En Linux, la librería de sockets es parte de la librería C estándar libc. Actualmente solo soporta los sockets AF_INET y AF_UNIX, pero se hacen esfuerzos para incorporar el soporte de los protocolos de red de Novell, de modo que se añadirían eventualmente una o mas clases de sockets.

Siendo el resultado del esfuerzo concentrado de programadores de todo el mundo, Linux no habría sido posible sin la red global. Así que no sorprende que ya en los primeros pasos del desarrollo, varias personas comenzaran a trabajar para dotarlo de capacidades de red. Casi desde el principio existía ya una implementación de UUCP para Linux; y fue en el otoño de 1992 cuando se comenzó a desarrollar el soporte de TCP/IP, cuando Ross Biro y otros crearon lo que ahora se conoce como Net-1.

Después de que Ross dejara el desarrollo activo en Mayo de 1993, Fred van Kempen comenzó a trabajar en una nueva implementación, reescribiendo gran parte del código. Este esfuerzo continuado se conoce como Net-2. En el verano de 1992 salió la primera versión publica de Net-2d (como parte del kernel 0.99.10), y ha sido mantenida y ampliada por varias personas, muy especialmente por Alan Cox, dando lugar al Net-2Debugged. Tras una dura corrección y numerosas mejoras en el código, cambio su nombre a Net-3 después de que saliese Linux 1.0. Esta es la versión del código de red que se incluye actualmente en las versiones oficiales del kernel.

Net-3 ofrece controladores de dispositivo para una amplia variedad de tarjetas Ethernet, así como SLIP (para enviar trafico de red sobre líneas serie), y PLIP (para líneas paralelo). Con Net-3, Linux tiene una implementación de TCP/IP que se comporta muy bien en entornos de red de área local, mostrándose superior a algunos de los Unix comerciales para PCs.

El desarrollo se mueve actualmente hacia la estabilidad necesaria para su funcionamiento fiable en nodos de Internet.

Además de estas facilidades, hay varios proyectos en marcha que mejoraran la versatilidad de Linux. Un controlador para PPP (el protocolo punto a punto, otra forma de enviar tráfico de red sobre líneas serie) está en estado Beta actualmente, y otro controlador AX.25 para ham radio está en estado Alfa. Alan Cox también ha implementado un controlador para el protocolo IPX de Novell, pero el esfuerzo para un paquete de red completo compatible con el de Novell se ha paralizado por el momento, debido a la negativa de Novell a facilitar la documentación necesaria. Otro proyecto muy prometedor es samba, un servidor de NetBIOS gratis para Unix, escrito por Andrew Tridgell.10

Mientras tanto, Fred siguió desarrollando, continuando con el Net-2e, que dispone de un diseño mas revisado de la capa de red. En el momento de escribir esto, Net-2e es aún software Beta. Lo mas notable sobre Net-2e es la incorporación del DDI, el Device Driver Interface (Interface del controlador de dispositivo). DDI ofrece un acceso y un método de configuración uniforme a todos los dispositivos y protocolos de red.

Otra implementación mas de red TCP/IP es la realizada por Matthias Urlichs, quien escribió un controlador de RDSI para Linux y FreeBSD. Para ello, integro algo del código de red de BSD en el kernel de Linux.

En un futuro previsible, sin embargo, Net-3 parece que llegara para quedarse. Alan trabaja actualmente en una implementación del protocolo AX.25 usado por radioaficionados.

Sin duda, la modularización, aun por desarrollar para el kernel, traerá también nuevos impulsos al código de red. Los módulos le permiten añadir controladores al kernel en tiempo de ejecución.

Aunque todas estas diferentes implementaciones de red intentan dar el mismo servicio, hay grandes diferencias entre ellas a nivel de kernel y dispositivos. Además, no podrá configurar un sistema con un kernel Net-2e con utilidades de Net-2d o Net-3, y viceversa. Esto solo se aplica a comandos que tienen mucho que ver con el funcionamiento interno del kernel; las aplicaciones y los comandos de red comunes como rlogin o telnet se ejecutan en cualquiera de ellos.

A pesar de todo, todas estas diferentes versiones de red no deben preocuparle. A no ser que este participando en el desarrollo activo, no tendrá que preocuparse de que versión del código TCP/IP esta utilizando. Las versiones oficiales del kernel siempre estarán acompañadas de un conjunto de herramientas de red que son compatibles con el código de red presente en el propio kernel.

La última versión del código de red Linux se puede obtener mediante FTP anónimo de varios sitios. El servidor oficial del Net-3 es sunacm.swan.ac.uk, copiado en sunsite.unc.edu en el directorio system/Network/sunacm. El último parche para el Net-2e y los binarios se encuentran disponibles en ftp.aris.com. El código de red basado en BSD de Matthias Urlichs se puede conseguir en ftp.ira.uka.de, directorio /pub/system/linux/netbsd.

Se pueden encontrar los últimos kernels en nic.funet.fi, en el directorio /pub/OS/Linux/PEOPLE/Linus; Los nodos sunsite y tsx-11.mit.edu tienen copias de este directorio.

_____________________________________________
10 NetBIOS es el protocolo en el que se basan las aplicaciones como lanmanager y Windows para Trabajo en Grupo.

En este libro, vamos a tratar principalmente los temas de instalación y configuración. Sin embargo la administración es mucho mas importante _ después de instalar un servicio, también hay que mantenerlo funcionando. Para la mayoría de ellos, solo se necesitara una pequeña atención, mientras que algunos, como el correo y las news, requieren realizar tareas rutinarias para mantener actualizado el sistema. Discutiremos estas tareas en los capítulos finales.

La tarea mínima de mantenimiento es comprobar regularmente el sistema y los ficheros de registro de cada aplicación buscando condiciones de error y eventos inusuales. Por lo general, es posible hacer esto escribiendo un par de scripts de shell y ejecutándolos periódicamente mediante el comando cron. La distribución fuente de algunas aplicaciones importantes como smail o C News, ya contiene esos scripts. Solo tendrá que retocarlos para adecuarlos a sus necesidades y preferencias.

La salida de cualquiera de sus trabajos del cron se debería enviar a una cuenta de administración. Por defecto, muchas aplicaciones enviaran informes, estadísticas de uso, o resúmenes del fichero de registro a la cuenta de root. Esto solo tiene sentido si accede como root frecuentemente; una idea mucho mejor es redirigir el correo del root a su cuenta personal estableciendo un alias de correo como se describe en el capítulo 14.

Por muy cuidadoso que sea configurando su máquina, la ley de Murphy garantiza que surgirá algún problema en cualquier momento. Por lo tanto, el mantenimiento de un sistema implica también estar disponible para quejas. Generalmente la gente espera que se pueda contactar con el administrador del sistema al menos por correo electrónico (como root), pero también hay otras direcciones que se usan con frecuencia para informar a la persona responsable de un aspecto concreto del mantenimiento. Por ejemplo, las quejas sobre una configuración de correo que funciona mal se dirigirán generalmente al postmaster (encargado del correo); y los problemas con el sistema de noticias pueden ser comunicados a newsmaster o usenet. El correo a hostmaster se debería redirigir a la persona encargada de los servicios básicos de red del nodo, y del servicio de nombres DNS si esta corriendo un servidor de nombres.

Otro aspecto muy importante de la administración de sistemas en un entorno de red es proteger al sistema y a sus usuarios de intrusos. Los sistemas administrados sin ningún cuidado ofrecen muchos huecos a los malintencionados: los ataques van desde averiguar las claves hasta acceder a nivel de Ethernet, y el daño causado puede ser desde mensajes de correo falsos hasta perdida de datos o violación de la privacidad de los usuarios. Mencionaremos algunos problemas concretos cuando discutamos el contexto en el que pueden ocurrir, y algunas defensas comunes contra ellos.

Esta sección comentara algunos ejemplos y técnicas básicas para pelearse con la seguridad del sistema. Por supuesto, los temas relatados no pueden tratar exhaustivamente todos los aspectos de seguridad con los que uno se puede encontrar; sirven meramente para ilustrar los problemas que pueden surgir. Por tanto, la lectura de un buen libro sobre seguridad es absolutamente obligada, especialmente en un sistema en red. "Practical UNIX Security" de Simon Garfinkel (véase [Spaf93]) es una de las lecturas recomendadas.

La seguridad del sistema comienza con una buena administración del mismo. Esto incluye comprobar la propiedad y permisos de todos los ficheros y directorios vitales, monitorizar el uso de cuentas privilegiadas, etc. El programa COPS, por ejemplo, comprobara su sistema de ficheros y ficheros de configuración comunes en busca de permisos inusuales u otras anomalías. También es conveniente usar un sistema de claves que fuerce ciertas reglas en las claves de los usuarios que las hagan difíciles de adivinar. El sistema de claves ocultas (shadow password), por ejemplo, requiere que una clave tenga al menos cinco letras, y contienen tanto mayúsculas como minúsculas y números.

Cuando un servicio se hace accesible a la red, asegúrese de darle el "menor privilegio", lo que quiere decir que no se permita hacer cosas que no son imprescindibles para que trabaje como se diseño. Por ejemplo, debería hacer sus programas con setuid root o alguna otra cuenta privilegiada solo si realmente lo necesitan. También, si quiere usar un servicio solo para una aplicación muy limitada, no dude en configurarla tan restrictivamente como su aplicación especial lo permita. Por ejemplo, si quiere permitir a maquinas sin disco arrancar desde su máquina, debe facilitar el TFTP (Trivial File Transfer Service) de modo que pueda obtener los ficheros de configuración básicos del directorio /boot. Sin embargo, cuando se usa sin restringir, TFTP permite a cualquier usuario de cualquier lugar del mundo leer cualquier fichero de su sistema. Si esto no es lo que desea, ¿por que no restringir el servicio TFTP al directorio /boot?11

Pensando en la misma línea, podría restringir ciertos servicios a usuarios que acceden desde ciertos nodos, digamos que solo para su red local. En el capítulo 9, presentaremos tcpd, que hace esto para una variedad de aplicaciones de red.

_____________________________________________
11 Volveremos sobre esto en el capítulo 9.

Otro punto importante es evitar software "peligroso". Claro que cualquier software que utilice puede ser peligroso, porque el software puede tener fallos que algunos listos pueden explotar para acceder a su sistema. Cosas como ésta ocurren, y no hay protección segura contra ello. Este problema afecta al software libre y a productos comerciales por igual. 12

Sin embargo, programas que requieren privilegio especial son inherentemente mas peligrosos que otros, ya que un agujero de estos puede tener consecuencias drásticas.13 Si instala un programa setuid con propósitos de red, sea doblemente cuidadoso y no deje de leerse toda la documentación, de modo que no cree una brecha en la seguridad por accidente.

Nunca olvide que sus precauciones pueden fallar, por muy cuidadoso que haya sido. Por eso debería asegurarse de que detecta pronto a los intrusos. Comprobar los ficheros de actividad es un buen comienzo, pero el intruso probablemente sea bastante listo, y borrará cualquier huella que haya dejado. Sin embargo, hay herramientas como tripwire14 que permite comprobar ficheros vitales del sistema para ver si sus contenidos o permisos han cambiado. tripwire realiza varios checksums15 fuertes sobre estos ficheros y los almacena en una base de datos. En las siguientes ejecuciones, se reevalúan y comparan los checksums con los almacenados para detectar cualquier modificación.

Los siguientes capítulos tendrán que ver con configurar Linux para redes TCP/IP, y con la ejecución de algunas aplicaciones importantes. Antes de que se manche las manos con la edición de ficheros y similares, examinaremos IP algo mas de cerca en el capítulo 2. Si ya sabe como funciona el encaminamiento IP, y como se realiza la resolución de direcciones, quizá desee saltarse este capítulo.

El capítulo 3 trata los aspectos mas básicos de configuración, como construir un kernel y configurar su tarjeta Ethernet. La configuración de los puertos serie se relata en un capítulo aparte, ya que la discusión no se aplica solo a redes TCP/IP, sino que también es relevante para UUCP.

El capítulo 5 le ayudara a configurar su máquina para redes TCP/IP. Contiene pasos de instalación para nodos aislados (solamente con enlace local), y nodos conectados a una Ethernet. También le presentara unas pocas herramientas útiles que puede utilizar para comprobar y retocar su configuración. El siguiente capítulo expone como configurar la resolución de nombres, y explica como montar un servidor de nombres.

_____________________________________________
12 Ha habido sistemas UNIX comerciales, por los que hay que pagar un montón de dinero, que venían con un script de shell con setuid-root que permitía a los usuarios obtener privilegios de root utilizando un conocido truco.
13 En 1988, el gusano RTM llevo a gran parte de Internet a un colapso, en parte por explotar un agujero que había en algunos programas sendmail. Este agujero ya ha sido reparado con creces.
14 Escrita por Gene Kim y Gene Spafford.
15 N. del T.: Sumas de bytes con objeto de comprobar alguna modificación no "autorizada" en el fichero.

Esto va seguido de dos capítulos que tratan de la configuración y uso de SLIP y PPP, respectivamente. El capítulo 7 explica como establecer conexiones SLIP, y da una referencia detallada de dip, una herramienta que le permite automatizar la mayoría de pasos necesarios.

El capítulo 8 cubre PPP y pppd, el demonio que se necesita para ello.

El capítulo 9 da una corta introducción a la instalación de las aplicaciones de red mas importantes, como rlogin, rcp, etc. Esto también abarca la gestión de los servicios por el inetd, y como puede restringir ciertos servicios de seguridad relevante a un grupo de nodos de confianza.

Los dos capítulos siguientes hablan de NIS, el sistema de información de red (Network Information System), y NFS, el sistema de ficheros de red (Network File System). NIS es una herramienta útil para distribuir información de administración, como las claves de usuario, en red de área local. NFS le permite compartir sistemas de ficheros entre varios nodos de su red.

El capítulo 12 le dará una amplia introducción a la administración del UUCP de Taylor, una implementación gratis del paquete UUCP.

El resto del libro será un viaje guiado por temas como el correo electrónico y las Noticias de Usenet. El capítulo 13 le conduce a los conceptos centrales del correo electrónico, como que aspecto tiene una dirección de correo, y como se las arregla el sistema de manejo de correo para llevar su mensaje hasta el destinatario.

Los capítulos 14 y 15 cubren respectivamente la puesta en marcha de smail y sendmail, dos agentes de transporte de correo que puede utilizar en Linux. Este libro explica ambos, ya que smail es mas fácil de instalar para un principiante, mientras que sendmail es más flexible.

Los capítulos 16 y 17 explican la forma en que se manejan las noticias en Usenet, y como instalar y usar C News, un paquete de software popular para la gestión de las noticias de Usenet. El capítulo 18 trata brevemente de como instalar un demonio NNTP para ofrecer el acceso a lectura de noticias para su red local. El capítulo 19 muestra finalmente como configurar y mantener varios lectores de noticias.