[Solar-general] Fwd: [LUGAr-gral] Problemas de conexión con Speedy
Javier Salinas
javier en salinas.com.ar
Mar Oct 19 05:33:27 CEST 2010
Hay una versión mejorada de esas reglas:
iptables -A OUTPUT -p tcp --dport 80 -m state --state NEW -m recent
--set --name thor --rdest -j ACCEPT
iptables -A INPUT -p tcp -m tcp --tcp-flag RST RST -m state --state
ESTABLISHED -m recent --name thor --rcheck --rsource --seconds 1 -j DROP
El problema con el proxy de $peedy es que contesta con un RST en forma
inmediata al SYN.
Sospecho que por saturación.
Leí, aunque no entiendo aun el porqué, que debido a que hay conexiones
que necesitan cerrarse con un RST, no se pueden dropear todos los RST
recibidos, sino que se puede considerar que cualquier RST que vuelva a
un intento de conexión antes de que pase un segundo puede interpretarse
como una "falla" del proxy.
Con estas dos reglas se identifican los paquetes salientes y si la
respuesta es un RST que llega antes de 1 segundo se dropea y se deja que
el propio TCP se ocupe de reintentar.
Saludos
Javier
Un post que hice al respecto:
http://blog.salinas.com.ar/2010/10/07/telefonica-y-el-proxy-de-los-misterios/
El 18/10/10 22:17, Pablo Manuel Rizzo escribió:
> 2010/10/18 Nicolás Reynolds <fauno en kiwwwi.com.ar
> <mailto:fauno en kiwwwi.com.ar>>
>
> El 18/10/10 10:50, Pablo Manuel Rizzo dijo:
> > 2010/10/18 Diego Saravia <dsa en unsa.edu.ar <mailto:dsa en unsa.edu.ar>>:
> > >>> Con el siguiente comando se reducen bastante estos cortes:
> > >>>
> > >>> iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state
> ESTABLISHED
> > >>> --source-port 80 -j DROP
> > >>>
> > >>
> > >> aja
> > >>
> > >> ¿pero qué hace ese comando exactamente?
> > >>
> > >> o sea ¿qué modificación nueva introduce en tu conexión?
> > >>
> > >>> Por lo que me han comentado, Telefónica está cambiando un
> software de QoS
> > >>> (Quality of Service) por uno de Microsoft y prioriza los
> dispositivos con
> > >>> Windows.
> > >>
> > >
> > >
> > > como sabe que son dispositivos windows?
> >
> > hmmm... mas que saber, debe estar más probado con los parametros de
> > tcp/ip que usa windows por defecto, y no tanto con los que usa
> > gnulinux.
> >
> >
> > Esa instrucción creo que
> >
> > iptables -A INPUT // para los paqutes entrantes
> >
> > -p tcp // del protocolo tcp (no udp)
> >
> > --tcp-flags RST RST // marcados con estos flags (que los desconosco,
> > supongo estarán por ahí documentados)
> >
> > -m state --state ESTABLISHED // que correspondan a conexiones
> > previamente establecidas (no nuevas ni cerrandose etc)
> >
> > --source-port 80 // que provengan del puerto http de la maquina
> remota
> >
> > -j DROP // eliminarlos inmediatamente
> >
> >
> > Y supongo que al ser eliminados y no llegar la información esa para la
> > conexión establecida, se intentará retrasmitir el paqute, y cuando
> > venga sin el flag RST RST pasará bien.
> >
> > Bueno, no recuerdo de memoria los parametros de iptables, muy
> > acostumbrado a usar herramientas graficas como fwbuilder o webmin, si
> > alguien sabe más, por favor corrija.
>
> Creo que es la misma que recomendaban para evitar el bloqueo de P2P que
> hacía Comcast, puede ser? El tema es que vos pedías conectarte a un par
> y el sistema de ellos te reconocía el tipo de paquete y te respondía con
> un RST (reset?).
>
> Entonces configurabas tu firewall para que no los acepte y listo :P
>
>
>
> Ahí uno decía esto en otra lista:
>
> "Los que analizaron un poco las conexiones, comprobaron que cuando el
> proxy transparente empieza a fallar (¿cuando está sobrecargado?)
> responde al SYN con RST (reset) en lugar de un SYN,ACK. ¿Porqué no pasa
> esto con Windows? Un verdadero misterio, y no creo en conspiraciones:
> calculo que por casualidad tienen implementado algo distinto en su stack
> TCP/IP que hace menos evidente el problema, porque un poco les pasa,
> pero muy poco."
>
>
> Yo tengo todas mis maquinas conectadas a un openvpn en un datacenter,
> ahora puse allí un squid y estoy navegando por allí, como va todo por
> vpn es a penas un poquito mas lento pero casi ni se nota y anda bien.
>
> --
> Pablo Manuel Rizzo
> -------------------------------
> http://pablorizzo.com
> -------------------------------
>
>
>
> ________________________________________________
>
>
> Solar-General es una lista abierta a toda la comunidad, sin ninguna moderación, por lo que se apela a la tolerancia y al respeto mutuo.
> Las opiniones expresadas son responsabilidad exclusiva de sus respectivos/as autores/as. La Asociación Solar no se hace responsable por los mensajes vertidos, ni representan necesariamente el punto de vista de la Asociación Solar.
>
> Solar-general en lists.ourproject.org
> https://lists.ourproject.org/cgi-bin/mailman/listinfo/solar-general
Más información sobre la lista de distribución Solar-general