Sonnenhügler_1

Die Regel, bei der ein SMB-Zugriff auf 192.168.1.107 den Rechner aufwecken soll, funktioniert allerdings nicht.

Wundert mich nicht.

Warum nutzt du nicht den Ping auf die DB?

@wari1957 Vielen Dank für die Rückmeldung.

Ich habe mir so etwas ähnliches auch schon gedacht, nämlich dass zu einem ausgeschalteten PC gar keine Verbindung hergestellt wird (auch nicht bei "Verbindungstyp: Beliebig"), so dass auch kein WOL ausgelöst wird.

Allerdings klappt es auch dann nicht, wenn eine Verbindung hergestellt werden kann. Ich habe dazu einen Versuch mit 3 Rechnern A, B und C gemacht. A und B waren eingeschaltet. C war ausgeschaltet und sollte aufgeweckt werden, sobald A eine SMB-Verbindung zu B herstellt. Ich habe meine Regel dazu entsprechend abgewandelt und als Ziel-IP die IP von B eingegeben. Auch das hat nicht funktioniert, obwohl B bereits eingeschaltet war und somit der Zugriff von A auf die Freigaben von B einwandfrei geklappt hat.

Bemerkenswert ist auch, dass in diesem Tutorial-Video die Einrichtung eines WOL-Filters beschrieben wird, das bei Herstellung einer https-Verbindung einen PC aufwecken soll. Auch da wird als Ziel-IP die IP des aufzuweckenden Rechners eingetragen (ab 0:50 im Video). Es wird mit keiner Silbe erwähnt, dass das nicht funktioniert.

Ich nutze WOL-Apps für Windows und iOS. Die funktionieren auch gut, aber nur, wenn kein VPN im Spiel ist. Da mir bekannt ist, dass WOL über VPN nicht funktioniert, bin ich folgendermaßen vorgegangen: ich greife per VPN und Remote Desktop von PC A auf den (immer eingeschalteten) PC B zu. Auf PC B gibt es die WOL-App, die wiederum PC C aufwecken soll. Dabei ist nur nur PC A über VPN angebunden, während PC B und PC C beide direkt an der Digibox hängen. Das WOL-Paket von PC B muss also kein VPN durchlaufen und kommt daher problemlos bei PC C an. Allerdings setzt diese Vorgehensweise voraus, dass ich mich immer erst per RDP auf PC B einlogge. Ich fände es komfortabler, wenn PC C einfach durch einen schlichten Zugriff auf seine Freigaben aufgeweckt werden könnte.

Ich werde jetzt mal probieren, ob man irgendwo feste Einträge in der ARP-Tabelle vornehmen kann, so dass auch ausgeschaltete PCs darin gefunden werden. Mal sehen, ob es dann funktioniert. Ich habe aber wenig Hoffnung, denn wie oben geschrieben funktioniert das Aufwecken auch dann nicht, wenn auf einen bereits eingeschalteten PC zugegriffen wird. Ich habe den Eindruck, dass die WOL-Filter nur greifen, wenn man als Ziel-IP die IP der Digibox angibt. Alle anderen Ziel-IPs werden ignoriert.

Grüße vom Sonnenhügler

Ich nutze nicht IPSec zur DB, sondern Wireguard zu einem VPN -Server in meinem Netz (läuft auf besagtem, immer eingeschalteten PC B). Mit Wireguard habe ich es leider noch nicht geschafft, einen PC per WOL aufzuwecken. Als ich noch die Fritzbox als Wireguard-Server verwendet habe, hat es auch nicht funktioniert.

Ich werde den am häufigsten benötigten PC jetzt erstmal über die Ping-WOL-Regel in der DB einschalten. Das funktioniert ja. Zum Einschalten der anderen PCs muss ich dann halt per Remote Desktop auf PC B einloggen und sie von da aus aufwecken. 

Nachtrag: irgendwo scheint bei der Implementation der WOL-Filter in der Digibox der Wurm drin zu sein.

Folgender Umstand bringt mich zu dieser Vermutung: ein Filter, der einen Rechner bei einem Ping an die Digibox (Ziel-IP 192.168.1.1) aufwecken soll, funktioniert. Der Rechner mit der in der zugehörigen Regel festgelegten MAC wird aufgeweckt. Ändert man jedoch die Ziel-IP in 192.168.1.2 (diese IP hat hier ein managebarer Switch, der sich natürlich auch anpingen lässt) und pingt diese IP an, funktioniert die Regel nicht mehr, und das obwohl die echo requests beim Switch und die Antworten am Senderechner ankommen (und dabei natürlich auch die Digibox durchlaufen). 

Damit ist klar: die WOL-Filter in der Digibox funktionieren offenbar nur mit der IP der Digibox als Ziel-IP. Andere Ziel-IPs funktionieren selbst dann nicht, wenn es sich um tatsächlich im LAN vorhandene IPs handelt. Das entspricht vermutlich nicht dem, was sich der Entwickler der WOL-Funktion gedacht hat.

Ich halte es auch für möglich, dass beliebige Ziel-IPs mit früheren Firmware-Versionen durchaus korrekt funktioniert haben, was man aus dem bereits erwähnten Videotutorial entnehmen kann. Dort wird nämlich gezeigt, wie man eine WOL-Regel in der Digibox so konfiguriert, dass sie einen Rechner bei einem HTTPS-Zugriff aufweckt. Dazu wird als Ziel-IP nicht die IP der Digibox, sondern die IP des aufzuweckenden Rechners eingetragen. Das Tutorial ist allerdings von 2018, und das GUI im Video sieht anders aus als das heutige. Es ist also eine ältere Firmware im Spiel. Und genau damit scheinen derartige Regeln offenbar noch funktioniert zu haben. Andernfalls gäbe es wohl kein Tutorial-Video, in dem suggeriert wird, dass das so klappt.

Heute funktioniert die Vorgehensweise jedoch nicht mehr. Das könnte ein Indiz dafür sein, dass sich in einer der neueren Firmware-Versionen ein Fehler eingeschlichen hat.

Mit einer Behebung dieses Fehlers darf man wegen der Bintec-Insolvenz wohl nicht mehr rechnen. Schade eigentlich.

Edit: Auch der eingangs erwähnte Filter auf SMB-Zugriffe funktioniert, sobald man als Ziel-IP die IP der Digibox einträgt. Und das, obwohl es auf der Digibox gar keine SMB-Freigaben gibt. Strange...

Grüße vom Sonnenhügler