Forum: PC Hard- und Software Fragen zu IP-Adressen und Routern


von franz (Gast)


Lesenswert?

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
von NurEinGast (Gast)


Lesenswert?


von franz (Gast)


Lesenswert?

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?

von Pete K. (pete77)


Lesenswert?

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.

von Oliver (Gast)


Lesenswert?

>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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Peter (Gast)


Lesenswert?

>  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

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

>>  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.

von STK500-Besitzer (Gast)


Lesenswert?

>nein, sind es nicht. Es sind 2^32 = 65536

2^32 ist etwas mehr als 65536 ( = 2^16)...

von Reinhard S. (rezz)


Lesenswert?

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?

von Pete K. (pete77)


Lesenswert?

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.

von Stefan E. (sternst)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Stefan E. (sternst)


Lesenswert?

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.

von P. S. (Gast)


Lesenswert?

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.

von Stefan E. (sternst)


Lesenswert?

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.

von Peter (Gast)


Lesenswert?

> > nein, sind es nicht. Es sind 2^32 = 65536
> Hust - 2^16.
mist ist ja dann eine ungleichung

von (prx) A. K. (prx)


Lesenswert?

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).

von franz (Gast)


Lesenswert?

>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.

von Peter (Gast)


Lesenswert?

> 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.

von Gerry E. (micky01)


Lesenswert?

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.

von Stefan E. (sternst)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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?

von franz (Gast)


Lesenswert?

@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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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?

von (prx) A. K. (prx)


Lesenswert?

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.

von franz (Gast)


Lesenswert?

>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.

von Peter (Gast)


Lesenswert?

> 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.

von (prx) A. K. (prx)


Lesenswert?

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.

von franz (Gast)


Lesenswert?

>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?

von Peter (Gast)


Lesenswert?

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.

von franz (Gast)


Lesenswert?

>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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von franz (Gast)


Lesenswert?

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?

von Peter (Gast)


Lesenswert?

> 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

von franz (Gast)


Lesenswert?

Hallo Peter,

besten Dank für die Antwort. Da werde ich mich demnächst ans 
Ausprobieren machen.

Gruß,
Franz

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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
Noch kein Account? Hier anmelden.