Re: MTU para una LAN, fragmentar paquetes
Ante todo gracias por tu muy interesante respuesta.
El Viernes, 30 de Diciembre de 2005 23:30, Gonzalo HIGUERA DÍAZ escribió:
|| 2005-12-29 21:19 +0100, Iñaki <ibc2@euskalnet.net>:
|| > Hola, hoy he tenido el supongo que clásico problema de poder acceder
|| > desde ordenadores en una LAN a ciertas webs y no a otras.
||
|| Clásico problema con interesantes posibilidades. ¿Cuántas webs dan
|| problemas? Quizás la pregunta te permita acotar de primeras la fuente
|| del problema.
Digamos que fallaban más del 75%. Algunas incluso empezaban a cargarse pero se
detenían enseguida.
|| > 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?
|| 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).
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?
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.
|| > Pero lo que yo me pregunto es porqué razón no lo hace el router
|| > automáticamente sin decirle nada, ¿acaso no fragmenta los paquetes IP de
|| > tamaño superior transparentemente sin que la máquina origen se entere?
|| > pues anda que no lo he hecho veces en papel...
||
|| Debería fragmentarlos, pero habría que comprobarlo. No tengo equipo
|| para hacerlo, pero quizás el comparar el resultado de lanzar
|| "traceroute -M want" y "traceroute -M dont" te ayude a ver dónde está
|| el problema. Si no, quizás puedas mirar como funciona "tracepath" y
|| ver si es posible enviar un UDP de 1500 pero que la respuesta sea
|| pequeña, para así tratar de reducir la problemática del MTU sólo a la
|| ida (si no importase la vuelta, la serie "ping", "ping -s 1486" y
|| "ping -s 1500" debería dar la respuesta).
Desgraciadamente el problema se produjo en una oficina de un cliente y como
puse MTU 1492 lo dejé ya funcionando. Por desgracia puedo entrar por ssh al
router, pero a ningún equipo pues son todos Windows. Si algún día tengo que
ir de nuevo lo probaré (aunque tendré que llevar un portátil porque no me
apetece hacerlo desde la consola de Windows si es que dispone de esos
comandos...).
|| > Supongo que al hacer "ifconfig eth0 mtu 1492" estoy obligando a que los
|| > equipos de la LAN envíen tramas de tamaño máximo 1492, pero la cosa es
|| > que no debería ser así,
||
|| ¿Deber? No es algo necesario en IPv4, pero es una labor social que
|| retira trabajo a todos los equipos que tienen que manejar los
|| fragmentos (y de paso aumenta tu rendimiento visible) y que no está de
|| más aplicar. De hecho, la fragmentación es tan enojosa como para que
|| IPv6 no la soporte.
Pero lo que me preocupa es que en todos los Debian que he visto haciendo de
router con ADSL la configuración ha sido similar en cuanto a los interfaces:
Red Local Internet
eth1 --------- Debian/Router ----------- ppp0
MTU=1500 MTU=1492
En ningún caso estaba fijada la MTU a 1492 en la red local y funcionaban todas
las páginas. Lo único que no era igual era el iptables, y creo que lo
relevante del mío en este problema son las líneas que he puesto antes, pero
yo no detecto ningún problema:
*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
Impido el FORWARD salvo para conexiones ESTABLISHED o RELATED, y supongo que
si llega algún paquete fragmentado de vuelta podría pasar por esas reglas al
hacer el forwarding a mi máquina local, ¿no? ¿Veis algún error o carencia en
estas reglas?
Si queréis puedo pegar todo el Iptables, es bastante cortito.
Agradezco mucho tu ayuda, esto me tiene un poco preocupado.
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)?
--
y hasta aquí puedo leer...
Reply to: