Épisode 2 – Piloter le lab à distance

Le problème

#

Je ne suis pas souvent à côté de la baie. Et même quand j’y suis, je n’ai aucune envie de laisser tourner le lab en permanence : le T440 fait le bruit d’un petit avion, et trois hyperviseurs allumés pour rien, c’est de l’électricité gaspillée.

La règle que je me suis fixée est donc simple : par défaut, tout est éteint. J’allume ce dont j’ai besoin quand je travaille, et j’éteins tout en partant. Mais pour que ça tienne au quotidien, il faut pouvoir le faire depuis n’importe où, sans me déplacer, et surtout sans ouvrir de port sur internet. Exposer l’administration d’un lab de sécurité pour gagner en confort, ce serait un mauvais départ.

Ce que je voulais au final : une seule commande, lancée depuis mon PC, qui allume ou éteint chaque machine dans le bon ordre. Ça a été plus long que prévu, parce que chaque machine a sa propre façon de se laisser piloter.

Ouvrir le schéma en grand

La porte d’entrée : pve0

#

Un thin client toujours allumé

#

Si tout le lab est éteint, il faut bien une machine allumée pour réveiller le reste. C’est le rôle de l’OptiPlex 3000 Thin Client, que j’appelle pve0. Il consomme quelques watts, ne fait aucun bruit, et c’est le seul équipement du lab (avec le pare-feu) qui tourne en permanence.

Je l’ai installé sous Proxmox, comme les autres nœuds. Ce n’est pas indispensable pour une machine d’administration, mais ça me permet de tout gérer de la même façon, et il pourra héberger plus tard quelques petits services toujours disponibles.

L’installation m’a demandé un peu de patience. Le SSD NVMe que j’ai ajouté est au format 2230, très court, et il ne tenait pas correctement dans son emplacement : je l’ai calé avec deux petits morceaux de mousse pour qu’il ne plie pas. Ensuite, l’installeur de Proxmox ne voyait que la petite mémoire eMMC soudée sur la carte, et pas le SSD. Il a fallu aller dans le BIOS et activer le port M.2 dans les options « Port Enablement », qui était tout simplement désactivé. Le genre de détail qu’on ne trouve dans aucun tutoriel, mais qu’on retient pour longtemps.

Tailscale plutôt qu’un port ouvert

#

Pour accéder au lab de l’extérieur, la solution classique serait un VPN sur le pare-feu. Sauf que mon FortiGate est derrière la box de mon fournisseur d’accès : pour le joindre depuis internet, il faudrait ouvrir et rediriger un port sur la box, donc exposer un service. C’est exactement ce que je voulais éviter.

J’ai donc installé Tailscale directement sur pve0. Le principe est différent : c’est pve0 qui ouvre une connexion sortante vers le service, et mon PC fait de même de son côté. Les deux se retrouvent sans qu’aucun port entrant ne soit ouvert, ni sur la box, ni sur le FortiGate.

pve0 sert aussi de « subnet router » : il annonce les réseaux d’administration du lab à mes autres appareils Tailscale. Depuis mon PC, où que je sois, j’atteins donc directement l’interface de Proxmox ou du FortiGate, comme si j’étais sur place.

Deux réglages comptent vraiment ici. D’abord, j’ai désactivé l’expiration de la clé pour pve0, et uniquement pour lui : c’est un serveur, il ne doit pas se déconnecter tout seul au bout de quelques mois. Ensuite, ce compte Tailscale devient de fait la clé de tout le lab, donc la double authentification n’est pas une option.

Une règle de pare-feu, service par service

#

pve0 n’est pas dans le même réseau que les machines qu’il doit piloter : il est sur le réseau interne du FortiGate, alors que les hyperviseurs, l’iDRAC et l’AMT sont dans le VLAN d’administration. Il faut donc une règle sur le FortiGate pour l’y autoriser.

Plutôt qu’une règle « tout autorisé », j’ai listé un par un les services dont il a besoin :

C’est un peu plus long à écrire, mais c’est une bonne habitude à prendre dès maintenant : on sait exactement ce qui passe, et pourquoi.

Petite frayeur pendant les tests : un ping vers le VLAN d’administration me revenait… de la box. Le switch était éteint, donc le réseau du VLAN n’existait plus pour le FortiGate, et le trafic partait tout simplement par la route par défaut, vers internet. Rien de grave ici, mais c’est typiquement le genre de fuite qu’on ne veut pas en entreprise. La correction propre, c’est une route « blackhole » sur les réseaux du lab : si un VLAN tombe, son trafic est jeté au lieu d’aller ailleurs. Je la mets en place dans l’épisode sur la segmentation.

Une méthode par machine

