[OpenBSD]

6.0 - Redes


6.0.1 - Introducción

Para la comprensión de la mayor parte de este documento será de gran ayuda que haya leido y, por lo menos, asimilado en parte el capítulo «Configuración del Núcleo» de las Preguntas Frecuentes, y las páginas de manual ifconfig(8) y netstat(1).

Si es Vd. un administrador de redes y está configurando protocolos de enrutamiento, si está usando su sistema OpenBSD como un enrutador, si necesita conocer más a fondo los protocolos de redes IP, entonces es realmente necesario que lea Understanding IP addressing. ¡Éste es un excelente documento que contiene conocimientos fundamentales sobre redes de IP!

Si está trabajando con aplicaciones como servidores de http, servidores de ftp, y servidores de correo, se puede beneficiar en gran medida de la lectura de los RFC.

(Nota: existe un proyecto de traducción de RFCs al castellano conocido como RFC-ES)

Lo más seguro es que no los pueda leer todos. Seleccione algunos temas que le interesen, o que use en su entorno de red. Léalos y averigüe cómo deberían funcionar. Los RFC definen muchísimas (miles) de las normas para protocolos en internet y cómo se supone que deben funcionar.

6.1 - Configuración inicial de la red

6.1.1 - Idenficación y configuración de la interfaces de red

Lo primero que debe hacer para empezar es identificar su interfaz de red. En OpenBSD las interfaces se designan por el tipo de tarjeta, no por el tipo de conexión. Puede ver su tarjeta de red iniciar durante el arranque, o después del arranque usando la orden dmesg(8). También puede ver su interfaz de red usando la orden ifconfig(8). Por ejemplo, vea a continuación la salida originada por dmesg para una tarjeta de red ne2k, que usa un nombre de dispositivo ne.

Si no sabe cuál es el nombre de su dispositivo, aquí tiene una lista de tarjetas comunes con sus nombres de dispositivo.

También puede comprobar qué interfaces han sido identificadas usando la utilidad ifconfig(8). He aquí la salida que mostraría un dispositivo ne2k.

Como habrá podido comprobar, ifconfig(8) muestra mucha más información de la que necesitamos en este momento. Pero lo importante aquí es que nos permite ver nuestra interfaz. En el ejemplo anterior, la tarjeta de la interfaz ya está configurada. Esto se sabe al ver que los valores ya han sido fijados en "inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255", y que los indicadores UP y RUNNING están activados. También podrá notar muchas otras interfaces. A continuación puede ver una lista de interfaces que se supone que deben estar ahí.

Si su interfaz no ha sido configurada, el primer paso será crear el fichero /etc/hostname.${IF}, donde el nombre de su interfaz substituirá ${IF}. De acuerdo con la información de los ejemplos anteriores, el nombre sería /etc/hostname.ne3. La composición de este fichero es como sigue a continuación. Para leer más sobre el formato de este fichero, tome como referencia la página de manual hostname.if(5)

Por lo tanto, para el ejemplo anterior, un nombre correcto sería parecido a este:

El siguiente paso será la configuración de su pasarela. Para ello basta con que ponga el IP de su pasarela en el fichero /etc/mygate. Esto permitirá que su pasarela se active en el momento del arranque. A continuación deberá configurar sus nombres de servidores ("nameservers") y su fichero /etc/hosts. Para configurar sus nombres de servidores debe crear un fichero con el nombre /etc/resolv.conf. Puede leer más sobre el formato de este fichero en la página de manual resolv.conf(5). El siguiente ejemplo es para un uso típico. En este ejemplo sus servidores de dominio son 125.2.3.4 y 125.2.3.5. También pertenece al dominio «sudominio.dom».

Desde este punto ya puede reiniciar o bien ejecutar el guión de configuración /etc/netstart. Puede hacerlo escribiendo (como root):

Fíjese en que se producen un pequeño número de errores, pero éstos se refieren a la interfaz de loopback. Por lo tanto puede ignorar estos errores. A partir de aquí su sistema debería funcionar correctamente. Puede hacer una comprobación con ifconfig(8) para asegurarse de que su interfaz se configuró correctamente. También puede comprobar sus rutas con netstat(1) o route(8). A continuación puede ver un ejemplo de cómo ver sus tablas de rutas usando ambas herramientas.

6.1.2 - Configuración del sistema OpenBSD como pasarela ("gateway")

Ésta es la información básica que necesita para configurar su sistema OpenBSD como una pasarela (también llamada «enrutador» o «encaminador»). Si piensa usar OpenBSD como un enrutador en Internet, le sugerimos que lea también la sección con las instrucciones sobre la configuración de Filtros IP, para bloquear tráfico potencialmente malicioso. Además, debido a la escasa disponibilidad de direcciones IPv4 en los proveedores de servicios de redes y registros regionales, es conveniente leer la sección sobre NAT para información sobre cómo conservar su espacio de dirección IP.

El núcleo GENERIC posee la capacidad de permitir IP Forwarding, pero debe ser activado. Para ello debe usar la utilidad sysctl(8). Para que los cambios sean permanentes, debe editar el fichero /etc/sysctl.conf para habilitar IP Forwarding. Esto lo puede llevar a cabo añadiendo la siguiente línea en ese fichero de configuración.

Para que este cambio surja efecto sin tener que reiniciar el sistema, use directamente la utilidad sysctl(8). Recuerde que este cambio todavía no existirá después de reiniciar, y que necesitará ser ejecutado como root.

A continuación modifique las rutas en los otros huéspedes de ambos lados. OpenBSD ofrece muchas posibilidades de uso como enrutador, usando software como routed(8), gated, mrtd, y zebra. OpenBSD dispone de soporte para gated y mrtd en la colección de portes. OpenBSD incluye soporte para varias interfaces T1, HSSI, ATM, FDDI, Ethernet, e interfaces de serie (PPP/SLIP).

6.1.3 - Configuración de alias en una interfaz.

¡Desde la versión 2.8, ya /etc/ifaliases no se usa!

OpenBSD dispone de un simple mecanismo para configurar los alias de ip en una interfaz. Para ellos sólo tiene que editar el fichero /etc/hostname.<if>. El guión /etc/rc, que forma parte de la jerarquía de inicio rc, leerá este fichero durante el proceso de inicio del sistema. Por ejemplo, supongamos que el usuario tiene una interfaz dc0 y pertenece a la red 192.168.0.0. Otra información de importancia:

Unas notas sobre los alias: en OpenBSD sólo se usa el nombre de la interfaz; no existen diferencias entre el primer alias y el segundo, por lo tanto, a diferencia de otros sistemas operativos, en OpenBSD no hay que referirse a ellos como dc0:0 y dc0:1. Si hace referencia a una direcció de IP alias específica con ifconfig, o si está añadiendo un alias, asegúrese de decir 'ifconfig int alias' en lugar de 'ifconfig int' en la línea de órdenes. Puede eliminar los alias con 'ifconfig int delete'.

Asumiendo que esté usando direcciones de IP múltiples que estén en la misma subred IP con alias, la configuración de su enmascaramiento de red ("netmask") para cada alias pasa a ser 255.255.255.255. No necesitan seguir el netmask del primer IP ligado a la interfaz. En el siguiente /etc/hostname.dc0 de ejemplo, se añaden dos alias al dispositivo dc0, el cual, por cierto, se configuró como 192.168.0.2 netmask 255.255.255.0.

Una vez que haya configurado este fichero será necesario reiniciar para que los cambios funcionen. Sin embargo, puede hacer efectivos los alias a mano, usando la utilidad ifconfig(8). Para hacer efectivo el primer alias use la orden:

Para ver estos alias debe usar la orden:

6.2 - Filtros IP

El paquete IP Filter se creó con el fin de gestionar dos tareas, tratar con permisos ipf(8) para el envío a nivel de paquetes y asignar huéspedes/subrredes a un campo de direcciones externas ipnat(8). Los ficheros de configuración para estos dos servicios son /etc/ipf.rules y /etc/ipnat.rules.

Para activarlos durante el inicio del sistema es necesario editar /etc/rc.conf. También es necesario tener la línea net.inet.ip.forwarding=1 en /etc/sysctl.conf (o el núcleo de su sistema necesita tener activada la opción IPFORWARDING o GATEWAY). Y también se necesita un núcleo compilado con las opciones IPFILTER y IPFILTER_LOG (los núcleos GENERIC no disponen de estas opciones).

Si ha compilado IP Filter en su núcleo pero no lo ha activado en el fichero /etc/rc.conf, lo puede activar fácilmente.

El indicador -E en ipf 'activa' IP Filter. El indicador -Fa limpia cualquier regla que pueda tener ahí.
-f /etc/ipf.rules carga las reglas desde /etc/ipf.rules.

Si hace algún cambio en /etc/ipf.rules después de haber cargado ipf, puede recargar sus reglas muy fácilmente.

Lo mismo para ipnat... También puede activar ipmon para el depurado.

A partir de aquí este documento cubrirá algunos aspectos básicos de configuraciones de ipf y ipnat. Existen muchos ejemplos para ipnat y ipf en /usr/share/ipf, le recomendamos que escoja el que más se acerque a la configuración que Vd. desee, y que lo modifique conforme a sus necesidades. Puede encontrar más información sobre Filtros IP en los archivos de la lista de correo IP Filter, en las páginas de IP Filter, y en el IP Filter HOWTO.

IPF

Para activar ipf desde el momento del inicio del sistema necesita modificar /etc/rc.conf de modo que lea IPFILTER=YES. IP Filter (ipf) está controlado por /etc/ipf.rules, que se leerá durante el inicio. Para una explicación más detallada lea la página de manual ipf(5). En los siguientes ejemplos, fxp0 representa la interfaz externa a internet. En su caso puede ser diferente según el adaptador de ethernet de que disponga en su máquina. En estas reglas se asumirá que existe una conexión permanente a internet, del mismo tipo que la de un servidor de web.

Las reglas de IP Filter se procesan de modo secuencial desde el principio hasta el final, siendo de ayuda para visualizar cada paquete que tenga que atravesar cada regla antes de alcanzar su destino.

Por ejemplo, el grupo de reglas predefinido permite que entren y salgan todos los paquetes:

Supongamos ahora que no queremos permitir ninguna conexión entrante por el puerto 3306 (mysql) porque la base de datos sólo debería permitir la conexión de forma local. En este caso el grupo de reglas sería así: Que traducido viene a decir lo siguiente: «bloquear todos los paquetes entrantes desde cualquier sitio hasta cualquier sitio cuyo destino sea 3306». Lo que ocurriría es que un paquete destinado al puerto 3306 en la interfaz fxp0 pasaría la primera regla "pass in", y acto seguido sería bloqueado por la regla "block in port = 3306". En el caso en que se invirtieran las reglas de entrada (recuerde que el orden es importante) los paquetes destinados al puerto 3306 pasarían debido a que la última regla en el grupo permite que pasen todos los paquetes. Cuando esté escribiendo reglas para el filtrado de paquetes es importante que tenga en cuenta lo siguiente: La última regla que concuerde tendrá precedencia.

Por supuesto que existen excepciones para toda regla. La opción quick filtra el paquete en la primera regla que concuerde. Veamos el defectuoso ejemplo anterior añadiéndole la opción quick a la regla "block in":

Un paquete destinado para el puerto 3306 será filtrado por la regla "block in quick" y bloqueado inmediatamente. Todos los paquetes destinados a otros puertos no encontrarán una concordancia en las reglas hasta llegar a la regla "pass in" que permite que pasen todos los paquetes.

Denegación predefinida

La política de filtrado de páquetes más segura es la de «denegación por definición». Esta política es mucho más segura que la denegación explícita de cada servicio protegido, permite grupos de reglas más breves, y puede proteger de un servicio que haya sido mal configurado de modo accidental y que haya quedado expuesto.

Veamos ahora otro ejemplo de grupo de reglas real, seguido de una explicación línea por línea. El siguiente ejemplo es para un servidor de web con una política de denegación predefinida que sólo permite conexiones ssh (para administración), y conexiones http (puerto 80) y https (puerto 443).

Esto permitirá las conexiones desde cualquier sitio a los puertos 22 (ssh), 80 (http) y 443 (https). Cualquier otro intento de conexión distinto será bloqueado, y permitirá todas las conexiones salientes. Este grupo de reglas es muy estricto. Pero, ¿y si Vd. sólo quisiera permitir la conexión a ssh a huéspedes internos en su bloque de direcciones 1.1.1.0, y al mismo tiempo permitir conexiones externas a http y https?

De acuerdo, pero, ¿y si sólo quisiera permitir la administración remota de su servidor de web a una sola máquina (1.1.1.1)? En tal caso cambiaría esta regla: por esta otra: IP Filter tiene soporte para formas de "netmask address" tanto CIDR como de punto decimal. Por tanto podría escribir lo anterior de esta forma: pero, ¿para qué?

Ejemplos de reglas

Aquí puede ver algunas buenas reglas que puede usar cualquier persona (se asume que fxp0 es la interfaz externa conectada a interner). Para empezar configuraremos una simple protección contra la falsificación de direcciones.

También es una buena idea separar su interfaz de loopback de sus otras reglas. Nuestro grupo de reglas empieza a tener buena pinta; cuando lo ponemos todo junto, esto es lo que vemos:

Registro de paquetes

De momento va bastante bien, pero podría ir mejor. ¿Qué haríamos si quisiéramos obtener un registro de cualquier intento de conexión al puerto 22 (ssh) que fuera por nuestro cortafuegos? Sería fácil, IP Filter puede gestionar este caso con la opción clave log:

Esta regla permitirá la conexión remota por el puerto 22 a nuestra máquina de administración, pero denegará y registrará cualquier otro intento de conexión al puerto 22.

Filtrado de paquetes según el protocolo

IP Filter puede filtrar cualquier protocolo IP basándose en su número o nombre en /etc/protocols. Para que se entienda con más claridad, sólo trataremos aquí con tcp, udp, e icmp. Éstos son los protocolos de uso más común. Todas las aplicaciones básicas de internet dependen de la disponibilidad y de la correcta operatibilidad de estos protocolos.

Para que ipf filtre según qué protocolo, se debe usar la opción clave proto. Basándonos en el ejemplo anterior, y puesto que ssh funciona sobre tcp, sólo deberíamos permitir la conexión a paquetes tcp. Usando la opción clave proto para permitir sólo conexiones tcp, obtendremos una regla como esta:

Pero, ¿y si necesitáramos permitir conexiones a un servicio como bind que funciona tanto sobre tcp como sobre udp? En el caso de tcp/udp, IP Filter nos permite agrupar ambos protocolos en un sólo (Nota: esto sólo es válido para tcp/udp). Usando el ejemplo de bind, una regla que permita conexiones de tcp y udp en un entorno de denegación por definición sería:

Filtrado de paquetes

Además de filtrar según el protocolo, IP Filter también puede gestionar paquetes de IP fragmentados (un método común para bular filtros de paquetes). Hay dos opciones claves posibles que se pueden usar para tratar paquetes de ip fragmentados, frag para paquetes de IP fragmentados normales, o short para paquetes de IP con cabeceras demasiado pequeñas para poder compararlas. Ya que, dependiendo de las condiciones de conexión, los paquetes fragmentados pueden darse normalmente, es mejor filtrar sólo los paquetes con cabeceras demasiado pequeñas como para obtener comparaciones válidas. Esto se puede conseguir con la siguiente regla:

