Werkt Wake-on-LAN via VPN niet? Het broadcast komt er nooit door

Je legt de kantoormachine in slaap, belt van huis uit de VPN in, en hij blijft uit. De tunnel staat, bestandsshares antwoorden, en de wake-on-LAN-pagina van de router meldt dat hij het verzoek heeft verzonden. Elk zichtbaar signaal zegt dat het netwerk in orde is, en juist daarom is dit geval verwarrend: het frame dat de machine zou wekken, bereikt nooit het segment waar hij staat.

De symptomen wijzen op het subnet, niet op de tunnel

Ping faalt voor de slapende host, en dat deel is normaal. Een machine in stand-by heeft geen draaiende IP-stack, kan dus geen ARP of ICMP beantwoorden, en geen enkele tunnelconfiguratie verandert dat. De nuttige test is of een tweede machine op hetzelfde LAN wakker wordt, en of de wake-pagina van de router werkt voor een host die erop is aangesloten.

Zodra de test binnen hetzelfde segment slaagt, zit het probleem in de reikwijdte. De afzender die je gebruikt, leeft op de VPN-interface, en het pakket dat hij bouwt is een broadcast voor de lokale link, dus het gaat de verkeerde interface uit of helemaal nergens heen. De tunnel is niet stuk; hij vervoert de verkeerde soort verkeer. Zoek uit welke interface de afzender kiest voordat je een routerinstelling wijzigt.

Een magic packet is een frame, geen dienst

De payload begint met een vaste header van zes 0xFF-bytes, dan zestien keer het hardwareadres van de doelkaart, dan een optioneel SecureOn-wachtwoord van vier bytes. Afzenders stoppen dat gewoonlijk in UDP naar poort 7 of poort 9, maar het poortnummer is een afspraak tussen afzender en kaart, geen listener waarmee je kunt verbinden. Er luistert niets, en er antwoordt niets.

Wat de machine wekt, is de netwerkinterface, die een klein stukje elektronica onder spanning houdt uit de stand-by-rail terwijl de rest van het systeem uit staat. Daarom moet de instelling zowel een volledige stroomuitval als een slaap overleven: een bord dat bij het uitschakelen de stand-by-voeding laat vallen, heeft geen kaart meer over om iets te ontvangen.

Waarom een gerouteerde tunnel het niet kan afleveren

Een gerouteerde VPN-interface is een point-to-point-IP-link tussen twee tunneladressen. Hij bestaat om pakketten aan de peer te bezorgen, en daarom werken ping, SSH en bestandsshares er normaal doorheen. Een broadcast-frame is niet aan die peer gericht, en het beperkte broadcastadres wordt door een router niet zonder meer doorgestuurd.

Het doorsturen van een subnetgericht broadcast is een bewuste routercapaciteit die de meeste standaardconfiguraties uitzetten, en zelfs dan levert hij af op dat subnet en niet bij een specifieke slapende kaart. Een slapende host kan ook geen ARP beantwoorden, dus een router die het doeladres voor het doorsturen wil oplossen, laat het frame vallen terwijl hij wacht op een antwoord dat nooit komt. Een statische binding lost dat deel op en laat het broadcast-reikwijdteprobleem onaangeroerd. Twee aparte beperkingen dus, en het oplossen van de ene doet niets voor de andere.

Drie plaatsingen die de kaart echt bereiken

Elke werkbare opstelling zet het frame op het segment van het doel, en ze verschillen in hoeveel van het netwerk ze verstoren:

1. Zet een altijd aanstaand apparaat op het doelsegment. Een router, NAS of kleine Linux-doos die onder stroom blijft, kan het frame lokaal uitzenden zodra je hem via de tunnel bereikt, en aan de VPN verandert niets.
2. Laat de router het frame zelf uitzenden. Veel firmwares bieden een wake-pagina die vanaf de LAN-bridge verstuurt, wat werkt zolang het doel op die bridge zit en niet achter een tweede router.
3. Brug de locaties met een TAP-tunnel wanneer broadcasts echt moeten oversteken. Dat voegt twee broadcast-domeinen samen, met broadcast-stormen, één adresplan en elk discovery-protocol dat beide locaties tegelijk ziet.

De eerste optie is de voorkeursoptie voor één machine. De derde is een netwerkontwerpbeslissing met blijvende kosten, dus behandel hem als zodanig en niet als een snelle oplossing voor één desktop.

Leg vast welke helper het frame verstuurt en op welke bridge of VLAN hij zit. Een helper die op de verkeerde interface uitzendt, levert een perfecte capture en een machine die nooit wakker wordt, en die combinatie kost een middag.

Controleer het verzenden voordat je de client de schuld geeft

Controleer eerst de doelkaart, want geen enkele afzender wekt een kaart die niet is ingesteld. De opdracht hieronder leest de ondersteunde en de huidige wake-modi, waarbij een huidige waarde van g betekent dat magic packet is ingeschakeld:

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

Draai de capture op de helper terwijl er wordt verzonden, en lees hem in plaats van succes aan te nemen. Een frame dat de juiste bridge verlaat met de broadcast-bestemmings-MAC is het enige bewijs dat het verzenden werkte; is de capture leeg, dan koos de afzender een andere interface en is de rest van de test zinloos. Een afzender die een ruw frame bouwt in plaats van een UDP-datagram, past niet op dat filter, dus kijk welke vorm je gereedschap gebruikt voordat je concludeert dat er niets is verzonden.

Op Windows is de equivalente kaartcontrole powercfg /devicequery wake_armed, die de apparaten opsomt die het systeem mogen wekken. Een netwerkadapter die in die lijst ontbreekt, negeert elk pakket dat ernaar wordt gestuurd, hoe correct het frame er op de draad ook uitziet.

Bevestig daarna het wekken zelf en de nazorg. Een machine die aangaat maar via de naam onbereikbaar blijft, heeft een statisch adres en een DNS-record nodig, omdat naamresolutie via broadcast de tunnel nog steeds niet oversteekt. Draadloos wekken is een aparte en veel minder betrouwbare mogelijkheid dan de bedrade versie, dus test het op hetzelfde segment voordat de VPN er überhaupt aan te pas komt. Schrijf de interfacenaam en de helper-host in het ticket, want de volgende storing gaat meestal over dezelfde twee feiten.