Wake-on-LAN vanaf internet via een derde computer

[aawe mwan]

Ik zoek een manier om automatisch Wake-on-LAN packets te laten genereren voor netwerkverkeer.

Is het mogelijk om een Ubuntu systeem te laten luisteren op de netwerkaansluiting en als hij ziet dat er een pakket langskomt voor een bepaalde computer, die op dat moment niet ingeschakeld is, om dan het betreffende etherwake commando te laten uitvoeren?

Mijn toepassing is het volgende. Ik heb een oude computer die ik via internet gebruik als server voor onder andere sftp en remote desktop (jumpserver). Hij stond normaal uit en als ik hem een keer nodig had, ging hij vanzelf aan, omdat de Fritz!Box automatisch het WOL-packet aanmaakte, wanneer een port-forward naar dit systeem gebruikt werd. En uit ging hij weer dankzij een cron-script dat ik daarvoor gemaakt had.

Dit werkte perfect, tot 11 april van dit jaar. Toen heb ik namelijk de firmware upgrade van de Fritz!Box 7360 geïnstalleerd. Een week later verscheen dit bericht op de AVM website: „Door een fout in FRITZ!OS 6.83 verstuurt de FRITZ!Box niet automatisch het magic packet dat nodig is voor "Wake on LAN". We werken aan een oplossing en zullen dit probleem zo spoedig mogelijk verhelpen met een FRITZ!OS-update. Tot de update beschikbaar is, kun je de Computer starten via de FRITZ!Box-gebruikersinterface.”. Lang verhaal kort: tot op de dag van vandaag, meer dan 8 maanden later, hebben ze nog geen nieuwe firmware gereleased.

Nu heb ik een Ubuntu 17.10 systeem dat gebaseerd is op een Atom processor, wat minder dan 10 Watt gebruikt. Dit systeem zou ik voorlopig 24 uur per dag aan willen laten staan, tot de nieuwe firmware voor de Fritz!Box er is, om het andere systeem (dat veel meer stroom gebruikt) wakker te maken. Kan dat?

[8088]

Met een beetje scripting (bijvoorbeeld in PHP) zou je een webinterface kunnen maken waarmee je WOL-packets kunt sturen.

[aawe mwan]

8088 schreef op dinsdag 26 december 2017 @ 12:53:
Met een beetje scripting (bijvoorbeeld in PHP) zou je een webinterface kunnen maken waarmee je WOL-packets kunt sturen.

De „FRITZ!Box-gebruikersinterface” die AVM noemt als alternatief is eigenlijk al een webinterface.
Dat gebruikte ik de afgelopen 8 maanden als alternatief, maar echt handig is dat niet.

Ik zoek meer naar een oplossing waarbij je niet elke keer vooraf handmatig iets extra's moet doen.

[Brahiewahiewa]

aawe mwan schreef op dinsdag 26 december 2017 @ 16:12:
[...]


De „FRITZ!Box-gebruikersinterface” die AVM noemt als alternatief is eigenlijk al een webinterface.
Dat gebruikte ik de afgelopen 8 maanden als alternatief, maar echt handig is dat niet.

Ik zoek meer naar een oplossing waarbij je niet elke keer vooraf handmatig iets extra's moet doen.

Maar dat betekent dat die atom-cpu dus al het netwerkverkeer op jouw netwerk moet scannen. Dus moet hij op een monitorport van de frtiz aangesloten zijn. En zal hij die 10 Watt ook permanent gebruiken.
Kun je op die oude laptop niet een disk-spindown doen? Goeie kans dat die dan minder dan 10 Watt gebruikt

[Hero of Time]

Had je de vorige firmware versie niet bewaart om te kunnen downgraden? Als dit zo'n belangrijke functie voor je is, had je dat op z'n minst moeten bewaren, met instellingen er naast natuurlijk.

Maar iets je hele netwerk laten sniffen en iets laten uitvoeren afhankelijk van wat er gevonden wordt is wat lastiger te maken dan luisteren op een specifieke instructie, zoals het oproepen van een webpagina. Heeft je Fritz!box geen VPN server optie? Dan zou je die eerder kunnen inzetten en door de VPN de magic packet proberen te versturen.

Daarnaast, hoe zwaar wordt je 'server' belast qua workload? Want als je een Atom systeem 24/7 wilt laten draaien puur en alleen om je 'server' wakker te maken kan je net zo goed alle taken die 't vervuld op dat pc'tje draaien.