¿Y qué hay de las Opciones de IP? IP Filter también puede tratar con ese tipo de paquetes. Los paquetes se pueden bloquear si tienen las opciones de IP activadas, o se pueden bloquear según las opciones de IP que estén activadas. Por ejemplo, la siguiente regla bloqueará y creará un registro de todos los paquetes con las opciones de ip activadas. Sin embargo, esto puede estropear algunas cosas como traceroute(8). También es posible especificar qué opciones no serán permitidas. Por ejemplo, una buena regla es la de bloquear todos los paquetes con opciones de enrutamiento de fuentes. Se puede llevar a cabo con esta regla: Indicadores TCP, conexiones establecidas, y mantenimiento del estado

La principal fuerza de IP Filter reside en su capacidad para filtrar paquetes basándose en los indicadores TCP, y mantener conexiones establecidas y el estado de la conexión. Se recomienda a todos los usuarios que deseen filtrar paquetes basándose en indicadores TCP que entiendan antes el papel que desempeña cada indicador. Por ejemplo, si un usuario quisiera denegar la conexión a todos los paquetes con los indicadores FIN, URG, y PSH activados (como por ejemplo un intento de obtener la huella digital de un sistema operativo por nmap), podría usar una regla como la siguiente:

(Gracias a Kyle Hargraves por esta regla)

El próximo truco de IP Filter es su capacidad para «mantener el estado» (keep state). Se ha descrito mantener el estado como «no hablar hasta que no le hablen», o en otras palabras, una vez que se ha establecido una conexión, los paquetes ya no tienen que atravesar grupos de reglas. Ésta es una potente característica que permite escribir unas reglas mucho más sencillas y seguras.

Por ejemplo, veamos cómo se puede aplicar este estado al ejemplo del grupo de reglas anterior. ¿Todavía está confundifo?. Revisémoslo: estamos permitiendo el acceso de gestión desde nuestra máquina de clase C al puerto 22 (ssh), y el acceso web a todo el tráfico a los puertos 80 (http) y 443 (https). Estamos bloqueando el resto de tráfico. Pero, ¿y si quisiera conectar por ssh fuera del servidor de web? o, ¿y si necesitara usar lynx para buscar algo en las páginas de Preguntas Frecuentes? No podría, ya que habría bloqueado todas las conexiones entrantes que no estuvieran dirigidas a los puertos especificados. Aunque ésta es la ruta más segura, puede ser muy poco conveniente. Al añadir las opciones clave keep state a la regla "pass out", puede permitir el paso de conexiones entrantes que sean respuestas a conexiones que Vd. haya iniciado, como por ejemplo al navegar por la web. Recuerde que es necesario especificar para qué protocolo estamos manteniendo el estado.

Este pequeño cambio supondrá un dramático incremento en la flexibilidad y seguridad de su grupo de reglas, debido a que IP Filter es extremadamente flexible. Por ejemplo, en el grupo de reglas anterior, está permitiendo todo el tráfico tcp a los puertos 80 y 443. Aún puede ajustarlo un poco más. Para establecer una conexión tcp sólo necesita permitir que tenga lugar el saludo inicial ("handshake"); una vez que esto ocurra, puede bloquear el tráfico a ese puerto y permitir a la regla "keep state" que gestione la conexión. Para que se complete el saludo inicial, sólo necesita permitir el paso a los paquetes con los indicadores SYN y SYNACK activados. Al dejar pasar sólo paquetes con SYN y SYNACK activados puede prevenir muchas formas de escaneos de puertos como puede ser el escaneo FIN. Ahora las reglas están de este modo:

Pongamos ahora todas las reglas que tenemos, poniéndolas en un solo paquete de reglas. Este paquete de reglas tendrá una política de denegación predefinida, permitirá conexiones de gestión sólo desde una red local (mediante ssh), y permitirá el paso de tráfico entrante en los puertos 80 (http) y 443 (https). Además, protegerá contra direcciones de ip falsificadas no enrutables, y bloqueará todos los paquetes que no estén tan fragmentados que no puedan ser inspeccionados. Una configuración bastante comprensiva para un servidor de web público. He aquí cómo quedaría /etc/ipf.rules:

Si tiene problemas puede activar el ingreso en reglas individuales para analizarlos; o sea, pass in log quick on fxp0 from 1.1.1.0/24 to any port = 22
Cuando modifique el fichero de configuración para obtener ficheros log de información de los paquetes, no se olvide de hacer que los cambios surtan efecto mediante: ipf -Fa -f /etc/ipf.rules
ipmon escribirá las entradas de los ficheros de log en /var/log/ipflog.
Para más información sobre ipf, el IPF howto es una fuente excelente, como también lo son los recursos disponibles en las páginas de IP Filter.

6.3 - IPNAT

Desarrollado sobre un trabajo original de Wayne Fergerstrom <wayne@methadonia.net>

6.3.1 Introducción a NAT

Sección de Introducción

Esta sección pretende servir de ayuda para aquellos que instalen y configuren la «Traducción de Direcciones de Red» (NAT, "Network Address Translation") en una máquina con OpenBSD. Se asume que el usuario ya ha configurado y activado una máquina con OpenBSD con dos tarjetas de red (una conectada a Internet y la otra a la red local). IP NAT funcionará en máquinas con sólo un NIC, sin embargo, como los paquetes entrarán y saldrán de la misma interfaz, las colisiones de ethernet ralentizarán el rendimiento de forma considerable.

Basado en RFC 1631, ipnat ofrece una forma fácil para la asignación de redes locales a una dirección única enrutable («real») de internet. Esto es de gran utilidad si no dispone de direcciones asignadas oficialmente para cada huésped en su red interna. Cuando configura redes privadas/internas, puede aprovechar los bloques de direcciones reservados (asignados en RFC 1918), como: 

10.0.0.0/8 (10.0.0.0 - 10.255.255.255)
172.16.0.0/12 (172.16.0.0 - 172.31.255.255)
192.168.0.0/16 (192.168.0.0 - 192.168.255.255)

Terminología

Los términos convencionales usados en este documento son bastante claros. Con el fin de documentarlos, repasaré algunos de estos términos y la acepción que toman en este documento.


Detalles de configuración

Esta parte se refiere a los detalles de configuración de las máquinas para este documento. Su configuración será distinta de ésta, pero el propósito de este documento es el de ofrecerle una breve idea de cómo puede ser, con el fin de que pueda adaptar esta información a su configuración.


6.3.2 Traducción de direcciones de red


Introducción a NAT

Cada día más empresas y usuarios entran en Internet, y cada uno debe tener una dirección IP, pero las direcciones IP públicas son cada vez más difíciles de conseguir. Para muchas personas la solución ha sido la «Traducción de Direcciones de Red» (o NAT). NAT es un modo muy simple y a la vez muy potente de conectar una LAN a Internet sin tener que comprar o alquilar direcciones IP para cada máquina. NAT también es conocido como «Enmascaramiento de IP» entre los usuarios de Linux.

Cuando NAT está funcionando correctamente, permite que los usuarios dentro de la LAN puedan acceder a Internet a través de diferentes direcciones de IP (la que haya activado con su proveedor). Cada máquina conectada a la LAN usa la dirección IP (de forma transparente) de la máquina que está configurada para usar la dirección de IP asignada por el Proveedor de Servicion de Internet (ISP).

El modo en que funciona NAT es increiblemente simple. Cuando un cliente dentro de la LAN quiere conectar a la máquina en Internet, le envía un paquete TCP con un requerimiento de conexión. Dentro de la cabecera del paquete TCP se encuentra la dirección IP del cliente (o sea, 192.168.1.40) y la dirección IP del anfitrión requerido (o sea, 123.45.67.89). La máquina en la que está funcionando NAT intercepta este paquete TCP y cambia la dirección IP del cliente de 192.168.1.40 a la dirección IP de la máquina conectada a Internet (o sea, 24.5.0.5). De este modo engaña a la máquina anfitriona, haciéndole pensar que la conexión requerida proviene de la máquina con NAT, no de la máquina cliente. Entonces el anfitrión envía de vuelta respuestas a la máquina NAT como si ésta fuera la que se estuviera conectando. Cuando la máquina NAT recibe las respuestas, las traduce rápidamente y envía el paquete al cliente. El cliente no tiene ni la más remota idea de lo que está ocurriendo y la falsificación de la conectividad a Internet es totalmente transparente.

El ejemplo siguiente muestra NAT de un modo más claro:


Porqué usar NAT

Una vez que ya había conseguido un módem cable en mi nuevo apartamento me dí cuenta de que tenía un pequeño problema. ¿Cómo podría conseguir acceso a Internet para mis compañeros de apartamento si el módem estaba en mi habitación? Sólo había unas pocas opciones que podían ayudarme, y que iban desde obtener direcciones IP extras, pasando por instalar un servidor proxy, hasta instalar NAT (no permita que el ejemplo del módem cable le engañe, NAT es lo suficientemente potente como para enmascarar un gran red con cientos o incluso miles de máquinas).

Existen varias razones por las que decidí instalar NAT, la primera de ellas mi economía. En la casa vivían dos compañeros de piso (cada uno con su propio PC) y yo (con tres PCs). Mi ISP sólo permitía tres direcciones IP por casa, lo que significaba que no habían suficientes IPs para que cada máquina pudiera tener acceso a Internet.

Usando NAT cada máquina tendría una dirección IP única (interna), pero compartirían la única dirección IP que mi ISP me dio. El coste se redujo.


Preconfiguración

Para activar NAT en su máquina OpenBSD, necesitará configurar IPF y NAT. Esto se puede llevar a cabo de una manera fácil editando los ficheros que aparecen en la siguiente lista (haga los cambios al fichero de modo que aparezcan como las opciones que siguen a continuación):

/etc/rc.conf (este fichero se usa para iniciar servicios durante el arranque)

/etc/sysctl.conf

Despuís de haber hecho estos cambios, la máquina estará lista para la configuración de NAT.


Configuración

El primer paso es configurar el fichero de reglas de IPF (/etc/ipf.rules). Para el propósito que persigue este documento, dejaremos que el tráfico pase a través de esta opción de cortafuegos sin que haya interferencias. El fichero será como sigue:

Para más información puede leer la sección 6.2 de estas Preguntas Frecuentes.

La sintaxis del fichero de configuración de NAT (/etc/ipnat.rules) es bastante simple. De acuerdo con el ejemplo de configuración anterior, el fichero de configuración de NAT contendrá las siguientes entradas:

He aquí lo que significan estas líneas.

La segunda línea tiene casi la misma entrada que la primera, exceptuando la parte final. En esta línea se indica a ipnat que debe asignar cualquier otra cosa (que no sea tcp/udp, ya que esos paquetes concuerdan en la primera línea) a cualquier puerto que requiera (usado por ICMP y otros protocolos). Una vez que esto está en el fichero, sólo tiene que ejecutar el dæmon IPF.


Funcionamiento

Ejecutar NAT también es un proceso muy sencillo. Una vez que haya acabado de configurarlo, hay dos maneras de activar NAT. La primera manera, y la mejor si fuera posible comprobar la fase de configuración, es reiniciando su sistema OpenBSD. Para ello basta que use la orden «reboot«.

Si quiere ejecutar ipnat desde la línea de órdenes, use las siguiente órdenes:

Con la primera línea de órdenes se activa IPF (recuerde que NAT depende de IPF, y por lo tanto es necesario iniciar IPF y tenerlo en funcionamiento antes de poder cargar NAT). Las opciones en la línea de órdenes "-Fa" limpian cualquier entrada existente. "-f /etc/ipf.rules" indica a ipf dónde encontrar el fichero con las reglas. "-E" es el interruptor para activar el dæmon IPF.

La segunda línea de órdenes es para activar NAT. "-CF" limpia y descarga todas las entradas existentes en la tabla de NAT. "-f /etc/ipnat.rules" indica a NAT dónde encontrar el fichero con las reglas de NAT. Ahora ya tiene NAT funcionando. Así de sencillo.

Nota: para volver a cargar las configuraciones de NAT (en el caso en que las cambiara y no quisiera reiniciar) ejecute la segunda orden de nuevo. Las configuraciones serán descargadas y cargadas de nuevo.


6.3.3 Base de conocimientos de NAT


Verificar el estado de NAT

Para averiguar cómo está funcionando NAT o asegurarse de que las configuraciones hayan hecho efecto, use la opción "-l". Esta opción le mostrará un listado de todas las opciones de configuración y sesiones actuales que esté usando ipnat:

El propósito de las primeras dos líneas es el de verificar las configuraciones que se introdujeron anteriormente en /etc/ipnat.rules. Cualquier línea a partir de esas dos mostrará una lista de las conexiones que estén siendo actualmente controladas por NAT.

Limitaciones de NAT (en FTP)

NAT tiene unas pocas limitaciones a tener en cuenta. Cuando un usuario conecta a un servidor de FTP remoto y pide información o un fichero a éste, el servidor de FTP conectará con el cliente y le transferirá los datos. Este proceso se lleva a cabo por un puerto libre aleatorio. Pero esto representa un problema para los usuarios que intentan obtener acceso a los servidores de FTP desde dentro de la LAN. Cuando el servidor de FTP envía sus datos, los envía al NIC externo en un puerto aleatorio. La máquina NAT los recibe, pero como no tiene ninguna asignación para el paquete desconocido ni para ese puerto en concreto, suelta el paquete y no lo entrega.

La solución a esto está en que el usuario se ubique en «modo pasivo» en su cliente de FTP. De este modo indicará al servidor que desea conectarse a éste, y que no ocurra lo antes mencionado. Así, al realizar el usuario la conexión, NAT la gestionará correctamente.

IP Filter ofrece otra solución para esta situación, un "proxy" de ftp integrado en el código de NAT. Para activarlo, debe escribir algo parecido a lo siguiente antes de sus otras asignaciones para NAT. 

map dc0 192.168.1.0/24 -> 24.5.0.5/32 proxy port ftp ftp/tcp
Con esto, el núcleo del sistema observará sus conexiones por FTP para la orden "PORT" que proceda del cliente de ftp, y substituirá la dirección IP y el puerto con su propia dirección IP externa y con un puerto de su elección. Obviamente, esto requiere de un uso mucho más intensivo de recursos pero, a menos que su máquina de filtrado NAT/IP esté alcanzando una masa crítica, no debería darle ningún problema.


Redireccionamiento del tráfico

