Debe introducir al menos 3 caracteres en el buscador.
Inicio / Wikis / Tutoriales / Guía de Administración de Redes con Linux - Redes TCP/IP

Guía de Administración de Redes con Linux - Redes TCP/IP

 ****- (23 opiniones)
GNU Free Documentation License Tutorial de Olaf Kirch y Terry Dawson - 14 de Febrero de 2006
Temas Relacionados: Administración de redes
11. Redes TCP/IP

Las aplicaciones modernas para trabajo en redes requieren de un sofisticado método de transporte desde una máquina a otra. Si usted administra una máquina GNU/Linux que posea muchos usuarios, los cuales desean estar conectados simultáneamente a un servidor remoto o a una red, necesitará un modo de acceso para que puedan compartir la conexión a la red, sin que las acciones de cada uno interfieran con las de los demás. La estrategia que un gran número de protocolos de red utilizan hoy día se llama conmutación de paquetes, (packet-switching). Un paquete es nada más que un pequeño trozo de datos que se transfiere de una máquina a otra a través de una red. Esta transferencia ocurre a medida que el datagrama es transmitido a través de cada enlace en la red. Una red de conmutación de paquetes comparte un único enlace con muchos usuarios, enviando los paquetes alternadamente, desde un usuario a otro, a través de ese enlace.

La solución que muchos sistemas Unix, (y posteriormente muchas otras plataformas), han adoptado, se conoce como TCP/IP. Cuando se habla de redes TCP/IP, siempre estará presente el término datagrama. Técnicamente, este término tiene un significado especial, pero es a menudo usado de forma intercambiable con paquete. En la siguiente sección, se echará un vistazo a los conceptos fundamentales de los protocolos TCP/IP.

Introducción a las Redes TCP/IP

El origen del protocolo TCP/IP, se debe a un proyecto de investigación, financiado por la DARPA, (Defense Advanced Research Projects Agency, o Agencia de Proyectos Avanzados de Investigación en Defensa), en 1969. La ARPANET, fue una red experimental que se convirtió en funcional a mediados de 1975, tras haber sido admitida su funcionalidad.

En 1983, el nuevo conjunto de protocolos TCP/IP, fue adoptado como estándar y todas las máquinas de la red tuvieron la necesidad de él. Cuando, finalmente, ARPANET creció y se convirtió en Internet, (integrándose luego ella misma a Internet, en 1990), el uso de TCP/IP se propagó incluso a redes ajenas a ella. Ahora, muchas compañías empresariales construyen redes TCP/IP, e Internet ha crecido hasta tal punto, que se la puede considerar como la corriente principal de consumo tecnológico. Actualmente, es difícil leer un periódico sin ver referencias sobre Internet; casi todo el mundo ya puede usarla.

Para apreciar algo palpable sobre lo que hemos discutido anteriormente, supongamos como ejemplo, la Universidad Groucho Marx, (GMU), la cual se encuentra en algún lugar de Federilandia. La mayoría de las divisiones de la universidad tienen su propia red local, mientras que algunas comparten una sola y otras poseen muchas de ellas. Todas se encuentran interconectadas, y están enlazadas a Internet por un simple enlace de alta velocidad.

Supóngase que se tiene una máquina GNU/Linux conectada a una LAN de servidores Unix en la división de Matemáticas, y su nombre es erdos. Para acceder a un servidor que se encuentra en la división de Física, cuyo nombre es, por ejemplo quark, se deberá introducir la siguiente orden:

$ rlogin quark.physics Welcome to the Physics Department at GMU (ttyq2) login:

Ante este indicador se podrá introducir un nombre de usuario, por ejemplo sebastian, y una contraseña. Luego, si todo es correcto, nos encontraremos frente a un intérprete de órdenes (shell)[1] de quark, en la cual, se podrá escribir como si se estuviera sentado frente a la misma consola del sistema. Tras salir del intérprete, se nos presentará nuevamente el antiguo indicador de órdenes de nuestra máquina. Se ha usado aquí, tan sólo una de las muchas aplicaciones instantáneas e interactivas que TCP/IP proporciona: remote login (registro remoto).

Mientras se trabaja en quark, puede que se desee ejecutar una aplicación de interfaz gráfica, como por ejemplo un procesador de textos, un programa de diseño gráfico, o hasta un navegador de Internet. El sistema de ventanas X es un entorno gráfico para el usuario, totalmente funcional bajo redes y está disponible para muchos tipos de sistemas informáticos. Para hacerle saber a la aplicación que se desea tener interfaz gráfica en la pantalla de nuestro nodo, se necesitará determinar la variable de entorno DISPLAY:

$ DISPLAY=erdos.maths:0.0 $ export DISPLAY

Si ahora se ejecuta la aplicación gráfica, ésta se comunicará con el servidor X de nuestro nodo en lugar de hacerlo con el de quark, y como consecuencia las ventanas aparecerán en nuestra la pantalla y no en la de nuestro servidor. Por supuesto, esto requiere que se esté ejecutando X11 en erdos. Lo más importante aquí es que TCP/IP permite el envío y reenvío de paquetes X11 entre quark y erdos, haciendo que el usuario tenga la ilusión de que trabaja en una única máquina. Trabajando de este modo, la red será bastante transparente.

