Quel composant détient vraiment une limite de routes OpenVPN ?

Un profil qui porte deux cents routes fonctionne sur une machine et en installe quarante sur une autre. Le moteur, l’intégration qui le démarre et le serveur qui l’alimente ont chacun leur mot à dire, et chacun peut arrêter la liste à un endroit différent. Lire la panne comme une limite unique vous envoie au mauvais fichier. Le mécanisme compte trois étapes, et l’étape qui s’est arrêtée laisse des preuves visibles quand on sait quoi chercher.

Trois étapes, trois limites différentes

D’abord le moteur analyse l’option et décide si cette version la comprend. Ensuite l’intégration installe ce que le moteur rapporte, et son propre code peut plafonner ou remodeler la liste. Enfin le serveur décide combien de routes il enverra à une identité donnée, avant que l’une ou l’autre étape côté client ne voie quoi que ce soit. Trois étapes, trois plafonds, et un seul d’entre eux est le nombre inscrit dans le profil.

Relever un plafond ne fait rien pour les autres. Une route envoyée puis refusée peut être une décision de politique sur le serveur, un recouvrement que le client a résolu, ou une limite de l’installateur qui a écarté l’excédent. Chacun de ces cas a sa propre correction.

Séparez les trois avant de mesurer quoi que ce soit. Une erreur d’analyseur nomme un jeton, une limite d’installateur laisse une table de routes courte, et une décision de politique ne laisse absolument rien. Les preuves vous disent quelle étape inspecter en premier.

L’analyseur parle en premier

Une option inconnue échoue bruyamment et tôt, et le texte de l’erreur nomme le jeton. C’est l’étape la plus facile à identifier : comparez le message exact à la version installée du moteur, car une option ajoutée dans une version est inconnue dans la précédente. Un profil copié depuis un déploiement plus récent est la source habituelle de cet écart. L’analyseur n’ignore jamais silencieusement une directive qu’il ne reconnaît pas.

Une option acceptée ne dit rien du résultat. L’analyse réussit, et la liste peut malgré tout être rognée par l’installateur ou n’être jamais proposée par le serveur. Traitez une analyse propre comme une autorisation de continuer, pas comme une preuve.

Notez la chaîne de version du binaire qui a réellement tourné, pas l’idée que se fait le gestionnaire de paquets de ce qui est installé. Ces deux-là se contredisent plus souvent qu’on ne l’attend.

L’installateur a son propre plafond

Le composant qui détient l’activation peut être un greffon NetworkManager plutôt que le binaire du moteur, et il peut imposer sa propre limite avant qu’un seul tunnel existe. Son éditeur peut exposer un champ que le moteur en cours ne lit jamais, ou lire un champ que l’éditeur n’affiche pas. Les deux situations ressemblent de l’extérieur à un défaut du client. Aucune n’est corrigée en modifiant le profil.

Comptez ce qui est arrivé plutôt que ce qui a été configuré. La commande ip route show dev tun0 liste les routes installées, et comparer ce décompte à la liste envoyée sépare une route écartée d’une route qui n’a jamais été envoyée. Un décompte qui correspond à l’envoi ramène le soupçon vers le serveur.

Une enveloppe de shell autour du binaire du moteur pour forcer un nombre plus grand brouille les mises à niveau et transforme le retour arrière en devinette. Elle cache aussi la vraie limite à quiconque lira la configuration ensuite.

Le serveur décide de ce qu’on vous a proposé

Une politique par client peut réduire la liste avant sa transmission. Un fichier propre à un client peut ajouter des routes pour une identité, ou une politique de groupe peut les omettre, et le client ne peut pas distinguer une route filtrée d’une route jamais définie. C’est cette ambiguïté qui rend l’enregistrement serveur important. Demandez la liste d’envoi effective pour cette identité, pas le modèle.

Comparez l’enregistrement du serveur à la liste reçue. L’écart entre les deux est la couche de politique, et il est généralement plus petit que le profil ne le suggère.

Quand la conception le permet, résumez les réseaux contigus et supprimez les entrées obsolètes. Des routes moins nombreuses et plus larges règlent plus de cas qu’un plafond plus élevé.

Changez le nombre au bon endroit

Utilisez le réglage documenté du composant qui détient réellement la limite. Si le champ manque dans le greffon, vérifiez si le greffon est antérieur à la fonction ou si un autre socle détient les routes. Documentez ensuite les versions du moteur, du greffon et du serveur à côté de la valeur choisie. La prochaine mise à niveau rouvre la question, et la note est ce qui la rend soluble.

Retestez après toute mise à niveau de l’un des trois. Une limite relevée au bon endroit bouge quand même lorsque le composant qui l’applique change. L’enregistrement des versions est la seule chose qui rend ce mouvement prévisible.