[Índice de documentos] [Sección 5 - Compilación del sistema con el código fuente] [Sección 7 - Controles de teclado y pantalla]
Para la comprensión de la mayor parte de este documento será de gran ayuda haber leído antes, y por lo menos haber asimilado en parte, el capítulo 5 sobre la «Configuración del Núcleo» de estos documentos, así como las páginas del manual de ifconfig(8) y de netstat(1).
Tanto si se es un administrador de redes que está configurando protocolos de enrutamiento, como si se está usando el sistema OpenBSD como un enrutador, como si se necesita conocer más a fondo los protocolos de redes IP, es realmente necesario leer Understanding IP addressing ¡Es un documento excelente que contiene conocimientos básicos fundamentales sobre redes IP!
Si se está trabajando con aplicaciones como servidores de http, servidores de ftp y servidores de correo, será muy beneficioso leer los RFC.
(Nota: existe un proyecto de traducción de documentos RFC al castellano, RFC-ES)
Pero lo más seguro es que no se puedan leer todos, y por ello lo más práctico es seleccionar algunos temas de interés o aquellos que se usen en el entorno de red del que se disponga. Es aconsejable leerlos al mismo tiempo que se intenta averiguar su funcionamiento. Los RFC definen muchísimas (miles) de las normas para protocolos en Internet y cómo se supone que deben funcionar estos protocolos.
Para empezar a configurar una red, lo primero que se debe hacer es identificar la interfaz de red. En OpenBSD las interfaces se designan por el tipo de tarjeta, no por el tipo de conexión. La tarjeta de red se puede ver durante el arranque mientras se inicia el sistema, o después del arranque usando la orden dmesg(8). También es posible ver la interfaz de red usando la orden ifconfig(8). Por ejemplo, véase a continuación la salida originada por dmesg para una tarjeta de red Intel Fast Ethernet, que usa el nombre de dispositivo fxp.
fxp0 at pci0 dev 10 function 0 "Intel 82557" rev 0x0c: irq 5, address 00:02:b3:2b:10:f7
inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 4
Si no se conoce el nombre del dispositivo, se puede buscar en la lista de hardware con soporte de la plataforma correspondiente. En esa página hay un listado con muchos nombres de tarjetas comunes junto con los nombres de dispositivo que les corresponde en OpenBSD. Combinando el nombre alfabético abreviado (como fxp) con un número asignado por el núcleo del sistema se obtendrá el nombre de la interfaz (como fxp0).
Se puede averiguar qué interfaces de red han sido identificadas por el sistema mediante la utilidad ifconfig(8). La orden siguiente mostrará todas las interfaces de red que existan en un sistema. En este ejemplo sólo se ha encontrado una interfaz física de ethernet, la fxp(4).
$ ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
lo1: flags=8008<LOOPBACK,MULTICAST> mtu 33224
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:04:ac:dd:39:6a
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255
inet6 fe80::204:acff:fedd:396a%fxp0 prefixlen 64 scopeid 0x1
pflog0: flags=0<> mtu 33224
pfsync0: flags=0<> mtu 2020
sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 296
sl1: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 296
ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
ppp1: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
tun0: flags=10<POINTOPOINT> mtu 3000
tun1: flags=10<POINTOPOINT> mtu 3000
enc0: flags=0<> mtu 1536
bridge0: flags=0<> mtu 1500
bridge1: flags=0<> mtu 1500
vlan0: flags=0<> mtu 1500
address: 00:00:00:00:00:00
vlan1: flags=0<> mtu 1500
address: 00:00:00:00:00:00
gre0: flags=9010<POINTOPOINT,LINK0,MULTICAST> mtu 1450
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif1: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif2: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif3: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
Como se puede comprobar, ifconfig(8) muestra mucha más información de la que necesitamos en este momento. Pero aquí lo importante es que nos permite ver nuestra interfaz. En el ejemplo, la tarjeta de la interfaz ya está configurada. Esto es obvio porque ya hay una red IP configurada en fxp0, y de aquí los valores "inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255". Además, los indicadores UP y RUNNING se encuentran activados.
Finalmente, nótese que hay otras interfaces que también se encuentran activadas de modo predeterminado. Éstas son interfaces virtuales que tienen varias funciones. Las siguientes páginas del manual las describen:
Si aún no se ha configurado la interfaz, el primer paso
será crear el fichero /etc/hostname.xxx, donde se debe
sustituir xxx por el nombre de la interfaz. De acuerdo con la
información de los ejemplos anteriores, el nombre sería
/etc/hostname.fxp0. La composición de este fichero es
así de sencilla:
address_family address netmask broadcast [other options]
(Se puede ver más información sobre el formato de este fichero en la página del manual de hostname.if(5))
El fichero de configuración de una interfaz típica, configurada para una dirección de IPv4, debe ser algo como lo siguiente:
$ cat /etc/hostname.fxp0
inet 10.0.0.38 255.255.255.0 NONE
También se podría especificar tipos de medio para Ethernet; por ejemplo, si se quisiera forzar el modo 100baseTX full-duplex:
inet 10.0.0.38 255.255.255.0 NONE media 100baseTX mediaopt full-duplex
Aunque nunca se debe forzar el modo full duplex, a menos que ambas partes de la conexión estén configuradas para ello. A menos que sea necesario por algún motivo especial, la configuración del tipo de medio se debe excluir.
Para especificar una interfaz determinada se puede usar indicadores especiales, en cuyo caso el formato del fichero hostname no cambiaría mucho:
$ cat /etc/hostname.vlan0
inet 172.21.0.0 255.255.255.0 NONE vlan 2 vlandev fxp1
El siguiente paso será la configuración de la pasarela (gateway) predeterminada. Para ello basta con poner la dirección IP de la pasarela en el fichero /etc/mygate. Esto permitirá que la pasarela se active en el momento del arranque. A continuación hay que configurar los nombres de servidores (nameservers) y el fichero /etc/hosts (véase la página del manual de hosts(5)). Para configurar los nombres de servidores, antes se debe crear un fichero con el nombre /etc/resolv.conf. Puede verse más información sobre el formato de este fichero en la página del manual de resolv.conf(5). El siguiente ejemplo es para un uso típico. En este ejemplo los servidores de dominio son 125.2.3.4 y 125.2.3.5. Y también se es parte del dominio «example.com»:
$ cat /etc/resolv.conf
search example.com
nameserver 125.2.3.4
nameserver 125.2.3.5
lookup file bind
Desde este punto ya se puede reiniciar o bien ejecutar el guión de configuración (script) /etc/netstart. Este guión de configuración se ejecuta como superusuario (root) del siguiente modo:
# sh /etc/netstart
writing to routing socket: File exists
add net 127: gateway 127.0.0.1: File exists
writing to routing socket: File exists
add net 224.0.0.0: gateway 127.0.0.1: File exists
Nótese que se ha producido un pequeño número de errores. Pero al ejecutar este guión, se reconfingurarán cosas que ya se habían configurado anteriormente. De hecho, algunas rutas ya existen en la tabla de enrutamiento del núcleo del sistema. Desde aquí, el sistema debería funcionar con normalidad. Se puede realizar una comprobación con ifconfig(8) para asegurarse de que la interfaz se ha configurado correctamente. También es posible comprobar las rutas con netstat(1) o route(8). Si tenemos problemas con el enrutamiento, podemos usar el indicador -n para la orden route(8), que muestra las direcciones de IP en lugar de realizar una búsqueda de DNS y mostrar el hostname. He aquí un ejemplo en el que se muestran las tablas de enrutamiento usando sendos programas:
$ netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 10.0.0.1 UGS 0 86 - fxp0
127/8 127.0.0.1 UGRS 0 0 - lo0
127.0.0.1 127.0.0.1 UH 0 0 - lo0
10.0.0/24 link#1 UC 0 0 - fxp0
10.0.0.1 aa:0:4:0:81:d UHL 1 0 - fxp0
10.0.0.38 127.0.0.1 UGHS 0 0 - lo0
224/4 127.0.0.1 URS 0 0 - lo0
Encap:
Source Port Destination Port Proto SA(Address/SPI/Proto)
$ route show
Routing tables
Internet:
Destination Gateway Flags
default 10.0.0.1 UG
127.0.0.0 LOCALHOST UG
localhost LOCALHOST UH
10.0.0.0 link#1 U
10.0.0.1 aa:0:4:0:81:d UH
10.0.0.38 LOCALHOST UGH
BASE-ADDRESS.MCA LOCALHOST U
Lo que sigue es la información básica necesaria para configurar el sistema OpenBSD como una pasarela (también llamada «enrutador» o «encaminador»). Si se va a usar OpenBSD como un enrutador en Internet, sugerimos la lectura de la sección que contiene las instrucciones sobre la configuración del Filtro de Paquetes IP (PF), para poder bloquear el tráfico que sea potencialmente malicioso. Además, debido a la escasa disponibilidad de direcciones de IPv4 en los proveedores de servicios de redes y registros regionales, es conveniente leer la sección sobre la Traducción de Direcciones de Red (NAT), que contiene información sobre cómo conservar el espacio de dirección IP.
El núcleo GENERIC posee la capacidad de permitir el reenvío de IP (IP Forwarding), pero antes debe ser activado. Para activarlo hay que usar la utilidad sysctl(8); y para que los cambios sean permanentes hay que editar el fichero /etc/sysctl.conf(5) y activar IP Forwarding en éste. Esto se puede hacer añadiendo la siguiente línea a ese fichero de configuración:
net.inet.ip.forwarding=1
Para que este cambio surja efecto sin que haya que reiniciar el sistema, hay que usar directamente la utilidad sysctl(8). Recuérdese que este cambio ya no existirá inmediatamente después de reiniciar, y que es necesario ejecutarlo como superusuario:
# sysctl -w net.inet.ip.forwarding=1
net.inet.ip.forwarding: 0 -> 1
A continuación se deben modificar las rutas en los otros anfitriones, en ambos extremos. OpenBSD ofrece muchas posibilidades de utilización como enrutador, usando software como routed(8), gated, mrtd y zebra. OpenBSD dispone de soporte para zebra, gated y mrtd en la colección de portes, e incluye soporte para varias interfaces T1, HSSI, ATM, FDDI, Ethernet, e interfaces de serie (PPP/SLIP).
OpenBSD dispone de un sencillo mecanismo para la configuración de los alias de IP en una interfaz. Lo único que hay que hacer para configurar los alias es editar el fichero /etc/hostname.<if>. El guión de ejecución /etc/rc(8), 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 es:
Notas sobre los alias: en OpenBSD sólo se usa el nombre de la interfaz y no existen diferencias entre el primer alias y el segundo; por lo tanto, y a diferencia de otros sistemas operativos, en OpenBSD no hay que referirse a ellos como dc0:0 y dc0:1. Si hacemos referencia a una dirección de IP alias específica con ifconfig, o si estamos añadiendo un alias, debemos asegurarnos de escribir 'ifconfig int alias', en lugar de 'ifconfig int', en la línea de órdenes. Los alias se pueden eliminar con la orden 'ifconfig int delete'.
Asumiendo que se estén usando direcciones de IP múltiples que se encuentran en la misma subred IP con alias, la configuración de la máscara de red (netmask) para cada alias pasa a ser 255.255.255.255. No necesitan seguir la máscara de red del primer IP vinculado a la interfaz. En el siguiente fichero /etc/hostname.dc0 de ejemplo, se han añadido dos alias al dispositivo dc0, el cual, por cierto, se ha configurado como 192.168.0.2 netmask 255.255.255.0:
# cat /etc/hostname.dc0
inet 192.168.0.2 255.255.255.0 media 100baseTX
inet alias 192.168.0.3 255.255.255.255
inet alias 192.168.0.4 255.255.255.255
Una vez que se haya configurado este fichero, será necesario reiniciar para que los cambios funcionen. Aunque también es posible hacer efectivos los alias a mano, usando la utilidad ifconfig(8). Para hacer efectivo el primer alias se usaría la orden:
# ifconfig dc0 inet alias 192.168.0.3 netmask 255.255.255.255
Para ver estos alias se usaría la orden:
$ ifconfig -A
dc0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST>
media: Ethernet manual
inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255
inet 192.168.0.3 netmask 0xffffffff broadcast 192.168.0.3
El Filtro de Paquetes (a partir de aquí PF) es el sistema de OpenBSD para filtrar el tráfico TCP/IP y realizar las tareas de Traducción de Direcciones de Red (NAT). PF también puede normalizar y acondicionar el tráfico TCP/IP y proveer control del ancho de banda y priorización de paquetes, y se puede utilizar para crear cortafuegos resistentes y flexibles. Su configuración y funcionamiento se describen en la Guía del Usuario de PF.
Para usar el cliente de DHCP que se incluye en OpenBSD,
dhclient(8),
hay que editar el fichero /etc/hostname.xl0 (suponiendo que la
interfaz principal de ethernet sea xl0 ... la interfaz podría ser
ep0, fxp0, o cualquier otra) para modificarlo. La única
modificación necesaria en este fichero es añadir la
palabra clave '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 nuestra dirección IP, pasarela, y servidores de DNS desde el servidor de DHCP.
Si se desea iniciar un cliente dhcp desde la línea de
órdenes, antes hay que asegurarse de que el fichero
/etc/dhclient exista y entonces usar la orden:
# dhclient fxp0
en donde fxp0 es la interfaz en la que se desea recibir dhcp.
Sea cual fuere el modo en que se inicie dhclient, se puede editar el
fichero /etc/dhclient para evitar que se actualice la
DNS de acuerdo con la idea que tenga el servidor de dhcp sobre la DNS,
comentando las líneas precedidas por 'request' (son ejemplos de
la configuración predefinida, pero es necesario 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, si se desea, es posible anular hostname u otras configuraciones.
Si se desea usar OpenBSD como servidor de DHCP con
dhcpd(8),
hay que editar el fichero /etc/rc.conf y configurarlo
añadiendo dhcp_flags="-q" en lugar de
dhcp_flags=NO. También hay que añadir en
/etc/dhcp.interfaces las interfaces en las que se desee que
dhcp permanezca a la escucha:
# echo xl1 xl2 xl3 >/etc/dhcpd.interfaces
y editar /etc/dhcpd.conf. Las opciones son bastante claras:
option domain-name "example.com";
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 indicaremos a los clientes de DHCP que el dominio que deben añadir a sus requerimientos de DNS es example.com (así, si un usuario escribiera 'telnet joe', los enviaría a joe.example.com). Les dirigirá a los servidores de DNS 192.168.1.3 y 192.168.1.5. A los anfitriones 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, con una configuración predeterminada de la pasarela de 192.168.1.1.
Si se quiere iniciar dhcpd(8) desde la línea de órdenes,
hay que intentar lo siguiente después de editar
/etc/dhcpd.conf:
# dhcpd -q fxp0
en donde fxp0 es la interfaz que se desea que empiece a servir requerimientos de dhcp. El indicador -q fuerza una salida silenciosa de dhcpd, ya que de otro modo es muy ruidoso.
Si se está actuando como servidor de DHCP para una máquina
Windows, se puede hacer que dhcpd(8) ofrezca al cliente una
dirección de servidor 'WINS'. Para ello hay que añadir 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 del servidor de Windows o Samba. Para información sobre otras opciones que puedan aceptar los clientes de DHCP, vése dhcp-options(5).
El «Protocolo Punto a Punto» (PPP) es el que se suele usar para crear una conexión con el ISP (el proveedor de Internet) a través de un módem. OpenBSD puede hacer esto de dos modos:
Primero trataremos el dæmon del modo de usuario. Para empezar necesitaremos algo de información sobre nuestro proveedor. He aquí una lista de la información que será necesaria:
Parte de esta información no es estrictamente necesaria, pero será de gran ayuda para configurar ppp. El dæmon PPP del modo de 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. Es aconsejable mirar en ese directorio.
En caso de no estar usando un núcleo GENERIC, debemos asegurarnos de que tenemos la siguiente línea en nuestro fichero de configuración:
pseudo-device tun 2
La configuración inicial del dæmon PPP del modo de usuario consiste en editar su fichero /etc/ppp/ppp.conf. Este fichero no existe y se debe crear, pero se puede tomar el fichero /etc/ppp/ppp.conf.sample, editarlo, y crear un fichero ppp.conf propio a partir de ahí. Aquí empezaremos con la configuración más simple, y probablemente la más utilizada. A continuación puede verse un pequeño fichero ppp.conf que realizará la conexión con el ISP y usará nuestras rutas predefinidas y nuestro nameserver. Para la creación de este fichero, toda la información que necesitaremos será el número de teléfono de nuestro ISP, nuestro nombre de usuario, y nuestra contraseña:
default:
set log Phase Chat LCP IPCP CCP tun command
set device /dev/cua01
set speed 115200
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT OK-AT-OK ATE1Q0 OK\\dATDT\\T TIMEOUT 40 CONNECT"
La sección bajo la opción default: se ejecutará cada vez que se realice un requerimiento para una conexión. 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 véase la página del manual de ppp(8). El dispositivo se configura con "set device". Éste es el dispositivo en el que se encuentra el módem. En este ejemplo el módem 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 configuran 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 podemos pasar a configurar la información específica para nuestro ISP. Para ello debemos añadir otra opción en la sección default:. Se puede dar cualquier nombre a esta etiqueta, pero lo más fácil es darle el nombre del 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:
myisp:
set phone 1234567
set login "ABORT NO\\sCARRIER TIMEOUT 5 ogin:--ogin: ppp word: ppp"
set timeout 120
set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
add default HISADDR
enable dns
Aquí hemos configurado la 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 con el ISP. La opción "set login" es para configurar nuestras opciones de ingreso. En el ejemplo hemos puesto un tiempo muerto de espera de 5, lo que significa que nuestro intento de ingreso terminará después de 5 segundos si no hay transportador. De lo contrario esperará hasta recibir un "login" para enviar nuestro nombre de usuario y contraseña. En el ejemplo, tanto el nombre de usuario como la contraseña son "ppp". Estos valores hay que sustituirlos 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:
set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
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. Si se tiene una dirección IP estática, se debe añadir 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 sustituir todo. El segundo IP que se especifique es el que esperamos como el IP de nuestro ISP. Si lo conocemos lo podemos 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 la conexión les requiera ``0.0.0.0''.
La siguiente opción "add default HISADDR" es para configurar la ruta predefinida hasta nuestra IP. Si nuestra IP cambiara, la ruta se actualizaría de forma automática. Con "enable dns" indicamos a nuestro ISP que autentifique nuestras direcciones nameservers. Esto no debe hacerse si se está usando una DNS local, ya que ppp circunvalará su uso introduciendo algunas líneas en /etc/resolv.conf.
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 se usa /usr/sbin/ppp sin pasarle ninguna opción, pasará al modo interactivo, desde donde se podrá interaccionar directamente con el módem. De este modo se pueden depurar problemas en el fichero ppp.conf.
Si se necesitara ejecutar órdenes al tiempo que se conecta o desconecta, puede hacerse creando dos ficheros adicionales, /etc/ppp/ppp.linkup y /etc/ppp/ppp.linkdown. Pueden verse ejemplos de configuración para estos ficheros en:
Se puede obtener más información en el capítulo sobre userppp de la Guía de FreeBSD.
Para problemas de conexión o enrutamiento se puede usar lo siguiente (hay que tener en cuenta que para que sea más efectivo, ambos lados de la conexión deben usar valores similares):
Para forzarlo hay que usar sysctl e incrementar los valores de:
net.inet.tcp.keepinittime
net.inet.tcp.keepidle
net.inet.tcp.keepintvl
Si se usa sysctl -a se podrán ver los valores actuales de estos y muchos otros parámetros. Para cambiar cualquiera de ellos, hay que usar sysctl -w; como por ejemplo en sysctl -w net.inet.tcp.keepidle=28800.
Por lo general, no es aconsejable hacerlo ya que, si el sistema OpenBSD es un enrutador, permite que se pueda enviar tráfico a la dirección o direcciones de emisión de nuestras redes.
En algunos casos, como en el de las redes cerradas, puede tener cierta utilidad, en particular cuando se estén usando implementaciones antiguas del protocolo NetBIOS. Se puede activar con sysctl -w net.inet.ip.directed-broadcast=1. Es convienente informarse sobre los ataques "smurf" para saber por qué se encuentra desactivado por definición.
También existe un sysctl para esto. De la página del
manual de
sysctl(8):
Añada la lista de puertos TCP que no deberían ser
asignados de forma dinámica por el núcleo. Esto puede
utilizarse para evitar que algunos dæmons se apropien de un cierto
puerto 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
El «Sistema de Archivos de Red» (NFS, Network File System) se usa para compartir un sistema de archivos en una red. Algunas páginas del manual que se deberían leer antes de intentar 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 ya se ha configurado el paquete de filtros, u otra protección como cortafuegos, para prevenir el acceso desde el exterior. Si nuestra configuración permite el acceso desde el exterior a nuestro servidor de NFS, y si tenemos algún tipo de datos confidenciales o importantes, es muy recomendable usar IPsec. De otro modo existe la posibilidad de que extraños puedan ver nuestro tráfico de NFS. También sería posible que alguien pretendiera estar en la dirección IP a la que hayamos autorizado la entrada en el servidor de 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 debe añadir un sistema de archivos a /etc/exports sin algún tipo de lista de anfitriones autorizados. Sin una lista de anfitriones que puedan montar un directorio particular, cualquiera que pueda llegar al anfitrión podrá montar los directorios de NFS en exports.
NFS depende de que portmap(8) se encuentre en ejecución antes de poder operar. Portmap(8), desde la versión 3.2 de OpenBSD, se encuentra desactivado en el modo predeterminado, y por lo tanto hay que activarlo en el fichero rc.conf(8) cambiando la línea de portmap así:
portmap=YES
y reiniciar para que el cambio sea efectivo.
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 el fichero /etc/exports. Este fichero se compone de una lista con los sistemas de archivos que se quiera que sean 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 del manual de exports(5). En este ejemplo empezaremos con un fichero /etc/exports como el siguiente:
#
# Base de datos de NFS exports
# Véase exports(5) para más información. Vaya con
# cuidado, una mala configuración puede hacer que
# sus sistemas de archivos sean legibles por todo el mundo.
/work -alldirs -ro -network 10.0.0 -mask 255.255.255.0
Esto quiere decir que el sistema de archivos local /work estará disponible a través de NFS. -alldirs indica que los clientes podrán montar en cualquier parte bajo el punto de montaje /work. -ro indica que únicamente 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 archivos. Esto es importante en algunos servidores accesibles desde diferentes redes.
Una vez que se haya configurado el fichero /etc/exports, se puede continuar y pasar a configurar el servidor de NFS. Primero hay que asegurarse de que las opciones NFSSERVER y NFSCLIENT se encuentren en la configuración del núcleo del sistema (el núcleo GENERIC incluye estas opciones). A continuación hay que configurar nfs_server=YES en el fichero /etc/rc.conf. De este modo, cuando se reinicie el sistema, se activarán nfsd(8) y mountd(8). Ahora ya se pueden iniciar los dæmons. Estos dæmons deben ser iniciados por el superusuario, root, y es necesario asegurarse de que portmap(8) esté en funcionamiento en el 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 se quiera dar servicio, hay que activar un número apropiado de dæmons del servidor de NFS.
# /sbin/nfsd -tun 4
No sólo se debe iniciar el servidor de nfsd(8), sino que también es necesario iniciar mountd(8). Éste es el dæmon que da servicio a los requerimientos para montar en NFS. Para iniciar mountd(8), hay que asegurarse de que existe un fichero vacío mountdtab e invocar el dæmon:
# echo -n >/var/db/mountdtab
# /sbin/mountd
Si se hace algún cambio en el fichero /etc/exports mientras NFS esté funcionando, se tendrá que avisar a mountd sobre el cambio pasándole una señal "HUP":
# kill -HUP `cat /var/run/mountd.pid`
Se pueden realizar comprobaciones para asegurarse de que estos dæmons estén funcionando y registrados con RPC. Para ello se usa rcpinfo(8).
$ rpcinfo -p 10.0.0.1
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 633 mountd
100005 3 udp 633 mountd
100005 1 tcp 916 mountd
100005 3 tcp 916 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
Durante su uso normal, existen unas pocas utilidades más que nos permitirán ver lo que está ocurriendo con NFS. Una de ellas es showmount(8) que nos 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), basta con escribir /usr/bin/showmount -a host. Por ejemplo:
$ /usr/bin/showmount -a 10.0.0.1
All mount points on 10.0.0.1:
10.0.0.37:/work
Los sistemas de archivos NFS se deben montar mediante mount(8) o, más exactamente, mediante mount_nfs(8). Para montar el sistema de archivos /work del anfitrión 10.0.0.1 en un sistema de archivo local /mnt, se debe hacer lo siguiente (no es necesario usar una dirección IP, mount se encargará de la resolución de nombres):
# mount -t nfs 10.0.0.1:/work /mnt
Para que el sistema se monte al iniciar, hay que añadir algo como lo que viene a continuación en el fichero /etc/fstab:
10.0.0.1:/work /mnt nfs rw 0 0
¡¡Es importante usar 0 0 al final de esta línea para que la 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:
10.0.0.1:/work /mnt nfs rw,nodev,nosuid 0 0
De este modo ningún dispositivo o programa setuid en el servidor de NFS podrá traspasar las medidas de seguridad en el cliente de NFS. Si los programas que se monten no deben ser ejecutados por el cliente de NFS, se debe añadir noexec a esta lista.
NOTA: Esta información no es válida para TODOS los proveedores de conexiones ADSL, pero mucha de la información que aquí se encuentra se puede usar como base. Esta información sólo se ha verificado con Inode, un proveedor de ADSL en Austria.
Antes que nada hay que instalar pptp. El porte de pptp se encuentra en /usr/ports/net/pptp. Se puede encontrar más información sobre el árbol de portes de OpenBSD en la sección sobre los Portes del capítulo 8 de estos documentos.
Debido a un conflicto entre el soporte integrado en el núcleo de gre(4) y pptp, es preciso recompilar el núcleo del sistema, eliminando el soporte para gre(4).
Parche para eliminar el soporte para GRE(4).
Index: GENERIC
===================================================================
RCS file: /cvs/src/sys/conf/GENERIC,v
retrieving revision 1.86
diff -u -r1.86 GENERIC
--- GENERIC 14 Mar 2002 00:42:25 -0000 1.86
+++ GENERIC 17 May 2002 01:52:17 -0000
@@ -87,7 +87,7 @@
pseudo-device enc 1 # option IPSEC needs the encapsulation interface
pseudo-device bridge 2 # network bridging support
pseudo-device vlan 2 # IEEE 802.1Q VLAN
-pseudo-device gre 1 # GRE encapsulation interface
+#pseudo-device gre 1 # GRE encapsulation interface
#pseudo-device strip 1 # Starmode Radio IP interface
pseudo-device pty 64 # pseudo-terminals
Para recompilar el núcleo, antes hay que obtener el código fuente de OpenBSD mediante cvs (véase la página de AnonCVS para más información), aplicar el parche anterior, y recompilar el núcleo tal y como se indica en la sección sobre la compilación del núcleo del capítulo 5 de estos documentos.
Una vez que ya se haya instalado el paquete pptp y el nuevo núcleo, hay que editar unos cuantos ficheros para configurar la conexión. Este paquete utiliza el programa de ppp(8) nativo de OpenBSD; si se está familiarizado con ppp(8), gran parte de la configuración es idéntica. Vése también la sección sobre PPP de este documento.
Para el fichero /etc/ppp/options, una configuración como la siguiente será probablemente todo lo que se necesite:
# cat /etc/ppp/options
name "LOGINNAME"
noauth
noipdefault
defaultroute
debug
Se debe sustituir LOGINNAME con el identificador de usuario.
Para el fichero /etc/ppp/pap-secrets se necesitará una línea como ésta:
# cat /etc/ppp/pap-secrets
LOGINNAME 10.0.0.138 PASSWORD
en donde LOGINNAME es el identificador de usuario y PASSWORD la contraseña. 10.0.0.138 es la dirección IP asignada al módem en caso de que se use ADSL, etc. Hay que asegurarse de que este fichero sólo pueda ser leído por es superusuario root (modo 600).
En el ejemplo anterior, el módem tenía una interfaz 10.0.0.38 preconfigurada. Pero ahora necesitaremos asignar una dirección a NUESTRA interfaz. Lo mejor es escoger una dirección de IP cercana a la asignada para el MODEM, o usar la dirección de IP estática que nos hayan asignado. La sección sobre Configuración inicial de la red de este documento contiene más información sobre la configuración de interfaces.
Una vez que hayamos configurado la interfaz, deberíamos estar en disposición de establecer una conexión pptp con la orden:
# /usr/local/sbin/pptp 10.0.0.138 &
Como ya hemos dicho, se usará el ppp(8) nativo de OpenBSD, y se iniciarán dos procesos; en consecuencia, para matar pptp será necesario matar estos dos procesos:
# kill -9 [pid de pppd]
$ kill -9 [pid de pptp]
Es recomendable abrir /var/log/messages en una ventana de terminal aparte, para poder reconocer cualquier posible problema.
# tail -f /var/log/messages
También es aconsejable poner la orden de inicio en /etc/rc.local para que se conecte de forma automática cuando se reinicie el sistema.
Un puente de red (o bridge) es un enlace entre dos o más redes separadas entre sí. A diferencia de los enrutadores, la transferencia de paquetes a través de un puente de red es «invisible»; lógicamente, los dos segmentos de red aparecen como un solo segmento a los nodos de cada extremo del puente. El puente sólo reenvía aquellos paquetes que deban pasar desde un segmento hacia el otro, por lo que, entre otras cosas, ofrecen una forma fácil para reducir el tráfico en una red compleja, y aún así, permiten que cualquier nodo pueda acceder a otro nodo cualquiera siempre que esto sea preciso.
Nótese que, debido a esta «naturaleza invisible», una interfaz en un puente puede o no tener una dirección IP propia. Si la tiene, la interfaz tendrá dos modos de operación, uno que será parte de un puente y el otro un NIC normal independiente. Si ninguna de las interfaces tiene una dirección IP, entonces el puente pasará los datos de red, pero no se podrá mantener externamente (esto se puede considerar una funcionalidad).
Uno de mis bastidores tiene unos cuantos sistemas ya viejos, y ninguno de éstos tiene un NIC 10BASE-TX integrado. Aunque todos tienen un conector AUI o AAUI, mis transportadores se limitan al cable coaxial. Una de las máquinas en este bastidor es un servidor de OpenBSD que siempre está conectado a la red de alta velocidad. Añadiéndole un segundo NIC con puerto coaxial puedo usar esta máquina como un puente de red hacia la red coaxial.
Ahora este sistema tiene dos NIC, una tarjeta Intel EtherExpress/100 (fxp0) y otra tarjeta 3c590-Combo (ep0) para el puerto coaxial. fxp0 es el enlace con el resto de mi red, y por lo tanto tendrá una dirección IP; ep0 sólo se va a usar para el puente, y por lo tanto no tendrá ninguna dirección IP. Las máquinas conectadas al segmento coaxial se comunican como si estuvieran en el resto de la red... ¿cómo se hace esto?
El fichero hostname.fxp0 contiene la información de configuración de la tarjeta fxp0. Esta máquina está configurada mediante DCHP, por lo que el fichero es como sigue:
$ cat /etc/hostname.fxp0
dhcp NONE NONE NONE NONE
Hasta aquí sin sorpresas.
La tarjeta ep0 es, lógicamente, algo diferente:
$ cat /etc/hostname.ep0
up media 10base2
Aquí pasamos al sistema la instrucción de activar esta interfaz usando ifconfig(8), y de configurarla como 10BASE-2 (coaxial). No es necesario especificar ninguna dirección IP ni información parecida para esta interfaz. Las opciones que acepta la tarjeta ep se pueden encontrar en la página del manual de ep(4).
Ahora necesitamos configurar el puente de red. Los puentes de red se inician siempre que exista un fichero que se llame algo como nombre_puente.bridge0. He aquí un ejemplo de mi situación:
$ cat /etc/bridgename.bridge0
add fxp0
add ep0
up
Lo que dice es que se configure un puente de red que consista de dos NIC, fxp0 y ep0, y que se active. No importa el orden en que aparezcan las tarjetas, recuérdese que un puente de red es muy simétrico, los paquetes pasan en ambas direcciones.
¡Eso es todo! Después de reiniciar ya tendremos un puente de red totalmente funcional.
Aunque existen varios usos para un puente de red simple como éste, es muy probable que quiera hacer algo con los paquetes mientras pasan a través del puente. Se puede usar PF para restringir el tráfico que pasará a través del puente.
Hay que tener en cuenta que, por la naturaleza del puente, los mismos datos pasarán a través de ambas interfaces, por lo que sólo será necesario filtrar en una sola interfaz. Las reglas "Pass all" pueden quedar así:
pass in on ep0 all
pass out on ep0 all
pass in on fxp0 all
pass out on fxp0 all
Supongamos ahora que quiero filtrar el tráfico que llegue a estas viejas máquinas, y que sólo quiero que pase el tráfico de web y SSH por ellas. En este caso dejaremos salir y entrar todo el tráfico de la interfaz ep0, y filtraremos el de la interfaz fxp0, usando "keep state" para manejar la respuesta de datos:
# Pass all traffic through ep0
pass in quick on ep0 all
pass out quick on ep0 all
# Block fxp0 traffic
block in on fxp0 all
block out on fxp0 all
pass in quick on fxp0 proto tcp from any to any port {22, 80} \
flags S/SA keep state
Nótese que este grupo de reglas evitará que llegue cualquier tráfico a la máquina que funciona como puente de red o a cualquier otro nodo «detrás» de ella, excepto el tráfico entrante de HTTP y SSH. Es posible obtener otros resultado filtrando la otra interfaz.
Para monitorizar y controlar el puente, se puede usar la orden brconfig(8), que también puede ser usada para crear un puente de red después del arranque.
[Índice de documentos] [Sección 5 - Compilación del sistema con el código fuente] [Sección 7 - Controles de teclado y pantalla]