Otra aplicación muy importante en una red TCP/IP es NFS, que significa Network File System (Sistema de Ficheros de Redes). Es otra forma de hacer de la red un sistema transparente, ya que, básicamente, permite al usuario trabajar con los ficheros y directorios de otros nodos como si fueran locales. Por ejemplo, todos los directorios \home de cada usuario pueden alojarse en un servidor central. Desde éste, los demás nodos de la LAN pueden montarlos cuando sea necesario. El resultado es que los usuarios pueden registrarse en el sistema y encontrarse siempre en el mismo directorio \home. De modo similar, es posible compartir grandes cantidades de datos, (como una base de datos, documentación o programas ejecutables), entre muchos nodos, almacenando físicamente una sola copia de dichos datos en un servidor, y permitiendo a los nodos en cuestión acceso a él. Se volverá a hablar de NFS en Capítulo 14.

Por supuesto, estos son sólo ejemplos de lo que se puede hacer en redes TCP/IP. Las posibilidades son casi infinitas, y el lector irá conociéndolas a medida que avance en el libro.

En las siguientes secciones, se estudiará más detenidamente, de qué manera funciona una red TCP/IP. Esta información ayudará a entender cómo y por qué se debe configurar una máquina. Se empezará examinando el hardware, y desde allí con las demás cuestiones.

Ethernets

El tipo de hardware más utilizado en LANs es lo que comúnmente conocemos como Ethernet. Descrito de una forma simple, consta de un solo cable con los nodos unidos a él a través de conectores, clavijas o transceptores. Los adaptadores Ethernet simples, son relativamente baratos de instalar, lo que unido a un flujo de transferencia neto de 10, 100 o hasta 1,000 Mega bits por segundo, avala gran parte de su popularidad.

Las redes Ethernet se pueden clasificar en tres tipos atendiendo al grosor del cable: gruesos,finos, y de par trenzado. Los dos primeros pueden usar cable coaxial, diferiendo en el grosor y el modo de conectar este cable a los nodos. El cable 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 cable Ethernet grueso requiere que se realice un pequeño agujero en el cable, y se conecte un transceptor utilizando un “conector vampiro” Luego, se podrán 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. La palabra “base” hace referencia a “modulación de banda base” y significa, simplemente, que los datos que alimentan al cable, fluyen directamente sin pasar por un módem. El número que se encuentra delante de la palabra alude a la velocidad de transmisión, en Mega bits por segundo, mientras que el número al final indica la máxima longitud que se le puede dar al cable, en cientos de metros. El par trenzado usa un cable hecho de dos hilos de cobre. Por lo común necesitan, además, hardware adicional que se conoce como Núcleo Activo. A este Ethernet se le conoce también como 10base-T, en donde “T” significa de par trenzado. Los pares trenzados con velocidad de 100 Mega bits por segundo son conocidos como 100base-T.

Para agregar un nodo a una instalación Ethernet fina se deberá suspender el servicio de la red por al menos unos minutos, ya que se deberá cortar el cable para insertar un conector. A pesar de que, por otro lado, agregar un nodo a un sistema Ethernet grueso es un poco complicado no hará, por lo general, que el servicio de la red se interrumpa. Un Ethernet de par trenzado es aún más simple. Usa un dispositivo denominado “hub,” que trabaja como un punto de interconexión. Se pueden insertar y quitar nodos de un núcleo sin interrumpir en absoluto, a ninguno de los demás usuarios.

La mayoría de gente prefiere el Ethernet fino porque es barato: las tarjetas de PC pueden encontrarse por unos 30$ americanos (algunas compañías están literalmente, regalándolas), y el cable por pocos centavos el metro. Sin embargo, para instalaciones de gran escala, son más apropiados el Ethernet grueso o el de par trenzado. Por ejemplo, en un principio, el Departamento de Matemáticas de la GMU decidió utilizar el cableado Ethernet grueso, ya que el gran tráfico que posee toda la red a lo largo de su gran recorrido, no se interrumpe cada vez que se añade un nodo. Actualmente, son muy comunes los cables Ethernet de par trenzado en una gran variedad de instalaciones. Los “hubs” son ahora más accesibles, y pequeñas unidades están disponibles a precios que son atractivos, incluso para pequeñas redes domésticas. El cable de par trenzado puede ser significativamente más barato para grandes instalaciones. Además, el mismo cable de par trenzado es mucho más flexible que los coaxiales usados por otros sistemas Ethernet. Los administradores de la red en la división de matemáticas de GMU, están planeando reemplazar su sistema por uno de par trenzado el año que viene, ya que, además de ahorrar tiempo a la hora de agregar nuevos nodos, y cambiar de lugar los viejos, también podrán ponerse al día con la tecnología actual.

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 red Ethernet entre sí utilizando repetidores, puentes o encaminadores[2]. 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 tiempo, no puede haber mas 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 receptor no está en la Ethernet local.

Ethernet funciona como un sistema de bus, donde un nodo puede mandar paquetes (o marcos) de hasta 1500 bytes a otro nodo de la misma Ethernet. A cada nodo se le asigna una dirección de seis bytes grabada en el firmware (memoria fija) 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 por ejemplo aa:bb:cc:dd:ee:ff.

