<!-- 0,1 -->
<!-- NET-3,0 -->
<!-- Joshua,Drake,poet@linuxports.com -->
<!-- Terry,Dawson,terry@perf.no.itg.telstra.com.au -->
<!-- Alessandro,Rubini,rubini@linux.it -->
<!-- 1.2,1997-08-20 -->
<!-- Ricardo Javier,Cárdenes Medina,a1402@serdis.dis.ulpgc.es -->
<!-- 0.1,1999-10-08 -->
<!-- NET,RED -->
<!-- Adm. Sistemas,Redes -->

<!-- Revisión 0.3 -->
<!doctype linuxdoc system>

<article>
<title>Redes en Linux Como (Previamente Net-3 Como)

<author>Autor actual: Joshua Drake, {Poet}, <tt><htmlurl
url="mailto:poet@linuxports.com" name="poet@linuxports.com"></tt> &nl;
Autores originales:
Terry Dawson (autor principal), <tt><htmlurl
url="mailto:terry@perf.no.itg.telstra.com.au"
name="terry@perf.no.itg.telstra.com.au"></tt>; Alessandro Rubini, <tt><htmlurl
url="mailto:rubini@linux.it" name="rubini@linux.it"></tt> (mantenimiento) &nl;
Traducido por: Ricardo Javier Cárdenes Medina, <tt><htmlurl
url="mailto:a1402@serdis.dis.ulpgc.es" name="a1402@serdis.dis.ulpgc.es">
</tt>&nl;
<date>v1.5, 20 de agosto de 1997, traducción del 3 de septiembre de 1999

<abstract>
Este <em/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.
</abstract>

<toc>

<sect>Introducción.
<p>

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 <tt>Como</tt>s de los que nos
encargamos, se va a convertir en algo muy diferente. Dentro de poco pasará
a ser el <it>Redes en Linux Como</it> en lugar de ser sólo el <it>Net-3(4)
Como</it>. Va a cubrir temas como PPP, VPN (Redes Privadas Virtuales), y
otros...

<sect>Historia del documento
<p>

El <it/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
<it/NET-2-HOWTO/ sobreseyó el <it/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 <tt/2.0.x/ y <tt/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.

<sect1>Comentarios y sugerencias
<p>

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: <htmlurl url="mailto:poet@linuxports.com"
name="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.

<sect>Cómo usar este documento.
<p>

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:

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

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

<tag>Lea la sección <ref id="IP y Ethernet" name="IP y Ethernet"> si está
conectado directamente a una LAN o a Internet</tag>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.

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

<tag>Lea las secciones específicas a tecnologías relacionadas con sus
necesidades</tag>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.

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

<tag>Busque más ayuda si la necesita</tag>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.

<tag>¡Diviértase!</tag>Trabajar en red es divertido, disfrútelo.

</descrip>

<sect1>Convenciones usadas en el documento
<p>

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 <tt>usuario&dollar;</tt> para las órdenes que no
necesitan que las ejecute el root. He escogido usar <tt>root&num;</tt> en
lugar de un simple <tt>&num;</tt> para evitar confusiones con los trozos
dispersos de guiones (<it>shell script</it>), donde la almohadilla
(&num;) 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 <tt/menuconfig/. Deberían ser comprensibles
incluso si usted (al igual que yo) no está acostumbrado a usar
<tt/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 <tt><htmlurl
url="http://www.linuxdoc.org" name="www.linuxdoc.org"></tt> (directorio
<tt>/pub/Linux/HOWTO</tt>) y en sus incontables servidores réplica
(<it>mirror sites</it>).

<sect>Información general sobre las redes en Linux.
<p>

