Configurer le VPN WireGuard en toute sécurité pour les administrateurs de serveurs

Un réseau de maintenance plutôt que des ports d'administration accessibles au public

Les ports d'administration accessibles au public augmentent la surface d'attaque d'un serveur : les tentatives de connexion SSH, les erreurs de configuration des interfaces d'administration et les services de surveillance exposés par inadvertance sont directement accessibles depuis des réseaux externes. Un accès WireGuard réduit cette visibilité, car seul un port UDP défini doit rester accessible pour le tunnel crypté. WireGuard ne masque toutefois pas le trafic sous la forme de HTTPS et ne propose pas de mode de transport TCP.

Le modèle idéal pour l'administration d'un VPN est généralement un réseau en étoile : le serveur gère l'interface wg0 et se voit alors attribuer, par exemple, l'adresse interne 10.77.0.1. L'ordinateur portable d'une personne autorisée se connecte en tant que pair à part entière et utilise, par exemple, l'adresse 10.77.0.10. SSH, une console Web interne ou des points de surveillance acceptent alors les accès via le réseau tunnel plutôt que via l'adresse publique du serveur.

Il ne s'agit pas d'un VPN destiné aux utilisateurs finaux, dont le but est de rediriger l'ensemble du trafic Web d'un appareil. Pour la maintenance, un modèle d'accès restreint est plus pertinent : le tunnel sert uniquement de passerelle vers des cibles d'administration clairement définies. Un tunnel complet peut certes être utilisé de manière ciblée, mais il modifie en outre le routage, l'utilisation du DNS et l'accessibilité aux services externes. Ces effets secondaires ne sont généralement pas nécessaires pour un accès dédié à la maintenance.

Le Réseau de maintenance Il s'agit uniquement d'une limite réseau. Elle ne détermine pas quel compte Linux est autorisé à se connecter, quelles commandes ce compte est autorisé à exécuter, ni si le système d'exploitation est à jour. En complément, vous avez besoin de clés SSH et de comptes personnels, de droits sudo correctement limités, de règles de pare-feu, de mises à jour de sécurité, d’une journalisation et d’un accès d’urgence bien géré. Ainsi, une faille dans une seule couche de protection ne sera pas le seul facteur déterminant l’accès.

Claser correctement les clés, les pairs et les adresses IP autorisées

Chaque pair WireGuard dispose de sa propre paire de clés. La clé privée reste exclusivement sur le serveur, l'ordinateur portable ou le dispositif de gestion correspondant ; seule la clé publique dérivée de celle-ci est stockée sur le poste distant. Une clé pré-partagée (PresharedKey) facultative complète la cryptographie à clé publique en ajoutant un matériau de clé symétrique supplémentaire. Il s'agit d'une couche supplémentaire, mais elle ne remplace ni les clés privées ni une gestion des clés traçable.

Place un Un pair par appareil et non pas un pair commun à toute une équipe. Cela permet de supprimer de manière ciblée un poste de travail perdu ou un appareil de prestataire de services qui n'est plus nécessaire. Les clés WireGuard permettent d’accéder au réseau de maintenance. Par ailleurs, les clés SSH authentifient une personne ou un appareil auprès du service SSH ; leur retrait doit donc être planifié à ces deux niveaux.

Les éléments suivants sont particulièrement importants : AllowedIPs sur le serveur. Dans WireGuard, elles constituent une table de routage Cryptokey : pour les paquets sortants, elles déterminent le pair approprié en fonction de l'adresse de destination. Pour les paquets entrants déjà authentifiés, elles limitent également les adresses sources internes que ce pair est autorisé à utiliser. Ce paramètre est donc bien plus qu’une simple spécification d’itinéraire.

Si l'ordinateur portable de l'administrateur se voit attribuer l'adresse 10.77.0.10, le serveur doit contenir, pour ce pair précis, AllowedIPs = 10.77.0.10/32. L'attribution /32 associe une seule adresse de tunnel à ce pair. Si vous attribuiez systématiquement 10.77.0.0/24 à chaque pair d'administration, cette association deviendrait floue et la configuration serait inutilement trop large. Vérifie également que le réseau VPN choisi n’entre pas en conflit avec les réseaux de site, de conteneurs ou domestiques.

Planifier les limites du réseau et le modèle d'accès

Planifiez le réseau d'adresses VPN avant l'installation. Choisissez un espace privé qui ne chevauche ni les réseaux LAN existants, ni les réseaux cloud, ni les réseaux Docker ou Kubernetes, ni les réseaux domestiques couramment utilisés. Déterminez quels systèmes doivent être accessibles via le tunnel : uniquement le serveur passerelle, un réseau d'administration délimité ou des services individuels. Cela permettra ensuite de définir les routes client, les règles de pare-feu et, le cas échéant, les routes de retour.

Pour chaque appareil, consigne par écrit le nom de l'utilisateur responsable, la clé publique WireGuard, l'adresse IP fixe du tunnel, l'objet de l'autorisation et la procédure de révocation. Les groupes doivent être définis en fonction des tâches, telles que l'exploitation, la gestion des bases de données ou l'assistance externe, et non selon un principe général du type „ le VPN autorise tout “. Conservez également un accès d'urgence indépendant, par exemple une console de fournisseur d'accès. Vérifiez-le avant toute modification du pare-feu, du SSH ou du routage, afin qu'une règle erronée n'entraîne pas un blocage.

Le Pare-feu Il s'agit de la limite de réseau principale : elle autorise le port UDP WireGuard sur l'interface publique, mais n'accepte les connexions SSH que via l'interface d'entrée wg0 ou l'interface WireGuard effectivement utilisée. Une vérification supplémentaire du réseau source du VPN peut affiner davantage la règle, mais ne doit pas se substituer à la liaison d'interface. Ainsi, le pare-feu n'accepte pas les paquets arrivant sur l'interface publique uniquement sur la base d'une adresse source VPN déclarée. WireGuard associe des adresses internes authentifiées à des pairs ; cette garantie s'applique aux paquets acceptés via l'interface du tunnel.

Au niveau SSH, on utilise des clés à la place de la connexion par mot de passe, des comptes personnels et des règles « sudo » aussi restrictives que possible. OpenSSH peut être configuré avec AllowUsers Associer des comptes à des adresses sources ou à des réseaux CIDR supplémentaires. Cette deuxième barrière vient compléter celle mise en place à wg0 règle de pare-feu associée, mais ne la remplace pas.

Les applications web publiques doivent toujours disposer de leur propre sécurisation de la transmission via HTTPS et de certificats adaptés. Guide sur la sécurisation d'un site web à l'aide du protocole TLS Ce niveau concerne les accès via un navigateur. WireGuard protège quant à lui l'accès au réseau d'administration privé ; il ne remplace ni le protocole TLS pour les services publics, ni la procédure de connexion, la vérification des droits d'accès et la maintenance de ces derniers.

Structure de base avec wg-quick sans pièges de routage

Pour un serveur de maintenance isolé, un scénario point à point restreint suffit : le serveur gère wg0 avec l'adresse du tunnel 10.77.0.1/24, l'ordinateur portable de l'administration est équipé en permanence 10.77.0.10/32. Le serveur public n'accepte que le protocole UDP pour WireGuard. Les fichiers suivants constituent une proposition de configuration pour wg-quick; elles ne contiennent délibérément aucune clé réelle.

Sur le serveur, un nœud associe la clé publique de l'ordinateur portable à l'adresse exacte de son tunnel. La clé privée du serveur reste exclusivement dans le fichier local. Enregistrez la configuration, par exemple, sous /etc/wireguard/wg0.conf et limite l'accès en lecture au contexte d'administration, car celui-ci contient une clé secrète. Les clés publiques, en revanche, sont destinées au correspondant concerné.

[Interface]
Address = 10.77.0.1/24
ListenPort = <UDP_PORT>
PrivateKey = <SERVER_PRIVATE_KEY>

[Peer]
# Administrations-Laptop Person A
PublicKey = <ADMIN_A_PUBLIC_KEY>
AllowedIPs = 10.77.0.10/32

Sur l'ordinateur portable, il renvoie vers Endpoint à l'adresse publique du serveur et au port UDP sélectionné. Pour la maintenance pure et simple du serveur, il convient d'utiliser, côté client, AllowedIPs le plus souvent seulement 10.77.0.1/32 nécessaire. Ainsi, seul le trafic destiné à l'adresse VPN du serveur est acheminé via le tunnel ; les accès à Internet depuis l'ordinateur portable suivent leur chemin habituel.