#

C’est la partie la plus intéressante. Les quatre équipements à piloter n’ont rien en commun, et chacun a demandé une solution différente.

Le switch : une prise connectée

#

Le switch n’a pas de bouton marche/arrêt à distance, alors je l’ai branché sur une prise connectée Shelly Plus Plug S, posée sur le bandeau électrique. Elle se pilote par une API HTTP locale, protégée par un mot de passe, et elle n’est jamais exposée sur internet. Allumer le switch revient à envoyer une requête :

# allume la prise du switch (true) ou l'eteint (false)
curl -s --digest -u "$auth" "http://<prise>/rpc/Switch.Set?id=0&on=true"

Le switch est le premier élément à démarrer et le dernier à s’éteindre, car tout passe par lui : les hyperviseurs, l’iDRAC, et même la borne Wi-Fi, qu’il alimente en PoE. Ce dernier point aura son importance plus bas.

Le T440 : l’iDRAC

#

Le T440 est le plus simple, parce qu’il a été conçu pour ça. L’iDRAC9 est une petite carte de gestion intégrée au serveur, avec son propre port réseau, qui reste alimentée tant que le serveur est branché, même éteint.

Le seul piège : l’IPMI sur le réseau est désactivé par défaut. Une fois activé dans l’interface de l’iDRAC, le serveur se pilote avec ipmitool :

# -C 17 : suite de chiffrement attendue par l'iDRAC9
# -f : mot de passe lu dans un fichier, jamais sur la ligne de commande
ipmitool -I lanplus -C 17 -H <idrac> -U <utilisateur> -f <fichier> chassis power on

L’option -C 17 m’a coûté un moment : sans elle, la connexion échoue avec un message qui n’aide pas beaucoup.

Le Precision vPro : Intel AMT… en Wi-Fi

#

Sur un PC professionnel, l’équivalent de l’iDRAC, c’est Intel AMT, la gestion à distance intégrée aux plateformes vPro. Elle permet d’allumer, d’éteindre ou de redémarrer la machine, même éteinte, tant qu’elle est branchée. Je l’ai activée avec rpc-go, l’outil d’Intel prévu pour ça.

Mais l’AMT ne fonctionne qu’avec les puces réseau Intel. Or, sur ce Precision, l’Ethernet passe par un adaptateur USB, que l’AMT ne sait pas utiliser. Il ne reste donc que le Wi-Fi, connecté au réseau du lab via la FortiAP. Et c’est là que les problèmes ont commencé.

Premier problème : l’AMT disparaissait dès que Proxmox démarrait. Le PC éteint, l’AMT répondait parfaitement. Mais une fois Linux lancé, son pilote Wi-Fi prenait la main sur la carte, et la connexion de l’AMT était coupée. Comme Proxmox n’utilise pas le Wi-Fi, la solution a été d’empêcher Linux de charger ce pilote :

# proxmox n'utilise pas le wifi : on laisse la carte a l'AMT
cat > /etc/modprobe.d/blacklist-wifi.conf <<EOF
blacklist iwlwifi
blacklist iwlmvm
EOF
update-initramfs -u -k all

Deuxième problème : après un allumage du switch, l’AMT mettait plusieurs minutes à revenir. Le switch alimente la FortiAP, qui doit d’abord démarrer, puis l’AMT se reconnecte au Wi-Fi à son rythme. J’ai mesuré environ sept minutes. Le script attend donc que l’AMT réponde avant d’envoyer l’ordre d’allumage, avec une limite à douze minutes.

Troisième subtilité : l’AMT ne répond pas au ping quand le PC est éteint. Pour savoir si elle est joignable, je teste son interface web sur le port 16992. L’ordre d’allumage lui-même passe par WS-Man, un protocole SOAP un peu verbeux, mais qui se résume à une valeur : 2 pour allumer, 8 pour couper.

C’est la machine qui m’a le plus résisté, et celle qui m’a le plus appris.

Le Precision sans vPro : Wake-on-LAN

#

Pour le deuxième Precision, je comptais faire la même chose. Même modèle, même processeur, un i7-11850H compatible vPro… et pourtant, aucune trace de l’AMT dans le BIOS. J’ai cherché un bon moment avant de comprendre : un processeur compatible ne suffit pas, il faut que toute la plateforme soit vPro. Ce portable ne l’est pas, et l’absence de l’étiquette « vPro » sur le châssis aurait dû me mettre la puce à l’oreille.

Je me suis donc rabattu sur le Wake-on-LAN. Une fois activé dans le BIOS, la carte réseau intégrée reste en veille et rallume la machine quand elle reçoit un « paquet magique ». Le problème, c’est que ce paquet est un broadcast : il ne sort pas de son VLAN. Envoyé depuis pve0, qui est sur un autre réseau, il n’arrive jamais.

