Attribuer une adresse IPv4 à la machine virtuelle

Dans le guide précédent, vous avez créé la première machine virtuelle de cette plateforme et y avez installé un système d'exploitation invité, à savoir un système Debian accessible uniquement depuis l'intérieur du pont de l'hôte Proxmox lui-même. Pour y accéder depuis Internet, vous devrez d'abord commander une adresse IPv4 routée et un tunnel auprès de Taipan, faire aboutir ce tunnel sur l'hôte Proxmox lui-même, puis acheminer l'une des adresses vers la machine virtuelle.

Commander une adresse IPv4 routée et un tunnel

La configuration s'effectue depuis le panneau de contrôle plutôt que depuis Proxmox : lorsque vous sélectionnez un type de tunnel dans la liste des services, l'écran de configuration propre à ce produit s'ouvre, avec une mise en page identique pour GRE, IPsec et WireGuard.

Écran de configuration du service GRE dans le panneau Taipan : un sélecteur de durée mensuelle proposant des réductions pour les abonnements de 3, 6 et 12 mois, une section de configuration du produit avec des cases d’adresses IPv4 allant de 1 à 100 et 5 adresses IP sélectionnées, des cases de trafic allant de 1 000 Go à 100 000 Go avec 1 000 Go sélectionnés à un tarif réduit de 0,35 par Go, un champ « Coupon » et un champ « Adresse IPv4 du terminal client » — L'écran de configuration du produit GRE : durée, nombre d'adresses, niveau de trafic et champ dédié au bon de réduction, le tout sur une seule page.

Les cinq adresses IP, mises en évidence sur cette capture d'écran, correspondent exactement au nombre indiqué dans ce guide : une pour la machine virtuelle créée dans la section précédente, et quatre autres à répartir dès que d'autres machines virtuelles seront disponibles. Le trafic fonctionne de la même manière : il s'agit d'une case fixe plutôt que d'un compteur, et le prix barré à côté correspond à la remise de campagne déjà visible sur la page des tarifs.

Cette capture d'écran représente l'interface utilisateur du produit GRE, et son dernier champ, « Customer endpoint IPv4 », est spécifique à GRE : il s'agit d'une adresse source fixe à partir de laquelle le tunnel attend du trafic. La version de cette même page propre à WireGuard supprime entièrement ce champ, car un pair WireGuard s’authentifie par paire de clés plutôt que par une adresse source fixe ; tous les autres éléments de la page (« Durée », « Nombre d’adresses IPv4 », « Niveau de trafic ») restent identiques.

Ce choix de produit repose sur trois types de tunnels, chacun présentant des avantages et des inconvénients différents :

GRE : le plus simple des trois. Il n'utilise aucun chiffrement, ce qui le rend rapide, mais il ne peut pas franchir seul un saut NAT.
IPsec : authentification et chiffrement via une session négociée par IKE ; le choix idéal lorsque le trafic lui-même doit rester confidentiel pendant son acheminement.
WireGuard : un système de chiffrement moderne basé sur des paires de clés, nécessitant une configuration minimale et continuant de fonctionner même en cas de changement d'adresse IP ; c'est la solution la plus simple pour établir une connexion sans adresse publique fixe.

Cet hôte Proxmox se trouve derrière l'adresse qui lui est attribuée par sa propre connexion en amont ; c'est donc WireGuard qui est le type de tunnel recommandé dans ce guide : une paire de clés statique résiste à ce changement d'adresse, contrairement au modèle GRE, qui repose sur une connexion fixe de point à point.

Cinq adresses suffisent pour répondre aux besoins de ce guide : une pour la machine virtuelle créée dans la section précédente, et quatre autres à attribuer dès qu’il y aura d’autres machines virtuelles. Une fois la commande validée, vous recevrez un numéro de commande valide, un bloc de cinq adresses IPv4 routées, ainsi que le point de terminaison WireGuard vers lequel ce tunnel aboutit :

order:    NL7R2aRA2oVbjHiL3DLfzXBd
endpoint: 195.123.189.9
routed:   195.123.189.17
          195.123.189.18
          195.123.189.19
          195.123.189.20
          195.123.189.21

Si la commande est confirmée mais que le tunnel lui-même affiche brièvement le statut « en attente », c'est tout à fait normal. La mise en service s'effectue sur le routeur gérant ce point d'extrémité selon son propre calendrier ; veuillez donc patienter quelques instants avant de passer à l'étape suivante.

