Per Link direkt in die LAN Seite eines Netzwerkgerätes springen

[McConnor]

Der Titel sagt es schon. Ich würde gerne - nach Eingabe von Benutzername und Passwort - direkt auf der LAN-Seite eines bestimmten Netzwerkgerätes landen um dieses dann per WOL zu starten. Ich habe schon versucht den entsprechenden Link auf den Desktop zu ziehen aber wenn ich den dann starte komme ich trotzdem immer nur auf der FB Startseite heraus (z.B. http://192.168.178.1/#/network/device/15027/lan)...

Alternativ wäre es auch super hilfreich wenn ich ein WOL Packet übers WAN an die entfernte Fritzbox schicken könnte - z.b. mit einer kleinen App wie "https://oette.wordpress.com/wol2/"

Früher habe ich über das WAN mit einer Webapp meine Rechner aufwecken können aber i.R. irgendeines Updates wurde wahrscheinlich das Direct Broadcasting deaktiviert. Ich würde aber gerne trotzdem Benutzern ermöglichen wollen einen bestimmten Rechner aufzuwecken ohne ihnen Zugriff auch meine Fritzbox zu geben. Das Feature "Diesen Rechner bei Zugriff aus dem Internet automatisch aufwecken" hat bei mir noch nie funktioniert egal wie lange ich nach herunterfahren des betreffenden Rechners mit dem WOL Versuch gewartet habe. Das Aufwecken mit WebIF der FB klappt hingegen aber es wäre besser man müsste zum Aufwecken nicht auf der Fritzbox herumsurfen mit potentiell der Gefahr Dinge zu verstellen...

Es wäre toll wenn da einer Hilfe zu hätte... Vielen Dank

 

[Erforderlich]

Bei Fritzboxen gibt es keine Möglichkeit, "von außen" einen WOL-Broadcast zu auszulösen:
Ich benutze/benutzte 4 funktionierende alternative Varianten:
1. "Dieses Gerät automatisch starten, wenn aus dem Internet darauf zugegriffen wird.", funktioniert über Portfreigabe und VPN.
2. Powershell-Script von PeterPawn
3. Bei vorhandenenem Server und einer größeren Anzahl von zu weckenden PCs, Portfreigabe und Broadcast-Server.
4. Home Assistant

 

[McConnor]

Danke für diese Ideen.
Variante 1 wäre natürlich am Besten. Es funktioniert aber bei mir nicht. Irgendeinen Tipp warum? Ich kann über das WebIF der FB den Rechner ohne Probleme aufwecken. Wenn ich aber dann von zu Hause auf den ausgeschalteten Rechner eine RDP Session machen möchte wird der Rechner nicht gestartet (die gleiche RDP-Verbindung funktioniert bei eingeschaltetem Rechner ohne Probleme). Könnte ich das an den Start bringen wäre das Problem eigentlich gelöst....

Variante 2: ich bin mir nicht ganz sicher meine aber zu wissen dass dies flashen der Fritzbox nötig macht? Das geht nicht. Oder kann ich auf dem entfernten Rechner das WOL Script per Powershell laufen lassen um über das WAN auf der entfernten FB ein WoL auszulösen? Vielleicht habe ich nicht mit den richtigen Schlagworten gesucht aber das konnte ich nicht ausfindig machen... Ginge das so dann könnte das mein Problem auch lösen. Insgesamt scheint die Script Geschichte nach erstem Querlesen meinen technischen Horiont zu überschreiten

Varianten 3 und 4 scheiden aktuell des Aufwandes wegen eher aus....

 

[PeterPawn]

YourFritz/tr-064/WoLbyMAC.ps1 at main · PeterPawn/YourFritz

dynamic package management for AVM routers. Contribute to PeterPawn/YourFritz development by creating an account on GitHub.

github.com

Das sollte mit angepasster URL (https://fritz.com/fileadmin/user_upload/Global/Service/Schnittstellen/AVM_TR-064_remote.pdf) auch aus der Ferne funktionieren, wenn die Voraussetzungen passen.

Wenn es klappt, kann man einfach eine Verknüpfung zum Skript (oder zu dessen Aufruf, wenn man es tatsächlich mit Parametern aufrufen will und nicht "fest verdrahtet") auf seinen Desktop legen.

Allerdings sind eben die Credentials eines FRITZ!Box-Administrators erforderlich - entweder als Parameter beim Aufruf (einer geänderten Variante, denn so wie im Repo funktioniert es nur aus dem LAN heraus) oder eben fest im Skript. Nur ist das m.W. ja auch so, wenn man über das GUI auf ein spezielles Gerät zum Wecken zugreifen will. Hier ist halt eine paar fehlende, feinere Granulierung, was die einzelnen Benutzerkonten für Rechte haben, eine weiterhin bestehende Schwäche der AVM-Firmware.

Ggf. hilft ja ein Proxy im LAN (auf irgendeinem dauerhaft laufenden Gerät), wo man eine entsprechende URL aufrufen kann, die dann ihrerseits den passenden Client im LAN weckt (halt über TR-064, was ja nicht nur mit PowerShell möglich ist) - dann muß nur der Proxy die Zugangsdaten zur FRITZ!Box kennen und der Aufruf des Proxys kann auch mit anderen Benutzerdaten abgesichert werden (damit nicht IRGENDJEMAND auf den Proxy zugreifen kann).

Mögliche Ursachen für Probleme beim automatischen Wecken bei Zugriff sind vielfältig - ohne genauere Untersuchung, WAS da klemmt, ist jeder Versuch einer Diagnose nur Stochern im Nebel. Wenn tatsächlich das Aufwecken per GUI-Button IMMER gelingt, liegt aber der Verdacht nahe, daß beim Aufbau einer TCP-Verbindung von außen nicht erkannt wird, daß ein WOL-Paket zu senden wäre - wobei hier ja nicht einmal klar ist, um welches Modell und welche Firmware-Version es sich überhaupt handelt. Es gab ja zwischendrin immer wieder mal Versionen, wo das tatsächlich nicht funktionierte …

 

[McConnor]

Vielen Dank dass du dir die Zeit genommen hast so ausführlich darauf zu antworten. ja es ist tatsächlich so man braucht auch aktuell die credentials um das entfernte Gerät aufzuwecken aber immerhin könnte man mit dem Skript vermeiden dass man auf dem Weg dahin alles mögliche verstellt.

Ich muss das einmal ausprobieren sobald ich mich mit den powerscripts etwas beschäftigt habe.

Ja über das Webif kann ich den Rechner jedes Mal beim drücken des Knopfes aufwecken aber das automatische aufwecken funktioniert nie (7590, FW 8.02). Eventuell könnte ich mit einem PowerShell Skript den ausgeschalteten Rechner so "kontaktieren" dass es die Fritzbox bemerkt und von sich aus das Magic Packet dann versendet. in dem Fall wäre das Aufwecken des Rechners ja einfach oder denke ich jetzt da zu simpel?

 

[stoney]

Wieso der umständliche Weg über einen extra Login usw?

Weshalb nicht einfach ein MagicPaket aus dem LAN senden? (dazu gibt es ja auch je nach OS verschiedene, einfachere, Möglichkeiten)

 

[McConnor]

Der Rechner ist räumlich wo ganz anders. Ich muss ihn also übers WAN aufwecken. Es wäre alles ganz einfach wenn die FB erkennen würde dass eine RDP Connection aufgebaut werden soll und den Rechner mit Magic Packet (wie beworben) aufwecken würde. Tut sie aber aktuell nicht. Nur über das Knöpfchen auf der Fritzbox-Geräteseite. Und um dahin zu kommen braucht man Credentials.

Ein simples Powershell Script hat nun leider jedenfalls nicht dazu geführt dass der Rechner aufwacht:
Test-NetConnection -computername https://beliebigername.myfritz.net -port 3389

 

[antonvm]

2. Powershell-Script von PeterPawn
3. Bei vorhandenenem Server und einer größeren Anzahl von zu weckenden PCs, Portfreigabe und Broadcast-Server.

Kannst Du 2. und 3. genauer erklären?
Wo finde ich die Powershell-Scripte? ----> https://github.com/PeterPawn/YourFritz/blob/main/tr-064/WoLbyMAC.ps1

Allerdings sind eben die Credentials eines FRITZ!Box-Administrators erforderlich

Das ist natürlich unschön und gefällt mir gar nicht.

Was für einen Broadcast-Server meinst Du?

Früher habe ich über das WAN mit einer Webapp meine Rechner aufwecken können aber i.R. irgendeines Updates wurde wahrscheinlich das Direct Broadcasting deaktiviert.

Das ist evtl. etwas für dich:

- https://www.ip-phone-forum.de/threa...ollte-aktiv-werden.320822/page-3#post-2596889

GitHub - seriousm4x/UpSnap: A simple wake on lan web app written with SvelteKit, Go and PocketBase.

A simple wake on lan web app written with SvelteKit, Go and PocketBase. - seriousm4x/UpSnap

github.com

 

[angos]

Ich stelle in so einem Fall im BIOS ein das der Rechner bei Power on starten soll. Dazu dann eine Fritzsteckdose und schon ist der Rechner an. Bedienung über die App oder VPN.

 

[McConnor]

Ich habe des TR-064 Script von Meister PeterPawn eben mal ausprobiert. Für mich funktioniert das nicht. Vielleicht liegt es daran dass ich die Myfritz Adresse nicht richtig formatiert eingebe (http, https, ganz ohne was, mit Port oder ohne....) Jedenfalls alle Varianten die ich probiert habe haben den Rechner nicht aufgeweckt...

Wann qualifiziert denn die FB einen Zugriff aus dem Internet als solchen und sendet das Magic Packet?

Offensichtlich nicht bei:
RDP Versuchsaufnahme
Test-NetConnection (Ping)

 

[stoney]

Statt einen Port freizugeben, welcher unter Umständen zufällig "abgeklopft" wird und es dann zu "kuriosem" Aufwecken kommt, würde ich eine VPN-Verbindung empfehlen, sodass Du "lokal" bist.

 

[Erforderlich]

2. Powershell-Script von PeterPawn
Nach meinen Erfahrungen muss dafür der Fritzbox-User nur vorhanden sein ohne jegliche zusätzliche Rechte.
Der Vollständigkeit halber hier mal meine Fassung des PeterPawn-Scripts:

Spoiler: Script

Param([Parameter(Mandatory = $False, Position = 0, HelpMessage = 'the username to login to TR-064')][string]$Username = "wake.on.lan.username",
      [Parameter(Mandatory = $False, Position = 1, HelpMessage = 'the password to login to TR-064')][string]$Password = "**************",
      [Parameter(Mandatory = $False, Position = 2, HelpMessage = 'the MAC address of device to wake up, 00:00:00:00:00:00')][string]$MAC = "84:85:86:87:88:89",
      [Parameter(Mandatory = $False, Position = 3, HelpMessage = 'the internal TR-064 (TLS protected) port, defaults 49443')][string]$Port = 49443
      [Parameter(Mandatory = $False, Position = 4, HelpMessage = 'the IP address of the FRITZ!Box, defaults to 192.168.178.1')][string]$Address = "192.168.178.1")

$WebClient = New-Object System.Net.WebClient
$xml_query='<?xml version="1.0"?><s:Envelope xmlns:s="http:#schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http:#schemas.xmlsoap.org/soap/encoding/"><s:Body><u:X_AVM-DE_WakeOnLANByMACAddress xmlns:u="urn:dslforum-org:service:Hosts:1"><NewMACAddress>' + $MAC + '</NewMACAddress></u:X_AVM-DE_WakeOnLANByMACAddress></s:Body></s:Envelope>'

$WebClient.Encoding = [System.Text.Encoding]::UTF8
$WebClient.Credentials = New-Object System.Net.NetworkCredential($Username, $Password)
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
$WebClient.Headers.Set("Content-Type", 'text/xml; charset="utf-8"')
$WebClient.Headers.Set("SOAPACTION", 'urn:dslforum-org:service:Hosts:1#X_AVM-DE_WakeOnLANByMACAddress')
$response = [xml]$WebClient.UploadString("https://" + $Address + ":" + $Port + "/upnp/control/hosts", $xml_query)

$response.Envelope.Body.InnerXml

Seit 2022 habe ich nur noch 1., 3. und 4. benutzt und kann keine Funktion garantieren.

3. Portfreigabe und Broadcast-Server.
Ein ständig laufender Server/PC mit Windows-WOLAgent* und eine Portfreigabe darauf. Der WOLAgent nimmt die WOL-Pakete an und macht daraus einen Broadcast im Netz.
Ein nahezu optimaler Client dafür ist WolCmd.exe, der als einer der wenigen die DynDNS/MyFritz-Adresse mit dem freigegebenen Port ansprechen kann.
Der Aufruf funktioniert dann so:

WolCmd.exe %MAC% %DynDNS-Adresse% 255.255.255.255 %Port%

Wenn man für die Freigabe einen hohen Port wählt, ist die Wahrscheinlichkeit für ein zufälliges Wecken per korrekter MAC-Adresse extrem niedrig.

*Bei meiner Installation hat der WOLAgent leider regelmäßig die Arbeit verweigert, aber mit einem Neustart aller 24h läuft er jetzt stabil "durch".

 

[antonvm]

Ein ständig laufender Server/PC mit Windows-WOLAgent*

Welcher WOLAgent* ist gemeint?

 

[Erforderlich]

Du hast wohl den Link-versteckenden Style aktiviert, also hier
WOLAgent: https://wol.aquilatech.com/agent/ (Download: https://github.com/basildane/WakeOnLAN/releases/tag/2.12.4)
WolCmd: https://www.depicus.com/wake-on-lan/wake-on-lan-cmd

 

[PeterPawn]

Jedenfalls alle Varianten die ich probiert habe haben den Rechner nicht aufgeweckt

Ich hatte ja nicht umsonst die AVM-Anleitung für TR-064-Zugriff von der WAN-Seite verlinkt - da steht ja alles drin, was man zum Aufbau der RICHTIGEN URL für einen solchen Aufruf wissen muß. Es braucht also gar kein ausuferndes "Probieren" und wenn man Probleme hat, die passende URL zu "formulieren", dann sollte man vielleicht "zeigen", was man da probiert und vielleicht (offenbar recht gründlich) falsch verstanden hat.

Das Skript ist jedenfalls (mit passender URL für den Zugriff von der WAN-Seite) auch dann zum Wecken eines Gerätes geeignet, wenn das KEINE Portfreigabe für eingehende Zugriffe hat. Denn nicht bei jeder "Aufgabenstellung" muß ein aus der Ferne zu startendes Gerät ja auch von außen erreichbar sein …

EDIT: Die Fassung in #12 ist jedenfalls AUCH nicht dazu geeignet, das über die WAN-Seite zu machen.

Und wenn man das schon von außen durch den Aufbau einer Verbindung per PowerShell testet (warum man dann nicht gleich den RDP-Client verwendet, verstehe ich ohnehin nicht), dann sollte man dabei auch den Netzwerkverkehr auf der LAN-Seite mitschneiden, um zu erkennen, ob da gar kein WoL-Paket von der Box gesendet wird oder ob das Gerät auf das gesendete Paket nicht richtig reagiert.

Natürlich braucht man dazu ein ANDERES Gerät als das zu weckende, welches die aufgezeichneten Daten entgegen nimmt - noch besser wäre allerdings die Aufzeichnung "auf dem Weg" zum (zu weckenden) Gerät, weil ansonsten durch den Mitschnitt schon die Wege der Daten im FRITZ!OS verändert werden (für die Aufzeichnung muß ja der "packet accelerator" deaktiviert/geändert werden).

Und noch eine kurze Bemerkung zur Lösung über "VPN" - auch das ist nicht immer(!) der Königsweg. Damit wird nämlich (ohne weitere Maßnahmen/Einstellungen) eben nicht nur der Zugriff auf das einzelne Gerät ermöglicht, sondern auf ALLE Geräte im LAN und das ist - wieder je nach Aufgabenstellung - auch nicht unproblematisch.

 

[antonvm]

Und noch eine kurze Bemerkung zur Lösung über "VPN" - auch das ist nicht immer(!) der Königsweg.

Kannst Du das noch etwas genau erläutern?

sondern auf ALLE Geräte im LAN

Kann ich das nicht irgendwie unterbinden?

 

[McConnor]

So "einfach" wie es sich anhört ist es für mich als diesbezüglich nicht beschlagenen User nicht. Ich bin zwar sehr gewillt dazu zu lernen aber da fehlt einfach viel an Grundlagen - evtl. muss ich akzeptieren dass ich den Rechner nicht ohne weiteres aus der Ferne aufwecken kann.

Ein VPN wäre evtl. eine Möglichkeit - dann könnte ich evtl. ein herkömmliches WOL-Tool fürs LAN verwenden aber wie ausgeführt könnte das anderweitig Probleme machen und wäre noch ein Programm zum installieren (WIreGuard der Einfachheit halber).

Lieber wäre es mir mit dem Tool das zunächst super geeignet ausschaut. Bis auf das Passwort habe ich alles direkt eingefügt. Es fragt also nur noch dieses ab und das wäre ja klasse. Aber entweder habe ich die URL Generierung trotz lesen der PDF nicht verstanden oder es gibt ein prinzipielles Problem. Auf der FB habe ich unter den Netzwerkeinstellungen nachgesehen: TR064 ist aktiviert.

Ich habe aus dem WebIF der entfernten FB meine Adresse wenn ich einfach mal von der Startseite die Adresszeile kopiere:

https://meinemyfritzadresse.myfritz.net:44097/#

Im Script ganz unten habe ich daraus das hier gemacht:
$response = [xml]$WebClient.UploadString("https://" + "meinemyfritzadresse.myfritz.net" + ":" + $Port + "/upnp/control/hosts", $xml_query)

Bei anderen Varianten wie u.a. auch:

https://meinemyfritzadresse.myfritz.net:44097/tr064/upnp/control/hosts

bekomme ich Fehlermeldungen, Timeouts wie z.B. diese hier:
Ausnahme beim Aufrufen von "UploadString" mit 2 Argument(en): "Die Verbindung mit dem Remoteserver kann nicht
hergestellt werden."
In C:\Temp\Rechner wecken.ps1:30 Zeichen:1
+ $response = [xml]$WebClient.UploadString("https://" + "meinemyfritzadresse ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: ) [], MethodInvocationException
+ FullyQualifiedErrorId : WebException

 

[McConnor]

3. Portfreigabe und Broadcast-Server.
Ein ständig laufender Server/PC mit Windows-WOLAgent* und eine Portfreigabe darauf. Der WOLAgent nimmt die WOL-Pakete an und macht daraus einen Broadcast im Netz.
Ein nahezu optimaler Client dafür ist WolCmd.exe, der als einer der wenigen die DynDNS/MyFritz-Adresse mit dem freigegebenen Port ansprechen kann.
Der Aufruf funktioniert dann so:

WolCmd.exe %MAC% %DynDNS-Adresse% 255.255.255.255 %Port%

Wenn man für die Freigabe einen hohen Port wählt, ist die Wahrscheinlichkeit für ein zufälliges Wecken per korrekter MAC-Adresse extrem niedrig.

Für meinen eigentlichen Anwendungs-Fall ist das leider keine Option aber bei mir zu Hause wäre das super - da habe ich einen 24/7 NUC am Laufen und werde das ausprobieren - Danke

 

[Erforderlich]

Ein VPN wäre evtl. eine Möglichkeit - dann könnte ich evtl. ein herkömmliches WOL-Tool fürs LAN verwenden...

Es gibt leider kein "normales VPN" was UDP/WOL-Pakete "broadcasten" kann. ZeroTier wäre eine Alternative, geht aber über einen Drittanbieter und wird nur von wenigen Routern unterstützt.

AVMs WOL-Option:
Für die die bisher einfachste Möglichkeit halte ich immer noch AVMs WOL-Option "Dieses Gerät automatisch starten, wenn aus dem Internet darauf zugegriffen wird.". Ich benutze das gern über VPN mit einem einfachen Zugriff auf eine SMB-Freigabe oder einem normalen Ping, habe aber auch zusätzlich bei Teamviewer das WOL mit mypc.dyndnsexample.org:55555 eingerichtet.
Die beiden Probleme bei früheren FW waren:
1. WOL-Option ging erst nach mehrmaligem Ein/Ausschalten bzw. nur umgedreht.
2. Die WOL-Option funktionierte eine gewisse Zeit lang nicht mit UDP-Paketen und ich musste mir einen UDP-TCP-Reflector per Powershell bauen, damit ich das Teamviewer-WOL elegant benutzen konnte.

Eine direkte 1:1-Freigabe auf den RDP-Port halte ich persönlich für grenzwertig und ich würde immer einen relativ hohen Port zum Wecken und einen anderen (hohen) für die RDP-Freigabe benutzen oder besser gleich RDP nur über VPN machen. (Ja, ich bin Berufs-Paranoiker.)

Zum Testen hat sich bei mir das port ping tool von https://codingfreaks.de/pping/ sehr bewährt.

 

[PeterPawn]

Bei anderen Varianten wie u.a. auch:

Funktioniert denn der Abruf der TR064-Servicebeschreibung wie in Punkt 3.1 bei AVM beschrieben? Ansonsten gibt es eben ein tieferliegendes Problem und man müßte erst mal dieses lösen.

Aus einem Timeout kann man ja nun gar nichts ablesen, was die Frage angeht, ob da ÜBERHAUPT irgendetwas antwortet (wohl eher nicht) und selbst eine funktionierende Portfreigabe (für RDP) ist ja nur ein Anzeichen dafür, daß da der MyFRITZ!-Name IRGENDWIE aufgelöst werden kann, was immer noch keine Aussage darüber trifft, ob das per IPv4 oder IPv6 erfolgt. Da wären schon noch ein paar ausführlichere Tests erforderlich - notfalls auch mal mit falschen Credentials oder falschem Format, um eine (aussagekräftigere) Fehlermeldung zu erhalten.

Und dann bitte das KOMPLETTE geänderte Skript zeigen und nicht nur Bruchstücke - von extern darf eben NICHT derselbe HTTPS-Port wie von innen verwendet werden (Anmerkung in Punkt 3.2) und das kann ich in #17 bei den Änderungen nicht erkennen, auch wenn die danach gezeigte URL (mit tr064 im Pfad) eigentlich funktionieren sollte (unter der Annahme, daß bis dahin auch alles andere glattgegangen ist).

Kann ich das nicht irgendwie unterbinden?

Im Prinzip schon (durch explizite Zuweisung bei der VPN-Verbindung), dann ist aber das derart freigegebene Gerät (im FRITZ!OS) auch für andere lokale Geräte nicht mehr ohne weiteres erreichbar - je nach Szenario auch keine immer passende Lösung.