La solution : demander à un nœud déjà allumé du même VLAN d’envoyer le paquet à ma place. Le script se connecte en SSH au T440 ou à l’autre Precision, et c’est lui qui réveille pve1 :

# le broadcast WoL ne traverse pas le FortiGate :
# on le fait envoyer par un noeud allume du VLAN d'admin
for relay in $PVE3_IP $PVE2_IP; do
  if [[ $(up "$relay") == UP ]]; then
    ssh root@"$relay" "wakeonlan -i 10.10.10.255 $PVE1_MAC" && return
  fi
done

Conséquence directe : pve1 est toujours le dernier à démarrer, puisqu’il a besoin d’un relais allumé.

Les portables, écran fermé

#

Dernier point propre aux portables : par défaut, fermer l’écran met la machine en veille. Dans une baie, écran fermé, c’est exactement ce qu’il ne faut pas. Il suffit de dire à Linux d’ignorer la fermeture du capot :

# /etc/systemd/logind.conf : ne rien faire a la fermeture de l'ecran
HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore

Puis un systemctl restart systemd-logind pour l’appliquer. Au passage, je vérifie de temps en temps que la batterie charge bien et que les températures restent raisonnables avec sensors : deux portables fermés l’un au-dessus de l’autre, c’est aussi pour ça que j’ai ajouté un ventilateur dans la baie.

Un script pour orchestrer tout ça

#

Avoir une méthode par machine, c’est bien, mais je ne voulais pas taper quatre commandes différentes à chaque fois. J’ai donc écrit un script, lab.sh, qui tourne sur pve0.

Au lancement, il récupère l’état de chaque machine et affiche une liste à cocher : je choisis ce que je veux allumer ou éteindre, je valide, et il s’occupe du reste. Il suit ensuite le démarrage en direct, jusqu’à ce que chaque machine réponde.

Tout l’intérêt est dans l’ordre des opérations. À l’allumage :

# allume dans le bon ordre : switch, puis pve2/pve3, puis pve1 (son WoL passe par pve2 ou pve3)
do_on() {
  if [[ $list == *" switch "* ]]; then on switch; wait_switch; fi
  for t in pve2 pve3; do [[ $list == *" $t "* ]] && on "$t"; done
  [[ $list == *" pve1 "* ]] && on pve1
}

L’extinction se fait dans l’ordre inverse, et c’est elle qui m’a demandé le plus d’ajustements. Chaque nœud est d’abord arrêté proprement en SSH, avec l’AMT ou l’iDRAC en secours s’il ne répond pas. Ensuite, le script attend que tout soit réellement éteint avant de couper le switch. Pour le T440, attendre que le ping tombe ne suffit pas : le serveur cesse de répondre bien avant la fin de son arrêt. Le script attend donc que l’iDRAC confirme que l’alimentation est coupée, puis laisse encore 30 secondes de marge aux portables avant de couper la prise.

Les mots de passe de la prise, de l’AMT et de l’iDRAC ne sont jamais écrits dans le script : ils sont lus dans des fichiers que seul root peut ouvrir.

Et comme je passe pas mal de temps devant, je me suis fait plaisir sur l’affichage :

Aujourd’hui, allumer tout le lab depuis mon PC, c’est une connexion à pve0, une commande, et quelques minutes d’attente. L’éteindre, pareil.

Et en entreprise ?

#

Ce montage reprend, à petite échelle, des principes qu’on retrouve partout en entreprise :

• un réseau d’administration séparé : les cartes de gestion (iDRAC, AMT) et les interfaces des hyperviseurs vivent dans leur propre VLAN, que les utilisateurs ne voient pas ;
• un point d’entrée unique : pve0 joue le rôle d’un bastion, la seule machine par laquelle on administre le reste ;
• un accès sans port exposé : Tailscale fonctionne comme une solution d’accès « zero trust », où c’est l’identité de l’utilisateur et de l’appareil qui ouvre l’accès, et non un port ouvert sur internet ;
• des flux listés un par un : la règle du pare-feu n’autorise que les services nécessaires.

Il manque encore des choses qu’une entreprise exigerait : des comptes nominatifs plutôt que root, une journalisation centralisée de chaque action, et des postes d’administration dédiés. Ce sont justement des briques prévues pour la suite : les postes d’administration ont leur VLAN, et le SOC viendra collecter les journaux.

La suite

#

Le lab s’allume et s’éteint maintenant depuis n’importe où. Dans l’épisode 3, on lui donne une vraie structure : plan d’adressage, VLANs, et règles de communication entre les zones.