de 2000 Linux 2.4 NAT COMO

de 2000 Linux 2.4 NAT COMO
Rusty Russell, lista de correo [email protected]
Traducido por Ricardo J. C�rdenes Medina [email protected]
v1.0.1 Lunes 1 de Mayo 18:38:22 CST 2000, traducci�n del 25
de Junio

Este documento describe c�mo hacer el enmascarado (masqueradinq),
proxy transparente, reenv�o de puertos (port forwarding), y otras for�
mas de Network Address Translation (Traducci�n de Direcciones de Red)
con los n�cleos 2.4 de Linux.
______________________________________________________________________

�ndice general

1. Introducci�n
2. �D�nde est� el sitio web oficial y la lista?
2.1 �Qu� es Network Address Translation?
2.2 Razones para usar NAT

3. Los dos tipos de NAT
4. Puesta al d�a r�pida con respecto a los n�cleos 2.0 y 2.2
4.1 �S�lo quiero enmascarar! �Ayuda!

5. �Qu� pasa con ipmasqadm?
6. Controlar qu� cosas pasar por NAT
6.1 Selecci�n sencilla usando iptables
6.2 Opciones m�s refinadas de selecci�n de paquetes a toquetear.

7. C�mo modificar los paquetes
7.1 Source NAT (Cambio de Origen)
7.1.1 Enmascaramiento
7.2 Destination NAT (Cambio de destino)
7.2.1 Redirecci�n
7.3 Correspondencias (mappings) en profundidad
7.3.1 Selecci�n de m�ltiples direcciones de un rango dado
7.3.2 Crear correspondencias NAT nulas
7.3.3 Comportamiento NAT est�ndar
7.3.4 Correspondencia impl�cita del puerto de origen
7.3.5 Qu� sucede cuando NAT falla
7.3.6 M�ltiples correspondencias (mappings), solapado y colisiones
7.3.7 Alterar el destino de conexiones generadas de forma local

8. Protocolos especiales
9. Defectos del NAT
10. Agradecimientos

______________________________________________________________________

1. Introducci�n

Bienvenido, gentil lector.

Est� a punto de sumergirse en el fascinante (y a veces horrendo) mundo
del NAT (Network Address Translation), y este COMO va a ser su gu�a
m�s o menos precisa para el n�cleo 2.4 de Linux y posteriores.

En Linux 2.4, se ha introducido una infrastuctura para trastear con
los paquetes, llamada �netfilter�. Hay una capa por encima que
proporciona NAT, completamente reescrita con respecto a anteriores
n�cleos.

2. �D�nde est� el sitio web oficial y la lista?

Hay tres sitios oficiales:

� Gracias a Penguin Computing:
http://antarctica.penguincomputing.com/~netfilter/.

� Gracias a el equipo Samba y a SGI http://www.samba.org/netfilter.

� Gracias a Jim Pick http://netfilter.kernelnotes.org.

La lista oficial de correo de netfilter est� en el servidor de listas
de Samba: http://lists.samba.org

2.1. �Qu� es Network Address Translation?

Normalmente, los paquetes viajan en una red desde su origen (por
ejemplo su ordenador) a su destino (como por ejemplo
www.kernelnotes.org) a trav�s de varios enlaces diferentes: unos 19
desde donde yo estoy en Australia (esto lo dice Rusty, claro). Ninguno
de estos enlaces altera realmente el paquete: simplemente lo env�an un
paso adelante.

Si uno de estos enlaces hiciera NAT, podr�a alterar el origen o
destino del paquete seg�n pasa a trav�s suyo. Como puede imaginar,
�sta no es la funci�n para la que se dise el sistema, y por tanto NAT
es siempre un tanto enrevesado. Normalmente, el enlace que est�
haciendo NAT recordar� c�mo juguete� con el paquete, para hacer la
acci�n inversa con el paquete de respuesta, de manera que todo
funciona como se esperaba.

2.2. Razones para usar NAT

En un mundo perfecto, no deber�a. Mientras tanto, las razones
principales son:

Conexiones con m�dem a Internet
La mayor�a de los PSI (Proveedor de Servicios de Internet) le
dan una sola direcci�n IP cuando se conecta con ellos. Puede
enviar paquetes con cualquier direcci�n que le plazca, pero s�lo
obtendr� respuestas a los paquetes con esa IP de origen. Si
desea utilizar varias m�quinas diferentes (como una red casera)
para conectar a Internet a trav�s de un enlace, necesita NAT.

