Czy to prawda, że nie możemy pozwolić na uśpienie żadnej maszyny, która może wymagać dostępu przez połączenie VPN?
(Pytam o to z winy serwera, ponieważ dotyczy to zarówno serwerów VPN, jak i uśpionych komputerów użytkowników końcowych)
Czy to prawda, że nie możemy pozwolić na uśpienie żadnej maszyny, która może wymagać dostępu przez połączenie VPN?
(Pytam o to z winy serwera, ponieważ dotyczy to zarówno serwerów VPN, jak i uśpionych komputerów użytkowników końcowych)
Odpowiedzi:
Stary wątek, ale chciałem się do niego włączyć, ponieważ jest to wciąż najwyżej oceniany wynik wyszukiwania dla „wol over vpn”.
Tak, magiczny pakiet WOL jest zdefiniowany w ramach ograniczeń warstwy 2, ale to nie znaczy, że nie może być zawarty w jednostce protokołu sieciowego i transportowego, którego można następnie użyć do trasowania go przez VPN. Powodem tego jest to, że sekwencja „magiczna” może znajdować się w dowolnym miejscu ładunku. Zasadniczo staje się więc kwestią uzyskania zwykłego pakietu routowalnego do hosta docelowego z sekwencją „magiczną” w jego ładunku.
Większość implementacji magicznego pakietu korzysta z portu UDP 9, chociaż tak naprawdę nie ma to znaczenia, o ile jest poprawnie trasowane i przesyłane w tej samej domenie rozgłoszeniowej, co komputer docelowy. Tak długo, jak klient VPN ma prawidłowe trasy, może poprawnie przesłać pakiet rozgłoszeniowy, taki jak 192.168.1.255 (adres rozgłoszeniowy), do bramki VPN przez Internet.
Tak więc routing jest naprawdę prosty, problem może polegać na prawidłowym nadawaniu go z docelowej bramy VPN. Oznacza to skonfigurowanie bramy VPN / znalezienie opcji, aby przekazywać ruch rozgłoszeniowy od zdalnych klientów VPN do sieci lokalnej.
Zazwyczaj nie, ponieważ „MagicPacket” znajduje się w warstwie 2. Nie jest nawet możliwy do routingu bez pomocy spedytorów (np. Pomocnika IP).
Istnieje wymyślny sposób na zbudowanie tunelu warstwy 2 za pomocą SSH, a przy tym WOL powinien działać dobrze. Dlatego nie widzę powodu, aby robić bez wysyłania maszyn do snu.
Na podstawie wzmianki o @slm zamieściłem poniżej ważne części źródła.
Wymagania wstępne:
1) oba komputery muszą mieć włączone logowanie roota. (przepraszam - dane logowania na obu komputerach muszą umożliwiać utworzenie urządzenia TAP). Oznacza to: na poziomie systemu root ma hasło;
2) w pliku sshd_config hosta, na którym działa demon ssh, ustawione są opcje PermitTunnel yes i PermitRootLogin yes;
3) Przekazywanie IP jest włączone w jądrze. Użyj komendy sysctl, aby ustawić tę opcję: sysctl -w net.ipv4.ip_forwarding = 1; dodaj także wiersz net.ipv4.ip_forwarding = 1 do pliku /etc/sysctl.conf, aby ustawienie pozostało po ponownym uruchomieniu. Zrób to na obu komputerach;
4) Zainstalowałeś pakiet bridge-utils lub masz do dyspozycji polecenie brctl na obu komputerach.
Utwórz tunel:
ssh -w 1: 1 -o Tunnel = nazwa hosta Ethernet
opcja -w ustawia nazwę urządzenia TAP na dowolnym hoście (tutaj tap1 zostanie utworzony na obu końcach).
opcja -o służy do określania opcji pliku konfiguracyjnego w wierszu poleceń. Używamy Tunnel = ethernet, aby skonfigurować tunel warstwy 2.
Ten formularz sprawi, że sesja ssh będzie otwarta na pierwszym planie. Jeśli chcesz, aby zrezygnował z powłoki po ustanowieniu tunelu, możesz użyć opcji -f, aby nakazać mu przejście do tła. Potrzebuje jednak polecenia do rozwidlenia, więc możesz po prostu użyć fikcyjnego polecenia, takiego jak true, aby go uruchomić. Możesz także użyć tej funkcji do skonfigurowania mostu na odległym końcu, ale nie wchodzę w to teraz. Wyglądałoby to tak:
ssh -f -w 1: 1 -o Tunnel = nazwa hosta ethernetowego true
Dodaj urządzenia TAP do mostu:
brctl addbr br0; brctl addif tap1; ifconfig tap1 up; ifconfig br0 w górę
uruchamiasz to na obu hostach (zauważ, że nie przypisałem adresu IP). brctl to polecenie używane do manipulowania urządzeniami mostowymi. brctl addbr dodaje most br0, a polecenie addif dołącza do niego urządzenie tap1.
Następnym krokiem byłoby dodanie fizycznych interfejsów Ethernet do urządzenia mostu. To, jak chcesz to zrobić, będzie się różnić, więc omówię kilka scenariuszy. Pierwszy scenariusz polega na tym, że Twoi partnerzy VPN znajdują się w tej samej podsieci (tj. Nie ma routingu między nimi), a drugi scenariusz będzie przez Internet.
Bezwstydny skradziony z: http://la11111.wordpress.com/2012/09/24/layer-2-vpns-using-ssh/
Tak, zamiast wysyłać pakiet WoL na adres rozgłoszeniowy w sieci docelowej, po prostu wyślij go na adres IP komputera, który chcesz obudzić. Programy testowane z PPTP VPN:
Zgadzam się z użytkownikiem48838 - z definicji magiczny pakiet jest wysyłany tylko przez lokalną podsieć. Jednak wcześniej użyłem skryptu napisanego przez jpo, który działał z innej podsieci za pośrednictwem normalnego routera. Spróbuj tego - YMMV
właściwie odpowiedź brzmi TAK.
Z powodzeniem korzystam z WOL przez PPTP VPN, używając tej aplikacji: https://play.google.com/store/apps/details?id=com.benfinnigan.wol&hl=pl
Przetestowałem to i odpowiedź brzmi TAK :)
Znalazłem w Internecie narzędzie, które wysyła pakiet WOL w trybie uni-cast do docelowego hosta, dzięki czemu unikam przekazywania pakietu rozgłoszeniowego przez problem z routerem.
Jednym z punktów, na które należy uważać przy tym rozwiązaniu, jest wprowadzenie statycznego wpisu arp na routerze, ponieważ host będzie wyłączony i nie będzie odpowiadał na żądanie ARP routera. Twoje zdrowie!