Es posible que haya momentos en los que necesite redireccionar el tráfico entrante o saliente hacia cierto protocolo o puerto. Un buen ejemplo de esto podría ser el caso en el que tuviera un servidor que residiera dentro de la LAN y que estuviera haciendo la función de servidor de web. Las conexiones entrantes a su IP válido de Internet se encontrarían con que, a menos que su máquina NAT fuera el servidor de web, no podrían conectar. Para solventarlo usaremos la directiva `rdr' de NAT en el fichero de reglas, para darle las instrucciones sobre a dónde debe redireccionar (o enrutar) una conexión en particular.

Para nuestro ejemplo, supongamos que un servidor de web reside en la LAN y que su dirección IP es 192.168.1.80. El fichero de reglas de NAT necesita una nueva directiva para gestionar esto. Añada una línea parecida a la siguiente a su ipnat.con:

Desglosando esta línea para ver qué signfica cada componente de ella:

Cuando haya terminado de añadir todos los datos, recargue las reglas de NAT y el redireccionamiento comezará de inmediato.


NAT frente a proxy

La diferencia entre NAT y una aplicación basada en proxy es que el software de proxy actúa como un intermediario entre Internet y las máquinas conectadas a la LAN. En prinicipio esto no presenta ningún problema, sin embargo cada aplicación que quiera ejecutar en su máquina y conectarla a Internet a través del servidor de proxy, DEBE reconocer el proxy (ser capaz de usarlo). No todas las aplicaciones con capaces de esto (en especial los juegos). Aún más, no existen aplicaciones para servidores de proxy para todos los servicios de Internet. NAT asigna su red interna de un modo transparente, para que pueda conectar a Internet. La única ventaja de seguridad que proxy tiene sobre NAT es que el software de proxy puede haber sido programado para funciones de seguridad, y puede filtrar según el contenido con el fin de evitar que una macro de virus se interne en su máquina Windows, o proteger sus programas contra desbordamientos de la memoria intermedia ("buffer overflows"), y otros peligros. El mantenimiento de estos filtros es a menudo un trabajo muy pesado.

6.3.4 Referencias y recursos

Ficheros de OpenBSD:

Enlaces de NAT en Internet:


6.4 - DHCP

6.4.1 Cliente DHCP

Para usar el cliente DHCP incluido en OpenBSD, dhclient(8), edite el fichero /etc/hostname.xl0 (suponiendo que su interfaz principal de ethernet sea xl0; la suya podría ser ep0, o fxp0, o cualquier otra). Todo lo que necesita añadir a este fichero es 'dhcp'. 

# echo dhcp >/etc/hostname.xl0
Esto hará que OpenBSD inicie el cliente DHCP automáticamente durante el arranque. OpenBSD obtendrá la información sobre su dirección IP, pasarela, y servidores de DNS desde el servidor de DHCP.

Si quiere iniciar un cliente dhcp desde la línea de órdenes, asegúrese de que el fichero /etc/dhclient existe, y entonces escriba: 

# dhclient fxp0
en donde fxp0 es la interfaz en la que quiere recibir dhcp.

Sea cual fuere el modo en que inicie dhclient, puede evitar que se actualice su DNS de acuerdo con la idea que tenga el servidor dhcp sobre la DNS, comentando las líneas precedidas por 'request' (son ejemplos de la configuración predefinida, pero necesita activarlos para anular la configuración predefinida de dhclient) 

request subnet-mask, broadcast-address, time-offset, routers,
      domain-name, domain-name-servers, host-name, lpr-servers, ntp-servers;
y a continuación eliminar domain-name-servers. También es posible que también desee anular hostname u otras configuraciones.

6.4.2 Servidor DHCP

Si quiere usar OpenBSD como servidor DHCP con dhcpd(8), edite el fichero /etc/rc.conf. Configúrelo poniendo dhcp_flags="-q" en lugar de dhcp_flags=NO. Añada en /etc/dhcp.interfaces las interfaces en las que quiera que dhcp esté a la escucha. 
# echo xl1 xl2 xl3 >/etc/dhcpd.interfaces
y edite /etc/dhcpd.conf. Las opciones son bastante claras: 
        option  domain-name "xyz.mil";
        option  domain-name-servers 192.168.1.3, 192.168.1.5;

        subnet 192.168.1.0 netmask 255.255.255.0 {
                option routers 192.168.1.1;

                range 192.168.1.32 192.168.1.127;
        }

Con esto indicará a sus clientes dhcp que el dominio que deben añadir a sus requerimientos de DNS es xyz.mil (así, si un usuario escribiera 'telnet joe', los enviaría a joe.xyz.mil). Les dirigirá a los servidores de DNS 192.168.1.3 y 192.168.1.5. Para los huéspedes que se encuentren en la misma red que una interfaz de ethernet en la máquina de OpenBSD, que está en el rango 192.168.1.0/24, les asignará una dirección de IP entre 192.168.1.32 y 192.168.1.127, configurando su pasarela por definición como 192.168.1.1.

Si quiere iniciar dhcpd desde la línea de órdenes, después de editar /etc/dhcpd.conf intente lo siguiente: 

# dhcpd -q fxp0
En donde fxp0 es la interfaz que Vd. desea que empiece a servir dhcp. El indicador -q fuerza dhcpd en silencio, de otro modo es muy ruidoso.

Si está actuando como servidor de DHCP para una máquina Windows, es posible que quiera que dhcp ofrezca al cliente una dirección de servidor 'WINS'. Para ello añada la siguiente línea al fichero /etc/dhcpd.conf: 

option	netbios-name-servers	192.168.92.55;
En donde 192.168.92.55 es el IP de su servidor de Windows o Samba. Para ver más opciones que puedan aceptar sus clientes DHCP, lea dhcp-options(5).

6.5 - PPP

El «Protocolo Punto a Punto» es el que se suele usar para crear una conexión con su ISP a través de un módem. OpenBSD puede hacer esto de dos maneras:

Primero trataremos el dæmon del modo de usuario. Para empezar necesitará algo de información sobre su isp. He aquí una lista de la información que necesitará:

Parte de esta información no es estrictamente necesaria, pero será de gran ayuda para configurar ppp. El dæmon PPP de modo usuario utiliza el fichero /etc/ppp/ppp.conf como fichero de configuración. Existen muchos ficheros en /etc/ppp de gran utilidad, que pueden contener diferentes ejemplos de configuración para situaciones distintas. Le aconsejamos que mire en ese directorio.

En caso de no estar usando un núcleo GENERIC, asegúrese de que tiene la siguiente línea en su fichero de configuración:

Configuración inicial para PPP(8)

La configuración inicial del dæmon PPP de modo usuario consiste en editar su fichero /etc/ppp/ppp.conf. Este fichero no existe y debe ser creado, pero puede tomar el fichero /etc/ppp/ppp.conf.sample, editarlo, y crear su propio fichero ppp.conf a partir de ahí. Aquí empezaré con la más simple, y probablemente más utilizada, configuración. A continuación puede ver un pequeño fichero ppp.conf que llevará a cabo la conexión con su ISP y usará sus rutas predefinidas y su nameserver. Para este fichero, toda la información que necesitará será el número de teléfono de su ISP, su nombre de usuario, y su contraseña.

AVISO - En OpenBSD 2.6, el sistema se lanzó con un fichero /etc/ppp/ppp.conf.example que contenía una configuración errónea para el dispositivo. El dispositivo era "set device /dev/cuaa0" cuando en realidad debía ser /dev/cua00, que corresponde al dispositivo para el puerto de comunicaciones 1 (COM1). Su dispositivo podría no estar en COM1, aún así este esquema era erróneo.

La sección en la opción default: será ejecutada cada vez. En ella se configura toda la información crítica. Con "set log" se configuran los niveles de ingreso. Esto se puede cambiar; para más información sobre cómo configurar los niveles de ingreso lea la página de manual ppp(8). El dispositivo se configura con "set device". Éste es el dispositivo en el que se encuentra el modem. En este ejemplo el modem está en el puerto de comunicaciones 2 (COM2), mientras que el puerto de comunicaciones 1 correspondería a /dev/cua00. Con "set speed" se configura la velocidad de la conexión por llamada, y con "set dial" se configura los parámetros de la llamada. Con esto se puede cambiar el tiempo muerto, etc... Es conveniente dejar esta línea más o menos como está.

A continuación puede pasar a configurar la información específica para su ISP. Para ello debe añadir otra opción en la sección default:. Puede dar cualquier nombre a esta etiqueta, pero lo más fácil es darle el nombre de su ISP. En el ejemplo usaremos myisp: para la opción que hará referencia a nuestro ISP. He aquí una configuración simple que incorpora todo lo necesario para conectar:

Aquí hemos configurado información esencial para un ISP específico. La primera opción, "set phone", es para configurar el número de teléfono para la conexión de su ISP. La opción "set login" es para configurar sus opciones de ingreso. En el ejemplo hemos puesto un tiempo muerto de espera de 5, lo que significa que terminará nuestro intento de ingreso después de 5 segundos su no hay transportador. De lo contrario esperará hasta recibir un "login" para enviar su nombre de usuario y contraseña. En el ejemplo, tanto el nombre de usuario como la contraseña son "ppp". Estos valores hay que substituirlos por otros reales. La opción "set timeout" es para configurar el tiempo de espera para todo el proceso de ingreso. La opción "set ifaddr" es algo complicada. He aquí una explicación más extensa sobre ella:

Hemos configurado la línea anterior con el formato "set ifaddr [myaddr[/nn] [hisaddr[/nn] [netmask [triggeradr]]]]". De este modo el primer IP que se especifique es el que querremos como nuestro IP. Sin tiene una dirección IP estática, escríbala aquí. En el ejemplo hemos usado /0, que indica que no es necesario que concuerde ningún bit de esta dirección ip, y que se puede substituir todo. El segundo IP que se especifique es el que esperamos como el IP de nuestro ISP. Si lo sabe lo puede especificar aquí, pero en la línea no sabemos cuál se asignará, así que dejaremos que nos lo digan. Esto es muy útil al negociar con algunas implementaciones PPP que no asignan un número IP a menos que su conexión les requiera ``0.0.0.0''.

La siguiente opción "add default HISADDR" es para configurar la ruta predefinida a su IP. Si su IP cambiara, la ruta se actualizaría de forma automática. Con "enable dns" indicamos a nuestro ISP que autentifique nuestras direcciones nameservers. No haga esto si está usando una DNS local, ya que ppp circunvalará su uso introduciendo algunas líneas en /etc/resolv.conf.

Cómo usar PPP(8)

Ahora que ya tenemos el fichero ppp.conf configurado, podemos intentar una conexión con nuestro ISP. A continuación se darán algunos detalles sobre argumentos de uso común con ppp.

Si usa /usr/sbin/ppp sin pasarle ninguna opción, le pasará al modo interactivo, desde donde podrá interaccionar directamente con el módem. De este modo puede depurar problemas en su fichero ppp.conf.

Acciones adicionales con ppp(8)

Si necesitara ejecutar órdenes al tiempo que conecta o desconecta, puede hacerlo creando dos ficheros adicionales. /etc/ppp/ppp.linkup y /etc/ppp/ppp.linkdown. Puede ver ejemplos de configuración para estos ficheros en:

Puede encontrar más información en http://www.freebsd.org/handbook/userppp.html o en http://www.es.freebsd.org/es/FAQ/ppp.html.

6.6 - Afinar parámetros de red

6.6.1 - ¿Cómo puedo forzar al núcleo del sistema para obtener un mayor número de reintentos y tiempos de espera mayores en las sesiones TCP?

Para problemas de conexión o enrutamiento puede usar lo siguiente. Tenga en cuenta que para que sea más efectivo, ambos lados de la conexión deben usar valores similares.

Para forzarlo use sysctl e incremente los valores de: 

net.inet.tcp.keepinittime
net.inet.tcp.keepidle
net.inet.tcp.keepintvl
Si usa sysctl -a podrá ver los valores actuales de estos y muchos otros parámetros. Para cambiar cualquiera de ellos, use sysctl -w, como por ejemplo en sysctl -w net.inet.tcp.keepidle=28800.

6.6.2 - ¿Cómo puedo activar emisiones dirigidas?

Por regla general no es aconsejable hacer esto, ya que si su sistema OpenBSD es un enrutador, permite que puedan enviar tráfico a la dirección o direcciones de emisión de sus redes.

En algunos casos, como en redes cerradas, puede tener cierta utilidad, en particular cuando esté usando implementaciones antiguas del protocolo NetBIOS. Se puede activar con sysctl -w net.inet.ip.directed-broadcast=1. Para saber porqué se encuentra desactivado por definición, infórmese sobre ataques "smurf".

6.6.3 - No quiero que el núcleo haga asignaciones dinámicas de ciertos puertos

También existe un sysctl para esto. De la página de manual de sysctl(8): 
Añada la lista de puertos TCP que no deberían ser
asignados dinámicamente por el núcleo.  Esto se puede
usar para evitar que algunos dæmons se apropien de un puerto
específico que sea necesario para el funcionamiento de otro
programa.  La lista de elementos puede ir separada por comas y/o
espacios en blanco.

   sysctl -w net.inet.tcp.baddynamic=749,750,751,760,761,871

También se pueden añadir o eliminar puertos de la lista
actual.

   sysctl -w net.inet.tcp.baddynamic=+748
   sysctl -w net.inet.tcp.baddynamic=-871

6.7 - Uso simple de NFS

El «Sistema de Archivos de Red» (NFS, "Network File System") se usa para compartir un sistema de archivos en una red. Algunas páginas de manual que debería leer antes de que intente configurar un servidor de NFS son:

En esta sección se detallarán los pasos para una configuración simple de NFS. El ejemplo ofrece detalles sobre un servidor en una LAN, con clientes que tengan acceso NFS en la LAN. En esta sección no se tratará sobre la seguridad de NFS. Asumiremos que Vd. ya ha configurado su paquete de filtros, u otra protección como cortafuegos, para prevenir el acceso desde el exterior. Si su configuración permite el acceso desde el exterior a su servidor de NFS, y si tiene algún tipo de datos confidenciales o importantes, le recomendamos encarecidamente que haga uso de IPSec. De otro modo existe la posibilidad de que extraños puedan ver su tráfico NFS. También sería posible que alguien pretendiera estar en la dirección IP que tenga autorizada la entrada en su servidor NFS. Existen varios tipos de ataques efectivos en este aspecto. Cuando IPSec está correctamente configurado, protege contra todos estos tipos de ataques.

Otra nota importante sobre seguridad. No se limite a añadir un sistema de archivos a /etc/exports sin algún tipo de lista de huéspedes autorizados. Sin una lista de huéspedes que puedan montar un directorio particular, cualquiera que pueda llegar a su huésped podrá montar sus directorios de NFS en exports.

La configuración consiste en un servidor con el ip 10.0.0.1, que servirá NFS sólo a clientes dentro de esa red. El primer paso para configurar NFS es configurar su fichero /etc/exports. Este fichero se compone de una lista con los sistemas de archivo que quiera que se encuentren accesibles por medio de NFS, y define quién puede acceder a cada uno de ellos. Existen muchas opciones que puede usar en su fichero /etc/exports, y es conveniente leer la página de manual exports(5). En este ejemplo empezaremos con un fichero /etc/exports como el siguiente:

Esto quiere decir que el sistema de archivo local /work estará disponible por medio de NFS. -alldirs indica que los clientes podrán montar en cualquier parte del punto de montaje /work. -ro indica que sólo se permitirá montarlo en modo de sólo lectura. Los dos últimos argumentos indican que sólo los clientes dentro de la red 10.0.0.0 que usen una máscara de red 255.255.255.0, estarán autorizados a montar este sistema de archivo. Esto es importante en algunos servidores accesibles desde diferentes redes.

Una vez que su fichero /etc/exports haya sido configurado, puede seguir adelante y configurar su servidor NFS. Primero debería asegurarse de que las opciones NFSSERVER y NFSCLIENT se encuentren en la configuración del núcleo de su sistema (el núcleo GENERIC incluye estas opciones). A continuación debe configurar nfs_server=YES en el fichero /etc/rc.conf. De este modo, cuando reinicie el sistema, se activarán nfsd(8) y mountd(8). Ahora ya puede continuar e iniciar los dæmons Vd. mismo. Estos dæmons deben ser iniciados por root, y debe asegurarse de que portmap(8) se encuentre funcionando en su sistema. El ejemplo que sigue sobre cómo iniciar nfsd(8) sirve tanto para TCP como para UDP usando 4 dæmons. Para gestionar el máximo número de requerimientos de clientes concurrentes a los que quiera dar servicio, debe activar un número apropiado de dæmons del servidor NFS.

No sólo debe iniciar el servidor nfsd(8), sino que también necesita iniciar mountd(8). Éste es el dæmon que da servicio a los requerimientos para montar en NFS. Para iniciar mountd(8) escriba:

Si hace algún cambio al fichero /etc/exports mientras NFS esté funcionando, tendrá que avisar a mountd sobre el cambio pasándole una señal "HUP":

Comprobación de estadísticas en NFS

Puede llevar a cabo comprobaciones para asegurarse de que estos dæmons estén funcionando y registrados con RPC. Para ello use rcpinfo(8).

Durante su uso normal, existen unas pocas utilidades más que le permitirán ver lo que está ocurriendo con NFS. Una de ellas es showmount(8), que le permite ver qué se encuentra montado y quién lo está montando. También está nfsstat(8), que muestra una información de las estadísticas mucho más amplia. Para usar showmount(8) escriba /usr/bin/showmount -a host. Por ejemplo:

Cómo montar sistemas de archivo NFS

Los sistemas de archivo NFS se deben montar mediante mount(8), o más exactamente mediante mount_nfs(8). Para montar un sistema de archivo /work del huésped 10.0.0.1 en un sistema de archivo local /mnt, haga lo siguiente (no necesita usar una dirección IP, mount se encargará de la resolución de nombres):

Para que el sistema se monte al iniciar, añada una algo como lo que ve a continuación en su fichero /etc/fstab:

¡¡Es importante que use 0 0 al final de esta línea para que su máquina no intente ejecutar fsck sobre el sistema de archivo NFS durante el inicio del sistema!! El resto de opciones de seguridad típicas como noexec, nodev, y nosuid, también deberían usarse donde sean posibles, como en:

De este modo ningún dispositivo o programa setuid en el servidor NFS podrá traspasar las medidas de seguridad en el cliente NFS. Si no está montando programas para ejecutarlos en el cliente NFS, añada noexec a esta lista.

6.8 - Servicio de Nombres de Dominio - DNS, BIND, y named

6.8.1 ¿Qué es DNS?

El «Servicio de Nombres de Dominio» (DNS, "Domain Name Service") es una facilidad de red que permite a los dominios de redes IP proveer resoluciones de direcciones nombre-a-IP y resoluciones dirección-a-nombre en respuesta a un requerimiento. Su instalación de OpenBSD está configurada por definición como un cliente de DNS, pero no como un servidor de DNS. O sea, su instalación de OpenBSD puede llevar a cabo un requerimiento de DNS para la dirección de una máquina contra un servidor de nombres de dominio, pero no puede responder a uno de esos requerimientos de DNS de por sí a menos que la configure para ello.

Mi máquina con OpenBSD está conectada actualmente a Internet a través de mi proveedor (ISP "Internet Service Provider"), y por lo tanto puedo usar la utilidad nslookup(8) para ejecutar el requerimiento de DNS:

165.87.201.244 es el nombre del servidor que ha contestado, porque es el «nombre de servidor» ("nameserver") que mi ISP me dijo que usara con mi cuenta, y cuyo número se introduce en el fichero /etc/resolv.conf. Pero la respuesta no fue autorizada. Para una respuesta autorizada, investiguemos cuál es el servidor de DNS autorizado para el dominio openbsd.org, y preguntémosle por la dirección de www.openbsd.org:

zeus.theos.com es, como puede suponer, una máquina que funciona con OpenBSD y que está correctamente configurada para ser un servidor de DNS para el dominio openbsd.org.

6.8.1.1 ¿Dónde puedo aprender todo sobre DNS y su implementación en OpenBSD?

La orden dig(1) es epecialmente útil porque puede requerir un dominio y devolver la información prácticamente en el mismo formato requerido por los ficheros de configuración de BIND. Puede usar dig(1) para examinar nombres de servidores que sepa que están operando correctamente para comparar su configuración con la de ellos.

6.8.2 ¿Necesita mi máquina ser un servidor de nombres de dominio?

Si no está seguro de si necesita que su máquina haga el papel de servidor de DNS, no la configure de ese modo. La instalación de OpenBSD no activa su máquina como servidor de nombres de dominio por definición, aunque todos los ficheros necesarios se encuentran instalados. Para la mayoría de estaciones de trabajo, es suficiente con los ficheros /etc/hosts para indicar las direcciones IP de la máquinas locales y /etc/resolv.conf para indicar qué servidores de DNS le harán el servicio en la intranet o internet.

Por otra parte, podría necesitar configurar su máquina como un servidor de nombres de dominio:

Algo más a tener en cuenta es el velocidad de ejecución. Como la resolución de nombres es un proceso repititivo, en el que el servidor de nombres lleva a cabo repetidos requerimientos de direcciones en dominios remotos a otros servidores de nombres, la resolución de nombres puede tardar algo más si tiene una conexión por módem a Internet y está requiriendo direcciones remotas a su propio servidor de DNS (que hará continuos requerimientos a servidores de nombres remotos a través del módem) que si está requiriendo el servidor de nombres de su ISP (que probablemente tenga una conexión más rápida a los servidores de nombres remotos).

6.8.3 ¿Cuáles son los componentes de software del servidor de DNS?

6.8.3.1 ¿Qué nivel de BIND tiene soporte?

BIND es el nombre de la especificación del comportamiento de un servidor de nombres de dominio. Los componentes de DNS existen para implementar BIND de forma colectiva.

Existen dos especificaciones BIND diferentes:

  1. BIND 4
  2. BIND 8

Tal y como queda instalado, OpenBSD named tiene soporte para BIND 4.x.

6.8.3.2 ¿Cuáles son algunas de las alternativas a proveer DNS a través de la implementación predefinida de BIND 4.x?

6.8.3.2.1 Nota de Seguridad

Si usa estas implementaciones alternativas del DNS, estará ofreciendo un servicio de red crítico mediante el uso de unos programas que pueden no haber sido sometidos al mismo nivel de escrutinio que el dæmon de name en la instalación base, named, el cual ha pasado una auditoría de seguridad. Esta es una consideración a tener muy en cuenta, ya que si un servidor de nombres de dominio es puesto en peligro, los resolucionadores que usen ese servidor de DNS pueden ser redireccionados al sitio de un impostor.

6.8.4 ¿Cuánto tengo que instalar?

Si la configuración predefinida de la red se instaló correctamente durante la instalación de OpenBSD, tendrá todo ya instalado. Sólo tiene que configurar el dæmon de name ("named").

6.8.5 ¿Cómo configuro DNS?

Para configurar DNS en OpenBSD, edite y/o cree los ficheros que controlan el dæmon de name, named. La ubicación por definición de estos ficheros es el directorio /var/named y sus subdirectorios, en especial el fichero /var/named/named.boot que es el fichero de inicialización para named. También hay un par más de pasos para la configuración que se deben llevar a cabo en /etc.

En este documento configuraremos el dæmon de name en nemo.yewtopia.com como el nombre nombre primario del servidor para el dominio (¡muy pequeño!) yewtopia.com. La dirección de nemo.yewtopia.com es 192.168.1.9. Otras dos máquinas en esa subrred son crater.yewtopia.com en 192.168.1.1 y earhart.yewtopia.com en 192.168.1.2.

6.8.5.1 Configuración en /etc/named

6.8.5.1.1 /var/named/named.boot

Esto indica al proceso de inicialización en qué subdirectorio y bajo qué nombres encontrará los ficheros de configuración de yewtopia.com.

6.8.5.1.2 /var/named/namedb/localhost.rev
6.8.5.1.3 /var/named/namedb/yewtopia
6.8.5.1.4 /var/named/namedb/yewtopia.rev

6.8.5.2 Configuración en /etc

6.8.5.2.1 /etc/resolv.conf

Asegúrese de que /etc/resolv.conf ahora señale al dominio de la máquina local (en vez de, por ejemplo, el nombre del servidor de su ISP), de modo que la resolución del nombre en requerimientos sea enviada al named que haya configurado.

6.8.5.2.2 /etc/hosts

Si anteriormente hubiera añadido las direcciones de varias máquinas al fichero /etc/hosts, puede que le interese acortar su fichero /etc/hosts al estado en que se encontraba por definicón

de modo que named no sea circunvalado en favor de direcciones (probablemente caducadas) en el fichero /etc/hosts. ¡Asegúrese de que tiene al menos la entrada predefinida de localhost, o su red no iniciará correctamente! Note también que nemo debe aparecer en su propio fichero hosts, o de lo contrario verá un mensaje de error (no dañino) durante el arranque cuando /etc/netstart invoque route(8) para añadir nemo (cuyo nombre aparece en /etc/myname).

6.8.5.3 Cómo usar dig(1) para examinar los resultados.

6.8.6 ¿Cómo y cuándo inicio y paro DNS?

6.8.6.1 Iniciar DNS

El dæmon de name named se lanza durante el inicio del sistema desde /etc/rc si la línea instalada por definición en /etc/rc.conf,

se cambia a

Examine también estas líneas en /etc/rc.conf:

Estos valores predefinidos serán válidos para casi todas las configuraciones.

Para iniciar named de forma manual, use la orden ndc(8). Por ejemplo:

6.8.6.2 Parar DNS

El mejor modo de parar el dæmon de name es usando la orden ndc(8). Por ejemplo:

Si no funcionara, encuentre el id del proceso de named y use la orden kill(1) para finalizar el proceso. El PID para named mientras esté funcionando se encontrará como la primera línea del fichero /var/named/named.pid.

6.8.6.3 Reiniciar DNS con una configuración alterada

Para hacer que un proceso en funcionamiento del dæmon de name se reinicie recargando su configuración después de haberle hecho cambios, envíe una señal hangup:

o use la orden ndc(8). Por ejemplo:

6.8.7 ¿Cómo bloqueo los requerimientos AXFR?

ejemplo:

Esta información es útil para depurar DNS, pero en algunos casos puede que no le interese que esta información se haga pública. Si está usando in-addr(rfc2317) sin clase para inverso, ¡ 'host -' podría informar sobre todos los dominios hospedados en su sistema! Esto se puede solucionar fácilmente con la cláusula 'allow-transfer' en su fichero zone.

Si usa Bind8 necesitará especificar los huéspedes a los que quiere permitir la transferencia de zonas en su(s) fichero(s) individual zone:

También puede bloquear las transferencias para todos los dominios editando /var/named.conf y añadiéndo el parámetro 'allow-transfer' a la sección 'options' del fichero de configuración: El método para Bind8 también funciona para Bind9.
Si está usando Bind 4 (predefinido en OpenBSD), puede editar /var/named/named.boot y usar la opción 'xfrnets'.
Bind 4 permite transferencias desde clases enteras, por lo que no es tan exacto. Generalmente, los únicos huéspedes que necesitan llevar a cabo transferencias son los esclavos y huéspedes de DNS desde los que quiera depurar (127.0.0.1 es normalmente un buen huésped desde donde permitir transferencias). El bloqueo de requerimientos AXFR añade un nivel adicional de privacidad, pero puede entorpecer el útil depurado de DNS (gracias a Nicholas Tang por este consejo).

6.8.7 ¿Qué ha quedado en el tintero sobre la configuración de DNS?

Hay muchas cosas de las que no hemos hablado, como por ejemplo, cómo configurar DNS para que los requerimientos para dominios de intranet que no sean visibles desde la raíz de la jerarquía del dominio dependan de servidores dentro de su empresa. Lea los documentos que le recomendamos para más información sobre DNS.

6.9 - Configuración de una conexión PPTP en OpenBSD

NOTA: Esta información no es válida para TODOS los proveedores de conexiones ADSL, pero mucha de la información que encontrará aquí se puede usar como base. Esta información sólo se ha comprobado con Inode, un proveedor de ADSL en Austria.

Antes que nada debe instalar pptp. Existe un porte de pptp en el árbol de portes de OpenBSD que fue añadido A PARTIR de la versión 2.8 de OpenBSD, y que se instala y funciona bien desde el mismo árbol. Lo puede encontrar en /ports/net/pptp. Para más información sobre el árbol de portes de OpenBSD, lea la sección 8.6 de las preguntas frecuentes.

Debido a un conflicto entre el soporte integrado en el núcleo de gre(4) y pptp, tendrá que recompilar el núcleo del sistema, eliminando el soporte de gre(4).

Para recompilar el núcleo, obtenga antes la distribución 2.8-stable de OpenBSD mediante cvs (lea la página de OpenBSD Stable para más información), aplicar el parche anterior al fichero de configuración del núcleo, GENERIC, y recompilar el núcleo tal y como se describe en la sección 5.3 de las preguntas frecuentes.

Una vez que ya tenga instalado el paquete pptp y el nuevo núcleo, deberá editar unos cuantos ficheros para configurar su conexión. Este paquete utiliza el programa de ppp(8) nativo de OpenBSD; si está familiarizado con ppp(8), gran parte de la configuración es idéntica. Lea también la sección 6.5 de este documento.

Para el fichero /etc/ppp/options, una configuración como la siguiente será probablemente todo lo que necesite:

Debe substituir LOGINNAME con su identificador de usuario.

Para el fichero /etc/ppp/pap-secrets necesitará una línea como ésta:

En donde LOGINNAME es su identificador de usuario y PASSWORD su contraseña. 10.0.0.138 es la dirección IP asignada a su modem en caso de que use ADSL, etc. Asegúrese de que este fichero sea de «sólo lectura» para el usuario "root" (modo 600).

6.9.1 - Asignación de una dirección a su interfaz de red

En el ejemplo anterior, el modem venía con una interfaz 10.0.0.38 preconfigurada. Pero ahora necesitaremos asignar una dirección a NUESTRA interfaz. Lo mejor es escoger una dirección IP cercana a la asignada para el MODEM, o usar la dirección IP estática que nos hayan asignado. Puede leer más sobre cómo configurar interfaces en la sección 6.1 de este documento.

Una vez que haya configurado su interfaz, debería poder establecer una conexión pptp con la orden:

Como ya hemos dicho, usará el ppp(8) nativo de OpenBSD, e iniciará dos procesos; en consecuencia, podrá matar pptp matando estos dos procesos:

Es recomendable abrir /var/log/messages en una ventana de terminal aparte, para poder reconoce cualquier posible problema.

También le sugerimos que ponga la orden de inicio en /etc/rc.local para que conecte de forma automática cuando reinicie el sistema.

[Volver al índice principal] [Sección 5.0 - Configuración del núcleo y del disco] [Sección 7.0 - Controles del teclado]

[índice] www@openbsd.org
Originally [OpenBSD: faq6.html,v 1.86 2000/12/26 20:07:04 ericj Exp ]
$Translation: faq6.html,v 1.26 2001/01/01 15:54:39 horacio Exp $
$OpenBSD: faq6.html,v 1.19 2001/01/02 17:11:52 jufi Exp $