Este es, de lejos, el uso m�s com�n de NAT hoy en d�a, conocido
normalmente como �enmascaramiendo� (masquerading) en el mundo de
Linux. Yo lo llamo SNAT, porque se cambia la direcci�n de origen
(source) del primer paquete.

Varios servidores
Puede que quiera cambiar el destino de los paquetes que entran
en su red. Con frecuencia esto se debe (como antes), a que s�lo
tiene una direcci�n IP, pero desea que la gente sea capaz de
llegar a las m�quinas detr�s de la que tiene la IP �real�. Si
reescribe el destino de los paquetes entrantes, podr�
conseguirlo.

Una variante com�n de esto es el balanceo de carga, en la cual
se toma un cierto n�mero de m�quinas, repartiendo los paquetes
entre ellas. Este tipo de NAT se llam� reenv�o de puerto (port-
forwarding) en anteriores versiones de Linux.

Proxy transparente
Hay veces que desear� simular que cada paquete que pase por su
m�quina Linux est� destinado a un programa en la propia m�quina.
Esto se utiliza para hacer proxyes transparentes: un proxy es un
programa que se pone entre su red y el mundo real, filtrando las
comunicaciones entre ambos. La parte transparente se debe a que
su red nunca tendr� por qu� enterarse de que est� comunic�ndose
con un proxy, a menos, claro, que el proxy no funciones.

Se puede configurar Squid para que trabaje de esta manera, y a
esto se le llam� redirecci�n o proxy transparente en anteriores
versiones de Linux.

3. Los dos tipos de NAT

Yo divido NAT en dos diferentes tipos: Source NAT (SNAT, por origen),
y Destination NAT (DNAT, por destino).

Source NAT es cuando alteramos el origen del primer paquete: esto es,
estamos cambiando el lugar de donde viene la conexi�n. Source NAT
siempre se hace despu�s del encaminamiento, justo antes de que el
paquete salga por el cable. El enmascaramiento es una forma
especializada de SNAT.

Destination NAT es cuando alteramos la direcci�n de destino del primer
paquete: esto es, cambiamos la direcci�n a donde se dirige la
conexi�n. DNAT siempre se hace antes del encaminamiento, cuando el
paquete entra por el cable. El port forwarding (reenv�o de puerto), el
balanceo de carga y el proxy transparente son formas de DNAT.

4. Puesta al d�a r�pida con respecto a los n�cleos 2.0 y 2.2

Lo siento por aquellos que todav�a est�n aturdidos por la transici�n
desde 2.0 (ipfwadm) a 2.2 (ipchains). Hay buenas y malas noticias.

Primero, puede seguir usando ipchains o ipfwadm como antes. Para
hacerlo, necesita cargar los m�dulos del n�cleo �ipchains.o� o
�ipfwadm.o� que encontrar� en la �ltima distribuci�n de netfilter. Son
mutuamente exclusivos (est� advertido), y no deber�an combinarse con
ning�n otro m�dulo de netfilter.

Una vez haya instalado uno de estos m�dulos puede utilizar ipchains e
ipfwadm con normalidad, excepto por las siguientes diferencias:

� Establecer los tiempos l�mite (timeout) con ipchains -M -S o
ipfwadm -M -s no hace nada. Como los l�mites de tiempo con la nueva
infrastructura NAT son m�s grandes, no deber�a haber problema.

� Los campos init_seq, delta y previous_delta en la lista ampliada de
enmascaramiento (verbose masquerade listing) siempre son 0.

� Listar los contadores y ponerlos a cero al mismo tiempo �-Z -L� ya
no funciona: los contadores no se pondr�n a cero.

Los hackers tambi�n se dar�n cuenta de que:

� Ahora puede asociar un programa (bind) a los puertos 61000-65095
incluso si est� haciendo enmascaramiento. El c�digo de enmascarado
asum�a que no hab�a nada en este rango, de manera que los programas
no lo pod�an usar.

� El parche (no documentado) de �getsockname�, que pod�an utilizar
los programas de proxy transparente para averiguar el destino real
de la conexi�n no funciona.

� El parche (no documentado) bind-to-foreign-address (asociado-a-una-
direcci�n-externa) tampoco est� implementado; se usaba para
completar la ilusi�n del proxy transparente.

