4 LINUX EN RED
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. Supongamos 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. ¿Cuáles son las opciones de A?
Podría...
1) Ir a la choza de B.
2) Hacerse con un tambor más grande.
3) Pedirle a C, que vive a mitad camino entre los dos, que retransmita el mensaje.
La última opción es lo que se llama una red.
Así pues, definimos una red como un conjunto de nodos
que son capaces de comunicarse entre si, a menudo contando con los servicios
de varios nodos especializados que conmutan datos entre 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 llamadas instalaciones (del inglés
site).
La comunicación sería imposible sin algún tipo de lenguaje o
código. En las redes de ordenadores, estos lenguajes son los llamados
colectivamente protocolos. Sin embargo, no se debe 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 son normas
muy estrictas para el intercambio de mensajes entre dos o más nodos.
Por otra parte, cuando hablamos de redes de ordenadores, a
menudo significa hablar de Linux. Linux es un sistema operativo bajo el cual,
la tecnología de internet nació.La capacidad de Linux es la misma que pueda
tener cualquier sistema de UNIX. Debido a que la tecnología de internet nació
en UNIX, otros sistemas operativos están a años luz de lo que UNIX puede
ofrecer. Este sistema operativo no es el único con capacidad de red, pero si
está considerado como uno de los mejores. Ha habido sistemas operativos tipo
UNIX gratuitos para PC, como 386BSD, FreeBSD y Linux. Linux es un sistema
operativo que lucha por ofrecer toda la funcionalidad que requieren los
estándares POSIX, para sistemas operativos tipo UNIX, aunque es una
reimplementación completa, desde cero.
Linux está cubierto por la Licencia Pública General (GPL)
GNU, que permite la libre distribución del código. Superando sus males de
joven, y atraído por una siempre creciente base de programas de aplicación
gratuitos, se está convirtiendo rápidamente en el sistema operativo de
elección de muchos usuarios de PC, favorecido en gran parte por una fuerte
circulación de dicho código libre a través de Internet.
UUCP es una abreviatura de Unix-to-Unix Copy. 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 70, pero aún es bastante espartano en los servicios que ofrece.
Su principal aplicación es todavía en redes de área metropolitanas (WAN)
basadas en los 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 más 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. Hoy día
UUCP ya no está destinado exclusivamente para el entorno UNIX. Hay versiones disponibles para
diversas plataformas.
Una de las principales desventajas de las redes UUCP es su
bajo ancho de banda. Por un lado, el equipo telefónico establece un límite
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
si 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.
La idea que hay detrás de UUCP es bastante simple: como su
nombre indica, basicamente copia ficheros de un nodo a otro, pero también
permite realizar ciertas acciones en el nodo remoto.
Supongamos que nos está permitido que nuestra máquina acceda
a un nodo hipotético llamado swim, y le vamos a hacer ejecutar el
comando de impresión lpr para nosotros. Entonces, podríamos escribir lo
siguiente en nuestra línea de comandos para que nos imprima este documento en
swim:
$ uux -r swim!lpr !RedesLinux.txt
Esto hace que uux, un comando del repertorio UUCP,
planifique un trabajo para swim. Este trabajo consta del fichero
de entrada, RedesLinux.txt, 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 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 número de aplicaciones UNIX. Para
transferir el fichero tripware-1.0.tar.gz hasta nuestra máquina
deberíamos indicarlo así:
$ uucp -mr
swim!groucho!~/security/tripware-1.0.tar.gz trip.tgz
El trabajo creado pedirá a swim que traiga el fichero
desde groucho, y lo envie hasta nuestra máquina, donde UUCP lo
almacenará en trip.tgz y nos notificará por correo la llegada del
fichero. Esto ocurrirá en tres pasos. Primero, nuestra máquina envía el
fichero 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 nuestra
máquina.
Actualmente, los servicios más importantes que proporcionan
las redes UUCP son el correo electrónico y las noticias, aunque también es el
medio elegido por muchos servidores de ficheros que ofrecen servicio público.
Generalmente podremos 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.
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 Área Local (LANs). Estas redes están compuestas
generalmente por un pequeño número de máquinas 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, nodos, o ejecutar aplicaciones distribuidas en diferentes
máquinas.
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 se llaman 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
UNIX) es conocida como TCP/IP.
El TCP/IP tiene sus orígenes en un proyecto de investigación
fundado en Estados Unidos por DARPA (Defense Advanced Research Projects Agency
- Agencia de Proyectos Avanzados de Investigación en Defensa) en 1969.
Ésta fue una red experimental, la red ARPANET, que pasó 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.
Tomaremos como ejemplo una red típica: la de una universidad,
concretamente la hipotética Universidad Groucho Marx (GMU). 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, siendo su nombre erdos, que intenta conectar
con un nodo del Departamento de Físicas, por ejemplo quark.
En línea de comandos, introduciremos nuestro nombre de
acceso y nuestra clave. Entonces dispondremos
de una shell de quark, sobre la que podemos escribir como si
estuvieramos sentados en la consola del sistema. Tras salir del shell
volveremos a tener la línea de comandos de nuestra propia máquina. Acabamos de
utilizar una de las aplicaciones de interactividad instantánea que proporciona
TCP/IP: el acceso remoto.
Mientras estemos conectados a quark, podríamos también
desear ejecutar una aplicación X. Para ello, si ponemos en marcha ahora nuestra aplicación, esta
contactará con nuestro servidor X en lugar de quark, y mostrará todas
las ventanas en nuestro munitor. Por supuesto, esto requiere que estemos
ejecutando X11 en erdos. La clave está en que TCP/IP permite a
quark y a erdos enviarse paquetes X11 en ambos sentidos para
darnos la impresión de que estamos 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 transparente la red, porque básicamente permite montar jerarquías de
directorios de otras máquinas, 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 máquinas 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 en disco en una única máquina, y exportar estos
directorios a otras máquinas.
Por supuesto, esto son sólo ejemplos de lo que se puede hacer
en un entorno de redes TCP/IP: las posibilidades son casi ilimitadas.
El tipo de hardware más utilizado en LANs es lo que
comunmente 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, variando en el grosor y el modo de conectar
este cable a los nodos. El Ethernet fino emplea conectores "BCN" 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 se realice un pequeño
agujero en el cable, y conecte un transceptor utilizando un "nodo vampiro".
Entonces se puede 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. Es
por ello que para instalaciones de gran escala es más apropiado el Ethernet
grueso.
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 si utilizando
repetidores, puentes o encaminadores (repeaters, bridges y
routers, respectivamente). 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 más de cuatro repetidores entre cualquier par de nodos de la red.
Los puentes y encaminadores son más sofisticados, analizan los datos de
entrada y los reenvían sólo si el nodo no está 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 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.
Una trama enviada por una estación la ven todas las
estaciones conectadas, pero sólo el nodo destinatario la toma y 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 está 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 número de testigos, de
modo que una estación sólo 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 Públicas de Datos 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), éstos deben ser encapsulados en paquetes X.25 y enviados a
través de la red.
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.
En instalaciones grandes como la Universidad 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
máquinas rápidas para profesores y graduados, y otra con máquinas más 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 (Figura 5), que maneja los paquetes entrantes y
salientes copiándolos entre las dos Ethernets y el cable de fibra óptica. Por
ejemplo, si nos encontramos en el Departamento de Matemáticas, y queremos
acceder a quark situada en la LAN del Departamento de Físicas desde
nuestra máquina Linux, el software de red no puede mandar paquetes a
quark directamente, porque no está en la misma Ethernet. Por tanto,
tenemos que confiar en la pasarela para que actúe como retransmisor. La
pasarela (llamemosla sophus) reenvía entonces estos paquetes a su
pasarela homóloga niels del Departamento de Físicas, usando la troncal,
y por fin niels los entrega a la máquina destino.
Figura 5 - Esquema de red con pasarelas
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 está gobernado por un único protocolo que es independiente del
hardware utilizado: IP.
El principal beneficio del IP es que conviene 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. Observese aqui 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
145.76.12.4. A este formato se le llama notación de puntos.
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
escribamos 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 Departmento de
Físicas, de algún modo tiene que encontrar a qué dirección Ethernet
corresponde la dirección IP. Lo cual no resuta trivial.
Estos pasos para encontrar las direcciones IP 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 lineas serie se usa frecuentemente el estandar "de
facto" conocido como SLIP o Serial Line IP (IP sobre linea serie). Una
modificacion del SLIP es el CSLIP, o SLIP Comprimido, que realiza compresion
de las cabeceras IP para aprovechar el bajo ancho de banda que proporcionan
los enlaces serie. Un protocolo serie distinto es el PPP, o Point-to-Point
Protocol (Protocolo Punto a Punto). PPP dispone de muchas mas caracteristicas
que SLIP, incluyendo una fase de negociacion del enlace. Su principal ventaja
sobre SLIP es, sin embargo, que no se limita a transportar datagramas IP, sino
que se diseñó para permitir la transmision de cualquier tipo de datagramas.
Pero la historia no se acaba con el envio de datagramas de un
nodo a otro. Si deseamos acceder a quark, necesitamos disponer de una
conexion fiable entre su proceso rlogin en erdos y el proceso de shell en
quark. Para ello, la informacion 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. Supongamos que diez personas de nuestro Ethernet comienzan a
transferirse la última versión de XFree86 del servidor de FTP de GMU. La
cantidad de tráfico 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 enviamos un paquete a quark, sophus podría tener agotado
el espacio del buffer durante un instante y por tanto no sería 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 retransmision
en caso de error.
De esto se encarga otro protocolo, TCP, o Transmission
Control Protocol (Protocolo de Control de la Transmision), que construye
un servicio fiable por encima de IP. La propiedad esencial de TCP es que usa
IP para darnos la impresion de una conexión simple entre los procesos en
nuestro equipo y la máquina remota, de modo que tenemos que preocuparnos de
como y sobre que ruta viajan realmente nuestros datos. Una conexión TCP
funciona basicamente como una tubería de doble sentido en la que ambos
procesos pueden escribir y leer; podemos imaginarla como una conversacion
telefonica.
TCP identifica los extremos de tal conexión por las
direcciones IP de los dos nodos implicados, y el número 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 más,
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).
Mediante 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 está 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 escribamos a rlogin en nuestra
máquina será pasado a traves del canal TCP y entregado a la shell como entrada
estandar.
El protocolo de mensajes de control de Internet o ICMP, lo
usa el software de gestión de red para comunicar mensajes de error entre
nodos. Por ejemplo, si estamos en la maquina erdos y hacemos un
telnet al puerto 12345 del nodo quark y no hay procesos
escuchando en ese puerto, recibirá un mensaje ICMP de "puerto inalcanzable".
Hay mas mensajes ICMP, muchos de ellos referidos a
condiciones de error. Sin embargo, hay uno interesante que es el de
redirección. Lo genera el módulo de encaminamiento al detectar que otro nodo
está usándolo como pasarela, a pesar de existir una ruta mucho más corta. Por
ejemplo, tras configurarse la tabla de encaminamiento de sophus, esta
puede estar incompleta, conteniendo rutas a través del encaminador por defecto
gcc1. Por lo tanto, los paquetes enviados inicialmente a quark
irán por gcc1 en lugar de niels. En este caso gcc1
notificará a sophus que está usando una ruta costosa y reenviará el
datagrama a niels, al mismo tiempo que devolverá un mensaje ICMP de
redirección a sophus informándole de la nueva ruta.
Pero aprece un nuevo problema, pues la redirección de ICMP y
el protocolo RIP no incluyen mecanismos de verificación de la autenticidad de
los mensajes. Esto permite a los piratas corromper el tráfico de la red
mediante mensajes ICMP. Por ello, algunas versiones del código de Linux tratan
los mensajes de redirección que afectan a rutas de red como si fueran
redirecciones de rutas a nodos.
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 Sockets 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 para especificar un nodo remoto, un protocolo de
transporte, y un servicio al que un programa pueda conectarse o escuchar
(usando connect, listen, y accept). La librería de
sockets, sin embargo, es algo más general, ya que proporciona no sólo 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.
En Linux, la librería de sockets es parte de la librería C
estándar libc. Actualmente 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 más 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 pública 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, cambió 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 tráfico 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) esta empezando a tener
gran auge. 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 con
gran éxito es samba, un servidor de NetBIOS gratis para Unix, escrito
por Andrew Tridgell.
Otra implementación más de red TCP/IP es la realizada por
Matthias Urlichs, quien escribió un controlador de RDSI para Linux y FreeBSD.
Para ello, integró algo del código de red de BSD en el kernel de Linux.
Sin embargo, Net-3 acabaría por llegar para quedarse (aunque en la ctualidad se
está sustituyendo por Net-4). Alan es también el autor de una implementación
del protocolo AX.25 usado por radioaficionados.
Sin duda, la modularización, aun desarrollándose para el
kernel, traerá también nuevos impulsos al código de red. Los módulos nos
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 podremos configurar un sistema con un kernel
Net-2e con utilidades de Net-2d o Net-3, y viceversa. Esto sólo 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.
Un 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.
La seguridad del sistema comienza con una buena
administracion del mismo. Esto incluye comprobar la propiedad y permisos de
todos los ficheros y directorios vitales, monitorizar el uso de cuentas
privilegiadas, etc. 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.
El direccionamiento en TCP/IP se basa
en numeros de 32 bits. Esos números no son fáciles de recordar, mientras que
sí lo es el nombre que se le asigna a cada máquina, como gauss o
strange. Existe una aplicación que es capaz de traducir nombres a
direcciones IP, y es conocida como sistema de resolucion de nombres o DNS.
Una aplicación que desee encontrar la dirección IP
correspondiente a una máquina de la que conoce su nombre, no tiene que incluir
rutinas para ello, ya que en las librerías estándares (libc) existen ya
rutinas preparadas, como gethostbyname o gethostbyaddr.
En otros sistemas se encuentran en otras librerías distintas
de la libc pero esto no sucede en Linux. Al conjunto de rutinas que hacen
estas tareas se les conoce como "sistema de resolución".
En una red pequeña no es difícil mantener una tabla
/etc/hosts en cada máquina, y modificarla al agregar, eliminar o
modificar nodos. Pero resulta complicado cuando hay muchas máquinas ya que, en
principio, cada una necesita una copia de /etc/hosts.
Una solución a esto es compartir esta y otras bases de datos
con el NIS, o Sistema de Informacion de Red, desarrollado por Sun
Microsystems y conocido también como páginas amarillas. En este caso,
las bases de datos como la de /etc/hosts se mantienen en un servidor
NIS central y los clientes accederán a ellas de forma transparente al usuario.
En todo caso, esta solución sólo es aconsejable para redes pequeñas o
medianas, ya que implican mantener un fichero central /etc/hosts que
puede crecer mucho, y luego distribuirlo entre los servidores NIS.
En Internet, se comenzo almacenando la informacion en un
fichero similar al hosts, mantenido por el NIC, y obtenido regularmente
por los demas servidores. Cuando la red creció comenzaron los problemas de
sobrecarga de servidores, ademas de que el NIC tenía que ocuparse de todos los
nombres de los nodos de Internet, y evitar la duplicidad de los mismos.
Por esto, en 1984 se diseñó y adoptó oficialmente un nuevo
sistema, el DNS o sistema de nombres por dominios, diseñado por Paul
Mockapetris.
DNS organiza los nombres de los nodos en una jerarquía de
dominios. Un dominio es una colección de nodos relacionados de alguna manera,
como estar en la misma red o pertenecer a una misma organizacion o pais. Por
ejemplo, las universidades norteamericanas se agrupan en el dominio edu, y
cada universidad mantiene un subdominio dentro de edu. Nuestro ejemplo, la
Universidad de Groucho Marx, mantendría el dominio gmu.edu y las
máquinas del Departamento de Matematicas se encontrarían dentro del dominio
maths.gmu.edu. De este modo el nombre completo de la máquina
erdos será erdos.maths.gmu.edu. El nombre completo se conoce
como nombre totalmente cualificado o FQDN, e identifica a ese nodo en todo el
mundo.
Figura 6 - Organización de dominios
Aquí se muestra una sección del espacio de dominios. La
entrada de la raíz del árbol, que se indica con un punto rojo, se puede denominar
dominio raíz, y agrupa al resto de los dominios. Para indicar que un nodo se
expresa en notación FQDN, se puede terminar el nombre en un punto, indicando
así que el nombre incluye al del dominio raíz. (Figura 6)
Dependiendo de su localización en la jerarquía, un dominio
puede ser de primer, segundo o tercer nivel. Pueden existir otros niveles pero
no son frecuentes. Por ejemplo, algunos dominios de primer nivel muy usuales
son los siguientes:
- edu
- Aquí se incluyen casi todas las universidades o centros de investigación
norteamericanos.
- com
- Compañías u organizaciones con fines comerciales.
- org
- Organizaciones no comerciales. Las redes UUCP privadas se encuentran
aquí.
- net
- Pasarelas y otros nodos administrativos de la red.
- mil
- Nodos militares norteamericanos.
- gov
- Nodos del gobierno norteamericano.
- uucp
- Oficialmente, todos los nombres de nodos UUCP sin dominio han sido
movidos a este nuevo dominio, .uucp.
En general, los dominios anteriores pertenecen a redes
norteamericanas. Algo especialmente cierto con los dominios mil o gov.
Fuera de los Estados Unidos, existe un dominio de primer
nivel para cada país, de dos letras segun se define en la norma ISO-3166.
Finlandia, por ejemplo, usa el dominio fi; el dominio de
corresponde a Alemania y el dominio es corresponde a España. Cada país
organiza por debajo del primer nivel, los dominios de segundo nivel, de manera
parecida a los americanos en algunos casos (por ejemplo, con dominios
com.au o edu.au) o directamente por organizaciones, como sucede
en España (con dominios como uji.es para la "Universitat Jaume I").
Por supuesto, un nodo dentro del dominio de un país puede no
estar fisicamente en él. El dominio únicamente identifica al nodo como
registrado en el NIC de ese país. Así, un comerciante español puede tener una
delegacion en Australia, y tener sus nodos australianos registrados dentro del
dominio de primer nivel español, es.
Esta organización por dominios soluciona el problema de la
unicidad de nombres. Además, los nombres totalmente cualificados no son
díficiles de recordar.
Pero DNS tiene otras ventajas: permite delegar la autoridad
sobre un determinado subdominio a sus administradores. Por ejemplo, los
subdominios maths y physics de la UGM son creados y mantenidos
por el Centro de Calculo de dicha universidad. Y si el mantenimiento del
subdominio maths.gmu.edu fuese complicado (por número elevado de nodos,
existencia de subdominios internos, etc), el Centro de Calculo de la UGM puede
delegar la autoridad sobre ese subdominio al departamento de Matemáticas. La
delegación de un subdominio implica el control total del mismo por parte de la
organización en la que se delegó, con total libertad para crear nuevos
subdominios internos, asociar nombres a nodos, etc.
Para este fin, el espacio de nombres se divide en zonas, cada
una asociada a un dominio. Notese que existe una diferencia entre zona y
dominio: el dominio groucho.edu incluye todos los nodos de la UGM,
mientras que la zona groucho.edu incluye sólo los nodos que mantiene
directamente el Centro de Cálculo, ya que los nodos del subdominio
physics.groucho.edu pertenecen a la zona controlada por el Departamento
de Físicas. En la imagen anterior marcamos el inicio de una zona con un
pequeño circulo a la derecha del nombre del dominio.
Este apartado de redes está extraido del libro "Linux Network Administrator Guide" [Kirch99], donde se hace una detallada exposición del funcionamiento y configuración de las redes bajo entorno Linux. Aunque la versión original es en inglés es posible encontrar en Internet una traducción al castellano.