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 <[email protected] <mailto:[email protected]>>
El 18/10/10 10:50, Pablo Manuel Rizzo dijo: > 2010/10/18 Diego Saravia <[email protected] <mailto:[email protected]>>: > >>> 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.
[email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/solar-general