<br><br><div class="gmail_quote">El 12 de octubre de 2010 16:20, Marcelo Fernandez <span dir="ltr"><<a href="mailto:marcelo.fidel.fernandez@gmail.com">marcelo.fidel.fernandez@gmail.com</a>></span> escribió:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> El día 12 de octubre de 2010 16:00, Mariano Reingart<br> <<a href="mailto:reingart@gmail.com">reingart@gmail.com</a>> escribió:<br> <div class="im">> 2010/10/12 leo fishman <<a href="mailto:leofishman@gmail.com">leofishman@gmail.com</a>>:<br> ><br> </div><div class="im">> ¿Y si ignoramos los RST del todo?<br> ><br> > sudo iptables -A INPUT -p tcp -m tcp --tcp-flags RST RST -j DROP<br> > # (para ignorarlos silenciosamente)<br> ><br> > o<br> ><br> > sudo iptables -A INPUT -p tcp -m tcp --tcp-flags RST RST -j REJECT<br> > # (para informarle a speedy que no los aceptamos...)<br> ><br> > algo más específico (aclaro que mi manejo de IPTABLES esta un poco<br> > desactualizado):<br> > iptables -A INPUT -p tcp -m tcp --tcp-flags RST RST --source-port 80 -j DROP<br> ><br> > Lo estoy probando y parece una solución provisoria viable (aunque no<br> > es optimo ni muy standard-friendly/compilant), y funciona porque al<br> > parecer el proxy de speedy tambien los ignora (ya que posiblemente<br> > sean falsos -forged-...)<br> ><br> <br> </div>Estaría bien esta solución también, el tema es que esto es stateless<br> (sin estado), y podés dejar conexiones abiertas más tiempo de lo<br> necesario (no siempre se cierran con FIN, y podés tirar un RST "de<br> verdad" que era necesario que vaya a la conexión). Otro efecto de<br> deshabilitar los RST de esta manera es si un sitio está caído o tiene<br> el puerto cerrado el navegador va a quedar "esperando respuesta...."<br> unos minutos (hasta que expire el timeout de recepción TCP).<br> <br> La solución del proxy es mejor (insisto no ví el código, sólo lo<br> supongo), ya que sólo luego e iniciar la conexión este chequea que se<br> reciba un ACK con datos y no un RST. Luego, si se recibe un RST, que<br> vaya al cliente, no problem; éstos son los que con la solución<br> firewall tirás y en realidad necesitás que fluyan.<br> <br> Saludos<br> <div class="im">--<br> Marcelo F. Fernández<br> Buenos Aires, Argentina<br> Licenciado en Sistemas - CCNA<br> <br> E-Mail: <a href="mailto:marcelo.fidel.fernandez@gmail.com">marcelo.fidel.fernandez@gmail.com</a><br> Blog: <a href="http://blog.marcelofernandez.info" target="_blank">http://blog.marcelofernandez.info</a><br> Twitter: <a href="http://twitter.com/fidelfernandez" target="_blank">http://twitter.com/fidelfernandez</a><br> <br> --</div><div><div class="h5"><br></div></div></blockquote><div><br>Hola muchachada! <br></div></div>Yo estoy teniendo el mismo inconveniente con Speedy.<br>Pregunto: ¿No hay modo de realizar un reclamo colectivo? Ya me cansé de llamar y llamar y no encontrar solución.<br> <br>Saludos,<br>Carlos<br>