Wake-on-LAN preko VPN-a ne radi? Emitiranje nikad ne prelazi

Uspavate uredsko računalo, birate VPN od kuće, a ono ostaje isključeno. Tunel je uspostavljen, datotečna dijeljenja odgovaraju, a stranica wake-on-LAN usmjerivača izvješćuje da je poslala zahtjev. Svaki vidljivi signal kaže da je mreža u redu, i upravo zato je ovaj slučaj zbunjujuć: okvir koji bi probudio računalo nikad ne stigne do segmenta na kojem se nalazi.

Simptomi upućuju na podmrežu, ne na tunel

Ping prema uspavanom hostu ne uspijeva, i taj je dio normalan. Računalo u stanju pripravnosti nema pokrenut IP stog, pa ne može odgovoriti na ARP ni ICMP, i nikakva konfiguracija tunela to ne mijenja. Koristan test je probudi li se drugo računalo u istom LAN-u i radi li stranica wake samog usmjerivača za host koji je na njega priključen.

Kad test u istom segmentu prođe, kvar je u dosegu. Pošiljatelj koji koristite živi na sučelju VPN-a, a paket koji sastavlja je emitiranje za lokalnu vezu, pa izlazi kroz pogrešno sučelje ili nikamo. Tunel nije pokvaren; prenosi pogrešnu vrstu prometa. Otkrijte koje sučelje pošiljatelj bira prije nego promijenite i jednu postavku usmjerivača.

Magic packet je okvir, a ne usluga

Korisni teret počinje fiksnom glavom od šest bajtova 0xFF, zatim adresa sklopovlja ciljne kartice ponovljena šesnaest puta, zatim neobavezna zaporka SecureOn od četiri bajta. Pošiljatelji to obično pakiraju u UDP na port 7 ili port 9, ali broj porta je konvencija između pošiljatelja i kartice, a ne usluga koja sluša i na koju se možete spojiti. Ništa ne sluša i ništa ne odgovara.

Ono što budi računalo jest mrežno sučelje, koje održava mali dio sklopova napajanima iz pripravne tračnice dok je ostatak sustava isključen. Zato postavka mora preživjeti i potpuni gubitak napajanja i uspavljivanje: matična ploča koja pri isključivanju odsiječe pripravno napajanje nema više kartice koja bi išta primila.

Zašto usmjereni tunel to ne može dostaviti

Usmjereno sučelje VPN-a je IP veza od točke do točke između dviju adresa tunela. Postoji da bi prenosilo pakete adresirane na partnera, i zato se ping, SSH i datotečna dijeljenja kroz njega ponašaju normalno. Okvir emitiranja nije adresiran na tog partnera, a ograničena adresa emitiranja nikad se ne prosljeđuje usmjerivačem samo po sebi.

Prosljeđivanje emitiranja usmjerenog na podmrežu namjerna je mogućnost usmjerivača koju većina zadanih konfiguracija isključuje, a i tada se dostavlja toj podmreži, a ne određenoj uspavanoj kartici. Uspavani host također ne može odgovoriti na ARP, pa usmjerivač koji prije prosljeđivanja pokušava razriješiti ciljnu adresu odbacuje okvir dok čeka odgovor koji nikad neće doći. Statički unos povezivanja rješava taj dio i ostavlja problem dosega emitiranja netaknutim. Dva odvojena ograničenja, dakle, i uklanjanje jednoga ništa ne čini za drugo.

Tri smještaja koja doista stižu do kartice

Svaki izvediv raspored stavlja okvir u segment mete, a razlikuju se po tome koliko remete mrežu:

1. Postavite uređaj koji je stalno uključen u ciljni segment. Usmjerivač, NAS ili mala Linux kutija koja ostaje napajana može emitirati okvir lokalno čim do nje dođete kroz tunel, i ništa se u VPN-u ne mijenja.
2. Pustite usmjerivač da sam emitira okvir. Mnogi firmveri nude stranicu wake koja šalje s LAN mosta, što radi dok meta sjedi na tom mostu, a ne iza drugog usmjerivača.
3. Premostite lokacije tunelom tipa TAP kad emitiranja doista moraju prijeći. To spaja dvije domene emitiranja, donosi oluje emitiranja, jedan plan adresiranja i svaki protokol otkrivanja koji vidi obje lokacije odjednom.

Prva je opcija ona koju treba preferirati za jedno računalo. Treća je odluka o dizajnu mreže sa stalnim troškom, pa je tako i tretirajte, a ne kao brzu popravku za jedno računalo.

Zapišite koji pomoćnik emitira okvir i na kojem mostu ili VLAN-u sjedi. Pomoćnik koji emitira na pogrešnom sučelju daje savršen snimak i računalo koje se nikad ne probudi, a ta kombinacija stoji jedno poslijepodne.

Provjerite slanje prije nego optužite klijenta

Najprije provjerite ciljnu karticu, jer nijedan pošiljatelj ne može probuditi karticu koja nije naoružana. Naredba u nastavku čita podržane i trenutačne načine wake, gdje trenutačna vrijednost g znači da je magic packet uključen:

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

Pokrenite snimku na pomoćniku dok se slanje odvija i pročitajte je umjesto da pretpostavite uspjeh. Okvir koji napusti pravi most s emitiranim ciljnim MAC-om jedini je dokaz da je slanje uspjelo; ako je snimka prazna, pošiljatelj je odabrao drugo sučelje i ostatak testa nema smisla. Pošiljatelj koji gradi sirovi okvir umjesto UDP datagrama ne odgovara tom filtru, pa provjerite koji oblik koristi vaš alat prije nego zaključite da ništa nije poslano.

U sustavu Windows istovjetna provjera kartice je powercfg /devicequery wake_armed, koja ispisuje uređaje koji smiju probuditi sustav. Mrežni adapter koji nedostaje na tom popisu ignorirat će svaki paket koji mu se pošalje, koliko god okvir ispravno izgledao na žici.

Zatim potvrdite samo buđenje i nastavak. Računalo koje se uključi, ali ostane nedostupno po imenu, treba statičnu adresu i DNS zapis, jer razrješavanje imena emitiranjem i dalje ne prelazi tunel. Bežično buđenje zasebna je i mnogo manje pouzdana mogućnost od žičane inačice, pa je isprobajte u istom segmentu prije nego uopće uključite VPN. Zapišite naziv sučelja i host pomoćnika u zahtjev, jer se sljedeći kvar obično tiče istih dviju činjenica.