El Viernes, 30 de Diciembre de 2005 20:58, Iñaki escribió: || El Viernes, 30 de Diciembre de 2005 20:29, Marcelo Fernandez escribió: || || El Viernes, 30 de Diciembre de 2005 15:54, Iñaki escribió: || || > El Viernes, 30 de Diciembre de 2005 06:25, Marcelo Fernandez escribió: || || > || El Jueves, 29 de Diciembre de 2005 17:19, Iñaki escribió: || || > || > 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. || || > || > || || > || > ........ || || > || > 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... || || > || > || || > || > 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í, la máquina de la LAN || || > || > envía a 1500 porque la red que usa es una Ethernet, y luego el || || > || > router (Debian) debería fragmentar la trama sin que el ordenador || || > || > local se entere. ¿No es así? || || > || > || || > || > En caso de que no esté equivocado, ¿qué hay que hacer para || || > || > habilitar la fragmentación de paquetes en el router Debian? || || > || > ¿algún módulo? || || > || > || || > || > Muchas gracias por cualquier aclaración. || || > || || || > || Lo que pasa es que en el protocolo IP hay un bit en el encabezado || || > || (más bien en los flags) que se llama "Don't Fragment". Si ese bit || || > || está activado el router no lo fragmenta y directamente dropea el || || > || paquete. Creo que esta es la explicación. :-D || || > || || > Sí, ya conocía el bit DF (Don't Fragment) del protocolo IP, pero || || > gracias por comentarlo ya que no se me habría ocurrido pensar que || || > pudiese ser eso. || || > || || > Pero entonces esto significa que tanto Windows como Debian por || || > defecto mandan los paquetes con ese bit activado, ya que el problema || || > ocurría con ambos SO como clientes de la LAN. ¿Podría alguien || || > confirmar si esto es normal? O sea, ¿realmente por defecto se activa || || > el bit DF? || || > || || > Lástima que no se me ocurrió hacer un tctpdump para comprobarlo... lo || || > haré cuando pueda. || || || || Pensá que el problema (activación del bit DF) también puede estar en || || cualquier nodo intermedio en el camino al destino, ya que en mi caso, || || el problema no estaba en el envío del mensaje, sino en que nunca volvía || || la respuesta (ethereal de por medio, claro) :-D || || No puede ser mi caso, ya que yo lo solucioné fijando el MTU a 1492 en vez || de 1500 en eth1 (el interfaz de Debian-Router con la red local). || || Pero ahora que lo dices... qué raro. Lo que me pasaba era que páginas como || yahoo.es no se cargaban (y muchas más, la mayoría). Lo que dices me hace || pensar: || || Cuando hago una petición de una web mi tráfico saliente es mínimo mientras || que el entrante (los datos de la web) son mucho mayores. Entonces tiene || sentido que el problema fuese al entrar, ¿pero eso cómo es posible que se || solucione disminuyendo el MTU del eth0 en la Debian? || || Se supone que los problemas de tamaño de trama se solucionan en cada tramo || de red. En caso de que no quepa el router correspondiente lo fragmenta y || esos fragmentos llegan por separado al destino final que los junta. || || No se me ocurre a qué se puede deber este problema, de verdad... || || Saludos. 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. 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. Entonces hay que hacer la "ñapa" en la zona cliente, o sea, nuestro router/firewall o nuestros clientes de la LAN. - En los clientes de la LAN: cambiar a todos la MTU (pasar de 1500 típica en Ethernet a 1492). El problema es que habría que hacerlo en cada cliente y en Windows no es precisamente cómodo pues exige modificar el registro, reiniciar y rezar. En Linux ya sabemos que es muy sencillo (sólo añadir "MTU 1492" en eth0 en /etc/network/interfaces). Aprovecho para rectificar una cosa que dije anteriormente y que pensaba que había sido la solución: Se me ocurrió cambiar la MTU de eth1 (el interfaz del router que es una Debian con la LAN) a 1492, pensando que entonces todos los clientes de la LAN tomarían esa MTU, pero es completamente falso y lo he comprobado haciendo tcpdump en el router. Los clientes siguen usando MTU 1500. - 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 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 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. -- y hasta aquí puedo leer...
Attachment:
iptables
Description: application/shellscript