Re: iptables ip_conntrack
Micha Holzmann <[email protected]>
| Newsgroups | gmane.linux.redhat.general.german |
|---|---|
| Message-ID | <[email protected]> |
Quoting Matthias Borrack <[email protected]>: > Michael Schwendt wrote: > >>Knapp 5 Tage für ein TimeOut ist einfach zu hoch. > > > > > > Es sind bei Dir nicht die üblichen zwei Minuten für TCP/IP? > > > > Guten Morgen, > > es betrifft ja nicht die "üblichen" (Verdächtigen) TCP/IP-Verbindungen > in dem Sinne, es geht um die Einträge in die Conntrack im Zusammenhang > mit NAT. Mit dem Wechsel von MASQ auf NAT, bzw. mit dem Wechsel von > ipchains auf iptables, wurde der MASQ/NAT-TimeOut/Ungültigkeit geändert > ("Sorry, we think 5 days are better" ... oder so). > Ich kan auf einigen Ports darauf verzichten bzw. der Status dieser > Verbindung ist mir recht egal, aber eben nur bei knapp 20 %, und genau > diese 20 % verursachen diese ewig-lebenden-Einträge, und dann sind > irgendwann auch 15000 Einträge in Conntrack zuviel. Problem ist nur, > entweder conntrack oder nicht, ein zwischending, conntrack nur da, wo > ICH es will, gibt es net :( > Auf netfilter.org ist der einzige Hinweis darauf ein Patch, in dem man > von den 5 Tagen wegkäme, aber es wird (bei dieser Maschine) schwer, > diesen Patch einzubasteln (zu dürfen), deswegen würd ich gerne darauf > verzichten. Ich benutze zu Hause ebenfalls MASQ/NAT und dafuer Connection Tracking. Die von dir beschriebenen Phaenomene konnte ich nach jetzt zweitaegiger Beobachtung nicht sehen. Bei mir werden alle Verbindungen nachdem der Client RST gesendet hat auch alle geschlossen. Vielleicht besorgst du dir das iptstate (http://www.phildev.net/iptstate/). Gruss, Micha Holzmann -- Who the hell is General Failure, and why he is reading my disk? _______________________________________________ redhat-list-de mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-list-de
signature.asc
(application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAWBv+ZrmPvQ66gg8RAu8CAKCCK6EmEXD8fpQudYj/ErUsMwKJ0ACgiMpI l5D0KyrB3uWEgmu9e6ntElQ= =yDUO -----END PGP SIGNATURE-----