Am Router sind eingehend alle Ports geschlossen, bis auf HTTP, POP, SMTP, …
Nun starte ich am Client einen Browser. Die Anfrage wird mit der IP-Adresse des Clients und mit der Portnummer 80 an den Router (=default Gateway) gesendet. Das Packet geht raus, wird beantwortet, kommt zurück, geht rein und kommt an den Browser zurück an Port 80.
Ich starte nun am Client den zweiten Browser (gleichzeitig) und beinne zu surfen. Ein Packet kommt zurück, wie weiß Windows, welchem Browser das gehört?
Möglichkeiten:
o.) Der zweite Browser sendet als Absenderport nicht 80 sondern z.B: 10.000, auch dieser Port wird am NAT-Rotuer ge"NAT"et und geht raus. Auf welcher Portnummer kommt das Packet zurück, wo doch am Router (siehe oben alle Ports (ausser…) geschlossen sind? Das Packet dürfte nicht zurück ins LAN kommen.
o.) Alle Packete von beiden Browsern gehen mit der gleichen Portnummer als Absenderkennung raus. Die Packete werden beantwortet und gehen zurück. Wie wieß Windows dann, welchem Browser das Packet gehört?
Ich hatte erwähnt, daß die Post mir versichert hat, daß
eingehend ALLE Ports geschlossen sind. Bis auf 80, SMTP, DNS,
…
ja, eingehend sind die alle Ports zu, d.h. wenn jemand von aussen eine TCP/IP Verbindung auf einen Port … sagen wir 10001 … aufbauen will geht das nicht.
Aber von dir aus eine Verbindung von (z.b. 10001) nach aussen will geht das natürlich (wenn das nicht gehen würde würde bei dir GAR nichts mehr gehen).
Ich schließe daraus, daß der Type von der Post sich nicht so
besonders auskennt.
Ich hatte erwähnt, daß die Post mir versichert hat, daß
eingehend ALLE Ports geschlossen sind. Bis auf 80, SMTP, DNS,
…
also die p[oe]st hat aus dem thema telekomunikation ja gluecklicherweise schon laenger ihre finger draussen - ob die nachfolgeorganisation so viel erstrebenswerter ist, sei dahingestellt.
aber in diesem fall hat der techniker nichts falsches gesagt - eine tcp-connection besteht aus zwei richtungskanaelen, die auf anfrage eines der beiden rechner aufgebaut werden - siehe rfc793 oder jedes halbwegs brauchbare netzwerk-tutorial. ein „geoeffneter port“ bedeutet, dass ein rechner anfragen zum verbindungsaufbau auf diesem port engegennimmt (laut definition ein packet mit gesetztem syn und gecleartem ack flag) und daraufhin den verbindungsaufbau fortsetzt (stichwort three-way-handshake) - die antworten auf seine eigenen verbindungen sid davon voellig unabhaengig.
ja, eingehend sind die alle Ports zu, d.h. wenn jemand von
aussen eine TCP/IP Verbindung auf einen Port … sagen wir
10001 … aufbauen will geht das nicht.
das sollte man meinen - bei solchen einfachen sog. screening-routern gibt es aber in letzter zeit haeufiger faelle, wo durch unterschiedliche auslegung der rfc durch routerhersteller und netwerk-stack programmierer ein verbindungsaufbau auch auf gefilterten ports moeglich war…
bei dsl-routern im ueblichen sinne (also nat mit dynamischer ip-addresse) ist es aber wenig wahrscheinlich, da hier immer explizit eine nat-rule (vulgo port-forwarding) eingetragen werden muss.
Aber von dir aus eine Verbindung von (z.b. 10001) nach aussen
will geht das natürlich (wenn das nicht gehen würde würde bei
dir GAR nichts mehr gehen).
o.) Alle Packete von beiden Browsern gehen mit der gleichen
Portnummer als Absenderkennung raus.
Und hier ist der Denkfehler - tun sie eben nicht. Die Pakete gehen mit dem gleichen Adressport heraus (www.kernel.org:80), aber haben für jede Verbindung unterschiedliche Absenderports (mein.rechner.private.ip:16077). Du hast schon in einem einzigen Fenster unterschiedliche Absenderports.
Die Absenderports liegen alle zwischen 1024 und 65535, da die Ports bis 1023 dem Systemverwalter vorbehalten sind und der Normaluser diese nicht nutzen darf.