ubuntuusers.de

Hallo, wie aus dem Betreff bereits bekannt, interessiert mich mal, warum man für die Kommunikation über jabber und icq oder andere Protokolle keinen Port in der Firewall öffnen muss.

Es ist doch so:

Starte ich z.B. Pidgin, dann loggt es mich automatisch mit meinen hinterlegten Zugangsdaten für den ICQ-Server an selbigem ein. Damit weiß der Server, das der Benutzer mit der Kennung 1234567 bereit ist Daten zu empfangen. Schickt mir dann Jemand per ICQ eine Nachricht, dann muss doch der ICQ-Server Kontakt zu meinem Client, also pidgin, aufnehme um diesem diese Nachricht zu übermitteln. Aber das ist ja eigentlich, firewalltechnisch gesehen, eine eingehende Verbindung. Und diese eingehenden Verbindungen sind normalerweise ja alle geblockt, sprich es sind alle Ports geschlossen. Dennoch funktionieren diese Instant-Messenger Problemlos mit geschlossenen Firewalls....Warum?

Grüße

Ich schätze mal das liegt daran, dass diese Messenger nicht auf einem Port horchen, ob was reinkommt, sondern laufend Anfragen an den Server stellen. Iswasdaiswasdaiswasda...

Oder so.

Habe ich mir auch gedacht, aber dann müsste ständig die Sende-/Empfangs-LED am DSL Router wie verrückt blinken. Das ist aber nicht der Fall. 😉 Das kann also nicht die Erklärung sein.

Du öffnest von dir aus einen Socket zum Server. Diese verbindung ist nicht gefirewalled, weil sie ausgehend ist. Die Verbindung wird vom Client nicht geschlossen und über diesen Socket kommen auch die Nachrichten rein.

redknight schrieb:

Du öffnest von dir aus einen Socket zum Server. Diese verbindung ist nicht gefirewalled, weil sie ausgehend ist. Die Verbindung wird vom Client nicht >geschlossen und über diesen Socket kommen auch die Nachrichten rein.

Ok, zunächt muss ich sagen, dass ich nicht weiß was ein Socket ist. Dann habe ich mir mal den Artikel der wikipedia.de zum Thema Socket(Software) durchgelesen. Richtig verstanden habe ich es immer noch nicht. Ich habe aber eine wage Ahnung davon was es sein könnte. Wenn ich mit meiner Vermutung Recht habe, dann habe ich auch verstanden wie Instant-Messeging funktioniert: Ein Socket kann ich mir also vorstellen wie eine art virtuelle Netzwerkschnittstelle, so wie man das auch von OpenVPN kennt. Über diese(s)(Socket) wird dann, durch die Firewall hindurch eine Punkt-zu-Punkt Verbindung zwischen Client und Server aufgebaut.

Hmm da fällt mir aber ein, dass man auch für OpenVPN wenn man bidirektional Dienste nutzen will sowohl serverseitig als auch clientseitig einen vereinbarten Port in der Firewall öffnen muss. Wie es scheint habe ich die Sache mit den Sockets wohl doch noch nicht verstanden.

Kannst du mir das mal genauer erläutern? Danke!

Im Normalfall filtert eine Firewall eingehenden Verkehr. Deine Verbindung ( Pidgin → ICQ-Sevrer) ist aber ausgehen. deshalkb wird sie nicht gefiltert. Diese Loginverbindung wird nicht geschlossen und über sie werden die Nachrichten versandt und empfangen.

redknight schrieb:

Im Normalfall filtert eine Firewall eingehenden Verkehr. Deine Verbindung ( Pidgin → ICQ-Sevrer) ist aber ausgehen. deshalkb wird sie nicht gefiltert. Diese Loginverbindung wird nicht geschlossen und über sie werden die Nachrichten versandt und empfangen.

Und was genau kann ich mir unter einer Loginverbindung vorstellen? Und wie wird das technisch gelöst, dass so eine Verbindung bestehen bleibt. Ich habe deshalb hier verständnisprobleme, weil es ja so ist, dass das TCP-Protokoll mit Paketen arbeitet. Nun schickt mein Pidgin ein paar Pakete welche zur anmeldung auf dem icq-Server nötig sind, und damit gut. Wie soll da eine Verbingung "bestehen" bleiben. Und wenn dann der Server wieder meinem Pidgin ein Paket schickt müsste doch eigentlich meine Firewall mäckern, weil das ja dann ein nicht angefordertes Paket von extern ist.

Sorry, aber ich stehe wohl aufm Schlauch. 😇

Klar Socket... oO. Jetzt geh ich mich schämen. In der Ecke. Man man...

LordNoxx schrieb:

Sorry, aber ich stehe wohl aufm Schlauch

Naja, ich kann dir die Lektüre vom O'Reilly nicht ersparen 😉 Wenn du weder Grundkenntnisse von Sockets noch von TCP hast, ist es auch nicht so einfach zu verstehen, würde aber den Thread sprengen. Nur so viel, es wird einfach kein fin gesendet, sondern eine sogenannte non-blocking-Verbindung verwendet. Das sollte nun genügend Lesematerial bieten 😉

Ok, dann danke ich dir auf jeden Fall mal bis hier hin. Damit hast mich wohl auf die richtige Spur gesetzt. Den Rest lese ich mir dann an. Danke.

LordNoxx schrieb:

redknight schrieb:

Im Normalfall filtert eine Firewall eingehenden Verkehr. Deine Verbindung ( Pidgin → ICQ-Sevrer) ist aber ausgehen. deshalkb wird sie nicht gefiltert. Diese Loginverbindung wird nicht geschlossen und über sie werden die Nachrichten versandt und empfangen.

Und was genau kann ich mir unter einer Loginverbindung vorstellen? Und wie wird das technisch gelöst, dass so eine Verbindung bestehen bleibt. Ich habe deshalb hier verständnisprobleme, weil es ja so ist, dass das TCP-Protokoll mit Paketen arbeitet. Nun schickt mein Pidgin ein paar Pakete welche zur anmeldung auf dem icq-Server nötig sind, und damit gut. Wie soll da eine Verbingung "bestehen" bleiben. Und wenn dann der Server wieder meinem Pidgin ein Paket schickt müsste doch eigentlich meine Firewall mäckern, weil das ja dann ein nicht angefordertes Paket von extern ist.

Der Client muss aktiv die Verbindung offen halten, indem er regelmäßig Pakete schickt. Die meisten Router/Firwalls halten Verbindungen mindestens 30 Sekunden offen, so dass man mit einem Paket alle 20 Sekunden auf der sicheren Seite ist. Linux als Router hat diesen kurzen 30 Sek timeout nur für DNS, ansonsten 5 Min - und bei TCP noch WESENTLICH länger, denn die werden ja normalerweise irgendwann wieder ordentlich zu gemacht.

Einfach mal Wireshark installieren und so gucken was da so kommt.

Als Filter kann man mit "netstat -anp" gucken, welche Ports das gewünschte Programm lokal aufmacht und die dann im wireshark einstellen.

Wenn man Linux auf dem Router einsetzt kann man mit cat /proc/net/ip_conntrack die aktuell offenen Verbindungen anzeigen (komfortabler geht das mit dem Tool iptstate).

Sorry, aber ich stehe wohl aufm Schlauch. 😇