Re: MTU para una LAN, fragmentar paquetes
2005-12-31 01:27 +0100, Iñaki <ibc2@euskalnet.net>:
> El Viernes, 30 de Diciembre de 2005 23:30, Gonzalo HIGUERA DÍAZ escribió:
> || > Después de comprobar los DNS's y demás se me ha ocurrido probar a
> || > reducir el MTU del interfaz LAN de 1500 a 1492 y ya funciona.
> || >
> || > El caso es que el router es una Debian con ADLS por ppp0 con MTU 1492
> || > (lo típico), y la LAN es eth1 con MTU 1500 (lo típico también). Pensaba
> || > que nunca habría ningún problema pues que yo sepa, si una máquina envía
> || > un paquete de un tamaño mayor al MTU de un tramo de la red, es el router
> || > correspondiente el que se encarga de fragmentar el paquete. Eso es al
> || > menos lo que hecho en muchos ejercicios teóricos en la universidad.
> ||
> || Correcto en cuanto a la teoría, pero en la práctica una máquina puede
> || estar mal configurada. Supón que una de las webs esté detrás de un
> || cortafuegos que sólo debe dejar pasar tráfico TCP dirigido al puerto
> || 80. Una traducción de dicha regla que no tenga en cuenta la
> || fragmentación en una máquina basada en iptables de Linux llevaría a
> || descartar todos los fragmentos, por no llevar cabecera TCP (como se
> || explica en el packet-filtering-HOWTO.
>
> Pero no puede ser cosa del servidor web, no creo que el 75% de los servidores
> web impidan el paso de paquetes fragmentados, ¿no?
Un porcentaje tan alto de fallo es clara señal de que el problema es
local, entendiéndose por local el tramo desde la máquina de pruebas
hasta donde se empieza a diversificar el tráfico. Por tanto, la
configuración de la red del ISP puede estar jugando un papel. Esto es
en cualquier caso puramente académico, ya que dudo que puedas influir
más allá del router Debian, así que mejor limitarse a ese tramo: desde
la máquina de pruebas hasta el router.
> || Esto también es aplicable a tu
> || router, sobre todo en las respuestas, y puede no ser por error sino
> || por eficiencia (con algo de mala uva si no se responde con un ICMP
> || "Destination Unreachable" con causa "4 = fragmentation needed and DF
> || set").
>
> Le doy vueltas y vueltas a esto que dices y no acabo de ver la luz
>
> No sé si lo dije anteriormente, pero antes de poner MTU=1492 a la red local,
> desde la Debian-Router SI que veía todas las páginas (lo probaba con Links),
> pero no así desde las máquinas locales (todos los Windows e incluso probé con
> un portátil con Debian y nada, no cargaban la mayoría de las páginas).
Normal, claro está, ya que el router veía una MTU de 1492 en el
interfaz de salida a Internet.
> Asumo que en la petición de una web el tráfico saliente es mínimo (como
> mencionas abajo), así que el problema es el entrante. Y de verdad que no
> puedo ni imaginarme dónde y porqué se atasca el asunto. Sólo se me ocurre que
> el servidor web responda con tramas que luego hay que fragmentar antes de
> llegar a mi router, y que mi router por alguna razón no permita el paso de
> paquetes fragmentados a mi red local. ¿Problema en mi Iptables?
Eso es lo que estaba sugiriendo. En principio también sería extensible
a la máquina de pruebas, pero como probaste con varias, parece que nos
podamos centrar en el router (sin descartar intervenciones por parte
de equipos que pudiera haber entre el extremo y el router).
> En mi iptables tenía:
>
> *filter
> :INPUT DROP [0:0]
> :FORWARD DROP [0:0]
> :OUTPUT DROP [0:0]
>
> -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -i ppp0 -p icmp -j icmp_packets
>
> -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
>
> -A icmp_packets -p icmp -m icmp --icmp-type 8 -j ACCEPT
> -A icmp_packets -p icmp -m icmp --icmp-type 11 -j ACCEPT
>
> El código 4 que comentas está en los ICMP de tipo 3, que yo no había incluido.
> ¿Podría ser la causa? yo creo que no, pero no estoy seguro.
Habiendo descartado el tráfico saliente, sabemos que el entrante se
puede fragmentar. Asociando el 1492 a la proliferación de accesos ADSL
mediante PPPoA, la necesidad de fragmentación se produce cuando lo
paquetes llegan a la red de aceso ADSL. Si se negasen a fragmentar,
enviarían el ICMP de tipo 3 a los servidores. Si más gente usa esa red
de acceso sin problemas ni configuraciones especiales, parece
razonable que ahí no esté el problema. Además, si impidesen la
fragmentación, tu equipo no tendría problemas con paquetes
fragmentados, así que parece que hay fragmentación.
Cuando un fragmento llega a tu router este puede decidir, que permite
el paso de fragmentos o bien que lanza un ICMP "fragmentation needed".
Por lo primero no conozco bien iptables, pero diría que con la regla
FORWARD que has puesto debería bastar, y por lo segundo, no se me
ocurre ninguna parte de Linux (e.g. net.ipv4.* de sysctl) que lo
permita, con lo que no lo veo como razón. Vamos, que con lo que hay,
no se me ocurre nada, menos aún sin la posibilidad de hacer pruebas
sobre el aparato, como habilitar el paso indiscriminado de fragmentos,
o ser más laxo con ICMP (tanto en INCOMING como en FORWARDING o en
OUTGOING). Siento haberme quedado falto de ideas.
> Si queréis puedo pegar todo el Iptables, es bastante cortito.
Adelante, por si se nos abre una luz a alguno, aunque espero que se te
encienda antes la bombilla y puedas contarnos la solución.
> PD: En cuanto al "packet-filtering-HOWTO" lo he buscado pero sólo lo encuentro
> en formato SGML, que puede que sea una revolución y lo que dios quiera, pero
> no sé cómo abrirlo, y si lo abro con un editor de texto es como ver el código
> HTML de una web y se hace dificil. ¿Alguien sabe dónde puedo conseguir ese
> documento en un formato más "normal" (incluso texto plano)?
El packet-filtering-HOWTO lo leo en mi Debian desde
"/usr/share/doc/iptables/html/". Respecto al SGML, es posible que sean
fuentes DocBook, en cuyo caso el paquete docbook-utils pueda serte de
ayuda.
--
Gonzalo HIGUERA DÍAZ <gonhidi@gmail.com>
Reply to: