Création d'un profil VPN sur un routeur Ubiquiti

Contexte et besoins

Dans le cadre de mon alternance, plusieurs admins du lab passent en télétravail ponctuel et doivent pouvoir reprendre la main sur les serveurs internes (contrôleur de domaine, hôte Docker, hyperviseur, etc.) sans qu’on expose chaque service sur Internet. La bonne approche est un VPN d’accès distant : un seul port UDP publié côté WAN, le client s’y connecte depuis son laptop en télétravail, et il arrive sur le LAN du lab comme s’il était sur place.

Le besoin est simple : monter un serveur WireGuard sur la passerelle UniFi du lab, générer un profil client laptop pour le télétravail, et valider la connexion depuis un partage de connexion mobile (4G) afin de s’assurer que le tunnel survit derrière le NAT d’un opérateur grand public.

Rappel théorique sur WireGuard

Pourquoi WireGuard plutôt qu’OpenVPN ou IPsec ?

WireGuard est un protocole VPN moderne intégré au noyau Linux depuis la version 5.6. Il a trois propriétés qui font sa différence :

Pour un usage interne entreprise, WireGuard gagne sur les axes pertinents : simplicité, performance, sécurité par défaut, configuration auditable.

Modèle d’authentification

Pas de certificats x509, pas de PSK partagé entre tous les clients. Chaque pair (peer) a :

• une clé privée (32 octets), gardée localement ;
• une clé publique (32 octets), partagée avec les autres pairs.

Les pairs s’identifient mutuellement par leur clé publique. C’est un modèle proche de SSH par clé : simple, robuste, traçable.

Concepts clés

• Endpoint : couple IP:port du serveur, vu par le client.
• AllowedIPs : côté client, double rôle ; c’est à la fois le filtrage des paquets entrants (n’accepte un paquet d’un peer que s’il vient d’une IP listée) et la table de routage (les paquets vers ces IPs partent dans le tunnel). Mettre 0.0.0.0/0 revient à router tout le trafic dans le VPN (full tunnel) ; mettre seulement le LAN cible fait du split-tunneling.
• PersistentKeepalive : intervalle (en secondes) entre deux paquets vides envoyés au pair. Indispensable pour traverser les NAT mobiles, qui ferment la session UDP au bout de 30-60 secondes d’inactivité.

Topologie

Prérequis

• Une UDM avec UniFi OS récent (≥ 4.x), qui propose WireGuard nativement dans Settings → VPN → VPN Server.
• Un compte admin local sur l’UDM.
• Une adresse IP publique stable côté FAI ou un nom DDNS configuré sur l’UDM (UniFi en propose un en *.ui.direct).
• Un client WireGuard installé sur le laptop (wireguard-tools côté Linux).

Création du serveur WireGuard sur l’UDM

Accès à l’interface UniFi

J’ouvre https://192.168.10.254 dans le navigateur, je me logge avec mon compte local admin.

Je passe ensuite dans Settings → VPN → VPN Server → Create New VPN Server.

Paramétrage du serveur

VPN Type        : WireGuard
Name            : LAB-WG
Network         : 10.0.200.0/24
Server Port     : 51820 (UDP)
Pre-shared key  : Generate (optionnel mais recommandé)
DNS             : 192.168.10.250 (DC interne du lab)

Explications ligne par ligne :

• Name: LAB-WG : nommage explicite pour distinguer si je crée plusieurs profils plus tard.
• Network: 10.0.200.0/24 : sous-réseau distinct du LAN principal (192.168.10.0/24). Permet d’écrire des règles de pare-feu fines (par exemple, limiter ce que le sous-réseau VPN peut atteindre côté LAN).
• Server Port: 51820 UDP : port standard WireGuard. On peut le changer pour quelque chose de moins évident, mais le port standard est OK quand on n’expose pas de bannière.
• Pre-shared key : couche cryptographique supplémentaire (PSK + clés publiques). Pas obligatoire, mais recommandé pour résister à un éventuel break-in cryptographique futur sur ChaCha20-Poly1305.
• DNS: 192.168.10.250 : DC interne du lab. Permet au client VPN de résoudre les noms internes (dc.lab.local, glpi.lab.local) une fois connecté.

L’UDM génère automatiquement la clé publique du serveur (visible dans l’écran récapitulatif) et démarre le service WireGuard sur le port 51820 UDP. Le port-forwarding WAN→service est mis en place automatiquement par UniFi.

Création du profil client laptop

Bouton Add Client dans la page du serveur LAB-WG.

Name             : LAPTOP-ADMIN
Client IP        : 10.0.200.2
Allowed Networks : 192.168.10.0/24
DNS              : 192.168.10.250
Pre-shared key   : Use server PSK

UniFi génère la clé privée du client et propose de télécharger un fichier .conf ou de scanner un QR code (utile pour les clients mobiles, je n’en ai pas besoin ici).

Le fichier LAPTOP-ADMIN.conf ressemble à :

[Interface]
PrivateKey = uK9...j8w=
Address    = 10.0.200.2/24
DNS        = 192.168.10.250

[Peer]
PublicKey    = WJh...8sM=
PresharedKey = aBc...XyZ=
Endpoint     = lab.ui.direct:51820
AllowedIPs   = 10.0.200.0/24, 192.168.10.0/24
PersistentKeepalive = 25

Explications ligne par ligne :

