27
Wake on LAN geht vom Router aus, aber nicht von PC
Hallo zusammen,
ich möchte einen Rechner mit einem kaputten Schalter per WoL einschalten. Von meinem Draytek-Router aus geht das. Von einem anderen PC aus mit einem WoL-Programm geht es nicht.
Gibt es dafür eine Erklärung? Laut einigen Fundstellen im Internet muss man an der Firewall nur was ändern, wenn man den WoL-Befehl von außerhalb des Netzes erteilen will.
Danke im Voraus,
Sarek \\//_
ich möchte einen Rechner mit einem kaputten Schalter per WoL einschalten. Von meinem Draytek-Router aus geht das. Von einem anderen PC aus mit einem WoL-Programm geht es nicht.
Gibt es dafür eine Erklärung? Laut einigen Fundstellen im Internet muss man an der Firewall nur was ändern, wenn man den WoL-Befehl von außerhalb des Netzes erteilen will.
Danke im Voraus,
Sarek \\//_
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: 4080282479
Url: https://administrator.de/forum/wake-on-lan-geht-vom-router-aus-aber-nicht-von-pc-4080282479.html
Ausgedruckt am: 21.12.2024 um 15:12 Uhr
27 Kommentare
Neuester Kommentar
Hallo,
vielleicht darum? WoL L2/L3?
Oder ein Mikrosegmentierungsmechanismus? Mehr Infos zu deinem Setup wären nicht schlecht.
Grüße
TA
vielleicht darum? WoL L2/L3?
Oder ein Mikrosegmentierungsmechanismus? Mehr Infos zu deinem Setup wären nicht schlecht.
Grüße
TA
Am Router (Draytek 2762) hängt ein SOHO-Switch (D-Link DGS-1005D).
An dem Switch hängt sowohl mein PC mit diesem WoL-Tool als auch der zu startende PC.
Sende ich den Aufwachbefehl über die entsprechende Funktion des Draytek startet der PC. Sende ich es über das Tool vom PC, passiert nichts. Das Tool ist wie folgt eingestellt:
Der dazwischenliegende Switch ist in beiden Fällen der selbe, an dem L2/L3-Problem sollte es also nicht liegen.
An dem Switch hängt sowohl mein PC mit diesem WoL-Tool als auch der zu startende PC.
Sende ich den Aufwachbefehl über die entsprechende Funktion des Draytek startet der PC. Sende ich es über das Tool vom PC, passiert nichts. Das Tool ist wie folgt eingestellt:
Der dazwischenliegende Switch ist in beiden Fällen der selbe, an dem L2/L3-Problem sollte es also nicht liegen.
Geht aber auch nicht
Und um ganz sicher zu gehen, habe ich das Tool auch als Firewall-Ausnahme definiert, obwohl das ja angeblich nicht nötig ist.
Wenn der Aufweckport den du definiert hast stimmt dann blockiert eine Firewall oder ein Gerät dazwischen den magic packet, oder das Packet geht vorher verloren.
N’Abend,
da dein D-Link-Switch ein stinknormaler L2-Switch ist (dieser also von L3/IPs keine Ahnung hat), geht es folglich um reinen Broadcast im selben Netzwerksegment. „Directed broadcast“, um Netzwerkgrenzen zu überwinden, muss somit nicht beachtet werden.
Nun wäre es interessant, ob vom „Sende-PC“ beim aufzuweckenden PC das Magic Packet eingeht - und wie es im Vergleich zum Magic Packet des Routers aufgebaut ist.
Starte doch mal Whireshark (gerne als Live-System z.B. „Kali“) mit Filter auf Broadcast auf dem aufzuweckenden PC (oder ein dritter PC/Laptop) und beobachte das Ganze. Dann solltest du mehr wissen.
Hintergrund: neben dem „Standard-Magic Packet“ gibt es auch andere Bauformen.
Kommt vom Sende-PC gar kein Packet, ist natürlich dort weiter zu suchen.
Grüße
TA
da dein D-Link-Switch ein stinknormaler L2-Switch ist (dieser also von L3/IPs keine Ahnung hat), geht es folglich um reinen Broadcast im selben Netzwerksegment. „Directed broadcast“, um Netzwerkgrenzen zu überwinden, muss somit nicht beachtet werden.
Nun wäre es interessant, ob vom „Sende-PC“ beim aufzuweckenden PC das Magic Packet eingeht - und wie es im Vergleich zum Magic Packet des Routers aufgebaut ist.
Starte doch mal Whireshark (gerne als Live-System z.B. „Kali“) mit Filter auf Broadcast auf dem aufzuweckenden PC (oder ein dritter PC/Laptop) und beobachte das Ganze. Dann solltest du mehr wissen.
Hintergrund: neben dem „Standard-Magic Packet“ gibt es auch andere Bauformen.
Kommt vom Sende-PC gar kein Packet, ist natürlich dort weiter zu suchen.
Grüße
TA
Zitat von @TwistedAir:
Starte doch mal Whireshark (gerne als Live-System z.B. „Kali“) mit Filter auf Broadcast auf dem aufzuweckenden PC (oder ein dritter PC/Laptop) und beobachte das Ganze. Dann solltest du mehr wissen.
Hintergrund: neben dem „Standard-Magic Packet“ gibt es auch andere Bauformen.
Starte doch mal Whireshark (gerne als Live-System z.B. „Kali“) mit Filter auf Broadcast auf dem aufzuweckenden PC (oder ein dritter PC/Laptop) und beobachte das Ganze. Dann solltest du mehr wissen.
Hintergrund: neben dem „Standard-Magic Packet“ gibt es auch andere Bauformen.
Tja, wenn ich das Packet über den Router sende, ist alles fein:
Sende ich es über den PC (bei ausgeschalteter Firewall und ausgeschaltetem Bitdefender-Echtzeitscan) ist kein derartiges Paket zu finden. Das einzige, was da an Broadcast herumschwirrt, sind "Who has"-Anfragen.
Das Tool meldet aber, dass es das Magic Packet gesendet hat:
Kommt vom Sende-PC gar kein Packet, ist natürlich dort weiter zu suchen.
Aber in welche Richtung, wenn ich Firewall (auch die Windows-Firewall) und den Echtzeitscan vom Bitdefender bereits deaktiviert habe (und vorher sogar das Programm aus Ausnahme in der Firewall definiert hatte)?
Moin,
Teste es mal mit diesem Tool.
Ermittle die MAC deines aufzuweckenden Clients und dann Feuer frei.
VLANs kommen bei dir ( scheinbar) nicht zum Einsatz!?
Gruß
em-pie
Teste es mal mit diesem Tool.
Ermittle die MAC deines aufzuweckenden Clients und dann Feuer frei.
VLANs kommen bei dir ( scheinbar) nicht zum Einsatz!?
Gruß
em-pie
Kann ich heute abend gerne noch mal probieren, jetzt bin ich schon auf dem Weg zur Arbeit. Was ist an dem Tool besser/anders als an dem, das ich verwendet habe?
Ermittle die MAC deines aufzuweckenden Clients und dann Feuer frei.
Die MAC kenne ich ja längst, sonst würde es vom Router aus ja auch nicht gehen ...
VLANs kommen bei dir ( scheinbar) nicht zum Einsatz!?
Nein ... die würden den DGS-1005D auch nicht überleben
Es gibt bekanntlich 2 Arten von WoL Paketen. Einmal rein auf Basis Layer 2 (Mac Adressen) und einmal mit einem IP Header. In der Regel UDP 9 (discard). Siehe hier.
Dein Wireshark Trace oben ist leider zu oberflächlich dargestellt um beurteilen zu können welche Variante der Router verwendet.
Du solltest also im WoL Setup des PCs bzw. seiner NIC einmal checken welche Variante dieser zum Aufwachen benötigt!
Noch einfacher ist es natürlich bei reichelt.de einen neuen Schalter zu beschaffen.
Der forwardet auch Tagged Frames mit ihren VLAN Tags problemlos. Sie "überleben" also schon!!
Dein Wireshark Trace oben ist leider zu oberflächlich dargestellt um beurteilen zu können welche Variante der Router verwendet.
Du solltest also im WoL Setup des PCs bzw. seiner NIC einmal checken welche Variante dieser zum Aufwachen benötigt!
Noch einfacher ist es natürlich bei reichelt.de einen neuen Schalter zu beschaffen.
die würden den DGS-1005D auch nicht überleben
Das ist falsch und stimmt nur zum Teil...Der forwardet auch Tagged Frames mit ihren VLAN Tags problemlos. Sie "überleben" also schon!!
Zitat von @aqui:
Es gibt bekanntlich 2 Arten von WoL Paketen. Einmal rein auf Basis Layer 2 (Mac Adressen) und einmal mit einem IP Header. In der Regel UDP 9 (discard). Siehe hier.
Dein Wireshark Trace oben ist leider zu oberflächlich dargestellt um beurteilen zu können welche Variante der Router verwendet.
Es gibt bekanntlich 2 Arten von WoL Paketen. Einmal rein auf Basis Layer 2 (Mac Adressen) und einmal mit einem IP Header. In der Regel UDP 9 (discard). Siehe hier.
Dein Wireshark Trace oben ist leider zu oberflächlich dargestellt um beurteilen zu können welche Variante der Router verwendet.
Hm, ich habe den gespeicherten Trace noch mal im Detail ausgegeben:
Was ist das nun? Laut Deinem Screenshot in dem verlinkten Track ein USP-Paket, oder?
Noch einfacher ist es natürlich bei reichelt.de einen neuen Schalter zu beschaffen.
Nicht für ein Notebook. Und selbst wenn, fange ich auf der Platine bestimmt nicht an zu löten.
die würden den DGS-1005D auch nicht überleben
Der forwardet auch Tagged Frames mit ihren VLAN Tags problemlos. Sie "überleben" also schon!!Oh ... wieder was dazugelernt. Ich ging immer davon aus, dass nicht vLAN-fähige Switches die vLAN-Informationen rauslöschen ...
Zitat von @SarekHL:
Kann ich heute abend gerne noch mal probieren, jetzt bin ich schon auf dem Weg zur Arbeit. Was ist an dem Tool besser/anders als an dem, das ich verwendet habe?
Bei dem weiß ich, dass es funktioniert Kann ich heute abend gerne noch mal probieren, jetzt bin ich schon auf dem Weg zur Arbeit. Was ist an dem Tool besser/anders als an dem, das ich verwendet habe?
Nutze es selbst hier und es funktioniert auch über VLAN-Grenzen hinweg (da am Router/ Switch die Pakete weitergereicht werden)
Ermittle die MAC deines aufzuweckenden Clients und dann Feuer frei.
Die MAC kenne ich ja längst, sonst würde es vom Router aus ja auch nicht gehen ...
Screenshot in dem verlinkten Track ein USP-Paket, oder?
Siehst du ja auch selber, oder? Ja, UDP Header mit dem recht ungewöhnlichen und exotischem DST Port 2304. Letztendlich hat das aber keinen Einfluss.Du kannst die beiden unterschiedlichen Versionen sehr einfach einmal generieren und auf den PC loslassen.
- Krame deinen Raspberry Pi aus der Bastelschublade und installiere die beiden Tools etherwake und wakeonlan (apt install ...)
- etherwake -b -i eth0 01:02:03:04:05:06 sendet ein nacktes Layer 2 WoL Paket im AMD Magic Packet Format.
- wakeonlan 01:02:03:04:05:06 sendet es mit einem UDP Port 9 Header und all Network Broadcast
- wakeonlan -i 192.168.178.255 01:02:03:04:05:06 sendet es mit einem spezifischen IP Netzwerk Broadcast im 192.168.178.0/24 Segment.
Ich ging immer davon aus, dass nicht vLAN-fähige Switches die vLAN-Informationen rauslöschen
Du als Netzwerk und Wireshark Profi hättest es besser wissen müssen! 😉Zitat von @aqui:
Du kannst die beiden unterschiedlichen Versionen sehr einfach einmal generieren und auf den PC loslassen.
Du kannst die beiden unterschiedlichen Versionen sehr einfach einmal generieren und auf den PC loslassen.
- Krame deinen Raspberry Pi aus der Bastelschublade und installiere die beiden Tools etherwake und wakeonlan (apt install ...)
ok, und jetzt die Windows-Versionen? Ich habe nämlich keinen Pi oder andere Linux-Kisten (außer natürlich diversen Geräten, die vermutlich intern ein Linux laufen haben).
So kannst du alle Varianten genau durchtesten was der PC haben will.
Naja, das Problem ist ja ein anderes. Vielleicht weckt auch ein "nacktes Layer 2 WoL Paket" den PC auf. Aber dieses Paket, von meinem PC aus versendet, kommt ja lt. Wireshark gar nicht an dem zu weckenden Rechner an.
Ich würde jetzt gerne mit dem UDP-Paket experimentieren. Jetzt ist doch nur noch die Frage, welches Windows-Tool ein solches Paket sendet. Das Tool, dass ich verwendet habe, bietet ja auch einen "Directed Broadcast".
Ist das dieser Modus? Mich verwirrt allerdings das "IP benötigt". Bei einem Gerät ohne feste IP kenne ich die doch nicht. Hat das Gerät im ausgeschalteten Zustand überhaupt schon eine Adresse vom DHCP bekommen?
Ich habe nämlich keinen Pi oder andere Linux-Kisten
Ein Kauf für 10 Euronen https://buyzero.de/collections/boards-kits/products/raspberry-pi-zero-w lohnt immer!!Ansonsten Virtual Box hochfahren mit einem kleinen, schlanken Debian oder Ubuntu drauf. Ist in 10 Minuten erledigt. Du bist doch IT Profi! 😉
Vielleicht weckt auch ein "nacktes Layer 2 WoL Paket" den PC auf.
Vielleicht... Vielleicht aber auch nicht. Deshalb ja der Test.kommt ja lt. Wireshark gar nicht an dem zu weckenden Rechner an.
Dann hast du aber ein Problem an deinem Rechner! Wenn der erst gar keine WoL Pakete aussendet hat DER ein Problem (oder ne falsche Firewall).WoL Pakete, egal welche Variante, sind ja immer Broadcast Pakete sprich all Net Broadcasts oder Segment spezifische Broadcasts. Sie sind also immer an allen Endgeräten im gleichen L2 Segment überall zu sehen, sprich ein Wireshark oder tcpdump sollte sie immer anzeigen, egal wo.
Mich verwirrt allerdings das "IP benötigt"
Warum? Bedeutet doch nur das ein WoL Paket mit IP Header (UDP) generiert wird und kein reines L2 WoL via Mac ohne L3. Siehe oben...Die Geräte IP ist vollkommen irrelevant, denn wie oben schon beschrieben (und wie du auch selber an deinem eigenen Wireshark Trace sehen kannst) sendet WoL immer an eine all Net Broadcast oder Segment spezifische Broadcast Adresse, niemals an eine Hostadresse. Wäre bei einem Rechner im Standby ja auch völlig sinnfrei, denn der hat ja in dem Zustand gar keine IP Adresse. 😉
Zitat von @aqui:
Ein Kauf für 10 Euronen https://buyzero.de/collections/boards-kits/products/raspberry-pi-zero-w lohnt immer!!
Ein Kauf für 10 Euronen https://buyzero.de/collections/boards-kits/products/raspberry-pi-zero-w lohnt immer!!
Ist das so? Ich habe verschiedentlich schon mal geschaut, wo ich einen Pi in meiner Umgebung sinnvoll einsetzen kann - ich habe nichts gefunden. Und nur für einen Test? ....
Ansonsten Virtual Box hochfahren mit einem kleinen, schlanken Debian oder Ubuntu drauf. Ist in 10 Minuten erledigt. Du bist doch IT Profi! 😉
Aber kein Linux-Profi. Ich wüsste nicht mal, wie man darauf ein Programm installiert. Ich bin zu 100% "Windowser"
kommt ja lt. Wireshark gar nicht an dem zu weckenden Rechner an.
Dann hast du aber ein Problem an deinem Rechner! Wenn der erst gar keine WoL Pakete aussendet hat DER ein Problem (oder ne falsche Firewall).Dass das Problem dort liegt, will ich nicht ausschließen - dann aber auch auf dem Notebook meiner Frau und auf meinem Notebook, denn ich habe es von überall getestet. Nur bin ich langsam mit meinem Latein am Ende, welcher Art das Problem sein könnte. Wenn ich bei Bitdefender sowohl den Echtzeitschutz als auch die Firewall ausschalte und dann auch noch unter Windows die Defender-Firewall ausschalte, sollte da nichts mehr sein, was Pakete blockiert.
Warum? Bedeutet doch nur das ein WoL Paket mit IP Header (UDP) generiert wird und kein reines L2 WoL via Mac ohne L3. Siehe oben... Die Geräte IP ist vollkommen irrelevant,
Also nur eine irreführende Bezeichnung ...
Moin,
wie schon gesagt, teste es mit der wol.exe
Alternativ geht auch noch die WakeMeOnLan.exe
wobei 00-11-22-AA-BB-CC die MAC-Adresse ist.
wenn das klappt. das einfach in eine Batch-Datei ablegen und dann per Doppelklick den Client aufwecken - fertig.
edit: wol.exe vs. wakemeonlan.exe: https://www.andysblog.de/windows-wake-on-lan-via-skript-oder-verknuepfun ...
in beiden Fällen kannst du auch den Default-Port 9 auf was anderes abändern
wie schon gesagt, teste es mit der wol.exe
Alternativ geht auch noch die WakeMeOnLan.exe
WakeMeOnLan.exe /wakeup 00-11-22-AA-BB-CC wenn das klappt. das einfach in eine Batch-Datei ablegen und dann per Doppelklick den Client aufwecken - fertig.
edit: wol.exe vs. wakemeonlan.exe: https://www.andysblog.de/windows-wake-on-lan-via-skript-oder-verknuepfun ...
in beiden Fällen kannst du auch den Default-Port 9 auf was anderes abändern
Zitat von @em-pie:
edit: wol.exe vs. wakemeonlan.exe: https://www.andysblog.de/windows-wake-on-lan-via-skript-oder-verknuepfun ...
in beiden Fällen kannst du auch den Default-Port 9 auf was anderes abändern
edit: wol.exe vs. wakemeonlan.exe: https://www.andysblog.de/windows-wake-on-lan-via-skript-oder-verknuepfun ...
in beiden Fällen kannst du auch den Default-Port 9 auf was anderes abändern
Danke für den Link. Darin habe ich etwas gefunden, was relevant sein könnte:
Befindet sich der Computer in mehreren Netzwerken, kann es passieren, dass das Magic Paket für Wake-On-LAN auf der falschen Netzwerkkarte raus geht und folglich nicht der gewünschte Effekt erzielt wird. Für solch eine Überraschung genügt es schon, das z.B. VirtualBox installiert ist, denn dann existiert ein “VirtualBox Host-Only Network” das einem in die Quere kommt.
Das könnte der Grund sein, weshalb die aus meinem Rechner gesendeten Pakete nicht ankommen ...
na dann einfach ein
wol.exe 112233AABBCC 192.168.100.5 und du sendest von der richtigen NIC (sofern die 192.168.100.5 die IP deines PCs ist, welcher das Paket auf die Reise schicken soll).Zitat von @em-pie:
na dann einfach ein
na dann einfach ein
wol.exe 112233AABBCC 192.168.100.5 und du sendest von der richtigen NIC (sofern die 192.168.100.5 die IP deines PCs ist, welcher das Paket auf die Reise schicken soll).Werde ich heute abend ausprobieren ;)
Das von @em-pi empfohlene wol.exe ist ja schnell ausprobiert und benötigt keine Installation - damit solltest du in kürzester Zeit eingrenzen können, ob es an der Software liegt.
Wenn es dann immer noch nicht klappt und du dein(e) System(e) in Verdacht hast, hättest du zur Eingrenzung noch die Möglichkeiten
Die Idee von @aqui einen leistungsarmen Raspberry (der muss ja nicht viel können) zu verwenden, finde ich sehr charmant. Möchte man einen "Fat Client" ggf. erst starten um einen anderen zu booten? So ein kleine Box mit einem an die GPIO-Pins angeschlossenen Taster, die bei Betätigung ein Skript mit dem WoL-Befehl abfeuert - ein nettes Projekt für die kommenden dunklen Tage und um sich mit Linux zu beschäftigen.
Grüße
TA
Wenn es dann immer noch nicht klappt und du dein(e) System(e) in Verdacht hast, hättest du zur Eingrenzung noch die Möglichkeiten
- Whireshark auf dem sendenden Rechner zu installieren. Mit einer allgemeinen Einstellung siehst du zuerst ob ein Magic Packet generiert wird; durch geschickte Wahl der zu überwachenden Adapter kannst du dann sehen, wo es raus geschickt wird. Mit einem zweiten Whireshark-PC könntest du den Broadcast im Zielnetz verfolgen, sprich, ob das Packet auch ankommt.
- (Linux-)Live-System vom Stick starten, dann bleibt das Original-System unangetastet. Anregungen dazu hier, hier hier oder hier [in den Abschnitten, wo ums Aufwecken eines anderen Systems geht].
Die Idee von @aqui einen leistungsarmen Raspberry (der muss ja nicht viel können) zu verwenden, finde ich sehr charmant. Möchte man einen "Fat Client" ggf. erst starten um einen anderen zu booten? So ein kleine Box mit einem an die GPIO-Pins angeschlossenen Taster, die bei Betätigung ein Skript mit dem WoL-Befehl abfeuert - ein nettes Projekt für die kommenden dunklen Tage und um sich mit Linux zu beschäftigen.
Grüße
TA
Zitat von @TwistedAir:
Das von @em-pi empfohlene wol.exe ist ja schnell ausprobiert und benötigt keine Installation - damit solltest du in kürzester Zeit eingrenzen können, ob es an der Software liegt.
Das von @em-pi empfohlene wol.exe ist ja schnell ausprobiert und benötigt keine Installation - damit solltest du in kürzester Zeit eingrenzen können, ob es an der Software liegt.
Ja, aber erst wenn ich wieder zuhause bin ;)
Wenn es dann immer noch nicht klappt und du dein(e) System(e) in Verdacht hast, hättest du zur Eingrenzung noch die Möglichkeiten [...] Whireshark auf dem sendenden Rechner zu installieren. Mit einer allgemeinen Einstellung siehst du zuerst ob ein Magic Packet generiert wird; durch geschickte Wahl der zu überwachenden Adapter kannst du dann sehen, wo es raus geschickt wird.
Wenn du dich davor scheust zusätzliche/unnötige Software und systemnahe Treiber zu installieren (bin ich auch kein Freund von), kannst du auch ein * (Linux-)Live-System vom Stick starten, dann bleibt das Original-System unangetastet.
Wenn du dich davor scheust zusätzliche/unnötige Software und systemnahe Treiber zu installieren (bin ich auch kein Freund von), kannst du auch ein * (Linux-)Live-System vom Stick starten, dann bleibt das Original-System unangetastet.
Nur wenn ich das tue, sehe ich ja nicht, ob irgendeine Software auf meinem Rechner das ganze blockiert. Ist letztlich aber auch egal, denn:
Die Idee von @aqui einen leistungsarmen Raspberry (der muss ja nicht viel können) zu verwenden, finde ich sehr charmant. Möchte man einen "Fat Client" ggf. erst starten um einen anderen zu booten?
das Notebook (mit dem defekten Einschalter) ist ja nicht meins. Eines unserer Kirchenvorstandsmitglieder möchte den gerne nutzen, und zwar als festen (Zweit)rechner zuhause. Insofern passt das schon mit dem Einschalt-Prozedere. Bloß bevor ich ihm sage, dass das geht, möchte ich zumindest sichergehen, dass man das Notebook überhaupt von einem Windows-Rechner aus starten kann.
Wenn es mit dem WOL-Tool nicht geht, installiere ich mir vermutlich ein virtuelles System und teste es von dort aus. Dazu noch mal eine Frage (vermutlich an aqui): Ist es bei Virtual Box per Default so, dass der Netzwerkverkehr eines virtuellen Rechners direkt ins Netzwerk gepumpt wird, also die Firewall des Hosts übergeht? Oder brauche ich dafür noch spezielle Einstellungen? So tief habe ich mich mit Virtual Box noch nie beschäftigt.
Kommt etwas drauf an wie man es installiert.
Häufig wird im Netzwerk Setup die Bridge Funktion genutzt, sprich lokale NIC und die VM NIC werden einfach über eine Bridge zusammengefasst (Layer 2) und arbeiten dann im lokalen LAN des Hypervisor Hosts. Da gibts dann keine Firewall.
Alternativ kann man den Host Mode benutzen was normal dann die VM isoliert.
Aktiviert man aber IP Forwarding auf dem Hypervisor kann man die VM durchrouten über dessen Firewall.
Das entspricht dann einem klassischen Routing Design mit 2 IP Netzen wie z.B. HIER beschrieben.
Beides führt zum Ziel.
Häufig wird im Netzwerk Setup die Bridge Funktion genutzt, sprich lokale NIC und die VM NIC werden einfach über eine Bridge zusammengefasst (Layer 2) und arbeiten dann im lokalen LAN des Hypervisor Hosts. Da gibts dann keine Firewall.
Alternativ kann man den Host Mode benutzen was normal dann die VM isoliert.
Aktiviert man aber IP Forwarding auf dem Hypervisor kann man die VM durchrouten über dessen Firewall.
Das entspricht dann einem klassischen Routing Design mit 2 IP Netzen wie z.B. HIER beschrieben.
Beides führt zum Ziel.
Zitat von @aqui:
Häufig wird im Netzwerk Setup die Bridge Funktion genutzt, sprich lokale NIC und die VM NIC werden einfach über eine Bridge zusammengefasst (Layer 2) und arbeiten dann im lokalen LAN des Hypervisor Hosts. Da gibts dann keine Firewall.
Häufig wird im Netzwerk Setup die Bridge Funktion genutzt, sprich lokale NIC und die VM NIC werden einfach über eine Bridge zusammengefasst (Layer 2) und arbeiten dann im lokalen LAN des Hypervisor Hosts. Da gibts dann keine Firewall.
Das ist ja das, was ich zumindest für diesen Test möchte, um Fehler auszuschließen, die durch die Firewall verursacht werden. Danke.
Dann machst du das klassische, 08/15 Standardsetup mit der Bridge! 😉
Zitat von @em-pie:
na dann einfach ein
na dann einfach ein
wol.exe 112233AABBCC 192.168.100.5 und du sendest von der richtigen NIC (sofern die 192.168.100.5 die IP deines PCs ist, welcher das Paket auf die Reise schicken soll).Das war's!!!! Das Problem war also offenbar, dass meine Rechner versucht haben, das Paket über die falsche NIC rauszusenden ...
Das passiert wenn man als Winblows Knecht die NIC Bindungsreihenfolge oder neu Metrik nicht beachtet. Ein "route print" ist bei mutliplen NICs dein bester Freund... 😉
