Proton VPN sur un Pi sans écran : application ou fichier WireGuard ?

Installer l’application Linux ressemble à une seule instruction sur un Pi sans écran, et cela cache un choix entre deux chemins de déploiement aux limites de support différentes. L’un est l’application officielle du fournisseur, qui porte ses propres exigences de distribution et d’architecture. L’autre est un fichier de configuration manuel utilisé par un client standard que le système d’exploitation empaquette déjà. Les deux atteignent le même service, et ils ne sont pas interchangeables en matière de maintenance.

La question de l’architecture vient d’abord, car une carte 64 bits peut exécuter un espace utilisateur 32 bits et l’application n’en fournit qu’un seul.

Deux limites de support, pas deux installateurs

Lisez la page d’installation actuelle du fournisseur pour l’application que vous comptez utiliser et comparez-la à la carte : version de la distribution, architecture du paquet et toute exigence de bureau ou de session. Le fait qu’un Pi prenne en charge le fonctionnement 64 bits ne dit pas quel espace utilisateur est installé maintenant, et c’est cette valeur que vérifie le gestionnaire de paquets. dpkg --print-architecture et uname -m y répondent chacun en une ligne. Si la version ou l’architecture sort de l’ensemble documenté, l’application n’y est pas prise en charge même lorsqu’elle s’installe.

Le support varie aussi selon la méthode d’empaquetage. Une limitation documentée pour un format de paquet ne s’applique pas automatiquement à une compilation depuis un dépôt, et une distribution dérivée de Debian n’est pas automatiquement un environnement pris en charge. Les paquets communautaires et les anciennes recettes d’installation apportent leur propre modèle de maintenance, que vous pouvez accepter délibérément mais que vous ne devriez pas adopter par accident.

Ce que l’application apporte et qu’un profil n’apporte pas

L’application officielle est plus qu’une connexion : elle porte généralement le coupe-circuit du fournisseur, la gestion du DNS et des commutateurs de fonctionnalités, et le fournisseur prend en charge ces comportements comme un ensemble. Un profil manuel remis à un client standard n’en hérite rien. Le client manuel possède le cycle de vie de la connexion et la politique locale de défaillance, ce qui est bien quand vous les configurez vous-même et surprenant quand vous supposez qu’ils sont venus avec. Les deux options atteignent les mêmes serveurs ; une seule inclut la logique environnante.

Si une fonctionnalité compte, bloquer le trafic hors du tunnel par exemple, elle doit exister dans votre configuration et non dans l’application du fournisseur.

WireGuard à la main : les étapes qui comptent

Le fournisseur documente la génération d’une configuration WireGuard pour un client compatible avec la norme et recommande cette voie pour les installations manuelles, en réservant OpenVPN aux appareils plus anciens. Générez le profil dans le tableau de bord du compte, apportez-le au Pi et placez-le là où seul le propriétaire peut le lire. Ne collez jamais le fichier dans un fil de support, car un nom de fichier sympathique ne rend pas la clé privée intégrée publiable. Testez ensuite le tunnel avec une seule requête avant d’y connecter quoi que ce soit d’autre.

Le retrait de serveurs est un détail opérationnel que les gens oublient. Un point de terminaison choisi manuellement peut être retiré, et le fournisseur note qu’une configuration de remplacement peut être nécessaire. Notez quel point de terminaison le profil utilise pour qu’une panne ultérieure soit diagnosticable.

Décidez si le Pi est aussi une passerelle

Un tunnel utilisé par les applications du Pi ne devient pas automatiquement une passerelle pour les appareils situés derrière lui. Le transfert, le routage de retour, la propriété du résolveur et toute politique empêchant le trafic de s’échapper hors du tunnel sont une conception distincte avec ses propres modes de défaillance. Si d’autres appareils sont concernés, évaluez-les comme leur propre cas au lieu de supposer que la connexion du Pi les couvre. Cette séparation est ce qui garde un petit déploiement maintenable.

Acceptez ensuite le cycle de vie : une requête fraîche depuis le Pi, la résolution de noms par le résolveur prévu et le comportement de démarrage ou de reconnexion que vous avez planifié. Vérifiez chacun au lieu de supposer que l’application ou le profil le fournit.

Le mythe qu’il vaut la peine d’abandonner est qu’un installateur Linux et un fichier WireGuard représentent la même décision. Ce sont deux modèles de fonctionnement avec deux propriétaires différents.