Dlaczego Wake-on-LAN działa lokalnie, ale nie działa przez domowe VPN?

Wake-on-LAN nie działa przez VPN, gdy magiczny pakiet nigdy nie dociera do lokalnego segmentu Ethernet śpiącego urządzenia.

W sieci domowej telefon lub laptop połączony przez WireGuard, OpenVPN, Tailscale lub inny tunel może uzyskać dostęp do routowanych usług IP bez automatycznego dołączania do domeny rozgłoszeniowej LAN. Poprawna diagnoza polega więc na potwierdzeniu lokalnej ścieżki wybudzania, przechwyceniu tego, co wysyła klient VPN, zidentyfikowaniu, gdzie zatrzymuje się dostarczanie rozgłoszeń, a następnie wybraniu bezpiecznej lokalnej metody przekaźnikowej lub wspomaganej przez router zamiast otwierania nieautoryzowanego portu UDP do internetu.

Potwierdź lokalną ścieżkę wybudzania przed testowaniem VPN

Wybudź cel z innego urządzenia w tej samej sieci Ethernet lub Wi-Fi, używając dokładnego adresu MAC i stanu zasilania, którego zamierzasz użyć zdalnie. Testuj osobno uśpienie, hibernację i wyłączenie, ponieważ wsparcie sprzętowe może się różnić między nimi.

Praktyczny przewodnik dla domowego laboratorium opisuje Wake-on-LAN jako rozgłoszeniowy magiczny pakiet, który wyłączony interfejs rozpoznaje po adresie MAC. Sukces lokalny potwierdza, że firmware, karta sieciowa, kabel i stan nasłuchiwania niskiego poboru mocy działają na tym segmencie.

Zapisz adres MAC celu, VLAN, podsieć, obsługiwany stan uśpienia oraz normalne opóźnienie wybudzania. Jeśli lokalne wybudzanie jest niestabilne, najpierw napraw BIOS, sterownik, zarządzanie energią, port przełącznika lub zasilanie w trybie czuwania, ponieważ przekaźnik VPN nie naprawi celu, który nie nasłuchuje niezawodnie.

Sprawdź, czy klient VPN wysyła do właściwego celu

Połącz się przez VPN i sprawdź adres docelowy, port UDP, interfejs i maskę podsieci w aplikacji Wake-on-LAN. Wiele aplikacji domyślnie używa adresu rozgłoszeniowego aktualnego interfejsu VPN urządzenia, a nie adresu rozgłoszeniowego zdalnej sieci domowej.

Przewodnik specyficzny dla VPN zauważa, że pakiet musi być skierowany na adres rozgłoszeniowy zdalnej sieci LAN, a nie tylko do punktu końcowego tunelu. Ładunek MAC może być poprawny, podczas gdy adres IP docelowy umieszcza pakiet po niewłaściwej stronie routera.

Przechwyć ruch na bramie VPN i sprawdź, czy datagram UDP w ogóle dociera. Jeśli nigdy się nie pojawia, napraw trasę klienta VPN lub adres docelowy aplikacji; jeśli dociera jako unicast do starego IP śpiącego hosta, kontynuuj sprawdzanie zachowania ARP i przekaźnika.

Znajdź granicę warstwy 3, która blokuje rozgłoszenie

Większość VPN trasuje pakiety między podsieciami, podczas gdy Wake-on-LAN jest zwykle dostarczany jako rozgłoszenie warstwy 2 na docelowym segmencie. Routery zazwyczaj odmawiają przekazywania rozgłoszeń kierowanych, ponieważ niekontrolowane przekazywanie stwarza ryzyko bezpieczeństwa i amplifikacji.

Dyskusja OPNsense podsumowuje podstawową niezgodność: WoL to rozgłoszenie warstwy 2, podczas gdy zapora i tunel działają na warstwie 3. Dlatego normalne pingowanie, SMB i dostęp do panelu mogą działać przez VPN, nawet gdy pakiet wybudzający zawodzi.

Przechwyć ruch zarówno na interfejsie VPN, jak i na interfejsie sieci domowej. Jeśli pakiet wchodzi do zapory, ale nigdy nie wychodzi na LAN, nie zmieniaj dalej śpiącego komputera; wybierz przekaźnik, funkcję routera lub urządzenie zawsze włączone w domu, które może lokalnie wygenerować pakiet.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Przetestuj lokalny przekaźnik zamiast przekazywania UDP z internetu

Uruchom polecenie wybudzania z urządzenia zawsze włączonego w sieci domowej, takiego jak router, mały serwer, host Home Assistant lub inny NAS. Wywołaj to lokalne polecenie przez uwierzytelnione połączenie VPN.

Przewodniki dotyczące przekazywania rozgłoszeń często oferują lokalny przekaźnik WoL, ponieważ przekaźnik może odebrać routowane żądanie i wygenerować wymagane rozgłoszenie LAN na właściwym interfejsie.

Jeśli lokalny przekaźnik wybudza urządzenie, zachowaj VPN jako granicę uwierzytelniania i udostępniaj tylko akcję przekaźnika zaufanym użytkownikom. Unikaj publicznego przekierowywania portów do UDP 7 lub 9, chyba że dokładnie rozumiesz zachowanie rozgłoszeń routera i ryzyko nadużyć.

Sprawdź stan ARP, gdy wybudzanie unicast działa tylko tymczasowo

Niektóre routery mogą wysłać unicastowy magiczny pakiet na ostatni adres IP celu, gdy adres MAC pozostaje w tabeli ARP lub sąsiadów. Metoda może działać krótko po wyłączeniu, a potem zawodzić po wygaśnięciu tego wpisu.

To wyjaśnia, dlaczego zdalny test wybudzania może się powieść zaraz po uśpieniu maszyny, ale zawieść po kilku godzinach. Router zna adres MAC celu tylko wtedy, gdy przestarzały wpis sąsiada jest dostępny; śpiący host nie może odpowiedzieć na nowe żądanie ARP.

Używaj statycznego wpisu sąsiada tylko wtedy, gdy router bezpiecznie to obsługuje, a NAS lub PC ma stabilny zarezerwowany adres IP. W przeciwnym razie preferuj rozgłoszenie generowane przez lokalny przekaźnik, aby konstrukcja nie zależała od wygasającego cache’u.

Zweryfikuj sukces wybudzania osobno od dostępności VPN

Magiczny pakiet zwykle nie zwraca potwierdzenia. Po jego wysłaniu sprawdź stan zasilania przez status łącza przełącznika, log lokalnego przekaźnika, odczyt inteligentnej wtyczki lub opóźnioną próbę połączenia z usługą, która startuje po uruchomieniu.

Porównanie ZimaSpace ścieżek VPN i przekierowania portów pomaga oddzielić bezpieczną ścieżkę zdalnego dostępu od mechanizmu rozgłoszeniowego, który wybudza maszynę.

Naprawa jest kompletna tylko wtedy, gdy ten sam klient VPN może wywołać lokalny przekaźnik, cel wybudza się z zamierzonego stanu niskiego poboru mocy, a oczekiwana usługa staje się dostępna po stałym opóźnieniu. Jeśli maszyna się wybudza, ale usługa pozostaje niedostępna, rozwiąż problemy z siecią startową, zaporą, DNS lub trasowaniem VPN jako osobny problem.