VPN auto-hébergé sur un VPS : WireGuard en dix minutes, et la confidentialité qu'il vous apporte réellement

Ce qu'un VPN fait réellement — et la phrase que la plupart des explications esquivent

Un VPN chiffre votre trafic et l'envoie à un serveur, qui le déchiffre et le retransmet. La conséquence n'est pas que votre trafic devient invisible. C'est que l'ensemble des personnes capables de le voir change. Avant : le Wi-Fi du café, l'hôtel, l'opérateur mobile, votre FAI domestique, et le middlebox national qui les surplombe — tous voient quels sites vous atteignez et à peu près ce que vous y faites. Après : ils voient un seul flux chiffré de longue durée vers une seule adresse, et rien de ce qu'il contient. En échange, le réseau sur lequel se trouve votre serveur occupe désormais la position qu'ils viennent d'abandonner.

C'est là tout le mécanisme, et il vaut la peine d'être direct à ce sujet, car la version marketing — « devenez invisible en ligne » — pousse à attendre une protection que le dispositif n'offre pas. Un VPN change votre point d'observation. Que cela vous aide dépend entièrement de la question de savoir si le nouveau point d'observation vaut mieux que l'ancien pour le problème précis qui vous préoccupe. Déplacer l'observateur d'un réseau d'hôtel dont vous n'avez jamais entendu parler vers un centre de données que vous avez choisi, dans un pays que vous avez choisi, faisant tourner un logiciel que vous avez configuré, est en général un très bon échange. Le déplacer de votre FAI domestique vers une société qui fait de la publicité dans des podcasts est un échange différent, et moins évident.

L'auto-hébergement ne change que la seconde moitié de cette phrase, rien d'autre. La cryptographie est identique — le document de conception de WireGuard décrit le même handshake, que le pair soit le vôtre ou celui d'un fournisseur. Ce qui change, c'est qui détient la clé privée à l'autre bout, qui pourrait journaliser s'il le voulait, l'existence ou non d'une base de clients, et qui d'autre partage votre adresse de sortie. Ces quatre différences constituent l'intégralité des arguments pour et contre l'auto-hébergement, et ils ne vont pas tous dans le même sens.

Votre propre sortie ou une sortie commerciale : l'échange que vous faites réellement

Le réflexe est de considérer l'auto-hébergement comme l'option strictement la plus privée, et pour la plupart des modèles de menace, c'est vrai. Il n'y a aucun fournisseur détenant une fiche de compte, aucune infrastructure partagée susceptible d'être saisie à cause du compte de quelqu'un d'autre, aucune politique de confidentialité à croire sur parole, et aucune possibilité de changement de journalisation dont vous n'auriez pas été informé. Vous détenez la clé. Personne n'a besoin d'être digne de confiance, parce que personne n'est en position de vous trahir.

Mais il existe une dimension où un VPN commercial l'emporte nettement, et ce n'est pas un détail. Leur adresse de sortie est partagée par des centaines, voire des milliers de personnes à la fois, si bien qu'un site web recevant une requête depuis celle-ci n'apprend presque rien sur laquelle de ces personnes l'a envoyée. Votre adresse de sortie n'est partagée que par vous. Elle est stable, elle appartient à un seul client, et chaque site que vous visitez à travers elle voit le même identifiant — exactement comme une adresse IP domestique, seulement dans un autre pays. Si ce que vous cherchez, c'est disparaître dans une foule, une foule d'une seule personne n'y parvient pas.

Lisez ce tableau comme deux questions distinctes plutôt que comme un score unique. Si votre adversaire est le réseau sur lequel vous vous trouvez — un FAI qui revend des données de navigation, un employeur qui inspecte le TLS, un café, un hôtel, un pare-feu censeur — l'auto-hébergement l'emporte sur tous les points qui comptent, parce que ce dont vous vous cachez se trouve en amont du tunnel et ne peut pas voir à travers. Si votre adversaire est le site que vous visitez, cherchant à relier la session d'aujourd'hui à celle du mois dernier, alors c'est la foule qui protège, et une sortie privée est pire qu'inutile. Très peu de personnes sont réellement dans le second cas, et la plupart de celles qui le sont devraient lire ce qui concerne Tor plutôt que les VPN.