4.1. �S�lo quiero enmascarar! �Ayuda!

Esto es lo que la mayor�a de la gente quiere. Si tengo una conexi�n
PPP con IP din�mica (si no sabe lo que es, entonces tiene una),
simplemente querr� decirle a mi m�quina que todos los paquetes que
vengan de la red interna deber�an aparentar venir de la m�quina que
tiene el enlace PPP.

# Cargue el m�dulo NAT (esto carga tambi�n los otros).
modprobe iptable_nat

# Agrega (-A) una regla a la tabla NAT (-t nat), despu�s del
# encaminamiento (POSTROUTING) para todos los paquetes que salgan por
# ppp0 (-o ppp0) enmascarando la conexi�n (-j MASQUERADE).
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

# Ponga en marcha el reenv�o de IP (IP forwarding)
echo 1 > /proc/sys/net/ipv4/ip_forward

F�jese que no est� haciendo filtrado de paquetes: para eso, lea el
COMO de Filtrado de Paquetes: �Mezclando NAT con Filtrado de
Paquetes�.

5. �Qu� pasa con ipmasqadm?

Este programa tiene un nicho de usuarios mucho m�s definido, de manera
que no me he preocupado mucho de darle compatibilidad retroactiva.
Puede usar �iptables -t nat� para hacer reenv�o de puertos. De manera
que, por ejemplo, en Linux 2.2 podr�a haber hecho:

#Linux 2.2
#Reenv�a los paquetes TCP dirigidos al puerto 8080 de 1.2.3.4 al 80 de
#192.168.1.1
ipmasqadm portfw -a -P tcp -L 1.2.3.4 8080 -R 192.168.1.1 80

Ahora deber�a hacer:

# Linux 2.4
# Agrega una regla previa al encaminamiento (-A PREROUTING) a la tabla NAT
# (-t nat) de manera que los paquetes TCP (-p tcp) que vayan a 1.2.3.4
# (-d 1.2.3.4), puerto 8080 (--dport 8080) tengan una correspondencia de
# destino (-j DNAT) con 192.168.1.1, puerto 80 (--to 192.168.1.1:80).
iptables -A PREROUTING -t nat -p tcp -d 1.2.3.4 --dport 8080 \
-j DNAT --to 192.168.1.1:80

Si desea que esta regla altere tambi�n las conexiones locales
(aquellas que se originen en la propia m�quina que hace NAT), puede
insertar la misma regla en la cadena OUTPUT (que es para los paquetes
locales de salida):

# Linux 2.4
iptables -A OUTPUT -t nat -p tcp -d 1.2.3.4 --dport 8080 \
-j DNAT --to 192.168.1.1:80

6. Controlar qu� cosas pasar por NAT

Necesita crear reglas NAT que le digan al n�cleo qu� conexiones
cambiar, y c�mo hacerlo. Para ello, usaremos la muy vers�til
herramienta iptables, y le diremos que altere la tabla de NAT usando
la opci�n �-t nat�.

La tabla de reglas NAT contiene tres listas llamadas �cadenas�: cada
regla se examina por orden hasta que una coincide. Las tres cadenas se
llaman PREROUTING (para Destination NAT, seg�n los paquetes entran),
POSTROUTING (para SOURCE NAT, seg�n los paquetes salen), y OUTPUT
(para Destination NAT con los paquetes generados en la propia
m�quina).

El siguiente diagrama lo ilustrar�a bastante bien si yo tuviese algo
de talento art�stico:

_____ _____
/ \ / \
PREROUTING -->[Decisi�n de ]----------------->POSTROUTING----->
\D-NAT/ [Encaminamiento] \S-NAT/
| ^
| __|__
| / \
| | OUTPUT|
| \D-NAT/
| ^
| |
----------> Proceso Local ----------

En cada uno de los puntos anteriores, cuando un paquete pasa miramos
la conexi�n a la que est� asociado. Si es una conexi�n nueva,
comprobamos la cadena correspondiente en la tabla de NAT para ver qu�
hacer con ella. La respuesta que obtenemos se aplicar� a cualquier
paquete posterior de esa conexi�n.
6.1. Selecci�n sencilla usando iptables

iptables toma cierto n�mero de decisiones est�ndar que se listar�n
ahora. Todas las opciones con doble gui�n pueden ser abreviadas,
siempre que iptables pueda distinguirlas de otras opciones posibles.
Si el n�cleo tiene la implementaci�n de iptables como m�dulo,
necesitar� cargar el m�dulo ip_tables.o antes: �insmod ip_tables�.