Mettre fin au tunnel sur l'hôte Proxmox

Le tunnel WireGuard n'a rien de spécifique à Proxmox : il s'agit d'une interface Linux standard, configurée de la même manière, qu'elle soit exécutée sur un hyperviseur ou sur n'importe quelle autre machine Debian. Cela signifie également que chaque commande ci-dessous correspond exactement à ce qu'un script de provisionnement exécuterait en mode automatisé, sans qu'aucun assistant ne s'interpose entre le panneau de configuration et l'interface elle-même.

Générer une paire de clés

WireGuard authentifie les pairs à l'aide de paires de clés plutôt que d'un secret partagé ; ainsi, la première étape se déroule entièrement hors ligne, avant même que Taipan n'intervienne :

install -d -m 700 /etc/wireguard
sh -c 'umask 077; wg genkey | tee /etc/wireguard/taipan.key | wg pubkey > /etc/wireguard/taipan.pub'
cat /etc/wireguard/taipan.pub

Cette dernière commande affiche la partie publique, la seule qui doive effectivement quitter cet hôte :

FIv6nJ3IE0EsMH79Hxj6wV4piku0Guj8nvyaUJ7PEic=

La clé privée dans /etc/wireguard/taipan.key Elle n'est jamais collée nulle part, ni envoyée, ni transmise par e-mail : seule la clé publique est transmise à Taipan, selon le même principe d'asymétrie qui permet de générer en toute sécurité une paire de clés SSH avant même qu'un compte n'existe pour l'utiliser.

Rédiger la configuration de WireGuard

À partir des adresses de routage et du point de terminaison indiqués dans la commande, ainsi que de la clé publique et du port UDP de Taipan indiqués dans le panneau de configuration, /etc/wireguard/wg0.conf contient tout ce dont l'interface a besoin :

[Interface]
PrivateKey = <contents of /etc/wireguard/taipan.key>
Address = 100.64.0.2/32
Table = off
PostUp = ip rule add from 195.123.189.17/32 table 20 priority 100
PostUp = ip rule add from 195.123.189.18/32 table 20 priority 100
PostUp = ip rule add from 195.123.189.19/32 table 20 priority 100
PostUp = ip rule add from 195.123.189.20/32 table 20 priority 100
PostUp = ip rule add from 195.123.189.21/32 table 20 priority 100
PostUp = ip route add default dev %i table 20
PreDown = ip rule del from 195.123.189.17/32 table 20 priority 100
PreDown = ip rule del from 195.123.189.18/32 table 20 priority 100
PreDown = ip rule del from 195.123.189.19/32 table 20 priority 100
PreDown = ip rule del from 195.123.189.20/32 table 20 priority 100
PreDown = ip rule del from 195.123.189.21/32 table 20 priority 100

[Peer]
PublicKey = <Taipan's public key, from the panel>
Endpoint = 195.123.189.9:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Table = off arrêts wg-quick sans modifier la route par défaut de cet hôte, qui doit toujours passer par la liaison montante habituelle pour tout ce qui ne correspond pas à l'une de ces cinq adresses. Le PostUp Ces lignes créent plutôt une deuxième table de routage, qui n'est consultée que par le trafic provenant d'une adresse routée ; ainsi, une réponse provenant de 195.123.189.17 sort par le tunnel, tandis que le trafic sortant normal provenant du serveur hôte n'est absolument pas affecté.

Pourquoi le champ « Adresse » utilise-t-il 100.64.0.2 au lieu de l'une des cinq adresses réelles ?

En effet, l'interface du tunnel elle-même n'a pas besoin d'une identité publique ; seules les adresses routées qui transitent par celle-ci en ont besoin. 100.64.0.0/10 est l'espace d'adressage partagé réservé précisément à ce type de liaison point à point non numérotée ; il permet ainsi de numérot l'interface sans utiliser l'une des cinq adresses pour lesquelles ce guide a effectivement payé.

Remontez le tunnel

wg-quick lit ce même fichier et effectue, dans l'ordre, exactement ce qui est indiqué dans sa propre sortie : il crée l'interface, charge la clé, attribue l'adresse et exécute chaque PostUp ligne.

Console hôte Proxmox exécutant la commande « wg-quick up wg0 », affichant les commandes d'initialisation de l'interface, de la clé et de la route qu'elle exécute, suivie de la commande « wg show wg0 » répertoriant le pair, le point de terminaison 195.123.189.9:51820, ainsi qu'un keepalive persistant de 25 secondes — Une commande « wg-quick up wg0 », immédiatement suivie d'une commande « wg show wg0 » pour vérifier le pair et son point de terminaison.

