Na początku maja ubiegłego roku po wielogodzinnych testach, próbach i poszukiwaniach powstał artykuł stanowiący mini-kompendium wiedzy na temat Wake On LAN. Spotkał się ze sporym zainteresowaniem pomimo faktu, że opisane doświadczenia i wyniki były dość mocno ograniczone do posiadanego przeze mnie sprzętu, a w szczególności routera – Apple Time Capsule. Niestety to właśnie to urządzenie stanowi słabe ogniwo, przyczynę przez którą budzenie z sieci Internet nie działa poprawnie.
Osoby zaczynające dopiero zabawę z WOL zapraszam do lektury wcześniejszego artykułu – wiedza tam zawarta pomoże zrozumieć dzisiejszy wpis.
Niedawno – aktualizacja z dnia 24.07.2014 – zasugerowałem czytelnikom, posiadaczom innych routerów (z możliwością instalacji alternatywnego firmware’u) wykorzystanie VPNa(-u?) co mogłoby sprawić, że Magiczny Pakiet trafi do sieci lokalnej. Okazuje się, że oprogramowanie typu dd-wrt czy Tomato pozwala również na modyfikację, której nie oferują urządzenia sieciowe Apple, tj. dodawanie statycznych, trwałych wpisów w tablicy ARP na routerze. Z tego rozwiązania skorzystał Paweł Szczepanek (@pauluz_szczepan), który podzielił się z nami swoją wiedzą. Mail zawierający kolejne kroki prowadzące do celu zamieszczam w całości poniżej (odrobinę przeredagowany za sugestią i zgodą autora):
Cześć
Przeczytałem aktualizacje, piszę do ciebie list zamiast komentarza we wpisie. Zawartość tego listu daję na prawach CC 3.
Mam router Linksys WRT160NL z oprogramowaniem: DD-WRT v24-sp2 (08/07/10) std (SVN revision 14896)
Konfiguracja komputera wzbudzanego: Win7 Ultimate 64-bit, Gigabyte GA-F2A85X-UP4, AMD APU A10-5800k 4GHz; karta sieciowa: RealTek Semiconductor RTL8168/8111 PCI-E Gigabit Ethernet NIC
Ponieważ zadziałało budzenie kompa na odległość (z internetu), więc opiszę co robiłem.
Przeczytałem ten wpis w wikiaby lepiej zrozumieć jak to może działać. No i generalnie chodzi o to, że forwardowanie portów 9 lub 7 na adres rozgłoszeniowy często nie działa. Raczej nie chce wnikać dlaczego ale coś bym przypuszczał, że specyfikacja nie pozwala na zapis w odpowiednich plikach konfiguracyjnych od routingu przekierowania na adres typu 192.168.1.255 (broadcast).
Stąd rozwiązanie leży w tym, że kierujemy te porty (9) na inny adres, na którym NIE MA jakiegoś urządzenia – np. 192.168.1.254 i ten adres w tablicy ARP definiujemy jako rozgłoszeniowy (konstruujemy na nim odpowiedni pakiet rozgłoszeniowy).
Ja tak zrobiłem jak piszą w tym rozdziale na dd-wrt, czyli:
dałem forwarding:
wol | 9 | 9 | udp | 192.168.1.254 | x
i uzupełniłem ARP:
arp -i br0 -s 192.168.1.254 FF:FF:FF:FF:FF:FF
W artykule wyjaśniają dlaczego tak a nie inaczej trzeba go zbudować (to FF:…) oraz co tam jeszcze jest istotne.
Do obserwowania przychodzących pakietów Magic używam programu Wake-On-Lan Packet Sniffer (co ciekawe mam wersję 1.2 a na stronie widnieje v1.1), a pakiety wysyłam z programu Wake On Lan GUI.
Dla mnie ważne było to że wysyłałem Pakiet Magic z maską 255.255.255.255 na mój IP routera z adresem MAC ustawionym już dla właściwego kompa w LAN. Bez tej maski nie przekazywał całego IP routera tylko rozgłoszeniowy (a więc typu xxx.xxx.xxx.255)
Tutaj właśnie tego nie rozumiem w pełni. Być może chodzi z tymi maskami o to, aby pakiet Magic wysłać do wszystkich komputerów w podsieci, ale ja w tym momencie (wysyłka z Internetu) nie chcę go posyłać gdzieś na wiele IP tylko konkretnie na ares IP mojego routera. Potem dopiero rozgłosi się już w mojej sieci lokalnej za routerem.
Generalnie działa u mnie bo Sniffer pokazuje że przyszedł pakiet. Mówię tu oczywiście o wysyłaniu z całkiem innego miejsca w sieci.
Kompy obserwowałem przez TeamViewer. Całkiem zacny programik i śmiga za Free dla użytkowników niekomercyjnych.
Sam TeamViewer także oferuje wzbudzanie kompów jeśli mamy je zarejestrowane w tym programie, ale to nie zadziałało u mnie – trochę mnie to martwi, bo nie widzę przeciwskazań aby TeamViewer wysłał Magic Pakiet na wskazany przeze mnie IP routera – i potem już router z portu 9 zajął by się resztą….
Mam jeszcze po drugiej stronie mojej sieci router D-Link DIR-300, ale posiada fatalny interfejs webowy i nie można modyfikować w nim tablicy ARP.
Na forach polecają po prostu podmienić w nim zarządzanie na dd-wrt ale tego się na razie nie podjąłem. http://www.dd-wrt.com/wiki/index.php/DIR300 (mam tę wersję Revision A)
Samo skierowanie w tym DIR-300 portu 9 na broadcast do mojej sieci LAN nie dawało efektu – i temu się nie dziwię. Sądzę że podobnie i w tym routerze musiałbym
dopisać wpis do ARP.
I na koniec: tutaj piszą, że aby móc wysyłać pakiet budzący z Internetu, wymagany jest router na którego można się telnetować i ustawiać wpisy w ARP.
To tyle.
Pozdrawiam
Ze swojej strony dodam, że:
jeśli wasz router pozwala na dostęp via Telnet/SSH możecie z poziomu tego urządzenia wysłać Magiczny Pakiet wykorzystując komendę wol (przy czym należy zastosować pełną ścieżkę!):
192.168.1.255 – ten adres należy zastąpić adresem rozgłoszeniowym w waszej sieci lokalnej,
AA:BB:CC:DD:EE:FF – oznacza adres MAC komputera, który chcecie obudzić.
Kwestia maski 255.255.255.255 o której pisze Paweł związana jest z wybranym sposobem wysyłania pakietów:
Limited broadcast. Magic Packet sent to the limited broadcast address (255.255.255.255) it is received by all machines on the same subnet but not forwarded to machines on other subnets.
Czyli właśnie dzięki jej zastosowaniu gwarantujemy, że pakiet trafi wyłącznie do wszystkich urządzeń znajdujących się w tej samej podsieci, i nie zostanie przesłany dalej.
Jak wcześniej wspomniałem, ograniczenia Time Capsule sprawiają, że powyższe przepisy nie zadziałają. Można wydłużyć nieco czas przechowywania wpisów w tablicy ARP stosując adresację statyczną, włączyć domyślny host w Narzędzie AirPort -> wybieramy Time Capsule i klikamy Edycja -> Sieć -> Opcje sieci, ale prędzej czy później utracimy możliwość wybudzania komputera.
Oczywiście, jeśli poświęcimy jeden komputer i pozostawimy go włączonego, to po zdalnym podłączeniu możemy z tego komputera wybudzić pozostałe maszyny w sieci. Wydaje mi się jednak, że zdecydowanie bardziej rozsądnym rozwiązaniem będzie wymiana routera.
Nie tak dawno opisywałem na łamach applesauce swoje boje z klimatyzatorem. Jedną z kwestii, która mnie pozytywnie zaskoczyła, było to, że dzięki dedykowanej aplikacji oraz posiadaniu konta w serwisie producenta, mogę zdalnie urządzenie wyłączać – a co ważniejsze – również je włączać. Postanowiłem sprawdzić, jak wygląda sprawa uruchamiania, bądź wybudzania komputerów, na odległość. I temu właśnie tematowi poświęcam niniejszy wpis.
Na samym początku zdradzę, że finalne efekty są dość zdywersyfikowane i zależą od wielu czynników, które nie omieszkam się opisać. Temat potraktowałem raczej ambicjonalnie, ponieważ jak dotąd udawało mi się funkcjonować bez takich udogodnień, ale jak wiadomo, apetyt rośnie w miarę konsumpcji, a z oczekiwaniami dotyczącymi wygody, jest identycznie :)
Większość z Was, drodzy czytelnicy jeśli nie miała do czynienia, to słyszała pojęcie: WOL – Wake On LAN, czyli wybudzanie po sieci lokalnej. Oczywiście określenie to, używane jest obecnie także do opisania innych metod, ale po kolei. Załóżmy, że mamy komputer i chcemy go zdalnie obudzić, w takiej sytuacji pojawiają się następujące problemy do rozwiązania:
platforma: Mac / PC
sposób podłączenia do sieci: Ethernet / WiFi
dostęp do sieci, lokalnie lub z Internetu: LAN / WAN
stan komputera: uśpiony / wyłączony
Z powyższymi wiążą się kolejne komplikacje. Spędziłem kilka długich dni na testach i poszukiwaniach, a sprawę utrudniały dość często sprzeczne informacje, dostępne u wielu źródeł.
Całą tajemnicę budzenia na odległość, można uprościć do dwóch, koniecznych warunków:
z urządzenia nadawczego (komputera/smartfona/tabletu/itp.) wysyłamy specjalnie spreparowane dane, zwane Magic Packet,
odbiorca pakietu musi mieć aktywny interfejs sieciowy, bym móc ten magiczny pakiet przyjąć.
Rzecz jasna, „od kuchni” jest to znacznie bardziej skomplikowanie…
STAN KOMPUTERA
Niezależnie od tego, czy komputer jest uśpiony czy wyłączony, by zagwarantować odbiór magicznego pakietu, karta sieciowa komputera MUSI być zasilana. Wyłączony interfejs oznacza komputer odłączony od sieci.
Sytuacja I – Komputer uśpiony
Sprawdzamy odpowiednie preferencje systemowe. Dla OS X weryfikujemy, czy „zaptaszkowana” jest opcja Budź przy dostępie przez sieć, którą znajdziemy w kategorii Oszczędzanie energii.
Pod Windowsem natomiast, musimy sprawdzić właściwości karty sieciowej, w dwóch miejscach:
Zarządzanie energią (tu warto zaznaczyć wszystkie opcje, lub ew. pominąć pierwszą, związaną z oszczędzaniem energii)
Zaawansowane (tutaj warto dla każdej właściwości związanej z budzeniem, przełączyć wartość na Włączone)
Może się okazać, że mamy pecha i akurat nasz sprzęt nie posiada interfejsów sieciowych wspierających Wake On LAN… Kolejna sprawa to notebooki i laptopy – może się okazać, że aby wybudzić uśpiony taki komputer, musi być on podłączony do prądu, inaczej mówiąc zasilany z sieci energetycznej, a nie oczekujący na zasilaniu bateryjnym. Z drugiej strony, komputer przenośny częściej mamy pod ręką, zatem zapewne rzadziej zachodzi potrzeba zdalnego wybudzenia.
Sytuacja II – Komputer wyłączony
Tutaj niestety muszę zmartwić wszystkich użytkowników jabłuszek – na chwilę obecną nie ma możliwości zdalnego zastartowania wyłączonego Maczka :/ Trudno powiedzieć, co odpowiada za taki stan rzeczy, czy „Think Different”, czy wyjście z założenia, że macuserzy nie wyłączają swoich komputerów, tylko je usypiają? Nawet jeśli OS X jest stabilny jak skała, to jednak wyjeżdżając na dwutygodniowe wakacje, zostawiać go uśpionego (zwłaszcza, gdy brak UPSa) nie będziemy. A los bywa tak perfidny i dowcipny, że akurat w tym właśnie czasie, możemy potrzebować dostępu do istotnych plików…
Tak czy inaczej, jedyne wyjście na to by Mac dał się obudzić (i dotyczy to zarówno budzenia w sieci lokalnej jak i przez Internet), to przełączyć w tryb sleep. W tym stanie podtrzymywana jest pamięć, karty sieciowe i inne niezbędne komponenty. Nie wiem, z jakim poborem mocy należy się w takiej sytuacji liczyć, będzie to zdecydowanie więcej niż gdyby komputer był wyłączony (no, nie całkowicie). Z drugiej strony możemy śmiało założyć, że z uwagi na przyjazność środowisku, produkty Apple, nie są aż tak łakomymi pożeraczami energii.
Z pecetem jest tu nieco lepiej, ale za pełen sukces odpowiada „szczęście egzemplarza”. To od możliwości płyty głównej oraz dostępnych ustawień w BIOSie/EFI zależy czy nasz komputer włączymy zdalnie czy nie. Pecet w moim domu, bazuje na starej już płycie głównej Asus P8P67LE, ze zintegrowanym Gigabit Ethernetem firmy Realtek (PCIe). W BIOSie, w trybie zaawansowanym, w menu Advanced i kategorii zwanej APM załączyłem „Power On By PCIE”. Tak po prawdzie, z lenistwa, to załączyłem prawie wszystkie dostępne tam opcje Power On :)
Bardzo często przy złączu RJ-45, na tylnym panelu, znajduje się dioda sygnalizująca pracę karty sieciowej, jeśli się świeci przy wyłączonym komputerze, to oznacza, że ten interfejs jest podtrzymywany, a Magic Pocket powinien uruchomić urządzenie.
PODŁĄCZENIE DO SIECI
Według praktycznie wszystkich źródeł, komputer, który chcemy wybudzić zdalnie, powinien być podłączony do sieci po kablu. Informacje takie, znajdziemy również w appkach dla iPhone, które potrafią wysłać magiczny pakiet (opiszę je nieco dalej). Śmiem twierdzić, że nie jest to stuprocentowa prawda, i zależy to od konkretnego modelu komputera, płyty głównej, bezprzewodowej karty sieciowej, oraz systemowego wparcia. Mój stacjonarny pecet nie posiada karty WiFi, ale sprawdziłem możliwość wybudzenia bezprzewodowego w służbowym laptopie (Asus K52JC), niestety próby zakończyły się całkowitym niepowodzeniem.
Okazuje się, że – dla odmiany – z komputerami Apple jest tu lepiej. Firma, jak ma w zwyczaju, wdrożyła własną implementację WOL zwaną WOD – Wake On Demand. Nie będę tu przepisywać specyfikacji, streszczę tylko wyjaśniając, że funkcja ta działa oczywiście tylko z uśpionymi komputerami, oraz wykorzystuje technologię Bonjour a dokładnie usługę Bonjour Sleep Proxy, oraz działa również z kartami bezprzewodowymi AirPort! Czy nasz komputer posiadający taką kartę WiFi obsługuje WOD, należy sprawdzić w aplikacji Informacje o systemie (dawniej Profil systemu).
O dziwo mój stary iMac wspiera Wake On Demand i przewodowo i bezprzewodowo.
BUDZENIE W SIECI LOKALNEJ
To przysłowiowa bułka z masłem, o ile nasze komputery spełniają wyżej opisane warunki. Potrzebujemy jedynie „prowodyra”, czyli urządzenia które wyśle Magic Packet. Ja oczywiście od samego początku myślałem o iPhone, urządzeniu, które mam praktycznie 99% czasu przy sobie, jako inicjatorze pobudki pozostałych gratów. W tym celu przeprowadziłem szybkie poszukiwania odpowiedniej aplikacji. App Store „wypluł” pokaźną listę, którą zgrubnie odfiltrowałem, zostawiając na polu bitwy tylko darmowe appki. Poniżej przedstawię dwie, moim zdaniem najlepsze.
NetAwake – program autorstwa Power of Two Software to, szybkie proste i estetyczne i estetyczne rozwiązanie WOL. Przewagą NetAwake nad innymi programami jest to, że wykorzystuje Bonjour, do wyszukiwania możliwych do wybudzenia maszyn w sieci.
Inaczej mówiąc, jesteśmy zwolnieni z odnajdywania i wpisywania fizycznych adresów interfejsów, tzw. adresów MAC, które to stanowią kluczową informację determinującą odbiorcę magicznego pakietu.
W przypadku innych platform trzeba ręcznie dodać wpis zawierający nazwę i MAC adres. Myślałem, że instalacja tego, rozwiąże sprawę, jednak NetAwake nie chce, z automatu, mojego peceta zobaczyć…
Chyba jedyną wadą NetAwake jest fakt, że nie ma możliwości podania adresu IP, co przy budzeniu z sieci zewnętrznej (WAN) jest elementem niezbędnym.
Ograniczenia tego, nie ma druga z polecanych przeze mnie appek.
Mocha WOL – to produkt MochaSoft znanego z wielu innych programów wspierających zabawy w sieci.
Nie jest może idealny, ale posiada wystarczające możliwości konfiguracyjne i jest również darmowy.
Pozwala również na zmianę domyślnego (9) portu usługi!
Gdy mamy już ściągniętą i zainstalowaną taką aplikację na iPhone, dodaliśmy komputery, są uśpione (lub wyłączone, w przypadku PC wspierającego Power On…), możemy śmiało rozpocząć pobudkę na odległość!
To zdecydowanie najtrudniejsza w realizacji sprawa, właściwie to możliwa do osiągnięcia w bardzo specyficznych warunkach.
Na pierwszy rzut oka, wygląda na to, że jedynym problemem jest dostarczyć pakiet z sieci rozległej WAN do lokalnej LAN. Ale to zaledwie początek góry lodowej…
Po pierwsze musimy uświadomić sobie, że nasza sieć lokalna, jest widoczna w Internecie pod publicznym adresem IP, przypisywanym naszemu modemowi, przez dostawcę usługi (ISP). Problem w tym, że większość popularnych usług (Neostrada, Net24, itp.) przypisuje ten adres dynamicznie, czyli zmienia się on co jakiś czas, a zmiana ta może być inicjowana przez operatora, bądź wynikać np. z restartu modemu (po zmianie ustawień lub przerwie w zasilaniu). Gdy adres się zmieni, to go nie znamy, więc trudno z zewnątrz dostać się do swojej sieci.
Najlepszym rozwiązaniem jest posiadanie stałego publicznego (zewnętrznego) adresu IP. Niektórzy operatorzy (np. w sieciach kablowych) oferują taką możliwość za dodatkową opłatą, u innych wiąże się to ze zmianą „taryfy”, z indywidualnej na firmową.
Alternatywnym rozwiązaniem są serwisy DDNS, jak no-ip.com czy dyn.com które pozwalają na rejestrację domeny powiązanej ze zmiennym publicznym adresem naszej sieci. Niestety, aby móc aktualizować to przypisanie, musimy:
„poświęcić” jeden z komputerów w naszej sieci lokalnej, zainstalować na nim oprogramowanie klienckie, które po każdej zmianie adresu IP wyśle notyfikacje to naszego konta w serwisie DDNS, lub
posiadać router wspierający usługę Dynamic Domain Name System, a urządzenie włączone 24 godziny na dobę, samo będzie wysyłać aktualizacje do serwisu.
Niestety, Time Capsule nie wspiera DDNS w taki sposób, by możliwe było skorzystanie w wyżej wymienionych serwisów.
Próbowałem zgłębić temat iCloud i usługi Zdalnie na moim Macu (Back To My Mac), bo przecież tą drogą aktualizacje zmian adresu IP również się dokonują. Jednak, jak się okazało, Apple korzysta tu z protokołu i adresacji IPv6, co sprawę komplikuje na tyle, że się w końcu poddałem.
Gdy się uporamy ze zmiennym publicznym adresem IP, będziemy musieli się zmierzyć z kolejnym problemem – przekierowanie portu, na którym działa usługa WOL (domyślnie 9, ale często też wykorzystywany jest port o numerze 7). Znów, wygląda to trywialnie i właściwie w przypadku znakomitej większości routerów, to prosta sprawa. Sęk w tym, że przekierowanie powinniśmy ustawić na tzw. adres rozgłoszeniowy (ang. broadcast address) naszej sieci lokalnej! Dlaczego? Ano dlatego, że interfejsy sieciowe, nawet jeśli są podtrzymywane „przy życiu”, to gdy komputery są uśpione bądź wyłączone, nie mają przypisanych prywatnych adresów IP. Dlatego magiczny pakiet wysyłany musi być do wszystkich potencjalnych odbiorców, czyli po całej puli adresowej sieci lokalnej. Lecz tylko odbiorca, posiadający właściwy adres MAC, przesyłkę odbierze i zinterpretuje.
Tu pojawia się kolejna wada Time Capsule – nie pozwala na przekierowanie portu na adres rozgłoszeniowy (np. 192.168.1.255).
Próbowałem partyzantki, tj. ręcznej edycji pliku konfiguracyjnego TC, bez skutku. Utworzyłem podsieć, czyli ograniczyłem o połowę pulę DHCP, zmieniłem maskę podsieci na 255.255.255.128, tak by broadcast był pod adresem 192.168.1.127 – to również nie zadziałało.
Przeprowadziłem też zabawę z przypisywaniem adresów statycznych komputerom, i utworzyłem przekierowania portów dla tych konkretnych IP.
I… nawet to poskutkowało, ale tylko przez kilka minut po uśpieniu/wyłączeniu komputerów. Dokładnie trwało to tyle czasu, ile funkcjonowały wpisy w tablicy ARP routera. Wpisy tworzone są dynamicznie i przechowywane w pamięci podręcznej, oraz usuwane/odświeżane po upłynięciu tzw. czasu życia odwzorowania.
No to mamy trzecią już wadę Time Capsule – brak możliwości utworzenia statycznych odwzorowań w tablicy ARP.
No to by było chyba na tyle :) Jeśli macie jakieś pytania, lub własne doświadczenia, podzielcie się nimi w komentarzach. Mam nadzieję, że to mini-kompendium, zebrane w jednym artykule, mimo że dotyczy konfiguracji mojego „parku maszynowego”, pomoże zainteresowanym, w rozwiązaniu podobnych problemów.
Ja, chcąc nie chcąc, muszę zakceptować niedoskonałości TC i zrezygnować z budzenia komputerów przez Internet. Bardziej mnie jednak irytuje fakt, że wciąż nie wiem, jak rozwiązali ten problem magicy z Samsunga…
Zapraszam Cię do innych ciekawych wpisów dotyczących sieci, które ukazały się na applesaue.pl:
