Wake-on-LAN über VPN funktioniert nicht? Das Broadcast kommt nie an

Der Tunnel steht, und Freigaben antworten, doch die Maschine bleibt im Schlaf. Das Magic Packet muss im Segment des Ziels selbst ausgesendet werden, also stellen Sie dort einen Helfer auf.

Sie legen den Bürorechner schlafen, wählen von zu Hause aus das VPN, und er bleibt aus. Der Tunnel steht, Dateifreigaben antworten, und die Wake-on-LAN-Seite des Routers meldet, dass sie die Anfrage gesendet hat. Jedes sichtbare Signal sagt, dass das Netz in Ordnung ist, und genau darum ist dieser Fall verwirrend: Das Frame, das den Rechner aufwecken würde, erreicht nie das Segment, in dem er sitzt.

Die Symptome deuten auf das Subnetz, nicht auf den Tunnel

Ping schlägt für den schlafenden Host fehl, und das ist normal. Ein Rechner im Standby hat keinen laufenden IP-Stack, kann also weder ARP noch ICMP beantworten, und keine Tunnelkonfiguration ändert daran etwas. Der nützliche Test ist, ob ein zweiter Rechner im selben LAN aufwacht und ob die Wake-Seite des Routers für einen dort angesteckten Host funktioniert.

Sobald der Test im selben Segment gelingt, liegt das Problem im Geltungsbereich. Der Absender, den Sie nutzen, lebt auf der VPN-Schnittstelle, und das Paket, das er baut, ist ein Broadcast für den lokalen Link, also geht es über die falsche Schnittstelle hinaus oder gar nicht. Der Tunnel ist nicht kaputt; er befördert die falsche Art von Verkehr. Finden Sie heraus, welche Schnittstelle der Absender wählt, bevor Sie eine einzige Routereinstellung ändern.

Ein Magic Packet ist ein Frame, kein Dienst

Die Nutzlast beginnt mit einem festen Header aus sechs 0xFF-Bytes, dann folgt die Hardwareadresse der Zielkarte sechzehnmal, dann ein optionales SecureOn-Passwort von vier Byte. Absender verpacken das üblicherweise in UDP auf Port 7 oder Port 9, doch die Portnummer ist eine Konvention zwischen Absender und Karte, kein Listener, mit dem Sie sich verbinden könnten. Nichts lauscht, und nichts antwortet.

Was den Rechner weckt, ist die Netzwerkschnittstelle, die einen kleinen Teil ihrer Schaltkreise aus der Standby-Schiene gespeist hält, während der Rest des Systems aus ist. Darum muss die Einstellung einen vollständigen Stromausfall ebenso überstehen wie einen Schlaf: Eine Platine, die beim Herunterfahren die Standby-Versorgung kappt, hat keine Karte mehr, die etwas empfangen könnte.

Warum ein gerouteter Tunnel es nicht zustellen kann

Eine geroutete VPN-Schnittstelle ist eine Punkt-zu-Punkt-IP-Verbindung zwischen zwei Tunneladressen. Sie existiert, um Pakete an den Peer zu befördern, weshalb Ping, SSH und Dateifreigaben darüber normal funktionieren. Ein Broadcast-Frame ist nicht an diesen Peer adressiert, und die begrenzte Broadcast-Adresse wird von einem Router nicht ohne Weiteres weitergeleitet.

Das Weiterleiten eines subnetzgerichteten Broadcasts ist eine bewusste Router-Fähigkeit, die die meisten Standardkonfigurationen abschalten, und selbst dann wird es an dieses Subnetz zugestellt und nicht an eine bestimmte schlafende Karte. Ein schlafender Host kann außerdem kein ARP beantworten, also verwirft ein Router, der die Zieladresse vor dem Weiterleiten auflösen will, das Frame, während er auf eine Antwort wartet, die nie kommt. Ein statischer Bindungseintrag behebt diesen Teil und lässt das Broadcast-Geltungsproblem unberührt. Zwei getrennte Einschränkungen also, und die eine zu beseitigen hilft der anderen nicht.