Une nouvelle interface affiche « 0 octets reçus » jusqu’à ce que le pair réponde effectivement, ce qui peut prendre un certain temps après le tout premier paquet. Une poignée de main prouve uniquement que la relation cryptée entre pairs fonctionne ; il convient donc de vérifier de manière ciblée si une adresse routée est réellement accessible de bout en bout, plutôt que de le supposer à partir d’un système « propre ». wg show seul.

Rediriger une adresse vers la machine virtuelle

Le tunnel aboutit désormais sur l'hôte Proxmox lui-même ; il faut donc un saut supplémentaire pour atteindre effectivement la machine virtuelle : une route qui fait correspondre une adresse spécifique à l'adresse privée de cette machine virtuelle sur vmbr0, le même pont configuré il y a deux guides.

ip route add 195.123.189.17/32 via 10.0.2.100 dev vmbr0

Cette seule ligne fait toute la différence entre servir une adresse routée à partir de la passerelle elle-même et la transmettre à une machine virtuelle située derrière celle-ci : au lieu d'ajouter l'adresse à lo sur l'hôte, contrairement à ce que ferait un service s'exécutant directement sur la passerelle, l'hôte le transmet un saut plus loin vers l'adresse interne que la machine virtuelle détient déjà.

Du côté de la machine virtuelle, deux éléments correspondants sont nécessaires : l'adresse publique elle-même, et une route de retour via l'hôte pour tout trafic provenant de celle-ci.

ip address add 195.123.189.17/32 dev ens18
ip route add default via 10.0.2.100 dev ens18 onlink

Avant de procéder à un test depuis l'extérieur : assurez-vous que net.ipv4.ip_forward = 1 est en fait configuré sur l'hôte Proxmox lui-même. Le transfert entre le tunnel et vmbr0 en dépend, et sans cela, une adresse routée ne mène nulle part, sans que l'utilisateur s'en rende compte. Pour vérifier, sysctl net.ipv4.ip_forward devrait afficher un 1.

Une fois le transfert activé et les deux côtés configurés, ip route get 1.1.1.1 from 195.123.189.17 Une commande exécutée sur l'hôte Proxmox permet de vérifier le chemin d'accès effectivement choisi pour cette adresse : le résultat affiche dev wg0 Cela signifie que les réponses transitent par le tunnel comme prévu, tandis que dans tous les autres cas, le routage spécifique à la source défini à l'étape précédente doit être réexaminé avant de poursuivre les tests.

Répartir les adresses restantes

Quatre adresses issues de cette même commande ne sont toujours pas utilisées, et le schéma qui a permis d'attribuer la première se répète exactement pour chacune d'entre elles : une adresse privée sur vmbr0 pour la machine virtuelle en question, une route côté hôte pointant vers celle-ci, et l'adresse elle-même ajoutée sur l'interface propre à cette machine virtuelle.

195.123.189.17  ->  web01, 10.0.2.100 (this guide)
195.123.189.18  ->  next VM, once created
195.123.189.19  ->  next VM, once created
195.123.189.20  ->  next VM, once created
195.123.189.21  ->  next VM, once created

Les cinq machines partagent toujours le même tunnel et la même table de routage configurés précédemment : la table 20 contient déjà une règle spécifique à la source pour chaque adresse du bloc ; ainsi, une nouvelle machine virtuelle n'a besoin que de sa propre ip route add <address>/32 via <its internal IP> dev vmbr0 du côté de l'hôte, rien de plus concernant le tunnel lui-même.

En résumé

Un tunnel WireGuard est une interface Linux standard, qui se configure à l'aide des mêmes commandes, que Proxmox soit utilisé ou non.
Table = off De plus, le routage spécifique à la source permet de distinguer une adresse routée de la route par défaut propre à l'hôte.
Attribuer une adresse à une machine virtuelle plutôt qu'à la passerelle elle-même ne fait qu'ajouter une route supplémentaire, pointant vers l'adresse interne de cette machine virtuelle.
Toutes les adresses, dans le même ordre, transitent par ce tunnel unique, chacune n’ayant besoin que de son propre itinéraire dès lors qu’une machine virtuelle est disponible pour la recevoir.

Dans le guide suivant, vous utiliserez ce modèle de machine virtuelle pour créer la suivante en un clin d'œil.