Redes en Linux Parte 1

Redes en Linux Como (Previamente Net-3 Como)
Autor actual: Joshua Drake, {Poet}, poet@linuxports.com
Autores originales: Terry Dawson (autor principal),
terry@perf.no.itg.telstra.com.au; Alessandro Rubini,
rubini@linux.it (mantenimiento)
Traducido por: Ricardo Javier Cárdenes Medina,
a1402@serdis.dis.ulpgc.es
v1.5, 20 de agosto de 1997, traducción del 3 de septiembre
de 1999

Este Cómo es la base para entender la evolución de las capacidades de
Linux para tratar con redes informáticas. Es el punto de partida para
aprender todo sobre el mantenimiento de redes TCP/IP, la configuración
de los archivos relacionados con la red, y hay un amplio capítulo
sobre configuración de dispositivos físicos. En suma, un documento muy
exhaustivo que merece la pena leer.
______________________________________________________________________

Índice general

1. Introducción.

2. Historia del documento

2.1 Comentarios y sugerencias

3. Cómo usar este documento.

3.1 Convenciones usadas en el documento

4. Información general sobre las redes en Linux.

4.1 Breve historia del desarrollo del
4.2 Recursos referentes al tratamiento de redes con Linux.
4.3 Dónde conseguir información sobre redes no específica de Linux.

5. Información genérica sobre la configuración de redes.

