Routes poussées par OpenVPN non installées : timing, droits ou politique

Le serveur dit avoir poussé la route, le client dit être connecté, et la destination reste injoignable. Trois causes produisent exactement cette image. L’ajout de la route s’est exécuté avant que l’appareil existe, le client manquait des droits nécessaires pour modifier la table, ou une politique lui a ordonné d’ignorer les options poussées.

De l’extérieur, elles se ressemblent et exigent des corrections différentes. Lisez le journal du client à l’endroit où la décision de route est prise.

Prouvez que la route est absente, pas seulement cassée

Commencez par prouver que la route est absente plutôt que cassée. Sous Linux, ip route show dev tun0 liste ce que le client a installé sur l’appareil de tunnel. Sous Windows, route print ou Get-NetRoute montre la même chose sous forme de tableau.

Une route qui existe mais ne transmet pas le trafic est un autre problème. Cela déplace l’enquête vers les règles de transfert et de pare-feu, pas vers l’installation de la route.

Timing : l’ajout s’est exécuté avant que l’appareil existe

Le client analyse le PUSH_REPLY du serveur une fois le canal de contrôle monté et après avoir configuré l’interface. C’est seulement alors qu’il touche à la table de routage, avec le mécanisme que fournit la plateforme. Linux passe par netlink ; Windows utilise une API qui exige un jeton élevé. Un script ou un client qui ajoute des routes dès qu’il lit la configuration peut s’exécuter avant que l’appareil TUN/TAP existe, et le noyau rejette l’ajout.

La même course explique pourquoi une route tapée à la main fonctionne alors que l’automatique non : au moment où vous la tapez, l’interface est déjà montée.

route-delay existe pour ce cas, et route-up nomme un script qui s’exécute après la configuration de l’interface et des routes. Placez les routes qui dépendent de l’adresse du tunnel dans ce hook plutôt qu’à une étape précoce.

Droits : qui peut modifier la table

Modifier la table de routage de Windows exige un jeton élevé. Une GUI lancée par un utilisateur standard peut définir l’adresse de l’adaptateur via le service et rester incapable d’ajouter une route. Le journal affiche alors une erreur de type accès refusé plutôt qu’un push manquant.

Lancer la GUI en tant qu’administrateur, ou utiliser le client basé sur le service, change ce résultat. Une tâche planifiée qui lance le client sans le jeton requis ne le change pas.

Vérifiez sous quel compte le client s’exécute réellement avant de changer quoi que ce soit. La version et le mode de service décident des causes possibles, alors notez les deux à côté de la sortie de route.

Politique : les routes poussées peuvent être écartées volontairement

route-nopull fait ignorer au client les routes que le serveur pousse, y compris une route par défaut poussée, tandis que l’adresse du tunnel est toujours acceptée. Les options DNS et DHCP poussées sont écartées par la même directive. Un tel client n’est pas défectueux ; il attend des lignes de route explicites dans sa propre configuration.

route-noexec est un autre contrôle : il empêche complètement le client d’exécuter des changements de route. Une topologie que le client ne peut pas cartographier peut produire un résultat similaire, la route étant journalisée comme rejetée plutôt qu’ajoutée. Lisez la ligne de journal qui rapporte la décision au lieu de deviner laquelle des trois s’applique. Vérifiez ensuite le profil effectif, car un importateur ou un outil de gestion peut ajouter des options que l’utilisateur n’a jamais modifiées.

Un profil qui semble propre dans un éditeur de texte peut encore porter une directive ajoutée à l’exécution.

Comparez la liste de push au tableau

Après la connexion, placez la liste de push du serveur à côté du tableau du client. Sous Linux, c’est ip route show dev tun0 ; sous Windows, route print ou Get-NetRoute. Si la route est absente, corrigez d’abord l’installation. Si elle est présente et que le trafic échoue, passez à la politique de transfert et de pare-feu.

Notez la version du client, le compte sous lequel il s’exécute et s’il est basé sur le service. Ces trois faits indiquent à la personne suivante quelles causes ont été écartées.