<sect1>Breve historia del desarrollo del <it>Linux Networking Kernel</it>.
<p>

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, <tt><htmlurl url="mailto:biro@yggdrasil.com"
name="biro@yggdrasil.com"></tt>. 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, <tt><htmlurl url="mailto:obz@Kodak.COM"
name="obz@Kodak.COM"></tt>, 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, <tt><htmlurl
url="mailto:loz@holmes.demon.co.uk" name="loz@holmes.demon.co.uk"></tt>
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,
<tt><htmlurl url="mailto:waltje@uwalt.nl.mugnet.org"
name="waltje@uwalt.nl.mugnet.org"></tt>.  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 <it/NET-2/ (el código <it/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 <it/Amateur Radio AX.25/ y
una interfaz de red diseñada más modularmente.  El código <it/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 <it/NET-FAQ/ y el subsecuente
<it/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, <tt><htmlurl url="mailto:iialan@www.uk.linux.org"
name="iialan@www.uk.linux.org"></tt> propuso una solución al problema
diseñada para resolver la situación. Propuso que él podría coger el
código <it/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 <it/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, <tt><htmlurl url="mailto:becker@cesdis.gsfc.nasa.gov"
name="becker@cesdis.gsfc.nasa.gov"></tt> 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 <it/NET-2-Debugged/ durante un tiempo
mientras trabajaba en solucionar algunos de los problemas que quedaban
sin mirar en la lista <tt/PORHACER/. Por la época en que al código fuente
<tt/1.3.*/ del núcleo les estaban creciendo los dientes, el código de red
había migrado a la entrega <it/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, <tt><htmlurl url="mailto:callahan@maths.ox.ac.uk"
name="callahan@maths.ox.ac.uk"></tt> y Al Longyear <tt><htmlurl
url="mailto:longyear@netcom.com" name="longyear@netcom.com"></tt>
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, <tt><htmlurl url="mailto:jsn@cs.nott.ac.uk"
name="sn@cs.nott.ac.uk"></tt> 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.

<sect1>Recursos referentes al tratamiento de redes con Linux.
<label id="recursos">
<p>

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 <it/LinuxPorts Consultants Database/, <tt><htmlurl
url="http://www.linuxports.com/" name="http://www.linuxports.com"></tt>

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: <tt><htmlurl
url="http://www.uk.linux.org/NetNews.html" name="www.uk.linux.org"></tt>.

Otro buen sitio es un libro escrito por Olaf Kirch titulado la <tt/Guía para
Administradores de Redes/. Es parte del Proyecto de Documentación de Linux
<tt><htmlurl url="http://www.linuxdoc.org/"
name="http://www.linuxdoc.org"></tt> y puede leerlo de forma interactiva en su
versión HTML <tt><htmlurl url="http://metalab.unc.edu/LDP/LDP/nag/nag.html"
name="http://metalab.unc.edu/LDP/LDP/nag/nag.html"></tt>, u obtenerlo en varios
formatos mediante FTP (y en castellano) desde el archivo del proyecto LuCAS
<tt><htmlurl url="ftp://lucas.hispalinux.es/pub/LuCAS/Manuales-LuCAS/GARL"
name="ftp://lucas.hispalinux.es/pub/LuCAS/Manuales-LuCAS/GARL"></tt>.  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: <tt><htmlurl
url="news:comp.os.linux.networking" name="comp.os.linux.networking"></tt>

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:

<tscreen><verb>
A: majordomo@vger.rutgers.edu
Asunto: cualquier cosa
Mensaje:

subscribe linux-net
</verb></tscreen>

En las diferentes redes de IRC suele haber canales <tt/&num;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 <tt/pppd/ o
<tt/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.

<sect1>Dónde conseguir información sobre redes no específica de
Linux.
<p>

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:

<descrip>

<tag>TCP/IP Introduction</tag> este documento está tanto en versión texto
<tt><htmlurl url="ftp://athos.rutgers.edu/runet/tcp-ip-intro.doc"
name="ftp://athos.rutgers.edu/runet/tcp-ip-intro.doc"></tt> como en
versión PostScript <tt><htmlurl
url="ftp://athos.rutgers.edu/runet/tcp-ip-intro.ps"
name="ftp://athos.rutgers.edu/runet/tcp-ip-intro.ps"></tt>.

<tag>TCP/IP Administration </tag> este documento está tanto en versión
texto <tt><htmlurl url="ftp://athos.rutgers.edu/runet/tcp-ip-admin.doc"
name="ftp://athos.rutgers.edu/runet/tcp-ip-admin.doc"></tt> como en
versión PostScript <tt><htmlurl
url="ftp://athos.rutgers.edu/runet/tcp-ip-admin.ps"
name="ftp://athos.rutgers.edu/runet/tcp-ip-admin.ps"></tt>.

</descrip>

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

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

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

<quote>
<em>Unix Network Programming</em>, by W. Richard Stevens, ISBN 0-13-949876-1,
Prentice Hall publications, 1990.
</quote>

También debería probar el grupo de noticias <tt><htmlurl
url="news:comp.protocols.tcp-ip" name="comp.protocols.tcp-ip"></tt>.
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 <it/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
<tt><htmlurl url="http://pubweb.nexor.co.uk/public/rfc/index/rfc.html"
name="http://pubweb.nexor.co.uk/public/rfc/index/rfc.html"></tt>.

<sect>Información genérica sobre la configuración de redes.
<p>

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.

<sect1>¿Qué necesito para comenzar?
<p>

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

<sect2>Código fuente del núcleo.
<p>

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 &nl; <tt><htmlurl
url="ftp://ftp.cdrom.com/pub/linux/sunsite/kernel.org/pub/linux/kernel"
name="ftp://ftp.cdrom.com/pub/linux/sunsite/kernel.org/pub/linux/kernel">
</tt>.  Este no es el sitio oficial, pero tiene un GRAN ancho de banda y
permite que MUCHOS usuarios conecten simultáneamente. El sitio oficial es
<tt/kernel.org/, pero use el anterior si tiene la posibilidad. Por favor,
recuerde que <tt/ftp.kernel.org/ está seriamente sobrecargado. Use un
servidor réplica.

Normalmente las fuentes del núcleo se instalarán en el directorio
<tt>/usr/src/linux</tt>. Para más información sobre cómo aplicar parches
y construir el núcleo debería leer el <tt><htmlurl url="Kernel-Como.html"
name="Kernel Como"></tt>. Para más información sobre cómo configurar
módulos del núcleo debería leer el <it/Modules mini-Howto/. Además, el
fichero <tt>README</tt> que hay en las fuentes del núcleo y el directorio
<tt>Documentation</tt> 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 <tt/2.1/, por lo que
tendrá que tomar una decisión: puede mantenerse en <tt/2.0/ mientras
espera por el <tt/2.2/ y por una distribución con cada herramienta
actualizada, o puede coger un <tt/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
<tt/2.1.115/ y se espera que el <tt/2.2/ aparezca pronto.

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

<sect2>Herramientas de red actualizadas.
<p>

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:
<!-- NOTA: revisado por última vez en la RH-5.1, ago 98 -->

<tt><htmlurl url="ftp://ftp.inka.de/pub/comp/Linux/networking/NetTools/"
name="ftp://ftp.inka.de/pub/comp/Linux/networking/NetTools/"></tt> y están
replicadas en: <tt><htmlurl
url="ftp://ftp.uk.linux.org/pub/linux/Networking/base/"
name="ftp://ftp.uk.linux.org/pub/linux/Networking/base/"></tt>.

También puede encontrar los últimos paquetes de RedHat en <tt><htmlurl
url="ftp://ftp.cdrom.com/pub/linux/redhat/redhat-6.0/i386/base/"
name="ftp://ftp.cdrom.com/pub/linux/redhat/redhat-6.0/i386/base/net-tools-1.51-3.i386.rpm"></tt>.

Para Debian, los paquetes que traen las principales herramientas son los
paquetes <tt>hostname</tt>, <tt>netbase</tt> y <tt>netstd</tt>, que
encontrará en <tt><htmlurl
url="ftp://ftp.debian.org/debian/dists/stable/main/binary-i386/base/"
name="ftp://ftp.debian.org/debian/dists/stable/main/binary-i386/base/"></tt>.

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:

<tscreen><verb>
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
</verb></tscreen>

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

<tscreen><verb>
root# rpm -U net-tools-x.xx-y.i386.rpm
</verb></tscreen>

y con Debian:

<tscreen><verb>
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
</verb></tscreen>

En los anteriores ejemplos, <tt>x.xx</tt> se refiere a la versión de las
herramientas, e <tt>y.yy</tt> 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á <tt>ipfwadm</tt>.  La última versión la puede
obtener en: <tt><htmlurl url="ftp:/ftp.xos.nl/pub/linux/ipfwadm"
name="ftp:/ftp.xos.nl/pub/linux/ipfwadm"></tt>.  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 <tt/2.1/ y <tt>ipfwadm</tt> ha
sido sustituida por <tt>ipchains</tt> en la versión <tt/2.2/ del núcleo.
<tt>ipfwadm</tt> sólo vale para la versión <tt/2.0/ del núcleo. Se sabe
de estas distribuciones que se ajustan a versiones <tt/2.0/ o anteriores
del núcleo:

<itemize>
<item>Redhat 5.2 o anteriores
<item>Caldera antes de la versión 2.2
<item>Slackware antes de las versiones 4.x
<item>Debian antes de las versiones 2.x
</itemize>

Para instalar y configurar la versión actual en el momento de escribir
esto necesita leer el <it/IPChains Howto/, disponible en el Proyecto de
Documentación de Linux <tt><htmlurl url="http://www.linuxdoc.org/"
name="http://www.linuxdoc.org"></tt>

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

<!-- FIXME: nuevas herramientas para cortafuegos -->

<sect2>Aplicaciones de red.
<p>

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

<sect2>Introducción a las direcciones IP.
<p>

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» (<it/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 <it/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 (<it/netmask/), y
su papel es determinar qué direcciones pertenecen a la red y cuáles no.
Consideremos el siguiente ejemplo:

<tscreen><verb>
---------------------  ---------------
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
---------------------  ---------------
</verb></tscreen>

Cualquier dirección a la que se aplique una operación <it/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» (<it/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
<tt>192.168.110.255</tt>. 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:

<tscreen><verb>
----------------------------------------------------------
| 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 |
----------------------------------------------------------
</verb></tscreen>

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:

<descrip>

<tag>Instalar una máquina Linux en una red IP existente</tag> 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:

<itemize>
    <item>Dirección IP del Host
    <item>Dirección IP de la red
    <item>Dirección IP de broadcast
    <item>Máscara de red IP
    <item>Dirección del encaminador (router)
    <item>Dirección del Servidor de Nombre de Dominio (DNS)
</itemize>

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

<tag>Construir una nueva red propia que nunca conectará con
Internet</tag> 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:

<tscreen><verb>
-----------------------------------------------------------
|      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 |
-----------------------------------------------------------
</verb></tscreen>

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

</descrip>

<sect1>¿Dónde debería poner las órdenes de configuración?
<p>

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 <tt/init/. El programa <tt/init/ lee entonces el fichero
de configuración llamado <tt>/etc/inittab</tt> y comienza el proceso de
arranque. Hay unos pocos <tt/init/ diferentes, aunque todo el mundo está
ahora convergiendo al modelo <it/SystemV/, desarrollado por Miguel van
Smoorenburg.

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

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

<tscreen><verb>
si::sysinit:/etc/init.d/boot
</verb></tscreen>

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 <tt/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:

<tscreen><verb>
----------------------------------------------------------------------
Distrib. |Interfaz Configuración/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/*
----------------------------------------------------------------------
</verb></tscreen>

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
<tt>/etc/sysconfig</tt>, 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 <tt>/etc/inittab</tt> y la documentación que acompaña
a <tt>init</tt>. 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.

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

<sect1>Creación de las interfaces de red.
<p>

En muchos sistemas operativos Unix los dispositivos de red tienen
correspondencias en el directorio <tt>/dev</tt>. Esto <bf/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
<tt/eth&lsqb;0..n]/ secuencialmente según va encontrado tarjetas Ethernet. La
primera tarjeta que encuentra es <tt/eth0/, la segunda <tt/eth1/, etc.

Sin embargo, en algunos casos, de los que <tt/slip/ y <tt/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 <tt/ppp/ o
<tt/slip/ puede variar durante la actividad de la máquina. Estos casos
serán cubiertos con más detalle en secciones posteriores.

<sect1>Configuración de una interfaz de red.
<label id="Ethernet">
<p>

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 <tt/ifconfig/ (<bf/i/nter<bf/f/ace
<bf/config/ure).

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

<tscreen><verb>
root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
</verb></tscreen>

En este caso estoy configurando la interfaz Ethernet <tt/eth0/, con
dirección IP <tt/192.168.0.1/ y máscara de red <tt/255.255.255.0/. El
`<tt/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 <tt>ifconfig eth0
down</tt>.

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 <tt/192.168.0.0/ y una dirección de difusión
<tt/192.168.0.255/.  Hay otras muchas opciones para la orden <tt/ifconfig/.
Las mas importantes son:

<descrip>

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

<tag/down/esta opción desactiva una interfaz.

<tag/&lsqb;-]arp/esta opción activa o desactiva el uso del protocolo
de resolución de dirección (<bf/a/ddress <bf/r/esolution <bf/p/rotocol) sobre
la interfaz

<tag/&lsqb;-]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.

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

<tag/netmask &lt;direc>/este parámetro le permite asignar la máscara de
la red a la que pertenece el dispositivo.

<tag/irq &lt;direc>/este parámetro sólo trabaja con ciertos tipos de
hardware, y permite especificar la IRQ del dispositivo.

<tag/&lsqb;-]broadcast &lsqb;direc]/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.

<tag/&lsqb;-]pointopoint &lsqb;direc]/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.

<tag/hw &lt;tipo> &lt;direc>/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.

</descrip>

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

<sect1>Configuración del sistema de resolución de nombres (<it>Name
Resolver</it>) 
<label id="Resolucion de Nombres">
<p>

El sistema de <it/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 <tt/ftp.funet.fi/
a direcciones IP «amigables para la máquina» como <tt/128.214.248.6/.

<sect2>¿Qué hay en un nombre?
<p>

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 <em/dominio/ es una
familia, o grupo de nombres. Un <em/dominio/ puede ser fragmentado en
<em/subdominios/. Un «dominio de nivel superior» (<it/toplevel domain/) es un
dominio que NO es un subdominio. Los Dominios de Nivel Superior están
especificados en el <it/RFC-920/. Algunos ejemplos de los más comunes son:

<!-- FIXME: add .firm and other top-level domains -->

<descrip>
<tag/COM/Organizaciones Comerciales
<tag/EDU/Organizaciones Educativas
<tag/GOV/Organizaciones Gubernamentales
<tag/MIL/Organizaciones Militares
<tag/ORG/Otras organizaciones
<tag/NET/Organizaciones relacionadas con InterNet
<tag/Designador de País/éstos son códigos de dos letras que representan a un
país en particular.
</descrip>

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 <tt/.us/. Esto ha dejado de ser cierto para los dominios
<tt/.com/ y <tt/.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 <tt/com/, <tt/edu/, <tt/gov/, <tt/mil/ y <tt/org/. Por
ejemplo, encontrará cosas como <tt/com.au/ y <tt/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 <em/hostname/, la porción del nombre a la derecha del
nombre de la máquina es el <em/domainname/ (nombre de dominio), y el nombre
completo es llamado <em/Fully Qualified Domain Name/ (Nombre de Dominio
Completamente Cualificado).

Si usamos el ordenador de Terry como ejemplo, el nombre completamente
cualificado es <tt/perf.no.itg.telstra.com.au/. Esto significa que el nombre de
la máquina es <tt/perf/ y el nombre de dominio el <tt/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 <tt/.com/ como siguiente nivel de dominio.  El nombre de la
compañía es (era) <tt/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
<tt/systemy.it/ y mi organización sin ánimo de lucro se llama <tt/linux.it/,
sin subdominio <tt/com/ ni <tt/org/, por lo que mi propia máquina se llama
<tt/morgana.systemy.it/ y <tt/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
<tt/pluto.linux.it/, porque los dueños de <tt/linux.it/ convinieron en abrir un
subdominio para el GUL. 

<sect2>Qué información necesitará
<p>

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 <em/Servidor de Nombres de Dominio/
(<it/Domain Name Server/), por lo que deberá saber la dirección IP del servidor
de nombres (<it/nameserver/) local que vaya a usar.

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

<sect2><tt>/etc/resolv.conf</tt>
<p>

<tt>/etc/resolv.conf</tt> 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:

<descrip>
<tag/domain/esta palabra clave especifica el nombre de dominio local.

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

<tag/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.
</descrip>

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

<tscreen><verb>
domain maths.wu.edu.au
search maths.wu.edu.au wu.edu.au
nameserver 192.168.10.1
nameserver 192.168.12.1
</verb></tscreen>

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 <tt/maths.wu.edu.au/, y que si no se encuentra la
máquina en este dominio intentemos también el dominio <tt/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.

<sect2><tt>/etc/host.conf</tt>
<p>

El fichero <tt>/etc/host.conf</tt> 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
<tt/resolv+/. El ejemplo siguiente funcionará en casi todas las
circunstancias:

<tscreen><verb>
order hosts,bind
multi on
</verb></tscreen>

Esta configuración le dice al resolutor de nombres que examine el fichero
<tt>/etc/hosts</tt> 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 <tt>/etc/hosts</tt>, en lugar de sólo el primero.

<sect2><tt>/etc/hosts</tt>
<p>

El fichero <tt>/etc/hosts</tt> 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.

<tscreen><verb>
# /etc/hosts
127.0.0.1      localhost loopback
192.168.0.1    this.host.name
</verb></tscreen>

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

<sect2>Ejecutar un servidor de nombres
<p>

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

<sect1>Configuración de la interfaz <tt>loopback</tt>
<p>

La interfaz <it/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 <tt/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 <tt/127.0.0.1/, siempre llegará a la
interfaz interna.

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

<tscreen><verb>
root# ifconfig lo 127.0.0.1
root# route add -host 127.0.0.1 lo
</verb></tscreen>

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

<sect1>Encaminamiento (<it>Routing</it>).
<p>

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:

<quote>
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.
</quote>

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:

<tscreen><verb>
root# cat /proc/net/route
</verb></tscreen>

o con cualquiera de estas otras:
 
<tscreen><verb>
root# /sbin/route -n
root# /bin/netstat -r
</verb></tscreen>

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 <tt/route/.

Un ejemplo sencillo. Imagine que tiene una red Ethernet. Le han dicho que
pertenece a una red clase C con dirección <tt/192.168.1.0/. Le han dado la
dirección IP <tt/192.168.1.10/ para su uso y también que <tt/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:

<tscreen><verb>
root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
</verb></tscreen>

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 <tt>192.168.1.*</tt>, deberán ser enviados al dispositivo
Ethernet. Debería usar una orden similar a:

<tscreen><verb>
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
</verb></tscreen>

Fíjese en el uso del parámetro <tt/-net/ para especificar al programa
<tt/route/ que esta entrada es una regla para una red completa. Otra opción es
<tt/-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 <it/por defecto/. El
camino <it/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 <it/por defecto/.
La idea del camino <it/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:

<tscreen><verb>
root# route add default gw 192.168.1.1 eth0
</verb></tscreen>

El parámetro <tt/gw/ le dice a la orden <tt/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:

<tscreen><verb>
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
</verb></tscreen>

Si echa una mirada a los ficheros <tt/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:

<tscreen><verb>
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
</verb></tscreen>

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 <tt/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 <tt/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.

<sect2>Entonces ¿qué hace el programa <tt>routed</tt>?
<p>

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 (<it/Routing Information Protocol/) y OSPF (<it/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: <tt/routed/ (RIP) y <tt/gated/ (RIP, OSPF y otros). El
programa <tt/routed/ suele venir incluido en las distribuciones de Linux, y si
no, estará incluido en el paquete <it/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:

<tscreen><verb>
      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
</verb></tscreen>

Tenemos tres encaminadores <tt/A/, <tt/B/ y <tt/C/. Cada uno da servicio a un
segmento Ethernet con una red IP de clase C (máscara de red
<tt/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 <tt/A/
podría ser algo como:

<tscreen><verb>
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
</verb></tscreen>

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

Pero espere un momento. Si <tt/A/ puede hablar con <tt/C/ y <tt/C/ puede aún
hablar con <tt/B/, ¿por qué no puede <tt/A/ encaminar sus datagramas para
<tt/B/ a través de <tt/C/ y dejar que <tt/C/ se los mande a <tt/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 <tt/A/,
<tt/B/ y <tt/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
<tt/A/:

<tscreen><verb>
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# /usr/sbin/routed
</verb></tscreen>

El demonio de encaminamiento <tt/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:

<enum>

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

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

<item>RIP es adecuado para redes de tamaño pequeño y medio.

</enum>

<sect1>Configuración de los servidores de red y los servicios.
<p>

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:

<descrip>

<tag>autónomo (standalone)</tag>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.

<tag>esclavo del servidor <tt>inetd</tt></tag> 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.

</descrip>

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

<sect2><tt>/etc/services</tt>
<p>

El fichero <tt>/etc/services</tt> 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:

<tscreen><verb>
nombre      puerto/protocolo        sobrenombres     # comentario
</verb></tscreen>

<descrip>

<tag>nombre</tag>una sola palabra que representa el servicio descrito.

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

<tag>puerto</tag>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 <it>RFC-1340</it>.

<tag>protocolo</tag>este subcampo debe tener como valor <tt>tcp</tt> o
<tt>udp</tt>.

Es importante que tenga en cuenta que el servicio <tt>18/tcp</tt> es muy
diferente del <tt>18/udp</tt> 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
<tt>tcp</tt> y otra <tt>udp</tt> para el mismo servicio si es que está
disponible para ambos.

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

</descrip>

Cualquier texto que aparezca en una línea después de un caracter <tt/&num;/ es
ignorado y se trata como un comentario.

<sect3>Un ejemplo de fichero <tt>/etc/services</tt>.
<p>

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

<tscreen><verb>
# /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
</verb></tscreen>

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 <tt>/etc/services</tt> de una distribución
reciente.

<sect2><tt>/etc/inetd.conf</tt>
<p>

<tt>/etc/inetd.conf</tt> es el fichero de configuración para el demonio
servidor <tt/inetd/. Su función es la de almacenar la información relativa a lo
que <tt/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 <tt/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 <tt/&num;/ 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:

<tscreen><verb>
servicio  tipo_socket  proto  flags  usuario  servidor  argumentos 
</verb></tscreen>

<descrip>

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

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

<tag>proto</tag>el protocolo considerado válido para este servicio. Debería
corresponder con la entrada apropiada en el fichero <tt>/etc/services</tt> y
suele ser <tt/tcp/ o <tt/udp/.  Los servidores basados en Sun RPC (<it/Remote
Procedure Call/) usarán <tt>rpc/tcp</tt> o <tt>rpc/udp</tt>.

<tag>flags</tag>sólo hay dos valores posibles. Este campo le dice a <em/inetd/
si el programa servidor de red libera el socket después de comenzar la
ejecución, y si por tanto <tt/inetd/ podrá ejecutar otro servidor para la
siguiente petición de conexión, o si <tt/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
<tt/tcp/ deberían tener esta entrada con el valor <tt/nowait/ y la mayoría de
servidores <tt/udp/ deberían tener <tt/wait/.  De todas maneras hay algunas
excepciones notables, por lo que debería leer la guía de ejemplo si no está
seguro.

<tag>usuario</tag>este campo indica qué cuenta de usuario de
<tt>/etc/passwd</tt> 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 <tt/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 <tt/root/, porque muchos
servidores requieren privilegios de administrador para funcionar correctamente.

<tag>servidor</tag>este campo es el camino completo hasta el programa servidor
a ejecutar para esta entrada.

<tag>argumentos</tag>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.

</descrip>

<sect3>Un ejemplo de <tt>/etc/inetd.conf</tt>
<p>

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

<tscreen><verb>
# /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
</verb></tscreen>

<sect1>Otros ficheros de configuración relacionados con la red
<p>

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.

<sect2><tt>/etc/protocols</tt>
<p>

El fichero <tt>/etc/protocols</tt> es una base de datos que correlaciona
números de identificación de protocolos con sus nombres. Esto lo usan los
programadores para especificar protocolos por su nombre en sus programas y
también por programas como <tt/tcpdump/ para mostrar nombres en lugar de
números en su salida. En general la sintaxis del fichero es:

<tscreen><verb>
nombredelprotocolo  número  sobrenombres
</verb></tscreen>

El fichero <tt>/etc/protocols</tt> proporcionado con la distribución Debian
<tt><htmlurl url="http://www.debian.org/" name="http://www.debian.org"></tt> es
como sigue:

<tscreen><verb>
# /etc/protocols:
# $Id: protocols,v 1.1 1995/02/24 01:09:41 imurdock Exp $
#
# Internet (IP) protocols
#
#       from: @(#)protocols     5.1 (Berkeley) 4/17/89
#
# Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992).

ip      0       IP              # internet protocol, pseudo protocol number
icmp    1       ICMP            # internet control message protocol
igmp    2       IGMP            # Internet Group Management
ggp     3       GGP             # gateway-gateway protocol
ipencap 4       IP-ENCAP        # IP encapsulated in IP (officially «IP»)
st      5       ST              # ST datagram mode
tcp     6       TCP             # transmission control protocol
egp     8       EGP             # exterior gateway protocol
pup     12      PUP             # PARC universal packet protocol
udp     17      UDP             # user datagram protocol
hmp     20      HMP             # host monitoring protocol
xns-idp 22      XNS-IDP         # Xerox NS IDP
rdp     27      RDP             # "reliable datagram" protocol
iso-tp4 29      ISO-TP4         # ISO Transport Protocol class 4
xtp     36      XTP             # Xpress Tranfer Protocol
ddp     37      DDP             # Datagram Delivery Protocol
idpr-cmtp       39      IDPR-CMTP       # IDPR Control Message Transport
rspf    73      RSPF            # Radio Shortest Path First.
vmtp    81      VMTP            # Versatile Message Transport
ospf    89      OSPFIGP         # Open Shortest Path First IGP
ipip    94      IPIP            # Yet Another IP encapsulation
encap   98      ENCAP           # Yet Another IP encapsulation
</verb></tscreen>

<sect2><tt>/etc/networks</tt>
<p>

El fichero <tt>/etc/networks</tt> tiene una función similar a la del fichero
<tt>/etc/hosts</tt>. Proporciona una base de datos sencilla de nombres de red y
direcciones de red. Su formato difiere en que sólo puede haber dos campos por
línea y los campos están codificados así:

<tscreen><verb>
nombredelared direccióndered
</verb></tscreen>

Un ejemplo podría ser:

<tscreen><verb>
loopnet    127.0.0.0
localnet   192.168.0.0
amprnet    44.0.0.0
</verb></tscreen>

Cuando use órdenes como <tt/route/, si un destino es una red y la red tiene una
entrada en el fichero /etc/networks entonces route mostrará el nombre de la red
en lugar de su dirección.

<sect1>Seguridad en la red y control de acceso.
<p>

Déjeme empezar esta sección advirtiendo que la seguridad de su máquina y red
ante ataques maliciosos es un arte complejo. No me considero un experto en este
campo y aunque los mecanismos que voy a describir puedan ayudar, si quiere
tomarse en serio la seguridad entonces le recomiendo que investigue un poco en
el tema. Hay algunas buenas referencias en Internet relacionadas con la
seguridad, incluido el <it/Security HOWTO/ (Dispone de una  traducción en
<tt><htmlurl url="http://www.insflug.org/documentos/Seguridad-Como/"
name="http://www.insflug.org/documentos/Seguridad-Como/"></tt>.

Una regla general importante es: <bf>No ejecute servicios que no tenga
intención de usar</bf>'.  Muchas distribuciones vienen configuradas con todo
tipo de servicios que se inician automáticamente. Para asegurar un nivel mínimo
de seguridad debería examinar el fichero <tt>/etc/inetd.conf</tt> y comentar
(<em>poner un <tt/&num;/ al inicio de la línea</em>) de toda declaración de
servicio que no vaya a usar. Buenos candidatos son: <tt/shell/, <tt/exec/,
<tt/uucp/, <tt/ftp/ y servicios de información como <tt/finger/, <tt/netstat/ y
<tt/systat/.

Hay todo tipo de mecanismos de seguridad y control de acceso, describiré
los más elementales.

<sect2><tt>/etc/ftpusers</tt>
<p>

El fichero <tt>/etc/ftpusers</tt> es un mecanismo sencillo que le permite
denegar la entrada a ciertos usuarios mediante FTP. El fichero
<tt>/etc/ftpusers</tt> lo lee el programa demonio de FTP (<tt/ftpd/) cuando se
recibe una conexión FTP. El fichero es una simple lista de aquellos usuarios
que no tienen permitido el acceso. Puede parecerse a esto:

<tscreen><verb>
# /etc/ftpusers - users not allowed to login via ftp
root
uucp
bin
mail
</verb></tscreen>

<sect2><tt>/etc/securetty</tt>
<p>

El fichero <tt>/etc/securetty</tt> permite especificar qué dispositivos
<tt/tty/ puede usar <tt/root/ para identificarse en el sistema. El fichero
<tt>/etc/securetty</tt> es leído por el programa de acceso (normalmente
<tt>/etc/login</tt>). Su formato es una lista de los nombres de dispositivos
<tt/tty/ permitidos, en todos los demás <tt/root/ tiene prohibida la entrada:

<tscreen><verb>
# /etc/securetty - tty's on which root is allowed to login
tty1
tty2
tty3
tty4
</verb></tscreen>

<sect2>El mecanismo de control de acceso <it>hosts</it> de <tt>tcpd</tt>
<p>

El programa <tt>tcpd</tt> que ha visto listado en el fichero
<tt>/etc/inetd.conf</tt> proporciona mecanismos de control de registro y acceso
a los servicios que haya de proteger.

Cuando es invocado por el programa <tt>inetd</tt> lee dos ficheros que
contienen reglas de acceso y que permiten o deniegan acceso al servidor que
está protegiendo.

Mirará en los ficheros de reglas hasta que encuentre la primera
correspondencia. Si no se encuentran correspondencias asume que el acceso
debería estar permitido para todo el mundo. La secuencia de archivos que revisa
es: <tt>/etc/hosts.allow</tt>, <tt>/etc/hosts.deny</tt>. Describiré cada uno de
estos en seguida. Para una descripción completa de este servicio debería
referirse a las páginas del manual apropiadas (<tt/hosts_access/ (5) es un buen
punto de partida).

<sect3><tt>/etc/hosts.allow</tt>
<p>

El <tt>/etc/hosts.allow</tt> es un fichero de configuración del programa
<tt>/usr/sbin/tcpd</tt>. El fichero <tt>hosts.allow</tt> contiene reglas que
describen qué máquinas tienen permiso para acceder a un servicio en la suya.

El formato del fichero es bastante sencillo:

<tscreen><verb>
# /etc/hosts.allow
#
# <lista de servicios>: <lista de hosts> [: orden]
</verb></tscreen>

<descrip>

<tag><tt/lista de servicios/ </tag>es una lista delimitada por comas de nombres
de servidores a los que se aplica esta regla.  Ejemplos de nombre de servicio
son: <tt/ftpd/, <tt/telnetd/ y <tt/fingerd/.

<tag><tt/lista de hosts/ </tag>es una lista de nombres de máquinas, delimitada
por comas. Aquí también puede usar direcciones IP. De forma adicional, puede
especificar nombres de máquinas o direcciones usando caracteres comodín para
corresponder con grupos de máquinas. Por ejemplo: <tt/gw.vk2ktj.ampr.org/ para
una máquina específica, <tt/.uts.edu.au/ para cualquier nombre de máquina que
acabe en esa cadena, <tt/44./ para cualquier dirección IP que comience con esos
dígitos. Hay algunas palabras especiales para simplificar la configuración,
algunas de las cuales son:

<itemize>

<item><tt/ALL/, que se corresponde con cualquier host. 

<item><tt/LOCAL/ se corresponde con cualquier nombre de host que no contenga un
<tt/./ o sea que esté en el mismo dominio que su máquina;

<item><tt/PARANOID/ se corresponde con cualquier nombre que no se corresponda
con esta dirección (name spoofing). Hay una última palabra que también es útil.
La palabra 

<item><tt/EXCEPT/ permite proporcionar una lista con excepciones. Esto lo
cubriremos en un capítulo posterior.
</itemize>

<tag><tt/orden/</tag>es un parámetro opcional. Este parámetro es el camino
completo hasta una orden que debería ser ejecutada cada vez que se cumpla esta
regla. Podría por ejemplo ejecutar una instrucción que intentase identificar
quién está autenticado en el host que conecta, o generar un mensaje de correo u
otro tipo de alerta a un administrador de sistema avisando de que alguien
intenta conectar. Hay cierto número de expansiones que podríamos incluir,
algunos ejemplos comunes son: <tt/&percnt;h/ se expande al nombre de la máquina
que se conecta o a su dirección si no tiene un nombre, <tt/&percnt;d/ es el
demonio que está siendo llamado.

</descrip>

Un ejemplo:

<tscreen><verb>
# /etc/hosts.allow
#
# Permitir correo a todo el mundo
in.smtpd: ALL
# Todo telnet y FTP sólo a hosts dentro de mi dominio y el host que tengo
# en caso
telnetd, ftpd: LOCAL, myhost.athome.org.au
# Permitir finger a cualquiera pero mantener un registro de quién es.
fingerd: ALL: (finger @%h | mail -s "finger desde %h" root)
</verb></tscreen>

<sect3><tt>/etc/hosts.deny</tt>
<p>

El fichero <tt>/etc/hosts.deny</tt> es un fichero de configuración del
programa <tt>/usr/sbin/tcpd</tt>. El fichero <tt/hosts.deny/ contiene
reglas que describen qué máquinas tienen <em>prohibido</em> el acceso a
un servicio en su máquina.

Un ejemplo simple podría parecerse a esto:

<tscreen><verb>
# /etc/hosts.deny
#
# Desautorizar a todos los host con nombre sospechoso
ALL: PARANOID
#
# Desautorizar a todos los host.
ALL: ALL
</verb></tscreen>

La entrada <tt>PARANOID</tt> es redundante porque la otra entrada abarca todo
en cualquier caso. Ambas entradas serían razonables por defecto dependiendo de
sus requisitos particulares.

La configuración más segura es tener <tt>ALL: ALL</tt> por defecto en 
<tt>/etc/hosts.deny</tt> para después dar permiso específicamente a aquellos
servicios y hosts que se desee en <tt>/etc/hosts.allow</tt>.

<sect2><tt>/etc/hosts.equiv</tt>
<p>

El fichero <tt>hosts.equiv</tt> se usa para garantizar a ciertos hosts y
usuarios derechos de acceso a cuentas en su máquina sin que tenga que
proporcionar una clave. Esto es útil en un entorno seguro donde controle todas
las máquinas, pero en otro caso es un peligro para la seguridad. Su máquina es
sólo tan segura como la menos segura de aquellas en las que confíe.  Para
maximizar la seguridad, no use este mecanismo, y anime a sus usuarios para que
tampoco usen ficheros <tt/.rhost/.

<sect2>Configure su demonio de ftp adecuadamente.
<p>

Muchos servidores estarán interesados en ejecutar un demonio de <em/FTP/
anónimo para permitir a otras personas que subir y descargar ficheros sin
necesidad de un <it/userid/ específico. Si decide ofrecer este servicio
asegúrese de que configura el demonio de <em/ftp/ apropiadamente para acceso
anónimo. La mayoría de las páginas de <tt>ftpd(8)</tt> describen cómo hacerlo.
Debería asegurarse siempre de que sigue estas instrucciones. Una cosa
importante es no usar una copia de su fichero <tt>/etc/passwd</tt> habitual en
el directorio <tt>/etc</tt> de la cuenta anónima; asegúrese de que elimina
todos los detalles sobre las cuentas excepto aquellos que deba tener, ya que en
otro caso será vulnerable a las técnicas de adquisición de claves por fuerza
bruta.

<sect2>Cortafuegos para redes.
<p>

Un excelente medio de seguridad es no permitir que los datagramas lleguen
siquiera a su máquina o servidores. Esto lo cubre en profundidad el
<tt><htmlurl url="http://www.insflug.org/documentos/Cortafuegos-Como/"
name="http://www.insflug.org/documentos/Cortafuegos-Como/"></tt> y, más
concisamente, la última sección de este documento.

<sect2>Otras sugerencias.
<p>

Hay otras sugerencias, que debería considerar, pero que realmente son
cuestión de cada uno.

<descrip>

<tag>sendmail</tag>a pesar de su popularidad, el demonio <em/sendmail/ aparece
con preocupante regularidad en los anuncios de alerta de seguridad. Usted
decides, pero yo elijo no ejecutarlo.

<tag>NFS y otros servicios Sun RPC</tag>tenga cuidado con estos. Hay todo tipo
de posibles formas de explotar estos servicios. Es difícil de encontrar una
opción a los servicios NFS, y si decide usarlos, asegúrese de que es cuidadoso
con los permisos que da al configurarlo.

</descrip>

<sect>Información relacionada con IP y Ethernet
<label id="IP y Ethernet">
<p>

Esta sección cubre la información específica a Ethernet e IP. Estas
subsecciones han sido agrupadas juntas debido a que pienso que son las más
interesante dentro de la que previamente se llamó sección de «Tecnología
Específica». Cualquiera que tenga una LAN se beneficiará de esta parte.

<sect1>Ethernet
<p>

Los dispositivos Ethernet son <tt/eth0/, <tt/eth1/, <tt/eth2/, etc.  A la
primera tarjeta detectada por el núcleo se le asigna <tt/eth0/ y al resto se
les asigna secuencialmente en el orden en que sean detectadas.

Por defecto, el núcleo de Linux sólo intenta buscar una tarjeta de red, por lo
que tendrá que pasarle algunos parámetros para forzar la detección de las
demás.

Para aprender cómo hacer trabajar una tarjeta Ethernet bajo Linux debería
acudir al Ethernet Howto, <tt><htmlurl url="Ethernet-HOWTO.html"
name="Ethernet-HOWTO.html"></tt>.

Una vez que tenga el núcleo compilado para reconocer su tarjeta Ethernet,
configurar la tarjeta es sencillo.

Normalmente debería hacer algo como:

<tscreen><verb>
root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
root# route add -net 192.168.0.0 netmask 255.255.255.0 eth0
</verb></tscreen>

La mayoría de los controladores Ethernet fueron desarrollados por Donald
Becker, <tt><htmlurl url="mailto:becker@CESDIS.gsfc.nasa.gov"
name="becker@CESDIS.gsfc.nasa.gov"></tt>.

<sect1>EQL - ecualizador de tráfico para líneas múltiples
<p>

El nombre del dispositivo EQL es <tt/eql/. Con las fuentes estándar del núcleo
sólo podrá tener un dispositivo EQL por máquina. EQL proporciona un medio para
utilizar múltiples líneas punto a punto como un solo enlace PPP, slip o PLIP
lógico para llevar tcp/ip. A menudo es más barato usar varias líneas de baja
velocidad que tener una sola línea de alta velocidad.

<bf/Opciones de Compilación del Núcleo/:

<tscreen><verb>
Network device support  --->
  [*] Network device support
  <*> EQL (serial line load balancing) support
 </verb></tscreen>

Para poder usar este mecanismo la máquina en el otro extremo de la línea debe
admitirlo también. Linux, Livingstone Portmasters y los nuevos servidores
dial-in soportan servicios compatibles.

Para configurar EQL necesitará las herramientas eql que están disponibles en
<tt><htmlurl url="ftp://metalab.unc.edu/pub/linux/system/Serial/eql-1.2.tar.gz"
name="ftp://metalab.unc.edu/pub/linux/system/Serial/eql-1.2.tar.gz"></tt>.

La configuración es bastante directa. Se comienza por la interfaz eql.  La
interfaz es exactamente como la de cualquier otro dispositivo de red. La
dirección IP y mtu se configura usando <tt/ifconfig/, con algo como:

<tscreen><verb>
root# ifconfig eql 192.168.10.1 mtu 1006
</verb></tscreen>

Lo siguiente que se necesita es iniciar manualmente cada una de las líneas que
se vayan a usar. Esta puede ser cualquier combinación de dispositivos de red
punto a punto. Cómo iniciar las conexiones depende del tipo de enlace que sea,
por lo que ha de mirar las secciones apropiadas para más información.

Finalmente necesitará asociar el enlace serie con el dispositivo EQL, esto se
llama «esclavizar» y se hace con la orden <tt/eql_enslave/ como se ve en el
ejemplo:

<tscreen><verb>
root# eql_enslave eql sl0 28800
root# eql_enslave eql ppp0 14400
</verb></tscreen>

El parámetro <em>velocidad estimada</em> que se da a <tt/eql_enslave/ no hace
nada directamente. Lo usa el controlador (<it/driver/) EQL para determinar qué
parte de los datagramas va a recibir cada dispositivo, para así afinar el
balance de las líneas jugando con este valor.

Para disociar una línea de un dispositivo EQL use <tt/eql_emancipate/ de esta
manera:

<tscreen><verb>
#root eql_emancipate eql sl0
</verb></tscreen>

Puede añadir rutas de la misma manera que para cualquier otro enlace punto a
punto, excepto en que las rutas deben referirse al dispositivo <tt/eql/ en
lugar de a los verdaderos dispositivos en serie. Normalmente usará:

<tscreen><verb>
root# route add default eql
</verb></tscreen>

El controlador EQL fue desarrollado por Simon Janes, <tt><htmlurl
url="mailto:simon@ncm.com" name="simon@ncm.com"></tt>.

<sect1>IP Accounting (en Linux 2.0)
<p>

Los servicios de auditoría IP del núcleo de Linux le permiten recolectar y
analizar datos de uso de la red. Los datos recogidos comprenden el número de
paquetes y de bytes acumulados desde que se puso a cero la última vez.  Tiene a
su disposición varias reglas para categorizar estas cifras para que se ajusten
a los propósitos que les vaya a dar. Esta opción ha sido eliminada del núcleo a
partir de la versión <tt/2.1.102/, porque el viejo sistema de cortafuegos
basado en <tt/ipfwadm/ fue reemplazado por <tt/ipfwchains/.

<bf/Opciones de Compilación del Núcleo/:

<tscreen><verb>
Networking options  --->
  [*] IP: accounting
 </verb></tscreen>

Después de que haya compilado e instalado el núcleo necesitará hacer uso
de la orden <tt/ipfwadm/ para configurar la auditoría de IP. Hay muchas maneras
diferentes de obtener la información de auditoría para elegir.  He creado un
ejemplo sencillo de lo que podría ser útil, pero debería leer la página de
manual de <tt/ipfwadm/ para obtener más información.

Escena: Tenemos una red Ethernet que accede a la Internet mediante un
enlace PPP. En la Ethernet tiene una máquina que ofrece cierta variedad
de servicios y está interesado en saber cuánto tráfico se genera por cada
conexión ftp y http, así como el tráfico total tcp y udp.

Podrías usar un conjunto de órdenes que se pareciese a lo siguiente, que
se presenta como guión de ejecución de órdenes (<it/shell script/):


<tscreen><verb>
#!/bin/sh
#
# Borrar las reglas de contabilidad
ipfwadm -A -f
#
# Establecer macros
localnet=44.136.8.96/29
any=0/0
# Agregar reglas para los segmentos de la red local
ipfwadm -A in  -a -P tcp -D $localnet ftp-data
ipfwadm -A out -a -P tcp -S $localnet ftp-data
ipfwadm -A in  -a -P tcp -D $localnet www
ipfwadm -A out -a -P tcp -S $localnet www
ipfwadm -A in  -a -P tcp -D $localnet
ipfwadm -A out -a -P tcp -S $localnet
ipfwadm -A in  -a -P udp -D $localnet
ipfwadm -A out -a -P udp -S $localnet
#
# Reglas por defecto
ipfwadm -A in  -a -P tcp -D $any ftp-data
ipfwadm -A out -a -P tcp -S $any ftp-data
ipfwadm -A in  -a -P tcp -D $any www
ipfwadm -A out -a -P tcp -S $any www
ipfwadm -A in  -a -P tcp -D $any
ipfwadm -A out -a -P tcp -S $any
ipfwadm -A in  -a -P udp -D $any
ipfwadm -A out -a -P udp -S $any
#
# Mostrar las reglas
ipfwadm -A -l -n
#
</verb></tscreen>

Los nombres <tt/ftp-data/ y <tt/www/ se refieren a líneas en
<tt>/etc/services</tt>. La última orden da una lista de cada una de las reglas
de auditoría y muestra los totales obtenidos.

Una cosa importante a tener en cuenta cuando analizamos IP accounting es que
<bf/los totales de todas las reglas que se han cumplido se han incrementado/,
por tanto para obtener las diferencias tendrá que hacer los cálculos
apropiados. Por ejemplo, si quiero saber cuantos datos no fueron de ftp, ni www
restaré los totales individuales de la regla que se corresponde con todos los
puertos.

<tscreen><verb>
root# ipfwadm -A -l -n
IP accounting rules
 pkts bytes dir prot source               destination          ports
    0     0 in  tcp  0.0.0.0/0            44.136.8.96/29       * -> 20
    0     0 out tcp  44.136.8.96/29       0.0.0.0/0            20 -> *
   10  1166 in  tcp  0.0.0.0/0            44.136.8.96/29       * -> 80
   10   572 out tcp  44.136.8.96/29       0.0.0.0/0            80 -> *
  252 10943 in  tcp  0.0.0.0/0            44.136.8.96/29       * -> *
  231 18831 out tcp  44.136.8.96/29       0.0.0.0/0             * -> *
    0     0 in  udp  0.0.0.0/0            44.136.8.96/29       * -> *
    0     0 out udp  44.136.8.96/29       0.0.0.0/0            * -> *
    0     0 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> 20
    0     0 out tcp  0.0.0.0/0            0.0.0.0/0            20 -> *
   10  1166 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> 80
   10   572 out tcp  0.0.0.0/0            0.0.0.0/0            80 -> *
  253 10983 in  tcp  0.0.0.0/0            0.0.0.0/0            * -> *
  231 18831 out tcp  0.0.0.0/0            0.0.0.0/0            * -> *
    0     0 in  udp  0.0.0.0/0            0.0.0.0/0            * -> *
    0     0 out udp  0.0.0.0/0            0.0.0.0/0            * -> *
</verb></tscreen>

<sect1>IP Accounting (en Linux 2.2)
<p>

El nuevo código para llevar la contabilidad se accede mediante «IP Firewall
Chains». Consulte la página principal de IP chains <tt><htmlurl
url="http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html"
name="http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html"></tt> si
desea más información. Entre otras cosas, necesitará usar <tt/ipchains/ en
lugar de <tt/ipfwadm/ para configurar sus filtros. (De
<tt>Documentation/Changes</tt> en las últimas fuentes del núcleo)

<sect1>IP Aliasing
<p>

Hay algunas aplicaciones para las que es útil ser capaz de asignar varias
direcciones IP a un sólo dispositivo de red. Los Proveedores de Servicios de
Internet usan esto a menudo para ofertar a sus usuarios WWW y FTP «a medida».
Puede acudir al <it/IP-Alias mini-HOWTO/ si quiere obtener más información de
la que aquí hay.

<bf/Opciones de Compilación del Núcleo/:

<tscreen><verb>
Networking options  --->
   ....
   [*] Network aliasing
   ....
   <*> IP: aliasing support
</verb></tscreen>

Después de compilar e instalar su núcleo con la implementación de IP_Alias, la
configuración es muy sencilla. Los alias se añaden a dispositivos de red
virtuales asociados al verdadero dispositivo de red.  Se aplica una convención
sencilla para dar nombres a estos dispositivos, que es
<tt>&lt;nombredisp>:&lt;núm disp virtual></tt>, por ejemplo <tt/eth0:0/,
<tt/ppp0:10/, etc. Tenga en cuenta que dispositivo nombre:número sólo se puede
configurar <em>después</em> de haber activado la interfaz principal.

Por ejemplo, asumiremos que tiene una red Ethernet que soporta dos redes IP
diferentes simultáneamente y quiere que tu máquina tenga acceso directo a
ambas. Podríamos hacer algo como:

<tscreen><verb>
root# ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0

root# ifconfig eth0:0 192.168.10.1 netmask 255.255.255.0 up
root# route add -net 192.168.10.0 netmask 255.255.255.0 eth0:0
</verb></tscreen>

Para borrar un alias sencillamente añadimos un `<tt/-/' al final de su nombre y
nos referimos a él de forma tan sencilla como:

<tscreen><verb>
root# ifconfig eth0:0- 0
</verb></tscreen>

También serán borradas automáticamente todas las rutas asociadas con ese alias.

<sect1>IP Firewall (para Linux 2.0)
<p>

Los temas referentes a Cortafuegos IP y al trabajo con Cortafuegos está
cubierto en mayor profundidad en el <tt><htmlurl
url="http://www.insflug.org/documentos/Cortafuegos-Como/"
name="http://www.insflug.org/documentos/Cortafuegos-Como/"></tt>. Tener un
Cortafuegos IP le permite asegurar su máquina frente a accesos por la red no
autorizados filtrando o permitiendo que entren datagramas de o hacia las
direcciones IP que sean designadas. Hay tres clases diferentes de reglas,
filtrado de entradas (<it/incoming filtering/), filtrado de salidas
(<it/outgoing filtering/) y filtrado de reenvíos (<it/forwarding filtering/).
Las reglas de entradas son aplicadas a los datagramas recibidos en un
dispositivo de red. Las reglas de salidas se aplican a los datagramas que va a
transmitir un dispositivo de red. Las reglas de reenvíos se aplican a
datagramas que se reciben pero que no son para esta máquina, como por ejemplo
datagramas que entran por una interfaz para ser encaminados por otra.

<bf/Opciones de Compilación del Núcleo/:

<tscreen><verb>
Networking options  --->
  [*] Network firewalls
  ....
  [*] IP: forwarding/gatewaying
  ....
  [*] IP: firewalling
  [ ] IP: firewall packet logging
</verb></tscreen>

La configuración de las reglas del cortafuegos IP se realiza usando la
orden <tt/ipfwadm/. Como mencioné antes, yo no soy un experto en seguridad, por
lo aunque le voy a presentar un ejemplo que se puede usar, usted debería
investigar y desarrollar sus propias reglas si la seguridad es algo que le
importe.

El uso más común de los cortafuegos IP es probablemente cuando está
usando su máquina Linux como encaminador y pasarela (gateway) cortafuegos para
proteger tu red local de accesos sin autorización desde fuera de la red.

La configuración siguiente está basada en una contribución de Arnt
Gulbrandsen, <tt><htmlurl url="mailto:agulbra@troll.no"
name="agulbra@troll.no"></tt>.

El ejemplo describe la configuración de las reglas de cortafuegos en la
máquina cortafuegos/encaminadora ilustrada en este diagrama.

<tscreen><verb>
-                                   -
 \                                  | 172.16.37.0
  \                                 |   /255.255.255.0
   \                 ---------      |
    |  172.16.174.30 | Linux |      |
NET =================|  f/w  |------|    ..37.19
    |    PPP         | router|      |  --------
   /                 ---------      |--| Mail |
  /                                 |  | /DNS |
 /                                  |  --------
-                                   -
</verb></tscreen>

Las órdenes que siguen, deberían normalmente estar situadas en un fichero
<tt/rc/ de manera que sean ejecutadas automáticamente cada vez que el
sistema reinicie. Para mayor seguridad deberían ser llamadas después de
que ser configuradas las interfaces de red, pero antes de que las
interfaces hayan sido puestas «en marcha» para prevenir cualquier intento
de acceder mientras la máquina cortafuegos está reiniciando.

<tscreen><verb>
#!/bin/sh

# Limpiar la tabla de reglas de 'Reenvíos'
# Cambiar la política por defecto a 'accept'
#
/sbin/ipfwadm -F -f
/sbin/ipfwadm -F -p accept
#
# .. y lo mismo para 'Entradas'
#
/sbin/ipfwadm -I -f
/sbin/ipfwadm -I -p accept

# Antes que nada, sellamos la interfaz PPP
# Me encantaría usar '-a deny' en lugar de '-a reject -y' pero entonces
# sería imposible originar conexiones desde ese interfaz.
# El -o causa que todos los datagramas rechazados sean registrados. Esto
# toma espacio de disco a cambio de tener el conocimiento de un ataque
# por error de configuración.
#
/sbin/ipfwadm -I -a reject -y -o -P tcp -S 0/0 -D 172.16.174.30

# Eliminar ciertos tipos de paquetes que obviamente han sido generados
# de forma 'artificial': No puede venir nada de direcciones
# multicast/anycast/broadcast
#
/sbin/ipfwadm -F -a deny -o -S 224.0/3 -D 172.16.37.0/24
#
# y nunca deberíamos ver llegar por un cable nada de la red
# 'loopback'
#
/sbin/ipfwadm -F -a deny -o -S 127.0/8 -D 172.16.37.0/24

# aceptamos entradas de las conexiones SMTP y DNS, pero sólo
# hacia el Mail/Name Server
#
/sbin/ipfwadm -F -a accept -P tcp -S 0/0 -D 172.16.37.19 25 53
#
# DNS usa tanto UPD como TCP, por lo tanto los permitimos ambos
# para quien pregunte por nuestro servidor de nombres
#
/sbin/ipfwadm -F -a accept -P udp -S 0/0 -D 172.16.37.19 53
#
# pero no "respuestas" que lleguen a puertos peligrosos como el de NFS
# y extensiones de NFS de Larry McVoy. Si ejecutamos squid, añadir
# su puerto aquí también.
#
/sbin/ipfwadm -F -a deny -o -P udp -S 0/0 53 \
-D 172.16.37.0/24 2049 2050

# valen las respuestas a otros puertos de usuario
#
/sbin/ipfwadm -F -a accept -P udp -S 0/0 53 \
        -D 172.16.37.0/24 53 1024:65535

# Rechazar conexiones de entrada a identd Usaremos 'reject' aquí para que
# se le diga al ordenador que intenta conectar que no continúe, si no lo
# hiciéramos, experimentaríamos retrasos mientras ident da un error de
# 'time out'
#
/sbin/ipfwadm -F -a reject -o -P tcp -S 0/0 -D 172.16.37.0/24 113

# Aceptamos algunas conexiones a servicios comunes desde las redes
# 192.168.64 y 192.168.65, que son amistades en las que confiamos.
#
/sbin/ipfwadm -F -a accept -P tcp -S 192.168.64.0/23 \
       -D 172.16.37.0/24 20:23

# aceptar y dejar pasar cualquier cosa que se origine dentro
#
/sbin/ipfwadm -F -a accept -P tcp -S 172.16.37.0/24 -D 0/0

# denegar la mayoría del resto de conexiones TCP y registrarlas
# (añade 1:1023 si tiene problemas con el FTP)
#
/sbin/ipfwadm -F -a deny -o -y -P tcp -S 0/0 -D 172.16.37.0/24

# ... para UDP también
#
/sbin/ipfwadm -F -a deny -o -P udp -S 0/0 -D 172.16.37.0/24
</verb></tscreen>

Las buenas configuraciones de cortafuegos son un poco complicadillas. Este
ejemplo debería ser un punto de partida razonable. La página de manual de
<tt/ipfwadm/ ofrece más asistencia en lo que respecta al manejo de la
herramienta. Si intenta configurar un cortafuegos, asegúrese de que hace
suficientes preguntas para tener información de las fuentes que considera
fiables y haga algunas pruebas de funcionamiento con su configuración desde el
exterior de la red.

<sect1>IP Firewall (para Linux 2.2)
<p>

Al nuevo código para controlar el cortafuegos se accede mediante <it/IP Firewall
Chains/. Consulte la página principal de IP Chains <tt><htmlurl
url="http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html"
name="http://www.adelaide.net.au/~rustcorp/ipfwchains/ipfwchains.html"> </tt>
si desea más información. Entre otras cosas, necesitará usar <tt/ipchains/ en
lugar de <tt/ipfwadm/ para configurar sus filtros.  (De
<tt>Documentation/Changes</tt> en las últimas fuentes del núcleo)

Estamos avisados de que esto está seguramente desfasado y estamos trabajando
para tener esta sección más al día. Es posible que tengamos una versión nueva
para agosto de 1999.

<sect1>Encapsulación IPIP
<p>

¿Qué razón hay para encapsular datagramas IP dentro de datagramas IP?  Le
parecerá una tontería si nunca ha visto antes sus aplicaciones.  Bien, aquí
tenemos un par de ejemplos comunes en los que se usa: Mobile-IP e IP-Multicast.
Posiblemente su uso más extendido o al menos el mejor conocido es Amateur
Radio.

<bf/Opciones de Compilación del Núcleo/:

<tscreen><verb>
    Networking options  --->
        [*] TCP/IP networking
        [*] IP: forwarding/gatewaying
        ....
        <*> IP: tunneling
</verb></tscreen>

Los dispositivos túneles de IP se denominan <tt/tunl0/, <tt/tunl1/,
etc.

<it/¿Pero por qué?/. Bien, bien. Las reglas convencionales de encaminamiento
de redes IP comprenden direcciones de red y máscaras de red. Esto hace que
conjuntos de direcciones contiguas sean encaminadas mediante una sola regla de
encaminamiento. Esto es muy conveniente, pero significa que sólo puede usar una
dirección IP en particular cuando está conectado a alguna parte de la red a la
que pertenece.  En la mayoría de los casos esto vale, pero si suele desplazarse
entonces no será capaz siempre de conectar desde el mismo sitio. La
encapsulación IP/IP (IP tunneling) le permite saltarse esta restricción
permitiendo que los datagramas que están destinados a su dirección IP sean
encapsulados y dirigidos a otra dirección IP. Si sabe que va a estar durante un
tiempo trabajando en otra red IP entonces podrá poner a punto una máquina de su
red habitual para que acepte los datagramas que van dirigidos a su IP y que los
reenvíe a la dirección que esté usando de manera temporal.

<sect2>Una configuración de red con <it>túneles</it>
<p>

<tscreen><verb>
 192.168.1/24                          192.168.2/24

     -                                     -
     |      ppp0 =            ppp0 =       |
     |  aaa.bbb.ccc.ddd  fff.ggg.hhh.iii   |
     |                                     |
     |   /-----\                 /-----\   |
     |   |     |       //        |     |   |
     |---|  A  |------//---------|  B  |---|
     |   |     |     //          |     |   |
     |   \-----/                 \-----/   |
     |                                     |
     -                                     -
</verb></tscreen>

El diagrama ilustra otra posible razón para usar encapsulación IPIP, las
redes privadas virtuales. Este ejemplo presupone que tiene dos máquinas
cada una con una sola conexión ppp a Internet. Cada máquina tiene una sola
dirección IP. Tras cada una de estas máquinas hay algunas redes privadas
de área local configuradas con direcciones de red IP reservadas.
Supongamos que quiere permitir que cualquier máquina en la red <tt/A/ se
conecte con cualquier máquina en la red <tt/B/, como si estuvieran conectadas a
Internet por una ruta de red. La encapsulación IP se lo permitirá. Tenga
en cuenta que la encapsulación no resuelve el problema de cómo hacer que
las máquinas las redes <tt/A/ y <tt/B/ se comuniquen con otras máquinas en
Internet, ya que para seguimos necesitando trucos como el Enmascaramiento IP.
La encapsulación la realiza normalmente una máquina que esté funcionando como
encaminador.

El encaminador Linux <tt/A/ debería configurarse así:

<tscreen><verb>
#!/bin/sh
PATH=/sbin:/usr/sbin
mask=255.255.255.0
remotegw=fff.ggg.hhh.iii
#
# Configuración Ethernet
ifconfig eth0 192.168.1.1 netmask $mask up
route add -net 192.168.1.0 netmask $mask eth0
#
# Configuración ppp0 (iniciar enlace ppp, establecer ruta por defecto)
pppd
route add default ppp0
#
# Configuración del dispositivo túnel
ifconfig tunl0 192.168.1.1 up
route add -net 192.168.2.0 netmask $mask gw $remotegw tunl0
</verb></tscreen>

El encaminador Linux `<tt/B/' debería configurarse con:

<tscreen><verb>
#!/bin/sh
PATH=/sbin:/usr/sbin
mask=255.255.255.0
remotegw=aaa.bbb.ccc.ddd
#
# Configuración Ethernet
ifconfig eth0 192.168.2.1 netmask $mask up
route add -net 192.168.2.0 netmask $mask eth0
#
# Configuración ppp0 (iniciar enlace PPP, establecer ruta por defecto)
pppd
route add default ppp0
#
# Configuración del dispositivo túnel
ifconfig tunl0 192.168.2.1 up
route add -net 192.168.1.0 netmask $mask gw $remotegw tunl0
</verb></tscreen>

La orden:

<tscreen><verb>
route add -net 192.168.1.0 netmask $mask gw $remotegw tunl0
</verb></tscreen>

se leería: <it>Envía cualquier datagrama destinado a</it>
<tt>192.168.1.0/24</tt> <it>dentro de un datagrama IPIP con dirección de
destino</it> <tt>aaa.bbb.ccc.ddd</tt>'.

Las configuraciones son recíprocas en cada extremo. El dispositivo de túnel usa
el <tt/gw/ dado en la ruta como <em/destino/ del datagrama IP en el que
encerrará el datagrama que ha recibido para encaminar.  Esa máquina debe saber
cómo desencapsular datagramas IPIP, esto es, debe también estar configurada con
un dispositivo túnel.

<sect2>Configuración de la máquina cuyos paquetes serán encapsulados
<p>

No tiene por qué estar encaminando una red entera. Por ejemplo puede
estar encapsulando una sola dirección IP. En este caso podría configurar
el dispositivo <tt/tunl/ en la máquina `remota' con su dirección IP y el
extremo <tt/A/ usará la máquina encaminadora (y <it/Proxy Arp/) en lugar
encaminar la red a través del dispositivo túnel. Dibujemos de nuevo y
modifiquemos apropiadamente nuestra configuración. Ahora tenemos una máquina
<tt/B/ que quiere actuar y comportarse como si estuviera conectada a Internet y
al mismo tiempo fuera parte de una red remota soportada por la máquina
<tt/A/:

<tscreen><verb>
 192.168.1/24

     -
     |      ppp0 =                ppp0 =
     |  aaa.bbb.ccc.ddd      fff.ggg.hhh.iii
     |
     |   /-----\                 /-----\
     |   |     |       //        |     |
     |---|  A  |------//---------|  B  |
     |   |     |     //          |     |
     |   \-----/                 \-----/
     |                      también: 192.168.1.12
     -
</verb></tscreen>

El encaminador Linux <tt/A/ debería configurarse así:

<tscreen><verb>
#!/bin/sh
PATH=/sbin:/usr/sbin
mask=255.255.255.0
remotegw=fff.ggg.hhh.iii
#
# Configuración Ethernet
ifconfig eth0 192.168.1.1 netmask $mask up
route add -net 192.168.1.0 netmask $mask eth0
#
# Configuración ppp0 (iniciar enlace ppp, establecer ruta por defecto)
pppd
route add default ppp0
#
# Configuración del dispositivo túnel
ifconfig tunl0 192.168.1.1 up
route add -host 192.168.1.12 gw $remotegw tunl0
#
# Proxy ARP para la máquina remota
arp -s 192.168.1.12 xx:xx:xx:xx:xx:xx pub
</verb></tscreen>

El encaminador Linux <tt/B/ debería configurarse así:

<tscreen><verb>
#!/bin/sh
PATH=/sbin:/usr/sbin
mask=255.255.255.0
remotegw=aaa.bbb.ccc.ddd
#
# Configuración ppp0 (iniciar enlace ppp, establecer ruta por
# defecto)
pppd
route add default ppp0
#
# Configuración del dispositivo túnel
ifconfig tunl0 192.168.1.12 up
route add -net 192.168.1.0 netmask $mask gw $remotegw tunl0
</verb></tscreen>

Esta clase de configuración es más típica de aplicaciones Mobile-IP, donde una
máquina quiere moverse por Internet y mantener una única IP fija. Debería leer
la sección Mobile-IP (IP Móvil) si quiere más información de cómo se hace esto
en la práctica.

<sect1>Enmascarado IP (<it>IP Masquerade</it>)
<p>

Mucha gente dispone de una sola cuenta por conexión telefónica para
conectarse a Internet. Casi todos los que utilizan esa configuración se ve
limitado a una sola dirección IP que le da el Proveedor de Servicios de
Internet. Esto normalmente es bastante para permitir un sólo acceso
completo a la red. El Enmascarado IP es un truco inteligente que permite
que varias máquinas usen una sola dirección IP, haciendo que las otras
máquinas se hagan pasar, y de ahí el término de enmascaramiento, por la
máquina que realmente tiene la conexión. Hay un pequeño defecto y es que
el enmascarado funciona casi siempre en un sólo sentido, y este es que las
máquinas enmascaradas pueden hacer llamadas, pero no pueden aceptar o
recibir llamadas de otras máquinas remotas. Esto significa que algunos
servicios de red como <em/talk/ no funcionarán y otros como <em/ftp/
deberán ser configurados en modo pasivo (PASV) para que funcionen. 
Afortunadamente los servicios de red más comunes como <em/telnet/, WWW e
<em/irc/ funcionan bien.

<bf/Opciones de Compilación de Red/:

<tscreen><verb>
    Code maturity level options  --->
        [*] Prompt for development and/or incomplete code/drivers
    Networking options  --->
        [*] Network firewalls
        ....
        [*] TCP/IP networking
        [*] IP: forwarding/gatewaying
        ....
        [*] IP: masquerading (EXPERIMENTAL)
</verb></tscreen>

Lo normal es que su máquina Linux esté usando una línea slip o PPP como si
fuera una máquina aislada. Sin embargo, podemos tener además otros
dispositivos de red configurados, quizá una ethernet, configurada con una
de las direcciones de red privadas. Las máquinas que van a ser
enmascaradas podrían estar en esta segunda red. Cada una de ellas debería
tener asignada la dirección IP del puerto Ethernet de la máquina Linux
como la pasarela (<it/gateway/) por defecto.

Una configuración típica podría ser algo parecido a:

<tscreen><verb>
-                                   -
 \                                  | 192.168.1.0
  \                                 |   /255.255.255.0
   \                 ---------      |
    |                | Linux | .1.1 |
NET =================| masq  |------|
    |    PPP/slip    | router|      |  --------
   /                 ---------      |--| host |
  /                                 |  |      |
 /                                  |  --------
-                                   -
</verb></tscreen>

<em>Enmascarado con IPFWADM</em>

Las órdenes más importantes para esta configuración son:

<tscreen><verb>
# Ruta de red hacia la Ethernet
route add -net 192.168.1.0 netmask 255.255.255.0 eth0
#
# Ruta por defecto al resto de Internet
route add default ppp0
#
# Hace que todas las máquinas de la red 192.168.1/24 sean
# enmascarados
ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0
</verb></tscreen>

<em>Enmascarado con IPCHAINS</em>

<tscreen><verb>
# Ruta de red hacia la Ethernet
route add -net 192.168.1.0 netmask 255.255.255.0 eth0
#
# Ruta por defecto al resto de Internet
route add default ppp0
#
# Hace que todas las máquinas de la red 192.168.1/24 sean
# enmascarados
ipchains -A forward -s 192.168.1.0/24 -j MASQ
</verb></tscreen>

Puede obtener más información sobre Enmascarado IP de Linux en la página de
recursos de IP Masquerade <tt><htmlurl
url="http://www.hwy401.com/achau/ipmasq/"
name="http://www.hwy401.com/achau/ipmasq"></tt>. También hay un documento
<em/muy/ detallado que habla sobre enmascaramiento, que es el
<it/IP-Masquerade-Como/ (que también enseña a configurar otros sistemas
operativos para trabajar teniendo un Linux como servidor enmascarador).

<sect1>Proxy IP transparente
<p>

El proxy transparente de IP es una característica que le permite redirigir
servidores o servicios destinados a otra máquina a esos servicios en esta
máquina. Normalmente esto es útil cuando tiene un Linux como encaminador
que además proporciona un servidor proxy. Debería redirigir todas las
conexiones destinadas a este servicio de forma remota al servidor local
de proxy.

<bf/Opciones de Compilación del Núcleo/:

<tscreen><verb>
    Code maturity level options  --->
        [*] Prompt for development and/or incomplete code/drivers
    Networking options  --->
        [*] Network firewalls
        ....
        [*] TCP/IP networking
        ....
        [*] IP: firewalling
        ....
        [*] IP: transparent proxy support (EXPERIMENTAL)
</verb></tscreen>

La configuración de la característica de proxy transparente se realiza
mediante la orden <tt/ipfwadm/.

Un ejemplo que podría ser útil es el siguiente:

<tscreen><verb>
root# ipfwadm -I -a accept -D 0/0 telnet -r 2323
</verb></tscreen>

Este ejemplo hará que cualquier intento de conexión al puerto <tt/telnet/ (23)
por parte de otra máquina sea redirigida al puerto 2323 de esta máquina. Si
tiene un servicio activo en ese puerto, podría redirigir las conexiones telnet,
hacer un registro de lo que pasa, o cualquier cosa que se ajuste a sus
necesidades.

Un ejemplo más interesante es redirigir todo el tráfico <tt/http/ a través
de un almacén caché local. Sin embargo, el protocolo usado por los
servidores proxy es diferente al http nativo: mientras que un cliente
conecta a <tt/www.servidor.com:80/ y pregunta por <tt>/camino/página</tt>,
cuando conecta a la caché local busca <tt/proxy.dominio.local:8080/ y
pregunta por <tt>www.servidor.com/camino/página</tt>.

Para filtrar una petición <tt/http/ a través del proxy local, necesitará
adaptar el protocolo insertando un pequeño servidor llamado <tt/transproxy/ (lo
puede encontrar en la web). Si quiere puede ejecutarlo en el puerto 8081, y
ejecutar esta orden:

<tscreen><verb>
root# ipfwadm -I -a accept -D 0/0 80 -r 8081
</verb></tscreen>

Entonces, el programa <tt/transproxy/ recibirá todas las conexiones que tengan
que alcanzar servidores externos y las pasará al proxy local arreglando las
diferencias de protocolo.

<sect1>IPv6
<label id="IPv6">
<p>

¡Justo ahora que creía que empezaba a entender las redes IP las reglas
cambian! IPv6 es la notación abreviada de la versión 6 del Internet
Protocol. IPv6 fue desarrollada principalmente para responder a los
temores de la comunidad de Internet al respecto de que pronto habrá
escasez de direcciones IP para asignar. Las direcciones IPv6 son de 16
bytes (128 bits). IPv6 incorpora varios cambios más, en su mayor parte
simplificaciones, que harán que las redes IPv6 sean más manejables que las
IPv4.

Linux ya tiene una implementación de IPv6 que funciona, pero no está
completa, a partir de la serie de núcleos <tt/2.2.*/.

Si quiere experimentar con esta próxima generación de tecnología de
Internet, o le hace falta, debería leerse la <it/IPv6-FAQ/ que está disponible
en <tt><htmlurl url="http://www.terra.net/ipv6/"
name="http://www.terra.net/ipv6"></tt>.

<sect1>Mobile IP
<label id="Mobile IP">
<p>

El término <it/movilidad de IP/ describe la habilidad de una máquina que es
capaz de mover su conexión de red de un punto de Internet a otro sin cambiar su
dirección IP o perder conectividad. Normalmente cuando una máquina con IP
cambia su punto de conexión también debe cambiar su dirección IP. La Movilidad
de IP soluciona este problema asignando una IP fija a la máquina móvil y usando
encapsulación IP (<it/tunneling/) con encaminado automático para asegurar que
los datagramas destinados a ella se encaminan a la verdadera dirección IP que
esté usando en ese momento.

Está en camino un proyecto para proporcionar un juego completo de herramientas
de movilidad de IP para Linux. El estado del proyecto y las herramientas los
puede obtener de la página principal de Linux Mobile IP <tt><htmlurl
url="http://anchor.cs.binghamton.edu/~mobileip/"
name="http://anchor.cs.binghamton.edu/~mobileip"></tt>.

<sect1>Multicast
<label id="Multicast">
<p>

IP Multicast permite encaminar datagramas IP hacia a un número arbitrario de
máquinas con IP de forma simultánea. Este mecanismo se explota para
proporcionar material de amplia distribución por Internet como transmisiones de
imagen y sonido y otras aplicaciones noveles.

<bf/Opciones de Compilación del Núcleo/:

<tscreen><verb>
     Networking options  --->
         [*] TCP/IP networking
         ....
         [*] IP: multicasting
 </verb></tscreen>

Esto requiere un conjunto de herramientas y algo de configuración de la red.
Una fuente de información sobre cómo instalar y configurar esto para Linux la
encontramos en <tt><htmlurl name="http://www.teksouth.com/linux/multicast"
url="http://www.teksouth.com/linux/multicast/"></tt>.

<sect1>NAT - Network Address Translation (Traducción de direcciones de
red)
<label id="NAT">
<p>

El servicio de Traducción de Direcciones de Redes IP es algo así como el
hermano mayor estandarizado del servicio de Enmascarado IP de Linux.  Está
especificado con cierto detalle en el <it/RFC-1631/ en su archivo RFC más
próximo.  NAT proporciona características que no posee el Enmascarado IP que lo
hacen eminentemente más apropiado para su uso en los diseños de encaminamiento
de cortafuegos corporativos y en instalaciones a mayor escala.

Michael Hasenstein, <tt><htmlurl
url="mailto:Michael.Hasenstein@informatik.tu-chemnitz.de"
name="Michael.Hasenstein@informatik.tu-chemnitz.de"></tt>, ha desarrollado una
implementación alfa de NAT para el núcleo <tt/2.0.29/ de Linux. La
documentación e implementación de Michaels está disponible en: la página Web de
<it/Linux IP Network Address/ <tt><htmlurl
name="http://www.csn.tu-chemnitz.de/HyperNews/get/linux-ip-nat.html"
url="http://www.csn.tu-chemnitz.de/HyperNews/get/linux-ip-nat.html"></tt>

Los núcleos más modernos de Linux <tt/2.2.x/ también incluyen algo de la
funcionalidad NAT en el algoritmo de encaminamiento.

<sect1>Traffic Shaper (Manipulación del ancho de banda)
<label id="Traffic Shaper">
<p>

El traffic shaper (regulador de caudal) es un controlador que crea nuevas
interfaces de red, las cuales tienen una limitación en el caudal, definida por
el usuario, y que actúan sobre una interfaz de red física para hacer la
comunicación real, pudiendo ser utilizadas por el encaminador para el tráfico
saliente.

El regulador fue introducido con Linux-2.1.15 y fue portado a Linux-2.0.36
(apareció en el <tt/2.0.36-pre-patch-2/ distribuido por Alan Cox, el autor
del dispositivo regulador y mantenedor de Linux-2.0).

El regulador de caudal sólo puede ser compilado como módulo y para
configurarlo se usa el programa <em/shapecfg/ con órdenes como las
siguientes:

<tscreen><verb>
shapecfg attach shaper0 eth1
shapecfg speed shaper0 64000
</verb></tscreen>

El dispositivo regulador sólo puede controlar el ancho de banda del tráfico de
salida, ya que los paquetes son transmitidos a través suyo de acuerdo con las
tablas de rutas; sin embargo, una funcionalidad de <it/rutas por dirección de
origen/ podría ayudar a limitar el ancho de banda global de máquinas específicas
que estén usando un encaminador Linux.

Linux-2.2 implementa también ese tipo de encaminamiento, y si lo necesita en
Linux-2.0, busque el parche de Mike McLagan, en
<tt><htmlurl url="ftp://ftp.invlogic.com" name="ftp://ftp.invlogic.com"></tt>.
Lea <tt>Documentation/networking/shaper.txt</tt> si desea más información al
respecto del <em/shaper/.

Si quiere probar un intento de regulación de caudal de paquetes entrantes,
use <tt>rshaper-1.01</tt> (o más nuevo). Lo encontrará en <tt><htmlurl
url="ftp://ftp.systemy.it/pub/develop"
name="ftp://ftp.systemy.it/pub/develop"></tt>.

<sect1>Encaminamiento con Linux-2.2
<p>

La última versión de Linux, la 2.2, ofrece mucha flexibilidad en lo que a
política de encaminamiento se refiere. Desafortunadamente, deberá esperar
a la siguiente versión de este Como, o acudir a las fuentes del núcleo.

<sect>Uso de hardware común en los PC
<p>

<sect1>RDSI
<p>

La Red Digital de Servicios Integrados (RDSI) es una serie de estándares
que especifican una red digital conmutada de propósito general. Una
llamada RDSI crea un servicio de datos asíncrono punto a punto hacia el
destino. RDSI suele distribuirse con un enlace de gran velocidad que se
divide en varios canales discretos. Hay dos tipos de canales diferentes,
los <it/Canales B/ que son los que realmente transportan los datos del
usuario y un sólo canal llamado <it/canal D/ que se usa para enviar
información de control a la RDSI para establecer llamadas y otras
funciones. En Australia, por ejemplo, RDSI se distribuye con un enlace
de 2Mbps que se divide en 30 canales discretos B de 64kbps con un canal D
de 64kbps.  Se pueden usar cualquier número de canales en cualquier
momento y en cualquier combinación. Usted podría, por ejemplo, establecer
30 llamadas separadas a 30 destinos diferentes a 64kbps cada uno, o
15 llamadas a 15 destinos diferentes a 128kbps cada uno (dos canales por
llamada), o sencillamente un pequeño número de llamadas y dejar el resto
de los canales sin usar. Se puede usar un canal tanto para llamadas
entrantes como salientes. La intención original de la RDSI fue permitir a
las compañías de telecomunicaciones proporcionar un sólo servicio de datos
que pudiera transmitir tanto teléfono (mediante voz digitalizada) como
servicios de datos a su casa o negocio sin que tuviera que hacer ningún cambio
especial de configuración.

Hay unas pocas maneras diferentes de conectar su ordenador a un servicio
RDSI. Una manera es usar un dispositivo llamado <it/Adaptador Terminal/ que se
enchufa a la Unidad Terminadora de Red que su compañía local de
telecomunicaciones tuvo que instalar al proporcionarle el servicio RDSI y que
presenta unas cuantas interfaces serie. Uno de estos interfaces se
usa para introducir instrucciones de establecimiento de llamadas y la
configuración y los otros son los que realmente se conectan a los
dispositivos de red que usarán los circuitos de datos cuando se hayan
establecido. Linux trabajará con este tipo de configuración sin
modificación alguna, simplemente tiene que tratar el puerto del Adaptador
Terminal como trataría cualquier otro dispositivo serie.  Otra manera,
que es para la que está diseñado el soporte de RDSI del núcleo permite instalar
una tarjeta RDSI en su máquina Linux y dejar entonces que sea el propio Linux
quien maneje los protocolos y haga las llamadas.

<bf/Opciones de Compilación del Núcleo/:

<tscreen><verb>
    ISDN subsystem  --->
        <*> ISDN support
        [ ] Support synchronous PPP
        [ ] Support audio via ISDN
        < > ICN 2B and 4B support
        < > PCBIT-D support
        < > Teles/NICCY1016PC/Creatix support
 </verb></tscreen>

La implementación del núcleo de Linux de la RDSI soporta varios tipos
diferentes de tarjetas RDSI. Son las que vienen listadas en las opciones de
configuración del núcleo.

<itemize>
<item/ICN 2B and 4B/
<item/Octal PCBIT-D/
<item/Tarjetas Teles ISDN y compatibles/
</itemize>

Algunas de estas tarjetas requieren que se les carguen ciertos programas
antes de funcionar. Hay una utilidad aparte que hace esto.

Hay disponibles más detalles de cómo configurar el soporte RDSI de Linux
en el directorio <tt>/usr/src/linux/Documentation/isdn/</tt> y también un
listado <it/PUF/ (Pregutas de Uso Frecuente) dedicado a <tt>isdn4linux</tt> en
<tt><htmlurl url="http://www.lrz-muenchen.de/~ui161ab/www/isdn/"
name="http://www.lrz-muenchen.de/~ui161ab/www/isdn"></tt>.  (Puede pulsar sobre
la bandera inglesa para la versión en inglés).

<bf/Una nota al respecto de PPP/. El conjunto de protocolos PPP operará
tanto sobre lineas serie síncronas como asíncronas. El demonio PPP
(<tt/pppd/) que se suele distribuir para Linux sólo soporta el modo
asíncrono. Si desea ejecutar los protocolos PPP sobre el servicio RDSI,
necesitará una versión especial modificada. En la documentación
anteriormente mencionada encontrará detalles de cómo encontrarlo.

En <tt><htmlurl url="http://www.insflug.org/documentos/RDSI-Como/"
name="http://www.insflug.org/documentos/RDSI-Como/"></tt> tiene a su
disposición un documento con detalles específicos de la configuración en
España.

<sect1>PLIP en Linux-2.0
<p>

Los nombres de los dispositivos PLIP son `<tt/plip0/', `<tt/plip1/' y
`<tt/plip2/'.

<bf/Opciones de Compilación del Núcleo/:

<tscreen><verb>
    Network device support  --->
        <*> PLIP (parallel port) support
</verb></tscreen>

<em/plip/ (Parallel Line IP), se parece a SLIP en que se usa para
proporcionar conexiones <em/punto a punto/ entre dos máquinas, excepto en
que está diseñado para usar los puertos paralelos de impresora de la
máquina en lugar de los puertos serie (se incluye un diagrama de cableado
en la sección de diagramas de cableado más adelante). Como es posible
transmitir más de un bit a la vez con un puerto paralelo, es posible
obtener mayores velocidades con la interfaz <em/plip/ que con los
dispositivos serie estándar.  Además, puede aprovecharse incluso el más
sencillo de los puertos paralelos, el puerto de impresora, en lugar de
tener que comprar una UART 16550AFN, comparativamente más cara, para los
puertos serie. PLIP usa mucha CPU si lo comparamos con un enlace serie y
casi seguro que no será una buena opción si puede obtener algunas tarjetas
Ethernet baratas, pero funcionará cuando no esté disponible nada más y
además lo hará bastante bien.  Se puede esperar una tasa de transferencia
de alrededor de 20 kilobytes por segundo cuando el enlace está funcionando
correctamente.

Los controladores de dispositivo de PLIP compiten con el controlador de
dispositivo paralelo por el hardware del puerto paralelo. Si desea usar ambos
controladores deberá compilar los dos como módulos para asegurarse de que es
capaz de elegir qué puerto quiere que use PLIP y qué puertos usará como
dispositivos para la impresora. Lea el <it/Modules mini-Howto/ para obtener más
información sobre la configuración de los módulos en el núcleo.

Por favor tenga en cuenta que algunos portátiles usan circuitería que no
funcionará con PLIP porque no permiten algunas combinaciones de señales en las
que se basa PLIP, que las impresoras no usan.

El interfaz <tt/plip/ de Linux es compatible con el <em/Crynwyr Packet Driver
PLIP/ y esto significa que puede conectar su máquina Linux a una máquina DOS
que esté ejecutando cualquier clase de programas tcp/ip mediante <tt/plip/.

En la serie de núcleos 2.0.* los dispositivos PLIP están asignados a
puertos e IRQ como sigue

<tscreen><verb>
    dispositivo  i/o    IRQ
    ----------- -----   ---
    plip0       0x3bc   5
    plip1       0x378   7
    plip2       0x278   2
</verb></tscreen>

Si sus puertos paralelos no se ajustan a alguna de las combinaciones de encima
entonces tendrá que cambiar la IRQ de un puerto usando el parámetro <tt/irq/ de
la orden <tt/ifconfig/. Asegúrese de que activa las IRQ de los puertos de
impresora en la ROM BIOS antes, si es que dispone de esa opción. Como
alternativa, puede especificar las opciones <tt/io=/ e <tt/irq=/ como
argumentos a <tt/insmod/, si usa módulos. Por ejemplo:

<tscreen><verb>
root# insmod plip.o io=0x288 irq=5
</verb></tscreen>

La operación PLIP se controla con dos retardos, cuyos valores por defecto
suelen ser correctos. Posiblemente necesite incrementarlos si tiene una
máquina un tanto lenta, en cuyo caso los temporizadores a incrementar
están en la <bf/otra/ máquina. Hay un programa llamado <tt/plipconfig/ que
permite cambiar la configuración de los temporizadores sin recompilar el
núcleo. Viene con muchas distribuciones Linux.

Para configurar una interfaz <em/plip/, necesitará invocar las siguientes
órdenes (o <bf/añadirlas/ a su guión de iniciación del sistema):

<tscreen><verb>
root# /sbin/ifconfig plip1 pliplocal pointopoint plipremota
root# /sbin/route add plipremota plip1
</verb></tscreen>

Aquí, el puerto usado es el que está en la dirección E/S <tt/0x378/;
<tt/pliplocal/ y <tt/plipremota/ son los nombres o direcciones IP usadas para
los extremos del cable PLIP. Personalmente, prefiero tenerlas en mi base de
datos <tt>/etc/hosts</tt>:

<tscreen><verb>
# entradas plip
192.168.3.1   pliplocal
192.168.3.2   plipremota
</verb></tscreen>

El parámetro <tt/pointopoint/ tiene el mismo significado que para SLIP, en el
que especifica la dirección de la máquina en el otro extremo del enlace.

En casi todos los aspectos, se puede tratar una interfaz <tt/plip/ como si
fuese una interfaz <tt/SLIP/, excepto que no se puede (ni se necesita)
usar <tt/dip/ ni <tt/slattach/.

Para obtener más información al respecto de PLIP, acuda al <it/PLIP
mini-Howto/. 

<sect1>PLIP en Linux-2.2
<p>

Durante el desarrollo de las versiones 2.1 del núcleo, se cambió la
implementación del puerto paralelo, hacia una configuración mejor.

<bf/Opciones de compilación del núcleo/:

<tscreen><verb>
    General setup  --->
        [*] Parallel port support
    Network device support  --->
        <*> PLIP (parallel port) support
</verb></tscreen>

El nuevo código de PLIP se comporta como el anterior (se usan las mismas
órdenes <tt/ifconfig/ y <tt/route/ que en la sección anterior, pero la
iniciación del dispositivo es diferente debido a la avanzada implementación del
manejo del puerto paralelo).

El «primer» dispositivo PLIP siempre es denominado <tt/plip0/, siendo
éste el que primero detecta el sistema, de manera similar a lo que ocurre
con los dispositivos Ethernet. El verdadero puerto paralelo que se va a
usar es uno de los que estén disponibles, tal como se muestra en
<tt>/proc/parport</tt>. Por ejemplo, si sólo tiene un puerto paralelo,
sólo tendrá un directorio llamado <tt>/proc/parport/0</tt>.

Si el núcleo no detecta la IRQ usada por el puerto, <tt>insmod plip</tt>
fallará; en este caso simplemente tendrá que escribir el número correcto en
<tt>/proc/parport/0/irq</tt> y reinvocar <tt/insmod/.

Hay disponible información completa al respecto del puerto paralelo en el
archivo <tt>Documentation/parport.txt</tt>, parte de las fuentes de su
núcleo.

<sect1>PPP
<p>

Los nombres de los dispositivos PPP son <tt/ppp0/, <tt/ppp1/, etc. Los
dispositivos están numerados de forma secuencial de manera que el primer
dispositivo configurado recibe el <tt/0/.

<bf/Opciones de compilación del Núcleo/:

<tscreen><verb>
    Networking options  --->
        <*> PPP (point-to-point) support
</verb></tscreen>

La configuración del PPP está cubierta en detalle en el PPP-Como, <tt><htmlurl
url="http://www.insflug.org/documentos/PPP-Como/"
name="http://www.insflug.org/documentos/PPP-Como/"></tt>.

<sect2>Mantener una conexión permanente a la red usando <tt>pppd</tt>.
<p>

Si es tan afortunado como para tener una conexión semi-permanente a la red y
quiere hacer que su máquina establezca automáticamente la conexión PPP si se
pierde, existe un truco sencillo para hacerlo.

Configure el PPP de tal manera que pueda ser iniciado por el usuario
<tt/root/ ejecutando la orden:

<tscreen><verb>
# pppd
</verb></tscreen>

<bf/Asegúrese/ de que tiene configurada la opción <tt/-detach/ en el fichero
<tt>/etc/ppp/options</tt>. Entonces, inserte la siguiente línea en el fichero
<tt>/etc/inittab</tt>, bajo las definiciones de <tt/getty/.

<tscreen><verb>
pd:23:respawn:/usr/sbin/pppd
</verb></tscreen>

Esto hará que el programa <tt/init/ ejecute y monitorice el programa <tt/pppd/
y que lo reinicie automáticamente si muere.

<sect1>Cliente SLIP
<p>

Los nombres de los dispositivos SLIP son <tt/sl0/, <tt/sl1/, etc.  siendo
asignado el <tt/0/ al primer dispositivo configurado y el resto incrementando
secuencialmente según van siendo configurados.

<bf/Opciones de compilación del núcleo/:

<tscreen><verb>
    Network device support  --->
        [*] Network device support
        <*> SLIP (serial line) support
        [ ]  CSLIP compressed headers
        [ ]  Keepalive and linefill
        [ ]  Six bit SLIP encapsulation
</verb></tscreen>

El SLIP (<it/Serial Line Internet Protocol/) le permite usar tcp/ip sobre una
línea serie, sea una línea de teléfono con un módem, o una línea dedicada.  Por
supuesto para usar SLIP necesitará tener acceso a un <em>servidor SLIP</em> de
algún tipo. Muchas universidades y empresas de todo el mundo proporcionan
acceso mediante SLIP.

Slip usa los puertos serie de su máquina para transportar datagramas IP.
Para hacerlo debe tomar el control del dispositivo serie. Los dispositivos
SLIP se denominan <tt/sl0/, <tt/sl1/, etc. ¿Cómo se corresponden a sus
dispositivos serie? El código de red usa lo que denominados una llamada
<em>ioctl</em> (i/o control - control de e/s) para convertir los dispositivos
serie en dispositivos SLIP. Se le proporcionan dos programas
que pueden hacer esto, y se llaman <tt>dip</tt> y <tt>slattach</tt>.

<sect2>dip
<p>

<tt>dip</tt> (Dialup IP) es un sofisticado programa capaz de programar la
velocidad del dispositivo serie, ordenar a su módem que llame al otro extremo
del enlace, identificarle automáticamente en el servidor remoto, examinar los
mensajes que le envía el servidor y obtener información tal como su dirección
IP y ejecutar las <em>ioctl</em> necesarias para conmutar su puerto serie al
modo SLIP. <tt>dip</tt> tiene una gran capacidad para ejecutar guiones
(scripts) y esto lo puede explotar para automatizar el procedimiento de
autenticación.

Puede encontrarlo en: <tt><htmlurl
url="ftp://metalab.unc.edu/pub/Linux/system/Network/serial/dip/dip337o-uri.tgz"
name="ftp://metalab.unc.edu/pub/Linux/system/Network/serial/dip/dip337o-uri.tgz"></tt>.

Para instalarlo, intente lo siguiente:

<tscreen><verb>
    usuario% cd /usr/src
    usuario% gzip -dc dip337o-uri.tgz | tar xvf -
    usuario% cd dip-3.3.7o
    root# make install
</verb></tscreen>

El <tt>Makefile</tt> asume la existencia de un grupo denominado <tt>uucp</tt>,
pero puede que usted quiera cambiarlo a <tt>dip</tt> o <tt>SLIP</tt>
dependiendo de su configuración.

<sect2>slattach
<p>

<tt>slattach</tt> es un programa muy sencillo comparado con <tt>dip</tt>, muy
fácil de usar, pero no tiene la sofisticación de <tt>dip</tt>. No tiene
capacidad para ejecutar guiones, todo lo que hace es configurar su dispositivo
serie como dispositivo SLIP. Asume que tiene toda la información que necesita
y la línea serie se establece antes de que lo invoque. <tt>slattach</tt> es
ideal para usarlo donde necesite una conexión permanente al servidor, como un
cable físico o una línea dedicada.

<sect2>¿Cuándo usar cada uno?
<p>

Debería usar <tt>dip</tt> cuando su enlace a la máquina servidora de SLIP es un
módem, o algún otro enlace temporal. Debería usar <tt>slattach</tt> cuando
disponga de una línea dedicada, quizá un cable, entre su máquina y el servidor,
y no se necesita ejecutar ninguna acción especial para hacer que el enlace
funcione. Mire la sección <ref id="Conexion Permanente con Slip" name="Conexión
Permanente con Slip"> para más información.

configurar SLIP se parece mucho a configurar una interfaz Ethernet (lea la
sección <ref id="Ethernet" name="Configuración
de un dispositivo Ethernet"> más atrás).  Sin embargo, hay unas pocas
diferencias clave.

Antes que nada, los enlaces SLIP son diferentes a las redes Ethernet en
que sólo hay dos máquinas en la red, una en cada extremo del enlace. Al
contrario que con Ethernet que está disponible para su uso nada más que
termine de cablear, con SLIP, dependiendo del tipo de enlace que tenga,
puede que tenga que iniciar la conexión de red de alguna manera especial.

Si está usando <tt>dip</tt> entonces esto no debería hacerlo en el momento de
arrancar, sino algo más adelante, cuando esté preparado para usar el enlace. Es
posible automatizar este procedimiento.  Si está usando <tt>slattach</tt>
entonces probablemente quieras añadir una sección a su fichero
<tt>rc.*</tt> correspondiente. Esto lo describiremos pronto.

Hay dos tipos principales e servidores SLIP: servidores de direcciones IP
dinámicas y servidores de direcciones IP estáticas. Casi cualquier
servidor SLIP le pedirá al conectar una identificación y una contraseña.
<tt>dip</tt> puede proporcionar estos datos automáticamente.

<sect2>Servidor SLIP estático con línea por llamada y DIP.
<p>

Un servidor estático de SLIP es aquél en el que se le ha dado una dirección IP
que es exclusivamente suya. Cada vez que conecte al servidor, tendrá que
configurar su puerto SLIP con esa dirección. El servidor estático de SLIP
contestará a la llamada del módem, posiblemente le pregunte su nombre de
usuario y contraseña, y entonces encaminará cualquier datagrama destinado a su
dirección mediante esa conexión. Si tiene un servidor estático, entonces puede
que quiera añadir una entrada con su dirección IP y el nombre de su máquina (ya
que sabe cuales serán) en <tt>/etc/hosts</tt>. También debería configurar
algunos otros ficheros como: <tt>rc.*</tt>, <tt>host.conf</tt>,
<tt>resolv.conf</tt>, <tt>/etc/HOSTNAME</tt> y <tt>rc.local</tt>. Recuerde que
cuando configure <tt>rc.*</tt>, no necesita añadir ninguna orden especial para
la conexión SLIP ya que es <tt>dip</tt> el que hace todo el trabajo duro al
configurar la interfaz. Necesitará proporcionarle a <tt>dip</tt> la información
apropiada de manera que configure la interfaz por usted después de ordenarle al
módem que establezca la llamada y de darle de alta en el servidor SLIP.

Si esta es la manera de trabajar de su servidor SLIP entonces puede pasar
a la sección <ref id="Uso de Dip" name="Uso de Dip"> para aprender a configurar
<tt>dip</tt> de forma apropiada.

<sect2>Servidor SLIP dinámico con línea por llamada y DIP.
<p>

Un servidor <em>dinámico</em> de SLIP es aquél que le asigna una dirección IP
al azar, a partir de una reserva de direcciones, cada vez que se registra. Eso
significa que no hay garantías de que tenga una dirección en particular cada
vez, y esa dirección puede ser usada por otra persona después de que usted haya
desconectado. El administrador de red que configuró el servidor SLIP habrá
asignado un rango de direcciones para que el servidor SLIP las use, cuando el
servidor recibe una nueva llamada entrante, localiza la primera dirección sin
asignar, guía a quien llama a través del procedimiento de registro y entonces
imprime un mensaje de bienvenida que contiene la dirección IP que se le ha
asignado, para entonces proceder a usar esa dirección IP durante toda la
llamada.

La configuración para este tipo de servidor es similar a la configuración
para un servidor estático, excepto en que debe añadir un paso en el que obtiene
la dirección IP que el servidor le ha asignado y configura su dispositivo SLIP
con ella.

De nuevo, <tt>dip</tt> hace el trabajo duro y las nuevas versiones son
suficientemente sofisticadas no sólo como para registrarle, sino también como
para leer automáticamente la dirección IP impresa en el mensaje de bienvenida y
almacenarla de manera que pueda configurar el dispositivo SLIP con ella.

Si esta es la manera de trabajar de su servidor SLIP, entonces puede pasar a la
sección <ref id="Uso de Dip" name="Uso de Dip"> para aprender a configurar
<tt>dip</tt> de forma apropiada.

<sect2>Uso de Dip.
<label id="Uso de Dip">
<p>

Como se explicó anteriormente, <tt>dip</tt> es un programa potente que puede
simplificar y automatizar el proceso de llamada a el servidor SLIP, registro,
inicio de la conexión y configuración de tus dispositivos SLIP con las órdenes
<tt>ifconfig</tt> y <tt>route</tt> apropiadas.

Esencialmente, para usar <tt>dip</tt> escribiremos un «guión dip», que es
básicamente una lista de órdenes que <tt>dip</tt> comprende y que le dicen
cómo debe realizar cada una de las acciones que usted quiere que haga.  Eche un
vistazo al fichero <tt>sample.dip</tt> que viene con <tt>dip</tt> para hacerse
una idea de cómo funciona. <tt>dip</tt> es un programa bastante potente, con
muchas opciones. No las va a encontrar todas aquí, y tendrá que mirar la
correspondiente página <tt/man/, el <tt/README/ y los ficheros de ejemplo que
vendrán con su versión de <tt>dip</tt>.

Fíjese en que el guión <tt>sample.dip</tt> asume que está accediendo a un
servidor SLIP estático, por lo que su IP ya se conoce de antemano. Las nuevas
versiones de <tt>dip</tt> incluyen, para los servidores SLIP dinámicos, una
orden que puede usarse para leer y configurar automáticamente el dispositivo
SLIP con la dirección IP que el servidor dinámico le asigna. El ejemplo
siguiente es una versión modificada y traducida del <tt>sample.dip</tt> que
viene con <tt>dip337j-uri.tgz</tt> y probablemente sea un buen punto de
partida. Puede que quiera grabarlo como <tt>/etc/guiondip</tt> y editarlo para
que se ajuste a su configuración.

<tscreen><verb>
#
# sample.dip    Programa de soporte de conexión para Dialup IP
#
#               Este fichero (debería mostrar) muestra el uso de DIP
#       Este fichero debería funcionar para los servidores dinámicos
#       de tipo Annex, si usted usa un servidor estático entonces utilice
#       el fichero sample.dip que viene en el paquete dip337-uri.tgz
#
#
# Versión:      @(#)sample.dip  1.40    20/07/93
#
# Autor:        Fred N. van Kempen, <waltje@uWalt.NL.Mugnet.ORG>
#

main:
# Lo siguiente es configurar el nombre y dirección del otro extremo
# La máquina a la que llamo se llama 'xs4all.hacktic.nl'
# (== 193.78.33.42)
get $remote xs4all.hacktic.nl
# Asignar 255.255.255.0 como máscara de red de sl0
netmask 255.255.255.0
# Asignar el puerto serie y velocidad deseados
port cua02
speed 38400

# Reiniciar el módem y la línea terminal
# ¡Esto parece darle problemas a algunas personas!
reset

# ¡Nota! Valores "estándar" predefinidos de "errlevel"
#  0 - OK
#  1 - CONNECT
#  2 - ERROR
#
# Puede cambiarlos buscando "addchat()" en *.c...

# Nos preparamos para llamar.
send ATQ0V1E1X4\r
wait OK 2
if $errlvl != 0 goto problema_con_modem
dial 555-1234567
if $errlvl != 1 goto problema_con_modem

# Estamos conectados. Registrarse en el sistema.
login:
sleep 2
wait ogin: 20
if $errlvl != 0 goto problema_al_registrarse
send MILOGIN\n
wait ord: 20
if $errlvl != 0 goto clave_erronea
send MIPASSWD\n
loggedin:

# Ahora estamos registrados.
wait SOMEPROMPT 30
if $errlvl != 0 goto error_de_prompt

# Ordenamos al servidor que entre en modo SLIP
send SLIP\n
wait SLIP 30
if $errlvl != 0 goto error_de_prompt

# Obtenemos nuestra dirección IP del servidor y la asignamos
#   Aquí asumiremos que tras ordenar al servidor SLIP que entre
#   en modo SLIP, nos imprime nuestra dirección IP.
get $local remote 30
if $errlvl != 0 goto prompt_error

# Configurar los parámetros operativos de SLIP
get $mtu 296
# Aseguramos que se ejecuta "route add -net default xs4all.hacktic.nl"
default

# ¡Decimos hola y arrancamos!
done:
print CONNECTED $local ---> $rmtip
mode CSLIP
goto salir

error_de_prompt:
print Se produjo un TIME-OUT esperando a que arrancara sliplogin
goto error

problema_al_registrarse:
print Hubo un problema esperando por el mensaje Login:...
goto error

clave_erronea:
print Hubo un problema esperando por el mensaje Password:...
goto error

problema_con_modem:
print Hubo un problema con el módem...
error:
print FALLÓ LA CONEXIÓN a $remote
quit

salir:
exit
</verb></tscreen>

El ejemplo anterior asume que estamos llamando a un servidor SLIP
<em>dinámico</em>. Si está llamando a un servidor SLIP <em>estático</em>,
entonces debería funcionarle el fichero <tt>sample.dip</tt> que viene con
<tt>dip-337-uri.tgz</tt>.

Cuando se le da a <tt>dip</tt> la orden <tt>get &dollar;local</tt>, busca en el
texto que viene del otro extremo una cadena que se parezca a una dirección IP,
osea una cadena de números separados por caracteres «.». Esta modificación se
hizo específicamente pensando en los servidores SLIP <em>dinámicos</em>, para
que el proceso de leer la dirección IP pudiera ser automatizado.

El ejemplo anterior creará automáticamente una ruta por defecto a través del
enlace SLIP. Si no es lo que deseaba, a lo mejor porque tiene una conexión
Ethernet que debería ser la ruta por defecto, entonces elimine la orden
<tt>default</tt> del guión. Después de que haya acabado de ejecutarse el guión,
si ejecuta la orden <tt>ifconfig</tt>, verá que hay un dispositivo
<tt>sl0</tt>. Este es el dispositivo SLIP. Si fuese necesario, podría modificar
su configuración a mano, después de que la orden <tt>dip</tt> haya acabado,
usando las órdenes <tt>ifconfig</tt> y <tt>route</tt>.

Por favor, observe que <tt>dip</tt> le permite elegir varios protocolos
diferentes en la orden <tt>mode</tt>. El ejemplo más común es <em>cSLIP</em>
que es SLIP con compresión. Por favor, tenga en cuenta que ambos extremos del
enlace deben concordar, por lo que debe asegurarse de que elija lo que elija,
sea la mismo que lo que tenga el servidor.

El ejemplo anterior es bastante robusto y debería copar con la mayoría de los
errores. Para obtener más información, haga el favor de dirigirse a las páginas
man de <tt>dip</tt>. Naturalmente podría, por ejemplo, codificar un guión para
que haga cosas como llamar de nuevo al servidor si no consigue conectarse tras
un periodo de tiempo determinado, o incluso hacer intentos con varios
servidores si tiene acceso a más de uno.

<sect2>Conexión SLIP permanente usando una línea dedicada y slattach
<label id="Conexion Permanente con Slip"> 
<p>

Si lo que tiene es un cable entre dos máquinas, o es tan afortunado como para
tener una línea dedicada, o algún otro tipo de conexión en serie permanente
entre su máquina y otra, entonces no necesita la complejidad de usar
<tt>dip</tt> para establecer un enlace serie. <tt>slattach</tt> es una utilidad
muy sencilla de usar, que le permite suficiente funcionalidad como para
configurar una conexión.

Como la conexión será permanente, querrá añadir algunas órdenes al fichero
<tt>rc</tt> pertinente. En esencia, todo lo que necesita hacer para tener una
conexión permanente es asegurarse de que configura el dispositivo serie a la
velocidad correcta y que lo pasa a modo SLIP. <tt>slattach</tt> permite hacer
esto con una sola orden. Añade lo siguiente al fichero <tt>rc</tt> pertinente:

<tscreen><verb>
#
# Activar una conexión SLIP estática por línea dedicada
#
#  configuramos /dev/cua0 para 19.2kbps y cslip
/sbin/slattach -p cslip -s 19200 /dev/cua0 &
/sbin/ifconfig sl0 IPA.IPA.IPA.IPA pointopoint IPR.IPR.IPR.IPR up
#
# Fin de SLIP estático
</verb></tscreen>

<bf>Nota del traductor</bf>: A fecha de la traducción, la serie estable del
núcleo era la <tt/2.2/. En la serie <tt/2.2/, los dispositivos
<tt>/dev/cuaX</tt> han sido completamente eliminados, unificándolos a los
<tt>/dev/ttySX</tt>.

Donde:

<descrip>
<tag>IPA.IPA.IPA.IPA</tag>representa su dirección IP.
<tag>IPR.IPR.IPR.IPR</tag>representa la dirección IP del extremo remoto.
</descrip>

<tt>slattach</tt> asigna el primer dispositivo SLIP sin asignar al dispositivo
serie especificado. <tt>slattach</tt> comienza por <tt>sl0</tt>. Por lo tanto
la primera orden <tt>slattach</tt> asocia el dispositivo SLIP <tt>sl0</tt> al
dispositivo serie especificado y <tt>sl1</tt> la siguiente vez, etc.

<tt>slattach</tt> le permite configurar varios protocolos diferentes con el
argumento <tt>-p</tt>. En su caso podrá usar tanto <tt>SLIP</tt> como
<tt>cSLIP</tt> dependiendo de si quiere o no usar compresión. Nota: ambos
extremos deben estar de acuerdo sobre si usar compresión o no.

<sect1>Servidor SLIP.
<label id="Servidor SLIP">
<p>

Si tiene una máquina, quizá conectada a una red, a la que le gustaría que otra
máquina pudiese llamar y proporcionar servicios de red, entonces necesita
configurarla como servidor. Si quiere usar SLIP como protocolo de línea serie,
entonces tiene tres opciones para configurar su máquina Linux como servidor
SLIP. Yo preferiría usar la primera presentada, <tt>sliplogin</tt>, ya que
parece la más sencilla de configurar y entender, pero presentaré un sumario de
cada una, para que pueda tomar su propia decisión.

<sect2>Servidor slip usando <tt>sliplogin</tt>.
<label id="Servidor slip usando sliplogin">
<p>

<tt/sliplogin/ es un programa, que puede asignar a los usuarios de SLIP en
lugar de un «shell» normal, que convierte una línea terminal en una línea SLIP.
Esto le permite configurar una máquina Linux tanto como <em/servidor de
direcciones estáticas/, obteniendo los usuarios la misma dirección cada vez que
llaman, o como <em/servidor de direcciones dinámicas/, donde los usuarios
obtienen una dirección que no tiene que ser necesariamente la misma que la
última vez que llamaron.

El que llama se registrará igual que en un proceso estándar de <tt/login/,
introduciendo su nombre de usuario y contraseña, pero en lugar de presentarle
un intérprete de órdenes normal tras el registro, se ejecuta <tt/sliplogin/, el
cual busca en su fichero de configuración (<tt>/etc/slip.hosts</tt>) una
entrada con el nombre de usuario que corresponda a la persona que llamó. Si lo
encuentra, entonces configura la línea como «clean» y de 8 bit, y hace una
llamada <em/ioctl/ para convertir la disciplina de la línea a SLIP. Cuando se
completa este proceso, toma lugar la última parte de la configuración, en la
cual <tt/sliplogin/ invoca un guión de intérprete de órdenes que configura la
interfaz SLIP con la dirección ip y máscara de red relevantes, y asigna
las rutas apropiadas. Este guión suele llamarse <tt>/etc/slip.login</tt>
pero, de forma parecida a <tt/getty/, si ciertos usuarios requieren una
iniciación especial, entonces puede crear guiones de configuración llamados
<tt>/etc/slip.login.nombreusuario</tt> que serán ejecutados específicamente
para ellos en lugar del que hay por defecto.

También hay tres o cuatro ficheros que necesitará configurar para tener
<tt/sliplogin/ en funcionamiento. Detallaré cómo y dónde obtener los programas
y cómo se configura cada uno. Los ficheros son:

<itemize>
<item><tt>/etc/passwd</tt>, para las cuentas de los usuarios que llaman.

<item><tt>/etc/slip.hosts</tt>, para almacenar la información única a cada
usuario que llama.

<item><tt>/etc/slip.login</tt>, que lleva la configuración del encaminamiento
que necesite hacerse para el usuario.

<item><tt>/etc/slip.tty</tt>, que será necesario sólo si está configurando el
servidor para asignar direcciones dinámicas y contiene una tabla de direcciones
a asignar.

<item><tt>/etc/slip.logout</tt>, que contiene las órdenes necesarias para dejar
las cosas a punto una vez el usuario cuelgue o cierre la conexión.

</itemize>

<sect3>Dónde obtener <tt>sliplogin</tt>
<p>

Puede que ya tenga el paquete <tt/sliplogin/ instalado como parte de su
distribución; si no es así entonces podrá obtenerlo de: <tt><htmlurl
url="ftp://metalab.unc.edu/pub/linux/system/Network/serial/sliplogin-2.1.1.tar.gz"
name="ftp://metalab.unc.edu/pub/linux/system/Network/serial/sliplogin-2.1.1.tar.gz"></tt>.
El fichero tar contiene tanto las fuentes, como los programas ya compilados y
una página <em/man/.

para asegurar que sólo son capaces de ejecutar <tt/sliplogin/ los usuarios
autorizados, debería añadir una entrada al fichero <tt>/etc/group</tt> similar
a la siguiente:

<tscreen><verb>
 ..
slip::13:radio,fred
 ..
</verb></tscreen>

Cuando instale el paquete <tt/sliplogin/, el <tt/Makefile/ cambiará el grupo al
que pertenece el programa <tt/sliplogin/ por <tt/slip/, y esto significa que
sólo los usuarios que pertenezcan a ese grupo serán capaces de ejecutarlo. El
ejemplo anterior autorizará ejecutar <tt/sliplogin/ sólo a los usuarios
<tt/radio/ y <tt/fred/.

Para instalar los ejecutables en el directorio <tt>/sbin</tt> y la página de
<em/man/ en la sección 8, haga lo siguiente:

<tscreen><verb>
# cd /usr/src
# gzip -dc .../sliplogin-2.1.1.tar.gz | tar xvf -
# cd sliplogin-2.1.1
# <..edite el Makefile si no usa shadow password..>
# make install
</verb></tscreen>

Si quiere recompilar los ejecutables tras la instalación, añada un <tt/make
clean/ antes de <tt/make install/. Si quiere instalar los ejecutables en
cualquier otro lado, necesitará editar la regla <tt/install/ en el
<tt/Makefile/.

Por favor, lea los ficheros <tt/README/ que vienen con el paquete si quiere
obtener más información.

<sect3>Configuración de <tt>/etc/passwd</tt> para máquinas que usan Slip.
<p>

Lo normal es que cree algunos <it/login/ especiales en el fichero
<tt>/etc/passwd</tt> para la gente que llama con Slip. Una convención
comúnmente aceptada es usar el nombre de la máquina que llaman prefijándole una
letra «S» mayúscula. Por tanto, por ejemplo, si la máquina que llama se
denomina <tt/radio/, entonces podrías crear una entrada en <tt>/etc/passwd</tt>
que se pareciese a:

<tscreen><verb>
Sradio:FvKurok73:1427:1:radio SLIP login:/tmp:/sbin/sliplogin
</verb></tscreen>

Realmente no importa cómo se llame la cuenta, siempre y cuando tenga algún
significado para usted.

Nota: el que llama no necesita ningún directorio personal, ya que no se le
presentará ningún intérprete de órdenes, por tanto <tt>/tmp</tt> es una buena
elección. Observe también que se usa <tt/sliplogin/ en lugar de un intérprete
de órdenes normal.

<sect3>Configuración de <tt>/etc/slip.hosts</tt>
<p>

El fichero <tt>/etc/slip.hosts</tt> es el fichero en el que <em/sliplogin/
busca las entradas que se correspondan al nombre de login que de las que
obtiene los detalles de configuración para esa persona. Es aquí donde
se especifica la dirección ip y la máscara de red que se le asignará al que
llama y que serán configuradas para su uso.  Las entradas para dos máquinas,
una con configuración estática para <tt/radio/ y otra, con configuración
dinámica, para la máquina <tt/albert/, deberían parecerse a lo siguiente:

<tscreen><verb>
#
Sradio   44.136.8.99   44.136.8.100  255.255.255.0  normal      -1
Salbert  44.136.8.99   DYNAMIC       255.255.255.0  compressed  60
#
</verb></tscreen>

Las entradas del fichero <tt>/etc/slip.hosts</tt> son

<enum>
<item>el nombre de login del que llama.
<item>la dirección ip de la máquina servidor, osea esta máquina.

<item>la dirección IP que se asignará al que llama. Si este campo se rellena
con <tt/DYNAMIC/ entonces se asignará una dirección ip basada en la información
contenida en el fichero <tt>/etc/slip.tty</tt> del que se habló antes.
<bf/Nota:/ deberá usar al menos la versión <tt/1.3/ de sliplogin para que esto
funcione.

<item>la máscara de red asignada a la máquina que llama en notación decimal
punteada, por ejemplo <tt/255.255.255.0/ para una máscara de red para una clase
C.

<item>las opciones del modo slip, que le permiten activar o desactivar la
compresión y otras características de slip. Los valores permitidos aquí
son <tt/normal/ y <tt/compressed/.

<item>un parámetro de <it/timeout/ que especifica cuánto tiempo puede estar
ociosa la línea (sin recibir datagramas) antes de que se desconecte la línea.
Un valor negativo desactivará esta característica.

<item>argumentos opcionales.
</enum>

Nota: Para los campos 2 y 3 puede usar tanto el nombre de la máquina como su
dirección IP en notación decimal. Si usted usa nombres entonces tendrán que ser
resueltos, esto es, su máquina deberá ser capaz de localizar la dirección ip de
esos nombres o en caso contrario el guión fallará cuando sea ejecutado. Puede
probarlo intentando hacer telnet hacia esos nombres, y si obtiene el mensaje
<tt/Trying nnn.nnn.nnn.../ entonces es que su máquina ha sido capaz de
encontrar una dirección ip para ese nombre. Si obtiene el mensaje <tt/Unknown
host/, entonces no lo consiguió. En este caso, use una dirección ip en notación
decimal o ponga a punto la configuración de su resolutor de nombres. (Ver
sección <ref id="Resolucion de Nombres" name="Resolución de Nombres">).

Los modos slip más comunes son:

<descrip>
<tag>normal</tag>para habilitar el SLIP normal sin compresión.
<tag>compressed</tag>para habilitar la compresión de cabeceras de
van Jacobsen (cSLIP)
</descrip>

Por supuesto, son mutuamente exclusivos. Puede usar uno o el otro, pero no
ambos. Para obtener más información sobre las otras opciones disponibles, ve a
las páginas de <tt>man</tt>.

<sect3>Configuración del fichero <tt>/etc/slip.login</tt>.
<p>

Después de que sliplogin haya examinado el <tt>/etc/slip.hosts</tt> y
encontrado una entrada que concuerde, intentará ejecutar el fichero
<tt>/etc/slip.login</tt> para configurar la interfaz SLIP con su dirección ip y
su máscara.

El fichero de ejemplo <tt>/etc/slip.login</tt> proporcionado con el paquete
<tt>sliplogin</tt> se parece a esto:

<tscreen><verb>
#!/bin/sh -
#
#       @(#)slip.login  5.1 (Berkeley) 7/1/90
#
# fichero de login genérico para una línea SLIP. sliplogin
# lo invoca con los parámetros:
#     $1       $2       $3    $4, $5, $6 ...
# unidadSLIP veloctty   pid   los argumentos de la entrada en slip.host
#
/sbin/ifconfig $1 $5 pointopoint $6 mtu 1500 -trailers up
/sbin/route add $6
arp -s $6 <hw_addr> pub
exit 0
#
</verb></tscreen>

Podrá comprobar que este guión se limita a usar las órdenes <tt>ifconfig</tt> y
<tt>route</tt> para configurar el dispositivo SLIP con su dirección ip,
dirección ip remota y máscara de red y crea una ruta hasta la dirección remota
a través del dispositivo SLIP. Exactamente lo mismo que haría si estuviera
usando la orden <tt>slattach</tt>.

Advierta también el uso de <it>Proxy ARP</it> para asegurar que otras
máquinas en la misma Ethernet que la máquina servidora sabrán cómo llegar
a la máquina que llama. El campo <tt>&lt;hw_addr&gt;</tt> (dirección hardware)
debería ser la dirección hardware de la tarjeta Ethernet de la máquina. Si su
máquina servidora no está en una red Ethernet, entonces puede eliminar
completamente esa línea.

<sect3>Configuración del fichero <tt>/etc/slip.logout</tt>.
<p>

Cuando la llamada se corta, querrá asegurarse de que se restaura el estado
normal del dispositivo serie para que otras personas sean capaces más adelante
de registrarse correctamente. Esto se lleva a cabo mediante el uso del fichero
<tt>/etc/slip.logout</tt>. Es de formato bastante sencillo y se le llama con
los mismos argumentos que al fichero <tt>/etc/slip.login</tt>.

<tscreen><verb>
#!/bin/sh -
#
#               slip.logout
#
/sbin/ifconfig $1 down
arp -d $6
exit 0
#
</verb></tscreen>

Todo lo que hace es desactivar (down) la interfaz, lo que borrará la ruta que
se creó anteriormente. También usa la orden <tt>arp</tt> para borrar cualquier
proxy que se estableciese. De nuevo, no necesita la orden <tt>arp</tt> en el
guión si su máquina servidora no tiene un puerto ethernet.

<sect3>Configuración del fichero <tt>/etc/slip.tty.</tt>
<p>

Si está usando asignación dinámica de direcciones ip (tiene configurada
cualquier máquina con la palabra clave <tt>DYNAMIC</tt> en el fichero
<tt>/etc/slip.hosts</tt>, entonces deberá configurar el fichero
<tt>etc/slip.tty</tt> para que tenga una lista de las direcciones que se
asignarán a qué puerto. Sólo necesita este fichero si desea que su servidor
asigne de manera dinámica las direcciones a los usuarios.

El fichero es una tabla que lista los dispositivos <tt>tty</tt> que darán
soporte a las conexiones SLIP y las direcciones ip que deberían asignarse
a los usuarios que llaman a ese puerto.

Su formato es como sigue:

<tscreen><verb>
# slip.tty    tty -> correspondencias IP para SLIP dinámico
# formato: /dev/tty?? xxx.xxx.xxx.xxx
#
/dev/ttyS0      192.168.0.100
/dev/ttyS1      192.168.0.101
#
</verb></tscreen>

Lo que dice esta tabla es que a la gente que llame al puerto
<tt>/dev/ttyS0</tt> y que tengan la palabra <tt>DYNAMIC</tt> en su campo de
dirección remota en el fichero <tt>/etc/slip.hosts</tt> les será asignada una
dirección de <tt>192.168.0.100</tt>.

De esta manera sólo necesita asignar una dirección por puerto para todos los
usuarios que no requieran una dirección dedicada para ellos. Esto le ayuda a
mantener bajo mínimos los números de dirección para evitar su escasez.

<sect2>Servidor Slip usando <tt>dip</tt>.
<label id="Servidor Slip usando dip">
<p>

Déjeme empezar diciendo que parte de la información que sigue viene de las
páginas de manual de <tt>dip</tt>, donde se documenta brevemente la manera de
usar Linux como servidor SLIP. por favor, preste atención, puesto que lo
siguiente está basado en el paquete <tt>dip337o-uri.tgz</tt> y probablemente no
ses aplicable a otrs versiones de <tt>dip</tt>.

<tt>dip</tt> tiene un modo de operación de entrada, en el cual asigna
automáticamente una entrada para el usuario que lo invoque y configura la línea
serie como enlace SLIP de acuerdo con la información que encuentre en el
fichero <tt>/etc/dipshosts</tt>. Este modo de operación de entrada se activa
invocando a <tt>dip</tt> como <tt>diplogin</tt>. Es así por tanto la manera de
usar <tt>dip</tt> como servidor SLIP, creando cuentas especiales donde se usa
<tt>diplogin</tt> como <it/login shell/.

Lo primero que necesita hacer es un enlace simbólico como sigue:

<tscreen><verb>
# ln -sf /usr/sbin/dip /usr/sbin/diplogin
</verb></tscreen>

Después necesitará añadir entradas tanto al fichero <tt>/etc/passwd</tt> como
al <tt>/etc/diphosts</tt>. Las entradas que necesita hacer tienen el formato
que sigue:

Para configurar Linux como servidor SLIP con <tt>dip</tt>, se necesita crear
algunas cuentas SLIP especiales para los usuarios, en las que se usa
<tt>dip</tt> (en modo entrada) como <it/login shell/. Se sugiere la convención
de comenzar los nombres de las cuentas SLIP con una <tt/S/ mayúscula, como por
ejemplo <tt/Sfredm/.

Una entrada en <tt>/etc/passwd</tt> para un usuario SLIP se parece a:

<tscreen><verb>
Sfredm:ij/SMxiTlGVCo:1004:10:Fred:/tmp:/usr/sbin/diplogin
^^         ^^        ^^  ^^   ^^   ^^   ^^
|          |         |   |    |    |    \__ diplogin como login shell
|          |         |   |    |    \_______ Directorio `home'
|          |         |   |    \____________ Nombre completo del usuario
|          |         |   \_________________ ID de grupo del usuario
|          |         \_____________________ ID del usuario
|          \_______________________________ Contraseña cifrada
\__________________________________________ Nombre de Login del Usuario SLIP
</verb></tscreen>

Después de que el usuario se registre, el programa <tt>login</tt>, si encuentra
y autentica al usuario, ejecutará la orden <tt>diplogin</tt>.  <tt>dip</tt>,
cuando es invocado como <tt>diplogin</tt>, sabe que debe asumir automáticamente
que va a ser usado como intérprete de órdenes de <it/login/. Cuando comienza
como <tt>diplogin</tt>, la primera cosa que hace es usar la función
<tt>getuid()</tt> para tomar el userid de quien fuera que lo invocó. Entonces
busca en el fichero <tt>/etc/diphosts</tt> la primera entrada que se
corresponda bien con el userid, bien con el dispositivo <tt>tty</tt> por el que
entró la llamada y se configura apropiadamente. Por razones de sentido común,
para que se pueda dar a un usuario una entrada en el fichero <tt>diphosts</tt>,
o bien para que se le dé la configuración por defecto, es posible montar el
servidor de tal manera que se pueda tener una mezcla de usuarios a los que se
asigne la dirección de forma estática o dinámica.

<tt>dip</tt> añadirá automáticamente una entrada <it/Proxy-ARP/ si se le invoca
en modo entrada, por lo que no tendrá que preocuparse de hacerlo manualmente.

<sect3>Configuración del fichero /etc/diphosts
<p>

<tt>/etc/diphosts</tt> lo usa <tt>dip</tt> para buscar configuraciones ya
establecidas para máquinas remotas. Estas máquinas remotas pueden ser usuarios
que llaman a la máquina Linux, o pueden ser máquinas a las que usted llamas
desde su máquina.

El formato general para <tt>/etc/diphosts</tt> es como sigue:

<tscreen><verb>
 ..
Suwalt::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006
ttyS1::145.71.34.3:145.71.34.2:255.255.255.0:Dynamic ttyS1:CSLIP,296
 ..
</verb></tscreen>

Los campos son:

<enum>

<item><tt>nombre de login</tt>: el que devuelve <tt/getpwuid(getuid())/ o el
nombre de la tty.

<item><tt>sin uso</tt>: para compatibilidad con <tt/passwd/

<item><tt>Dirección Remota</tt>: dirección IP de la máquina que llama, puede
ser tanto la numérica como el nombre.

<item><tt>Dirección Local</tt>: dirección IP de esta máquina, en número o por
nombre.

<item><tt>Máscara de red</tt>: en notación decimal puntuada.
<item><tt>Campo de comentario</tt>: ponga aquí lo que quiera.
<item><tt>protocolo</tt>: Slip, cSLIP, etc.
<item><tt>MTU</tt>: número decimal.

</enum>

Un ejemplo de entrada en <tt>/etc/net/diphosts</tt> para un usuario SLIP
remoto podría ser:

<tscreen><verb>
Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:SLIP,296
</verb></tscreen>

lo que especifica un enlace SLIP con dirección remota <tt/145.71.34.1/ y MTU de
<tt/296/, o:

<tscreen><verb>
Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006
</verb></tscreen>

que especifica un enlace capaz de usar cSLIP con dirección remota
<tt/145.71.34.1/ y MTU de <tt/1006/.

Por tanto, todos los usuarios que desee que tengan asignado un acceso de
llamada con IP estática deberían tener una entrada en <tt>/etc/diphosts</tt>.
Si quiere que los usuarios que llaman a un puerto en particular y, que los
detalles sean asignados dinámicamente, deberá tener entonces una entrada para
el dispositivo <tt>tty</tt> y no una basada en el usuario. Debería configurar
al menos una entrada para cada dispositivo <tt>tty</tt> que usen los usuarios
para asegurar que hay disponible para ellos una configuración adecuada
independientemente al módem al que llamen.

Cuando un usuario se registra recibirá las preguntas normales sobre su
cuenta y contraseña en las que debería introducir su userid o contraseña
de SLIP-login. Si se verifican, entonces el usuario no verá mensajes
especiales y sólo tendrá que cambiar el modo SLIP en su extremo. El
usuario debería ser capaz de conectar y quedar configurado con los
parámetros relevantes del fichero <tt>diphosts</tt>.

<sect2>Servidor SLIP usando el paquete <tt>dSLIP</tt>.
<label id="Servidor SLIP usando el paquete dSLIP">
<p>

Matt Dillon, <tt><htmlurl url="mailto:dillon@apollo.west.oic.com"
name="dillon@apollo.west.oic.com"></tt> ha escrito un paquete que no sólo hace
llamadas SLIP entrantes sino también llamadas salientes.  El paquete de Matt es
una combinación de pequeños programas y guiones que coordinan las conexiones
por usted. Necesitará tener instalado <tt>tcsh</tt> ya que al menos uno de los
guiones lo necesita. Matt proporciona una copia ejecutable de la utilidad
<tt>expect</tt> ya que la necesita otro de los guiones. Además necesitará tener
algo de experiencia con <tt>expect</tt> para hacer que este paquete funcione a
su gusto, pero no deje que eso le desanime.

Matt ha escrito unas instrucciones de instalación muy buenas en el fichero
<tt/README/, por lo que no pienso repetirlas.

Puede obtener el paquete dSLIP de su sitio de origen:

<tt><htmlurl url="ftp://apollo.west.oic.com/pub/linux/dillon_src/dSLIP203.tgz"
name="ftp://apollo.west.oic.com/pub/linux/dillon_src/dSLIP203.tgz"></tt>

o desde:

<tt><htmlurl
url="ftp://metalab.unc.edu/pub/Linux/system/Network/serial/dSLIP203.tgz"
name="ftp://metalab.unc.edu/pub/Linux/system/Network/serial/dSLIP203.tgz"></tt>

Léase el fichero <tt>README</tt> y cree las entradas en <tt>/etc/passwd</tt> y
<tt>/etc/group</tt> antes de hacer <tt>make install</tt>.

<sect>Otras tecnologías de red
<p>

Las siguientes subsecciones son específicas a ciertas tecnologías de red.  La
información que contienen no son válidas necesariamente para cualquier otro
tipo de tecnología. Los conceptos están ordenados alfabéticamente.

<sect1>ARCNet
<p>

Los nombres de dispositivo ARCNet son <tt/arc0e/, <tt/arc1e/, <tt/arc2e/
etc. o <tt/arc0s/, <tt/arc1s/, <tt/arc2s/ etc. A la primera tarjeta detectada
por el núcleo se le asigna <tt/arc0e/ o <tt/arc0s/ y el resto es asignado
secuencialmente en el orden en que se detecte. La letra del final identifica si
ha seleccionado el formato de paquete de encapsulación Ethernet o el formato de
paquete especificado en el <it/RFC 1051/.

<bf/Opciones de Compilación del Núcleo/:

<tscreen><verb>
    Network device support  --->
        [*] Network device support
        <*> ARCnet support
        [ ]   Enable arc0e (ARCnet "Ether-Encap" packet format)
        [ ]   Enable arc0s (ARCnet RFC1051 packet format)
</verb></tscreen>

Una vez que haya compilado el núcleo apropiadamente para admitir su tarjeta
Ethernet, la configuración de la tarjeta es sencilla.

Normalmente se usa algo como:

<tscreen><verb>
# ifconfig arc0e 192.168.0.1 netmask 255.255.255.0 up
# route add -net 192.168.0.0 netmask 255.255.255.0 arc0e
</verb></tscreen>

Lea, por favor, los ficheros
<tt>/usr/src/linux/Documentation/networking/arcnet.txt</tt> y
<tt>/usr/src/linux/Documentation/networking/arcnet-hardware.txt</tt> si desea
obtener más información.

La implementación de ARCNet fue desarrollada por Avery Pennarun,
<tt><htmlurl url="mailto:lapenwarr@foxnet.net"
name="lapenwarr@foxnet.net"></tt>.

<sect1>Appletalk (<tt>AF_APPLETALK</tt>)
<p>

La implementación de Appletalk no utiliza nombres especiales para sus
dispositivos ya que usa otros ya existentes.

<bf/Opciones de Compilación del Núcleo/:

<tscreen><verb>
    Networking options  --->
        <*> Appletalk DDP
</verb></tscreen>

Trabajar con Appletalk permite a una máquina Linux interconectar con redes
Apple. Una utilidad importante que se saca de esto es poder compartir recursos
tales como impresoras y discos entre una máquina Linux y ordenadores Apple. Se
necesita un programa adicional, que se llama <em/netatalk/. Wesley Craig
<tt><htmlurl url="mailto:netatalk@umich.edu" name="netatalk@umich.edu"></tt>
representa a un equipo llamado el <it/Research Systems Unix Group/, de la
Universidad de Michigan y han creado el paquete <em/netatalk/, que proporciona
programas que implementan la pila del protocolo Appletalk y algunas utilidades.
El paquete <em/netatalk/ viene en su distribución de Linux, y si no, lo puede
encontrar en su servidor de origen, en la Universidad de Michigan <tt><htmlurl
url="ftp://terminator.rs.itd.umich.edu/unix/netatalk/"
name="ftp://terminator.rs.itd.umich.edu/unix/netatalk/"></tt>.

Para compilar e instalar el paquete haga algo como esto:

<tscreen><verb>
user% tar xvfz .../netatalk-1.4b2.tar.Z
user% make
root# make install
</verb></tscreen>

Puede que quiera editar el <tt/Makefile/ antes de ejecutar <tt/make/.
Principalmente para cambiar la variable <tt/DESTDIR/, que define el lugar donde
serán instalados los ficheros. El directorio por defecto
<tt>/usr/local/atalk</tt> suele ser una buena elección.

<sect2>Configuración del software Appletalk.
<p>

La primera cosa que tiene que hacer para que todo funcione es asegurarse de que
están presentes las entradas apropiadas en el fichero <tt>/etc/services</tt>.
La entradas que necesita son:

<tscreen><verb>
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
</verb></tscreen>

El siguiente paso es crear los ficheros de configuración de Appletalk en el
directorio <tt>/usr/local/atalk/etc</tt> (o donde haya instalado el paquete).

El primer fichero a crear es el <tt>/usr/local/atalk/etc/atalkd.conf</tt>.  En
principio, este fichero sólo necesita una línea que da el nombre del
dispositivo a través del cual se accede a la red donde están tus máquinas
Apple.

<tscreen><verb>
eth0
</verb></tscreen>

El demonio Appletalk añadirá más detalles después de ejecutarse.

<sect2>Exportación de un sistema de ficheros Linux vía Appletalk.
<p>

Existe la posibilidad de exportar sistemas de ficheros desde una máquina Linux
a la red para que las máquinas Apple en la red puedan compartirlos.
  
Para hacerlo tiene que configurar el fichero
<tt>/usr/local/atalk/etc/AppleVolumes.system</tt>. Hay otro fichero de
configuración llamado <tt>/usr/local/atalk/etc/AppleVolumes.default</tt>, que
tiene exactamente el mismo formato y describe qué sistemas de archivos
recibirán los usuarios que conecten con privilegios de invitado.

Puede encontrar todos los detalles de configuración de estos ficheros y qué
significa cada opción en la página de manual del <tt>afpd</tt>.

Un ejemplo sencillo podría parecerse a esto:

<tscreen><verb>
/tmp Scratch
/home/ftp/pub "Espacio Público"
</verb></tscreen>

Que exportaría su sistema de ficheros <tt>/tmp</tt> como el Volumen AppleShare
<tt/Scratch/ y el directorio público de FTP como el Volumen AppleShare
<tt/Espacio Público/. Los nombres de volumen no son obligatorios, el demonio
elegirá un nombre por defecto, pero no le va a morder si lo especifica.

<sect2>Compartir la impresora Linux a través de Appletalk.
<p>

Puede compartir una impresora linux con máquinas Apple de manera bastante
sencilla. Necesita ejecutar el programa <tt>papd</tt> que es el <it/Printer
Access Protocol Daemon/ de Appletalk. Cuando ejecute este programa, aceptará
peticiones de las máquinas Apple y meterá la tarea de impresión en la cola del
demonio de la impresora local para ser impreso.  
Debe editar el fichero <tt>/usr/local/atalk/etc/papd.conf</tt> para configurar
el demonio. La sintaxis de este fichero es la misma que la del fichero
<tt>/etc/printcap</tt>. El nombre que le dé a la definición se registrado con
el protocolo de nombres de Appletalk, NBP.

Un ejemplo de configuración podría ser como éste:

<tscreen><verb>
TricWriter:\
   :pr=lp:op=cg:
</verb></tscreen>

Que pondría a disposición de la red Appletalk la impresora <tt/TricWriter/ y
todos los trabajos aceptados serían impresos en la impresora linux <tt/lp/
(definida en el fichero <tt>/etc/printcap</tt>) usando <tt>lpd</tt>. La entrada
<tt/op=cg/ dice que el usuario de Linux <tt/cg/ es el operador de la
impresora.

<sect2>Ejecución de AppleTalk.
<p>

Muy bien, ahora debería estar preparado para probar esta configuración básica.
Hay un fichero <tt>rc.atalk</tt> proporcionado con el paquete <tt>netatalk</tt>
que debería funcionar bien, por lo que todo lo que tiene que hacer es:

<tscreen><verb>
root# /usr/local/atalk/etc/rc.atalk
</verb></tscreen>

y todo debería comenzar y ejecutarse bien. No debería ver mensajes de error y
el software enviará mensajes a la consola indicando cada etapa según comienza.

<sect2>Comprobación de AppleTalk.
<p>

Para comprobar que el software está funcionando adecuadamente, vaya a una de
las máquinas Apple, abra el menú Apple, seleccione el <it/Chooser/, pulse sobre
<it/AppleShare/, y debería aparecer la máquina Linux.

<sect2>Problemas con AppleTalk.
<p>

<itemize>

<item>Puede que necesite ejecutar el software Appletalk antes de configurar la
red IP. Si tiene problemas ejecutando los programas Appletalk, o si después de
ejecutarlo tiene problemas con la red IP, entonces intente ejecutar los
programas Appletalk antes de ejecutar el fichero <tt>rc</tt> correspondiente.


<item>El <tt>afpd</tt> (<it/Apple Filing Protocol Daemon/) desordena mucho el
disco duro. Bajo el punto de montaje crea un par de directorios llamados
<tt>.AppleDesktop</tt> y <tt>Network Trash Folder</tt>. Además, por cada
directorio al que acceda creará un <tt>.AppleDouble</tt> bajo él de manera que
pueda almacenar <it/resource forks/, etc. Por tanto, piénselo dos veces antes
de exportar <tt>/</tt>, o se pasará un rato borrando después.

<item>El programa <tt>afpd</tt> espera que las claves que vengan de los Mac
estén sin cifrar. Esto podría ser un problema de seguridad; por tanto, sea
cuidadoso cuando ejecute este demonio en una máquina conectada a Internet, o
sufrirá las consecuencias si algún indeseable decide hacerle alguna maldad.

<item>Las herramientas de diagnóstico existentes como <tt>netstat</tt> e
<tt>ifconfig</tt> no soportan Appletalk. La información «en bruto» está
disponible en el directorio <tt>/proc/net</tt> si tuviese necesidad de ella.

</itemize>

<sect2>Si necesitase más información...
<p>  

Eche un vistazo a la página del <em/Linux Netatalk-Howto/ de Anders Brownworth
si quiere una descripción más detallada de cómo configurar Appletalk para Linux
en <tt><htmlurl url="http://thehamptons.com/anders/netatalk/"
name="http://thehamptons.com/anders/netatalk"></tt>.

<sect1>ATM
<p>

Werner Almesberger, <tt><htmlurl url="mailto:werner.almesberger@lrc.di.epfl.ch"
name="werner.almesberger@lrc.di.epfl.ch"></tt> está dirigiendo un proyecto para
proporcionar una implementación del <it/Asynchronous Transfer Mode/ en Linux.
Puede obtener información actualizada sobre el estado del proyecto en:
<tt><htmlurl url="http://lrcwww.epfl.ch/linux-atm/"
name="http://lrcwww.epfl.ch/linux-atm"></tt>.

<sect1>AX25 (<tt>AF_AX25</tt>)
<p>

Los nombres de los dispositivos AX.25 son <tt/sl0/, <tt/sl1/, etc. en los
núcleos <tt/2.0.*/ y <tt/ax0/, <tt/ax1/, etc. a partir de los núcleos
<tt/2.1.*/.

<bf/Opciones de Compilación del Núcleo/:

<tscreen><verb>
    Networking options  --->
        [*] Amateur Radio AX.25 Level 2
</verb></tscreen>

Los protocolos AX25, Netrom y Rose están cubiertos por el <tt><htmlurl
url="AX25-HOWTO.html" name="AX25 Howto"></tt>.  Estos protocolos son usados por
los Operadores de Amateur Radio de todo el mundo para experimentar con packet
radio.

La mayoría del trabajo de implementación de estos protocolos lo ha hecho
Jonathon Naylor, <tt><htmlurl url="mailto:jsn@cs.nott.ac.uk"
name="sn@cs.nott.ac.uk"></tt>.

<sect1>DECNet
<p>

Actualmente se está trabajando en la implementación de DECNet. Debería aparecer
en algún núcleo <tt/2.1.*/ tardío.

<sect1>FDDI
<p>

Los nombres de dispositivo FDDI son <tt/fddi0/, <tt/fddi1/, <tt/fddi2/, etc. A
la primera tarjeta detectada por el núcleo se le asigna <tt/fddi0/ y al resto
se le asigna secuencialmente en el orden en que son detectadas.

Lawrence V. Stefani, <tt><htmlurl url="mailto:larry_stefani@us.newbridge.com"
name="larry_stefani@us.newbridge.com"></tt>, ha desarrollado un controlador
para las tarjetas FDDI EISA y PCI de <it/Digital Equipment Corporation/.

<bf/Opciones de Compilación del Núcleo/:

<tscreen><verb>
    Network device support  --->
        [*] FDDI driver support
        [*] Digital DEFEA and DEFPA adapter support
</verb></tscreen>

Cuando tenga el núcleo compilado para trabajar con el controlador FDDI e
instalado, la configuración de la interfaz FDDI es casi idéntica al de una
interfaz Ethernet. Simplemente ha de especificar la interfaz FDDI apropiada en
las órdenes <tt/ifconfig/ y <tt/route/.

<sect1>Retransmisión de Tramas (<tt>Frame Relay</tt>)
<p>

Los nombres de dispositivo Frame Relay son <tt/dlci00/, <tt/dlci01/, etc para
los dispositivos de encapsulación DLCI y <tt/sdla0/, <tt/sdla1/, etc para los
FRAD.

El Frame Relay (Retransmisión de tramas) es una tecnología de red diseñada para
ajustarse al tráfico de comunicación de datos que es de naturaleza «explosiva»
o intermitente. La conexión a una red Frame Relay se realiza usando un
<it/Frame Relay Access Device/ (FRAD). El Linux Frame Relay implementa IP sobre
Frame Relay según se describe en el <it/RFC-1490/.

<bf/Opciones de Compilación del Núcleo/:

<tscreen><verb>
    Network device support  --->
        <*> Frame relay DLCI support (EXPERIMENTAL)
        (24)   Max open DLCI
        (8)   Max DLCI per device
        <*>   SDLA (Sangoma S502/S508) support
</verb></tscreen>

Mike McLagan, <tt><htmlurl url="mailto:mike.mclagan@linux.org"
name="mike.mclagan@linux.org"></tt>, desarrolló el soporte de Frame Relay y las
herramientas de configuración.

Actualmente los únicos FRAD soportados son los <tt/S502A/, <tt/S502E/ y
<tt/S508/ de <it/Sangoma Technologies/ <tt><htmlurl
url="http://www.sangoma.com/" name="http://www.sangoma.com"></tt> Para
configurar los dispositivos FRAD y DLCI después de haber recompilado el núcleo
necesitará las herramientas de configuración Frame Relay. Están disponibles en
<tt><htmlurl url="ftp://ftp.invlogic.com/pub/linux/fr/frad-0.15.tgz"
name="ftp://ftp.invlogic.com/pub/linux/fr/frad-0.15.tgz"></tt>. Compilar e
instalar las herramientas es algo muy sencillo, pero la carencia de un fichero
<tt/Makefile/ para todo lo convierte en un proceso básicamente manual:

<tscreen><verb>
user% tar xvfz .../frad-0.15.tgz
user% cd frad-0.15
user% for i in common dlci frad; make -C $i clean; make -C $i; done
root# mkdir /etc/frad
root# install -m 644 -o root -g root bin/*.sfm /etc/frad
root# install -m 700 -o root -g root frad/fradcfg /sbin
root# install -m 700 -o root -g root dlci/dlcicfg /sbin
</verb></tscreen>

Tenga en cuenta que estas órdenes usan sintaxis de <tt/sh/. Si utiliza un
intérprete de órdenes tipo <tt/csh/ (como <tt/tcsh/), el bucle <tt/for/ será
diferente.

Después de instalar las herramientas necesitará crear un fichero
<tt>/etc/frad/router.conf</tt>. Puede usar esta plantilla, que es una versión
modificada de uno de los ficheros de ejemplo:

<tscreen><verb>
# /etc/frad/router.conf
# Esta es una plantilla de configuración para retransmisión de tramas.
# Se incluyen todas las etiquetas. Los valores por defecto están basados
# en el código proporcionado con los controladores DOS para la tarjeta
# Sangoma S502A.
#
# Un '#' en cualquier parte de una línea constituye un comentario
# Los espacios en blanco son ignorados (puede indentar con tabuladores
# también)
# Las entradas [] y claves desconocidas son ignoradas
#

[Devices]
Count=1                 # Número de dispositivos a configurar
Dev_1=sdla0             # el nombre del dispositivo
#Dev_2=sdla1            # el nombre del dispositivo
  
# Lo especificado aquí es aplicado a todos los dispositivos y puede ser
# cambiado para cada tarjeta en particular.
#
Access=CPE
Clock=Internal
KBaud=64
Flags=TX
#
# MTU=1500              # Máxima longitud del IFrame, por defecto 4096
# T391=10               # valor T391    5 - 30, por defecto 10
# T392=15               # valor T392    5 - 30, por defecto 15
# N391=6                # valor N391    1 - 255, por defecto 6
# N392=3                # valor N392    1 - 10, por defecto 3
# N393=4                # valor N393    1 - 10, por defecto 4

# Lo especificado aquí da los valores por defecto para todas las tarjetas
# CIRfwd=16             # CIR forward   1 - 64
# Bc_fwd=16             # Bc forward    1 - 512
# Be_fwd=0              # Be forward    0 - 511
# CIRbak=16             # CIR backward  1 - 64
# Bc_bak=16             # Bc backward   1 - 512
# Be_bak=0              # Be backward   0 - 511

#
#
# Configuración específica para el dispositivo
#
#

#
# El primer dispositivo es un Sangoma S502E
#
[sdla0]
Type=Sangoma            # Tipo del dispositivo a configurar, actualmente
                        # sólo se reconoce SANGOMA
#
# Estas claves son específicas al tipo "Sangoma"
#
# El tipo de tarjeta Sangoma - S502A, S502E, S508
Board=S502E
#
# El nombre del firmware de prueba para la tarjeta Sangoma
# Testware=/usr/src/frad-0.10/bin/sdla_tst.502
#
# El nombre del firmware FR 
# Firmware=/usr/src/frad-0.10/bin/frm_rel.502
#
Port=360                # Puerto de esta tarjeta
Mem=C8                  # Dirección de la memoria, A0-EE, depende
IRQ=5                   # Número de la IRQ, no especificar para la S502A
DLCIs=1                 # Número de DLCI asociados al dispositivo
DLCI_1=16               # Número del DLCI nº 1, 16 - 991
# DLCI_2=17
# DLCI_3=18
# DLCI_4=19
# DLCI_5=20
#
# Lo especificado aquí se aplica a este dispositivo nada más y
# prevalece sobre los valores por defecto
#
# Access=CPE            # CPE o NODE, por defecto CPE
# Flags=TXIgnore,RXIgnore,BufferFrames,DropAborted,Stats,MCI,AutoDLCI
# Clock=Internal        # External o Internal, por defecto Internal
# Baud=128              # Tasa en baudios del CSU/DSU asociado
# MTU=2048              # Longitud máxima del IFrame, por defecto 4096
# T391=10               # valor T391    5 - 30, por defecto 10
# T392=15               # valor T392    5 - 30, por defecto 15
# N391=6                # valor N391    1 - 255, por defecto 6
# N392=3                # valor N392    1 - 10, por defecto 3
# N393=4                # valor N393    1 - 10, por defecto 4

#
# El segundo dispositivo es otra tarjeta
#
# [sdla1]
# Type=FancyCard        # Type of the device to configure.
# Board=                # Type of Sangoma board
# Key=Value             # values specific to this type of device

#
# DLCI Default configuration parameters
# These may be overridden in the DLCI specific configurations
#
CIRfwd=64               # CIR forward   1 - 64
# Bc_fwd=16             # Bc forward    1 - 512
# Be_fwd=0              # Be forward    0 - 511
# CIRbak=16             # CIR backward  1 - 64
# Bc_bak=16             # Bc backward   1 - 512
# Be_bak=0              # Be backward   0 - 511

#
# DLCI Configuration
# These are all optional. The naming convention is
# [DLCI_D<devicenum>_<DLCI_Num>]
#

[DLCI_D1_16]
# IP=
# Net=
# Mask=
# Flags defined by Sangoma: TXIgnore,RXIgnore,BufferFrames
# DLCIFlags=TXIgnore,RXIgnore,BufferFrames
# CIRfwd=64
# Bc_fwd=512
# Be_fwd=0
# CIRbak=64
# Bc_bak=512
# Be_bak=0

[DLCI_D2_16]
# IP=
# Net=
# Mask=
# Flags defined by Sangoma: TXIgnore,RXIgnore,BufferFrames
# DLCIFlags=TXIgnore,RXIgnore,BufferFrames
# CIRfwd=16
# Bc_fwd=16
# Be_fwd=0
# CIRbak=16
# Bc_bak=16
# Be_bak=0
</verb></tscreen>
  
Cuando haya terminado el fichero <tt>/etc/frad/router.conf</tt>, el único paso
que queda es configurar el dispositivo en sí. Esto es sólo un poco más complejo
que la configuración de un dispositivo de red normal. Debe recordar activar el
dispositivo FRAD antes que los dispositivos de encapsulación DLCI. Es mejor que
ponga estas órdenes en un guión, ya que son muchos:

<tscreen><verb>
#!/bin/sh
# Configurar los parámetros del frad y los DLCI
/sbin/fradcfg /etc/frad/router.conf || exit 1
/sbin/dlcicfg file /etc/frad/router.conf
#
# Activar el dispositivo FRAD
ifconfig sdla0 up
#
# Configurar los dispositivos de encapsulación DLCI
ifconfig dlci00 192.168.10.1 pointopoint 192.168.10.2 up
route add -net 192.168.10.0 netmask 255.255.255.0 dlci00
#
ifconfig dlci01 192.168.11.1 pointopoint 192.168.11.2 up
route add -net 192.168.11.0 netmask 255.255.255.0 dlci00
#
route add default dev dlci00
#
</verb></tscreen>

<sect1>IPX (<tt>AF_IPX</tt>)
<p>

El protocolo IPX se usa comúnmente en entornos de redes de área local Novell
Netware(tm). Linux incluye una implementación de este protocolo y puede ser
configurado para actuar como punto final en una red, o como encaminador de IPX.

<bf/Opciones de Compilación del Núcleo/:

<tscreen><verb>
    Networking options  --->
        [*] The IPX protocol
        [ ] Full internal IPX network
</verb></tscreen>

Los protocolos IPX y el NCPFS están cubiertos en gran profundidad en el
<tt><htmlurl url="IPX-HOWTO.html" name="IPX Howto"></tt>.

<sect1>NetRom (<tt>AF_NETROM</tt>)
<p>

Los nombres de los dispositivos NetRom son <tt/nr0/, <tt/nr1/, etc.

<bf/Opciones de Compilación del Núcleo/:

<tscreen><verb>
    Networking options  --->
        [*] Amateur Radio AX.25 Level 2
        [*] Amateur Radio NET/ROM
</verb></tscreen>

Los protocolos AX25, Netrom y Rose están cubiertos en el <tt><htmlurl
url="AX25-HOWTO.html" name="AX25 Howto"></tt>. Estos protocolos los usan
Operadores de Amateur Radio de todo el mundo en la experimentación de
<it/packet radio/.

La mayoría del trabajo de la implementación de estos protocolos lo ha
Jonathon Naylor, <tt><htmlurl url="mailto:jsn@cs.nott.ac.uk"
name="jsn@cs.nott.ac.uk"></tt>.

<sect1>Protocolo Rose (<tt>AF_ROSE</tt>)
<p>

Los nombres de los dispositivos Rose son <tt/rs0/, <tt/rs1/, etc, en los
núcleos <tt/2.1.*/. Rose está disponible a partir de los núcleos <tt/2.1.*/.

<bf/Opciones de Compilación del Núcleo/:

<tscreen><verb>
    Networking options  --->
        [*] Amateur Radio AX.25 Level 2
        <*> Amateur Radio X.25 PLP (Rose)
</verb></tscreen>

Los protocolos AX25, Netrom y Rose están cubiertos por el <tt><htmlurl
url="AX25-HOWTO.html" name="AX25 Howto"></tt>. Estos protocolos los usan
Operadores de Amateur Radio de todo el mundo en la experimentación de
<it/packet radio/.
  
La mayoría del trabajo de la implementación de estos protocolos lo ha
hecho Jonathon Naylor, <tt><htmlurl url="mailto:jsn@cs.nott.ac.uk"
name="jsn@cs.nott.ac.uk"></tt>. 

<sect1>Soporte SAMBA - NetBEUI, NetBios.
<p>

SAMBA es una implementación del protocolo <it/Session Management Block/.  Samba
permite que los sistemas de Microsoft (y otros) monten y usen sus discos e
impresoras.

SAMBA y su configuración vienen cubiertos en detalle en el <tt><htmlurl
url="http://www.insflug.org/documentos/Samba-Como/"
name="http://www.insflug.org/documentos/Samba-Como/"></tt>.

<sect1>Soporte de STRIP (<it>Starmode Radio IP</it>)
<p>

Los nombres de los dispositivos STRIP son <tt/st0/, <tt/st1/, etc.

<bf/Opciones de Compilación del Núcleo/:

<tscreen><verb>
    Network device support  --->
        [*] Network device support
        ....
        [*] Radio network interfaces
        < > STRIP (Metricom starmode radio IP)
</verb></tscreen>

STRIP es un protocolo diseñado específicamente para un rango de radio-módems
Metricon para un proyecto de investigación conducido por la Universidad de
Stanford llamado MosquitoNet Project <tt><htmlurl
url="http://mosquitonet.Stanford.EDU/mosquitonet.html"
name="http://mosquitonet.Stanford.EDU/mosquitonet.html"></tt>. Es muy
interesante leerse esto, incluso si no está interesado directamente en el
proyecto.

Las radios Metricon se conectan a un puerto serie, emplean tecnología de
espectro amplio y suelen ser capaces de alcanzar los 100kbps. Hay información
disponible acerca de las radios Metricon en el servidor Web de Metricon
<tt><htmlurl url="http://www.metricom.com/"
name="http://www.metricom.com"></tt>.

En estos momentos las herramientas y utilidades estándar de red no implementan
el controlador STRIP, por lo que deberá obtener algunas herramientas preparadas
desde el servidor WWW de MosquitoNet. Los detalles sobre los programas que
necesitará están disponibles en la página de MosquitoNet sobre STRIP
<tt><htmlurl url="http://mosquitonet.Stanford.EDU/strip.html"
name="http://mosquitonet.Stanford.EDU/strip.html"></tt>.

En resumen de la configuración, use un programa <tt/slattach/ modificado para
establecer STRIP como la disciplina de línea de un dispositivo serie tty y
entonces configurar el dispositivo <tt/st[0-9]/ resultante igual que haría con
uno Ethernet con una excepción importante: por razones técnicas, STRIP no
soporta el protocolo ARP, por lo que deberá configurar manualmente las entradas
ARP de cada una de las máquinas en la subred.  Esto no debería ser demasiado
oneroso.

<sect1>Anillo con testigo (<it>Token Ring</it>)
<p>

Los nombres de los dispositivos de anillo con testigo son <tt/tr0/, <tt/tr1/,
etc. El anillo con testigo es un protocolo de red LAN estándar de IBM que evita
colisiones proporcionando un mecanismo que permite que sólo una de las
estaciones en la red tenga en un momento determinado derecho a transmitir. Una
estación mantiene un «testigo» (<it/token/) durante un tiempo determinado y ésa
es la única con permiso para transmitir.  Cuando ha transmitido los datos le
pasa el testigo a la siguiente estación.  El testigo traza un bucle entre todas
las estaciones activas, de ahí el nombre de «Anillo con Testigo».

<bf/Opciones de Compilación del Núcleo/:

<tscreen><verb>
    Network device support  --->
        [*] Network device support
        ....
        [*] Token Ring driver support
        < > IBM Tropic chipset based adaptor support
</verb></tscreen>

La configuración de un anillo con testigo es idéntica a la de una Ethernet con
la excepción del nombre de los dispositivos a configurar.

<sect1>X.25
<p>

El X.25 es un protocolo de circuitos basados en conmutación de paquetes
definido por el <tt/C.C.I.T.T./ (una organización de estándares reconocida por
compañías de Telecomunicaciones en la mayor parte del mundo). En estos momentos
está en funcionamiento una implementación de X.25 y LAPB y los núcleos
<tt/2.1.*/ más recientes incluyen el trabajo que está en progreso.

Jonathon Naylor <tt><htmlurl url="mailto:jsn@cs.nott.ac.uk"
name="jsn@cs.nott.ac.uk"></tt> está liderando el desarrollo y se ha establecido
una lista de correo para discutir materias relativas al X.25 en Linux. Para
suscribirse, envíe un mensaje a: <tt><htmlurl
url="mailto:majordomo@vger.rutgers.edu" name="majordomo@vger.rutgers.edu"></tt>
con el texto <tt/subscribe linux-x25/ en el cuerpo del mensaje.

Se pueden obtener las primeras versiones de las herramientas de configuración
desde el sitio de FTP de Jonathon en <tt><htmlurl
url="ftp://ftp.cs.nott.ac.uk/jsn/" name="ftp://ftp.cs.nott.ac.uk/jsn"></tt>.

<sect1>Tarjeta WaveLan
<p>

Los nombres de los dispositivos Wavelan son <tt/eth0/, <tt/eth1/, etc.

<bf/Opciones de Compilación del Núcleo/:

<tscreen><verb>
Network device support  --->
    [*] Network device support
    ....
    [*] Radio network interfaces
    ....
    <*> WaveLAN support
</verb></tscreen>

La tarjeta WaveLAN es una tarjeta de red LAN inalámbrica de amplio espectro. La
tarjeta se parece bastante en la práctica a una tarjeta Ethernet y se configura
de la misma manera.

Puede obtener información acerca de la tarjeta Wavelan de Wavelan.com
<tt><htmlurl url="http://www.wavelan.com/" name="http://www.wavelan.com"></tt>.

<sect>Cables y Cableado
<p>

Aquellos de ustedes que se manejen con un soldador puede que quieran construir
sus propios cables para interconectar dos máquinas Linux.  Los siguientes
diagramas de cableado deberían serles de ayuda.

<sect1>Cable serie Módem NULO (NULL Modem)
<p>

No todos los cables Módem NULO son iguales. Muchos cables módem nulo hacen poco
más que un pequeño truco para que el ordenador crea que están presentes todas
las señales apropiadas, cruzando los cables de transmisión y recepción. Esto
vale, pero significa que deberá usar programas de control de flujo software
(XON/XOFF), que es menos eficiente que el control de flujo hardware. El
siguiente cable proporciona la mejor señalización posible entre las máquinas y
permite usar control de flujo por hardware (RTS/CTS).

<tscreen><verb>
Nombre Patilla Patilla                           Patilla
 Datos Tx       2  -----------------------------  3
 Datos Rx       3  -----------------------------  2
 RTS            4  -----------------------------  5
 CTS            5  -----------------------------  4
 Tierra         7  -----------------------------  7
 DTR            20 -\---------------------------  8
 DSR            6  -/
 RLSD/DCD       8  ---------------------------/-  20
                                              \-  6
</verb></tscreen>

<sect1>Cable de puerto paralelo (cable PLIP)
<p>

Si pretende usar el protocolo PLIP entre dos máquinas, entonces este cable 
funcionará independientemente del tipo de puertos paralelos que tenga
instalados.

<tscreen><verb>
Nombre Patilla  Patilla        Patilla
 STROBE         1*
 D0->ERROR      2  ----------- 15
 D1->SLCT       3  ----------- 13
 D2->PAPOUT     4  ----------- 12
 D3->ACK        5  ----------- 10
 D4->BUSY       6  ----------- 11
 D5             7*
 D6             8*
 D7             9*
 ACK->D3        10 ----------- 5
 BUSY->D4       11 ----------- 6
 PAPOUT->D2     12 ----------- 4
 SLCT->D1       13 ----------- 3
 FEED           14*
 ERROR->D0      15 ----------- 2
 INIT           16*
 SLCTIN         17*
 GROUND         25 ----------- 25
</verb></tscreen>

Notas:

<itemize>
<item>No conecte las patillas marcadas con un asterisco, <tt/*/.
<item>Las tomas de tierra extra son 18,19,20,21,22,23 y 24.

<item>Si el cable que está usando tiene apantallamiento metálico, debería estar
conectado a la carcasa DB-25 en <bf/sólo uno/ de los extremos.

</itemize>

<bf>Cuidado: Un cable PLIP mal hecho puede destruir la tarjeta</bf>
controladora. Sea muy cuidadoso y examine dos veces cada conexión para
asegurarse de que no va a hacer más trabajo ni a llevarse más infartos de lo
necesario.

Aunque puede que sea capaz de tener cables PLIP para grandes distancias,
debería evitarlo. Las especificaciones del cable permiten una longitud de
alrededor de 1 metro. Por favor, tenga mucho cuidado cuando tienda cables PLIP
largos, ya que las fuentes de campos electromagnéticos fuertes, como los rayos,
cables de corriente y emisoras de radio pueden interferir en los controladores,
y a veces dañarlos. Si realmente quiere conectar dos ordenadores a larga
distancia, debería intentar obtener un par de tarjetas Ethernet para thin-net
(red de cable fino) y tender cable coaxial.

<sect1>Cableado Ethernet 10base2 (coaxial fino)
<p>

10base2 es un estándar de cableado Ethernet que especifica el uso de cables
coaxiales de 52 ohmios con un diámetro de alrededor de 5 milímetros. Hay un par
de reglas importantes a recordar cuando conectemos máquinas con cableado
10base2. La primera es que debe usar terminadores en <em/ambos extremos/ del
cable. Un terminador es una resistencia de 52 ohmios que ayuda a asegurar que
la señal es absorbida y no reflejada cuando alcanza el final del cable. Sin un
terminador a cada extremo del cable, podría pasar que la Ethernet sea
ineficiente o que no funcione.  Normalmente debería usar conectores en «T» para
interconectar las máquinas por lo que terminará con algo que se parezca a:

<tscreen><verb>

 |==========T=============T=============T==========T==========|
            |             |             |          |
            |             |             |          |
          -----         -----         -----      -----
          |   |         |   |         |   |      |   |
          -----         -----         -----      -----

</verb></tscreen>

Donde el <tt/|/ a cada extremo representa un terminador, el <tt/======/
representa cables coaxiales con conectores BNC a cada extremo y las <tt/T/
representan conectores «en T». Debería hacer que la longitud del cable entre la
<tt/T/ y el PC lo más corto posible ya que, idealmente, la «T» debería estar
directamente enchufada a la tarjeta Ethernet.

<sect1>Cable Ethernet de Par Trenzado
<p>

Si tiene sólo dos tarjetas Ethernet de par trenzado y desea conectarlas,
entonces no necesita un concentrador. Puede cablear las dos tarjetas
directamente una a otra. Hay un diagrama que muestra cómo hacerlo incluido en
el <tt><htmlurl url="Ethernet-HOWTO.html" Name="Ethernet Howto"></tt>

<sect>Glosario de Términos usados en este documento
<p>

La siguiente lista contiene algunos de los términos más importantes usados
en este documento.

<descrip>

<tag>ARP</tag>Es un acrónimo para del <em>Protocolo de Resolución de
Direcciones</em> (Address Resolution Protocol) y es la manera en que
asocia una máquina de red una dirección IP con una dirección hardware.

<tag>ATM</tag>Es un acrónimo de <em>Modo Asíncrono de Transferencia</em>
(Asynchronous Transfer Mode). Una red ATM empaqueta los datos en bloques
de tamaño estándar que puede transportar eficientemente de un punto a
otro. ATM es una tecnología de red basada en circuitos de paquetes
conmutados.

<tag>cliente</tag>Suele ser la parte de un programa que se encuentra en el
lado del usuario. Hay ciertas excepciones, por ejemplo, en el sistema de
ventanas X11 es el servidor el que está con el usuario, y el cliente puede
estar ejecutándose en una máquina remota. El cliente es el programa o
terminal de un sistema que está recibiendo el servicio proporcionado por
el servidor. En el caso de sistema <em/de igual a igual/ (peer to peer),
como <tt/slip/ o <tt/ppp/, se dice que el cliente es el extremo que inicia
la conexión y el extremo remoto, que ha sido llamado, es el servidor.

<tag>datagrama</tag>Un datagrama es un paquete discreto de datos y
cabeceras que contiene direcciones, que es la unidad básica de transmisión
a través de una red IP. Puede que lo haya oído llamar «paquete».

<tag>Dirección hardware</tag>Es un número que identifica de forma unívoca
una máquina en una red física en la capa de acceso al medio. Algunos
ejemplos son las <em>Direcciones Ethernet</em> y las <em>Direcciones
AX.25</em>.

<tag>Dirección IP</tag>Es un número que identifica unívocamente una máquina
TCP/IP en la red. La dirección es de 4 bytes de longitud y normalmente se la
representa en <it/notación decimal puntuada/, donde cada byte es representado
en decimal con puntos «<tt/./» entre ellos.

<tag>DLCI</tag>DLCI viene de <it/Data Link Connection Identifier/ y se usa para
identificar una conexión virtual punto a punto en particular a través de una
red de Retransmisión de Tramas. Los DLCI los suele asignar el proveedor de red
de Retransmisión de Tramas.

<tag>ISP</tag>Véase PSI.

<tag>MSS</tag>El Tamaño Máximo de Segmento (<em>Maximum Segment Size</em>)
es la mayor cantidad de datos que pueden ser transmitidos a la vez. Si
quiere prevenir la fragmentación, el MSS debería ser igual al MTU de la
cabecera IP.

<tag>MTU</tag> La Máxima Unidad de Transmisión (<em>Maximum Transmission
Unit</em>) es un parámetro que determina el mayor datagrama que puede ser
transmitido por una interfaz IP sin necesidad de dividirlo en unidades más
pequeñas. La MTU debería ser más grande que el mayor datagrama que desee
transmitir sin fragmentar. Fíjese que esto sólo previene la fragmentación
de manera local, algunos otros enlaces por el camino pueden tener una MTU
más pequeña y el datagrama será fragmentado allí. Los valores normales son
1500 bytes para una interfaz Ethernet, o 576 bytes para una interfaz SLIP.

<tag>PSI</tag>Es un acrónimo de Proveedor de Servicios de Internet (ISP -
Internet Service Provider). Son organizaciones y compañías que
proporcionan conectividad con Internet.

<tag>RDSI</tag>Es un acrónimo de <em>Red Digital de Servicios
Integrados</em> (ISDN en inglés). La RDSI proporciona medios
estandarizados por los cuales las compañías de Telecomunicaciones pueden
llevar información tanto de voz como de datos según las premisas de los
abonados. Técnicamente la RDSI es una red de circuitos de paquetes
conmutados.

<tag>Retransmisión de tramas</tag>La retransmisión de tramas (o Frame
Relay) es una tecnología de red idealmente preparada para transportar
tráfico que es de naturaleza esporádica o a ráfagas. Los costes de red se
reducen compartiendo varios abonados a la retransmisión de tramas la
misma capacidad de red y dejándoles a ellos el deseo de usar la red en
momentos ligeramente diferentes.

<tag>ruta</tag>La <em>ruta</em> es el camino que siguen los datagramas a
través de la red para alcanzar su destino.

<tag>servidor</tag>Normalmente es la parte del programa o terminal de un
sistema remoto con respecto al usuario. El servidor proporciona algún
servicio a uno o varios clientes. Los ejemplos de servidores incluyen
<em/ftp/, <em/Network File System/ o <em/Domain Name Server/. En el caso
de sistemas de <em/igual a igual/ (peer to peer) tales como <tt/slip/ o
<tt/ppp/. Se dice que es el servidor el extremo del enlace que recibe la
llamada y el otro extremo es el cliente.

<tag>ventana</tag>La <em>ventana</em> es la mayor cantidad de datos que el
extremo receptor puede aceptar en un momento dado.
</descrip>

<sect>¿Linux para un PSI?
<p>

Si está interesado en usar Linux para propósitos de PSI entonces le recomiendo
que eche un vistazo a la página principal de Linux ISP <tt><htmlurl
url="http://www.anime.net/linuxisp/" name="http://www.anime.net/linuxisp"></tt>
si quiere obtener una buena lista de enlaces a la información que pudiera
necesitar.

<sect>Reconocimientos
<p>

Me gustaría dar las gracias a las siguientes personas por su contribución
a este documento (no están por orden): Terry Dawson, Axel Boldt, Arnt
Gulbrandsen, Gary Allpike, Cees de Groot, Alan Cox, Jonathon Naylor,
Claes Ensson, Ron Nessim, John Minack, Jean-Pierre Cocatrix, Erez Strauss.

El traductor quisiera también reconocer el trabajo de Fernando Tricas,
por su inestimable ayuda en el proceso de revisión del documento.

El mayor de los reconocimientos a la gran labor de Francisco Montilla
<tt><htmlurl url="mailto:pacopepe@insflug.org"
name="pacopepe@insflug.org"></tt> y el grupo Insflug <tt> <htmlurl
url="http://www.insflug.org" name="http://www.insflug.org"></tt> para conseguir
aportar documentación de calidad al movimiento LiNUX. ¡Animo!

<sect>Copyright.
<p>
<P>
<EM>Copyright Information</EM>
<P>
<P>
The NET-3-HOWTO, information on how to install and configure networking
support for Linux. Copyright (c) 1997 Terry Dawson, 1998 Alessandro
Rubini,
1999 {POET} - LinuxPorts
<P>
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your option)
any later version. This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General
Public License for more details. You should have received a copy of the
GNU General Public License along with this program; if not, write to the:
Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

<sect>Anexo: El INSFLUG <label id="Insflug">
<p>

El <it/INSFLUG/ forma parte del grupo internacional <it>Linux Documentation
Project</it>, encargándose de las traducciones al castellano de los Howtos,
así como de la producción de documentos originales en aquellos casos en los
que no existe análogo en inglés, centrándose, preferentemente, en documentos
breves, como los <em/COMOs/ y <em/PUFs/ (<bf/P/reguntas de <bf/U/so
<bf/F/recuente, las <it/FAQs/. <tt/:)/ ), etc.

Diríjase a la sede del Insflug para más información al respecto.

En ella encontrará siempre las <bf/últimas/ versiones de las traducciones
«oficiales»:  <tt><htmlurl url="http://www.insflug.org" 
name="www.insflug.org"></tt>. Asegúrese de comprobar cuál es la última
versión disponible en el Insflug antes de bajar un documento de un
servidor réplica. 

Además, cuenta con un sistema interactivo de gestión de fe de erratas y
sugerencias en línea, motor de búsqueda específico, y más servicios en los
que estamos trabajando incesantemente.

Ponga su granito de arena; si detecta una errata o incorrección en este
documento, por favor, diríjase a <tt><htmlurl
url="http://www.insflug.org/documentos/Redes-En-Linux-Como/"
name="http://www.insflug.org/documentos/Redes-En-Linux-Como/"></tt> y aporte su
sugerencia o errata en línea.

En <tt><htmlurl url="http://www.insflug.org/insflug/creditos.php3"
name="http://www.insflug.org/insflug/creditos.php3"></tt> cuenta con una
detallada relación de las personas que hacen posible tanto esto como las
traducciones.

¡Diríjase a <tt><htmlurl url="http://www.insflug.org/colaboracion/index.php3"
name="http://www.insflug.org/colaboracion/index.php3"></tt> si desea
unirse a nosotros!.

«Cartel» Insflug, <tt><htmlurl url="mailto:cartel@insflug.org"
name="cartel@insflug.org"></tt>. 

</article>
