Ce qui se passe réellement quand vous démarrez un VPN sous Linux

Appuyez sur connecter et trois choses changent sur une machine Linux : une interface apparaît, des routes sont installées et le résolveur commence à répondre différemment. La plupart des échecs de configuration viennent de ce que l'une de ces trois choses se produise sans les autres, ou de ce que deux programmes ne soient pas d'accord sur qui les possède. Comprendre la séquence explique la panne plus vite que la lecture de la sortie de journal d'un client.

Une interface apparaît avant que quoi que ce soit fonctionne

Un client de tunnel ouvre une interface virtuelle et lui remet des paquets. Un périphérique TUN transporte des paquets IP, ce dont un VPN routé a besoin ; un périphérique TAP transporte des trames Ethernet, ce dont une conception pontée a besoin. Le module du noyau fournit le périphérique, et le client le possède tant que la session dure.

Que l'interface monte n'est pas la même chose que le tunnel qui fonctionne. Elle peut exister avec une adresse alors que le pair est injoignable, et c'est pourquoi la liste des interfaces est la première vérification et non la dernière. Un périphérique qui se déclare monté décrit la vue du noyau sur un lien virtuel, pas la volonté du pair de répondre.

Laissez le mode d'interface fourni tel quel. Passer un profil TUN en TAP ne transforme pas un serveur routé en serveur ponté, et cela produit généralement une connexion qui s'établit et ne transmet rien.

Les routes sont installées par celui qui possède le tunnel

Les routes sont le deuxième changement, et leur propriété compte plus que leur contenu. Un profil NetworkManager, une unité systemd et un client lancé à la main peuvent tous installer des routes, et deux d'entre eux le faisant en même temps produisent une table que personne ne saura expliquer plus tard.

ip -br addr show
ip route show
ip -6 route show

Un profil de tunnel complet remplace la route par défaut ; un profil de tunnel divisé ajoute des routes plus spécifiques et laisse la route par défaut tranquille. Les deux sont normaux, et le second est la raison pour laquelle supprimer une route par défaut est un mauvais premier test sur une machine que vous administrez à distance. La retirer est aussi le moyen le plus rapide de perdre la session que vous utilisez pour corriger le problème.

Lisez la table au lieu de supposer. Une route plus spécifique ou une règle de politique peut envoyer le trafic dans le tunnel alors que la route par défaut pointe encore vers l'interface physique, ce qui semble contradictoire jusqu'à ce que vous lisiez toute la table. Cette combinaison est normale pour un tunnel divisé et déroutante pour qui attend qu'une seule ligne décrive la conception. Cherchez la route qui correspond à votre destination réelle, pas celle qui correspond au schéma.

Le résolveur change de mains

Le DNS est le troisième changement et celui qui est le plus susceptible d'être géré à un endroit que vous n'avez pas regardé. Sur un poste de travail, NetworkManager peut pousser les réglages du résolveur par connexion. Sur un système qui utilise systemd-resolved, les réglages sont appliqués par lien et /etc/resolv.conf peut être un stub ou un lien symbolique plutôt qu'un fichier que vous devriez modifier.

resolvectl status
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

Si une modification manuelle du fichier du résolveur disparaît après une reconnexion, c'est le signal pour trouver le composant qui le maintient et changer plutôt le profil. Modifier le fichier généré est un changement qu'une reconnexion effacera.

Les noms privés ont généralement besoin du résolveur interne et des domaines de recherche fournis par l'opérateur. Remplacer par un résolveur public peut casser précisément la ressource pour laquelle le VPN existe, et le symptôme ressemble à une panne de routage et non à une panne DNS. Testez le nom et l'adresse séparément, car l'un qui fonctionne et l'autre qui échoue vous dit exactement où regarder. Cette seule comparaison économise une heure de débogage de routes.

Un gestionnaire par connexion

Le format du profil décide quel programme peut l'utiliser. Un profil OpenVPN nécessite OpenVPN ou un greffon compatible, et une configuration WireGuard a son propre format avec des clés de pair et des préfixes autorisés. Une boîte d'importation ne traduit pas l'un en l'autre, quoi que suggère l'extension du fichier.

Choisissez un gestionnaire et laissez-lui posséder la connexion. Monter le même tunnel via deux outils rend la table de routes et le comportement de reconnexion ambigus, et le second à démarrer gagne généralement de façons difficiles à reproduire.

Installez les paquets pris en charge par votre distribution et obtenez le profil auprès de l'opérateur. Traitez-le comme un identifiant, car il contient généralement une clé privée ou un matériel équivalent, et stockez-le là où vivent vos autres secrets. Un profil laissé dans un dossier de téléchargements est une clé laissée sur un bureau.

Que vérifier quand c'est monté mais que ça ne fonctionne pas

L'interface étant montée et le client rapportant un succès, travaillez vers l'extérieur : la table de routes sélectionne-t-elle le tunnel pour la destination, le résolveur répond-il pour le nom privé, et le côté distant a-t-il un chemin de retour. Chacun a une commande distincte et un propriétaire distinct.

nmcli connection show --active
nmcli device status
wg show

La référence nmcli documente les commandes d'état et de connexion si vous avez besoin de l'ensemble complet. Ce qui compte ici, c'est la distinction entre un profil actif et un périphérique qui transporte du trafic, car les deux peuvent se contredire.

Reconnectez une fois via le même gestionnaire avant de déclarer l'installation terminée, et vérifiez que le DNS fonctionne encore après une déconnexion. Une configuration qui ne fonctionne que jusqu'au premier changement de réseau n'est pas terminée, elle fonctionne seulement à cet instant.