Le Pi comme client VPN : un gestionnaire ou un script maison ?

Un Raspberry Pi qui ne doit protéger que son propre trafic sortant a deux conceptions réalistes : laisser le gestionnaire réseau posséder le tunnel, ou garder un script qui le possède. Les deux peuvent transporter du trafic. Ils échouent à des endroits différents, et la panne que vous pouvez diagnostiquer à distance à deux heures du matin est celle qui vaut la peine d’être choisie. Comparez-les sur la propriété, sur ce que signifie un tunnel complet une fois IPv6 et DNS impliqués, et sur ce qui se passe à l’instant où le tunnel tombe.

Deux propriétaires pour un tunnel

La conception A est un profil à l’intérieur du gestionnaire réseau du système : un profil OpenVPN importé ou une connexion WireGuard native, activée au démarrage par le même service qui monte Ethernet et le Wi-Fi. La conception B est une unité à vous qui exécute le client directement, modifie la configuration du résolveur et installe ses propres routes et règles de pare-feu. Les deux sont légitimes ; elles diffèrent par qui a le droit de modifier la table de routage.

Les pannes diffèrent parce que les propriétaires diffèrent. Avec A, un profil qui ne s’active pas laisse l’interface montée et le tunnel en bas, et les journaux du gestionnaire disent pourquoi. Avec B, un script qui réussit à moitié laisse des routes qui survivent au processus qui les a créées. Faire tourner les deux est le pire résultat : deux processus écrivent la route par défaut, deux modifications du résolveur se disputent au démarrage et deux jeux de secrets sont à renouveler.

Choisissez un propriétaire par tunnel et désactivez l’autre avant de tester quoi que ce soit. Deux propriétaires signifient aussi deux endroits où regarder quand le tunnel est monté et que rien ne se résout. Cette règle unique évite la plupart des états confus décrits dans les fils Pi VPN.

Ce qu’une importation crée, et ce qu’elle ne crée pas

Sur Raspberry Pi OS Bookworm et versions ultérieures, l’outil de configuration réseau par défaut est NetworkManager, donc un profil est le foyer naturel d’un tunnel client. L’importation exige le greffon correspondant installé ; sans lui, l’importation échoue avec un message sur un type de connexion non pris en charge, ce qui est le signal honnête pour s’arrêter et installer le greffon.

nmcli connection import type openvpn file ./provider.ovpn
nmcli connection show
nmcli --ask connection up id provider-name

L’importation enregistre un profil. Elle ne prouve pas que l’autre côté est joignable, et ne garantit pas que chaque directive du fichier a survécu à la conversion. Relisez la connexion obtenue et vérifiez les parties qui portent l’identité et la confiance : le certificat, l’hôte distant et le port, et si un mot de passe est demandé ou stocké.

L’activation avec --ask garde une phrase secrète hors de l’historique du shell sur une machine partagée. Pour un Pi sans surveillance, vous voudrez finalement que le profil monte au démarrage, ce qui est une décision distincte du fait de le monter une fois à la main.

Tunnel complet, comparé sur les deux conceptions

Un tunnel complet est une affirmation sur les routes, pas sur l’intention, et les deux conceptions l’expriment différemment. L’approche par profil demande au gestionnaire d’installer une route par défaut et ses réglages de résolveur ; l’approche par script fait ce que dit le script, y compris rien. Aucune des deux ne couvre IPv6 sauf si on le lui demande, et une route par défaut IPv6 intacte portera allègrement du trafic hors du tunnel pendant qu’IPv4 semble parfait.

ip -4 route get 198.51.100.23
ip -6 route show default
resolvectl query example.org

Utilisez une adresse de documentation pour la consultation de route et remplacez-la par un hôte que vous êtes autorisé à sonder. La première commande montre quelle interface le Pi utiliserait pour une destination ordinaire ; la deuxième montre si une route par défaut IPv6 existe encore ; la troisième prouve quel résolveur a répondu. Lisez les trois avant de croire une affirmation sur un tunnel complet.

Si les instructions du fournisseur promettent un tunnel complet mais que la route par défaut IPv6 survit, le Pi fuit. Désactivez IPv6 sur le lien montant ou demandez au profil de le revendiquer, et décidez délibérément au lieu de le découvrir plus tard.

Échec ouvert contre échec fermé

Quand le tunnel tombe, une table de routage qui perd sa route par défaut retombe simplement sur le lien physique, et le trafic continue en clair. C’est l’échec ouvert, et c’est le comportement par défaut des deux conceptions sauf si quelque chose l’empêche. La plupart des gens le découvrent des semaines plus tard en lisant un journal de pare-feu.

L’échec fermé vous coûte l’accès distant quand le tunnel est en bas, il lui faut donc une exception délibérée pour le chemin de gestion. Une façon est une règle qui n’autorise que l’adresse du pair VPN hors du tunnel :

sudo nft add table inet vpnkill
sudo nft 'add chain inet vpnkill out { type filter hook output priority 0; policy accept; }'
sudo nft add rule inet vpnkill out oifname != "tun0" ip daddr != 203.0.113.24 reject

Comparez le coût opérationnel honnêtement. Un profil ne peut généralement pas exprimer cette règle, donc l’échec fermé vous pousse vers la conception par script ou vers une petite unité qui installe la règle indépendamment du tunnel. Dans tous les cas, journalisez les rejets pendant une semaine : un rejet silencieux ressemble à un service cassé, et vous voudrez le compteur quand un utilisateur signalera qu’un site a cessé de se charger.

Choisir pour un Pi sans écran

Si l’image fait déjà tourner NetworkManager, que le tunnel n’a besoin de rien d’exotique et que vous voulez qu’il suive le lien montant automatiquement, prenez le profil. Si vous avez besoin de routage par politiques, de plusieurs tunnels choisis par destination, ou d’une règle d’échec fermé qui doit exister avant que le tunnel monte, prenez le script et possédez chaque partie, y compris l’ordre de démarrage et le nettoyage. Mélanger les deux conceptions coûte plus cher que l’une ou l’autre seule.

Migrer entre les deux est surtout une question d’ordre : désactivez l’ancien propriétaire, confirmez qu’aucune route ni entrée de résolveur obsolète ne survit, puis activez le nouveau et redémarrez deux fois. Un seul redémarrage peut masquer une course qu’un second révèle. Terminez en testant le Pi plutôt que le tunnel : résolvez un nom, récupérez quelque chose en IPv4, récupérez en IPv6 si vous l’avez gardé, puis coupez le tunnel et confirmez que le comportement choisi se produit vraiment. Une interface dans ip link est le début du test, pas la fin.