IP-Ermittlung von Clients im Netzwerk ohne DNS-Server

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Zum Glück wurde der Threadtitel extra unpassend und irreführend gewählt. Wenigstens etwas...
 
Und wo ist jetzt die neue Erkenntnis? Dass DNS oder was Ähnliches gebraucht wird, stand doch in Post #9.
die neue Erkenntnis ist, dass ich jetzt weiß, wo der Ersatz-DNS nun sitzt und wie er festgelegt wird.
Das ist ein ganz krasser Unterschied.

Aber ich merke schon. Das Forum hier empfängt neue Mitglieder (egal ob Anfänger oder Pro) mit sehr offenen Armen und der rauhe Ton wirkt sehr freundlich.

Trotzdem danke an alle dir mir geholfen oder auch nicht geholfen haben.

Zum Glück wurde der Threadtitel extra unpassend und irreführend gewählt. Wenigstens etwas...
danke für den Hinweis, ich werde Ihn schnell ändern. Kein Problem
 
Zuletzt bearbeitet:
Das hat nicht mit Neuankömmlingen zu tun.

Es hat sich aber scheinbar in der Gesellschaft durchgesetzt, dass man bei Fragen die Hälfte weglässt.

Eine wichtige Information wäre gewesen, was genau du wo anklickst, bzw. welchen Dienst du nutzt, etc. Wir sitzen 100te km von dir entfernt und können dir nicht in den Kopf schauen, um deine Fragezeichen zu erkennen.

Deine Lösung oder besorgte Information gilt z.b. auf Linux oder embedded System fast garnicht. Dort existieren nur die Dienste, ARP und DNS-Auflösung. Netbios, WIDS oder WSD gibt es dort garnicht.
 
ja danke für den Hinweis underclocker2k4,

ich als Fragesteller kann ja nur die Frage so stellen, wie ich das Problem betrachte, weil mir eben Informationen fehlen. Darum frage ich doch.
Im anderen Forum hat man mein Problem doch sofort verstanden. Also so schlecht formuliert dürfte sie nicht gewesen sein oder?

Wie gesagt, trotzdem danke für deine Hilfsbereitschaft.
 
Das Problem ist, dass Windows so blödsinnig komplex ist. Wenn du den Explorer aufmachst und da ein Rechner in der Netzwerkumgebung erscheint, ist im Hintergrund schon soviel Komplexität abgelaufen, dass das mit gemeinem ARP und IP-Adressen nicht mehr viel zu tun hat. Das ist zwar alles beteiligt, aber da drüber sitzen hochkomplexe Schichten, damit das, was der gemeine Windows-User als "Netzwerk" vorgesetzt bekommt, möglichst vollautomatisch abläuft.

"Windows-Netzwerk" = "normales Netzwerk" + viel komplexer Schrott.
 
ist im Hintergrund schon soviel Komplexität abgelaufen, dass das mit gemeinem ARP und IP-Adressen nicht mehr viel zu tun hat. Das ist zwar alles beteiligt, aber da drüber sitzen hochkomplexe Schichten, damit das, was der gemeine Windows-User als "Netzwerk" vorgesetzt bekommt, möglichst vollautomatisch abläuft.
das ist genau was ich denke. Deswegen beschäftige ich mich zur Zeit mit dem Thema Netzwerk usw. um zu verstehen, was da im Hintergrund passiert.

Hatte vorher alles nie beachtet, wollte aber nun mal alles genau verstehen und arbeite mich durch die OSI-Schichten durch.
Bin bei Schicht 2, wo der Switch mit Ethernetframes und MAC-Adresse arbeitet. Und hier steckte ich beim Thema ARP fest.
 
Der Vollständigkeit halber sei noch erwähnt, dass es bei Apple auch diesen aufgeblasenen Overhead gibt. Nennt sich Bonjur.

Netzwerke sind normalerweise nicht belastet, wenn niemand gerade einen Userdienst nutzt. Windows, MacOS oder Klickibunti Linux hingegen sind so gesprächig, dass einem schlecht wird.
Ordentliche Netzwerkgeräte halten überwiegend die Klappe. Daher nutzen die auch nur DNS als Namensauflösung, der Rest ist dann alles IP.

Diese Gesprächigkeit ist der vermeintlichen usability geschuldet.
 
Ich versuche, den Mist einfach zu ignorieren und mich an DNS zu halten. Solange das Windows vom dhcpd den Domainnamen kriegt und der Hostname foo automatisch zu foo.$domain wird[1], interessiert mich nicht, was das Teil da noch so treibt.

