Wake-on-LAN över VPN fungerar inte? Broadcastet tar sig aldrig fram

Tunneln är uppe och utdelningar svarar, men maskinen sover vidare. Magic packet måste skickas på målets eget segment, så sätt en hjälpare där.

Du försätter kontorsmaskinen i viloläge, ringer upp VPN hemifrån, och den förblir avstängd. Tunneln är uppe, filutdelningar svarar, och routerns wake-on-LAN-sida rapporterar att den skickade begäran. Varje synlig signal säger att nätet är i ordning, och just därför är det här fallet förvirrande: ramen som skulle väcka maskinen når aldrig det segment den står på.

Symtomen pekar på subnätet, inte på tunneln

Ping misslyckas för den sovande värden, och den delen är normal. En maskin i standby har ingen körande IP-stack, kan alltså inte svara på ARP eller ICMP, och ingen tunnelkonfiguration ändrar det. Det användbara testet är om en andra maskin på samma LAN vaknar, och om routerns egen wake-sida fungerar för en värd som är inkopplad i den.

När testet inom samma segment lyckas ligger felet i räckvidden. Avsändaren du använder lever på VPN-gränssnittet, och paketet den bygger är ett broadcast för den lokala länken, så det går ut genom fel gränssnitt eller ingenstans alls. Tunneln är inte trasig; den bär fel sorts trafik. Ta reda på vilket gränssnitt avsändaren väljer innan du ändrar en enda routerinställning.

Ett magic packet är en ram, inte en tjänst

Nyttolasten börjar med ett fast header på sex 0xFF-byte, sedan målkortets hårdvaruadress sexton gånger, sedan ett valfritt SecureOn-lösenord på fyra byte. Avsändare stoppar normalt detta i UDP till port 7 eller port 9, men portnumret är en konvention mellan avsändare och kort, inte en lyssnare du kan ansluta till. Inget lyssnar, och inget svarar.

Det som väcker maskinen är nätverksgränssnittet, som håller en liten del kretsar strömförsörjd från standby-skenan medan resten av systemet är av. Därför måste inställningen överleva både ett fullt strömavbrott och ett viloläge: ett moderkort som tappar standby-strömmen vid avstängning har inget kort kvar som kan ta emot något.

Varför en routad tunnel inte kan leverera det

Ett routat VPN-gränssnitt är en punkt-till-punkt-IP-länk mellan två tunneladresser. Det finns för att bära paket adresserade till peeren, och därför beter sig ping, SSH och filutdelningar normalt genom det. En broadcast-ram är inte adresserad till den peeren, och den begränsade broadcast-adressen vidarebefordras inte utan vidare av en router.

Att vidarebefordra ett subnätsriktat broadcast är en medveten routerförmåga som de flesta standardkonfigurationer stänger av, och även då levereras det till det subnätet och inte till ett visst sovande kort. En sovande värd kan inte heller svara på ARP, så en router som försöker lösa måladdressen före vidarebefordran släpper ramen medan den väntar på ett svar som aldrig kommer. En statisk bindning löser den delen och lämnar broadcast-räckviddsproblemet orört. Två separata begränsningar alltså, och att åtgärda den ena gör inget för den andra.

Tre placeringar som faktiskt når kortet

Varje fungerande uppställning sätter ramen på målets segment, och de skiljer sig i hur mycket av nätet de stör:

  1. Sätt en enhet som alltid är på i målsegmentet. En router, NAS eller liten Linux-burk som hålls strömförsörjd kan sända ramen lokalt när du väl når den via tunneln, och inget med VPN att göra ändras.
  2. Låt routern sända ramen själv. Många firmware erbjuder en wake-sida som skickar från LAN-bron, vilket fungerar så länge målet sitter på den bron och inte bakom en andra router.
  3. Brygga platserna med en TAP-tunnel när broadcasts verkligen måste korsa. Det slår ihop två broadcast-domäner, med broadcast-stormar, en enda adressplan och varje discovery-protokoll som ser båda platserna samtidigt.

Det första alternativet är det man bör föredra för en enda maskin. Det tredje är ett nätverksdesignbeslut med löpande kostnad, så behandla det som sådant och inte som en snabb lösning för en skrivbordsdator.

Anteckna vilken hjälpare som skickar ramen och på vilken bro eller VLAN den sitter. En hjälpare som sänder på fel gränssnitt ger en perfekt inspelning och en maskin som aldrig vaknar, och den kombinationen kostar en eftermiddag.

Verifiera sändningen innan du skyller på klienten

Kontrollera målkortet först, för ingen avsändare kan väcka ett kort som inte är aktiverat. Kommandot nedan läser de stödda och aktuella wake-lägena, där ett aktuellt värde på g betyder att magic packet är påslaget:

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

Kör inspelningen på hjälparen medan sändningen sker, och läs den i stället för att anta att det lyckades. En ram som lämnar rätt bro med broadcast-mål-MAC är det enda beviset på att sändningen fungerade; är inspelningen tom valde avsändaren ett annat gränssnitt och resten av testet är meningslöst. En avsändare som bygger en rå ram i stället för ett UDP-datagram matchar inte det filtret, så kontrollera vilken form ditt verktyg använder innan du drar slutsatsen att inget skickades.

På Windows är motsvarande kortkontroll powercfg /devicequery wake_armed, som listar de enheter som får väcka systemet. En nätverksadapter som saknas i den listan ignorerar varje paket som skickas till den, hur korrekt ramen än ser ut på tråden.

Bekräfta sedan själva väckningen och uppföljningen. En maskin som startar men förblir onåbar via namn behöver en statisk adress och en DNS-post, eftersom broadcast-namnsuppslagning fortfarande inte korsar tunneln. Trådlös väckning är en separat och långt mindre tillförlitlig förmåga än den trådbundna varianten, så testa den på samma segment innan VPN ens kommer in i bilden. Skriv gränssnittsnamnet och hjälparens värd i ärendet, eftersom nästa fel vanligtvis handlar om samma två fakta.

Relaterade artiklar