Hola El 03/Jan/06 - 14:55, Iñaki dijo: > He encontrado el problema, y he descubierto que no había llegado a > solucionarlo, sólo fue casualidad y de hecho he tenido que ir hoy a dicha > oficina porque padecían los problemas de nuevo. > > Resulta ser un problema clásico en Internet. El problema es el siguiente: > > - La máquina A está detrás de un router en una red Ethernet (MTU 1500). > - El router/firewall hace PPPoE con el ISP de ADSL (MTU 1492) > - S es un servidor web que está en otra Lan (MTU 1500) detrás de un > router/firewall muy capullo. > - A quiere pedir una página a S, por lo que lo primero que hace es la conexión > TCP en la que informa a S de que la MTU de A es 1500 (es correcto, es la que > A ve). > - S también puede enviar con MTU 1500 así que envía paquetes IP de 1500 bytes > con la opción DF=1 (No Defragmentar). Todo esto es un protocolo para evitar > la fragmentación, pues no resulta eficiente. > - Cuando el paquete llega a mi ISP, éste no le deja pasar pues sólo permite > paquetes de 1492 bytes, ya que 8 bytes los necesita para el protocolo PPPoE. > - Así que el router de mi ISP envía a S un mensaje ICMP diciéndole > "fragmentation needed and DF set" e informando también del tamaño correcto > (1492). > - Pero resulta que el router/firewall que permite el acceso a S está > administrado por un incompetente paranoico que deniega el paso de mensajes > ICMP de éste tipo concreto (Tipo 3), así que el mensaje no llega a S. > - S no recibe respuesta ni confirmación de A así que le vuelve a mandar el > paquete del mismo tamaño y el problema vuelve a repetirse. > Según he leído, aparte de que haya muchos administradores paranoicos/incompetentes de firewalls, lo que causa el problema en un alto porcentaje de las veces, ocurre también que muchos router de los ISP's no implementan correctamente el 'protocolo' pmtud por lo que no envían las respuestas icmp de tipo 3 cuando deberían. Además, parece ser que incluso muchos router adsl domésticos tampoco lo hacen... con lo que lo tenemos mal... Coincído contigo cuando dices que internet apesta :-( > > La solución a éste problema sería permitir el paso de esos ICMP en el router > del servidor, pero aún purulan incompetentes que evitan esos mensajes > necesarios para la correcta comunicación por Internet. Otra solución sería desactivar el 'protocolo' pmtud. En linux es fácil (echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc). Así no se envíarían paquetes con el bit DF a 1 y los router lo fragmentarían. Lo que pasa es que para algo lo han inventado. La idea es buena (aunque depende de icmp) y por tanto está activado por defecto en todos los SSOO. Yo he probado a desactivarlo y algunas páginas que antes no abrían sí que lo hacen, pero sigue fallando en la mayoría de las veces puesto que el problema está casi siempre en "la vuelta", siendo necesario desactivarlo en el otro lado, y por tanto, en toda la internet para que fuera eficiente. No es solución :-( > Entonces hay que hacer la "ñapa" en la zona cliente, o sea, nuestro > router/firewall o nuestros clientes de la LAN. > [...] > - Una mejor solución es añadir una regla en el firewall del router que haga la > trampa: cuando A le quiere decir a S que su MTU es de 1500 el firewall > detecta ese paquete y modifica la cantidad a 1492, por lo que S recibe el > mensaje alterado y cree que A le dice que sólo permite 1492, así que actúa en > consecuencia y ya no hay problema. > > Añado que esta "ñapa" viene incluida en los routers que instalan las ISP. En > mi caso convertí el router en un modem y era una Debian la que hacía de > router y firewall con iptables, por lo tanto su responsabilidad la de hacer la > "ñapa". > > Cuando ejecuté "pppoeconf" recuerdo que me preguntó si quería transformar la > MTU en las conexiones salientes de los clientes de la LAN precisamente para > evitar este problema, y yo le dije que sí. > > Hoy he comprendido que lo que realmente hace es añadir esta regla a Iptables > cuando se levanta PPP: > > -A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss > 1400:1536 -j TCPMSS --clamp-mss-to-pmtu Alá!! qué bueno!! No sabía que pppoeconf hacía esto!!! La verdad es que yo estoy usando pppoe en un Linux de un sistema embebido y por tanto no hay pppoeconf. Joer... recuendo lo que me costó aprender esto... jejej y resulta que pppoeconf ya lo hacía :-)))) Debian is different ;-). De todas maneras, reconozco que no tener pppoeconf me hizo aprender un montón de cosas :-) > Esta regla precisamente altera el paquete inicial de conexión que los clientes > de la LAN envían al exterior. Lo que hace es disminuir el MSS (que repercute > finalmente en la MTU, pues el MSS es el MTU menos las cabeceras IP y TCP). > Lo disminuye automáticamente para que no sobrepase el MTU del interfaz de > salida, en este caso ppp0 que tiene un MTU de 1492 (el necesario para los > ADLS pues usan PPPoE o PPPoA). > > Mi problema era que había añadido un script en /etc/init.d de iptables que > facilita mucho su arranque, su parada, cargar otros esquemas... Lo adjunto > por si a alguien le interesa (reconozco que no sé de dónde ha salido). > > Este script de iptables se ejecutaba después del PPP así que reseteaba las > reglas existentes (la "ñapa" de antes) así que el problema reaparecía. Lo he > solucionado simplemente añadiendo esa regla a mi Iptables. > > > > Visto lo mal que lo he pasado (por suerte con final feliz) os recomiendo > efusivamente la lectura de este documento que explica el problema muy bien: > > http://www.trust-factory.com/van_den_berg-lisa02.pdf Muy buen documento!! > > Así mismo agradezco a Gonzalo la ayuda prestada pues sin su observación no se > me habría ocurrido mirar estos temas. > > > Saludos a todos. Saludos > > > > -- > y hasta aquí puedo leer... -- ___________________________________________________________________ Iván Forcada Atienza: correo: ivan@forcada.info ------------------------------------------------------------------- "Software is like sex: it's better when it's free" (Linus Torvalds)
Attachment:
pgp5h7JacOFOT.pgp
Description: PGP signature