Quatre réponses de l’employeur déterminent si un Pi peut rejoindre le VPN professionnel : quel protocole de passerelle il parle, quels systèmes d’exploitation et architectures il prend en charge, comment l’authentification doit se faire, et si un client autre que l’officiel est autorisé. Une URL de portail et le mot Linux ne règlent aucune d’elles. Demandez avant de télécharger quoi que ce soit, car les réponses changent le paquet que vous installez et la viabilité même d’une installation sans écran.

Notez les quatre réponses. Le reste de ce texte est ce que chacune change.

Le protocole de la passerelle détermine le client

La passerelle parle un ou plusieurs protocoles, et le client doit implémenter celui que votre organisation exploite réellement. OpenConnect est une implémentation indépendante qui a commencé par la compatibilité avec Cisco AnyConnect et couvre désormais plusieurs autres passerelles d’entreprise ; ce n’est pas le client de marque de l’éditeur, et la compatibilité de protocole ne garantit pas la prise en charge de chaque fonction de passerelle, contrôle de posture ou politique d’appareil. Confirmez le protocole auprès de l’équipe réseau plutôt que de le déduire de l’URL du portail. Confirmez ensuite que l’employeur accepte ce client pour ce déploiement.

Les preuves de compatibilité doivent venir de la documentation de l’employeur ou d’un collègue qui l’a fait sur le même modèle, pas de l’existence d’un paquet dans un dépôt.

L’architecture n’est pas un détail

Notez la version du système d’exploitation et l’architecture de l’espace utilisateur du Pi, la version du client que vous comptez utiliser et l’origine de ce paquet. Un installateur x86 ne devient pas adapté à une autre architecture parce que son nom de fichier a changé, et un client de l’éditeur qui ne fournit que des builds x86 ne peut pas du tout fonctionner sur le Pi. Ce seul fait peut régler toute la question avant même que l’authentification soit abordée. Vérifiez la maintenance de la source du paquet plutôt que d’installer un binaire errant trouvé sur un fil de forum.

Un espace utilisateur 64 bits sur un noyau 64 bits est le cas simple ; un espace utilisateur 32 bits sur une carte 64 bits est là où les gens installent le mauvais paquet. dpkg --print-architecture et uname -m répondent aux deux moitiés en une ligne chacun.

L’authentification détermine le flux de travail

Les mots de passe, le MFA et la connexion via le navigateur imposent chacun leur propre flux de travail. Un certificat conservé sur un jeton matériel peut nécessiter un pilote que le Pi n’a pas, tandis qu’un flux SSO peut ouvrir une fenêtre de navigateur qu’une session sans écran ne peut pas afficher. Certaines passerelles proposent un chemin par code d’appareil ou copie manuelle précisément pour ce cas, et d’autres non. Demandez quelle méthode l’organisation prend en charge pour un hôte Linux sans écran, puis testez-la avant d’en dépendre.

L’intégration côté interface est un choix distinct de l’authentification. Un greffon NetworkManager peut organiser une connexion et stocker ses secrets, mais il ne peut pas rendre compatible une méthode d’authentification non prise en charge. Gardez ces deux questions séparées.

Préservez la frontière de l’employeur

Si l’organisation exige son client officiel, un appareil géré ou une distribution prise en charge, respectez cette exigence ou demandez une alternative approuvée. Désactiver les vérifications de certificat, imiter des résultats de posture ou couper les contrôles de point de terminaison pour qu’un autre client paraisse accepté transforme un problème de compatibilité en violation de politique. Gardez les mots de passe, les cookies de session et les clés privées hors de l’historique du shell et des transcriptions de discussion. Un défi-réponse fonctionnel n’est pas une autorisation de publier le matériel de session.

Après une inscription approuvée, confirmez le DNS privé, les ressources prévues, une ressource refusée et la reconnexion, le tout depuis le Pi lui-même. Un tunnel connecté peut encore router incorrectement ou manquer d’une autorisation.

Le livrable est un accord soutenable avec un responsable nommé : quel client, quelle version, quel chemin d’inscription. Cela vaut mieux qu’installer le client proche de l’éditeur en espérant que les exigences restantes se révèlent facultatives.

Articles similaires