[Will_M]

Waarom zou 't hele spel WAKE ON LAN heten? Als je 't direct over 't internet zou moeten kunnen benaderen hadden ze 't wel WAKE ON WAN genoemd, toch?

Iets wat ik direct met een "Magic packet" vanop 't internet kan benaderen staat serieus al véél te ver open naar de buitenwereld!!

[ Voor 4% gewijzigd door Will_M op 27-12-2017 01:01 ]

[Hero of Time]

@wimmel_1, je snapt niet helemaal wat de TS zegt dat er gebeurt. Er wordt geen WOL via internet gestuurd. De router stuurt die als de machine waar de portforward voor is ingesteld uit staat. Dus stel dat er een site draait en het systeem is in slaap, dan wordt deze door de Fritz!box via de magic packet wakker gemaakt als de site wordt benadert.

[Will_M]

Hero of Time schreef op woensdag 27 december 2017 @ 01:02:
@wimmel_1, je snapt niet helemaal wat de TS zegt dat er gebeurt. Er wordt geen WOL via internet gestuurd. De router stuurt die als de machine waar de portforward voor is ingesteld uit staat. Dus stel dat er een site draait en het systeem is in slaap, dan wordt deze door de Fritz!box via de magic packet wakker gemaakt als de site wordt benadert.

Waarschijnlijk snap ik 't inderdaad écht niet (óf wil ik 't überhaupt niet snappen?). Als je vanop een "vreemde" locatie een machine een power-up/down wil kunnen geven dan doe je dat (IMHO) maar nadat je ingelogd bent op een managementomgeving welke vervolgens ook alléén maar mag en kán connecten naar/met management NIC's.... En waarbij verkeer óver zo'n management NIC alsnog niks kan op 't OS van 't achterliggende systeem zélf. ((r)ILO(e) / DRAC.... SCVMM /VRealize...).

[vso]

waarom ipv een pc een goedkope zuinige pc
- raspberry pi
- intel nuc
- zotac
- moederbord met ipmi (kvm via lan)

Bij xs4all kreeg ik een gratis simkaart voor internet only kan je ook gebruiken voor Wake on USB,

[Wolfboy]

Hero of Time schreef op woensdag 27 december 2017 @ 00:49:
Had je de vorige firmware versie niet bewaart om te kunnen downgraden? Als dit zo'n belangrijke functie voor je is, had je dat op z'n minst moeten bewaren, met instellingen er naast natuurlijk.

Daar heeft de TS nu vast heel veel aan
Als dat een optie was dan had de TS waarschijnlijk dit topic niet geopend gok ik

Anyway, ik kan me in ieder geval een (hacky) oplossing bedenken... Gebruik een port knocking daemon om een WOL pakket te versturen
1. Laat de port knocking daemon luisteren naar een bepaalde trigger poort
2. Laat de port knocking daemon een WOL commando versturen

Alternatief om het volautomatisch te doen:
1. Stel op de low powered NUC een port forward regel in en laat die het verkeer routeren naar die andere PC.
2. Voeg bij die port forward regel een LOG regel toe
3. Laat een proces het log in de gaten houden en een WOL pakketje versturen zodra er voor het eerst wat data binnen komt binnen X minuten (wat ook de shutdown tijd is).

[aawe mwan]

@Brahiewahiewa De Atom zou inderdaad het complete netwerkverkeer moeten scannen, net zoals je dat met Wireshark bijvoorbeeld kunt doen. Ik vraag me af of het niet voldoende zou zijn om alleen de ARP packets te bekijken: als een computer een tijdje in slaapstand staat, kan je dat toch wel merken aan de ARP packets?

@Hero of Time Het upgraden van firmware wordt steeds „gemakkelijker”: het is een kwestie van op de knop drukken, bestanden met firmware heb ik nooit in handen gehad. Uitstellen van een upgrade van een router is vanwege de veiligheid (en SIP account) ook niet echt een optie. Ik had vlak voor de upgrade handmatig de instellingen in een bestand moeten opslaan, om terugrollen een optie te laten zijn. Aan terugrollen heb ik ook niet echt gedacht vanwege de doortrapte manier van communiceren: ik verwachtte dat er na een tiental dagen opnieuw een upgrade zou verschijnen, maar zoiets hebben ze natuurlijk helemaal niet beloofd.