[Interface]
Address = 10.77.0.10/32
PrivateKey = <ADMIN_A_PRIVATE_KEY>

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = <SERVER_PUBLIC_ADDRESS>:<UDP_PORT>
AllowedIPs = 10.77.0.1/32
PersistentKeepalive = <ONLY_IF_NEEDED>

L'indication 0.0.0.0/0 Sur le client, en revanche, une route par défaut IPv4 via le tunnel signifie : un Tunnel complet. wg-quick détermine les routes à partir des adresses IP autorisées (AllowedIPs) et traite les routes par défaut à l'aide d'une logique supplémentaire de routage basé sur des règles. Cela est possible dans le cadre d'un accès délibérément conçu ainsi, mais modifie notamment le trafic externe et peut mettre en évidence des problèmes liés au DNS ou à l'accessibilité.

Cet exemple concerne exclusivement IPv4. Si le serveur dispose d'une connectivité IPv6 publique, le port TCP 22 doit également y être explicitement bloqué par le pare-feu IPv6, ou le service SSH doit être lié de manière appropriée. Une autorisation IPv4 fermée ne protège pas contre un écouteur IPv6 qui resterait accessible publiquement. Planifiez séparément les adresses de tunnel IPv6 et les préfixes côté client ; ::/0 Il s'agirait alors également d'une route par défaut pour IPv6 et non d'un simple complément neutre à la configuration IPv4.

Commence par activer le tunnel, vérifie la connexion à l'adresse VPN, puis connecte-toi via SSH dans une deuxième session. Ce n'est que lorsque cette méthode fonctionne de manière fiable et qu'un accès indépendant à la console ou un accès de secours est disponible que tu devrais supprimer l'autorisation SSH publique. Vérifie à la fois l'IPv4 et, le cas échéant, l'IPv6. Les clés privées n'ont pas leur place dans les tickets, les historiques de discussion ou les systèmes de gestion de versions.

Comparer les modèles de routage et les règles de pare-feu

Le pare-feu applique le modèle d'accès souhaité. Sur l'interface publique, il est autorisé à accepter le port UDP WireGuard défini ; en revanche, le port TCP 22 ne doit pas y rester ouvert en tant qu'accès d'administration général. SSH n'est autorisé que pour les paquets dont l'interface d'entrée est wg0 ou l'interface WireGuard utilisée. Une vérification complémentaire du réseau source peut restreindre davantage la plage VPN autorisée, mais une règle basée exclusivement sur l'adresse source n'est pas suffisante.

La liaison à l'interface d'entrée empêche qu'un paquet arrivant sur l'interface publique ne satisfasse aux critères d'autorisation SSH uniquement en raison d'une adresse source falsifiée provenant de la zone VPN. Le mappage cryptographique des pairs et des adresses internes de WireGuard s'applique aux paquets authentifiés sur l'interface du tunnel. La syntaxe concrète du pare-feu doit correspondre au logiciel utilisé et prendre en compte de manière univoque tant l'interface que la famille d'adresses.

Tenez expressément compte de la connectivité IPv6 publique. Si seule l'ouverture du port IPv4 pour le protocole TCP 22 est supprimée, SSH peut rester accessible depuis Internet via IPv6. Bloquez donc également ce port dans les règles IPv6 ou configurez le service SSH de manière à ce qu'il n'écoute pas sur une adresse IPv6 publique. Les règles IPv4 et IPv6 doivent être vérifiées séparément.

Dans le cas d'un pare-feu à état, il ne suffit pas de ne considérer que le sens aller souhaité. Les paquets de réponse d'une connexion autorisée doivent également parvenir au client ; pour les accès derrière une passerelle, il faut en outre prendre en compte le sens retour depuis le réseau de destination. Une autorisation générale de l'ensemble du sous-réseau VPN vers tous les services transforme inutilement le réseau de maintenance en un vaste réseau d'accès interne.

Pour la maintenance d'un serveur unique, le premier modèle est le plus clair. Le chemin d'accès client vers 10.77.0.1/32 Cela suffit, et le pare-feu peut autoriser le protocole SSH uniquement pour les paquets arrivant via l'interface WireGuard. Le port UDP reste certes visible depuis l'extérieur, mais sans clé de pair correspondante, cela ne permet pas d'accéder au système à des fins d'administration.

Le deuxième modèle impose une séparation claire : le serveur VPN n'est alors pas seulement un point d'extrémité, mais aussi un routeur. Le pare-feu devrait autoriser, par exemple, le protocole SSH vers des serveurs d'administration définis et le protocole HTTPS vers une console interne, dans chaque cas limité à l'interface d'entrée WireGuard, à des réseaux cibles et à des ports spécifiques. Vous ne devriez pas ouvrir les ports de base de données à l'ensemble du VPN simplement parce que les utilisateurs sont déjà connectés.

Dans le cas d'un « Full Tunnel », le serveur VPN fait également office de passerelle pour les destinations Internet. Pour cela, il doit acheminer les paquets IPv4 entre wg0 et le transmettre via sa liaison montante ; de plus, les réponses doivent pouvoir revenir vers le réseau VPN. Dans de nombreuses configurations de serveurs, on utilise à cet effet une règle Source NAT ciblée au niveau de la liaison montante, lorsque le réseau en amont ne connaît pas de route vers le préfixe VPN. Concevez ces règles de manière réfléchie et limitez-les au réseau tunnel prévu.

Un « Full Tunnel » n'est pas une exigence de sécurité imposée par WireGuard, mais un choix de routage effectué au niveau du client. Parce que wg-quick Les routes par défaut issues de la liste « AllowedIPs » faisant l'objet d'un traitement particulier, ce paramètre ne doit être utilisé qu'avec une résolution de noms planifiée, une capacité de passerelle suffisante et des règles de sortie adaptées. Pour l'utilisation habituelle Administration du VPN elle est généralement plus large que nécessaire. Pour IPv6, la même question de planification se pose séparément : ::/0 achemine l'ensemble du trafic IPv6 via le tunnel.

Rendre les réseaux internes accessibles de manière ciblée

Si les administrateurs doivent accéder à d'autres systèmes privés situés derrière la passerelle VPN, la tâche ne se limite plus à un simple accès au serveur, mais s'étend au réseau d'administration routé. Commencez par planifier les réseaux et services cibles : par exemple, SSH vers les serveurs du segment d'administration et HTTPS vers une console interne. Chaque chemin supplémentaire élargit la zone de confiance et doit donc être justifié par une tâche opérationnelle concrète.

La première condition technique est que la passerelle soit autorisée à transférer des paquets IPv4. Le paramètre du noyau net.ipv4.ip_forward active ce comportement. Il ne faut pas la considérer comme une simple ligne de code sans conséquence : selon la documentation du noyau, une modification de ip_forward Les autres paramètres de configuration IPv4 reviennent à leurs valeurs par défaut sur l'hôte ou le routeur. Vérifie donc les consignes réseau et de sécurité en vigueur avant et après la modification.

Deuxièmement, le pare-feu a besoin de règles explicites Règles de transit dans les deux sens. Une règle ne devrait pas se contenter de bloquer tout le trafic provenant de wg0 les accepter sur le réseau local. Limitez-les plutôt au réseau source du VPN, aux adresses de destination prévues et aux protocoles nécessaires, par exemple le TCP 22 vers les serveurs d'administration et le TCP 443 vers une console. Les bases de données restent exclues de cette autorisation, sauf exception justifiée.

Troisièmement, le réseau de destination a besoin d'une voie de retour vers le réseau VPN, par exemple une route pour 10.77.0.0/24 via l'adresse interne de la passerelle. Sans cette route de retour, le trajet aller peut fonctionner, mais les réponses ne parviennent pas à l'administrateur. Si le routage n'est pas possible dans le réseau de destination, le NAT source sur la passerelle peut constituer une alternative technique ; toutefois, cela masque l'adresse d'origine du client VPN et complique ainsi la journalisation côté destination ainsi que la mise en place de règles plus précises.

