On Thu, Jul 27, 2000 at 09:59:53AM +0200, Stefan Nobis wrote: > > sondern daß anscheinend Pakete da sind, wenn meiner Meinung nach eigentlich > > keine da sein sollten. > Das ist genau das Problem mit den Sockets. Wenn ich z.B. mit Netscape > von meinem *lokalen* Server im Intranet eine Seite abrufe, habe ich > auch eine Minute später mit netstat noch folgende Ausgabe: > stefan@teddy:~$ netstat -tun > Active Internet connections (w/o servers) > Proto Recv-Q Send-Q Local Address Foreign Address State > tcp 1 0 10.0.1.3:1028 10.0.1.2:80 CLOSE_WAIT > > Die Verbindung ist also (für den TCP/IP-Stack) immer noch offen. In > diesem Fall hilft tatsächlich auch ein Beenden von Netscape. Manchmal > jedoch bleiben Verbindungen im Stadium FIN_WAIT hängen und da hilft > auch ein Beenden des Netscape (oder welches Programm das auch immer > ausgelöst hat) nicht weiter, der TCP/IP-Stack will fleissig > weitermachen (und hat halt so seine Timeout-Zeiten, d.h. er schickt > ein Paket, wartet eine ganze Weile, erhält keine Antwort und sendet > dann ein neues Paket -- dies hat jedoch eine neue Absender-IP und > damit kann der TCP/IP-Stack niemals die passende Antwort bekommen und > es dauert eine kleine Ewigkeit, bis er den Socket dann von sich aus > killt). Lösungsmöglichkeit: Alte Datenpakete per ipchains blocken, > z.B. indem du im Normalbetrieb nur Pakete mit gesetztem SYN und > fehlendem ACK und FIN Bit erlaubst und dann in ip-up alles erlaubst > und in ip-down wieder alles bis auf SYN-Pakete blockst. So habe ich > das hier ganz gut in den Griff bekommen (bei DoD, dynamischer IP und > ISDN). Das interessiert mich hier näher. Könntest Du mir mal die Config zumailen, welche ich zum konfigurieren der Firewall benötige ? Weil meist habe ich dasselbe Problem wie Du, wenn ich mit dem Netscape gesurft habe. Trotz Beendigung desselben wird die Verbindung aufrecht gehalten. cu Stefan
Attachment:
pgphrzy8ybNHX.pgp
Description: PGP signature