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

[Nicolás Reynolds]

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

-- 
Salud!
Nicolás Reynolds,
xmpp:fauno en kiwwwi.com.ar
omb:http://identi.ca/fauno
blog:http://selfdandi.com.ar/
gnu/linux user #455044

http://librecultivo.org.ar
http://parabolagnulinux.org
------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre     : no disponible
Tipo       : application/pgp-signature
Tamaño     : 490 bytes
Descripción: no disponible
Url        : https://lists.ourproject.org/pipermail/solar-general/attachments/20101019/0e2a99b7/attachment.pgp