Guide
Configurer un VPN sous Linux
Le client du fournisseur depuis son propre dépôt, l'alternative d'un fichier de configuration dans les outils du système, le détail DNS qui fuit davantage sous Linux que partout ailleurs, et les vérifications depuis un terminal. Rédigé pour Ubuntu 26.04 LTS et NetworkManager.
Avant de commencer
Ce guide ne choisit pas à votre place
Toutes les étapes ci-dessous sont les mêmes, quel que soit le fournisseur utilisé, raison pour laquelle aucun n'est nommé ici. Le choix est une tâche distincte, qui se fait dans le registre, où il repose sur un score publié et non sur une page de téléchargement.
Installez le client depuis le dépôt du fournisseur, avec la clé de signature fournie dans ses propres instructions. Ne collez jamais dans un terminal une commande d'installation en une ligne trouvée sur un forum ou un blog : la commande s'exécute en tant que root et vous n'avez aucune idée de ce qu'elle a récupéré. Un paquet provenant d'un dépôt signé peut être vérifié ; un script redirigé vers un shell, non.
Installer le client
Deux voies existent sous Linux, et toutes deux sont légitimes. Le client du fournisseur est la première : il apporte un kill switch, un sélecteur de serveur et la gestion du DNS sans configuration supplémentaire. Un fichier de configuration dans les outils du système est la seconde ; la dernière section de ce guide précise ce qu'elle coûte.
- Connectez-vous au site du fournisseur et ouvrez ses instructions Linux depuis l'espace du compte. Elles indiquent le dépôt, la clé et le paquet ; suivez-les, et rien d'autre.
- Ajoutez le dépôt et sa clé, puis installez le paquet avec le gestionnaire de paquets de la distribution. La clé permet au gestionnaire de paquets de refuser un paquet altéré ; un dépôt ajouté sans elle est donc un dépôt auquel vous avez décidé de faire confiance.
- Activez le service du client pour qu'il démarre au démarrage. Un client est généralement composé d'un démon root et d'une application de bureau qui lui parle ; le démon gère le tunnel, et un kill switch qui doit être actif dès le démarrage a besoin que le démon le soit aussi.
- Connectez-vous au client — depuis l'application ou depuis la ligne de commande avec le jeton fourni par l'espace du compte — et donnez à l'appareil un nom qui ne permette pas de vous identifier.
- Ne vous connectez pas encore. Ouvrez d'abord les paramètres. Deux des trois paramètres ci-dessous sont désactivés par défaut dans la plupart des clients.
Les trois paramètres à vérifier
Les menus des clients diffèrent, pas les paramètres. Chacun des trois possède une entrée dans le glossaire si son nom ne vous est pas familier.
Le kill switch
Il bloque tout le trafic si le tunnel tombe, au lieu de laisser discrètement la connexion revenir au réseau ordinaire. Sous Linux, il s'agit d'un ensemble de règles de pare-feu écrites par le client : tout ce qui n'est pas l'interface du tunnel ou le propre point de terminaison du tunnel est bloqué. Activez-le et choisissez la forme toujours active ou lockdown lorsque le client la propose, afin que les règles soient appliquées dès le démarrage et pas seulement pendant la connexion. Le rôle du switch est expliqué sur sa propre page.
Le DNS dans le tunnel
Les requêtes de noms peuvent quitter la machine en dehors du tunnel même lorsque tout le reste y passe, et sous Linux c'est la fuite la plus fréquente, car le résolveur est un élément mobile. Sous Ubuntu, cet élément est systemd-resolved : chaque interface possède ses propres résolveurs, et celui qui dispose de la route par défaut pour le DNS répond à tout ce qui ne correspond pas à un domaine plus spécifique. Le client devrait diriger cette route par défaut vers le résolveur du fournisseur, via l'interface du tunnel. Configurez le DNS du client sur celui du fournisseur, et non sur celui d'un tiers ; la seconde partie qui ne voit que les requêtes est une partie de plus. Le fonctionnement d'une fuite est expliqué sur la page consacrée aux fuites DNS.
Le protocole
Laissez le protocole moderne par défaut, sauf si quelque chose ne fonctionne pas — la page des protocoles indique lesquels sont actuels et lesquels sont anciens. Si le client propose une option plus ancienne pour résoudre un problème de connexion, faites ce compromis en connaissance de cause, puis annulez-le : le registre marque le protocole le plus faible qu'un fournisseur propose encore, et le sélectionner manuellement revient à choisir ce marquage pour vous-même.
Confirmer que tout fonctionne réellement
Connectez-vous, puis vérifiez au lieu de supposer. Voici trois vérifications à effectuer depuis un terminal, dans cet ordre :
- Votre adresse a changé. Utilisez
curlavec un service « quelle est mon adresse IP ? », ou ouvrez-en un dans le navigateur, et vérifiez que le pays correspond à la sortie choisie.ip route getvers une adresse publique devrait indiquer l'interface du tunnel, et non celle du Wi-Fi ou de l'Ethernet. - Les requêtes passent dans le tunnel. Avec
resolvectl status, vérifiez que l'interface du tunnel porte le résolveur du fournisseur et la route DNS par défaut ; le résolveur de l'interface physique devrait être inutilisé. Un test de fuite DNS dans le navigateur constitue un second avis, et toute information appartenant à votre fournisseur d'accès signifie que le paramètre DNS n'a pas été appliqué. - Le kill switch fait ce qu'il annonce. Pendant qu'un téléchargement est en cours, arrêtez le service du client avec
systemctl stop, ou désactivez l'interface du tunnel avecip link set … down, afin que le tunnel tombe sans que le client en reçoive la demande. Le transfert devrait s'arrêter net. S'il continue, le switch est décoratif.
La série de tests plus complète, ainsi que ce que chacun peut ou ne peut pas montrer, se trouve dans son propre guide.
Ce que ces vérifications prouvent
+Votre trafic sort par le serveur de sortie, dans le pays que vous avez sélectionné
+Le résolveur qui répond à vos requêtes est celui du fournisseur, à l'intérieur du tunnel
+Un tunnel interrompu bloque la connexion au lieu de revenir discrètement au réseau ordinaire
Ce qu'elles ne prouvent pas
−Elles ne disent rien de ce que le fournisseur conserve — c'est une question de documents, à laquelle répondent les pages sur la conservation
−Elles ne vous rendent pas anonyme : votre navigateur et vos connexions restent inchangés ; consultez ce contre quoi un VPN ne vous protège pas
−Un test réussi aujourd'hui ne constitue pas une promesse pour la prochaine mise à jour du paquet ou du noyau
La voie du fichier de configuration, et son coût
La plupart des fournisseurs publient des fichiers de configuration pour les deux protocoles courants depuis l'espace du compte. Un fichier WireGuard s'importe dans NetworkManager depuis l'éditeur de connexions ou avec nmcli connection import, et fonctionne tout aussi bien avec wg-quick ; un fichier OpenVPN s'importe de la même manière avec le module OpenVPN. Vous obtenez le tunnel, le propre interrupteur d'interface du système, et rien que le fournisseur n'ait pas mis dans le fichier.
Ce que vous perdez, c'est le reste du client. Il n'y a pas de kill switch, sauf si vous écrivez vous-même les règles du pare-feu ; un fichier importé dans NetworkManager qui tombe rend simplement le trafic au réseau ordinaire. Il n'y a pas de gestion du DNS au-delà de la ligne DNS du fichier, et un fichier qui n'en contient pas est à l'origine de la fuite dans la première réponse de dépannage. Il n'y a pas de sélecteur de serveur : chaque fichier correspond à une sortie, et changer de sortie signifie utiliser un autre fichier. Générez les fichiers depuis l'espace du compte et gardez-les privés : un fichier WireGuard contient la clé privée qui constitue votre identité auprès du fournisseur.
Cette voie convient à un serveur, à une machine sans interface graphique ou à une distribution que le client ne prend pas en charge. Sur un ordinateur portable, préférez le client ; le switch qu'il apporte est précisément ce qu'un fichier de configuration ne peut pas fournir.
Quand cela ne fonctionne pas
Le tunnel est actif, mais le DNS passe toujours par mon fournisseur d'accès
La fuite Linux classique. Un fichier de configuration qui ne définit aucun DNS laisse systemd-resolved utiliser le résolveur fourni par le réseau, en dehors du tunnel. Exécutez resolvectl status : l'interface du tunnel devrait indiquer le résolveur du fournisseur et porter la route DNS par défaut, signalée par un signe plus.
Ajoutez une ligne DNS à la configuration ou définissez le DNS de la connexion dans NetworkManager, puis reconnectez-vous. Le propre client du fournisseur le fait automatiquement, ce qui est l'une des raisons de le préférer.
Tout s'arrête lorsque le tunnel tombe, et c'est agaçant
C'est le kill switch qui fait son travail : un tunnel interrompu devient une connexion morte au lieu de revenir silencieusement au réseau nu. Reconnectez-vous plutôt que de désactiver le switch.
S'il tombe souvent sur un réseau et rarement ailleurs, changez une fois de protocole et essayez une sortie plus proche. Si aucun protocole ne tient sur ce réseau, celui-ci bloque le trafic VPN, et ce guide s'arrête là.
Le client demande sudo ou un mot de passe à chaque fois
La création d'une interface réseau est une opération privilégiée, et un client qui n'installe pas de service en arrière-plan doit le demander à chaque fois. La plupart en installent un — un démon qui s'exécute en tant que root et une application de bureau qui lui parle — ; l'invite répétée signifie que le service ne fonctionne pas ou n'est pas activé.
Mêmes étapes, autres appareils
Le reste des plateformes
Chaque plateforme a son propre guide plutôt qu'un onglet sur celui-ci. Les étapes divergent dès que l'installateur s'ouvre, et une page qui répond à trois plateformes à la fois ne répond correctement à aucune d'elles.