[1] Das ist unter UNIXen eine Eigenschaft des Resolvers, dass "unqualified" host names ohne Domain automatisch die Domain des Systems angehängt kriegen. Sollte man auch wissen.
 
@hexyvaxa, du hast noch nicht verstanden, dass Rechner 1 überhaupt nicht wissen muss, wie er Rechner 2 erreicht. Er muss nur die IP Adresse von Rechner 2 kennen, alles andere erledigt die Netzinfrastruktur. Du sagst deinem Browser auf Rechner 1 also z.B., dass er http://192.168.0.2/ ansteuern soll. Darauf schickt Rechner 1 IP Pakete los mit Zieladresse 192.168.0.2. Mehr muss Rechner 1 nicht können. Der Switch sieht die Pakete mit der Zieladresse, schaltet die Pakete auf den Port an dem Rechner 2 hängt und schickt die Pakete dort hin. Und falls Rechner 2 nicht am gleichen Switch hängt, reicht der Switch die Pakete an den Router durch und der kümmert sich um die Zustellung an den nächsten Netzwerkknoten, so lange bis Rechner 2 erreicht worden ist.

Edit: Ich habe die ganzen ARP Geschichten raus gelassen, weil die erstens nur im lokalen Netzwerk relevant sind und zweitens offensichtlich unnötig Verwirrung stiften.
 
Zuletzt bearbeitet:
ARP ist das wichtigste überhaupt!
Und ARP ist auch im nicht lokalen Netzwerk interessant. Was meinst du, wie dein Rechner 8.8.8.8 findet? Richtig, er muss das Gateway über ARP auflösen und kann dann 8.8.8.8 erreichen.

Und natürlich erledigt nichts die Netzinfrastruktur. Er schickt kein Paket mit 192.168.0.2 los. Er schickt ein Paket mit der vorher ermittelten MAC-Adresse und anschließend enthaltener IP-Adresse.
Die Netzinfrastruktur (@home im Regelfall nur Switch) arbeitet auf MAC-Ebene. Es gibt also beim Pakete Verteilen garkeine IP-Adresse, die relevant wäre. Daher muss man ja mittels ARP die MAC ermitteln. Denn nur so weiß das Switch, wo das Zeug hin soll. Ein Switch kennt keine IPs und leitet daher auch keine IP-Pakete weiter. Es leitet MAC-Pakete weiter.

Die IP ist nur interessant um den Netzwerkstack des Empfangsgerätes zur Arbeit zu bewegen. Das Paket kommt aber im geswitchten Netzwerk nur Aufgrund der MAC-Adresse an.
Daher spricht man beim Switch auch von MAC-Tabellen und nicht von ARP- oder IP-Tabellen. Switch ist Layer2=MAC.

PS: Hexy hat scheinbar mehr Ahnung von der Materie als du.
Es geht ihm ja um das ARP, bzw. wie das ARP zustande kommt.

Und falls Rechner 2 nicht am gleichen Switch hängt, reicht der Switch die Pakete an den Router durch und der kümmert sich um die Zustellung an den nächsten Netzwerkknoten
Das ist natürlich auch nonsense. Ein Switch leitet keine Pakete bei Unzustellbarkeit an den Router weiter. Was soll der Router auch damit anfangen, wenn beide Rechner sich im gleichen Subnetz befinden. Außerdem weiß der Switch auch garnicht welches Gerät Router ist und welches nicht. Für den sind alle gleich, nur irgendwelche MACs in einer einfachen Tabelle.. Wenn der 1. Rechner die MAC zum Gerät hat, dann kennt sein Switch auch die MAC und den Port an dem die MAC hängt. Und wenn die MAC an einem weiteren Switch hängt, dann hat der 1. Switch für diesen Port (wo der 2. Switch dranhängt) mehrere MAC-Einträge. Und da ist auch die MAC vom 2. Rechner enthalten, auch wenn der am 100. Switch dranhängt. MAC-Tabellen sind keine 1:1 Zuordnung, sondern eine 1:N Zuordnung.
Daher ist in größeren voll geswitchten Netzwerken die Größe der MAC-Tabelle interessant. Wenn man z.B. 4000 Geräte hat, aber nur 1000 MACs speichern kann, dann kann man das Netz in der Pfeife rauchen. Das gibt nen Paketspam.
(neben dem Umstand, dass nen 4000er geswitchtes Netzwerk noch ganz andere Probleme hat)

Und wenn es tatsächlich keinen Eintrag in der MAC-Tabelle findet, dann gibt es nen Paketbroadcast. (ähnlich einem Hub) Das macht dann mächtig Spaß.
Das ist also kein gezieltes Verhalten sondern eher "einer wird's schon haben wollen"-Verfahren.
 
Zuletzt bearbeitet:
OK, habe mir schon gedacht, dass da gleich die Kavallerie angeritten kommt. Ersetze mal IP Adresse durch MAC Adresse, dann klingt's vermutlich schon besser.

Also ist jetzt die eigentliche Frage, wie ARP genau funktioniert?
 
Wird nicht wirklich besser. Man kann nicht MAC und IP einfach wahlweise ersetzen. Das sind unterschiedliche Layer im Osi-Modell. Und jeder Layer hat seine eigene Funktion.

Und natürlich kannst du dir das denken. Unsinn schreiben und dann "denken", dass die Kavallerie gleich kommt. Dazu muss man kein Prophet sein, das ist die logische Konsequenz.

EDIT:
Nein, das ist ihm klar. Er wusste nur nicht, woher das Gerät (wie sich dann im Nachhinein rausgestellt ist es nen Windows-PC) die IP-Adresse weiß um so die MAC mittels ARP zu ermitteln.

Den Rest kann man nachlesen.
 
Zuletzt bearbeitet:
@hexyvaxa, du hast noch nicht verstanden,
- Darauf schickt Rechner 1 IP Pakete los
- Der Switch sieht die Pakete mit der Zieladresse, schaltet die Pakete auf den Port an dem Rechner 2 hängt und schickt die Pakete dort hin.
Ich glaube du hast vieles ganz schön durcheinandergewürfelt. So simpel ist das Thema echt nicht.
Je mehr ich mich in das Thema einlese, desto mehr Respekt bringe ich den Leuten entgegen, die das Zeug beherschen...
Hut ab, was man alles als Netzwerker wissen muss.


wow erstmal vielen Dank für die genauen Erklärungen.
Hab dein Wissen ganz schön unterschätzt. Lag also doch an meiner ungenauen Frageformulierung
Deine Beschreibungen spiegeln sogut wie 100% das wieder, was ich bisher gefunden und gelernt habe.
Hab ich also doch alles richtig verinnerlicht :rofl:


Richtig, er muss das Gateway über ARP auflösen und kann dann 8.8.8.8 erreichen.
eine Frage um mein bisheriges Wissen zu testen:
Einfache Situation: Modem > WLAN-Router > PC (Windows) und Notebook (Windows)

wenn ein Rechner ein Gateway auflöst, dann ermittelt er quasi die MAC-Adresse des...Routers und schickt dann die Frames dorthin, richtig?
Der Router "packt den Ethernetframe" aus, schaut sich die Ziel-IP (=8.8.8.8, also Google-DNS-Server) an und schickt das enthaltene IP-Paket an das nächste Gateway (=next hop = Router von meinem Provider?) weiter, richtig?

Wozu bedarf es noch der Routing-Tabelle? (Befehl "route print" bei Windows)

Ich hab den Zusammenhang zwischen Gateway bzw. Routing-Tabellen noch nicht verinnerlichen können.
Was das Gateway ist und wozu es gut ist weiß ich im Prinzip, aber die Routing-Tabellen bei Windows verwirren mich noch ein wenig.
Insbesondere die Spalte "Gateway" in der Tabelle verwirrt mich ein wenig.

Was ich weiß:
Im ARP-Cache stehen nur MAC-Adressen aus dem "lokalen" IP-Netz.
Also alle angeschlossenen "Rechner", also auch die IP des Routers und seine MAC ist drin
Für die Kommunikation mit anderen Netzen, z.B. dem WAN, wird ja immer der Router genutzt,
sprich Traffic für andere Netze wird an die MAC-Adresse des Routers gesendet, weil dieser einen Gateway zum Internet/Modem hat.

Magst du mir den Zusammenhang Gateway <> Routigtabelle kurz anreißen?
 
Zuletzt bearbeitet:
Die Routingtabelle sagt dem IP-Stack des OS, welche Zieladresse wie erreicht werden kann. Dadurch weiß der Rechner überhaupt erst, welche Gateways existieren. Was man im hübschen Einstellungsdialog einträgt oder was der Rechner per DHCP kriegt, landet in der Routingtabelle. Anders hätte es gar keine Auswirkung. Die Routingtabelle ist die einzige autoritative Quelle, damit das OS weiß, wohin die Pakete überhaupt müssen.
 
