par ·0 Commentaires

Le VPN classique dont on a parlé sur ce blog (OpenVPN etc) suit un modèle client → serveur : toutes les connexions passent par un point central. Pratique, mais vite limité quand on veut relier plusieurs machines, sites ou serveurs entre eux sans devenir l’admin d’une PKI artisanale.

Les mesh VPN changent la donne : chaque machine est un pair, les tunnels se créent directement entre les machines (peer-to-peer), et une couche centrale, le control plane, s’occupe de distribuer les clés et de faire du NAT traversal pour vous. Résultat : vous installez un client, vous vous authentifiez, et hop, toutes vos machines se voient, même derrière le NAT de votre FAI ou d’un hôtel.

Trois solutions dominent le marché de l’homelab : Tailscale, Headscale et NetBird. Les trois reposent sur WireGuard sous le capot. Voyons comment choisir.

Le principe : control plane et data plane

Pour bien comprendre la suite, il faut distinguer deux choses :

  • Le control plane : le service qui connaît vos machines, distribue les clés publiques, gère les ACL, et indique aux pairs où se joindre. C’est LUI qu’on veut pouvoir auto-héberger ou pas.
  • Le data plane : le trafic réel. Avec ces trois solutions, il passe directement entre vos machines, chiffré en WireGuard. Il ne transite (normalement) jamais par le serveur central, sauf en mode relais quand le NAT traversal échoue.

La vraie question qui détermine votre choix est donc : de qui dépend le control plane ?

Tailscale – le plus simple

Tailscale, c’est le leader. Le client s’installe en une commande, l’inscription se fait via Google/GitHub/etc., et en deux minutes votre Raspberry Pi et votre laptop se parlent :

curl -fsSL https://tailscale.com/install.sh | sh
tailscale up
  • MagicDNS : vos machines se joignent par nom (raspberry.tailnet-xyz.ts.net), plus besoin de retenir des IP.
  • Subnet routing : une machine peut exposer tout un sous-réseau local (votre LAN entier devient accessible).
  • Exit nodes : routez le trafic d’un appareil via une autre machine (un mini-proxy VPN version 2026).
  • ACL et utilisateurs : gestion fine des accès, parfait pour la famille ou la petite équipe.

Le plan gratuit est très généreux (jusqu’à 3 utilisateurs et 100 appareils), et le client est open source et tourne partout.

Le bémol, et c’est LE sujet de débat chez les amateurs de self-hosted : le control plane est propriétaire et hébergé par Tailscale Inc. Vos clés publiques et vos métadonnées d’infrastructure vivent chez eux. Le chiffrement reste de votre côté, mais si un jour vous ne voulez plus dépendre du service (tarifs, changements de politique, panne), vous êtes bloqué.

Headscale – Tailscale en self-hosted

Headscale répond exactement à ce problème : c’est une implémentation open source du control plane de Tailscale, que vous hébergez sur votre serveur. Et le meilleur dans l’histoire : vous continuez à utiliser les clients Tailscale officiels, vous pointez simplement votre serveur dans la configuration du client.

  • Vos clés et vos données d’infrastructure restent chez vous.
  • Même ergonomie côté client que Tailscale.
  • Pas besoin d’ouvrir des ports sur chaque machine, l’NAT traversal fait le boulot.

Les limites : pas d’interface web officielle (il existe des UIs tierces comme headplane), l’installation est plus manuelle, certaines fonctionnalités avancées de Tailscale n’y sont pas, et le projet est maintenu par la communauté. C’est un projet d’admin, pour des admins — ce qui est probablement votre cas si vous lisez ce blog.

NetBird – la plateforme alternative 100% open source

NetBird (ex-WireTrustee) prend un chemin différent : plutôt que de recréer Tailscale, c’est une plateforme complète, open source, avec son propre client et son propre control plane que vous pouvez déployer chez vous via Docker.

  • Self-hosting complet et supporté : la doc propose un guide d’auto-hébergement officiel (management, signal, relay, base de données).
  • Interface d’administration web intégrée : gestion des pairs, groupes et politiques d’accès sans toucher aux fichiers de config.
  • Clients natifs pour Windows, macOS, Linux, Android et iOS.
  • STUN/TURN intégrés pour le NAT traversal, et une communauté très active sur GitHub.

Le projet est plus jeune que Tailscale et un peu moins « plug and play », mais si votre objectif est un mesh VPN open source avec une vraie UI d’administration que vous hébergez, c’est aujourd’hui le candidat le plus abouti.

Tableau comparatif

CritèreTailscaleHeadscaleNetBird
Control planeCloud propriétaireSelf-hosted (open source)Self-hostable (open source)
ClientOfficiel, tous OSClients Tailscale officielsNatif, tous OS
UI d’administrationOuiNon (UI tierce)Oui
MagicDNS / NAT traversalOuiOuiOui
Facilité d’installationTrès facileManuelleMoyenne (Docker)
Dépendance externeForteAucuneAucune
Tailscale vs Headscale vs NetBird

Cas d’usage dans un homelab

  • Accéder à son NAS ou ses serveurs depuis n’importe où : fini les règles firewall pourries et les ports ouverts sur Internet (on a vu dans les articles précédents pourquoi c’est une mauvaise idée).
  • Relier deux sites sans configurer un site-to-site OpenVPN complet : le subnet routing fait le lien en quelques minutes.
  • SSH sécurisé vers ses VPS : plus besoin de fermer/ouvrir le port 22, tout passe dans le mesh.
  • Gaming LAN entre amis : l’équivalent moderne de ce qu’on faisait avec OpenVPN pour les jeux en réseau local.

Mon avis

Comme souvent, il n’y a pas de mauvais choix, seulement des priorités :

  • Vous voulez que ça marche tout de suite, sans réfléchir ? → Tailscale. Le plan gratuit suffit largement pour un usage perso.
  • Vous aimez Tailscale mais pas la dépendance au cloud ? → Headscale, vos données restent chez vous.
  • Vous voulez une plateforme open source complète avec une UI d’admin auto-hébergée ? → NetBird.

Pour ma part, j’ai toujours préféré garder le contrôle de mon infra, donc la voie self-hosted (Headscale ou NetBird) me semble la plus cohérente avec l’esprit de ce blog. Mais je reconnais que Tailscale a rendu le mesh VPN accessible à tout le monde, et ça, c’est mériteux.

Liens utiles :

par ·0 Commentaires

Guide Complet des Différentes Configurations

Rapide explications sur les différentes architectures OpenVPN et leurs cas d’usage spécifiques.

Si vous ne le savez pas, OpenVPN est une technologie de VPN SSL, il n’est donc pas compatible avec de l’IPSEC par exemple. Cette distinction est importante car elle impacte directement les choix d’architecture et d’interopérabilité avec votre infrastructure existante.

On va donc connecter un client qui se trouve à l’intérieur de notre LAN à notre serveur OpenVPN. Cette connexion est bien-entendu cryptée (liste des algorithmes) et même notre firewall ne verra pas en clair le contenu du trafic à l’intérieur du tunnel. Il verra juste des connexions UDP (ou TCP suivant la configuration) vers notre serveur. C’est d’ailleurs un avantage majeur : le trafic VPN ressemble à du trafic classique et traverse plus facilement les firewalls restrictifs.

Passerelle Locale et Routage du Trafic

Suivant votre utilisation, vous avez la possibilité de rediriger tout le trafic vers votre tunnel VPN (redirect-gateway def1) ou bien uniquement le subnet spécifié.

Le choix de la méthode de routage dépend essentiellement de vos besoins :

  • Redirection totale : Tout le trafic du client passe par le tunnel. Idéal pour le télétravail ou l’utilisation d’un proxy VPN, mais peut impacter les performances si votre serveur VPN a une bande passante limitée.
  • Routage sélectif : Seuls certains sous-réseaux sont accessibles via le tunnel. Recommandé pour l’accès à des ressources spécifiques (serveurs internes, NAS, etc.) tout en conservant votre connexion internet normale pour le reste du trafic.

