Parmi toutes les directives de configuration géniales d'OpenVPN, j'en ai encore découverts deux : config
et local
.
La première, config
, permet d'inclure un ou plusieurs fichiers de configuration dans un autre fichier de configuration. C'est extrêmement utile pour factoriser votre configuration quand vous avez plusieurs isntances (UDP et TCP, sécurisée et moins sécurisée, etc.).
La deuxième, local
permet d'écouter sur une ou plusieurs IP spécifiées au lieu d'écouter sur toutes les interfaces réseaux. Bon, forcément, vous perdez la fonctionnalité de Linux qui permet d'écouter en IPv6 et en IPv4 en même temps, avec la même socket. Du coup, il vous faudra plusieurs instances : une v4, une v6. Pour peu que vous ayez déjà une instance udp et une instance tcp, ça vous fera 4 instances.
J'ai utilisé la deuxième option pour monter deux VPN dans une même VM : l'un proposant un chiffrement du canal de transport des données en Blowfish + SHA-1 (la config' par défaut depuis des années) et l'autre proposant un chiffrement AES-128 + SHA-256. On route 2 IPv4 et v6 jusqu'à la VM, on attribue les IP sur l'interface. Ensuite, on souhaite associer chaque VPN à une IP. Ce type de configurations permet de conserver un ancien VPN avec un chiffrement qui tend à être démodé aujourd'hui tout en mettant en prod' un VPN avec un chiffrement plus fort pour qu'il puisse être essayé par les utilisateur-rice-s car le chiffrement peut impacter le débit (bon, pas sur l'ADSL, faut pas charrier) et la latence sous certaines conditions, voir : https://shaarli.guiguishow.info/?r6npkg. Au total, on se retrouve avec 8 processus OpenVPN, 8 instances : legacy ipv4 udp, legacy ipv4 tcp, legacy ipv6 udp, legacy ipv6 tcp et la même chose pour le VPN au chiffrement différent. :D
Pourquoi ne pas avoir mis le VPN de test dans une autre VM ?
Parce que ça pose un problème de routage dans notre infra. Hé oui, par défaut, les blocs d'adresses IPv4 et v6 que nous dédions à notre service de VPn sont routés sur le VPN "classique". mais il faut bien que les IPs des aboné-e-s qui testent le VPN "renforcé" soient routées sur l'autre VM. Ça suppose d'utiliser un protocole de routage dynamique pour que l'utilisateur-rice puisse tester en changeant de VPN (classique ou renforcé) à volonté. Sauf que ce routage pose problème.
Si l'on monte 2 sessions BGP (une avec chacun de nos routeurs), ça foire lorsque la VM est sur le routeur qui n'est pas équipé de Quagga. Car, du point de vue de ce routeur Quagga, le next-hop est alors récursif : le next-hop du VPN est l'IP de la VM, le next-hop de la VM, c'est l'autre routeur. Or, Quagga refuse la récursivité quand elle consiste à piocher dans autre chose que des routes statiques ou des routes apprises grâce à un protocole de routage interne. Vieux principe Cisco. Or, nous utilisons exclusivement BGP puisque nos deux routeurs sont les seuls routeurs de notra infra.
Une piste possible est de monter deux sessions BGP et d'envoyer les routes uniquement au routeur-hyperviseur sur laquelle la VM se trouve présentement. Celui-ci sera chargé de le re-annoncer en iBGP à l'autre routeur et vu qu'on écrase le next-hop sur cette session iBGP, ça fonctionnerait. C'est du routage conditionnel. Ça se fait plutôt bien avec ExaBGP, il nous faut juste écrire le programme kiVaBien. Juste, ça sera un while(true) bien monstrueux (ben oui, quoi d'autre pour vérifier si la VM n'a pas changé d'hyperviseur-routeur ?).
Si l'on monte une seule session BGP, uniquement avec le routeur-hyperviseur sur lequel la VM est active présentement, il faut le faire sur une IP locale au lien sinon les deux sessions se monteront automatiquement. Cela fonctionne en IPv4 mais en IPv6, il est impossible de monter une session sans préciser l'interface… sauf qu'avec Ganeti, on ne la connaît pas à l'avance donc impossible de la mettre dans la configuration du routeur BGP. On peut faire un mix incluant neighbor IPv6 globale et source-address locale + multihop mais BIRD ne supporte pas (ce qui est logique, c'est totalement illogique).
De plus, si on a qu'une seule session active à la fois, le monitoring va gueuler (bah oui, y'a une session configurée mais down, c'est bien son rôle de prévenir). Certes, on peut re-écrire le check pour exclure la session BGP avec la VM VPN.