Choisissez le réseau d'adresses VPN de manière à ce qu'il n'entre en conflit ni avec les réseaux locaux des administrateurs, ni avec les réseaux existants des sites, du cloud ou des conteneurs. Les chevauchements rendent le choix de l'itinéraire ambigu et génèrent des erreurs qui peuvent ressembler à un problème lié à WireGuard ou au pare-feu. Documente également les adresses de tunnel fixes et les appareils associés avant d'activer d'autres pairs ou réseaux cibles.

Gérer l'exploitation et les changements en toute sécurité

Un réseau de maintenance ne reste gérable que si chaque appareil se voit attribuer son propre pair, sa propre paire de clés et une adresse IP de tunnel fixe. Un inventaire doit donc comporter au minimum l'adresse du tunnel, la désignation de l'appareil, le nom de la personne responsable, l'usage prévu, ainsi que les dates de mise en service et de contrôle. L'attribution de l'adresse 10.77.0.10/32 à un ordinateur portable d'administration spécifique permet de retracer les accès et empêche que plusieurs appareils n'utilisent la même identité VPN.

Prévoyez le changement de clés comme un processus opérationnel régulier, et non pas uniquement en réaction à un incident. En cas de remplacement d’un appareil, créez un nouveau pair avec une nouvelle adresse ou une adresse de remplacement clairement documentée, vérifiez l’accès, puis supprimez l’ancien pair. Les clés privées WireGuard doivent se trouver exclusivement sur le terminal concerné ; elles ne doivent figurer ni dans les tickets ni dans les listes d’inventaire centralisées.

En cas de perte d'un ordinateur portable ou de départ d'une personne externe, tu supprimes le pair correspondant de la configuration du serveur. Cela empêche cette personne d'accéder au réseau d'administration, sans qu'il soit nécessaire de changer les clés des autres administrateurs. Retrait par les pairs Mais cela n'équivaut pas à la révocation d'une clé SSH : la clé WireGuard régit le cheminement du réseau, tandis que la clé SSH sert à se connecter au compte de destination.

Une fois un pair supprimé, WireGuard ne peut plus échanger de paquets via ce pair dans le cadre d'une connexion SSH existante ; la connexion se bloque donc ou prend fin après une interruption ou un délai d'expiration. La suppression n'annule toutefois pas automatiquement la connexion SSH déjà établie au niveau de l'application et ne met pas non plus fin aux processus lancés précédemment. En cas d'incident, vérifie donc également les autorisations SSH, les processus en cours, les comptes et, le cas échéant, les droits sudo.

Pour effectuer des modifications ciblées, il est possible de wg syncconf comparer une configuration WireGuard existante en mettant en évidence les différences ; selon le manuel, cela devrait perturber moins les sessions entre pairs que setconf. Cela ne remplace toutefois pas la validation, le contrôle par deux personnes ou les fenêtres de maintenance. Avant toute modification, sauvegarde la configuration fonctionnelle et note la procédure à suivre pour la restaurer.

Diagnostic : de la négociation de connexion à l'accès SSH

En cas de dysfonctionnement, sépare systématiquement le transport, le routage et l'application. Commence par le port UDP accessible publiquement et la procédure d'établissement de la connexion avant de modifier les paramètres SSH. La commande wg show Affiche, entre autres, les adresses IP autorisées (AllowedIPs), l'heure de la dernière poignée de main et le compteur de transferts pour les pairs configurés. Des valeurs manquantes ou inchangées indiquent un problème survenant avant l'accès SSH proprement dit.

Une fois la négociation établie, tu vérifies, tant sur le client que sur le serveur, l'adresse du tunnel effectivement définie et la route vers la destination. Pour la simple gestion de la passerelle, le client doit pouvoir atteindre la destination 10.77.0.1 via l'interface WireGuard. Pour les destinations internes, il faut également tenir compte des compteurs du pare-feu, du trafic de retour autorisé et de la route de retour du réseau de destination ; une poignée de main réussie ne garantit pas le respect de ces conditions.

Ce n'est qu'une fois que le chemin d'accès au réseau est correct que l'on peut passer à la vérification du service SSH. Vérifie les entrées pertinentes pour la connexion et la restriction de source dans le fichier sshd_config, notamment les partages d'utilisateurs tels que AllowUsers, puis vérifie l'état des services ainsi que les journaux à l'aide des outils fournis par ta distribution. Ensuite, examine le compte utilisateur et les entrées dans authorized_keys et les règles sudo séparément. La documentation de configuration ne suffit pas à elle seule à prouver ni la réussite de la connexion, ni l'accessibilité du service.