Drei Platzierungen, die die Karte tatsächlich erreichen

Jede praktikable Anordnung bringt das Frame auf das Segment des Ziels, und sie unterscheiden sich darin, wie stark sie das Netz stören:

  1. Stellen Sie ein immer laufendes Gerät im Zielsegment auf. Ein Router, NAS oder kleiner Linux-Rechner, der am Strom bleibt, kann das Frame lokal aussenden, sobald Sie ihn über den Tunnel erreichen, und am VPN ändert sich nichts.
  2. Lassen Sie den Router das Frame selbst aussenden. Viele Firmwares bieten eine Wake-Seite, die aus der LAN-Bridge sendet, was funktioniert, solange das Ziel an dieser Bridge hängt und nicht hinter einem zweiten Router.
  3. Brücken Sie die Standorte mit einem TAP-Tunnel, wenn Broadcasts wirklich hinüber müssen. Das führt zwei Broadcast-Domänen zusammen, bringt Broadcast-Stürme, einen einzigen Adressplan und jedes Discovery-Protokoll, das beide Standorte gleichzeitig sieht.

Die erste Option ist die für einen einzelnen Rechner vorzuziehende. Die dritte ist eine Netzwerkdesign-Entscheidung mit laufenden Kosten, also behandeln Sie sie als solche und nicht als schnelle Lösung für einen Desktop.

Notieren Sie, welcher Helfer das Frame sendet und an welcher Bridge oder welchem VLAN er hängt. Ein Helfer, der auf der falschen Schnittstelle sendet, liefert einen perfekten Mitschnitt und einen Rechner, der nie aufwacht, und diese Kombination kostet einen Nachmittag.

Prüfen Sie das Senden, bevor Sie den Client beschuldigen

Prüfen Sie zuerst die Zielkarte, denn kein Absender weckt eine Karte, die nicht aktiviert ist. Der Befehl unten liest die unterstützten und die aktuellen Wake-Modi, wobei ein aktueller Wert von g bedeutet, dass Magic Packet eingeschaltet ist:

ethtool enp3s0 | grep -A1 'Wake-on'
ip neigh show 192.168.1.50
tcpdump -ni br0 -e 'ether broadcast and udp dst port 9'
etherwake -i br0 3c:7c:3f:00:11:22

Führen Sie den Mitschnitt auf dem Helfer aus, während gesendet wird, und lesen Sie ihn, statt Erfolg anzunehmen. Ein Frame, das die richtige Bridge mit der Broadcast-Ziel-MAC verlässt, ist der einzige Beweis, dass das Senden geklappt hat; ist der Mitschnitt leer, hat der Absender eine andere Schnittstelle gewählt und der Rest des Tests ist bedeutungslos. Ein Absender, der ein rohes Frame statt eines UDP-Datagramms baut, passt nicht zu diesem Filter, also prüfen Sie, welche Form Ihr Werkzeug nutzt, bevor Sie schließen, dass nichts gesendet wurde.

Unter Windows ist die entsprechende Kartenprüfung powercfg /devicequery wake_armed, die die Geräte auflistet, die das System wecken dürfen. Ein Netzwerkadapter, der in dieser Liste fehlt, ignoriert jedes an ihn gesendete Paket, so korrekt das Frame auf der Leitung auch aussieht.

Bestätigen Sie dann das Aufwachen selbst und den Nachlauf. Ein Rechner, der angeht, aber über den Namen unerreichbar bleibt, braucht eine statische Adresse und einen DNS-Eintrag, weil die Namensauflösung per Broadcast den Tunnel weiterhin nicht überquert. Kabelloses Aufwecken ist eine eigene und weit weniger verlässliche Fähigkeit als die kabelgebundene Variante, also testen Sie es im selben Segment, bevor das VPN überhaupt ins Spiel kommt. Schreiben Sie den Schnittstellennamen und den Helfer-Host ins Ticket, denn der nächste Fehler betrifft meist dieselben zwei Fakten.

Ähnliche Artikel