Pourquoi route-nopull seul laisse le serveur de fichiers injoignable
Ignorer les routes poussées n’est que la moitié d’un tunnel divisé. Choisissez le propriétaire de la route, ajoutez le préfixe du bureau à la main et testez trois flux avant de déclarer la panne résolue.
Le serveur de fichiers s’ouvre sans problème, et l’appel vidéo dans la fenêtre voisine commence à saccader. Rien n’est lent et aucune MTU n’est fausse : votre client a repris la liste de routes que le serveur lui a donnée, donc chaque paquet sort désormais par le pare-feu du bureau. Le correctif n’est pas un indicateur de réglage de plus mais une décision sur qui possède la table de routage du client. Cette décision appartient à un seul endroit, et les modes de défaillance ci-dessous vous disent lequel vous avez réellement choisi.
Décidez qui possède la table de routage
Trois propriétaires sont possibles. Le serveur peut pousser des routes et une passerelle par défaut, auquel cas le client installe ce qu’on lui dit et devient un tunnel complet. Le profil client peut prendre la propriété en écartant les poussées et en portant ses propres lignes de route. Un gestionnaire de connexions de bureau peut aussi posséder la décision via ses propres propriétés de route et de route par défaut.
Chaque choix échoue différemment, et c’est pourquoi la table vaut la peine d’être lue avant de modifier un profil. La ligne qui correspond à votre symptôme est le propriétaire que vous avez réellement.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
Choisissez-en un et écrivez-le. Mélanger les deux laisse un hôte dont le chemin par défaut contredit sa propre documentation, et l’ingénieur suivant ne peut pas savoir quelle couche a gagné. Supprimez explicitement le perdant.
route-nopull filtre les poussées, il n’ajoute pas de routes
route-nopull appartient au profil client, et son ordre dans ce fichier n’a pas d’importance car il ne fait qu’écarter les valeurs venant du serveur. Il écarte les routes poussées, y compris une route par défaut poussée, pendant que le tunnel monte toujours normalement.
La conséquence que les gens manquent, c’est que les options DHCP poussées partent avec elles. Les réglages DNS envoyés par le serveur sont aussi écartés, si bien que les noms internes cessent de se résoudre alors que le tunnel est sain et que le serveur est joignable par adresse.
Cela laisse un tunnel sans chemin vers le préfixe du bureau, sauf si vous en ajoutez un vous-même : route-nopull suivi de route 10.30.0.0 255.255.0.0 dans le même profil. Cette ligne porte une adresse et un masque ; elle ne nomme pas de saut suivant.
Une forme alternative ajoute un jeton de passerelle, route 10.30.0.0 255.255.0.0 vpn_gateway, qui pointe l’entrée vers le tunnel par son nom. Les importateurs diffèrent sur la traduction de cette variante, alors inspectez la connexion enregistrée si l’entrée manque dans la table du noyau.
Vérifiez par des recherches de route, pas par un ping
Un ping vous dit que quelque chose a répondu. Une recherche de route vous dit quelle interface le noyau choisirait, et c’est la question que vous avez réellement posée. Quatre commandes courtes séparent une route absente d’une route qui pointe vers le mauvais périphérique.
Lisez ce que le tunnel a installé avec ip route show dev tun0. Aucune sortie du tout signifie zéro route, ce qui n’est pas un tunnel divisé qui fonctionne, et c’est le résultat habituel de l’ajout du filtre sans la ligne explicite.
Vérifiez ensuite une adresse du bureau avec ip route get 10.30.5.7, et une adresse internet ordinaire avec ip route get 1.1.1.1. La seconde devrait nommer l’interface physique ; si elle nomme le tunnel, la poussée n’a pas été filtrée du tout.
Enfin, lisez ip rule, car une règle de politique laissée par une tentative précédente peut supplanter la table que vous venez de corriger. Un profil correct avec une règle obsolète au-dessus ressemble exactement à un profil cassé. Supprimez la règle ajoutée la dernière fois avant d’en ajouter une autre.
Les sous-réseaux qui se chevauchent ressemblent à un tunnel cassé
Deux plages privées peuvent être identiques du point de vue du client, et c’est là qu’un tunnel divisé est blâmé pour quelque chose qu’il n’a pas causé. Si le bureau distribue le même préfixe que votre routeur domestique, la route du tunnel couvre le routeur et le réseau de la maison semble disparaître.
Comparez l’adresse de votre propre interface avec la route que le profil installe, en utilisant une simple liste d’adresses avant de changer quoi que ce soit. Le chevauchement est réel, et aucune option de profil ne le résout. Ce que vous pouvez corriger, c’est le nommage, pour que la personne suivante voie deux plages au lieu d’une.
Les corrections honnêtes consistent à renuméroter un côté ou à traduire les adresses au bureau. Épingler une seule route d’hôte sur le routeur fonctionne jusqu’à ce que l’adresse du routeur change, et cela devient alors un second mystère par-dessus le premier.
Faites survivre la décision à une reconnexion
Les entrées saisies à la main ne survivent pas à une reconnexion, et un gestionnaire de connexions reconstruit la table à chaque démarrage du profil. Placez la décision là où la connexion est créée, que ce soit le profil ou les réglages enregistrés du gestionnaire. Redémarrez ensuite la connexion une fois exprès au lieu de découvrir le comportement pendant un appel. Un profil qui ne fonctionne que jusqu’à la prochaine reconnexion n’est pas terminé.
Exercez trois chemins à la fois : un hôte du bureau par adresse littérale, le même hôte par nom, et un site public ordinaire. Celui du milieu dépend du service de noms que vous avez configuré après avoir écarté les options DNS poussées, et c’est celui qui échoue silencieusement.