Una trama enviada por una estación es vista por todas las demás estaciones conectadas, pero sólo el nodo destinatario la toma y la procesa. Si dos estaciones intentan emitir al mismo tiempo, se produce lo que se llama una colisión. Una colisión en un complejo Ethernet, es detectada electrónicamente por las tarjetas de interfaz. Se resuelve por parte de las dos estaciones abortando el envío, y reintentándolo al cabo de un intervalo de tiempo tomado al azar. Seguramente se han escuchado muchas historias que afirmen que las colisiones en un Ethernet son un problema, y que la verdadera tasa de transmisión de datos en un Ethernet, sólo ocupa un 30 por ciento del ancho de banda disponible debido a ellas. La verdad es que las colisiones en un sistema Ethernet son un fenómeno natural. Es más, en un sistema muy activo, no se debería sorprender al ver que las colisiones tienen un índice mayor al 30 por ciento. En la práctica, el administrador de una red Ethernet sólo debería preocuparse cuando la tasa de transmisión se vea limitada a aproximadamente un 60 por ciento del ancho de banda.[3]

Otro Tipo de Hardware

En instalaciones mayores, como la Universidad de Groucho Marx, Ethernet no es el único tipo de red que puede utilizarse. Hay muchos otros tipos de protocolos disponibles y usados en la actualidad, y cada uno de ellos son soportados por GNU/Linux. A continuación se hará una descripción de otros protocolos usados, aunque será algo breve debido a las restricciónes en el tamaño de este documento. La mayoría de estos protocolos poseen documentos HOWTO que los describen en detalle. Es por esto que se debería leerlos si se está interesado en explorar aquellos protocolos que no se describen aquí.

En la Universidad de Groucho Marx cada LAN de un departamento está enlazada a la ”espina dorsal” de la red del campus. Ésta está formada por 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 símbolos, de modo que una estación sólo pueda enviar una trama si captura un símbolo. La principal ventaja de FDDI es la reducción de colisiones. Como consecuencia, el paso de datos puede utilizar en mayor proporción el ancho de banda, lo que permite una velocidad de hasta 100 Mbps. Otro beneficio de FDDI es que, al utilizar fibra óptica, la máxima longitud del cable sea mucho mayor a la que ofrecen las tecnologías basadas en cables, como Ethernet. La máxima longitud de cable usando FDDI oscila en los 200 km, lo que hace que esta tecnología sea ideal para unir las máquinas que se encuentren en distintos edificios de una ciudad. En el caso de nuestra universidad, FDDI une a los diferentes edificios en un campus.

De modo similar, si se tratase de equipos IBM, sería muy común el ver una red IBM de Token Ring. Esta tecnología es usada, en algunos entornos LAN, como alternativa a Ethernet. La ventaja esencial es que, como FDDI, en términos de utilización de la banda, se reducen las colisiones, aunque a velocidades inferiores (de 4 a 16Mbps). Su coste es menor que el de FDDI, ya que utiliza cables en lugar de fibra óptica. En un sistema GNU/Linux una red basada en Token Ring se configura casi de la misma manera que una red Ethernet, por lo que no se cubrirá, en el libro este procedimiento específicamente.

A pesar de que otras tecnologías para LAN soportadas por GNU/Linux, como por ejemplo ArcNet o DECNet, pueden ser instaladas, no se describirán aquí. Esto es debido, principalmente a que son muy poco usadas en la actualidad.

Muchas redes nacionales, operadas por compañías de Telecomunicaciónes, soportan otros protocolos basados en la conmutación de paquetes. Probablemente, el más popular de estos es un estándar llamado X.25. Muchas Redes de Datos Públicos, como por ejemplo Tymnet en EEUU, Austpac en Australia, y Datex-P en Alemania, ofrecen este servicio. X.25 define una conjunto de protocolos que describen cómo una terminal de datos se comunicará con otros equipos de transmisión, (o sea, un interruptor X.25). X.25 requiere un enlace de datos síncrono y, por consiguiente, un puerto síncrono especial en el hardware. Se puede usar X.25 en un puerto serie normal, con ayuda de un dispositivo especial llamado PAD, (Packet Assembler Disassembler). El PAD hace que el puerto en serie trabaje de modo síncrono o asíncrono, según sean las condiciones de la tarea. El dispositivo entiende el protocolo X.25 de un modo tal, que las simples terminales pueden efectuar y/o aceptar conexiones vía X.25.

X.25 también es usado para transportar otros protocolos de redes, como TCP/IP. Dado que los datagramas IP no pueden ser fácilmente asignados a X.25, (o recíprocamente), son encapsulados en paquetes X.25, y transmitidos por la red. Existe una implementación experimental del protocolo X.25 disponible para GNU/Linux.

Un protocolo más reciente ofrecido por compañías de telecomunicaciónes es el denominado Conmutación de Tramas, (Frame Relay). Este protocolo tiene características técnicas similares a las del X.25, aunque su comportamiento es mucho más parecido al IP. Al igual que el protocolo X.25, el de Conmutación de Tramas requiere un tipo de hardware síncrono especial. Debido a la similitud que existe entre estos dos protocolos, muchas tarjetas soportan ambos. Existe una alternativa, la cual no requiere de hardware interno y que consiste en un componente externo de hardware, denominado Dispositivo de Acceso a Conmutación de Tramas, (FRAD)[4], el cual administra la encapsulación de los paquetes Ethernet en paquetes de Conmutación de Tramas para ser transmitidos a través de la red. El protocolo de Conmutación de Tramas es ideal para transportar al TCP/IP de un sitio a otro. GNU/Linux provee de controladores que soportan algunos tipos de dispositivos internos para el protocolo de Conmutación de Tramas.