Si les gens confondent les deux, c'est que l'industrie vend un seul produit sous ces deux descriptions. Le seul argument réel et défendable d'un VPN commercial, c'est la foule. Tout le reste du discours commercial — la promesse de zéro journalisation, les audits, la juridiction d'incorporation — est une tentative de compenser le fait que vous confiez votre trafic à une entreprise. L'auto-hébergement supprime l'entreprise. Il ne peut pas fabriquer une foule.

Quand l'auto-hébergement est la bonne réponse

Le cas le plus net est celui d'un réseau que vous ne contrôlez pas et auquel vous ne pouvez pas faire confiance. Wi-Fi de conférence, hôtels, aéroports, connexion partagée d'un propriétaire, itinérance mobile dans un pays au régime d'interception légale agressif. Dans tous ces cas, la menace est locale et passive, et un tunnel vers n'importe où ailleurs l'élimine complètement. Que ce soit le cas d'usage le moins glamour ne le rend pas le moins précieux — c'est celui qui s'applique à presque tout le monde, presque chaque semaine.

Le deuxième est la juridiction. Un tunnel qui sort à Zurich signifie que le trafic qui en sort relève du droit suisse, transite par un opérateur suisse, et échappe au régime qui gouverne votre propre connexion. Ce n'est pas une abstraction pour les habitants de pays où le FAI est tenu de conserver et de transmettre les historiques de navigation. Choisir délibérément le pays de sortie est l'une des rares décisions de confidentialité à l'effet net et lisible, et il vaut la peine de lire la comparaison des juridictions avant de déployer plutôt qu'après.

Le troisième est la censure. Les pare-feu nationaux bloquent les VPN commerciaux en recensant leurs plages d'adresses, ce qui est facile puisque ces plages sont publiées, vendues et massivement utilisées. Une adresse de VPS isolée dans un réseau d'hébergement ne figure sur aucune liste de ce genre — non par ruse, mais parce que personne n'a de raison de l'avoir cataloguée. C'est pourquoi les dispositifs de contournement les plus fiables ont toujours été petits et personnels plutôt que gros et commerciaux, et c'est le seul endroit où la foule devient franchement un handicap.

Le quatrième, c'est que vous voulez une sortie stable, propre et maîtrisable pour autre chose que la navigation : joindre un labo domestique depuis l'extérieur, donner à une petite équipe l'accès à des services internes sans les exposer, faire tourner un service qui a besoin d'une adresse source prévisible, ou maintenir une session de longue durée sur une adresse qui ne changera pas sous vos pieds. Ce sont des problèmes d'ingénierie réseau qu'un VPN commercial ne peut absolument pas résoudre, et qu'un VPS à $8.50 résout en une après-midi. La page dédiée à la charge de travail VPN couvre le dimensionnement et les spécificités réseau.

Et l'argument contre : si vous n'êtes pas capable de maintenir un serveur à jour, n'en faites pas tourner un. Un VPS non maintenu avec un port SSH ouvert produit un résultat pire pour votre vie privée que n'importe quel VPN commercial, parce qu'une sortie compromise voit tout et répond à quelqu'un d'autre. L'auto-hébergement échange un problème de confiance contre un problème d'exploitation. C'est un bon échange seulement si vous assurez réellement cette exploitation, ce que la dernière section de ce guide ramène à environ dix minutes par mois.

WireGuard en dix minutes : la configuration complète

WireGuard est assez petit pour se lire d'un bout à l'autre. Il vit dans le noyau Linux, ne parle qu'un seul port UDP, utilise un jeu fixe et unique de primitives modernes sans négociation, et toute sa surface de configuration tient en deux types de bloc : un [Interface] décrivant cette machine, et un [Peer] par appareil autorisé à se connecter. Il n'y a ni autorité de certification, ni suite cryptographique à mal choisir, ni démon à régler. Ce minimalisme est la raison pour laquelle il est difficile de le mal configurer dangereusement, et la raison pour laquelle il a remplacé les alternatives presque partout.

Commencez par installer le paquet et générer une paire de clés. Réglez d'abord umask 077 pour que la clé privée ne soit pas écrite lisible par tous — wg-quick se plaindra bruyamment si c'est le cas, et il a raison de le faire. wg genkey produit la clé privée, wg pubkey en dérive la moitié publique. Faites de même sur chaque client. Les clés publiques s'échangent ; les clés privées ne quittent jamais la machine qui les a générées.

