20f467558b
translated files. In this way, we will be able to generate the list of the outdated files automatically. Obtained from: The FreeBSD Hungarian Documentation Project Inspired by: The FreeBSD Greek Documentation Project - Being on that, s/Sinópsis/Sinopsis/g. One mistake repeated many times. Cosmetic change.
9144 lines
402 KiB
Text
Executable file
9144 lines
402 KiB
Text
Executable file
<!--
|
||
The FreeBSD Documentation Project
|
||
|
||
|
||
The FreeBSD Spanish Documentation Project
|
||
%SOURCE% en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml
|
||
%SRCID% 0.0
|
||
|
||
|
||
$FreeBSD$
|
||
$FreeBSDes: doc/es_ES.ISO8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.3 2004/08/26 10:03:24 carvay Exp $
|
||
-->
|
||
|
||
|
||
<chapter id="advanced-networking">
|
||
<title>Networking avanzado</title>
|
||
|
||
<para>Networking avanzado</para>
|
||
|
||
<sect1 id="advanced-networking-synopsis">
|
||
<title>Resumen</title>
|
||
|
||
<para>Este capítulo cubre algunos de los servicios de red
|
||
que se usan con más frecuencia en sistemas
|
||
&unix;. Para ser más concretos este capítulo
|
||
explica cómo definir, ejecutar, probar
|
||
y mantener todos los servicios de red que utiliza
|
||
&os;. Se muestran además ejemplos de ficheros de
|
||
configuración que podrá utilizar para sus
|
||
propios quehaceres.</para>
|
||
|
||
<para>Después de leer este capítulo habremos
|
||
aprendido:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Los conceptos básicos de pasarelas y
|
||
<quote>routers</quote>.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Cómo poner en funcionamiento dispositivos IEEE
|
||
802.11 y &bluetooth;.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Cómo configurar &os; para que actúe
|
||
como un <quote>bridge</quote>.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Cómo poner en funcionamiento un sistema de
|
||
ficheros en red con NFS.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Cómo realizar un arranque del sistema por red en
|
||
máquinas sin disco duro.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Cómo ejecutar un servidor de información
|
||
en red para compartir cuentas de usuario mediante NIS.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Cómo especificar parámetros de
|
||
configuración automática de red utilizando
|
||
DHCP.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Cómo ejecutar un servidor de nombres de dominio.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Cómo sincronizar la hora y la fecha y ejecutar
|
||
un servidor horario utilizando el protocolo NTP.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Cómo ejecutar un servicio de traducción de
|
||
direcciones de red.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Cómo gestionar el dæmon
|
||
<application>inetd</application>.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Cómo conectar dos computadoras a través de
|
||
PLIP.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Cómo habilitar IPv6 en una máquina
|
||
FreeBSD.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Cómo configurar ATM sobre &os; 5.X.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<para>Antes de leer este capítulo debería usted:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Intentar comprender los conceptos básicos de los
|
||
scripts de <filename>/etc/rc</filename>.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Familiarizarse con la terminología básica
|
||
de redes.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</sect1>
|
||
|
||
<sect1 id="network-routing">
|
||
<sect1info>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Coranth</firstname>
|
||
<surname>Gryphon</surname>
|
||
<contrib>Escrito por </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
</sect1info>
|
||
<title>Pasarelas y <quote>routers</quote></title>
|
||
|
||
<indexterm><primary>routing</primary></indexterm>
|
||
<indexterm><primary>gateway</primary></indexterm>
|
||
<indexterm><primary>subnet</primary></indexterm>
|
||
<para>Para que una máquina sea capaz de encontrar otra
|
||
máquina remota a través de la red debe existir
|
||
mecanismo que describa cómo llegar del origen al destino.
|
||
Este mecanismo se demonina <firstterm>routing</firstterm> o
|
||
<firstterm>encaminamiento</firstterm>. Una <quote>ruta</quote>
|
||
es un par definido de direcciones: una dirección de
|
||
<quote>destino</quote> y una dirección
|
||
de <quote>pasarela</quote>. Éste par indica que para llegar a
|
||
dicho <emphasis>destino</emphasis> debe efectuarse una
|
||
comunicación previa con dicha
|
||
<emphasis>pasarela</emphasis>. Exiten tres tipos distintos
|
||
de destinos: máquinas individuales, subredes y
|
||
<quote>por defecto</quote>. La <quote>ruta por defecto</quote>
|
||
se utiliza sólamente cuando no se puede aplicar ninguna
|
||
de las otras rutas existentes. El tema de las
|
||
rutas por defecto se tratará más adelante con
|
||
más detalle. También existen tres tipos de
|
||
pasarelas distintas: máquinas individuales, interfaces
|
||
(también llamados <quote>enlaces</quote>) y direcciones
|
||
hardware de ethernet (direcciones MAC).</para>
|
||
|
||
<sect2>
|
||
<title>Ejemplo</title>
|
||
|
||
<para>Para ilustrar diferentes aspectos del sistema de
|
||
encaminamiento veamos el siguiente ejemplo obtenido mediante
|
||
<command>netstat</command>.</para>
|
||
|
||
<screen>&prompt.user; <userinput>netstat -r</userinput>
|
||
Routing tables
|
||
|
||
Destination Gateway Flags Refs Use Netif Expire
|
||
|
||
default outside-gw UGSc 37 418 ppp0
|
||
localhost localhost UH 0 181 lo0
|
||
test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77
|
||
10.20.30.255 link#1 UHLW 1 2421
|
||
ejemplo.com link#1 UC 0 0
|
||
host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0
|
||
host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 =>
|
||
host2.ejemplo.com link#1 UC 0 0
|
||
224 link#1 UC 0 0</screen>
|
||
|
||
<indexterm><primary>default route</primary></indexterm>
|
||
<para>Las primeras dos líneas especifican la ruta por
|
||
defecto (la cual se comenta en la
|
||
<link linkend="network-routing-default">siguiente
|
||
sección</link>) y la ruta de <hostid>máquina
|
||
local</hostid>.</para>
|
||
|
||
<indexterm><primary>loopback device</primary></indexterm>
|
||
<para>La interfaz (columna <literal>Netif</literal>) que
|
||
especifica esta tabla de rutas
|
||
para el destino <literal>localhost</literal> se denomina
|
||
<devicename>lo0</devicename>,
|
||
y también se conoce como el dispositivo de <quote>
|
||
loopback</quote> a de bucle de retorno. Esto viene a decir que
|
||
el tráfico no debe entregarse a la red puesto que
|
||
dicho tráfico va destinado a la misma máquina
|
||
que lo originó.</para>
|
||
|
||
<indexterm>
|
||
<primary>Ethernet</primary>
|
||
<secondary>MAC address</secondary>
|
||
</indexterm>
|
||
<para>Lo siguiente que podemos observar son las direcciones
|
||
que comienzan por
|
||
<hostid role="mac">0:e0:</hostid>. Son direcciones hardware de
|
||
Ethernet, llamadas también se direcciones MAC.
|
||
FreeBSD identifica automáticamente cualquier
|
||
máquina (<hostid>test0</hostid> en el ejemplo anterior)
|
||
que se encuentre en la red local y
|
||
crea una ruta del estilo que estamos comentando, para entregar
|
||
el tráfico directamente a través del
|
||
correspondiente interfaz Ethernet, en este caso
|
||
<devicename>ed0</devicename>. Existe también
|
||
un contador (<literal>Expire</literal>) asociado con este tipo
|
||
de rutas que se usa para borrarlas cuando dicho contador expira.
|
||
Las rutas para las máquinas de nuestra propia red de
|
||
de área local se crean dinámicamente
|
||
utilizando el protocolo ARP (Address Resolution Protocol o
|
||
Protocolo de Resolución de Direcciones),
|
||
que se encarga de averiguar la dirección MAC que se
|
||
corresponde con la dirección IP de la máquina
|
||
destino.</para>
|
||
|
||
<indexterm><primary>subnet</primary></indexterm>
|
||
<para>FreeBSD tambíen utiliza rutas de subred para
|
||
direccionar la subred local (<hostid
|
||
role="ipaddr">10.20.30.255</hostid> es la dirección
|
||
de broadcast para la subred
|
||
<hostid role="ipaddr">10.20.30</hostid>, y
|
||
<hostid role="domainname">ejemplo.com</hostid> es el nombre de
|
||
dominio asociado con dicha subred.)
|
||
La notación <literal>link#1</literal> se refiere a la
|
||
primera tarjeta Ethernet de la máquina.
|
||
En este tipo de redes no se especifica ningún interfaz
|
||
en el campo de <literal>Netif</literal>.</para>
|
||
|
||
<para>Las rutas de subredes aparecen cuando se asigna una
|
||
dirección IP a una interfaz, utilizando una
|
||
máscara de red. También se pueden aprender
|
||
dinámicamente utilizando demonios de encaminamiento,
|
||
como <application>routed</application>. Por último estas
|
||
rutas pueden crearse manualmente de forma explícita;
|
||
es lo que se conoce con el nombre de rutas estáticas.</para>
|
||
|
||
<para>La línea de <literal>host1</literal> se refiere a
|
||
nuestra máquina, que el sistema identifica por la
|
||
correspondiente dirección Ethernet de la tarjeta de red.
|
||
FreeBSD sabe que debe utilizar la interfaz de loopback
|
||
(<devicename>lo0</devicename>) en vez de enviar los paquetes a
|
||
a través de red.</para>
|
||
|
||
<para>Las dos líneas que comienzan por
|
||
<literal>host2</literal> son ejemplos del uso de alias de
|
||
&man.ifconfig.8; alias (consultar la sección sobre
|
||
Ethernet para averiguar por qué nos podría
|
||
interesar hacer esto.) El símbolo
|
||
<literal>=></literal> después de la interfaz
|
||
<devicename>lo0</devicename> especifica que no sólo
|
||
estamos utilizando la interfaz de loopback, si no que
|
||
además especifica que se trata de un alias. Estas rutas
|
||
sólo aparecen en las máquinas que implementan el
|
||
alias, el resto de las máquinas de la subred local
|
||
solamente poseerán una línea
|
||
<literal>link#1</literal> para dichas rutas.</para>
|
||
|
||
<para>La última línea (destino de subred <hostid
|
||
role="ipaddr">224</hostid>) trata sobre encaminamiento
|
||
multicast, que cubriremos en otra sección.</para>
|
||
|
||
<para>Finalmente, se pueden observar varios atributos
|
||
relacionados con las rutas en la columna de
|
||
<literal>Flags</literal>. A continuación se muestra una
|
||
pequeña tabla con el significado de algunos de esos
|
||
de los atributos o <quote>flags</quote>.</para>
|
||
|
||
<informaltable frame="none">
|
||
<tgroup cols="2">
|
||
<tbody>
|
||
<row>
|
||
<entry>U</entry>
|
||
<entry>Up: La ruta está activa.</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry>H</entry>
|
||
<entry>Host: El destino de la ruta es una única
|
||
máquina.</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry>G</entry>
|
||
<entry>Gateway: Envía cualquier cosa para éste
|
||
destino a través de la pasarela especificada,
|
||
la cual decidirá cómo encaminar el paquete
|
||
hasta que eventualmente se alcance el destino.</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry>S</entry>
|
||
<entry>Static: Esta ruta se configuró
|
||
manualmente, y no se ha generado de forma
|
||
automática por el sistema.</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry>C</entry>
|
||
<entry>Clone: Genera una nueva ruta para la
|
||
máquina a la que nos queremos conectar
|
||
basándose en la ruta actual. Este tipo de ruta se
|
||
utiliza normalmente en redes locales.</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry>W</entry>
|
||
<entry>WasCloned: Indica una ruta que se auto-configuró
|
||
basándose en una ruta de red de área local con
|
||
etiqueta Clone.</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry>L</entry>
|
||
<entry>Link: Esta ruta posée referencias a hardware de
|
||
Ethernet.</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</informaltable>
|
||
</sect2>
|
||
|
||
<sect2 id="network-routing-default">
|
||
<title>Rutas por defecto</title>
|
||
|
||
<indexterm><primary>default route</primary></indexterm>
|
||
<para>Cuando el sistema local necesita realizar una conexión con
|
||
una máquina remota se examina la tabla de rutas para determinar
|
||
si se conoce algún camino para llegar al destino.
|
||
Si la máquina remota pertenece a una subred que sabemos
|
||
cómo alcanzar (rutas clonadas) entonces el sistema comprueba si
|
||
se puede conectar utilizando dicho camino.</para>
|
||
|
||
<para>Si todos los caminos conocidos fallan al sistema le queda una
|
||
única opción: la <quote>ruta por defecto</quote>.
|
||
Esta ruta está constituída por un tipo especial de
|
||
pasarela (normalmente el único <quote>router</quote>
|
||
presente en la red
|
||
área local) y siempre posée el <quote>flag</quote>
|
||
<literal>c</literal> en el campo de <quote>flags</quote>.
|
||
En una LAN, la pasarela es la máquina que posée
|
||
conectividad con el resto de las redes (sea a través de un
|
||
enlace PPP, DSL, cable modem, T1 u otra interfaz de red.)</para>
|
||
|
||
<para>Si se configura la ruta por defecto en una máquina que
|
||
está actuando como pasarela hacia el mundo exterior
|
||
la ruta por defecto será el <quote>router</quote>
|
||
que se encuentre en
|
||
posesión del proveedor de servicios de internet (ISP).</para>
|
||
|
||
<para>Vamos a examinar un ejemplo que utiliza rutas por defecto.
|
||
A continuación se muestra una configuración bastante
|
||
común:</para>
|
||
|
||
<mediaobject>
|
||
<imageobject>
|
||
<imagedata fileref="advanced-networking/net-routing">
|
||
</imageobject>
|
||
|
||
<textobject>
|
||
<literallayout class="monospaced">
|
||
[Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW]
|
||
</literallayout>
|
||
</textobject>
|
||
</mediaobject>
|
||
|
||
<para>Las máquinas <hostid>Local1</hostid> y
|
||
<hostid>Local2</hostid> se encuentran en nuestro sitio u
|
||
organización. <hostid>Local1</hostid> se conecta con un ISP
|
||
a través de una conexión de modem PPP.
|
||
El servidor PPP del ISP se conecta a través de una red de
|
||
área local a otra pasarela utilizando una interfaz
|
||
externa.</para>
|
||
|
||
<para>Las rutas por defecto para cada una de las máquinas son
|
||
las siguientes:</para>
|
||
|
||
<informaltable frame="none">
|
||
<tgroup cols="3">
|
||
<thead>
|
||
<row>
|
||
<entry>Host</entry>
|
||
<entry>Default Gateway</entry>
|
||
<entry>Interface</entry>
|
||
</row>
|
||
</thead>
|
||
|
||
<tbody>
|
||
<row>
|
||
<entry>Local2</entry>
|
||
<entry>Local1</entry>
|
||
<entry>Ethernet</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry>Local1</entry>
|
||
<entry>T1-GW</entry>
|
||
<entry>PPP</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</informaltable>
|
||
|
||
<para>Una pregunta bastante frecuente es <quote>¿Por
|
||
qué (o cómo) hacer que la máquina
|
||
<hostid>T1-GW</hostid> sea el <quote>router</quote> por defecto para
|
||
<hostid>Local1</hostid> en vez de que sea el servidor del ISP
|
||
al cual se está conectando?</quote>.</para>
|
||
|
||
<para>Recordemos que, como la interfaz PPP está utilizando una
|
||
dirección de la red local del ISP en nuestro lado de la
|
||
las rutas para cualquier otra máquina en la red local del
|
||
proveedor se generarán de forma automática. De este
|
||
ya sabemos el modo de alcanzar la máquina
|
||
<hostid>T1-GW</hostid>, de tal forma que no se necesita un paso
|
||
intermedio para enviar tráfico al servidor del ISP.</para>
|
||
|
||
<para>Es frecuente utilizar la dirección <hostid
|
||
role="ipaddr">X.X.X.1</hostid> como la dirección de
|
||
la pasarela en la red local. Siguiendo con el ejemplo anterior, si
|
||
nuestro espacio de direccionamiento local fuera la clase C
|
||
<hostid role="ipaddr">10.20.30</hostid> y nuestro ISP estuviera
|
||
utilizando <hostid role="ipaddr">10.9.9</hostid> las rutas por
|
||
defecto serían:</para>
|
||
|
||
<informaltable frame="none">
|
||
<tgroup cols="2">
|
||
<thead>
|
||
<row>
|
||
<entry>Host</entry>
|
||
<entry>Default Route</entry>
|
||
</row>
|
||
</thead>
|
||
<tbody>
|
||
<row>
|
||
<entry>Local2 (10.20.30.2)</entry>
|
||
<entry>Local1 (10.20.30.1)</entry>
|
||
</row>
|
||
<row>
|
||
<entry>Local1 (10.20.30.1, 10.9.9.30)</entry>
|
||
<entry>T1-GW (10.9.9.1)</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</informaltable>
|
||
|
||
<para>Se puede especificar fácilmente la entrada de la
|
||
ruta por defecto utilizando el fichero
|
||
<filename>/etc/rc.conf</filename>. En nuestro ejemplo
|
||
en la máquina <hostid>Local2</hostid>, se añadió
|
||
la siguiente línea en dicho fichero:</para>
|
||
|
||
<programlisting>defaultrouter="10.20.30.1"</programlisting>
|
||
|
||
<para>También se puede hacer directamente desde la línea
|
||
de órdenes mediante &man.route.8;:</para>
|
||
|
||
<screen>&prompt.root; <userinput>route add default 10.20.30.1</userinput></screen>
|
||
|
||
<para>Para obtener más información sobre la
|
||
manipulación de tablas de rutas se ruega consultar
|
||
la página de manual &man.route.8;.</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Máquinas con doble pertenencia (Dual Homed Hosts)</title>
|
||
<indexterm><primary>dual homed hosts</primary></indexterm>
|
||
<para>Existe otro tipo de configuración que debemos describir
|
||
y que se produce cuando una máquina se sitúa en dos
|
||
redes distintas al mismo tiempo. Técnicamente hablando
|
||
cualquier máquina que actúa como pasarela (en el
|
||
caso anterior utilizando un enlace de PPP) pertenece al tipo
|
||
de máquinas con doble pertenencia, pero normalmente el
|
||
término sólo se aplica para describir máquinas
|
||
que se encuentran directamente conectadas con dos redes de área
|
||
local.</para>
|
||
|
||
<para>En un caso la máquina posée dos tarjetas de red
|
||
Ethernet, cada una de ellas con una dirección de red
|
||
independiente. En otro caso la máquina puede tener
|
||
sólo una tarjeta de red, pero utilizar <quote>
|
||
aliasing</quote> (&man.ifconfig.8;). El primer caso se utiliza cuando
|
||
se necesita usar dos redes Ethernet al mismo tiempo mientras que el
|
||
segundo caso se utiliza cuando se dispone de un único segmento
|
||
de red físico pero se han definido dos redes lógicas
|
||
distintas</para>
|
||
|
||
<para>En cualquier caso la tabla de rutas se construye de tal forma
|
||
que cada subred sepa que la máquina es la pasarela definida
|
||
definida (<quote>inbound route</quote>) para la otra subred.
|
||
Ésta configuración en la que la máquina
|
||
actúa como <quote>router</quote> entre las dos subredes se
|
||
usa a menudo
|
||
cuando queremos implementar filtrado de paquetes o cortafuegos
|
||
seguridad en un sentido o en ambos.</para>
|
||
|
||
<para>Si queremos que dicha máquina encamine paquetes entre las
|
||
dos interfaces es necesario decirle a FreeBSD que active dicha
|
||
funcionalidad. En la siguiente sección se explica cómo
|
||
hacerlo.</para>
|
||
</sect2>
|
||
|
||
<sect2 id="network-dedicated-router">
|
||
<title>Construcción de un <quote>route</quote></title>
|
||
|
||
<indexterm><primary>router</primary></indexterm>
|
||
|
||
<para>Un <quote>router</quote> de red, también llamado pasarela o
|
||
<quote>route</quote>, es simplemente un sistema que reenvía
|
||
paquetes desde un interfaz hacia otro interfaz. Los estándares
|
||
Internet y el sentido común aplicado a la ingeniería de
|
||
redes impiden que FreeBSD incluya por defecto ésta
|
||
característica. Se puede activar cambiando a
|
||
<literal>YES</literal> el valor de la siguiente variable en el fichero
|
||
&man.rc.conf.5;:</para>
|
||
|
||
<programlisting>gateway_enable=YES # Set to YES if this host will be a gateway</programlisting>
|
||
|
||
<para>Esta opción modificará la variable de
|
||
&man.sysctl.8; <varname>net.inet.ip.forwarding</varname> al valor
|
||
<literal>1</literal>. Si en algún momento se necesita
|
||
detener el <quote>router</quote> de forma temporal basta con
|
||
asignar a dicha
|
||
variable el valor <literal>0</literal>. Consulte &man.sysctl.8; para
|
||
más detalles.</para>
|
||
|
||
<para>Nuestro recién activado <quote>router</quote>
|
||
necesita rutas para
|
||
saber a dónde debe enviar el tráfico recibido.
|
||
Si nuestra red es ña se pueden definir rutas estáticas.
|
||
FreeBSD incluye por defecto el dæmon de encaminamiento BSD,
|
||
&man.routed.8;, que admite RIP (versión 1 y versión 2)
|
||
e IRDP. El paquete <filename role="package">net/zebra</filename> le
|
||
permitirá usar otros protocolos de encaminamiento
|
||
dinámico como BGP v4, OSPF v2 y muchos otros.
|
||
En caso de necesitar características avanzadas de
|
||
gestión puede usted recurrir a productos comerciales como
|
||
<application>&gated;</application>.</para>
|
||
|
||
<indexterm><primary>BGP</primary></indexterm>
|
||
<indexterm><primary>RIP</primary></indexterm>
|
||
<indexterm><primary>OSPF</primary></indexterm>
|
||
|
||
<para>Incluso cuando FreeBSD se configura del modo descrito no se
|
||
cumple completamente con los estándares de Internet
|
||
respecto a los <quote>routers</quote>. Bastará no obstante
|
||
para poder usarse.</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<sect2info>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Al</firstname>
|
||
<surname>Hoang</surname>
|
||
<contrib>Escrito por</contrib>
|
||
</author>
|
||
</authorgroup>
|
||
</sect2info>
|
||
<!-- Feb 2004 -->
|
||
<title>Configuración de rutas estáticas</title>
|
||
|
||
<sect3>
|
||
<title>Configuración manual</title>
|
||
|
||
<para>Vamos a suponer que tenemos la siguiente topología de
|
||
red:</para>
|
||
|
||
<literallayout class="monospaced">
|
||
INTERNET
|
||
| (10.0.0.1/24) Router por defecto para Internet
|
||
|
|
||
|Interfaz xl0
|
||
|10.0.0.10/24
|
||
+------+
|
||
| | RouterA
|
||
| | (pasarela FreeBSD)
|
||
+------+
|
||
| Interfaz xl1
|
||
| 192.168.1.1/24
|
||
|
|
||
+--------------------------------+
|
||
Red Interna 1 | 192.168.1.2/24
|
||
|
|
||
+------+
|
||
| | RouterB
|
||
| |
|
||
+------+
|
||
| 192.168.2.1/24
|
||
|
|
||
Red Interna 2
|
||
</literallayout>
|
||
|
||
<para>En este escenario <hostid>RouterA</hostid> es nuestra
|
||
máquina &os; que actúa como pasarela para acceder al
|
||
resto de internet. Tiene una ruta por defecto que apunta a
|
||
<hostid role="ipaddr">10.0.0.1</hostid> que le permite conectarse
|
||
con el mundo exterior. Vamos a suponer también que
|
||
<hostid>RouterB</hostid> se encuentra configurado de forma adecuada
|
||
que sabe cómo llegar a cualquier sitio que necesite.
|
||
Esto es sencillo viendo nuestra topología de red, basta
|
||
con añadir una ruta por defecto en la máquina
|
||
<hostid>RouterB</hostid> utilizando
|
||
<hostid role="ipaddr">192.168.1.1</hostid> como
|
||
<quote>router</quote>.</para>
|
||
|
||
<para>Si observamos la tabla de rutas de
|
||
<hostid>RouterA</hostid> veremos algo como lo siguiente:</para>
|
||
|
||
<screen>&prompt.user; <userinput>netstat -nr</userinput>
|
||
Routing tables
|
||
|
||
Internet:
|
||
Destination Gateway Flags Refs Use Netif Expire
|
||
default 10.0.0.1 UGS 0 49378 xl0
|
||
127.0.0.1 127.0.0.1 UH 0 6 lo0
|
||
10.0.0/24 link#1 UC 0 0 xl0
|
||
192.168.1/24 link#2 UC 0 0 xl1</screen>
|
||
|
||
<para>Con la tabla de rutas actual <hostid>RouterA</hostid>
|
||
no es capaz de alcanzar la red interna 2. Esto es así
|
||
porque no posee ninguna ruta para la red
|
||
<hostid role="ipaddr">192.168.2.0/24</hostid>. Una forma de
|
||
mitigar esto es añadir de forma manual la ruta que falta. La
|
||
siguiente orden añade la red interna 2 a la tabla de rutas
|
||
de la máquina <hostid>RouterA</hostid>
|
||
utilizando <hostid
|
||
role="ipaddr">192.168.1.2</hostid> como siguiente salto:</para>
|
||
|
||
<screen>&prompt.root; <userinput>route add -net 192.168.2.0/24 192.168.1.2</userinput></screen>
|
||
|
||
<para>Ahora <hostid>RouterA</hostid> puede alcanzar cualquier
|
||
máquina en la red
|
||
<hostid role="ipaddr">192.168.2.0/24</hostid>.</para>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Cómo hacer la configuración persistente</title>
|
||
|
||
<para>El ejemplo anterior es perfecto en tanto que resuelve el
|
||
problema de encaminamiento entre redes pero existe un problema.
|
||
La información de encaminamiento desaparecerá si se
|
||
reinicia la máquina. La forma de evitarlo es
|
||
añadir las rutas estáticas a
|
||
<filename>/etc/rc.conf</filename>:</para>
|
||
|
||
<programlisting># Añade la red interna 2 como una ruta estática
|
||
static_routes="redinterna2"
|
||
route_internalnet2="-net 192.168.2.0/24 192.168.1.2"</programlisting>
|
||
|
||
<para>La variable de configuración
|
||
<literal>static_routes</literal> es una lista de cadenas
|
||
separadas por espacios. Cada cadena identifica un nombre para la
|
||
ruta que se desea definir. En el ejemplo anterior sólamente
|
||
se dispone de una cadena dentro de la variable
|
||
<literal>static_routes</literal>.
|
||
Esta cadena es <replaceable>redinterna2</replaceable>. A
|
||
continuación se añade otra variable de
|
||
configuración denominada
|
||
<literal>route_<replaceable>redinterna2</replaceable></literal>
|
||
donde se escriben todos los parámetros de
|
||
configuración que normalmente utilizaríamos
|
||
normalmente utilizaríamos con &man.route.8;.
|
||
En el ejemplo que estamos comentando se utilizaría la
|
||
siguiente orden:</para>
|
||
|
||
<screen>&prompt.root; <userinput>route add -net 192.168.2.0/24 192.168.1.2</userinput></screen>
|
||
|
||
<para>De tal forma que la variable debería contener
|
||
<literal>"-net 192.168.2.0/24 192.168.1.2"</literal>.</para>
|
||
|
||
|
||
<para>Como ya se ha comentado anteriormente podemos especificar
|
||
más de una cadena en la variable
|
||
<literal>static_routes</literal>. Esto nos permite crear varias
|
||
rutas estáticas. Las siguientes línas muestran
|
||
un ejemplo donde se añaden rutas estáticas para las
|
||
redes <hostid role="ipaddr">192.168.0.0/24</hostid>
|
||
y <hostid role="ipaddr">192.168.1.0/24</hostid> en un
|
||
<quote>router</quote>imaginario:</para>
|
||
|
||
<programlisting>static_routes="red1 red2"
|
||
route_red1="-net 192.168.0.0/24 192.168.0.1"
|
||
route_red2="-net 192.168.1.0/24 192.168.1.1"</programlisting>
|
||
</sect3>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Propagación de rutas</title>
|
||
<indexterm><primary>routing propagation</primary></indexterm>
|
||
<para>Ya hemos comentado cómo se definen las rutas para
|
||
el mundo exterior pero no hemos comentado nada sobre cómo
|
||
haremos que el mundo exterior nos encuentre a nosotros.</para>
|
||
|
||
<para>También hemos aprendido que las tablas de rutas se
|
||
pueden construír de tal forma que un grupo de tráfico
|
||
(perteneciente a un espacio de direcciones determinado) se
|
||
reenvíe a una máquina específica de la red,
|
||
que se encargará de reenviar los paquetes hacia adentro.</para>
|
||
|
||
<para>Cuando se obtiene un espacio de direcciones para la
|
||
organización el proveedor de servicios modifica sus tablas de
|
||
rutas para que todo el tráfico para nuestra subred se encamine
|
||
a través del enlace PPP hasta alcanzarnos.
|
||
Pero ¿cómo conocen las organizaciones dispersas
|
||
a través del país que deben enviar los paquetes
|
||
dirigidos a nosotros hacia nuestro ISP?</para>
|
||
|
||
<para>Existe un sistema (muy similar al sistema de nombres de
|
||
dominio, DNS) que se encarga de controlar todos los espacios de
|
||
direcciones que se encuentran actualmente repartidos y que
|
||
además define sus puntos de conexión con el
|
||
<quote>backbone</quote> de internet. El <quote>backbone</quote>
|
||
está formado por las principales líneas de
|
||
de comunicacion que se encargan de transportar el tráfico de
|
||
internet a través del país y del mundo entero.
|
||
Cada máquina del <quote>backbone</quote> dispone de una copia
|
||
de un conjunto maestro de tablas de rutas gracias a las cuales pueden
|
||
dirigir el tráfico para una red particular hacia una
|
||
determinada red de transporte de dicho <quote>backbone</quote>.
|
||
Una vez en la red de transporte adecuada el tráfico se encamina
|
||
a través de un número indeterminado de redes de
|
||
proveedores de servicio hasta que se alcanza la red de destino
|
||
final.</para>
|
||
|
||
<para>Una de las tareas que debe realizar el proveedor de servicio
|
||
servicio consiste en anunciarse a las organizaciones del
|
||
consiste en anunciarse a las organizaciones del
|
||
<quote>backbone</quote> como el punto de conexión principal
|
||
(y por tanto como el camino de entrada) para alcanzar las redes de
|
||
sus clientes. Este proceso se denomina propagación de
|
||
rutas.</para>
|
||
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Solución de problemas</title>
|
||
<indexterm>
|
||
<primary><command>traceroute</command></primary>
|
||
</indexterm>
|
||
<para>En algunas ocasiones surgen problemas con la propagación
|
||
de las rutas y algunas organizaciones son incapaces de conectarse con
|
||
nuestra subred. Quizá la orden más útil para
|
||
averiguar dónde se está interrumpiendo el sistema
|
||
de encaminamiento sea &man.traceroute.8;. Se puede usar
|
||
también cuando somos nosotros los que no podemos alcanzar
|
||
alguna red externa (por ejemplo cuando &man.ping.8; falla).</para>
|
||
|
||
<para>&man.traceroute.8; se ejecuta pasandole como parámetro el
|
||
nombre de la máquina remota a la que nos queremos
|
||
conectar. Esta orden muestra por pantalla lás máquinas
|
||
que actúan de pasarela a lo largo del camino. El proceso
|
||
termina bien porque se alcanza el destino o bien porque algún
|
||
<quote>router</quote> intermedio no puede conectarse con el siguiente
|
||
salto, o lo desconoce.</para>
|
||
|
||
<para>Si quiere saber más sobre esto consulte la página
|
||
man de &man.traceroute.8;.</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Rutas multicast</title>
|
||
<indexterm>
|
||
<primary>multicast</primary>
|
||
<secondary>options MROUTING</secondary>
|
||
</indexterm>
|
||
<para>FreeBSD soporta tanto aplicaciones multicast como encaminamiento
|
||
multicast de forma nativa. Las aplicaciones multicast no necesitan
|
||
ninguna configuración especial en FreeBSD; estas aplicaciones
|
||
se ejecutan tal cual. El encaminamiento multicast necesita para
|
||
ser usado que se compile dicho soporte en el núcleo de
|
||
FreeBSD:</para>
|
||
|
||
<programlisting>options MROUTING</programlisting>
|
||
|
||
<para>Se debe configurar además el dæmon de
|
||
encaminamiento multicast, &man.mrouted.8;, para establecer
|
||
túneles y ejecutar DVMRP utilizando
|
||
<filename>/etc/mrouted.conf</filename>. Se pueden encontrar
|
||
más detalles sobre cómo realizar una
|
||
configuración de multicast en &man.mrouted.8;.</para>
|
||
</sect2>
|
||
</sect1>
|
||
|
||
<sect1 id="network-wireless">
|
||
<sect1info>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Eric</firstname>
|
||
<surname>Anderson</surname>
|
||
<contrib>Escrito por </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
</sect1info>
|
||
<title>Redes sin cables (<quote>wireless</quote>)</title>
|
||
|
||
<indexterm><primary>wireless networking</primary></indexterm>
|
||
<indexterm>
|
||
<primary>802.11</primary>
|
||
<see>Redes sin cables</see>
|
||
</indexterm>
|
||
|
||
<sect2>
|
||
<title>Introducción</title>
|
||
<para>Puede resultar muy útil el ser capaz de utilizar una
|
||
computadora sin la molestia de tener un cable de red colgando
|
||
de la máquina en todo momento. FreeBSD puede utilizarse
|
||
como un cliente de <quote>wireless</quote> e incluso como un
|
||
<quote>punto de acceso</quote>.</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Modos de operación Wireless</title>
|
||
<para>Existen dos formas diferentes de configurar dispositivos wireless
|
||
802.11: BSS e IBSS.</para>
|
||
|
||
<sect3>
|
||
<title>Modo BSS</title>
|
||
<para>El modo BSS es el que se utiliza normalmente. Este modo
|
||
también se denomina modo infraestructura. En
|
||
esta configuración se conectan un determinado
|
||
número de puntos de acceso a una red cableada. Cada red
|
||
Cada red <quote>wireless</quote> posée su propio nombre.
|
||
Este nombre es el SSID de la red.</para>
|
||
|
||
<para>Los clientes <quote>wireless</quote> se conectan a estos puntos
|
||
de acceso. El estándar IEEE 802.11 define el protocolo que
|
||
se utiliza para realizar esta conexión. Un cliente
|
||
<quote>wireless</quote> puede asociarse con una determinada red
|
||
<quote>wireless</quote> especificando el SSID.
|
||
Un cliente <quote>wireless</quote> también puede asociarse a
|
||
cualquier red que se encuentre disponible; basta con no especificar
|
||
ningún SSID.</para>
|
||
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Modo IBSS</title>
|
||
<para>El modo IBSS, también conocido como modo ad-hoc, se ha
|
||
diseñado para facilitar las conexiones punto a punto.
|
||
En realidad existen dos tipos distintos de modos ad-hoc. Uno es
|
||
el modo IBSS, también conocido como modo ad-hoc o modo
|
||
ad-hoc del IEEE. Este modo se encuentra especificado en el
|
||
estándar IEEE 802.11. El segundo tipo se denomina modo
|
||
ad-hoc de demostración o modo ad-hoc de Lucent (y algunas
|
||
veces, también se le llama simplemente modo ad-hoc, lo cual
|
||
es bastante confuso). Este es el modo de funcionamiento
|
||
antíguo, anterior al estándar 802.11, del modo ad-hoc
|
||
debería utilizarse sólo en instalaciones
|
||
propietarias. No profundizaremos más sobre estos modos de
|
||
funcionamiento.</para>
|
||
|
||
</sect3>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Modo infraestructura</title>
|
||
<sect3>
|
||
<title>Puntos de acceso</title>
|
||
|
||
<para>Los puntos de acceso son dispositivos de red
|
||
<quote>wireless</quote> que funcionan de forma equivalente a los
|
||
<quote>hubs</quote> o concentradores, permitiendo que varios clientes
|
||
<quote> wireless</quote> se comuniquen entre sí.
|
||
A menudo se utilizan varios puntos de acceso para cubrir un
|
||
área determinada como una casa, una oficina u otro tipo de
|
||
localización delimitada.</para>
|
||
|
||
<para>Los puntos de acceso poseen típicamente varias
|
||
conexiones de red: la tarjeta <quote>wireless</quote> y una o
|
||
más tarjetas Ethernet que se utilizan para comunicarse con
|
||
el resto de la red.</para>
|
||
|
||
<para>Los puntos de acceso se pueden comprar como tales
|
||
pero también se puede configurar un sistema FreeBSD para
|
||
crear nuestro propio punto de acceso <quote>wireless</quote>
|
||
utilizando un determinado tipo de tarjetas <quote>wireless</quote>
|
||
que poseen tales capacidades de configuración.
|
||
Existe una gran cantidad de fabricantes de hardware que distribuyen
|
||
puntos de acceso y tarjetas de red <quote>wireless</quote>, aunque
|
||
las capacidades de unos y otras varín.</para>
|
||
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Construcción de un punto de acceso basado en
|
||
&os;</title>
|
||
<indexterm><primary>wireless networking</primary>
|
||
<secondary>Punto de acceso</secondary>
|
||
</indexterm>
|
||
|
||
<sect4><title>Requisitos</title>
|
||
|
||
<para>Para crear nuestro propio punto de acceso con FreeBSD
|
||
debemos utilizar un determinado tipo de tarjeta
|
||
<quote>wireless</quote>. Por el momento, sólo las tarjetas
|
||
con el chip Prism nos permiten hacer un punto de acceso.
|
||
También vamos a necesitar una tarjeta para red cableada que
|
||
sea soportada por el sistema (esto no es muy complicado dada la
|
||
ingente cantidad de dispositivos de este tipo que funcionan en
|
||
FreeBSD). Para este ejemplo vamos a suponer que queremos puentear
|
||
(&man.bridge.4;) todo el tráfico entre la red cableada y la
|
||
red inalámbrica.</para>
|
||
|
||
<para>El uso como punto de acceso <quote>wireless</quote>
|
||
(también denominado <emphasis>hostap</emphasis>)
|
||
funciona mejor con determinadas versiones del <quote>
|
||
firmware</quote>. Las tarjetas con chip Prism2 deben disponer de
|
||
la versión 1.3.4 (o superior) del <quote>
|
||
firmware</quote>. Los chips Prism2.5 y Prism3 deben disponer de
|
||
la versión 1.4.9 o superior del <quote>firmware</quote>.
|
||
Las versiones más antíguas de estos <quote>
|
||
firmwares</quote> pueden no funcionar correctamente. A día
|
||
de hoy la única forma de actualizar el <quote>
|
||
firmware</quote> de las tarjetas es usando las herramientas que
|
||
proporciona el fabricante para &windows;.</para>
|
||
|
||
</sect4>
|
||
|
||
<sect4>
|
||
<title>Puesta en marcha del sistema</title>
|
||
<para>Primero debemos asegurarnos de que el sistema reconoce
|
||
la tarjeta <quote>wireless</quote>:</para>
|
||
<screen>&prompt.root; <userinput>ifconfig -a</userinput>
|
||
wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
|
||
inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7
|
||
inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
|
||
ether 00:09:2d:2d:c9:50
|
||
media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps)
|
||
status: no carrier
|
||
ssid ""
|
||
stationname "nodo Wireless FreeBSD"
|
||
channel 10 authmode OPEN powersavemode OFF powersavesleep 100
|
||
wepmode OFF weptxkey 1</screen>
|
||
|
||
<para>No se preocupe si no entiende algo de la configuración
|
||
anterior, lo importante es asegurarse de que el sistema muestra
|
||
algo parecido, lo cual nosindicará que la tarjeta
|
||
<quote>wireless</quote> ha sido correctamente reconocida por
|
||
FreeBSD. Si el interfaz inalámbrico no es reconocido
|
||
correctamente y se está utilizando una tarjeta PC Card
|
||
consulte &man.pccardc.8; y &man.pccardd.8;, en las que
|
||
tiene mucha información al respecto.</para>
|
||
|
||
<para>A continuación, para que podamos disponer de
|
||
un <quote>bridge</quote> deberá cargar el módulo
|
||
del kernel &man.bridge.4; por el sencillo procedimiento de
|
||
ejecutar la siguiente orden:</para>
|
||
|
||
<screen>&prompt.root; <userinput>kldload bridge</userinput></screen>
|
||
|
||
<para>No debería aparecer mensaje de error alguno al ejecutar
|
||
dicha orden. Si apareciera alguno quizás deba compilar
|
||
el kernel del sistema con &man.bridge.4; incluído. La
|
||
sección <link
|
||
linkend="network-bridging">Bridging</link> de éste
|
||
manual incluye información abundante para llevar a buen
|
||
puerto esa tarea.</para>
|
||
|
||
<para>Una vez que tenemos el soporte de <quote>bridging</quote>
|
||
cargado debemos indicar a FreeBSD qué interfaces se desean
|
||
puentear. Para ello emplearemos &man.sysctl.8;:</para>
|
||
|
||
<screen>&prompt.root; <userinput>sysctl net.link.ether.bridge=1</userinput>
|
||
&prompt.root; <userinput>sysctl net.link.ether.bridge_cfg="wi0,xl0"</userinput>
|
||
&prompt.root; <userinput>sysctl net.inet.ip.forwarding=1</userinput></screen>
|
||
|
||
<para>En &os; 5.2-RELEASE y posteriores se deben emplear las
|
||
siguientes opciones en lugar de las anteriormente expuestas:</para>
|
||
|
||
<screen>&prompt.root; <userinput>sysctl net.link.ether.bridge.enable=1</userinput>
|
||
&prompt.root; <userinput>sysctl net.link.ether.bridge.config="wi0,xl0"</userinput>
|
||
&prompt.root; <userinput>sysctl net.inet.ip.forwarding=1</userinput></screen>
|
||
|
||
<para>Ahora es el momento de configurar la tarjeta de red
|
||
inalámbrica. La siguiente orden convierte la tarjeta en
|
||
un punto de acceso:</para>
|
||
|
||
<screen>
|
||
&prompt.root; <userinput>ifconfig wi0 ssid <replaceable>mi_red</replaceable> channel 11 media DS/11Mbps mediaopt hostap up stationname "<replaceable>PA FreeBSD</replaceable>"</userinput>
|
||
</screen>
|
||
|
||
<para>La línea de &man.ifconfig.8; levanta el interfaz
|
||
<devicename>wi0</devicename>, configura el SSID con el valor de
|
||
<replaceable>mi_red</replaceable> y también el nombre
|
||
de la estación como
|
||
<replaceable>FreeBSD</replaceable>. La opción
|
||
<option>media DS/11Mbps</option> configura la tarjeta a 11Mbps.
|
||
Ésto es necesario para que cualquier valor que se necesite
|
||
asignar a <option>mediaopt</option> surta efecto.
|
||
La opción <option>mediaopt hostap</option> sitúa el
|
||
interfaz en modo punto de acceso. La opción <option>
|
||
channel 11</option> configura la tarjeta para que use el canal de
|
||
radio número 11. En &man.wicontrol.8; encontraráa
|
||
rangos de canales válidos para varios dominios
|
||
regulatorios. Por favor, tenga en cuenta que no todos los canales
|
||
son legales en todos los países.</para>
|
||
|
||
<para>Despues de esto deberíamos disponer de un punto de
|
||
acceso completamente funcional y en ejecución.
|
||
Le animamos a consultar &man.wicontrol.8;, &man.ifconfig.8; y
|
||
&man.wi.4; para máss información.</para>
|
||
|
||
<para>También le recomemdamos leer la sección sobre
|
||
cifrado que econtrará más adelante.</para>
|
||
</sect4>
|
||
|
||
<sect4>
|
||
<title>Información de estado</title>
|
||
<para>Una vez que el punto de acceso estáconfigurado
|
||
resulta interesante poder obtener información acerca de los
|
||
clientes que estén asociados. La persona encargada de la
|
||
administración del punto de acceso puede ejecutar cuando
|
||
estime oportuno lo siguiente:
|
||
|
||
<screen>&prompt.root; <userinput>wicontrol -l</userinput>
|
||
1 station:
|
||
00:09:b7:7b:9d:16 asid=04c0, flags=3<ASSOC,AUTH>, caps=1<ESS>, rates=f<1M,2M,5.5M,11M>, sig=38/15
|
||
</screen>
|
||
|
||
<para>Lo que aquí se muestra indica que hay una única
|
||
estación asociada y nos suministra sus parámetros.
|
||
Los valores de señal que se muestran se deben tomar
|
||
sólo como indicaciones aproximadas de la fuerza de dicha
|
||
señal. Su traducción a dBm u otras unidades
|
||
varía según la versión del <quote>
|
||
firmware</quote> de la tarjeta que se use.</para>
|
||
</sect4>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Clientes</title>
|
||
|
||
<para>Un cliente <quote>wireless</quote> es un sistema que se comunica
|
||
con un punto de acceso o directamente con otro cliente
|
||
<quote>wireless</quote>.</para>
|
||
|
||
<para>Generalmente los clientes <quote>wireless</quote> sólo
|
||
poseen un dispositivo de red: la tarjeta de red
|
||
inalámbrica.</para>
|
||
|
||
<para>Existen varias formas de configurar un cliente <quote>
|
||
wireless</quote> basadas en los distintos modos
|
||
inalámbricos, normalmente reducidos a BSS (o modo
|
||
infraestructura, que requiere de un punto de acceso) y el
|
||
modo IBSS (modo ad-hoc, o modo punto a punto). En nuestro ejemplo
|
||
usaremos el más famoso de ambos, el BSS, para comunicarnos
|
||
con un punto de acceso.</para>
|
||
|
||
<sect4>
|
||
<title>Requisitos</title>
|
||
<para>Sólamente existe un requisito real para configurar
|
||
un sistema FreeBSD como cliente inalámbrico: usar una
|
||
tarjeta de red inalámbrica soportada por el sistema.</para>
|
||
</sect4>
|
||
|
||
<sect4>
|
||
<title>Ejecución de un cliente inalámbrico &os;</title>
|
||
|
||
<para>Para utilizar una red inalámbrica se necesitan
|
||
conocer algunos conceptos básicos de redes
|
||
de redes wireless. En nuestro ejemplo queremos conectarnos a la
|
||
red inalámbrica <replaceable>mi_red</replaceable> y queremos
|
||
hacerlo con el soporte de cifrado desactivado.</para>
|
||
|
||
<note><para>En este ejemplo no se utiliza cifrado,
|
||
lo cual resulta ser bastante peligroso. En la próxima
|
||
sección aprenderemos cómo activar el sistema de
|
||
cifrado común el los dispositivos
|
||
inalámbricos, por qué resulta importante hacerlo
|
||
y por qué algunas tecnologías de cifrado no son
|
||
suficientes para protegernos completamente.</para></note>
|
||
|
||
<para>Asegúrese de que FreeBSD reconoce su tarjeta de
|
||
red inalámbrica:</para>
|
||
|
||
<screen>&prompt.root; <userinput>ifconfig -a</userinput>
|
||
wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
|
||
inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7
|
||
inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
|
||
ether 00:09:2d:2d:c9:50
|
||
media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps)
|
||
status: no carrier
|
||
ssid ""
|
||
stationname "FreeBSD Wireless node"
|
||
channel 10 authmode OPEN powersavemode OFF powersavesleep 100
|
||
wepmode OFF weptxkey 1</screen>
|
||
|
||
<para>A continuación debemos especificar los
|
||
parámetros correctos para nuestra red:</para>
|
||
|
||
<screen>&prompt.root; <userinput>ifconfig wi0 inet <replaceable>192.168.0.20</replaceable> netmask <replaceable>255.255.255.0</replaceable> ssid <replaceable>mi_red</replaceable></userinput></screen>
|
||
|
||
<para>Sustituya <hostid role="ipaddr">192.168.0.20</hostid> y
|
||
<hostid role="netmask">255.255.255.0</hostid> con una
|
||
dirección IP y máscara de red que se
|
||
adecúen con el espacio de direccionamiento de la red cableada.
|
||
Recordemos que nuestro punto de acceso está puenteando la red
|
||
inalámbrica y la red de cable, de modo que para el resto de
|
||
dispositivos de la red el cliente inalábrico se muestra como
|
||
un elemento más de la red cableada.</para>
|
||
|
||
<para>Llegados a este punto deberíamos poder hacer ping a las
|
||
máquinas de la red cableada como si estuviéramos
|
||
compartiendo el mismo enlace físico cableado.</para>
|
||
|
||
<para>Si se presentan problemas con la conexión
|
||
inalámbrica se puede comprobar si la tarjeta <quote>
|
||
wireless</quote> se encuentra correctamente asociada (conectada)
|
||
con el punto de acceso:</para>
|
||
|
||
<screen>&prompt.root; <userinput>ifconfig wi0</userinput></screen>
|
||
|
||
<para>ebería devolver algún tipo de información
|
||
entre la que deberíamos observar la siguiente
|
||
línea:</para>
|
||
<screen>status: associated</screen>
|
||
|
||
<para>Si no aparece la palabra <literal>associated</literal> puede ser
|
||
que nos encontremos fuera de la cobertura proporcionada por el punto
|
||
de acceso o puede ser que necesitemos activar el cifrado, aunque
|
||
éstos no son los únicos problemas con los que nos
|
||
podemos encontrar.</para>
|
||
|
||
</sect4>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Cifrado</title>
|
||
<indexterm>
|
||
<primary>wireless networking</primary>
|
||
<secondary>encryption</secondary>
|
||
</indexterm>
|
||
|
||
<para>El cifrado, también llamado codificación, de una
|
||
red inalámbrica es un proceso importante porque, a diferencia
|
||
de lo que ocurre con las redes cableadas convencionales, las redes
|
||
inalámbricas no se pueden restringir a un espacio
|
||
físico determinado. Los datos que viajan a través de
|
||
ondas de radio se difunden a través de las paredes y alcanzan
|
||
a los vecinos más cercanos. Aquí es donde entra en
|
||
en juego el sistema de cifrado. El cifrado se emplea para evitar que
|
||
cualquiera pueda examinar los datos enviados a través del
|
||
aire.</para>
|
||
|
||
<para>Los dos métodos más comunes para realizar el cifrado
|
||
de datos entre el cliente y el punto de acceso son WEP e
|
||
&man.ipsec.4;.</para>
|
||
|
||
<sect4>
|
||
<title>WEP</title>
|
||
<indexterm><primary>WEP</primary></indexterm>
|
||
|
||
<para>WEP son las siglas de Wired Equivalency Protocol. WEP es un
|
||
un intento de crear redes inalámbricas al menos tan seguras
|
||
omo las redes cableadas o al menos de seguridad equivalente a dichas
|
||
redes. Por desgracia el sistema WEP es débil y resulta
|
||
bastante sencillo de romper. Esto significa que cuando se transmite
|
||
información de carácter crítico no se debe
|
||
confiar únicamente en este sistema de cifrado.</para>
|
||
|
||
<para>No obstante es mejor que no utilizar nada; puede activar WEP en el
|
||
sistema que hace de punto de acceso mediante:</para>
|
||
|
||
<screen>&prompt.root; <userinput>ifconfig wi0 inet up ssid
|
||
<replaceable>mi_red</replaceable> wepmode on wepkey
|
||
<replaceable>0x1234567890</replaceable> media DS/11Mbps
|
||
mediaopt hostap</userinput></screen>
|
||
|
||
<para>y en un cliente inalámbrico mediante la siguiente
|
||
orden:</para>
|
||
|
||
<screen>&prompt.root; <userinput>ifconfig wi0 inet <replaceable>192.168.0.20</replaceable> netmask <replaceable>255.255.255.0</replaceable> ssid <replaceable>mi_red</replaceable> wepmode on wepkey <replaceable>0x1234567890</replaceable></userinput></screen>
|
||
|
||
<para>Por favor, tenga un poco de sentido común y reemplace la
|
||
clave <replaceable>0x1234567890</replaceable> por otra clave
|
||
menos obvia.</para>
|
||
|
||
</sect4>
|
||
|
||
<sect4>
|
||
<title>IPsec</title>
|
||
|
||
<para>&man.ipsec.4; es una herramienta más robusta y potente para
|
||
cifrar datos que se mueven a través de una red. Es el
|
||
mecanismo más conveniente para asegurar los datos de una red
|
||
inalámbrica. Tiene más información sobre el
|
||
protocolo &man.ipsec.4; y cómo utilizarlo en la sección
|
||
<link linkend="ipsec">IPsec</link> de este manual.</para>
|
||
</sect4>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Herramientas</title>
|
||
|
||
<para>No hay muchas herramientas disponibles si se quiere depurar y
|
||
monitorizar redes inalámbricas pero en el siguiente apartado
|
||
mostraremos cómo utilizar algunas de ellas.</para>
|
||
<sect4>
|
||
<title>El paquete <application>bsd-airtools</application></title>
|
||
|
||
<para>El paquete <application>bsd-airtools</application> es un
|
||
conjunto muy completo de herramientas <quote>wireless</quote> que se
|
||
pueden utilizar para multitud de tareas, entre las cuales podemos citar
|
||
citar el desciframiento de claves WEP, detección de puntos de
|
||
de acceso, monitorización de la señal de radio, etc.</para>
|
||
|
||
<para>El paquete <application>bsd-airtools</application> se puede instalar
|
||
como <quote>port</quote> desde <filename role="package">
|
||
net/bsd-airtools</filename>. La información relacionada con los
|
||
<quote>ports</quote> puede encontrarse en la sección
|
||
<xref linkend="ports"> de este
|
||
manual.</para>
|
||
|
||
<para>El programa <command>dstumbler</command> es una herramienta que
|
||
permite descubrir puntos de acceso y entre otras cosas muestra de forma
|
||
gráfica la relación señal / ruido del enlace.
|
||
Si se experimentan problemas para acceder a un determinado punto de
|
||
acceso <command>dstumbler</command> puede ser muy útil.</para>
|
||
|
||
<para>Para probar la seguridad de la red inalámbrica se puede usar
|
||
<quote>dweputils</quote>, concretamente las órdenes <command>
|
||
dwepcrack</command>, <command>dwepdump</command> y <command>
|
||
dwepkeygen</command>. Estas órdenes permiten determinar hasta
|
||
qué punto la seguridad que ofrece WEP es suficiente para nuestras
|
||
necesidades.</para>
|
||
|
||
</sect4>
|
||
|
||
<sect4>
|
||
<title>Las utilidades <command>wicontrol</command>,
|
||
<command>ancontrol</command> y
|
||
<command>raycontrol</command></title>
|
||
|
||
<para>Mediante estas herramientas se puede controlar el comportamiento de
|
||
la tarjeta de red inalámbrica. En los ejemplos anteriores se
|
||
ha utilizado &man.wicontrol.8; debido a que la tarjeta de red del
|
||
ejemplo utiliza el interfaz <devicename>wi0</devicename>. Si se
|
||
posée una tarjeta <quote>wireless</quote> de Cisco dicha tarjeta
|
||
se mostrará en el sistema mediante el interfaz <devicename>
|
||
an0</devicename> y por lo tanto la orden equivalente que se debe usar
|
||
será &man.ancontrol.8;.</para>
|
||
|
||
</sect4>
|
||
|
||
<sect4>
|
||
<title><command>ifconfig</command></title>
|
||
<indexterm><primary>ifconfig</primary></indexterm>
|
||
|
||
<para>Con &man.ifconfig.8; se puede utilizar unas cuantas de las opciones
|
||
que se pueden usar con &man.wicontrol.8;, pero no obstante no
|
||
posée todas las funcionalidades que proporciona
|
||
&man.wicontrol.8;. Se recomienda leer &man.ifconfig.8; para conocer los
|
||
detalles de los parámetros y opciones que admite.</para>
|
||
|
||
</sect4>
|
||
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Tarjetas de Red inalámbricas soportadas</title>
|
||
<sect4>
|
||
<title>Puntos de acceso</title>
|
||
|
||
<para>Las únicas tarjetas que soportan el modo de funcionamiento
|
||
funcionamiento BSS (pueden funcionar como puntos de acceso) son los
|
||
dispositivos basados en el chip Prism 2, 2.5 ó 3. Consulte
|
||
&man.wi.4; para ver una lista completa de ellos.</para>
|
||
</sect4>
|
||
|
||
<sect4>
|
||
<title>Clientes</title>
|
||
|
||
<para>FreeBSD soporta casi todas las tarjetas inalámbricas 802.11b
|
||
802.11b que se encuentran actualmente en el mercado. La
|
||
mayoría de las tarjetas basadas en los chips Prism, Spectrum24,
|
||
Spectrum24, Hermes, Aironet y Raylink tambíen funcionan en modo
|
||
IBSS (modos ad-hoc, punto a punto y BSS).</para>
|
||
|
||
</sect4>
|
||
</sect3>
|
||
|
||
</sect2>
|
||
</sect1>
|
||
|
||
<sect1 id="network-bluetooth">
|
||
<sect1info>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Pav</firstname>
|
||
<surname>Lucistnik</surname>
|
||
<contrib>Escrito por </contrib>
|
||
<affiliation>
|
||
<address><email>pav@oook.cz</email></address>
|
||
</affiliation>
|
||
</author>
|
||
</authorgroup>
|
||
</sect1info>
|
||
<title>Bluetooth</title>
|
||
|
||
<indexterm><primary>Bluetooth</primary></indexterm>
|
||
<sect2>
|
||
<title>Introducción</title>
|
||
<para>Bluetooth es una tecnología inalámbrica que opera en
|
||
banda de 2.4 GHz (donde no se necesita licencia). Se trata de una
|
||
tecnología pensada para la creación de redes de
|
||
ámbito personal (de cobertura reducida, normalmente de unos 10
|
||
metros). Las redes se suelen construir en modo <quote>ad-hoc</quote>
|
||
utilizando dispositivos heterogéneos como teléfonos
|
||
móviles, dispositivos manuales (<quote>handhelds</quote>) y
|
||
computadoras portátiles. A diferencia de otras
|
||
tecnologías inalámbricas como Wi-Fi, Bluetooth ofrece
|
||
perfiles de servicio más detallados; por ejemplo un perfil para
|
||
actuar como un servidor de ficheros basado en FTP, para la
|
||
difusión de ficheros (<quote>file pushing</quote>), para el
|
||
transporte de voz, para la emulación de línea serie y
|
||
muchos más.</para>
|
||
|
||
<para>La pila de Bluetooth en &os; se implementa utilizando el entorno
|
||
de Netgraph (véase &man.netgraph.4;). La mayoría de los
|
||
dispositivos USB Bluetooth se pueden utilizar mediante el controlador
|
||
&man.ng.ubt.4;. Los dispositivos Bluetooth basados en el chip Broadcom
|
||
BCM2033 están soportados mediante los controladores
|
||
&man.ubtbcmfw.4; y &man.ng.bt3c.4;. Los dispositivos Bluetooth
|
||
basados en la interfaz serie o de Rayos Infrarrojos (UART) se
|
||
controlan mediante &man.sio.4;, &man.ng.h4.4; y &man.hcseriald.8;.
|
||
Este capítulo describe el uso de dispositivos Bluetooth USB.
|
||
El soporte para Bluetooth se encuentra en las versiones de &os; 5.0 y
|
||
posteriores.</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Instalación del dispositivo</title>
|
||
<para>Por defecto los controladores de los dispositivos Bluetooth se
|
||
encuentran disponibles como módulos del kernel. Antes de
|
||
enchufar el dispositivo Bluetooth se debe cargar el módulo
|
||
correspondiente dentro del núcleo.</para>
|
||
|
||
|
||
<screen>&prompt.root; <userinput>kldload ng_ubt</userinput></screen>
|
||
|
||
<para>Si el dispositivo Bluetooth se encuentra conectado cuando el
|
||
sistema arranca se debe cargar el módulo modificando a tal
|
||
efecto el fichero <filename>/boot/loader.conf</filename>.</para>
|
||
|
||
<programlisting>ng_ubt_load="YES"</programlisting>
|
||
|
||
<para>Al conectar el dispositivo Bluetooth aparecerá en la
|
||
consola (o en syslog) la siguiente información:</para>
|
||
|
||
<screen>ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2
|
||
ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
|
||
ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3,
|
||
wMaxPacketSize=49, nframes=6, buffer size=294</screen>
|
||
|
||
<para>Se debe copiar
|
||
<filename>/usr/share/examples/netgraph/bluetooth/rc.bluetooth</filename>
|
||
a algún lugar más conveniente, por ejemplo
|
||
<filename>/etc/rc.bluetooth</filename>. Este script se usa para
|
||
ejecutar y detener la pila Bluetooth del sistema. Se suele recomendar
|
||
quitar la pila antes de desenchufar el dispositivo pero si no se hace
|
||
no debería producirse ningún desastre. Cuando se
|
||
arranca la pila aparece un mensaje similar a este:</para>
|
||
|
||
<screen>&prompt.root; <userinput>/etc/rc.bluetooth start ubt0</userinput>
|
||
BD_ADDR: 00:02:72:00:d4:1a
|
||
Features: 0xff 0xff 0xf 00 00 00 00 00
|
||
<3-Slot> <5-Slot> <Encryption> <Slot offset>
|
||
<Timing accuracy> <Switch> <Hold mode> <Sniff mode>
|
||
<Park mode> <RSSI> <Channel quality> <SCO link>
|
||
<HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD>
|
||
<Paging scheme> <Power control> <Transparent SCO data>
|
||
Max. ACL packet size: 192 bytes
|
||
Number of ACL packets: 8
|
||
Max. SCO packet size: 64 bytes
|
||
Number of SCO packets: 8</screen>
|
||
|
||
</sect2>
|
||
|
||
<indexterm><primary>HCI</primary></indexterm>
|
||
<sect2>
|
||
<title>Interfaz de la controladora de la máquina (HCI)</title>
|
||
|
||
<para>La interfaz de la Controladora de la Máquina (Host
|
||
Controller Interface) proporciona una interfaz de órdenes
|
||
para la controladora de banda base y para el gestor de enlace,
|
||
y permite acceder al estado del hardware y a los
|
||
registros de control. Esta interfaz proporciona una capa de
|
||
acceso homogénea para todos los dispositivos Bluetooth
|
||
de banda base. La capa HCI de la máquina intercambia
|
||
órdenes y datos con el firmware del HCI presente en el
|
||
dispositivo Bluetooth. El driver de la capa de transporte de
|
||
la controladora de la máquina
|
||
(es decir, el driver del bus físico) proporciona
|
||
ambas capas de HCI la posibilidad de intercambiar
|
||
información entre ellas.</para>
|
||
|
||
<para>Se crea un nodo Netgraph de tipo <emphasis>HCI</emphasis>
|
||
para cada dispositivo Bluetooth. El nodo Netgraph HCI
|
||
se conecta normalmente con el nodo que representa el
|
||
controlador del dispositivo Bluetooth de la máquina
|
||
(sentido de bajada) y con el nodo Netgraph L2CAP en el sentido
|
||
de subida. Todas las operaciones HCI se realizan sobre el
|
||
nodo Netgraph HCI y no sobre el el nodo que representa al
|
||
dispositivo. El nombre por defecto para el nodo HCI es
|
||
<quote>devicehci</quote>. Para obtener más detalles,
|
||
por favor consulte la página del manual de
|
||
&man.ng.hci.4;.</para>
|
||
|
||
<para>Una de las tareas más importantes que se deben
|
||
realizar es el descubrimiento automático de otros
|
||
dispositivos Bluetooth que se encuentren dentro del radio de
|
||
cobertura. Esta operación se denomina en inglés
|
||
<emphasis>inquiry</emphasis> (consulta). Esta operación
|
||
o otras operaciones HCI relacionadas se realizan mediante
|
||
la utilidad &man.hccontrol.8;. El siguiente ejemplo muestra
|
||
cómo descubrir dispositivos en pocos segundos.
|
||
Tenga siempre presente que un dispositivo remoto sólo
|
||
contesta a la consulta si se encuentra configurado en modo
|
||
descubrimiento (<emphasis>discoverable mode</emphasis>).</para>
|
||
|
||
<screen>&prompt.user; <userinput>hccontrol -n ubt0hci inquiry</userinput>
|
||
Inquiry result, num_responses=1
|
||
Inquiry result #0
|
||
BD_ADDR: 00:80:37:29:19:a4
|
||
Page Scan Rep. Mode: 0x1
|
||
Page Scan Period Mode: 00
|
||
Page Scan Mode: 00
|
||
Class: 52:02:04
|
||
Clock offset: 0x78ef
|
||
Inquiry complete. Status: No error [00]</screen>
|
||
|
||
<para><literal>BD_ADDR</literal> es la dirección
|
||
identificativa única del dispositivo Bluetooth,
|
||
similar a las direcciones MAC de las tarjetas Ethernet. Esta
|
||
dirección se necesita para transmitir otro tipo de
|
||
información a otros dispositivos. Se puede asignar un nombre
|
||
más significativo para los humanos en la variable BD_ADDR.
|
||
El fichero <filename>/etc/bluetooth/hosts</filename> contiene
|
||
información relativa a los dispositivos Bluetooth conocidos.
|
||
El siguiente ejemplo muestra cómo obtener un nombre
|
||
significativo para los humanos que fué asignado a un
|
||
dispositivo remoto:</para>
|
||
|
||
<screen>&prompt.user; <userinput>hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4</userinput>
|
||
BD_ADDR: 00:80:37:29:19:a4
|
||
Name: Pav's T39</screen>
|
||
|
||
<para>Si se realiza una consulta (inquiry) sobre el dispositivo
|
||
Bluetooth remoto, dicho dispositivo identificará nuestro
|
||
computador como <quote>nombre.de.su.sistema
|
||
(ubt0)</quote>. El nombre asignado al dispositivo local se puede
|
||
modificar en cualquier momento.</para>
|
||
|
||
<para>El sistema Bluetooth proporciona una conexión punto a punto
|
||
(con sólo dos unidades Bluetooth involucradas) o
|
||
también una conexión punto multipunto. En el
|
||
último caso, la conexión se comparte entre varios
|
||
dispositivos Bluetooth. El siguiente ejemplo muestra como obtener una
|
||
lista de las conexiones de banda base activas en el dispositivo
|
||
local:</para>
|
||
|
||
<screen>&prompt.user; <userinput>hccontrol -n ubt0hci read_connection_list</userinput>
|
||
Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State
|
||
00:80:37:29:19:a4 41 ACL 0 MAST NONE 0 0 OPEN</screen>
|
||
|
||
<para>Resulta útil disponer de un <emphasis>manejador de
|
||
la conexión</emphasis> cuando se necesita terminar la
|
||
conexión de banda base. Es importante recalcar que normalmente
|
||
no es necesario realizar esta terminación de forma manual.
|
||
La pila Bluetooth puede concluír automáticamente las
|
||
conexiones de banda base que se encuentren inactivas.</para>
|
||
|
||
<screen>&prompt.root; <userinput>hccontrol -n ubt0hci disconnect 41</userinput>
|
||
Connection handle: 41
|
||
Reason: Connection terminated by local host [0x16]</screen>
|
||
|
||
<para>Se ruega consultar la salida de la orden
|
||
<command>hccontrol help</command> para obtener un listado completo de
|
||
las órdenes HCI disponibles. La mayoría de
|
||
estas órdenes no requiren privilegios de superusuario.</para>
|
||
|
||
</sect2>
|
||
|
||
<indexterm><primary>L2CAP</primary></indexterm>
|
||
<sect2>
|
||
<title>Protocolo de adaptación y de control de enlace a
|
||
nivel lógico (L2CAP)</title>
|
||
|
||
<para>El protocolo L2CAP (Logical Link Control and Adaptation
|
||
Protocol) proporciona servicios de datos tanto orientados a
|
||
conexión como no orientados a conexión a los protocolos
|
||
de las capas superiores, junto con facilidades de
|
||
multiplexación y de segmentacion y reensamblaje. L2CAP permite
|
||
que los protocolos de capas superiores puedan transmitir y recibir
|
||
paquetes de datos L2CAP de hasta 64 kilobytes de longitud.</para>
|
||
|
||
<para>L2CAP se basa en el concepto de <emphasis>canales</emphasis>.
|
||
Un canal es una conexión lógica que se sitúa
|
||
sobre la conexión de banda base. Cada canal se asocia a un
|
||
único protocolo. Cada paquete L2CAP que se recibe a un canal
|
||
se redirige al protocolo superior correspondiente. Varios canales
|
||
pueden operar sobre la misma conexión de banda base, pero un
|
||
canal no puede tener asociados más de un protocolo de alto
|
||
nivel.</para>
|
||
|
||
<para>Para cada dispositivo Bluetooth se cre un único nodo
|
||
Netgraph de tipo <emphasis>l2cap</emphasis>. El nodo L2CAP se conecta
|
||
normalmente conectado al nodo Netgraph HCI (hacia abajo) y con nodos
|
||
Bluetooth tipo <quote>sockets</quote> hacia arriba. El nombre por
|
||
defecto para el nodo Netgraph L2CAP es <quote>devicel2cap</quote>.
|
||
Para obtener más detalles se ruega consultar la página
|
||
del manual &man.ng.l2cap.4;.</para>
|
||
|
||
<para>&man.l2ping.8; le será muy útil para
|
||
hacer ping a otros dispositivos. Algunas
|
||
implementaciones de Bluetooth no devuelven todos los datos que se
|
||
envían, de tal forma que el valor <emphasis>0 bytes</emphasis>
|
||
que se observa a continuación es normal:</para>
|
||
|
||
<screen>&prompt.root; <userinput>l2ping -a 00:80:37:29:19:a4</userinput>
|
||
0 bytes from 0:80:37:29:19:a4 seq_no=0 time=48.633 ms result=0
|
||
0 bytes from 0:80:37:29:19:a4 seq_no=1 time=37.551 ms result=0
|
||
0 bytes from 0:80:37:29:19:a4 seq_no=2 time=28.324 ms result=0
|
||
0 bytes from 0:80:37:29:19:a4 seq_no=3 time=46.150 ms result=0</screen>
|
||
|
||
<para>La herramienta &man.l2control.8; se utiliza para realizar
|
||
varias operaciones sobre los nodos L2CAP. Este ejemplo muestra
|
||
cómo obtener la lista de conexiones lógicas (canales) y
|
||
la lista de conexiones de banda base (física) que mantiene el
|
||
dispositivo local:</para>
|
||
|
||
<screen>&prompt.user; <userinput>l2control -a 00:02:72:00:d4:1a read_channel_list</userinput>
|
||
L2CAP channels:
|
||
Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State
|
||
00:07:e0:00:0b:ca 66/ 64 3 132/ 672 OPEN
|
||
&prompt.user; <userinput>l2control -a 00:02:72:00:d4:1a read_connection_list</userinput>
|
||
L2CAP connections:
|
||
Remote BD_ADDR Handle Flags Pending State
|
||
00:07:e0:00:0b:ca 41 O 0 OPEN</screen>
|
||
|
||
<para>Otra herramienta de diagnóstico interesante es
|
||
&man.btsockstat.1;. Realiza un trabajo similar a la orden
|
||
&man.netstat.1;, pero en este caso para las estructuras de datos
|
||
relacionadas con el sistema Bluetooth. A continuación se
|
||
muestra la información relativa a la misma conexión
|
||
lógica del ejemplo anterior.</para>
|
||
|
||
<screen>&prompt.user; <userinput>btsockstat</userinput>
|
||
Active L2CAP sockets
|
||
PCB Recv-Q Send-Q Local address/PSM Foreign address CID State
|
||
c2afe900 0 0 00:02:72:00:d4:1a/3 00:07:e0:00:0b:ca 66 OPEN
|
||
Active RFCOMM sessions
|
||
L2PCB PCB Flag MTU Out-Q DLCs State
|
||
c2afe900 c2b53380 1 127 0 Yes OPEN
|
||
Active RFCOMM sockets
|
||
PCB Recv-Q Send-Q Local address Foreign address Chan DLCI State
|
||
c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPEN</screen>
|
||
|
||
</sect2>
|
||
|
||
<indexterm><primary>RFCOMM</primary></indexterm>
|
||
<sect2>
|
||
<title>Protocolo RFCOMM </title>
|
||
|
||
<para>El protocolo RFCOMM proporciona emulación de puertos serie
|
||
a través del protocolo L2CAP. Este protocolo se basa en el
|
||
estándar de la ETSI denominado TS 07.10. RFCOMM es un
|
||
protoclo de transporte sencillo, con soporte para hasta 9 puertos
|
||
serie RS-232 (EIATIA-232-E). El protocolo RFCOMM permite hasta 60
|
||
conexiones simultaneas (canales RFCOMM) entre dos dispositivos
|
||
Bluetooth.</para>
|
||
|
||
<para>Para los propósitos de RFCOMM, un camino de
|
||
comunicación involucra siempre a dos aplicaciones que se
|
||
ejecutan en dos dispositivos distintos (los extremos de la
|
||
comunicación). Entre ellos existe un segmento que los
|
||
comunica. RFCOMM pretende cubrir aquellas aplicaciones que utilizan
|
||
los puertos serie de las máquinas donde se ejecutan. El
|
||
segmento de comunicación es un enlace Bluetooth desde un
|
||
dispositivo al otro (conexión directa).</para>
|
||
|
||
|
||
<para>RFCOMM trata únicamente con la conexión de
|
||
dispositivos directamente, y también con conexiones entre el
|
||
dispositivo y el modem para realizar conexiones de red. RFCOMM puede
|
||
soportar otras configuraciones, tales como módulos que
|
||
se comunican via Bluetooth por un lado y que proporcionan una interfaz
|
||
de red cableada por el otro.</para>
|
||
|
||
<para>En &os; el protocolo RFCOMM se implementa utilizando la
|
||
capa de <quote>sockets</quote> de Bluetooth.</para>
|
||
</sect2>
|
||
|
||
<indexterm><primary>pairing</primary></indexterm>
|
||
<sect2>
|
||
<title>Enparejamiento de dispositivos</title>
|
||
|
||
<para>Por defecto, la comunicación Bluetooth no se valida, por lo
|
||
que cualquier dispositivo puede en principio hablar con cualquier
|
||
otro. Un dispositivo Bluetooth (por ejemplo un teléfono
|
||
celular) puede solicitar autenticación para realizar un
|
||
determinado servicio (por ejemplo para el servicio de
|
||
marcación por modem). La autenticación de Bluetooth
|
||
normalmente se realiza utilizando <emphasis>códigos
|
||
PIN</emphasis>. Un código PIN es una cadena ASCII de hasta
|
||
16 caracteres de longitud. Los usuarios deben introducir
|
||
el mismo código PIN en ambos dispositivos. Una vez que el
|
||
usuario ha introducido el PIN adecuado ambos dispositivos generan una
|
||
<emphasis>clave de enlace</emphasis>. Una vez generada, la clave se
|
||
puede almacenar en el propio dispositivo o en un dispositivo de
|
||
almacenamiento externo. La siguiente vez que se comuniquen ambos
|
||
dispositivos se reutilizará la misma clave. El procedimiento
|
||
descrito hasta este punto se denomina
|
||
<emphasis>emparejamiento (pairing)</emphasis>. Es importante recordar
|
||
que si la clave de enlace se pierde en alguno de los dispositivos
|
||
involucrados se debe volver a ejecutar el procedimiento de
|
||
emparejamiento.</para>
|
||
|
||
<para>El dæmon &man.hcsecd.8; se encarga de gestionar todas las
|
||
peticiones de autenticación Bluetooth. El archivo de
|
||
configuración predeterminado se denomina
|
||
<filename>/etc/bluetooth/hcsecd.conf</filename>. A
|
||
continuación se muestra una sección de ejemplo de un
|
||
teléfono celular con el código PIN arbitrariamente
|
||
fijado al valor <quote>1234</quote>:
|
||
</para>
|
||
|
||
<programlisting>device {
|
||
bdaddr 00:80:37:29:19:a4;
|
||
name "Pav's T39";
|
||
key nokey;
|
||
pin "1234";
|
||
}</programlisting>
|
||
|
||
<para>No existe ninguna limitación en los códigos PIN a
|
||
excepción de su longitud. Algunos dispositivos (por ejemplo
|
||
los dispositivos de mano Bluetooth) pueden obligar a escribir un
|
||
número predeterminado de caracteres para el código
|
||
PIN. La opción <option>-d</option> fuerza al dæmon
|
||
&man.hcsecd.8; a permanecer ejecutádose en primer plano,
|
||
de tal forma que se puede observar fácilmente lo que ocurre. Si
|
||
se configura el dispositivo Bluetooth remoto para aceptar el
|
||
procedimiento de emparejamiento y se inicia la conexión con
|
||
dicho dispositivo, el dispositivo remoto debería decir que el
|
||
procedimiento de emparejamiento se ha aceptado y debería
|
||
solicitar el código PIN. Si se introduce el mismo
|
||
código PIN que se escribió en su momento en el fichero
|
||
<filename>hcsecd.conf</filename> el procedimiento de emparejamiento y
|
||
de generación de la clave de enlace debería terminar
|
||
satisfactoriamente. Por otra parte el procedimiento de emparejamiento
|
||
se puede iniciar en el dispositivo remoto. A continuación
|
||
se muestra un ejemplo de la salida del dæmon
|
||
<command>hcsecd</command>.</para>
|
||
|
||
<programlisting>hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4
|
||
hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist
|
||
hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4
|
||
hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4
|
||
hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists
|
||
hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4</programlisting>
|
||
|
||
</sect2>
|
||
|
||
<indexterm><primary>SDP</primary></indexterm>
|
||
<sect2>
|
||
<title>Protocolo de descubrimiento de servicios (SDP)</title>
|
||
|
||
<para>El Protocolo de Descubrimiento de Servicios (Service
|
||
Discovery Protocol o SDP) permite a las aplicaciones
|
||
cliente descubrir la existencia de diversos servicios
|
||
proporcionados por uno o varios servidores de aplicaciones,
|
||
junto con los atributos y propiedades de los servicios que se
|
||
ofrecen. Estos atributos de servicio incluyen
|
||
el tipo o clase de servicio ofrecido y el mecanismo o la
|
||
información necesaria para utilizar dichos servicios.</para>
|
||
|
||
<para>SDP se basa en una determinada comunicación entre
|
||
un servidor SDP y un cliente SDP. El servidor mantiene una lista de
|
||
registros de servicios, los cuales describen las
|
||
características de los servicios ofrecidos. Cada registro
|
||
contiene información sobre un determinado servicio. Un cliente
|
||
puede recuperar la información de un registro de servicio
|
||
almacenado en un servidor SDP lanzando una petición SDP. Si el
|
||
cliente o la aplicación asociada con el cliente decide utilizar
|
||
un determinado servicio, debe establecer una conexión
|
||
independiente con el servicio en cuestión. SDP proporciona un
|
||
mecanismo para el descubrimiento de servicios y sus atributos
|
||
asociados, pero no proporciona ningún mecanismo ni protocolo
|
||
para utilizar dichos servicios.</para>
|
||
|
||
<para>Normalmente, un cliente SDP realiza una búsqueda de
|
||
servicios acotada por determinadas características. No obstante
|
||
hay momentos en los que resulta deseable descubrir todos los
|
||
servicios ofrecidos por un servidor SDP sin que pueda existir
|
||
ningún conocimiento previo sobre los registros que pueda
|
||
contener. Este proceso de búsqueda de cualquier servicio
|
||
ofrecido se denomina <emphasis>navegación</emphasis> o
|
||
<emphasis>browsing</emphasis>.</para>
|
||
|
||
<para>El servidor Bluetooth SDP denominado &man.sdpd.8; y el cliente de
|
||
línea de órdenes &man.sdpcontrol.8; se incluyen en
|
||
la instalación estándar de &os;. El siguiente ejemplo
|
||
muestra cómo realizar una consulta de navegación
|
||
una consulta de navegación SDP.</para>
|
||
|
||
<screen>&prompt.user; <userinput>sdpcontrol -a 00:01:03:fc:6e:ec browse</userinput>
|
||
Record Handle: 00000000
|
||
Service Class ID List:
|
||
Service Discovery Server (0x1000)
|
||
Protocol Descriptor List:
|
||
L2CAP (0x0100)
|
||
Protocol specific parameter #1: u/int/uuid16 1
|
||
Protocol specific parameter #2: u/int/uuid16 1
|
||
|
||
Record Handle: 0x00000001
|
||
Service Class ID List:
|
||
Browse Group Descriptor (0x1001)
|
||
|
||
Record Handle: 0x00000002
|
||
Service Class ID List:
|
||
LAN Access Using PPP (0x1102)
|
||
Protocol Descriptor List:
|
||
L2CAP (0x0100)
|
||
RFCOMM (0x0003)
|
||
Protocol specific parameter #1: u/int8/bool 1
|
||
Bluetooth Profile Descriptor List:
|
||
LAN Access Using PPP (0x1102) ver. 1.0
|
||
</screen>
|
||
|
||
<para>... y así sucesivamente. Resulta importante resaltar una
|
||
vez más que cada servicio posee una lista de atributos (por
|
||
ejemplo en el canal RFCOMM). Dependiendo de los servicios que se
|
||
quieran utilizar puede resultar necesario anotar algunos de los
|
||
atributos. Algunas implementaciones de Bluetooth no soportan
|
||
navegación de servicios y pueden devolver una lista
|
||
vacía. En este caso se puede intentar buscar algún
|
||
servicio determinado. El ejemplo siguiente muestra cómo buscar
|
||
el servicio OBEX Object Push (OPUSH):</para>
|
||
|
||
<screen>&prompt.user; <userinput>sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH</userinput></screen>
|
||
|
||
<para>En &os; los servicios a clientes Bluetooth se suministran mediante
|
||
el servidor &man.sdpd.8;.</para>
|
||
<screen>&prompt.root; <userinput>sdpd</userinput></screen>
|
||
|
||
<para>La aplicación local servidora que quiere proporcionar
|
||
servicio Bluetooth a los clientes remotos puede registrar su servicio
|
||
con el dæmon SDP local. Un ejemplo de dicha aplicación
|
||
Un ejemplo de dicha aplicación lo constituye el dæmon
|
||
&man.rfcomm.pppd.8;.
|
||
Una vez ejecutado el dæmon registra un servicio LAN de Bluetooth
|
||
en el dæmon SDP local.</para>
|
||
|
||
<para>Se puede obtener la lista de servicios registrados con el servidor
|
||
SDP local lanzando una consulta de navegación SDP utilizando
|
||
el canal de control local.</para>
|
||
|
||
<screen>&prompt.root; <userinput>sdpcontrol -l browse</userinput></screen>
|
||
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Acceso telefónico a redes (DUN) y acceso a redes mediante
|
||
perfiles PPP (LAN)</title>
|
||
|
||
<para>El perfil de Acceso Telefónico a Redes (Dial-Up Networking
|
||
o DUN) se utiliza mayoritariamente con modems y teléfonos
|
||
celulares. Los escenarios cubiertos por este perfil se describen a
|
||
continuación:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem><para>Utilización de un teléfono celular o un
|
||
modem por una computadora para simular un modem sin cables
|
||
que se conecte a un servidor de acceso telefónico a redes o
|
||
para otros servicios de acceso telefónico relacionados;
|
||
</para></listitem>
|
||
|
||
<listitem><para>Utilización de un teléfono celular o un
|
||
modem por un computador para recibir llamadas de datos.
|
||
</para></listitem>
|
||
</itemizedlist>
|
||
|
||
<para>El Acceso a Redes con perfiles PPP (LAN) se puede utilizar en las
|
||
siguientes situaciones:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem><para>Acceso LAN para un único dispositivo Bluetooth;
|
||
</para></listitem>
|
||
|
||
<listitem><para>Acceso LAN para múltiples dispositivos
|
||
Bluetooth;
|
||
</para></listitem>
|
||
|
||
<listitem><para>Conexión de PC a PC (utilizando
|
||
emulación de PPP sobre una línea serie).
|
||
</para></listitem>
|
||
</itemizedlist>
|
||
|
||
<para>En &os; ambos perfiles se implementan bajo las órdenes
|
||
&man.ppp.8; y &man.rfcomm.pppd.8;, un encapsulador que convierte la
|
||
conexión RFCOMM de Bluetooth en algo que puede ser utilizado
|
||
por PPP. Antes de que se puedan utilizar los perfiles se debe
|
||
definir una nueva etiqueta PPP en el fichero de configuración
|
||
<filename>/etc/ppp/ppp.conf</filename>. Consulte &man.rfcomm.pppd.8;
|
||
para ver algunos ejemplos.</para>
|
||
|
||
|
||
<para>En el siguiente ejemplo se va a utilizar &man.rfcomm.pppd.8; para
|
||
abrir una conexión RFCOMM con un dispositivo remoto con
|
||
BD_ADDR 00:80:37:29:19:a4 sobre un canal RFCOMM basado en DUN (Dial-Up
|
||
Networking). El número de canal RFCOMM se obtiene a partir del
|
||
dispositivo remoto a través de SDP. Es posible especificar el
|
||
canal RFCOMM a mano, en cuyo caso &man.rfcomm.pppd.8; no
|
||
realizará ninguna consulta SDP. Se puede utilizar la orden
|
||
&man.sdpcontrol.8; para descubrir el canal RFCOMM utilizado en el
|
||
dispositivo remoto.</para>
|
||
|
||
<screen>&prompt.root; <userinput>rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup</userinput></screen>
|
||
|
||
<para>Para proporcionar el servicio de Acceso a Redes a través de
|
||
PPP (LAN) se debe ejecutar el servidor &man.sdpd.8;. Se debe crear
|
||
una nueva entrada en <filename>/etc/ppp/ppp.conf</filename>. Le
|
||
rogamos que consulte &man.rfcomm.pppd.8; y observe los ejemplos que
|
||
se facilitan. Por último se debe ejecutar el servidor PPP
|
||
RFCOMM sobre un número de canal RFCOMM adecuado. El servidor
|
||
PPP RFCOMM registrará automáticamente el servicio LAN
|
||
de Bluetooth con el servidor SDP local. El ejemplo que se muestra a
|
||
continuación describe cómo ejecutar el servidor PPP
|
||
RFCOMM.</para>
|
||
|
||
<screen>&prompt.root; <userinput>rfcomm_pppd -s -C 7 -l rfcomm-server</userinput></screen>
|
||
|
||
</sect2>
|
||
|
||
<indexterm><primary>OBEX</primary></indexterm>
|
||
<sect2>
|
||
<title>Perfil OBEX Object Push (OPUSH)</title>
|
||
<para>OBEX es un protocolo muy utilizado para transferencias de ficheros
|
||
sencillas entre dispositivos móviles. Su uso más
|
||
importante se produce en comuncaciones por infrarrojos, donde se
|
||
utiliza para transferencia de ficheros genéricos entre
|
||
portátiles o dispositivos Palm y para enviar tarjetas de visita
|
||
o entradas de la agenda entre teléfonos celulares y otros
|
||
dispositivos con aplicaciones PIM.</para>
|
||
|
||
<para>El cliente y el servidor de OBEX se implementan como un paquete
|
||
denominado <application>obexapp</application> disponible como <quote>
|
||
port</quote> en
|
||
<filename role="package">comms/obexapp</filename>.</para>
|
||
|
||
<para>El cliente OBEX se utiliza para introducir y para recuperar
|
||
recuperar objetos del servidor OBEX. Un objeto puede por ejemplo ser
|
||
una tarjeta de visita o una cita. El cliente OBEX puede obtener un
|
||
número de canal RFCOMM del dispositivo remoto utilizando SDP.
|
||
Esto se hace especificando el nombre del servicio en lugar del
|
||
número de canal RFCOMM. Los nombres de servicios soportados
|
||
son: IrMC, FTRN y OPUSH. Es posible especificar el canal RFCOMM como
|
||
un número. A continuación se muestra un ejemplo de una
|
||
sesión OBEX donde el objeto que posee la información del
|
||
dispositivo se recupera del teléfono celular y un nuevo objeto
|
||
(la tarjeta de visita) se introduce en el directorio de dicho
|
||
teléfono.</para>
|
||
|
||
<screen>&prompt.user; <userinput>obexapp -a 00:80:37:29:19:a4 -C IrMC</userinput>
|
||
obex> get
|
||
get: remote file> telecom/devinfo.txt
|
||
get: local file> devinfo-t39.txt
|
||
Success, response: OK, Success (0x20)
|
||
obex> put
|
||
put: local file> new.vcf
|
||
put: remote file> new.vcf
|
||
Success, response: OK, Success (0x20)
|
||
obex> di
|
||
Success, response: OK, Success (0x20)</screen>
|
||
|
||
<para>Para proporcionar servicio de OBEX el servidor &man.sdpd.8; debe
|
||
estar en funcionamiento. Además se debe crear un directorio
|
||
raíz donde todos los objetos van a ser almacenados. La ruta
|
||
por defecto para el directorio raíz es <filename>
|
||
/var/spool/obex</filename>. Por último se debe ejecutar el
|
||
servidor OBEX en un número de canal RFCOMM válido. El
|
||
servidor OBEX registra automáticamente el servicio de Object
|
||
Push con el dæmon SDP local. El ejemplo que se muestra a
|
||
local. El ejemplo que se muestra a continuación
|
||
continuación describe cómo ejecutar el servidor
|
||
OBEX.</para>
|
||
|
||
<screen>&prompt.root; <userinput>obexapp -s -C 10</userinput></screen>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Perfil de puerto serie (SP) </title>
|
||
<para>El perfil de puerto serie (Serial Port o SP) permite que
|
||
dispositivos Bluetooth realicen emulación de RS232 (o
|
||
similar). El escenario cubierto por este perfil trata con
|
||
con aplicaciones comerciales que utilizan Bluetooth como un sustituto
|
||
sustituto del cable, utilizando una capa de abstracción que
|
||
representa un puerto serie virtual.</para>
|
||
|
||
<para>La aplicación &man.rfcomm.sppd.1; implementa el perfil
|
||
Puerto Serie. Usa una pseudo tty como abstracción de puerto
|
||
serie virtual. El ejemplo de más abajo muestra cómo
|
||
conectarse a un servicio de dispositivo remoto de Puerto Serie.
|
||
Observe que no necesita especificarse el canal RFCOMM:
|
||
&man.rfcomm.sppd.1; puede obtenerlo del dispotivo remoto via
|
||
SDP. Si necesita especificarlo por alguna razón
|
||
hágalo en la propia línea de órdenes.</para>
|
||
|
||
<screen>&prompt.root; <userinput>rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6</userinput>
|
||
rfcomm_sppd[94692]: Starting on /dev/ttyp6...</screen>
|
||
|
||
<para>Una vez conectado el pseudo tty se puede utilizar como un puerto
|
||
serie.</para>
|
||
|
||
<screen>&prompt.root; <userinput>cu -l ttyp6</userinput></screen>
|
||
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Solución de problemas</title>
|
||
|
||
<sect3>
|
||
<title>Un dispositivo remoto no puede conectarse</title>
|
||
|
||
<para>Algunos dispositivos Bluetooh antiguos no soportan el cambio de
|
||
cambio de roles. Por defecto,
|
||
roles. Cuando &os; acepta una nueva conexión por defecto
|
||
intenta realizar un cambio de rol y convertirse en maestro.
|
||
Dispositivos que no son capaces de realizar este cambio no pueden
|
||
conectarse. Es interesante resaltar que el cambio de roles se
|
||
realiza cuando se está estableciendo una nueva
|
||
conexión de tal forma que no es posible preguntar al
|
||
dispositivo si soporta intercambio de roles. Existe una
|
||
opción HCI para desactivar el intercambio de roles en la
|
||
parte local.</para>
|
||
|
||
<screen>&prompt.root; <userinput>hccontrol -n ubt0hci write_node_role_switch 0</userinput></screen>
|
||
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Algo va mal ¿puedo ver exactamente qué
|
||
está ocurriendo?</title>
|
||
<para>Sí, se puede. Utilice el paquete
|
||
<application>hcidump-1.5</application>, que se puede descargar de
|
||
<ulink
|
||
url="http://www.geocities.com/m_evmenkin/">aquí</ulink>.
|
||
La herramienta <application>hcidump</application> es similar a la
|
||
herramienta &man.tcpdump.1;. Se puede utilizar para mostrar el
|
||
contenido de los paquetes Bluetooth sobre el terminal y para volcar
|
||
los paquetes Bluetooth a un fichero.</para>
|
||
|
||
</sect3>
|
||
|
||
</sect2>
|
||
|
||
</sect1>
|
||
|
||
<sect1 id="network-bridging">
|
||
<sect1info>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Steve</firstname>
|
||
<surname>Peterson</surname>
|
||
<contrib>Escrito por </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
</sect1info>
|
||
<title>Puenteado</title>
|
||
|
||
<sect2>
|
||
<title>Introducción</title>
|
||
<indexterm><primary>IP subnet</primary></indexterm>
|
||
<indexterm><primary>bridge</primary></indexterm>
|
||
<para>Algunas veces resulta útil dividir una red física
|
||
(como por ejemplo un segmento Ethernet) en dos segmentos de red
|
||
separados, sin tener que crear subredes IP y sin utilizar una pasarela
|
||
para comunicar ambos segmentos. El dispositivo que realiza esta
|
||
función se denomina <quote>bridge</quote>. Un sistema FreeBSD
|
||
con dos interfaces de red puede actuar como un <quote>bridge</quote>
|
||
o puente entre ambas.</para>
|
||
|
||
<para>El <quote>bridge</quote> funciona de tal forma que aprende las
|
||
direcciones de la capa MAC (direcciones Ethernet) de los nodos que se
|
||
encuentran conectados a cada interfaz de red de tal forma que
|
||
sólo se reenvía tráfico entre los segmentos de
|
||
red cuando las direcciones fuente y destino se encuentran separadas en
|
||
segmentos distintos.</para>
|
||
|
||
<para>En varios aspectos se puede comparar un <quote>bridge</quote> con
|
||
un <quote>switch</quote> de pocos puertos.</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Situaciones donde el puenteado resulta adecuado</title>
|
||
|
||
<para>Existen al menos dos situaciones típicas donde se puede
|
||
utilizar la funcionalidad proporcionada por los <quote>
|
||
bridges</quote>.</para>
|
||
|
||
|
||
<sect3>
|
||
<title>Tráfico de gran volumen en un segmentos de red</title>
|
||
|
||
<para>La primera situación surge cuando nos encontramos con un
|
||
segmento de red congestionado pero por las razones que sean no
|
||
queremos subdividir la red e interconectar las nuevas subredes
|
||
mediante un <quote>route</quote>.</para>
|
||
|
||
<para>Vamos a considerar un ejemplo de un periódico donde los
|
||
departamentos editoriales y de producción utilizan la misma
|
||
subred. Los usuarios de la editorial utilizan el servidor
|
||
<hostid>A</hostid> como servidor de ficheros y los de
|
||
producción utilizan el servidor <hostid>B</hostid>. Se
|
||
Se utiliza una red Ethernet para conectar ambos departamentos y se
|
||
ha detectado que la alta utilización del enlace está
|
||
ralentizando el funcionamiento de la red.</para>
|
||
|
||
|
||
<para>Si los usuarios de la editorial pudieran agregarse en un
|
||
segmento de red mientras que los usuarios de producción se
|
||
localizaran en otro se podrían conectar ambos segmentos
|
||
mediante un <quote>bridge</quote>. Sólo se utilizará
|
||
el <quote>bridge</quote> para encaminar tráfico de red
|
||
destinado a interfaces que se encuentren en el <emphasis>
|
||
otro</emphasis> lado del <quote>bridge</quote>, reduciendo de esta
|
||
forma la congestión en cada nuevo segmento.</para>
|
||
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Cortafuegos de filtrado/conformación de tráfico
|
||
</title>
|
||
<indexterm><primary>firewall</primary></indexterm>
|
||
<indexterm><primary>network address
|
||
translation</primary></indexterm>
|
||
|
||
<para>La segunda situación típica se produce cuando se
|
||
necesita un cortafuegos pero no la Traducción de Direcciones
|
||
de Red (NAT).</para>
|
||
|
||
<para>A continuación se muestra un ejemplo. Una
|
||
pequeña compañía se comunica con su ISP
|
||
utilizando DSL o ISDN. Dicha compañía posee 13
|
||
13 direcciones IP globalmente accesibles delegadas por su ISP y tiene
|
||
10 ordenadores en funcionamiento. En esta situación un
|
||
un cortafuegos basado en un <quote>router</quote> resulta
|
||
difícil debido a la distribución del espacio de
|
||
direccionamiento disponible (subnetting).</para>
|
||
|
||
<indexterm><primary>router</primary></indexterm>
|
||
<indexterm><primary>DSL</primary></indexterm>
|
||
<indexterm><primary>ISDN</primary></indexterm>
|
||
<para>Un cortafuegos implementado sobre un <quote>bridge</quote> se
|
||
puede utilizar en el camino de bajado desde el ISP hasta las
|
||
oficinas de la compañía sin necesidad de tener en
|
||
cuenta ningún aspecto relacionado con la
|
||
distribución de las direcciones IP.</para>
|
||
|
||
</sect3>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Configuración de un <quote>bridge</quote></title>
|
||
|
||
<sect3>
|
||
<title>Selección de la interfaz de red</title>
|
||
|
||
<para>Un <quote>bridge</quote> necesita al menos dos tarjetas de red
|
||
situadas en dos segmentos de red para su funcionamiento. Por
|
||
desgracia no todas las interfaces de red pueden usarse para el
|
||
puenteo. Consulte &man.bridge.4;, ahín encontrará
|
||
más información sobre qué tarjetas puede
|
||
usar.</para>
|
||
|
||
<para>Por favor, instale y pruebe las dos tarjetas de red antes de
|
||
continuar.</para>
|
||
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Cambios en la configuración del núcleo</title>
|
||
<indexterm>
|
||
<primary>kernel options</primary>
|
||
<secondary>options BRIDGE</secondary>
|
||
</indexterm>
|
||
|
||
<para>Para activar el soporte de <quote>bridging</quote> en el
|
||
núcleo añada</para>
|
||
|
||
<programlisting>options BRIDGE</programlisting>
|
||
|
||
<para>al fichero de configuración del núcleo y
|
||
recompile el kernel.</para>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Soporte de cortafuegos</title>
|
||
<indexterm><primary>firewall</primary></indexterm>
|
||
<para>Si se desea utilizar el <quote>bridge</quote> como un
|
||
cortafuegos, se debe añadir además la opción
|
||
<literal>IPFIREWALL</literal>. Lea el capílo de
|
||
firewalls <!--<xref linkend="firewalls">--> para obtener
|
||
información general sobre cómo configurar el
|
||
bridge para que actúe además como cortafuegos.</para>
|
||
|
||
<para>Si además queremos que los paquetes que no sean IP (por
|
||
ejemplo paquetes ARP) puedan atravesar el <quote>bridge</quote>
|
||
deberemos añadir la opción
|
||
<literal>IPFIREWALL_DEFAULT_TO_ACCEPT</literal>. Tenga en cuenta
|
||
opción modifica el comportamiento del cortafuegos de tal
|
||
forma que por defecto aceptará cualquier paquete. Hay que
|
||
tener cuidado para asegurarse de que el comportamiento esperado del
|
||
cortafuegos, que reside en el conjunto de reglas que se hayan
|
||
definido, no se vea afectado por este cambio.</para>
|
||
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Soporte de conformado de tráfico</title>
|
||
|
||
<para>Si se quiere utilizar el <quote>bridge</quote> como un
|
||
conformador de tráfico, es decir, como un elemento capaz de
|
||
adaptar los distintos flujos según determinados patrones, se
|
||
debe añadir la opción
|
||
<literal>DUMMYNET</literal> a la configuración del
|
||
núcleo. Se ruega consultar &man.dummynet.4; para obtener
|
||
más información al respecto.</para>
|
||
|
||
</sect3>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Cómo activar el <quote>bridge</quote></title>
|
||
|
||
<para>Añadir la línea:</para>
|
||
|
||
<programlisting>net.link.ether.bridge=1</programlisting>
|
||
|
||
<para>en <filename>/etc/sysctl.conf</filename> para habilitar el
|
||
soporte de <quote>bridging</quote> en tiempo de ejecución y la
|
||
línea:</para>
|
||
|
||
<programlisting>net.link.ether.bridge_cfg=<replaceable>if1</replaceable>,<replaceable>if2</replaceable></programlisting>
|
||
|
||
<para>Para activar el <quote>bridging</quote> en las interfaces
|
||
especificadas (sustituya
|
||
<replaceable>if1</replaceable> y
|
||
<replaceable>if2</replaceable> con los nombres de sus interfaces de
|
||
red). Si deseamos filtrar los paquetes puenteados utilizando
|
||
&man.ipfw.8;, debemos añadir también:</para>
|
||
|
||
<programlisting>net.link.ether.bridge_ipfw=1</programlisting>
|
||
|
||
<para>En &os; 5.2-RELEASE y posteriores, se debe utilizar las
|
||
siguientes líneas en lugar de las anteriores:</para>
|
||
|
||
<programlisting>net.link.ether.bridge.enable=1
|
||
net.link.ether.bridge.config=<replaceable>if1</replaceable>,<replaceable>if2</replaceable>
|
||
net.link.ether.bridge.ipfw=1</programlisting>
|
||
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Información adicional</title>
|
||
|
||
<para>Si queremos ser capaces de conectarnos al <quote>bridge</quote>
|
||
mediante &man.telnet.1; se puede asignar una dirección IP a
|
||
una de las tarjetas de red del <quote>bridge</quote>. Por amplio
|
||
consenso se considera una mala idea asignar más de una
|
||
dirección IP al <quote>bridge</quote>.</para>
|
||
|
||
<para>Si poseemos varios <quote>bridges</quote> en nuestra red
|
||
sólamente puede existir un único camino entre
|
||
cualesquiera dos máquinas de nuestra red.
|
||
Técnicamente hablando esto significa que no existe soporte para
|
||
gestión de enlace mediante mecanismos basados en
|
||
árboles de recubrimiento mínimos (<quote>spanning
|
||
tree</quote>).</para>
|
||
|
||
<para>Un <quote>bridge</quote> puede añadir latencia a los tiempos
|
||
de respuesta de la orden &man.ping.8;, especialmente cuando
|
||
el tráfico tiene que viajar de un segmento de red al
|
||
otro.</para>
|
||
|
||
</sect2>
|
||
</sect1>
|
||
|
||
<sect1 id="network-nfs">
|
||
<sect1info>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Tom</firstname>
|
||
<surname>Rhodes</surname>
|
||
<contrib>Reorganizado y ampliado por </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Bill</firstname>
|
||
<surname>Swingle</surname>
|
||
<contrib>Escrito por </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
</sect1info>
|
||
<title>NFS</title>
|
||
|
||
<indexterm><primary>NFS</primary></indexterm>
|
||
<para>FreeBSD soporta diversos sistemas de ficheros, uno de los
|
||
cuales es el Sistema de Ficheros en Red, tambíen conocido
|
||
por su acrónimo en inglés <acronym>NFS</acronym>.
|
||
<acronym>NFS</acronym> permite compartir directorios y ficheros a
|
||
través de la red. Los usuarios del sistema <acronym>
|
||
NFS</acronym> pueden acceder a ficheros que se encuentran
|
||
físicamente en máquinas remotas de una forma
|
||
transparente, como si se tratara de ficheros locales.</para>
|
||
|
||
<para>He aquí algunos los beneficios más destacados que
|
||
<acronym>NFS</acronym> proporciona:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Las estaciones de trabajo locales utilizan menos espacio de
|
||
disco debido a que los datos se encuentran centralizados en un
|
||
único lugar pero pueden ser accedidos y modificados por
|
||
varios usuarios, de tal forma que no es necesario replicar la
|
||
información.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Los usuarios no necesitan disponer de un directorio <quote>
|
||
home</quote> en cada una de las máquinas de la
|
||
organización. Los directorios <quote>home</quote> pueden
|
||
crearse en el servidor de <acronym>NFS</acronym> para posteriormente
|
||
poder acceder a ellos desde cualquier máquina a través
|
||
de la infraestrutura de red.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>También se pueden compartir a través de la red
|
||
dispositivos de almacenamiento como disqueteras, CDROM y unidades
|
||
ZIP. Esto puede reducir la inversión en dichos dispositivos
|
||
y mejorar el aprovechamiento del hardware existente en la
|
||
organización.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<sect2>
|
||
<title>Cómo funciona <acronym>NFS</acronym></title>
|
||
|
||
<para>El sistema <acronym>NFS</acronym> está dividido al menos en
|
||
dos partes principales: un servidor y uno o más clientes.
|
||
Los clientes acceden de forma remota a los datos que se encuentran
|
||
almacenados en el servidor. Para que el sistema funcione
|
||
correctamente se deben configurar y ejecutar unos cuantos
|
||
procesos.</para>
|
||
|
||
<note><para>En &os; 5.X se ha reemplazado <application>
|
||
portmap</application> por <application>rpcbind</application>.
|
||
de esta forma para los ejemplos que vamos a comentar a
|
||
continuación se recuerda que en &os; 5.X se debe reemplazar
|
||
cualquier instancia de <application>portmap</application> por
|
||
<application>rpcbind</application>.</para></note>
|
||
|
||
<para>El servidor de <acronym>NFS</acronym> debe ejecutar los siguientes
|
||
dæmones:</para>
|
||
<indexterm>
|
||
<primary>NFS</primary>
|
||
<secondary>server</secondary>
|
||
</indexterm>
|
||
<indexterm>
|
||
<primary><application>portmap</application></primary>
|
||
</indexterm>
|
||
<indexterm>
|
||
<primary><application>mountd</application></primary>
|
||
</indexterm>
|
||
<indexterm>
|
||
<primary><application>nfsd</application></primary>
|
||
</indexterm>
|
||
|
||
<informaltable frame="none">
|
||
<tgroup cols="2">
|
||
<thead>
|
||
<row>
|
||
<entry>Dæmon</entry>
|
||
<entry>Descripción</entry>
|
||
</row>
|
||
</thead>
|
||
<tbody>
|
||
<row>
|
||
<entry><application>nfsd</application></entry>
|
||
<entry>El dæmon<acronym>NFS</acronym>, que atiende
|
||
peticiones de clientes <acronym>NFS</acronym>.</entry>
|
||
|
||
</row>
|
||
<row>
|
||
<entry><application>mountd</application></entry>
|
||
<entry>El dæmon de montaje de <acronym>NFS</acronym>,
|
||
que transporta las peticiones que &man.nfsd.8; realiza.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><application>portmap</application></entry>
|
||
<entry> El dæmon portmapper permite que los clientes
|
||
<acronym>NFS</acronym> puedan descubrir qué puerto
|
||
está utilizando el servidor de
|
||
<acronym>NFS</acronym>.</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</informaltable>
|
||
|
||
<para>El cliente también puede ejecutar un dæmon conocido ,
|
||
como <application>nfsiod</application>. El dæmon
|
||
<application>nfsiod</application> atiende las peticiones provinientes
|
||
del servidor <acronym>NFS</acronym>. Este dæmon es opcional y
|
||
sirve para mejorar el rendimiento pero no es necesario para el
|
||
funcionamiento correcto del sistema. Se recomienda consultar
|
||
&man.nfsiod.8; para obtener más información.</para>
|
||
|
||
</sect2>
|
||
|
||
<sect2 id="network-configuring-nfs">
|
||
<title>Configuración de <acronym>NFS</acronym></title>
|
||
<indexterm>
|
||
<primary>NFS</primary>
|
||
<secondary>configuration</secondary>
|
||
</indexterm>
|
||
|
||
<para>La configuración de <acronym>NFS</acronym> es un proceso
|
||
relativamente sencillo. Para que los procesos anteriormente descritos
|
||
se ejecuten en tiempo de arranque del sistema, basta con realizar
|
||
paqueñas modificaciones en <filename>/etc/rc.conf</filename>.
|
||
</para>
|
||
|
||
<para>En <filename>/etc/rc.conf</filename> del servidor de
|
||
<acronym>NFS</acronym> se deben configurar las siguientes opciones:</para>
|
||
|
||
<programlisting>portmap_enable="YES"
|
||
nfs_server_enable="YES"
|
||
mountd_flags="-r"</programlisting>
|
||
|
||
<para><application>mountd</application> se ejecuta
|
||
automáticamente cuando se activa el servidor
|
||
<acronym>NFS</acronym>.</para>
|
||
|
||
<para>En el cliente debemos asegurarnos de que se encuentra activada la
|
||
activada la siguiente opción dentro de <filename>
|
||
/etc/rc.conf</filename>:</para>
|
||
|
||
<programlisting>nfs_client_enable="YES"</programlisting>
|
||
|
||
<para>El archivo <filename>/etc/exports</filename> especifica los
|
||
directorios o sistemas de ficheros que <acronym>NFS</acronym> exporta
|
||
al exterior. Cada línea dentro de <filename>
|
||
/etc/exports/</filename> especifia un sistema de ficheros y qué
|
||
máquinas tienen derechos de acceso sobre dicho sistema.
|
||
Además de los derechos de acceso se pueden definir otras
|
||
opciones de acceso, tales como solo lectura o lectura y escritura.
|
||
Existen multitud de opciones que pueden definirse sobre un directorio
|
||
exportable pero en este manual sólo se van a comentar unas
|
||
pocas. Consulte &man.exports.5; para obtener una descripción
|
||
más detallada.</para>
|
||
|
||
<para>Aquí se muestran algunos ejemplos de entradas para
|
||
<filename>/etc/exports</filename>:</para>
|
||
|
||
<indexterm>
|
||
<primary>NFS</primary>
|
||
<secondary>export examples</secondary>
|
||
</indexterm>
|
||
|
||
<para>El siguiente ejemplo proporciona una idea de cómo exportar
|
||
sistemas de ficheros, aunque los parámetros pueden diferir
|
||
dependiendo de su entorno y su configuración de red. En dicho
|
||
ejemplo, se exporta el directorio <filename>/cdromm</filename> a tres
|
||
máquinas que se encuentran en el mismo dominio que el servidor
|
||
(de ahí que no se especifique ningún nombre de dominio
|
||
para cada máquina) o que pueden estar dadas de alta en
|
||
<filename>/etc/hosts</filename>. En cualquier caso la opción
|
||
<option>-ro</option> configura el sistema de ficheros de red como
|
||
<quote>sólo lectura</quote> (<quote>read-only</quote>).
|
||
Con esta opción los sistemas remotos no serán capaces
|
||
de realizar cambios sobre el sistema de ficheros exportados.</para>
|
||
|
||
<programlisting>/cdrom -ro host1 host2 host3</programlisting>
|
||
|
||
<para>La siguiente línea exporta el directorio
|
||
<filename>/home</filename> a tres máquinas utilizando
|
||
direcciones IP. Esto resulta útil cuando disponemos de una red
|
||
privada pero no disponemos de ningún servidor de
|
||
<acronym>DNS</acronym> configurado. También se podría
|
||
configurar <filename>/etc/hosts</filename> para que resolviera
|
||
nombres de máquinas internos; consulte &man.hosts.5; para
|
||
obtener más información al respecto. La opción
|
||
<option>-alldirs</option> permite que los subdirectorios del
|
||
directorio <filename>/home</filename> tambíen se puedan utilizar
|
||
como puntos de montaje. En otras palabras, esto permite que los
|
||
clientes puedan trabajar sobre los subdirectorios en los que
|
||
estén realmente interesados.</para>
|
||
|
||
<programlisting>/home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4</programlisting>
|
||
|
||
<para>La siguiente línea exporta el directorio
|
||
<filename>/a</filename> de tal forma que puedan acceder a dicho
|
||
directorio dos máquinas situadas en distintos dominios. La
|
||
opción <option>-maproot=root</option> permite que el usuario
|
||
<username>root</username> de la máquina cliente modifique los
|
||
datos del sistema de ficheros en red como si fuera el usuario
|
||
<username>root</username> del servidor. Si no se especifica la
|
||
opción <option>-maproot=root</option> el usuario
|
||
<username>root</username> del cliente puede no poseer los permisos
|
||
necesarios para realizar modificaciones en el sistema de
|
||
ficheros.</para>
|
||
|
||
<programlisting>/a -maproot=root host.example.com box.example.org</programlisting>
|
||
|
||
<para>Para que un cliente pueda acceder al sistema de ficheros exportado
|
||
debe poseer permisos para ello. Debemos asegurarnos de que el cliente
|
||
se encuentra listado en <filename>/etc/exports</filename>.</para>
|
||
|
||
<para>Dentro de <filename>/etc/exports</filename> cada línea
|
||
representa información de exportación de un sistema de
|
||
ficheros para un determinado conjunto de máquinas. Una
|
||
máquina sólo puede aparecer una vez dentro de un
|
||
sistema de ficheros exportable y el archivo sólo puede tener
|
||
una única entrada por defecto. Por ejemplo, si suponemos que
|
||
<filename>/usr</filename> es un único sistema de ficheros la
|
||
siguiente configuración de <filename>/etc/exports</filename>
|
||
sería incorrecta:</para>
|
||
|
||
<programlisting>/usr/src client
|
||
/usr/ports client</programlisting>
|
||
|
||
<para>Existe un sistema de ficheros, concretamente
|
||
<filename>/usr</filename>, que posee dos líneas con reglas de
|
||
exportación para la misma máquina,
|
||
<hostid>client</hostid>. El formato correcto para esta
|
||
situación sería el siguiente:</para>
|
||
|
||
<programlisting>/usr/src /usr/ports client</programlisting>
|
||
|
||
<para>Las propiedades de un sistemas de ficheros que se exporta al
|
||
exterior deben aparecer agrupadas bajo la misma línea.
|
||
Líneas que no poseen ningún cliente se tratan como si
|
||
tuvieran una única máquina. Esto limita la forma en que
|
||
pueden configurarse la exportaciones de sistemas de ficheros pero para
|
||
la mayoría de la gente no suele ser un problema.</para>
|
||
|
||
<para>El ejemplo que se muestra a continuación es una muestra de
|
||
una lista de exportación correcta, donde <filename>
|
||
/usr</filename> y <filename>/exports</filename> son sistemas de
|
||
ficheros locales:</para>
|
||
|
||
<programlisting># Exportar src y ports a cliente01 y cliente02, pero
|
||
# solo el cliente01 tiene acceso root
|
||
/usr/src /usr/ports -maproot=root cliente01
|
||
/usr/src /usr/ports cliente02
|
||
# Las maquinas cliente tienen acceso root y pueden montar todo lo que aparezca
|
||
# en /exports. Cualquier sistema puede montar /exports/obj en modo
|
||
# solo lectura
|
||
/exports -alldirs -maproot=root cliente01 cliente02
|
||
/exports/obj -ro</programlisting>
|
||
|
||
<para>Se debe reiniciar el dæmon <application>mountd</application>
|
||
siempre que se modifique el contenido del archivo
|
||
<filename>/etc/exports</filename> para que los cambios surtan efecto.
|
||
Esto se realiza enviando la señal HUP al proceso
|
||
<command>mountd</command>:</para>
|
||
|
||
<screen>&prompt.root; <userinput>kill -HUP `cat /var/run/mountd.pid`</userinput></screen>
|
||
|
||
<para>También se puede reiniciar FreeBSD para que se cargue la
|
||
nueva configuración pero este mecanismo no resulta necesario
|
||
si se ejecutan las órdenes como
|
||
<username>root</username>, que ponen el servidor de
|
||
<acronym>NFS</acronym> de nuevo en funcionamiento.</para>
|
||
|
||
<para>En el servidor de <acronym>NFS</acronym>:</para>
|
||
|
||
<screen>&prompt.root; <userinput>portmap</userinput>
|
||
&prompt.root; <userinput>nfsd -u -t -n 4</userinput>
|
||
&prompt.root; <userinput>mountd -r</userinput></screen>
|
||
|
||
<para>En el cliente de <acronym>NFS</acronym>:</para>
|
||
|
||
<screen>&prompt.root; <userinput>nfsiod -n 4</userinput></screen>
|
||
|
||
<para>En este punto todo debería estar preparado para
|
||
poder anclar el sistema de ficheros remoto en la máquina
|
||
cliente. En los siguientes ejemplos el nombre del servidor es
|
||
<hostid>server</hostid> y el punto de montaje temporal utilizado
|
||
por el cliente es <hostid>client</hostid>. Si se desea montar el
|
||
sistema de ficheros de forma temporal o simplemente comprobar que la
|
||
configuración funciona sin problemas se puede ejecutar una
|
||
orden como la que se muestra a continuación con permisos
|
||
de <username>root</username> en la máquina cliente:</para>
|
||
|
||
<indexterm>
|
||
<primary>NFS</primary>
|
||
<secondary>mounting</secondary>
|
||
</indexterm>
|
||
<screen>&prompt.root; <userinput>mount server:/home /mnt</userinput></screen>
|
||
|
||
<para>Esta orden ancla el directorio
|
||
<filename>/home</filename> del servidor en el directorio
|
||
<filename>/mnt</filename> del cliente. Si todo funciona correctamente
|
||
debería poder entrar en el directorio
|
||
<filename>/mnt</filename> del cliente y ver todos los ficheros que se
|
||
encuentran en el directorio <filename>/home</filename> del servidor.
|
||
</para>
|
||
|
||
<para>Si queremos anclar automáticamente un sistema de ficheros
|
||
remoto cuando la máquina está arrancando se puede
|
||
añadir una línea como la siguiente dentro de
|
||
<filename>/etc/fstab</filename>:</para>
|
||
|
||
<programlisting>servidor:/home /mnt nfs rw 0 0</programlisting>
|
||
|
||
<para>&man.fstab.5; comenta todas las opciones disponibles.</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Usos prácticos</title>
|
||
|
||
<para>El protocolo <acronym>NFS</acronym> tiene múltiples usos
|
||
prácticos. Los más típicos se enumeran a
|
||
continuación:</para>
|
||
|
||
<indexterm>
|
||
<primary>NFS</primary>
|
||
<secondary>uses</secondary>
|
||
</indexterm>
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Compartición de la unidad de CDROM entre varias
|
||
máquinas. Esto resulta ser más barato y una forma
|
||
más conveniente para instalar software en varias
|
||
máquinas.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>En grandes redes puede ser más adecuado configurar un
|
||
servidor central de <acronym>NFS</acronym> en el cual se
|
||
almacenen todos los <quote>homes</quote> de los distintos
|
||
usuarios. Estos directorios se pueden exportar a través de
|
||
la red de tal forma que los usuarios pueden trabajar con el mismo
|
||
directorio independientemente de la máquina que utilicen.
|
||
</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Varias máquinas pueden poseer el directorio
|
||
<filename>/usr/ports/distfiles</filename> compartido. De
|
||
este modo cuando necesitemos instalar un port en varias
|
||
máquinas, se puede acceder rápidamente a las fuentes
|
||
sin necesidad de bajarlas una vez para cada máquina.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</sect2>
|
||
|
||
<sect2 id="network-amd">
|
||
<sect2info>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Wylie</firstname>
|
||
<surname>Stilwell</surname>
|
||
<contrib>Escrito por </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Chern</firstname>
|
||
<surname>Lee</surname>
|
||
<contrib>Reescrito por </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
</sect2info>
|
||
<title>Anclajes automáticos usando <application>amd</application></title>
|
||
|
||
<indexterm><primary>amd</primary></indexterm>
|
||
<indexterm><primary>automatic mounter daemon</primary></indexterm>
|
||
|
||
<para>El dæmon &man.amd.8; (<quote>the automatic mounter
|
||
daemon</quote>, o dæmon de montaje automático)
|
||
automáticamente ancla un sistema de ficheros remoto cuando se
|
||
tiene que acceder a un fichero perteneciente a dicho sistema. Los
|
||
sistemas de ficheros que permanecen inactivos durante un determinado
|
||
periodo de tiempo son automáticamente desmontados por el mismo
|
||
dæmon. Este dæmon proporciona una alternativa sencilla a
|
||
la utilización de los montajes permanentes que normalmente se
|
||
especifican a través del fichero <filename>
|
||
/etc/fstab</filename>.</para>
|
||
|
||
<para><application>amd</application> trabaja actuando como un servidor
|
||
servidor de NFS para los directorios
|
||
<filename>/host</filename> y <filename>/net</filename>. Cuando se
|
||
accede a algún fichero ubicado bajo estos directorios
|
||
<application>amd</application> busca el punto de montaje remoto y
|
||
automáticamente lo monta. El directorio <filename>
|
||
/net</filename> se utiliza para anclar sistemas de ficheros remotos
|
||
especificados mediante direcciones IP, mientras que el directorio
|
||
<filename>/host</filename> almacena aquellos sistemas de ficheros
|
||
remotos que han sido especificados mediante un nombre de
|
||
máquina.</para>
|
||
|
||
<para><application>amd</application> detecta cualquier intento
|
||
de acceder a un fichero dentro del directorio
|
||
<filename>/host/foobar/usr</filename> y se encarga de montar
|
||
el sistema de ficheros remoto (<filename>/usr</filename>)
|
||
en la máquina, en caso de que no estuviera ya
|
||
anclado.</para>
|
||
|
||
<example>
|
||
<title>Anclaje de una exportación utilizando
|
||
<application>amd</application></title>
|
||
|
||
<para><command>showmount</command> muestra los
|
||
puntos de montaje que posee una máquina remota. Por ejemplo
|
||
para conocer los montajes de un máquina llamada
|
||
<hostid>foobar</hostid>, se puede utilizar:</para>
|
||
|
||
<screen>&prompt.user; <userinput>showmount -e foobar</userinput>
|
||
Exports list on foobar:
|
||
/usr 10.10.10.0
|
||
/a 10.10.10.0
|
||
&prompt.user; <userinput>cd /host/foobar/usr</userinput></screen>
|
||
</example>
|
||
|
||
<para>Como se observa en el ejemplo,
|
||
<command>showmount</command> muestra el directorio
|
||
<filename>/usr</filename>
|
||
como una exportación. Cuando se cambia el directorio actual
|
||
al directorio <filename>/host/foobar/usr</filename> el dæmon
|
||
<application>amd</application> intenta resolver el nombre
|
||
<hostid>foobar</hostid> y automáticamente ancla el sistema
|
||
de ficheros remoto.</para>
|
||
|
||
<para>El dæmon <application>amd</application> se puede ejecutar
|
||
a partir de los scripts de inicio, utilizando la siguiente
|
||
línea del archivo de configuración
|
||
<filename>/etc/rc.conf</filename>:</para>
|
||
|
||
<programlisting>amd_enable="YES"</programlisting>
|
||
|
||
<para>Además, <application>amd</application> soporta opciones
|
||
adicionales que pueden definirse mediante la variable
|
||
<varname>amd_flags</varname>. Por defecto, la variable
|
||
<varname>amd_flags</varname> posee las siguientes opciones:</para>
|
||
|
||
<programlisting>amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map"</programlisting>
|
||
|
||
<para>El archivo <filename>/etc/amd.map</filename> define las opciones
|
||
por defecto con las cuales se anclan los sistemas de ficheros
|
||
remotos. El archivo <filename>/etc/amd.conf</filename> define algunas
|
||
características avanzadas para el dæmon
|
||
<application>amd</application>.</para>
|
||
|
||
<para>Se ruega consultar las páginas del manual de &man.amd.8; y
|
||
de &man.amd.conf.5; para obtener más información.</para>
|
||
</sect2>
|
||
|
||
<sect2 id="network-nfs-integration">
|
||
<sect2info>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>John</firstname>
|
||
<surname>Lind</surname>
|
||
<contrib>Escrito por </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
</sect2info>
|
||
<title>Problemas de integración con otras plataformas</title>
|
||
|
||
<para>Determinados adaptadores Ethernet para sistemas basados en
|
||
el bus ISA poseen restricciones que pueden producir serios problemas
|
||
de red, en particular con el protocolo NFS. Estos problemas no son
|
||
específicos de FreeBSD, pero los sistemas &os; se ven
|
||
afectados por ellos.</para>
|
||
|
||
<para>El problema surge casi siempre cuando el sistema (&os;)
|
||
está empotrado dentro de una red compuesta por estaciones de
|
||
trabajo de alto rendimiento, como por ejemplo estaciones de Silicon
|
||
Graphics y de Sun Microsystems. El montaje del sistema de ficheros
|
||
remoto suele funcionar perfectamente y algunas operaciones sobre el
|
||
el sistema de ficheros pueden tener é,xito pero de repente el
|
||
el servidor que no responde a las peticiones del cliente, aunque
|
||
peticiones y respuestas de otros clientes funcionan con normalidad y
|
||
se continúan procesando. Esto sucede en los sistemas clientes,
|
||
tanto en sistemas FreeBSD como en otras estaciones de trabajo.
|
||
En muchos sistemas, lo único que se puede hacer es resetear
|
||
la máquina de forma abrupta, ya que el bloqueo producido por el
|
||
protocolo NFS no se puede solucionar.</para>
|
||
|
||
<para>Aunque la solución <quote>correcta</quote> consiste en
|
||
obtener un adaptador Ethernet con mayor rendimiento y capacidad,
|
||
todavía se puede aplicar un parche sencillo que puede llegar a
|
||
permitir un funcionamiento sin problemas. Si el sistema FreeBSD
|
||
actúa como servidor de <emphasis>NFS</emphasis> se puede
|
||
incluír la opción <option>w=1024</option> cuando el
|
||
ejecute una petición de montaje sobre dicho servidor. Si &os;
|
||
dicho servidor. Si &os; actúa como cliente de
|
||
<emphasis>NFS</emphasis>, se puede ejecutar &man.mount.8; con el
|
||
parámetro <option>-r=1024</option>. Estas opciones se pueden
|
||
especificar en el <filename>/etc/fstab</filename> del cliente para que
|
||
entren en funcionamiento cuando se realicen montajes
|
||
automáticos y también se puede utilizar el
|
||
parámetro <option>-o</option> de &man.mount.8; cuando se
|
||
realicen montajes manuales.</para>
|
||
|
||
<para>Resulta apropiado resaltar que existe un problema totalmente
|
||
distinto que algunas veces se confunde con el que acabamos de
|
||
describir, que aparece cuando el servidor y los clientes se encuentran
|
||
en redes diferentes. Si nos encontramos en esta situación
|
||
debemos <emphasis>asegurarnos</emphasis> de que nuestros <quote>
|
||
routers</quote> están encaminando correctamente los paquetes
|
||
UDP que genera el protocolo <acronym>NFS</acronym> pues en caso
|
||
contrario el sistema no funcionará, independientemente de los
|
||
ajustes que se realicen en el cliente o en el servidor.</para>
|
||
|
||
<para>En los siguientes ejemplos <hostid>fastws</hostid> es el nombre de
|
||
una estación de trabajo de altas prestaciones y <hostid>
|
||
freebox</hostid> es el nombre de un sistema &os; con un adaptador
|
||
Ethernet de bajas prestaciones. Se pretende además exportar el
|
||
directorio <filename>/sfcompartido</filename> (ver &man.exports.5;) y
|
||
el directorio <filename>/projecto</filename>. Tenga en cuenta que en
|
||
cualquier caso puede resultar útil definir opciones adicionales
|
||
a las que que se muestran en el siguiente ejemplo, como pueden ser
|
||
<option>hard</option>, <option>soft</option> o
|
||
<option>bg</option>. Esto dependerá de la aplicación
|
||
que utilice el sistema de ficheros remoto.</para>
|
||
|
||
<para>Ejemplos de configuración para el sistema &os;
|
||
(<hostid>freebox</hostid>) que actúa como cliente.
|
||
Configuración del archivo
|
||
<filename>/etc/fstab</filename> de
|
||
<hostid>freebox</hostid>:</para>
|
||
|
||
<programlisting>fastws:/sfcompartido /projecto nfs rw,-r=1024 0 0</programlisting>
|
||
|
||
<para>Orden de ejecución manual para
|
||
<hostid>freebox</hostid>:</para>
|
||
|
||
<screen>&prompt.root; <userinput>mount -t nfs -o -r=1024 fastws:/sfcompartido /projecto</userinput></screen>
|
||
|
||
<para>Ejemplos de configuración para el sistema &os; que
|
||
actúa como servidor. Configuración de
|
||
<filename>/etc/fstab</filename> de <hostid>fastws</hostid>:</para>
|
||
|
||
<programlisting>freebox:/sfcompartido /projecto nfs rw,-w=1024 0 0</programlisting>
|
||
|
||
<para>Orden de ejecución manual para
|
||
<hostid>fastws</hostid>:</para>
|
||
|
||
<screen>&prompt.root; <userinput>mount -t nfs -o -w=1024 freebox:/sfcompartido /projecto</userinput></screen>
|
||
|
||
<para>Casi cualquier adaptador Ethernet de 16 bits permite operar sin
|
||
operar sin las restricciones anteriores sobre el tamaño de
|
||
lectura o escritura especificado por defecto.</para>
|
||
|
||
<para>Por si alguien estuviera interesado a continuación se
|
||
muestra el error que aparece en estos casos, lo cual explica por
|
||
qué decimos que el error resulta irrecuperable. NFS trabaja
|
||
típicamente con un tamaño de <quote>bloque</quote>
|
||
de 8 K (aunque se pueden producir fragmentos de menor
|
||
tamaño). Debido a que el máximo tamaño de los
|
||
paquetes Ethernet se encuentra alrededor de los 1500 bytes el
|
||
<quote>bloque</quote> de NFS se trocea en varios paquetes Ethernet
|
||
aunque desde el punto de vista del protocolo NFS se trata como si
|
||
fuese un único paquete. Los trozos deben reensamblarse en el
|
||
destino y se debe enviar una <emphasis>confirmación</emphasis>
|
||
para el bloque recibido. Las estaciones de trabajo de altas
|
||
prestaciones pueden soltar paquetes NFS de forma contínua uno
|
||
después de otro, lo más juntos posible. Por otro lado
|
||
en las tarjetas de red más pequeñas y de menor
|
||
capacidad puede ocurrir que un paquete recien llegado a la tarjeta
|
||
sobreescriba información perteneciente a un paquete anterior
|
||
antes de que llegue a ser transmitido completamente, de tal forma que
|
||
al recibirse el bloque NFS no puede ser ni reconstruido ni
|
||
ni reconocido. Como resultado de este proceso la máquina
|
||
tratará de enviar el mismo paquete transcurridos unos instantes
|
||
de espera, pero se tratarán de enviar de nuevo los 8 K
|
||
que constituyen un bloque NFS, y de esta forma se repetirá el
|
||
el proceso, así hasta el infinito.</para>
|
||
|
||
<para>Si se mantiene el tamaño del bloque por debajo del
|
||
tamaño de paquete máximo de Ethernet, podemos asegurar
|
||
que cualquier paquete Ethernet transporta un bloque NFS, el cual
|
||
puede asentirse individualmente, evitando así la
|
||
explosión de paquetes y el eventual bloqueo del sistema.</para>
|
||
|
||
<para>Desbordamientos circulares del <quote>buffer</quote> (<quote>
|
||
overruns</quote>) pueden producirse si nos encontramos con una
|
||
estación de trabajo de altas prestaciones que envía
|
||
contínuamente mucho tráfico a un sistema convencional,
|
||
pero con tarjetas Ethernet de buena calidad, estos desbordamientos
|
||
resultan altamente improbables para el caso de los tamaños de
|
||
bloque por defecto generados por el sistema NFS. Cuando se produce un
|
||
desbordamiento, las unidades afectadas se retransmiten, y
|
||
existe una gran probabilidad de que se reciban, se reensamblen
|
||
y se confirmen.</para>
|
||
</sect2>
|
||
</sect1>
|
||
|
||
<sect1 id="network-diskless">
|
||
<sect1info>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Jean-François</firstname>
|
||
<surname>Dockès</surname>
|
||
<contrib>Actualizado por </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Alex</firstname>
|
||
<surname>Dupre</surname>
|
||
<contrib>Reorganizado y ampliado por </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
</sect1info>
|
||
<title>Ejecución sin disco duro</title>
|
||
|
||
<indexterm><primary>diskless workstation</primary></indexterm>
|
||
<indexterm><primary>diskless operation</primary></indexterm>
|
||
|
||
<para>Una máquina &os; se puede arrancar a través
|
||
de la red y operar sin que necesite poseer ningún disco,
|
||
utilizando sistemas de ficheros de un servidor de
|
||
<acronym>NFS</acronym>. No se necesita realizar ninguna
|
||
modificación al sistema, salvo configurar determinados ficheros.
|
||
Este tipo de sistemas se pueden configurar fácilmente puesto
|
||
que &os; dispone de todos los elementos necesarios:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Existen al menos dos formas de cargar el núcleo
|
||
del sistema operativo a través de la red:</para>
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para><acronym>PXE</acronym>: El sistema de &intel; conocido como
|
||
Preboot Execution Environment. Se trata de una especie de
|
||
arranque inteligente a partir de una memoria de sólo
|
||
lectura (ROM) que se encuentra en algunas placas bases y
|
||
tarjetas de red. Se puede obtener más información
|
||
en &man.pxeboot.8;.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>El port <application>etherboot</application>
|
||
(<filename role="package">net/etherboot</filename>)
|
||
genera código de sólo lectura (código ROM)
|
||
que se puede utilizar para arrancar máquinas a
|
||
través de la red. Dicho código se puede instalar
|
||
en una memoria de arranque tipo PROM en algunas tarjetas de red
|
||
o se puede cargar en una disquetera (o disco duro), y
|
||
también en un sistema de ficheros &ms-dos; que
|
||
esté en ejecución. Varias tarjetas de red soportan
|
||
este mecanismo.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Existe un script de ejemplo
|
||
(<filename>/usr/share/examples/diskless/clone_root</filename>) que
|
||
facilita la creación y el mantenimiento del sistema de
|
||
ficheros raíz de la estación de trabajo en el
|
||
servidor. La configuración de este <quote>script</quote> se
|
||
debe retocar ligeramente pero sirve como punto de partida para
|
||
comenzar rápidamente.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Existen ficheros estándar de arranque bajo
|
||
<filename>/etc</filename> que dan soporte al arranque de
|
||
máquinas sin disco.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>El <quote>swapping</quote>, en caso de ser necesario, se puede
|
||
realizar usando <acronym>NFS</acronym> y tambíen
|
||
usando un disco duro local.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<para>Existen varias formas de ejecutar una estación de trabajo sin
|
||
discos. En el proceso se involucran distintos elementos y la
|
||
mayoría se pueden adaptar a las necesidades del usuario.
|
||
A continuación se describen variaciones sobre la
|
||
configuración de un sistema sin discos, haciendo incapié
|
||
en la simplicidad y compatibilidad con los <quote>scripts</quote> de
|
||
arranque de &os;. El sistema que vamos a describir tiene las
|
||
siguientes características.</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Las estaciones de trabajo sin disco utilizan un sistema
|
||
de ficheros <filename>raíz</filename> de sólo lectura
|
||
y un sistema de ficheros compartido, también de
|
||
sólo lectura, bajo <filename>/usr</filename>.</para>
|
||
|
||
|
||
<para>El sistema de ficheros <filename>raíz</filename>
|
||
es una copia del sistema raíz estandar de &os; (normalmente
|
||
del sistema raíz del servidor), donde se sobreescriben
|
||
algunos archivos de configuración necesarios para la
|
||
ejecución sin discos y para la configuración local
|
||
específica de la máquina objetivo.</para>
|
||
|
||
<para>Las partes del sistema de ficheros
|
||
<filename>raíz</filename> que tiene que tener permisos de
|
||
lectura y escritura se superponen con los sistemas de ficheros
|
||
&man.mfs.8; (&os; 4.X) o &man.md.4;. Cualquier cambio que se
|
||
produzca en dichas partes se perderá cuando se reinicie el
|
||
sistema.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>El núcleo se transmite y se carga utilizando
|
||
<application>etherboot</application> o bien
|
||
<acronym>PXE</acronym>, dependiendo del hardware y los mecanismos
|
||
que se soporten.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<caution><para>Como se ha comentado con anterioridad estos sistemas son
|
||
inseguros. Se debe confinar dentro de una red protegida y el resto
|
||
de las máquinas por defecto no deben confiar en estos
|
||
métodos.</para>
|
||
</caution>
|
||
|
||
<para>Toda la información que se presenta en esta
|
||
sección se ha probado utilizando &os; 4.9-RELEASE y
|
||
5.2.1-RELEASE. El texto se encuentra estructurado principalmente para
|
||
utilización en sistemas 4.X. Se insertan notas para indicar
|
||
cambios producidos en las versiones 5.X.</para>
|
||
|
||
<sect2>
|
||
<title>Conocimientos previos</title>
|
||
|
||
<para>Configurar estaciones de trabajo sin discos es una
|
||
operación relativamente sencilla pero en la que pueden
|
||
cometerse errores. Estos errores resultan algunas veces
|
||
difíciles de diagnosticar debido a razones que vamos a
|
||
exponer a continuación. Por ejemplo:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Diferentes opciones de tiempo de compilación pueden
|
||
determinar comportamientos distintos en tiempo de
|
||
ejecución.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Los mensajes de error a menudo resultan crípticos o
|
||
incluso no existen.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<para>Se se quieren resolver los posibles problemas que puedan surgir
|
||
resulta muy útil conocer el funcionamiento conceptual del
|
||
mecanismo.</para>
|
||
|
||
<para>Para que el arranque se produzca exitosamente se deben realizar
|
||
varias operaciones:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>La máquina necesita obtener algunos
|
||
parámetros iniciales, tales como su dirección IP,
|
||
el fichero ejecutable, el nombre del servidor y la ruta
|
||
raíz. Esto se realiza utilizando los protocolos
|
||
<acronym>DHCP</acronym> o <acronym>BOOTP</acronym>.
|
||
<acronym>DHCP</acronym> es una extensión compatible del
|
||
protocolo <acronym>BOOTP</acronym> y utiliza los mismos
|
||
números de puertos y los mismos formatos de paquete
|
||
básicos.</para>
|
||
|
||
<para>Es posible configurar un sistema de tal forma que utilice
|
||
sólamente <acronym>BOOTP</acronym>. En el sistema base de
|
||
&os; se incluye el programa servidor &man.bootpd.8;.</para>
|
||
|
||
<para>No obstante <acronym>DHCP</acronym> posee varias ventajas sobre
|
||
BOOTP (archivos de configuración más limpios,
|
||
posibilidad de ejecutar <acronym>PXE</acronym>, junto con otras
|
||
características que no se relacionan directamente con el
|
||
tema que estamos tratando tratando) por lo que principalmente se
|
||
va a describir la configuración de <acronym>DHCP</acronym>,
|
||
proporcionando ejemplos equivalentes en &man.bootpd.8; siempre que
|
||
sea posible. La configuración de ejemplo se basa en el
|
||
paquete software de <application>ISC DHCP</application> (en el
|
||
servidor de prueba se instaló la versión
|
||
3.0.1.r12).</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>La máquina sin disco necesita transferir uno o varios
|
||
programas a la memoria local. Para ello se usa
|
||
<acronym>TFTP</acronym> o bien <acronym>NFS</acronym>.
|
||
La elección entre ambos se produce mediante la
|
||
configuración de la compilación que se produce en
|
||
varios lugares. Una fuente de error típica aparece cuando
|
||
se especifican ficheros con el protocolo incorrecto:
|
||
<acronym>TFTP</acronym> normalmente transfiere todos los ficheros
|
||
desde un único directorio del servidor, de modo que espera
|
||
nombres de ficheros relativos a dicho directorio. Por otro lado
|
||
<acronym>NFS</acronym> necesita recibir rutas de fichero
|
||
absolutas.</para>
|
||
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>El kernel y los programas de arranque intermedios deben ser
|
||
inicializados y ejecutados. Existen diferencias importantes en
|
||
este área:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para><acronym>PXE</acronym> carga &man.pxeboot.8;, una
|
||
versión modificada de la tercera fase del cargador de
|
||
arranque de &os;. &man.loader.8; obtiene la mayoría de
|
||
los parámetros necesarios para arrancar el sistema
|
||
y los deposita en variables de entorno del kernel antes de
|
||
tranferir el control. En este caso es posible utilizar un
|
||
un núcleo <filename>GENERIC</filename>
|
||
.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para><application>etherboot</application> carga directamente el
|
||
directamente el núcleo con menos trabajo previo que
|
||
el método anterior. Para ello se debe compilar un
|
||
núcleo con ciertas opciones.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<para><acronym>PXE</acronym> y <application>etherboot</application>
|
||
funcionan muy bien en los sistemas 4.X. Dado que los
|
||
núcleos de los sistemas 5.X permiten que el &man.loader.8;
|
||
realice más tareas, se prefiere usar <acronym>
|
||
PXE</acronym>.</para>
|
||
|
||
<para>Si su <acronym>BIOS</acronym> y su tarjeta de red soportan
|
||
<acronym>PXE</acronym> lo normal es utilizarlo. No obstante se
|
||
puede arrancar un sistema 5.X utilizando <application>
|
||
etherboot</application>.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Para acabar la tarea la máquina necesita acceder al
|
||
sistema de ficheros. En todos los casos se utiliza
|
||
<acronym>NFS</acronym>.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<para>No olvide consultar &man.diskless.8;.</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Instrucciones de configuración</title>
|
||
|
||
<sect3>
|
||
<title>Configuración utilizando <application>ISC
|
||
DHCP</application></title>
|
||
<indexterm>
|
||
<primary>DHCP</primary>
|
||
<secondary>diskless operation</secondary>
|
||
</indexterm>
|
||
|
||
<para>El servidor <application>ISC DHCP</application> puede
|
||
responder tanto a peticiones de BOOTP como a peticiones de
|
||
<acronym>DHCP</acronym>.</para>
|
||
|
||
<para><application>ISC DHCP</application> no forma parte de
|
||
la versión 4.9 de &os; por lo que se debe instalar el port
|
||
<filename role="package">net/isc-dhcp3-server</filename> o el
|
||
paquete correspondiente. Por favor, consulte <xref
|
||
linkend="ports"> para obtener
|
||
más información sobre los ports y los
|
||
paquetes.</para>
|
||
|
||
<para>Una vez que <application>ISC DHCP</application> se encuentra
|
||
instalado necesita un fichero de configuración para poder
|
||
ejecutarse
|
||
<filename>/usr/local/etc/dhcpd.conf</filename>). A
|
||
continuación se muestra un ejemplo comentado, donde la
|
||
máquina <hostid>margaux</hostid> utiliza
|
||
<application>etherboot</application> y
|
||
la máquina <hostid>corbieres</hostid> utiliza
|
||
<acronym>PXE</acronym>:</para>
|
||
|
||
<programlisting>
|
||
default-lease-time 600;
|
||
max-lease-time 7200;
|
||
authoritative;
|
||
|
||
option domain-name "example.com";
|
||
option domain-name-servers 192.168.4.1;
|
||
option routers 192.168.4.1;
|
||
|
||
subnet 192.168.4.0 netmask 255.255.255.0 {
|
||
use-host-decl-names on; <co id="co-dhcp-host-name">
|
||
option subnet-mask 255.255.255.0;
|
||
option broadcast-address 192.168.4.255;
|
||
|
||
host margaux {
|
||
hardware ethernet 01:23:45:67:89:ab;
|
||
fixed-address margaux.example.com;
|
||
next-server 192.168.4.4; <co id="co-dhcp-next-server">
|
||
filename "/data/misc/kernel.diskless"; <co id="co-dhcp-filename">
|
||
option root-path "192.168.4.4:/data/misc/diskless"; <co id="co-dhcp-root-path">
|
||
}
|
||
host corbieres {
|
||
hardware ethernet 00:02:b3:27:62:df;
|
||
fixed-address corbieres.example.com;
|
||
next-server 192.168.4.4;
|
||
filename "pxeboot";
|
||
option root-path "192.168.4.4:/data/misc/diskless";
|
||
}
|
||
}
|
||
</programlisting>
|
||
|
||
<calloutlist>
|
||
<callout arearefs="co-dhcp-host-name"><para>Esta
|
||
opción indica a
|
||
<application>dhcpd</application> que envíe el
|
||
valor que se encuentra en las declaraciones
|
||
de <literal>host</literal> como el nombre de
|
||
máquina para la máquina sin disco. Otra forma
|
||
de hacer esto sería añadiendo una opción
|
||
<literal>option host-name
|
||
<replaceable>margaux</replaceable></literal> dentro de las
|
||
declaraciones de máquina.</para>
|
||
</callout>
|
||
|
||
<callout arearefs="co-dhcp-next-server"><para>La directiva
|
||
<literal>next-server</literal> selecciona el servidor
|
||
de <acronym>TFTP</acronym> o de <acronym>NFS</acronym>
|
||
que se debe utilizar para cargar el núcleo
|
||
o el fichero cargador del núcleo (por defecto se
|
||
utiliza la misma máquina que actúa como servidor
|
||
de <acronym>DHCP</acronym>).</para>
|
||
</callout>
|
||
|
||
<callout arearefs="co-dhcp-filename"><para>La directiva
|
||
<literal>filename</literal> define el archivo que
|
||
<application>etherboot</application> o <acronym>PXE</acronym>
|
||
cargará en el siguiente paso de ejecución.
|
||
Debe especificarse de acuerdo con el método de
|
||
transferencia seleccionado.
|
||
<application>Etherboot</application> se puede compilar para
|
||
que use <acronym>NFS</acronym> o <acronym>TFTP</acronym>. El
|
||
sistema &os; se configura por defecto para <acronym>
|
||
NFS</acronym>.
|
||
<acronym>PXE</acronym> utiliza <acronym>TFTP</acronym> por lo
|
||
que se utiliza una ruta relativa para especificar el nombre del
|
||
fichero (esto puede depender de la configuración del
|
||
servidor de <acronym>TFTP</acronym> pero suele ser lo
|
||
normal). Además <acronym>PXE</acronym> no carga el
|
||
núcleo, lo hace <filename>pxeboot</filename>.
|
||
Existen otras posibilidades interesantes, como cargar
|
||
<filename>pxeboot</filename> desde el directorio
|
||
<filename role="directory">/boot</filename>
|
||
de una unidad de CD-ROM de &os; (ya que &man.pxeboot.8; puede
|
||
cargar un núcleo
|
||
<filename>GENERIC</filename> surge la posibilidad de utilizar
|
||
<acronym>PXE</acronym> para arrancar desde una unidad de
|
||
CD-ROM remota).</para>
|
||
</callout>
|
||
|
||
<callout arearefs="co-dhcp-root-path"><para>La opción
|
||
<literal>root-path</literal> define la ruta para el
|
||
sistema de ficheros raíz utilizando la notación
|
||
típica de <acronym>NFS</acronym>. Cuando se utiliza
|
||
<acronym>PXE</acronym>, es posible dejar la
|
||
dirección IP siempre y cuando no se active la
|
||
opción del núcleo de BOOTP. El servidor
|
||
<acronym>NFS</acronym> será en este caso el mismo que el
|
||
servidor de <acronym>TFTP</acronym>.</para>
|
||
</callout>
|
||
</calloutlist>
|
||
|
||
</sect3>
|
||
<sect3>
|
||
<title>Configuración utilizando BOOTP</title>
|
||
<indexterm>
|
||
<primary>BOOTP</primary>
|
||
<secondary>diskless operation</secondary>
|
||
</indexterm>
|
||
|
||
<para>A continuación se muestra la configuración
|
||
equivalente utilizando <application>bootpd</application>
|
||
(reducida a un único cliente). Esta configuración
|
||
se debe situar en <filename>/etc/bootptab</filename>.</para>
|
||
|
||
<para>Por favor, recuerde que <application>etherboot</application>
|
||
se debe compilar con la opción específica de
|
||
<literal>NO_DHCP_SUPPORT</literal> para que pueda utilizar BOOTP
|
||
y que <acronym>PXE</acronym> <emphasis>requiere</emphasis>
|
||
<acronym>DHCP</acronym>. La única ventaja obvia de
|
||
<application>bootpd</application> es que se encuentra disponible en
|
||
el sistema base.</para>
|
||
|
||
<programlisting>
|
||
.def100:\
|
||
:hn:ht=1:sa=192.168.4.4:vm=rfc1048:\
|
||
:sm=255.255.255.0:\
|
||
:ds=192.168.4.1:\
|
||
:gw=192.168.4.1:\
|
||
:hd="/tftpboot":\
|
||
:bf="/kernel.diskless":\
|
||
:rp="192.168.4.4:/data/misc/diskless":
|
||
|
||
margaux:ha=0123456789ab:tc=.def100
|
||
</programlisting>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Preparación de un programa de arranque con
|
||
<application>Etherboot</application></title>
|
||
|
||
<indexterm>
|
||
<primary>Etherboot</primary>
|
||
</indexterm>
|
||
|
||
<para><ulink url="http://etherboot.sourceforge.net">La
|
||
página web de Etherboot
|
||
</ulink> contiene
|
||
<ulink
|
||
url="http://etherboot.sourceforge.net/doc/html/userman/t1.html">
|
||
una amplia documentación</ulink> enfocada
|
||
principalmente a los sistemas Linux pero en cualquier caso contiene
|
||
información que puede resultar útil. En los siguientes
|
||
párrafos se describe brevemente como se puede utilizar
|
||
<application>etherboot</application> en un sistema &os;.</para>
|
||
|
||
<para>Lo primero es instalar el port o paquete <filename
|
||
role="package">net/etherboot</filename>. El port de
|
||
<application>etherboot</application> está en
|
||
<filename>/usr/ports/net/etherboot</filename>. Si el árbol
|
||
de ports está instalado en el sistema basta con ejecutar
|
||
<literal>make</literal> en dicho directorio. Por favor,
|
||
lea <xref linkend="ports"> para saber más sobre los ports y
|
||
los paquetes.</para>
|
||
|
||
<para>Se puede modificar la configuración de
|
||
<application>etherboot</application> (por ejemplo, para que use
|
||
<acronym>TFTP</acronym> en lugar de <acronym>NFS</acronym>) editando
|
||
el fichero <filename>Config</filename> que se encuentra en el
|
||
directorio fuente de <application>etherboot</application>.</para>
|
||
|
||
<para>Para nuestros propósitos se utilizará un disquete
|
||
de arranque. Para utilizar otros métodos (PROM o un
|
||
programa &ms-dos;) por favor consulte la documentación de
|
||
<application>etherboot</application>.</para>
|
||
|
||
<para>Para crear un disco de arranque se debe insertar un disco en la
|
||
unidad de disquetes de la máquina donde se ha instalado
|
||
<application>etherboot</application>, cambiar al directorio
|
||
<filename>src</filename> dentro del árbol de directorios de
|
||
<application>etherboot</application> y teclear:</para>
|
||
|
||
<screen>
|
||
&prompt.root; <userinput>gmake bin32/<replaceable>tipo_de_dispositivo</replaceable>.fd0</userinput>
|
||
</screen>
|
||
|
||
<para><replaceable>tipo_de_dispositivo</replaceable> depende del tipo
|
||
de tarjeta Ethernet que se encuentre instalada en la estación
|
||
de trabajo sin disco. Consulte el fichero
|
||
<filename>NIC</filename> en el mismo directorio para determinar
|
||
cúal es el <replaceable>tipo_de_dispositivo</replaceable> que
|
||
debe usted usar.</para>
|
||
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Arranque con <acronym>PXE</acronym></title>
|
||
|
||
<para>Por defecto el cargador &man.pxeboot.8; carga, valga la
|
||
redundancia, el kernel vía <acronym>NFS</acronym>. El
|
||
El cargador se puede compilar para que utilice <acronym>
|
||
TFTP</acronym> en lugar de <acronym>NFS</acronym> especificando la
|
||
opción <literal>LOADER_TFTP_SUPPORT</literal> dentro de
|
||
<filename>/etc/make.conf</filename>. Observe los comentarios de
|
||
<filename>/etc/defaults/make.conf</filename> (o de
|
||
<filename>/usr/share/examples/etc/make.conf</filename> para
|
||
sistemas 5.X) para saber más detalles.</para>
|
||
|
||
<para>Existen otras dos opciones de
|
||
<filename>make.conf</filename> no documentadas que pueden
|
||
ser útiles para arrancar una máquina sin disco a
|
||
través del puerto serie:
|
||
<literal>BOOT_PXELDR_PROBE_KEYBOARD</literal> y
|
||
<literal>BOOT_PXELDR_ALWAYS_SERIAL</literal> (esta
|
||
última sólo existe en &os; 5.X).</para>
|
||
|
||
<para>Para utilizar <acronym>PXE</acronym> cuando arranca la
|
||
máquina normalmente el usuario tiene que seleccionar la
|
||
opción <literal>Boot from network</literal> dentro del
|
||
menú de opciones de la <acronym>BIOS</acronym> o pulsar un
|
||
tecla de función cuando la máquina se está
|
||
inicializando.</para>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Configuración de servidores de
|
||
<acronym>TFTP</acronym> y de <acronym>NFS</acronym></title>
|
||
|
||
<indexterm>
|
||
<primary>TFTP</primary>
|
||
<secondary>diskless operation</secondary>
|
||
</indexterm>
|
||
<indexterm>
|
||
<primary>NFS</primary>
|
||
<secondary>diskless operation</secondary>
|
||
</indexterm>
|
||
|
||
<para>Si <acronym>PXE</acronym> o
|
||
<application>etherboot</application> se encuentran configurados para
|
||
utilizar <acronym>TFTP</acronym> se necesita activar
|
||
<application>tftpd</application> en el servidor de ficheros:
|
||
</para>
|
||
<procedure>
|
||
<step>
|
||
<para>Crear un directorio desde el cual el dæmon
|
||
<application>tftpd</application> servirá los
|
||
ficheros, por ejemplo <filename>/tftpboot</filename>.</para>
|
||
</step>
|
||
|
||
<step>
|
||
<para>Añadir la siguiente línea a
|
||
<filename>/etc/inetd.conf</filename>:</para>
|
||
|
||
<programlisting>tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpboot</programlisting>
|
||
|
||
<note><para>Parece que al menos algunas versiones de
|
||
<acronym>PXE</acronym> utilizan la versión
|
||
<acronym>TCP</acronym>
|
||
de <acronym>TFTP</acronym>. En este caso se puede
|
||
añadir una segunda línea, donde se reemplace
|
||
<literal>dgram udp</literal> por <literal>stream
|
||
tcp</literal>.</para>
|
||
</note>
|
||
</step>
|
||
<step>
|
||
<para>Indicar a <application>inetd</application> que
|
||
vuelva a leer su fichero de configuración:</para>
|
||
|
||
<screen>&prompt.root; <userinput>kill -HUP `cat
|
||
/var/run/inetd.pid`</userinput></screen>
|
||
</step>
|
||
</procedure>
|
||
|
||
<para>Se puede situar el directorio
|
||
<filename>tftpboot</filename> en cualquier parte del servidor.
|
||
Debe asegurarse de que la localización se encuentra
|
||
correctamente configurada tanto en
|
||
<filename>inetd.conf</filename> como en
|
||
<filename>dhcpd.conf</filename>.</para>
|
||
|
||
<para>En todos los casos también resulta necesario activar el
|
||
sistema de <acronym>NFS</acronym> y exportar los sistemas de
|
||
ficheros adecuados, todo ello en el servidor de
|
||
<acronym>NFS</acronym>.</para>
|
||
|
||
<procedure>
|
||
<step>
|
||
<para>Añadir lo siguiente a
|
||
<filename>/etc/rc.conf</filename>:</para>
|
||
<programlisting>nfs_server_enable="YES"</programlisting>
|
||
</step>
|
||
|
||
<step>
|
||
<para>Exportar el sistema de ficheros donde el directorio
|
||
raíz sin disco se encuentra localizado añadiendo
|
||
lo siguiente a <filename>/etc/exports</filename> (ajuste el
|
||
punto de montaje de la unidad y sustituya
|
||
<replaceable>margaux corbieres</replaceable> por el
|
||
nombre de las estaciones de trabajo sin disco, según
|
||
corresponda):</para>
|
||
|
||
<programlisting><replaceable>/data/misc</replaceable> -alldirs -ro <replaceable>margaux corbieres</replaceable></programlisting>
|
||
</step>
|
||
<step>
|
||
<para>Indicar a <application>mountd</application> que vuelva a leer
|
||
su archivo de configuración. Si en un primer paso se ha
|
||
configurado la activación automática del sistema de
|
||
<acronym>NFS</acronym> en
|
||
<filename>/etc/rc.conf</filename> lo mejor es reiniciar para que
|
||
los cambios surtan efecto.</para>
|
||
|
||
<screen>&prompt.root; <userinput>kill -HUP `cat
|
||
/var/run/mountd.pid`</userinput></screen>
|
||
</step>
|
||
</procedure>
|
||
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Construcción de un kernel sin
|
||
disco</title>
|
||
|
||
<indexterm>
|
||
<primary>diskless operation</primary>
|
||
<secondary>kernel configuration</secondary>
|
||
</indexterm>
|
||
|
||
<para>Si se utiliza <application>etherboot</application>, se necesita
|
||
crear un archivo de configuración para el kernel de la
|
||
máquina sin disco que posea las siguientes opciones
|
||
(además de las opciones del núcleo habituales):</para>
|
||
|
||
<programlisting>
|
||
options BOOTP # Use BOOTP to obtain IP address/hostname
|
||
options BOOTP_NFSROOT # NFS mount root filesystem using BOOTP info
|
||
</programlisting>
|
||
|
||
<para>Puede resultar interesante utilizar además
|
||
<literal>BOOTP_NFSV3</literal>,
|
||
<literal>BOOT_COMPAT</literal> y
|
||
<literal>BOOTP_WIRED_TO</literal>
|
||
(consultar <filename>LINT</filename> en 4.X o
|
||
<filename>NOTES</filename> en sistemas 5.X).</para>
|
||
|
||
<para>Los nombres de estas opciones son nombres
|
||
históricos y ligeramente confusos ya que permiten un uso
|
||
indistinto tanto de <acronym>DHCP</acronym> como de BOOTP dentro del
|
||
núcleo (también resulta posible forzar la
|
||
utilización única de o bien BOOTP o bien de
|
||
<acronym>DHCP</acronym>).</para>
|
||
|
||
<para>Contruir el núcleo (vea <xref
|
||
linkend="kernelconfig">) y copiarlo al lugar especificado
|
||
en el archivo <filename>dhcpd.conf</filename>.</para>
|
||
|
||
<note>
|
||
<para>Cuando se utiliza <acronym>PXE</acronym>, la
|
||
construcción del núcleo con las opciones anteriores
|
||
no resulta ser algo estrictamente necesario (aunque se
|
||
recomienda). Activar dichas opciones provoca un mayor
|
||
tráfico de peticiones de <acronym>DHCP</acronym> durante el
|
||
arranque del núcleo, lo que puede dar lugar a
|
||
pequeñas inconsistencias entre los nuevos valores y los
|
||
los valores recuperados por &man.pxeboot.8; en casos muy
|
||
específicos. La ventaja de utilizarlas consiste en que como
|
||
un efecto colateral se configurará el nombre de la
|
||
máquina. De otro modo tendríamos que configurar dicho
|
||
nombre mediante otro método por ejemplo mediante la
|
||
configuración específica de la máquina cliente
|
||
a través del archivo <filename>rc.conf</filename>.</para>
|
||
</note>
|
||
|
||
<note>
|
||
<para>Para que el núcleo se pueda cargar sin problemas con
|
||
<application>etherboot</application> en sistemas 5.X dicho
|
||
núcleo tiene que tener compilado el soporte para
|
||
<emphasis>device hints</emphasis>. Para ello normalmente se
|
||
especifica la siguiente opción dentro del fichero
|
||
de configuración del núcleo (consulte los comentarios
|
||
del fichero <filename>NOTES</filename>):</para>
|
||
|
||
<programlisting>hints "GENERIC.hints"</programlisting>
|
||
</note>
|
||
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Preparación del sistema de ficheros
|
||
raíz</title>
|
||
|
||
<indexterm>
|
||
<primary>root file system</primary>
|
||
<secondary>diskless operation</secondary>
|
||
</indexterm>
|
||
|
||
<para>Se debe crear un sistema de ficheros raíz en las
|
||
estaciones de trabajo sin disco, concretamente en la
|
||
localización especificada por <literal>root-path</literal>
|
||
dentro de <filename>dhcpd.conf</filename>. Las siguientes secciones
|
||
describen dos formas de hacer esto.</para>
|
||
<sect4>
|
||
<title>Utilización del <quote>script</quote>
|
||
<filename>clone_root</filename></title>
|
||
|
||
<para>Este es el modo más rápido de crear un sistema de
|
||
ficheros raíz, pero actulamente sólo se encuentra
|
||
soportado en &os; 4.X. El <quote>script</quote> de shell se
|
||
encuentra en <filename>/usr/share/examples/diskless/clone_root</filename>
|
||
y debe ser configurado al menos para ajustar el lugar donde se
|
||
construirá el sistema de ficheros (concretamente la
|
||
variable <literal>DEST</literal>).</para>
|
||
|
||
<para>Consulte los comentarios que se encuentran al comienzo del
|
||
<quote>script</quote> para conocer cuales son las instrucciones que
|
||
debe seguir. Allí se explica cómo se construye el
|
||
sistema de ficheros base y como determinados ficheros se pueden
|
||
sobreescribir de manera selectiva por versiones
|
||
específicas para funcionar sin discos, para toda una subred
|
||
o para una máquina individual. También allí
|
||
se muestran ejemplos de los ficheros
|
||
<filename>/etc/fstab</filename> y
|
||
<filename>/etc/rc.conf</filename> para máquinas sin
|
||
disco.</para>
|
||
|
||
<para>Los archivos <filename>README</filename> que se encuentran
|
||
dentro de <filename>/usr/share/examples/diskless</filename>
|
||
contienen mucha información de base, que junto con
|
||
el resto de ejemplos dentro del directorio
|
||
<filename>diskless</filename> sirven para documentar un
|
||
método de configuración distinto del que se
|
||
utiliza en <filename>clone_root</filename> y en los <quote>
|
||
scripts</quote> del sistema de <filename
|
||
role="directory">/etc</filename>, que resultan ser un tanto
|
||
confusos. No obstante se pueden utilizar a modo de referencia,
|
||
excepto si se prefiere utilizar el método que se describe
|
||
en ellos, en cuyo caso se necesitará modificar y
|
||
adaptar los <quote>scripts</quote> de forma adecuada.</para>
|
||
</sect4>
|
||
|
||
<sect4>
|
||
<title>Utilización del procedimiento estándar de
|
||
<command>make world</command>
|
||
</title>
|
||
|
||
<para>Este método se puede utilizar tanto en
|
||
&os; 4.X o 5.X y se instalará un sistema completamente
|
||
nuevo (no sólo el sistema de ficheros raíz) dentro de
|
||
<envar>DESTDIR</envar>. Basta con ejecutar el siguiente <quote>
|
||
script</quote>:</para>
|
||
|
||
<programlisting>#!/bin/sh
|
||
export DESTDIR=/data/misc/diskless
|
||
mkdir -p ${DESTDIR}
|
||
cd /usr/src; make world && make kernel
|
||
cd /usr/src/etc; make distribution</programlisting>
|
||
|
||
<para>Una vez ejecutado puede ser necesario ajustar los ficheros
|
||
<filename>/etc/rc.conf</filename> y
|
||
<filename>/etc/fstab</filename> que se encuentran en
|
||
<envar>DESTDIR</envar> de acuerdo con nuestras necesidades.</para>
|
||
</sect4>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Configuración de la partición de
|
||
intercambio</title>
|
||
|
||
<para>En caso de ser necesario se puede acceder a un fichero
|
||
de intercambio (swap) a través del sistema
|
||
<acronym>NFS</acronym>. Uno de los métodos
|
||
típicamente utilizados para realizar esta tarea ha sido
|
||
retirado de la distribución 5.X.</para>
|
||
<sect4>
|
||
<title><acronym>NFS</acronym> swap en sistemas &os; 4.X</title>
|
||
|
||
<para>La ubicación del fichero de intercambio y su
|
||
tamaño se puede especificar con las opciones
|
||
&os;-specific 128 y 129 de BOOTP/<acronym>DHCP</acronym>.
|
||
A continuación se muestran varios ejemplos de ficheros de
|
||
de configuración para <application>
|
||
ISC DHCP 3.0</application> o
|
||
<application>bootpd</application>:</para>
|
||
|
||
<procedure>
|
||
<step><para>Añadir las siguientes líneas al fichero
|
||
<filename>dhcpd.conf</filename>:</para>
|
||
<programlisting>
|
||
# Global section
|
||
option swap-path code 128 = string;
|
||
option swap-size code 129 = integer 32;
|
||
|
||
host margaux {
|
||
... # Standard lines, see above
|
||
option swap-path <replaceable>"192.168.4.4:/netswapvolume/netswap"</replaceable>;
|
||
option swap-size <replaceable>64000</replaceable>;
|
||
}
|
||
</programlisting>
|
||
|
||
<para><literal>swap-path</literal> es la ruta al directorio donde
|
||
se instalarán los archivos de intercambio. Cada
|
||
Cada fichero se denomina
|
||
<filename>swap.<replaceable>direccion-ip-del-cliente</replaceable></filename>.</para>
|
||
|
||
<para>Versiones más antiguas de
|
||
<application>dhcpd</application> usaban una sintáxis del
|
||
estilo de <literal>option option-128 "...</literal>, lo cual ya
|
||
no está soportado.</para>
|
||
|
||
<para><filename>/etc/bootptab</filename> normalmente
|
||
utiliza la siguiente sintaxis:</para>
|
||
|
||
<programlisting>T128="192.168.4.4:/netswapvolume/netswap":T129=0000fa00</programlisting>
|
||
|
||
<note><para>El tamaño del fichero dedicado a intercambio
|
||
se debe expresar en <filename>/etc/bootptab</filename>
|
||
en formato hexadecimal.</para></note>
|
||
</step>
|
||
|
||
<step>
|
||
<para>En el servidor de ficheros <acronym>NFS</acronym>
|
||
donde va a residir el fichero de <quote>swap</quote> se debe(n)
|
||
crear dicho(s) fichero(s)</para>
|
||
<screen>
|
||
&prompt.root; <userinput>mkdir <replaceable>/volumenintercambiored/intercambiored</replaceable></userinput>
|
||
&prompt.root; <userinput>cd <replaceable>/volumenintercambiored/intercambiored</replaceable></userinput>
|
||
&prompt.root; <userinput>dd if=/dev/zero bs=1024 count=<replaceable>64000</replaceable> of=swap.<replaceable>192.168.4.6</replaceable></userinput>
|
||
&prompt.root; <userinput>chmod 0600 swap.<replaceable>192.168.4.6</replaceable></userinput>
|
||
</screen>
|
||
<para><replaceable>192.168.4.6</replaceable> es la dirección IP del cliente sin disco.</para>
|
||
</step>
|
||
|
||
<step>
|
||
<para>En el servidor <acronym>NFS</acronym> añadir a
|
||
<filename>/etc/exports</filename> la siguiente línea:
|
||
</para>
|
||
<programlisting>
|
||
<replaceable>/volumenintercambiored</replaceable> -maproot=0:10 -alldirs <replaceable>margaux corbieres</replaceable>
|
||
</programlisting>
|
||
<para>A continuación indicar a
|
||
<application>mountd</application> que vuelva a leer el fichero
|
||
<filename>/etc/exports</filename> como se ha indicado
|
||
anteriormente.</para>
|
||
</step>
|
||
</procedure>
|
||
</sect4>
|
||
|
||
<sect4>
|
||
<title><acronym>NFS</acronym> swap en &os 5.X</title>
|
||
|
||
<para>El núcleo no soporta la activación del
|
||
intercambio a través de <acronym>NFS</acronym> en tiempo de
|
||
arranque. De esta forma la <quote>swap</quote> se debe activar
|
||
mediante los <quote>scripts</quote> montando un sistema de ficheros
|
||
de lectura-escritura y creando y activando el fichero de
|
||
intercambio. Para crear un fichero de intercambio de un
|
||
determinado tamaño se puede ejecutar lo siguiente:</para>
|
||
|
||
<screen>&prompt.root; <userinput>dd if=/dev/zero of=<replaceable>/ruta/al/fichero/de/intercambio</replaceable> bs=1k count=1 oseek=<replaceable>100000</replaceable></userinput></screen>
|
||
|
||
<para>Para activar el intercambio se tiene que añadir
|
||
la siguiente línea al fichero de configuración
|
||
<filename>rc.conf</filename>:</para>
|
||
|
||
<programlisting>swapfile=<replaceable>/ruta/al/fichero/de/intercambio</replaceable></programlisting>
|
||
</sect4>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Varios</title>
|
||
|
||
|
||
<sect4>
|
||
<title>Ejecución con un <filename>/usr</filename> de
|
||
sólo lectura</title>
|
||
|
||
<indexterm>
|
||
<primary>diskless operation</primary>
|
||
<secondary>/usr read-only</secondary>
|
||
</indexterm>
|
||
|
||
<para>Si la estación de trabajo sin disco se configura para
|
||
utilizar el sistema X-Window se tiene que ajustar el fichero de
|
||
configuración de xdm debido a que dicho fichero
|
||
sitúa por defecto el fichero de <quote>logs</quote> de
|
||
errores en el directorio <filename>/usr</filename>.</para>
|
||
</sect4>
|
||
<sect4>
|
||
<title>Uso de un servidor no-&os;</title>
|
||
|
||
<para>Cuando el servidor del sistema de ficheros raíz no
|
||
ejecuta &os; se tiene que crear un sistema de ficheros
|
||
raíz sobre una máquina &os; para después
|
||
copiarlo al servidor original mediante las órdenes
|
||
<command>tar</command> o <command>cpio</command>.</para>
|
||
|
||
|
||
<para>En esta situación algunas veces surgen varios
|
||
problemas relacionados con los dispositivos especiales que
|
||
se encuentran en el directorio
|
||
<filename>/dev</filename> debido a los diferentes
|
||
tamaños de los enteros mayor/menor. Una solución
|
||
para este problema consiste en exportar un directorio del servidor
|
||
no-&os;, montar este directorio en la máquina &os; anterior
|
||
y ejecutar <command>MAKEDEV</command> en dicha máquina para
|
||
crear las entradas de dispositivo correctas (&os; 5.0 y
|
||
posteriores utilizan &man.devfs.5; para ubicar nodos de
|
||
dispositivos de forma transparente para el usuario de tal modo que
|
||
la ejecución de <command>MAKEDEV</command> en estos
|
||
sistemas no sirve para nada).</para>
|
||
|
||
</sect4>
|
||
|
||
</sect3>
|
||
|
||
</sect2>
|
||
</sect1>
|
||
|
||
<sect1 id="network-isdn">
|
||
<title>RDSI</title>
|
||
|
||
<indexterm>
|
||
<primary>RDSI</primary>
|
||
</indexterm>
|
||
|
||
<para><ulink url="http://www.alumni.caltech.edu/~dank/isdn/">la
|
||
página de RDSI de Dan Kegel</ulink> constituye un recurso de
|
||
información bastante bueno sobre la tecnología RDSI
|
||
(ISDN en inglés) y sobre el hardware relacionado.</para>
|
||
|
||
<para>A continuación se comenta un esquema rápido sobre
|
||
RDSI:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Si usted vive en Europa le puede resultar útil leer la
|
||
sección sobre tarjetas RDSI.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Si se prevee utilizar RDSI principalmente para conectarse a
|
||
Internet a través de un Proveedor de Servicios utilizando
|
||
un mecanismo de marcación automática no dedicado
|
||
(dial-up), se puede echar un vistazo a los Adaptadores de
|
||
Terminal. Dichos adaptadores proporciona la mayor flexibilidad y
|
||
garantiza los mínimos problemas en caso de cambio de
|
||
cambio de proveedor.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Si estamos conectados a dos LAN o conectando a Internet con una
|
||
conexión RDSI dedicada puede ser interesante considerar la
|
||
opción de usar un <quote>router/bridge</quote>
|
||
único.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<para>El coste es un factor importante a la hora de determinar
|
||
qué solución se debe escoger. Las siguientes opciones se
|
||
encuentran ordenadas desde las más baratas hasta las
|
||
más caras.</para>
|
||
|
||
<sect2 id="network-isdn-cards">
|
||
<sect2info>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Hellmuth</firstname>
|
||
<surname>Michaelis</surname>
|
||
<contrib>Escrito por </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
</sect2info>
|
||
<title>Tarjetas RDSI</title>
|
||
|
||
<indexterm>
|
||
<primary>ISDN</primary>
|
||
<secondary>cards</secondary>
|
||
</indexterm>
|
||
|
||
<para>La implementación de RDSI que posee &os; soporta
|
||
sólamente el estandar DSS1/Q.931 (también conocido como
|
||
Euro-RDSI) utilizando tarjetas pasivas. A partir de &os; 4.4 se
|
||
soportan también algunas tarjetas activas usando firmware que
|
||
además soporta otros protocolos de señalización;
|
||
esto también sucede con la primera tarjeta RDSI de
|
||
acceso primario (PRI) soportada.</para>
|
||
|
||
<para>El software <application>isdn4bsd</application> permite conectar
|
||
con otras pasarelas RDSI utilizando IP sobre HDLC o bien PPP
|
||
PPP síncrono: ambos mediante el uso del PPP del núcleo
|
||
con <literal>isppp</literal>, una versión modificada del
|
||
controlador &man.sppp.4; o mediante la utilización del PPP de
|
||
entorno de usuario, &man.ppp.8;. Si se utiliza &man.ppp.8; de entorno
|
||
de usuario se pueden agrupar dos o mas canales B de RDSI (channel
|
||
bonding). Existe también software que permite a una
|
||
máquina responder a llamadas de teléfono y algunas
|
||
cosas más como un modem de 300 baudios.</para>
|
||
|
||
<para>Cada vez se soportan más tarjetas RDSI bajo &os; y los
|
||
informes existentes muestra que &os; se utiliza con dichas tarjetas de
|
||
forma satisfactoria en toda Europa y también en otras partes del
|
||
mundo.</para>
|
||
|
||
<para>Las tarjetas RDSI pasivas soportadas en &os; son principalmente las
|
||
que poseen el chip Infineon (antiguamente Siemens) ISAC/HSCX/IPAC.
|
||
También las tarjetas RDSI con los chips de Cologne (en bus ISA
|
||
exclusivamente), tarjetas PCI con el chip Winbond W6692, algunas
|
||
tarjetas con combinaciones de los chips Tiger 300/320/ISAC y
|
||
también algunas tarjetas basadas en chips propietarios como
|
||
las AVM Fritz! PCI V.1.0 y AVM Fritz! PnP.</para>
|
||
|
||
<para>Actualmente las tarjetas RDSI activas soportadas son las
|
||
AVM B1 (ISA y PCI) BRI, y las AVM T1 PCI PRI.</para>
|
||
|
||
<para>Se puede consultar
|
||
<filename>/usr/share/examples/isdn/</filename> para
|
||
obtener documentación sobre
|
||
<application>isdn4bsd</application> y también
|
||
en <ulink url="http://www.freebsd-support.de/i4b/">la
|
||
página principal de isdn4bsd</ulink>, donde hay enlaces de
|
||
ayuda, erratas y mucha más información útil,
|
||
como por ejemplo el <ulink
|
||
url="http://people.FreeBSD.org/~hm/">manual de isdn4bsd</ulink>.</para>
|
||
|
||
<para>Si se quiere añadir soporte para un protoclo RDSI distinto
|
||
para una tarjeta RDSI que no se encuentra soportada o para mejorar
|
||
<application>isdn4bsd</application> en algún aspecto por favor
|
||
póngase en contacto con &a.hm;.</para>
|
||
|
||
<para>Para realizar consultas referentes a la instalación,
|
||
configuración y depuración de problemas relacionados con
|
||
<application>isdn4bsd</application> le recomendamos recurrir a la lista
|
||
de correo &a.isdn.name;.</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Adaptadores de terminal RDSI</title>
|
||
|
||
<para>Los Adaptadores de Terminal (TA), son para RDSI lo que los modems
|
||
son para las líneas de teléfono convencionales.</para>
|
||
|
||
<indexterm><primary>modem</primary></indexterm>
|
||
<para>La mayor parte de los TAs utilizan el conjunto de instrucciones AT
|
||
de los modem Hayes y se pueden utilizar en lugar del modem.</para>
|
||
|
||
<para>Un TA opera básicamente de igual forma que un modem,
|
||
diferenciándose en que las velocidades de conexión y
|
||
<quote>throughput</quote> son mucho más grandes. La
|
||
configuración de <link
|
||
linkend="ppp">PPP</link> se realiza exactamente igual que para una
|
||
configuración de modem convencional.</para>
|
||
|
||
<indexterm><primary>PPP</primary></indexterm>
|
||
|
||
<para>La ventaja principal de utilizar un TA para conectarse a un
|
||
proveedor de servicios de internet consiste en que se puede usar PPP
|
||
dinámico. Ya que el espacio de direcciones de IP se está
|
||
direcciones de IP se está convirtiendo cada vez
|
||
convirtiendo en un recurso cada dí más limitado y escaso
|
||
los proveedores ya no desean proporcionar direcciones IP
|
||
estáticas a sus clientes. No obstante la mayoría de los
|
||
<quote>routers standalone</quote> no son capaces de adquirir
|
||
direcciones IP dinámicas.</para>
|
||
|
||
<para>Los TAs confían completamente en el dæmon de PPP
|
||
que se está ejecutando para proporcionar fiabilidad y
|
||
estabilidad en la conexión. De esta forma si se tiene
|
||
configurado PPP se puede migrar fácilmente de la
|
||
utilización de modems analógicos al uso de RDSI. No
|
||
obstante si existía algún problema con PPP antes de
|
||
efectuar la migración dichos problemas persistirán en
|
||
RDSI.</para>
|
||
|
||
<para>Si se desea máxima estabilidad se puede utilizar la
|
||
opción <link linkend="ppp">PPP</link>, no el
|
||
<link linkend="userppp">PPP a nivel de usuario</link>.</para>
|
||
|
||
<para>Se sabe que los siguientes TAs funcionan con &os;:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Motorola BitSurfer y Bitsurfer Pro</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Adtran</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<para>La mayoría de los demás TAs probablemente
|
||
también funcionen puesto que los fabricantes siempre tratan de
|
||
que sus productos puedan aceptar la mayoría de las
|
||
órdenes AT.</para>
|
||
|
||
<para>El problema que existe con los TAs es que, como sucede con los
|
||
modems, se necesita tener una buena tarjeta serie instalada en el
|
||
sistema.</para>
|
||
|
||
<para>Se recomienda consultar el tutorial <ulink
|
||
url="../../articles/serial-uart/index.html">FreeBSD Serial
|
||
Hardware</ulink> para obtener una comprensión detallada del
|
||
funcionamiento de los dispositivos serie en &os; y para comprender las
|
||
diferencias entre puertos serie síncronos y
|
||
asíncronos.</para>
|
||
|
||
<para>Un TA que se ejecuta a través de un puerto serie
|
||
(asíncrono) está limitado a 115.2 Kbs, aunque la
|
||
conexión RDSI sea de 128 Kbs. Para utilizar completamente
|
||
el ancho de banda que RDSI proporciona, se debe conectar el TA a una
|
||
tarjeta serie síncrona.</para>
|
||
|
||
<para>No se engañe creyendo que comprando un TA interno
|
||
hará desaparecer los problemas
|
||
síncronos/asíncronos. Los TA internos simplemente
|
||
disponen de un chip de puerto serie instalado de fábrica.
|
||
Lo único que se consigue con estos dispositivos es no tener
|
||
que enchufarlos a la red elétrica ahorrando así un
|
||
enchufe y no tener que comprar un cable serie, pero los problemas
|
||
dichos anteriormente permanecen.</para>
|
||
|
||
<para>Una tarjeta asíncrona con un TA resulta ser al menos tan
|
||
rápida como un <quote>router standalone</quote> y si &os;
|
||
controla dicha tarjeta se puede adaptar más
|
||
fácilmente.</para>
|
||
|
||
<para>La elección de una tarjeta síncrona/TA
|
||
versus un <quote>router standalone</quote> se trata en la
|
||
mayoría de los casos de una cuestión cuasi-religiosa.
|
||
Han existido diversas discusiones sobre este tema en varias listas de
|
||
correo. Nosotros recomendamos que busque información en los
|
||
<ulink
|
||
url="http://www.freebsd.org/search/index.html">
|
||
históricos</ulink> para para poder sopesar los pros y los
|
||
contras que se han esgrimido en tales discusiones.</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title><quote>bridges/routers</quote> RDSI <quote>Stand-alone</quote></title>
|
||
<indexterm>
|
||
<primary>ISDN</primary>
|
||
<secondary>stand-alone bridges/routers</secondary>
|
||
</indexterm>
|
||
<para>Los <quote>bridges</quote> o <quote>routers</quote> RDSI no son
|
||
específicos de &os; o de cualquier otro sistema operativo.
|
||
Para una descripción completa de la tecnología de
|
||
<quote>bridge</quote> y de pasarela de red por favor consulte
|
||
cualquier libro sobre redes.</para>
|
||
|
||
<para>En el contexto de esta sección los términos
|
||
<quote>router</quote>, pasarela y <quote>bridge</quote> se
|
||
utilizarán indistintamente.</para>
|
||
|
||
<para>Según va bajando el coste de los <quote>
|
||
routers/bridges</quote> RDSI su utilización entre el
|
||
público en general va en aumento.
|
||
Un <quote>router</quote> RDSI es una pequeña caja que se
|
||
conecta directamente a la red Ethernet local y que gestiona sus propias
|
||
conexiones con el <quote>bridge/router</quote> remoto. Posee un
|
||
software preconfigurado para comunicarse vía PPP y
|
||
tambíen utilizando otros protocolos de uso común.</para>
|
||
|
||
<para>Un router sopota una mayor tasa de paquetes (throughput) que un
|
||
<quote>standalone TA</quote>, ya que utiliza una conexión RDSI
|
||
síncrona de forma completa.</para>
|
||
|
||
<para>El problema principal que surge con los <quote>routers</quote> y
|
||
los <quote>bridges</quote> RDSI es que la interoperatibilidad entre
|
||
fabricantes muchas veces causa problemas. Si se está
|
||
planificando conectarse a un proveedor de servicios resulta conveniente
|
||
discutir previamente con ellos las necesidades y requisitos.</para>
|
||
|
||
<para>Si se tiene en mente conectar dos segmentos LAN tales como su LAN
|
||
de casa y la LAN de su oficina RDSI proporciona la solución
|
||
más simple y menos costosa de gestionar. Esto es así
|
||
porque al comprar usted mismo el equipamiento necesario para ambos
|
||
extremos de la conexión tiene usted el control sobre el enlace
|
||
y puede asegurar su correcto funcionamiento.</para>
|
||
|
||
<para>Por ejemplo, si queremos conecar una computadora casera o una
|
||
sucursal de la red de oficinas con la oficinal central, se puede
|
||
utilizar una configuración como la que se muestra a
|
||
continuación.</para>
|
||
|
||
<example>
|
||
<title>Sucursal o red doméstica</title>
|
||
|
||
<indexterm><primary>10 base 2</primary></indexterm>
|
||
<para>La red utiliza una topología basada en bus con
|
||
Ethernet tipo 10 base 2 (<quote>thinnet</quote>). Se conecta, en
|
||
caso de ser necesario, el <quote>router</quote> a la red cableada
|
||
mediante un <quote>transceiver</quote> AUI/10BT.</para>
|
||
|
||
<mediaobject>
|
||
<imageobject>
|
||
<imagedata fileref="advanced-networking/isdn-bus">
|
||
</imageobject>
|
||
|
||
<textobject>
|
||
<literallayout class="monospaced">---Estacion Sun
|
||
|
|
||
---Sistema FreeBSD
|
||
|
|
||
---Windows 95
|
||
|
|
||
Router Stand-alone
|
||
|
|
||
ISDN BRI line</literallayout>
|
||
</textobject>
|
||
|
||
<textobject>
|
||
<phrase>10 Base 2 Ethernet</phrase>
|
||
</textobject>
|
||
</mediaobject>
|
||
|
||
<para>Si nuestra sucursal o red hogar está compuesta
|
||
únicamente por una computadora se puede utilizar un cable
|
||
cruzado de par trenzado para conectar con el <quote>router
|
||
standalone</quote> de forma directa.</para>
|
||
</example>
|
||
|
||
<example>
|
||
<title>Oficina central u otra LAN</title>
|
||
|
||
<indexterm><primary>10 base T</primary></indexterm>
|
||
<para>La red utiliza una topología en estrella basada en
|
||
Ethernet de 10 base T (<quote>Par Trenzado</quote>).</para>
|
||
|
||
<mediaobject>
|
||
<imageobject>
|
||
<imagedata fileref="advanced-networking/isdn-twisted-pair">
|
||
</imageobject>
|
||
|
||
<textobject>
|
||
<literallayout class="monospaced"> -------Novell Server
|
||
| H |
|
||
| ---Sun
|
||
| |
|
||
| U ---FreeBSD
|
||
| |
|
||
| ---Windows 95
|
||
| B |
|
||
|___---Stand-alone router
|
||
|
|
||
ISDN BRI line</literallayout>
|
||
</textobject>
|
||
|
||
<textobject>
|
||
<phrase>ISDN Network Diagram</phrase>
|
||
</textobject>
|
||
</mediaobject>
|
||
</example>
|
||
|
||
<para>Una gran ventaja que poseen la mayoría de los
|
||
<quote>routers/bridges</quote> es que pueden gestionar al mismo tiempo
|
||
dos conexiones PPP <emphasis>independientes</emphasis> destinadas a dos
|
||
organizaciones distintas. Esta funcionalidad no se proporciona en la
|
||
mayoría de los TAs, excepto para determinados modelos
|
||
(normalmente más caros) que se fabrican con dos puertos serie.
|
||
No confunda esto con la agrupación de canales, MPP, etc.</para>
|
||
|
||
<para>Esta característica puede resultar muy útil si, por
|
||
ejemplo, se dispone de una conexión RDSI dedicada con la
|
||
oficina y queremos introducirnos en ella pero no queremos utilizar
|
||
otra línea RDSI en el trabajo. Un <quote>router</quote> situado
|
||
en las instalaciones de la oficina puede gestionar una
|
||
conexión de canal B dedicada (64 Kpbs) hacia internet y
|
||
utilizar el otro canal B como una conexión de datos
|
||
independiente. El segundo canal B se puede utilizar para
|
||
marcación remota (<quote>dial-in</quote> y <quote>
|
||
dial-out</quote>) o para agrupación dinámica de canales
|
||
(MPP, etc) en conjunción con el primer canal B con el objetivo
|
||
de obtener un mayor ancho de banda.</para>
|
||
|
||
<indexterm><primary>IPX/SPX</primary></indexterm>
|
||
<para>Un <quote>bridge</quote> Ethernet permite transmitir más
|
||
tráfico aparte del tráfico IP. Se puede transmitir
|
||
IPX/SPX o cualquier otro protocolo que se esté utilizando.</para>
|
||
</sect2>
|
||
</sect1>
|
||
|
||
<sect1 id="network-nis">
|
||
<sect1info>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Bill</firstname>
|
||
<surname>Swingle</surname>
|
||
<contrib>Escrito por </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Eric</firstname>
|
||
<surname>Ogren</surname>
|
||
<contrib>Ampliado por </contrib>
|
||
</author>
|
||
<author>
|
||
<firstname>Udo</firstname>
|
||
<surname>Erdelhoff</surname>
|
||
</author>
|
||
</authorgroup>
|
||
</sect1info>
|
||
<title>NIS/YP</title>
|
||
|
||
<sect2>
|
||
<title>¿Qué es esto?</title>
|
||
<indexterm><primary>NIS</primary></indexterm>
|
||
<indexterm><primary>Solaris</primary></indexterm>
|
||
<indexterm><primary>HP-UX</primary></indexterm>
|
||
<indexterm><primary>AIX</primary></indexterm>
|
||
<indexterm><primary>Linux</primary></indexterm>
|
||
<indexterm><primary>NetBSD</primary></indexterm>
|
||
<indexterm><primary>OpenBSD</primary></indexterm>
|
||
<para>NIS, siglas de Network Information Services (Servicios de
|
||
Información de Red), fué un servicio desarrollado por
|
||
Sun Microsystems para centralizar la administración de sistemas
|
||
&unix; (originalmente &sunos;). Actualmente se considera como un
|
||
estándar de la industria; los principales sistemas tipo &unix;
|
||
(&solaris;, HP-UX, &aix;, Linux, NetBSD, OpenBSD, &os;, etc)
|
||
implementan NIS.</para>
|
||
|
||
<indexterm><primary>yellow pages</primary><see>NIS</see></indexterm>
|
||
<para>NIS también se conocía como el servicio de
|
||
páginas amarillas pero debido a problemas legales debidos a
|
||
la propiedad de marcas comerciales, Sun tuvo que cambiar el nombre.
|
||
El antíguo término (<quote>Yellow Pages</quote> o yp)
|
||
todavía se ve y se utiliza con frecuencia.</para>
|
||
|
||
<indexterm>
|
||
<primary>NIS</primary>
|
||
<secondary>domains</secondary>
|
||
</indexterm>
|
||
<para>Se trata de un sistema cliente servidor basado en llamadas RPC que
|
||
permite a un grupo de máquinas que se encuentran definidas
|
||
dentro de un dominio administrativo NIS compartir un conjunto de
|
||
ficheros de configuración. Esto permite al administrador de
|
||
sistemas por un lado configurar clientes NIS de forma minimalista y
|
||
por otro lado centralizar la gestión de los ficheros de
|
||
configuración en una única ubicación (una sola
|
||
máquina).</para>
|
||
|
||
<indexterm><primary>Windows NT</primary></indexterm>
|
||
<para>Se trata de algo similar al sistema de dominio de &windowsnt;
|
||
aunque la implementación interna no se puede comparar, la
|
||
funcionalidad y el servicio obtenido son similares.</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Términos/procesos que debe usted conocer</title>
|
||
|
||
<para>Existen varios conceptos y varios procesos de usuario que el
|
||
usuario no versado en estos temas suele encontrarse la primera vez que
|
||
se intenta implantar un servicio de NIS en &os;, tanto si se intenta
|
||
configurar un servidor como si se intenta configurar un cliente:</para>
|
||
|
||
<indexterm>
|
||
<primary><application>portmap</application></primary>
|
||
</indexterm>
|
||
|
||
<informaltable>
|
||
<tgroup cols="2">
|
||
<thead>
|
||
<row>
|
||
<entry>Term</entry>
|
||
<entry>Description</entry>
|
||
</row>
|
||
</thead>
|
||
<tbody>
|
||
<row>
|
||
<entry>NIS domainname</entry>
|
||
<entry>Un servidor maestro de NIS y todos sus clientes
|
||
(incluyendo a sus servidores esclavos) poseen el mismo nombre
|
||
dominio NIS. Al igual que ocurre con el nombre de dominio de
|
||
&windowsnt;, el nombre de dominio de NIS no tiene nada que ver
|
||
con el nombre de dominio de DNS.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><application>portmap</application></entry>
|
||
<entry>Debe ejecutarse para que se activen las llamadas a
|
||
procedimientos remotos (Remote Procedure Call o RPC)
|
||
que son utilizadas por NIS. Si
|
||
<application>portmap</application> no se está ejecutando
|
||
no se podrá ejecutar ni clientes ni servidores de
|
||
NIS.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><application>ypbind</application></entry>
|
||
|
||
<entry><quote>Asocia</quote> un cliente con un servidor NIS.
|
||
Primeramente se lee el nombre de dominio NIS del sistema y
|
||
utilizando RPC se conecta con el servidor.
|
||
<application>ypbind</application> es la parte central de la
|
||
comunicación cliente servidor del sistema NIS;
|
||
si <application>ypbind</application> muere en una
|
||
máquina cliente, dicha máquina no podrá
|
||
acceder al servidor NIS.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><application>ypserv</application></entry>
|
||
<entry>Debe ejecutarse sólamente en los servidores NIS;
|
||
se trata del proceso servidor de NIS. Si &man.ypserv.8;
|
||
muere, el servidor no será capaz de responder a
|
||
peticiones NIS (no obstante, si se definen servidores NIS
|
||
esclavos la situación puede recuperarse). Existen
|
||
algunas implementaciones de NIS (no es el caso de &os;)
|
||
que no intentan conectarse con otro servidor si el servidor
|
||
con otro servidor si el servidor que se estaba
|
||
que se estaba utilizando muere. A menudo lo único que
|
||
se puede hacer en estos casos es reiniciar el servidor (el
|
||
proceso o la propia máquina) o el proceso
|
||
<application>ypbind</application> del cliente.</entry>
|
||
</row>
|
||
<row>
|
||
<entry><application>rpc.yppasswdd</application></entry>
|
||
<entry>Otro proceso que sólo debe ejecutarse en el
|
||
servidor maestro de NIS; se trata de un dæmon que permite
|
||
a los clientes de NIS modificar las contraseñas de los
|
||
usuarios. Si no se ejecuta este dæmon los usuarios
|
||
tendrán que entrar en el servidor maestro de NIS para
|
||
cambiar sus contraseñas allí.</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</informaltable>
|
||
<!-- XXX Missing: rpc.ypxfrd (not important, though) May only run
|
||
on the master -->
|
||
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>¿Cómo funciona?</title>
|
||
|
||
<para>Existen tres tipos de máquinas dentro del entorno
|
||
NIS: los servidores maestros, los servidores esclavos y los clientes
|
||
de NIS. Los servidores actúan como repositorios centrales para
|
||
almacenamiento de información de configuración.
|
||
Los servidores maestros mantienen una copia maestra de dicha
|
||
información, mientras que los servidores esclavos mantienen
|
||
copias de la información maestra por motivos de redundancia.
|
||
Los servidores se encargan de transmitir la información
|
||
necesaria a los clientes a petición de estos
|
||
últimos.</para>
|
||
|
||
<para>De esta forma se pueden compatir mucha información
|
||
contenida en varios archivos. Los ficheros <filename>
|
||
master.passwd</filename>, <filename>group</filename> y <filename>
|
||
hosts</filename> normalmente se comparten a través de NIS.
|
||
Siempre que un proceso en un cliente necesita información que,
|
||
en caso de no utilizar NIS, se podría recuperar de ficheros
|
||
locales, en este caso se envía una solicitud al servidor NIS con
|
||
el que nos encontramos asociados.</para>
|
||
|
||
<sect3>
|
||
<title>Clases de máquinas</title>
|
||
|
||
<itemizedlist>
|
||
<indexterm>
|
||
<primary>NIS</primary>
|
||
<secondary>master server</secondary>
|
||
</indexterm>
|
||
<listitem>
|
||
<para><emphasis>Servidor de NIS maestro</emphasis>.
|
||
Este servidor, semejante a un controlador de dominio primario de
|
||
&windowsnt; mantiene todos los archivos que utilizan los
|
||
clientes. Los ficheros <filename>passwd</filename>,
|
||
<filename>group</filename> y algunos otros se encuentran
|
||
ubicados en el servidor maestro.</para>
|
||
|
||
<note><para>Resulta posible configurar una máquina para que
|
||
actúe como servidor NIS maestro para más de un
|
||
dominio NIS. No obstante esta configuración no se va a
|
||
tratar en esta introducción, en la cual asumimos un
|
||
entorno NIS de tamaño relativamente
|
||
pequeño.</para></note>
|
||
</listitem>
|
||
<indexterm>
|
||
<primary>NIS</primary>
|
||
<secondary>slave server</secondary>
|
||
</indexterm>
|
||
<listitem>
|
||
<para><emphasis>Servidores de NIS esclavos</emphasis>.
|
||
Semejantes a los controladores de backup de &windowsnt;,
|
||
los servidores NIS esclavos se utilizan para proporcionar
|
||
redundancia en entornos de trabajo donde la disponibilidad del
|
||
servicio resulta muy importante. Además se utilizan para
|
||
distribuir la carga que normalmente soporta un servidor
|
||
maestro: los clientes de NIS siempre se asocian con el servidor
|
||
de NIS que posee mejor tiempo de respuesta, y esto
|
||
y esto también incluye a los servidores de NIS
|
||
esclavos.</para>
|
||
</listitem>
|
||
<indexterm>
|
||
<primary>NIS</primary>
|
||
<secondary>client</secondary>
|
||
</indexterm>
|
||
<listitem>
|
||
<para><emphasis>Clientes NIS</emphasis>. Los clientes NIS, de
|
||
forma semejante a las estaciones de trabajo de &windowsnt;, se
|
||
validan contra un servidor NIS (en el caso de &windowsnt; se
|
||
validan contra un controlador de dominio) para acceder al
|
||
sistema.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</sect3>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Uso de NIS/YP</title>
|
||
|
||
<para>Esta sección trata sobre cómo configurar y poner en
|
||
funcionamiento un entorno de NIS sencillo.</para>
|
||
|
||
<note><para>Esta sección supone que se está utilizando
|
||
utilizando &os; 3.3 o posteriores. Las instrucciones dadas
|
||
aquí <emphasis>probablemente</emphasis> funcionen
|
||
también en cualquier versión de &os; superior a la 3.0
|
||
pero no podemos garantizar que esto sea así.</para></note>
|
||
|
||
<sect3>
|
||
<title>Planificación</title>
|
||
|
||
<para>Vamos a suponer que somos el administrador de un pequeño
|
||
laboratorio de una universidad. En este laboratorio, compuesto por
|
||
15 máquinas &os;, actualmente no existe ningún punto
|
||
de administración centralizada; cada máquina posee sus
|
||
sus propios <filename>/etc/passwd</filename> y <filename>
|
||
/etc/master.passwd</filename>. Estos ficheros se encuentran
|
||
sincronizados el uno con el otro mediante intervención
|
||
manual; por tanto, cuando queramos añadir un usuario a
|
||
nuestro laboratorio tendremos que ejecutar
|
||
<command>adduser</command> en todas las máquinas.
|
||
Claramente esta situación tiene que cambiar, de tal forma que
|
||
hemos decidido crear un dominio NIS en el laboratorio usando dos
|
||
máquinas como servidores NIS.</para>
|
||
|
||
<para>La configuración de nuestro laboratorio debería ser
|
||
algo parecido a lo siguiente:</para>
|
||
|
||
<informaltable>
|
||
<tgroup cols="3">
|
||
<thead>
|
||
<row>
|
||
<entry>Nombre de máquina</entry>
|
||
<entry>Dirección IP</entry>
|
||
<entry>Papel</entry>
|
||
</row>
|
||
</thead>
|
||
<tbody>
|
||
<row>
|
||
<entry><hostid>ellington</hostid></entry>
|
||
<entry><hostid role="ipaddr">10.0.0.2</hostid></entry>
|
||
<entry>servidor NIS maestro</entry>
|
||
</row>
|
||
<row>
|
||
<entry><hostid>coltrane</hostid></entry>
|
||
<entry><hostid role="ipaddr">10.0.0.3</hostid></entry>
|
||
<entry>Servidor NIS esclavo</entry>
|
||
</row>
|
||
<row>
|
||
<entry><hostid>basie</hostid></entry>
|
||
<entry><hostid role="ipaddr">10.0.0.4</hostid></entry>
|
||
<entry>Estación de trabajo del profesorado</entry>
|
||
</row>
|
||
<row>
|
||
<entry><hostid>bird</hostid></entry>
|
||
<entry><hostid role="ipaddr">10.0.0.5</hostid></entry>
|
||
<entry>máquina cliente</entry>
|
||
</row>
|
||
<row>
|
||
<entry><hostid>cli[1-11]</hostid></entry>
|
||
<entry><hostid role="ipaddr">10.0.0.[6-17]</hostid></entry>
|
||
<entry>Resto de máquinas clientes</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</informaltable>
|
||
|
||
<para>Si se está configurando un esquema de NIS por primera vez
|
||
es una buena idea detenerse a pensar cómo queremos implantar
|
||
el sistema. Existen varias decisiones que se deben tomar
|
||
independientemente del tamaño de nuestra red.</para>
|
||
|
||
<sect4>
|
||
<title>Elección del nombre de dominio NIS</title>
|
||
|
||
<indexterm>
|
||
<primary>NIS</primary>
|
||
<secondary>domainname</secondary>
|
||
</indexterm>
|
||
<para>Este nombre puede no ser el <quote>nombre de
|
||
dominio</quote> al que estamos acostumbrados. Resulta más
|
||
preciso llamarlo <quote>nombre de dominio NIS</quote>.
|
||
Cuando un cliente genera peticiones de NIS que llegan a todas las
|
||
máquinas (broadcast) solicitando información se
|
||
incluye el nombre de dominio NIS que tiene configurado.
|
||
De esta forma, varios servidores de dominios distintos situados en
|
||
la misma red pueden discriminar las peticiones recibidas. Se puede
|
||
pensar en el nombre de dominio NIS como un identificador de grupos
|
||
de máquinas que se encuentran relacionados
|
||
administrativamente de alguna forma.</para>
|
||
|
||
<para>Algunas organizaciones eligen utilizar su nombre de dominio de
|
||
Internet como nombre de dominio NIS. Esto no se recomienda ya que
|
||
puede causar confusión cuando se intentan depurar problemas
|
||
de red. El nombre de dominio NIS debería ser un nombre
|
||
único dentro de nuestra red y resulta más
|
||
útil aún si el nombre elegido puede describir de
|
||
alguna forma al conjunto de máquinas que representa.
|
||
Por ejemplo el departamento de arte de la empresa Acme puede
|
||
utilizar como nombre de dominio <quote>acme-art</quote>.
|
||
En nuestro ejemplo hemos utilizado el nombre
|
||
<literal>test-domain</literal>.</para>
|
||
|
||
<indexterm><primary>SunOS</primary></indexterm>
|
||
<para>No obstante algunos sistemas operativos (de forma
|
||
notable &sunos;) utilizan como nombres de dominio nombres de
|
||
Internet. Si se poseen máquinas con esta
|
||
restricción no queda más remedio que
|
||
<emphasis>utilizar</emphasis> los nombres de dominio de Internet
|
||
como nombres de dominio NIS.</para>
|
||
</sect4>
|
||
|
||
<sect4>
|
||
<title>Requisitos físicos de los servidores</title>
|
||
|
||
<para>Existen varias cosas que debemos tener en cuenta cuando se
|
||
selecciona una máquina para actuar como servidor NIS.
|
||
Una de las características desafortunadas del servicio de
|
||
páginas amarillas es el alto nivel de dependencia que llegan
|
||
a tener los clientes respecto del servidor de NIS. Si el cliente
|
||
no puede contactar con el servidor NIS normalmente la
|
||
máquina se queda en un estado totalmente inutilizable.
|
||
La carencia de información de usuarios y grupos provoca que
|
||
las máquinas se bloqueen. Con esto en mente debemos
|
||
debemos asegurarnos de escoger un servidor de NIS que no se
|
||
reinicie de forma habitual o uno que no se utilice para
|
||
para desarrollar. Si se dispone de una red con poca carga
|
||
puede resultar aceptable colocar el servidor de NIS en una
|
||
máquina donde se ejecuten otros servicios pero en todo
|
||
momento se debe tener presente que si por cualquier motivo el
|
||
servidor de NIS quedara inutilizable afectaría a
|
||
<emphasis>todas</emphasis> las máquinas de forma
|
||
negativa.</para>
|
||
</sect4>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Servidores NIS</title>
|
||
|
||
<para>Las copias canónicas de toda la información que
|
||
mantiene el sistema de páginas amarillas se almacenan en una
|
||
única máquina denominada servidor maestro de NIS.
|
||
Las bases de datos utilizadas para almacenar la información
|
||
se denominan mapeos NIS. En &os; estas asociaciones o mapeos se
|
||
almacenan en el directorio <filename>/var/yp/[nombrededominio]</filename>
|
||
donde <filename>[nombrededominio]</filename> es el nombre del dominio
|
||
de NIS que el servidor gestiona. Un único servidor NIS puede
|
||
gestionar varios dominios al mismo tiempo de forma que resulta
|
||
posible tener varios directorios como el anterior, uno por cada
|
||
dominio soportado. Cada dominio posee su conjunto de mapeos
|
||
independiente y propio.</para>
|
||
|
||
<para>Los servidores maestro y esclavos manejan todas las peticiones de
|
||
a través del dæmon <command>ypserv</command>.
|
||
<command>ypserv</command> se responsabiliza de recibir
|
||
peticiones de los clientes NIS. Estas peticiones se traducen a una
|
||
ruta dentro del servidor. Esta ruta localiza un fichero de base de
|
||
datos determinado del servidor de NIS, y finalmente <command>
|
||
ypserv</command> se encarga de transmitir la información de
|
||
dicha base de datos de vuelta al cliente que la
|
||
solicitó.</para>
|
||
|
||
<sect4>
|
||
<title>Configuración de un servidor de NIS maestro</title>
|
||
<indexterm>
|
||
<primary>NIS</primary>
|
||
<secondary>server configuration</secondary>
|
||
</indexterm>
|
||
<para>La configuración de un servidor de NIS maestro puede
|
||
resultar relativamente sencilla dependiendo de las necesidades que
|
||
se tengan. &os; viene preconfigurado por defecto con un servicio
|
||
NIS. Todo lo que necesitamos es añadir la siguiente
|
||
línea en <filename>/etc/rc.conf</filename> y
|
||
&os; se encarga del resto.</para>
|
||
|
||
<procedure>
|
||
<step>
|
||
<para><programlisting>nisdomainname="test-domain"</programlisting>
|
||
Esta línea establece el nombre de dominio NIS como
|
||
<literal>test-domain</literal>, cuando se realiza la
|
||
configuración de la red (por ejemplo, después
|
||
de un reinicio).</para>
|
||
</step>
|
||
<step>
|
||
<para><programlisting>nis_server_enable="YES"</programlisting>
|
||
Esta variable indica a &os; que ejecute los procesos
|
||
necesarios para actuar como un servidor de NIS la
|
||
próxima vez que se configure el subsistema de
|
||
red.</para>
|
||
</step>
|
||
<step>
|
||
<para><programlisting>nis_yppasswdd_enable="YES"</programlisting>
|
||
Esto permite activar el dæmon
|
||
<command>rpc.yppasswdd</command> el cual, como se ha
|
||
mencionado anteriormente, permite a los usuarios realizar
|
||
cambios de contraseña desde las máquinas clientes
|
||
de NIS.</para>
|
||
</step>
|
||
</procedure>
|
||
|
||
<note>
|
||
<para>Dependiendo de la configuración de NIS podemos
|
||
necesitar añadir algunas entradas más. Consulte
|
||
la <link
|
||
linkend="network-nis-server-is-client">sección sobre
|
||
servidores NIS que también actúan como
|
||
clientes</link>, más adelante en el texto, para saber
|
||
más sobre esto.</para>
|
||
</note>
|
||
|
||
<para>Una vez hecho esto todo lo que tenemos que hacer es ejecutar
|
||
<command>/etc/netstart</command> como superusuario. Esta
|
||
orden realiza los pasos de configuración necesarios
|
||
utilizando los valores de las variables definidas en
|
||
<filename>/etc/rc.conf</filename>.</para>
|
||
</sect4>
|
||
|
||
<sect4>
|
||
<title>Inicialización de los mapeos de NIS</title>
|
||
<indexterm>
|
||
<primary>NIS</primary>
|
||
<secondary>maps</secondary>
|
||
</indexterm>
|
||
<para>Las <emphasis>asociaciones o mapeos de NIS</emphasis>
|
||
no son más que ficheros de base de datos.
|
||
Estos ficheros se generan a partir de los ficheros de
|
||
configuración contenidos en el directorio <filename>
|
||
etc/</filename> excepto para el caso del fichero <filename>
|
||
etc/master.passwd</filename>. Esto es así por una buena
|
||
razón ya que no suele ser buena idea propagar las
|
||
contraseñas de <username>root</username> y de otras cuentas
|
||
de administración a todos los servidores NIS del dominio.
|
||
servidores NIS del dominio. Así, antes de inicializar los
|
||
mapeos se debe ejecutar:</para>
|
||
|
||
<screen>&prompt.root; <userinput>cp /etc/master.passwd /var/yp/master.passwd</userinput>
|
||
&prompt.root; <userinput>cd /var/yp</userinput>
|
||
&prompt.root; <userinput>vi master.passwd</userinput></screen>
|
||
|
||
<para>Se deben borrar todas las entradas que hagan referencia a
|
||
cuentas del sistema
|
||
(<username>bin</username>, <username>tty</username>,
|
||
<username>kmem</username>, <username>games</username>,
|
||
etc), junto con cualquier cuenta que no deseemos que se transmita
|
||
a los clientes NIS (por ejemplo la cuenta de <username>
|
||
root</username> y cualquier otra cuenta con UID 0 (el del
|
||
superusuario)).</para>
|
||
|
||
<note><para>Asegúrese de que
|
||
<filename>/var/yp/master.passwd</filename> no se puede leer ni por
|
||
grupos ni por el resto de usuarios (modo 600). Utilice
|
||
<command>chmod</command> en caso de necesidad.</para></note>
|
||
|
||
<indexterm><primary>Tru64 UNIX</primary></indexterm>
|
||
<para>Una vez hecho esto es hora de inicializar las asociaciones de
|
||
NIS. &os; incluye un <quote>script</quote> denominado
|
||
<command>ypinit</command> para realizar esta tarea (consulte su
|
||
página del manual para obtener más
|
||
información). Recuerde que este <quote>script</quote> se
|
||
encuentra disponible en la mayoría de los sistemas &unix;,
|
||
pero no en todos. En sistemas Digital UNIX/Compaq Tru64 UNIX se
|
||
denomina <command>ypsetup</command>. Debido a que se pretende
|
||
generar asociaciones para un servidor NIS maestro vamos a
|
||
ejecutar <command>ypinit</command> con la opción
|
||
<option>-m</option>. A modo de ejemplo, suponiendo que todos los
|
||
pasos comentados anteriormente se han realizado con éxito,
|
||
ejecute:</para>
|
||
|
||
<screen>ellington&prompt.root; <userinput>ypinit -m test-domain</userinput>
|
||
Server Type: MASTER Domain: test-domain
|
||
Creating an YP server will require that you answer a few questions.
|
||
Questions will all be asked at the beginning of the procedure.
|
||
Do you want this procedure to quit on non-fatal errors? [y/n: n] <userinput>n</userinput>
|
||
Ok, please remember to go back and redo manually whatever fails.
|
||
If you don't, something might not work.
|
||
At this point, we have to construct a list of this domains YP servers.
|
||
rod.darktech.org is already known as master server.
|
||
Please continue to add any slave servers, one per line. When you are
|
||
done with the list, type a <control D>.
|
||
master server : ellington
|
||
next host to add: <userinput>coltrane</userinput>
|
||
next host to add: <userinput>^D</userinput>
|
||
The current list of NIS servers looks like this:
|
||
ellington
|
||
coltrane
|
||
Is this correct? [y/n: y] <userinput>y</userinput>
|
||
|
||
[..salida de la generacion de mapeos..]
|
||
|
||
NIS Map update completed.
|
||
ellington has been setup as an YP master server without any errors.</screen>
|
||
|
||
<para><command>ypinit</command> debería haber creado el
|
||
fichero <filename>/var/yp/Makefile</filename> a partir de
|
||
<filename>/var/yp/Makefile.dist</filename>.
|
||
Una vez creado este archivo presupone que se está usando un
|
||
entorno NIS con un único servidor utilizando
|
||
sólamente máquinas &os;. Debido a que
|
||
<literal>test-domain</literal> posee también un servidor
|
||
NIS esclavo se debe editar el fichero <filename>
|
||
var/yp/Makefile</filename>:</para>
|
||
|
||
<screen>ellington&prompt.root; <userinput>vi
|
||
/var/yp/Makefile</userinput></screen>
|
||
|
||
<para>Se debe comentar la línea que dice:</para>
|
||
|
||
<programlisting>NOPUSH = "True"</programlisting>
|
||
|
||
<para>(si es que no se encuentra ya comentada).</para>
|
||
</sect4>
|
||
|
||
<sect4>
|
||
<title>Configuración de un servidor NIS
|
||
esclavo</title>
|
||
<indexterm>
|
||
<primary>NIS</primary>
|
||
<secondary>slave server</secondary>
|
||
</indexterm>
|
||
<para>La configuración de un servidor NIS esclavo resulta ser
|
||
incluso más sencilla que la del maestro. Basta con entrar
|
||
en el servidor esclavo y editar <filename>/etc/rc.conf</filename>
|
||
de foma semejante a como se realizó en el apartado
|
||
anterior. La única diferencia consiste en que ahora debemos
|
||
utilizar la opción <option>-s</option> cuando ejecutemos
|
||
ejecutemos <command>ypinit</command>. A continuación del
|
||
parámetro <option>-s</option> se debe especificar el nombre
|
||
del servidor maestro de modo que la orden tendría que ser
|
||
algo parecido a esto:</para>
|
||
|
||
<screen>coltrane&prompt.root; <userinput>ypinit -s ellington test-domain</userinput>
|
||
|
||
Server Type: SLAVE Domain: test-domain Master: ellington
|
||
|
||
Creating an YP server will require that you answer a few questions.
|
||
Questions will all be asked at the beginning of the procedure.
|
||
|
||
Do you want this procedure to quit on non-fatal errors? [y/n: n] <userinput>n</userinput>
|
||
|
||
Ok, please remember to go back and redo manually whatever fails.
|
||
If you don't, something might not work.
|
||
There will be no further questions. The remainder of the procedure
|
||
should take a few minutes, to copy the databases from ellington.
|
||
Transferring netgroup...
|
||
ypxfr: Exiting: Map successfully transferred
|
||
Transferring netgroup.byuser...
|
||
ypxfr: Exiting: Map successfully transferred
|
||
Transferring netgroup.byhost...
|
||
ypxfr: Exiting: Map successfully transferred
|
||
Transferring master.passwd.byuid...
|
||
ypxfr: Exiting: Map successfully transferred
|
||
Transferring passwd.byuid...
|
||
ypxfr: Exiting: Map successfully transferred
|
||
Transferring passwd.byname...
|
||
ypxfr: Exiting: Map successfully transferred
|
||
Transferring group.bygid...
|
||
ypxfr: Exiting: Map successfully transferred
|
||
Transferring group.byname...
|
||
ypxfr: Exiting: Map successfully transferred
|
||
Transferring services.byname...
|
||
ypxfr: Exiting: Map successfully transferred
|
||
Transferring rpc.bynumber...
|
||
ypxfr: Exiting: Map successfully transferred
|
||
Transferring rpc.byname...
|
||
ypxfr: Exiting: Map successfully transferred
|
||
Transferring protocols.byname...
|
||
ypxfr: Exiting: Map successfully transferred
|
||
Transferring master.passwd.byname...
|
||
ypxfr: Exiting: Map successfully transferred
|
||
Transferring networks.byname...
|
||
ypxfr: Exiting: Map successfully transferred
|
||
Transferring networks.byaddr...
|
||
ypxfr: Exiting: Map successfully transferred
|
||
Transferring netid.byname...
|
||
ypxfr: Exiting: Map successfully transferred
|
||
Transferring hosts.byaddr...
|
||
ypxfr: Exiting: Map successfully transferred
|
||
Transferring protocols.bynumber...
|
||
ypxfr: Exiting: Map successfully transferred
|
||
Transferring ypservers...
|
||
ypxfr: Exiting: Map successfully transferred
|
||
Transferring hosts.byname...
|
||
ypxfr: Exiting: Map successfully transferred
|
||
|
||
coltrane has been setup as an YP slave server without any errors.
|
||
Don't forget to update map ypservers on ellington.</screen>
|
||
|
||
<para>En estos momentos debemos tener un nuevo directorio llamado
|
||
<filename>/var/yp/test-domain</filename>. Las copias de los
|
||
mapeos del servidor maestro se almacenan en dicho directorio.
|
||
Es nuestra responsabilidad como administradores asegurar que dichas
|
||
copias permanecen actualizadas en todo momento. La siguiente
|
||
entrada en el archivo <filename>/etc/crontab</filename> del
|
||
servidor esclavo se encarga de realizar esta tarea:</para>
|
||
|
||
<programlisting>20 * * * * root /usr/libexec/ypxfr passwd.byname
|
||
21 * * * * root /usr/libexec/ypxfr passwd.byuid</programlisting>
|
||
|
||
<para>Estas dos líneas obligan al servidor esclavo a
|
||
sincronizar los mapeos con el servidor maestro. Estas entradas no
|
||
son obligatorias ya que el servidor maestro siempre intenta
|
||
comunicar cualquier cambio que se produzca en sus asociaciones
|
||
a todos los servidores esclavos ya que la información de,
|
||
esclavos, ya que la información de, por ejemplo,
|
||
contraseñas es de vital importancia para el funcionamiento
|
||
de los sistemas que dependen del servidor. No obstante es una
|
||
buena idea obligar a que se realicen estos cambios mediante las
|
||
entradas anteriores. Esto resulta ser incluso más
|
||
importante en redes de sobrecargadas donde las actualizaciones de
|
||
asociaciones pueden algunas veces no llegar a realizarse de forma
|
||
completa.</para>
|
||
|
||
<para>A continuación se ejecuta
|
||
<command>/etc/netstart</command> en el servidor esclavo de igual
|
||
de igual forma que se hizo con el servidor maestro; esto relanza
|
||
de nuevo el servidor de NIS.</para>
|
||
</sect4>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Clientes NIS</title>
|
||
|
||
<para>Un cliente de NIS establece lo que se conoce con el nombre de
|
||
asociación (bind en inglés) con un servidor NIS
|
||
NIS determinado utilizando el dæmon <command>
|
||
ypbind</command>. <command>ypbind</command> comprueba el dominio
|
||
por defecto del sistema (especificado mediante
|
||
<command>domainname</command>) y comienza a enviar peticiones
|
||
RPC a todos los elementos de la red local (broadcast). Estas
|
||
peticiones especifican el nombre del dominio con el que se quiere
|
||
establecer la asociación. Si esta petición alcanza una
|
||
petición alcanza un servidor NIS configurado para servir dicho
|
||
dominio el servidor responde a la petición e
|
||
<command>ypbind</command> almacenará la dirección de
|
||
dicho servidor. Si existen varios servidores disponibles (un maestro
|
||
y varios esclavos, por ejemplo), <command>ypbind</command>
|
||
utilizará la dirección del primero en responder.
|
||
A partir de este punto el cliente dirigirá el resto de sus
|
||
peticiones NIS directamente a la dirección IP almacenada.
|
||
Ocasionalmente <command>ypbind</command> envía un
|
||
<quote>ping</quote> sobre el servidor para comprobar que en efecto
|
||
se encuentra funcionando. Si no se recibe contestación al
|
||
ping dentro de un espacio de tiempo determinado
|
||
<command>ypbind</command> marca el dominio como <quote>sin
|
||
asociar</quote> y comienza de nuevo a inundar la red con la esperanza
|
||
de localizar algún otro servidor NIS.</para>
|
||
|
||
<sect4>
|
||
<title>Configuración de un cliente NIS</title>
|
||
<indexterm>
|
||
<primary>NIS</primary>
|
||
<secondary>client configuration</secondary>
|
||
</indexterm>
|
||
<para>La configuración de un cliente &os; de NIS resulta ser
|
||
una operación extremadamente sencilla.</para>
|
||
|
||
<procedure>
|
||
<step>
|
||
<para>Editar el fichero
|
||
<filename>/etc/rc.conf</filename> y añadir las
|
||
siguientes líneas para establecer el nombre de dominio
|
||
NIS y para que se ejecute
|
||
<command>ypbind</command> al arranque de la red:</para>
|
||
|
||
<programlisting>nisdomainname="test-domain"
|
||
nis_client_enable="YES"</programlisting>
|
||
</step>
|
||
|
||
<step>
|
||
<para>Para importar todas las entradas de contraseñas del
|
||
servidor de NIS hay que eliminar todas las cuentas de usuario
|
||
de <filename>/etc/master.passwd</filename> y utilizar
|
||
<command>vipw</command> para añadir la siguiente
|
||
línea al final de dicho fichero:</para>
|
||
|
||
<programlisting>+:::::::::</programlisting>
|
||
|
||
<note>
|
||
<para>Esta línea permite que cualquiera abra una cuenta
|
||
en local, siempre que dicha cuenta se encuentre definida en
|
||
las asociaciones de cuentas y contraseñas del
|
||
servidor NIS. Existen varias formas de configurar los
|
||
clientes NIS modificando esta línea. Consulte la
|
||
<link
|
||
linkend="network-netgroups">sección sobre
|
||
netgroups</link> que se encuentra más adelante en
|
||
este mismo texto. Si quiere saber más puede consultar
|
||
el libro de O'Reilly <literal>Managing NFS and
|
||
NIS</literal>.</para>
|
||
</note>
|
||
|
||
<note>
|
||
<para>Se debe mantener al menos una cuenta local (por ejemplo,
|
||
una cuenta que no se importe a través de NIS) en
|
||
el fichero <filename>/etc/master.passwd</filename> y
|
||
además dicha cuenta debería ser miembro del
|
||
grupo <groupname>wheel</groupname>. Si algo va mal con el
|
||
procedimiento descrito esta cuenta se puede utilizar
|
||
para entrar en la máquina cliente de forma remota
|
||
para posteriormente convertirse en superusuario e intentar
|
||
solucionar el problema.</para>
|
||
</note>
|
||
</step>
|
||
|
||
<step>
|
||
<para>Para importar todas las entradas de grupo posibles del
|
||
servidor NIS se debe añadir la siguiente línea
|
||
al fichero <filename>/etc/group</filename>:</para>
|
||
|
||
<programlisting>+:*::</programlisting>
|
||
</step>
|
||
</procedure>
|
||
|
||
<para>Después de completar estos pasos deberímos ser
|
||
capaces de ejecutar <command>ypcat passwd</command> y ver la
|
||
asociación de contraseñas que se encuentra en el
|
||
servidor de NIS</para>
|
||
</sect4>
|
||
</sect3>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Seguridad en NIS</title>
|
||
|
||
<para>En general cualquier usuario remoto puede realizar peticiones de
|
||
RPC a &man.ypserv.8; y recuperar los contenidos de las asociaciones
|
||
de NIS siempre y cuando el usuario remoto conozca el nombre de
|
||
dominio de NIS. Para evitar este tipo de transacciones no autorizadas,
|
||
&man.ypserv.8; soporta una característica denominada
|
||
<quote>securenets</quote> la cual se puede utilizar para limitar el
|
||
acceso a un determinado conjunto de máquinas. En el arranque
|
||
&man.ypserv.8; intenta cargar la información de
|
||
<quote>securenets</quote> a partir de un fichero denominado
|
||
<filename>/var/yp/securenets</filename>.</para>
|
||
|
||
<note>
|
||
<para>Esta ruta de fichero varía dependiendo del camino
|
||
especificado con la opción <option>-p</option>. Dicho fichero
|
||
contiene entradas compuestas de, por un lado, un rango de red y por
|
||
otro una máscara de red, separados por espacios en blanco.
|
||
Las líneas que comienzan por <quote>#</quote> se consideran
|
||
comentarios. A continuación se muestra un ejemplo de un
|
||
fichero <quote>securenet</quote>:</para>
|
||
</note>
|
||
|
||
<programlisting># admitir conexiones desde localhost -- obligatorio
|
||
127.0.0.1 255.255.255.255
|
||
# admitir conexiones desde cualquier host
|
||
# on the 192.168.128.0 network
|
||
192.168.128.0 255.255.255.0
|
||
# admitir conexiones desde cualquier host
|
||
# between 10.0.0.0 to 10.0.15.255
|
||
# esto incluye las maquinas en el 'testlab'
|
||
10.0.0.0 255.255.240.0</programlisting>
|
||
|
||
<para>Si &man.ypserv.8; recibe una petición de una
|
||
dirección que coincide con alguna de las reglas especificadas
|
||
en el fichero se procesa la petición. Si no existe ninguna
|
||
coincidencia la petición se rechaza y se graba un mensaje de
|
||
aviso. Si el archivo
|
||
<filename>/var/yp/securnets</filename> no existe
|
||
<command>ypserv</command> acepta conexiones de cualquier
|
||
máquina.</para>
|
||
|
||
<para>El programa <command>ypserv</command> también posee soporte
|
||
para el paquete de Wietse Venema denominado <application>
|
||
tcpwrapper</application>. Este paquete permite utilizar los ficheros
|
||
de configuración de <application>tcpwrapper</application> para
|
||
realizar control de acceso en lugar de utilizar <filename>
|
||
var/yp/securenets</filename>.</para>
|
||
|
||
<note>
|
||
<para>Aunque ambos mecanismos de control de acceso proporcionan un
|
||
grado de seguridad mayor que no utilizar nada resultan vulnerables
|
||
a ataques de <quote>falsificación de IPs</quote>. El
|
||
cortafuegos de la red donde se implanta el servicio de NIS
|
||
debería encargarse de bloquear el tráfico
|
||
específico de dicho servicio.</para>
|
||
|
||
<para>Los servidores que utilizan
|
||
<filename>/var/yp/securenets</filename>
|
||
pueden no prestar servicio a clientes NIS legítimos cuando se
|
||
trabaja con implementaciones arcaicas de TCP/IP. Algunas de estas
|
||
implementaciones ponen a cero todos los bits de máquina
|
||
cuando se realizan broadcast y/o pueden fallar al especificar la
|
||
máscara de red en el mismo caso, por citar algunos
|
||
ejemplos. Mientras que algunos de estos problemas se pueden
|
||
solucionar variando la configuración del cliente en otros
|
||
casos podemos vernos obligados a prescindir del cliente en
|
||
cuestión o a prescindir del fichero <filename>
|
||
var/yp/securenets</filename>.</para>
|
||
|
||
<para>Se desaconseja la utilización de <filename>
|
||
var/yp/securenets</filename> en un sistema con una
|
||
implementación arcaica de TCP/IP y puede suponer una
|
||
pérdida de funcionalidad para grandes zonas de la red.</para>
|
||
|
||
<indexterm><primary>tcpwrapper</primary></indexterm>
|
||
<para>La utilización del paquete
|
||
<application>tcpwrapper</application> incrementa la latencia del
|
||
servidor NIS. El retardo adicional introducido puede ser lo
|
||
suficientemente grande como para causar la expiración de
|
||
ciertos temporizadores de los programas clientes, especialmente en
|
||
redes muy cargadas o con servidores de NIS lentos. Si se
|
||
experimentan estos síntomas en varias máquinas
|
||
clientes, puede ser conveniente convertir dichas máquinas
|
||
en servidores NIS esclavos y obligarlas a asociarse con ellas
|
||
mismas.</para>
|
||
</note>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Prohibir el acceso a determinados usuarios</title>
|
||
|
||
<para>En nuestro laboratorio de ejemplo existe una
|
||
máquina denominada <hostid>basie</hostid> que
|
||
actúa sólo como una estación de trabajo para el
|
||
profesorado. No queremos sacar a esta máquina del dominio NIS
|
||
pero nos damos cuenta de que el fichero <filename>passwd</filename>
|
||
que se encuentra en el servidor de NIS posee cuentas tanto para
|
||
profesores como para alumnos. ¿Qué podemos
|
||
hacer?.</para>
|
||
|
||
<para>Existe una forma de prohibir el acceso a determinados usuarios
|
||
sobre una determinada máquina incluso aunque se encuentren dados
|
||
de alta en la base de datos de NIS. Para realizar esto todo lo que
|
||
debemos hacer es añadir
|
||
<literal>-<replaceable>nombredeusuario</replaceable></literal> al final del
|
||
fichero <filename>/etc/master.passwd</filename> en la máquina
|
||
cliente donde <replaceable>nombredeusuario</replaceable> es el nombre
|
||
de usuario del usuario al que queremos prohibirle el acceso.
|
||
Esto se debe realizar a poder ser mediante
|
||
<command>vipw</command> ya que <command>vipw</command> realiza
|
||
comprobaciones de seguridad sobre los cambios realizados y
|
||
además se encarga de reconstruir la base de datos de
|
||
contraseñas cuando se termina la edición. Por ejemplo,
|
||
si quisiéramos prohibir el acceso al usuario <username>
|
||
bill</username> a la máquina <hostid>basie</hostid>
|
||
haríamos:</para>
|
||
|
||
|
||
<screen>basie&prompt.root; <userinput>vipw</userinput>
|
||
<userinput>[añadimos -bill al final y salimos]</userinput>
|
||
vipw: rebuilding the database...
|
||
vipw: done
|
||
|
||
basie&prompt.root; <userinput>cat /etc/master.passwd</userinput>
|
||
|
||
root:[password]:0:0::0:0:The super-user:/root:/bin/csh
|
||
toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh
|
||
daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin
|
||
operator:*:2:5::0:0:System &:/:/sbin/nologin
|
||
bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin
|
||
tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin
|
||
kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin
|
||
games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin
|
||
news:*:8:8::0:0:News Subsystem:/:/sbin/nologin
|
||
man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin
|
||
bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin
|
||
uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
|
||
xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin
|
||
pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin
|
||
nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin
|
||
+:::::::::
|
||
-bill
|
||
|
||
basie&prompt.root;</screen>
|
||
</sect2>
|
||
|
||
<sect2 id="network-netgroups">
|
||
<sect2info>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Udo</firstname>
|
||
<surname>Erdelhoff</surname>
|
||
<contrib>Escrito por </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
</sect2info>
|
||
|
||
<title>Uso de Netgroups</title>
|
||
<indexterm><primary>netgroups</primary></indexterm>
|
||
|
||
<para>El método descrito en la sección anterior funciona
|
||
razonablemente bien si las reglas especiales se definen para un
|
||
conjunto pequeño de usuarios y/o máquinas. En dominios
|
||
admnistrativos grandes puede que se nos <emphasis>olvide</emphasis>
|
||
prohibir el acceso a algún usuario en determinadas
|
||
máquinas perdiendo de esta forma el principal beneficio de
|
||
utilizar el servicio de páginas amarillas:<emphasis>
|
||
administración centralizada</emphasis>.</para>
|
||
|
||
<para>La solución creada por los desarrolladores de NIS se
|
||
denomina <emphasis>netgroups</emphasis>. Su propósito se
|
||
asemeja al concepto de grupos utilizado por los sistemas &unix;. La
|
||
diferencia principal es la carencia de un identificador
|
||
numérico y la habilidad para definir un <quote>netgroup</quote>
|
||
que incluye tanto a cuentas de usuario como a otros
|
||
<quote>netgroups</quote>.</para>
|
||
|
||
<para>Los netgroups se desarrollaron para gestionar redes grandes y
|
||
y complejas con cientos de usuarios y máquinas. Por un lado
|
||
esto es una Cosa Buena si nos encontramos en tal situación
|
||
pero por otro lado esta complejidad añadida hace que sea casi
|
||
imposible de explicar a través de ejemplos sencillos. El
|
||
ejemplo que va a utilizar en lo que queda de sección
|
||
ilustrará este hecho.</para>
|
||
|
||
<para>Vamos a suponer que la exitosa introducción del servicio de
|
||
páginas amarillas en nuestro laboratorio ha llamado la
|
||
atención de nuestros jefes. Nuestra siguiente tarea consiste en
|
||
extender el dominio de NIS para que cubra otras máquinas del
|
||
campus. Las tablas que se muestran a continuación contienen los
|
||
nombres de los nuevos usuarios y máquinas junto con una breve
|
||
descripción de ellas.</para>
|
||
|
||
<informaltable>
|
||
<tgroup cols="2">
|
||
<thead>
|
||
<row>
|
||
<entry>Nombre del Usuario/usuarios</entry>
|
||
<entry>Descripción</entry>
|
||
</row>
|
||
</thead>
|
||
|
||
<tbody>
|
||
<row>
|
||
<entry><username>alpha</username>, <username>beta</username></entry>
|
||
<entry>Empleados normales del departamento de IT</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><username>charlie</username>, <username>delta</username></entry>
|
||
<entry>Los nuevos aprendices del departamento de IT</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><username>echo</username>, <username>foxtrott</username>, <username>golf</username>, ...</entry>
|
||
<entry>Empleados normales</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><username>able</username>, <username>baker</username>, ...</entry>
|
||
<entry>Los actuales internos</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</informaltable>
|
||
|
||
<informaltable>
|
||
<tgroup cols="2">
|
||
<thead>
|
||
<row>
|
||
<entry>Nombre de la Máquina(s)</entry>
|
||
<entry>Descripción</entry>
|
||
</row>
|
||
</thead>
|
||
|
||
<tbody>
|
||
<row>
|
||
<!-- Nombres provenientes de "Buenos Presagios" de Neil Gaiman y
|
||
Terry Pratchett. Muchas gracias por ese libro
|
||
tan brillante. -->
|
||
<!-- Nota del Revisor: No era del todo necesario traducir los
|
||
nombres de los hosts pero siendo el revisor fan convicto y
|
||
confeso de Terry Pratchett no ha habido mas remedio -->
|
||
<entry><hostid>guerra</hostid>, <hostid>muerte</hostid>,
|
||
<hostid>hambre</hostid>,
|
||
<hostid>peste</hostid></entry>
|
||
<entry>Los servidores más
|
||
importantes. Sólo los empleados de IT pueden
|
||
entrar en estas máquinas</entry>
|
||
</row>
|
||
<row>
|
||
<!-- omitimos gula porque estaba muy gorda -->
|
||
<entry><hostid>orgullo</hostid>, <hostid>avaricia</hostid>,
|
||
<hostid>envidia</hostid>, <hostid>ira</hostid>,
|
||
<hostid>lujuria</hostid>, <hostid>pereza</hostid></entry>
|
||
<entry>Servidores de menor importancia. Todos los miembros del
|
||
departamento de IT pueden entrar en ellos.</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><hostid>uno</hostid>, <hostid>dos</hostid>,
|
||
<hostid>tres</hostid>, <hostid>cuatro</hostid>,
|
||
...</entry>
|
||
<entry>Estaciones de trabajo ordinarias. Sólo los
|
||
empleados <emphasis>actuales</emphasis> pueden utilizar estas
|
||
máquinas.</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><hostid>trashcan</hostid></entry>
|
||
<entry>Una máquina muy vieja sin ningún dato
|
||
dato crítico. Incluso los internos pueden utilizar
|
||
esta máquina.</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</informaltable>
|
||
|
||
<para>Si se trata de implementar estas restricciones a nivel de usuario
|
||
particular tendríamos que añadir una línea
|
||
<literal>-<replaceable>usuario</replaceable></literal> a cada fichero
|
||
<filename>passwd</filename> del sistema para cada usuario que tuviera
|
||
prohibido el acceso a dicho sistema. Si nos olvidamos de una sola
|
||
entrada podrímos tener serios problemas. Puede ser factible
|
||
realizar esta configuración cuando se instala el servicio pero
|
||
no obstante el riesgo que corremos al mantener este sistema de
|
||
restricciones en el día día es muy alto. Después
|
||
de todo Murphy era un optimista.</para>
|
||
|
||
<para>La gestión de esta situación mediante netgroups
|
||
ofrece varias ventajas. Cada usuario no tiene que tratarse de una
|
||
forma individualizada; basta con añadir un usuario a uno o
|
||
más netgroups y posteriormente permitir o prohibir el acceso
|
||
para todos los usuarios del netgroup. Si se añade una nueva
|
||
máquina al servicio de NIS simplemente tendremos que definir
|
||
restricciones de acceso para los netgroups definidos en la
|
||
red. Si se añade un nuevo usuario bastará con
|
||
añadir dicho usuario a un netgroup existente. Estos cambios son
|
||
independientes unos de otros: se acabó la necesidad de aplicar
|
||
la frase <quote>por cada combinación de usuario y máquina
|
||
haga esto y esto</quote>. Si hemos planificado nuestro servicio de
|
||
NIS cuidadosamente, sólo tendremos que modificar un fichero de
|
||
configuración en un determinado servidor para permitir o denegar
|
||
estos accesos.</para>
|
||
|
||
<para>El primer paso consiste en la inicialización de la
|
||
asociación o mapeo del netgroup. La orden de &os;
|
||
&man.ypinit.8; no crea este mapeo por defecto pero una vez creado
|
||
será tenido en cuenta por la implementación de NIS.
|
||
Para crear una asociación vacía simplemente
|
||
escriba:</para>
|
||
|
||
<screen>ellington&prompt.root; <userinput>vi /var/yp/netgroup</userinput></screen>
|
||
|
||
<para>y comienze a añadir contenido. En nuestro ejemplo
|
||
necesitamos al menos cuatro netgroups: empleados de IT,
|
||
aprendices de IT, empleados normales e internos.</para>
|
||
|
||
<programlisting>IT_EMP (,alpha,test-domain) (,beta,test-domain)
|
||
IT_APP (,charlie,test-domain) (,delta,test-domain)
|
||
USERS (,echo,test-domain) (,foxtrott,test-domain) \
|
||
(,golf,test-domain)
|
||
INTERNS (,able,test-domain) (,baker,test-domain)</programlisting>
|
||
|
||
<para><literal>IT_EMP</literal>, <literal>IT_APP</literal> etc.
|
||
son los nombres de los netgroups. Cada conjunto delimitado por
|
||
paréntesis define una o más cuentas como pertenecientes
|
||
al netgroup. Existen tres campos definidos dentro de dichos de dichos
|
||
grupos:</para>
|
||
|
||
<orderedlist>
|
||
<listitem>
|
||
<para>El nombre de las máquinas donde los siguientes items
|
||
son aplicables. Si no se especifica un nombre de
|
||
máquina la entrada se aplica a todas las máquinas
|
||
existentes. Si se especifica una máquina determinada
|
||
entraremos en un mundo lleno de horrores y confusiones así
|
||
que mejor no hacerlo.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>El nombre de la cuenta que pertenece al netgroup que estamos
|
||
definiendo.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>El dominio NIS donde reside la cuenta. Se pueden importar
|
||
cuentas de otros dominios NIS (en caso de que usted pertenezca al
|
||
extraño grupo de personas que gestionan más de un
|
||
dominio NIS.</para>
|
||
</listitem>
|
||
</orderedlist>
|
||
|
||
<para>Cada uno de estos campos puede contener comodines. Consulte
|
||
&man.netgroup.5; para obtener más detalles.</para>
|
||
|
||
<note>
|
||
<indexterm><primary>netgroups</primary></indexterm>
|
||
<para>No se deben utilizar nombres de los netgroups superiores
|
||
a ocho caracteres, especialmente si las máquinas de nuestro
|
||
dominio utilizan sistemas operativos variados. Los nombres son
|
||
sensibles a las mayúsculas/minúsculas: se recomienda
|
||
utilizar nombres en mayúsculas para distinguirlos de los
|
||
usuarios o máquinas.</para>
|
||
|
||
<para>Algunos clientes de NIS (distintos de los clientes &os;) no
|
||
pueden gestionar netgroups con un gran número de entradas.
|
||
Por ejemplo algunas versiones antiguas de &sunos; comienzan a
|
||
presentar problemas si un netgroup contiene más de
|
||
<emphasis>quince entradas</emphasis>. Se puede solventar este
|
||
problema creando varios sub-netgroups de como mucho quince usuarios
|
||
y finalmente creando el verdadero netgroup compuesto por los
|
||
sub-netgroups:</para>
|
||
|
||
<programlisting>BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...]
|
||
BIGGRP2 (,joe16,domain) (,joe17,domain) [...]
|
||
BIGGRP3 (,joe31,domain) (,joe32,domain)
|
||
BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3</programlisting>
|
||
|
||
<para>Se puede repetir este proceso si se tienen que definir
|
||
más de 225 usuarios dentro de un único netgroup.</para>
|
||
</note>
|
||
|
||
<para>La activación y distribución de nuestro nuevo mapeo
|
||
NIS resulta sencillo:</para>
|
||
|
||
<screen>ellington&prompt.root; <userinput>cd /var/yp</userinput>
|
||
ellington&prompt.root; <userinput>make</userinput></screen>
|
||
|
||
<para>Esto genera las tres asociaciones NIS
|
||
<filename>netgroup</filename>, <filename>netgroup.byhost</filename> y
|
||
<filename>netgroup.byuser</filename>. Utilice &man.ypcat.1; para
|
||
comprobar si el nuevo mapeo NIS se encuentra disponible:</para>
|
||
|
||
<screen>ellington&prompt.user; <userinput>ypcat -k netgroup</userinput>
|
||
ellington&prompt.user; <userinput>ypcat -k netgroup.byhost</userinput>
|
||
ellington&prompt.user; <userinput>ypcat -k netgroup.byuser</userinput></screen>
|
||
|
||
<para>La salida de la primera orden debería parecerse a los
|
||
contenidos del fichero
|
||
<filename>/var/yp/netgroup</filename>. La segunda orden no
|
||
mostrará ninguna salida salvo que se hayan especificado
|
||
netgroups específicos para máquinas. La tercera orden
|
||
se puede utilizar para obtener la lista de los netgroups a los que
|
||
petenece un determinado usuario.</para>
|
||
|
||
<para>La configuración del cliente es bastante simple. Para
|
||
configurar el servidor <hostid>guerra</hostid> se debe ejecutar
|
||
&man.vipw.8; y sustituír la línea</para>
|
||
|
||
<programlisting>+:::::::::</programlisting>
|
||
|
||
<para>por</para>
|
||
|
||
<programlisting>+@IT_EMP:::::::::</programlisting>
|
||
|
||
<para>Ahora sólo se importan los datos para los usuarios
|
||
que se encuentren definidos en el netgroup
|
||
<literal>IT_EMP</literal>; dichos datos se importan en la base de datos
|
||
de contraseñas de <hostid>guerra</hostid> y sólo se
|
||
permite el acceso a estos usuarios.</para>
|
||
|
||
<para>Por desgraciaesta información también se aplica a la
|
||
función <literal>~</literal> del shell y a todas las rutinas que
|
||
traducen nombres de usuarios con los correspondientes identificadores
|
||
númericos de usuario (uid). En otras palabras, la orden
|
||
<command>cd
|
||
~</command> no va a funcionar, <command>ls
|
||
-l</command> muestra el identificador numérico en lugar del
|
||
nombre de usuario y <command>find . -user joe
|
||
-print</command> produce un error de <errorname>
|
||
No such user</errorname> (<quote>Usuario desconocido</quote>). Para
|
||
solucionar esto debemos importar todas las entradas de usuario en la
|
||
máquina cliente NIS pero sin permitirles el acceso.</para>
|
||
|
||
<para>Esto se puede realizar añadiendo otra línea
|
||
al fichero <filename>/etc/master.passwd</filename>. Esta línea
|
||
debería contener lo siguiente:</para>
|
||
|
||
<para><literal>+:::::::::/sbin/nologin</literal>, lo que significa que se
|
||
<quote>importen todas las entradas pero que se reemplace el shell por
|
||
<filename>/sbin/nologin</filename></quote>. Se puede sustituir
|
||
cualquier campo de la entrada de contraseñas especificando un
|
||
valor concreto para dicho campo en el fichero local
|
||
local <filename>/etc/master.passwd</filename>.</para>
|
||
|
||
<!-- Been there, done that, got the scars to prove it - ue -->
|
||
<warning>
|
||
<para>Asegúrese de que la línea
|
||
<literal>+:::::::::/sbin/nologin</literal> se sitúa
|
||
después de
|
||
<literal>+@IT_EMP:::::::::</literal>. Si esto no se cumple todas las
|
||
cuentas de usuario importadas del servidor NIS poseerán
|
||
<filename>/sbin/nologin</filename> como shell de acceso.</para>
|
||
</warning>
|
||
|
||
<para>Después de este cambio si se introduce un nuevo empleado
|
||
en el departamento de IT basta con cambiar una asociación de
|
||
NIS. Se podría aplicar una aproximación similar para los
|
||
servidores menos importantes sustituyendo la cadena
|
||
<literal>+:::::::::</literal> en las versiones locales del fichero
|
||
<filename>/etc/master.passwd</filename> por algo parecido a
|
||
esto:</para>
|
||
|
||
<programlisting>+@IT_EMP:::::::::
|
||
+@IT_APP:::::::::
|
||
+:::::::::/sbin/nologin</programlisting>
|
||
|
||
<para>Las líneas correspondientes para las estaciones de trabajo
|
||
normales podrían ser:</para>
|
||
|
||
<programlisting>+@IT_EMP:::::::::
|
||
+@USERS:::::::::
|
||
+:::::::::/sbin/nologin</programlisting>
|
||
|
||
<para>Y parece que todos nuestros problemas de gestión han
|
||
desaparecido; hasta que unas semanas más tarde se produce un
|
||
cambio en la política de gestión: el depatamento de IT
|
||
comienza a alquilar interinos. Los interinos de IT pueden utilizar
|
||
las estaciones de trabajo normales y los servidores menos importantes
|
||
y los aprendices de IT pueden acceder a los servidores principales.
|
||
No nos queda más remedio que añadir un nuevo netgroup
|
||
denominado <literal>IT_INTERN</literal> y añadir los nuevos
|
||
interinos de IT a este nuevo grupo y comenzar a cambiar la
|
||
la configuración de cada máquina, una por una...
|
||
Como dice el antiguo proverbio: <quote>Errores en la
|
||
planificación centralizada conllevan grandes quebraderos de
|
||
de cabeza globales</quote>.</para>
|
||
|
||
<para>La habilidad que posee NIS para crear netgroups a partir de otros
|
||
netgroups se puede utilizar para evitar la situación
|
||
anterior. Una posibilidad consiste en la creación de netgroups
|
||
basados en roles. Por ejemplo, se podría crear un netgroup
|
||
denominado <literal>BIGSRV</literal> para definir las restricciones
|
||
de acceso para los servidores importantes, otro grupo denominado
|
||
<literal>USERBOX</literal> para las estaciones de trabajo... Cada uno
|
||
de estos netgroups podría contener los netgroups que pueden
|
||
acceder a dichas máquinas. Las nuevas entradas para nuestro
|
||
mapeo NIS de netgroups sería algo así:</para>
|
||
|
||
<programlisting>BIGSRV IT_EMP IT_APP
|
||
SMALLSRV IT_EMP IT_APP ITINTERN
|
||
USERBOX IT_EMP ITINTERN USERS</programlisting>
|
||
|
||
<para>Este método de definir restricciones de acceso funciona
|
||
razonablemente bien si podemos definir grupos de máquinas
|
||
que posean restricciones semejantes. Por desgracia lo normal es que
|
||
este caso resulta ser una excepción más que una regla.
|
||
En la mayor parte de las ocasiones necesitaremos definir restricciones
|
||
de acceso en función de máquinas individuales.</para>
|
||
|
||
<para>Las definiciones de netgroups específicos para determinadas
|
||
máquinas constituyen el segundo método que se puede
|
||
utilizar para gestionar el cambio de política del ejemplo
|
||
que estamos explicando. En nuestro caso el fichero
|
||
<filename>/etc/master.passwd</filename> de cada máquina
|
||
contiene dos líneas que comienzan por
|
||
<quote>+</quote>. La primera de ellas añade un netgroup con las
|
||
cuentas que pueden acceder a esa máquina, mientras que la
|
||
segunda añade el resto de cuentas con shell
|
||
el resto de cuentas con shell
|
||
<filename>/sbin/nologin</filename>. Es una buena idea utilizar la
|
||
versión <quote>todo en mayúsculas</quote> del nombre de
|
||
máquina como el nombre del netgroup. En otras palabras, las
|
||
líneas deberían ser como la siguiente:</para>
|
||
|
||
<programlisting>+@<replaceable>BOXNAME</replaceable>:::::::::
|
||
+:::::::::/sbin/nologin</programlisting>
|
||
|
||
<para>Una vez que hemos completado esta tarea para todas las
|
||
máquinas nunca más resultará necesario modificar
|
||
las versiones locales de <filename>/etc/master.passwd</filename>.
|
||
Los futuros cambios se pueden gestionar simplemente modificando el
|
||
mapeo o asociación de NIS. A continuación se muestra un
|
||
mapeo de netgroups para el escenario que se está explicando
|
||
junto con algunas buenas ideas:</para>
|
||
|
||
<programlisting># Definimos antes que nada los grupos de usuarios
|
||
IT_EMP (,alpha,test-domain) (,beta,test-domain)
|
||
IT_APP (,charlie,test-domain) (,delta,test-domain)
|
||
DEPT1 (,echo,test-domain) (,foxtrott,test-domain)
|
||
DEPT2 (,golf,test-domain) (,hotel,test-domain)
|
||
DEPT3 (,india,test-domain) (,juliet,test-domain)
|
||
ITINTERN (,kilo,test-domain) (,lima,test-domain)
|
||
D_INTERNS (,able,test-domain) (,baker,test-domain)
|
||
#
|
||
# Ahora definimos unos pocos grupos basados en roles
|
||
USERS DEPT1 DEPT2 DEPT3
|
||
BIGSRV IT_EMP IT_APP
|
||
SMALLSRV IT_EMP IT_APP ITINTERN
|
||
USERBOX IT_EMP ITINTERN USERS
|
||
#
|
||
# Y un grupo para tareas especiales
|
||
# Permitimos a echo y golf acceso a nuestra maquina-anti-virus
|
||
SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain)
|
||
#
|
||
# netgroups basados en maquinas
|
||
# Nuestros servidores principales
|
||
GUERRA BIGSRV
|
||
HAMBRE BIGSRV
|
||
# El usuario india necesita acceso a este servidor
|
||
PESTE BIGSRV (,india,test-domain)
|
||
#
|
||
# Este es realmente importante y necesita mas restricciones de
|
||
# acceso
|
||
MUERTE IT_EMP
|
||
#
|
||
# La maquina-anti-virus que mencionabamos mas arriba
|
||
ONE SECURITY
|
||
#
|
||
# Restringimos una maquina a un solo usuario
|
||
TWO (,hotel,test-domain)
|
||
# [...otros grupos]</programlisting>
|
||
|
||
<para>Si estamos utilizando algun tipo de base de datos para gestionar
|
||
cuentas de usuario debemos ser capaces de crear la primera parte del
|
||
mapeo utilizando las herramientas proporcionadas por dicho sistema
|
||
de base de datos. De este modo los nuevos usuarios tendrán
|
||
automáticamente derechos de acceso sobre las máquinas.
|
||
</para>
|
||
|
||
<para>Una última, por precaución: puede no ser siempre
|
||
aconsejable utilizar netgroups basados en máquinas. Si se
|
||
están desplegando, por ejemplo, un par de docenas o
|
||
incluso cientos de máquinas idénticas en laboratorios
|
||
de estudiantes, es mejor utilizar netgroups basados en roles en lugar
|
||
de netgroups basados en máquinas individuales
|
||
para mantener el tamaño de la asociación NIS dentro de
|
||
unos límites razonables.</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Conceptos importantes a tener muy en cuenta</title>
|
||
|
||
<para>Todavía quedan un par de cosas que tendremos que hacer de
|
||
forma distinta a lo comentado hasta ahora en caso de encontrarnos
|
||
dentro de un entorno de NIS.</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Cada vez que deseemos añadir un usuario a nuestro
|
||
laboratorio debemos añadirlo al servidor NIS maestro
|
||
<emphasis>únicamente</emphasis> y es tarea fundamental del
|
||
administrador <emphasis>acordarse de reconstruir los mapeos
|
||
NIS</emphasis>. Si nos olvidamos de esto el nuevo usuario
|
||
será incapaz de acceder a ninguna máquina excepto al
|
||
servidor NIS. Por ejemplo, si necesitáramos
|
||
añadir el nuevo usuario <username>jsmith</username> al
|
||
laboratorio tendríamos que ejecutar lo siguiente:</para>
|
||
|
||
<screen>&prompt.root; <userinput>pw useradd jsmith</userinput>
|
||
&prompt.root; <userinput>cd /var/yp</userinput>
|
||
&prompt.root; <userinput>make test-domain</userinput></screen>
|
||
|
||
<para>Se puede ejecutar también <command>adduser
|
||
jsmith</command> en lugar de
|
||
<command>pw useradd jsmith</command>.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis>No introduzca las cuentas de administración
|
||
dentro de los mapeos de NIS</emphasis>. No es buena idea
|
||
propagar cuentas y contraseñas de administración a
|
||
máquinas donde residen usuarios que normalmente no
|
||
deberían poder acceder a dichas cuentas.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><emphasis>Mantenga el servidor maestro y esclavo de NIS
|
||
seguros y minimize el tiempo de interrupción del
|
||
servicio</emphasis>. Si alguien fuera capaz de comprometer la
|
||
integridad de estas máquinas o de apagarlas los usuarios
|
||
del dominio no podrían acceder a sus cuentas en
|
||
ningún sistema.</para>
|
||
|
||
<para>Esto es la debilidad principal de cualquier sistema de
|
||
administración centralizada. Si no se protegen los servidores
|
||
NIS tendremos frente a nosotros a una horda de usuarios bastante
|
||
enfadados.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Compatibilidad con NIS v1</title>
|
||
|
||
<para> El servicio <application>ypserv</application> de &os; puede servir
|
||
también a clientes NIS v1. La implementación de NIS de
|
||
&os; sólo utiliza el protocolo NIS v2 aunque otras
|
||
implementaciones incluyen soporte para el protocolo v1 por razones de
|
||
compatibilidad con sistemas antiguos. Los dæmones
|
||
<application>ypbind</application> suministrados con estos sistemas
|
||
tratan de establecer una asociación con un servidor NIS
|
||
versión 1 aunque puede que nunca la lleguen a utilizar (y
|
||
pueden continuar realizando búsquedas mediante broadcast incluso
|
||
cuando reciben una respuesta de un servidor versión 2).
|
||
Tenga muy presente que mientras se soportan las llamadas normales de
|
||
clientes v1, la versión de <application>ypserv</application>
|
||
actualmente suministrada no gestiona peticiones de transferencia de
|
||
mapeos a través de la versión 1; en consecuencia no se
|
||
puede utilizar como maestro o esclavo junto con servidores de NIS
|
||
antiguos que sólo soporten el protocolo v1. Por suerte quedan
|
||
muy pocos servidores de este estilo en funcionamiento hoy en
|
||
día.</para>
|
||
|
||
</sect2>
|
||
|
||
<sect2 id="network-nis-server-is-client">
|
||
<title>Servidores NIS que actúan también como clientes
|
||
NIS</title>
|
||
|
||
<para>Se debe tener cuidado cuando se ejecuta
|
||
<application>ypserv</application> en un entorno multi-servidor
|
||
donde las máquinas servidoras actúan
|
||
también como máquinas clientes de NIS. Normalmente
|
||
es una buena idea obligar a los servidores a que se asocien con
|
||
ellos mismos mejor que permitirles emitir peticiones de
|
||
asociación en broadcast, lo que posiblemente
|
||
terminará con los servidores asociados entre sí.
|
||
Se pueden producir extraños fallos si un servidor del que
|
||
dependen otros deja de funcionar. Puede darse que los contadores
|
||
de todos los clientes expiren e intenten asociarse a otro
|
||
servidor, pero el retardo puede ser considerable y los fallos
|
||
todavía podrín persistir debido a que los servidores
|
||
se asocian contínuamente los unos a los otros.</para>
|
||
|
||
<para>Se puede obligar a una máquina a asociarse con un
|
||
servidor en particular ejecutando
|
||
<command>ypbind</command> con la opción
|
||
<option>-S</option>. Si no se quiere ejecutar esto manualmente
|
||
cada vez que se reinice el servidor NIS se puede
|
||
puede añadir la siguiente línea al fichero
|
||
<filename>/etc/rc.conf</filename>:</para>
|
||
|
||
<programlisting>nis_client_enable="YES" # ejecuta tambien el soft cliente
|
||
nis_client_flags="-S <replaceable>NIS domain</replaceable>,<replaceable>server</replaceable>"</programlisting>
|
||
|
||
<para>Consulte &man.ypbind.8; para obtener más información.</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Formatos de contraseñas</title>
|
||
<indexterm>
|
||
<primary>NIS</primary>
|
||
<secondary>password formats</secondary>
|
||
</indexterm>
|
||
<para>Uno de los problemas más comunes que se encuentra la gente
|
||
a la hora de implantar un servicio de NIS es la compatibilidad del
|
||
formato de las contraseñas. Si nuestro servidor de NIS
|
||
utiliza contraseñas cifradas mediante DES sólo
|
||
podrá aceptar clientes que utilicen DES. Por ejemplo, si
|
||
poseemos clientes de NIS &solaris; en nuestra red casi seguro que
|
||
necesitaremos utilizar contraseñas cifradas mediante
|
||
DES.</para>
|
||
|
||
<para>Para comprobar qué formato utilizan los servidores y los
|
||
clientes, se puede mirar en
|
||
<filename>/etc/login.conf</filename>. Si la máquina se
|
||
configura para utilizar cifrado de contraseñas mediante
|
||
DES, entonces la clase por defecto debe poseer una entrada como la
|
||
siguiente:</para>
|
||
|
||
<programlisting>default:\
|
||
:passwd_format=des:\
|
||
:copyright=/etc/COPYRIGHT:\
|
||
[Se han omitido otras entradas]</programlisting>
|
||
|
||
<para>Otros posibles valores para característica de
|
||
<literal>passwd_format</literal> pueden ser
|
||
<literal>blf</literal> y <literal>md5</literal> (para utilizar los
|
||
algoritmos Blowfish y MD5 respectivamente).</para>
|
||
|
||
<para>Se debe reconstruir la base de datos de acceso siempre que se
|
||
modifique el fichero
|
||
<filename>/etc/login.conf</filename> mediante la ejecución
|
||
de la siguiente orden como <username>root</username>:</para>
|
||
|
||
<screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>
|
||
|
||
<note><para>El formato de las contraseñas que ya se encuentran
|
||
definidas en <filename>/etc/master.passwd</filename> no
|
||
se actualizará hasta que el usuario cambie su
|
||
contraseña, después de que se haya reconstruido la
|
||
base de datos de tipos de acceso.</para></note>
|
||
|
||
<para>A continuación para asegurarse de que las
|
||
contraseñas se cifran con el formato seleccionado
|
||
también debemos comprobar que la variable
|
||
<literal>crypt_default</literal> dentro del fichero
|
||
<filename>/etc/auth.conf</filename> da preferencia al formato de
|
||
contraseña elegido. Por ejemplo cuando se utilizan
|
||
contraseñas cifradas con DES la entrada debe ser:</para>
|
||
|
||
<programlisting>crypt_default = des blf md5</programlisting>
|
||
|
||
<para>Si se realizan los pasos anteriores en cada una de las
|
||
máquinas clientes y servidoras de nuestro entorno NIS podemos
|
||
asegurar que todas utilizan el mismo formato de contraseña
|
||
dentro de nuestra red. Si se presentan problemas de validación
|
||
con determinados usuarios en una determinada máquina cliente se
|
||
puede empezar a investigar sobre el asunto. Recuerde: si se quiere
|
||
desplegar un servicio de páginas amarillas sobre un entorno de
|
||
red heterogéneo probablemente se deba utilizar DES en todos los
|
||
sistemas puesto que DES es el mínimo común
|
||
denominador.</para>
|
||
</sect2>
|
||
</sect1>
|
||
|
||
<sect1 id="network-dhcp">
|
||
<sect1info>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Greg</firstname>
|
||
<surname>Sutter</surname>
|
||
<contrib>Escrito por </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
</sect1info>
|
||
<title>DHCP</title>
|
||
|
||
<sect2>
|
||
<title>¿Qué es DHCP?</title>
|
||
<indexterm>
|
||
<primary>Dynamic Host Configuration Protocol</primary>
|
||
<see>DHCP</see>
|
||
</indexterm>
|
||
<indexterm>
|
||
<primary>Internet Software Consortium (ISC)</primary>
|
||
</indexterm>
|
||
|
||
<para>DHCP, el Protocolo de Configuración Dinamica de
|
||
Máquinas (<quote>Dynamic Host Configuration Protocol</quote>),
|
||
especifica un método para configurar dinámicamente los
|
||
parámetros de red necesarios para que un sistema pueda
|
||
comunicarse efectivamente. &os; utiliza la implementación de
|
||
DHCP proporcionada por el Internet Software Consortium (ISC) de tal
|
||
forma que toda la información relativa a la configuración
|
||
de DHCP se basa en la distribución proporcionada por el
|
||
ISC.</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Contenido de esta seccións</title>
|
||
|
||
<para>Esta sección describe tanto los componentes de la parte
|
||
servidora como los componentes de la parte cliente del sistema DHCP del
|
||
ISC. El programa cliente, denominado forma parte por defecto de los
|
||
sistemas &os; y el programa servidor se puede instalar a partir del
|
||
<quote>port</quote> <filename
|
||
role="package">net/isc-dhcp3-server</filename>. Las principales
|
||
fuentes de información son las páginas de manual
|
||
&man.dhclient.8;, &man.dhcp-options.5; y &man.dhclient.conf.5; junto
|
||
con las referencias que se muestran a continuación en esta misma
|
||
sección.</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Cómo funciona</title>
|
||
<indexterm><primary>UDP</primary></indexterm>
|
||
<para>Cuando el cliente de DHCP, <command>dhclient</command>, se ejecuta
|
||
en una máquina cliente, valga la redundancia, comienza a enviar
|
||
peticiones <quote>broadcast</quote> solicitando información de
|
||
configuración. Por defecto estas peticiones se realizan contra
|
||
el puerto UDP 68. El servidor responde a través del puerto
|
||
UDP 67 proporcionando al cliente una dirección IP junto con
|
||
otros parámetros relevantes para el correcto funcionamiento del
|
||
sistema en la red, tales como la máscara de red, el <quote>
|
||
router</quote> por defecto y los servidores de DNS. Toda esta
|
||
información se <quote>presta</quote> y es válida
|
||
sólo durante un determinado período de tiempo
|
||
(configurado por el administrador del servidor de DHCP). De esta forma
|
||
direcciones IP asignadas a clientes que ya no se encuentran conectados
|
||
a la red pueden ser reutilizadas al pasar determinado periodo de
|
||
tiempo.</para>
|
||
|
||
<para>Los clientes de DHCP pueden obtener una gran cantidad de
|
||
información del servidor. Se puede encontrar una lista completa
|
||
en &man.dhcp-options.5;.</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Integración dentro de los sistemas &os;</title>
|
||
|
||
<para>&os; se integra totalmente con el cliente DHCP del ISC, <command>
|
||
dhclient</command>. Este soporte se proporciona tanto en el proceso de
|
||
instalación como en la instalación por defecto del
|
||
sistema base obviando la necesidad de poseer un conocimiento detallado
|
||
de aspectos relacionados con la configuración de redes siempre y
|
||
cuando se disponga de servicio de DHCP en la red dada.
|
||
<command>dhclient</command> se incluye en todas las distribuciones de
|
||
&os; desde la versión 3.2.</para>
|
||
<indexterm>
|
||
<primary><application>sysinstall</application></primary>
|
||
</indexterm>
|
||
|
||
<para><application>sysinstall</application> soporta DHCP. Cuando se
|
||
configura la interfaz de red la primera pregunta es: <quote>
|
||
¿Quiere intentar configurar el interfaz mediante
|
||
DHCP?</quote>. Si se responde afirmativamente se ejecutará
|
||
<command>dhclient</command> y si tiene éxito se
|
||
procede con los siguientes pasos de configuración rellenandose
|
||
automáticamente las variables de arranque necesarias para
|
||
completar la configuración de la red.</para>
|
||
|
||
<para>Existen dos cosas que se deben realizar de tal forma que nuestro
|
||
sistema utilice la configuración de red mediante DHCP al
|
||
arrancar:</para>
|
||
<indexterm>
|
||
<primary>DHCP</primary>
|
||
<secondary>requirements</secondary>
|
||
</indexterm>
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Asegurarse de que el dispositivo <devicename>
|
||
bpf</devicename> se encuentra compilado en el kernel. Para ello
|
||
basta añadir <literal>device bpf</literal>
|
||
(<literal>pseudo-device bpf</literal> en los sistemas
|
||
&os; 4.X) al fichero de configuración del kernel y
|
||
recompilarlo e instalarlo. Para más información
|
||
sobre la construcción de núcleos consulte <xref
|
||
linkend="kernelconfig">.</para>
|
||
|
||
<para>El dispositivo <devicename>bpf</devicename> se encuentra
|
||
activado por defecto dentro del fichero de configuración
|
||
del núcleo (<filename>GENERIC</filename> que
|
||
encontrará en su sistema &os; de forma que si no se
|
||
está utilizando un fichero de configuración del
|
||
núcleo específico (hecho a medida y/o por usted) no
|
||
es necesario crear uno nuevo y se puede utilizar directamente
|
||
<filename>GENERIC</filename>.</para>
|
||
<note>
|
||
<para>Para aquellas personas especialmente preocupadas por la
|
||
seguridad debemos advertir de que el dispositivo <devicename>
|
||
bpf</devicename> es el dispositivo que las aplicaciones de
|
||
captura de paquetes utilizan para acceder a los mismos (aunque
|
||
dichas aplicaciones deben ser ejecutadas como
|
||
<username>root</username>). DHCP
|
||
<emphasis>requiere</emphasis> la presencia de
|
||
<devicename>bpf</devicename> pero si la seguridad del sistema
|
||
es más importante que la configuración
|
||
automática de la red no se recomienda instalar
|
||
<devicename>bpf</devicename> en el núcleo.</para>
|
||
</note>
|
||
</listitem>
|
||
<listitem>
|
||
<para>Editar el fichero <filename>/etc/rc.conf</filename> para
|
||
para incluir lo siguiente:</para>
|
||
|
||
<programlisting>ifconfig_fxp0="DHCP"</programlisting>
|
||
|
||
<note>
|
||
<para>Asegúrese de sustituir <literal>fxp0</literal> con
|
||
el nombre de interfaz que desea que se configure
|
||
dinámicamente, como se describe en <xref
|
||
linkend="config-network-setup">.</para>
|
||
</note>
|
||
|
||
<para>Si se utiliza una ubicación distinta para
|
||
<command>dhclient</command> o si se desea añadir opciones
|
||
adicionales a <command>dhclient</command> se puede
|
||
incluir, adaptándolo a las condiciones particulares de
|
||
cada usuario, lo siguiente:</para>
|
||
|
||
<programlisting>dhcp_program="/sbin/dhclient"
|
||
dhcp_flags=""</programlisting>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<indexterm>
|
||
<primary>DHCP</primary>
|
||
<secondary>server</secondary>
|
||
</indexterm>
|
||
<para>El servidor de DHCP (<application>dhcpd</application>) forma
|
||
parte del <quote>port</quote> <filename
|
||
role="package">net/isc-dhcp3-server</filename>. Este <quote>
|
||
port</quote> también contiene la documentación de ISC
|
||
DHCP.</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Ficheros</title>
|
||
<indexterm>
|
||
<primary>DHCP</primary>
|
||
<secondary>configuration files</secondary>
|
||
</indexterm>
|
||
<itemizedlist>
|
||
<listitem><para><filename>/etc/dhclient.conf</filename></para>
|
||
<para><command>dhclient</command> necesita un fichero de
|
||
configuración denominado
|
||
<filename>/etc/dhclient.conf</filename>. Normalmente este
|
||
fichero sólo contiene comentarios de forma que las
|
||
opciones que se definen por defecto son razonablemente
|
||
inocuas. Este fichero de configuración se describe
|
||
en la página de manual de
|
||
&man.dhclient.conf.5;.</para>
|
||
</listitem>
|
||
|
||
<listitem><para><filename>/sbin/dhclient</filename></para>
|
||
<para><command>dhclient</command> se encuentra enlazado de
|
||
forma estática y reside en <filename>/sbin</filename>.
|
||
La página de manual de &man.dhclient.8; proporciona
|
||
más información sobre la orden
|
||
<command>dhclient</command>.</para>
|
||
</listitem>
|
||
|
||
<listitem><para><filename>/sbin/dhclient-script</filename></para>
|
||
<para><command>dhclient-script</command> es el <quote>
|
||
script</quote> de configuración del cliente de DHCP
|
||
específico de &os;. Tiene todos los detalles en
|
||
&man.dhclient-script.8; pero no necesita hacer ninguna
|
||
modificación en él para que todo funcione
|
||
correctamente.</para>
|
||
</listitem>
|
||
|
||
<listitem><para><filename>/var/db/dhclient.leases</filename></para>
|
||
<para>El cliente de DHCP mantiene una base de datos de
|
||
préstamos en este fichero que se escribe de forma semejante
|
||
a un <quote>log</quote>. En &man.dhclient.leases.5; puede
|
||
consultar una explicación ligeramente más
|
||
detallada.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Lecturas recomendadas</title>
|
||
|
||
<para>El protocolo DHCP se describe completamente en
|
||
<ulink url="http://www.freesoft.org/CIE/RFC/2131/">RFC 2131</ulink>.
|
||
También tiene más información en
|
||
<ulink url="http://www.dhcp.org/">dhcp.org</ulink>.</para>
|
||
</sect2>
|
||
|
||
<sect2 id="network-dhcp-server">
|
||
<title>Instalación y configuración de un servidor de
|
||
DHCP</title>
|
||
|
||
<sect3>
|
||
<title>Qué temas se tratan en esta sección</title>
|
||
|
||
<para>Esta sección proporciona información sobre
|
||
cómo configurar un sistema &os; de forma que actúe
|
||
como un servidor de DHCP utilizando la implementación
|
||
proporcionada por el Internet Software Consortium
|
||
(ISC).</para>
|
||
|
||
<para>La parte servidora del paquete proporcionado por el ISC no
|
||
se instala por defecto en los sistemas &os; pero se puede
|
||
intalar como <quote>port</quote> desde <filename
|
||
role="package">net/isc-dhcp3-server</filename>. Consulte <xref
|
||
linkend="ports"> si necesita saber más sobre la
|
||
Colección de <quote>ports</quote>.</para>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Instalación del servidor DHCP</title>
|
||
<indexterm>
|
||
<primary>DHCP</primary>
|
||
<secondary>installation</secondary>
|
||
</indexterm>
|
||
<para>Para configurar un sistema &os; como servidor de DHCP debe
|
||
asegurarse de que el dispositivo &man.bpf.4; está compilado
|
||
dentro del núcleo. Para ello basta añadir
|
||
<literal>device bpf</literal> (<literal>
|
||
pseudo-device bpf</literal> en &os; 4.X) al fichero de
|
||
configuración del núcleo y reconstruir el mismo.
|
||
Si necesita saber más sobre el proceso de compilar e
|
||
instalar el núcleo consulte <xref
|
||
linkend="kernelconfig">.</para>
|
||
|
||
<para>El dispositivo <devicename>bpf</devicename> ya se encuentra
|
||
activado en el fichero de configuración
|
||
<filename>GENERIC</filename> del núcleo que se facilita
|
||
con &os; de tal forma que no resulta imprescindible crear un
|
||
núcleo a medida para ejecutar DHCP.</para>
|
||
|
||
<note>
|
||
<para>Para aquellas personas especialmente preocupadas por la
|
||
seguridad debemos advertir de que el dispositivo
|
||
<devicename>bpf</devicename> es el dispositivo que las
|
||
aplicaciones de captura de paquetes utilizan para acceder a
|
||
los mismos (aunque dichas aplicaciones deben ser ejecutadas
|
||
como <username>root</username>). DHCP
|
||
<emphasis>requiere</emphasis> la presencia de
|
||
<devicename>bpf</devicename> pero si la seguridad del sistema
|
||
es más importante que la configuración
|
||
automática de la red no se recomienda instalar
|
||
<devicename>bpf</devicename> en el núcleo.</para>
|
||
</note>
|
||
|
||
<para>El siguiente paso consiste en editar el fichero de ejemplo
|
||
<filename>dhcpd.conf</filename> que se crea al instalar el
|
||
<quote>port</quote> <filename
|
||
role="package">net/isc-dhcp3-server</filename>. Por defecto el
|
||
fichero se llama
|
||
<filename>/usr/local/etc/dhcpd.conf.sample</filename>,
|
||
así que se debe copiar este fichero a
|
||
<filename>/usr/local/etc/dhcpd.conf</filename> y a
|
||
continuación realizar todos los cambios sobre este
|
||
último.</para>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Configuración del servidor de DHCP</title>
|
||
<indexterm>
|
||
<primary>DHCP</primary>
|
||
<secondary>dhcpd.conf</secondary>
|
||
</indexterm>
|
||
<para>El fichero <filename>dhcpd.conf</filename> se compone
|
||
de un conjunto de declaraciones que hacen referencia a
|
||
máquinas y a subredes. Esto se entenderá mejor
|
||
mediante el siguiente ejemplo:</para>
|
||
|
||
<programlisting>option domain-name "ejemplo.com";<co id="domain-name">
|
||
option domain-name-servers 192.168.4.100;<co id="domain-name-servers">
|
||
option subnet-mask 255.255.255.0;<co id="subnet-mask">
|
||
|
||
default-lease-time 3600;<co id="default-lease-time">
|
||
max-lease-time 86400;<co id="max-lease-time">
|
||
ddns-update-style none;<co id="ddns-update-style">
|
||
|
||
subnet 192.168.4.0 netmask 255.255.255.0 {
|
||
range 192.168.4.129 192.168.4.254;<co id="range">
|
||
option routers 192.168.4.1;<co id="routers">
|
||
}
|
||
|
||
host mailhost {
|
||
hardware ethernet 02:03:04:05:06:07;<co id="hardware">
|
||
fixed-address mailhost.ejemplo.com;<co id="fixed-address">
|
||
}</programlisting>
|
||
|
||
<calloutlist>
|
||
<callout arearefs="domain-name">
|
||
<para>Esta opción especifica el dominio que se proporciona
|
||
a los clientes y que dichos clientes utilizan como dominio de
|
||
búsqueda por defecto. Consulte &man.resolv.conf.5;
|
||
si necesita más información sobre qué
|
||
significa el dominio de búsqueda.</para>
|
||
</callout>
|
||
|
||
<callout arearefs="domain-name-servers">
|
||
<para>Esta opción especifica la lista de servidores de DNS
|
||
(seperados por comas) que deben utilizar los clientes.</para>
|
||
</callout>
|
||
|
||
<callout arearefs="subnet-mask">
|
||
<para>La máscara de red que se proporciona a los clientes.</para>
|
||
</callout>
|
||
|
||
<callout arearefs="default-lease-time">
|
||
<para>Un cliente puede solicitar un determinado tiempo de vida
|
||
para el préstamo. En caso contrario el servidor asigna
|
||
un tiempo de vida por defecto mediante este valor (expresado en
|
||
segundos).</para>
|
||
</callout>
|
||
|
||
<callout arearefs="max-lease-time">
|
||
<para>Este es el máximo tiempo que el servidor puede
|
||
utilizar para realizar préstamos a los clientes. Si un
|
||
cliente solicita un tiempo mayor como máximo se
|
||
responderá con el valor aquí configurado,
|
||
ignorándose la petición de tiempo del
|
||
cliente.</para>
|
||
</callout>
|
||
|
||
<callout arearefs="ddns-update-style">
|
||
<para>Esta opción especifica si el servidor de DHCP debe
|
||
intentar actualizar el servidor de DNS cuando se acepta o se
|
||
libera un préstamo. En la implementación
|
||
proporcionada por el ISC esta opción es
|
||
<emphasis>obligatoria</emphasis>.</para>
|
||
</callout>
|
||
|
||
<callout arearefs="range">
|
||
<para>Esto indica qué direcciones IP se pueden utilizar
|
||
para ser prestadas a los clientes que las soliciten. Las
|
||
direcciones IP pertenecientes a este rango, incluyendo los
|
||
extremos, se pueden entregar a los clientes.</para>
|
||
</callout>
|
||
|
||
<callout arearefs="routers">
|
||
<para>Declara cúal es la pasarela por defecto que se
|
||
proporcionará a los clientes.</para>
|
||
</callout>
|
||
|
||
<callout arearefs="hardware">
|
||
<para>Especifica la dirección MAC de una máquina,
|
||
de tal forma que el servidor de DHCP pueda identificar a la
|
||
máquina cuando realice una petición.</para>
|
||
</callout>
|
||
|
||
<callout arearefs="fixed-address">
|
||
<para>Especifica que la máquina cliente debería
|
||
obtener siempre la misma dirección IP. Recuerde
|
||
que se puede utilizar un nombre de máquina para esto
|
||
ya que el servidor de DHCP resolverá el nombre por
|
||
sí mismo antes de devolver la información al
|
||
cliente.</para>
|
||
</callout>
|
||
</calloutlist>
|
||
|
||
<para>Una vez que se ha acabado de configurar el fichero
|
||
<filename>dhcpd.conf</filename> se puede proceder con la
|
||
ejecución del servidor mediante la siguiente
|
||
orden:</para>
|
||
|
||
<screen>&prompt.root; <userinput>/usr/local/etc/rc.d/isc-dhcpd.sh start</userinput></screen>
|
||
|
||
<para>Si posteriormente se necesitan realizar cambios en la
|
||
configuración anterior tenga en cuenta que el envío
|
||
de la señál <literal>SIGHUP</literal> a la
|
||
aplicación <application>dhcpd</application>
|
||
<emphasis>no</emphasis> provoca que se lea de nuevo la
|
||
configuración como suele ocurrir en la mayoría de
|
||
los dæmones. Tendrá que enviar la señal
|
||
<literal>SIGTERM</literal> para parar el proceso y
|
||
posteriormente relanzar el dæmon utilizando la orden
|
||
anterior.</para>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Ficheros</title>
|
||
<indexterm>
|
||
<primary>DHCP</primary>
|
||
<secondary>configuration files</secondary>
|
||
</indexterm>
|
||
<itemizedlist>
|
||
<listitem><para><filename>/usr/local/sbin/dhcpd</filename></para>
|
||
<para><application>dhcpd</application> se encuentra
|
||
enlazado de forma estática y reside en el directorio
|
||
<filename>/usr/local/sbin</filename>. La página de
|
||
manual &man.dhcpd.8; que se instala con el <quote>port</quote>
|
||
le proporcionará más información sobre
|
||
<application>dhcpd</application>.</para>
|
||
</listitem>
|
||
|
||
<listitem><para><filename>/usr/local/etc/dhcpd.conf</filename></para>
|
||
<para><application>dhcpd</application> necesita un fichero de
|
||
configuración, <filename>
|
||
/usr/local/etc/dhcpd.conf</filename>. Este fichero contiene
|
||
toda la información relevante que se quiere proporcionar
|
||
a los clientes que la soliciten, junto con información
|
||
relacionada con el funcionamiento del servidor. Este fichero
|
||
de configuración se describe en la página del
|
||
manual &man.dhcpd.conf.5; que instala el <quote>
|
||
port</quote>.</para>
|
||
</listitem>
|
||
|
||
<listitem><para><filename>/var/db/dhcpd.leases</filename></para>
|
||
<para>El servidor de DHCP mantiene una base de datos de
|
||
préstamos o alquileres dentro de este fichero, que
|
||
presenta un formato de fichero de <quote>log</quote>. La
|
||
página del manual &man.dhcpd.leases.5; que se
|
||
instala con el <quote>port</quote> proporciona una
|
||
descripción ligeramente más larga.</para>
|
||
</listitem>
|
||
|
||
<listitem><para><filename>/usr/local/sbin/dhcrelay</filename></para>
|
||
<para><application>dhcrelay</application> se utiliza en
|
||
entornos de red avanzados donde un servidor de DHCP
|
||
reenvía una petición de un cliente hacia otro
|
||
servidor de DHCP que se encuentra localizado en otra subred.
|
||
Si se necesita esta funcionalidad se debe instalar el
|
||
<quote>port</quote> <filename
|
||
role="package">net/isc-dhcp3-server</filename>. La
|
||
página del manual &man.dhcrelay.8; proporcionada por
|
||
el <quote>port</quote> contiene más detalles sobre
|
||
esto.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</sect3>
|
||
|
||
</sect2>
|
||
|
||
</sect1>
|
||
|
||
<sect1 id="network-dns">
|
||
<sect1info>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Chern</firstname>
|
||
<surname>Lee</surname>
|
||
<contrib>Enviado por </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
</sect1info>
|
||
<title>DNS</title>
|
||
|
||
<sect2>
|
||
<title>Resumen</title>
|
||
<indexterm><primary>BIND</primary></indexterm>
|
||
|
||
<para>FreeBSD utiliza por defecto una versión de BIND (Berkeley
|
||
Internet Name Domain) que proporciona la implementación
|
||
más común del protocolo de DNS. DNS es el protocolo a
|
||
través del cual los nombres de máquinas se asocian con
|
||
direcciones IP y viceversa. Por ejemplo una consulta preguntando por
|
||
<hostid>www.FreeBSD.org</hostid> recibe una respuesta con la
|
||
dirección IP del servidor web del Proyecto FreeBSD, mientras que
|
||
una pregunta sobre <hostid>ftp.FreeBSD.org</hostid> recibe como
|
||
respuesta la dirección IP correspondiente al servidor de FTP.
|
||
El proceso inverso sucede de una forma similar. Una pregunta
|
||
relativa a una determinada dirección IP se resuelve al nombre de
|
||
la máquina que la posee. No se necesita ejecutar un servidor de
|
||
DNS para poder realizar consultas y búsquedas de DNS.</para>
|
||
|
||
<indexterm><primary>DNS</primary></indexterm>
|
||
<para>El DNS se coordina de forma distribuida a través de
|
||
Internet utilizando un sistema en cierta forma complejo de servidores
|
||
de nombres raíz autorizados y mediante otros servidores de
|
||
nombres de menor escala que se encargan de replicar la
|
||
información de dominios individuales con el objetivo de mejorar
|
||
los tiempos de respuesta de búsquedas reiteradas de la misma
|
||
información.</para>
|
||
|
||
<para>
|
||
Este documento hace referencia a la versión estable BIND 8.X.
|
||
BIND 9.X se puede instalar a través del <quote>port</quote>
|
||
<filename role="package">net/bind9</filename>.</para>
|
||
|
||
<para>
|
||
El protocolo de DNS se encuentra definido en la RFC1034 y la RFC1035.
|
||
</para>
|
||
|
||
<para>
|
||
El <ulink url="http://www.isc.org/">
|
||
Internet Software Consortium (www.isc.org)</ulink> se encarga de
|
||
de mantener el software de BIND.
|
||
</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Terminología</title>
|
||
|
||
<para>Para comprender este documento se deben definir los siguientes
|
||
términos:</para>
|
||
|
||
<informaltable frame="none">
|
||
<tgroup cols="2">
|
||
<thead>
|
||
<row>
|
||
<entry>Término</entry>
|
||
<entry>Definición</entry>
|
||
</row>
|
||
</thead>
|
||
|
||
<tbody>
|
||
<row>
|
||
<entry>DNS directo (Forward DNS)</entry>
|
||
<entry>Asociación de nombres de máquinas con
|
||
direcciones IP</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry>Origen</entry>
|
||
<entry>Se refiere al dominio cubierto por un determinado fichero
|
||
de zona</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><application>named</application>, BIND, servidor
|
||
de nombres (name server)</entry>
|
||
<entry>Nombres típicos que hacen referencia al paquete
|
||
servidor de nombres de BIND de &os;</entry>
|
||
</row>
|
||
|
||
<indexterm><primary>resolver</primary></indexterm>
|
||
<row>
|
||
<entry>Resolver</entry>
|
||
<entry>Un proceso del sistema que utilizan las aplicaciones para
|
||
hacer preguntas al servidor de nombres.</entry>
|
||
</row>
|
||
|
||
<indexterm><primary>reverse DNS</primary></indexterm>
|
||
<row>
|
||
<entry>DNS inverso (Reverse DNS)</entry>
|
||
<entry>Lo contrario de lo que realiza el DNS directo;
|
||
asocia direcciones IP con nombres de máquinas</entry>
|
||
</row>
|
||
|
||
<indexterm><primary>root zone</primary></indexterm>
|
||
<row>
|
||
<entry>Zona Raíz</entry>
|
||
|
||
<entry>El comienzo de la jerarquía de zonas de Internet.
|
||
Todas las zonas surgen a partir de una zona raíz de
|
||
forma similar a como todos los directorios de un sistema de
|
||
ficheros se encuentran a partir de un directorio raíz
|
||
inicial.</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry>Zona</entry>
|
||
<entry>Un dominio individual, subdominio o porción del
|
||
DNS que se encuentra administrado por la misma autoridad.</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</informaltable>
|
||
|
||
<indexterm>
|
||
<primary>zones</primary>
|
||
<secondary>examples</secondary>
|
||
</indexterm>
|
||
|
||
<para>Ejemplos de zonas:
|
||
</para>
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para><hostid>.</hostid> es la zona raíz</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><hostid>org.</hostid> es una zona localizada bajo la zona
|
||
raíz</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><hostid>ejemplo.org</hostid> es una zona localizada bajo la
|
||
zona <hostid>org.</hostid></para>
|
||
</listitem>
|
||
<listitem>
|
||
<para><hostid>foo.ejemplo.org.</hostid> es un subdominio o una zona
|
||
ubicada bajo la zona <hostid>ejemplo.org.</hostid></para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>
|
||
<hostid>1.2.3.in-addr.arpa</hostid> es una zona que referencia a
|
||
a todas las direcciones IP que se encuentran dentro del espacio de
|
||
direcciones de 3.2.1.*.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<para>Como se puede observar la parte más específica de una
|
||
máquina aparece más a la izquierda. Por ejemplo
|
||
<hostid>ejemplo.org</hostid> es más específico que
|
||
<hostid>org.</hostid> y del mismo modo <hostid>org.</hostid> es
|
||
más específico que la zona raíz. El formato de
|
||
cada parte del nombre de la máquina es muy similar al formato
|
||
de un sistema de ficheros: el directorio
|
||
<filename>/dev</filename> se encuentra dentro del directorio
|
||
raíz, y así sucesivamente.</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Razones para ejecutar un servidor de nombres</title>
|
||
|
||
<para>Los servidores de nombres normalmente son de dos tipos:
|
||
autoritarios y de cache.</para>
|
||
|
||
<para>Se necesita un servidor de nombres autoritario cuando:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>uno quiere proporcionar información de DNS al resto del
|
||
mundo respondiendo con información autoritaria a las
|
||
consultas recibidas.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>un dominio, por ejemplo
|
||
<hostid>ejemplo.org</hostid>, está registrado y se
|
||
necesita añadir nombres de máquinas bajo dicho
|
||
dominio.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>un bloque de direcciones IP necesita entradas de DNS inversas
|
||
(de IP a nombre de máquina).</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>un servidor de nombres de <quote>backup</quote>, llamado
|
||
esclavo, debe responder a consultas cuando el servidor primario se
|
||
encuentre caído o inaccesible.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<para>Se necesita un servidor caché cuando:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>un servidor de DNS local puede responder más
|
||
rápidamente de lo que se haría si se tuviera que
|
||
preguntar al servidor de nombres externo.</para>
|
||
</listitem>
|
||
<listitem>
|
||
<para>se desea reducir el tráfico global de red (se ha
|
||
llegado a comprobar que el tráfico de DNS supone un 5% o
|
||
más del total del tráfico que circula por
|
||
Internet).</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<para>Cuando se pregunta por <hostid>www.FreeBSD.org</hostid> el <quote>
|
||
resolver</quote> normalmente pregunta al servidor de nombres del ISP
|
||
de nivel superior y se encarga de recibir la respuesta. Si se utiliza
|
||
un servidor de DNS caché local la pregunta sólo se dirige
|
||
una única vez hacia el exterior. Dicha pregunta la realiza el
|
||
servidor caché. Posteriores consultas sobre el mismo nombres
|
||
son respondidas directamente por este servidor.</para>
|
||
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Cómo funciona</title>
|
||
<para>En &os; el dæmon de BIND se denomina
|
||
<application>named</application> por razones obvias.</para>
|
||
|
||
<informaltable frame="none">
|
||
<tgroup cols="2">
|
||
<thead>
|
||
<row>
|
||
<entry>Fichero</entry>
|
||
<entry>Descripción</entry>
|
||
</row>
|
||
</thead>
|
||
|
||
<tbody>
|
||
<row>
|
||
<entry><application>named</application></entry>
|
||
<entry>El dæmon de BIND</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><command>ndc</command></entry>
|
||
<entry>El programa de control del dæmon</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><filename>/etc/namedb</filename></entry>
|
||
<entry>El directorio donde se almacena la información de
|
||
las zonas de BIND</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><filename>/etc/namedb/named.conf</filename></entry>
|
||
<entry>El archivo de configuración del dæmon</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</informaltable>
|
||
|
||
<para>
|
||
Los ficheros de zonas se encuentran normalmente bajo el directorio
|
||
<filename>/etc/namedb</filename> y contienen la información
|
||
que proporciona el servidor de nombres al resto de máquinas de
|
||
Internet.
|
||
</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Ejecución de BIND</title>
|
||
<indexterm>
|
||
<primary>BIND</primary>
|
||
<secondary>starting</secondary>
|
||
</indexterm>
|
||
<para>
|
||
Debido a que BIND se instala por defecto la configuración
|
||
resulta ser bastante sencilla.
|
||
</para>
|
||
<para>
|
||
Para asegurarnos de que el dæmon se ejecuta al inicio del
|
||
sistema se deben añadir las siguientes modificaciones en
|
||
<filename>/etc/rc.conf</filename>:
|
||
</para>
|
||
<programlisting>named_enable="YES"</programlisting>
|
||
<para>Para arrancar el dæmon de forma manual (una vez
|
||
configurado)</para>
|
||
<screen>&prompt.root; <userinput>ndc start</userinput></screen>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Ficheros de configuración</title>
|
||
<indexterm>
|
||
<primary>BIND</primary>
|
||
<secondary>configuration files</secondary>
|
||
</indexterm>
|
||
<sect3>
|
||
<title>Uso de <command>make-localhost</command></title>
|
||
<para>Asegúrese de hacer los siguiente
|
||
</para>
|
||
<screen>&prompt.root; <userinput>cd /etc/namedb</userinput>
|
||
&prompt.root; <userinput>sh make-localhost</userinput></screen>
|
||
<para>para que se cree el archivo de zona inversa
|
||
<filename>/etc/namedb/localhost.rev</filename> de forma apropiada.
|
||
</para>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title><filename>/etc/namedb/named.conf</filename></title>
|
||
|
||
<programlisting>// $FreeBSD$
|
||
//
|
||
// Consulte la página man de named(8) para más detalles. tiene
|
||
// alguna vez la necesidad de configurar un servidor primario
|
||
// asegúree de que entiende a la perfección los detalles peliagudos
|
||
// del funcionamiento del DNS. Si hay errores, incluso triviales,
|
||
// puede sufrir pérdidas de conectividad ogenerar cantidades ingentes
|
||
// de tráfico inútil hacia o desde Interne
|
||
|
||
options {
|
||
directory "/etc/namedb";
|
||
|
||
// Además de con la láusula "forwarders" puedeobligar a su servidor
|
||
// de nombres a que nunca lance búsquedas por su cuenta sino que
|
||
// se las pida a sus "forwarders". Esto se hace del siguiente modo:
|
||
//
|
||
// forward only;
|
||
|
||
// Si su proveedor de acceso tiene a su alcance un servidor DNS
|
||
// escriba aquí su dirección IP y descomente la líneaPodrá usar
|
||
// su caché y por lo tanto reducir el tráfico DNS de Internet.
|
||
//
|
||
|
||
/*
|
||
forwarders {
|
||
127.0.0.1;
|
||
};
|
||
*/</programlisting>
|
||
|
||
<para>
|
||
Tal y como se dice en los comentarios del ejemplo para beneficiarnos
|
||
de la caché se puede activar <literal>forwarders</literal>.
|
||
En circunstancias normales un servidor de nombres busca de forma
|
||
recursiva a través de Internet tratando de localizar un
|
||
servidor de nombres que sea capaz de responder una determinada
|
||
pregunta. Si se activa esta opción por defecto se pasa a
|
||
preguntar primero al servidor de nombres especificado (servidor o
|
||
servidores) pudiendo aprovecharse de la información de
|
||
caché que dicho servidor tuviera disponible. Si el servidor
|
||
de nivel superior al nuestro se encuentra congestionado puede
|
||
merecer la pena la activación de esta característica de
|
||
<quote>redirección</quote> ya que se puede disminuir la carga
|
||
de tráfico que dicho servidor tiene que soportar.</para>
|
||
|
||
<warning><para>La dirección IP <hostid
|
||
role="ipaddr">127.0.0.1</hostid> <emphasis>no</emphasis> funciona
|
||
aí. Se debe cambiar esta dirección IP por un
|
||
servidor de nombres válido.</para>
|
||
</warning>
|
||
|
||
<programlisting> /*
|
||
* Si hay un cortafuegos entre usted y los servidores de
|
||
* nombres que quiere consultar tendrá que descoentar la
|
||
* siguiente directiva, "query-source". Las versiones
|
||
* anteriores de BIND siempre hacían sus consultas a través
|
||
* del puerto 53 pero BIND 8.1 utiliza por defecto un puerto no
|
||
* privilegiado.
|
||
*/
|
||
// query-source address * port 53;
|
||
|
||
/*
|
||
* Si lo va a ejecutar en un "cajón de arena" (o "sandbox")
|
||
* tendrá que declarar una uicación diferente para el
|
||
* fichero de volcado de named.
|
||
*/
|
||
// dump-file "s/named_dump.db";
|
||
};
|
||
|
||
// Nota: lo siguiente será incluído en futuras versiones.
|
||
/*
|
||
host { any; } {
|
||
topology {
|
||
127.0.0.0/8;
|
||
};
|
||
};
|
||
*/
|
||
|
||
// La configuración de secundarios se explica de modo secillo a
|
||
// partir de aquí.
|
||
//
|
||
// Si activa un servidor de nombres local no olvide incluír
|
||
// 127.0.0.1 en su /etc/resolv.conf para que sea ese servidor el
|
||
// primero al que se consulte.
|
||
// Asegúrese también de activarlo en /etc/rc.con
|
||
|
||
zone "." {
|
||
type hint;
|
||
file "named.root";
|
||
};
|
||
|
||
zone "0.0.127.IN-ADDR.ARPA" {
|
||
type master;
|
||
file "localhost.rev";
|
||
};
|
||
|
||
zone
|
||
"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" {
|
||
type master;
|
||
file "localhost.rev";
|
||
};
|
||
|
||
// Nota: No use las direcciones IP que se muestran aquí, son falsas
|
||
// y sólo se usancomo demostración y para una mejor comprensión.
|
||
//
|
||
// Ejemplo de entradas en la configuración de secundarios. Puede ser
|
||
// conveniente convertirse en secundario al menos del dominio en cuya
|
||
// zona está su dominio. Cnsulte con su administrador de red para
|
||
// que le facilite la dirección IP del servidor primario.
|
||
//
|
||
// No olvide incluír la zona del bucle inverso (IN-ADDR.ARPA). (Son
|
||
// los primeros bytes de la dirección IP correspondiente, en orden
|
||
// inverso, con ".IN-ADDR.ARPA" al final.)
|
||
//
|
||
// Antes de configurar una zona primara asegúresede haber comprendido
|
||
// completamente cómo funcionan DNS y BIND. Hay errores que no son
|
||
// visibles fácilmente. La configuración de un secundario es, por
|
||
// el contrario, muchísimo más sencilla.
|
||
//
|
||
// Nota: No se limite a copiar los ejemplos de más arriba. :-)
|
||
// Utilice nombres y direcciones reales.
|
||
//
|
||
// ADVERTENCIA: FreeBSD ejecuta bind en un sandbok (observe los
|
||
// parámeros de named (named_flags) en rc.conf). El directorio que
|
||
// contiene las zonas secundarias debe tener permisos de escritura
|
||
// para bind. Le sugerimos la siguiente secuencia de órdenes:
|
||
//
|
||
// mkdir /etc/namedb/s
|
||
// chown bind:bind /etc/namedb/s
|
||
// chmod 750 /etc/namedb/s</programlisting>
|
||
|
||
<para>Si quiere más información sobre cómo
|
||
ejecutar BIND en un <quote>sandbox</quote> consulte
|
||
<link linkend="network-named-sandbox">Ejecución de named en
|
||
un sandbox</link>.
|
||
</para>
|
||
|
||
<programlisting>/*
|
||
zone "ejemplo.com" {
|
||
type slave;
|
||
file "s/ejemplo.com.bak";
|
||
masters {
|
||
192.168.1.1;
|
||
};
|
||
};
|
||
|
||
zone "0.168.192.in-addr.arpa" {
|
||
type slave;
|
||
file "s/0.168.192.in-addr.arpa.bak";
|
||
masters {
|
||
192.168.1.1;
|
||
};
|
||
};
|
||
*/</programlisting>
|
||
<para>Dentro del fichero <filename>named.conf</filename> se muestran
|
||
ejemplos de entradas de esclavo tanto para las zonas directas como
|
||
para las inversas.</para>
|
||
|
||
<para>Para cada nueva zona administrada se debe crear una entrada de
|
||
zona dentro del fichero
|
||
<filename>named.conf</filename></para>
|
||
|
||
<para>Por ejemplo la entrada de zona más simple para el dominio
|
||
<hostid role="domainname">ejemplo.org</hostid> puede ser algo como
|
||
esto:</para>
|
||
|
||
<programlisting>zone "ejemplo.org" {
|
||
type master;
|
||
file "ejemplo.org";
|
||
};</programlisting>
|
||
|
||
<para>Esta zona es una zona maestra ( observe la línea de
|
||
<option>type</option>, y mantiene la información de la zona en
|
||
<filename>/etc/namedb/ejemplo.org</filename> tal como se indica en la
|
||
línea de <option>file</option>.</para>
|
||
|
||
<programlisting>zone "ejemplo.org" {
|
||
type slave;
|
||
file "ejemplo.org";
|
||
};</programlisting>
|
||
|
||
<para>En el caso del esclavo la información de la zona se
|
||
transmite desde el servidor de nombres maestro y se almacena en el
|
||
fichero especificado. Cuando el servidor maestro <quote>
|
||
muere</quote> o no puede ser alcanzado el servidor de nombres esclavo
|
||
puede responder a las peticiones debido a que posee la
|
||
información de la zona.</para>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Ficheros de zona</title>
|
||
<para>
|
||
A continuación se muestra un fichero de una zona maestra para
|
||
el dominio <hostid>ejemplo.org</hostid>, que se encuentra ubicado en
|
||
<filename>/etc/namedb/ejemplo.org</filename>:</para>
|
||
|
||
<programlisting>$TTL 3600
|
||
|
||
example.org. IN SOA ns1.ejemplo.org. admin.ejemplo.org. (
|
||
5 ; Serial
|
||
10800 ; Refresh
|
||
3600 ; Retry
|
||
604800 ; Expire
|
||
86400 ) ; Minimum TTL
|
||
|
||
; DNS Servers
|
||
@ IN NS ns1.ejemplo.org.
|
||
@ IN NS ns2.ejemplo.org.
|
||
|
||
; Machine Names
|
||
localhost IN A 127.0.0.1
|
||
ns1 IN A 3.2.1.2
|
||
ns2 IN A 3.2.1.3
|
||
mail IN A 3.2.1.10
|
||
@ IN A 3.2.1.30
|
||
|
||
; Aliases
|
||
www IN CNAME @
|
||
|
||
; MX Record
|
||
@ IN MX 10 mail.ejemplo.org.</programlisting>
|
||
|
||
<para>
|
||
Tenga muy en cuenta que todo nombre de máquina que termina en
|
||
<quote>.</quote> es tratado como si fuera un nombre de
|
||
máquina completo mientras que cualquier otro nombre sin el
|
||
<quote>.</quote> final se trata como una referencia relativa al
|
||
dominio de origen de la zona. Por ejemplo <literal>www</literal> se
|
||
traduce a <literal>www + origen</literal>. En nuestro fichero de
|
||
zona ficticio nuestro origen es <hostid>ejemplo.org</hostid> de forma
|
||
que <literal>www</literal> se convierte en <hostid>
|
||
www.ejemplo.org</hostid>
|
||
</para>
|
||
|
||
<para>
|
||
El formato de un fichero de zona es el siguiente:
|
||
</para>
|
||
<programlisting>nombrederegistro IN tipodeentrada valor</programlisting>
|
||
|
||
<indexterm>
|
||
<primary>DNS</primary>
|
||
<secondary>records</secondary>
|
||
</indexterm>
|
||
<para>
|
||
Los registros de DNS que más se utilizan son:
|
||
</para>
|
||
|
||
<variablelist>
|
||
<varlistentry>
|
||
<term>SOA</term>
|
||
|
||
<listitem><para>Comienzo de Zona con Autoridad (Start Of zone Authority)</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>NS</term>
|
||
|
||
<listitem><para>Un servidor de nombres con autoridad para una
|
||
una determinada zona</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>A</term>
|
||
|
||
<listitem><para>Una dirección IP de una máquina</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>CNAME</term>
|
||
|
||
<listitem><para>El nombre canónico de una máquina para definir un alias</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>MX</term>
|
||
|
||
<listitem><para>mail exchanger</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>PTR</term>
|
||
|
||
<listitem><para>Un puntero a un nombre de dominio (utilizados para
|
||
definir el DNS inverso)
|
||
</para></listitem>
|
||
</varlistentry>
|
||
</variablelist>
|
||
|
||
<programlisting>
|
||
ejemplo.org. IN SOA ns1.ejemplo.org. admin.ejemplo.org. (
|
||
5 ; Serial
|
||
10800 ; Refresh after 3 hours
|
||
3600 ; Retry after 1 hour
|
||
604800 ; Expire after 1 week
|
||
86400 ) ; Minimum TTL of 1 day</programlisting>
|
||
|
||
|
||
|
||
<variablelist>
|
||
<varlistentry>
|
||
<term><hostid>ejemplo.org.</hostid></term>
|
||
|
||
<listitem><para>el nomre de dominio, también el origen para
|
||
el fichero de zona</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><hostid>ns1.ejemplo.org.</hostid></term>
|
||
|
||
<listitem><para>el servidor de nombres
|
||
primario/autoritario para esta zona</para></listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><literal>admin.ejemplo.org.</literal></term>
|
||
|
||
<listitem><para>la persona responsable de esta zona; observe que
|
||
la dirección de correo electrónico aparece con la @
|
||
sustituida por un punto. (<email>admin@ejemplo.org</email> se
|
||
escribe <literal>admin.ejemplo.org</literal>)</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term><literal>5</literal></term>
|
||
|
||
<listitem><para>el número de serie del fichero. Este
|
||
número se debe incrementar cada vez que se modifique
|
||
el fichero de zona. Muchos administradores prefieren un
|
||
formato expresado del siguiente modo <literal>
|
||
aaaammddss</literal>. 2001041002 significa (según dicho
|
||
formato) que el fichero se modificó por última
|
||
vez el 04/10/2001 y se indica con los dos últimos
|
||
dígitos (02) que es la segunda vez en el día que
|
||
se ha modificado el fichero. El número de serie es
|
||
importante ya que para avisar a los servidores de nombres
|
||
esclavos de que se ha actualizado la zona.</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
</variablelist>
|
||
|
||
<programlisting>
|
||
@ IN NS ns1.ejemplo.org.</programlisting>
|
||
|
||
<para>
|
||
Esta es una entrada de tipo <varname>NS</varname>. Cada servidor de
|
||
nombres que contesta de forma autoritaria a las consultas de un
|
||
determinado dominio debe tener una de estas entradas. El caracter
|
||
<literal>@</literal> se sustituye por <hostid
|
||
role="domainname">ejemplo.org.</hostid>, es decir, se sustituye
|
||
por el origen.
|
||
</para>
|
||
|
||
<programlisting>
|
||
localhost IN A 127.0.0.1
|
||
ns1 IN A 3.2.1.2
|
||
ns2 IN A 3.2.1.3
|
||
mail IN A 3.2.1.10
|
||
@ IN A 3.2.1.30</programlisting>
|
||
|
||
<para>
|
||
El registro de tipo A hace referencia a nombres de máquinas .
|
||
Como puede verse más arriba <hostid>
|
||
ns1.ejemplo.org</hostid> se resuelve a <hostid
|
||
role="ipaddr">3.2.1.2</hostid>. Vemos que se utiliza otra vez el
|
||
origen <literal>@</literal>, que significa que <hostid>
|
||
ejemplo.org</hostid> se resuelve a <hostid
|
||
role="ipaddr">3.2.1.30</hostid>.
|
||
</para>
|
||
|
||
<programlisting>
|
||
www IN CNAME @</programlisting>
|
||
|
||
<para>
|
||
Los registros de nombres canónicos se utilizan normalmente
|
||
como alias de máquinas. En el ejemplo
|
||
<hostid>www</hostid> es un alias de <hostid>ejemplo.org</hostid>
|
||
(<hostid role="ipaddr">3.2.1.30</hostid>).
|
||
<varname>CNAME</varname>s se puede utilizar para proporcionar alias
|
||
de nombres de máquinas, o también para proporcionar un
|
||
mecanismo de vuelta cíclica (<quote>round robin</quote>)
|
||
de un nombre de máquina mapeado a un determinado conjunto de
|
||
máquinas intercambiables.</para>
|
||
<indexterm>
|
||
<primary>MX record</primary>
|
||
</indexterm>
|
||
|
||
<programlisting>
|
||
@ IN MX 10 mail.ejemplo.org.</programlisting>
|
||
|
||
<para>
|
||
El registro <varname>MX</varname> indica qué servidores de
|
||
correo se encargan de recibir correos para esta zona.
|
||
<hostid role="fqdn">mail.example.org</hostid> es el nombre del
|
||
servidor de correo y 10 significa la prioridad de dicho
|
||
servidor.
|
||
</para>
|
||
|
||
<para>
|
||
Se pueden especificar varios servidores de correo con prioridades de,
|
||
por ejemplo,3, 2 y 1. Un servidor de correo que intenta entregar
|
||
correo para el dominio <hostid
|
||
role="domainname">ejemplo.org</hostid> primero intentará
|
||
contactar con el servidor especificado en el registro MX de mayor
|
||
prioridad, después con el siguiente y así sucesivamente
|
||
hasta que lo logre entregar.
|
||
</para>
|
||
|
||
<para>
|
||
Para los ficheros de zona de in-addr.arpa (DNS inverso) se utiliza
|
||
el mismo formato excepto que se especifican registros
|
||
<varname>PTR</varname> en lugar de registros
|
||
<varname>A</varname> o <varname>CNAME</varname>.
|
||
</para>
|
||
|
||
<programlisting>$TTL 3600
|
||
|
||
1.2.3.in-addr.arpa. IN SOA ns1.ejemplo.org. admin.ejemplo.org. (
|
||
5 ; Serial
|
||
10800 ; Refresh
|
||
3600 ; Retry
|
||
604800 ; Expire
|
||
3600 ) ; Minimum
|
||
|
||
@ IN NS ns1.ejemplo.org.
|
||
@ IN NS ns2.ejemplo.org.
|
||
|
||
2 IN PTR ns1.ejemplo.org.
|
||
3 IN PTR ns2.ejemplo.org.
|
||
10 IN PTR mail.ejemplo.org.
|
||
30 IN PTR ejemplo.org.</programlisting>
|
||
<para>
|
||
Este fichero proporciona las asociaciones de direcciones IP con
|
||
nombres de máquinas adecuadas para nuestro dominio ficticio.
|
||
</para>
|
||
</sect3>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Servidor de nombres de cache</title>
|
||
<indexterm>
|
||
<primary>BIND</primary>
|
||
<secondary>caching name server</secondary>
|
||
</indexterm>
|
||
<para>
|
||
Un servidor de nombres de tipo caché es un servidor de nombres
|
||
que no es autoritario para ninguna zona. Simplemente realiza consultas
|
||
por sí mismo y recuerda las respuestas para futuros usos.
|
||
Para configura uno de estos servidores se configura el servidor de la
|
||
forma habitual pero se omite la inclusión de zonas.
|
||
</para>
|
||
</sect2>
|
||
|
||
<sect2 id="network-named-sandbox">
|
||
<title>Ejecución de <application>named</application> en una <quote>
|
||
Sandbox</quote></title>
|
||
<indexterm>
|
||
<primary>BIND</primary>
|
||
<secondary>running in a sandbox</secondary>
|
||
</indexterm>
|
||
|
||
<indexterm>
|
||
<primary><command>chroot</command></primary>
|
||
</indexterm>
|
||
<para>Para obtener una mayor seguridad se puede ejecutar
|
||
&man.named.8; como un usuario sin privilegios y configurarlo mediante
|
||
&man.chroot.8; dentro del directorio especificado como el directorio
|
||
del <quote>sandbox</quote>. Esto hace que cualquier cosa que se
|
||
encuentre fuera de dicho directorio resulte inaccesible para el
|
||
dæmon <application>named</application>. En caso de que se
|
||
comprometiera la seguridad de <application>named</application> esta
|
||
restricción puede ayudar a limitar el daño sufrido.
|
||
&os; dispone por defecto de un usuario y un grupo destinado a este
|
||
uso: <groupname>bind</groupname>.
|
||
|
||
<note><para>Hay quien recomienda que en lugar de configurar
|
||
<application>named</application> con <command>chroot</command> es mejor
|
||
configurarlo dentro de &man.jail.8;. En esta sección no se va
|
||
a explicar esa alternativa.</para>
|
||
</note>
|
||
|
||
<para>Debido a que <application>named</application> no va a poder
|
||
acceder a nada que se encuentre fuera del directorio <quote>
|
||
sandbox</quote> (y esto incluye cosas tales como bibliotecas
|
||
compartidas, <quote>sockets</quote> de <quote>log</quote>, etc) se
|
||
debe efectuar una serie de cambios para que <application>
|
||
named</application> pueda funcionar con normalidad. En la siguiente
|
||
lista se supone que la ruta del <quote>sandbox</quote> es
|
||
<filename>/etc/namedb</filename> y que no se ha modificado
|
||
anteriormente dicho directorio. Por favor, ejecute los pasos que se
|
||
muestran a continuación:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Cree todos los directorios que
|
||
<application>named</application> espera tener a su
|
||
disposición:</para>
|
||
|
||
<screen>&prompt.root; <userinput>cd /etc/namedb</userinput>
|
||
&prompt.root; <userinput>mkdir -p bin dev etc var/tmp var/run master slave</userinput>
|
||
&prompt.root; <userinput>chown bind:bind slave var/*</userinput><co id="chown-slave"></screen>
|
||
|
||
<calloutlist>
|
||
<callout arearefs="chown-slave">
|
||
<para><application>named</application> sólamente necesita
|
||
escribir en estos directorios así que eso es todo lo que
|
||
debemos crear.</para>
|
||
</callout>
|
||
</calloutlist>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Reorganizar y crear los archivos de configuración de
|
||
zona básicos:</para>
|
||
<screen>&prompt.root; <userinput>cp /etc/localtime etc</userinput><co id="localtime">
|
||
&prompt.root; <userinput>mv named.conf etc && ln -sf etc/named.conf</userinput>
|
||
&prompt.root; <userinput>mv named.root master</userinput>
|
||
<!-- I don't like this next bit -->
|
||
&prompt.root; <userinput>sh make-localhost && mv localhost.rev localhost-v6.rev master</userinput>
|
||
&prompt.root; <userinput>cat > master/named.localhost
|
||
$ORIGIN localhost.
|
||
$TTL 6h
|
||
@ IN SOA localhost. postmaster.localhost. (
|
||
1 ; serial
|
||
3600 ; refresh
|
||
1800 ; retry
|
||
604800 ; expiration
|
||
3600 ) ; minimum
|
||
IN NS localhost.
|
||
IN A 127.0.0.1
|
||
^D</userinput></screen>
|
||
|
||
<calloutlist>
|
||
<callout arearefs="localtime">
|
||
<para>Esto permite que <application>named</application> pueda
|
||
escribir al archivo de log la hora correcta a través
|
||
del &man.syslogd.8;</para>
|
||
</callout>
|
||
</calloutlist>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Si está usando una versión de &os; anterior a
|
||
4.9-RELEASE se debe construir una copia estáticamente
|
||
enlazada de <application>named-xfer</application> y copiarla dentro
|
||
del directorio del <quote>sandbox</quote>:</para>
|
||
|
||
<screen>&prompt.root; <userinput>cd /usr/src/lib/libisc</userinput>
|
||
&prompt.root; <userinput>make cleandir && make cleandir && make depend && make all</userinput>
|
||
&prompt.root; <userinput>cd /usr/src/lib/libbind</userinput>
|
||
&prompt.root; <userinput>make cleandir && make cleandir && make depend && make all</userinput>
|
||
&prompt.root; <userinput>cd /usr/src/libexec/named-xfer</userinput>
|
||
&prompt.root; <userinput>make cleandir && make cleandir && make depend && make NOSHARED=yes all</userinput>
|
||
&prompt.root; <userinput>cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer</userinput><co id="clean-cruft"></screen>
|
||
|
||
<para>Despueés de instalar la versión estática
|
||
de <command>named-xfer</command> se deben realizar algunas tareas
|
||
de limpieza para evitar dejar copias de bibliotecas o de programas
|
||
en nuestros ficheros de fuentes:</para>
|
||
|
||
<screen>&prompt.root; <userinput>cd /usr/src/lib/libisc</userinput>
|
||
&prompt.root; <userinput>make cleandir</userinput>
|
||
&prompt.root; <userinput>cd /usr/src/lib/libbind</userinput>
|
||
&prompt.root; <userinput>make cleandir</userinput>
|
||
&prompt.root; <userinput>cd /usr/src/libexec/named-xfer</userinput>
|
||
&prompt.root; <userinput>make cleandir</userinput></screen>
|
||
|
||
<calloutlist>
|
||
<callout arearefs="clean-cruft">
|
||
<para>En algunas ocasiones este paso puede fallar. Si es su caso
|
||
ejecute lo siguiente:</para>
|
||
|
||
<screen>&prompt.root; <userinput>cd /usr/src && make cleandir && make cleandir</userinput></screen>
|
||
|
||
<para>y borre su directorio <filename>/usr/obj</filename>:</para>
|
||
|
||
<screen>&prompt.root; <userinput>rm -fr /usr/obj && mkdir /usr/obj</userinput></screen>
|
||
|
||
<para>Esto limpia cualquier <quote>impureza</quote> del
|
||
árbol de fuentes y si se repiten los pasos anteriores
|
||
todo debería funcionar.</para>
|
||
</callout>
|
||
</calloutlist>
|
||
|
||
<para>Si se está usando &os; version 4.9-RELEASE o posterior
|
||
el ejecutable de <command>named-xfer</command> del directorio
|
||
<filename>/usr/libexec</filename> ya se encuentra
|
||
enlazado estáticamente y se puede utilizar &man.cp.1; para
|
||
copiarlo directamente en nuestro <quote>sandbox</quote>.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Cree el fichero <devicename>dev/null</devicename> de tal forma
|
||
que <application>named</application> pueda verlo y pueda escribir
|
||
sobre él:</para>
|
||
|
||
<screen>&prompt.root; <userinput>cd /etc/namedb/dev && mknod null c 2 2</userinput>
|
||
&prompt.root; <userinput>chmod 666 null</userinput></screen>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Enlace simbólicamente <filename> /var/run/ndc</filename>
|
||
con <filename>/etc/namedb/var/run/ndc</filename>:</para>
|
||
|
||
<screen>&prompt.root; <userinput>ln -sf /etc/namedb/var/run/ndc /var/run/ndc</userinput></screen>
|
||
|
||
<note>
|
||
<para>Esto simplemente evita el tener que especificar la
|
||
opción <option>-c</option> de &man.ndc.8; cada vez que se
|
||
ejecute. Dado que los contenidos de /var/run se borran al
|
||
inicio del sistema, si se piensa que esto puede resultar
|
||
útil, se puede añadir esta orden al <quote>
|
||
crontab</quote> del usuario root utilizando la opción
|
||
<option>@reboot</option>. Consulte &man.crontab.5; para
|
||
saber más información sobre esto.</para>
|
||
</note>
|
||
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Configure &man.syslogd.8; para que cree un <quote>socket</quote>
|
||
de <devicename>log</devicename> adicional de tal forma que
|
||
<application>named</application> pueda escribir sobre él.
|
||
Añada <literal>-l
|
||
/etc/namedb/dev/log</literal> a la variable
|
||
<varname>syslogd_flags</varname> dentro del fichero
|
||
<filename>/etc/rc.conf</filename>.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Reorganice la ejecución de las aplicaciones
|
||
<application>named</application> y
|
||
<command>chroot</command> para que se ejecuten dentro
|
||
del <quote>sandbox</quote> añadiendo lo siguiente al
|
||
fichero<filename>/etc/rc.conf</filename>:</para>
|
||
|
||
<programlisting>named_enable="YES"
|
||
named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf"</programlisting>
|
||
|
||
<note>
|
||
<para>Recuerde que el fichero de configuración
|
||
<replaceable>/etc/named.conf</replaceable> tiene una ruta
|
||
completa <emphasis>que comienza en el directorio del
|
||
<quote>sandbox</quote></emphasis>; por ejemplo, en la
|
||
línea superior el fichero que aparece es en realidad
|
||
<filename>/etc/namedb/etc/named.conf</filename>.</para>
|
||
</note>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<para>El siguiente paso consiste en editar el fichero
|
||
<filename>/etc/namedb/etc/named.conf</filename> de tal forma que
|
||
<application>named</application> pueda conocer qué zonas cargar
|
||
y donde encontrarlas en disco. A continuación se muestra un
|
||
ejemplo comentado (cualquier cosa que no se comenta en el ejemplo es
|
||
porque resulta igual que la configuración del servidor de DNS
|
||
del caso normal):</para>
|
||
|
||
<programlisting>options {
|
||
directory "/";<co id="directory">
|
||
named-xfer "/bin/named-xfer";<co id="named-xfer">
|
||
version ""; // No muestra la versi<73>n de BIND
|
||
query-source address * port 53;
|
||
};
|
||
// ndc control socket
|
||
controls {
|
||
unix "/var/run/ndc" perm 0600 owner 0 group 0;
|
||
};
|
||
// A partir de aquívan las zonas:
|
||
zone "localhost" IN {
|
||
type master;
|
||
file "master/named.localhost";<co id="master">
|
||
allow-transfer { localhost; };
|
||
notify no;
|
||
};
|
||
zone "0.0.127.in-addr.arpa" IN {
|
||
type master;
|
||
file "master/localhost.rev";
|
||
allow-transfer { localhost; };
|
||
notify no;
|
||
};
|
||
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" {
|
||
type master;
|
||
file "master/localhost-v6.rev";
|
||
allow-transfer { localhost; };
|
||
notify no;
|
||
};
|
||
zone "." IN {
|
||
type hint;
|
||
file "master/named.root";
|
||
};
|
||
zone "private.example.net" in {
|
||
type master;
|
||
file "master/private.example.net.db";
|
||
allow-transfer { 192.168.10.0/24; };
|
||
};
|
||
zone "10.168.192.in-addr.arpa" in {
|
||
type slave;
|
||
masters { 192.168.10.2; };
|
||
file "slave/192.168.10.db";<co id="slave">
|
||
};</programlisting>
|
||
|
||
<calloutlist>
|
||
<callout arearefs="directory">
|
||
<para>La línea que contiene
|
||
<literal>directory</literal> se especifica como
|
||
<filename>/</filename>, ya que todos los ficheros que
|
||
<application>named</application> necesita se encuentran dentro de
|
||
este directorio (recuerde que esto es equivalente al fichero
|
||
<filename>/etc/namedb</filename> de un usuario
|
||
<quote>normal</quote>.</para>
|
||
</callout>
|
||
|
||
<callout arearefs="named-xfer">
|
||
<para>Especifica la ruta completa para el binario
|
||
<command>named-xfer</command> binary (desde el marco de referencia
|
||
de <application>named</application>). Esto resulta necesario ya
|
||
que por defecto <application>named</application> se compila de tal
|
||
forma que trata de localizar
|
||
<command>named-xfer</command> dentro de
|
||
<filename>/usr/libexec</filename>.</para>
|
||
</callout>
|
||
<callout arearefs="master"><para>Especifica el nombre del fichero
|
||
(relativo a la línea
|
||
(relativo a la línea ) <literal>directory</literal> anterior)
|
||
donde <application>named</application> puede encontrar el fichero de
|
||
zona para esta zona.</para>
|
||
</callout>
|
||
<callout arearefs="slave"><para>Especifica el nombre del fichero
|
||
(relativo a la líena <literal>directory</literal> anterior)
|
||
donde <application>named</application> debería escribir una
|
||
copia del archivo de zona para esta zona después de
|
||
recuperarla exitosamente desde el servidor maestro. Este es el
|
||
motivo por el que en las etapas de configuración anteriores
|
||
necesitábamos cambiar la propiedad del directorio
|
||
<filename>slave</filename> al grupo
|
||
<groupname>bind</groupname>.</para>
|
||
</callout>
|
||
</calloutlist>
|
||
|
||
<para>Después de completar los pasos anteriores reinicie el
|
||
servidor o reinicie &man.syslogd.8; y ejecute &man.named.8;
|
||
asegurándose de que se utilicen las nuevas opciones
|
||
especificadas en <varname>syslogd_flags</varname> y
|
||
<varname>named_flags</varname>. En estos momentos deberíamos
|
||
estar ejecutando una copia de <application>named</application> dentro
|
||
de un <quote>sandbox</quote>.</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Seguridad</title>
|
||
|
||
<para>Aunque BIND es la implementación de DNS más
|
||
utilizada existe siempre el asunto relacionado con la seguridad. De
|
||
vez en cuando se encuentran agujeros de seguridad y
|
||
vulnerabilidades.</para>
|
||
|
||
<para>
|
||
Es una buena idea suscribirse a <ulink
|
||
url="http://www.cert.org/">CERT</ulink> y a <ulink
|
||
url="../handbook/eresources.html#ERESOURCES-MAIL">freebsd-security-notifications</ulink>
|
||
para estar al día de los problemas de seguridad relacionados
|
||
con <application>named</application>.</para>
|
||
|
||
<tip><para>Si surge un problema nunca está de más
|
||
actualizar los fuentes y recompilar los ejecutables desde dichas
|
||
fuentes.</para></tip>
|
||
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Lecturas recomendadas</title>
|
||
<para>
|
||
Las páginas del manual de BIND/named:
|
||
&man.ndc.8; &man.named.8; &man.named.conf.5;
|
||
</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para><ulink
|
||
url="http://www.isc.org/products/BIND/">Página oficial
|
||
de ISC Bind</ulink></para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para><ulink
|
||
url="http://www.nominum.com/getOpenSourceResource.php?id=6">
|
||
Preguntas más frecuentes sobre BIND</ulink></para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para><ulink
|
||
url="http://www.oreilly.com/catalog/dns4/">Libro de O'Reilly
|
||
"DNS and BIND", cuarta edición</ulink></para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para><ulink
|
||
url="ftp://ftp.isi.edu/in-notes/rfc1034.txt">RFC1034
|
||
- Nombre de Dominio - Conceptos y Características</ulink></para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para><ulink
|
||
url="ftp://ftp.isi.edu/in-notes/rfc1035.txt">RFC1035
|
||
- Nombres de Domninio - Implementación y
|
||
Especificación</ulink></para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
</sect2>
|
||
</sect1>
|
||
|
||
<sect1 id="network-ntp">
|
||
<sect1info>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Tom</firstname>
|
||
<surname>Hukins</surname>
|
||
<contrib>Escrito por </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
</sect1info>
|
||
<title>NTP</title>
|
||
|
||
<indexterm><primary>NTP</primary></indexterm>
|
||
|
||
<sect2>
|
||
<title>Resumen</title>
|
||
|
||
<para>Según pasa el tiempo el reloj de un computador está
|
||
expuesto a ligeros desplazamientos. NTP (Protocolo de Hora
|
||
en Red, en inglés <quote>Network Time Protocol</quote>) es
|
||
un protocolo que permite asegurar la exactitud de nuestro reloj.</para>
|
||
|
||
<para>Existen varios servicios de internet que confían y se pueden
|
||
beneficiar de relojes de computadores precisos. Por ejemplo un
|
||
servidor web puede recibir peticiones de un determinado fichero si ha
|
||
sido modificado posteriormente a una determinada fecha u hora.
|
||
Servicios como &man.cron.8; ejecutan órdenes en determinados
|
||
instantes. Si el reloj no se encuentra ajustado estas órdenes
|
||
pueden ejecutarse fuera de la hora prevista.</para>
|
||
|
||
<indexterm>
|
||
<primary>NTP</primary>
|
||
<secondary>ntpd</secondary>
|
||
</indexterm>
|
||
<para>&os; viene con el servidor NTP &man.ntpd.8; que se puede utilizar
|
||
para preguntar a otros servidores NTP, de tal forma que podemos
|
||
ajustar nuestro reloj según la hora de otros servidores e
|
||
incluso proporcionar servicio de hora nosotros mismos.</para>
|
||
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Elección de los servidores de hora adecuados</title>
|
||
|
||
<indexterm>
|
||
<primary>NTP</primary>
|
||
<secondary>choosing servers</secondary>
|
||
</indexterm>
|
||
|
||
<para>Para sincronizar nuestro reloj necesitamos comunicarnos con uno o
|
||
más servidores NTP. El administrador de nuestra red o nuestro
|
||
proveedor de servicios de Internet muy posiblemente hayan configurado
|
||
algún servidor NTP para estos propósitos. Consulte la
|
||
documentación de que disponga. Existe una <ulink
|
||
url="http://www.eecis.udel.edu/~mills/ntp/servers.html">lista de
|
||
servidores NTP públicamente accesibles</ulink> que se pueden
|
||
utilizar para buscar un servidor NTP que se encuentre
|
||
geográficamente próximo. Asegúrese de que conoce
|
||
la política de uso de estos servidores públicos ya que
|
||
en algunos casos es necesario pedir permiso al administrador antes de
|
||
de poder utilizarlos, principalmente por motivos
|
||
estadísticos.</para>
|
||
|
||
<para>Le recomendamos seleccionar servidores NTP que no se encuentren
|
||
conectados entre sí por si alguno de los servidores que use
|
||
sea inaccesible o su reloj se averíe. &man.ntpd.8; utiliza las
|
||
respuestas que recibe de otros servidores de una forma inteligente.
|
||
servidores de una forma inteligente (Tiene a hacer más caso a
|
||
los más fiables.</para>
|
||
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Configuración de la máquina</title>
|
||
|
||
<indexterm>
|
||
<primary>NTP</primary>
|
||
<secondary>configuration</secondary>
|
||
</indexterm>
|
||
|
||
<sect3>
|
||
<title>Configuración básica</title>
|
||
<indexterm><primary>ntpdate</primary></indexterm>
|
||
|
||
<para>Si sólamente deseamos sincronizar nuestro reloj cuando
|
||
se arranca la máquina se puede utilizar &man.ntpdate.8;.
|
||
Esto puede ser adecuado en algunas máquinas de escritorio que
|
||
se reinician frecuentemente y donde la sincronización no suele
|
||
ser un objetivo prioritario pero normalmente la mayoría de las
|
||
máquinas deberían ejecutar &man.ntpd.8;.</para>
|
||
|
||
<para>La utilización de &man.ntpdate.8; en tiempo de arranque
|
||
es también una buena idea incluso para las máquinas que
|
||
ejecutan &man.ntpd.8;. El programa &man.ntpd.8; modifica el reloj de
|
||
forma gradual, mientras que &man.ntpdate.8; ajusta directamente el
|
||
reloj sin importar que tamaño tenga la diferencia de tiempo
|
||
existente entre la máquina y el servidor de tiempo de
|
||
referencia.</para>
|
||
|
||
<para>Para activar &man.ntpdate.8; en tiempo de arranque, añada
|
||
<literal>ntpdate_enable="YES"</literal> al fichero
|
||
<filename>/etc/rc.conf</filename>. También es necesario
|
||
especificar todos los servidores que deseamos utilizar para
|
||
realizar el proceso de sincronización y cualquier
|
||
parámetro que deseemos pasar a &man.ntpdate.8;
|
||
utilizando la variable <varname>ntpdate_flags</varname>.</para>
|
||
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<indexterm>
|
||
<primary>NTP</primary>
|
||
<secondary>ntp.conf</secondary>
|
||
</indexterm>
|
||
|
||
<title>Configuración general</title>
|
||
|
||
<para>NTP se configura mediante el archivo
|
||
<filename>/etc/ntp.conf</filename> utilizando el formato descrito en
|
||
&man.ntp.conf.5;. A continuación se muestra un sencillo
|
||
ejemplo:</para>
|
||
|
||
<programlisting>server ntplocal.ejemplo.com prefer
|
||
server timeserver.ejemplo.org
|
||
server ntp2a.ejemplo.net
|
||
|
||
driftfile /var/db/ntp.drift</programlisting>
|
||
|
||
<para>La opción <literal>server</literal> especifica qué
|
||
servidores se van a utilizar, especificando un servidor por
|
||
línea. Si se especifica un servidor con el argumento
|
||
<literal>prefer</literal>, como en <hostid
|
||
role="fqdn">ntplocal.ejemplo.com</hostid> dicho servidor se prefiere
|
||
sobre los demás. No obstante la respuesta de su servidor
|
||
preferido se descartará si difiere sustancialmente de la
|
||
respuesta recibida por parte del resto de los servidores
|
||
especificados; en caso contrario sólo se tendrá en
|
||
cuenta la respuesta del servidor preferido sin importar la
|
||
información suministrada por el resto. El argumento
|
||
<literal>prefer</literal> se utiliza normalmente en servidores NTP
|
||
altamente precisos, como aquellos que poseen hardware de tiempo
|
||
específico.</para>
|
||
|
||
<para>La opción <literal>driftfile</literal> especifica
|
||
qué fichero se utiliza para almacenar el desplazamiento de
|
||
la fracuencia de reloj de la máquina. El programa
|
||
&man.ntpd.8; utiliza este valor para automáticamente
|
||
compensar el desvío que experimenta de forma natural el reloj
|
||
de la máquina, permitiendo mantener una precisión
|
||
acotada incluso cuando se pierde la comunicación con el resto
|
||
de referencias externas.</para>
|
||
|
||
<para>La opción <literal>driftfile</literal> especifica
|
||
qué fichero se utiliza para almacenar la información
|
||
sobre espuestas anteriores de servidores NTP. Este fichero
|
||
contiene información útil para la implementación
|
||
de NTP. No debería ser modificada por ningún otro
|
||
proceso.</para>
|
||
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Control de acceso al servidor NTP</title>
|
||
|
||
<para>Por defecto nuestro servidor de NTP puede ser accedido por
|
||
cualquier máquina de Internet. La opción
|
||
<literal>restrict</literal> se puede utilizar para controlar
|
||
controlar qué máquinas pueden acceder al
|
||
servicio.</para>
|
||
|
||
<para>Si queremos denegar el acceso a todas las máquinas
|
||
existentes basta con añadir la siguiente línea a
|
||
<filename>/etc/ntp.conf</filename>:</para>
|
||
|
||
<programlisting>restrict default ignore</programlisting>
|
||
|
||
<para>Si sólo queremos permitir el acceso al servicio de hora
|
||
a las máquinas de nuestra red y al menos tiempo nos queremos
|
||
asegurar de que dichos clientes no pueden a su vez configurar la
|
||
hora del servidor o utilizarse ellos mismos como nuevos servidores
|
||
de hora basta con añadir lo siguiente en lugar de lo
|
||
anterior:</para>
|
||
|
||
<programlisting>restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap</programlisting>
|
||
|
||
<para>donde <hostid role="ipaddr">192.168.1.0</hostid> es la
|
||
dirección IP de nuestra red y <hostid
|
||
role="netmask">255.255.255.0</hostid> es la máscara de
|
||
red.</para>
|
||
|
||
<para><filename>/etc/ntp.conf</filename> puede contener varias
|
||
opciones de tipo <literal>restrict</literal>. Para más
|
||
detalles consulte la sección <literal>Soporte de Control de
|
||
Acceso</literal> de &man.ntp.conf.5;.</para>
|
||
</sect3>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Ejecución del servidor de NTP</title>
|
||
|
||
<para>Para asegurarnos de que el servidor de NTP se ejecuta en tiempo de
|
||
arranque se debe añadir la línea <literal>
|
||
xntpd_enable="YES"</literal> al fichero
|
||
<filename>/etc/rc.conf</filename>. Si deseamos pasar opciones
|
||
adicionales a &man.ntpd.8; se puede modificar la variable
|
||
<varname>xntpd_flags</varname> del fichero
|
||
<filename>/etc/rc.conf</filename>.</para>
|
||
|
||
<para>Para ejecutar el servidor sin reiniciar la máquina ejecute
|
||
<command>ntpd</command> junto con todos aquellos parámetros que
|
||
haya especificado en la variable de arranque
|
||
<varname>xntpd_flags</varname> del fichero
|
||
<filename>/etc/rc.conf</filename>. Por ejemplo:</para>
|
||
|
||
<screen>&prompt.root; <userinput>ntpd -p /var/run/ntpd.pid</userinput></screen>
|
||
|
||
<note>
|
||
<para>Bajo &os; 5.X se han renombrado algunas opciones del
|
||
fichero <filename>/etc/rc.conf</filename>. Se debe reemplazar
|
||
cualquier aparición <literal>xntpd</literal> por
|
||
por <literal>ntpd</literal>.</para></note>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Utilización de ntpd junto con una conexión temporal
|
||
a Internet</title>
|
||
|
||
<para>El programa &man.ntpd.8; no necesita una conexión
|
||
permanente a Internet para poder funcionar correctamente. No obstante
|
||
si la conexión a Internet se encuentra configurada con
|
||
marcación bajo demanda es una buena idea impedir que el
|
||
tráfico de NTP lance una marcación automática o
|
||
que mantenga la conexión viva. Si se utiliza el PPP de
|
||
entorno de usuario se pueden utilizar las directivas
|
||
<literal>filter</literal> dentro del fichero
|
||
<filename>/etc/ppp/ppp.conf</filename> para evitar esto. Por
|
||
ejemplo:</para>
|
||
|
||
<programlisting> set filter dial 0 deny udp src eq 123
|
||
# Evita que el tráfico NTP inice una llamada saliente
|
||
set filter dial 1 permit 0 0
|
||
set filter alive 0 deny udp src eq 123
|
||
Evita que el tráficoNTP entrante mantenga abierta la conexión
|
||
set filter alive 1 deny udp dst eq 123
|
||
Evita que el tráfico NTP saliente mantenga abierta la conexión
|
||
set filter alive 2 permit 0/0 0/0</programlisting>
|
||
|
||
<para>Para ás detalles consulte la sección
|
||
<literal>PACKET FILTERING</literal> de &man.ppp.8; y los ejemplos que
|
||
se encuentran en
|
||
<filename>/usr/share/examples/ppp/</filename>.</para>
|
||
|
||
<note>
|
||
<para>Algunos proveedores de acceso a Internet bloquean paquetes que
|
||
utilizan números de puertos bajos impidiendo que los paquetes
|
||
de vuelta alcancen nuestra máquina.</para>
|
||
</note>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Información adicional</title>
|
||
|
||
<para>Hay documentación sobre el servidor NTP en formato HTML en
|
||
<filename>/usr/share/doc/ntp/</filename>.</para>
|
||
</sect2>
|
||
</sect1>
|
||
|
||
<sect1 id="network-natd">
|
||
<sect1info>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Chern</firstname>
|
||
<surname>Lee</surname>
|
||
<contrib>Escrito por </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
</sect1info>
|
||
<title>Traducción de direcciones de red</title>
|
||
|
||
<sect2 id="network-natoverview">
|
||
<title>Overview</title>
|
||
<indexterm>
|
||
<primary><application>natd</application></primary>
|
||
</indexterm>
|
||
<para>El dæmon de &os; que se encarga de traducir direcciones de
|
||
red, más conocido como &man.natd.8;, es un dæmon que
|
||
acepta paquetes IP, modifica la dirección IP fuente de dichos
|
||
paquetes y los reinyecta en el flujo de paquetes IP de salida.
|
||
&man.natd.8; ejecuta este proceso modificando la dirección de
|
||
origen y el puerto de tal forma que cuando se reciben paquetes de
|
||
contestación &man.natd.8; es capaz de determinar el destino
|
||
real y reenviar el paquete a dicho destino.</para>
|
||
|
||
<indexterm><primary>Internet connection sharing</primary></indexterm>
|
||
<indexterm><primary>IP masquerading</primary></indexterm>
|
||
<para>El uso más común de NAT es para Compartir la
|
||
Conexión a Internet.</para>
|
||
</sect2>
|
||
|
||
<sect2 id="network-natsetup">
|
||
<title>Configuración</title>
|
||
<para>Debido al pequeño espacio de direccionamiento que se
|
||
encuentra actualmente disponible en IPv4 y debido también al
|
||
gran aumento que se está produciendo en cuanto a número
|
||
de usuarios de líneas de conexión a Internet de alta
|
||
velocidad como cable o DSL la gente necesita utilizar cada vez
|
||
más la salida de Compartición de
|
||
Conexión a Internet. La característica de poder conectar
|
||
varios computadores a través de una única conexión
|
||
y una única dirección IP hacen de &man.natd.8; una
|
||
elección razonable.</para>
|
||
|
||
<para>Cada vez con más frecuencia un usuario típico
|
||
dispone de una máquina conectada mediante cable o DSL pero
|
||
desearía utilizar dicha máquina como un <quote>
|
||
router</quote> de acceso para el resto de los ordenadores de su red
|
||
de área local.</para>
|
||
|
||
<para>Para poder hacerlo la máquina (&os; por supuesto) debe
|
||
configurarse para actuar como pasarela. Debe tener al menos dos
|
||
tarjetas de red, una para conectarse a la red de área local y
|
||
la otra para conectarse con el <quote>router</quote> de acceso a
|
||
Internet. Todas las máquinas de la LAN se conectan entre
|
||
sí mediante un <quote>hub</quote> o un <quote>
|
||
switch</quote>.</para>
|
||
|
||
<mediaobject>
|
||
<imageobject>
|
||
<imagedata fileref="advanced-networking/natd">
|
||
</imageobject>
|
||
|
||
<textobject>
|
||
<literallayout class="monospaced"> _______ __________ ________
|
||
| | | | | |
|
||
| Hub |-----| Client B |-----| Router |----- Internet
|
||
|_______| |__________| |________|
|
||
|
|
||
____|______
|
||
| |
|
||
| Cliente A |
|
||
|___________|</literallayout>
|
||
</textobject>
|
||
|
||
<textobject>
|
||
<phrase>Topología de la Red</phrase>
|
||
</textobject>
|
||
</mediaobject>
|
||
|
||
<para>Una configuración como esta se utiliza frecuentemente para
|
||
compartir el acceso a Internet. Una de las máquinas de la
|
||
<acronym>LAN</acronym> está realmente conectada a Internet.
|
||
El resto de las máquinas acceden a Internet utilizando como
|
||
<quote>pasarela</quote> la máquina inicial.</para>
|
||
|
||
</sect2>
|
||
|
||
<sect2 id="network-natdkernconfiguration">
|
||
<indexterm>
|
||
<primary>kernel</primary>
|
||
<secondary>configuration</secondary>
|
||
</indexterm>
|
||
<title>Configuración</title>
|
||
<para>Se deben añadir las siguientes opciones al fichero de
|
||
configuración del núcleo:</para>
|
||
<programlisting>options IPFIREWALL
|
||
options IPDIVERT</programlisting>
|
||
|
||
<para>Además, según se prefiera, se pueden añadir
|
||
también las siguientes:</para>
|
||
<programlisting>options IPFIREWALL_DEFAULT_TO_ACCEPT
|
||
options IPFIREWALL_VERBOSE</programlisting>
|
||
|
||
<para>Lo que viene a continuación se tiene que definir en
|
||
<filename>/etc/rc.conf</filename>:</para>
|
||
|
||
<programlisting>gateway_enable="YES"
|
||
firewall_enable="YES"
|
||
firewall_type="OPEN"
|
||
natd_enable="YES"
|
||
natd_interface="<replaceable>fxp0</replaceable>"
|
||
natd_flags=""</programlisting>
|
||
|
||
<informaltable frame="none">
|
||
<tgroup cols="2">
|
||
<tbody>
|
||
<row>
|
||
<entry>gateway_enable="YES"</entry>
|
||
<entry>Configura la máquina para que actúe como
|
||
<quote>router</quote> o pasarela de red. Se puede conseguir
|
||
lo mismo ejecutando
|
||
<command>sysctl net.inet.ip.forwarding=1</command>.</entry>
|
||
</row>
|
||
<row><entry>firewall_enable="YES"</entry>
|
||
<entry>Activa las reglas de cortafuegos que se encuentran
|
||
definidas por defecto en
|
||
<filename>/etc/rc.firewall</filename> y que entran en
|
||
funcionamiento en el arranque del sistema.</entry>
|
||
</row>
|
||
<row><entry>firewall_type="OPEN"</entry>
|
||
<entry>Especifica un conjunto de reglas de cortafuegos que
|
||
permite el acceso a todos los paquetes que se reciban.
|
||
Consulte <filename>/etc/rc.firewall</filename> para obtener
|
||
información sobre el resto de tipos de reglas que se
|
||
pueden configurar.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>natd_interface="fxp0"</entry>
|
||
<entry>Indica qué interfaz se utiliza para reenviar
|
||
paquetes (la interfaz que se conecta a Internet).</entry>
|
||
</row>
|
||
<row>
|
||
<entry>natd_flags=""</entry>
|
||
<entry>Define cualesquiera otras opciones que se deseen
|
||
proporcionar a &man.natd.8; en tiempo de arranque.</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</informaltable>
|
||
|
||
<para>Si se definen las opciones anteriores, en el arranque del sistema
|
||
el fichero <filename>/etc/rc.conf</filename> configurará las
|
||
variables de tal forma que se ejecutaría
|
||
<command>natd -interface fxp0</command>. Evidentemente esta orden
|
||
también se puede ejecutar de forma manual.</para>
|
||
|
||
<note>
|
||
<para>También es posible utilizar un fichero de
|
||
configuración para &man.natd.8; en caso de que deseemos
|
||
especificar muchos parámetros de arranque. Tendremos que
|
||
declarar la ubicación del fichero de configuración
|
||
mediante la inclusión de lo siguiente en
|
||
<filename>/etc/rc.conf</filename>:</para>
|
||
|
||
<programlisting>natd_flags="-f /etc/natd.conf"</programlisting>
|
||
|
||
<para>El fichero <filename>/etc/natd.conf</filename> debe contener una
|
||
lista de opciones de configuración una opción por
|
||
línea. Por ejemplo, en el caso que se comenta en la siguiente
|
||
sección se utilizaría un fichero de
|
||
configuración con la siguiente información:</para>
|
||
|
||
<programlisting>redirect_port tcp 192.168.0.2:6667 6667
|
||
redirect_port tcp 192.168.0.3:80 80</programlisting>
|
||
|
||
<para>Para obtener más información sobre el fichero de
|
||
configuración se puede consultar la opción
|
||
<option>-f</option> que se describe en la página del manual de
|
||
&man.natd.8;.</para>
|
||
</note>
|
||
|
||
<para>Cada máquina (y cada interfaz) que se encuentra conectada
|
||
a la LAN debe poseer una dirección IP perteneciente al espacio
|
||
de direcciones IP privado tal y como se define en <ulink
|
||
url="ftp://ftp.isi.edu/in-notes/rfc1918.txt">RFC 1918</ulink> y debe
|
||
poseer como pasarela por defecto la dirección IP de la
|
||
interfaz interna (la interfaz que se conecta a la LAN) de la
|
||
máquina que ejecuta
|
||
<application>natd</application>.</para>
|
||
|
||
<para>Por ejemplo los clientes <hostid>A</hostid> y
|
||
<hostid>B</hostid> se encuentran en la LAN utilizando las direcciones
|
||
IP <hostid role="ipaddr"><3E>192.168.0.2</hostid> y
|
||
<hostid role="ipaddr">192.168.0.3</hostid>, respectivamente. La
|
||
máquina que ejecuta <application>natd</application> posee la
|
||
dirección IP <hostid
|
||
role="ipaddr">192.168.0.1</hostid> en la interfaz que se conecta a la
|
||
LAN. El <quote>router</quote> por defecto tanto de <hostid>A</hostid>
|
||
omo de <hostid>B</hostid> se establece al valor
|
||
<hostid role="ipaddr">192.168.0.1</hostid>. La interfaz externa de la
|
||
máquina que ejecuta <application>natd</application>, la interfaz
|
||
que se conecta con Internet, no necesita de ninguna
|
||
especial en relación con el tema que estamos tratando en esta
|
||
sección.</para>
|
||
</sect2>
|
||
|
||
<sect2 id="network-natdport-redirection">
|
||
<title>Redirección de puertos</title>
|
||
|
||
<para>El incoveniente que se presenta con la utilización de
|
||
&man.natd.8; es que los clientes de la LAN no son accesibles desde
|
||
Internet. Dichos clientes pueden establecer conexiones con el
|
||
exterior pero no pueden recibir intentos de conexión desde
|
||
pueden recibir intentos de conexion desde Internet. Esto supone un
|
||
gran problema cuando se quieren ejecutar servicios de acceso global
|
||
en una o varias máquinas de la red LAN. Una forma sencilla de
|
||
solucionar parcialmente este problemma consiste en redirigir
|
||
determinados puertos en el servidor <application>natd</application>
|
||
hacia determinadas máquinas de la LAN.</para>
|
||
|
||
<para>Supongamos por ejemplo que en <hostid>A</hostid> se ejecuta un
|
||
servidor de IRC y que en <hostid>B</hostid> se ejecuta un servidor
|
||
web. Para que funcione lo que hemos comentado anteriormente se tienen
|
||
que redirigir las conexiones recibidas en los puertos 6667 (IRC) y
|
||
80 (web) a dichas máquinas, respectivamente.</para>
|
||
|
||
<para>Se debe pasar la opción <option>-redirect_port</option> a
|
||
&man.natd.8; con los valores apropiados. La sintaxis es como
|
||
sigue:</para>
|
||
<programlisting> -redirect_port proto IPdestino:PUERTOdestino[-PUERTOdestino]
|
||
[aliasIP:]aliasPUERTO[-aliasPUERTO]
|
||
[IPremota[:PUERTOremoto[-PUERTOremoto]]]</programlisting>
|
||
|
||
<para>Continuando con el ejemplo anterior los valores serían:</para>
|
||
|
||
<programlisting> -redirect_port tcp 192.168.0.2:6667 6667
|
||
-redirect_port tcp 192.168.0.3:80 80</programlisting>
|
||
|
||
<para>
|
||
Esto redirigirá los puertos <emphasis>tcp</emphasis> adecuados
|
||
a las máquinas situadas en la LAN.</para>
|
||
|
||
<para>La opción <option>-redirect_port</option> se puede
|
||
utilizar para indicar rangos de puertos en vez de puertos
|
||
individuales. Por ejemplo, <replaceable>tcp
|
||
192.168.0.2:2000-3000 2000-3000</replaceable> redirige todas las
|
||
conexiones recibidas desde los puertos 2000 al 3000 a los puertos
|
||
puertos 2000 a 3000 de la máquina
|
||
<hostid>A</hostid>.</para>
|
||
|
||
<para>Estas opciones se pueden utilizar cuando se ejecute
|
||
directamente &man.natd.8; se pueden situar en la variable
|
||
<literal>natd_flags=""</literal> en
|
||
<filename>/etc/rc.conf</filename> y también se pueden pasar
|
||
mediante un archivo de configuración.</para>
|
||
|
||
<para>Para obtener más información sobre opciones de
|
||
configuración por favor consulte &man.natd.8;</para>
|
||
</sect2>
|
||
|
||
<sect2 id="network-natdaddress-redirection">
|
||
<title>Redirección de direcciones</title>
|
||
<indexterm><primary>address redirection</primary></indexterm>
|
||
|
||
<para>La redirección de direcciones es una característica
|
||
útil si se dispone de varias direcciones IP pero todas ellas se
|
||
ubican en una única máquina. Gracias a esto
|
||
&man.natd.8; puede asignar a cada cliente de la red LAN su propia
|
||
dirección IP externa. &man.natd.8; reescribe los paquetes que
|
||
salen de la red LAN con la dirección IP externa adecuada y
|
||
redirige todo el tráfico recibido de vuelta al cliente en
|
||
función de la dirección IP de destino: esto se conoce
|
||
como NAT estático. Por ejemplo las direcciones IP
|
||
<hostid role="ipaddr">128.1.1.1</hostid>,
|
||
<hostid role="ipaddr">128.1.1.2</hostid> y
|
||
<hostid role="ipaddr">128.1.1.3</hostid> pertenecen al <quote>
|
||
router</quote> <application>natd</application>.
|
||
<hostid role="ipaddr">128.1.1.1</hostid> se puede utilizar como la
|
||
dirección IP externa del
|
||
<application>natd</application>, mientras que
|
||
<hostid role="ipaddr">128.1.1.2</hostid> y
|
||
<hostid role="ipaddr">128.1.1.3</hostid> se redirigen a los
|
||
clientes <hostid>A</hostid> y <hostid>B</hostid>, respectivamente.</para>
|
||
|
||
<para>La sintaxis de la opción
|
||
<option>-redirect_address</option> es la siguiente:</para>
|
||
|
||
<programlisting>-redirect_address IPlocal IPpública</programlisting>
|
||
|
||
|
||
<informaltable frame="none">
|
||
<tgroup cols="2">
|
||
<tbody>
|
||
<row>
|
||
<entry>IPlocal</entry>
|
||
<entry>La dirección IP interna del cliente de la LAN.</entry>
|
||
</row>
|
||
<row>
|
||
<entry>IPpública</entry>
|
||
<entry>La dirección IP externa que se corresponde con un
|
||
determinado cliente de la LAN.</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</informaltable>
|
||
|
||
<para>En nuestro ejemplo esta opción se especificaría de la
|
||
siguiente forma:</para>
|
||
|
||
<programlisting>-redirect_address 192.168.0.2 128.1.1.2
|
||
-redirect_address 192.168.0.3 128.1.1.3</programlisting>
|
||
|
||
<para>De forma semejante a la opción
|
||
<option>-redirect_port</option> estos argumentos se pueden especificar
|
||
directamente sobre la variable
|
||
<literal>natd_flags=""</literal> del fichero
|
||
<filename>/etc/rc.conf</filename> o también se pueden pasar
|
||
vía archivo de configuración de
|
||
<application>natd</application>. Si se utiliza redirección
|
||
de direcciones ya no es necesario utilizar redirección de
|
||
puertos ya que todos los paquetes que se reciben en una determinada
|
||
dirección IP son redirigidos a la máquina
|
||
especificada.</para>
|
||
|
||
<para>Las direcciones IP externas de la máquina que ejecuta
|
||
<application>natd</application> se deben activar y deben formar
|
||
parte de un alias configurado sobre la interfaz externa que se conecta
|
||
a Internet. Consulte &man.rc.conf.5; para aprender a
|
||
hacerlo.</para>
|
||
</sect2>
|
||
</sect1>
|
||
|
||
<sect1 id="network-inetd">
|
||
<sect1info>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Chern</firstname>
|
||
<surname>Lee</surname>
|
||
<contrib>Escrito por </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
</sect1info>
|
||
|
||
<title>El <quote>Superservidor</quote> <application>
|
||
inetd</application></title>
|
||
|
||
<sect2 id="network-inetd-overview">
|
||
<title>Resumen</title>
|
||
|
||
<para>&man.inetd.8; se conoce como el <quote>Super Servidor de
|
||
Internet</quote> debido a que gestiona las conexiones de
|
||
varios dæmones. Los dæmones son programas que
|
||
proporcionan servicios de red.
|
||
<application>inetd</application> actúa como un servidor de
|
||
servidor de gestión de otros dæmones. Cuando
|
||
&man.inetd.8; recibe una conexión se determina qué
|
||
dæmon debería responder a dicha conexión, se lanza
|
||
un proceso que ejecuta dicho dæmon y se le entrega el <quote>
|
||
socket</quote>. La ejecución de una única instancia de
|
||
<application>inetd</application> reduce la carga del sistema en
|
||
comparación con lo que significaría ejecutar cada uno de
|
||
los dæmones que gestiona de forma individual.</para>
|
||
|
||
<para><application>inetd</application> se utiliza principalmente para
|
||
lanzar procesos que albergan a otros dæmones pero
|
||
<application>inetd</application> también se utiliza para
|
||
gestionar determinados protocolos triviales como
|
||
<application>chargen</application>,
|
||
<application>auth</application> y
|
||
<application>daytime</application>.</para>
|
||
|
||
<para>Esta sección trata la configuración básica de
|
||
<application>inetd</application> a través de sus opciones de
|
||
línea de órdenes y utilizando su fichero de
|
||
configuración, denominado
|
||
<filename>/etc/inetd.conf</filename>.</para>
|
||
|
||
</sect2>
|
||
|
||
<sect2 id="network-inetd-settings">
|
||
<title>Configuraciones</title>
|
||
|
||
<para><application>inetd</application> se inicializa a través
|
||
del fichero <filename>/etc/rc.conf</filename> en tiempo de
|
||
arranque. La opción <literal>inetd_enable</literal> posee el
|
||
valor <literal>NO</literal> por defecto, pero a menudo la
|
||
aplicación <application>sysinstall</application> la activa
|
||
cuando se utiliza la configuración de perfil de seguridad
|
||
medio.
|
||
Estableciendo <programlisting>inetd_enable="YES"</programlisting> o
|
||
<programlisting>inetd_enable="NO"</programlisting> dentro de
|
||
<filename>/etc/rc.conf</filename> se puede activar o desactivar la
|
||
la ejecución de
|
||
<application>inetd</application> en el arranque del
|
||
sistema.</para>
|
||
|
||
<para>Se pueden además aplicar distintas opciones de
|
||
línea de órdenes mediante la opción
|
||
<literal>inetd_flags</literal>.</para>
|
||
|
||
</sect2>
|
||
|
||
<sect2 id="network-inetd-cmdline">
|
||
<title>Opciones de línea de órdenes</title>
|
||
|
||
<para><application>sinopsis de inetd</application>:</para>
|
||
|
||
<para><option> inetd [-d] [-l] [-w] [-W] [-c máximo] [-C tasa] [-a dirección | nombre_de_host]
|
||
[-p nombre_de_fichero] [-R tasa] [fichero de configuración ]</option></para>
|
||
|
||
<variablelist>
|
||
<varlistentry>
|
||
<term>-d</term>
|
||
|
||
<listitem>
|
||
<para>Activa la depuración.</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>-l</term>
|
||
|
||
<listitem>
|
||
<para>Activa el <quote>logging</quote> de las conexiones
|
||
efectuadas con écute.</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>-w</term>
|
||
|
||
<listitem>
|
||
<para>Activa el recubrimiento de TCP para servicios
|
||
externos (activado por defecto).</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>-W</term>
|
||
|
||
<listitem>
|
||
<para>Activa el recubrimiento de TCP para los servicios
|
||
internos, ejecutados directamente por el dæmon
|
||
<application>inetd</application> (activado por defecto).</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>-c máximo</term>
|
||
|
||
<listitem>
|
||
<para>Especifica el máximo número de invocaciones
|
||
simultáneas de cada servicio; el valor por defecto es
|
||
ilimitado. Se puede sobreescribir para cada servicio utilizando
|
||
la opción <option>max-child</option>.</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>-C tasa</term>
|
||
|
||
<listitem>
|
||
<para>Especifica el máximo número de veces que se
|
||
puede llamar a un servicio desde un dirección IP
|
||
determinada por minuto; el valor por defecto es ilimitado. Se
|
||
puede redefinir para cada servicio utilizando la opción
|
||
<option>max-connections-per-ip-per-minute</option>.</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>-R tasa</term>
|
||
|
||
<listitem>
|
||
<para>Especifica el máximo número de veces que se
|
||
puede invocar un servicio en un minuto; el valor por defecto es
|
||
256. Un valor de 0 permite un número ilimitado de
|
||
llamadas.</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>-a</term>
|
||
|
||
<listitem>
|
||
<para>Especifica una dirección IP a la cual se asocia y
|
||
sobre la cual se queda esperando recibir conexiones. Puede
|
||
declararse también un nombre de máquina, en cuyo
|
||
caso se utilizará la dirección (o direcciones si
|
||
hay más de una) IPv4 o IPv6 que estén tras dicho
|
||
nombre. Normalmente se usa un nombre de
|
||
máquina cuando <application>inetd</application> se
|
||
ejecuta dentro de un &man.jail.8;, en cuyo caso el nombre de
|
||
máquina se corresponde con el entorno
|
||
&man.jail.8;.</para>
|
||
|
||
<para>Cuando se desea asociarse tanto a direcciones IPv4 como a
|
||
direcciones IPv6 y se utiliza un nombre de máquina se
|
||
necesita una entrada para cada protocolo (IPv4 o IPv6) para cada
|
||
servicio que se active a través de <filename>
|
||
/etc/inetd.conf</filename>. Por ejemplo un servicio basado en
|
||
TCP necesitaría dos entradas, una utilizando
|
||
<literal>tcp4</literal> para el protocolo IPv4 y otra con
|
||
<literal>tcp6</literal> para las conexiones a través del
|
||
procolo de red IPv6.</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>-p</term>
|
||
|
||
<listitem>
|
||
<para>Especifica un fichero alternativo en el cual se guarda el
|
||
ID del proceso.</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
</variablelist>
|
||
|
||
<para>Estas opciones se pueden declarar dentro de las variables
|
||
<literal>inetd_flags</literal> del fichero
|
||
<filename>/etc/rc.conf</filename>. Por defecto
|
||
<literal>inetd_flags</literal> tiene el valor <literal>-wW</literal>,
|
||
lo que activa el recubrimiento de TCP para los servicios internos y
|
||
externos de <application>inetd</application>. Los usuarios inexpertos
|
||
no suelen introducir estos parámetros y por ello ni siquiera
|
||
necesitan especificarse dentro de <filename>
|
||
/etc/rc.conf</filename>.</para>
|
||
|
||
<note>
|
||
<para>Un servicio externo es un dæmon que se ejecuta fuera de
|
||
<application>inetd</application> y que se lanza cuando se recibe
|
||
un intento de conexión. Un servicio interno es un servicio
|
||
que <application>inetd</application> puede servir directamente sin
|
||
necesidad de lanzar nuevos procesos.</para>
|
||
</note>
|
||
|
||
</sect2>
|
||
|
||
<sect2 id="network-inetd-conf">
|
||
<title><filename>inetd.conf</filename></title>
|
||
|
||
<para>La configuración de
|
||
<application>inetd</application> se realiza a través del
|
||
ficherode configuración <filename>
|
||
/etc/inetd.conf</filename>.</para>
|
||
|
||
<para>Cuando se realiza una modificación en el fichero
|
||
<filename>/etc/inetd.conf</filename> se debe obligar a
|
||
<application>inetd</application> a releer dicho fichero de
|
||
configuración, lo cual se realiza enviando una señal
|
||
<quote>HANGUP</quote> al proceso <application>inetd</application>
|
||
como se muestra a continuación:</para>
|
||
|
||
<example id="network-inetd-hangup">
|
||
<title>Envío de una señal HANGUP a
|
||
<application>inetd</application></title>
|
||
|
||
<screen>&prompt.root; <userinput>kill -HUP `cat /var/run/inetd.pid`</userinput></screen>
|
||
</example>
|
||
|
||
<para>Cada línea del fichero de configuración especifica un
|
||
dæmon individual. Los comentarios se preceden por el
|
||
caracter <quote>#</quote>. El formato del fichero de
|
||
configuración <filename>/etc/inetd.conf</filename> es el
|
||
siguiente:</para>
|
||
|
||
<programlisting>service-name
|
||
socket-type
|
||
protocol
|
||
{wait|nowait}[/max-child[/max-connections-per-ip-per-minute]]
|
||
user[:group][/login-class]
|
||
server-program
|
||
server-program-arguments</programlisting>
|
||
|
||
<para>A continuación se muestra una entrada de ejemplo para el
|
||
dæmon <application>ftpd</application> para IPv4:</para>
|
||
|
||
<programlisting>ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l</programlisting>
|
||
|
||
<variablelist>
|
||
<varlistentry>
|
||
<term>service-name</term>
|
||
|
||
<listitem>
|
||
<para>Este es el nombre del servicio que proporciona un
|
||
determinado dæmon. Se debe corresponder con el nombre del
|
||
nombre de servicio que se declara en el fichero
|
||
<filename>/etc/services</filename>. Este fichero determina sobre
|
||
qué puerto debe ponerse a escuchar
|
||
<application>inetd</application>. Si se crea un nuevo servicio
|
||
se debe especificar primero en
|
||
<filename>/etc/services</filename>.</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>socket-type</term>
|
||
|
||
<listitem>
|
||
<para>Puede ser <literal>stream</literal>,
|
||
<literal>dgram</literal>, <literal>raw</literal> o
|
||
<literal>seqpacket</literal>. <literal>stream</literal>
|
||
se debe utilizar obligatoriamente para dæmones orientados
|
||
a conexión (dæmones TCP) mientras que
|
||
<literal>dgram</literal> se utiliza en dæmones basados en
|
||
el protocolo de transporte UDP.</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>protocol</term>
|
||
|
||
<listitem>
|
||
<para>Uno de los siguientes:</para>
|
||
|
||
<informaltable>
|
||
<tgroup cols="2">
|
||
<thead>
|
||
<row>
|
||
<entry>Protocolo</entry>
|
||
<entry>Explicación</entry>
|
||
</row>
|
||
</thead>
|
||
<tbody>
|
||
<row>
|
||
<entry>tcp, tcp4</entry>
|
||
<entry>TCP IPv4</entry>
|
||
</row>
|
||
<row>
|
||
<entry>udp, udp4</entry>
|
||
<entry>UDP IPv4</entry>
|
||
</row>
|
||
<row>
|
||
<entry>tcp6</entry>
|
||
<entry>TCP IPv6</entry>
|
||
</row>
|
||
<row>
|
||
<entry>udp6</entry>
|
||
<entry>UDP IPv6</entry>
|
||
</row>
|
||
<row>
|
||
<entry>tcp46</entry>
|
||
<entry>TCP IPv4 e IPv6 al mismo tiempo</entry>
|
||
</row>
|
||
<row>
|
||
<entry>udp46</entry>
|
||
<entry>UDP IPv4 e IPv6 al mismo tiempo</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</informaltable>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>{wait|nowait}[/max-child[/max-connections-per-ip-per-minute]]</term>
|
||
|
||
<listitem>
|
||
<para><option>wait|nowait</option> indica si el dæmon puede
|
||
gestionar su propio <quote>socket</quote> o no. Los <quote>
|
||
sockets</quote> de tipo <option>dgram</option> deben utilizar
|
||
obigatoriamente la opción <option>wait</option> mientras
|
||
que los dæmones basados en <quote>sockets</quote> de tipo
|
||
<quote>stream</quote>, los cuales se implementan normalmente
|
||
mediante hilos, debería utilizar la opción
|
||
<option>nowait</option>. La opción
|
||
<option>wait</option> normalmente entrega varios <quote>
|
||
sockets</quote> a un único dæmon, mientras que la
|
||
opción <option>nowait</option> lanza un dæmon
|
||
<quote>hijo</quote> por cada nuevo <quote>
|
||
socket</quote>.</para>
|
||
|
||
<para>El número máximo de dæmones <quote>
|
||
hijo</quote> que puede lanzar
|
||
<application>inetd</application> se puede especificar mediante
|
||
la opción <option>max-child</option>. Si se necesita por
|
||
ejemplo un límite de diez instancias para un dæmon
|
||
en particular se puede especificar el valor
|
||
<literal>10</literal> justo después de la opción
|
||
<option>nowait</option>.</para>
|
||
|
||
<para>Además de <option>max-child</option> se puede activar
|
||
otra opción para limitar en número máximo de
|
||
conexiones que se aceptan desde un determinado lugar mediante la
|
||
opción
|
||
<option>max-connections-per-ip-per-minute</option>.
|
||
Esta opción hace justo lo que su nombre indica. Un
|
||
valor de, por ejemplo, diez en esta opción
|
||
limitaría cualquier máquina remota a un
|
||
máximo de diez intentos de conexión por
|
||
minuto. Esto resulta útil para prevenir un consumo
|
||
incontrolado de recursos y ataques de Denegación de
|
||
Servicio (<quote>Denial of Service</quote> o DoS) sobre nuestra
|
||
máquina.</para>
|
||
|
||
<para>Cuando se especifica este campo las opciones
|
||
<option>wait</option> o <option>nowait</option> son
|
||
obligatorias <option>max-child</option> y
|
||
<option>max-connections-per-ip-per-minute</option> son
|
||
opcionales.</para>
|
||
|
||
<para>Un dæmon de tipo <quote>stream</quote> sin la
|
||
opción <option>max-child</option> y sin la opción
|
||
<option>max-connections-per-ip-per-minute</option>
|
||
simplemente especificaría la opción
|
||
<literal>nowait</literal>.</para>
|
||
|
||
<para>El mismo dæmon con el límite máximo de
|
||
diez dæmones <quote>hijos</quote> sería:
|
||
<literal>nowait/10</literal>.</para>
|
||
|
||
<para>La misma configuración con un límite
|
||
de veinte conexiones por dirección IP por minuto y un
|
||
máximo total de diez dæmones <quote>hijos</quote>
|
||
sería:
|
||
<literal>nowait/10/20</literal>.</para>
|
||
|
||
<para>Todas estas opciones son utilizadas por el dæmon
|
||
<application>fingerd</application> que se muestra a
|
||
continuación a modo de ejemplo:</para>
|
||
|
||
<programlisting>finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s</programlisting>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>user</term>
|
||
|
||
<listitem>
|
||
<para>Este es el nombre de usuario con el que debería
|
||
ejecutarse un determinado dæmon. Normalmente los
|
||
dæmones se suelen ejectar con permisos de
|
||
<username>root</username>. Por motivos de seguridad, resulta
|
||
bastante común encontrarse con algunos servidores que se
|
||
ejecutan bajo el usuario <username>daemon</username> o incluso
|
||
por el usuario menos privilegiado de todos que es el usuario
|
||
<username>nobody</username>.</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>server-program</term>
|
||
|
||
<listitem>
|
||
<para>La ruta completa de la localización del dæmon
|
||
que se quiere ejecutar cuando se recibe un intento de
|
||
conexión. Si el dæmon es un servicio
|
||
proporcionado por el propio <application>inetd</application> se
|
||
debe utilizar la opcion <option>internal</option> en su
|
||
lugar.</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
|
||
<varlistentry>
|
||
<term>server-program-arguments</term>
|
||
|
||
<listitem>
|
||
<para>Esto funciona en conjunción con
|
||
<option>server-program</option>, ya que especifica los
|
||
argumentos, comenzando por
|
||
<literal>argv[0]</literal>, que se pasan al dæmon
|
||
cuando se le invoca. Si la línea de órdenes es
|
||
<command>mydaemon -d</command>, <literal>midæmon
|
||
-d</literal> debería ser el valor de la opción
|
||
<option>server-program-arguments</option>. Si el
|
||
dæmon es un servicio interno se debe utilizar la
|
||
utilizar la opción <option>internal</option> en lugar de
|
||
la que estamos comentando.</para>
|
||
</listitem>
|
||
</varlistentry>
|
||
</variablelist>
|
||
</sect2>
|
||
|
||
<sect2 id="network-inetd-security">
|
||
<title>Seguridad</title>
|
||
|
||
<para>Dependiendo del perfil de seguridad establecido cuando se
|
||
instaló el sistema &os; varios dæmones de
|
||
<application>inetd</application> pueden estar desactivados o
|
||
activados. Si no se necesita un dæmon determinado, <emphasis>
|
||
no lo active</emphasis>. Especifique un <quote>#</quote> al
|
||
comienzo de la línea del dæmon que quiere desactivar y
|
||
envíe una señal <link
|
||
linkend="network-inetd-hangup">hangup</link> a
|
||
<application>inetd</application>. No se aconseja ejecutar algunos
|
||
dæmones determinados (un caso típico es
|
||
<application>fingerd</application>) porque pueden proporcionar
|
||
información valiosa para un atacante.</para>
|
||
|
||
<para>Algunos dæmones no presentan ninguna característica de
|
||
seguridad y poseen grandes o incluso no poseen tiempos de
|
||
expiración para los intentos de conexión. Esto permite
|
||
que un atacante sature los recursos de nuestra máquina
|
||
realizando intentos de conexión a una tasa relativamente baja
|
||
contra uno de estos ingenuos dæmones. Pueder ser una buena
|
||
idea protegerse de esto utilizando las opciones
|
||
<option>max-connections-per-ip-per-minute</option> y <option>
|
||
max-child</option> para este tipo de dæmones.</para>
|
||
|
||
<para>El recubrimiento de TCP está activado por defecto tal y como
|
||
ya se ha comentado anteriormente. Consulte la página
|
||
del manual de &man.hosts.access.5; para obtener más
|
||
información sobre cómo aplicar restricciones
|
||
relacionadas con TCP a los dæmones invocados por
|
||
<application>inetd</application>.</para>
|
||
</sect2>
|
||
|
||
<sect2 id="network-inetd-misc">
|
||
<title>Varios</title>
|
||
|
||
<para><application>daytime</application>,
|
||
<application>time</application>,
|
||
<application>echo</application>,
|
||
<application>discard</application>,
|
||
<application>chargen</application> y
|
||
<application>auth</application> son servicios que
|
||
<application>inetd</application> proporciona de forma
|
||
interna y propia.</para>
|
||
|
||
<para>El servicio <application>auth</application> proporciona
|
||
servicios de identificación a través de la red
|
||
(<application>ident</application>,
|
||
<application>identd</application>) y se puede configurar
|
||
hasta en cierto grado.</para>
|
||
|
||
<para>Consulte la página del manual de &man.inetd.8; si quiere
|
||
conocer todos los detalles.</para>
|
||
</sect2>
|
||
</sect1>
|
||
|
||
<sect1 id="network-plip">
|
||
<title>Línea IP paralela (PLIP)</title>
|
||
|
||
<indexterm><primary>PLIP</primary></indexterm>
|
||
<indexterm><primary>Parallel Line IP</primary></indexterm>
|
||
|
||
<para>PLIP nos permite configurar TCP/IP a través del puerto
|
||
paralelo. Es útil para conectar máquinas que no poseen
|
||
tarjetas de red, o para instalar &os; en ciertos viejos modelos de
|
||
portátiles. En esta sección se explica lo
|
||
siguiente:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Construcción de un cable paralelo (laplink).</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Conexión de dos computadores utilizando PLIP.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<sect2 id="network-create-parallel-cable">
|
||
<title>Construcción de un cable paralelo</title>
|
||
|
||
<para>Se puede comprar un cable paralelo en cualquier tienda de
|
||
componentes informáticos. No obstante si no es posible
|
||
comprarlo o simplemente queremos saber cómo hacerlo
|
||
nosotros mismos, en la siguiente tabla mostramos como hacer un cable
|
||
de impresora paralelo.</para>
|
||
|
||
<table>
|
||
<title>Cableado de una conexión de cable paralelo para redes</title>
|
||
|
||
<tgroup cols="5">
|
||
<thead>
|
||
<row>
|
||
<entry>Nombre-A</entry>
|
||
|
||
<entry>Extremo-A</entry>
|
||
|
||
<entry>Extremo-B</entry>
|
||
|
||
<entry>Descr.</entry>
|
||
|
||
<entry>Post/Bit</entry>
|
||
</row>
|
||
</thead>
|
||
|
||
<tbody>
|
||
<row>
|
||
<entry><literallayout>DATA0
|
||
-ERROR</literallayout></entry>
|
||
|
||
<entry><literallayout>2
|
||
15</literallayout></entry>
|
||
|
||
<entry><literallayout>15
|
||
2</literallayout></entry>
|
||
|
||
<entry>Data</entry>
|
||
|
||
<entry><literallayout>0/0x01
|
||
1/0x08</literallayout></entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><literallayout>DATA1
|
||
+SLCT</literallayout></entry>
|
||
|
||
<entry><literallayout>3
|
||
13</literallayout></entry>
|
||
|
||
<entry><literallayout>13
|
||
3</literallayout></entry>
|
||
|
||
<entry>Data</entry>
|
||
|
||
<entry><literallayout>0/0x02
|
||
1/0x10</literallayout></entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><literallayout>DATA2
|
||
+PE</literallayout></entry>
|
||
|
||
<entry><literallayout>4
|
||
12</literallayout></entry>
|
||
|
||
<entry><literallayout>12
|
||
4</literallayout></entry>
|
||
|
||
<entry>Data</entry>
|
||
|
||
<entry><literallayout>0/0x04
|
||
1/0x20</literallayout></entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><literallayout>DATA3
|
||
-ACK</literallayout></entry>
|
||
|
||
<entry><literallayout>5
|
||
10</literallayout></entry>
|
||
|
||
<entry><literallayout>10
|
||
5</literallayout></entry>
|
||
|
||
<entry>Strobe</entry>
|
||
|
||
<entry><literallayout>0/0x08
|
||
1/0x40</literallayout></entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><literallayout>DATA4
|
||
BUSY</literallayout></entry>
|
||
|
||
<entry><literallayout>6
|
||
11</literallayout></entry>
|
||
|
||
<entry><literallayout>11
|
||
6</literallayout></entry>
|
||
|
||
<entry>Data</entry>
|
||
|
||
<entry><literallayout>0/0x10
|
||
1/0x80</literallayout></entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry>GND</entry>
|
||
|
||
<entry>18-25</entry>
|
||
|
||
<entry>18-25</entry>
|
||
|
||
<entry>GND</entry>
|
||
|
||
<entry>-</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</table>
|
||
</sect2>
|
||
|
||
<sect2 id="network-plip-setup">
|
||
<title>Configuración de PLIP</title>
|
||
|
||
<para>En primer lugar debemos tener en nuesras manos un cable <quote>
|
||
laplink</quote>. A continuación se debe comprobar que ambos
|
||
sistemas poseen núcleos con soporte para el controlador
|
||
&man.lpt.4;:</para>
|
||
|
||
<screen>&prompt.root; <userinput>grep lp /var/run/dmesg.boot</userinput>
|
||
lpt0: <Printer> on ppbus0
|
||
lpt0: Interrupt-driven port</screen>
|
||
|
||
<para>El puerto paralelo debe ser un puerto controlado por alguna <quote>
|
||
irq</quote>. En &os; 4.X se debería tener un línea
|
||
como la siguiente en el fichero de configuración del
|
||
kernel:</para>
|
||
|
||
<programlisting>device ppc0 at isa? irq 7</programlisting>
|
||
|
||
<para>En &os; 5.X el fichero
|
||
<filename>/boot/device.hints</filename> debe contener las siguientes
|
||
líneas:</para>
|
||
|
||
<programlisting>hint.ppc.0.at="isa"
|
||
hint.ppc.0.irq="7"</programlisting>
|
||
|
||
<para>A continuación se debe comprobar que el fichero de
|
||
configuración del núcleo posee una línea con
|
||
<literal>device plip</literal> o también puede
|
||
comprobar si se ha cargado el módulo del núcleo
|
||
<filename>plip.ko</filename>. Tanto en un caso como en el otro, cuando
|
||
se ejecute &man.ifconfig.8; debería aparecer el interfaz de
|
||
red paralelo. En &os; 4.X se muestra algo parecido a
|
||
lo siguiente:</para>
|
||
|
||
<screen>&prompt.root; <userinput>ifconfig lp0</userinput>
|
||
lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500</screen>
|
||
|
||
<para>y en &os; 5.X:</para>
|
||
|
||
<screen>&prompt.root; <userinput>ifconfig plip0</userinput>
|
||
plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500</screen>
|
||
|
||
<note><para>El nombre del dispositivo utilizado para la interfaz
|
||
paralela es distinto en &os; 4.X
|
||
(<devicename>lp<replaceable>X</replaceable></devicename>)
|
||
y en &os; 5.X
|
||
(<devicename>plip<replaceable>X</replaceable></devicename>).</para></note>
|
||
|
||
<para>Enchufe el cable <quote>laplink</quote> en los interfaces de ambos
|
||
computadores.</para>
|
||
|
||
<para>Configure los parámetros de la interfaz de red en ambas
|
||
máquinas como <username>root</username>. Por ejemplo, si
|
||
queremos conectar la máquina <hostid>host1</hostid>
|
||
ejecutando &os; 4.X con la máquina
|
||
<hostid>host2</hostid> que ejecuta &os; 5.X:</para>
|
||
|
||
<programlisting> host1 <-----> host2
|
||
Dirección IP 10.0.0.1 10.0.0.2</programlisting>
|
||
|
||
<para>Configure la interfaz de <hostid>host1</hostid> así:</para>
|
||
|
||
<screen>&prompt.root; <userinput>ifconfig lp0 10.0.0.1 10.0.0.2</userinput></screen>
|
||
|
||
<para>Configure la interfaz de <hostid>host2</hostid> por medio de:</para>
|
||
|
||
<screen>&prompt.root; <userinput>ifconfig plip0 10.0.0.2 10.0.0.1</userinput></screen>
|
||
|
||
|
||
<para>Tras esto debería disponerse de una conexión
|
||
totalmente funcional. Por favor, consulte &man.lp.4; y &man.lpt.4;
|
||
si quiere saber más.</para>
|
||
|
||
<para>Además se debe añadir ambas máquinas al
|
||
fichero <filename>/etc/hosts</filename>:</para>
|
||
|
||
<programlisting>127.0.0.1 localhost.mi.dominio localhost
|
||
10.0.0.1 host1.mi.dominio host1
|
||
10.0.0.2 host2.mi.dominio</programlisting>
|
||
|
||
<para>Para comprobar que efectivamente la conexión funciona se
|
||
puede probar a hacer un ping desde cada máquina. Por
|
||
ejemplo en la máquina <hostid>host1</hostid>:</para>
|
||
|
||
<screen>&prompt.root; <userinput>ifconfig lp0</userinput>
|
||
lp0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
|
||
inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000
|
||
&prompt.root; <userinput>netstat -r</userinput>
|
||
Routing tables
|
||
|
||
Internet:
|
||
Destination Gateway Flags Refs Use Netif Expire
|
||
host2 host1 UH 0 0 lp0
|
||
&prompt.root; <userinput>ping -c 4 host2</userinput>
|
||
PING host2 (10.0.0.2): 56 data bytes
|
||
64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms
|
||
64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms
|
||
64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms
|
||
64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms
|
||
|
||
--- host2 ping statistics ---
|
||
4 packets transmitted, 4 packets received, 0% packet loss
|
||
round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms</screen>
|
||
|
||
</sect2>
|
||
</sect1>
|
||
|
||
<sect1 id="network-ipv6">
|
||
<sect1info>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Aaron</firstname>
|
||
<surname>Kaplan</surname>
|
||
<contrib>Texto original de </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Tom</firstname>
|
||
<surname>Rhodes</surname>
|
||
<contrib>Reestructurado y ampliado por </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
</sect1info>
|
||
|
||
<title>IPv6</title>
|
||
<para>IPv6 (también conocido como IPng o <quote>IP de nueva
|
||
generación</quote>) es la nueva versión del conocido
|
||
protocolo de red IP, tambíen llamado IPv4. Como sucede con el
|
||
resto de los sistemas *BSD &os; proporciona una implementación
|
||
de referencia que desarrolla el proyecto japonés
|
||
<acronym>KAME</acronym>. &os; dispone de todo lo necesario para
|
||
experimentar con el nuevo protocolo de red. Esta sección se
|
||
centra en conseguir configurar y ejecutar correctamente el protocolo
|
||
IPv6.</para>
|
||
|
||
<para>Al comienzo de los años 90 la gente comenzó a
|
||
preocuparse por el rápido consumo del espacio de direcciones
|
||
de IPv4. Dada la expansión actual de Internet existen dos
|
||
preocupaciones principales:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Agotamiento de las direcciones disponibles. Actualmente
|
||
no se trata del principal problema debido al uso generalizado del
|
||
del espacio de direccionamiento privado
|
||
(<hostid role="ipaddr">10.0.0.0/8</hostid>,
|
||
<hostid role="ipaddr">192.168.0.0/24</hostid>, etc.) junto con
|
||
<acronym>NAT</acronym>.
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>El número de entradas de las tablas de rutas comenzaba a
|
||
ser imposible de manejar. Esto todavia es un problema
|
||
prioritario.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<para>IPv6 trata de resolver estos problemas y algunos más de la
|
||
siguiente forma:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>IPv6 posee un espacio de direccionamiento de 128 bits. En otras
|
||
palabras, en teoría existen
|
||
340,282,366,920,938,463,463,374,607,431,768,211,456
|
||
direcciones disponibles. Esto significa que existen
|
||
aproximadamente 6.67 * 10^27 direcciones IPv6 por metro cuadrado
|
||
disponibles para todo el planeta Tierra.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Los <quote>routers</quote> sólo almacenan direcciones de
|
||
red agregadas así que se reduce el número de entradas
|
||
para cada tabla de rutas a un promedio de 8192.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<para>Existen además muchas otras caracterísiticas
|
||
interesantes que IPv6 proporciona, como:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Autoconfiguración de direcciones (<ulink
|
||
url="http://www.ietf.org/rfc/rfc2462.txt">RFC2462</ulink>)</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Direcciones anycast (<quote>una-de-varias</quote>)</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Soporte de direcciones multicast predefinido</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>IPsec (Seguridad en IP)</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Estructura de la cabecera simplificada</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>IP móvil</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Mecanismos de traducción de IPv6 a IPv4 (y viceversa)</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
|
||
<para>Si quiere saber más sobre IPv6 le recomendamos que
|
||
consulte:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Resumen de IPv6 en <ulink url="http://playground.sun.com/pub/ipng/html/ipng-main.html">playground.sun.com</ulink></para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para><ulink url="http://www.kame.net">KAME.net</ulink></para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para><ulink url="http://www.6bone.net">6bone.net</ulink></para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<sect2>
|
||
<title>Conceptos básicos sobre las direcciones IPv6</title>
|
||
|
||
<para>Existen varios tipos distintos de direcciones IPv6: Unicast,
|
||
Anycast y Multicast.</para>
|
||
|
||
<para>Las direcciones unicast son direcciones bien conocidas. Un
|
||
paquete que se envía a una dirección unicast
|
||
deberín llega a la interfaz identificada por dicha
|
||
dirección.</para>
|
||
|
||
<para>Las direcciones anycast son sintácticamente indistinguibles
|
||
de las direcciones unicast pero sirven para identificar a un
|
||
<emphasis>conjunto</emphasis> de interfaces. Un paquete destinado a
|
||
una dirección anycast llega a la interfaz
|
||
<quote>más cercana</quote> (en términos de
|
||
métrica de <quote>routers</quote>). Las direcciones anycast
|
||
sólo se pueden utilizar en <quote>routers</quote>.</para>
|
||
|
||
<para>Las direcciones multicast identifican un grupo de interfaces.
|
||
Un paquete destinado a una dirección multicast llega a todos los
|
||
los interfaces que se encuentran agrupados bajo dicha
|
||
dirección.</para>
|
||
|
||
<note><para>Las direcciones IPv4 de tipo broadcast
|
||
(normalmente <hostid
|
||
role="ipaddr">xxx.xxx.xxx.255</hostid>) se expresan en
|
||
IPv6 mediante direcciones multicast.</para></note>
|
||
|
||
<table>
|
||
<title>Direcciones IPv6 reservadas</title>
|
||
|
||
<tgroup cols="4">
|
||
<thead>
|
||
<row>
|
||
<entry>Dirección IPv6</entry>
|
||
<entry>Longitud del Prefijo (Bits)</entry>
|
||
<entry>Descripción</entry>
|
||
<entry>Notas</entry>
|
||
</row>
|
||
</thead>
|
||
|
||
<tbody>
|
||
<row>
|
||
<entry><hostid role="ip6addr">::</hostid></entry>
|
||
<entry>128 bits</entry>
|
||
<entry>sin especificar</entry>
|
||
<entry>como <hostid role="ipaddr">0.0.0.0</hostid> en Pv4</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><hostid role="ip6addr">::1</hostid></entry>
|
||
<entry>128 bits</entry>
|
||
<entry>dirección de bucle local (loopback)</entry>
|
||
<entry>como las <hostid role="ipaddr">127.0.0.1</hostid> en
|
||
IPv4</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><hostid
|
||
role="ip6addr">::00:xx:xx:xx:xx</hostid></entry>
|
||
<entry>96 bits</entry>
|
||
<entry>direcciónes IPv6 compatibles con IPv4</entry>
|
||
<entry>Los 32 bits más bajos contienen una
|
||
dirección IPv4. También se denominan direcciones
|
||
<quote>empotradas.</quote></entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><hostid
|
||
role="ip6addr">::ff:xx:xx:xx:xx</hostid></entry>
|
||
<entry>96 bits</entry>
|
||
<entry>direcciones IPv6 mapeadas a IPv4</entry>
|
||
<entry>Los 32 bits más bajos contienen una
|
||
dirección IPv4. Se usan para representar direcciones
|
||
IPv4 mediante direcciones IPv6.</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><hostid role="ip6addr">fe80::</hostid> -
|
||
<hostid role="ip6addr">feb::</hostid></entry>
|
||
<entry>10 bits</entry>
|
||
<entry>direcciones link-local</entry>
|
||
<entry>equivalentes a la dirección de loopback de
|
||
IPv4</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><hostid role="ip6addr">fec0::</hostid> -
|
||
<hostid role="ip6addr">fef::</hostid></entry>
|
||
<entry>10 bits</entry>
|
||
<entry>direcciones site-local</entry>
|
||
<entry>Equivalentes al direccionamiento privado de IPv4</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><hostid role="ip6addr">ff::</hostid></entry>
|
||
<entry>8 bits</entry>
|
||
<entry>multicast</entry>
|
||
<entry> </entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><hostid role="ip6addr">001</hostid> (base
|
||
2)</entry>
|
||
<entry>3 bits</entry>
|
||
<entry>direcciones unicast globales</entry>
|
||
<entry>Todas las direcciones IPv6 globales se asignan a partir de
|
||
este espacio. Los primeros tres bits siempre son
|
||
<quote>001</quote>.</entry>
|
||
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</table>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Lectura de las direcciones IPv6</title>
|
||
<para>La forma canónica que se utiliza para representar
|
||
direcciones IPv6 es: <hostid
|
||
role="ip6addr">x:x:x:x:x:x:x:x</hostid>, donde cada
|
||
<quote>x</quote> se considera un valor hexadecimal de 16 Bit.
|
||
Por ejemplo
|
||
<hostid
|
||
role="ip6addr">FEBC:A574:382B:23C1:AA49:4592:4EFE:9982</hostid></para>
|
||
|
||
<para>A menudo una dirección posee alguna subcadena de varios
|
||
ceros consecutivos de forma que se puede abreviar dicha cadena
|
||
(sólo una vez, para evitar ambigúedades) mediante
|
||
<quote>::</quote>. También se pueden omitir los ceros a la
|
||
ceros a la izquierda dentro de un valor
|
||
<quote>x</quote>. Por ejemplo
|
||
<hostid role="ip6addr">fe80::1</hostid> se corresponde con la forma
|
||
canónica
|
||
<hostid role="ip6addr">fe80:0000:0000:0000:0000:0000:0000:0001</hostid>.</para>
|
||
|
||
<para>Una tercera forma de escribir direciones IPv6 es utilizando la
|
||
ya tradicional notación decimal de IPv4 pero
|
||
sólamente para los 32 bits más bajos de la
|
||
dirección IPv6. Por ejemplo
|
||
<hostid role="ip6addr">2002::10.0.0.1</hostid> se correspondería
|
||
con la representation hexadecimal canónica
|
||
<hostid role="ip6addr">2002:0000:0000:0000:0000:0000:0a00:0001</hostid>
|
||
la cual es equivalente también a escribir <hostid
|
||
role="ip6addr">2002::a00:1</hostid>.</para>
|
||
|
||
|
||
<para>A estas alturas el lector debería ser capaz de comprender
|
||
lo siguiente:</para>
|
||
|
||
<screen>&prompt.root; <userinput>ifconfig</userinput></screen>
|
||
|
||
<programlisting>rl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
|
||
inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255
|
||
inet6 fe80::200:21ff:fe03:8e1%rl0 prefixlen 64 scopeid 0x1
|
||
ether 00:00:21:03:08:e1
|
||
media: Ethernet autoselect (100baseTX )
|
||
status: active</programlisting>
|
||
|
||
<para><hostid role="ip6addr">fe80::200:21ff:fe03:8e1%rl0</hostid>
|
||
es una dirección link-local autoconfigurada. Se construye a
|
||
partir de la dirección MAC de la tarjeta de red.</para>
|
||
|
||
<para>Si quiere saber más sobre la estructura de las
|
||
direcciones IPv6 puede consultar <ulink
|
||
url="http://www.ietf.org/rfc/rfc3513.txt">RFC3513</ulink>.</para>
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Establecimiento de conectividad</title>
|
||
|
||
<para>Actualmente existen cuatro formas distintas de conectarse
|
||
con otras máquinas y redes IPv6:</para>
|
||
|
||
<itemizedlist>
|
||
<listitem>
|
||
<para>Unirse a la red experimental denominada 6bone</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Obtener una red IPv6 a través de nuestro proveedor de
|
||
acceso a Internet. Consulte a su proveedor de servicios para
|
||
para más información.</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Encapsulación de IPv6 sobre IPv4 (<ulink
|
||
url="http://www.ietf.org/rfc/rfc3068.txt">RFC3068</ulink>)</para>
|
||
</listitem>
|
||
|
||
<listitem>
|
||
<para>Utilización del <quote>port</quote> <filename
|
||
role="package">net/freenet6</filename> si se dispone de una
|
||
de una conexión de marcación por modem.</para>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<para>Vamos a explicar cómo conectarse al 6bone ya que parece ser
|
||
la forma más utilizada en la actualidad.</para>
|
||
|
||
<para>En primer lugar se recomienda consultar el sitio web de
|
||
<ulink url="http://www.6bone.net/">6bone</ulink> para saber
|
||
cuál es la conexión del 6bone (físicamente)
|
||
más próxima. Se debe escribir a la persona responsable
|
||
de ese nodo y con un poco de suerte dicha persona responderá con
|
||
con un conjunto de instrucciones y pasos a seguir para establecer la
|
||
la conexión con ellos y a través de ellos con el resto
|
||
de los nodos IPv6 que forman parte del 6bone. Normalmente esta
|
||
conexión se establece usando túneles GRE (gif).</para>
|
||
|
||
<para>Veamos un ejemplo típico de configuración de un
|
||
de un túnel &man.gif.4;:</para>
|
||
|
||
<screen>&prompt.root; <userinput>ifconfig gif0 create</userinput>
|
||
&prompt.root; <userinput>ifconfig gif0</userinput>
|
||
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
|
||
&prompt.root; <userinput>ifconfig gif0 tunnel <replaceable>MI_DIRECCIÓn_IPV4</replaceable> <replaceable>SU_DIRECCIÓn_IPV4</replaceable></userinput>
|
||
&prompt.root; <userinput>ifconfig gif0 inet6 alias <replaceable>DIRECCIÓn_DE-SALIDA_IPv6_DEL_TÚNEL_ASIGNADO</replaceable></userinput></screen>
|
||
|
||
<para>Sustituya las palabras en mayúsculas por la
|
||
información recibida del nodo 6bone al que nos queremos
|
||
conectar.</para>
|
||
|
||
<para>La orden anterior establece el túnel. Compruebe que el
|
||
túnel funciona correctamente mediante &man.ping.8;.
|
||
Haga un &man.ping6.8; a <hostid
|
||
role="ip6addr">ff02::1%gif0</hostid>. Deberíamos recibir
|
||
recibir <quote>dos</quote> respuestas.</para>
|
||
|
||
<note><para>Para que el lector no se quede pensando en el significado
|
||
significado de la dirección <hostid
|
||
role="ip6addr">ff02:1%gif0</hostid> le podemos decir que se trata de
|
||
de una dirección IPv6 multicast de tipo link-local.
|
||
<literal>%gif0</literal> no forma parte del protocolo IPv6 como tal
|
||
sino que se trata de un detalle de implementación relacionado
|
||
con las direcciones link-local y se añade para especificar la
|
||
interfaz de salida que se debe utilizar para enviar los paquetes de
|
||
&man.ping6.8;. Como estamos haciendo ping a una dirección
|
||
multicast a la que se unen todos los interfaces pertenecientes al
|
||
mismo enlace debería responder al ping tanto nuestro propio
|
||
interfaz como el interfaz remoto.</para></note>
|
||
|
||
<para>A continuación se configura la ruta por defecto hacia
|
||
nuestro enlace 6bone; observe que es muy semejante a lo que hay que
|
||
hacer en IPv4:</para>
|
||
|
||
<screen>&prompt.root; <userinput>route add -inet6 default -interface gif0</userinput>
|
||
&prompt.root; <userinput>ping6 -n <replaceable>MI_UPLINK</replaceable></userinput></screen>
|
||
|
||
<screen>&prompt.root; <userinput>traceroute6 www.jp.FreeBSD.org</userinput>
|
||
(3ffe:505:2008:1:2a0:24ff:fe57:e561) from 3ffe:8060:100::40:2, 30 hops max, 12 byte packets
|
||
1 atnet-meta6 14.147 ms 15.499 ms 24.319 ms
|
||
2 6bone-gw2-ATNET-NT.ipv6.tilab.com 103.408 ms 95.072 ms *
|
||
3 3ffe:1831:0:ffff::4 138.645 ms 134.437 ms 144.257 ms
|
||
4 3ffe:1810:0:6:290:27ff:fe79:7677 282.975 ms 278.666 ms 292.811 ms
|
||
5 3ffe:1800:0:ff00::4 400.131 ms 396.324 ms 394.769 ms
|
||
6 3ffe:1800:0:3:290:27ff:fe14:cdee 394.712 ms 397.19 ms 394.102 ms</screen>
|
||
|
||
<para>Esta captura de pantalla variará dependiendo de la
|
||
localización de la máquina. Tras seguir estos pasos
|
||
deberíamos poder alcanzar el sitio IPv6 de <ulink
|
||
url="http://www.kame.net">www.kame.net</ulink> y ver la tortuga
|
||
bailarina, que es una imagen animada que sólo se muestra cuando
|
||
se accede al servidor web utilizando el protocolo IPv6 (para
|
||
ellos se encesita utilizar un navegador web que soporte IPv6,
|
||
IPv6, por ejemplo <filename
|
||
role="package">www/mozilla</filename> o
|
||
<application>Konqueror</application>, que forma parte de
|
||
<filename role="package">x11/kdebase3</filename>, o también
|
||
con <filename role="package">www/epiphany</filename>.</para>
|
||
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>DNS en el mundo IPv6</title>
|
||
|
||
<para>Existen dos tipos de registros de DNS para IPv6. No
|
||
obstante el IETF ha declarado los registros A6 y CNAME como registros
|
||
para uso experimental. Los registros de tipo AAAA son los
|
||
únicos estandar a día de hoy.</para>
|
||
|
||
<para>La utilización de registros de tipo AAAA es muy
|
||
sencilla. Se asocia el nombre de la máquina con la
|
||
dirección IPv6 de la siguiente forma:</para>
|
||
|
||
<programlisting>NOMBREDEMIMÁQUINA AAAA MIDIRECCIÓNIPv6</programlisting>
|
||
|
||
<para>De igual forma que en IPv4 se utilizan los registros de tipo
|
||
A. En caso de no poder administrar su propia zona de
|
||
<acronym>DNS</acronym> se puede pedir esta configuración a su
|
||
proveedor de servicios. Las versiones actuales de
|
||
<application>bind</application> (versiones 8.3 y 9) y el
|
||
<quote>port</quote> <filename role="package">dns/djbdns</filename>
|
||
(con el parche de IPv6 correspondiente) soportan los registros de tipo
|
||
AAAA.</para>
|
||
|
||
</sect2>
|
||
</sect1>
|
||
|
||
<sect1 id="network-atm">
|
||
<sect1info>
|
||
<authorgroup>
|
||
<author>
|
||
<firstname>Harti</firstname>
|
||
<surname>Brandt</surname>
|
||
<contrib>Escrito por </contrib>
|
||
</author>
|
||
</authorgroup>
|
||
</sect1info>
|
||
|
||
<title>ATM en &os; 5.X</title>
|
||
|
||
<sect2>
|
||
<title>Configuración de IP clásico sobre ATM (PVCs)</title>
|
||
|
||
<para>IP clásico sobre ATM (<acronym>CLIP</acronym>) es el
|
||
método más sencillo de utilizar ATM con IP. Se puede
|
||
utilizar con conexiones conmutadas (SVC) y con conexiones
|
||
permanentes (PVCs). En esta sección se describe cómo
|
||
configurar una red basada en PVCs.</para>
|
||
|
||
<sect3>
|
||
<title>Configuraciones en red mallada completa</title>
|
||
|
||
<para>El primer método para configurar <acronym>CLIP</acronym>
|
||
con PVCs consiste en conectar unas máquinas con otras mediante
|
||
circuitos PVC dedicados. Aunque la configuración parece
|
||
sencilla llega a resultar imposible de manejar cuando se posee un
|
||
número grande de máquinas. El ejemplo que se muestra
|
||
a continuación supone que nuestra red posee cuatro
|
||
máquinas y que cada una se conecta a la red ATM mediante una
|
||
tarjeta de red ATM. El primer paso consiste en planificar las
|
||
direcciones IP y las conexiones ATM que se van a configurar en las
|
||
máquinas.</para>
|
||
|
||
<informaltable frame="none">
|
||
<tgroup cols="2">
|
||
<colspec colwidth="1*">
|
||
<colspec colwidth="1*">
|
||
<thead>
|
||
<row>
|
||
<entry>Máquina</entry>
|
||
<entry>Dirección IP</entry>
|
||
</row>
|
||
</thead>
|
||
|
||
<tbody>
|
||
<row>
|
||
<entry><hostid>hostA</hostid></entry>
|
||
<entry><hostid role="ipaddr">192.168.173.1</hostid></entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><hostid>hostB</hostid></entry>
|
||
<entry><hostid role="ipaddr">192.168.173.2</hostid></entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><hostid>hostC</hostid></entry>
|
||
<entry><hostid role="ipaddr">192.168.173.3</hostid></entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><hostid>hostD</hostid></entry>
|
||
<entry><hostid role="ipaddr">192.168.173.4</hostid></entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</informaltable>
|
||
|
||
<para>Para construir una red completamente mallada necesitamos una
|
||
conexión ATM entre cada par de máquinas:</para>
|
||
|
||
<informaltable frame="none">
|
||
<tgroup cols="2">
|
||
<colspec colwidth="1*">
|
||
<colspec colwidth="1*">
|
||
<thead>
|
||
<row>
|
||
<entry>Máquinas</entry>
|
||
<entry>Pareja VPI.VCI</entry>
|
||
</row>
|
||
</thead>
|
||
|
||
<tbody>
|
||
<row>
|
||
<entry><hostid>hostA</hostid> - <hostid>hostB</hostid></entry>
|
||
<entry>0.100</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><hostid>hostA</hostid> - <hostid>hostC</hostid></entry>
|
||
<entry>0.101</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><hostid>hostA</hostid> - <hostid>hostD</hostid></entry>
|
||
<entry>0.102</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><hostid>hostB</hostid> - <hostid>hostC</hostid></entry>
|
||
<entry>0.103</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><hostid>hostB</hostid> - <hostid>hostD</hostid></entry>
|
||
<entry>0.104</entry>
|
||
</row>
|
||
|
||
<row>
|
||
<entry><hostid>hostC</hostid> - <hostid>hostD</hostid></entry>
|
||
<entry>0.105</entry>
|
||
</row>
|
||
</tbody>
|
||
</tgroup>
|
||
</informaltable>
|
||
|
||
<para>Los valores VPI y VCI en cada extremo de la conexión
|
||
pueden ser diferentes pero por simplicidad suponemos que son
|
||
iguales. A continuación necesitamos configurar las
|
||
interfaces ATM en cada máquina:</para>
|
||
|
||
<screen>hostA&prompt.root; ifconfig hatm0 192.168.173.1 up
|
||
hostB&prompt.root; ifconfig hatm0 192.168.173.2 up
|
||
hostC&prompt.root; ifconfig hatm0 192.168.173.3 up
|
||
hostD&prompt.root; ifconfig hatm0 192.168.173.4 up</screen>
|
||
|
||
<para>Suponiendo que la interfaz ATM es
|
||
<devicename>hatm0</devicename> en todas las máquinas. Ahora
|
||
necesitamos configurar los PVCs en las máquinas (suponemos que
|
||
ya se han configurado de forma correcta en el <quote>switch</quote>
|
||
ATM, para lo cual puede ser necesario consultar el manual del
|
||
<quote>switch</quote>).</para>
|
||
|
||
<screen>hostA&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 100 llc/snap ubr
|
||
hostA&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 101 llc/snap ubr
|
||
hostA&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 102 llc/snap ubr
|
||
|
||
hostB&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 100 llc/snap ubr
|
||
hostB&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 103 llc/snap ubr
|
||
hostB&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 104 llc/snap ubr
|
||
|
||
hostC&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 101 llc/snap ubr
|
||
hostC&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 103 llc/snap ubr
|
||
hostC&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 105 llc/snap ubr
|
||
|
||
hostD&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 102 llc/snap ubr
|
||
hostD&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 104 llc/snap ubr
|
||
hostD&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 105 llc/snap ubr</screen>
|
||
|
||
<para>Por supuesto que se pueden utilizar otras especificaciones
|
||
de tráfico siempre y cuando las tarjetas de red las
|
||
soporten. En este caso la especificación del tipo de
|
||
tráfico se completa con los parámetros del
|
||
tráfico. Puede acceder a la ayuda de &man.atmconfig.8;
|
||
así:</para>
|
||
|
||
<screen>&prompt.root; <userinput>atmconfig help natm add</userinput></screen>
|
||
|
||
<para>y por supuesto en la página de manual de
|
||
&man.atmconfig.8;.</para>
|
||
|
||
<para>Se puede crear la misma configuración utilizando el
|
||
fichero <filename>/etc/rc.conf</filename>. Para la máquina
|
||
<hostid>hostA</hostid> sería algo así:</para>
|
||
|
||
<programlisting>network_interfaces="lo0 hatm0"
|
||
ifconfig_hatm0="inet 192.168.173.1 up"
|
||
natm_static_routes="hostB hostC hostD"
|
||
route_hostB="192.168.173.2 hatm0 0 100 llc/snap ubr"
|
||
route_hostC="192.168.173.3 hatm0 0 101 llc/snap ubr"
|
||
route_hostD="192.168.173.4 hatm0 0 102 llc/snap ubr"</programlisting>
|
||
|
||
<para>El estado de todas las rutas
|
||
<acronym>CLIP</acronym> se puede obtener en todo momento
|
||
con:</para>
|
||
|
||
<screen>hostA&prompt.root; <userinput>atmconfig natm show</userinput></screen>
|
||
</sect3>
|
||
</sect2>
|
||
</sect1>
|
||
</chapter>
|
||
|
||
<!--
|
||
Local Variables:
|
||
mode: sgml
|
||
sgml-declaration: "../chapter.decl"
|
||
sgml-indent-data: t
|
||
sgml-omittag: nil
|
||
sgml-always-quote-attributes: t
|
||
sgml-parent-document: ("../book.sgml" "part" "chapter")
|
||
End:
|
||
-->
|
||
|
||
<!-- LocalWords: config mnt www -->
|