Un concentrateur OpenVPN, trois LAN : plan d’adressage et fichiers iroute

Trois LAN privés peuvent se retrouver sur un seul concentrateur sans qu’aucun site n’apprenne l’intérieur des autres, et toute la conception repose sur quatre courtes décisions de configuration. Ce qui la fait fonctionner n’est pas une fonctionnalité exotique du protocole, mais un plan d’adressage que personne n’a besoin de deviner, plus des routes par client qui indiquent au concentrateur quelle branche possède quel préfixe. Trompez-vous sur l’une ou l’autre et le tunnel monte quand même, et c’est précisément ce qui rend la panne déroutante.

Parcourez les étapes dans l’ordre. Chacune dépend du plan de l’étape précédente, et aucune n’exige une nouvelle autorité de certification.

Commencez par un plan que personne n’a besoin de deviner

Notez quatre préfixes disjoints avant de toucher à un fichier de configuration : le LAN du concentrateur lui-même, le LAN de chaque branche et le pool remis aux clients itinérants. La disjonction est ce qui garde tout le reste simple, car des plages qui se chevauchent transforment le routage en casse-tête de la plus longue correspondance qu’aucune configuration par client ne répare. Confirmez ensuite quelle machine est la passerelle par défaut de chaque LAN, car un routeur de branche qui n’est pas la passerelle de son LAN a besoin des routes distantes installées ailleurs. Enfin, fixez les noms authentifiés qui identifient chaque branche, car ce sont ces noms qui servent de clés pour retrouver les fichiers par client.

Un plan illustratif garde le pool bien à l’écart des trois LAN. Le vôtre sera différent, et la seule règle stricte est que deux plages ne se chevauchent pas.

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

Dites au noyau du concentrateur où se trouvent les branches

Le concentrateur a besoin de deux informations par branche : une route dans le noyau qui envoie le préfixe dans l’interface de tunnel, et une iroute entrée qui dit au OpenVPN processus quel client la possède. La route du noyau seule achemine les paquets vers le tunnel et s’arrête là, car le démon doit encore décider quel pair doit les recevoir. L’entrée iroute seule laisse ces paquets dans le noyau sans route à suivre. Les deux lignes appartiennent à la configuration que le démon charge réellement, ce qui vaut la peine d’être vérifié avant de déboguer quoi que ce soit d’autre.

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

Désactivez client-à-client lorsque le noyau doit être le point d’application. Cette option relaie le trafic entre pairs à l’intérieur du démon, ce qui est pratique et signifie aussi que vos règles de transfert ne voient jamais le flux. Tout ce qui suit suppose que le noyau voit chaque paquet entre branches.

Donnez à chaque branche les routes dont elle a besoin

Chaque branche a besoin de routes vers les autres branches et vers le LAN du concentrateur, et n’a pas besoin de route vers son propre LAN connecté. Poussez les préfixes distants depuis le concentrateur au lieu de les coller dans chaque routeur, afin qu’un quatrième site plus tard signifie un nouveau fichier par client au lieu de quatre modifications. Le fichier par client porte aussi la ligne iroute, qui garde la propriété et l’annonce au même endroit. Rendez le répertoire et ses fichiers lisibles selon le modèle de privilèges du serveur, sinon la recherche échoue sans message.

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

Un quatrième site suit le même schéma : un nom authentifié distinct, un préfixe possédé, une route dans le noyau du concentrateur, une iroute entrée et des annonces uniquement aux sites autorisés à l’atteindre.

Testez dans les deux sens avant de le déclarer terminé

Activez le transfert IPv4 sur les trois routeurs, puis confirmez que le pare-feu autorise les flux prévus dans les deux sens, car un test unidirectionnel passe avec un chemin de retour cassé plus souvent qu’on ne l’attend. Aucune traduction de source n’est nécessaire entre sites, et c’est la préservation de la source d’origine qui permet à chaque branche d’appliquer sa propre politique à une requête.

Testez depuis un hôte du LAN d’une branche vers un service d’une autre, puis inversez le sens, puis testez depuis une branche vers le LAN du concentrateur. Ces trois résultats sont des preuves différentes, et aucun n’implique les autres. Si un routeur de branche n’est pas la passerelle par défaut de son LAN, installez les préfixes distants sur la vraie passerelle et incluez aussi le pool lorsque les clients du tunnel doivent initier des connexions vers ce LAN.

Consignez le plan, les fichiers par client et les règles du pare-feu dans un seul document, car le prochain ajout de site sera jugé à leur aune.

La conception tient ensemble parce que chaque couche a un rôle : le plan garde les préfixes uniques, la route du noyau déplace les paquets, l’entrée iroute nomme le propriétaire, et le pare-feu décide de ce qui est autorisé. Quand quelque chose casse, cette liste est aussi l’ordre dans lequel le vérifier.