Cette configuration se définit côté serveur et peut être poussée automatiquement vers les clients lors de la connexion.

PKI vs Static Key : Choisir la Bonne Méthode d’Authentification

Suivant l’architecture que vous voulez, il est préférable de choisir la méthode d’authentification adéquate.

Static Key (Clé Statique)

Static key est à utiliser uniquement dans le cadre d’une architecture simple avec un seul client (site-to-site, ou client-to-server). Cette méthode présente l’avantage d’être rapide à mettre en place : une seule clé partagée entre le client et le serveur.

Avantages :

  • Configuration simplifiée
  • Mise en place rapide
  • Parfait pour les connexions point-à-point

Inconvénients :

  • Non scalable (un seul client possible)
  • Si la clé est compromise, tout le système est vulnérable
  • Pas de révocation possible sans reconfiguration complète

PKI (Public Key Infrastructure)

Le PKI est utilisé pour la connexion de plusieurs clients sur un même serveur. Cette infrastructure repose sur une autorité de certification (CA) qui émet des certificats pour chaque client.

Avantages :

  • Support de multiples clients simultanés
  • Révocation individuelle des certificats possible
  • Meilleure sécurité globale
  • Possibilité d’ajouter de l’authentification additionnelle (login/password, 2FA)

Inconvénients :

  • Configuration initiale plus complexe
  • Gestion des certificats nécessaire (renouvellement, révocation)

Plus d’info dans la doc

Cas d’Utilisation OpenVPN

Connexion Inter-Site (Site-to-Site)

Si vous avez deux sites géographiques distincts que vous voulez relier au sein du même réseau, il vous est possible de créer une passerelle sur chaque site. Vous pourrez alors utiliser une clé statique entre les deux routeurs/firewall/PC.

Cette configuration permet de faire communiquer deux réseaux locaux comme s’ils étaient physiquement connectés. Par exemple, vos bureaux de Paris et Lyon pourront partager des ressources (imprimantes, serveurs de fichiers, Active Directory) de manière transparente.

Points d’attention :

  • Assurez-vous que les plages IP des deux sites ne se chevauchent pas
  • Configurez correctement les routes sur chaque passerelle
  • Prévoyez une solution de secours en cas de panne du tunnel
  • Documentez bien votre architecture réseau

Si vous recherchez une solution software gratuite pour mettre en place ce lien sans trop de difficulté je vous recommande pfSense (Compatible OVPN et IPSEC). D’autres routeurs modernes intègrent pour la plupart des technologies VPN (Ubiquiti, MikroTik, Cisco, Fortinet, etc.).

N’oubliez pas de considérer l’étude d’une solution IPSEC plutôt que VPN SSL. Dans le cas présent, l’IPSEC est peut-être un peu mieux adéquat pour des connexions site-to-site permanentes, notamment en termes de performances et de compatibilité avec du matériel réseau professionnel.

Proxy et Navigation Anonyme

De nombreux services proposent une offre VPN afin de surfer anonymement. Le trafic qui sort du tunnel est par contre en clair, il faut donc éviter de laisser passer des choses trop sensibles (ou bien avoir confiance en votre fournisseur).

Dans ce scénario, votre client se connecte à un serveur VPN distant, et tout votre trafic internet passe par ce serveur. Votre FAI ne voit que la connexion cryptée vers le serveur VPN, pas les sites que vous visitez.

Cas d’usage :

  • Contourner des restrictions géographiques
  • Masquer votre activité à votre FAI
  • Sécuriser votre connexion sur des réseaux WiFi publics
  • Protéger votre IP réelle

Vous pouvez toujours héberger votre petit serveur OpenVPN sur un serveur dédié par exemple, vous aurez ainsi le contrôle sur toutes les informations qui transitent. C’est une alternative intéressante aux services VPN commerciaux, surtout si vous avez déjà un VPS ou un serveur dédié à disposition.

