Où placer la route dans OpenVPN : côté client ou côté serveur ?
Une route brute dans la configuration du serveur modifie le serveur, pas le client. Choisissez le fichier du client, un push global ou un push pour un client, puis vérifiez ce qui est arrivé.
Vous ajoutez route 10.60.0.0 255.255.255.0 à la configuration du serveur, vous redémarrez, vous reconnectez un ordinateur portable, et le sous-réseau reste injoignable depuis cet ordinateur. La ligne a été acceptée, le service a démarré proprement, et rien dans le journal ne semble anormal. Ce qui s’est passé, c’est que la route a été installée sur la machine que vous avez modifiée : la passerelle croit désormais pouvoir atteindre ce préfixe, tandis que le client n’a jamais rien su. L’emplacement est toute la question, et il existe quatre endroits où la même ligne peut vivre.
Les quatre emplacements et qui reçoit chacun
Une route peut être ajoutée par la configuration propre au client, proposée à tous les clients via un push global, proposée à un seul client via un fichier propre à ce client, ou écrite dans le contexte de routage du serveur lui-même.
Ces quatre cas utilisent une syntaxe presque identique et produisent des résultats totalement différents. Les trois premiers influencent ce qu’un client envoie dans le tunnel ; le quatrième influence la façon dont le serveur atteint un réseau, ce qui est utile lorsque le serveur lui-même a besoin d’un chemin et nuisible lorsqu’on le confond avec une distribution.
Décidez lequel des quatre vous voulez avant d’écrire la ligne, puis confirmez le destinataire.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
Pourquoi la route brute côté serveur surprend
La configuration du serveur est le premier endroit où les administrateurs regardent, et une directive de route y ressemble à une affirmation sur le réseau VPN. Ce n’est pas le cas. OpenVPN la traite comme une installation de route locale sur la machine qui exécute le démon, soit exactement le même type de changement que vous feriez avec ip route puis oublieriez.
La distribution exige que la route soit poussée, et le push exige que le client la tire. Un client démarré avec les options tirées désactivées ignore complètement l’offre. Vérifiez les deux extrémités de cette poignée de main avant de réécrire le fichier du serveur, car le journal du serveur ne se plaindra pas : de son côté, l’offre a été envoyée. Une route acceptée n’entre d’ailleurs en vigueur qu’à la prochaine connexion, jamais dans la session où vous êtes déjà.
Une fois les deux opérations vues comme distinctes, la panne cesse d’être mystérieuse : le serveur atteint le préfixe, le client non, et les deux affirmations sont vraies en même temps.
Fichiers par client et l’identité à laquelle ils correspondent
Un fichier propre à un client est nommé d’après l’identité que le serveur a authentifiée, qui est par défaut le nom commun du certificat. Un nom de connexion convivial dans un client de bureau n’est pas cette valeur, et une discordance produit un fichier qui n’est jamais lu.
Vérifiez le répertoire que le serveur utilise réellement, puis confirmez que le nom du fichier correspond exactement à l’identité authentifiée, majuscules et minuscules comprises.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Dans ce fichier, la route doit encore être poussée, car le contexte par client est un ensemble d’options appliquées à la session de ce client, pas une table de routage locale. Une route brute y pose le même problème qu’une route brute dans le fichier global.
Le fichier propre au client et l’outil qui le gère
Une route placée dans la configuration du client est installée lorsque ce client se connecte et retirée lorsqu’il se déconnecte, ce qui est le cycle de vie correct pour une destination statique.
Si un gestionnaire de réseau possède le profil, il peut importer ces options une fois puis conserver sa propre copie. Modifier ensuite le fichier téléchargé ne change rien, ce qui est une cause fréquente du "la route est là mais ne s’applique pas".
Vérifiez le profil actif plutôt que le fichier téléchargé, et vérifiez les paramètres importés que le gestionnaire affiche. Connectez-vous ensuite et demandez au système quel chemin utilise une adresse précise, au lieu de supposer que le tunnel a gagné parce que la route existait dans un fichier texte.
Vérifiez sur le client, puis contrôlez le chemin de retour
Interrogez la table de routage propre au client pour la destination, pas celle du serveur. Une recherche pour un seul hôte dans le préfixe suffit à montrer l’interface et le prochain saut qui seront utilisés.
ip route get 10.60.0.10Si la recherche pointe vers le tunnel, la distribution a fonctionné et le problème restant est ailleurs. Si elle pointe vers la passerelle par défaut, la route n’a pas été installée, a été filtrée par une option côté client, ou appartient à un profil que le client n’utilise pas.
Supposez que la distribution a fonctionné et que rien ne répond encore : vérifiez alors le transfert sur la passerelle, la route de retour de l’autre côté et tout pare-feu entre eux. Une route choisit un chemin, elle n’accorde pas l’accès.