Paketverlauf zwischen Router/Internet und meinem Computer

@

@night@

0
Hallo Community,
woher weiß ein Router an welchen Computer ein ankommendes IP-Paket gerichtet ist?
Beispiel: In meinem Intranet sind 2 Computer, beide schicken eine HTTP-Anfrage an Google. Das Versenden der Pakete stellt kein Problem dar, doch wie soll der Router die Antwortpakete unterscheiden? Bei TCP-Paketen ist dies ja noch recht einfach möglich, da dort die SYN- und ACK-Nummern höchstwahrscheinlich unterschiedlich sind (obwohl es ja theoretisch auch passieren kann, dass beide die gleichen Werte haben).

Bei UDP wird es schon viel schwieriger, da es nicht verbindungsbasiert ist. Lediglich den Quellport könnte der Router verändern, um selber zwischen den 2 verschiedenen Computern unterscheiden zu können.
Bei reinen IP-Paketen mit einem nicht normalen Protokoll ist es meiner Meinung nach unmöglich, da es dort noch nicht mal Ports gibt.

Wenn ich Wireshark im Promisciousmode starte, kann ich die Antwortpakete anderer Computer nicht mitlesen, dementsprechend muss mein Router in der Lage sein zu trennen. Doch wie tut er das?
 
Fluffy hat gesagt.:
Der TCP-Frame ist im IP-Packet enthalten.
Zum Vergrößern anklicken....
Kann sein - muss aber nicht :wink: Hier findest du eine Liste mit möglichen folgenden Protokollen, die als Angabe gemacht werden können.

Ausserdem kann ich mir nicht so recht vorstellen, dass meine Fritz!Box im Spezialfall TCP tatsächlich den gesamten Transportschichtheader analysiert. Gerade auch in dem unglaublich unrealistischen Fall, dass die Anfangswerte für SYN und ACK identisch sind.
 
Du "meldest" dich doch bei deinem Router an.
Der Router weiss also:
Aha auf Ethernetport a) liegt night's PC auf Ethernetport b) liegt Fluffy's PC.
2 unterschiedliche IP's.
Wir nehmen jetzt der Einfachheit halber an, es gibt kein NAT.
Dann weiss dein Router 192.168.0.1/24->night, 192.168.0.2/24 -> Fluffy
Wenn er nun ein Packet bekommt mit dest: 192.168.0.2 dann schickt er das Packet über den Ethernetport b) raus. und nicht über a) ist ja ein Router und kein HUB.
Gruß

Fluffy

P.s.: oder ich verstehe deine Frage nicht wirklich.
 
Ein Router / Switch in einem LAN (lernt)kennt die Zuordnung MAC <> IP.
IPs spielen bei dem eigentlichen Transport innerhalb eines LANs keine große Rolle (eben- Internet-Protocol) deswegen ist es intern ziemlich egal welche Protokolle durch einen Switch gehen, der eh einen Layer _unter_ den IP Protokollen arbeitet. Die Verarbeitung der Prüfsummen, ACK usw. wird auf den Endgeräten (PCs) von den entsprechenden Protokoll-Stacks übernommen. Bei TCP/IP eben von dem dafür zuständigen.

In deinem Szenario kommt auch NAT am Router dazu. Dazu behält der Router die Zuordnungen interner Request <> externe Antwort in seinem "Gedächtnis" um die zurückkommenden Pakete entsprechend umzubauen. Wenn Du auf deinem Router, während da PCs im Netz unterwegs sind, diese "Table" anzeigen lassen würdest, dann könntest Du eine Tabelle sehen, wo sich der Router eben diese ganzen Verbindungen "stateful" - "merkt".