Attention : Un VPN ne vous rend pas totalement anonyme. Les sites visités voient toujours l’IP de sortie du VPN, et le fournisseur du serveur VPN peut techniquement logger votre activité.

Jeux LAN et Gaming

Si vous connectez vos amis à votre réseau VPN, vous pourrez ainsi jouer à des parties « locales ». Utile pour remplacer Evolve, Hamachi ou tout autre logiciel équivalent – et ainsi garder le contrôle et assurer un minimum de performances.

Cette configuration crée un réseau local virtuel entre plusieurs joueurs distants géographiquement. Les jeux qui supportent uniquement le multijoueur LAN deviennent alors jouables en ligne.

Avantages :

  • Pas de dépendance à un service tiers qui peut fermer
  • Contrôle total sur qui se connecte
  • Possibilité d’optimiser les performances
  • Pas de limitation artificielle du nombre de joueurs

Configuration recommandée :

  • Utilisez UDP pour de meilleures performances en jeu
  • Ajustez le MTU pour éviter la fragmentation des paquets
  • Privilégiez un serveur avec une bonne connexion et proche géographiquement de tous les joueurs
  • Utilisez la compression seulement si nécessaire (peut ajouter de la latence)

Administration et Accès à Distance

Suivant les besoins, vous pourrez donner accès à certains périphériques de votre réseau pour qu’ils soient accessibles depuis un autre ordinateur dans un autre réseau.

Par exemple : J’ai un NAS à la maison, j’aimerais pouvoir l’administrer et avoir accès aux données présentes dessus quand je suis au boulot ou en voyage. Si le NAS a un client OVPN intégré c’est encore plus facile…

Cette utilisation est probablement l’une des plus courantes pour les particuliers et les petites structures. Elle permet de :

  • Accéder à vos fichiers personnels de manière sécurisée
  • Administrer vos serveurs et équipements réseau à distance
  • Utiliser des services internes (serveurs de développement, domotique, caméras de surveillance)
  • Éviter d’exposer directement vos services sur internet

Bonnes pratiques :

  • N’exposez que les ressources strictement nécessaires
  • Utilisez le routage sélectif plutôt que la redirection totale
  • Mettez en place une authentification forte (certificats + login/password)
  • Configurez des règles de firewall restrictives même au sein du VPN
  • Surveillez les logs de connexion régulièrement
  • Pensez à renouveler les certificats avant expiration

Protocoles et Ports : TCP vs UDP

OpenVPN peut fonctionner sur TCP ou UDP. Le choix a un impact significatif sur les performances et la fiabilité :

UDP (recommandé par défaut) :

  • Meilleures performances globales
  • Latence plus faible
  • Idéal pour le streaming, VoIP, jeux
  • Peut être bloqué par certains firewalls restrictifs

TCP (mode fallback) :

  • Plus fiable sur des connexions instables
  • Traverse mieux les firewalls et proxies
  • Peut utiliser le port 443 pour se faire passer pour du HTTPS
  • Performances réduites (double TCP overhead)

Considérations de Sécurité

Quelques recommandations pour sécuriser votre installation OpenVPN :

  • Utilisez des algorithmes de chiffrement modernes (AES-256-GCM recommandé)
  • Activez TLS-Auth ou TLS-Crypt pour prévenir les attaques DoS et l’analyse de trafic
  • Configurez des certificats avec une durée de validité limitée
  • Mettez en place une CRL (Certificate Revocation List) fonctionnelle
  • Isolez le serveur VPN dans une DMZ si possible
  • Limitez les privilèges du processus OpenVPN (user/group nobody)
  • Gardez votre installation à jour (patch de sécurité)
  • Loggez les connexions pour détecter des accès suspects

Conclusion

OpenVPN est une solution VPN flexible et puissante qui s’adapte à de nombreux cas d’usage. Le choix de l’architecture dépend principalement de vos besoins : nombre de clients, permanence de la connexion, niveau de sécurité requis, et compétences techniques disponibles.

