Powershell nutzt Wake on LAN

Die Funktionalität von Wake on LAN (WOL) sollte auf Systemen mit einer entsprechenden Unterstützung im BIOS des Rechners funktionieren. Doch es kann aufgrund der Netzwerkkonfiguration beim Unicast- aber auch beim Broadcast-Ansatz  (bezogen auf einzelne Subnetze) sowie wegen einiger Sicherheits-Restriktionen im Unternehmensnetz zu Problemen kommen. Der Autor John Savill zeigt zudem, wie sich mit Hilfe eines Powershell-Skripts einzelne Systeme „aufwecken“ lassen.

Wer für die Verwaltung seiner Windows-Umgebung Tools wie den SCCM 2007 (System Center Configuration Manager 2007) einsetzt, der kann auf zwei Konfigurationsarten für die WOL-Funktionalität zurückgreifen, die alle beide sich auf einen SCCM-Standort beziehen: Unicast und Subnetz-bezogene Broadcasts.

Beim Unicast-Ansatz wird ein sogenanntes Magic Paket direkt an die IP-Adresse des betreffenden (aufzuweckenden) Clients gesendet. Dieses Paket besteht aus einem speziellen Format. Zuerst wird sechsmal nacheinander der Wert FF gesendet und danach kommt die 16fache Wiederholung der MAC-Adresse des Clients (genauer seiner Netzwerkkarte, die an die IP-Adresse gebunden ist), die ohne eine Unterbrechung gesendet wird. Dieses Paket wird über das IP versendet, sprich es geht direkt an die IP-Adresse des Clients. Dieser Ansatz sollte eigentlich narrensicher sein, doch es kommt etwas Komplexität ins Spiel, wenn dieses Magic Paket über das IP versendet wird.

Address Resolution Protocol bringt Komplexität ins Spiel

Wenn IP-Pakete versendet werden, bildet das Address Resolution Protocol (ARP) die IP-Adresse auf die betreffende MAC-Adresse des Clients. Die Switches im Netzwerk halten einen ARP-Cache mit diesen Abbildungen vor und wissen so, an welche Zielsysteme sie die Pakete ausliefern können. Doch beim Aufwecken über WOL handelt es sich beim Zielsystem um einen Rechner, der schon einige Zeit außer Betrieb ist.

Viele Netzwerk-Switches löschen die Einträge in ihrem ARP-Cache, wenn eine Zeitlang keine Aktivität mit dem Gerät zu verzeichnen ist – üblicherweise ist diese Zeitspanne auf vier Stunden eingestellt. Danach liegt im ARP-Cache des Switch die Abbildung von IP- auf MAC-Adresse nicht mehr vor. Damit ist die Kommunikation unterbrochen und das Magic Paket kann nicht sofort zugestellt werden.

Zum Beheben dieses Problems im Unicast-Modus von WOL kann man die Switch-Konfiguration modifizieren und das Entfernen der Einträge im ARP-Cache überprüfen. Denn das könnte due Ursache sein – vor allem wenn es mit einem System bisher immer geklappt hat und erst nach einer langen Zeit der Inaktivität des Systems kein Durchkommen mehr zu verzeichnen ist.
Die Subnetz-bezogenen Broadcasts bei WOL arbeiten nach dem Prinzip, das Magic Paket an ein gesamtes Subnetz zu versenden (und nicht nur an eine IP-Adresse; sprich an die IP-Adresse <subnetz>.255 bei IP Version 4). Dann bekommen alle Maschinen im Subnetz das Paket zugestellt, doch die mehrfach wiederholte MAC-Adresse passt nur zu eier Netzwerkkarte und somit zu einem System.

Dieses System wird dann aufgeweckt. Damit treten keine ARP-Probleme auf, doch die meisten Switches oder Router sind aus Sicherheitsgründen so konfiguriert, dass sie derartige Broadcast-Sendungen blockieren. Deswegen kommen die Magic Pakets nicht zu den Endgeräten. Wer dieses Problem vorfindet, der muss bei allen Switches/Router es zulassen, dass Subnetz-bezogene Broadcasts versendet werden können. Doch das werden die meisten Netzwerkadministratoren in einem Unternehmensnetzwerk nicht zulassen.

In der Praxis treten bei beiden Konfigurationstypen Probleme auf. Wer die Netzwerkkonfiguration überprüft – insbesondere die der Switches – der kann das Problem besser eingrenzen. Es lassen sich dann auch Lösungen mit anderen WOL-Konfigurationen oder auch anderen WOL-Techniken (wie etwa die von Intels Vpro) verwenden. Generell muss aber das BIOS im Endgerät das WOL erlauben.

Wenn nun ein System WOL unterstützt und auch dann hochfahren darf, wenn es mit WOL aufgeweckt wird, kann man ein Skript einsetzen. Es sollte das Magic Paket an ein entferntes System versenden, um es hoch zu fahren.
Dazu muss man zuerst die MAC-Adresse des Systems (im Hex-Format xx:xx:xx:xx:xx:xx) kennen. Dann ist ein Powershell-Skript zu schreiben, das die folgenden Befehle enthält:

param ([String]$MACAddrString = $(throw ‚No MAC addressed passed, please pass as xx:xx:xx:xx:xx:xx‘))
 $MACAddr = $macAddrString.split(‚:‘) | %{ [byte](‚0x‘ + $_) }
 if ($MACAddr.Length -ne 6)
 {
     throw ‚MAC address must be format xx:xx:xx:xx:xx:xx‘
 }
 $UDPclient = new-Object System.Net.Sockets.UdpClient
 $UDPclient.Connect(([System.Net.IPAddress]::Broadcast),4000)
 $packet = [byte[]](,0xFF * 6)
 $packet += $MACAddr * 16
 [void] $UDPclient.Send($packet, $packet.Length)
 write "Wake-On-Lan magic packet sent to $MACAddrString, length $($packet.Length)"

Dieses Skript ist dann als Datei (mit der Endung .ps1) zu speichern (wie etwa wol.ps1). danach muss man noch die Ausführung der Powershell-Skripts in der eigenen Umgebung aktivieren und korrekt einstellen.

Dazu ist der folgende Befehl nötig, der die entsprechenden Warnhinweise erzeugt und nochmals eine Bestätigung braucht:

PS D:\Documents\scripts> Set-ExecutionPolicy unrestricted
 
 Execution Policy Change
 The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose you to the security risks described in the about_Execution_Policies help topic. Do you want to change the execution policy?
 [Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): Y

Danach ist das System mit dem folgenden Befehl zu starten:

PS D:\Documents\scripts> .\wol.ps1 D8:D3:85:9A:98:60
 Wake-On-Lan magic packet sent to D8:D3:85:9A:98:60, length 10

In diesem Beispiel ist die MAC-Adresse des Zielsystems D8:D3:85:9A:98:60Dieses Skript kann auch weiter verfeinert werden. Allerdings sollte man das Skript zuerst in einer Testumgebung verwenden und ausprobieren, ob es wie gewünscht funktioniert – nie ein ungeprüftes Skript in einer Produktivumgebung einsetzen!

John Savill/rhh

ff