[Solar-general] Fwd: [LUGAr-gral] Problemas de conexión con Speedy

[Javier Salinas]

El 19/10/10 08:45, Nicolás Reynolds escribió:
> El 19/10/10 12:33, Javier Salinas dijo:
>> 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.
> 
> che o sea que estamos contribuyendo a que ese proxy se prenda fuego? :P
> 

Y, podría decirse que si, ya que si responde con RST por saturación, el
reintento es mucho mas rápido que si el usuario tiene que hacer F5 para
recargar.

Saludos

Javier

> 
> 
> 
> ________________________________________________
> 
> 
> 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