Si se necesita trabajar en una red de alta velocidad, la cual sea capaz de transportar muchos tipos de datos, como por ejemplo sonido o vídeo digitalizado, al mismo tiempo que los datos usuales, ATM (Modo de Transferencia Asíncrona)[5] es, con seguridad, lo que se está buscando. ATM es una nueva tecnología de redes, la cual fue específicamente desarrollada para suministrar control sobre la Calidad del Servicio (Quality of Service, Q.S, en inglés). Muchas compañías de telecomunicaciones han destacado la infraestructura de la tecnología ATM, ya que permite integrar diferentes tipos de servicios en una sola plataforma, todo esto aspirando al ahorro en cuanto a la administración y a los costos de mantenimiento. También ATM se usa para transportar al protocolo TCP/IP. En el documento Networking-HOWTO se puede encontrar información sobre el soporte brindado por GNU/Linux para ATM.

A menudo, los radio-aficionados usan sus propios equipos de radio para conectar sus ordenadores en red; comúnmente, a esto se le llama radio paquetes (packet radio). Uno de los protocolos usados por los operadores radio-aficionados es llamado AX.25, que deriva del X.25. También, los operadores radio-aficionados usan al AX.25 para transmitir otros protocolos, como por ejemplo el TCP/IP. AX.25, al igual que X.25, requiere de hardware especial que le permita realizar operaciones síncronas, o un dispositivo externo llamado “Controlador de Nodo Terminal”[6], el cual convierta los paquetes transmitidos por un enlace en serie asíncrono, en paquetes transmitidos síncronamente. Existen muchas clases diferentes de interfaces de tarjetas disponibles que soporten la operación de radio paquetes. Normalmente, estas tarjetas son aludidas según la “base Z8530 SCC” y su nombre va tras el controlador de comunicación más popular usado en el diseño. Dos de los protocolos que son transportados comúnmente por el AX.25 son NetRom y Rose, los cuales se denominan protocolos de red en capas (Network layer protocols). Puesto que estos últimos se ejecutan sobre AX.25, tienen los mismos requerimientos de hardware que este último. GNU/Linux soporta ampliamente todas las características de los protocolos AX.25, NetRom y Rose. Una buena fuente de información, sobre la implementación para GNU/Linux de éstos, es el HOWTO AX25-Como.

Otro tipo de acceso a Internet implicaría la utilización de marcación telefónica a una central, sobre una línea serie. Esto involucraría una conexión más lenta, aunque más barata, (usando el teléfono, RDSI, u otros servicios). Esto requiere todavía de la ayuda de otro protocolo para la transmisión de los paquetes, como por ejemplo SLIP o PPP, los que serán descritos más adelante.

El Protocolo IP (Internet Protocol)

Por supuesto, el administrador puede no querer que su red esté limitada solamente a una Ethernet, o a un sólo enlace de datos punto-a-punto. Seguramente la idea original consistirá en poder acceder a un servidor sin importar el hardware del que dispone. Por ejemplo, en instalaciones grandes como la Universidad de Groucho Marx, se encontrará muy a menudo con varias redes distanciadas unas de otras, pero conectadas entre ellas 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 enlazadas 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 GNU/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 homóloga niels del Departamento de Física, usando la red troncal, y por fin niels los entrega a la máquina destino. El flujo de datos entre erdos y quark se muestra en Figura 1-1.

Figura 1-1. Los tres pasos del enviado de un datagrama desde erdos a quark

Este esquema de envío de datos al nodo remoto se llama encaminamiento, y en este contexto a los paquetes se les denomina 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 (Protocolo de Internet). En Capítulo 2, trataremos con más detalle al IP y al encaminamiento.

El principal beneficio del IP es su cualidad de convertir a redes físicamente diferentes en una red aparentemente homogénea. A esto se le llama interconexión de redes, y a la resultante “meta-red” se la denomina internet. Obsérvese aquí la sutil diferencia entre una internet y la Internet. El último es el nombre oficial de una internet global en 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, denominado dirección IP. Una dirección IP está definida normalmente, por 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. Este formato de dirección, es comúnmente llamado notación decimal de puntos, aunque también puede hacerse referencia a él como notación cuadrangular de puntos[7]. Sin embargo la denominación de IP, está cambiando del nombre de IPv4, (por Internet Protocol, Version 4), a un nuevo estándar llamado IPv6 que ofrece mucha más flexibilidad a la hora de direccionar y otras mejoras modernas. Pasará por lo menos un año tras esta edición, antes de que IPv6 empiece a ser usado.

Se dará cuenta de que ahora tenemos tres tipos distintos de direcciones: primero, tenemos el nombre del nodo, como por ejemplo 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 se escriba rlogin quark, se le pueda pasar la dirección IP de quark al software de red; y cuando el nivel IP envíe datos a la Ethernet del Departamento de Físicas, de algún modo tenga cómo encontrar a que dirección Ethernet corresponde la dirección IP.

Se hará un repaso de todo esto, con más profundidad en Capítulo 2. De momento, es suficiente con indicar que estos pasos para encontrar las direcciones se llaman: resolución de nombresal trazar un mapa de nombres de nodo con direcciones IP, y resolución de direcciones, al hacer corresponder estas últimas con direcciones hardware.