Rédigez ensuite /etc/wireguard/wg0.conf. Le tableau ci-dessous est le fichier complet d'un serveur fonctionnel — rien n'est omis par souci de concision.

Deux choses en dehors du fichier doivent également être vraies. Le noyau doit accepter de router : réglez net.ipv4.ip_forward=1 et net.ipv6.conf.all.forwarding=1, et écrivez-les dans /etc/sysctl.d/ pour qu'ils survivent à un redémarrage. Et la règle NAT dans PostUp doit nommer la véritable interface publique — sur la plupart des images cloud, c'est eth0, mais vérifiez avec ip route get 1.1.1.1 plutôt que de le supposer. Un mauvais nom d'interface est de loin la raison la plus courante pour laquelle une première installation de WireGuard se connecte puis ne mène nulle part.

Activez-la avec wg-quick up wg0, confirmez avec wg show que l'interface existe et liste vos pairs, puis systemctl enable --now wg-quick@wg0 pour qu'elle revienne après un redémarrage. Côté client, le fichier est presque identique, à trois différences près qui comptent : AllowedIPs devient 0.0.0.0/0, ::/0 — ce qui signifie faites tout passer par ici plutôt que acceptez ces sources — une ligne Endpoint pointe vers l'adresse publique et le port du serveur, et PersistentKeepalive = 25 maintient l'association vivante à travers les routeurs domestiques qui la laisseraient sinon expirer. Pour les téléphones, passez la configuration client dans qrencode -t ansiutf8 et scannez-la depuis le terminal. N'envoyez pas les fichiers de configuration via une appli de messagerie ; la clé privée s'y trouve.

Les quatre fuites qui contournent le tunnel

Un tunnel qui transporte du trafic n'est pas la même chose qu'un tunnel qui transporte tout le trafic, et c'est dans l'écart entre les deux que vivent tous les échecs réels de VPN. Chacun des quatre cas ci-dessous est une situation où le tunnel fonctionne parfaitement tout en étant contourné par votre trafic, et aucun ne se signale de lui-même. Il faut aller vérifier.

DNS. Si le client continue d'utiliser le résolveur distribué par le réseau local, le tunnel transporte votre trafic pendant que le serveur DHCP du café continue de recevoir en direct chaque domaine que vous consultez. Les noms de domaine, à eux seuls, donnent presque toute l'image. Corrigez cela en réglant une ligne DNS = explicite dans la configuration client, ou mieux, faites tourner un résolveur sur le VPS lié à l'adresse du tunnel et pointez les clients vers lui — les résolutions traversent alors elles aussi le tunnel et se terminent sur une machine qui vous appartient. Vérifiez depuis le client, pas depuis le serveur, avec n'importe quel test de fuite DNS ; vous devez voir exactement un résolveur, et ce doit être le vôtre.

IPv6. Le classique échec silencieux. Si AllowedIPs ne contient que 0.0.0.0/0 côté client, vous avez dit au système d'exploitation de router l'IPv4 dans le tunnel, sans rien dire de l'IPv6. Sur un réseau dual-stack — ce qui décrit désormais la plupart des réseaux domestiques et mobiles — chaque site possédant un enregistrement AAAA est atteint via votre adresse réelle, en dehors du tunnel, pendant qu'un test de fuite qui ne vérifie que la v4 affiche que tout va bien. Il faut soit ajouter ::/0 et distribuer des adresses v6 dans le tunnel, soit carrément désactiver l'IPv6 côté client. Ne rien faire des deux, c'est la configuration par défaut, et cette configuration par défaut est cassée.

L'absence de kill switch. Quand le tunnel tombe — l'ordinateur portable se met en veille, le mobile bascule d'une antenne à l'autre, le serveur redémarre pour une mise à jour du noyau — le système d'exploitation fait ce qu'il croit utile et retombe sur le réseau local. Le trafic que vous pensiez tunnellisé ne l'est plus, et rien ne vous prévient. Sous Linux, wg-quick avec la table de routage par défaut échoue déjà en mode fermé pour la plupart du trafic, mais la correction fiable est une règle de pare-feu explicite qui rejette tout ce qui ne sort pas par wg0. Sur Android et iOS, activez VPN permanent et Bloquer les connexions sans VPN. Sur les clients de bureau, vérifiez que le réglage existe avant de le supposer.

MTU. Ce n'est pas une fuite de confidentialité, mais c'est la raison pour laquelle les gens abandonnent. L'encapsulation de WireGuard coûte 60 octets pour IPv4 et 80 pour IPv6, si bien que le MTU d'interface par défaut de 1420 tient dans un chemin normal de 1500 octets. Sur PPPoE, certains réseaux mobiles, ou un second tunnel, le chemin réel est plus étroit, et le symptôme est étrange : les pings passent, les petites pages chargent, et les gros handshakes TLS restent bloqués indéfiniment. Si cela décrit ce que vous observez, faites baisser le MTU du client à 1380 ou 1280, et cela se remettra simplement à fonctionner.

Il y a une chose qu'un VPN ne peut pas corriger, et il vaut la peine de le dire pour que vous n'en attendiez pas plus : un observateur capable de surveiller les deux extrémités à la fois peut les corréler par le rythme et le volume, tunnel ou pas. Le chiffrement cache le contenu, pas la forme d'une conversation. Se défendre contre cet adversaire exige de mélanger votre trafic avec celui d'autres personnes à travers plusieurs relais, ce à quoi sert Tor et ce qu'un VPN à saut unique n'est structurellement pas. Si c'est votre modèle de menace, un VPN auto-hébergé est le mauvais outil, et aucune configuration ne le rendra bon.

Faire en sorte que l'adresse de sortie se comporte bien dans la nature

L'adresse depuis laquelle sort votre tunnel appartient à un réseau d'hébergement, et une grande partie du web moderne classe les adresses en résidentielles et datacenter avant de décider comment vous traiter. Les catalogues de streaming, certaines banques, les sites de billetterie et une bonne partie des outils anti-fraude traitent par défaut tout ce qui vient d'un réseau d'hébergement comme suspect. Ce n'est pas quelque chose qu'un changement de configuration corrige — c'est une propriété de l'endroit où vit le serveur, et cela s'applique aussi bien à un tunnel auto-hébergé qu'à n'importe quel VPN commercial du marché. Quiconque promet le contraire décrit un jeu du chat et de la souris qu'il est en train de perdre.

Ce qui diffère, en revanche, c'est sur quelles listes votre adresse apparaît. Les plages des VPN commerciaux sont recensées, publiées et vendues sous forme de flux précisément parce qu'elles sont grandes, statiques et partagées ; un site qui veut bloquer les VPN achète la liste. Une adresse isolée dans un réseau d'hébergement généraliste n'y figure pas. En pratique, cela signifie que les sorties auto-hébergées traversent sans encombre une part surprenante du web ordinaire qui bloque purement et simplement les fournisseurs commerciaux, tout en se heurtant encore aux services spécifiques qui bloquent tout le trafic datacenter. Attendez-vous à un CAPTCHA supplémentaire de temps en temps, rien de plus.

Quelques réglages valent la peine d'être faits une bonne fois pour toutes. Configurez un enregistrement de reverse DNS simple et sans intérêt sur l'adresse plutôt que de laisser celui du fournisseur — de nombreux systèmes de réputation lisent le PTR, et un nom d'hôte générique obtient un meilleur score que quelque chose qui sonne comme de l'infrastructure. Gardez le tunnel entièrement à l'écart du port 25 ; le courrier sortant depuis une adresse d'hébergement toute neuve atterrit dans les dossiers spam quoi que vous fassiez, et le problème de délivrabilité est un projet à part entière de plusieurs semaines. Et si l'adresse finit malgré tout par être grillée — héritée d'un précédent locataire, ou à cause de quelque chose qu'a fait l'un de vos propres pairs — demandez une réaffectation d'adresse plutôt que de vous battre contre elle. Nous réaffectons nos clients vers une nouvelle adresse dans le même préfixe, sans frais ; ouvrez un ticket dans le panneau et c'est fait en moins d'une journée.

La dernière considération, c'est qui d'autre se trouve derrière votre tunnel. Puisque tous les pairs partagent une seule adresse de sortie, le comportement d'une personne devient la réputation de tout le monde. Un foyer, aucun problème. Un groupe de vingt connaissances dont vous ignorez ce que fait la moitié, c'est exactement comme cela qu'une adresse propre devient une adresse bloquée, et qu'un signalement d'abus arrive avec le nom de votre compte dessus. Si vous distribuez des accès au-delà des personnes dont vous répondriez personnellement, donnez-leur plutôt leur propre instance — à $8.50 par mois, c'est une réponse moins coûteuse que l'alternative.