Jeder Rechner hat aber trotzdem eine Routingtabelle, auch wenn die auf Clients meist aus nicht mehr als "192.168.x/24 lokal über $interface, default über 192.168.x.y" besteht.
 
Und?

Die Routingtabelle hat nichts mit dem NAT im Router zu tun. Und nur auf letzteres habe ich mich bezogen.
 
Um NAT im Router gings aber gar nicht. Die Frage drehte sich um die Routingtabelle im Windows.
 
Sagst du.

Ich sage:
Einfache Situation: Modem > WLAN-Router > PC (Windows) und Notebook (Windows)
Das ist keine einfache Situation. Da, wie oben bereits angeführt, der "WLAN-Router" eben kein klassischer Router ist, wie man ihn aus der Netzwerktechnik kennt.

Daher dreht sich DEINE Antwort um die Routingtabelle in welchem OS auch immer.
Ich "behandle" das Thema was danach (oder davor) kommt, nämlich dann, wenn der Krempel ins Internet soll.
Zwischen einem klassischen Routing und einem NAT Routing besteht ein Unterschied. Dazu muss man sich nur den Unterschied in der Source-IP und Port anschauen.

EDIT:
Der Router "packt den Ethernetframe" aus, schaut sich die Ziel-IP (=8.8.8.8, also Google-DNS-Server) an und schickt das enthaltene IP-Paket an das nächste Gateway (=next hop = Router von meinem Provider?) weiter, richtig?

Und genau das tut der "WLAN-Router" eben nicht. Er passt nämlich vorher das Paket, wegen der NAT, an. Daher dreht sich die Frage schon um das Handling von Paketen im Router.
 
Zuletzt bearbeitet:
Nein, sagt der Fragensteller.


Ich sage:

Das ist keine einfache Situation. Da, wie oben bereits angeführt, der "WLAN-Router" eben kein klassischer Router ist, wie man ihn aus der Netzwerktechnik kennt.

Daher dreht sich DEINE Antwort um die Routingtabelle in welchem OS auch immer.
Ich "behandle" das Thema was danach (oder davor) kommt, nämlich dann, wenn der Krempel ins Internet soll.

Und selbst dann ändert NAT an der Routingtabelle gar nichts, ist NAT trivial und ein WLAN-Router in Bezug auf die Routingtabelle ein stinknormaler Router wie jeder andere, nur halt ggf. mit weniger Routen. Eine Routingtabelle ist eine Routingtabelle. Die funktioniert überall gleich, egal ob auf Clients, Plasteroutern oder Internetroutern.
 
Siehe EDIT.

Und ich wiederhole mich. Ich rede NICHT von Routingtabellen. Also drehe mir bitte nicht das Wort im Mund um.

EDIT:
Dass er das veränderte Paket nach seiner routingtable normal weiterverarbeitet stelle ich NICHT zur Diskussion.
 
Zuletzt bearbeitet:
Und genau das tut der "WLAN-Router" eben nicht. Er passt nämlich vorher das Paket, wegen der NAT, an. Daher dreht sich die Frage schon um das Handling von Paketen im Router.

NAT passiert, wenn das Paket das Interface verlässt. Da ist die Entscheidung nach Routingtabelle schon längst gefallen, sonst wüsste das OS gar nicht, auf welchem Interface das Paket rausgeht. Für die Betrachtung der Routingtabelle kann man NAT komplett ignorieren.
 
Zuletzt bearbeitet:
NAT passiert, wenn das Paket das Interface verlässt. Da ist die Entscheidung nach Routingtabelle schon längst gefallen, sonst wüsste das OS gar nicht, auf welchem Interface das Paket rausgeht. Für die Betrachtung der Routingtabelle kann man NAT komplett ignorieren.

Durchaus richtig. (aber auch da wiederhole ich mich, es geht mir nicht um die RTs, sondern um das, was da noch im Router passiert)
Nur DU bestehst darauf, dass es sich ausschließlich um die RTs dreht.

Und da homerouter nunmal NAT machen, geht es also nicht ausschließlich um die Routingtabellen sondern eben auch um das NAT.
Da du aber nicht der Mittelpunkt der Frage bist und nicht festlegst, welche Punkte im Router diskutiert werden sollen/dürfen...

Für klassisches Routing gibt es nur die RT. Da ich aber nicht glaube, dass der TE mit nem 3000EUR Cisco-Router klassisches Routing ins Internet betreibt, ist die NAT also durchaus erwähnungswert. Denn der Gute will verstehen, wie "sein" Netzwerk funktioniert.

EDIT:
Ich bin dann mal raus und lassen sich in deinem "nur RT ist interessant und NAT braucht keiner wissen"-Wahn weitermachen.
 
Zuletzt bearbeitet:
Für das, was gefragt wurde, spielt NAT absolut keine Rolle, weil es danach passiert. Das Routing ist fertig, und das Paket geht dann halt nicht mit Quelladresse 192.168.x.y raus sondern mit der öffentlichen Adresse a.b.c.d.

Vielleicht warten wir einfach mal, bis der OP zurückkommt. :>

Edit: Gut, ich sehs ein, NAT sollte man der Vollständigkeit halber erwähnen, damit das Bild komplett ist.
 
Zuletzt bearbeitet:
Hi,

für den Thread Ersteller mal eine kleine Erklärung bezüglich Routing Tabellen:

Du gehst aktuell von einem Rechner aus, welcher nur ein default Gateway hat, nämlich den lokalen Router. Ich gebe dir in sofern Recht, dass es bei einem solch einfachen Netz eigtl keine Routing Tabelle vorhanden sein müsste, da der Rechner eh nur einen Weg zum Ziel hat.

Aber nun ist das im World Wide Web nicht immer so. Es gibt da z.B. Server, welche mehr als ein Netzwerk Interface haben und es gibt Router, bis zu mehreren Hundert haben können.

Die Routing Tabelle sagt im Grunde genommen dem Router oder Server nicht anderes als, um das Netz X.X.X.X/X zu erreichen, nutze folgendes Interfaces und next-hop Gateway. Für Netz Y.Y.Y.Y/Y hingeben nimm ein anderes Interface.

Letzendlich kannst du Routing Tabellen als Verkehrsschilder mit Richtungsangaben sehen. Das Next-Hop Gateway ist in dem Fall die nächste Kreuzung mit Schildern. Das Interface ist die Straße, in welche das Schild zeigt.

Wenn du in der Routing Tabelle nun "Metriken" hast. Dann ist es ein Schild, welches zu einem Ziel 2 Wege hat. z.B. nach Links gehts nach Berlin ( 300km ) und nach Rechts gehts ebenfalls nach Berlin, jedoch 400km. Je niedriger die Metrik, um so Besser.
 
Auf Windows-Rechnern läuft standardmäßig ein Dienst namens "Computerbrowser".
Der klopft permanent das Netzwerk auf neue Computer ab.
Hat man einen DNS-Server im lokalen Netzwerk, kann man diesen Dienst auch deaktivieren.
 
Erwähnen sollte man noch, dass spezifischere Routen vorrangig gegenüber allgemeineren Routen gelten, bezogen auf die Netzmaske. Man kann also z.B. 192.168/16 über $interface1 routen, 192.168.0/24 über $interface2 und 192.168.0.42/32 wieder über $interface1.
 
Also ich wollte in der Tat ersteinmal die Routingtabellen auf dem OS verstehen.
Hab ja extra <Befehl "route print" bei Windows> erwähnt.

Ich möchte wie gesagt verstehen lernen, wie die Ethernet-Frames und Datenpakete bildlich durch alle OSI-Schichten wandern.
Oder anders umschrieben: ich möchte einmal als Datenpaket in der Daten-Achterbahn sitzen, und von PC-A zu PC-B fahren um zusehen, wie die "Post" arbeitet :)

Was man im hübschen Einstellungsdialog einträgt oder was der Rechner per DHCP kriegt, landet in der Routingtabelle.
Tatsache. :d Danke für den ultra wichtigen Hinweis.
Hab am PC probeweise eine 2. "Netzwerkkarte" rangesteckt (WLAN-Stick) und diese taucht dann tatsächlich auch in der Tabelle auf.

Die Frage dazu ist: wozu gibt es die Spalte Gateway?
Ich verstehe, dass die Spalte "Schnittstelle" das Interface, also der zu verwendende "Ausgang" für das jeweilige IP-Paket ist.
Sprich: OS liest Ziel-IP im Header des Paketes aus und vergleicht die Ziel-IP mit den Einträgen in der Tabelle...?
Wofür steht "Auf Verbindung" ?
Wird die Standard-Gateway-Adresse irgendwo auf dem Ethernetframe vermerkt...?




Ich habe versucht eure Beschreibungen und Erklärungen mir bildlich vorzustellen.
Könnt Ihr meine Beschreibungen überprüfen und ggf. Fehler markieren?

Beispielsituation:
Modem: IP 33.33.33.33 >> Heimrouter:192.168.1.1/24 >> PC2:192.168.1.2/24 und PC3:192.168.1.3/24

Situation 1
Webbrowser auf PC2 will Daten an PC3 schicken
>>erstellt IP-Paket mit Ziel-IP-adresse: 192.168.1.3
>>gibt IP-Paket an OS weiter

OS:
- schaut in der Routingtabelle nach
- aha, Eintrag vorhanden: Subnetz 192.168.1.0/24 geht über Interface/Schnittstelle "192.168.1.2" raus.
- braucht Zie-MAC-Adresse um Frame fertig zu machen: schaut in der ARP-Tabelle nach
- aha, zu 192.168.1.3 gehört MAC-Adresse: BB.BB.BB.BB.BB.BB
>>erstellt Ethernet-Frame, legt IP-Paket hinein, Ziel-MAC-Adresse: BB.BB.BB.BB.BB.BB
>>gibt Ethernet-Frame an Netzwerkstack (?) >> Frame geht über Interface/Schnittstelle "192.168.1.2" zum Switch

Switch:
- Switch empfängt Ethernet-Frame > schaut sich MAC-Adresse an > gleicht MAC-Adresse mit dem Eintrag in seiner SAT ab.
- aha, BB.BB.BB.BB.BB.BB hängt am Port2 > Paket an Port2 weiterleiten
Frage:
- ist der beschriebene Weg richtig?
- auch wenn beide Rechner per HeimRouter verbunden sind, geschieht die Kommunikation im LAN eigentlich nur über den
integrierten Switch im Router, richtig? Es wird also nix geroutet...?



Situation 2
Webbrowser auf PC2 will Daten an Webserver schicken, wartet auf Antwortpakete mit Portnummer 55444
>>reserviert sich Socket: 192.168.1.2:55444
>>erstellt IP-Paket mit
Quell-IP-Adresse: 192.168.1.2:55444
Ziel-IP-adresse: 11.11.11.11:80 (IP wurde vorher durch DNS-Server herausgefunden)
>>gibt Paket an OS weiter

OS:
- schaut in der Routingtabelle nach
- aha, Eintrag 11.11.11.11 NICHT vorhanden, also nehme ich die Zeile:
Netzwerkziel 0.0.0.0, NM 0.0.0.0, Gateway 192.168.1.1, Schnittstelle 192.168.1.2
sprich: geht über Interface/Schnittstelle "192.168.1.2" raus.
- braucht MAC-Adresse um Frame fertig zu machen: schaut in der ARP-Tabelle nach
- aha, zum Gateway 192.168.1.1 (=Router) gehört MAC-Adresse: CC.CC.CC.CC.CC.CC
>>erstellt Ethernet-Frame, legt IP-Paket hinein, Ziel-MAC-Adresse: CC.CC.CC.CC.CC.CC
>>gibt Ethernet-Frame an Netzwerkstack (?) >> Frame geht über Interface/Schnittstelle "192.168.1.2" zum Switch im Router

Switch: (im Router integriert)
- Switch empfängt Ethernet-Frame > schaut sich MAC-Adresse an > gleicht MAC-Adresse mit dem Eintrag in seiner SAT ab.
- CC.CC.CC.CC.CC.CC geht an Router

Router:
- packt Ethernetframe aus und liest Header von IP-Paket aus.
- aha, IP-Paket stammt von 192.168.1.2, geht an 11.11.11.11:80, und 192.168.1.2 wünscht sich Antwortpaket am Port 55444
55444 leider schon vergeben, also mache ich Port 55666 daraus und merke mir dies (=NAT?)
- Router schickt IP-Paket an Server:
Quell-IP-Adresse: 33.33.33.33:55666
Ziel-IP-Adresse: 11.11.11.11:80

Server:
- empfängt Anfragepaket und schickt Antwortpaket zurück:
Quell-IP-Adresse: 11.11.11.11:80
Ziel-IP-Adresse: 33.33.33.33:55666

Router:
- empfängt Antwortpaket an Port 55666, schickt Paket an 192.168.1.2:55444
Frage:
- ist der beschriebene Weg richtig?
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh