[Abandonné] Vlans et Ethernet/Magic Packet

Support Debian
#1

Bonjour Debian.

Nous avons des machines qui ne répondent pas au Wake-On-Lan malgré une configuration normalement correcte.

La raison (ou en tous cas une raison potentielle) nous a été donnée par l’administrateur réseau : l’attribution des VLANs est dynamique, en fonction de l’adresse MAC la machine va être attribuée à tel ou tel VLAN.
Éteinte, elle est donc sur le VLAN par défaut.

On m’a chargé de faire un script sur un Rapsberry Pi pour déclencher le WoL, puisque les machines à réveiller (des Optiplex7470 sous Windows10) sont sur un réseau différent du nôtre.

Comme ça ne marche pas, on me dit qu’il faut envoyer le Magic Packet sur le VLAN où sont les machines à l’arrêt.

Le Raspi est sur une prise configurée avec le VLAN n untag et le VLAN p taggé (n : VLAN des machines allumées, p : VLAN des machines éteintes).
Je n’ai pas accès à la configuration du switch ou du réseau.

Comme dit plus haut, je n’ai jamais utilisé de VLAN que sur du CISCO, donc j’ai suivi ces instructions en utilisant comme noms de VLAN ceux qu’on m’a fourni, soit :

auto eth0.p
iface eth0.p inet manual
  vlan-raw-device eth0

dans le /etc/network/interfaces.d/vlans

Ensuite (après bien sûr un systemctl restart networking) je fais un etherwake -i eth0.p MACAddressDeLaBécane, mais ça ne marche toujours pas.

Comment cela se débugue ?

(j’ai voulu poser la question sur le forum de Raspberry, mais impossible de poster, apparemment y’a un recaptcha obligatoire mais qui ne s’affiche pas chez moi)

#2

Le mieux est de regarder sur une machine sur le vlan p si elle voit passer le paquet envoyé. Tu peux déjà regarder si un simple ping sur une machine allumée du vlan p fonctionne.
Il peut y avoir des soucis de transfert du «paquet magique» WOL sur le vlan p à partir d’un port tagué d’un switch mais je ne vois pas trop pourquoi… PascalHambourg le saura surement.

1 J'aime
#3

Bonjour

Pour que la machine puisse être « réveillée », il faut que sa carte réseau soit alimentée pour pouvoir recevoir le paquet magique

Sur certaines machines, un voyant du côté du connecteur RJ45 reste allumé quand la machine est à l’arrêt et que la carte réseau est quand même alimentée.

As-tu vérifié que l’option LAN Only est bien sélectionnée dans le BIOS de la machine à réveiller :
BIOS -> Power Management -> Wake on LAN/WLAN -> LAN Only

#4

Il est possible que le mécanisme d’attribution du VLAN ne soit pas synchronisé avec les tables ARP des équipements réseaux. L’équipement envoi ton magik packet sur l’interface qui correspond à sa table, mais la machine elle est passé dans un autre vlan à une autre interface.

Et avec le Wake On Lan activé, sur une machine éteinte, je ne sais pas s’il y a des paquets ARP qui sont malgré tout échangés entre l’équipement et la machine pour justement maintenir cette table ARP.

#5

J’avoue que je n’ai pas pensé à cette hypothèse, mais j’envoie le magic packet par etherwake -i etho.p MacAddress donc il n’y a pas d’ARP impliqué normalement ?
Ou bien tu veux dire que le switch fait la conversion AdresseMac => IP destinataire lorsqu’il reçoit la trame ethernet et qu’il reconvertit ensuite IP => AdresseMac et qu’il peut y avoir erreur à ce niveau ?

Un switch bien éduqué ne fait pas ça normalement…

#6

Mais il n’y a pas de machine allumée sur le vlan p justement…
Faut voir si je peux en mettre une provisoirement.

#7

Mais à part ça vous confirmez que je n’ai rien oublié dans la configuration ?
Pas besoin de faire un vlan create ou un truc du genre comme j’ai vu dans des tutos datant des années 2010 ?

#8

J’ai pas tous suivi mais les machines cibles et la machine de départ ne sont pas sur le même switch ?

Si oui le/les vlans sont-ils bien configuré sur les switchs ?
Ton Rasp est brancher sur un switch et la configuration de la patte du switch est bien en mode trunk avec les deux vlan susmentionné ?

Il n’y a pas besoin de configuration particulière sur le Raspberry si tu ne gère pas les vlan depuis lui (du coup pour moi ta configuration d’interface est erronée).

Si @PascalHambourg passe par là il pourra sans doute mieux répondre à tes interrogations je suis pas suffisamment à l’aise avec ces notions pour expliquer au mieux.

#9

Si ta machine ne s’allume pas, c’est qu’elle ne voit pas passer le paquel WOL. Il faut d’abord voir si ce paquet est transmis, donc pour cela je te proposais de tester d’abord si tout se passait bien pour un paquet nor mal (un bon vieux ping par exemple), puis après de vérifier si la machine voyait bien le paquet WOL.

#10

Ça ne marchera pas, puisque pour pouvoir faire un ping il faut que la machine soit allumée, et si elle est allumée est n’est pas dans le même vlan que celui dont on veut s’assurer du fonctgionnement

#11

Je n’ai jamais utilisé WoL car je n’en ai jamais eu besoin et ça ne m’intéresse pas spécialement. Pas trop d’idée pour le moment.

Le VLAN des machines éteintes permet-il d’envoyer et recevoir des paquets ?

A mon avis il faudrait tester par étape.

  • Connecter le Raspberry Pi directement à une machine cible, envoyer le paquet magique sur l’interface non taggée et vérifier que la machine s’allume.
  • Connecter le Raspberry Pi à une machine de test sur laquelle tourne une capture de trafic, envoyer le paquet magique sur l’interface taggée et vérifier qu’il est bien émis avec le bon tag.
  • Connecter le Raspberry Pi à son port du switch et une machine de test avec capture de trafic au port du switch à la place d’une machine cible. Mais c’est là que ça risque de se compliquer.

Comment fait le switch pour déterminer si une machine est allumée ou éteinte ?
Je suppose que la machine est considérée comme allumée si le port reçoit du trafic ? Ensuite comment est-elle considérée comme éteinte ? Après un certain temps sans trafic ?

La machine de test ne doit donc émettre aucun paquet pour rester dans le VLAN des machines éteintes. Donc pas de configuration IP, pas d’autoconfiguration IPv6, éventuellement filtrage de tout le trafic IPv4 et IPv6 en sortie avec ip(6)tables/nftables…

1 J'aime
#12

Souvent la carte réseau présente un voyant allumé quand elle est branchée même si la machine est éteinte, donc je présume que le switch sait où elle est. J’utilise le WoL pour allumer 2 salles de 24 machines afin de procéder à des mises à jour, les deux salles sont mis sur un vlan relié à un switch HP Procurve. Donc machine éteinte sur un VLAN, le switch sait où sont les machines et transmet le paquet. La seule inconnu pour moi est de savoir si un paquet WoL émis sur un port tagué (mais «avec le bon tag» bien sûr), est correctement rerouté.
Voilà ce que cela donne pour une machine (en direct):
root@stargate:~# ping 192.168.1.201
PING 192.168.1.201 (192.168.1.201) 56(84) bytes of data.
^C
— 192.168.1.201 ping statistics —
2 packets transmitted, 0 received, 100% packet loss, time 1008ms
root@stargate:~# arp -n
Address HWtype HWaddress Flags Mask Iface
192.168.1.55 ether c8:9c:dc:b5:87:74 C eth0
[…]
192.168.1.201 (incomplete) eth0
[…]
iroot@stargate:~# grep 201 /etc/udhcpd.conf
#host MACHINE-201
static_lease 8C:89:A5:79:F9:9F 192.168.1.201
root@stargate:~# etherwake 8C:89:A5:79:F9:9F
root@stargate:~# etherwake 8C:89:A5:79:F9:9F
root@stargate:~# etherwake 8C:89:A5:79:F9:9F
[attente de 1mn)
root@stargate:~# ping 192.168.1.201
PING 192.168.1.201 (192.168.1.201) 56(84) bytes of data.
64 bytes from 192.168.1.201: icmp_req=1 ttl=64 time=0.246 ms
64 bytes from 192.168.1.201: icmp_req=2 ttl=64 time=0.290 ms
^C
— 192.168.1.201 ping statistics —
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.246/0.268/0.290/0.022 ms
root@stargate:~# arp -n | grep 201
192.168.1.201 ether 8c:89:a5:79:f9:9f C eth0
root@stargate:~#

#13

Qu’entends-tu exactement par « sait où elle est » ? Si tu veux dire qu’il connaît son adresse MAC, je n’en suis pas du tout sûr, je ne pense pas que l’adresse MAC intervienne à ce niveau. De toute façon ça n’a pas d’importance car dans le cas contraire les paquets destinés à cette adresse MAC sont diffusés sur tous les ports actifs du VLAN.

#14

Ben je viens de vérifier que si je fais un etherwake à une adresse mac inexistante, une machine sur le vlan ne voit rien passer. Du coup j’en déduit que machine éteinte mais branchée, le switch sait l’adresse MAC qu’il y a au bout. Je précise que dans mon expérience, la mache 192.168.1.201 était éteinte depuis au moins 2 jours. En revanche, le switch n’a jamais été éteint et les cables réseau jamais débranchés.
[edit: peut être que le switch ne diffuse pas si il connait l’adresse MAC de la machine allumée branchée sur le port, et ne diffuse que sur les ports connectés mais sans adresse MAC connue…, pas facile à tester de loin ça, il faudrait une machine allumée avec une carte réseau non configurée mais «up» (traduction?) pour voir si elle voit passer le paquet, donc être sur place et non à 11km…]

#15

Le switch va conserver son cache ARP de quel façon ?
L’ARP étant situé au niveau L3 techniquement un switch manageable L2/L3 doit pouvoir conserver une trace de la machine et permettre l’envoi vers celle-ci du paquet magique.

Maintenant dans le cas où il n’a aucune trace de la mac de la machine (en imaginant que c’est un switch L3 manageable dont on parle) il broadcast en respectant le tag initiale du paquet ou vraiment à tous le monde ?

Il faudrait déjà s’assurer qu’une machine allumée puisse correctement communiquer avec le Raspberry.

Par contre effectuer ce type de debug sans avoir la main sur le switch me parait compliqué.
idem je n’ai pas saisi la notion d’attribution de VLAN dynamique, dans ma tête un vlan doit être présent et disponible pour chaque machine qui doit-être dessus au niveau du switch (y compris les switch en amont dans le cas de montage en cascade du réseau).
Il y a donc un serveur radius ou autre de ce que j’ai lu qui va attribuer une configuration ip et un vlan selon la mac et l’authentification réussi ou non de la machine …
Du coup je sèche là, j’ai encore jamais eu à faire à ce genre de configuration réseau.

#16

Comment as-tu vérifié ? J’observe l’inverse avec un switch simple sans VLAN (qui peut être considéré comme un VLAN unique non taggé).

Oui, c’est le principe du switch, contrairement au hub.

Non, il doit diffuser sur tous les ports car il peut y avoir plusieurs adresses MAC derrière un port. Sinon ça ne marcherait pas avec les switchs en cascade, les VM pontées…

#17

Un vrai switch (L2) n’a pas de cache ARP. Il n’a qu’une table de correspondance MAC-port.

Pas besoin d’ARP pour envoyer un paquet magique WoL. Ce n’est pas un paquet IP.

#18

En fait si la machine a une carte réseau allumée, le port du switch est UP sinon il est DOWN.

#19

panda et stargate sont sur le même vlan:
Sur panda (serveur gros et gras :slight_smile: ):

panda:~# tcpdump -i br0 udp and not port domain and not port 123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes

sur stargate

root@stargate:~# etherwake 8C:89:00:79:F9:9F
root@stargate:~# etherwake 8C:89:00:79:F9:9F
root@stargate:~# etherwake 8C:89:00:79:F9:9F
root@stargate:~#

(l’adresse mac n’existe pas)
Les paquets n’apparaissent pas sur panda, tout ce que je vois passer sont des paquets pour une imprimante en bradcast.

Oui

Hum, j’ai lu la doc du HP procurve, il conseille d’activer le broadcast UDP. Du coup je ne comprends pas pourquoi je ne vois pas passer le paquet… J’essaye sur une autre machine, toujours sur le même vlan…

#20

[petit délai, il y avait des trucs à installer],Je confirme que sur la machine 192.168.1.201 (réveillée par WoL), je n’ai pas vu passer le paquet qui a réveillée la machine 192.168.1.222 (qui a bien été réveillée). Bref, le siwtch ne semble pas faire du broadcast. Je précise que toutes ces machines sont sur le même switch. En clair, ça reste flou pour moi.