5.1 ¿Qué necesito para comenzar?
5.1.1 Código fuente del núcleo.
5.1.2 Herramientas de red actualizadas.
5.1.3 Aplicaciones de red.
5.1.4 Introducción a las direcciones IP.
5.2 ¿Dónde debería poner las órdenes de configuración?
5.3 Creación de las interfaces de red.
5.4 Configuración de una interfaz de red.
5.5 Configuración del sistema de resolución de nombres (
5.5.1 ¿Qué hay en un nombre?
5.5.2 Qué información necesitará
5.5.3 (TT
5.5.4 (TT
5.5.5 (TT
5.5.6 Ejecutar un servidor de nombres
5.6 Configuración de la interfaz
5.7 Encaminamiento (
5.7.1 Entonces ¿qué hace el programa
5.8 Configuración de los servidores de red y los servicios.
5.8.1 (TT
5.8.1.1 Un ejemplo de fichero
5.8.2 (TT
5.8.2.1 Un ejemplo de
5.9 Otros ficheros de configuración relacionados con la red
5.9.1 (TT
5.9.2 (TT
5.10 Seguridad en la red y control de acceso.
5.10.1 (TT
5.10.2 (TT
5.10.3 El mecanismo de control de acceso
5.10.3.1 (TT
5.10.3.2 (TT
5.10.4 (TT
5.10.5 Configure su demonio de ftp adecuadamente.
5.10.6 Cortafuegos para redes.
5.10.7 Otras sugerencias.

6. Información relacionada con IP y Ethernet

6.1 Ethernet
6.2 EQL – ecualizador de tráfico para líneas múltiples
6.3 IP Accounting (en Linux 2.0)
6.4 IP Accounting (en Linux 2.2)
6.5 IP Aliasing
6.6 IP Firewall (para Linux 2.0)
6.7 IP Firewall (para Linux 2.2)
6.8 Encapsulación IPIP
6.8.1 Una configuración de red con
6.8.2 Configuración de la máquina cuyos paquetes serán encapsulados
6.9 Enmascarado IP (
6.10 Proxy IP transparente
6.11 IPv6
6.12 Mobile IP
6.13 Multicast
6.14 NAT – Network Address Translation (Traducción de direcciones de red)
6.15 Traffic Shaper (Manipulación del ancho de banda)
6.16 Encaminamiento con Linux-2.2

7. Uso de hardware común en los PC

7.1 RDSI
7.2 PLIP en Linux-2.0
7.3 PLIP en Linux-2.2
7.4 PPP
7.4.1 Mantener una conexión permanente a la red usando
7.5 Cliente SLIP
7.5.1 dip
7.5.2 slattach
7.5.3 ¿Cuándo usar cada uno?
7.5.4 Servidor SLIP estático con línea por llamada y DIP.
7.5.5 Servidor SLIP dinámico con línea por llamada y DIP.
7.5.6 Uso de Dip.
7.5.7 Conexión SLIP permanente usando una línea dedicada y slattach
7.6 Servidor SLIP.
7.6.1 Servidor slip usando
7.6.1.1 Dónde obtener
7.6.1.2 Configuración de
7.6.1.3 Configuración de
7.6.1.4 Configuración del fichero
7.6.1.5 Configuración del fichero
7.6.1.6 Configuración del fichero
7.6.2 Servidor Slip usando
7.6.2.1 Configuración del fichero /etc/diphosts
7.6.3 Servidor SLIP usando el paquete

8. Otras tecnologías de red

8.1 ARCNet
8.2 Appletalk (
8.2.1 Configuración del software Appletalk.
8.2.2 Exportación de un sistema de ficheros Linux vía Appletalk.
8.2.3 Compartir la impresora Linux a través de Appletalk.
8.2.4 Ejecución de AppleTalk.
8.2.5 Comprobación de AppleTalk.
8.2.6 Problemas con AppleTalk.
8.2.7 Si necesitase más información…
8.3 ATM
8.4 AX25 (
8.5 DECNet
8.6 FDDI
8.7 Retransmisión de Tramas (
8.8 IPX (
8.9 NetRom (
8.10 Protocolo Rose (
8.11 Soporte SAMBA – NetBEUI, NetBios.
8.12 Soporte de STRIP (
8.13 Anillo con testigo (
8.14 X.25
8.15 Tarjeta WaveLan

9. Cables y Cableado

9.1 Cable serie Módem NULO (NULL Modem)
9.2 Cable de puerto paralelo (cable PLIP)
9.3 Cableado Ethernet 10base2 (coaxial fino)
9.4 Cable Ethernet de Par Trenzado

10. Glosario de Términos usados en este documento

11. ¿Linux para un PSI?

12. Reconocimientos

13. Copyright.

14. Anexo: El INSFLUG

______________________________________________________________________

1. Introducción.

El Sistema Operativo Linux se enorgullece de contar con una
implementación de servicios de red basada en el núcleo, escrita casi
por completo partiendo de cero. Su rendimiento en los núcleos
recientes lo convierte en una alternativa válida incluso a el mejor de
sus iguales. Este documento intenta describir cómo instalar y
configurar el software de red de Linux y sus herramientas asociadas.

Esta es la primera entrega desde que LinuxPorts comenzó a hacerse
cargo del documento. Quisiera decir antes que nada que deseamos que
durante los próximos meses encuentre de utilidad este documento, y que
seamos capaces de proporcionar información precisa y puntual en lo que
respecta al tratamiento de redes con Linux.

Este documento, al igual que los otros Comos de los que nos
encargamos, se va a convertir en algo muy diferente. Dentro de poco
pasará a ser el Redes en Linux Como en lugar de ser sólo el Net-3(4)
Como. Va a cubrir temas como PPP, VPN (Redes Privadas Virtuales), y
otros…

2. Historia del documento

El NET-FAQ original fue escrito por Matt Welsh y Terry Dawson para
responder preguntas frecuentes sobre las redes para Linux, un tiempo
antes de que comenzara formalmente el Proyecto de Documentación de
Linux. Cubría las últimas versiones de desarrollo del Linux Networking
Kernel. El NET-2-HOWTO sobreseyó el NET-FAQ y fue uno de los
documentos HOWTO originales del LDP. Cubría lo que se llamó versión 2
y posteriormente versión 3 del Linux Kernel Networking software. Este
documento a su vez lo sobresee y sólo se refiere a la versión 4 del
Linux Networking Kernel: más específicamente a las versiones 2.0.x y
2.2.x del núcleo.

Las versiones anteriores de este documento llegaron a ser bastante
grandes a causa de la enorme cantidad de material que caía dentro de
su ámbito. Para ayudar a resolver este problema se han producido unos
cuantos Como que tratan con temas específicos sobre redes. Este
documento proporciona referencias a dichos Como cuando sean relevantes
y cubre aquellas áreas de las que aún no se habla en otros documentos.

2.1. Comentarios y sugerencias

Estamos interesados en que la gente nos proporcione sugerencias (que
nos informen de cambios, errores, etc.). Por favor, póngase en
contacto con nosotros en: poet@linuxports.com. De nuevo, si encuentra
algo erróneo o cualquier cosa que desearía que fuese añadida, por
favor, contacte con nosotros.

3. Cómo usar este documento.

Este documento está organizado de una manera vertical. La primera
sección incluye material informativo y se la puede saltar si no es de
su interés; lo que sigue es una discusión genérica sobre temas
referentes a las redes, y debe asegurarse de entender esto antes de
proceder con partes más específicas. El resto, información «específica
de la tecnología», está agrupada en tres secciones principales:
información relativa a Ethernet e IP, tecnologías pertinentes a
hardware para PC de amplia difusión y tecnologías usadas sólo rara
vez.

La metodología que nosotros sugerimos a la hora de leer este documento
es la siguiente:

Lea las secciones genéricas
Estas secciones se aplican a toda, o casi toda tecnología
descrita más adelante, y por tanto es muy importante que lo
comprenda.

Estudie su red
Debería saber cómo está, o estará diseñada su red, y exactamente
qué tipo de hardware y tecnología estará implementando.

Lea la sección “IP y Ethernet” si está
conectado directamente a una LAN o a Internet” Esta sección
describe la configuración básica para Ethernet ya las varias
posibilidades que ofrece Linux para las redes IP, como servicio
de cortafuegos, encaminamiento avanzado, etc.

Lea la siguiente sección si está interesado en redes locales de
bajo coste o en conexiones punto a punto” Esta sección describe
PLIP, PPP, SLIP y RDSI, las tecnologías de más amplia difusión
en estaciones de trabajo personales.

Lea las secciones específicas a tecnologías relacionadas con sus
necesidades” Si sus necesidades difieren de una solución con IP
y hardware común, la sección del final cubre detalles
específicos a protocolos diferentes al IP y a hardware de
comunicaciones peculiar.

Configure
Debería intentar configurar su red y tomar nota cuidadosamente
de cualquier problema que tenga.

Busque más ayuda si la necesita
Si experimenta problemas que este documento no le ayude a
resolver entonces lea la sección relativa a dónde encontrar
ayuda o dónde informar de los errores.

¡Diviértase!
Trabajar en red es divertido, disfrútelo.

3.1. Convenciones usadas en el documento

No se han utilizado convenciones especiales, pero debería estar al
corriente de la manera en que aparecen las órdenes. Siguiendo el
estilo clásico en la documentación de Unix, cualquier orden que deba
escribir en su intérprete de órdenes, estará prefijada por el símbolo
«prompt». Este Como muestra el prompt usuario$ para las órdenes que no
necesitan que las ejecute el root. He escogido usar root# en lugar de
un simple # para evitar confusiones con los trozos dispersos de
guiones (shell script), donde la almohadilla (#) se usa para definir
comentarios entre líneas.

Cuando se muestran «Opciones de Compilación del Núcleo», se presentan
en el formato usado por menuconfig. Deberían ser comprensibles incluso
si usted (al igual que yo) no está acostumbrado a usar menuconfig. Si
tiene dudas al respecto del anidamiento de las opciones, ejecutar el
programa le será de ayuda.

Fíjese en que los enlaces a otros documentos COMO son locales para que
pueda acceder a las copias de los documentos del LDP que haya en el
servidor al que usted está accediendo, en caso de que esté leyendo la
versión html de este documento. Si no dispone del paquete completo de
documentos, cada COMO puede ser obtenido en www.linuxdoc.org
(directorio /pub/Linux/HOWTO) y en sus incontables servidores réplica
(mirror sites).

4. Información general sobre las redes en Linux.

4.1. Breve historia del desarrollo del Linux Networking Kernel .

Desarrollar una nueva implementación núcleo de la pila para el
protocolo tcp/ip que rinda tan bien como las implementaciones
existentes no es una tarea fácil. La decisión de no portar una de las
implementaciones existentes se tomó en un tiempo en que había cierta
incertidumbre al respecto de si las implementaciones existentes serían
lastradas con copyrights restrictivos por el precedente sentado por
U.S.L. y en que había un gran entusiasmo por hacerlo diferente y
quizás incluso mejor de lo que se había hecho.

El voluntario original para liderar el desarrollo del núcleo del
código de red fue Ross Biro, biro@yggdrasil.com. Ross produjo una
implementación simple e incompleta pero aprovechable en su mayor parte
de rutinas que fueron completadas con un controlador de Ethernet para
la interfaz de red WD-8003. Esto era suficiente para tener a mucha
gente probando y experimentando con el software y algunas personas
incluso intentaron conectar máquinas con esta configuración a
conexiones reales en Internet. La presión dentro de la comunidad de
Linux conduciendo el desarrollo de la implementación de la red estaba
creciendo y, al final, el coste de una combinación de cierta presión
aplicada sobre Ross y sus propios compromisos personales le
sobrecargaron y se descolgó del puesto de desarrollador jefe. Los
esfuerzos de Ross por iniciar el proyecto y la aceptación de la
responsabilidad de producir realmente algo útil en tan controvertidas
circunstancias fue lo que catalizó todo el trabajo futuro y por lo
tanto supone un componente esencial en el éxito del producto actual.

Orest Zborowski, obz@Kodak.COM, produjo la interfaz original de
programación de sockets BSD para el núcleo de Linux. Fue un gran paso
adelante ya que permitió portar a Linux muchas de las aplicaciones de
red existentes sin modificaciones serias.

Por aquel momento, Laurence Culhane, loz@holmes.demon.co.uk desarrolló
los primeros controladores de dispositivo para la implementación del
protocolo SLIP en Linux. Esto permitió a mucha gente que no tenía
acceso a redes Ethernet experimentar con el nuevo software de red. De
nuevo, hubo gente que cogió este controlador y lo puso en servicio
para conectarse a Internet. Esto dio a mucha gente una idea de las
posibilidades que podrían hacerse realidad si Linux tuviera un soporte
total de red y creciera el número de usuarios usando y experimentando
de forma activa el software de red que existía.

Una de las personas que también había estado trabajando activamente en
la tarea de construir la implementación de red era Fred vam Kempen,
waltje@uwalt.nl.mugnet.org. Después de un periodo de incertidumbre
tras la renuncia de Ross al cargo de desarrollador jefe, Fred ofreció
su tiempo y esfuerzos y aceptó el papel esencialmente sin oposición.
Fred tenía planes ambiciosos sobre la dirección que quería que
siguiese el software de red de Linux y orientó el progreso hacia esos
objetivos. Fred desarrolló varias versiones del código de red llamado
el núcleo de código NET-2 (el código NET era el de Ross) que mucha
gente pudo usar de manera más útil. Fred puso formalmente algunas
innovaciones en la agenda de desarrollo, como la interfaz dinámica de
dispositivo, la implementación del protocolo Amateur Radio AX.25 y una
interfaz de red diseñada más modularmente. El código NET-2 de Fred
fue usado por un gran número de entusiastas, que crecía continuamente
según se iba corriendo la voz de que el software funcionaba. El
software de red en esos momentos aún estaba constituido por un gran
número de parches a la versión estándar del núcleo y no estaba
incluido en la versión normal. El NET-FAQ y el subsecuente NET-2-HOWTO
describían el por entonces relativamente complejo procedimiento de
ponerlo todo en marcha. Fred se concentraba en desarrollar
innovaciones frente a las implementaciones estándar de red y eso
estaba llevando tiempo. La comunidad de usuarios estaba
impacientándose por algo que funcionase eficazmente y satisficiera al
80% de usuarios y, como con Ross, la presión sobre Fred como
desarrollador en jefe creció.

Alan Cox, iialan@www.uk.linux.org propuso una solución al problema
diseñada para resolver la situación. Propuso que él podría coger el
código NET-2 de Fred para quitar fallos, haciéndolo eficaz y estable
para que satisficiera al impaciente usuario de base al tiempo que
retiraba esa presión de Fred permitiéndole continuar con su trabajo.
Alan se puso a ello, obteniendo buenos resultados y su primera versión
del código de red de Linux fue llamada it/Net-2D(ebugged)/. El código
funcionaba bien en muchas configuraciones típicas y el usuario de base
estaba feliz. Alan puso claramente sus propias ideas y habilidad para
contribuir al proyecto y como consecuencia comenzaron a aparecer
muchas discusiones relativas a la dirección del código NET-2. Esto
desarrolló dos tendencias distintas dentro de la comunidad de red de
Linux, una que tenía la filosofía «hazlo funcionar primero, y luego
hazlo mejor» y la otra «hazlo mejor primero». Linus terminó
arbitrando y ofreciendo su apoyo a los esfuerzos de desarrollo de Alan
e incluyó el código de Alan en la distribución estándar de las fuentes
del núcleo. Esto puso a Fred en una posición difícil. Cualquier
desarrollo continuado podría debilitar la gran base de usuarios usando
y probando activamente el código y eso significaría que los progresos
serían lentos y difíciles. Fred continuó trabajando un tiempo y a la
larga acabó dejándolo y Alan se convirtió en el nuevo jefe del
esfuerzo de desarrollo de red para Linux.

Donald Becker, becker@cesdis.gsfc.nasa.gov reveló pronto su talento
para los aspectos de bajo nivel de las redes y produjo un amplio
abanico de controladores de red. Casi todos los incluidos en los
núcleos actuales fueron desarrollados por él. Hay más gente que ha
hecho contribuciones significativas, pero el trabajo de Donald es
prolífico y eso le garantiza una mención especial.

Alan continuó refinando el código NET-2-Debugged durante un tiempo
mientras trabajaba en solucionar algunos de los problemas que quedaban
sin mirar en la lista PORHACER. Por la época en que al código fuente
1.3.* del núcleo les estaban creciendo los dientes, el código de red
había migrado a la entrega NET-3 que es en la que las versiones
actuales están basadas. Alan trabajó en muchos aspectos diferentes
del código de red y con la asistencia de mucha otra gente con talento
de la comunidad de red de Linux hizo crecer el código en todas
direcciones. Alan produjo dispositivos de red dinámicos y las
primeras implementaciones de los estándares AX.25 e IPX. Alan ha
continuado jugueteando con el código, estructurándolo y mejorándolo
lentamente hasta el estado en que se encuentra hoy día.

Michael Callahan, callahan@maths.ox.ac.uk y Al Longyear
longyear@netcom.com aportaron la implementación del protocolo PPP, lo
cual fue crítico para incrementar el número de gente que usaba
activamente Linux para trabajar en red.

Jonathon Naylor, sn@cs.nott.ac.uk ha contribuido mejorando
significativamente el código de AX.25 de Alan, añadiendo los
protocolos NetRom y Rose. La implementación de AX.25/NetRom/Rose es en
sí misma bastante significativa, porque ningún otro sistema operativo
puede enorgullecerse de trabajar de forma nativa con estos protocolos
aparte de Linux.

Por supuesto, ha habido centenares de otras personas que han hecho
contribuciones significativas al desarrollo del software de red de
Linux. A algunas de estas personas las encontrará más adelante en la
sección de tecnologías específicas; otras personas han contribuido con
módulos, controladores, correcciones de errores, sugerencias, informes
de pruebas y apoyo moral. En cada caso, cada uno puede decir que ha
puesto su granito de arena y que ofreció lo que pudo. El código de red
del núcleo de Linux es un excelente ejemplo de los resultados que se
pueden obtener del anárquico estilo de desarrollo de Linux. Si aún no
se ha sorprendido, lo hará pronto. El desarrollo no se ha detenido.

4.2. Recursos referentes al tratamiento de redes con Linux.

Hay varios sitios en los que puede encontrar información acerca de la
implementación de red de Linux.

Tiene a su disposición un montón de asesores. Podrá encontrar un
listado en la LinuxPorts Consultants Database,
http://www.linuxports.com

Alan Cox, quien en estos momentos se encarga de mantener el código de
red del núcleo de Linux tiene una página WWW con los últimos titulares
y eventos de interés relativos al estado de desarrollo de las
funcionalidades presentes y futuras en cuanto al código de red linux
en: www.uk.linux.org.

Otro buen sitio es un libro escrito por Olaf Kirch titulado la Guía
para Administradores de Redes. Es parte del Proyecto de Documentación
de Linux http://www.linuxdoc.org y puede leerlo de forma interactiva
en su versión HTML http://metalab.unc.edu/LDP/LDP/nag/nag.html, u
obtenerlo en varios formatos mediante FTP (y en castellano) desde el
archivo del proyecto LuCAS
ftp://lucas.hispalinux.es/pub/LuCAS/Manuales-LuCAS/GARL. El libro de
Olaf es bastante extenso y procura una buena iniciación de alto nivel
a la configuración de redes en Linux.

Hay un grupo de noticias en la jerarquía de noticias de Linux dedicado
a las redes y a materias relacionadas: comp.os.linux.networking

Hay una lista de correo a la que se puede suscribir, donde hacer
preguntas relacionadas al trabajo en redes con Linux. Para suscribirse
debe mandar un mensaje:

       A: majordomo@vger.rutgers.edu
       Asunto: cualquier cosa
       Mensaje:

       subscribe linux-net

En las diferentes redes de IRC suele haber canales #linux en los que
suele haber gente que responde preguntas sobre linux y redes.

Por favor, cuando vaya a informar de cualquier problema, recuerde
incluir todos los detalles que pueda relevantes al respecto. Debería
informar, específicamente, de las versiones de los programas que esté
usando, sobre todo la versión del núcleo, la versión de herramientas
como pppd o dip y la naturaleza exacta del problema que está
experimentando. Esto significa tomar nota de la sintaxis exacta de
cualquier mensaje de error que reciba y de cualquier orden que esté
ejecutando.

4.3. Linux. Dónde conseguir información sobre redes no específica de

Si está buscando información básica de aprendizaje sobre redes tcp/ip
en general, entonces le recomiendo que eche un vistazo a los
siguientes documentos:

TCP/IP Introduction
este documento está tanto en versión texto
ftp://athos.rutgers.edu/runet/tcp-ip-intro.doc como en versión
PostScript ftp://athos.rutgers.edu/runet/tcp-ip-intro.ps.

TCP/IP Administration
este documento está tanto en versión texto
ftp://athos.rutgers.edu/runet/tcp-ip-admin.doc como en versión
PostScript ftp://athos.rutgers.edu/runet/tcp-ip-admin.ps.

Si busca información algo más detallada sobre redes tcp/ip entonces le
recomiendo:

Internetworking with TCP/IP, Volume 1: principles, protocols
and architecture, de Douglas E. Comer, ISBN 0-13-227836-7,
Prentice Hall publications, Tercera edición, 1995.

Si quiere aprender a escribir aplicaciones de red en entornos
compatibles Unix entonces también le recomiendo:

Unix Network Programming, by W. Richard Stevens, ISBN
0-13-949876-1, Prentice Hall publications, 1990.

También debería probar el grupo de noticias comp.protocols.tcp-ip.
Otra fuente importante de información técnica específica relativa a la
Internet y al conjunto de protocolos tcp/ip son los RFC. RFC es un
acrónimo de Request For Comments y es el medio estándar de enviar y
documentar los protocolos estándar de Internet. Hay muchos sitios de
donde tomar los RFC. Muchos de estos sitios son de FTP y otros
proporcionan acceso por World Wide Web con un buscador asociado que le
permite buscar palabras clave en la base de datos de RFC.

Un posible lugar donde encontrar lo RFC es la base de datos de Nexor
http://pubweb.nexor.co.uk/public/rfc/index/rfc.html.

5. Información genérica sobre la configuración de redes.

Las siguientes subsecciones las necesitará para saber y comprender
ciertas cosas antes de que intente configurar la red. Son principios
fundamentales que se aplican independientemente de la naturaleza
exacta de la red que desee organizar.

5.1. ¿Qué necesito para comenzar?

Antes de que empiece a construir o configurar la red necesita saber
algunas cosas. Las más importantes son:

5.1.1. Código fuente del núcleo.

Antes que nada:

La mayoría de las distribuciones vienen por defecto con el soporte de
red activado, por lo cual no habrá que recompilar el núcleo. Si tiene
hardware común, debería irle bien. Por ejemplo, tarjetas de red 3COM,
NE2000, o Intel. Sin embargo proporcionamos la siguiente información
por si necesita actualizar el núcleo.

Como puede ser que el núcleo que está ejecutando no esté preparado
para los tipos de red o tarjetas que desee usar, probablemente
necesitará las fuentes del núcleo para recompilarlo con las opciones
apropiadas.

Siempre puede obtener la última versión de CDROM.com
permite que MUCHOS usuarios conecten simultáneamente. El sitio oficial
es kernel.org, pero use el anterior si tiene la posibilidad. Por
favor, recuerde que ftp.kernel.org está seriamente sobrecargado. Use
un servidor réplica.

Normalmente las fuentes del núcleo se instalarán en el directorio
/usr/src/linux. Para más información sobre cómo aplicar parches y
construir el núcleo debería leer el Kernel Como. Para más información
sobre cómo configurar módulos del núcleo debería leer el Modules mini-
Howto. Además, el fichero README que hay en las fuentes del núcleo y
el directorio Documentation son muy ilustrativos para el lector
intrépido.

A menos que se diga específicamente lo contrario, recomiendo que
empiece con la versión estándar del núcleo (la que tenga un número par
como segundo dígito del número de versión). Las versiones de
desarrollo del núcleo (las que tienen el segundo dígito impar) podrían
tener algunos cambios estructurales u otros que podrían causar
problemas con otro software en su sistema. Si no está seguro de que
pueda resolver ese tipo de problemas sumado al potencial de que haya
otros errores de software, no los use.

Por otro lado, algunas de las capacidades aquí descritas han sido
introducidas durante el desarrollo de los núcleos 2.1, por lo que
tendrá que tomar una decisión: puede mantenerse en 2.0 mientras espera
por el 2.2 y por una distribución con cada herramienta actualizada, o
puede coger un 2.1 y buscar los diversos programas necesarios para
explotar las nuevas capacidades. En el momento de escribir este Como,
en Agosto de 1998, el núcleo disponible es el 2.1.115 y se espera que
el 2.2 aparezca pronto.

Nota del Traductor: En el momento en que acabó la traducción de este
Como, en septiembre de 1999, las versiones disponibles del núcleo son
la 2.2.12 (estable) y la 2.3.16 (desarrollo). Además, las principales
distribuciones han puesto al día sus herramientas para tratar las
capacidades de la serie 2.1 y superiores.

5.1.2. Herramientas de red actualizadas.

Las herramientas de red son los programas que usted usa para
configurar los dispositivos de red de linux. Estas herramientas
permiten asignar direcciones a dispositivos y configurar rutas, por
ejemplo.

La mayoría de distribuciones modernas de Linux están dotadas con las
herramientas de red, por lo que si ha instalado Linux a partir de una
distribución y no ha instalado las herramientas de red, debería
hacerlo.

Si no ha instalado a partir de una distribución entonces necesitará
las fuentes para compilar las herramientas usted mismo. No es difícil.

Las herramientas de red las mantiene ahora Bernd Eckenfelds y están
disponibles en:

ftp://ftp.inka.de/pub/comp/Linux/networking/NetTools/ y están
replicadas en: ftp://ftp.uk.linux.org/pub/linux/Networking/base/.

También puede encontrar los últimos paquetes de RedHat en
ftp://ftp.cdrom.com/pub/linux/redhat/redhat-6.0/i386/base/net-
tools-1.51-3.i386.rpm.

Para Debian, los paquetes que traen las principales herramientas son
los paquetes hostname, netbase y netstd, que encontrará en
ftp://ftp.debian.org/debian/dists/stable/main/binary-i386/base/.

Asegúrese de que elige la versión que más se ajuste al núcleo que
desee usar y siga las instrucciones del paquete para instalarlo.

Para instalar y configurar la versión actual, —en el momento de
traducirse esto— esto necesitará hacer lo siguiente:

  usuario% cd /usr/src
  usuario% tar xvfz net-tools-x.xx.tar.gz
  usuario% cd net-tools-x.xx
  usuario% make config
  usuario% make
  root# make install

O si no, use los paquetes de su distribución. Por ejemplo, con RedHat:

       root# rpm -U net-tools-x.xx-y.i386.rpm

y con Debian:

       root# dpkg -i hostname_x.xx-y.yy.deb
       root# dpkg -i netbase_x.xx-y.yy.deb
       root# dpkg -i netstd_x.xx-y.yy.deb

En los anteriores ejemplos, x.xx se refiere a la versión de las
herramientas, e y.yy a la revisión de los correspondientes paquetes.

Si además va a configurar un cortafuegos o a usar la característica de
IP Masquerade, necesitará ipfwadm. La última versión la puede obtener
en: ftp:/ftp.xos.nl/pub/linux/ipfwadm. De nuevo se encontrará con más
de una versión disponible. Asegúrese de coger la versión que más se
ajuste a su núcleo. Tenga en cuenta que las capacidades de cortafuegos
de Linux cambiaron durante el desarrollo 2.1 y ipfwadm ha sido
sustituida por ipchains en la versión 2.2 del núcleo. ipfwadm sólo
vale para la versión 2.0 del núcleo. Se sabe de estas distribuciones
que se ajustan a versiones 2.0 o anteriores del núcleo:

· Redhat 5.2 o anteriores
· Caldera antes de la versión 2.2
· Slackware antes de las versiones 4.x
· Debian antes de las versiones 2.x

Para instalar y configurar la versión actual en el momento de escribir
esto necesita leer el IPChains Howto, disponible en el Proyecto de
Documentación de Linux http://www.linuxdoc.org

Tenga en cuenta que si tiene una versión 2.2 (o 2.1 de las últimas)
del núcleo, ipfwadm no es la herramienta correcta para configurar un
cortafuegos. Esta versión del NET-3-HOWTO todavía no trata con la
nueva configuración de cortafuegos. Si necesita información más
detallada sobre ipchains, por favor, diríjase al documento mencionado
anteriormente.

5.1.3. Aplicaciones de red.

Las aplicaciones de red son programas como telnet y ftp y sus
respectivos programas servidores. David Holland estuvo manteniendo una
distribución de las más comunes de la que ahora se ocupa
:netbug@ftp.uk.linux.org. Puede obtenerlas en:
ftp://ftp.uk.linux.org/pub/linux/Networking/base.

5.1.4. Introducción a las direcciones IP.

Las direcciones del Protocolo Internet (IP) están compuestas por
cuatro bytes. La convención es escribir estas direcciones en la
denominada «notación decimal puntuada» (dotted decimal notation). De
esta forma cada byte es convertido en un número decimal (0-255),
despreciando los ceros a la izquierda a menos que el número en sí sea
cero. Por convención, cada interfaz de una máquina o encaminador
tiene una dirección IP. Es válido usar la misma IP para cada interfaz
de una sola máquina en algunas circunstancias, pero normalmente cada
interfaz tiene su propia dirección.

Las Redes basadas en Internet Procotol son secuencias contiguas de
direcciones IP. Todas las direcciones dentro de una red tienen un
número de dígitos de en común. A la porción de la red que es común a
todas las direcciones llama la «porción de la red». Los dígitos
restantes son llamados «porción de la máquina». Al número de bits que
comparten todas las direcciones de una red se le llama máscara de red
(netmask), y su papel es determinar qué direcciones pertenecen a la
red y cuáles no. Consideremos el siguiente ejemplo:

       ---------------------  ---------------
       Dirección Host         192.168.110.23
       Máscara de red         255.255.255.0
       Porción de red         192.168.110.
       Porción de Host        .23
       ---------------------  ---------------
       Dirección de Red       192.168.110.0
       Dirección de Difusión  192.168.110.255
       ---------------------  ---------------

Cualquier dirección a la que se aplique una operación and de bits con
su máscara de red, revelará la dirección de la red a la que pertenece.
La dirección de red es por tanto siempre el menor número de dirección
dentro de el rango de la red y siempre tiene la porción de máquina
codificada toda con ceros.

La dirección «de difusión» (broadcast) es una especial a la que
escucha cada máquina en la red además de a la suya propia. Esta
dirección es a la que se envían los datagramas si se supone que todas
las máquinas de la red lo deben recibir. Ciertos tipos de datos, como
la información de encaminamiento y los mensajes de aviso son
transmitidos a la dirección de difusión para que cada estación en la
red pueda recibirlo simultáneamente. Hay dos estándares usados
comúnmente al respecto de la dirección de difusión. El más ampliamente
aceptado es el de usar la dirección más alta posible en la red. En el
ejemplo anterior sería 192.168.110.255. Por alguna razón, otras
estaciones han adoptado la convención de usar las direcciones de red
como direcciones de difusión. En la práctica no importa mucho cual
use, pero asegúrese de que cada máquina en la red está configurada con
la misma.

Por razones administrativas, durante el desarrollo inicial del
protocolo IP se formaron, de forma arbitraria, algunos grupos de
direcciones como redes, y estas redes se agruparon en las llamadas
«clases». Estas clases proporcionan un cierto número de redes de
tamaño estándar que pueden ser reservadas. Los rangos reservados son:

       ----------------------------------------------------------
       | Clase   | Máscara de    | Direcciones de red           |
       | de red  | red           |                              |
       ----------------------------------------------------------
       |    A    | 255.0.0.0     | 0.0.0.0    - 127.255.255.255 |
       |    B    | 255.255.0.0   | 128.0.0.0  - 191.255.255.255 |
       |    C    | 255.255.255.0 | 192.0.0.0  - 223.255.255.255 |
       |Multicast| 240.0.0.0     | 224.0.0.0  - 239.255.255.255 |
       ----------------------------------------------------------

Las direcciones que deberá usar dependen de lo que vaya a hacer
exactamente. Puede que tenga que realizar varias de las siguientes
actividades para obtener las direcciones que necesite:

Instalar una máquina Linux en una red IP existente
Si desea instalar una máquina Linux en una red IP existente
entonces debería contactar con los administradores de la red y
preguntarles por la siguiente información:

· Dirección IP del Host
· Dirección IP de la red
· Dirección IP de broadcast
· Máscara de red IP
· Dirección del encaminador (router)
· Dirección del Servidor de Nombre de Dominio (DNS)

Debería configurar entonces el dispositivo de red Linux con esos
detalles. No puede inventarlos y esperar que la configuración
funcione.

Construir una nueva red propia que nunca conectará con
Internet” Si está construyendo una red privada y no tiene
intención de conectar nunca esa red a Internet entonces puede
elegir las direcciones que quiera. De todas maneras, por razones
de seguridad y consistencia, se han reservado algunas
direcciones IP de red específicamente para este propósito. Están
descritas en el RFC1597 y son las que siguen:

     -----------------------------------------------------------
     |      DIRECCIONES RESERVADAS PARA REDES PRIVADAS         |
     -----------------------------------------------------------
     | Clase   | Máscara de    | Direcciones de red            |
     | de red  | red           |                               |
     -----------------------------------------------------------
     |    A    | 255.0.0.0     | 10.0.0.0    - 10.255.255.255  |
     |    B    | 255.255.0.0   | 172.16.0.0  - 172.31.255.255  |
     |    C    | 255.255.255.0 | 192.168.0.0 - 192.168.255.255 |
     -----------------------------------------------------------

Primero debería decidir cuán grande quiere que sea su red para
entonces elegir tantas direcciones como necesite.

5.2. ¿Dónde debería poner las órdenes de configuración?

Hay unas pocas opciones a elegir para el procedimiento de arranque del
sistema Linux. Después de que carga el núcleo, siempre ejecuta un
programa llamado init. El programa init lee entonces el fichero de
configuración llamado /etc/inittab y comienza el proceso de arranque.
Hay unos pocos init diferentes, aunque todo el mundo está ahora
convergiendo al modelo SystemV, desarrollado por Miguel van
Smoorenburg.

A pesar de que el programa init sea el mismo, la configuración del
arranque del sistema está organizada de manera diferente en cada
distribución.

Normalmente el fichero /etc/inittab contiene una entrada que dice algo
como:

       si::sysinit:/etc/init.d/boot

Esta línea especifica el nombre del fichero de guión de ejecución
(script) que controla la secuencia de carga. Este fichero es algo así
como el AUTOEXEC.BAT en MS-DOS.

El guión de arranque suele llamar a otros, y a menudo la red se
configura dentro de alguno de éstos.

La siguiente tabla puede ser usada como guía para su sistema:

----------------------------------------------------------------
Distrib. |Interfaz Configura/Encaminado|Iniciación del Servidor
----------------------------------------------------------------
Debian   | /etc/init.d/network         | /etc/rc2.d/*
----------------------------------------------------------------
Slackware| /etc/rc.d/rc.inet1          | /etc/rc.d/rc.inet2
----------------------------------------------------------------
RedHat   | /etc/rc.d/init.d/network    | /etc/rc.d/rc3.d/*
----------------------------------------------------------------

Fíjese en que Debian y Red Hat usan un directorio entero de guiones
que «levantan» los servicios del sistema (y normalmente la información
no se encuentra en esos archivos; por ejemplo, el sistema de Red Hat
almacena toda la configuración del sistema en ficheros dentro de
/etc/sysconfig, de donde es leída por los guiones de carga). Si quiere
comprender los detalles del proceso de arranque del sistema, le
sugiero que examine /etc/inittab y la documentación que acompaña a
init. Linux Journal va a publicar (o lo ha hecho ya) un artículo
tratando la iniciación del sistema, y este documento mantendrá una
referencia a él tan pronto como esté disponible en la red.

La mayoría de distribuciones modernas incluyen algún programa que le
permita configurar la mayoría de interfaces de red. Si tiene una de
éstas entonces debería ver si hace lo que usted quiere antes de acudir
a la configuración manual.

       --------------------------------------------
       Distrib.  | Programa de configuración de red
       --------------------------------------------
       RedHat    | /sbin/netcfg
       Slackware | /sbin/netconfig
       --------------------------------------------

5.3. Creación de las interfaces de red.

En muchos sistemas operativos Unix los dispositivos de red tienen
correspondencias en el directorio /dev. Esto no pasa en Linux. Los
dispositivos de red se crean de forma dinámica y por tanto no
requieren de la presencia de ficheros de dispositivo.

En la mayoría de los casos los dispositivos de red son creados
automáticamente por el controlador de dispositivos mientras se inicia
y localiza el hardware. Por ejemplo, el controlador Ethernet crea
interfaces eth[0..n] secuencialmente según va encontrado tarjetas
Ethernet. La primera tarjeta que encuentra es eth0, la segunda eth1,
etc.

Sin embargo, en algunos casos, de los que slip y ppp son ejemplos
notables, los dispositivos de red son creados por la acción de algún
programa de usuario. Se aplica la misma numeración secuencial de
dispositivos, pero no se crean al arrancar. La razón es que al
contrario que con los dispositivos Ethernet, el número de dispositivos
ppp o slip puede variar durante la actividad de la máquina. Estos
casos serán cubiertos con más detalle en secciones posteriores.

5.4. Configuración de una interfaz de red.

Cuando tenga todos los programas necesarios y su dirección e
información de red, puede configurar la interfaz de red. Cuando
hablamos de configurar una interfaz de red nos referimos al proceso de
asignar direcciones apropiadas a un dispositivo y asignar valores
adecuados a otros parámetros configurables. El programa usado más
comúnmente para hacer esto es la orden ifconfig (interface configure).

Lo normal será usar una orden similar a la siguiente:

       root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up

En este caso estoy configurando la interfaz Ethernet eth0, con
dirección IP 192.168.0.1 y máscara de red 255.255.255.0. El `up del
final de la orden le dice al interfaz que debería activarse, pero
normalmente se puede omitir, ya que es el valor por defecto. Para
desactivar una interfaz, simplemente tiene que ejecutar ifconfig eth0
down.

El núcleo asume ciertas cosas cuando configura interfaces. Por
ejemplo, puede especificar la dirección de red y difusión de una
interfaz, pero si usted no lo hace, como en mi ejemplo anterior,
entonces el núcleo hará una suposición razonable de cuáles deberían
ser, basándose en la máscara que se le proporciona; si tampoco indica
la máscara, entonces partirá de la clase de la dirección IP
configurada. En mi ejemplo, el núcleo asumirá que se va a configurar
una red clase C en la interfaz y establece una dirección de red
192.168.0.0 y una dirección de difusión 192.168.0.255. Hay otras
muchas opciones para la orden ifconfig. Las mas importantes son:

up esta opción activa una interfaz (y es la opción por defecto).

down
esta opción desactiva una interfaz.

[-]arp
esta opción activa o desactiva el uso del protocolo de
resolución de dirección (address resolution protocol) sobre la
interfaz

[-]allmulti
esta opción activa o desactiva la recepción de todos los
paquetes multicast por hardware. El multicast por hardware
permite que varios grupos de interfaces reciban paquetes
remitidos a destinos especiales. Esto puede ser de importancia
si está usando aplicaciones como videoconferencia, pero
normalmente no se usa.

mtu N
este parámetro le permite especificar la MTU del dispositivo.

netmask directorio
este parámetro le permite asignar la máscara de la red a la que
pertenece el dispositivo.

irq directorio
este parámetro sólo trabaja con ciertos tipos de hardware, y
permite especificar la IRQ del dispositivo.

[-]broadcast [directorio]
este parámetro le permite activar y asignar la acepción de
datagramas destinados a la dirección de difusión, o desactivarla
por completo.

[-]pointopoint [directorio]
este parámetro le permite asignar la dirección de la máquina en
el otro extremo de un enlace punto a punto, como en SLIP o PPP.

hw tipo directorio
este parámetro le permite asignar la dirección del hardware de
ciertos tipos de dispositivos de red. Esto no suele ser útil
para Ethernet, pero lo es para otras redes como AX.25.

Puede usar la orden ifconfig sobre cualquier dispositivo de red.
Algunos programas de usuario, como pppd y dip configuran
automáticamente los dispositivos de red al crearlos, por lo que es
innecesario el uso de ifconfig con ellos.

5.5. Resolver ) Configuración del sistema de resolución de nombres (
Name

El sistema de resolución de nombres es una parte de la biblioteca
estándar de Linux. Su función principal es proporcionar un servicio
para convertir las denominaciones «amistosas con el hombre» de las
máquinas como ftp.funet.fi a direcciones IP «amigables para la
máquina» como 128.214.248.6.

5.5.1. ¿Qué hay en un nombre?

Posiblemente esté familiarizado con la apariencia de los nombres de
máquina de Internet, pero puede que no entienda como se construyen, o
como se «desconstruyen». Los nombres de dominio de Internet son
jerárquicos por naturaleza; esto es, tienen una estructura en árbol.
Un dominio es una familia, o grupo de nombres. Un dominio puede ser
fragmentado en subdominios. Un «dominio de nivel superior» (toplevel
domain) es un dominio que NO es un subdominio. Los Dominios de Nivel
Superior están especificados en el RFC-920. Algunos ejemplos de los
más comunes son:

COM
Organizaciones Comerciales

EDU
Organizaciones Educativas

GOV
Organizaciones Gubernamentales

MIL
Organizaciones Militares

ORG
Otras organizaciones

NET
Organizaciones relacionadas con InterNet

Designador de País
éstos son códigos de dos letras que representan a un país en
particular.

Por razones históricas, la mayoría de los dominios pertenecientes a
uno de los de nivel superior que no basados en un nombre de país, son
de organizaciones dentro de los Estados Unidos, aunque los Estados
Unidos tienen también su propio código de país .us. Esto ha dejado de
ser cierto para los dominios .com y .org, que son usados de forma
común por compañías de fuera de los Estados Unidos de América.

Cada uno de estos dominios de nivel superior tiene subdominios. Los
dominios de nivel superior basados en el nombre de un país suelen
estar divididos en subdominios basados en com, edu, gov, mil y org.
Por ejemplo, encontrará cosas como com.au y gov.au, las organizaciones
comerciales y gubernamentales en Australia.

El siguiente nivel de división suele representar el nombre de la
organización. Los siguientes subdominios varían, a menudo basando el
siguiente nivel en la estructura departamental de la organización a la
que pertenecen, pero pueden estarlo en cualquier criterio considerado
razonable y con significado claro para los administradores de la red
de la organización.

La parte más a la izquierda de un nombre siempre es el nombre único
asignado a la máquina, y es llamada hostname, la porción del nombre a
la derecha del nombre de la máquina es el domainname (nombre de
dominio), y el nombre completo es llamado Fully Qualified Domain Name
(Nombre de Dominio Completamente Cualificado).

Si usamos el ordenador de Terry como ejemplo, el nombre completamente
cualificado es perf.no.itg.telstra.com.au. Esto significa que el
nombre de la máquina es perf y el nombre de dominio el
no.itg.telstra.com.au. El nombre de dominio está basado en un dominio
de nivel superior basado en su país, Australia, y como su dirección de
correo pertenece a una organización comercial tenemos .com como
siguiente nivel de dominio. El nombre de la compañía es (era)
telstra, y la estructura interna de su nombre está basada en una
estructura organizacional. En su caso, la máquina pertenece al Grupo
de Tecnología de la Información (Information Technology Group),
sección de Operaciones de Red (Network Operations).

Los nombres son, por norma, bastante más cortos; por ejemplo, mi PSI
se llama systemy.it y mi organización sin ánimo de lucro se llama
linux.it, sin subdominio com ni org, por lo que mi propia máquina se
llama morgana.systemy.it y rubini@linux.it es una dirección de correo
electrónico válida. Sepa que el dueño de un dominio tiene derecho
tanto para registrar una máquina como para registrar subdominios; por
ejemplo, el GUL (Grupo de Usuarios de Linux) al que pertenezco usa el
dominio pluto.linux.it, porque los dueños de linux.it convinieron en
abrir un subdominio para el GUL.

5.5.2. Qué información necesitará

Necesitará saber a qué dominio pertenecen sus máquinas. El software de
resolución de nombres proporciona el servicio de traducción haciendo
consultas a un Servidor de Nombres de Dominio (Domain Name Server),
por lo que deberá saber la dirección IP del servidor de nombres
(nameserver) local que vaya a usar.

Hay tres ficheros que es necesario editar. Los comentaré uno a uno.

5.5.3. /etc/resolv.conf

/etc/resolv.conf es el fichero de configuración principal del código
de resolución de nombres. Su formato es bastante simple. Es un fichero
de texto con una palabra clave por línea. Hay tres palabras clave de
uso frecuente, que son:

domain
esta palabra clave especifica el nombre de dominio local.

search
ésta especifica una lista de dominios alternativos para
completar el nombre de una máquina.

nameserver
ésta, que puede utilizarse varias veces, especifica una
dirección IP de un servidor de nombres de dominio para
consultarlo cuando se resuelvan nombres.

Su /etc/resolv.conf podría parecerse a éste:

       domain maths.wu.edu.au
       search maths.wu.edu.au wu.edu.au
       nameserver 192.168.10.1
       nameserver 192.168.12.1

Este ejemplo especifica que el nombre de dominio por defecto para
añadir a los nombres no cualificados (esto es, nombres de máquinas
suministrados sin dominio) es maths.wu.edu.au, y que si no se
encuentra la máquina en este dominio intentemos también el dominio
wu.edu.au directamente. Se proporcionan dos entradas de servidor de
nombres, cada uno de los cuales puede ser llamado por el código de
resolución de nombres para traducir el nombre.

5.5.4. /etc/host.conf

El fichero /etc/host.conf es el lugar donde se configuran algunos
elementos que gobiernan el comportamiento del código de resolución de
nombres. El formato de este fichero está descrito en detalle en la
página de manual resolv+. El ejemplo siguiente funcionará en casi
todas las circunstancias:

       order hosts,bind
       multi on

Esta configuración le dice al resolutor de nombres que examine el
fichero /etc/hosts antes de intentar consultar a un servidor de
nombres, y que devuelva todas las direcciones válidas de una máquina
que encuentre en el fichero /etc/hosts, en lugar de sólo el primero.

5.5.5. /etc/hosts

El fichero /etc/hosts es donde se pone el nombre y dirección IP de las
máquinas locales. Si usted inserta un nombre en este fichero, entonces
su ordenador no consultará a un servidor de dominio para obtener la
dirección IP. La desventaja de este método es que usted mismo tendrá
que poner el fichero al día si la dirección de alguna máquina cambia.
En un sistema bien administrado, las únicas entradas que suelen
aparecer son la interfaz de loopback (prueba en bucle) y el nombre de
la máquina local.

       # /etc/hosts
       127.0.0.1      localhost loopback
       192.168.0.1    this.host.name

Se puede especificar más de un nombre de máquina por línea, como se
demuestra en la primera entrada, que es la forma estándar para la
interfaz de prueba (loopback).

5.5.6. Ejecutar un servidor de nombres

Si quiere tener un servidor de nombres local, le resultará sencillo.
Por favor, lea el DNS Como, http://www.insflug.org/documentos/DNS-
Como/ y la documentación incluida en su copia de BIND (Berkeley
Internet Name Domain).

5.6. Configuración de la interfaz loopback

La interfaz loopback’ es un tipo especial de interfaz que le permite
hacer conexiones consigo mismo. Hay varias razones por las que podría
querer esto. Por ejemplo, puede que desee probar algún tipo de
programa sin interferir con alguien más en su red. Por convención, la
dirección de red IP 127.0.0.1 ha sido asignada específicamente para el
dispositivo de pruebas. Por lo que da igual lo que haga su máquina,
que si abre una conexión de telnet a 127.0.0.1, siempre llegará a la
interfaz interna.

Configurar la interfaz loopback es simple y debería asegurarse de
hacerlo.

       root# ifconfig lo 127.0.0.1
       root# route add -host 127.0.0.1 lo

Hablaremos más de la orden route en la siguiente sección.

5.7. Encaminamiento ( Routing ).

El encaminamiento es un tema amplio. Sería fácil llenar varios
volúmenes hablando de él. La mayoría de ustedes tendrán requisitos de
encaminamiento relativamente simples, pero algunos no. Cubriré
solamente algunos de los fundamentos básicos. Si está interesado en
información más detallada, entonces sugiero que se remita a las
referencias propuestas al principio del documento.

Comencemos con una definición. ¿Qué es el encaminamiento IP? Esta es
la que yo suelo aplicar:

El Encaminamiento IP es el proceso por el que una máquina
con múltiples conexiones de red decide por dónde dirigir un
datagrama IP que haya recibido.

Sería útil ilustrar esto con un ejemplo. Imagine una oficina con el
encaminamiento típico, que podría constar de un enlace PPP con
Internet, varios segmentos Ethernet alimentando las estaciones de
trabajo, y un enlace PPP hacia otra oficina. Cuando el encaminador
recibe un datagrama en cualquiera de sus conexiones de red, el
mecanismo que usa para determinar qué interfaz debería enviar el
datagrama, es el encaminamiento. Las estaciones sencillas también
necesitan encaminar. Todas las estaciones en Internet tienen dos
dispositivos de red: uno es la interfaz de pruebas descrita
anteriormente, y la otra es la que usa para comunicarse con el resto
de la red, quizá una Ethernet, quizá una interfaz serie PPP o SLIP.

Bien… Por tanto, ¿cómo funciona el encaminado? Cada máquina tiene
una lista de reglas, llamada tabla de encaminamiento. Esta tabla
contiene columnas que suelen contener al menos tres campos: el primero
es una dirección de destino, el segundo es el nombre de la interfaz a
la que se va a encaminar el datagrama, y el tercero es (opcionalmente)
la dirección IP de otra máquina que cogerá el datagrama en su
siguiente paso a través de la red. En Linux puede ver esta tabla
usando la siguiente orden:

       root# cat /proc/net/route

o con cualquiera de estas otras:

       root# /sbin/route -n
       root# /bin/netstat -r

El proceso de encaminado es relativamente simple: se recibe un
datagrama que llega, se examina la dirección de destino (para quién
es) y se compara con cada entrada en la lista. Se selecciona la
entrada que más se parezca y se reenvía el datagrama a la interfaz
especificada. Si el campo de pasarela (gateway) está descrito, el
datagrama se reenvía a esa máquina mediante la interfaz especificada,
y si no, se asume que la dirección de destino está en la red a la que
se accede mediante la interfaz correspondiente.

Para manipular esta tabla se usa una orden especial. Esta instrucción
toma sus argumentos en línea de órdenes y los convierte en llamadas al
sistema del núcleo, que le piden que añada, borre o modifique entradas
en la tabla de encaminamiento. Dicha orden se llama route.

Un ejemplo sencillo. Imagine que tiene una red Ethernet. Le han dicho
que pertenece a una red clase C con dirección 192.168.1.0. Le han dado
la dirección IP 192.168.1.10 para su uso y también que 192.168.1.1 es
un encaminador conectado a Internet.

El primer paso es configurar la interfaz como se describió
anteriormente. Puede usar una orden como:

       root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up

Ahora necesita añadir una entrada en la tabla de rutas para decirle al
núcleo que los datagramas destinados a todas las máquinas con
direcciones que se ajusten a 192.168.1.*, deberán ser enviados al
dispositivo Ethernet. Debería usar una orden similar a:

       root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0

Fíjese en el uso del parámetro -net para especificar al programa route
que esta entrada es una regla para una red completa. Otra opción es
-host, que indica una vía específica a una dirección IP en particular.

Esta ruta le permitirá establecer conexiones IP con todas las
estaciones de su segmento Ethernet. Pero ¿qué pasa con todas las
máquinas con dirección IP que no están en su segmento Ethernet?

Sería bastante engorroso, por no decir imposible, tener que añadir
caminos para cada red de destino posible, por lo que existe un truco
que se usa para simplificar la tarea. A este truco se le llama camino
por defecto. El camino por defecto se ajusta a todo destino posible,
pero con prioridad mínima, por lo que si existe cualquier otra entrada
que se ajuste a la dirección requerida, será la que se use en lugar
del camino por defecto. La idea del camino por defecto es simplemente
permitirle decir: «y todo lo demás debería ir por aquí». En el ejemplo
que me he inventado podría usar una orden como:

       root# route add default gw 192.168.1.1 eth0

El parámetro gw le dice a la orden route que lo que le sigue es la
dirección IP, o nombre, de una pasarela u otra máquina encaminadora a
la que se deberían enviar todos los datagramas que se ajusten a esta
entrada para futuro encaminamiento.

Por lo tanto, la configuración completa debería parecerse a:

       root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
       root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
       root# route add default gw 192.168.1.1 eth0

Si echa una mirada a los ficheros rc de red de su máquina, encontrará
que al menos uno de ellos se parece mucho a esto. Es una configuración
muy común.

Veamos ahora una configuración de encaminamiento un poco más
complicada. Imaginemos que estamos configurando el encaminador de
antes, el que soportaba el enlace PPP a Internet y los segmentos LAN
alimentando las estaciones de trabajo en la oficina. Imaginemos que el
encaminador tiene tres segmentos Ethernet y un enlace PPP. Nuestra
configuración de encaminamiento debería parecerse a esto:

       root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
       root# route add -net 192.168.2.0 netmask 255.255.255.0 eth1
       root# route add -net 192.168.3.0 netmask 255.255.255.0 eth2
       root# route add default ppp0

Cada una de las estaciones debería usar la forma simple que
presentamos anteriormente. Sólo el encaminador necesita especificar
cada uno de los caminos de red de forma separada, porque para las
estaciones el mecanismo de encaminamiento por defecto enviará todos
los paquetes al encaminador, dejándole el problema de repartirlos.
Puede estar preguntándose por qué el encaminador por defecto
presentado no especifica un gw. La razón es simple: los protocolos de
enlace serie como PPP y SLIP sólo tienen dos terminales en su red, uno
en cada extremo. Especificar el host al otro extremo como pasarela no
tiene sentido y es redundante, ya que no hay otra elección, por lo que
no se necesita especificar una pasarela para este tipo de conexión de
red. Otros tipos como Ethernet, arcnet o token ring necesitan que se
especifique la pasarela, ya que se puede acceder a un gran número de
terminales al mismo tiempo.

5.7.1. Entonces ¿qué hace el programa routed ?

La configuración de encaminamiento descrita anteriormente se ajusta a
necesidades de red simples, donde los posibles caminos hacia los
destinos son sencillos. Cuando se tienen necesidades de red más
complejas, las cosas se vuelven un poco más complicadas.
Afortunadamente la mayoría de ustedes no tendrá este problema.

El gran problema con el «encaminamiento manual» o «encaminamiento
estático» que aquí se ha descrito, es que si una máquina o enlace
falla en la red, entonces la única manera en que podrá dirigir sus
datagramas por otra dirección, si es que existe, es interviniendo
manualmente y ejecutando las órdenes apropiadas. Naturalmente esto es
poco elegante, lento, nada práctico y peligroso. Se han desarrollado
varias técnicas para ajustar automáticamente las tablas de
encaminamiento en el caso de fallos en la red donde hubiera caminos
alternativos. Todas estas técnicas se agrupan de manera no muy oficial
bajo la definición «protocolos de encaminamiento dinámico».

Puede que haya oído de alguno de los protocolos más comunes. Es
probable que RIP (Routing Information Protocol) y OSPF (Open Shortest
Path First Protocol) sean los más comunes. El Routing Information
Protocol es muy común en redes pequeñas, como las redes corporativas
pequeñas y medianas o en las redes de edificios. El OSPF es más
moderno y más capaz de gestionar grandes configuraciones de red, y
está mejor preparado para entornos donde haya un gran número de
caminos posibles a través de la red. Las implementaciones habituales
de estos protocolos son: routed (RIP) y gated (RIP, OSPF y otros). El
programa routed suele venir incluido en las distribuciones de Linux, y
si no, estará incluido en el paquete NetKit, detallado más adelante.

Un ejemplo de dónde y cómo debería usar un protocolo de encaminamiento
dinámico vendría a ser algo como lo siguiente:

     192.168.1.0 /                         192.168.2.0 /
       255.255.255.0                         255.255.255.0
     -                                     -
     |                                     |
     |   /-----\                 /-----\   |
     |   |     |ppp0   //    ppp0|     |   |
eth0 |---|  A  |------//---------|  B  |---| eth0
     |   |     |     //          |     |   |
     |   \-----/                 \-----/   |
     |      \ ppp1             ppp1 /      |
     -       \                     /       -
              \                   /
               \                 /
                \               /
                 \             /
                  \           /
                   \         /
                    \       /
                     \     /
                  ppp0\   /ppp1
                     /-----\
                     |     |
                     |  C  |
                     |     |
                     \-----/
                        |eth0
                        |
                   |---------|
                   192.168.3.0 /
                     255.255.255.0

Tenemos tres encaminadores A, B y C. Cada uno da servicio a un
segmento Ethernet con una red IP de clase C (máscara de red
255.255.255.0). Cada encaminador tiene también un enlace PPP a cada
uno de los otros encaminadores. La red forma un triángulo.

Debería estar claro que la tabla de encaminamiento del encaminador A
podría ser algo como:

root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add -net 192.168.2.0 netmask 255.255.255.0 ppp0
root# route add -net 192.168.3.0 netmask 255.255.255.0 ppp1

Esto funcionaría bien hasta que el enlace entre los encaminadores A y
B falle. Si falla ese enlace, entonces con la entrada de
encaminamiento mostrada anteriormente, las máquinas del segmento
Ethernet de A no podrán alcanzar a las del segmento Ethernet en B
porque sus datagramas serán dirigidos al enlace ppp0 de A que está
mal. Podrían seguir comunicándose todavía con las máquinas del
segmento Ethernet de C, y las del segmento Ethernet de C con las del
segmento Ethernet de B, porque el enlace entre B y C aún está intacto.

Pero espere un momento. Si A puede hablar con C y C puede aún hablar
con B, ¿por qué no puede A encaminar sus datagramas para B a través de
C y dejar que C se los mande a B? Este es exactamente el tipo de
problema para el que fueron diseñados los protocolos de encaminamiento
dinámico como RIP. Si cada uno de los encaminadores A, B y C está
ejecutando el demonio de encaminamiento, entonces sus tablas deberían
ser ajustadas automáticamente para reflejar el nuevo estado de la red
si alguno de los enlaces falla. Configurar tal red es sencillo. En
cada encaminador sólo necesita hacer dos cosas. En este caso, para el
Encaminador A:

root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# /usr/sbin/routed

El demonio de encaminamiento routed encuentra automáticamente todos
los puertos de red activos cuando comienza y busca mensajes en cada
uno de los dispositivos de red para poder determinar y poner al día la
tabla de encaminamiento en el host.

Ésta ha sido una explicación muy concisa del encaminamiento dinámico y
de dónde podría usarlo. Si quiere más información, tendrá que acudir a
las referencias listadas al principio del documento.

Los puntos importantes relacionados con el encaminamiento dinámico
son:

1. Sólo necesita ejecutar un protocolo de encaminamiento dinámico
cuando su máquina Linux tenga la posibilidad de elegir entre
múltiples caminos para llegar a un destino.

2. El demonio de encaminamiento dinámico modificará automáticamente la
tabla de encaminamiento para ajustarla a los cambios en la red.

3. RIP es adecuado para redes de tamaño pequeño y medio.

5.8. Configuración de los servidores de red y los servicios.

Los servidores de red y los servicios son aquellos programas que
permiten a un usuario remoto hacer uso de su máquina Linux. Los
programas servidores escuchan en los puertos de red. Los puertos de
red son el medio de llegar a un servicio en particular en una máquina
en particular, y es así como un servidor conoce la diferencia entre
una conexión telnet y otra de FTP que le lleguen. El usuario remoto
establece una conexión de red con la máquina, y el programa servidor,
el demonio de red que esté escuchando en ese puerto, aceptará la
conexión y se ejecutará. Hay dos modos de operación para los demonios
de red. Ambos se usan por igual en la práctica. Las dos maneras son:

autónomo (standalone)
el programa demonio de red escucha en el puerto de red asignado
y, cuando llega una conexión, se ocupa él mismo de dar el
servicio de red.

esclavo del servidor inetd
el servidor inetd es un demonio de red especial que se
especializa en controlar las conexiones entrantes. Tiene un
fichero de configuración que le dice qué programa debe ser
ejecutado cuando se reciba una conexión. Cualquier puerto de
servicio puede ser configurado tanto para el protocolo tcp como
para udp. Los puertos son descritos en otro fichero del que
hablaremos dentro de poco.

Hay dos ficheros importantes que necesitamos configurar. Son el
fichero /etc/services que asigna nombres a los números de puerto y el
fichero /etc/inetd.conf que es el fichero de configuración del demonio
de red inetd.

5.8.1. /etc/services

El fichero /etc/services es una base de datos sencilla, que asocia un
nombre que nosotros podamos entender, con un puerto de servicio de la
máquina. Su formato es bastante simple. Es un fichero de texto en el
que cada línea representa una entrada a la base de datos. Cada entrada
comprende tres campos separados por cualquier número de espacios en
blanco (espacio o tabulador). Los campos son:

nombre puerto/protocolo sobrenombres # comentario

nombre
una sola palabra que representa el servicio descrito.

puerto/protocolo
este campo está dividido en dos subcampos.

puerto
un número que especifica el número de puerto del servicio que
estará disponible. La mayoría de los servicios comunes tienen
asignados números de servicio, y están descritos en el RFC-1340.

protocolo
este subcampo debe tener como valor tcp o udp.

Es importante que tenga en cuenta que el servicio 18/tcp es muy
diferente del 18/udp y que no hay razón técnica por la cual
deban existir ambos. Normalmente prevalece el sentido común, y
sólo verá una entrada tcp y otra udp para el mismo servicio si
es que está disponible para ambos.

sobrenombres
(o alias) otros nombres que pueden usarse para referirse a esta
entrada de servicio.

Cualquier texto que aparezca en una línea después de un caracter # es
ignorado y se trata como un comentario.
5.8.1.1. Un ejemplo de fichero /etc/services .

Todas las distribuciones modernas de Linux tienen un buen fichero
/etc/services. Para el caso de que esté montando una máquina desde
cero, aquí tiene una copia del fichero /etc/services proporcionado por
una antigua la distribución Debian http://www.debian.org:

# /etc/services:
# $Id: services,v 1.3 1996/05/06 21:42:37 tobias Exp $
#
# Network services, Internet style
#
# Note that it is presently the policy of IANA to assign a single well-known
# port number for both TCP and UDP; hence, most entries here have two entries
# even if the protocol doesn’t support UDP operations.
# Updated from RFC 1340, «Assigned Numbers» (July 1992). Not all ports
# are included, only the more common ones.

tcpmux 1/tcp # TCP port service multiplexer
echo 7/tcp
echo 7/udp
discard 9/tcp sink null
discard 9/udp sink null
systat 11/tcp users
daytime 13/tcp
daytime 13/udp
netstat 15/tcp
qotd 17/tcp quote
msp 18/tcp # message send protocol
msp 18/udp # message send protocol
chargen 19/tcp ttytst source
chargen 19/udp ttytst source
ftp-data 20/tcp
ftp 21/tcp
ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp # SSH Remote Login Protocol
telnet 23/tcp
# 24 – private
smtp 25/tcp mail
# 26 – unassigned
time 37/tcp timserver
time 37/udp timserver
rlp 39/udp resource # resource location
nameserver 42/tcp name # IEN 116
whois 43/tcp nicname
re-mail-ck 50/tcp # Remote Mail Checking Protocol
re-mail-ck 50/udp # Remote Mail Checking Protocol
domain 53/tcp nameserver # name-domain server
domain 53/udp nameserver
mtp 57/tcp # deprecated
bootps 67/tcp # BOOTP server
bootps 67/udp
bootpc 68/tcp # BOOTP client
bootpc 68/udp
tftp 69/udp
gopher 70/tcp # Internet Gopher
gopher 70/udp
rje 77/tcp netrjs
finger 79/tcp
www 80/tcp http # WorldWideWeb HTTP
www 80/udp # HyperText Transfer Protocol
link 87/tcp ttylink
kerberos 88/tcp kerberos5 krb5 # Kerberos v5
kerberos 88/udp kerberos5 krb5 # Kerberos v5
supdup 95/tcp
# 100 – reserved
hostnames 101/tcp hostname # usually from sri-nic
iso-tsap 102/tcp tsap # part of ISODE.
csnet-ns 105/tcp cso-ns # also used by CSO name server
csnet-ns 105/udp cso-ns
rtelnet 107/tcp # Remote Telnet
rtelnet 107/udp
pop-2 109/tcp postoffice # POP version 2
pop-2 109/udp
pop-3 110/tcp # POP version 3
pop-3 110/udp
sunrpc 111/tcp portmapper # RPC 4.0 portmapper TCP
sunrpc 111/udp portmapper # RPC 4.0 portmapper UDP
auth 113/tcp authentication tap ident
sftp 115/tcp
uucp-path 117/tcp
nntp 119/tcp readnews untp # USENET News Transfer Protocol
ntp 123/tcp
ntp 123/udp # Network Time Protocol
netbios-ns 137/tcp # NETBIOS Name Service
netbios-ns 137/udp
netbios-dgm 138/tcp # NETBIOS Datagram Service
netbios-dgm 138/udp
netbios-ssn 139/tcp # NETBIOS session service
netbios-ssn 139/udp
imap2 143/tcp # Interim Mail Access Proto v2
imap2 143/udp
snmp 161/udp # Simple Net Mgmt Proto
snmp-trap 162/udp snmptrap # Traps for SNMP
cmip-man 163/tcp # ISO mgmt over IP (CMOT)
cmip-man 163/udp
cmip-agent 164/tcp
cmip-agent 164/udp
xdmcp 177/tcp # X Display Mgr. Control Proto
xdmcp 177/udp
nextstep 178/tcp NeXTStep NextStep # NeXTStep window
nextstep 178/udp NeXTStep NextStep # server
bgp 179/tcp # Border Gateway Proto.
bgp 179/udp
prospero 191/tcp # Cliff Neuman’s Prospero
prospero 191/udp
irc 194/tcp # Internet Relay Chat
irc 194/udp
smux 199/tcp # SNMP Unix Multiplexer
smux 199/udp
at-rtmp 201/tcp # AppleTalk routing
at-rtmp 201/udp
at-nbp 202/tcp # AppleTalk name binding
at-nbp 202/udp
at-echo 204/tcp # AppleTalk echo
at-echo 204/udp
at-zis 206/tcp # AppleTalk zone information
at-zis 206/udp
z3950 210/tcp wais # NISO Z39.50 database
z3950 210/udp wais
ipx 213/tcp # IPX
ipx 213/udp
imap3 220/tcp # Interactive Mail Access
imap3 220/udp # Protocol v3
ulistserv 372/tcp # UNIX Listserv
ulistserv 372/udp
#
# UNIX specific services
#
exec 512/tcp
biff 512/udp comsat
login 513/tcp
who 513/udp whod
shell 514/tcp cmd # no passwords used
syslog 514/udp
printer 515/tcp spooler # line printer spooler
talk 517/udp
ntalk 518/udp
route 520/udp router routed # RIP
timed 525/udp timeserver
tempo 526/tcp newdate
courier 530/tcp rpc
conference 531/tcp chat
netnews 532/tcp readnews
netwall 533/udp # -for emergency broadcasts
uucp 540/tcp uucpd # uucp daemon
remotefs 556/tcp rfs_server rfs # Brunhoff remote filesystem
klogin 543/tcp # Kerberized `rlogin’ (v5)
kshell 544/tcp krcmd # Kerberized `rsh’ (v5)
kerberos-adm 749/tcp # Kerberos `kadmin’ (v5)
#
webster 765/tcp # Network dictionary
webster 765/udp
#
# From «Assigned Numbers»:
#
# The Registered Ports are not controlled by the IANA and on most systems
# can be used by ordinary user processes or programs executed by ordinary
# users.
#
# Ports are used in the TCP [45,106] to name the ends of logical
# connections which carry long term conversations. For the purpose of
# providing services to unknown callers, a service contact port is
# defined. This list specifies the port used by the server process as its
# contact port. While the IANA can not control use of these ports it
# does register or list use of these ports as a convienence to the
# community.
#
ingreslock 1524/tcp
ingreslock 1524/udp
prospero-np 1525/tcp # Prospero non-privileged
prospero-np 1525/udp
rfe 5002/tcp # Radio Free Ethernet
rfe 5002/udp # Actually use UDP only
bbs 7000/tcp # BBS service
#
#
# Kerberos (Project Athena/MIT) services
# Note that these are for Kerberos v4 and are unofficial. Sites running
# v4 should uncomment these and comment out the v5 entries above.
#
kerberos4 750/udp kdc # Kerberos (server) udp
kerberos4 750/tcp kdc # Kerberos (server) tcp
kerberos_master 751/udp # Kerberos authentication
kerberos_master 751/tcp # Kerberos authentication
passwd_server 752/udp # Kerberos passwd server
krb_prop 754/tcp # Kerberos slave propagation
krbupdate 760/tcp kreg # Kerberos registration
kpasswd 761/tcp kpwd # Kerberos “passwd”
kpop 1109/tcp # Pop with Kerberos
knetd 2053/tcp # Kerberos de-multiplexor
zephyr-srv 2102/udp # Zephyr server
zephyr-clt 2103/udp # Zephyr serv-hm connection
zephyr-hm 2104/udp # Zephyr hostmanager
eklogin 2105/tcp # Kerberos encrypted rlogin
#
# Unofficial but necessary (for NetBSD) services
#
supfilesrv 871/tcp # SUP server
supfiledbg 1127/tcp # SUP debugging
#
# Datagram Delivery Protocol services
#
rtmp 1/ddp # Routing Table Maintenance Protocol
nbp 2/ddp # Name Binding Protocol
echo 4/ddp # AppleTalk Echo Protocol
zip 6/ddp # Zone Information Protocol
#
# Debian GNU/Linux services
rmtcfg 1236/tcp # Gracilis Packeten remote config server
xtel 1313/tcp # french minitel
cfinger 2003/tcp # GNU Finger
postgres 4321/tcp # POSTGRES
mandelspawn 9359/udp mandelbrot # network mandelbrot

# Local services

En el día a día, este fichero se encuentra en proceso de continuo
crecimiento según se van creando nuevos servicios. Si piensa que su
copia es incompleta, le sugiero que haga una copia del /etc/services
de una distribución reciente.

5.8.2. /etc/inetd.conf

/etc/inetd.conf es el fichero de configuración para el demonio
servidor inetd. Su función es la de almacenar la información relativa
a lo que inetd debe hacer cuando recibe una petición de conexión a un
servicio en particular. Para cada servicio que desee que acepte
conexiones deberá decirle a inetd qué demonio servidor de red
ejecutar, y cómo ha de hacerlo.

Su formato también es relativamente sencillo. Es un fichero de texto
en el que cada línea describe un servicio que desee proporcionar.
Cualquier texto en una línea que siga a # es ignorado y se considera
un comentario. Cada línea contiene siete campos separados por
cualquier número de espacios en blanco (espacio o tabulador). El
formato general es el siguiente:

servicio tipo_socket proto flags usuario servidor argumentos

servicio
es el servicio correspondiente a esta configuración, tomado del
fichero /etc/services.

tipo_socket
describe el tipo de socket que esta entrada considerará
relevante. Los valores permitidos son: stream, dgram, raw, rdm o
seqpacket. Es un poco técnico por naturaleza, pero por regla
general casi todos los servicios basados en tcp usan stream, y
casi todos los basados en udp usan dgram. Sólo algunos demonios
servidores muy particulares usarán otros valores.

proto
el protocolo considerado válido para este servicio. Debería
corresponder con la entrada apropiada en el fichero
/etc/services y suele ser tcp o udp. Los servidores basados en
Sun RPC (Remote Procedure Call) usarán rpc/tcp o rpc/udp.
flags
sólo hay dos valores posibles. Este campo le dice a inetd si el
programa servidor de red libera el socket después de comenzar la
ejecución, y si por tanto inetd podrá ejecutar otro servidor
para la siguiente petición de conexión, o si inetd deberá
esperar y asumir que el demonio servidor que esté ejecutándose
controlará las nuevas peticiones de conexión. Esto tiene su
dificultad, pero por norma general todos los servidores tcp
deberían tener esta entrada con el valor nowait y la mayoría de
servidores udp deberían tener wait. De todas maneras hay
algunas excepciones notables, por lo que debería leer la guía de
ejemplo si no está seguro.

usuario
este campo indica qué cuenta de usuario de /etc/passwd será
asignada como dueña del demonio de red cuando se ejecute. Esto
es a menudo útil si quiere protegerse ante riesgos de seguridad.
Puede asignar el usuario nobody a una entrada, por lo que si la
seguridad del servidor de red es traspasada el posible daño
queda minimizado. Habitualmente, sin embargo, este campo está
asignado a root, porque muchos servidores requieren privilegios
de administrador para funcionar correctamente.

servidor
este campo es el camino completo hasta el programa servidor a
ejecutar para esta entrada.

argumentos
este campo comprende el resto de la línea de órdenes y es
opcional. Es en donde se pone cualquier argumento de línea de
órdenes que desee pasar al programa demonio servidor cuando es
ejecutado.

5.8.2.1. Un ejemplo de /etc/inetd.conf

Al igual que pasa con el /etc/services, todas las distribuciones
modernas incluirán un buen fichero /etc/inetd.conf para trabajar con
él. Aquí incluyo, como ejemplo, el fichero /etc/inetd.conf de la
distribución Debian http://www.debian.org.

# /etc/inetd.conf: see inetd(8) for further informations.
#
# Internet server configuration database
#
#
# Modified for Debian by Peter Tobias tobias@et-inf.fho-emden.de
#
# service_name sock_type proto flags user server_path args
#
# Internal services
#
#echo stream tcp nowait root internal
#echo dgram udp wait root internal
discard stream tcp nowait root internal
discard dgram udp wait root internal
daytime stream tcp nowait root internal
daytime dgram udp wait root internal
#chargen stream tcp nowait root internal
#chargen dgram udp wait root internal
time stream tcp nowait root internal
time dgram udp wait root internal
#
# These are standard services.
#
telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd
ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.ftpd
#fsp dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.fspd
#
# Shell, login, exec and talk are BSD protocols.
#
shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd
login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rexecd
talk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.talkd
ntalk dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.ntalkd
#
# Mail, news and uucp services.
#
smtp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.smtpd
#nntp stream tcp nowait news /usr/sbin/tcpd /usr/sbin/in.nntpd
#uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico
#comsat dgram udp wait root /usr/sbin/tcpd /usr/sbin/in.comsat
#
# Pop et al
#
#pop-2 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.pop2d
#pop-3 stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.pop3d
#
# `cfinger’ is for the GNU finger server available for Debian. (NOTE: The
# current implementation of the `finger’ daemon allows it to be run as `root’.)
#
#cfinger stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.cfingerd
#finger stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.fingerd
#netstat stream tcp nowait nobody /usr/sbin/tcpd /bin/netstat
#systat stream tcp nowait nobody /usr/sbin/tcpd /bin/ps -auwwx
#
# Tftp service is provided primarily for booting. Most sites
# run this only on machines acting as “boot servers.”
#
#tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd
#tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /boot
#bootps dgram udp wait root /usr/sbin/bootpd bootpd -i -t 120
#
# Kerberos authenticated services (these probably need to be corrected)
#
#klogin stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind -k
#eklogin stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind -k -x
#kshell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rshd -k
#
# Services run ONLY on the Kerberos server (these probably need to be corrected)
#
#krbupdate stream tcp nowait root /usr/sbin/tcpd /usr/sbin/registerd
#kpasswd stream tcp nowait root /usr/sbin/tcpd /usr/sbin/kpasswdd
#
# RPC based services
#
#mountd/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.mountd
#rstatd/1-3 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rstatd
#rusersd/2-3 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rusersd
#walld/1 dgram rpc/udp wait root /usr/sbin/tcpd /usr/sbin/rpc.rwalld
#
# End of inetd.conf.
ident stream tcp nowait nobody /usr/sbin/identd identd -i

5.9. Otros ficheros de configuración relacionados con la red

Hay varios ficheros misceláneos relacionados con la configuración de
la red en Linux por los que podría estar interesado. Nunca debería
tener que modificar estos ficheros, pero merece la pena describirlos
para que sepa lo que contienen y para qué son.

Redes en Linux Parte 2

Los comentarios están cerrados.