Wake-on-LAN via VPN ne fonctionne pas ? La diffusion ne franchit jamais le tunnel

Vous mettez la machine du bureau en veille, vous composez le VPN depuis chez vous, et elle reste éteinte. Le tunnel est monté, les partages de fichiers répondent, et la page wake-on-LAN du routeur indique qu'il a envoyé la demande. Chaque signal visible dit que le réseau va bien, et c'est exactement pour cela que ce cas est déroutant : la trame qui réveillerait la machine n'atteint jamais le segment où elle se trouve.

Les symptômes désignent le sous-réseau, pas le tunnel

Le ping échoue vers l'hôte endormi, et cette partie est normale. Une machine en veille n'a pas de pile IP active, elle ne peut donc répondre ni à ARP ni à ICMP, et aucune configuration de tunnel n'y change rien. Le test utile consiste à vérifier si une deuxième machine du même réseau local se réveille, et si la page de réveil du routeur fonctionne pour un hôte qui y est branché.

Une fois le test réussi sur le même segment, la panne tient à la portée. L'émetteur que vous utilisez vit sur l'interface VPN, et le paquet qu'il construit est une diffusion pour le lien local, donc il sort par la mauvaise interface ou pas du tout. Le tunnel n'est pas cassé ; il transporte le mauvais type de trafic. Déterminez quelle interface l'émetteur choisit avant de changer le moindre réglage du routeur.

Un magic packet est une trame, pas un service

La charge utile commence par un en-tête fixe de six octets 0xFF, puis l'adresse matérielle de la carte cible répétée seize fois, puis un mot de passe SecureOn facultatif de quatre octets. Les émetteurs l'enveloppent classiquement dans de l'UDP vers le port 7 ou le port 9, mais le numéro de port est une convention partagée entre l'émetteur et la carte, pas un service à l'écoute auquel se connecter. Rien n'écoute, et rien ne répond.

Ce qui réveille la machine, c'est l'interface réseau, qui maintient une petite quantité de circuits alimentés par le rail de veille pendant que le reste du système est hors tension. C'est pourquoi le réglage doit survivre à une coupure de courant complète autant qu'à une mise en veille : une carte mère qui coupe l'alimentation de veille à l'arrêt n'a plus de carte pour recevoir quoi que ce soit.

Pourquoi un tunnel routé ne peut pas l'acheminer

Une interface VPN routée est une liaison IP point à point entre deux adresses de tunnel. Elle existe pour transporter les paquets adressés au pair, ce qui explique que ping, SSH et partages de fichiers s'y comportent normalement. Une trame de diffusion n'est pas adressée à ce pair, et l'adresse de diffusion limitée n'est jamais relayée d'office par un routeur.

Relayer une diffusion dirigée vers un sous-réseau est une capacité délibérée du routeur que la plupart des configurations par défaut désactivent, et même alors elle est livrée à ce sous-réseau et non à une carte endormie précise. Un hôte endormi ne peut pas non plus répondre à ARP, donc un routeur qui tente de résoudre l'adresse cible avant de relayer abandonne la trame pendant qu'il attend une réponse qui ne viendra jamais. Une entrée de liaison statique corrige cette partie et laisse intact le problème de portée de la diffusion. Deux restrictions distinctes, donc, et en lever une ne fait rien pour l'autre.

Trois emplacements qui atteignent vraiment la carte

Chaque disposition viable place la trame sur le segment de la cible, et elles diffèrent par l'ampleur des perturbations sur le réseau :

1. Placez un appareil toujours allumé sur le segment cible. Un routeur, un NAS ou un petit boîtier Linux qui reste sous tension peut émettre la trame localement dès que vous l'atteignez par le tunnel, et rien du VPN ne change.
2. Laissez le routeur émettre la trame lui-même. Beaucoup de firmwares proposent une page de réveil qui envoie depuis le pont LAN, ce qui fonctionne tant que la cible est sur ce pont et non derrière un second routeur.
3. Pontrez les sites avec un tunnel de type TAP quand les diffusions doivent réellement franchir. Cela fusionne deux domaines de diffusion, avec tempêtes de diffusion, un plan d'adressage unique et chaque protocole de découverte qui voit les deux sites à la fois.

La première option est celle à privilégier pour une seule machine. La troisième est une décision d'architecture réseau au coût permanent, alors traitez-la comme telle et non comme un correctif rapide pour un poste de bureau.

Notez quel relais émet la trame et sur quel pont ou VLAN il se trouve. Un relais qui émet sur la mauvaise interface produit une capture parfaite et une machine qui ne se réveille jamais, et cette combinaison coûte un après-midi.

Vérifiez l'émission avant d'accuser le client

Contrôlez d'abord la carte cible, car aucun émetteur ne peut réveiller une carte qui n'est pas armée. La commande ci-dessous lit les modes de réveil pris en charge et le mode courant, où une valeur courante de g signifie que le magic packet est activé :

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

Lancez la capture sur le relais pendant l'émission, et lisez-la au lieu de supposer que c'est réussi. Une trame qui quitte le bon pont avec l'adresse MAC de diffusion est la seule preuve que l'envoi a fonctionné ; si la capture est vide, l'émetteur a choisi une autre interface et le reste du test ne veut rien dire. Un émetteur qui construit une trame brute plutôt qu'un datagramme UDP ne correspond pas à ce filtre, vérifiez donc la forme employée par votre outil avant de conclure que rien n'a été envoyé.

Sous Windows, l'équivalent du contrôle de carte est powercfg /devicequery wake_armed, qui liste les périphériques autorisés à réveiller le système. Une carte réseau absente de cette liste ignorera chaque paquet qui lui est adressé, aussi correcte que la trame paraisse sur le fil.

Confirmez ensuite le réveil lui-même et la suite. Une machine qui démarre mais reste injoignable par son nom a besoin d'une adresse statique et d'un enregistrement DNS, car la résolution de noms par diffusion ne franchit toujours pas le tunnel. Le réveil sans fil est une capacité distincte et bien moins fiable que la version filaire, alors testez-la sur le même segment avant même de mêler le VPN. Inscrivez le nom de l'interface et l'hôte du relais dans le ticket, car la panne suivante concerne en général les deux mêmes faits.