Logo de AulaDigital
< Directorio de Cómos

Redes En Linux Como 5

Redes en Linux Como (Previamente Net-3 Como): Información genérica sobre la configuración de redes. Página siguiente Página anterior Índice general

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

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

5.1 ¿Qué necesito para comenzar?

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

Código fuente del núcleo.

Antes que nada:

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

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

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

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

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

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

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

Herramientas de red actualizadas.

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

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

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

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

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

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

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

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

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

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

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

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

y con Debian: 

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

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

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

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

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

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

Aplicaciones de red.

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

Introducción a las direcciones IP.

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

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

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

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

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

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

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

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

Instalar una máquina Linux en una red IP existente

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

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

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

Construir una nueva red propia que nunca conectará con Internet

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.3 Creación de las interfaces de red.

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

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

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

5.4 Configuración de una interfaz de red.

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

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

root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up

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

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

up

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

down

esta opción desactiva una interfaz.

[-]arp

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

[-]allmulti

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

mtu N

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

netmask <direc>

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

irq <direc>

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

[-]broadcast [direc]

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

[-]pointopoint [direc]

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

hw <tipo> <direc>

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

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

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

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

¿Qué hay en un nombre?

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

COM

Organizaciones Comerciales

EDU

Organizaciones Educativas

GOV

Organizaciones Gubernamentales

MIL

Organizaciones Militares

ORG

Otras organizaciones

NET

Organizaciones relacionadas con InterNet

Designador de País

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

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

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

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

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

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

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

Qué información necesitará

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

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

/etc/resolv.conf

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

domain

esta palabra clave especifica el nombre de dominio local.

search

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

nameserver

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

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

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

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

/etc/host.conf

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

order hosts,bind
multi on

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

/etc/hosts

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

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

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

Ejecutar un servidor de nombres

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

5.6 Configuración de la interfaz loopback

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

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

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

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

5.7 Encaminamiento (Routing).

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

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

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

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

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

root# cat /proc/net/route

o con cualquiera de estas otras: 

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

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

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

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

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

root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up

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

root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0

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

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

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

root# route add default gw 192.168.1.1 eth0

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

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

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

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

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

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

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

Entonces ¿qué hace el programa routed?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Sólo necesita ejecutar un protocolo de encaminamiento dinámico cuando su máquina Linux tenga la posibilidad de elegir entre múltiples caminos para llegar a un destino.
  2. El demonio de encaminamiento dinámico modificará automáticamente la tabla de encaminamiento para ajustarla a los cambios en la red.
  3. RIP es adecuado para redes de tamaño pequeño y medio.

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

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

autónomo (standalone)

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

esclavo del servidor inetd

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

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

/etc/services

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

nombre      puerto/protocolo        sobrenombres     # comentario

nombre

una sola palabra que representa el servicio descrito.

puerto/protocolo

este campo está dividido en dos subcampos.

puerto

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

protocolo

este subcampo debe tener como valor tcp o udp.

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

sobrenombres

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

Cualquier texto que aparezca en una línea después de un caracter # es ignorado y se trata como un comentario.

Un ejemplo de fichero /etc/services.

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

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

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

# Local services

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

/etc/inetd.conf

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

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

servicio  tipo_socket  proto  flags  usuario  servidor  argumentos

servicio

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

tipo_socket

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

proto

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

flags

sólo hay dos valores posibles. Este campo le dice a inetd si el programa servidor de red libera el socket después de comenzar la ejecución, y si por tanto inetd podrá ejecutar otro servidor para la siguiente petición de conexión, o si inetd deberá esperar y asumir que el demonio servidor que esté ejecutándose controlará las nuevas peticiones de conexión. Esto tiene su dificultad, pero por norma general todos los servidores tcp deberían tener esta entrada con el valor nowait y la mayoría de servidores udp deberían tener wait. De todas maneras hay algunas excepciones notables, por lo que debería leer la guía de ejemplo si no está seguro.

usuario

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

servidor

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

argumentos

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

Un ejemplo de /etc/inetd.conf

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

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

5.9 Otros ficheros de configuración relacionados con la red

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

/etc/protocols

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

nombredelprotocolo  número  sobrenombres

El fichero /etc/protocols proporcionado con la distribución Debian http://www.debian.org es como sigue: 

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

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

/etc/networks

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

nombredelared direccióndered

Un ejemplo podría ser: 

loopnet    127.0.0.0
localnet   192.168.0.0
amprnet    44.0.0.0

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

5.10 Seguridad en la red y control de acceso.

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

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

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

/etc/ftpusers

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

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

/etc/securetty

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

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

El mecanismo de control de acceso hosts de tcpd

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

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

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

/etc/hosts.allow

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

El formato del fichero es bastante sencillo: 

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

lista de servicios

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

lista de hosts

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

  • ALL, que se corresponde con cualquier host.
  • LOCAL se corresponde con cualquier nombre de host que no contenga un . o sea que esté en el mismo dominio que su máquina;
  • PARANOID se corresponde con cualquier nombre que no se corresponda con esta dirección (name spoofing). Hay una última palabra que también es útil. La palabra
  • EXCEPT permite proporcionar una lista con excepciones. Esto lo cubriremos en un capítulo posterior.

orden

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

Un ejemplo: 

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

/etc/hosts.deny

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

Un ejemplo simple podría parecerse a esto: 

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

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

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

/etc/hosts.equiv

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

Configure su demonio de ftp adecuadamente.

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

Cortafuegos para redes.

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

Otras sugerencias.

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

sendmail

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

NFS y otros servicios Sun RPC

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

Página siguiente Página anterior Índice general