• [Interface] PrivateKey : clé privée du laptop. Ne jamais partager. UniFi ne la stocke pas après génération : si je perds le .conf, il faudra recréer un client.
• Address: 10.0.200.2/24 : IP du laptop dans le tunnel.
• DNS: 192.168.10.250 : force la résolution des noms via le DNS interne du lab quand le tunnel est actif.
• [Peer] PublicKey : clé publique du serveur (l’UDM).
• Endpoint: lab.ui.direct:51820 : DDNS UniFi de l’UDM. Plus stable qu’une IP publique qui peut changer chez le FAI.
• AllowedIPs: 10.0.200.0/24, 192.168.10.0/24 : mode split-tunneling. Seul le trafic vers le sous-réseau VPN et le LAN du lab passe par le tunnel. Le reste du trafic (navigation web, visio, etc.) sort en direct depuis le réseau du moment.
• PersistentKeepalive: 25 : un paquet vide toutes les 25 secondes. Indispensable pour survivre derrière le NAT 4G d’un opérateur mobile (timeout typique 30-60 s).

Configuration côté Linux

# Installation des outils WireGuard sur Debian/Ubuntu
apt install -y wireguard-tools

# Copie du profil dans /etc/wireguard
sudo cp ~/Downloads/LAPTOP-ADMIN.conf /etc/wireguard/wg0.conf
sudo chmod 600 /etc/wireguard/wg0.conf

# Activation manuelle (test)
sudo wg-quick up wg0

# État du tunnel
sudo wg show

wg show doit afficher quelque chose comme :

interface: wg0
  public key: ABC...=
  private key: (hidden)
  listening port: 41234

peer: WJh...8sM=
  preshared key: (hidden)
  endpoint: 192.0.2.123:51820
  allowed ips: 10.0.200.0/24, 192.168.10.0/24
  latest handshake: 2 seconds ago
  transfer: 1.2 KiB received, 856 B sent
  persistent keepalive: every 25 seconds

latest handshake confirme que le tunnel est établi.

Démarrage à la demande

# Activation manuelle quand on en a besoin
sudo systemctl start wg-quick@wg0

# Coupure du tunnel
sudo systemctl stop wg-quick@wg0

Vérifications

Test depuis le LAN du lab : ne fait rien

Quand je suis branché sur le LAN du lab, je désactive le tunnel. Pas besoin de VPN pour atteindre 192.168.10.x directement.

Test depuis un partage de connexion 4G : test critique

Je bascule mon laptop en partage de connexion 4G d’un téléphone, je désactive le Wi-Fi de l’entreprise pour être sûr de ne pas tester en local.

# Tunnel actif
sudo wg-quick up wg0

# Test : ping de la passerelle interne du lab
ping -c 4 192.168.10.254

# Test : DNS interne
dig @192.168.10.250 dc.lab.local

# Test : ouverture d'une session SSH sur la VM Docker
ssh admin@192.168.10.150

Tout doit passer : ping, DNS, SSH. Si le ping échoue mais que wg show montre un handshake, c’est que les règles de pare-feu de l’UDM filtrent le trafic VPN→LAN — il faut alors créer une règle d’autorisation dans Settings → Security → Firewall Rules.

Test split-tunneling

# IP publique vue de l'extérieur
curl https://api.ipify.org

Sans VPN actif, je vois l’IP publique de l’opérateur 4G. Avec le VPN actif et un AllowedIPs limité (split-tunneling), je vois toujours l’IP de la 4G : c’est le comportement attendu — seul le trafic vers le LAN du lab passe par le VPN, le reste sort en direct.

Si je voulais router tout le trafic via le lab (par exemple pour passer toutes les requêtes par le proxy interne), je remplacerais AllowedIPs par 0.0.0.0/0, ::/0 côté client.

Problèmes rencontrés et solutions

Compétences du bloc 1 mobilisées

Bilan

Le serveur WireGuard est fonctionnel sur l’UDM, le profil LAPTOP-ADMIN se monte en quelques secondes côté laptop, et le test 4G valide le passage du NAT opérateur. L’expérience est très différente d’OpenVPN : la connexion s’établit en moins d’une seconde, la conf est minimaliste, et la batterie n’est pas affectée en mobilité.

Trois enseignements :

• la clé privée par device est non négociable pour un usage propre : un profil partagé entre plusieurs postes empêche la révocation ciblée ;
• PersistentKeepalive est invisible mais critique en mobilité : sans lui, le tunnel meurt silencieusement sur 4G ;
• le split-tunneling est le bon défaut pour un VPN d’accès distant : pas besoin de faire transiter tout le trafic d’un admin en télétravail par le lab, ça consomme de la bande passante sans gain.

Pour la suite, il reste à ajouter un profil par admin au fur et à mesure des demandes, rédiger les règles de pare-feu spécifiques au sous-réseau VPN (par exemple, autoriser SSH vers le segment serveurs mais bloquer le segment AD si non nécessaire), et documenter la procédure de révocation d’un profil dans la base de connaissances de l’équipe.

Sources

• Ubiquiti Help — UniFi VPN Server , Ubiquiti.
• WireGuard — Quick Start , Jason A. Donenfeld.
• WireGuard — White Paper , Jason A. Donenfeld, 2017.
• WireGuard — Install , WireGuard project.
• ANSSI — Recommandations relatives à l’administration sécurisée des systèmes d’information , ANSSI.