Wake-on-LAN via VPN ne fonctionne plus ? Corrigez l'entrée ARP

Envoyez un paquet de réveil juste après l'extinction et le PC revient ; la même commande le lendemain matin ne fait rien. Rien n'a changé dans la configuration du VPN, et la redirection de port pointe toujours vers la bonne adresse. La différence, c'est le temps : la table de voisinage du routeur a oublié la machine endormie, elle n'a donc aucune adresse MAC à inscrire dans la trame. C'est cette expiration, et non le tunnel, qui explique la plupart des échecs de Wake-on-LAN via un VPN.

Le premier réveil fonctionne et le suivant non

Un routeur transmet une trame vers une adresse privée en cherchant la destination dans sa table de voisinage. Tant que la machine tourne, elle répond à l'ARP, si bien que la correspondance reste fraîche. Une fois éteinte, plus rien ne répond, l'entrée expire au bout de quelques minutes et les trames suivantes vers cette adresse sont rejetées, même si l'IP et la redirection de port restent valides.

Le schéma vous dit quel échec vous avez. Un réveil qui ne fonctionne jamais désigne la livraison : mauvais port, mauvaise destination ou pare-feu qui rejette le paquet avant qu'il n'atteigne le LAN. Un réveil qui fonctionne une fois puis échoue pendant des heures désigne l'entrée de voisinage. Un réveil qui fonctionne jusqu'au changement de bail DHCP désigne l'adressage, qu'une réservation corrige.

Vérifiez que l'adresse est stable avant de toucher à l'ARP. Si la machine endormie prend une nouvelle adresse à l'expiration d'un bail, une entrée de voisinage figée pour l'ancienne adresse sera à la fois permanente et inutile. Configurez d'abord une réservation DHCP pour que l'adresse survive aux redémarrages.

Ce dont le paquet magique a besoin sur le réseau

La charge utile est simple : 102 octets composés de six octets 0xFF suivis seize fois de l'adresse MAC cible, généralement envoyés vers le port UDP 9. Sur un LAN plat, elle part en diffusion, chaque port la reçoit et la carte réseau éteinte reconnaît sa propre adresse.

À travers un VPN, le paquet arrive au routeur en unicast vers une adresse privée ou en diffusion dirigée vers le sous-réseau. Dans le cas de l'unicast, le routeur doit résoudre la destination en une adresse MAC avant de pouvoir poser la trame sur le LAN, et c'est précisément cette résolution qui échoue pendant que l'hôte dort.

Certains outils envoient vers le port 7 au lieu du 9, et certains équipements bloquent la diffusion dirigée par défaut. Ce sont des échecs de livraison, pas des échecs ARP, alors vérifiez la destination et le port avant de modifier la table de voisinage.

Trois chemins vers un hôte endormi

Vous avez trois façons pratiques d'amener la trame sur le LAN, et le bon choix dépend de ce que vous contrôlez.

Choisissez l'hôte auxiliaire quand il en existe un, car il diffuse sur le lien et ne demande aucune exception sur le routeur. Choisissez la diffusion dirigée quand le routeur l'autorise déjà et que l'outil de réveil accepte une adresse. Choisissez l'entrée statique quand aucune des deux n'est disponible et que vous pouvez exécuter une commande sur le routeur.

Ces options ne s'excluent pas. Une entrée permanente fait aussi survivre le chemin unicast au sommeil, ce qui est utile quand le client VPN ne peut envoyer qu'à une adresse précise.

Rendre l'entrée de voisinage permanente

Sur un routeur doté d'un shell Linux, une seule commande fixe la correspondance. Les valeurs ci-dessous appartiennent à un LAN d'exemple et doivent être remplacées par les vôtres :

ip neigh replace 192.168.50.23 lladdr 3c:7c:3f:12:9a:4e dev br0 nud permanent
ip neigh show dev br0 | grep 192.168.50.23

L'état nud permanent maintient l'entrée au-delà des délais ARP et l'utilise pour le transfert tant que la machine est éteinte. La seconde commande prouve que l'entrée existe et affiche l'interface à laquelle elle appartient, ce qui compte sur les routeurs dotés d'un pont invité ou d'un VLAN séparé.

Rendez-la persistante au redémarrage grâce au mécanisme offert par le firmware : un script dans /jffs/scripts sur Asuswrt-Merlin, une unité oneshot systemd sur un serveur Linux faisant office de passerelle, une Neighbor= stanza dans systemd-networkd, ou une entrée dans /etc/ethers que lisent les outils locaux. Une commande tapée dans un shell disparaît au redémarrage suivant, et c'est la raison la plus fréquente pour laquelle un correctif qui fonctionne semble cesser de fonctionner.

Testez depuis l'extérieur et sachez quand la retirer

Mettez la machine en veille et attendez au moins dix minutes, assez pour que toute entrée dynamique expire. Envoyez ensuite la demande de réveil depuis le client VPN et observez les deux côtés du routeur :

tcpdump -ni tun0 udp port 9
tcpdump -ni br0 ether proto 0x0806 or udp port 9

La première capture prouve que le paquet est arrivé par le tunnel ; la seconde prouve que le routeur a posé une trame sur le LAN. Un paquet magique valide apparaît sous la forme de 102 octets avec la MAC répétée, vérifiez donc la longueur autant que la destination. Si la trame quitte le pont LAN et que la machine reste éteinte, le problème restant vient de l'appareil : démarrage rapide, veille profonde ou réglage du BIOS qui coupe l'alimentation de la carte réseau.

Retirez l'entrée quand la carte réseau change, et mettez-la à jour quand vous déplacez la machine vers une autre adresse. Une correspondance permanente est une exception délibérée, et une exception dont personne ne se souvient est la façon dont un futur portable finit par recevoir des trames destinées à un bureau mis au rebut.