Hallo Zusamen, schon länger beschäftigt mich die Frage, wie der Übergang vom Router zu Hause auf die angeschlossenen Rechner funktioniert. Vom Internetprovider bekommt man eine IP-Adresse für den Router. Schließt man jetzt an den Router verschiedene andere Rechner an, sieht das Internet ja nur die IP-Adresse vom Router. Wie gelangen die Daten nun zu den einzelnen Rechnern? Vielen Dank erst mal für die Antworten, Franz
:
Verschoben durch Moderator
Danke für die Antwort. Soweit ich es aus dem Artikel verstehe, wird die Zuordnung über die Erweiterung der IP-Adresse durch eine Portadresse bewerkstelligt. Wenn ich den Aufbau des Internetprotokolls anschaue http://de.wikipedia.org/wiki/IP-Paket sehe ich allerdings nicht, dass in jedem IP-Paket eine Portadresse mit übertragen wird. Das müsste ja eigentlich für die "Source NAT" wie sie in den Routern zu finden ist der Fall sein, damit der Router das IP-Packet an die ensprechende lokale Adresse schicken kann. Verstehe ich das was falsch?
Der Port gehört nicht zum IP, sondern zum TCP Protokoll. Also eine Schicht höher. http://de.wikipedia.org/wiki/Transmission_Control_Protocol Der Router muss also bei NAT auch diese Schicht mit auswerten (zumindest den Header). TCP ist in der Payload von IP enthalten.
>Soweit ich es aus dem Artikel verstehe, wird die >Zuordnung über die Erweiterung der IP-Adresse durch eine Portadresse >bewerkstelligt. Grundsätzlich geht jede TCP/IP-Kommunikation immer von einem Port an einer IP-Adresse (bzw. MAC-Adresse) zu einem Port an einer anderen IP-Adresse. Egal, ob mit oder ohne Router. An einer IP-Adresse können also so viele Verbindungen gleichzeitig ankommen, wie Ports vorhanden sind (theoretisch sind das 32.767). Von aussen aus gesehen hast du halt mit deinem Router nur eine einzige IP-Adresse, aber die hat viele Ports für getrennte Verbindungen. Der Router führt intern Listen über offene Verbindungen und ordnet die Daten dann den internen Rechnern (mit verschiedenen IP-Adressen) zu. Oliver
Oliver schrieb: > An einer IP-Adresse können > also so viele Verbindungen gleichzeitig ankommen, wie Ports vorhanden > sind (theoretisch sind das 32.767). Es sind 65535 pro Protokoll, UDP und TCP zählen dabei getrennt.
> An einer IP-Adresse können > also so viele Verbindungen gleichzeitig ankommen, wie Ports vorhanden > sind (theoretisch sind das 32.767). nein, sind es nicht. Es sind 2^32 = 65536
>> An einer IP-Adresse können >> also so viele Verbindungen gleichzeitig ankommen, wie Ports vorhanden >> sind (theoretisch sind das 32.767). > nein, sind es nicht. Es sind 2^32 = 65536 Hust - 2^16.
>nein, sind es nicht. Es sind 2^32 = 65536
2^32 ist etwas mehr als 65536 ( = 2^16)...
Oliver schrieb: > An einer IP-Adresse können > also so viele Verbindungen gleichzeitig ankommen, wie Ports vorhanden > sind. Bsp. Webserver, stark frequentiert. Mindestens die erste Anfrage muss ja über Port 80 laufen. Soll da wirklich nur eine Verbindung möglich sein?
Das erste, was ein Server macht, der eine Anfrage auf seinen Port (z.B. 80) bekommt, ist, einen neuen Port für die eigentliche Übertragung auszuhandeln (meist >5000). Damit steht der Port wieder für neue Anfragen zur Verfügung.
Reinhard S. schrieb: > Oliver schrieb: > >> An einer IP-Adresse können >> also so viele Verbindungen gleichzeitig ankommen, wie Ports vorhanden >> sind. > > Bsp. Webserver, stark frequentiert. Mindestens die erste Anfrage muss ja > über Port 80 laufen. Soll da wirklich nur eine Verbindung möglich sein? Nein, die Aussage von Oliver ist natürlich falsch. Eine "Verbindung" besteht aus der Kombination aus Absender ip:port und Empfänger ip:port. Die Begrenzung der möglichen Verbindungen liegt also nicht in der Anzahl der Ports. Sie liegt einfach nur darin, wie viele Verbindungen der TCP/IP-Stack intern verwalten kann.
Pete K. schrieb: > Das erste, was ein Server macht, der eine Anfrage auf seinen Port (z.B. > 80) bekommt, ist, einen neuen Port für die eigentliche Übertragung > auszuhandeln (meist >5000). Unsinn. Ein Server kann auf einen Port beliebig viele Verbindungen parallel aufrecht erhalten, soviel wie seine Resourcen hergeben und wie der im API angegeben hat. Ein HTTP Server führt normalerweise keine Umleitung auf einen weiteren Port durch.
Pete K. schrieb: > Das erste, was ein Server macht, der eine Anfrage auf seinen Port (z.B. > 80) bekommt, ist, einen neuen Port für die eigentliche Übertragung > auszuhandeln (meist >5000). Es wäre mir gänzlich neu, wenn HTTP das tun würde. > Damit steht der Port wieder für neue Anfragen zur Verfügung. Das tut er sowieso. Ein Port ist nicht nur einmal verwendbar.
Stefan Ernst schrieb:
> Es wäre mir gänzlich neu, wenn HTTP das tun würde.
Stimmt, das macht der Protokollstack. Denn irgendwie muessen ja nachher
die verschiedenen Verbindungen unterschieden werden.
Peter Stegemann schrieb: > Stefan Ernst schrieb: > >> Es wäre mir gänzlich neu, wenn HTTP das tun würde. > > Stimmt, das macht der Protokollstack. Denn irgendwie muessen ja nachher > die verschiedenen Verbindungen unterschieden werden. Auch der ändert den Port nicht. Wie ich bereits schrieb, besteht eine Verbindung aus Empfänger und Absender. franz:100 - server:80 egon:200 - server:80 Beides sind unterschiedliche Verbindungen und "server" kann sie eindeutig voneinander unterscheiden, auch wenn sie bei ihm über den selben Port laufen.
> > nein, sind es nicht. Es sind 2^32 = 65536 > Hust - 2^16. mist ist ja dann eine ungleichung
Möglicherweise verwechselt hier jemand Portnummern und Sockets. Der HTTP-Server hat für alle Verbindungen den gleichen Port, aber für jede einzelne Verbindung darauf einen eindeutigen Socket (Handle).
>Der Port gehört nicht zum IP, sondern zum TCP Protokoll. Also eine >Schicht höher. >http://de.wikipedia.org/wiki/Transmission_Control_Protocol >Der Router muss also bei NAT auch diese Schicht mit auswerten (zumindest >den Header). TCP ist in der Payload von IP enthalten. Hmm, interessant. So wie ich es verstanden habe, werden alle überlagerten Protokolle ( z.B. TCP, UDP ) in den IP-Frame hineingepackt. TCP und UDP haben in ihrem Header immer einen Source-Port und einen Destination Port. z.B. UDP: Quell-Port, Ziel-Port, Länge, Prüfsumme, Daten Im IP-Protokoll werden die verschiedenen überlagerten Protokolle im 3ten "long" im Bit 8-15 übertragen. D.h. es wären 256 überlagerte Protokolle möglich. Bei Linux sind die möglichen Protokolle ja in /etc/protocols gelistet ip 0 IP # internet protocol, pseudo protocol number tcp 6 TCP # transmission control protocol cbt 7 CBT # CBT, Tony Ballardie egp 8 EGP # exterior gateway protocol igp 9 IGP # any private interior gateway (Cisco: for IGRP) .... udp 17 UDP # user datagram protocol ( http://www.control.auc.dk/~jdn/edu/litt/ip-tables/iptables/iptables-tutorial.frozentux.net/other/protocols.txt ) Meine Idee ist, z.B. einfach das 9.te Protokoll rauszuwerfen und durch was völlig eigenes zu in meinem Quell- und Zielrechner zu ersetzen. Theoretisch müsste das Internet ja meine eigenes Protokoll weitervermitteln, da es ja im IP-Protokoll verpackt ist.
> Meine Idee ist, z.B. einfach das 9.te Protokoll rauszuwerfen und durch > was völlig eigenes zu in meinem Quell- und Zielrechner zu ersetzen. > Theoretisch müsste das Internet ja meine eigenes Protokoll > weitervermitteln, da es ja im IP-Protokoll verpackt ist. und warum dieser aufwand? Wenn du nur eine externe IP Hast kannst du ein VPN aufbauen, damit kannst du jeden gerät erreichen. Wenn du kein VPN machen willst, kannst du immer noch jeden gerät ein Port von der einen IP zuweisen. Wenn du 500 geräte hast, dann sind das doch auch nur 500Port von 65535 - also noch genügend da.
franz schrieb: > Meine Idee ist, z.B. einfach das 9.te Protokoll rauszuwerfen und durch > was völlig eigenes zu in meinem Quell- und Zielrechner zu ersetzen. > Theoretisch müsste das Internet ja meine eigenes Protokoll > weitervermitteln, da es ja im IP-Protokoll verpackt ist. Das kann funktionieren, wenn Dein Router das unterstützt.
franz schrieb: > Meine Idee ist, z.B. einfach das 9.te Protokoll rauszuwerfen und durch > was völlig eigenes zu in meinem Quell- und Zielrechner zu ersetzen. Und warum willst du etwas rauswerfen, wenn es
1 | # 134-254 # Unassigned |
gibt? > Theoretisch müsste das Internet ja meine eigenes Protokoll > weitervermitteln, da es ja im IP-Protokoll verpackt ist. Dem "Internet" ist es egal, was du ins IP-Paket packst.
franz schrieb: > Meine Idee ist, z.B. einfach das 9.te Protokoll rauszuwerfen und durch > was völlig eigenes zu in meinem Quell- und Zielrechner zu ersetzen. > Theoretisch müsste das Internet ja meine eigenes Protokoll > weitervermitteln, da es ja im IP-Protokoll verpackt ist. Im Prinzip ja, allerdings könnte das mit NAT kollidieren. Bei UDP und TCP pflegt der Router für NAT eine Tabelle der aktiven Verbindungen, die ihm bei von aussen eingehenden Antworten die Rückübersetzung von Portnummer und Adresse auf die internen Werte ermöglicht. Bei einem eigenen IP-Protokoll kann er das nicht automatisch, da muss dann ein manuelles Forwarding rein, sofern der Router das auf Basis einer IP Protokollnummer überhaupt beherrscht. Wozu soll das eigentlich gut sein?
@A.K. Vielen Dank für die Antwort, das war schon mal sehr hilfreich. Das heist ja eigentlich, dass bei einem zwischengeschaltetem Router nur UDP und TCP vernünftig funktionieren, weil die anderen Protokolle möglicherweise bei der Address-Translation eine Problem haben. @Stefan Ernst >Und warum willst du etwas rauswerfen, wenn es ># 134-254 # Unassigned >gibt? Die würden laut A.K. ja nicht durch den Router kommen.
franz schrieb: > Meine Idee ist, z.B. einfach das 9.te Protokoll rauszuwerfen und durch > was völlig eigenes zu in meinem Quell- und Zielrechner zu ersetzen. IGP, da hast du sicher gute Chancen, das kein Provider das weiter vermitteln will. ;-) Sowas wird für die Router-zu-Router- Kommunkation benutzt, und da es sich um ein interior gateway protocol handelt (also eins, was innerhalb eines Providers benutzt wird, nicht zwischen Providern), ist es gut möglich, dass die Router eines ISPs so konfiguriert sind, dass sie das nicht durchlassen. > Theoretisch müsste das Internet ja meine eigenes Protokoll > weitervermitteln, da es ja im IP-Protokoll verpackt ist. An sich ja, wobei man halt kein von der IANA zugewiesenes Protokoll umdefinieren sollte. Dein DSL-NAT-Router wird damit allerdings nichts anfangen können und das komplett ignorieren. Dem müsstest du das also in der Firmware beibringen, dafür noch NAT zu machen. Was willst du eigentlich bewerkstelligen?
franz schrieb: > Vielen Dank für die Antwort, das war schon mal sehr hilfreich. Das heist > ja eigentlich, dass bei einem zwischengeschaltetem Router nur UDP und > TCP vernünftig funktionieren, weil die anderen Protokolle möglicherweise > bei der Address-Translation eine Problem haben. Yep. Und manche TCP Protokolle funktionieren über NAT nur, wenn der Router bei Traffic auf den entsprechenden Ports automatisch tiefer in die Pakete rein sieht als üblich. So funktioniert beispielsweise das klassische aktive FTP über NAT nur dann, wenn der Router die FTP-Kommandos auf Port 21 mitliest und aufgrund des Inhalts die NAT-Tabelle füllt. Hängt man den FTP-Server auf einen anderen Port, dann ist aktives FTP via NAT gestorben.
>Was willst du eigentlich bewerkstelligen?
Ich bin gerade dabei, die Funktionsweise des Internet etwas besser
kennenzulernen. Ein falsch bezeichnetes eigenes Protokoll wäre
vermutlich einigermaßen abhörsicher ( deep packet inspection geht nicht
).
Aber eigentlich wollte ich nur mal wissen, welche Hindernisse dem
entgegestehen.
Eine ander Frage: Welche Möglichkeit gibt es, in C direkt ein IP-Packet
zu erzeugen und zu empfangen oder zu schicken?
Welche nützlichen Kommandozeilentools gibt es, um das Netzwerk zu
analysieren? Bis jetzt habe ich schon mal netstat endeckt, mit dem man
die Routingtabelle ausgeben kann.
> Eine ander Frage: Welche Möglichkeit gibt es, in C direkt ein IP-Packet > zu erzeugen und zu empfangen oder zu schicken? dafür gibt es RAW-Sockets. Aber die Möglichkeiten sind unter windows eingeschränkt aber unter linux sollte das noch einfach möglich sein. (in Windows wurde diese Möglichkeit stark eingeschränkt um zu verhindern das viren damit die Firewall umgehen können) Ich würde mich auf soetwas nicht einlassen, verwende lieber die normalen Protokolle (TCP/UDP) denn du kannst nie sichergehen das die billigen Homerouter mit den andern Protokollen sauber umgeben. Kann mir auch vorstellen das es über UMTS probleme mit neuen Protokollen gibt.
franz schrieb: > kennenzulernen. Ein falsch bezeichnetes eigenes Protokoll wäre > vermutlich einigermaßen abhörsicher ( deep packet inspection geht nicht Das ergibt keinen Sinn. Wenn du abhörsicher kommunizieren willst, dann verwende VPN. Das kriegst du fertig von der Stange, kannst es aber auch selbst implementieren, über UDP oder TCP und daher mit NAT verträglich.
>Ich würde mich auf soetwas nicht einlassen, verwende lieber die normalen >Protokolle (TCP/UDP) Hmm, ist ja nur um ein wenig zu experimentieren und die Grenzen kennezulernen. Frage: Ich habe einen WLAN Router und meinen EEEPC hier. Was müsste ich tun, um von der Arbeit aus meinem EEPC eine UDP Message schicken zu können. Kennt jemand ein Beispiel in C, mit dem ich einen UDP Server einrichten kann, der irgenwie antwortet?
Du musst den router erstmal so einrichten das er vom Internet kommende UDP Packete an deinen EEEPC weiter leitet. Dann musst du hoffen das euer Admin keine UDP Packet filtert. jetzt noch einfach mal bei google socket programmierung suchen und loslegen. http://www.tenouk.com/cnlinuxsockettutorials.html Aber du hast uns noch nicht das Betriebssystem verraten, da gibt es ein paar kleine unterschiede.
>Aber du hast uns noch nicht das Betriebssystem verraten, da gibt es ein >paar kleine unterschiede. Im Geschäft, üblicher und blöderweise VISA. Mein EEPC praktischerweise Ubuntu ;-) Die Frage wäre für mich, ob ich mir beim Aufmachen des Routers nicht ein Sicherheitsproblem inhandele.
franz schrieb: >>Was willst du eigentlich bewerkstelligen? > > Ich bin gerade dabei, die Funktionsweise des Internet etwas besser > kennenzulernen. Dafür ist eine NAT-Umgebung nicht wirklich besonders günstig, da die zusätzlichen Übersetzungsebenen das Verständnis nicht gerade erleichtern bzw. zusätzlichen Konfigurationsaufwand am NAT-Router verursachen. Wenn du eine geradlinige IP-adressierte Umgebung benutzen kannst (das kann ja ein reines LAN sein), wird das einfacher. Gibt's sogar zu DSL-Zeiten, nicht jeder Provider ist so geizig und spendiert dir nur eine IP-Adresse.
franz schrieb: > Die Frage wäre für mich, ob ich mir beim Aufmachen des Routers nicht ein > Sicherheitsproblem inhandele. Wenn du genau einen TCP- oder UDP-Port von draußen auf den EEEPC lenkst, dann kommen nur Pakete auf diesem einen Port durch den Router durch. OK, mit normalem Routing hat das natürlich dann auch nichts mehr zu tun :) (da käme ja immer alles durch, was für diese IP-Adresse bestimmt ist), aber das ist für den Fall eher nebensächlich. Was auf diesem Port dann passiert, bestimmt doch letztlich der Prozess, der ihn auf deinem EEEPC offen hält. Aber s. o., du kommst besser, wenn du dir die Grundlagen von IP- Netzen erst einmal in einem LAN aneignest, da dir ja ganz offenbar noch viele Grundbegriffe fehlen. Du solltest zumindest erst einmal einen einfachen TCP-echo-Server oder sowas programmiert haben (den kann man mit telnet als Client einfach testen), bevor du dich an weitere Dinge heranwagst.
Vielen Dank für die Antworten.
Im Link von Peter gibt es ja einige einfache Beispiele in C für die
Programmierung von einfachen Server Funktionen.
>http://www.tenouk.com/cnlinuxsockettutorials.html
Ich hätte da noch eine andere Frage:
Wenn ich meinen Rechner zuhause via UDP anspreche, ist im UDP-Header der
Quelport vom Geschäftsrechner und der Zielport meines Privatrechners
enthalten. Öffnet der Router normalerweise dann die Firewall für die
Rückantwort über die selben Ports?
> Wenn ich meinen Rechner zuhause via UDP anspreche, ist im UDP-Header der > Quelport vom Geschäftsrechner und der Zielport meines Privatrechners > enthalten. Öffnet der Router normalerweise dann die Firewall für die > Rückantwort über die selben Ports? das ist nicht festgelegt. Es kann also jeder router/firewall machen wie er will. Bei TCP wird meinst in der Firewall festgelegt das eine aktive Verbindung daten auf dem rückweg übertragen darf. Aber eine Aktive Verbindung gibt es bei UDP ja nicht. Es muss ja auch festgelegt weden wie lange danach noch die gegenrichtung offen sein darf. Also ausprobieren
Hallo Peter, besten Dank für die Antwort. Da werde ich mich demnächst ans Ausprobieren machen. Gruß, Franz
Peter schrieb: > Bei TCP wird meinst in der Firewall festgelegt das eine aktive > Verbindung daten auf dem rückweg übertragen darf. Aber eine Aktive > Verbindung gibt es bei UDP ja nicht. Einen Rückweg gibt es schon: es wird für die Antwort das gleiche Adress-/Port-Tupel benutzt, auf dem die Anfrage rein kam. Es gibt zwar auch Pakete, die nie eine Antwort erwarten (routing broadcasts zum Beispiel oder auch multicasts), aber sehr viele UDP-Protokolle benutzen natürlich Antworten. Es gibt halt nur keinen expliziten Verbindungsauf- und -abbau wie bei TCP, den der Firewall mitverfolgen kann. > Es muss ja auch festgelegt weden > wie lange danach noch die gegenrichtung offen sein darf. Diese Möglichkeit ist daher nahezu die einzige bei UDP: man gestattet ein Antwort-Zeitfenster, innerhalb dessen für das Adress-/Port-Tupel der Rückkanal geöffnet bleibt. Ähnliches muss man bspw. auch tun, um eine ICMP echo reply als Antwort zu einem ICMP echo request zu gestatten (also ein "ping"), wobei man dort nur IP-Adressen hat, keine Portnummern. Bei TCP braucht man das nicht, da nach dem gegenseitigen Austausch der FIN-Pakete keine weitere Kommunikation zwischen beiden Partnern notwendig ist, und das Verbindungs-Tupel aus den Firewallregeln entfernt werden kann.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.