Bei UDP funktioniert es am Router genau wie bei TCP. Er "merkt" sich, wer mit wem spricht und leitet die Pakete entsprechend weiter, nachdem sie (NAT) "umadressiert" worden sind. Deine Verwunderung bei UDP mag von der irreführenden Bezeichnung "verbindungslos" kommen, die eben eine "Verbindungslosigkeit" suggeriert, was im Grunde nicht stimmt, denn auch ein UDP Paket muss ja wissen wo es herkommt und wo es hin will - es fehlen eben nur (auf dem Stack) Rechenlastige Features, wie der Handshake und Prüfsumme.
 
Danke, ich habs jetzt kapiert! Trotzdem glaube ich, dass nicht alle verstanden habe was ich eigentlich meinte :D
Ich formulier die Lösung nochmal für alle die dasselbe über google suchen:

Wenn 2 Computer aus dem selben Privatnetzwerk (z.B) eine UDP-Kommunikation zum gleichen Server im Internet aufbauen, werden nahezu identische Paketheader vom Router aus abgeschickt.
Wenn nun auch noch der Quell- und Zielport in diesen Paketen gleich ist, sollte es für den Router quasi unmöglich sein Antwortpakete zu unterscheiden.

Beispiel: PC1 sendet UDP-Paket mit folgendem Header.
Ziel-IP: 170.0.0.1
Quell-IP: 192.168.0.2
Ziel-Port: 1337
Quell-Port: 10

PC2 sendet UDP-Paket mit folgendem Header.
Ziel-IP: 170.0.0.1
Quell-IP: 192.168.0.3
Ziel-Port: 1337
Quell-Port: 10

Der Router muss jetzt trivialerweise die Quell-IP mit seiner Eigenen austauschen. Doch nicht nur das. Falls er den Quellport unverändert lässt, wird er ankommende Antworten nicht mehr internen Computern zuordnen können. Deswegen tauscht er die Quellports auch noch aus und ersetzt sie mit eigenen, freien Ports. Dies funktioniert ähnlich zu einem Man-in-the-middle-Angriff.

Daraus stellen sich mir aber gleich 2 weitere Fragen:

1) Können portlose Transportschichtprotokolle im Allgemeinen nicht geroutet werden? Habe gerade gesehen, dass bei ICMP etwas auf Schicht 4 getrickst wird. Aber der Router kann ja nicht alle Protkolle auf Schicht 4 "auswendig" können.

2) Gibt es mit IPv6 eigentlich die Möglichkeit allen Computern eine eigene IP zuzuordnen? Dann könnte man immerhin auf NAT verzichten und die damit verbundenen Nachteile.
 
Zuletzt bearbeitet:
Die MAC-Adressen in den Ethernetframes sind eindeutig.

Bzgl. IPv6.
Ja gibt es.
Abgesehen von den schieren numerischen Kombinationen, gibt es ein Feld was für die MAC-Adresse reserviert ist und die ist von Werk ab eindeutig.
Nachteil ist natürlich, das du immer weisst welcher PC gerade was macht.
Wurde zum Glück mit einer zufällig generierten Zahl, welche man bei bedarf anstelle der MAC nehmen kann entschärft.
Gruß

Fluffy
 
1) Können portlose Transportschichtprotokolle im Allgemeinen nicht geroutet werden? Habe gerade gesehen, dass bei ICMP etwas auf Schicht 4 getrickst wird. Aber der Router kann ja nicht alle Protkolle auf Schicht 4 "auswendig" können.
Zum Vergrößern anklicken....

Alle Router für den Hausgebrauch können selbstverständlich die nötigen Protokolle um sachgerecht zu funktionieren. Das sind aber nicht sehr viele die man da zu können braucht. Zwar gibt es tausende von Netzwerkprotokollen aber wenn sie durch IP Netze müssen, werden die idR in den verfügbaren Protokollen (TCP/IP, UDP) gekapselt.

Nochmal zu den Nachteilen von NAT. Insgesamt waren Subnetting und NAT in erster Linie ein Segen und auch wenn man prinzipiell jedes Device mit einer IPv6 Adresse versehen kann, so ist das doch in der Praxis eher nicht so wünschenswert. Für Firmen und Entwickler wäre es prima. Für Netzwerkbetreiber eher ein nicht - nimmt es doch ein gutes Stück Flexibilität wenn es um Redundanz, Lastenverteilung und Skalierbarkeit geht.
 
