8
Standardgateway logisch nicht im selben Subnetz?
Guten Tag zusammen 
Ich arbeite hier gerade ein paar Fragen zur Prüfungsvorbereitung durch, und dabei ist mir etwas unklar:
Als Info ist gegeben, dass ein neu installierter PC mit der IP 192.168.2.93, der SNMask 255.255.255.192 und der Gteway-Adresse 192.168.2.222 konfiguriert wurde.
Die Frage ist nun, warum der PC "nicht mit anderen Hosts im LAN kommunizieren kann".
Als erstes fällt natürlich auf, dass das Gateway nicht im selben Subnetz liegt wie der PC. Es erschließt sich mich allerdings nicht ganz, warum der PC deswegen nicht mit anderen Hosts im LAN kommunizieren können soll. Meiner Meinung nach kann der PC sehr wohl, zumindest mit den Hosts im selben Subnetz, kommunizieren. Und rein theoretisch müsste der PC doch auch mit Hosts aus anderen Subnets reden können: Wenn er ein Paket an eine IP in einem anderen Subnet hat, packt er das in einen Frame und adressiert diesen an die MAC-Adresse des Gateways 192.168.2.222, falls dieses physikalisch am selben Netz hängt und sich somit per ARP dessen MAC-Adresse überhaupt ermitteln lässt. Auf dem Rückweg müsste das doch genauso funktionieren, fals der Router so konfiguriert ist, dass er alle Pakete für 192.168.2.2/26 über sein Interface 192.168.2.222 rausschickt.
Also ich denke, dass der PC theoretisch schon mit anderen Hosts kommunizieren kann, der Haken liegt wohl eher in der Konfiguration der anderen Netzwerkgeräte. Habe ich hier irgendwo einen Denkfehler?
Für Kommentare wäre ich sehr dankbar, ich lass' mich gerne eines besseren belehren
Viele Grüße
Michl
Ich arbeite hier gerade ein paar Fragen zur Prüfungsvorbereitung durch, und dabei ist mir etwas unklar:
Als Info ist gegeben, dass ein neu installierter PC mit der IP 192.168.2.93, der SNMask 255.255.255.192 und der Gteway-Adresse 192.168.2.222 konfiguriert wurde.
Die Frage ist nun, warum der PC "nicht mit anderen Hosts im LAN kommunizieren kann".
Als erstes fällt natürlich auf, dass das Gateway nicht im selben Subnetz liegt wie der PC. Es erschließt sich mich allerdings nicht ganz, warum der PC deswegen nicht mit anderen Hosts im LAN kommunizieren können soll. Meiner Meinung nach kann der PC sehr wohl, zumindest mit den Hosts im selben Subnetz, kommunizieren. Und rein theoretisch müsste der PC doch auch mit Hosts aus anderen Subnets reden können: Wenn er ein Paket an eine IP in einem anderen Subnet hat, packt er das in einen Frame und adressiert diesen an die MAC-Adresse des Gateways 192.168.2.222, falls dieses physikalisch am selben Netz hängt und sich somit per ARP dessen MAC-Adresse überhaupt ermitteln lässt. Auf dem Rückweg müsste das doch genauso funktionieren, fals der Router so konfiguriert ist, dass er alle Pakete für 192.168.2.2/26 über sein Interface 192.168.2.222 rausschickt.
Also ich denke, dass der PC theoretisch schon mit anderen Hosts kommunizieren kann, der Haken liegt wohl eher in der Konfiguration der anderen Netzwerkgeräte. Habe ich hier irgendwo einen Denkfehler?
Für Kommentare wäre ich sehr dankbar, ich lass' mich gerne eines besseren belehren
Viele Grüße
Michl
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 117163
Url: https://administrator.de/forum/standardgateway-logisch-nicht-im-selben-subnetz-117163.html
Ausgedruckt am: 22.12.2024 um 20:12 Uhr
8 Kommentare
Neuester Kommentar
Scheinbar hast du noch ein bischen Übung nötig bevor es zur Prüfung geht, denn die Kenntnisse des IP Protokolls weisen noch erhebliche Lücken auf bei dir.
Generell gilt: Ohne einen Router können unterschiedliche IP Netze NICHT miteinander kommunizieren !!!
(Tricks wie Secondary IPs oder Proxy ARP lassen wir jetzt mal bewusst außen vor !)
Du hast ein paar Lücken was den IP Kommunikationsaufbau anbetrifft.
Bevor eine Verbindung aufgebaut wird benötigt der TCP/IP Stack die OSI Layer 2 Mac Adresse seines Gegenübers, er schickt also erstmal ein ARP Paket los per Broadcast:
Falls du nicht weisst was das ist:
http://de.wikipedia.org/wiki/Address_Resolution_Protocol
Soweit reichte es bei dir ja noch....
Der Stack merkt anhand der Subnetzmaske ob der ARP an die Subnetz Broadcast Adresse gehen soll oder nicht.
Liegt die Ziel IP innerhalb des Subnetzes ARPt er nach der Host Zieladresse, liegt sie NICHT innerhalb des Subnetzes ARPt er nach der Gateway Adresse die im selben Subnetz liegen muss !!!
Ist kein Gateway eingetragen verwirft er das Paket und du bekommst eine ICMP unreachable Message !
Zielrechner antworten natürlich nur auf den ARP Broadcast wenn der auch in ihrem Bereich der Subnetzmaske liegt !! Aus diesem Grund würden andere Broadcast Adressen schlicht ignoriert und folglich käme keine Kommunikation mit netzfremden Hosts je zustande !
Der Grund warum ein ARP bei deinem Beispiel oben ins Leer läuft da das Gateway NICHT im gleichen Subnetz ist ! Richtig erkannt !! Ein ARP würde gleich verworfen werden....
Wenn du dir nur mal die Mühe gemacht hättest das mit einem Wireshark Sniffer in einem Netz quasi als Prüfungsvorberitungsaufgabe zu verifizieren hättest du die o.a. Frage gar nicht stellen müssen !
Anhand dieser Logik ist es also vollkommen klar das ein IP Endgerät niemals mit IP Adressen außerhalb seines eigenen Subnetzes kommunizieren kann.
Was du also vermutest ist frei erfundener Unsinn ! Wie gesagt Techniken wie Secondary IPs oder Proxy ARP mal nicht eingerechnet.
Eine weiterführende Lektüre die du vor der Prüfung lesen solltest ist:
http://de.wikipedia.org/wiki/Routing
Ob das dann für die Prüfung reicht.... ??!!
Generell gilt: Ohne einen Router können unterschiedliche IP Netze NICHT miteinander kommunizieren !!!
(Tricks wie Secondary IPs oder Proxy ARP lassen wir jetzt mal bewusst außen vor !)
Du hast ein paar Lücken was den IP Kommunikationsaufbau anbetrifft.
Bevor eine Verbindung aufgebaut wird benötigt der TCP/IP Stack die OSI Layer 2 Mac Adresse seines Gegenübers, er schickt also erstmal ein ARP Paket los per Broadcast:
Falls du nicht weisst was das ist:
http://de.wikipedia.org/wiki/Address_Resolution_Protocol
Soweit reichte es bei dir ja noch....
Der Stack merkt anhand der Subnetzmaske ob der ARP an die Subnetz Broadcast Adresse gehen soll oder nicht.
Liegt die Ziel IP innerhalb des Subnetzes ARPt er nach der Host Zieladresse, liegt sie NICHT innerhalb des Subnetzes ARPt er nach der Gateway Adresse die im selben Subnetz liegen muss !!!
Ist kein Gateway eingetragen verwirft er das Paket und du bekommst eine ICMP unreachable Message !
Zielrechner antworten natürlich nur auf den ARP Broadcast wenn der auch in ihrem Bereich der Subnetzmaske liegt !! Aus diesem Grund würden andere Broadcast Adressen schlicht ignoriert und folglich käme keine Kommunikation mit netzfremden Hosts je zustande !
Der Grund warum ein ARP bei deinem Beispiel oben ins Leer läuft da das Gateway NICHT im gleichen Subnetz ist ! Richtig erkannt !! Ein ARP würde gleich verworfen werden....
Wenn du dir nur mal die Mühe gemacht hättest das mit einem Wireshark Sniffer in einem Netz quasi als Prüfungsvorberitungsaufgabe zu verifizieren hättest du die o.a. Frage gar nicht stellen müssen !
Anhand dieser Logik ist es also vollkommen klar das ein IP Endgerät niemals mit IP Adressen außerhalb seines eigenen Subnetzes kommunizieren kann.
Was du also vermutest ist frei erfundener Unsinn ! Wie gesagt Techniken wie Secondary IPs oder Proxy ARP mal nicht eingerechnet.
Eine weiterführende Lektüre die du vor der Prüfung lesen solltest ist:
http://de.wikipedia.org/wiki/Routing
Ob das dann für die Prüfung reicht.... ??!!
Dazu mal eine kleine Anmerkung von mir...
Ich habe einen vServer bei HostEurope der mittels Virtuozzo umgesetzt wird. Mein virtueller Netzwerkadapter hat eine öffentliche IP (80.x.x.x), hat aber als Standardgateway eine lokale IP (192.168.0.0/22) eingetragen.
Laut "route print" wird der Standardgateway über den Netzwerkadapter mit der öffentlichen IP angesprochen, obwohl dieser die private IP nicht kennen dürfte.
Mich irritiert, dass das funktioniert. Wireshark kann ich leider auf der VM nicht anwerfen, daher weiß ich nicht wie und warum das auf ARP Eben funktioniert.
Mich nervt an der Tatsache auch, dass ich nicht weiß, wieso (hier Windows Server 2003) die lokale IP grade über den Netzwerkadapter mit der öffentlichen IP angesprochen wird, statt z.B. über den Loopback Adapter.
Ich traue mich daher auch nicht die IP Konfiguration meines Servers anzutasten, da ich Angst habe, er ist danach vielleicht nicht mehr erreichbar ^^
Sobald ich in der IP Konfiguration versuche etwas zu ändern, sagt mir Windows eh, dass der Gateway ausserhalb des Netzes liegt und das nicht funktionieren wird.
Diese Art Konfiguration scheint bei Virtuozzo gängige Praxis zu sein... Ich werde mal HE anschreiben und ein paar mehr Infos einholen... Würde nämlich gerne OpenDNS verwenden ohne meinen Server unerreichbar zu machen ;)
Rein generell bin ich aber auch der Meinung, dass ein PC nur mit dem eigenen Subnetz aber nicht mit anderen kommunizieren kann, wenn der Gateway ausserhalb des eigenen Subnetzes liegt.
Zumindest theoretisch ist das so gedacht... Praktisch sieht es ganz offensichtlich anders aus ;)
Ich habe einen vServer bei HostEurope der mittels Virtuozzo umgesetzt wird. Mein virtueller Netzwerkadapter hat eine öffentliche IP (80.x.x.x), hat aber als Standardgateway eine lokale IP (192.168.0.0/22) eingetragen.
Laut "route print" wird der Standardgateway über den Netzwerkadapter mit der öffentlichen IP angesprochen, obwohl dieser die private IP nicht kennen dürfte.
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.111.153 87.230.89.99 10
87.230.88.0 255.255.252.0 87.230.89.99 87.230.89.99 10
87.230.89.99 255.255.255.255 127.0.0.1 127.0.0.1 10
87.255.255.255 255.255.255.255 87.230.89.99 87.230.89.99 10
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
224.0.0.0 240.0.0.0 87.230.89.99 87.230.89.99 10
255.255.255.255 255.255.255.255 87.230.89.99 87.230.89.99 1
Default Gateway: 192.168.111.153Mich irritiert, dass das funktioniert. Wireshark kann ich leider auf der VM nicht anwerfen, daher weiß ich nicht wie und warum das auf ARP Eben funktioniert.
Mich nervt an der Tatsache auch, dass ich nicht weiß, wieso (hier Windows Server 2003) die lokale IP grade über den Netzwerkadapter mit der öffentlichen IP angesprochen wird, statt z.B. über den Loopback Adapter.
Ich traue mich daher auch nicht die IP Konfiguration meines Servers anzutasten, da ich Angst habe, er ist danach vielleicht nicht mehr erreichbar ^^
Sobald ich in der IP Konfiguration versuche etwas zu ändern, sagt mir Windows eh, dass der Gateway ausserhalb des Netzes liegt und das nicht funktionieren wird.
Diese Art Konfiguration scheint bei Virtuozzo gängige Praxis zu sein... Ich werde mal HE anschreiben und ein paar mehr Infos einholen... Würde nämlich gerne OpenDNS verwenden ohne meinen Server unerreichbar zu machen ;)
Rein generell bin ich aber auch der Meinung, dass ein PC nur mit dem eigenen Subnetz aber nicht mit anderen kommunizieren kann, wenn der Gateway ausserhalb des eigenen Subnetzes liegt.
Zumindest theoretisch ist das so gedacht... Praktisch sieht es ganz offensichtlich anders aus ;)
Mmmmhhh da sind in der Tat erhebliche Ungereimtheiten:
Du gibst an das das Gateway im Bereich 192.168.0.0 mit einer 22 Bit Subnetzmaske (255.255.252.0) liegen soll !
Der gültige Adressbereich für dieses Subnetz wäre dann 192.168.0.1 bis 192.168.3.254 !!
Die 192.168.111.153 liegt damit aber ebenso total außerhalb !!
Vermutlich hast du hier aber wohl selber einen IP Adressierungsfehler oder nur Schreibfehler begangen, den du meinst vermutlich das Subnetz 192.168.108.0 das dann gültige IP Host Adressen von 192.168.108.1 bis 192.168.111.254 hat ??!!
Nach dem Printout von oben ist das Gateway auf der vollkommen 192.168.111.153 unsinnig.
Schon allein aus dem Grunde weil das 192.168er Netz ist ein RFC 1918 Netzwerk was im Internet gar nicht geroutet wird. Aktiv darf diese IP also im Routing Pfad gar nicht auftauchen !! Daraus lässt sich mit ziemlicher Sicherheit schliessen das sie nach außen niemals benutzt wird wenn überhaupt !
Wenn dann kann es nur in der Virtualisierung laufen oder beim Hoster dann direkt der es dann irgendwo mit NAT wieder umsetzen müsste.
IP mässig kann das also nicht stimmen.
Man müsste jetzt mal genau nachlesen wie Virtuozzo oder OpenVZ die IP Adressierung mit virtuellen Maschinen machen.
Mal suchen obs da was gibt....
Du gibst an das das Gateway im Bereich 192.168.0.0 mit einer 22 Bit Subnetzmaske (255.255.252.0) liegen soll !
Der gültige Adressbereich für dieses Subnetz wäre dann 192.168.0.1 bis 192.168.3.254 !!
Die 192.168.111.153 liegt damit aber ebenso total außerhalb !!
Vermutlich hast du hier aber wohl selber einen IP Adressierungsfehler oder nur Schreibfehler begangen, den du meinst vermutlich das Subnetz 192.168.108.0 das dann gültige IP Host Adressen von 192.168.108.1 bis 192.168.111.254 hat ??!!
Nach dem Printout von oben ist das Gateway auf der vollkommen 192.168.111.153 unsinnig.
Schon allein aus dem Grunde weil das 192.168er Netz ist ein RFC 1918 Netzwerk was im Internet gar nicht geroutet wird. Aktiv darf diese IP also im Routing Pfad gar nicht auftauchen !! Daraus lässt sich mit ziemlicher Sicherheit schliessen das sie nach außen niemals benutzt wird wenn überhaupt !
Wenn dann kann es nur in der Virtualisierung laufen oder beim Hoster dann direkt der es dann irgendwo mit NAT wieder umsetzen müsste.
IP mässig kann das also nicht stimmen.
Man müsste jetzt mal genau nachlesen wie Virtuozzo oder OpenVZ die IP Adressierung mit virtuellen Maschinen machen.
Mal suchen obs da was gibt....
Du hast natürlich recht, 192.168.0.0/22 war falsch, das hab ich nur unbedacht schnell hingeschrieben... aber die Angaben der Routing-Tabelle sind so korrekt.
Bei einem ausgehenden Tracert ist der erste Hop auch wirklich 192.168.111.153, der zweite ist dann 87.230.88.1.
Laut ARP Cache haben 192.168.111.153 und 87.230.88.1 die selbe MAC Adresse.
Unabhängig davon, dass Virtuozzo hier sicher intern irgendein NAT oder ähnliches veranstaltet, wundert mich eben schon die Tatsache, dass Windows Server 2003 den Spass überhaupt mitmacht. Und noch mehr frage ich mich, wozu dies nötig ist?! Ich hab schonmal versucht etwas dazu heraus zu finden, bin aber nicht weit gekommen... Mich würde ja interessieren was passiert, wenn ich einfach 87.230.88.1 als Gateway angeben würde... aber ich will die VM hald nicht abschießen :D
Bei einem ausgehenden Tracert ist der erste Hop auch wirklich 192.168.111.153, der zweite ist dann 87.230.88.1.
Laut ARP Cache haben 192.168.111.153 und 87.230.88.1 die selbe MAC Adresse.
Unabhängig davon, dass Virtuozzo hier sicher intern irgendein NAT oder ähnliches veranstaltet, wundert mich eben schon die Tatsache, dass Windows Server 2003 den Spass überhaupt mitmacht. Und noch mehr frage ich mich, wozu dies nötig ist?! Ich hab schonmal versucht etwas dazu heraus zu finden, bin aber nicht weit gekommen... Mich würde ja interessieren was passiert, wenn ich einfach 87.230.88.1 als Gateway angeben würde... aber ich will die VM hald nicht abschießen :D
Das OpenVZ Handbuch auf dem Virtuozzo basiert ist da leider auch nur recht oberflächlich:
http://download.openvz.org/doc/OpenVZ-Users-Guide.pdf
Vermutlich nutzt der VPS aber im internen Netzwerk das ihn mit dem Node (Host) verbindet ein RFC 1918 Netzwerk und macht wohl statisches NAT zum Node (Host).
Der Host hat vermutlich ein statisches 1 zu 1 NAT das die öffentliche IPs des Hosters direkt auf die internen VPS umsetzt, anders ist die o.a. Funktion nicht zu erklären.
Virtuozzo unterbindet so vermutlich das einzelne VPS sich sehen können auf dem Host, denn das muss beim Provider absolut verhindert werden um gegenseitige Schnüffelei mit Sniffern zu unterbinden.
Um das aber 100%ig zu klären müsste man tiefer in Virtuozzo einsteigen bzw. die Installation des Hosters kenne, die der sicher aus verständlichen Gründen etwas geheim hält...
Mit den Infos sollte gi_networx seine Prüfung nun aberwohl sicher bestehen wenn er nochmal in sich geht...
http://download.openvz.org/doc/OpenVZ-Users-Guide.pdf
Vermutlich nutzt der VPS aber im internen Netzwerk das ihn mit dem Node (Host) verbindet ein RFC 1918 Netzwerk und macht wohl statisches NAT zum Node (Host).
Der Host hat vermutlich ein statisches 1 zu 1 NAT das die öffentliche IPs des Hosters direkt auf die internen VPS umsetzt, anders ist die o.a. Funktion nicht zu erklären.
Virtuozzo unterbindet so vermutlich das einzelne VPS sich sehen können auf dem Host, denn das muss beim Provider absolut verhindert werden um gegenseitige Schnüffelei mit Sniffern zu unterbinden.
Um das aber 100%ig zu klären müsste man tiefer in Virtuozzo einsteigen bzw. die Installation des Hosters kenne, die der sicher aus verständlichen Gründen etwas geheim hält...
Mit den Infos sollte gi_networx seine Prüfung nun aberwohl sicher bestehen wenn er nochmal in sich geht...
Danke für die Aufklärung und die Motivation zur Prüfung ;)
Nein ehrlich,durch genaues gedankliches Durchspielen oder eben mitsniffen hätte ich darauf wohl auch selber kommen können bzw. müssen. Aber wie so oft hab ich da wohl mal wieder Quantität vor Qualität gestellt
Trotzdem vielen Dank für die schnelle ausführliche Antwort!
Viele Grüße
Michl
Nein ehrlich,durch genaues gedankliches Durchspielen oder eben mitsniffen hätte ich darauf wohl auch selber kommen können bzw. müssen. Aber wie so oft hab ich da wohl mal wieder Quantität vor Qualität gestellt
Trotzdem vielen Dank für die schnelle ausführliche Antwort!
Viele Grüße
Michl
Immer gerne wieder....
Dann aber bitte auch
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !!
Dann aber bitte auch
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !!
Weil man dieses Thema sehr schnell in Google findet, wenn man nach Standardgateway und so weiter sucht hier für alle noch kommenden eine Richtigstellung:
1.) Es gibt durchaus Geräte, die ARP-Anfragen auch aus fremden Subnetzen beantworten - viele "große" Router tun das definitiv, bei Windows-Client-Büchsen mag das anders aussehen.
2.) Muss das Standardgateway nicht unbedingt im selben logischen Netzwerk liegen. Ich kann durchaus auch die IP eines fremden logischen Netzwerkes im gleichen physikalischen Netzwerk angeben, wenn ich eine statische route definiere, bzw. die IP auf dem Interface bekannt mache. Unter Linux würde man das z.B. so realisieren:
ws1 ~ # ifconfig | grep inet
inet 80.255.8.78 netmask 255.255.255.192 broadcast 80.255.8.127
inet 127.0.0.1 netmask 255.0.0.0
ws1 ~ # ping 8.8.8.8
connect: Network is unreachable
ws1 ~ # route add 81.95.4.1 eth0
ws1 ~ # route add default gw 81.95.4.1
ws1 ~ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=51 time=6.22 ms
Bei Windows (hab 's nur auf Server 2008 getestet) genügt einfach die Eingabe des Standard Gateways außerhalb des lokalen logischen Netzwerks. Man quittiert einfach die Warnung und gut ist 's.
1.) Es gibt durchaus Geräte, die ARP-Anfragen auch aus fremden Subnetzen beantworten - viele "große" Router tun das definitiv, bei Windows-Client-Büchsen mag das anders aussehen.
2.) Muss das Standardgateway nicht unbedingt im selben logischen Netzwerk liegen. Ich kann durchaus auch die IP eines fremden logischen Netzwerkes im gleichen physikalischen Netzwerk angeben, wenn ich eine statische route definiere, bzw. die IP auf dem Interface bekannt mache. Unter Linux würde man das z.B. so realisieren:
ws1 ~ # ifconfig | grep inet
inet 80.255.8.78 netmask 255.255.255.192 broadcast 80.255.8.127
inet 127.0.0.1 netmask 255.0.0.0
ws1 ~ # ping 8.8.8.8
connect: Network is unreachable
ws1 ~ # route add 81.95.4.1 eth0
ws1 ~ # route add default gw 81.95.4.1
ws1 ~ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=51 time=6.22 ms
Bei Windows (hab 's nur auf Server 2008 getestet) genügt einfach die Eingabe des Standard Gateways außerhalb des lokalen logischen Netzwerks. Man quittiert einfach die Warnung und gut ist 's.
