[LUG.ro-Wireless] Más ayuda técnica
Horacio Castellini
lugro-wireless@lugro.org.ar
Mon, 21 Jul 2003 19:42:18 -0300 (ART)
Que les parece este Howtto en español que conseguí? Interesante no!
------------------------------------------------------------------------------
Introducción
Este documento (al que aún falta gran parte, pero que se irá completando y modificando con el tiempo) es una guía paso a paso para montar un nodo Madrid Wireless desde el principio hasta el final. Los comentarios y correcciones a este documento deberán enviarse al autor (jorgegv@eresmas.net <mailto:jorgegv@eresmas.net>) y a la lista de correo Madrid Wireless (madridwireless@sindominio.net <mailto:madridwireless@sindominio.net>), para ser incluidos en posteriores versiones del mismo. Cualquier pregunta al respecto deberá dirigirse a la lista, donde será respondida por los integrantes del proyecto, entre los cuales me incluyo ;-D.
Para poder entrar de lleno en el proyecto Madrid Wireless, creo que es necesario tener al menos una idea de su filosofía, así como de la estructuración de la red. Por ello incluyo a continuación una breve reseña a propósito de ambas cosas. Si ya conoces el funcionamiento de MW, puedes saltarte esta introducción e ir directamente al apartado de Configuración del Nodo.
El tipo de nodo que se configura en este documento está basado en un ordenador tipo PC funcionando con sistema operativo GNU/Linux <http://www.linux.org>. Es perfectamente viable tener un nodo Madrid Wireless funcionando con otro tipo de hardware (un router Cisco, una máquina con Windows, etc.), pero ese tipo de nodo no se describe aquí. Sin embargo, las partes de la Filosofía y la Estructura de Red son perfectamente válidas para todo tipo de nodos.
Filosofía de Madrid Wireless
Madrid Wireless <http://www.madridwireless.net> somos un grupo de gente decidido a montar una red inalámbrica a través de Madrid, y ofrecer cobertura a los que deseen conectarse a nuestra red mediante tarjetas de red inalámbricas Ethernet 802.11b.
La finalidad principal de Madrid Wireless es crear una red entre los sistemas pertenecientes a ella (llamados nodos) y ofrecer acceso a dicha red a las personas que lo deseen, simplemente entrando en la zona de cobertura de uno de los nodos con un sistema que tenga una tarjeta de red Ethernet 802.11b (llamados clientes).
La finalidad principal de MW no es la de proveer de acceso a Internet gratuito, aunque algunos de los nodos ofrezcan ese servicio a los clientes que se conecten con ellos.
Estructura general de la red
La red esta estructurada según el modelo de una red de backbone y otra de acceso: el backbone lo forman los nodos de la red y las conexiones entre ellos (normalmente privadas y punto a punto), y la red de acceso la forman los receptores 802.11b instalados en cada nodo, que son los que "captan" las conexiones de los clientes.
Es importante tener claros estos dos niveles, ya que deben ponerse a punto de forma separada e independiente primero, para después ajustar el encaminamiento del tráfico entre la red de backbone y los clientes.
En la Figura 1> puede verse un esquema dibujado a mano alzada (;-) de la estructura de la red.
Figura 1. Estructura General de la Red
Los circulos azules con la N dibujada corresponden a los nodos, y las líneas azules contínuas, a las conexiones entre ellos. Todos juntos (nodos y conexiones entre nodos) forman la red de backbone.
Las líneas verdes contínuas con ordenadores dibujados representan las (posibles) redes locales que los administradores de los nodos pudiesen tener conectadas directamente a los nodos (en mi caso, la red local de mi casa).
Las torretas rojas junto con los ordenadores rojos y los rayitos representan los clientes wireless que puede tener un nodo.
Cuando un cliente se conecta a un nodo, sigue un mecanismo muy similar al que sigue para conectarse a Internet: con un ISP, hay una asignación dinamica de dirección IP y algún otro parametro, y desde entonces está conectado al backbone del ISP, quien a su vez enruta el tráfico del cliente hacia Internet. Con Madrid Wireless es similar: el nodo asigna dinámicamente la dirección IP al cliente, y este queda conectado al backbone de Madrid Wireless. Este se encarga, a su vez, de encaminar el tráfico del cliente hacia otros clientes o nodos de Madrid Wireless, o en caso de que el nodo lo permita, hacia Internet.
Estructura del backbone
Las conexiones entre los nodos (los enlaces de backbone) pueden ser de muchos tipos, y no es necesario que sean mediante tarjetas Wi-Fi, aunque es probablemente la más barata de las alternativas de conexión entre nodos (gratis ;-). Estas conexiones normalmente serán punto a punto, aunque es perfectamente viable una situación en la que varios nodos que estén lo bastante cerca como para tirar un cable (legalmente) entre ellos, estén conectados mediante tarjetas Ethernet normales y un switch o hub; por ejemplo, en una comunidad de vecinos.
Es necesario aclarar, en el tema de las conexiones entre nodos, el hecho de que no es necesario que sea mediante tarjetas Wi-Fi. Una alternativa para interconectar nodos o redes de distintos grupos podría ser, por ejemplo, la apertura de túneles a través de Internet, para la gente que tenga conexiones ADSL o por cable. Otra podría ser conexiones RDSI/PPP, o mediante enlaces ópticos, etc. Lo que tiene que quedar claro es el único punto en el que es estrictamente necesaria la interfaz radio (802.11b) es en el acceso de los clientes a la red.
Para permitir el enrutamiento entre nodos, si el número de nodos fuese bajo podría hacerse mediante rutas estáticas. Esto tiene la ventaja de ser muy fácil de hacer, pero no es escalable a un número de nodos medio o alto por el alto coste de mantenimiento. Por ello, lo que se debe implantar es un protocolo de enrutamiento dinámico. En la lista de Madrid Wireless ya se ha debatido el tema, y el protocolo que se usará, casi con total seguridad, será OSPF (Open Shortest Path First), que es estándar y está totalmente soportado en Linux, mediante el paquete Zebra.
Estructura de un nodo
Un nodo, como hemos dicho más arriba, es un sistema que cumple las funciones de enrutar tráfico desde y hacia otros nodos de la red, y desde y hacia los clientes a los que proporcione acceso. Conceptualmente, un nodo es un router, con capacidades mejoradas. Y dado que un nodo es capaz de enrutar trafico entre diversas redes, lo normal es que tenga varias interfaces de red, del tipo que sean.
En la Figura 2> puede verse un nodo con una estructura típica.
Figura 2. Estructura General de la Red
El nodo de la figura tiene 4 interfaces:
• eth0: es la interfaz que conecta el nodo con la red local del administrador del nodo. Normalmente esta red será privada, y los clientes no tendrán acceso a ella, aunque lógicamente dependerá del administrador del nodo, e incluso se pueden ofrecer servicios en ella.
• eth1: es la interfaz mediante la que los clientes Wi-Fi se conectan al nodo, y de ahí a Madrid Wireless. Normalmente esta interfaz está conectada a una antena omnidireccional o similar, para mejorar la cobertura. Es probable que, según el controlador de tarjetas Wi-Fi que se use, esta interfaz se llame wlanX, en vez de ethX.
• ppp0: es la interfaz mediante la que el nodo se conecta a Internet. Puede ser una conexión PPP a través de la Red Telefónica Convencional (RTC), RDSI, ADSL, Cable-modem, etc. El nombre de la interfaz variará, según el modo de acceso.
• ppp1: es la interfaz mediante la que el nodo se conecta a otro nodo adyacente. Igualmente, puede ser una conexión PPP, Ethernet, ADSL, etc. y por ello el nombre también puede variar.
Lógicamente, con todos los tipos de tráfico que esto puede gestionar (tráfico hacia y desde Internet, Madrid Wireless, redes privadas...), se vuelve imprescindible la activación de técnicas de firewall y NAT entre las interfaces del nodo.
Configuración del nodo
Como ya se ha comentado más arriba, el tipo de nodo que se describe en este documento es un PC con GNU/Linux y algunas aplicaciones necesarias para soportar el servicio que se quiere ofrecer.
No es necesario ser un experto en Linux para seguir esta guía, aunque se presuponen unos conocimientos básicos de redes TCP/IP, administración de equipos UNIX y el proceso de compilación del kernel, sin los cuales la instalación puede ser un poco más complicada. Para intentar evitar este problema, al principio de cada apartado se incluye un mini-párrafo de explicación general del funcionamiento del elemento hardware o software que se va a configurar en dicho apartado, y se incluyen referencias.
Dada la complejidad de la configuración de algunos de los subsistemas y paquetes implicados, se aconseja seguir esta guía paso a paso y en el orden indicado, y no pasar al punto siguiente sin estar seguro de que los anteriores funcionan correctamente. Esto es especialmente crítico en lo que se refiere a la configuración de la red de backbone, ya que si no se sigue el orden, en caso de problemas estos serán mucho más difíciles de aislar y solucionar.
Hardware y software necesarios
Hardware:
• Sistema: un PC.
• Para dar cobertura a clientes: una tarjeta Wi-Fi con todo el hardware necesario (si es PCMCIA y el ordenador es de sobremesa, es necesario un bridge PCI-PCMCIA o ISA-PCMCIA). También se puede usar un Access Point, en cuyo caso la conexión con el nodo será, probablemente, mediante una tarjeta Ethernet normal, o mediante un puerto USB. Es muy aconsejable que antes de comprar la tarjeta se revise la lista de tarjetas PCMCIA soportadas.
• Para mejorar la cobertura: una antena omnidireccional. La antena no es estrictamente necesaria para hacer las pruebas mientras se monta el nodo, pero sí lo es si se quiere dar una cobertura mínimamente decente.
• Para conectar con otros nodos: otra interfaz de red, de cualquier tipo. Puede ser otra tarjeta Wi-Fi con una antena direccional, una tarjeta Ethernet normal y un cable, una conexión PPP a través del teléfono, un túnel a través de Internet, en general cualquier método que sirva para conectar dos equipos.
Aparte de estos elementos, pueden añadirse los que sean necesarios para conectar, por ejemplo, con otra red local que se tenga disponible en el emplazamiento del nodo. Para ello haria falta otra tarjeta Ethernet, por ejemplo.
Software:
• Sistema Operativo RedHat Linux 7.x. Este es el que se ha usado al generar este documento, pero cualquier distribución es válida (Debian, Slackware, Mandrake...). La versión del kernel utilizada es la 2.4.17 (de momento) aunque las opciones necesarias para el software de nodo son lo suficientemente genéricas y estables para que la versión del kernel no suponga un problema. El web de Redhat es este: www.redhat.com.
• Servidor DHCP de Internet Software Consortium (ISC). Viene de serie con todas las distribuciones, pero por si acaso, el sitio original es www.isc.org.
• Paquete PCMCIA-CS. Es necesario para poder configurar y utilizar las tarjetas Wi-Fi, ya que la inmensa mayoría vienen en este formato, incluso si son para PCs de sobremesa (la mayoría de tarjetas de sobremesa son tarjetas PCMCIA con bridges que permiten conectarlas). El sitio para descargarlo es http://pcmcia-cs.sourceforge.net.
• Paquete IPTABLES. También viene de serie con todas las distribuciones, aunque es posibe que para usarlo se tenga que recompilar el kernel con las opciones adecuadas. El sitio original es www.netfilter.org.
• Paquete ZEBRA. Es el programa que permite hacer enrutamiento dinámico mediante varios protocolos, y entre ellos OSPF. Hay que descargarlo de la siguiente dirección: www.zebra.org.
• Paquete IPROUTE. También viene de serie, y es probable que haya que recompilar el kernel para usarlo. La página original del paquete es ftp://ftp.inr.ac.ru/ip-routing/.
Configuración del Sistema Operativo
No entraremos en detalles sobre la instalación del sistema operativo, ya que el método varía bastante de una distribución a otra y no es el objeto de este documento. Únicamente se dirá que es necesario instalar un Linux, con capacidad de comunicación en red, y con los paquetes software que se han comentado más arriba (los que vienen incluidos en la distribución).
No es necesaria la instalación de interfaces gráficas ni del sistema X-Window, y de hecho es recomendable que el sistema instalado incluya lo mínimo imprescindible para dar servicio, aunque como es de suponer que la mayoría de los administradores no tendrán una máquina especialmente dedicada a Madrid Wireless, esto será difícil de cumplir. Por ello se prestará especial atención a la parte de configuración del firewall, más adelante. Por otro lado, sí es necesaria la instalación de herramientas de desarrollo, al menos el compilador de C y las librerías asociadas, ya que algunos paquetes y probablemente el kernel necesitarán ser recompilados.
Es conveniente, además, ejecutar la instalación con las tarjetas PCMCIA introducidas en sus ranuras, para que la instalacion las detecte y las configure. [Desconozco cómo configura una tarjeta Wi-Fi el instalador de RedHat, porque yo añadí el soporte después de instalar, pero estoy razonablemente seguro de que las configura correctamente, al menos de forma elemental. Necesito que alguien que haya instalado el equipo de esta forma corrobore esto último.]
A partir de esta sección se supone que se dispone de un sistema Linux correctamente configurado y con las herramientas de red y de desarrollo necesarias para la administración del nodo.
Solicitud de rangos de direccionamiento
Para configurar un nodo Madrid Wireless es necesario solicitar al menos dos rangos de direccionamiento: uno para la red de acceso y otro para la red de backbone. El esquema de direccionamiento se explica de forma detallada en este documento, pero para los impacientes, el direccionamiento de la red de acceso son direcciones de la red 10.x.x.x, en subredes de 32 direcciones, y las conexiones punto a punto entre nodos son direcciones de la red 172.16.x.x, con subredes de 4 direcciones (las normales en conexiones punto a punto).
El procedimiento para la solicitud de direcciones y el plan actual de direccionamiento, lista de nodos, ubicación, etc. se encuentra disponible en este documento.
A partir de aquí se supondrá que se han asignado para este nodo los siguientes rangos:
• Red de Acceso: 10.64.0.0/27. Es decir, de la 10.64.0.0 a la 10.64.0.31.
• Red de Backbone: 172.16.0.0/30. Es decir, de la 172.16.0.0 a la 172.16.0.3.
Configuración de la tarjeta Wi-Fi
Lo primero es comprobar si el sistema ha reconocido correctamente la tarjeta Wi-Fi en la instalación, en cuyo caso se revisará la configuración, a nivel de interfaz de red, y a nivel de radio.
Para comprobar la configuración de la interfaz de red:
• En Redhat:
Se puede hacer editando los ficheros que se encuentran en el directorio /etc/sysconfig/network-scripts/, que se llaman ifcfg-XXXX, y es donde se almacenan las opciones de cada interfaz (XXXX puede ser, por ejemplo eth1). O bien se puede arrancar la herramienta gráfica de configuración de interfaces de red, llamada netcfg.
La interfaz correspondiente a la red de acceso debe configurarse con una IP fija, del rango que se ha solicitado antes, el 10.0.0.0. Ya que la dirección 10.0.0.0 está reservada como dirección de red, y la dirección 10.0.0.31 como dirección de broadcast, se elegirá la 10.0.0.1. Esta dirección es la que los clientes deben tener como dirección de gateway por defecto, para poder enrutar tráfico hacia el resto de nodos o clientes. Ya se verá más adelante que esta es una de las opciones que se configurarán en el servidor DHCP.
La máscara de red deberá ser de 27 bits, es decir, 255.255.255.224.
• En Debian:
La manera más sencilla para configurar los interfaces de red ethernet es instalar el paquete etherconf. Se harán una serie de preguntas como la dirección IP, mascara de red, etc. Si se quiere hacer "a mano" basta con modificar el fichero "/etc/network/interfaces", añadiendo (ejemplo):
iface eth0 inet static
address 192.168.0.2
netmask 255.255.255.0
gateway 192.168.0.1
Para configurar la tarjeta wireless basta con modificar en el fichero "/etc/pcmcia/network.opts" las variables IPADDR, NETMASK, NETWORK, BROADCAST y GATEWAY.
Para comprobar la configuración a nivel radio:
Debe editarse el fichero /etc/pcmcia/wireless.opts, y en él se configurará el valor de algunas variables, para la tarjeta particular que se esté usando.
En dicho fichero, existen unas líneas que indican los parámetros a seleccionar según la dirección MAC de la tarjeta Wi-Fi que se active. Al principio del fichero deben insertarse las siguientes líneas:
# Ejemplo generico
*,*,*,*)
INFO=""
ESSID="madridwireless"
MODE="Ad-Hoc"
KEY="off"
RATE="auto"
FREQ="1"
;;
Esta configuración radio es válida tanto para el nodo como para el cliente, ya que define una serie de parámetros para la comunicación de nivel físico sobre la que se monta Ethernet (que es nivel de enlace).
• Con la primera línea se le indica que los parámetros que siguen son aplicables a cualquier tarjeta Wi-Fi que se inserte, sea del fabricante que sea. El último asterisco es la dirección MAC a la que afectan esos parámetros (los comodines son válidos). En este caso, se pone todo como comodines, para facilitar la configuración.
• La variable INFO es opcional y sirve para proporcionar información adicional sobre la interfaz de red a las herramientas software.
• La variable ESSID es imprescindible, y debe tener el mismo valor en todos los nodos que quieran pertenecer a la misma red. En el caso de Madrid Wireless, como este valor debe ser público, se ha decidido que sea el valor "madridwireless".
• La variable MODE es también imprescindible, y puede tener varios valores. Los que interesan son "Ad-Hoc" y "Managed", que se corresponden con los modos autónomo (cada tarjeta habla con las demás directamente) e infraestructura (cada tarjeta habla con las demás a través de un dispositivo especial, llamado Access Point). También hay otros modos ("Master", "Secondary",...) que sirven para poner la tarjeta en modos especiales, como por ejemplo, cuando se hace funcionar el propio PC como si fuera un Access Point. Estos otros modos, no se cubren en este documento, al menos de momento. Para dar cobertura mediante una tarjeta, se debe poner en modo "Ad-Hoc".
• La variable KEY sirve para especificar la clave de cifrado que se usará en la red Wi-Fi. Ultimamente ha sido demostrado que el algoritmo de cifrado de estas tarjetas es penetrable con unos recursos mínimos, así que en Madrid Wireless se ha decidido que el tráfico vaya sin cifrar. Se definirán protocolos en niveles superiores que permitirán las operaciones clásicas de autentificación y cifrado de datos (IPSec, SSH, OpenPGP, SSL, etc.)
• La variable RATE especifica la velocidad de conexión. El estandar 802.11b define varias velocidades de conexión: 1, 2, 5.5 y 11 Mbps (Megabits por segundo). Si esta variable tiene el valor "auto", se seleccionará automáticamente la más alta disponible. Valores: "1M", "2M", "5.5M" y "11M".
• La variable FREQ indica el canal en el que tendrá lugar la comunicación. Lógicamente, para que dos tarjetas hablen entre sí, deben emitir en el mismo canal. El estándar define hasta 13 (?) canales, de los cuales en España son legales 11 (?). En esta variable se puede especificar un número del 1 al 13, o bien la frecuencia en GHz. Valores posibles: "1" a "13", o bien "2.425G" (por ejemplo). Lo más cómodo es especificarlo por número de canal.
Es posible configurar la tarjeta Wi-Fi de un cliente sin configurar ni el ESSID ni el canal (FREQ), de forma que coja los parámetros automáticamente de la red que encuentre disponible. Para esto, la tarjeta Wi-Fi del nodo que da cobertura debe estar funcionando como Access Point, o bien el nodo debe utilizar un AP para dar cobertura. En este caso, el cliente se conectará a la red con los datos del AP que tenga más cerca, de forma automática.
Configuración del DHCP (ISC)
El protocolo DHCP (Dynamic Host Configuration Protocol) es el que se utiliza para la asignación dinámica de direccionamiento a los clientes en la red de acceso. Cuando un cliente está cerca de un nodo y configura su tarjeta Wi-Fi, en el momento en que el nivel de enlace (Ethernet) está funcionando, lanza una petición buscando servidores DHCP (paquete DHCPDISCOVER). El servidor DHCP recoge esa petición, y en caso de que tenga direcciones libres para asignar en la interfaz en la que le ha llegado la petición, ofrece una dirección al cliente (paquete DHCPOFFER). El cliente entonces envía una solicitud oficial para la dirección que le han ofrecido (paquete DHCPREQUEST), y el servidor DHCP anota y confirma la solicitud al cliente (paquete DHCPACK). Además, se le envía al cliente diversos tipos de información, como el router por defecto, los servidores DNS, servidores WINS, y muchos otros parámetros que pueden ser de interés. El envío de todos estos parámetros es totalmente config!
urable en el servidor.
La configuración del servidor DHCP es bastante sencilla, y se resume a continuación en los puntos siguientes:
1. Instalación del paquete DHCP: en RedHat el paquete se llama dhcp-x.y-z.i386.rpm (siendo x, y y z los números de versión), y viene en el CD del Sistema Operativo. En Debian, el paquete se llama dhcp-x.y.i386.deb y también viene en el CD de instalación.
La instalación es sencilla: en el caso de RedHat, basta con ejecutar rpm -ihv dhcp-x.y-z.i386.rpm; en el caso de Debian, el comando es apt-get install dhcp-x.y.i386.deb, con lo que según el medio de instalación que se tenga configurado pedirá CD o se lo bajará de la red.
2. Configuración general: a continuación se incluye el fichero de configuración necesario para el nodo y direccionamiento que se ha mencionado anteriormente. Después se explica detalladamente el contenido del fichero:
Fichero /etc/dhcpd.conf:
subnet 10.64.0.0 netmask 255.255.255.224 {
# --- default gateway
option routers 10.64.0.1;
option subnet-mask 255.255.255.224;
option domain-name-servers 10.64.0.1;
range dynamic-bootp 10.64.0.2 10.64.0.30;
default-lease-time 3600;
max-lease-time 7200;
}
subnet 172.16.0.0 netmask 255.255.0.0 {
}
o El fichero esta compuesto de varias secciones subnet, que es donde se configura cada una de las subredes a las que tiene acceso la máquina. Dentro de cada una de estas secciones, se configura la información que se enviará a los clientes DHCP que se pongan en comunicación con el servidor en dicha subred.
o La línea option routers ... indica el router por defecto que se indicará a los clientes que deben utilizar.
o La línea option subnet-mask ... indica la máscara de red para los clientes.
o Mediante la línea option ...domain-name-servers se informa a los ...clientes del(de los) servidor(es) DNS que pueden usar.
o La línea range dynamic-bootp ... indica al servidor el rango de direcciones de dicha subred que se debe usar para asignación dinámica. En este caso, de la 2 a la 30, es decir, 29 direcciones.
o las líneas default-lease-time ... y max-lease-time ... definen los períodos por defecto y máximo que un cliente puede mantener su dirección sin necesidad de renovarla pidiéndola de nuevo. Cuando el servidor asigna una dirección a un cliente, le asigna también una caducidad, y una vez transcurrido dicho período el cliente debe renovar su asignación de dirección solicitándola de nuevo.
3. Configuración de los parámetros: hay otros muchos parámetros que se pueden enviar a los clientes, como por ejemplo, los nombres de dominio Internet o NIS, las direcciones de los servidores WINS (para clientes Windows), las direcciones de servidores NTP (Network Time Protocol), servidores de impresión, rutas, y otros muchos. Para conocer todos los parámetros que el servidor DHCP permite configurar, se puede consultar la página man correspondiente a dhcp-options (5).
Cosas a tener en cuenta:
• El servidor DHCP necesita tener configuradas todas las interfaces y subredes que encuentre en el equipo, incluso aunque no vaya a servir direcciones en ellas; en este último caso, no se definirán rangos en el fichero de configuración para dichas subredes. En caso de que falte alguna, el servidor no arrancará.
• Debido a esto, si cualquiera de las interfaces cambia (direccionamiento, nombre, etc.), será necesario reiniciar también el servidor DHCP para que active la nueva configuración. Un caso en el que pasa esto es, por ejemplo, mientras se está montando el nodo y se cambian parámetros de la tarjeta Wi-Fi, como el ESSID, el canal, o el direccionamiento. En este caso, normalmente se reinicia el subsistema PCMCIA para activar dichos cambios, y también debe reniciarse el servidor DHCP.
Configuración de la red de backbone
Configuración del nivel de enlace
Conexión con otro nodo mediante Wi-Fi
Por hacer.
Conexión con otro nodo mediante Ethernet
Por hacer.
Conexión con otro nodo mediante PPP
Por hacer.
Configuración del nivel de Red
En esta sección vamos a explicar brevemente como crear VPNs (Red Privada Virtual) mediante túneles y GNU/Linux. Para comunicar los nodos wireless, si estos no se ven directamente, es necesario crear túneles cifrados a través de Internet, para pasarse la información de la red así como las tablas de enrutamiento y de esta manera unir múltiples redes inalámbricas para crear una sola red. Existen diversas herramientas bajo la licencia GNU/GPL para crear VPN's como FreeS/WAN, VPND, CIPE, etc. VPND cubre nuestras necesidades y es muy fácil de instalar y configurar, mientras que FreeS/WAN utiliza IPSec y es por tanto estándar y capaz de interoperar con otros equipos también estándares.
Conexión Mediante Túnel IPSec
IPsec son un conjunto de extensiones al protocolo IP que proporcionan mecanismos de autentificación y encriptación similares a los que ofrece SSL, pero a nivel de red en vez de de transporte. Gracias a esto conseguimos que nuestras aplicaciones no tengan que preocuparse en este tema, además de ser bastante más potente que SSL.
IPsec nos ofrece confidencialidad, integridad y autentificación mediante dos protocolos, AH y ESP. AH (Authentication Header) nos proporciona integridad y autentificación usando una firma hash sobre el paquete IP. ESP (Encapsulated Security Payload) nos permite la integridad, autentificación y confidencialidad de nuestro paquetes IP, mediante diferentes algoritmos de cifrado.
Instalación
La versión que hemos probado es un snapshot del cvs (snap2002jan15b) de Frees/WAN y el kernel 2.4.16. Para compilar el parche de Frees/WAN nos hará falta tener instalado las librerías GMP y sus cabeceras.
Lo primero que hay que hacer es compilar el kernel, sin preocuparnos de aplicar el parche de Frees/WAN. Mejor probar el kernel compilado e instalado para estar seguro de que funciona correctamente.
Lo siguiente es descomprimir los fuentes de Frees/WAN y ejecutar uno de los siguientes comandos:
make menugo # usa menuconfig
make xgo # usa xconfig
make ogo # usa config
make oldgo # usa oldconfig
Una vez dentro de la configuración del kernel, las opciones de IPsec están en la sección "Networking-unrelated". Las opciones más importantes estarán señaladas. Ya solo queda salvar la configuración nueva y esperar a que se compile el nuevo kernel e instale las aplicaciones de IPsec.
Configuración
VPN (gateway-gateway)
Lo primero es generar nuestras claves. Para ello utilizamos ejecutaremos como root:
$ ipsec newhostkey > /etc/ipsec.secrets
$ chmod 600 /etc/ipsec.secrets
Lo siguiente es configurar nuestra conexión entre los dos gateways. Para ésto deberemos modificar el fichero /etc/ipsec.conf, que más o menos tendrá esta pinta (cambiar direcciones ip):
# Configuración básica
config setup
interfaces="ipsec0=eth0"
klipsdebug=all
plutodebug=all
plutoload=%search
plutostart=%search
uniqueids=yes
# Parámetros por defecto para las conexiones
conn %default
keyingtries=0
conn dummy
right=a.b.c.d
rightsubnet=a.b.c.0/24
rightnexthop=
left=e.f.g.h
leftsubnet=e.f.g.0/24
leftnexthop=
authby=rsasig
rightrsasigkey=0sAQNbpZ ...
leftrsasigkey=0sAQNxm7 ...
La sección conn setup describe la configuración de la máquina. El parámetro interface indica que interfaz de red vamos a usar para crear el túnel. klipsdebug y plutodebug indican distintas opciones de depuración. Con plutoload y plutostart decimos que conexiones se cargarán y se iniciarán automáticamente al arrancar el demonio Pluto (demonio de intercambio de claves).
La sección conn %default describe la configuración por defecto de las conexiones. keyingtries indica los intentos para establecer una conexión, el valor 0 corresponde a un número "ilimitado" de intentos.
La sección conn corresponde a la configuración de una determinada conexión. Los parámetros right y left indican cada uno de los gateways. Que gateway es el de un lado u otro da igual. rightsubnet y leftsubnet indican las subredes de las que se quiere que usen el túnel, si no se quieres usar ninguna subred dejar en blanco. En authby decimos el modo de autentificación. rightrsasigkey y leftrsasigkey son las claves públicas de cada gateway.
Lo único que a lo mejor tenéis que añadir son rightnexthop y/o leftnexthop si hay algún router por medio, teniendo que añadir la dirección de éste. Si ambos gateways se ven directamente (los paquetes no tienen que pasar por ningún router) dejar en blanco.
Mucha más documentación en las páginas del manual (ipsec.conf(5), ipsec.secrets(5) y en la documentación (HowTo) de Frees/WAN. Páginas de los ficheros de configuración:
Para obtener las claves públicas (rightrsasigkey o leftrsasigkey) podéis mirar el fichero /etc/ipsec.secrets o usar el siguiente comando:
$ ipsec showhostkey --{left|right}
Ya solamente queda iniciar el túnel (en ambas máquinas).
$ ipsec auto --add dummy
$ ipsec auto --up dummy
Si queremos que se creé el túnel automáticamente cada vez que iniciamos ipsec, basta con añadir "auto=add" en el fichero ipsec.conf, en la sección conn dummy.
Una vez terminado con la configuración y creado el túnel deberíamos tener algo de este estilo:
$ ifconfig
ipsec0 Link encap:Ethernet HWaddr 00:20:E0:6A:AC:C2
inet addr:10.0.0.1 Mask:255.255.255.0
inet6 addr: fe80::220:e0ff:fe6a:acc2/10 Scope:Link
UP RUNNING NOARP MTU:16260 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:3 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
$ ip link list
4: ipsec0: <NOARP,UP> mtu 16260 qdisc pfifo_fast qlen 10
link/ether 00:20:e0:6a:ac:c2 brd ff:ff:ff:ff:ff:ff
$ ip route list
10.0.0.0/24 dev ipsec0 proto kernel scope link src 10.0.0.1
Conexión Mediante Túnel VPND
Vpnd nos permite crear enlaces seguros sobre TCP/IP, con claves de hasta 512 bits con algoritmo de ecriptación blowfish, montando una interface serie virtual (slx) que proporciona la posibilidad de enrutar tráfico IP entre dos subredes. Para empezar, deberemos tener soporte SLIP en el núcleo:
SLIP (serial line) support
[*] CSLIP compressed headers
[*] Keepalive and linefill
[*] Six bit SLIP encapsulation
Después de configurar el núcleo, compilarlo y probar que funciona correctamente pasamos a instalar el paquete vpnd (con 'apt-get install vpnd' en Debian; para RedHat se puede buscar el RPM correspondiente).
Una vez instalado deberemos crear la clave de sesión con 'vpnd -m /etc/vpnd/vpnd.key'. Esta clave debe ser la misma en los dos extremos de la VPN por lo que tendremos que pasarle la clave por un medio seguro al otro equipo. Después de esto solo nos queda configurar las dos patas de la VPN, como se comunican a través de TCP siguiendo la estructura cliente/servidor uno actuará de cliente y el otro de servidor de la VPN.
Fichero /etc/vpn/vpnd.conf de configuración en el servidor:
mode server
# Dirección IP y puerto del servidor
server a.b.c.d 2001
# Dirección IP y puerto del cliente
client w.x.y.z 2001
# Dirección IP privada del servidor
local a.b.c.d
# Dirección IP privada del cliente
remote w.x.y.z
# Opciones generales
autoroute
keepalive 10
noanswer 3
keyfile /etc/vpnd/vpnd.key
pidfile /var/run/vpnd.pid
keyttl 120
randomdev /dev/urandom
mtu 1600
Fichero /etc/vpn/vpnd.conf de configuración en el cliente:
mode client
# Dirección IP y puerto del cliente
client w.x.y.z 2001
# Dirección IP y puerto del servidor
server a.b.c.d 2001
# Dirección IP privada del cliente
local w.x.y.z
# Dirección IP privada del servidor
remote a.b.c.d
# Opciones generales
autoroute
keepalive 10
noanswer 3
keyfile /etc/vpnd/vpnd.key
pidfile /var/run/vpnd.pid
randomdev /dev/urandom
mtu 1600
Una vez hechas estas modificaciones ya podemos levantar la VPN iniciando los demonios con '/etc/init.d/vpnd start'. Para comprobar que todo ha funcionado correctamente podemos hacer pings a nuestra IP privada y a la IP del otro extremo y ver con 'ifconfig -a' que tenemos una interface nueva como esta:
sl0 Link encap:VJ Serial Line IP
inet addr:10.0.0.1 P-t-P:10.0.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1600 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
compressed:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 compressed:0 txqueuelen:10
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Si ves esto ya tienes el invento funcionando :-). Si quieres aprender más sobre el tema te recomiendo que te pases por la página del proyecto vpnd donde se explican algunas cosas más sobre el tema.
Activación del firewall (IPTABLES)
Las técnicas de firewalling son imprescindibles si se quiere mantener la seguridad del nodo. Hemos de tener en cuenta que se está permitiendo la conexión al nodo a clientes desconocidos y potencialmente hostiles, asi que se deberán filtrar adecuadamente todos los accesos a las distintas redes.
En el caso de Madrid Wireless, el firewall que se va a emplear es el que viene de serie con el kernel 2.4.x: Netfilter (más conocido por el nombre de su herramienta de configuración: iptables).
Para configurar adecuadamente el firewall es necesario seguir una serie de pasos que facilitan la configuración. Aunque en un principio pueda parecer un poco engorroso, es un procedimiento que al final ahorra trabajo y problemas. Dichos pasos se explican en las secciones siguientes.
En este capítulo se ha omitido (temporalmente) la configuración de las redes de backbone y por tanto lo referente a enrutamiento dinámico. Estas partes se incluiran en versiones posteriores de este documento.
Preparación del kernel e instalación del software necesario
En la mayoría de casos, el kernel viene precompilado con las opciones necesarias para la activación del firewall. Las opciones imprescindibles son (aparte de "TCP/IP Networking", por supuesto ;-) "Network packet filtering" (opcion CONFIG_NETFILTER), y dentro del submenú "IP: Netfilter Configuration", lo mejor es activar todas las opciones como módulos.
No está estrictamente relacionado con el firewall , pero aprovechando que se va a recompilar el kernel (en caso de que vaya a hacerse), conviene activar también las opciones relativas a la categoría "IP: Advanced Router", con todas sus subopciones activadas (será necesario para la activación de las políticas de tráfico),y tambien "IP: Multicasting" (necesario para el enrutamiento dinámico con OSPF). Estas opciones también suelen venir activadas con los kernels de las distribuciones.
Una vez reconfigurado el kernel, se procederá a compilarlo, instalarlo y reiniciar la máquina como de costumbre.
Identificación de interfaces
Es imprescindible la identificación de todas las interfaces de red de las que dispone el nodo, y las redes con las que están conectadas. En el caso del nodo ejemplo que se está montando en este documento, las interfaces se vieron en la sección sobre Estructura de un nodo.
La lista de interfaces del nodo, y sus redes convenientemente etiquetadas, podría ser la que sigue:
• eth0: red PRIVADA.
• eth1: red de ACCESO.
• ppp0: red INTERNET.
• ppp1: red de BACKBONE1.
[En el caso de ppp1 se añade la numeración para enfatizar el hecho de que puede haber más de una conexión al backbone, es decir, puede haber conexión con más de un nodo]
Identificación del tráfico
Una vez identificadas las interfaces del nodo, es necesario plantearse el tráfico que se va a ver en cada una de las interfaces, clasificarlo según el origen y el destino, y decidir si se permitirá o no el paso de dicho tráfico a través del nodo.
Es muy importante distinguir entre el tráfico que pasa A TRAVÉS del nodo (es decir, el que tiene como dirección de origen y destino direcciones pertenecientes a las redes a las que está conectado), y el trafico HACIA Y DESDE el nodo (el tráfico que va dirigido a la dirección IP del propio nodo y el que sale de ella); y hay por tanto que plantearse el tráfico que va a permitirse que llegue al nodo y el que salga de él. Normalmente esto significará permitir ciertos servicios, como SSH, desde y hacia la red PRIVADA (por ejemplo) y rechazar el resto del tráfico que involucre al nodo.
Se deberá crear otra tabla, esta vez con las interfaces emparejadas dos a dos, de forma que se cubran todas las combinaciones posibles de entrada y salida; y se anotarán las conexiones permitidas en dicha tabla.
Un ejemplo de dicha tabla para el nodo que se esta configurando en este documento puede ser el siguiente:
Tabla 1. Identificación de Tráfico entre Interfaces
Interfaces Origen Destino Permitido Resto Notas
eth0-ppp0 eth0 ppp0 Todo Permitimos todo el tráfico de salida desde la red privada hacia Internet
ppp0 eth0 Paquetes de Conexiones Abiertas Log y Rechazar Rechazamos todo lo que venga de Internet, salvo los paquetes de vuelta pertenecientes a conexiones establecidas
eth0-eth1 eth0 eth1 Todo Permitimos todo el tráfico de salida desde la red privada hacia MadridWireless
eth1 eth0 Paquetes de Conexiones Abiertas Log y Rechazar Rechazamos todo lo que venga de MadridWireless, salvo los paquetes de vuelta pertenecientes a conexiones establecidas
eth1-ppp0 eth1 ppp0 Todo Permitimos todo el tráfico de salida desde MadridWireless hacia Internet
ppp0 eth1 Paquetes de Conexiones Abiertas Log y Rechazar Rechazamos todo lo que venga de Internet, salvo los paquetes de vuelta pertenecientes a conexiones establecidas
La Tabla 1> es la que se usará para la clasificación del tráfico entre interfaces, que no involucre al nodo. En el marco de IPTABLES, esto se traducirá en la utilización de la cadena FORWARD, como veremos en la siguiente sección.
Para el tráfico entrante y saliente al propio nodo, se puede realizar una tabla similar:
Tabla 2. Identificación de Tráfico Hacia y Desde el Nodo
Interfaz Origen Destino Permitido Resto Notas
eth0 eth0 NODO Todo Permitimos todo el tráfico entrante y saliente entre la red privada y el nodo. Suponemos que es una red fiable.
NODO eth0 Todo
eth1 eth1 NODO DNS(udp), ICMP, DHCP(udp), www(tcp), Paquetes de Conexiones Abiertas Log y Rechazar Permitimos tráfico DNS e ICMP ("inofensivo"), WWW (nuestro nodo puede mostrar información de interés), y DHCP (necesario para el funcionamiento de MadridWireless)
NODO eth1 Todo Permitimos todo el trafico saliente del nodo hacia MadridWireless
ppp0 ppp0 NODO DNS(udp), ICMP, auth(tcp), Paquetes de Conexiones Abiertas Log y Rechazar Permitimos tráfico DNS e ICMP ("inofensivo") y AUTH (algunos servidores FTP se empeñan en saber quien les llama ;-)
NODO ppp0 Todo Permitimos todo el trafico saliente del nodo hacia Internet
La Tabla 2> es la que se usará para la clasificación del tráfico desde y hacia el nodo. En el marco de IPTABLES, esto se traducirá en la utilización de las cadenas INPUT y OUTPUT, como veremos en la siguiente sección. Esta es precisamente la principal diferencia entre el esquema IPCHAINS, utilizado en versiones del kernel 2.2.x y NetFilter, de la serie 2.4.x: en IPCHAINS los paquetes que no iban dirigidos al nodo pasaban por las cadenas INPUT, FORWARD y OUTPUT, en ese orden; en NetFilter los paquetes no dirigidos al nodo únicamente pasan por la cadena FORWARD, y las cadenas INPUT y OUTPUT se reservan de forma exclusiva para el tráfico que involucra al firewall.
Debe quedar claro que las tablas presentadas aquí son a modo de ejemplo, y deben ser personalizadas al máximo hasta conseguir que el nodo sea lo más seguro posible frente a accesos no deseados. Para más información sobre la configuración de NetFilter, deberá consultarse la referencia dada en el índice de este documento al respecto.
Generación de políticas y reglas de filtrado de paquetes
Para comprender los pasos que se indican a continuación es bastante recomendable haber leido algún documento general sobre el funcionamiento de NetFilter, aunque se intentará explicar cada regla con todo el detalle posible. Como introducción, diremos que en NetFilter los paquetes pasan por una serie de tablas, y dentro de las tablas, a su vez por un conjunto de cadenas, en orden. Las tablas predefinidas son filter, nat y mangle, de las cuales las más importantes y usadas son las dos primeras. Dentro de la tabla filter, se usarán las cadenas INPUT y OUTPUT (que filtran el tráfico cuya dirección de origen o de destino es el firewall) y FORWARD (que filtra el tráfico que debe enrutarse de una interfaz a otra). Y dentro de la tabla nat, se usará la cadena POSTROUTING (que es la que permite activar el enmascaramiento).
Dentro de cada cadena se puede definir una serie de reglas, contra las que se comparará cada paquete que pase por esa cadena, y las acciones a tomar en caso de que el paquete se ajuste al definido en la regla. Como parte de la cadena, se define una política, que es la que decide qué se hace con un paquete que ha pasado por dicha cadena, pero no ha coincidido con ninguna regla.
Una vez identificadas las interfaces y clasificados los tipos de tráfico que se permitirán y bloquearán entre ellas mediante las tablas que se han preparado en el apartado anterior, la generación de las reglas para NetFilter es inmediata. A continuación se incluirán los elementos de las tablas anteriores, por partes, junto con las reglas NetFilter que se generarán para ellas.
Es necesario comenzar limpiando todas las tablas de las reglas que hubiese anteriormente. Esto se consigue con los siguientes comandos:
iptables -t filter -F
iptables -t nat -F
iptables -t mangle -F
Lo primero que se definirán son las políticas por defecto que se usarán en las cadenas: rechazo (REJECT) en las cadenas INPUT y FORWARD, y aceptar (ACCEPT) en la cadena OUTPUT. Este tipo de política es la más común en los firewalls ("descartar todo lo que no se ajuste a alguna de las reglas explícitas"). Estas políticas se activan con las siguientes reglas:
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT
A continuación, las regas para el tráfico entre eth0 y ppp0:
Tabla 3.
Interfaces Origen Destino Permitido Resto Notas
eth0-ppp0 eth0 ppp0 Todo Permitimos todo el tráfico de salida desde la red privada hacia Internet
ppp0 eth0 Paquetes de Conexiones Abiertas Log y Rechazar Rechazamos todo lo que venga de Internet, salvo los paquetes de vuelta pertenecientes a conexiones establecidas
Esto se consigue mediante las siguientes reglas:
iptables -t filter -A FORWARD -i eth0 -o ppp0 -j ACCEPT
iptables -t filter -A FORWARD -i ppp0 -o eth0 -p tcp ! --syn -j ACCEPT
Merece especial atención la segunda regla, por la forma en que se especifica la condición "Paquetes de Conexiones Abiertas": esto se traduce en paquetes TCP que no tengan el bit SYN activado (este es el bit que indica una solicitud de conexión). Con esto se permite que los paquetes de vuelta de conexiones iniciadas desde la red en eth0 lleguen a su destino, pero no se permite que se inicien conexiones hacia la red eth0, que es lo que se pretende.
Para los paquetes entre eth1 y ppp0, y entre eth0 y eth1, las reglas son idénticas, así que no incluiremos aquí la parte correspondiente de la tabla, simplemente las reglas:
iptables -t filter -A FORWARD -i eth0 -o eth1 -j ACCEPT
iptables -t filter -A FORWARD -i eth1 -o eth0 -p tcp ! --syn -j ACCEPT
iptables -t filter -A FORWARD -i eth1 -o ppp0 -j ACCEPT
iptables -t filter -A FORWARD -i ppp0 -o eth1 -p tcp ! --syn -j ACCEPT
Para finalizar con la cadena FORWARD, se añadirá la regla necesaria para que cualquier paquete que no haya sido captado por ninguna de las reglas anteriores, sea anotado en el log del sistema, antes de ser rechazado por la política de la cadena:
iptables -t filter -A FORWARD -j LOG
A continuación, se crearán las reglas necesarias para las cadenas INPUT y OUTPUT, que son las que rigen el tráfico que involucra directamente al firewall.
Entre la interfaz eth0 y el nodo:
Tabla 4.
Interfaz Origen Destino Permitido Resto Notas
eth0 eth0 NODO Todo Permitimos todo el tráfico entrante y saliente entre la red privada y el nodo. Suponemos que es una red fiable.
NODO eth0 Todo
La primera regla es muy sencilla; ni siquiera hay que preocuparse de la cadena OUTPUT, ya que la política por defecto en esta cadena es dejar pasar el tráfico. Así que solo hay que añadir la siguiente regla:
iptables -t filter -A INPUT -i eth0 -j ACCEPT
Entre la interfaz eth1 y el nodo:
Tabla 5.
Interfaz Origen Destino Permitido Resto Notas
eth1 eth1 NODO DNS(udp), ICMP, DHCP(udp), www(tcp), Paquetes de Conexiones Abiertas Log y Rechazar Permitimos tráfico DNS e ICMP ("inofensivo"), WWW (nuestro nodo puede mostrar información de interés), y DHCP (necesario para el funcionamiento de MadridWireless)
NODO eth1 Todo Permitimos todo el trafico saliente del nodo hacia MadridWireless
Las reglas generadas para esta parte son las siguientes:
iptables -t filter -A INPUT -i eth1 -p tcp ! --syn -j ACCEPT
iptables -t filter -A INPUT -i eth1 -p tcp --dport www --syn -j ACCEPT
iptables -t filter -A INPUT -i eth1 -p udp --dport domain -j ACCEPT
iptables -t filter -A INPUT -i eth1 -p udp -s 0.0.0.0 --sport bootpc \
-d 255.255.255.255 --dport bootps -j ACCEPT
iptables -t filter -A INPUT -i eth1 -p icmp -j ACCEPT
Con la primera de ellas permitimos los paquetes de conexiones TCP ya abiertas. La segunda es la que permite que nuestro nodo ofrezca servicio Web. La tercera es la que permite el tráfico DNS. La cuarta es la más crítica, ya que permite que el nodo reciba paquetes DHCP - paquetes con direccion origen 0.0.0.0 y puerto origen el del cliente BOOTP (bootpc - 68), y con direccion de destino 255.255.255.255 y puerto de destino el del servidor BOOTP (bootps - 67) -. Finalmente, la última de ellas es la que permite que el nodo reciba paquetes ICMP.
De nuevo, no es necesario activar ninguna regla para la cadena OUTPUT, con motivo de la política que está activa en dicha cadena.
Y finalmente, para las comunicaciones entre el nodo e Internet:
Tabla 6.
Interfaz Origen Destino Permitido Resto Notas
ppp0 ppp0 NODO DNS(udp), ICMP, auth(tcp), Paquetes de Conexiones Abiertas Log y Rechazar Permitimos tráfico DNS e ICMP ("inofensivo") y AUTH (algunos servidores FTP se empeñan en saber quien les llama ;-)
NODO ppp0 Todo Permitimos todo el trafico saliente del nodo hacia Internet
Las reglas generadas aquí son las siguientes:
iptables -t filter -A INPUT -i ppp0 -p tcp ! --syn -j ACCEPT
iptables -t filter -A INPUT -i ppp0 -p tcp --dport auth --syn -j ACCEPT
iptables -t filter -A INPUT -i ppp0 -p udp --sport domain -j ACCEPT
iptables -t filter -A INPUT -i ppp0 -p icmp -j ACCEPT
Con la primera de ellas, al igual que en la tabla anterior, se permiten el tráfico correspondiente a conexiones TCP ya abiertas. La segunda de ellas es la que permite las conexiones AUTH al nodo (este tipo de conexiones son efectuadas a veces por sistemas remotos en respuesta a intentos de conexión, y en caso de no ser permitidas provocan a veces retrasos en las conexiones y ocasionalmente fallos. Para evitarlo, es sencillo abrir este tipo de conexiones, y tener activado un servidor AUTH que no proporcione información al exterior). La tercera permite el tráfico DNS de entrada, es decir, las respuestas a las consultas DNS que haga el nodo. Finalmente, la cuarta permite el tráfico ICMP.
Una vez más no es necesario activar ninguna regla para permitir el tráfico en la cadena OUTPUT, por el motivo descrito antes.
Para finalizar con la cadena INPUT, también se añadirá una regla para anotar en el log cualquier paquete no captado por ninguna de las reglas anteriores, antes de ser rechazado por la política:
iptables -t filter -A INPUT -j LOG
Y como último paso, una vez activados todos los filtros de tráfico necesarios en los pasos anteriores, es necesario activarel enmascaramiento, para que todas las conexiones con destino a Internet y que hayan pasado los filtros anteriores puedan establecerse con normalidad:
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Se incluye a continuación un único listado completo de todas las reglas creadas para la configuración del firewall en el nodo:
# limpieza de reglas anteriores
iptables -t filter -F
iptables -t nat -F
iptables -t mangle -F
# establecimiento de politicas por defecto
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT
# paquetes de entrada al nodo
iptables -t filter -A INPUT -i eth0 -j ACCEPT
iptables -t filter -A INPUT -i eth1 -p tcp --dport www --syn -j ACCEPT
iptables -t filter -A INPUT -i eth1 -p tcp ! --syn -j ACCEPT
iptables -t filter -A INPUT -i eth1 -p udp --dport domain -j ACCEPT
iptables -t filter -A INPUT -i eth1 -p udp -s 0.0.0.0 --sport bootpc \
-d 255.255.255.255 --dport bootps -j ACCEPT
iptables -t filter -A INPUT -i eth1 -p icmp -j ACCEPT
iptables -t filter -A INPUT -i ppp0 -p tcp ! --syn -j ACCEPT
iptables -t filter -A INPUT -i ppp0 -p tcp --dport auth --syn -j ACCEPT
iptables -t filter -A INPUT -i ppp0 -p udp --sport domain -j ACCEPT
iptables -t filter -A INPUT -i ppp0 -p icmp -j ACCEPT
iptables -t filter -A INPUT -j LOG
# filtrado entre redes
iptables -t filter -A FORWARD -i eth0 -o ppp0 -j ACCEPT
iptables -t filter -A FORWARD -i ppp0 -o eth0 -p tcp ! --syn -j ACCEPT
iptables -t filter -A FORWARD -i eth0 -o eth1 -j ACCEPT
iptables -t filter -A FORWARD -i eth1 -o eth0 -p tcp ! --syn -j ACCEPT
iptables -t filter -A FORWARD -i eth1 -o ppp0 -j ACCEPT
iptables -t filter -A FORWARD -i ppp0 -o eth1 -p tcp ! --syn -j ACCEPT
iptables -t filter -A FORWARD -j LOG
# activacion del enmascaramiento
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Estas reglas deberán ser incluidas en alguno de los scripts de inicio del sistema, de forma que sean ejecutadas automáticamente en el arranque del nodo. Un sitio razonable puede ser al final del fichero /etc/rc.d/rc.local, en RedHat. En otras distribuciones hay scripts con funcionalidad similar donde pueden incluirse.
------------------------------------------------------------------------------
Saludos Horacio