Comment planifier un serveur VPN silencieux, sobre et toujours allumé

Le repos est l'état dans lequel un boîtier VPN domestique passe presque toute sa vie, c'est donc cet état qui mérite d'être mesuré. La même machine doit encore répondre à une connexion, servir un fichier et terminer une sauvegarde pendant que le tunnel est monté, et ces trois tâches tirent dans des directions différentes. Silencieux, sobre et toujours joignable sont des propriétés distinctes, et une fiche technique n'en décrit aucune. Dérouler les vérifications ci-dessous dans l'ordre évite qu'une décision matérielle ne devienne une reconstruction six mois plus tard.

Commencez par les rôles, pas par les pièces

Notez chaque tâche que le boîtier doit accomplir quand personne ne regarde. Une passerelle WireGuard ou OpenVPN, un partage de fichiers, une cible de sauvegarde et une tâche d'indexation ont des coûts permanents différents, et une machine qui fait les quatre a un plancher bien plus élevé qu'une machine qui ne fait que la première. La consommation au repos est la somme de ces planchers, pas leur moyenne. C'est pourquoi deux boîtiers décrits tous deux comme sobres peuvent varier d'un facteur trois dans la même pièce.

Décider tôt si les données vivent sur le même hôte que le tunnel conditionne tout le reste. Des hôtes séparés signifient deux consommations au repos, mais une passerelle qui reste éveillée pendant que le stockage dort ; un seul hôte signifie une seule consommation et un seul domaine de défaillance. Ni l'un ni l'autre n'est faux, mais la réponse doit être écrite avant que la liste des pièces existe.

Mesurez le boîtier entier dans trois états

Un wattmètre mural entre la prise et l'alimentation est le seul instrument honnête ici, car il inclut les pertes de conversion, le démarrage des disques et chaque périphérique USB que vous avez oublié. Relevez trois chiffres : le repos avec le tunnel monté et rien d'autre, le même boîtier sous un vrai transfert distant, et le boîtier pendant une sauvegarde planifiée.

Les compteurs logiciels aident à expliquer la lecture du wattmètre mais ne la remplacent pas. L'interface RAPL rapporte l'énergie du paquet et du domaine mémoire, ce qui exclut les pertes de l'alimentation et tout ce qui est branché en USB.

read -r a < /sys/class/powercap/intel-rapl:0/energy_uj; sleep 60; read -r b < /sys/class/powercap/intel-rapl:0/energy_uj
awk -v a="$a" -v b="$b" 'BEGIN{printf "package average: %.1f W\n", (b-a)/60/1000000}'

Le bruit demande le même traitement. Un boîtier sans ventilateur supprime une source et laisse le disque dur, l'alimentation et le sifflement des bobines, alors écoutez pendant une sauvegarde plutôt qu'à l'écran de connexion. La température fait partie du même passage : lisez les capteurs sous charge soutenue et ne désactivez jamais la protection thermique pour rendre un boîtier plus silencieux.

Convertissez les watts en une année comparable

La consommation continue se convertit en énergie par une multiplication, et la faire une fois évite que le coût annuel soit une surprise. Une moyenne illustrative de 11 W sur une année complète se calcule ainsi.

awk 'BEGIN{printf "%.1f kWh/year at 11 W\n", 11*24*365/1000}'

Ce chiffre est de l'arithmétique, pas une mesure de votre boîtier, et le tarif par lequel vous le multipliez déplace la réponse plus que quelques watts. Le calcul sert à comparer deux conceptions : une passerelle au repos à 6 W contre une à 15 W est une décision que vous pouvez chiffrer. La puissance nominale d'un processeur n'est pas ce chiffre, car elle décrit un paquet sous charge et non un système au repos. Utilisez la moyenne du wattmètre avec le tarif local et étiquetez le résultat comme une estimation.

Décidez si la veille est autorisée

La veille économise le plus d'énergie et casse le plus d'hypothèses. Un hôte endormi ne peut pas accepter la connexion entrante qui le réveillerait, et un keepalive client n'y change rien ; seul un appareil toujours allumé sur le même LAN peut envoyer un paquet wake-on-LAN.

Si le tunnel doit être joignable à toute heure, traitez la veille comme désactivée par politique et écrivez-le dans les notes de construction. Masquer les cibles est brutal, mais c'est explicite et cela survit mieux aux mises à jour de paquets qu'une habitude.

systemctl status sleep.target suspend.target
sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
systemd-inhibit --list

Wake-on-LAN mérite sa propre ligne dans ces notes parce qu'il échoue en silence. La fonction doit être activée dans le firmware, ne fonctionne que sur certaines interfaces et exige un appareil déjà éveillé pour envoyer le paquet. Testez-la avant d'en dépendre, pas après un voyage.

Prouvez-le sous la charge qu'il verra vraiment

La dernière vérification est celle que les gens sautent : lancez la charge prévue et observez le boîtier pendant une heure. Un transfert distant, une sauvegarde et une reconstruction d'index en même temps montreront si le refroidissement, la liaison et le stockage peuvent porter la combinaison de rôles choisie.

uptime
sensors | grep -E 'Core|Package|fan'
ss -s

Regardez aussi la liaison d'accès dans la même fenêtre, car la bande passante montante limite généralement le débit distant bien avant le processeur. Si le tunnel sature à une fraction de ce que le processeur pourrait chiffrer, une puce plus rapide n'achète absolument rien.