Accès distant nomade : tunnel WireGuard et routeur de voyage
Mise en place d'un accès distant chiffré vers le réseau domestique et le lab, combinant un tunnel WireGuard porté par l'hyperviseur et un routeur de voyage autonome qui rétablit l'environnement réseau du domicile depuis n'importe quelle connexion.
Le contexte
Mon infrastructure de lab tourne chez moi, sur une machine unique. Deux besoins en découlent naturellement.
Le premier est celui de l'administrateur : pouvoir intervenir sur l'infrastructure depuis l'extérieur, sans avoir à être physiquement devant la machine.
Le second est celui de l'utilisateur nomade : retrouver son environnement réseau habituel — ses machines, ses résolutions de noms, ses accès — depuis un hôtel, un logement temporaire ou un partage de connexion mobile, sur des réseaux sur lesquels on n'a aucune confiance et aucune maîtrise.
Ce sont deux problèmes différents, et ils appellent deux réponses différentes.
La contrainte de départ
Une box opérateur grand public, sans adresse IP fixe, et aucune envie d'ouvrir un port entrant dessus.
C'est le point qui détermine toute l'architecture. Un VPN classique suppose un serveur qui écoute, donc un service exposé en permanence à Internet : gestion de certificats, surveillance des tentatives de connexion, et une porte que quelqu'un finira par essayer. Sur un équipement de bordure que je ne maîtrise pas, ce n'était pas le compromis que je voulais.
Le choix de WireGuard
WireGuard est un protocole de tunnel chiffré récent et volontairement minimaliste : quelques milliers de lignes de code là où les protocoles plus anciens en comptent des centaines de milliers. Cette compacité le rend plus facile à auditer et réduit sa surface de vulnérabilité. Il est intégré au noyau Linux depuis 2020.
Concrètement, il apporte trois choses utiles ici : des performances élevées pour un coût processeur faible, une reconnexion quasi instantanée lors d'un changement de réseau — ce qui compte quand on bascule du Wi-Fi à la 4G —, et une configuration réduite à une paire de clés par machine.
L'architecture
Le tunnel d'administration — l'hyperviseur en passerelle
Plutôt qu'installer un client VPN sur chacune des machines du lab, c'est l'hyperviseur qui porte le client et qui annonce la route du réseau du lab.
Une annonce de route, c'est le fait pour une machine du VPN de déclarer qu'elle sait joindre tout un réseau, et pas seulement elle-même. L'hyperviseur devient donc la passerelle : le client est installé sur une seule machine, et l'ensemble des serveurs est joignable avec leurs adresses habituelles, sans rien modifier sur eux.
La mise en relation passe par Tailscale, une surcouche de WireGuard. Chaque machine établit une connexion sortante vers un service d'annuaire qui se contente de mettre les extrémités en relation ; le trafic reste chiffré de bout en bout entre elles. Aucun port entrant n'est ouvert sur la box.
Le compromis, assumé : on introduit une dépendance à un service tiers pour l'établissement de la relation. En contrepartie, on supprime toute exposition permanente d'un service à Internet. Sur un réseau domestique dont je ne maîtrise pas l'équipement de bordure, c'est l'arbitrage que je retiens. En entreprise, avec une IP fixe et un pare-feu périmétrique maîtrisé, je monterais le tunnel WireGuard directement sur le pare-feu.
Le routeur de voyage — l'utilisateur nomade
Le second volet répond à un besoin différent : ne pas avoir à configurer un client VPN sur chaque appareil qu'on emporte.
Un routeur de voyage GL.iNet Slate AX (GL-AXT1800), sous OpenWrt, porte le client WireGuard directement dans son firmware. Il se raccorde à Internet par le moyen disponible sur place — Wi-Fi de l'hôtel en mode répéteur, câble Ethernet, partage de connexion mobile — puis monte le tunnel et diffuse son propre réseau Wi-Fi.
Conséquence pratique : tout appareil qui se connecte à ce Wi-Fi passe automatiquement par le tunnel, sans configuration ni client à installer. Un téléphone, un ordinateur portable, une console : ils voient un réseau Wi-Fi normal, et sortent par la connexion du domicile.
L'ensemble est alimentable sur batterie externe, ce qui le rend totalement autonome et transportable.
Trois bénéfices en découlent :
- le réseau public devient un simple transport — le Wi-Fi de l'hôtel ne voit passer que du trafic chiffré, et n'a accès à rien ;
- un seul SSID à retenir, quel que soit le lieu, avec la même clé — les appareils s'y reconnectent seuls ;
- l'isolation — les appareils sont derrière le routeur, pas exposés sur le réseau partagé de l'établissement.
L'articulation avec le pare-feu
Le VPN traverse le filtrage : une règle explicite autorise l'interface d'administration de l'hyperviseur depuis la plage d'adresses attribuée par le VPN. Sans elle, l'activation du pare-feu aurait coupé l'accès distant.
Cette règle a été validée en conditions réelles : le pare-feu a été activé au travers du tunnel lui-même, ce qui constituait à la fois le test et le risque. Une session de secours et un accès physique à la machine avaient été prévus avant la bascule.
La limite rencontrée
Le recouvrement de plages d'adressage. Le réseau du lab utilise 192.168.1.0/24, qui est aussi la plage la plus courante sur les box domestiques. Depuis un réseau utilisant la même plage, la route annoncée entre en conflit avec le réseau local : la machine ne sait plus si 192.168.1.201 désigne un serveur du lab ou un appareil sur place.
Deux contournements existent — passer par les adresses du réseau VPN plutôt que par les adresses locales, ou utiliser la résolution de noms interne du VPN. La correction de fond serait de renuméroter le lab sur une plage moins courante, ce qui est la bonne pratique lorsqu'on prévoit dès le départ des accès distants.
Je préfère annoncer cette limite plutôt que de la laisser découvrir : c'est une conséquence directe d'un choix d'adressage fait avant que le besoin d'accès distant n'existe.
Le résultat
Deux modes d'accès complémentaires, qui couvrent deux usages distincts du même protocole :
| Tunnel d'administration | Routeur de voyage | |
|---|---|---|
| Usage | Administrer l'infrastructure | Retrouver son réseau domestique |
| Client installé sur | La machine de l'administrateur | Le routeur, une seule fois |
| Appareils couverts | Un | Tous ceux connectés au Wi-Fi |
| Portée | Tout le réseau du lab, via annonce de route | Tout le trafic sortant |
Ce que j'en retiens
Le VPN nomade relie une machine à un réseau — c'est le cas ici. Le VPN site-à-site relie deux réseaux entiers en permanence, monté par les équipements réseau : les utilisateurs n'installent rien et perçoivent les deux sites comme un seul.
Ce projet m'a fait manipuler la première catégorie dans deux configurations opposées : un client par machine, et un client unique servant toute une flotte. La seconde approche est celle qui se transpose le mieux en entreprise — c'est exactement le principe d'une agence raccordée au siège.