VPN on Zwindler's Reflection

Un cluster Kubernetes gratuit pour vos labs persos ! - part 2

Tue, 23 May 2023 18:00:00 +0200

Cet article fait partie d’une suite d’articles sur l’installation d’un cluster Kubernetes sur le free tier d’Oracle Cloud Infrastructure :

L’avantage principal de ce tuto est qu’il est gratuit. L’inconvénient est que l’installation est relativement longue…

“Résumé des épisodes précédents”

Dans l’article précédent (que vous pouvez retrouver ici), on avait pris en main Oracle Cloud et installé k3s sur deux machines ARM du free tier.

A l’issue de l’article, on avait donc, pour rappel, un cluster Kubernetes fonctionnel avec un master et un worker, mais pas encore accessible ni vraiment utilisable sur Internet.

Dans cette partie, on va donc finaliser tous les petits bouts qui manquent pour avoir quelque chose de vraiment propre.

Creuse ton tunnel

Comme je le dis juste avant, on a un cluster fonctionnel. Si je me connecte sur la machine controlplane et que je lance la CLI kubectl, je pourrais interagir avec mon cluster Kubernetes.

Cependant, il est très probable que vous vouliez accéder à votre cluster flambant neuf sans avoir à vous connecter préalablement en SSH sur votre machine (enfin moi, c’est mon cas).

Et je n’ai pas envie non plus de publier l’API server (port 6443) de mon control plane sur Internet (en soi pour du POC, c’est faisable, mais ça ne me dit rien, perso).

Je vais donc monter un VPN wireguard entre ma machine et mon control plane. Dans un setup plus “pro”, on montera un bastion dans notre LAN privé du cloud provider pour ça. Ici, pour les besoins de l’article, je me contente de monter le peer directement entre le node controlplane et mon PC.

J’installe d’abord wireguard sur les deux machines, et je génère un couple clé publique/privée :

$ sudo apt install wireguard

$ sudo -i
$ cd /etc/wireguard/
$ umask 077; wg genkey | tee private.key | wg pubkey > public.key
$ exit

Récupérez le contenu de la clé publique de chaque machine, ainsi que leur IP publique.

Note : pour trouver rapidement l’IP publique de chez vous, vous pouvez utiliser des services comme dig +short myip.opendns.com @resolver1.opendns.com, curl http://4.ifcfg.me ou équivalent

Ensuite, je vais créer un fichier de configuration /etc/wireguard/oci0.conf sur mon pc. Dans mon cas, l’interface réseau s’appelle enp8s0

$ sudo -i
$ PEER_IP=IP.PUBLIQUE.DU.CONTROLPLANE
$ PEER_PUBLIC_KEY=CLE.PUBLIQUE.DE.VOTRE.CONTROLPLANE
$ cat > /etc/wireguard/oci0.conf << EOF
[Interface]
Address = 10.10.10.1/24
ListenPort = 55555
PrivateKey = `cat /etc/wireguard/private.key`

[Peer]
PublicKey = ${PEER_PUBLIC_KEY}
AllowedIPs = 10.10.10.2/32,10.0.0.0/24
Endpoint = ${PEER_IP}:55555
EOF
$ exit
$ wg-quick up oci0

Et on fait pareil sur le node controlplane (son interface réseau s’appelle enp0s6 dans mon cas).

$ sudo -i
$ PEER_IP=IP.PUBLIQUE.DU.PC
$ PEER_PUBLIC_KEY=CLE.PUBLIQUE.DE.VOTRE.PC
$ cat > /etc/wireguard/oci0.conf << EOF
[Interface]
Address = 10.10.10.2/24
ListenPort = 55555
PrivateKey = `cat /etc/wireguard/private.key`

[Peer]
PublicKey = ${PEER_PUBLIC_KEY}
AllowedIPs = 10.10.10.1/32
Endpoint = ${PEER_IP}:55555
EOF
$ exit
$ wg-quick up oci0

Comme les machines OCI disposent toutes d’un pare-feu iptables et aussi d’un pare-feu au niveau du réseau virtuel, on doit ouvrir les ports côté controlplane

# allow wireguard access from your own public IP address
$ iptables -I INPUT -s IP.PUBLIQUE.DU.PC -p udp --dport 55555 -j ACCEPT

# save rules
$ sudo netfilter-persistent save

Et côté console Oracle Cloud (Security list dans l’administration du VCN, je vous renvoie au précédent post où je détaille comment faire)

A partir de maintenant, votre PC à l’IP 10.10.10.1 et votre control plane l’IP 10.10.10.2. Les deux doivent pouvoir se pinger :

$ ping 10.10.10.1
$ ping 10.10.10.2

On devrait aussi pouvoir ping l’IP privée (interne) de notre controlplane depuis notre pc

$ ping 10.0.0.xxx

Si wireguard vous intéresse, il existe énormément de documentation sur Internet à ce sujet, à commencer par le site officiel.

Accéder au cluster depuis votre poste

On a maintenant un tunnel pour discuter de notre PC vers notre control plane Kubernetes, mais toujours pas la possibilité de discuter avec Kubernetes. Il reste encore une règle iptables à ajouter 😭.

Pour s’en convaincre, on tente de voir si le port répond depuis notre PC :

$ nc -zv 10.10.10.2 6443
nc: connect to 10.10.10.2 port 6443 (tcp) failed: No route to host
$ nc -zv 10.0.0.xxx 6443
nc: connect to 10.0.0.xxx port 6443 (tcp) failed: No route to host

Côté controlplane, on va donc autoriser le traffic provenant de wireguard (interface oci0) à se connecter à l’API server

# allow access to apiserver from wireguard interface
$ sudo iptables -I INPUT -i oci0 -p tcp --dport 6443 -j ACCEPT

# save rules
$ sudo netfilter-persistent save

Et maintenant, depuis notre PC :