Chromatin hat gesagt.:
Alle Router für den Hausgebrauch können selbstverständlich die nötigen Protokolle um sachgerecht zu funktionieren. Das sind aber nicht sehr viele die man da zu können braucht. Zwar gibt es tausende von Netzwerkprotokollen aber wenn sie durch IP Netze müssen, werden die idR in den verfügbaren Protokollen (TCP/IP, UDP) gekapselt.

Nochmal zu den Nachteilen von NAT. Insgesamt waren Subnetting und NAT in erster Linie ein Segen und auch wenn man prinzipiell jedes Device mit einer IPv6 Adresse versehen kann, so ist das doch in der Praxis eher nicht so wünschenswert. Für Firmen und Entwickler wäre es prima. Für Netzwerkbetreiber eher ein nicht - nimmt es doch ein gutes Stück Flexibilität wenn es um Redundanz, Lastenverteilung und Skalierbarkeit geht.
Zum Vergrößern anklicken....

Ursprünglich war NAT für IPv6 gar nicht vorgesehen, da eigentlich unnötig. Erst später wurde das durch RFCs spezifiziert (mit durchaus großem Wiederstand, mehr siehe hier: Gretchenfrage: NAT oder nicht NAT für IPv6? | heise Netze)

Ehrlich gesagt sehe ich auch aus Netzbetreibersicht keine Vorteile von NAT (außer "das haben wir schon immer so gemacht"). Was lässt sich denn ohne NAT nicht umsetzen?
Netzinterne IPv6 Adressen können genauso dynamisch und flexibel vergeben werden wie lokale IPv4 Adressen. Die Trennung von internem Netz und Internet sollte durch eine Firewall passieren. Bei NAT ist das nur ein Nebeneffekt, aber den will man so eigentlich gar nicht haben und dafür wurde NAT nicht entwickelt. NAT zerstört das Ende-zu-Ende Prinzip, welches für die Idee und stetige Weiterentwicklung des Internets wesentlich ist. Viele Protokolle können wegen NAT nur auf Umwegen realisiert werden, z.B. IPsec.
 
Ehrlich gesagt sehe ich auch aus Netzbetreibersicht keine Vorteile von NAT (außer "das haben wir schon immer so gemacht"). Was lässt sich denn ohne NAT nicht umsetzen?
Zum Vergrößern anklicken....

Im Betrieb haben wir nun mal "best practice" Verfahren. Das hat selten was mit Sturheit oder Bequemlichkeit zu tun sondern vielmehr mit rein ökonomischen Aspekten.

Nochmal: NAT ist wunderbar beim Loadbalancing und Aufbau redundanter Serverlandschaften, sowie schoen fuer Netzanbieter, die keine echten IP Zugänge haben und auch keine Anbieten wollen.

Die Trennung von internem Netz und Internet sollte durch eine Firewall passieren.
Zum Vergrößern anklicken....
Ja, das war 1988 so. Heute hat man in großen Projekten gänzlich andere Strukturen und das ist durch NAT (also NAT, Firewall-Router) sehr viel einfacher zu lösen.

Viele Protokolle können wegen NAT nur auf Umwegen realisiert werden, z.B. IPsec.
Zum Vergrößern anklicken....
Ja und wo ist dabei das Problem? Hätte man NAT bei IPSec, bzw. IPv6 gleich mit berücksichtigt, dann haette man das Problem berücksichtigen können?
Generell wird in der Praxis ständig irgendwo irgendwas angepasst um Dinge zum Laufen zu bringen. Dort geschieht Weiterentwicklung - nicht alleine auf den Listen der IETF.

Das ist ein klassisches Unternehmer vs. Tekkie Ding und belebt insgesamt die Entwicklung :D
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben