![]() |
Wake on LAN aus öffentlichem Netz
Hallo,
ich versuche aus dem öffentlichen Netz heraus meinen Rechner zu Hause aus zu starten. Leider gelingt mir dies nur im Netzwerk zu Hause. Hier mal meine Firewall Regeln dazu: Action Name Source Dest Protocol,Port Allow WOL1 WAN, xxx LAN, 192.168.0.2 *,7 Allow WOL2 WAN, xxx LAN, 192.168.0.2 *,9 Ich habe auch probiert den Rechner in die DMZ zu stellen und Port Forwarding zu betreiben. Kann es sein, dass das Senden von Magic Packets im öffentlichen Netz unterbunden wird? Wenn ja wie merke ich das bzw. wie kann ich das umgehen? Vielen Dank für eure Tips! Viele Grüße anve |
Hab mich schon lange nicht mehr damit beschäftigt,
aber welches WoL verwendest du? Wenn ich mich richtig erinnere, gibt es unterschiedliche Arten ... Die üblichste ist mit einen "Magic Packet" wo die MAC mehrfach und noch andere Werte in das lokale Netzwerk geschickt werden. (Hat nur den Nachteil, dass dieses Paket das eigene Netzwerk nie verlässt) Was du brauchst, ist ein Modus über TCP oder UDP (Unicast IP) ... wobei TCP üblicherweise weniger Probleme bei den Routern macht. Allgemein: http://de.wikipedia.org/wiki/Wake_On_LAN Linux Seite mit Zusammenstellung der üblichen Modus: http://www.brueck-computer.de/index2...=1404&link=1#3 |
Das per Magic Packet. Ich verwende WOL GUI dafür: http://www.depicus.com/wake-on-lan/wake-on-lan-gui.aspx
Ist aber für Windows ;) D.h. wenn ich ein anderes Tool verwende, dann gehts? OK, hab ich noch nicht probiert. |
Das tool scheint das eh zu unterstützen ... aber schau mal auf deinen zu weckenden PC in den WoL Einstellungen nach, was ihn alles aufwecken lässt.
Hab eine alte Anleitung für Windows gefunden: http://www.novak.it/?p=67 Das einzige was ich anders machen würde ist, dass ich testweise "pattern match" auch zulassen würde. |
Hi ZombyKillah,
die Anleitung hab ich auch benutzt um das WOL zum Laufen zu kriegen (inkl. dem Tool) ;) Pattern match hab ich zugelassen. Meine einzige Firewall-Regel besteht aus folgendem Port-Forwarding: Action Name Source Dest Protocol,Port Allow WOL1 *, * LAN, 192.168.0.102 UDP,9 Zusätzlich habe ich "Nur Verwaltungsstationen können Standbycomputer aktivieren" deaktiviert (im Gegensatz zur Anleitung!). Mit dem in der Anleitung gepostetem Tool (http://ifatwww.et.uni-magdeburg.de/wol/) habe ich es geschafft den PC einzuschalten. Wenn ich jedoch in das öffentliche Netz gehe, passiert gar nichts. Ich hab auch in die Log-File gesehen und beim Online-WOL-Tool habe ich das Port-Forwarding erkannt. Wenn ich das öffentliche Netz verwende, ist kein Eintrag zu finden. Heißt das das öffentliche Netz ist schuld? Zumindest eine Umgehungsmöglichkeit hätte ich schon :D Lieber wär es mir, wenn ich es aus dem öffentlichen Netz zum Laufen kriegen würde. Vielen Dank für deine Hilfe. Liebe Grüße anve |
hallo anve,
du scheinst ucasts zu verwenden. wie sollen die arp requests beantwortet werden, wenn der rechner pennt? http://www.dieschmids.at/Speedtouch-...n-WOL-wie.html lg zid |
Hi zid,
ich habe eine DHCP Reservation List wo diese Zuordnung zwischen Mac und IP-Adresse stattfinden könnte. Ansonsten könnte das Online-WOL-Tool meiner Meinung nach nicht funktionieren. Ein Broadcast wäre über diesen Router nicht möglich. Ich denke trotzdem, dass das öffentliche Netz zu strikte Firewall regeln hat und das rausfiltert (mit welcher Regel?). Grüße anve |
wol kann doch nicht mit einer port weiterleitung auf einen bestimmten pc funktionieren, der ausgeschaltete pc hat ja keine ip adresse. Das portforwarding muss auf die broadcast adresse zeigen, bei dir 192.168.0.255, und selbst dann hast nur eine chance wenn dein router überhaupt eigehende broadcasts verarbeitet.
|
hallo anve,
>"...ich habe eine DHCP Reservation List wo diese Zuordnung zwischen Mac und IP-Adresse stattfinden könnte..." dann muß die firewall aber diese list auswerten. das tun die wenigsten... >"...Ein Broadcast wäre über diesen Router nicht möglich..." net-directed bcasts sind grundsätzlich routebar, aus sicherheitsgründen ist das routing dieser bcast meist deaktiviert. bei höherwertigen geräten kann man aber das routing-verhalten konfigurieren. >"...Ich denke trotzdem, dass das öffentliche Netz zu strikte Firewall regeln hat und das rausfiltert..." ich verwende wake-on-wan schon jahrelang in den unterschiedlichsten netzen (aus sicherheitsgründen immer ucasts) und hatte noch nie probs, auch andre, die wow verwenden, haben noch nie über derartige probs berichtet... ist aber egal, weil du das ganz einfach selbst überprüfen kannst: du installierst am zu weckenden rechner den wireshark, startest ihn (ggf. sicherheitssoftware am pc *für die dauer des versuchs* deaktivieren) und schickst von draußen ein magic packet rein. da der rechner on ist, gibts für ihn einen dynamischen eintrag im arp-cache der firewall, sodaß arp kein problem ist. falls das magic packet nicht im shark sichtbar ist, dann wird es sicher von irgendeiner firewall geblockt, und ich würd mit der suche gleich bei der eigenen firewall beginnen... sollte es sich herausstellen, daß dein provider tatsächlich die magic packets blockt, dann hast du nur noch 2 möglichkeiten: - du ziehst einen tunnel zur firewall auf und tunnelst die magic packets. - du verwendest eine(n) firewall/router, die/der einen wol-client implementiert hat (draytek, alternative sw. wie dd-wrt, pirelli...). lou, >"...wol kann doch nicht mit einer port weiterleitung auf einen bestimmten pc funktionieren, der ausgeschaltete pc hat ja keine ip adresse..." die ip/udp-kapselung wird ja auch nicht für wol selbst verwendet, sondern ist vielmehr eine hilfskonstruktion, um das magic packet überhaupt routen zu können- und *nur* dazu wird sie verwendet. es gibt 2 typen von wol-anwendungen: 1. clients die das magic packet nicht kapseln, sondern im raw format rausschicken (d.h. nur mit dem ethernet-header). "etherwake" unter linux wär so ein beispiel. 2. clients, die das magic packet in ip/udp kapseln, z.b. "wol" unter linux. will man clients vom typ1 verwenden, dann müssen wecker und schläfer in derselben bcast domain angesiedelt sein, weil raw packets nicht geroutet werden können. ist das nicht der fall (also insbesondere bei wow), muß man zwangsläufig clients vom typ2 verwenden. aus dem gesagten folgt weiters, daß das socket, an das das magic packet weitergeleitet wird, im prinzip völlig egal ist. es muß nur in dem verwendeten adressbereich liegen und eindeutig sein. wenn man das magic packet an eine andere adresse als die lan-ip des schläfers schickt, wird nach dem erwachen des schläfers der arp-cache der firewall vergiftet (2 ips mit derselben hw.-address). und da die leute idr. weniger auf vergiftete arp-caches stehen, wird als ziel für die magic packets die lan-ip des schläfes genommen. mehr isses nicht. lg zid |
Hallo zid,
ich habs nun probiert. Es funktioniert über das eine öffentliche Netzwerk nicht (Firewall deaktiviert, PC in DMZ). Nur über das Online-WOL-Tool (mit Firewall, ohne DMZ, nur Port-Forwarding-Regel). -Wie funktioniert das Tunneling? Was wird dazu benötigt (Tools)? -Verwende einen D-Link DIR-100 als Router, aber der hat keinen WOL-Client integriert. Einen anderen werde ich mir wahrscheinlich auch nicht anschaffen (hängt von den Kosten ab). Gibts für meinen überhaupt eine alternative Firmware? LG anve |
hallo anve,
>"...Es funktioniert über das eine öffentliche Netzwerk nicht (Firewall deaktiviert, PC in DMZ). Nur über das Online-WOL-Tool..." ich versteh jetzt kein wort... du mußt auf alle fälle von außen testen, weil dein dlink kein natloopback kann. was ist das für ein "Online-WOL-Tool", und was meinst du mit "das *eine* öffentliche Netzwerk"? mit dem wol-client der uni magdeburg (s.o.) sollte das ganze wie in dem screenshot ausschauen (ich hab den udp/40000 genommen). setz ev. einen ansichtsfilter, wie ich es getan hab, dann übersiehst du das magic packet sicher nicht. http://www.bilderkiste.org/show/orig...burg_wows.jpeg welchen provider hast du, und über welchen isp geht dein wecker ins inet? >"...-Wie funktioniert das Tunneling? Was wird dazu benötigt (Tools)?..." ein(e) router/sa, der/die ipsec kann. dann ziehst du einen ipsec-tunnel auf (site-2-site oder client-2-site) und tunnelst das magic packet. ich verwende für solche gschichterln meist bintecs oder das st608(wl), und das auch nur dann, wenns um heiklere netze geht. im normalfall schick ich das magic packet unverschlüsselt oder wecke lokal, wenn der eingesetzte router eine wol-anwendung integriert hat. >"...Verwende einen D-Link DIR-100 als Router..." mit der gurke kannst wow vergessen... hab kurz bei dd-wrt nachgeschaut, der dir-100 ist nicht unter den supported devices: http://www.dd-wrt.com/wiki/index.php...Devices#D-Link detto openwrt: http://wiki.openwrt.org/toh/start#d-link http://wiki.openwrt.org/oldwiki/hardware/dlink lg zid |
Hi zid,
schön das du noch da bist ;) Mit öffentlichem Netzwerk meine ich ein Uni-Netzwerk. Ich habe von außen getestet. Einmal über das Uni-Netzwerk und einmal mit dem Online-WOL-Tool (WOL-Client der Uni Magdeburg). Das Magic Packet hab ich nur beim WOL-Client der Uni Magdeburg gefunden (auch ohne Filter probiert und Datenverkehr minimiert). Provider öffentliche Netzwerk: ACOnet Provider Home-Netzwerk: Chello IPSec unterstützt der DIR-100 noch nicht. Mal sehen ob ich ihn austausche. Ich hab auch schon nach Unterstützung bezüglich dd-wrt nachgesehen. Lässt sich nichts machen. Bleibt noch mein Online-WOL-Tool, was ja funktioniert. Weißt du welches php-Skript dahinter läuft? Könnte man das auch im Webserver laufen lassen? LG anve |
hallo anve,
chello blockt inbound magic packets sicher nicht, das weiß ich. >"...Bleibt noch mein Online-WOL-Tool, was ja funktioniert..." das ist aber nur der erste teil der lösung... du hast ja getestet, als der schläfer wach war und in diesem fall gibts einen dynamischen arp-eintrag im arp-cache des dlinks, sodaß der dlink den rechner findet. wenn der rechner sich aufs ohr haut, wird dieser dynamische eintrag nach einer gewissen zeit gelöscht und danach weiß der dlink nicht mehr, wohin er das magic packet weiterleiten soll- er verwirft es dann still. du müßtest also das magic pakerl als net directed bcast weiterleiten, was beim dlink jedoch nicht machbar ist. ich würd an deiner stelle nägel mit köpf machen: - in der geräteliste von dd-wrt einen router aussuchen, der dir zusagt- er sollte min. 4 mb flash haben- und den dir100 gegen diesen austauschen. - dd-wrt auf den neuen router ziehen und https (bei der mini version nicht verfügbar) oder ssh wanseitig öffnen (dd-wrt hat den wol-client "wol" integriert). - und schon fertig- einfach und sicher :) lg zid |
hm, eine billige 2. lösung gäbs auch noch:
du ergatterst dir ein st546v6/st585v6. da du bei chello das dsl-modem nicht brauchst, ist der annex wurscht, und da würd ich mich auf die isdn-variante stürzen- größeres angebot und deshalb niedrigere preise...;) vorsicht bei geräten aus gb(o2) oder nl(kpn), da ist der bootloader gesperrt. - das ding für chello herrichten - den früher erwähnten ucast-ansatz von dieschmids.at durchziehen. - damit funkt einmal das online wol-tool der uni magdeburg. - die security policy von aconet scheint ziemlich restriktiv zu sein. ich glaube aber nicht, daß der udp/53 (dns) outbound geblockt wird...*gg* über diesen port könntest du dann wol laufen lassen- würd ich aber vorher testen. wär auch 'ne möglichkeit, hat aber für mich weniger charme als der ansatz von oben, weil hier das magic packet unverschlüsselt übers wan geschickt wird. lg zid |
Hallo zid,
du hast Recht. Der arp-cache wird nach einiger Zeit gelöscht. Ich hatte damals den Rechner nur kurz aus und da hat das Online-WOL-Tool funktioniert, da der Cache noch nicht gelöscht war. Vielen Dank für deine Tips. Du nimmst dir echt viel Zeit! Ich werde mir dann eine Lösung aussuchen. Wenn ich dann noch eine Frage habe, dann frag ich dich :D LG anve |
hallo anve,
>"...Ich hatte damals den Rechner nur kurz aus und da hat das Online-WOL-Tool funktioniert, da der Cache noch nicht gelöscht war..." *das* kenn ich. wenns um wow geht, dann sind problembeschreibungen in etwa dieser preisklasse fast schon standard: "...wenn ich meinen rechner daheim abdrehe und dann von außen wecke, funkts immer. wenn ich in die firma fahr und die gurke von dort wecken will, funkts nimmer..." gut, für 0815 fragen hab ich 0815 antworten: "...ja, mein lieber, aus deiner problembeschreibung schließe ich haarscharf, daß die anfahrtszeit zu deiner firma größer ist als der idle timeout des arp cache deines routers. vergiß das auto und nimm 'nen hubschrauber..." :D lg zid |
*lol* :D
der ist gut |
| Alle Zeitangaben in WEZ +2. Es ist jetzt 22:30 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag