Zum Inhalt wechseln


Foto

Windows Netzwerk und Subnetting


  • Bitte melde dich an um zu Antworten
21 Antworten in diesem Thema

#16 Reingucker

Reingucker

    Senior Member

  • 397 Beiträge

 

Geschrieben 14. Januar 2017 - 09:15

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.

 

 

 

Angehängte Datei  arp2.png   324,23K   0 Mal heruntergeladen

 

 

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.



#17 Reingucker

Reingucker

    Senior Member

  • 397 Beiträge

 

Geschrieben 14. Januar 2017 - 23:37

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

 

Angehängte Datei  arp_mit_redirect.png   378,56K   0 Mal heruntergeladen

 

 

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.

 

Angehängte Datei  html.png   356,38K   0 Mal heruntergeladen


Bearbeitet von Reingucker, 15. Januar 2017 - 17:09.


#18 zahni

zahni

    Expert Member

  • 16.520 Beiträge

 

Geschrieben 16. Januar 2017 - 08:25

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.


Wen du nicht mit Können beeindrucken kannst, den verwirre mit Schwachsinn!


#19 Reingucker

Reingucker

    Senior Member

  • 397 Beiträge

 

Geschrieben 16. Januar 2017 - 09:08

Ja, aber ist das dann Arp-Proxy?



#20 zahni

zahni

    Expert Member

  • 16.520 Beiträge

 

Geschrieben 16. Januar 2017 - 11:30

https://en.wikipedia.../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.


Wen du nicht mit Können beeindrucken kannst, den verwirre mit Schwachsinn!


#21 Reingucker

Reingucker

    Senior Member

  • 397 Beiträge

 

Geschrieben 16. Januar 2017 - 13:57

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.

#22 zahni

zahni

    Expert Member

  • 16.520 Beiträge

 

Geschrieben 16. Januar 2017 - 14:44

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


Wen du nicht mit Können beeindrucken kannst, den verwirre mit Schwachsinn!