$ nc -zv 10.10.10.2 6443
Connection to 10.10.10.2 6443 port [tcp/*] succeeded!
$ nc -zv 10.0.0.xxx 6443
Connection to 10.0.0.34 6443 port [tcp/*] succeeded!

Récupérez le contenu du fichier /etc/rancher/k3s/k3s.yaml sur le serveur controlplane. Créez un fichier k3s.yaml sur votre machine et remplacez la valeur server: https://127.0.0.1:6443 par server: https://10.10.10.2:6443.

Vous devriez maintenant avoir accès à votre cluster depuis votre PC !

$ export KUBECONFIG=k3s.yaml
$ kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system helm-install-traefik-crd-xdg7s 0/1 Completed 0 29d
kube-system helm-install-traefik-ncqzm 0/1 Completed 1 29d
kube-system svclb-traefik-084208f2-dcsqr 2/2 Running 0 29d
kube-system local-path-provisioner-5d56847996-x76zx 1/1 Running 5 (29d ago) 29d
kube-system svclb-traefik-084208f2-zw6bv 2/2 Running 7 (29d ago) 29d
kube-system coredns-7c444649cb-gg22s 1/1 Running 3 (29d ago) 29d
kube-system metrics-server-7b67f64457-r5c5n 1/1 Running 5 (29d ago) 29d
kube-system traefik-56b8c5fb5c-px5pc 1/1 Running 3 (29d ago) 29d

Ouverture des ports pour Traefik

On peut maintenant interagir avec Kubernetes, mais on ne peut toujours pas en faire grand-chose. Je suis certain que vous allez déployer des applications web sur votre cluster et c’est quand même plus cool d’y accéder depuis Internet :-p.

Par défaut, k3s installe l’IngressController traefik. Vous l’avez deviné… on va devoir ouvrir des flux !

Si vous regardez sur quels IPs/ports traefik est disponible sur votre cluster, vous remarquerez que Traefik utilise un service de type LoadBalancer, directement accessible sur l’IP privée de vos machines (10.0.0.x et 10.0.0.y dans cet exemple)

kubectl -n kube-system get svc traefik
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
traefik LoadBalancer 10.43.44.139 10.0.0.xxx,10.0.0.yyy 80:30614/TCP,443:30839/TCP 42m

Dans OCI, ça sera pratique, on va pouvoir attaquer directement le port 80/443 de nos serveurs et avoir l’IngressController au bout du fil.

$ curl http://10.0.0.xxx
404 page not found

Ne vous laissez pas tromper par l’erreur 404. Le fait qu’on nous réponde une erreur 404 prouve que traefik répond bien !

Sur les DEUX machines (control plane ET worker), on va autoriser l’accès au port 80 depuis partout :

# allow access to HTTP 80 from everywhere
$ sudo iptables -I INPUT -p tcp --dport 80 -j ACCEPT
# save rules
$ sudo netfilter-persistent save

Mais on va probablement vouloir exposer ça sur Internet et les IP privées sont… privées. On va donc créer un load balancer en frontal, ça nous permettra de diriger le trafic sur tous les noeuds du cluster, pas juste un seul (ça ferait un SPOF en plus).

Créer un Loadbalancer

Dans l’onglet Networking, on va sélectionner Loadbalancer (ici)

Suivez le wizard, choisissez un Load balancer (L7)

Puis donnez-lui un petit nom (kube-traefik-lb par exemple), laissez Public (choix par défaut), sélectionnez votre VCN et votre subnet.

Au moment de choisir les “backends”, cliquez sur “Add backends” et ajoutez vos 2 machines (c’est Kubernetes et flannel qui se chargent de rediriger les requêtes au bon endroit)

Laissez le port 80 par défaut, puisqu’on vient de vérifier que ces ports répondent bien à curl http://10.0.0.xxx (pas besoin d’utiliser le NodePort, pour ceux qui savent de quoi je parle). Laissez aussi les paramètres par défaut pour la “health check policy”, SAUF pour le code retour attendu (puisque notre traefik renvoie 404 si aucun Ingress ne matche l’“host” envoyé par la requête).

Dans la page d’après dans “configure Listener”, si vous avez un certificat TLS valide, vous pouvez l’intégrer au loadbalancer avec l’option “Load balancer managed certificate” dans le cadre “SSL certificate”. Vous pouvez aussi gérer les certificats depuis Oracle Cloud Infrastructure. Je n’ai pas exploré cette option mais c’est très standard chez les cloud providers.

Sinon, cliquez sur “HTTP”.

Une fois le LoadBalancer créé, il devrait devenir “vert” et vous pourrez récupérer son adresse IP publique pour y accéder.

Conclusion

Vous êtes arrivés jusque-là. Bravo !

Vous pouvez déployer des applications web avec des Ingress et faire pointer vos enregistrements DNS sur l’IP du LoadBalancer. Les requêtes HTTP seront correctement routées sur un des deux serveurs Kubernetes, puis vers Traefik, puis vers votre appli.

J’ai fait le test avec une image Docker personnelle (utilisée pour mon dernier talk) et ça a marché :-).

On a fait plus d’iptables que de Kubernetes mais bon c’est pas très grave 😅. Ca aura été une excuse pour tester le free tier d’Oracle et de tester un peu le fonctionnement de ce cloud provider assez peu connu en France (je trouve).

Autres blogs posts utiles

Créer un VPN distribué avec Tinc

Mon, 17 Feb 2020 07:30:00 +0000

Faire un VPN Tinc fullmesh sans monter un gros réseau IPSec

Un des gros problèmes que j’ai rapidement eu à régler lorsque j’ai voulu monter des clusters de serveurs Proxmox VE chez des providers de serveurs physiques, c’est la façon dont est gérée le clustering dans PVE.

Les concepteurs de PVE ne veulent pas que l’on monte des clusters sur Internet et mettent volontairement le plus de bâtons dans les roues pour vous empêcher de le faire. J’exagère à peine.

En version 5.x, PVE se basait sur la version 2 de corosync par multicast (bloqué par tous les providers) et qu’en v6.x, on nous bride en demandant explicitement un sous réseau LAN dédié, autant dire qu’on est pas aidé.

OpenVPN vs Tinc

Une solution que j’ai expérimenté est de monter un serveur OpenVPN sur un des serveurs et de connecter les autres dessus. J’ai d’ailleurs fait un tuto là dessus pour PVE.

Cette approche n’est pas optimale : si on a 2 machines, c’est bon, mais si on en a 3 ou plus, on se retrouve soit avec un SPOF, soit à devoir monter un maillage complexe de couples serveur-client. Au delà de 3, c’est pratiquement ingérable.

Au contraire, Tinc est un logiciel libre (GPLv2) permettant de monter des VPNs multipoints (full mesh routing) entre des machines sur Internet. Tinc est prévu pour notre cas d’usage !

le vrai logo de Tinc (la photo en haut du blog c’est Supercopter, of course)

On sécurise

Comme tout service “ouvert” sur Internet, il est évidemment nécessaire de faire du firewalling pour bloquer le trafic malveillant. Pour information, Tinc utilise le port 655 en TCP et UDP, que vous devrez donc ouvrir dans les deux sens entre l’ensemble de vos serveurs, mais bloquer pour le reste d’Internet.

A noter, ce n’est pas confirmé mais la page principale de Tinc indique qu’il est possible que ce logiciel (tout comme OpenVPN, Wireguard et IPSec) soit vulnérable à la CVE-2019-14899.

On l’installe et on le configure

On va devoir installer le package/binaire sur toutes les machines du VPN. Pas trop de soucis de ce côté, tinc est multiplateforme (Windows aussi) et est packagé dans de nombreuses distrib Linux. Sur les dépôts Debian, tinc est présent sans souci et j’imagine que ça sera le cas pour d’autres distribs aussi.

apt install tinc

Une fois installé, on peut créer notre VPN. Pour déclarer un VPN, il faut ajouter le nom de celui ci dans un fichier de configuration global :

echo "vpnzwindler" >> /etc/tinc/nets.boot

On créé ensuite un répertoire du même nom, contenant lui même un dossier hosts.

mkdir -p /etc/tinc/vpnzwindler/hosts

Dans ces dossiers, on va créer fichier de configuration, /etc/tinc/vpnzwindler/tinc.conf. Ce fichier va nous permettre de décrire le node courant et qui doit se connecter à qui.

Name = node01
AddressFamily = ipv4
Address = 1.1.1.1
Device = /dev/net/tun
Mode = switch
ConnectTo = node02
ConnectTo = node03
ConnectTo = node04
[...]

Dans les informations importantes, Name va être le nom (arbitraire) du node pour tout le VPN, Address représente l’adresse IP publique de votre node, et ConnectTo, la liste des autres Names des autres nodes.

A partir de là, on peut demander à tinc de nous générer des couples clé publique/clé privée pour tous nos serveurs. Sur tous les nodes du VPN, lancer :

echo -e '\n\n' | tincd -n vpnzwindler -K4096

Si tout se passe bien et que tous les fichiers de conf et dossiers ont été créés correctement, tinc devrait créer un couple clé privée/clé publique, puis créer un fichier /etc/tinc/vpnzwindler/hosts/node01 (sur celui dont le Name est node01).

Envoyez (par scp par exemple) l’ensemble des fichiers dans le dossier hosts sur tous les serveurs. Maintenant, tous les VPNs sauront quelle IP publique contacter et avec quel clé authentifier le trafic.

Autre méthode : tinc invite / tinc join

Une feature sympa de tinc, mais seulement en 1.1 (la dernière version), est la possibilité d’ajouter des nodes à un VPN existants via une simple commande tinc invite (voir la doc).

Je ne l’ai pas testée mais a priori tinc créé une URL qui permet d’inviter n’importe qui et de configurer son node avec un tinc join.

The whole URL is around 80 characters long and looks like this: server.example.org:12345/cW1NhLHS-1WPFlcFio8ztYHvewTTKYZp8BjEKg3vbMtDz7w4

Configuration du réseau de l’OS

Maintenant qu’on a tous les prérequis, on peut configurer l’aspect réseau de notre VPN. Ça dépend de votre distribution bien sûr (où dans le cas de PVE, si vous utilisez OpenVSwitch ou pas par exemple). Dans le cas d’une Debian récente, on va gérer tout ça avec ip.

Pour gérer cette partie, Tinc va vous demander de créer 2 scripts. Un tinc-up.sh et un tinc-down.sh, respectivement pour le démarrage et l’extinction de l’interface VPN.

cat /etc/tinc/vpnzwindler/tinc-up
#!/bin/bash
/sbin/ip link set vpnzwindler up
/sbin/ip addr add 10.0.0.1/24 dev vpnzwindler
/sbin/ip route add 10.0.0.0/24 dev vpnzwindler
cat /etc/tinc/vpnzwindler/tinc-down
#!/bin/bash
/sbin/ip link set vpnzwindler down
chmod +x tinc-*

Rien de bien compliqué ici, on demande au binaire ip de créer une interface vpnzwindler. Puis on lui affecte l’IP virtuelle 10.0.0.1 (notre node01). Enfin d’ajouter une route pour que tout le trafic du VPN passe par cette interface.

On le démarre

Dernière étape, on va demander à systemd de nous démarrer le vpn qu’on vient de créer dès le démarrage de la machine.

systemctl daemon-reload
systemctl enable tinc@vpnzwindler
systemctl start tinc@vpnzwindler

Et voilà !!! Vous avez maintenant un VPN multipoint simple et efficace !

root@node01 ~ # ping node02
PING node02 (10.0.0.2) 56(84) bytes of data.
64 bytes from node02 (10.0.0.2): icmp_seq=1 ttl=64 time=17.1 ms

Changement de provider, mon hyperviseur sur un dédié Hetzner

Tue, 19 Nov 2019 07:30:00 +0000

Au revoir OneProvider, bonjour Hetzner

Certains d’entre vous m’ont peut être vu me plaindre de OneProvider et plus particulièrement le support avec qui j’ai eu plusieurs accrochages (Spoiler, j’ai migré vers Hetzner).

Sans rentrer dans les détails (j’ai échangé avec certains d’entre vous sur le sujet), après cette déconvenue, j’ai donc cherché une alternative pour héberger mes machines.

Les prérequis étaient d’avoir :

une machine physique
avec suffisamment de RAM (minimum 8 Go, 16 c’est mieux)
idéalement, une gestion des réseaux virtuels entre machines du provider (type RPN ou vRack)
si possible pas un ATOM en CPU (le souci de l’ATOM, c’est que c’est tellement faiblard que ça pénalise les IO)
si possible du VT-x (je n’en ai pas besoin d’en l’absolu, je vais surtout du LXC, mais ça peut dépanner)
si possible du SSD parce que c’est quand même cool
si possible 2 disques pour avoir du RAID ou que je puisse me faire un équivalent (ZFS/ZRAID)
un prix pas trop élevé (genre pas OVH) car j’ai été mal habitué avec les prix agressifs de OneProvider (oui je sais, je l’ai payé avec le support)

L’état du marché

Chez OneProvider, j’avais tout ça pour environ 20-25 euros / mois, à l’exception du réseaux privé virtuel entre machine.

Autant dire qu’on est très loin du premier prix de chez OVH (>60€/mois TTC). Si on descend en gamme chez OVH, on perd le réseau privé virtuel entre machines (vRack) en passant chez SoYouStart et pourtant on est toujours à plus de 42€ / mois TTC. Toujours 2 fois plus cher que OneProvider :-/.

Il faut descendre encore de gamme et passer chez Kimsufi pour trouver des prix comparables dans mes critères (et toujours pas de réseau privé virtuel), avec de vieux CPU et surtout un réseau bridé au 100 Mbps (ce qui est pénible pour les transferts de gros fichiers, les réplications de VMs et les sauvegardes).

J’avais aussi jeté un œil côté Online.net, qui eux proposent sur certaines machines identiques à celles que j’avais avec EN PLUS le graal, un réseau privé virtuel entre dédiés (RPN).

Ces deux configs me disaient vraiment quelque chose… et pour cause ! OneProvider les revends en marque blanche.

Donc c’est exactement les mêmes machines que celle que j’ai pu avoir dans le passé, mais avec le RPN en plus, et un peu plus cher (beaucoup plus cher même).

Ce qui est dommage ici, c’est que le RPN ne soit pas disponible sur les machines un peu plus petites (mon PRA n’est pas aussi gros, juste de quoi faire tourner le blog en cas de gros crash).

Vient alors Hetzner

Ça fait pas mal de fois que je voyais circuler le nom. Des bloggeurs et d’autres confrères en disaient beaucoup de bien, et j’ai voulu aller voir. La première chose intéressante est que Hetzner, comme OVH et Online, propose bien un service de type réseau privé virtuel entre vos serveurs !

Plus de puissance chez Hetzner !

Par contre, quand j’ai vu les machines… au début je me suis dis que ça allait pas le faire…

Voilà leur machine “bas de gamme” :

Pour à peine plus que le moins cher des SoYouStart (un vieux Xeon E3 v2 4c/4t avec 16Go de RAM et 2 HDD), vous avez un tout nouveau Ryzen 5 6c/12t, 64 Go de RAM et un RAID de 2 SSD NVMe de 512 Go.

Bon clairement on était hors budget mais ils avaient piqué ma curiosité avec leurs config fofolles.

Et je suis donc tombé en fouillant un peu sur leur “server auction”, qui est ni plus ni moins que les serveurs de leurs anciennes gammes qu’ils louent à nouveau. Et là c’était déjà plus proche de mon besoin.

Pour un peu plus de 30€/mois soit 50% plus que mon serveur précédent, mais comparable au prix Online, j’ai un i7-4770, 32 Go de RAM et 2 disques “Entreprise”. Soit beaucoup mieux que la machine chez Online.

Quitte à changer, j’ai donc tenté Hetzner et commandé un serveur.

C’est puissant mais… qu’est ce que c’est moche

Bon, l’UI n’est pas follement attrayante. C’est… spartiate.

Dans le menu “Servers”, vous avez une bête liste de vos serveurs avec le numéro de commande, un hostname (une fois que vous l’aurez setté) et un ID (peu parlant). Bof pratique, surtout au début ou si vous en avez beaucoup.

Et quand on sélectionne un serveur, ce n’est malheureusement guère mieux. Les informations importantes éclatées dans un nombre incalculable de menus.

Bref, côté expérience utilisateur, on repassera. Cependant, tout ce qu’il faut pour bien administrer son serveur est là. On finira par s’y retrouver avec un peu d’habitude…

Installation de l’hyperviseur

Pour installer notre serveur, on peut utiliser l’interface web pour installer un Debian, ou passer par l’image de rescue.

J’ai préféré utiliser la 2ème solution, car elle est immédiatement disponible à la livraison du serveur, avec votre clé SSH.

On arrive sur un login on ne peut plus classique, avec un résumé des caractéristiques de vos serveurs.

Point intéressant, il existe un binaire installimage sur l’OS rescue de Hetzner. Il permet, comme son nom l’indique, d’installer une image.

Comme j’utilise Proxmox VE comme hyperviseur, j’ai donc installé une Debian 10 :

Une fois l’image de base choisie, vous allez arriver à un éditeur de texte. Il va vous permettre de configurer de manière plus fine votre installation. Je trouve cette méthode assez originale. Ça change des interfaces webs pas toujours stables vous demandant la taille de vos partitions pour finalement planter dès que vous demandez un truc non standard.

Ici tout a très bien marché, j’ai configuré le hostname, ainsi qu’un RAID soft et un partitionnement LVM.

Là encore, je suis navré qu’on tombe dans le cliché, mais si ce n’est pas “joli” ni “user friendly”, au moins c’est efficace.

Passer de Debian 10 à Proxmox VE 6

Une fois validé, l’image Debian 10 a été copié extrêmement rapidement (une ou deux minutes). Forcément, c’est une “minimal”. Mais bon c’est quand même agréable d’avoir son serveur “up and running” en moins d’une demie heure entre la commande et la fin de l’installation.

Reste donc à installer PVE 6 sur notre dédié Hetzner. Sans trop de surprise, j’ai réutilisé mon playbook Ansible qui configure de A à Z la Debian pour en faire un Proxmox. Pour ceux qui l’ont loupé, c’est par ici que ça se passe.

J’ai juste eu un petit souci lors de l’installation. La debian étant minimale, je n’avais même pas python d’installé. C’est gênant quand on fait du Ansible !

cat inventory_hetzner.yml
all:
children:
proxmoxve:
hosts:
<fqdn_hyperviser>:
ansible proxmoxve -i inventory_hetzner.yml -u root -m ping
<fqdn_hyperviser> | FAILED! => {
"changed": false,
"module_stderr": "Shared connection to <fqdn_hyperviser> closed.\r\n",
"module_stdout": "/bin/sh: 1: /usr/bin/python: not found\r\n",
"msg": "MODULE FAILURE",
"rc": 127
}

Heureusement j’avais déjà eu le souci dans un autre contexte. J’ai donc écris un playbook supplémentaire (dispo sur le Github) pour installer les prérequis manquants.

ansible-playbook -i inventory_hetzner.yml -u root proxmox_python_firstinstall.yml
ansible-playbook -i inventory_hetzner.yml -u root proxmox_prerequisites.yml

Et en quelques minutes, mon Proxmox VE était opérationnel sur Hetzner !

Cluster Proxmox VE, v6 cette fois ci !

Tue, 20 Aug 2019 11:45:00 +0000

Proxmox VE

Et oui, avec la sortie de Proxmox VE 6, je vous avais prévenu : il va y avoir pas mal d’articles là dessus, même si quelques articles sur Kubernetes sont en cours d’écriture aussi ;-).

Fin juillet, j’avais écris un article sur des playbooks Ansible que j’ai écris pour faciliter le déploiement de cluster Proxmox VE. Malheureusement, comme cet article traînait dans mes brouillons, les playbooks ne géraient pas la version 6 (qui venait de sortir) de PVE.

C’est aujourd’hui de l’histoire ancienne puisque, pour tester la v6, j’ai forcément du adapter les playbooks ;-).

Point important, je vais partir du principe que vous n’avez pas la possibilité d’installer Proxmox VE directement avec l’ISO. C’est souvent le cas souvent avec les hébergeurs de serveurs dédiés pas chers (OneProvider par exemple) ou de VMs (OVH, Scaleway, etc).

Car si vous avez la main, le plus simple est bien sûr d’installer l’ISO directement ! Cependant, ce tuto reste utile pour toute la partie mise en VPN et configuration du cluster.

Les prérequis

Dans l’article précédent, pour gagner du temps pour ceux qui veulent juste tester, j’avais mis à disposition un playbook permettant de générer des VMs chez le cloud provider Scaleway (et notamment tirer parti de l’inventaire dynamique proposé par le module développé par Scaleway pour Ansible).

Ici, je met volontairement de côté cette partie qui n’apporterait rien de plus. Si vous voulez voir comment ça fonctionne je vous invite à (re)lire l’article précédent, la procédure est la même.

Le seul prérequis pour ce tutoriel sont donc d’avoir idéalement 3 machines* (ou plus) sous Debian 10 (la raison pour laquelle je n’avais pas pu le faire avec Scaleway qui ne propose pas encore Debian Buster) accessibles en depuis votre station de travail.

*Mais si vous voulez juste installer Proxmox, une seule suffit mais vous n’aurez évidemment pas un cluster. A partir de 2, on peut faire un cluster mais il sera instable dès que vous perdrez une seule des 2 machines (ce qui est dommage) à moins d’ajouter un device pour permettre d’avoir le quorum (ce que nous verrons dans un autre article).

Installer Ansible et récupérer les playbooks

Des fois que n’auriez pas Ansible, installez le (pour git, c’est juste plus simple de cloner le dépôt mais vous pouvez le télécharger autrement si vous ne voulez pas installer git)

apt-get install git ansible
git clone https://github.com/zwindler/ansible-proxmoxve
cd

Ensuite, on créé un fichier d’inventaire pour Ansible (ce qui n’étais pas nécessaire avec Scaleway puisque, je le rappelle, il y a un module d’inventaire dynamique). Ici on se contente juste de lister les serveurs qui nous intéressent.

cat pve_inventory.yml
all:
children:
proxmoxve:
hosts:
proxmox1.myexample.org:
proxmox2.myexample.org:
proxmox3.myexample.org:

Vous ne reconnaissez peut être pas le format de cet inventaire Ansible. En effet, l’inventaire est ici stocké au format YAML et non au format plat. Très peu de gens utilisent ce format (qui existait au début, puis a été retiré pour être de nouveau supporté depuis la 2.4 je crois).

Étant habitué aux inventaires parfois un peu hétéroclites, je préfère largement ce format YAML, qui permet de rajouter de manière beaucoup plus lisibles des variables à des groupes ou mêmes des hôtes directement (sans passer par une arborescence complète avec groups_vars et hosts_vars). De plus, je trouve les dépendances entre groupes plus claires que lorsque nous avions à déclarer les :children du groupe père (mais c’est subjectif).

Notez par contre qu’il faut :

que mes hôtes soient résolvables par DNS (sinon il faut ajouter une variable ansible_host avec l’IP pour chacun)
que vous n’oubliez surtout par le “:” à la fin de chaque hostname, sans quoi vous aurez une erreur de syntaxe.

Lancer le playbook d’installation de Proxmox VE 6

Nous y voilà. Normalement vous pouvez accéder en SSH à l’ensemble de vos machines. Pour installer Proxmox VE 6 sur une debian 10, il faut donc simplement lancer la commande suivante :

ansible-playbook -i pve_inventory.yml proxmox_prerequisites.yml -u root

Normalement, le playbook vous promptera pour répondre à quelques questions basiques (votre domaine, est ce que les machines commencent par test plutôt que proxmox dans le hostname, …) et à l’issue, un reboot sera effectué (pour basculer sur le noyau Linux de PVE et pas celui de debian Buster).

Mise en réseau privé virtuel avec Tinc

Cette étape n’est pas forcément nécessaire. Si vous travaillez sur des machines qui sont dans un même réseau local, il vaut mieux s’en passer.

En revanche, dans le cas où comme moi vous louez des serveurs chez un provider et qu’il ne vous met pas à disposition un moyen de simuler un réseau privé (RPN chez Online, Rack quelque chose chez OVH je crois), il sera préférable de monter un VPN entre les différentes machines du cluster.

Je dis préférable et pas nécessaire, car jusqu’à la version 6 de Proxmox (et Corosync v3), il était nécessaire également de faire passer du multicast entre les machines pour faire fonctionner le cluster. Ce n’est aujourd’hui plus le cas et on peut donc très bien imaginer un cluster Proxmox avec des machines sur des LAN distincts. Cependant, pour activer des fonctionnalités comme Ceph (et probablement d’autre), il est toujours nécessaire d’avoir un LAN.

Pour se faire, j’utilise Tinc plutôt qu’OpenVPN, qui a l’avantage d’être simple à configurer et surtout multipoint (pas de notion de serveur maitre et de clients connectés dessus). Ce n’est pas le cas avec OpenVPN, dont la structure client/serveur complexifie beaucoup l’implémentation si on veut éviter un SPOF (en gros il faut un serveur sur toutes les machines, et que l’ensemble des serveurs soient tous clients les uns des autres, en toile d’araignée). Vous pouvez quand même jeter un oeil sur mes premières tentatives ici, si ça vous intéresse.

Comme j’automatise tout avec Ansible, j’ai donc aussi créé un playbook qui permet d’installer et configurer Tinc sur toutes nos machines et de les mettre en réseau sur un VPN dédié.

ansible-playbook -i pve_inventory.yml tinc_installation.yml -u root

A partir de là, vous avez donc 3 machines Proxmox VE 6, connectés ensembles sur un VPN avec l’adresse 10.10.10.0/24

Le réseau c’est compliqué ?

Un point pas forcément évident avec Proxmox est que la configuration du réseau dépend beaucoup de comment vos machines sont connectées en réseau.

Les différentes configurations conseillées sont détaillées dans un article dédié sur le wiki de Proxmox. J’aurais vraiment aimé connaître cette page lorsque M4vr0x et moi avons fait nos premières expériences avec PVE car nous avons beaucoup tâtonné…

Dans mon cas précis, j’ai des machines hostées par un provider. Je n’ai donc aucunement la main sur le réseau et je ne souhaite pas acheter d’IP supplémentaires.

Dans ce cas là, le plus simple est donc de créer un bridge Linux, qui portera un réseau virtuel interne à chaque serveur et dont le trafic externe sera routé.

L’inconvénient de cette solution est qu’on ne peut pas utiliser l’interface graphique pour faire ces modifications, et aussi qu’en cas d’erreur, vous n’aurez plus accès à votre serveur…

Configuration réseau pour des machines dédiées chez un Provider type OneProvider

Nous voilà donc dans les premières bidouilles manuelles. Connectez vous en SSH à votre (vos) serveurs, et modifier le fichier /etc/network/interfaces.

Je me suis basé sur la section “Masquerading (NAT) with iptables”

Le mien ressemble à ça :

source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
auto eth0
#real IP address
iface eth0 inet static
address x.x.x.x
netmask 24
gateway x.x x.1
auto vmbr0
iface vmbr0 inet static
address 192.168.0.1
netmask 255.255.255.0
bridge-ports none
bridge-stp off
bridge-fd 0
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -t nat -A POSTROUTING -s '192.168.0.0/24' -o eth0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '192.168.0.0/24' -o eth0 -j MASQUERADE

Le plus important ici pour que tout fonctionne est que vous ne vous trompiez pas sur le nom de l’interface réseau (eth0 dans mon exemple).

Ensuite, une fois que les modifications sont faites, redémarrez le réseau (systemctl restart networking) ou carrément le serveur (c’est ce que Proxmox conseille, même si je ne vois pas bien l’intérêt).

Ici, la configuration est beaucoup plus simple que ce que nous avions imaginé avec M4vr0x dans la série d’articles détaillés sur PVE 5. Et c’est tant mieux car ça suffira amplement à la plupart d’entre vous ;-).

Configuration du cluster Proxmox VE

Ok ! Maintenant tous les prérequis sont en place, on peut donc construire le cluster. Le wizard de la GUI a assez peu évolué depuis la V5 (même s’il y a quelques petites améliorations)

Vous vous connectez sur une des machines
Dans la vue Datacenter, vous sélectionnez Create Cluster, puis vous copiez les informations de connexion pour les autres serveurs.
Sur les autres serveurs, vous rejoignez le cluster en collant les informations des

(Plus de détails dans l’article précédent)

Un cluster Proxmox VE en 5 minutes avec Ansible

Mon, 22 Jul 2019 11:45:34 +0000

Cool on va (encore) déployer du Proxmox VE !!!

Petit tuto aujourd’hui, massivement facilité par l’usage d’Ansible : on va déployer un cluster de machines Proxmox VE via le cloud provider Scaleway.

A noter : Si jamais vous ne voulez pas utiliser Scaleway, les playbooks ont été découpés de manière à ce que la partie d’installation de Proxmox ainsi que l’installation de tinc et la mise en cluster puissent être réalisés à part. Vous pouvez donc tout à faire partir de machines sous Debian 9 via ces playbooks.

Pourquoi Scaleway me direz vous ? Tout simplement parce qu’ils ont, contrairement à d’autres, une très bonne API, qui a permis à un de leurs employés de faire de très bons modules Ansible, notamment un module permettant de gérer l’inventaire dynamique (pas besoin de renseigner un fichier hosts pour Ansible, c’est directement l’API qui nous liste les VMs).

J’ai d’ailleurs utilisé ce provider à plusieurs reprises pour cette raison (voir mon article sur k3s et Ansible ou mon talk à BDX I/O Ami développeur, deviens un ops sans effort avec Ansible).

Proxmox VE 5.4 ? Pourquoi pas 6.0 ?

La deuxième question, tout aussi légitime, repose donc sur “pourquoi diantre monter un cluster Proxmox VE 5.4 alors que tu viens de nous faire un article qui vante les bienfaits de la version 6.0 qui vient de sortir ?”

Et là j’ai deux raisons (une bonne et une mauvaise). La mauvaise, c’est simplement que l’article trainait dans mes brouillons et que je n’ai pas cliqué sur “Poster”… La “bonne” raison, c’est que la version 10 de Debian, qui est la base de Proxmox VE 6, n’est pas encore disponible sur Scaleway, ce qui complique un peu l’installation.

Lorsqu’elle le sera, je ne manquerais pas de faire un petit refresh de l’article ainsi que des playbooks Ansible ;)

Déployer les VMs avec Ansible

Je l’ai dis juste avant, le gros avantage de Scaleway, c’est de pouvoir spawner des VMs à la volées avec Ansible et surtout d’avoir l’inventaire dynamique.

Petite (grosse?) limitation : comme il s’agit de VMs, il ne sera évidemment pas possible de faire tourner des VMs de type KVM/qemu sur ces machines (sauf moyennant un hack de type nesting de VM dans une VM).

Cependant, depuis quelques temps, je n’utilise plus du tout les VMs (je n’ai pas de workload Windows) et j’utilise plutôt des containers LXC.

C’est vraiment plus léger en terme d’empreinte mémoire (je n’ai jamais été embêté côté CPU mais côté RAM, chaque Mo compte) et ça se gère (install, gestion, sauvegarde) de la même façon qu’une VM, contrairement à Docker qui nécessite une gymnastique mentale complémentaire.

Bon, on fait ça comment ?

Maintenant que j’ai posé le décor, on peut commencer le tuto. L’idée va être de :

Créer des VMs
Récupérer leurs informations (IP publique, surtout)
Installer les prérequis de Proxmox VE (puis les rebooter pour passer sur le kernel PVE)
Installer les prérequis et configurer tinc, le VPN qui va nous permettre d’initier le cluster et de laisser passer les trames multicast, nécessaires au clustering

A l’issue de ces étapes, on arrêtera là l’automatisation et on passera sur quelques (rapides) étapes manuelles.

Ok, j’avoue que c’est dommage que tout ne soit pas automatisé. Mais le gros du boulot, c’est vraiment les étapes précédentes. Pour s’en convaincre, vous pouvez lire l’article que j’avais écris pour la version 5.2 (mais avec OpenVPN) ou tout simplement lire le contenu des playbooks.

Prérequis

Et oui, il y a quand même quelques prérequis à ce tuto. Il faudra :

Avoir un compte sur Scaleway
Avoir une clé SSH, avoir la clé publique à la racine du projet, et l’appeler admin.pub
Installer les package pip

pip install jinja2 PyYAML paramiko cryptography packaging

Installer Ansible depuis les sources (>= 2.8)
Installer jq

J’aurai pu faire aussi un playbook pour ça, mais comme c’est très dépendant de votre distribution Linux (ou Windows ahaha), …

You token to me ?

Créez un token sur le site de Scaleway pour les accès distants et le stocker dans un fichier scaleway_token sur votre machine avec Ansible :

export SCW_API_KEY='aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa'

Puis sourcez le fichier :

source scaleway_token

A partir de maintenant, vous avez le pouvoir tout puissant du cloud au bout de vos doigts (et de votre CB) !

Générer les machines

Là, on tire totalement parti du travail de Rémy Léone sur https://github.com/scaleway/ansible et des modules Ansible pour Scaleway, intégrés au repo officiel.

On va donc utiliser le playbook create_proxmox_vms.yaml pour :

récupérer l’ID d’organisation du compte Scaleway (votre identifiant unique)
récupérer un ID d’une image disque compatible debian Stretch (de la bonne taille)
ajouter si nécessaire la clé SSH de l’admin dans le portail Scaleway, qui sera injectée dans vos VMs à leur création
créer autant de machines que nécessaire

ansible-playbook create_proxmox_vms.yml

Bon, je vous ai pas menti, c’est quand même hyper simple non ?

A noter, actuellement le script traite les demandes de création de machines séquentiellement. Pour 3 VMs, comptez environ 3 minutes.

Cependant, si vous avez un gros besoin, sachez qu’il est possible de modifier le script pour les lancer en parallèle (déjà fait dans mon repo ansible-deploy-azure sur Github) via la fonction async d’Ansible.

Mise en place de l’inventaire dynamique

J’arrête pas de vous en parler depuis tout à l’heure, normalement dans Ansible, maintenant que nos VMs sont créées, pour pouvoir nous y connecter, on devrait créer un fichier texte “inventory” contenant la liste des hôtes et de leur IP (a minima). C’est fastidieux, surtout si vous avez beaucoup de VMs.

Et là, on a juste un fichier inventory.yml, contenant le nom du plugin, la région utilisée (Paris dans mon script) et le tag des machines générées :

plugin: scaleway
regions:
- par1
tags:
- proxmoxve

A partir de là, on peut vérifier le retour de la commande ansible-inventory

ansible-inventory --list -i inventory.yml
{
"_meta": {
"hostvars": {
"x.x.x.x": {
"arch": "x86_64",
"commercial_type": "DEV1-S",
"hostname": "test3",
[...]
"proxmoxve": {
"hosts": [
"x.x.x.x",
"y.y.y.y",
"z.z.z.z"
]
}

Petite hack SSH : comme Ansible se connecte en SSH aux hôtes distants, à la première connexion on va bloquer sur l’acceptation de la fingerprint.

Un moyen de bypasser ça en une ligne de commande est d’utiliser la commande ssh-keyscan et de coller tout ça dans votre known_hosts. On peut le faire avec ce petit oneliner :

ansible-inventory --list -i inventory.yml | jq -r '.proxmoxve.hosts | .[]' | xargs ssh-keyscan >> ~/.ssh/known_hosts

Ce n’est évidemment pas recommandé en production !!! Mais dans le cadre d’un test temporaire, vous me pardonnerez cette liberté.

Ajoutez votre clé SSH dans l’agent, puis vérifiez que vous pouvez vous connecter à tous les serveurs :

eval `ssh-agent`
ssh-add myprivate.key

ansible proxmoxve -i inventory.yml -u root -m ping
x.x.x.x | SUCCESS => {
"changed": false,
"ping": "pong"
}
y.y.y.y | SUCCESS => {
"changed": false,
"ping": "pong"
}
z.z.z.z | SUCCESS => {
"changed": false,
"ping": "pong"
}

Préparation du serveur

Ok ! Maintenant, on a 3 (ou plus) VMs Debian 9. A partir de là, j’ai créé un playbook Ansible qui suit la doc d’installation officielle de Proxmox sur un Debian Stretch.

ansible-playbook -i inventory.yml -u root proxmox_prerequisites.yml

A l’issue de l’installation, il est nécessaire de rebooter les serveurs (manuellement ou via ansible), pour passer sur le kernel de PVE.

Installation et configuration de tinc

C’est piou-piou.

Une fois que vos serveurs sont revenus à la vie, vous avez installé Proxmox. Pas mal hein ?

Cependant, chez Scaleway (et tous les autres providers que je connais), le multicast est coupé entre vos VMs. Et ça c’est la loose car tout notre clustering va passer par des trames multicast.

Pour bypasser ce souci de taille, le plus simple est de passer par un VPN, de créer un réseau privé virtuel entre toutes nos instances, qui lui ne filtrera rien.

Dans les articles précédents, j’avais utilisé OpenVPN (parce que c’est ce que je connais le mieux). Le souci d’OpenVPN c’est qu’il fonctionne sur un base client-serveur. Or, dès qu’on dépasse les 3 serveurs, on se retrouve avec 1 serveur maitre et 2 (ou plus clients), et donc un SPOF…

L’avantage avec tinc, c’est qu’on a pas cette notion de client/serveur. Tous les tincs sont connectés à tous les tincs, dans un genre de gros maillage qui nous évite donc tout SPOF.

L’installation de tinc n’est en soit pas follement complexe (cf le playbook), mais là encore, l’automatiser c’est toujours sympa.

ansible-playbook -i inventory.yml -u root tinc_installation.yml

Etapes additionnelles manuelles

Une fois que vous en êtes là, on arrive dans les tâches non triviales à automatiser.

Actuellement, il n’est pas possible de créer un cluster Proxmox VE sans avoir un mot de passe root. Or, lors de la création des VMs, Scaleway utilise notre clé SSH (ce qui est beaucoup mieux). Nous allons donc devoir nous connecter sur l’ensemble des machines et réinitialiser le mot de passe du compte root.

root@test1:~# passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

Créer un cluster

Cette partie aurait pu être automatisée. Dans le tutoriel précédent, je le faisais en ligne de commandes, à cause d’une limitation dans le wizard de création de cluster. En effet, dans les précédentes versions de Proxmox, on ne pouvait pas sélectionner sur quelle interface réseau on souhaitait utiliser, et donc mon cluster ne passait pas par le VPN et les trames multicast ne passaient jamais.

Pour autant, maintenant on peut profiter du beau wizard tout neuf et le faire via la GUI :

Se connecter à l’UI de Proxmox avec un des noeuds (le premier, au hasard)
Dans Datacenter (à gauche), sélectionner Cluster puis cliquer sur “Create Cluster”
Donner un nom au cluster, mais surtout, donner comme adresse ring0 l’adresse VPN (10.10.10.1 si on est sur le noeud 1)
Une fois l’opération terminée, cliquer sur “Join Information”, dans le même menu, et copier les informations en cliquant sur “Copy Information”

Joindre le cluster

Se connecter sur l’UI de la 2ème machine
Dans Datacenter, sélectionner Cluster puis cliquer sur “Join Cluster”
Dans le champ “Information”, coller les données récupérée lors de l’étape précédente. Les informations de connexion devraient automatiquement être remplies, SAUF le Corosync ring0, qu’il faut positionner à 10.10.10.2", et le mot de passe root du noeud 1. Cliquer sur “Join”.
Si l’opération réussie, un message doit s’afficher pour dire de recharger la page

Répéter l’opération pour les noeuds suivants (3, voire ++)

Et en attendant la même chose avec la v6, amusez vous bien :)

[Tutoriel] Faire un petit cluster Proxmox chez Kimsufi avec OpenVPN

Tue, 29 Aug 2017 11:40:23 +0000

C’est la rentrée, vous reprendrez bien un petit article sur Proxmox !

Ou plutôt, c’est bientôt la rentrée et il est grand temps que je solde les articles qui trainent dans mes tiroirs car je moi pars bientôt en vacances.

« Et tout le monde s’en fout »

J’ai donc rédigé un tutoriel pas à pas pour vous montrer qu’on peut créer rapidement un petit cluster sous Proxmox avec deux petites machines chez un hébergeur pas cher type Kimsufi (j’avais justement deux machines car j’ai profité d’une promo chez eux), sans que les machines soient dans le même sous réseau IP.

Si vous ne connaissez pas Proxmox, je vous renvoie vers les articles que M4vr0x ou moi avons écris sur le sujet.

Pourquoi un tutoriel pour les clusters Proxmox ?

Vous allez me dire, pourquoi un énième article sur le sujet ? La documentation officielle, même si elle est en anglais, est assez claire et il existe plusieurs tutoriels en Français pour le faire.

Ah ah oui… mais la distinction c’est « faire un cluster de machines Proxmox, sans que les machines soient dans le même sous réseau IP » !

Et à moins que vous ayez une chance de ouf’, il est peu probable que vos deux Kimsufi le soient.

Petit rappel des prérequis pour faire un cluster Proxmox

Deux serveurs physiques (au minimum)
Port 22 accessible au moins dans un premier temps pour configurer le cluster
Que la latence d’un serveur à l’autre soit inférieure à 2ms
Que les deux serveurs soient capables de communiquer en multicast

Et là, c’est le drame !

Jusqu’à ce qu’on arrive à la dernière ligne, nous étions sereins.

Si jamais vous avez deux serveurs chez Kimsufi (ou autre) et que vous essayez de les faire communiquer en multicast, vous allez vite vous rendre compte que le multicast est bloqué !

Impossible donc de faire fonctionner correctement votre cluster Proxmox (basé sur corosync) sans cela. Vous pouvez mettre tous les autres tutos à la poubelle ;-).

Bidouille & compagnie, et les risques encourus

Si vous vous sentez la curiosité de monter quand même un cluster sur votre Kimsufi, on va contourner le problème en montant un VPN entre les deux machines. M4vr0x a déjà détaillé l’utilisation d’OpenVPN avec pfSense sur Proxmox, mais on n’était pas dans le même contexte.

On ne peut pas se baser là dessus dans le cas présent car Proxmox a la fâcheuse manie de réinitialiser toute la configuration lorsqu’on démarre le mode « cluster » .

ATTENTION !!!
Oui, ça veut bien dire que vous ne verrez plus ni vos VMs existantes, ni le stockage que vous avez précédemment configuré…
Les VMs continuent d’exister et sont accessibles tant que vous ne rebootez pas. Le stockage aussi. Ce n’est juste plus visible.

Vous l’avez deviné, c’est du vécu : j’ai flingué ma configuration existante lorsque j’ai initialisé le cluster.

Mise en réseau

Maintenant que vous savez ce que vous risquez, on va donc configurer tout ça à la main, directement en SSH sur les machines Proxmox :

Sur le serveur 1

La première chose à faire est simplement d’installer openvpn, ainsi qu’un utilitaire qui s’appelle easy-rsa qui va nous faciliter la tâche de configuration.

apt-get update
apt-get upgrade
apt-get install openvpn easy-rsa

Une fois que c’est fait, on copie les templates de config et les scripts de easy-rsa et on modifie les valeurs par défaut par nos propres valeurs.

cp -ai /usr/share/easy-rsa/ /etc/openvpn/easy-rsa/
cd /etc/openvpn/easy-rsa/
vi vars
[...]
# These are the default values for fields
# which will be placed in the certificate.
# Don't leave any of these fields blank.
export KEY_COUNTRY="FR"
export KEY_PROVINCE="Aquitaine"
export KEY_CITY="Bordeaux"
export KEY_ORG="mondomaine.tld"
export KEY_EMAIL="key@mondomaine.tld"
export KEY_OU="key"

Sourcez le fichier nouvellement rempli :

. ./vars

Nettoyez les clés provenant d’anciennes itérations de l’outil (pas nécessaire si c’est la première fois mais si vous n’en êtes pas au premier coup, ça peut éviter des erreurs bêtes) :

./clean-all

Et enfin, on génère l’ensemble des clés dont vous aurez besoin (les CA, les clés serveurs, les clés clientes et la diffie helmann) :

./build-ca
./build-key-server serveur1.mondomaine.tld
./build-key serveur2.mondomaine.tld
./build-dh

Normalement tout devrait se passer sans encombre et vous devriez avoir plusieurs certificats nouvellement créés. On va copier les certificats du serveur OpenVPN dans le dossier /etc/openvpn, puis envoyer les certificats du client par SCP :

cp keys/ca.* keys/serveur1.mondomaine.tld.* keys/dh2048.pem /etc/openvpn/
scp keys/ca.crt keys/serveur2.mondomaine.tld.crt keys/serveur2.mondomaine.tld.key serveur2.mondomaine.tld:/etc/openvpn/

Maintenant qu’on a tout, on peut créer le fichier de configuration. Ici rien de bien compliqué à comprendre :

On créé un fichier server.conf qui va monter un VPN sur le port 1194 en UDP via un device de type TAP (j’y reviendrai) et on force le réseau en 10.9.0.0/24
On donne le chemin vers tous les certificats qu’on vient de créer
On ajoute un script « up » et un script « down », avec l’option script-security à « 2 » sinon ça ne fonctionnera pas

cat > /etc/openvpn/server.conf << EOF
# [server.conf]
port 1194
proto udp
#dev tun
dev tap
ca /etc/openvpn/ca.crt
cert /etc/openvpn/serveur1.mondomaine.tld.crt
key /etc/openvpn/serveur1.mondomaine.tld.key
dh /etc/openvpn/dh2048.pem
server 10.9.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
script-security 2
up /etc/openvpn/add_multicast_route
down /etc/openvpn/add_multicast_route
EOF

Bon et qu’est ce qu’il contient ce fameux script ? Et bien pour l’instant il se contente simplement d’ajouter et de supprimer une route sur les serveurs qui va router « à la main » tout le traffic multicast non par vers la gateway, mais vers le VPN ! Et c’est comme ça qu’on va contourner le blocage des flux multicast entre nos deux Kimsufi !

vi /etc/openvpn/add_multicast_route
#!/bin/bash
#
# Add a route to force multicast through VPN
[ "$script_type" ] || exit 0
case "$script_type" in
up)
route add -net 224.0.0.0 netmask 240.0.0.0 dev $1
;;
down)
route del -net 224.0.0.0 netmask 240.0.0.0 dev $1
;;
esac
chmod +x /etc/openvpn/add_multicast_route

On termine par démarrer (et activer au démarrage) le serveur OpenVPN :

systemctl enable openvpn
systemctl start openvpn

Dans ce cas là, comme on est pas en réel mode client serveur ou l’ensemble du traffic client est routé sur le serveur on a pas besoin de modifier le paramètre kernel « ip_forward » :

sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0

Aparté tun vs tap

Les plus aguerris d’entre vous auront remarqués que j’ai volontairement choisi de ne pas utiliser une interface virtuelle de type tun (par défaut dans OpenVPN) mais une interface de type tap.
Historiquement, ce type d’interface est connu pour ne pas fonctionner correctement en multicast, ce qui est ici notre but principal.

A priori c’est censé être résolu depuis longtemps, mais chez moi ça n’a pas marché alors que dès que j’ai switché sur tap ça a fonctionné directement. Je vous engage à regarder si ça vous intéresse. J’ai mis un lien vers une discussion à ce sujet sur le forum d’OpenVPN en fin d’article.

Sur le serveur 2

Maintenant que le serveur est configuré, au tour du client. Même topo, à ceci près qu’on ne va pas générer de certificats (c’est déjà fait).

apt-get update
apt-get upgrade
apt-get install openvpn
cat > /etc/openvpn/client.conf << EOF
# [client.conf]
client
#dev tun
dev tap
proto udp
remote @IP_publique_du_serveur1 1194
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ca /etc/openvpn/ca.crt
cert /etc/openvpn/serveur2.mondomaine.tld.crt
key /etc/openvpn/serveur2.mondomaine.tld.key
ns-cert-type server
comp-lzo
verb 3
script-security 2
up /etc/openvpn/add_multicast_route
down /etc/openvpn/add_multicast_route
EOF

vi /etc/openvpn/add_multicast_route
#!/bin/bash
#
# Add a route to force multicast through VPN
[ "$script_type" ] || exit 0
case "$script_type" in
up)
route add -net 224.0.0.0 netmask 240.0.0.0 dev $1
;;
down)
route del -net 224.0.0.0 netmask 240.0.0.0 dev $1
;;
esac
chmod +x /etc/openvpn/add_multicast_route
systemctl enable openvpn
systemctl start openvpn

Facile, hein ?

Sur tous les nœuds

Pour s’assurer que tout fonctionne comme ça devrait (ou pour déboguer), vous pouvez autoriser temporairement la réponse à l’ICMP sur multicast. Un simple ping permettra de s’assurer que les deux serveurs se voient bien :

sysctl net.ipv4.icmp_echo_ignore_broadcasts=0
root@serveur1:/etc/pve# ping 224.0.0.1
PING 224.0.0.1 (224.0.0.1) 56(84) bytes of data.
64 bytes from 10.9.0.1: icmp_seq=1 ttl=64 time=0.019 ms
64 bytes from 10.9.0.2: icmp_seq=1 ttl=64 time=1.07 ms (DUP!)
64 bytes from 10.9.0.1: icmp_seq=2 ttl=64 time=0.020 ms
64 bytes from 10.9.0.2: icmp_seq=2 ttl=64 time=0.672 ms (DUP!)
64 bytes from 10.9.0.1: icmp_seq=3 ttl=64 time=0.020 ms
64 bytes from 10.9.0.2: icmp_seq=3 ttl=64 time=0.619 ms (DUP!)

Les deux serveurs répondent aux pings depuis l’interface du VPN, on est bons ! Du coup vous pouvez re-désactiver la réponse aux broadcasts avec la commande suivante :

sysctl net.ipv4.icmp_echo_ignore_broadcasts=1

Pour faciliter la résolution de noms dans le cluster, vous pouvez ajouter les IPs VPN des serveurs dans le fichier /etc/hosts.

vi /etc/hosts
[...]
10.9.0.1 serveur1-vpn
10.9.0.2 serveur2-vpn

Création du cluster

Sur le nœud 1

En théorie, si on lit la documentation il suffit simplement de faire “pvecm create mycluster” et le tour est joué.

STOOOOP !

Si vous le faite, ça ne fonctionnera pas (et vous pourrez vous en sortir avec cet article). Pourtant tout est correct au niveau des prérequis : les nœuds fonctionnent bien et que le multicast est correctement routé via le VPN. Un coup d’œil au fichier de configuration de corosync nous en apprendra plus :

cat /etc/pve/corosync.conf
logging {
debug: off
to_syslog: yes
}
nodelist {
node {
name: serveur2
nodeid: 2
quorum_votes: 1
ring0_addr: serveur2
}
node {
name: serveur1
nodeid: 1
quorum_votes: 1
ring0_addr: serveur1
}
}
quorum {
provider: corosync_votequorum
}
totem {
cluster_name: mycluster
config_version: 4
ip_version: ipv4
secauth: on
version: 2
interface {
bindnetaddr: @IP_publique_du_serveur1
ringnumber: 0
}
}

En fait le problème ici, c’est que l’adresse bindée bindnetaddr: n’est pas bonne. Si vous n’avez pas lu mon gros “STOOOOP”, il faut tout réinitialiser car il est assez compliqué de modifier un cluster existant sous Proxmox (a priori pas possible proprement mais je vous donnerai la tips dans un prochain article).

Voilà la bonne commande à taper :

pvecm create mycluster -bindnet0_addr 10.9.0.1 -ring0_addr serveur1-vpn
Corosync Cluster Engine Authentication key generator.
Gathering 1024 bits for key from /dev/urandom.
Writing corosync key to /etc/corosync/authkey.

Sur le noeud 2

En théorie, là aussi c’est très facile. Il suffit de faire “pvecm add serveur2-vpn” pour que l’hôte serveur2.mondomaine.tld rejoigne le cluster créé sur le noeud serveur1.mondomaine.tld.

Voilà ce qui va se passer si vous le faites :

pvecm add serveur1-vpn
The authenticity of host 'serveur1-vpn (10.9.0.1)' can't be established.
ECDSA key fingerprint is SHA256:VOIH2X7kTzWLUEzRPCl4431hlYnc3HCsDmzXYEs3V+g.
Are you sure you want to continue connecting (yes/no)? yes
root@serveur1-vpn's password:
copy corosync auth key
stopping pve-cluster service
backup old database
Job for corosync.service failed because the control process exited with error code.
See "systemctl status corosync.service" and "journalctl -xe" for details.
waiting for quorum...

Même principe ici. Si l’adresse ring0_addr n’est pas spécifiée explicitement, corosync va tenter de s’abonner sur une IP multicast sur l’IP de l’interface Ethernet principale. Elle ne passera donc pas pas notre VPN et le cluster ne communiquera pas en multicast !

Vous pouvez en lire plus là dessus sur ce lien.

Sur le noeud serveur2, on ajoute donc l’adresse IP (et donc l’interface) que corosync devra emprunter pour communiquer avec serveur1-vpn (via le VPN donc).

pvecm add serveur1-vpn -ring0_addr 10.9.0.2
The authenticity of host 'serveur1-vpn (10.9.0.1)' can't be established.
ECDSA key fingerprint is SHA256:oKkuOYY1pbEa1RrM0y9fWVJfnQabhUvG7la+6fZUnQ4.
Are you sure you want to continue connecting (yes/no)? yes
root@serveur2-vpn's password:
copy corosync auth key
stopping pve-cluster service
backup old database
waiting for quorum...OK
generating node certificates
merge known_hosts file
restart services
successfully added node 'serveur2' to cluster.

A partir de là, tout devrait marcher. Vous devriez avoir sur la même interface vos deux serveurs, et avoir perdu toutes vos VMs si vous n’avez pas bien lu mon avertissement ;-)

A noter : chose qui n’était pas possible entre la version 3 et la version 4 (car les deux composants n’utilisaient pas le même logiciel pour le clustering), il est possible de faire un cluster ProxMox mixant version 4 et version 5 comme le montre cette capture d’écran :

Aller plus loin : les limites d’OpenVPN

On a maintenant un cluster de 2 machines Proxmox. Pour autant, ce n’est pas idéal et ça ne suffira pas pour passer en production, notamment en cas de coupure réseau entre les deux machines (split brain). On va vite vouloir en rajouter au moins une, sinon plus.

Cependant, on sera bloqués. Les limites de cette méthode est que la configuration d’OpenVPN est en mode client-serveur. Si vous avez plus de 2 machines, vous vous rendrez vite compte que vous pouvez communiquer entre les clients et le serveurs, mais pas entre clients.

Et en gros ça ne marche pas, le 3ème noeud ne rejoindra pas le cluster car il ne peut pas joindre l’ensemble des membres et il se mettra en defaut.

Pour bien faire en conservant ce mécanisme, il va falloir monter un service VPN externe aux serveurs Proxmox, qui seront tous clients de ce service, ou alors se créer un réseau de type full mesh, par exemple avec de l’IPSec si vous êtes un maitre en Réseau/Telco.

Autant dire qu’il vaut mieux passer par un hébergeur qui permet le multicast ou qui fourni un service VPN. Ca ira plus vite…