La opci�n m�s importante aqu� es la opci�n de selecci�n de tabla,
�-t�. Para todas las operaciones de NAT, querr� usar �-t nat� para la
tabla NAT. La segunda m�s importante es �-A� para a�adir una nueva
regla al final de una cadena (�-A POSTROUTING�), o �-I� para
insertarla al principio (�-I PREROUTING�).

Puede especificar el origen (�-s� o �--source�) y el destino (�-d� o
�--destination�) de los paquetes sobre los que quiere hacer NAT. Estas
opciones pueden ir seguidas por una IP sencilla (192.168.1.1), un
nombre (www.kernelnotes.org), o una direcci�n de red (192.168.1.0/24 o
192.168.1.0/255.255.255.0).

Puede especificar qu� interfaz de entrada (�-i� o �--in-interface�) o
de salida (�-o� o �--out-interface�) mirar, pero lo que puede
especificar depende de en qu� cadena est� poniendo la regla: en
PREROUTING s�lo puede elegir la interfaz de entrada, y en POSTROUTING
(y OUTPUT) s�lo la de salida. Si usa la equivocada, iptables le
avisar� con un mensaje de error.

6.2. Opciones m�s refinadas de selecci�n de paquetes a toquetear.

Dije antes que se puede especificar una direcci�n de origen y destino.
Si omite la opci�n de origen, entonces ser� cualquier direcci�n de
origen. Si omite la de destino, ser� cualquier direcci�n de destino.

Tambi�n puede indicar un protocolo espec�fico (�-p� o �--protocol�),
como TCP o UDP; s�lo los paquetes de este protocolo coincidir�n con la
regla. La raz�n principal para hacer esto es que especificar uno de
los protocolos tcp o udp permite m�s opciones: espec�ficamente las
opciones �--source-port� y �--destination-port� (abreviadas �--sport�
y �--dport�).

Estas opciones le permiten especificar que s�lo los paquetes con un
determinado origen y destino coincidir�n con la regla. Esto es �til
para redireccionar peticiones web (puertos TCP 80 u 8080) y dejar los
dem�s paquetes tranquilos.

Estas opciones deben seguir a la �-p� (que tiene el efecto secundario
de cargar la biblioteca compartida de extensi�n para ese protocolo).
Puede usar n�meros de puerto, o un nombre de fichero /etc/services.

Todos los diferentes par�metros por los que se puede seleccionar un
paquete vienen enumerados con toda clase de dolorosos detalles en la
p�gina de manual (man iptables).

7. C�mo modificar los paquetes

De manera que ahora sabemos c�mo elegir los paquetes que queremos
modificar. Para completar nuestra regla, necesitamos decirle al n�cleo
exactamente qu� queremos que haga con los paquetes.

7.1. Source NAT (Cambio de Origen)

Quiere hacer Source NAT; cambiar la direcci�n de origen de las
conexiones a algo diferente. Esto se hace en la cadena POSTROUTING,
justo antes de que sea enviado. Este es un detalle importante, ya que
significa que cualquier otro servicio de la m�quina Linux
(encaminamiento, filtrado de paquetes) ver� el paquete sin cambiar.
Tambi�n significa que se puede utilizar la opci�n �-o� (interfaz de
salida).

El Source NAT se especifica indicando �-j SNAT�, y la opci�n �--to-
source� especifica una direcci�n IP, un rango de direcciones IP, y un
puerto o rango de puertos opcionales (s�lo con los protocolos UDP y
TCP).

## Cambiar la direcci�n de origen por 1.2.3.4
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4

## Cambiar la direcci�n de origen a 1.2.3.4, 1.2.3.5 o 1.2.3.6
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4-1.2.3.6

## Cambiar la direcci�n de origen por 1.2.3.4, puertos 1-1023
# iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to 1.2.3.4:1-1023

7.1.1. Enmascaramiento

Hay un caso especializado de Source NAT denominado �enmascaramiento�
(masquerading): s�lo deber�a ser usado para direcciones IP asignadas
de forma din�mica, tales como las de conexiones por llamada est�ndar
(para direcciones IP est�ticas, utilize el SNAT descrito
anteriormente).