IP en Líneas Serie

Para líneas serie se usa frecuentemente el estándar “de facto” conocido como SLIP o Serial Line IP (IP sobre línea en 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. Otro protocolo serie es el PPP, o Point-to-Point Protocol (Protocolo Punto a Punto). PPP dispone de muchas más características que SLIP, lo que lo hace mucho más atractivo. Su principal ventaja sobre SLIP es, sin embargo, que no se limita a transportar datagramas IP, sino que se diseñó para que la transmisión de cualquier tipo de protocolo pueda realizarse sobre él.

El Protocolo de Control de Transmisión, TCP

Pero la historia no se acaba con el envío de datagramas de un nodo a otro. Si se registra en quark, necesita disponer de una conexión fiable entre su proceso rlogin en erdos y el proceso del intérprete de órdenes en quark. Así, la información enviada en uno u otro sentido debe dividirse por 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 sí sólo, no es fiable. Suponga que diez personas de su Ethernet comienzan a transferirse la última versión del código fuente del Navegador web Netscape, usando el servidor FTP de GMU. La cantidad de tráfico generada por esto podría ser excesiva para la pasarela, por ser demasiado lenta, o tener poca memoria. Si en ese momento Ud. enviara un paquete a quark, sophus podría tener agotado el espacio del búfer durante un instante y por tanto no seria capaz de reenviarlo. IP resuelve este problema simplemente descartando el paquete el cual se pierde irrevocablemente. Esto traslada, por consiguiente, la responsabilidad de comprobar la integridad y exactitud de los datos a los nodos extremos, y su retransmisión en caso de error.

De este proceso se encarga otro protocolo: el Protocolo de Control de Transmisión, (TCP, Transmission Control Protocol), que construye un servicio fiable por encima de IP. La propiedad esencial de TCP es que usa IP para dar al usuario 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 cómo y sobre el recorrido de los datos a través de la ruta por la que viajan. Una conexión TCP funciona básicamente como una tubería de doble sentido, en la que ambos procesos pueden escribir y leer; Se puede usar la analogía de una conversación telefónica para comprender el funcionamiento de este protocolo.

TCP identifica los extremos de una conexión específica por las direcciones IP de los dos nodos implicados, y el número de los puertos de cada nodo. Los puertos se pueden ver como puntos de enganche para conexiones de red. Para seguir utilizando el ejemplo del teléfono un poco más, si pensamos en una analogía entre las ciudades como nodos, se 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). Un nodo en particular puede soportar diferentes servicios, cada uno diferenciado por su propio número de puerto.

En el ejemplo con rlogin, la aplicación cliente (rlogin) abre un puerto en erdos y se conecta al puerto 513 de quark, en el cual se sabe que el servidor rlogind está escuchando. Esto establece una conexión TCP. Usando esta conexión, rlogind desempeña el procedimiento de autorización para luego, generar un servicio de ontérprete de órdenes. La entrada y salida estándar de la shell se redirigen a la conexión TCP, de tal forma que cualquier cosa que se teclee a rlogin en nuestra máquina será pasada al flujo TCP para ser luego transmitida a la entrada estándar del intérprete de órdenes.

El Protocolo de Datagramas de Usuario

Sin embargo, 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, la cual utiliza un protocolo derivado de TCP llamado UDP, o User Datagram Protocol (Protocolo de Datagramas de Usuario). De igual modo que TCP, UDP 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, se puede usar para enviar paquetes sueltos al servicio destino - de ahí su nombre.

Supóngase que se ha solicitado una pequeña cantidad de información de un servidor de base de datos. Esto tomará, al menos tres datagramas para establecer la conexión TCP, otros tres para enviar y confirmar la cantidad de datos y otros tres para cerrar la conexión. UDP nos facilita el hacer la mayor parte de todo esto, pero solamente usando dos datagramas. Este protocolo es caracterizado por tener un método de conexión y desconexión mucho más rápido, y no requiere que el usuario establezca y cierre una conexión. El mecanismo es simple: UDP coloca los datos en un datagrama y lo envía al servidor. Éste realiza un proyecto del reenvío, poniendo los datos dentro de un datagrama direccionado a nuestra máquina, y luego lo transmite. Mientras que este procedimiento es más rápido y más eficiente que el de TCP para transacciónes simples, UDP no fue construido para tratar con posibles pérdidas de datos. Lidiar con estas dificultades dependerá de la aplicación en cuestión.

Más sobre Puertos

Los puertos se pueden ver como puntos de anclaje para conexiones de red. Si una aplicación quiere ofrecer un cierto servicio, se engancha ella misma a un puerto y espera a los clientes (a esto también se le llama escuchar en el puerto). Un cliente que quiera usar este servicio se asigna un puerto libre en su nodo local, y se conecta al puerto del servidor en el nodo remoto. El puerto del servidor podrá ser abierto por diferentes máquinas, pero nunca podrán usarlo más de una al mismo tiempo.

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 a su mismo puerto y aguardar a otros 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, el primer cliente rlogin usará el puerto local 1023, y el segundo el 1022. Sin embargo, ambos se conectarán al mismo puerto 513 de quark. Las dos conexiones se distinguirán según el puerto que cada una use en erdos.

