Re: ip_conntrack table
Also sprach Marc Haber <mh+debian-user-german@zugschlus.de> (Sun, 04
Dec 2005 14:01:37 +0100):
> On Sun, 4 Dec 2005 12:18:21 +0100, Richard Mittendorfer
> <delist@gmx.net> wrote:
> >Also sprach "Felix M. Palmen" <zirias@despammed.com> (Sun, 4 Dec 2005
> >10:22:34 +0100):
> >> Was ist dann bei UPD-Verbindungen, die ja keinen dedizierten
> >> Abbau-Mechanismus haben? Blockieren die alle für mindestens 5 Tage
> >> einen Tabellen-Eintrag?
> >
> >ip_conntrack_udp_timeout
> >
> >Wie schon erkannt, ist udp "stateless" (keine "established" Verbindung).
>
> Wenn ich mich richtig erinnere, hat Netfilter bei klassischem
> "Frage-Antwort-UDP" einen recht kurzen Timeout, der bei Beobachtung
> eines zweiten "Antwort"-Pakets drastisch erhöht wird. So erhofft man,
> Streaminganwendungen zu erkennen.
>
> Bei Amanda fällt dieses Verfahren auf die Schnauze, weil dort im
> ersten Paket drin steht "schick mir mal eine Schätzung für die Größe
> Deines Dateisystems /usr", in der Antwort steht "Ja, in Ordnung", und
> wenn dann zehn Minuten später die eine Seite mit der Schätzung fertig
> ist, ist die Session auf dem Paketfiler längst ausgetimed und das
> Paket mit der "richtigen" Antwort zerschellt.
Da scheint wohl ip_conntrack_udp_timeout_stream zu helfen?
Nein - tut es nicht. Hab mir das nun genauer angesehen: Ein UDP-Link
wird einige Zeit mit einem kurzen timeout (default 30s) gehalten, und
bei Bedarf (aka falls es als "stream" erkannt wird) obiges
timeout_stream (180s) verwendet. Gehen aber zu wenige Packete/Zeit zum
Sender retour, wird das nicht als stream erkannt und ip_ct_udp_timeout
greift.
sl ritch
Reply to: