Windows Netzwerk und Subnetting

[Reingucker 3]

Nachdem nun klar ist was "normaler Weise" auf dem Kabel passiert, kommt jetzt das gleiche Szenario, also gleiche Rechnereinstellungen, nur diesmal mit dem falschen Gateway in der gleichen Broadcastdomäne.

 

 

 

 

 

Hier sieht man daß wie auch zuvor der Rechner einen Arp raus aufs Kabel schickt um das falsche Gateway, welches ja in einem anderen Subnetz ist, zu finden - und bekommt auch eine Antwort weill der Arp es ja erreicht (Farbe Rot). Darauf hin schickt der Rechner die Pakete an dieses Gateway, bekommt aber hier in meinem Szenario natürlich vom Gateway nur "not found" weil das Gateway keine Routen nach woanders hin hat (Farbe Grün). Das Gateway aber, welches die Pakete ja weiter schicken möchte, fängt jetzt selbst an mit Arp (da keine routen vorhanden) nach der 8.8.8.8 in dieser Broadcastdomäne zu suchen (Farbe Gelb). Fals jetzt ein Rechner mit der 8.8.8.8 in dieser Broadcastdomäne vorhanden wäre, dann bekäme das Gateway antwort und würde die Pakete vom Ursprungsrechner weiter leiten und zurück (normaler Weise, abhängig von den Gateway/Router Einstellungen)

 

Und das ist der Grund warum in dem Szenario des TO er trotzdem eine Verbindung bekommt, obwohl das Gateway zwar im falschen Subnet ist, aber in der gleichen Broadcastdomäne.

[Reingucker 3]

Ah, und wenn dann in diesem Szenario das "Gateway" mit seiner einen und einzigen Nic und mit seiner einen und einzigen IP das routing aktiviert hat und wir die IP/Adressräume des TO einsetzen, dann sieht das so aus

 

 

 

Wobei der Rechner 1

 

nur eine Nic

10.0.0.65

255.255.255.192

10.0.0.1

 

Rechner 2 (spielt hier Gateway)

 

nur eine Nic

10.0.0.1

255.255.255.192

routing aktiviert

 

Rechner 3

 

nur eine Nic

10.0.0.62

255.255.255.192

10.0.0.1

 

Alle mit ihrer einen Nic in der gleichen Broadcastdomäne.

 

Hmm, weiter ausführen tu ich es mal nicht.

 

Edit:

 

Hier noch der Zugriff auf eine Webseite auf Rechner 3 von Rechner 1 aus. Hatte ich vergessen. Wie man sieht funktioniert er und die Webseite kann mit dem Browser angezeigt werden. Die Queues auf Rechner 2 für out of order Pakete sind allerdings nicht optimiert (weiß im Moment auch gar nicht wie man das auf Server 2013 r2 macht). Daher viel Retransmission ect. Ist halt kein spezialisierter Router.

 

bearbeitet 15. Januar 2017 von Reingucker

[zahni 554]

Kurzfassung: Wenn das Gerät, aus welchen Gründen auch immer, per ARP für eine beliebige IP-Adresse nach der MAC zu fragen, kann er mit dieser IP kommunizieren, wenn er per ARP eine Antwort erhält.

Denn dann haben wir Layer 2.

[Reingucker 3]

Ja, aber ist das dann Arp-Proxy?

[zahni 554]

https://en.wikipedia.org/wiki/Proxy_ARP

 

Wird wohl hauptsächlich für VPN genutzt. Damit kann man ein Remote-Gerät so einbinden, als ob es sich im lokalen Netz  befindet.

[Reingucker 3]

Also ist es im Fall des TO kein Arp-proxy. Dann wäre es eine routing geschichte- und das obwohl das einzige Gateway in einem anderen Subnetz sitzt.

[zahni 554]

Wie ich schon weiter oben schrieb: Die  IP-Adresse des Routers muss in jedem Fall per ARP aufgelöst werden. Daher klappt der Zugriff. Da es die Router-IP ist kann der Client sie nicht zu einem Router schicken ;)