OpenVPN iroute ou route du noyau : laquelle manque ?

Un paquet destiné à 10.77.20.0/24 prend deux décisions distinctes sur un serveur OpenVPN : le système d’exploitation doit le remettre à l’interface VPN, et OpenVPN doit savoir quel client connecté possède ce préfixe. Une route du noyau absente le jette avant le tunnel, une route du pair absente le jette après. Les deux pannes se ressemblent depuis le LAN distant, et diagnostiquer laquelle vous avez demande une commande de chaque côté.

Dans le chemin de données classique en espace utilisateur, la route du noyau amène le paquet au processus du tunnel et iroute indique à ce processus quel pair doit le recevoir. Aucune ne remplace l’autre, et une configuration qui n’en porte qu’une seule semblera raisonnable jusqu’au premier ping.

Deux décisions, pas une seule route

Imaginez une liaison de site à site où 10.77.20.0/24 se trouve derrière un seul client. La route du noyau du serveur, par exemple ip route add 10.77.20.0/24 dev tun0, envoie les paquets correspondants vers le périphérique du tunnel. OpenVPN consulte ensuite sa propre table interne, construite à partir des entrées iroute du répertoire de configuration du client, pour décider quelle connexion de pair les reçoit. Sans la route du noyau, le paquet n’atteint jamais le processus, et sans la route du pair, il atteint le processus et ne va nulle part.

Cette séparation s’oublie facilement, car une seule ligne de route dans un profil client peut sembler faire les deux tâches. Elle ne les fait pas : pousser une route indique aux clients quoi envoyer dans le tunnel, tandis que iroute indique au serveur qui possède une plage d’adresses derrière un client. Elles vivent dans des fichiers différents, sont lues par des côtés différents et échouent dans des directions opposées.

Où va iroute et ce qu’il dit

L’entrée va dans un fichier par client nommé d’après le common_name du client, sous client-config-dir, sous la forme iroute 10.77.20.0/24. La correspondance du nom de fichier n’est pas cosmétique : OpenVPN recherche l’identité authentifiée et lit le fichier portant exactement ce nom, si bien qu’un fichier nommé site-a ne prend effet que pour un client dont le nom commun est site-a. Ajoutez ccd-exclusive si les clients dépourvus d’un tel fichier doivent être refusés d’emblée, ce qui est le bon réglage quand chaque client est une passerelle de site. Gardez un fichier par passerelle et nommez-le d’après le sujet du certificat que vous émettez réellement.

Testez l’entrée depuis le serveur avant d’accuser le LAN distant. Le fichier d’état liste les clients connectés avec leurs noms communs, et un serveur exécuté avec --verb 4 journalise l’installation d’iroute au moment où le pair se connecte. Si rien n’apparaît à la connexion, le fichier est dans le mauvais répertoire ou nomme la mauvaise identité.

Le piège : fichier présent, identité erronée

Un iroute d’apparence correcte attaché au mauvais pair fait perdre plus de temps qu’un fichier absent, car tout sur le disque semble correct. Le renommage de certificats, les noms communs en double et username-as-common-name changeant l’identité effective le produisent tous. Vérifiez l’identité que le serveur a authentifiée plutôt que celle que vous attendiez : la sortie d’état fait foi, tandis que le nom de fichier n’est qu’une clé de recherche.

Une route peut aussi survivre à son propriétaire. Les routes statiques et les entrées iroute décrivent un préfixe, pas une garantie de disponibilité, si bien que le trafic peut continuer d’être routé vers un pair actuellement déconnecté.

Achevez le chemin au-delà du pair

La propriété du pair est le milieu du chemin, pas la fin. Le client doit transmettre les paquets du tunnel vers son LAN, ce qui suppose le transfert IP activé sur cet hôte et une règle de pare-feu autorisant le transit. Les hôtes du LAN distant ont besoin d’un chemin de retour pour l’adresse du tunnel : soit une route pointant vers la passerelle, soit une conception NAT délibérée côté client. Confirmez le réglage de transfert sur le client avec sysctl net.ipv4.ip_forward au lieu de supposer une valeur par défaut de la distribution.

Si d’autres clients VPN doivent atteindre ce sous-réseau, l’agencement grandit encore : le serveur a besoin de client-to-client, et ces clients doivent router le préfixe par le tunnel. Rien de tout cela n’est impliqué par la table de routage du serveur lui-même.

Vérifiez une destination depuis une source réelle plutôt que depuis le serveur lui-même. Un ping d’un hôte LAN sans rapport vers un hôte derrière le client exerce le chemin de retour, la règle de transfert et la propriété du pair en un seul geste, alors qu’une poignée de main réussie ne prouve que l’identité. Déconnectez ensuite le pair propriétaire et notez ce que fait la route, car cette réponse est votre mode de défaillance.