@wimmel_1 Er draait op deze machine software die verkeer van internet verwacht. Vanwege stroombesparing gaat de machine pas aan op het moment dat er daadwerkelijk netwerkverkeer is op een gebruikte poort. Iedereen op internet kon mijn machine aanzetten door een portscan uit te voeren, maar gevaarlijk is dat niet en op mijn IP-adres merk ik dat niet eens, mits ik andere poortnummers gebruik dan de standaard poorten.

@Wolfboy Ik denk dat ik de sftp-server het best rechtstreeks op de Atom kan laten draaien
en voor de rest ga ik jouw tips proberen.

[Thralas]

aawe mwan schreef op woensdag 27 december 2017 @ 07:47:
@Brahiewahiewa De Atom zou inderdaad het complete netwerkverkeer moeten scannen, net zoals je dat met Wireshark bijvoorbeeld kunt doen. Ik vraag me af of het niet voldoende zou zijn om alleen de ARP packets te bekijken: als een computer een tijdje in slaapstand staat, kan je dat toch wel merken aan de ARP packets?

Correct. Meer dan ARP kun je ook niet doen, en daar krijgt hij het echt niet warm noch koud van. Tot iemand een ARP response stuurt zal je niet meer dan ARP requests zien op de lijn..

Maar je had zelf dus ook al iets bedacht; naar ARP responses luisteren en dan een magic packet sturen. Dat lijkt me prima te doen en vooralsnog de 'netste' oplossing.

Waar loop je daarbij vast? Ik kan namelijk 10001 manieren bedenken om dat op te lossen, van een regel shell commands tot iets in je favoriete programmeertaal.

[Houtenklaas]

Jij zal de V2 versie hebben denk ik, voor de V1 is er nooit een 6.83 geweest voor zover ik weet. De 6.52 firmware kan je hier downloaden voor de V2 versie van de 7360:

https://service.avm.de/do...4.06.52.recover-image.exe

[aawe mwan]

Thralas schreef op woensdag 27 december 2017 @ 21:48:
Maar je had zelf dus ook al iets bedacht; naar ARP responses luisteren en dan een magic packet sturen. Dat lijkt me prima te doen en vooralsnog de 'netste' oplossing.

Ik heb hiervoor dit gemaakt:

code:

# interface=enp1s0f1 \
; ip=192.168.178.44 \
; macadres=00:11:22:33:44:55 \
; tcpdump -i $interface -n -l arp \
| grep 'who-has '${ip//[.]/[.]} --line-buffered \
| xargs -l1 \
  etherwake -i $interface $macadres

en dat werkt perfect om een machine wakker te maken. Maar het probleem hiermee is dat als de machine zichzelf net uitgeschakeld heeft er alweer een nieuw ARP verzoek van fritz.box langskomt voor hem.
Zou ik met tcpdump bijvoorbeeld kunnen zien wat de aanleiding voor het ARP packet was?

[Hero of Time]

En nu heb je precies wat ik al dacht dat er zou gaan gebeuren. Daarom zei ik ook dat het wellicht beter is om alles te laten draaien op je energiezuinige machientje. Sftp en jumphost kan er bijvoorbeeld prima op draaien. Wat heb je nog meer dat er nodig is? Je kan dan alles laten doorsturen naar je Atom en alles wat eigenlijk voor je server is, forward je weer naar je 'echte' server waarbij je een etherwake doet om de dienst online te brengen.

[Thralas]

aawe mwan schreef op donderdag 28 december 2017 @ 09:54:
en dat werkt perfect om een machine wakker te maken.

Dat is inderdaad de oplossing die ik ongeveer in gedachten had. Je kunt eventueel nog het IP in het capture filter verwerken, scheelt greppen. Maar heel elegant gaat dat niet, dan zul je op de bytes van het IP binnen de ARP header moeten matchen (of tshark gebruiken).

Maar het probleem hiermee is dat als de machine zichzelf net uitgeschakeld heeft er alweer een nieuw ARP verzoek van fritz.box langskomt voor hem.

Dan heeft hij blijkbaar verkeer voor die machine.

Zou ik met tcpdump bijvoorbeeld kunnen zien wat de aanleiding voor het ARP packet was?

Zet de stroomslurpende machine uit en voeg het IP toe op je Atom. Dan beantwoordt hij alle ARP requests en kun je aan het packet erna zien wat de aanleiding was.

De FritzBox gaat echt niet zonder reden ARP'en voor je server; waar ik vermoed dat je tegenaanloopt zijn connection tracking entries die nog even blijven bestaan in je FritzBox. Bijvoorbeeld een UDP 'connectie'.

Als dat het probleem blijkt dan wordt het wel een complexere zaak om het geheel te automatiseren (ipv. een trivale expliciete trigger). Je zou dan het IP van je server moeten overnemen als deze down is, want dan kun je tenminste uitgebreidere tcpdump matching doen. Volgens mij twee regels met arping (duplicate address detection mode) & 'ip address add/del', maar het wordt wel een beetje hacky langzaamaan.

Misschien is het dan netter om alles gewoon door die Atom te NAT'en, maar ymmv.

[aawe mwan]

Er is een onverwachte wending in het hele verhaal gekomen.

Naar aanleiding van de discussie ben ik de Atom stick-PC gaan gebruiken als jumpserver en dat ging best goed: hij heeft sinds kerst stabiel gedraaid. En dat is bijzonder, omdat ik hem heb aangesloten via een FRITZ! Powerline adapter, die ik lang geleden in de kast gelegd had omdat hij in dit stopcontact niet stabiel te krijgen was. Maar nu is de verbinding gewoon prima.

Ik was dus van plan om de oude machine definitief te gaan vervangen door de Atom.

Totdat me opeens de volgende melding in de auth.log opviel:
Jan 27 03:14:57 〰machine〰 lightdm: pam_succeed_if(lightdm:auth): requirement "user ingroup nopasswdlogin" not met by user "〰ik〰"

Op dat tijdstip sliep ik. Hoe kan iemand deze machine hebben proberen te hacken, als die niet aan staat? Zouden ze een IoT apparaat op mijn LAN zijn binnengedrongen en van daaruit een WoL packet verstuurd hebben? Want een upgrade voor de FRITZ!Box was er nog steeds niet, dus het kon niet via internet komen.

Nou, dat bleek dus niet meer te kloppen. Bij het openen van dit topic heb ik nog gecontroleerd dat WoL via internet niet meer werkte, maar ergens tussen kerst en 27 januari is het blijkbaar spontaan weer gaan werken.

[Hero of Time]

En je punt nu? Welke machine komt dat log vandaan, je oude of de atom on a stick? En hoe zou je dan via internet inloggen op dat ding, met SSH of xrdp? Want je log melding is van LightDM, je Display Manager. Oftewel, je grafische interface. Ik hoop voor je dat je niet automatisch op de console inlogt als je systeem wakker wordt, want dat is een serieuzer security issue dan wanneer iemand domweg zonder wachtwoord probeert in te loggen. Het kan net zo goed je kat zijn die over 't toetsenbord loopt.

[aawe mwan]

Hero of Time schreef op zaterdag 10 februari 2018 @ 12:43:
En je punt nu? Welke machine komt dat log vandaan, je oude of de atom on a stick? En hoe zou je dan via internet inloggen op dat ding, met SSH of xrdp?

Het punt is dat het wakker maken ineens vanzelf weer is gaan werken. Ook voor de Synology NAS.

Deze logregel komt van een bestaande machine. Een kat is niet mogelijk, want op deze machine is geen toetsenbord aangesloten en ik heb geen kat. Op deze machine staat wel xrdp, maar alleen poort 22 (ssh) en poort 4000 (NoMachine) staan open voor internet (en daar gebruik ik op internet natuurlijk andere poortnummers voor).

Als ik door de logs van januari loop, denk ik dat deze melding op deze machine altijd één keer verschijnt als de machine gereboot is. Hij viel me nu op, omdat ik niet zelf de machine aangezet heb na de reboot.

In de logs van de FRITZ!Box zie ik dat deze vrijdag 26 januari 09:42 opnieuw is opgestart met de melding „The DSL settings for interference resistance were changed.”. En op 27/1 om 02:49:18 probeert een Kazachstans IP-adres 178.91.17.* met de usernaam „user” in te loggen bij de FTP service van de FRITZ!Box; waarschijnlijk een robot die daarna een grotere reeks poorten op mijn adres heeft gescand.