Pour débuter, une installation simple avec quelques clients en PKI est un bon compromis entre sécurité et facilité de gestion. Vous pourrez ensuite faire évoluer votre architecture au fur et à mesure de vos besoins.

par ·0 Commentaires

Bon, on ne va pas plus présenter Tor…

Savez-vous qu’il est possible d’héberger des services uniquement accessibles depuis ce réseau ? Ces services cachés, appelés « Hidden Services » ou services onion, offrent une couche d’anonymat supplémentaire tant pour l’hébergeur que pour les visiteurs.

Configuration d’un Hidden Service

Oui, il faut configurer Tor avec les bons paramètres – voici un exemple pour un serveur web :

HiddenServiceDir /var/lib/tor/hidden_service/http
HiddenServicePort 80 127.0.0.1:80

Le paramètre HiddenServiceDir spécifie le répertoire où Tor stockera les clés et l’adresse .onion de votre service. Le paramètre HiddenServicePort définit le port externe (80 dans cet exemple) et redirige le trafic vers votre service local (ici 127.0.0.1:80).

Puis configurer notre service Apache ou Nginx pour qu’il écoute sur localhost, redémarrer le service Tor et hop, on a un site web uniquement accessible depuis le réseau Tor. L’adresse .onion générée se trouve dans le fichier hostname du répertoire défini par HiddenServiceDir.

Pas trop dur… On peut aussi faire de même pour d’autres services (IRC, XMPP, serveur de fichiers…). Il suffit d’adapter le port et l’adresse locale du service concerné.

Sécuriser son serveur

Et oui, grâce à Tor, il est possible de sécuriser son serveur. Je m’explique :

Imaginons que nous administrons à distance (via SSH) un serveur. D’ordinaire, on est obligé d’ouvrir le port 22 depuis tout Internet, ce qui expose notre serveur aux tentatives de connexion malveillantes, aux scans de ports et aux attaques automatisées. Ici, on va créer un service caché SSH, on pourra ainsi éviter les robots brute-force et autres scripts. Pour se connecter à notre serveur, il faudra être connecté au réseau Tor (il faut déjà le savoir), connaître l’adresse onion du serveur (vas-y pour le brute-force – une adresse en 56 caractères aléatoires pour les services v3) et bien entendu les autres mécanismes de sécurité liés au service SSH (PAM, clé RSA,…).

Configuration pour un Hidden Service SSH :

HiddenServiceDir /var/lib/tor/hidden_service/ssh
HiddenServicePort 22 127.0.0.1:22

Donc pas de DDNS ni de configuration firewall de dingue (juste le deny). Votre serveur devient pratiquement invisible depuis Internet classique, tout en restant accessible pour vous via Tor.

Pour vous connecter ensuite, il suffit d’utiliser SSH via Tor avec la commande suivante :

ssh -o ProxyCommand="nc -X 5 -x 127.0.0.1:9050 %h %p" user@votre-adresse.onion

Ou de configurer torify :

torify ssh user@votre-adresse.onion

Plus d’infos

Firewall

Il n’y a pas de configuration spéciale du firewall à faire. C’est le service Tor qui contacte (output) le réseau. On peut ainsi rejeter toutes les connexions inconnues entrantes (input).

Exemple de règles iptables minimalistes :

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Voilà, vous disposez d’un serveur sécurisé dont l’adresse IP réelle reste cachée, protégé des scans et attaques automatisées. Les services ne sont accessibles que via le réseau Tor, offrant une couche de sécurité par l’obscurité (en complément des autres mesures, pas en remplacement).

Avantages des Hidden Services

Les avantages sont multiples : anonymat de l’hébergeur, protection contre les attaques DDoS ciblées sur l’IP, contournement de la censure, et simplicité de mise en place. Pas besoin d’adresse IP fixe, pas de nom de domaine à acheter, pas de certificat SSL à configurer (le chiffrement est assuré par Tor).

Évidemment, cette approche a aussi ses limites : dépendance au réseau Tor, latence plus élevée, et nécessité pour les utilisateurs d’utiliser le navigateur Tor ou de configurer leur client.