Des adresses IP autorisées (AllowedIPs) identiques ou qui se chevauchent ne constituent pas une simple erreur de documentation. Lors de l'envoi, WireGuard attribue les adresses de destination à un pair en fonction de ces préfixes ; lors de la réception, ceux-ci limitent les adresses sources internes du pair authentifié. Les préfixes d'hôte en double ou contradictoires ne constituent donc pas une identification unique et fiable Mise en correspondance entre pairs. Il ne faut pas partir du principe qu'un outil d'administration produira un résultat concret lors de la prise en charge d'une telle configuration. Il vaut mieux éviter la collision dès la phase d'inventaire et lors de la vérification de la configuration.

Applique les corrections de manière contrôlée et n'effectue les diagnostics qu'en disposant d'un accès d'urgence. Ainsi, une modification erronée au niveau des pairs, du routage ou du pare-feu ne bloquera pas en même temps la voie de retour permettant la réparation. Après chaque reprise, vérifie à nouveau la poignée de main, le compteur de transferts, la route et l'accès au service d'administration spécifiquement autorisé.

wg show
ip route

Le choix des outils et les limites de sécurité sont déterminants

Le choix de la méthode d'administration dépend de la configuration actuelle de l'administration du serveur, et non d'une méthode WireGuard prétendument universelle. wg-quick Convient aux configurations simples : le script d'aide configure l'interface, les adresses et les routes dérivées des adresses IP autorisées (AllowedIPs). Pour les réseaux complexes, la documentation recommande en revanche d'utiliser des outils plus spécifiques ou de procéder à une configuration directe à l'aide de wg et les outils IP.

Si un hôte gère déjà son réseau de manière déclarative via systemd-networkd, les fichiers .netdev et .network constituent une alternative appropriée. systemd-networkd prend en charge les paramètres spécifiques à WireGuard et peut récupérer les clés privées à partir des identifiants ; pour les contenus confidentiels, la documentation recommande d'utiliser des identifiants chiffrés ou, à défaut, des droits d'accès restrictifs sur les fichiers comme mesure de protection. Cela convient particulièrement aux serveurs déployés de manière automatisée.

Appels directs depuis wg et ip offrent un contrôle optimal pour l'automatisation, le routage par règles et les opérations spécifiques au pare-feu, mais exigent un modèle d'exploitation clairement défini. Ne gérez jamais la même interface à la fois via wg-quick, systemd-networkd et vos propres scripts. La coexistence de plusieurs entités responsables peut entraîner des conflits entre les routes, les adresses ou les paramètres de pair, ce qui complique la mise en place d'une restauration fiable.

La fonction PersistentKeepalive n'est utile que pour les pairs situés derrière un NAT ou un pare-feu à état, qui envoient rarement des données eux-mêmes mais doivent néanmoins rester joignables en entrée. Elle est désactivée par défaut ; la documentation mentionne 25 secondes uniquement comme intervalle possible, et non comme valeur par défaut générale. Les clients mobiles bénéficient souvent de l'itinérance, car WireGuard peut mettre à jour le point de terminaison à l'aide de paquets correctement authentifiés.

L'itinérance et la restriction stricte des terminaux constituent un compromis : un pare-feu qui n'accepte le protocole UDP qu'à partir de réseaux sources connus peut limiter la surface d'attaque, mais empêche une utilisation flexible en déplacement. WireGuard souligne également qu’un attaquant actif peut rediriger l’adresse source externe et ainsi favoriser une attaque par déni de service, sans pour autant lire ni modifier le contenu chiffré.

Un tunnel WireGuard ne remplace pas la gestion des identités, le contrôle des droits d'accès, les mises à jour, les sauvegardes ou la journalisation. Il ne masque pas son trafic sous la forme de HTTPS et ne propose pas de mode TCP. Les applications web publiques nécessitent donc toujours une sécurisation TLS distincte ; cet article explique les exigences et la mise en œuvre. Configurer HTTPS en toute sécurité. Distinguez clairement cette couche de protection de l'accès VPN destiné à l'administration.