No es necesario escribir la direcci�n de origen de forma expl�cita con
el enmascaramiento: utilizar� la direcci�n de origen de la interfaz
por la que el paquete est� saliendo. Pero m�s importante a�n, si el
enlace cae, las conexiones (que se iban a perder de todas maneras) se
olvidan, lo que significa que habr� menos foll�n cuando la conexi�n
vuelva a la normalidad con una IP diferente.

## Enmascarar todo lo que salga por ppp0.
# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

7.2. Destination NAT (Cambio de destino)

Esto se hace en la cadena PREROUTING, seg�n entra el paquete; esto
significa que cualquier otro servicio de la m�quina con Linux
(encaminamiento, filtrado de paquetes) ver� el paquete yendo a su
destino �real� (el definitivo). Esto significa que se puede utilizar
la opci�n �-i� (interfaz de entrada).

Para alterar el destino de un paquete generado de forma local (en la
m�quina que hace el NAT), se debe usar la cadena OUTPUT, pero esto es
m�s inusual.

Destination NAT se especifica utilizando �-j DNAT�, y la opci�n �--to-
destination� especifica una direcci�n IP, un rango de direcciones IP,
y un puerto o rango de puertos opcionales (s�lo para los protocolos
UDP y TCP).
## Cambia la direcci�n de destino por 5.6.7.8
# iptables -t nat -A PREROUTING -i eth1 -j DNAT --to 5.6.7.8

## Cambia la direcci�n de destino por 5.6.7.8, 5.6.7.9 o 5.6.7.10.
# iptables -t nat -A PREROUTING -i eth1 -j DNAT --to 5.6.7.8-5.6.7.10

## Cambia la direcci�n de destino del tr�fico web por 5.6.7.8,
## puerto 8080.
# iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 \
-j DNAT --to 5.6.7.8:8080

## Redirige los paquetes locales que van a 1.2.3.4 hacia el dispositivo
## loopback.
# iptables -t nat -A OUTPUT -d 1.2.3.4 -j DNAT --to 127.0.0.1

7.2.1. Redirecci�n

Hay un caso especializado de Destination NAT llamado redirecci�n: es
una simple conveniencia que es exactamente lo mismo que hacer DNAT,
pero con la direcci�n de la interfaz de entrada.

## Env�a el tr�fico que entra dirigido al puerto 80 (web) a nuestro
## proxy squid (transparente)
# iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 \
-j REDIRECT --to-port 3128

7.3. Correspondencias (mappings) en profundidad

Hay algunas sutilezas de NAT con las que la mayor�a de la gente no
tendr� que enfrentarse nunca. Las he documentado aqu� para los m�s
curiosos.

7.3.1. Selecci�n de m�ltiples direcciones de un rango dado

Si se da un rango de direcciones IP, la direcci�n a usar se elegir�
bas�ndose en la menos utilizada para las conexiones de las que sabe
nuestra m�quina. Esto nos permite hacer un balanceo de carga
primitivo.

7.3.2. Crear correspondencias NAT nulas

Puede utilizar el objetivo �-j ACCEPT� para dejar que una conexi�n
pase sin que se produzca ninguna conversi�n NAT.

7.3.3. Comportamiento NAT est�ndar

El comportamiento est�ndar es alterar la conexi�n lo menos posible,
dentro de los l�mites de la regla dada por el usuario. Esto significa
que no cambiaremos el puerto a menos que nos veamos obligados.

7.3.4. Correspondencia impl�cita del puerto de origen

Incluso cuando no se pide NAT para una conexi�n, puede ser que haya un
cambio de puerto de forma impl�cita, si otra conexi�n lo est� usando
ya. Consideremos el caso del enmascaramiento, que es lo m�s com�n:

1. Se establece una conexi�n web entre la m�quina 192.1.1.1, puerto
1024 y www.netscape.com, puerto 80.

2. Esta conexi�n es enmascarada por otra m�quina para que utilice su
direcci�n como origen (1.2.3.4).

3. La m�quina enmascaradora intenta hacer la conexi�n web con
www.netscape.com puerto 80, desde 1.2.3.4 (la direcci�n de su
interfaz interna), puerto 1024.

4. El c�digo de NAT alterar� la direcci�n de origen de una segunda
conexi�n al puerto 1025, de manera que no pueda haber solapado.

Cuando se produce este cambio impl�cito de origen, los puertos se
dividen en tres clases:

� Puertos por debajo del 512.