Este ejemplo muestra el uso de puertos como puntos de encuentro, donde un cliente se contacta con un puerto específico para obtener un servicio específico. Para que un cliente pueda conectarse al número de puerto correcto, se ha tenido que llegar a un acuerdo entre los administradores de los dos sistemas para definir la asignación de estos números. Para servicios ampliamente usados, como rlogin, estos números tienen que administrarse de modo universal. Esto lo realiza el IETF (o Internet Engineering Task Force), que regularmente publica un RFC (Request For Comment) denominado Assigned Numbers (Números Asignados, RFC-1700). Describe, entre otras cosas, los números de puerto asignados a servicios reconocidos. GNU/Linux utiliza un archivo para hacer corresponder los nombres con números, llamado /etc/services.

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).

La Biblioteca de Sockets

En sistemas operativos UNIX, el software que realiza todas las tareas y protocolos descritos anteriormente es generalmente parte del núcleo, y por tanto viene incorporado dentro de GNU/Linux. La interfaz de programación más común en el mundo UNIX es la Biblioteca de Sockets de Berkeley[8]. Su nombre proviene de una analogía popular que ve los puertos como enchufes, y el 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, o accept)[9]. La biblioteca 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, como el protocolo XNS (Xerox Networking System), o el X.25.

En GNU/Linux, la biblioteca de sockets forma parte de la biblioteca C estándar, libc. Da soporte a los sockets AF_INET y AF_INET6, para sockets de dominio Unix. También soporta AF_IPX para los protocolos de redes Novell; AF_X25 para el protocolo X.25; AF_ATMPVC y AF_ATMSVC para el protocolo de redes ATM; y AF_AX25, AF_NETROM, y AF_ROSE para sockets que usen el protocolo de radio-aficionados[10]. En este momentos se están desarrollando otras familias de protocolos conocidos, que se agregarán sin esperar mucho tiempo.

Notas

[1]

Una shell es un intérprete de órdenes, que actúa como interfaz con el sistema operativo Unix. Se le puede comparar al COMMAND.COM de DOS en un entorno de Microsoft Windows, aunque mucho más potente.

[2]

Respectivas traducciones de “repeaters”, “bridges” y “routers”. Nota del T.

[3]

El FAQ de Ethernet que se encuentra en http://www.faqs.org/faqs/LANs/ethernet-faq/ habla sobre este tema. También se puede encontrar abundante información histórica y técnica, muy detallada en el web de Charles Spurgeon's dedicado a Ethernet, http://wwwhost.ots.utexas.edu/ethernet/.

[4]

En el original: Frame Relay Access Device. Nota del T.

[5]

En el original: Asynchronous Transfer Mode. Nota del T.

[6]

“Terminal Node Controller”, en el original. Nota del T.

[7]

Definiciones que en el inglés serían “dotted decimal notation” y “dotted quad notation”, respectivamente. Nota del T.

[8]

Berkeley Socket Library. Nota del T.

[9]

En donde las traducciones al español de los términos “bind”, “connect”, “listen” y “accept” son “enlazar”, “conectar”, “escuchar” y “aceptar” respectivamente

[10]

Amateur Radio protocol. Nota del T.