La couche que personne ne configure : comment vous avez payé la machine

Voici l'échec qui annule tout ce qui précède, et il n'a rien à voir avec WireGuard. Le trafic quitte votre adresse de sortie. L'adresse appartient à un serveur. Le serveur appartient à un compte. Le compte a été ouvert avec une adresse e-mail et payé avec une carte à votre nom. À ce stade, la chaîne qui relie le trafic jusqu'à vous compte quatre sauts, elle est entièrement documentée et repose dans la base de données de facturation d'un fournisseur, en attendant que quelqu'un vienne la consulter. Vous n'avez pas supprimé un observateur ; vous l'avez déplacé vers un endroit qui tient de meilleurs registres.

C'est là toute la différence entre un VPN qui change votre position réseau et un VPN qui change votre exposition, et elle se joue au moment du paiement, pas dans le fichier de configuration. Si la raison pour laquelle vous voulez une sortie privée est que votre FAI ou votre gouvernement ne devrait pas avoir accès à votre historique de navigation, et que le serveur est loué sous votre identité légale via un paiement par carte, le montage fonctionne quand même — le FAI ne peut effectivement pas voir à travers le tunnel. Mais c'est une amélioration de confidentialité contre un observateur précis, pas contre un adversaire déterminé. Sachez clairement lequel des deux vous achetez.

Combler cet écart suppose que ni le compte ni le paiement ne puissent vous identifier. Cela signifie aucune vérification d'identité à l'inscription — une adresse e-mail jetable et rien d'autre, ce que l'hébergement sans KYC signifie réellement en pratique — et un paiement passant par un canal qui ne porte pas votre nom. Monero est la réponse la plus nette, car les montants et les parties ne figurent sur aucun registre public ; le tutoriel prend environ cinq minutes de bout en bout. Bitcoin fonctionne, mais constitue un registre public permanent, donc il n'est privé qu'à la mesure des pièces qui y entrent, et la comparaison entre les deux vaut la peine d'être lue avant de décider que cela n'a pas d'importance.

Vient ensuite la juridiction, qui détermine ce que n'importe qui pourrait exiger même s'il le demandait. Un fournisseur incorporé hors de la sphère des 14-Eyes, avec des centres de données dans des pays dont le droit de rétention n'impose pas de conserver les journaux de trafic, est structurellement incapable de transmettre un historique de navigation qu'il n'a jamais collecté. C'est une garantie plus solide qu'une promesse de ne pas regarder. Pour la version complète de cet argument — ce qui est réellement traçable dans un serveur loué, et ce qui ne l'est pas — la réponse honnête se trouve ici, y compris les parties moins rassurantes que le discours marketing.

Dimensionnement : de combien de serveur un tunnel a vraiment besoin

WireGuard coûte remarquablement peu cher à faire tourner. Il vit dans le noyau, si bien que les paquets ne sont jamais recopiés vers l'espace utilisateur ; il utilise ChaCha20-Poly1305, rapide sur n'importe quel CPU et qui n'a pas besoin d'accélération AES pour le rester ; et il ne conserve que quelques kilo-octets d'état par pair, rien de plus. Un seul cœur moderne pousse environ un gigabit de débit chiffré, et la mémoire n'est pratiquement jamais la contrainte. Sur un tunnel hébergé sur un VPS, la limite pratique, c'est l'uplink, pas le processeur.

Ce qui signifie que la plupart des gens choisissent leur offre pour la mauvaise raison. Un foyer de cinq appareils qui naviguent, streament et passent des appels vidéo toute la journée reste très loin des limites du plus petit palier — le CPU reste inactif et la bande passante est illimitée. Montez en gamme quand vous avez beaucoup de pairs simultanés qui poussent du trafic réel en même temps, ou quand vous voulez plus de marge sur l'uplink, pas parce qu'un tunnel donne l'impression qu'il devrait être exigeant.

L'emplacement compte plus que le matériel dans la façon dont le tunnel se ressent. Chaque paquet que vous envoyez fait un détour par le serveur, si bien que votre latence vers n'importe quoi devient votre latence vers le serveur plus la latence du serveur en aval. Choisissez un centre de données proche de vous si le tunnel reste actif en permanence et que la réactivité vous importe ; choisissez-en un proche de ce que vous cherchez à atteindre si ce n'est pas le cas. Amsterdam offre le chemin le plus court vers la majeure partie de l'Europe, Zurich et Reykjavík échangent quelques millisecondes contre des juridictions au droit de la vie privée plus solide, et Bucarest se situe entre les deux sur ces deux plans.

Encore une chose à savoir avant de choisir : le handshake de WireGuard a une forme reconnaissable sur le fil, et un pare-feu pratiquant l'inspection profonde des paquets peut l'identifier et le rejeter sans rien savoir de la destination. Dans la majeure partie du monde, cela ne se pose jamais. Dans une poignée de réseaux, cela signifie que WireGuard seul ne se connectera pas, et qu'il vous faut un transport d'obfuscation devant lui — Shadowsocks, une pile xray ou v2ray, ou l'un des forks de WireGuard qui remplit le handshake de bourrage. Tous tournent sur la même instance ; c'est une couche ajoutée par-dessus, pas une offre différente.

Le faire tourner pendant des années sans y penser

La charge opérationnelle d'un point de terminaison WireGuard personnel est proche de zéro, mais pas tout à fait, et c'est cette différence qui sépare une sortie privée d'une sortie compromise. Tout ce qui suit se règle une bonne fois pour toutes, sauf le dernier point, qui demande environ dix minutes par mois.

Verrouillez d'abord la porte d'entrée. SSH par clés uniquement — PasswordAuthentication no, PermitRootLogin prohibit-password — et un pare-feu qui n'accepte exactement que deux choses depuis internet : le port UDP de WireGuard, et SSH. Pour aller au bout de la démarche, déplacez SSH pour qu'il n'écoute que sur l'adresse du tunnel, ce qui fait que le seul service joignable sur l'interface publique est WireGuard lui-même, et WireGuard ne répond à aucun paquet non authentifié. Un scan de ports de la machine ne renvoie alors rien, une propriété véritablement inhabituelle pour un serveur exposé sur internet.

Activez les mises à jour de sécurité automatiques et laissez-les tourner. Le noyau compte ici d'une manière qu'il ne compte pas sur la plupart des serveurs, parce que l'implémentation de WireGuard en fait partie. Redémarrez quand une mise à jour du noyau arrive ; wg-quick@wg0 sous systemd relève le tunnel tout seul, et les clients dotés de PersistentKeepalive se reconnectent en quelques secondes sans que personne n'y touche.

Traitez les clés comme des comptes, parce que c'est ce qu'elles sont. Une paire de clés par appareil, jamais partagée entre deux. Révoquer un accès consiste à supprimer ce bloc [Peer] et à exécuter wg syncconf wg0 <(wg-quick strip wg0), ce qui applique le changement sans couper la session de personne d'autre. Sauvegardez /etc/wireguard/ quelque part de chiffré et hors de la machine — le perdre signifie ré-enrôler chaque appareil à la main. Si le serveur héberge autre chose qui vous tient à cœur, le chiffrement intégral du disque est un ajout raisonnable, même si pour un tunnel pur, il y a très peu de choses sur le disque qui méritent d'être chiffrées en dehors de ce seul répertoire.

Surveillez sans journaliser. wg show vous donne l'heure du dernier handshake pour chaque pair, ce qui suffit à répondre à toutes les questions opérationnelles que vous vous poserez réellement — est-ce que ça tourne, cet appareil est-il connecté, quand s'est-il connecté pour la dernière fois. Résistez à la tentation d'ajouter une comptabilisation du trafic ou des journaux de connexion : vous avez construit tout ceci précisément pour que personne ne détienne de trace de la destination de votre trafic, et la personne la plus susceptible de créer cette trace, c'est désormais vous. De notre côté, il n'y a rien à désactiver — aucun netflow, aucun port mirroring, aucune capture de trafic d'aucune sorte, et des tables ARP qui expirent en 24 heures, ce qui est documenté sur la page de confidentialité plutôt que promis en bas de page.

C'est tout le travail. Quinze lignes de configuration, un pare-feu, des mises à jour de sécurité programmées, et un coup d'œil mensuel à wg show. La partie difficile d'un VPN auto-hébergé n'a jamais été le VPN — c'est de se rappeler que le tunnel ne fait que déplacer l'observateur, et que toute la valeur de ce déplacement dépend du fait que les quatre fuites ci-dessus soient bien colmatées et que le compte qui se trouve derrière ne remonte pas jusqu'à vous.