� Puertos entre el 512 y el 1023 (inclusive).

� Puertos 1024 y superiores.

Nunca se har� corresponder un puerto con otro de clase diferente.

7.3.5. Qu� sucede cuando NAT falla

Si no hay manera de hacer corresponder una conexi�n de forma �nica tal
como ha pedido el usuario, ser� descartada. Esto se aplica tambi�n a
los paquetes que no pueden ser clasificados como parte de una
conexi�n, porque est�n malformados, o nos hemos quedado sin memoria,
etc.

7.3.6. M�ltiples correspondencias (mappings), solapado y colisiones

Podemos tener reglas NAT que asignen paquetes dentro del mismo rango.
El c�digo NAT es suficientemente inteligente para evitar colisiones.
Por tanto, tener dos reglas que hagan corresponder las direcciones de
origen 192.168.1.1 y 192.168.1.2 respectivamente con 1.2.3.4 es
correcto.

A�n m�s, se pueden hacer correspondencias sobre direcciones reales y
en uso, siempre y cu�ndo estas direcciones pasen tambi�n a trav�s de
nuestra m�quina. De manera que si tenemos una red asignada
(1.2.3.0/24), pero tenemos una red interna que est� usando esas
direcciones y otra con Direcciones Privadas de Internet
192.168.1.0./24, podemos hacer NAT con las direcciones de origen
192.168.1.0/24 dentro del rango de la red 1.2.3.0, sin temor a
colisiones:

# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 \
-j SNAT --to 1.2.3.0/24

La misma l�gica se aplica a las direcciones que usa la propia caja que
hace NAT: �sta es la manera en que funciona el enmascaramiento
(compartiendo las direcciones de la interfaz entre los paquetes
enmascarados y los paquetes �reales� que vienen de la propia m�quina).

A�n m�s, podemos direccionar los mismos paquetes a varios objetivos
diferentes, y ser�n compartidos. Por ejemplo, si no queremos
direccionar nada usando 1.2.3.5, podr�amos hacer:

# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 \
-j SNAT --to 1.2.3.0-1.2.3.4 --to 1.2.3.6-1.2.3.254

7.3.7. Alterar el destino de conexiones generadas de forma local

Si se cambia el destino de un paquete generado de forma local (esto
es, usando la cadena OUTPUT), y eso hace que el paquete salte a una
interfaz diferente, entonces se cambia tambi�n la direcci�n de origen
a la de esa interfaz. Por ejemplo, cambiar el destino de un paquete de
loopback para que salga por eth0 tendr� como resultado que tambi�n se
cambie la direcci�n de origen, 127.0.0.1, por la de eth0. Al contrario
que con el resto de cambios, esto se hace de forma inmediata.
Naturalmente, ambos cambios son invertidos cuando llega la respuesta
del paquete.

8. Protocolos especiales

A algunos protocolos no les gusta pasar por NAT. Se deben escribir dos
extensiones para cada uno de ellos; uno para el seguimiento de las
conexiones de ese protocolo, y otro para el propio NAT.

Junto con la distribuci�n de netfilter, hay m�dulos para el ftp:
ip_conntrack_ftp.o e ip_nat_ftp.o. Si inserta estos m�dulos en el
n�cleo (o los compila de forma permanente), entonces podr� hacer NAT
sobre conexiones FTP. Si no lo hace, entonces s�lo podr� utilizar FTP
pasivo, e incluso eso no ser� del todo fiable si hace algo m�s que un
sencillo Source Nat.

9. Defectos del NAT

Si hace NAT sobre una conexi�n, todos los paquetes que pasen en ambas
direcciones (dentro y fuera de la red) deber�n hacerlo a trav�s de la
m�quina que hace NAT, ya que si no, no funcionar� de forma fiable. En
particular, el c�digo de seguimiento de conexiones ensambla los
fragmentos, lo que significa que no s�lo la conexi�n no ser� fiable,
sino que los paquetes pueden terminar por no llegar, ya que los
fragmentos quedar�n retenidos.

10. Agradecimientos

Gracias antes que nada a WatchGuard, y a David Bonn, quien crey� en la
idea de netfilter lo suficiente para darme soporte mientras trabajaba
en ello.

Y al resto del mundo que soport� mis cabreos mientras aprend�a sobre
los horrores de NAT, especialmente a aquellos que leyeron mi diario.

Rusty.