Tabla de contenidos
  1. 1 - Prefacio
  2. 2 - Fuentes de información
  3. 3 - Estandares de Sistemas de Ficheros
  4. 4 - Estandar del Sistema Basico Linux
  5. 5 - Acerca de este Libro
  6. 6 - La Versión Oficial Impresa
  7. 7 - Envío de Cambios
  8. 8 - Agradecimientos
  9. 9 - La traducción al español
  10. 10 - Historia del trabajo en redes
  11. 11 - Redes TCP/IP
  12. 12 - Redes UUCP
  13. 13 - Redes con GNU/Linux
  14. 14 - Mantenimiento del Sistema
  15. 15 - Interfaces de red
  16. 16 - Direcciones IP
  17. 17 - Resolución de direcciones
  18. 18 - Encaminamiento IP
  19. 19 - El Internet Control Message Protocol
  20. 20 - Resolución de nombres de puesto
  21. 21 - Configuración del hardware de red
  22. 22 - Configuracion del núcleo
  23. 23 - Un vistazo a los dispositivos de red de Linux
  24. 24 - Instalación de una Ethernet
  25. 25 - El controlador PLIP
  26. 26 - Los controladores PPP y SLIP
  27. 27 - Otros tipos de redes
  28. 28 - Configuración del Hardware Serie
  29. 29 - Software de Comunicaciones para Enlaces con Módem
  30. 30 - Introducción a los Dispositivos Serie
  31. 31 - Acceso a Dispositivos Serie
  32. 32 - Hardware Serie
  33. 33 - Uso de las Utilidades de Configuración
  34. 34 - Dispositivos Serie y el Indicador login: (ingreso)
  35. 35 - Configuración del Protocolo TCP/IP
  36. 36 - Montando el Sistema de Ficheros /proc
  37. 37 - Instalación de los ejecutables
  38. 38 - Establecimiento del Nombre de la Maquina
  39. 39 - Asignación de una dirección IP
  40. 40 - Creación de Subredes
  41. 41 - Preparación de los ficheros hosts y networks
  42. 42 - Interfaz Configuración de la Interfaz para IP
  43. 43 - Todo sobre ifconfig
  44. 44 - La orden netstat
  45. 45 - Comprobación de las tablas ARP
  46. 46 - El servicio de nombres y su configuración
  47. 47 - La biblioteca de resolución
  48. 48 - Cómo funciona el DNS
  49. 49 - Ejecución de named (I)
  50. 50 - Ejecución de named (II)
  51. 51 - Ejecución de named (III)
  52. 52 - SLIP: IP por línea serie
  53. 53 - Requerimientos Generales para SLIP o PPP
  54. 54 - Operación de SLIP
  55. 55 - Trabajando con direcciones de red IP privadas
  56. 56 - Usando dip
  57. 57 - Funcionamiento en modo Servidor
  58. 58 - El Protocolo Punto-a-Punto
  59. 59 - PPP en Linux
  60. 60 - Ejecutando pppd
  61. 61 - Usando los Ficheros de Opciones
  62. 62 - Realización de la Llamada con chat
  63. 63 - Opciones de Configuración IP
  64. 64 - Opciones de Control de Enlace
  65. 65 - Consideraciones de Seguridad General
  66. 66 - Autentificación con PPP
  67. 67 - Depurando su configuración de PPP
  68. 68 - Configuraciones avanzadas de PPP
  69. 69 - Cortafuegos de TCP/IP
  70. 70 - Métodos de ataque
  71. 71 - ¿Qué es un cortafuegos?
  72. 72 - ¿Qué es el filtrado de IP?
  73. 73 - Configuración de Linux como cortafuegos
  74. 74 - Las tres formas posibles de filtrado
  75. 75 - El cortafuegos original de IP (núcleos 2.0)
  76. 76 - Cortafuegos 'IP Chains' (núcleos 2.2) (I)
  77. 77 - Cortafuegos 'IP Chains' (núcleos 2.2) (II)
  78. 78 - Netfilter e 'IP Tables' (Núcleos 2.4)
  79. 79 - Manipulación de los bits de TOS
  80. 80 - Comprobación de una configuración del cortafuegos
  81. 81 - Un ejemplo de configuración del cortafuegos
  82. 82 - Contabilidad IP
  83. 83 - Configurando el núcleo para contabilidad IP
  84. 84 - Configurando Contabilidad IP
  85. 85 - Utilizando los resultados de contabilidad IP
  86. 86 - Restableciendo contadores
  87. 87 - Vaciando las reglas
  88. 88 - Colección pasiva de datos de contabilidad
  89. 89 - Enmascaramiento IP yTraducción de Direcciones de Red
  90. 90 - Efectos Laterales y Beneficios Accesorios
  91. 91 - Configuración del Núcleopara enmascaramiento IP
  92. 92 - Configuración del enmascaramiento IP
  93. 93 - Manipulación del Servicio de Nombres
  94. 94 - Mas sobre la traducción de direcciones de red
  95. 95 - Características Importantesde Redes
  96. 96 - El Super Servidor inetd
  97. 97 - La Facilidad de Control de Acceso tcpd
  98. 98 - Los Ficheros de Servicios Y Protocolos
  99. 99 - Llamada a Procedimiento Remoto
  1. 100 - Configurando el Registro y Ejecución Remotos
  2. 101 - El Sistema de Información de Red (NIS)
  3. 102 - Familiarizandose con NIS
  4. 103 - NIS Versus NIS+
  5. 104 - La Parte Cliente en NIS
  6. 105 - Ejecutando un Servidor NIS
  7. 106 - Seguridad en el Servidor NIS
  8. 107 - Configurando un Cliente NIS con la libc de GNU
  9. 108 - Escogiendo los Mapas Correctos
  10. 109 - Utilizando los Mapas passwd y group
  11. 110 - Usando NIS con Soporte de Contraseñas Ocultas
  12. 111 - El Sistema de Ficherosde Red
  13. 112 - Preparando NFS
  14. 113 - Montando un Volumen NFS
  15. 114 - Los Demonios NFS
  16. 115 - El Fichero exports
  17. 116 - Soporte para NFSv2 Basado en Núcleo
  18. 117 - Soporte para NFSv2 Basado en Núcleo
  19. 118 - IPX y el Sistema de Ficheros NCP
  20. 119 - Xerox, Novell, e Historia
  21. 120 - IPX y Linux
  22. 121 - Configurando el núcleo para IPX y NCPFS
  23. 122 - Configurando las interfaces IPX
  24. 123 - Configurando un Encaminador IPX
  25. 124 - Montando un Volumen NetWare Remoto
  26. 125 - Explorando Algunas de las Otras Herramientas IPX
  27. 126 - Imprimiendo en una Cola de Impresión NetWare
  28. 127 - Emulación del Servidor NetWare
  29. 128 - Administración deTaylor UUCP
  30. 129 - Transferencias UUCP y ejecución remota
  31. 130 - Ficheros de configuración de UUCP (I)
  32. 131 - Ficheros de configuración de UUCP (II)
  33. 132 - Controlar el acceso a las prestaciones de UUCP
  34. 133 - Configuración de su sistema para recibir llamadas
  35. 134 - Protocolos UUCP de bajo nivel
  36. 135 - Resolución de problemas
  37. 136 - Ficheros de registro y depuración
  38. 137 - Correo Electrónico
  39. 138 - ¿Qué es un mensaje de correo?
  40. 139 - ¿Cómo se reparte el correo?
  41. 140 - Direcciones de correo electrónico
  42. 141 - ¿Cómo funciona el encaminamiento del correo?
  43. 142 - como configurar elm
  44. 143 - Sendmail
  45. 144 - Instalando Sendmail
  46. 145 - Un Vistazo a los Ficheros de Configuración
  47. 146 - Los Ficheros sendmail.cf y sendmail.mc
  48. 147 - Generando el Fichero sendmail.cf
  49. 148 - Interpretación de las Reglas de Escritura - Reescritura
  50. 149 - Configuración de las Opciones de Sendmail
  51. 150 - Algunas configuraciones útiles para Sendmail
  52. 151 - Probando la Configuración
  53. 152 - Ejecución de Sendmail
  54. 153 - Pistas y Trucos
  55. 154 - Poner Exim en marcha
  56. 155 - Ejecución de Exim
  57. 156 - Si el correo no llega a su destino
  58. 157 - Compilar Exim
  59. 158 - Modos de Envío de Correo
  60. 159 - Otras opciones de configuración
  61. 160 - Encaminamiento y envío de mensajes
  62. 161 - Protegerse contra el "spam"
  63. 162 - Instalación UUCP
  64. 163 - Noticias
  65. 164 - Historia de Usenet
  66. 165 - Pero, ¿qué es Usenet después de todo?
  67. 166 - ¿Cómo maneja Usenet las noticias?
  68. 167 - C-News
  69. 168 - Enviando noticias
  70. 169 - Instalación
  71. 170 - El fichero sys
  72. 171 - El Fichero active
  73. 172 - Procesar Artículos por Lotes
  74. 173 - Caducando Noticias
  75. 174 - Ficheros Diversos
  76. 175 - Mensajes de Control
  77. 176 - C-News en un Entorno NFS
  78. 177 - Herramientas y Tareas de Mantenimiento
  79. 178 - NNTP y el Demonio nntpd
  80. 179 - El Protocolo NNTP
  81. 180 - Instalar el servidor NNTP
  82. 181 - Restringir el acceso con NNTP
  83. 182 - Autorización NNTP
  84. 183 - Interacción de nntpd con C News
  85. 184 - Noticias de Internet
  86. 185 - Algunos aspectos internos de INN
  87. 186 - INN y los lectores de noticias
  88. 187 - Instalación de INN
  89. 188 - Configuración de INN: Configuración Basica
  90. 189 - INN: Ficheros de Configuración (I)
  91. 190 - INN: Ficheros de Configuración (II)
  92. 191 - Activación de INN
  93. 192 - Uso de INN: El programa ctlinnd
  94. 193 - Configuración del lector de noticias
  95. 194 - Configuración de tin
  96. 195 - Configuración de trn
  97. 196 - Configuración de nn
  98. 197 - Apéndice A. Red de ejemplo:La Cervecera Virtual
  99. 198 - Apéndice B. Configuraciones de cableado útiles
