Qui devrait posséder les routes et le DNS lorsque openfortivpn se connecte ?

Quatre étapes s'empilent les unes sur les autres dans une session openfortivpn qui fonctionne. Le client s'authentifie auprès de la passerelle et démarre une connexion TLS, puis exécute PPP à l'intérieur de cette connexion, reçoit ensuite une adresse et des informations DNS, et applique enfin des routes d'hôte et des réglages de résolveur. Chaque étape peut être vivante alors que la suivante ne l'est pas, et c'est pourquoi « connecté » est un mot si glissant dans les fils d'assistance.

La décision qui lève l'essentiel de la confusion est de savoir qui possède la dernière étape. Soit le client VPN applique lui-même les changements sur l'hôte, soit un autre composant le fait, et mélanger les deux à moitié est la façon dont les routes et les fichiers de résolveur finissent par décrire des sessions différentes.

Quatre étapes qui ressemblent à une seule connexion

La première étape est l'admission. un domaine d'authentification nommé ou un code à usage unique, et reçoit les paramètres dont il a besoin pour continuer. Quand le client imprime qu'il est connecté à la passerelle, cela signifie que le transport TLS est actif. Cela ne signifie pas que PPP a négocié, et certainement pas qu'une application interne est joignable.

La deuxième étape est la liaison PPP. Le client lance un processus PPP contre le périphérique de tunnel, et les deux côtés négocient les options de liaison et les adresses. C'est seulement après que l'hôte sait quelles adresses locales et distantes la session utilise, et seulement alors une route pointant vers le tunnel peut avoir un sens.

La troisième étape consiste à appliquer ces informations à l'hôte, et c'est là que la propriété compte. Le client peut ajouter les routes et réécrire la configuration du résolveur, ou on peut lui demander de s'effacer et de laisser les deux à ce qui gère le réseau sur cette machine. Le README du projet décrit cela comme des responsabilités distinctes plutôt qu'un comportement automatique unique.

Qui modifie la table de routage

Par défaut, le client est le propriétaire. Il ajoute une route vers la passerelle via l'interface physique, une route pour le pair du tunnel et des routes pour les réseaux que la session est autorisée à utiliser, puis les retire lorsque le processus se termine. Ce défaut est pratique sur un portable doté d'un seul gestionnaire de réseau et d'aucun autre logiciel VPN.

Ne choisissez la remise que lorsque autre chose possède réellement le routage. Une intégration de gestionnaire de réseau, un espace de noms réseau de conteneur ou un agent de routage à l'échelle du site peuvent déjà savoir installer et nettoyer les mêmes préfixes. Passer l'option no-routes empêche alors deux écrivains de se disputer la même table, une course qui se manifeste par la perte intermittente d'un sous-réseau plutôt que par un échec net.

Le chevauchement est la deuxième raison de remettre. Si les routes poussées incluent un préfixe que le réseau local utilise déjà, le client ne peut pas résoudre le conflit à votre place. Quelqu'un doit décider si ce préfixe est joignable par le tunnel, par la liaison physique ou par une route plus spécifique, et cette décision appartient à qui possède la topologie.

Le nettoyage est la troisième. Un client qui plante avant de retirer ses routes laisse un trou noir qui survit à la session, et la connexion suivante peut ajouter un doublon par-dessus. Qui possède le routage possède aussi la vérification que les anciennes entrées ont disparu. Faites de cette vérification une partie du chemin de démarrage, pas une étape de nettoyage facultative.

Qui possède le DNS et le fichier de résolveur

Le DNS est la même décision avec des bords plus tranchants. Le client peut accepter les serveurs DNS rapportés par la passerelle ou le pair PPP et les écrire dans la configuration du résolveur de l'hôte. Sur une machine simple, c'est exactement ce que vous voulez, car les noms internes ne se résolvent alors que tant que le tunnel est actif.

Sur un hôte Linux moderne, le résolveur peut être géré par un stub local, et réécrire le fichier de résolveur dans le dos de ce stub produit une configuration qui semble correcte et se comporte de façon incohérente. Si l'hôte exécute déjà un gestionnaire de résolveur, laissez-le posséder le DNS et alimentez-le avec les serveurs du tunnel via son interface prise en charge. L'option no-dns du client est le bon choix ici, pas un contournement.

Le DNS divisé est une question distincte de qui écrit le fichier. Envoyer chaque requête par le tunnel est simple et lent ; n'envoyer que les zones internes par celui-ci exige une configuration par domaine que la plupart des clients simples n'offrent pas. Décidez du comportement dont l'hôte a besoin avant d'activer les changements de résolveur du client. Un mauvais choix ici ressemble à une panne de résolution de noms même lorsque le tunnel lui-même va bien.

Privilèges, disponibilité et la remise

Créer le périphérique de tunnel et modifier les routes d'hôte ou l'état du résolveur exige une autorité réseau élevée. L'erreur courante est de conclure que tout doit donc tourner en root, y compris le navigateur ou l'application qui utilise le tunnel. Gardez la partie privilégiée petite : le client et son fichier de configuration, détenus par un administrateur, tandis que les applications utilisateur conservent leur compte normal.

La disponibilité doit être définie par consommateur. Un superviseur peut considérer le service démarré lorsque le processus client tourne et que le périphérique de tunnel existe. Une tâche de sauvegarde ne devrait considérer le VPN utilisable que lorsque son point de stockage répond par le tunnel. Ce sont des contrôles différents, et utiliser le plus faible pour l'objectif le plus fort produit des tâches qui démarrent trop tôt et échouent par intermittence. Écrivez la définition choisie, car un superviseur et une tâche qui ne sont pas d'accord sur la disponibilité sont un ticket d'assistance qui attend de se produire.

Testez le contrat avec quatre observations : la phase de passerelle se termine, PPP attribue des adresses, la route prévue est présente et une requête vers un hôte interne réussit. Arrêtez ensuite le client et confirmez que chacun de ces éléments a été retiré ou restauré. Si l'hôte résout encore des noms internes ou détient encore une route après la fermeture du tunnel, la remise de propriété est incomplète.