Re: MTU para una LAN, fragmentar paquetes
El Domingo, 1 de Enero de 2006 13:05, Gonzalo HIGUERA DÍAZ escribió:
|| 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>
Muchas gracias por todo, Gonzalo. Es posible que dentro de dos semanas tenga
que ir al lugar del meollo y aprovecharé para hacer alguna prueba. Mientras
tanto seguiré investigando a ver si se me ocurre algo sobre lo que me has
dicho. Al menos parece que el problema está bastante localizado.
Aprovecho para pegar el Iptables completo, por si alguien averigua en él la
causa del problema:
######################## MANGLE
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
####################### NAT
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# Hacemos NAT:
-A POSTROUTING -o ppp0 -j MASQUERADE
COMMIT
######################## FILTER
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:bad_tcp_packets - [0:0]
:tcp_packets - [0:0]
:udp_packets - [0:0]
:icmp_packets - [0:0]
:allowed - [0:0]
###### INPUT:
# Inspeccionammos paquetes TCP:
-A INPUT -p tcp -j bad_tcp_packets
# Permitimos acceso total desde la LAN:
-A INPUT -s 192.168.2.0/255.255.255.0 -i eth1 -j ACCEPT
# VPN: OpenVPN:
-A INPUT -i tun+ -j ACCEPT
# Acceso total desde loopback:
-A INPUT -i lo -j ACCEPT
# Permitimos DHCP desde la LAN:
-A INPUT -i eth1 -p udp -m udp --sport 68 --dport 67 -j ACCEPT
-A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i ppp0 -p tcp -j tcp_packets
-A INPUT -i ppp0 -p udp -j udp_packets
-A INPUT -i ppp0 -p icmp -j icmp_packets
-A INPUT -m limit --limit 3/min --limit-burst 3 -j ULOG --ulog-prefix
"f.INPUT:PacketDied:"
# TCP: Permitimos SSH, Apach:
-A tcp_packets -p tcp -m tcp --dport 22 -j allowed
-A tcp_packets -p tcp -m tcp --dport 80 -j allowed
# ICMP:
-A icmp_packets -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A icmp_packets -p icmp -m icmp --icmp-type 11 -j ACCEPT
###### FORWARD:
-A FORWARD -i eth1 -j ACCEPT
-A FORWARD -i tun+ -j ACCEPT
-A FORWARD -o tun+ -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m limit --limit 3/min --limit-burst 3 -j ULOG --ulog-prefix
"f.FORWARD:PacketDied:"
###### OUTPUT:
-A OUTPUT -p tcp -j bad_tcp_packets
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o eth1 -j ACCEPT
-A OUTPUT -o eth0 -j ACCEPT
-A OUTPUT -o ppp0 -j ACCEPT
-A OUTPUT -o tun+ -j ACCEPT
-A OUTPUT -m limit --limit 3/min --limit-burst 3 -j ULOG --ulog-prefix
"f.OUTPUT:PacketDied:"
###### bad_tcp_packets:
#-A bad_tcp_packets -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m state --state
NEW -j REJECT --reject-with tcp-reset
-A bad_tcp_packets -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -m state
--state NEW -j LOG --log-prefix "New not syn:"
-A bad_tcp_packets -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -m state
--state NEW -j DROP
###### allowed:
-A allowed -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j ACCEPT
-A allowed -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A allowed -p tcp -j DROP
COMMIT
--
y hasta aquí puedo leer...
Reply to: