[LUGA] Mit freundlicher Unterstützung von:
init.at

Mail Thread Index


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [luga] iptables-Timeouts



On 2015-06-17 22:10:06 +0200, Steffen Nurpmeso wrote:
> "Peter J. Holzer" <hjp-luga2@hjp.at> wrote:
>  |On 2015-06-17 15:29:13 +0200, Steffen Nurpmeso wrote:
>  |> "Peter J. Holzer" <hjp-luga2@hjp.at> wrote:
>  |>|On 2015-06-17 13:26:50 +0200, Steffen Nurpmeso wrote:
>  |>|> "Peter J. Holzer" <hjp-luga2@hjp.at> wrote:
>  |>|>|Meine Erinnerung war also entweder falsch oder sie ist inzwischen
>  |>|>|veraltet. Bei halbwegs aktuellen Linuxfirewalls kann eine TCP-Verbindung
>  |>|>|viele Tage idle sein, ohne vom Firewall gekappt zu werden.
> 
>  |>|>   [1] http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/
> 
>  |>   At this time, we're in a stable status: connection is
>  |>   established, and now we would normally wait for someone to send
>  |>   data over the channel.
>  |> 
>  |> ....
>  |> 
>  |>   Keepalive can tell you when another peer becomes unreachable
>  |>   without the risk of false-positives.
>  |
>  |Mir ist nicht ganz klar, warum Du das hier zitierst. Es scheint wenig
>  |Zusammenhang mit meinen Beobachtungen zu haben. Es könnte helfen, wenn
>  |Du nicht nur irgendwelche Zitate mehr oder weniger kommentarlos in den
>  |Raum wirfst, sondern auch dazuschreibst, worauf Du hinauswillst.
> 
> Na, aber ja doch.  Gut gut, also gut.
> 
>  |Ich weiß, was TCP-Keepalive ist und wozu es gut ist (und wozu nicht).
>  |Bei diesem Experiment wäre es störend gewesen, daher hatte ich es nicht
>  |aktiviert und mittels Wireshark überprüft, dass es tatsächlich nicht
>  |aktiv ist.
> 
> Meinereiner dachte sich, daß Verbindungen gar nicht automatisch
> gekappt werden,

Kommt darauf an, was man unter "automatisch gekappt" versteht. Im
Normalfall muss jede Seite der anderen signalisieren, dass sie keine
weiteren Daten schicken wird. Solange kein FIN-Paket kommt, muss jede
Seite annehmen, dass noch weitere Daten kommen können. Wenn eine Seite
Daten schickt und entweder keine Bestätigung oder ein RST zurückbekommt,
weiß sie auch, dass die Verbindung tot ist. Aber im Prinzip gibt es
keine Möglichkeit, eine "stille" von einer "toten" Verbindung zu
unterscheiden. Das kann für Router ein Problem sein, wenn diese pro
Verbindung Status-Information halten müssen (z.B. für stateful filtering
oder NAT). Die haben daher üblicherweise Timeouts (von unter einer
Stunde bis zu mehreren Tagen) nach denen sie die Information über die
Verbindung vergessen. Weitere Pakete kommen dann unter Umständen nicht
mehr durch, wodurch die Verbindung "gekappt" erscheint.


> und Keepalive nun denn testet, ob die Verbindung noch besteht, um z.
> B. sinnlose Ressourcenverschwendung auf der lokalen Box zu vermeiden, 

Das ist richtig. 

> es also «falsch» benannt ist,

Das könnte man so sehen, da der eigentliche Zweck nicht ist, die
Verbindung am Leben zu erhalten, sondern im Gegenteil, tote Verbindungen
zu erkennen. "Heartbeat" wäre heute wohl ein üblicherer Ausdruck für
diese Funktionalität.

Ich weiß nicht, wann und und von wem diese Bezeichnung geprägt wurde. In
RFC 1122 (Oktober 1989) wird sie verwendet, aber offenbar war das damals
schon recht üblich.

Stateful Packet Filter, PPP-Implementationen, die bei Stille auflegen,
und anderes Netzwerkequipment, das durch Keepalive tatsächlich "am Leben
erhalten" wird, kam m.W. erst in den 90er-Jahren auf.

Mit "false positive" in dem von Dir zitierten Howto war aber wohl
gemeint, dass eine existierende Verbindung fälschlicherweise als tot
diagnostiziert wird (und natürlich kann das auch bei der
Linux-Implementatin passieren, "without the risk of false-positives" ist
also falsch, es sei denn, man definiert "unreachable" genau so, wie den
Test).

	hp

-- 
   _  | Peter J. Holzer     | You can do reverse engineering,
|_|_) | Schriftführer LUGA  | but you can't do reverse hacking.
| |   | hjp@luga.at         |
__/   | http://www.luga.at/ | -- Vilayanur S. Ramachandran

Attachment: signature.asc
Description: Digital signature



powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
Juni 2015