Client Fortinet sous Linux : vérifiez la passerelle avant de réparer

Le guide archivé indique d’installer des bibliothèques 32 bits, de corriger un thème GTK et de lancer l’installateur depuis un terminal. Une partie de ce conseil était correcte pour une version précise du client, et rien de tout cela ne peut rétablir un mode tunnel que la passerelle n’offre plus. Avant de modifier un paquet, trouvez la première étape qui a échoué. Cela part de la passerelle vers l’intérieur, car c’est là que les réponses coûtent peu et qu’une correction locale erronée coûte le plus de temps.

Vérification 1 : nommez l’étape qui a échoué

Trois étapes échouent différemment. Le programme ne démarre pas, il démarre et rejette l’identité du serveur, ou il se connecte et la passerelle n’a aucun service du type dont vous avez besoin. Chaque échec laisse sa propre preuve : une erreur de chargeur, un message de certificat, une réponse de la passerelle qui nomme un mode indisponible.

Notez-le avant de toucher à quoi que ce soit. Tout ce qui suit dépend de l’étape que vous avez nommée, et les trois corrections n’ont rien en commun.

Vérification 2 : la version de la passerelle et le mode tunnel

Le mode tunnel a disparu sur les passerelles actuelles, et le tableau d’intégration FortiClient 7.4.4 pour Linux est l’endroit où cela est écrit : FortiOS 7.6.3 et les versions ultérieures n’offrent plus le mode tunnel SSL VPN et renvoient les administrateurs vers IPsec. Gardez le produit, la version et le mode attachés à cette phrase lorsque vous la répétez. Elle ne dit rien de chaque produit Fortinet, ni des fonctions d’accès web qui existent encore. La compatibilité générale des versions et la disponibilité d’un mode tunnel sont des vérifications distinctes.

Demandez deux choses au propriétaire de la passerelle : quelle version la passerelle exécute, et quelles méthodes d’accès sont activées aujourd’hui. Demandez la réponse par écrit, avec la chaîne de version et la page de réglages ou la ligne de configuration d’où elle vient, car c’est une assurance verbale qui renvoie les gens au guide archivé. Vérifiez ensuite cette réponse contre les notes de la passerelle ou la matrice du fournisseur pour cette version exacte. Un navigateur qui affiche le portail web prouve que le portail répond, rien de plus.

Vérification 3 : l’édition du client que le propriétaire approuve

Obtenez l’édition et la version approuvées du client Linux, puis vérifiez le système d’exploitation, l’architecture, le bureau et le flux d’authentification pris en charge. La matrice 7.4.4 est un exemple lié à une version, pas une recommandation pour le client le plus récent ni une promesse pour chaque dérivé. Demandez quel client le propriétaire soutiendra réellement, car cette réponse fait partie de la migration et n’est pas une réflexion après coup. Un client qui meurt avant que son premier paquet atteigne la passerelle prouve quelque chose sur l’ordinateur portable, pas sur le service.

Les bibliothèques 32 bits et un thème corrigé changent ce que le binaire peut charger ; ils ne changent pas ce que le fournisseur prend en charge. Si le système d’exploitation ou le flux d’authentification sort de la matrice, la question de qualification est déjà tranchée.

Vérification 4 : demandez le profil de remplacement

Si l’organisation est passée du mode tunnel SSL VPN à IPsec, demandez le nouveau profil et la procédure d’enrôlement dans la même conversation. Ne renommez pas une configuration SSL en supposant que les champs suivent : un profil IPsec nomme une version d’IKE, une passerelle distante et son identité, une méthode d’authentification et les sélecteurs de trafic que chaque côté accepte. La politique de compte et d’appareil peut aussi être appliquée différemment. Un renommage produit un client qui semble configuré et ne négocie rien.

Lisez le profil avant de lui faire confiance. Il doit indiquer la version d’IKE et les propositions, si l’authentification utilise un certificat ou une clé pré-partagée, quels sous-réseaux locaux et distants sont sélectionnés, et ce que la passerelle attend comme identité. Confirmez que le client Linux approuvé prend en charge cette disposition, car un document de migration n’est pas une déclaration de parité de fonctions pour chaque version du client. Un client indépendant comme openfortivpn n’est pas un interpréteur OpenVPN, donc traitez tout autre produit portant SSL dans son nom comme non approuvé jusqu’à ce que le propriétaire dise le contraire pour ce mode, ce flux de connexion et cette politique d’appareils.

Vérification 5 : les dépendances locales, puis validez et consignez

Une fois la passerelle et le client réglés, un échec de lancement est un problème d’empaquetage, et les instructions du paquet maintenu sont la référence à suivre. Un échec d’identité TLS relève de l’opérateur : les ancres de confiance et le nom attendu sont sa configuration, pas quelque chose à contourner localement. Ce sont les deux étapes où le guide archivé a jamais été utile.

Aucun des deux ne se résout en acceptant un certificat inconnu ou en désactivant un contrôle de posture. Gardez les contrôles MFA et d’appareil en place, car rétablir la connectivité en les affaiblissant échange une panne contre un incident. Si le mode a disparu, aucun indicateur local ne le ramène.

Après le changement approuvé, atteignez la ressource privée visée, confirmez la résolution DNS et reconnectez-vous une fois. Consignez le client, la plateforme, la version de la passerelle et le mode tunnel ensemble, car la personne suivante a besoin des quatre. Un programme qui s’ouvre avec succès a franchi l’étape locale de lancement, et rien de plus.