Serveur VPN sur Raspberry Pi : partez de l’appli du téléphone, pas de la recette

La plupart des montages VPN sur Raspberry Pi commencent par la recette du serveur et finissent avec un téléphone qui ne peut pas se connecter. L’ordre est inversé. Un client mobile implémente un protocole précis avec un échange d’authentification précis, et le serveur doit correspondre à cet échange, pas l’inverse. Choisir d’abord l’appli transforme un après-midi de débogage en une courte liste de vérification.

L’ordre qui épargne la reconstruction

Notez le système d’exploitation du téléphone et l’appli VPN exacte avant d’installer quoi que ce soit sur le Pi. Ce couple détermine quel protocole est seulement possible. Une appli cliente ne devient pas un autre client parce qu’un profil contient par hasard un champ familier.

Un secret partagé dans un profil, ou un numéro de port qui semble familier, ne transforme pas un protocole en un autre. L’échange correspond soit à ce que l’appli implémente, soit il échoue à une étape qui vous laisse très peu à lire. Il n’existe aucun diagnostic qui dise en mots simples « mauvais protocole ». Vous obtenez un délai dépassé, une erreur de certificat ou une boucle de nouvelle tentative silencieuse, et tout cela ressemble à un problème de serveur.

Une fois l’appli fixée, le choix du serveur se resserre et le reste du montage a une cible.

Ce que l’appli du téléphone implémente réellement

Une fiche de client publiée décrit une application, pas un service. L’appli OpenVPN Connect pour Android attend un serveur OpenVPN ; elle ne fournit pas le côté serveur. Elle ne devient pas non plus un client IPsec ou L2TP quand un profil paraît similaire.

Cette distinction compte surtout quand vous suivez un guide plus ancien. Les recettes écrites pour un protocole que l’appli actuelle a abandonné s’installent toujours proprement sur le Pi et échouent toujours sur le téléphone, ce qui se lit comme une erreur de configuration et non comme une incompatibilité de protocole.

Vérifiez dans la documentation actuelle de l’appli quels formats de profil elle importe avant de vous engager sur un paquet serveur. Cinq minutes de lecture valent mieux qu’une reconstruction.

L’accord en quatre parties

Notez quatre choses et gardez-les ensemble : le système d’exploitation et la version de l’appli du téléphone, l’implémentation serveur sur le Pi, la politique d’authentification et de confiance, et le point de terminaison externe. Chacune des quatre peut invalider les trois autres.

Une mise à jour de l’appli, un changement de paquet serveur ou une nouvelle autorité de certification cassent l’accord, et l’échec se voit à l’identique depuis le téléphone à chaque fois. Ce sont les quatre notées qui permettent d’identifier quelle partie a bougé.

Les identifiants ont des rôles distincts

Décidez si le profil utilise des certificats clients, un nom d’utilisateur et un mot de passe, ou une combinaison prise en charge, et faites s’accorder les deux extrémités. L’identité du serveur et le matériel de CA de confiance doivent aussi correspondre à ce que le client acceptera.

Le certificat public de la CA et sa clé privée de signature sont des objets différents. Seule la partie publique a sa place dans un profil de téléphone. Placer la clé de signature sur un téléphone revient à distribuer la capacité de créer des identités, ce qui est l’inverse de ce à quoi sert une CA. Traitez ce fichier comme l’objet le plus sensible de tout le montage.

Utilisez le flux d’export et d’import pris en charge par le service plutôt que d’assembler un profil à la main. Les profils montés à la main portent souvent des directives réservées au bureau que l’appli mobile ignore ou refuse.

Surtout, ne remplacez pas la validation du certificat par « accepter n’importe quel serveur » pour faire connecter un exemple ancien. Cela transforme un problème de compatibilité en contournement de l’authentification, et cela survit généralement jusqu’en production parce que ça fonctionne.

L’accessibilité est un contrat distinct

Le téléphone doit atteindre le point de terminaison externe du serveur à travers la disposition réelle en amont. La traduction du routeur domestique, le filtrage et le NAT de l’opérateur se situent tous entre les deux. Un nom DNS dynamique ne donne au point de terminaison qu’un nom stable ; il ne crée pas de chemin entrant.

Définissez ensuite ce que le client peut atteindre une fois connecté : préfixes privés ou sortie internet complète, leurs chemins de transfert et de réponse, le comportement du DNS, et si IPv6 entre dans le périmètre. Une connexion réussie ne prouve rien de tout cela.

Acceptez le téléphone et le profil prévus directement, y compris une vérification qu’une ressource non autorisée reste inatteignable et que la révocation retire réellement l’accès. Le succès avec un client de bureau valide ce client de bureau, pas le téléphone dans votre main. La fiche d’OpenVPN Connect est un exemple concret d’une appli cliente qui attend un service correspondant.