Réveiller un PC de maison endormi via VPN : d’où vient le paquet

Vous vous connectez, le routeur répond et le poste de bureau reste éteint. Le tunnel est correct ; le paquet qui aurait dû réveiller la machine n’a jamais atteint le segment où la machine écoute. En remontant le chemin depuis le routeur, on voit où il meurt.

Trois appareils ont trois rôles. Les confondre est la raison habituelle pour laquelle une tentative de réveil tourne indéfiniment.

Partez du client distant et suivez le chemin

Depuis un réseau d’hôtel, vous vous connectez au routeur de la maison, qui est le seul point de terminaison toujours actif de l’image. Une demande de réveil tapée sur votre portable devient du trafic de tunnel ordinaire, adressé à la destination que vous avez nommée. Cette destination décide de tout ce qui suit.

Si vous l’avez envoyée à l’adresse LAN du routeur de la maison sur le port du magic packet, le routeur peut accepter le datagramme et n’émettre jamais de trame sur le segment de la maison, car rien n’y écoute ce port. Si vous la diffusez à l’intérieur du tunnel, elle s’arrête à l’interface du tunnel. Un tunnel routé n’est pas une extension de couche 2 du câblage de la maison. Suivez le chemin saut après saut et l’impasse devient évidente.

La vérification qui tranche demande une commande depuis le côté distant et une depuis le côté maison. Envoyez la demande, puis surveillez le segment de la maison pour la trame.

Déplacez l’émetteur sur le segment de la maison

Le routeur peut faire le réveil lui-même une fois que vous êtes authentifié par le tunnel. OpenWrt documente un service Wake-on-LAN qui s’exécute sur l’appareil et émet la trame localement, ce qui est exactement la forme nécessaire : authentification distante dehors, diffusion locale dedans.

Cette disposition garde aussi la fonction de réveil hors d’internet public. Rien de nouveau n’est exposé à internet, car le déclencheur passe par le VPN auquel vous faites déjà confiance. L’alternative, un service de réveil avec port redirigé, échange un petit confort contre un point de terminaison tourné vers internet que n’importe qui peut sonder.

La dépendance circulaire mérite d’être nommée clairement. Un client VPN installé sur le bureau ne peut pas réveiller ce bureau, car le processus client a besoin que la machine tourne. Gardez le point d’entrée distant sur le routeur ou une autre boîte toujours active, et laissez le bureau n’être qu’une cible.

Confirmez la cible avant d’accuser le tunnel

Cette partie est décidée par le matériel, pas par le VPN, et l’état d’alimentation la décide en premier. L’adaptateur doit prendre en charge le réveil, le firmware doit laisser l’adaptateur alimenté en veille et le système d’exploitation doit être configuré pour l’autoriser. Une machine suspendue est un cas différent d’une machine éteinte, et les deux diffèrent d’une machine dont l’alimentation est coupée au mur. Réglez cet état avant de parcourir le reste de la liste.

Lisez l’adresse matérielle de l’adaptateur qui recevra réellement la trame. Un poste de bureau doté à la fois d’Ethernet et de Wi-Fi a souvent deux adresses, et une seule d’entre elles peut être capable de réveil. Le réveil sans fil est une capacité distincte avec ses propres exigences de firmware, donc un réveil Ethernet qui fonctionne ne dit rien du réveil par Wi-Fi.

Prouvez d’abord le chemin local. Envoyez le magic packet depuis un autre appareil sur le même commutateur et regardez la machine démarrer. Si cela échoue, aucune quantité de débogage du tunnel n’aidera, et la panne est dans le firmware, les réglages de l’adaptateur ou l’état d’alimentation.

Après la reprise, connectez-vous au service voulu

Réveiller n’est pas un accès distant. Une fois la machine reprise, elle doit encore démarrer ses services, obtenir une adresse et accepter la session dont vous avez réellement besoin. Laissez-lui le temps d’atteindre cet état avant de conclure que le réveil a échoué.

# 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

La ligne arp est la plus utile. Une entrée qui passe d’incomplète à une vraie adresse matérielle signifie que la machine a repris et répondu ; une demande qui ne se résout jamais renvoie à l’étape de réveil plutôt qu’au service que vous cherchiez à joindre.

Séparez les étapes dans vos notes : réveil, démarrage, service. Une panne à la deuxième étape ressemble depuis une fenêtre de chat à une panne à la première, et seule la preuve locale les distingue.