Een slapende thuis-pc wekken via VPN: waar het pakket vandaan komt

Je maakt verbinding, de router antwoordt en de desktop blijft donker. De tunnel is in orde; het pakket dat de machine had moeten wekken, bereikte nooit het segment waar de machine luistert. Als je het pad vanaf de router terugloopt, zie je waar het sterft.

Drie apparaten hebben drie taken. Ze door elkaar halen is de gebruikelijke reden waarom een wekpoging eindeloos ronddraait.

Begin bij de externe client en volg het pad

Vanuit een hotelnetwerk maak je verbinding met de thuisrouter, het enige altijd actieve eindpunt in het beeld. Een wekverzoek dat je op je laptop typt, wordt gewoon tunnelverkeer, gericht aan welke bestemming je ook hebt genoemd. Die bestemming bepaalt alles wat volgt.

Als je het naar het LAN-adres van de thuisrouter op de magic-packet-poort hebt gestuurd, kan de router het datagram aannemen en nooit een frame op het thuissegment uitsturen, omdat daar niets op die poort luistert. Als je het binnen de tunnel broadcast, stopt het bij de tunnelinterface. Een gerouteerde tunnel is geen uitbreiding van laag 2 van de huisbekabeling. Volg het pad hop voor hop en de doodlopende weg wordt duidelijk.

De controle die dit beslecht, vraagt één commando van de externe kant en één van de thuiskant. Stuur het verzoek en kijk dan op het thuissegment naar het frame.

Verplaats de afzender naar het thuissegment

De router kan het wekken zelf doen zodra je via de tunnel bent geauthenticeerd. OpenWrt documenteert een Wake-on-LAN-dienst die op het apparaat draait en het frame lokaal uitstuurt, en dat is precies de vorm die nodig is: authenticatie buiten, lokale broadcast binnen.

Die opzet houdt de wekfunctie ook buiten het publieke internet. Er wordt niets nieuws aan het internet blootgesteld, omdat de trigger over de VPN rijdt die je al vertrouwt. Het alternatief, een wekdienst met doorgestuurde poort, ruilt een klein gemak voor een naar het internet gericht eindpunt dat iedereen kan aftasten.

De cirkelvormige afhankelijkheid is het waard om ronduit te benoemen. Een VPN-client die op de desktop is geïnstalleerd, kan die desktop niet wekken, omdat het clientproces de machine nodig heeft die draait. Houd het externe toegangspunt op de router of een andere altijd actieve doos, en laat de desktop alleen een doel zijn.

Controleer het doel voordat je de tunnel de schuld geeft

Dit deel wordt door de hardware beslist, niet door de VPN, en de energiestatus beslist het eerst. De adapter moet wekken ondersteunen, de firmware moet de adapter in slaap van stroom voorzien, en het besturingssysteem moet zo zijn ingesteld dat het dat toestaat. Een machine die is opgeschort is een ander geval dan een die is afgesloten, en beide verschillen van een machine waarvan de voeding bij de muur is uitgeschakeld. Los die status op voordat je de rest van de lijst doorwerkt.

Lees het hardwareadres van de adapter die het frame werkelijk ontvangt. Een desktop met zowel Ethernet als Wi-Fi heeft vaak twee adressen, en slechts één daarvan is misschien wekbekwaam. Draadloos wekken is een aparte mogelijkheid met eigen firmware-eisen, dus een werkend Ethernet-wekken zegt niets over wekken via Wi-Fi.

Bewijs eerst het lokale pad. Stuur het magic packet vanaf een ander apparaat op dezelfde switch en kijk hoe de machine opkomt. Als dat mislukt, helpt geen enkele hoeveelheid tunnel-debugging, en de fout zit in de firmware, de adapterinstellingen of de energiestatus.

Maak na het ontwaken verbinding met de dienst die je wilde

Wekken is geen externe toegang. Als de machine hervat, moet hij nog zijn diensten opstarten, een adres krijgen en de sessie accepteren die je echt nodig hebt. Geef hem tijd om die status te bereiken voordat je concludeert dat het wekken is mislukt.

# remote side: trigger the wake through the already-authenticated tunnel
ssh [email protected] 'wol -i br-lan 3c:7a:8f:2b:11:04'

# home side: is the target answering on the LAN?
ping -c 3 10.10.0.42
arp -n 10.10.0.42

De regel arp is de nuttige. Een vermelding die van onvolledig naar een echt hardwareadres verandert, betekent dat de machine hervatte en antwoordde; een verzoek dat nooit wordt opgelost, wijst terug naar de wekstap en niet naar de dienst die je probeerde te bereiken.

Scheid de fasen in je notities: wekken, opstarten, dienst. Een fout in fase twee ziet er vanuit een chatvenster identiek uit als een fout in fase één, en alleen het lokale bewijs onderscheidt ze.