Autor y licencia de 'Guía de Administración de Redes con Linux - Redes TCP/IP'
Olaf Kirch y Terry Dawson Extraído de: http://es.tldp.org/Manuales-LuCAS/GARL2/garl2/ GNU Free Documentation License
Licencia GNU Free Documentation License: http://www.es.gnu.org/licencias/fdles.html
Este contenido ha sido recopilado por el equipo de Wikilearning. Todo el contenido recopilado se ha obtenido respetando y comunicando en nuestro site la licencia de cada fuente.
Wikilearning tiene permiso expreso por escrito de los autores para publicar los contenidos que ha extraído de otras webs, incluyendo su uso comercial.

Wikis relacionados con 'Guía de Administración de Redes con Linux - Redes TCP/IP'

Hablar de redes de ordenadores siempre implica hablar de Unix. Por supuesto, Unix no es... Más »
La gran rapidez con la que Internet se ha expandido y popularizado en los últimos... Más »
A lo largo de este trabajo se va a intentar hacer un repaso de los... Más »
Quisiera por lo tanto partir ahora de un conjunto de apuntes generales, de una veloz... Más »
A mediados de los 70 diversos fabricantes desarrollaron sus propios sistemas de redes locales. Es... Más »
Gente Wiki
José Francisco Navarro Martín
Arquitecto y amante del deporte ( baloncesto sobretodo ) y de la cultura en general ( literatura, cine, viajes, arte......
Idioma ruso
Carlos Roberto Martínez Gómez
Me dedico a la capacitación de empresas y soy catedrático de la universidad regional del sureste, en la facultad de...
Mariana Uresberoeta
Hola! mi nombre es mariana, soy de argentina. Soy profesora de inglés y estoy haciendo una especialización en fonética y...
Víctor Torres Tananta
Tengo mucho interés en temas relacionados con el Desarrollo Urbano y la Gestión Municipal. Hace poco culminamos un Proyecto de...
Sergio Martín Cabeza
A sus 42 años, ejerce como director de una sucursal bancaria y como coach personal y ejecutivo. Es diplomado en...
Gestión del conocimiento, Inteligencia emocional,...
David Olmo
Técnico superior en administracion de sistemas operativos. Administrador de sistemas linux/unix en la junta de castilla y león. Gestiona servidores...
Electrónica, PERL,...
Suscribirse
¿Estás seguro de que deseas eliminar este capítulo?