Wake-on-LAN przez VPN nie działa? Rozgłoszenie nigdy nie przechodzi

Tunel działa i udziały odpowiadają, ale maszyna pozostaje uśpiona. Magic packet musi zostać wysłany w segmencie samego celu, więc umieść tam pomocnika.

Usypiasz komputer biurowy, łączysz się z VPN z domu, a on pozostaje wyłączony. Tunel działa, udziały plików odpowiadają, a strona wake-on-LAN routera informuje, że wysłała żądanie. Każdy widoczny sygnał mówi, że sieć jest w porządku, i właśnie dlatego ta sprawa jest myląca: ramka, która obudziłaby maszynę, nigdy nie dociera do segmentu, w którym ona siedzi.

Objawy wskazują na podsieć, nie na tunel

Ping do uśpionego hosta nie działa i ta część jest normalna. Maszyna w stanie uśpienia nie ma działającego stosu IP, więc nie może odpowiedzieć na ARP ani ICMP, i żadna konfiguracja tunelu tego nie zmieni. Przydatny test to sprawdzenie, czy budzi się druga maszyna w tej samej sieci LAN i czy strona wake samego routera działa dla hosta podłączonego do niego.

Gdy test w tym samym segmencie przechodzi, usterka dotyczy zasięgu. Nadawca, którego używasz, żyje na interfejsie VPN, a pakiet, który buduje, jest rozgłoszeniem dla łącza lokalnego, więc wychodzi złym interfejsem albo wcale. Tunel nie jest zepsuty; przenosi niewłaściwy rodzaj ruchu. Ustal, który interfejs wybiera nadawca, zanim zmienisz choć jedno ustawienie routera.

Magic packet to ramka, nie usługa

Ładunek zaczyna się stałym nagłówkiem z sześciu bajtów 0xFF, potem adres sprzętowy karty docelowej powtórzony szesnaście razy, potem opcjonalne hasło SecureOn z czterech bajtów. Nadawcy zwykle pakują to w UDP na port 7 albo port 9, ale numer portu jest konwencją między nadawcą a kartą, a nie nasłuchem, z którym można się połączyć. Nic nie nasłuchuje i nic nie odpowiada.

To, co budzi maszynę, to interfejs sieciowy, który utrzymuje niewielką część układów zasilanych z szyny podtrzymania, gdy reszta systemu jest wyłączona. Dlatego ustawienie musi przetrwać zarówno pełny zanik zasilania, jak i uśpienie: płyta, która odcina zasilanie podtrzymania przy wyłączaniu, nie ma już karty, która mogłaby coś odebrać.

Dlaczego tunel routowany nie potrafi tego dostarczyć

Interfejs VPN routowany to łącze IP punkt-punkt między dwoma adresami tunelu. Istnieje po to, by przenosić pakiety adresowane do peera, dlatego ping, SSH i udziały plików zachowują się przez niego normalnie. Ramka rozgłoszeniowa nie jest adresowana do tego peera, a ograniczony adres rozgłoszeniowy nigdy nie jest przekazywany przez router rutynowo.

Przekazywanie rozgłoszenia skierowanego do podsieci to świadoma funkcja routera, którą większość domyślnych konfiguracji wyłącza, a nawet wtedy trafia ono do tej podsieci, a nie do konkretnej uśpionej karty. Uśpiony host nie może też odpowiedzieć na ARP, więc router, który próbuje rozwiązać adres docelowy przed przekazaniem, porzuca ramkę, czekając na odpowiedź, która nigdy nie nadejdzie. Statyczny wpis powiązania naprawia tę część i pozostawia problem zasięgu rozgłoszenia nietknięty. Dwa odrębne ograniczenia, zatem, a usunięcie jednego nic nie daje drugiemu.

Trzy umiejscowienia, które naprawdę docierają do karty

Każde działające rozwiązanie umieszcza ramkę w segmencie celu, a różnią się tym, jak bardzo zakłócają sieć:

  1. Postaw w segmencie docelowym urządzenie, które jest zawsze włączone. Router, NAS albo małe pudełko z Linuksem, które pozostaje zasilane, może wysłać ramkę lokalnie, gdy tylko dotrzesz do niego przez tunel, i nic w VPN się nie zmienia.
  2. Pozwól routerowi samemu wysłać ramkę. Wiele firmware'ów oferuje stronę wake, która wysyła z mostu LAN, co działa, dopóki cel siedzi na tym moście, a nie za drugim routerem.
  3. Powiąż mostkiem lokalizacje tunelem typu TAP, gdy rozgłoszenia naprawdę muszą przechodzić. To scala dwie domeny rozgłoszeniowe, przynosząc burze rozgłoszeniowe, jeden plan adresowania i każdy protokół wykrywania widzący obie lokalizacje naraz.

Pierwsza opcja jest tą, którą warto wybrać dla jednej maszyny. Trzecia jest decyzją projektową o trwałym koszcie, więc traktuj ją jak taką, a nie jak szybką naprawę dla jednego komputera.

Zapisz, który pomocnik wysyła ramkę i na którym moście lub VLAN siedzi. Pomocnik, który wysyła na złym interfejsie, daje doskonały zrzut i maszynę, która nigdy się nie budzi, a ta kombinacja kosztuje popołudnie.

Zweryfikuj wysyłkę, zanim obwinisz klienta

Sprawdź najpierw kartę docelową, bo żaden nadawca nie obudzi karty, która nie jest uzbrojona. Polecenie poniżej odczytuje obsługiwane i bieżące tryby wake, gdzie bieżąca wartość g oznacza, że magic packet jest włączony:

ethtool enp3s0 | grep -A1 'Wake-on'
ip neigh show 192.168.1.50
tcpdump -ni br0 -e 'ether broadcast and udp dst port 9'
etherwake -i br0 3c:7c:3f:00:11:22

Uruchom zrzut na pomocniku w trakcie wysyłki i przeczytaj go, zamiast zakładać sukces. Ramka opuszczająca właściwy most z docelowym adresem MAC rozgłoszenia to jedyny dowód, że wysyłka zadziałała; jeśli zrzut jest pusty, nadawca wybrał inny interfejs i reszta testu nic nie znaczy. Nadawca, który buduje surową ramkę zamiast datagramu UDP, nie pasuje do tego filtra, więc sprawdź, jakiej formy używa twoje narzędzie, zanim uznasz, że nic nie wysłano.

W Windows odpowiednikiem sprawdzenia karty jest powercfg /devicequery wake_armed, które wymienia urządzenia mogące budzić system. Karta sieciowa nieobecna na tej liście zignoruje każdy wysłany do niej pakiet, niezależnie od tego, jak poprawnie ramka wygląda na przewodzie.

Następnie potwierdź samo budzenie i dalsze kroki. Maszyna, która się włącza, ale pozostaje nieosiągalna po nazwie, potrzebuje statycznego adresu i rekordu DNS, bo rozwiązywanie nazw rozgłoszeniem nadal nie przechodzi przez tunel. Budzenie bezprzewodowe to odrębna i znacznie mniej niezawodna możliwość niż wersja przewodowa, więc przetestuj ją w tym samym segmencie, zanim w ogóle wciągniesz do sprawy VPN. Zapisz w zgłoszeniu nazwę interfejsu i hosta pomocnika, bo następna awaria zwykle dotyczy tych samych dwóch faktów.

Powiązane artykuły