Comment attribuer une adresse IP publique aux invités Proxmox VE

L'e-mail Configuration du serveur dédié envoyé lors de la création de votre machine liste toutes les adresses qui lui sont attribuées, d'abord les IPv4 puis les IPv6. La même liste se trouve dans votre panneau de contrôle sur la page du serveur, sous Accès, réseau & rDNS, où chaque adresse est affichée avec son enregistrement DNS inverse.

Sur une installation Proxmox, l'e-mail comporte une ligne supplémentaire, et c'est la raison d'être de cette page : seule la première adresse est configurée sur l'hôte. Les autres vous appartiennent et vous pouvez les attribuer depuis Proxmox, à vos machines virtuelles ou à l'hôte lui-même. Notre installateur configure délibérément une seule adresse puis s'arrête, car un hôte qui les porterait toutes répondrait pour chacune d'elles et ne laisserait rien à vos invités.

Le masque de réseau est toujours /24 (255.255.255.0) et la passerelle est toujours le .1 du /24 dans lequel se trouve l'adresse elle-même. Cette seconde moitié compte plus qu'il n'y paraît. Les adresses commandées ensemble sont consécutives au sein d'un même /24, elles partagent donc une passerelle. Les adresses ajoutées ultérieurement à un serveur existant peuvent provenir d'une autre de nos plages, et chacune utilise alors son propre .1 — par exemple, une adresse dans 203.0.113.0/24 utilise 203.0.113.1 même sur une machine dont l'adresse principale est dans une autre plage. Les deux fonctionnent sur le même port et sur le même pont.

Le résolveur que notre installateur configure est 209.244.0.3. Vous êtes libre de pointer vos invités vers n'importe quel autre.

Connectez-vous en SSH en tant que root et examinez les interfaces écrites par l'installateur :

ip -br addr
cat /etc/network/interfaces

Une machine fraîchement installée ressemble à ceci, avec votre propre nom d'interface et votre propre adresse principale à la place des exemples :

auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

vmbr0 est déjà un pont et l'interface physique en est déjà un port. C'est tout le modèle en pont, et c'est pourquoi l'étape trois ne vous demande de ne rien changer sur l'hôte.

Proxmox VE 9 est Debian 13 et utilise ifupdown2, donc un changement de configuration ne nécessite pas de redémarrage. Modifiez /etc/network/interfaces et appliquez-le avec :

ifreload -a

Si vous modifiez le réseau via l'interface web de Proxmox à la place, vos changements sont mis en attente dans /etc/network/interfaces.new jusqu'à ce que vous appuyiez sur Appliquer la configuration. Dans tous les cas, ouvrez la console du serveur depuis votre panneau de contrôle avant de recharger. Une erreur dans ce fichier met la machine hors réseau, et la console est le moyen d'y revenir sans ticket.

C'est la solution à utiliser sauf raison contraire. L'invité est une machine ordinaire sur le même segment que l'hôte, il parle directement à nos routeurs, et rien ne change sur l'hôte.

Dans l'interface Proxmox, donnez à la machine virtuelle un périphérique réseau sur le pont vmbr0 et laissez l'adresse MAC que Proxmox a générée pour elle. Configurez ensuite l'adresse à l'intérieur de l'invité exactement comme vous le feriez sur n'importe quel serveur. Pour un invité Debian ou Ubuntu utilisant ifupdown :

auto lo
iface lo inet loopback

auto ens18
iface ens18 inet static
    address 203.0.113.58/24
    gateway 203.0.113.1
    dns-nameservers 209.244.0.3 1.1.1.1

Pour un invité Ubuntu utilisant netplan, dans /etc/netplan/01-netcfg.yaml :

network:
  version: 2
  ethernets:
    ens18:
      addresses: [203.0.113.58/24]
      routes:
        - to: default
          via: 203.0.113.1
      nameservers:
        addresses: [209.244.0.3, 1.1.1.1]

Un invité Windows prend les trois mêmes valeurs dans les propriétés IPv4 de l'adaptateur. N'importe quel système d'exploitation fonctionne, car de notre côté c'est simplement une autre machine sur le sous-réseau.

Vous n'avez pas à enregistrer l'adresse MAC d'un invité chez nous, et nous ne limitons pas le nombre que votre port peut utiliser. Certains hébergeurs le font, et leur documentation vous demande de déclarer une MAC pour chaque machine virtuelle. Pas la nôtre : le port du commutateur sur lequel votre serveur est branché n'a aucune restriction de nombre de MAC et la sécurité du port est désactivée, donc une MAC d'invité est apprise exactement comme celle de l'hôte. Nous avons testé cela avant de le publier, en plaçant une seconde MAC et une adresse libre sur le port client d'un serveur du personnel et en l'atteignant depuis l'internet public.

Trois points à respecter :

• Donnez à chaque invité une adresse MAC distincte. Deux invités qui partagent la même, ou un invité qui copie celle de l'hôte, cassent les deux.
• Utilisez la passerelle appartenant au /24 de l'adresse elle-même, depuis l'étape un.
• Ne configurez jamais qu'une adresse attribuée à votre compte. Le pont fait face à un réseau réel partagé avec d'autres machines. Prendre une adresse qui n'est pas la vôtre emporte le trafic de quelqu'un d'autre avec elle.

Pour la même raison, n'exécutez pas de serveur DHCP, de démon d'annonces de routeur pirate ou quoi que ce soit d'autre qui réponde pour le segment sur vmbr0. Si vous voulez servir du DHCP à vos propres invités, utilisez le modèle de sous-réseau privé de l'étape cinq, où le pont n'a pas de port physique et ne peut atteindre personne d'autre.

Utilisez ce mode quand vous voulez que chaque paquet à destination ou en provenance d'un invité passe par l'hôte, afin que le pare-feu de l'hôte le voie, ou quand vous préférez que vos invités n'apparaissent jamais du tout sur notre couche 2. L'adresse reste une adresse publique de votre compte ; seul le chemin change.

L'adresse publique quitte le pont et passe sur l'interface physique, l'hôte transfère, et il répond aux requêtes ARP au nom des invités pour lesquels il route. Sur l'hôte :

auto lo
iface lo inet loopback

auto eno1
iface eno1 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    post-up echo 1 > /proc/sys/net/ipv4/ip_forward
    post-up echo 1 > /proc/sys/net/ipv4/conf/eno1/proxy_arp

auto vmbr0
iface vmbr0 inet manual
    bridge-ports none
    bridge-stp off
    bridge-fd 0
    up ip route add 203.0.113.58/32 dev vmbr0
    down ip route del 203.0.113.58/32 dev vmbr0

Ajoutez une paire up et down par adresse routée. À l'intérieur de l'invité, l'adresse est un /32 et l'hôte est atteint par une route on-link explicite avant la route par défaut :

auto lo
iface lo inet loopback

auto ens18
iface ens18 inet static
    address 203.0.113.58/32
    post-up ip route add 203.0.113.10 dev ens18
    post-up ip route add default via 203.0.113.10
    dns-nameservers 209.244.0.3 1.1.1.1

Deux remarques sur la strophe de l'hôte. La ligne proxy_arp est ce qui fait fonctionner ce mode ici : nos routeurs demandent sur le segment l'adresse de l'invité, et l'hôte répond pour elle. Sans cette ligne, l'invité est silencieux depuis l'extérieur. Et les deux lignes post-up echo sont la forme documentée par Proxmox ; si vous préférez les définir une fois pour toutes, placez net.ipv4.ip_forward=1 et net.ipv4.conf.eno1.proxy_arp=1 dans un fichier sous /etc/sysctl.d/ à la place.

Le mode routé vous coûte un peu de configuration dans chaque invité et vous donne un hôte capable de filtrer, compter et journaliser tout. Le mode pont ne coûte rien et ne vous donne ni l'un ni l'autre. C'est tout le compromis.

Les invités qui n'ont besoin que de sortir — agents de build, workers, une base de données que rien d'extérieur ne devrait toucher — n'ont pas du tout besoin d'une adresse publique. Placez-les sur un pont sans port physique et laissez l'hôte traduire leur trafic vers sa propre adresse en sortie. Cela ne coûte aucune adresse et c'est le moyen le moins cher de faire tourner beaucoup de machines.

Ajoutez un second pont sur l'hôte, en laissant vmbr0 tel quel :

auto vmbr1
iface vmbr1 inet static
    address 10.10.10.1/24
    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 '10.10.10.0/24' -o eno1 -j MASQUERADE
    post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o eno1 -j MASQUERADE

Les invités vont sur vmbr1 avec une adresse dans cette plage, 10.10.10.1 comme passerelle, et le résolveur de votre choix. Ils atteignent l'internet en tant que votre serveur ; rien de l'extérieur ne les atteint sauf si vous le décidez. Pour publier un service, ajoutez une règle de transfert à côté de la règle de masquage, en choisissant un port que l'hôte n'utilise pas lui-même :

post-up iptables -t nat -A PREROUTING -i eno1 -p tcp --dport 8443 -j DNAT --to 10.10.10.2:443
post-down iptables -t nat -D PREROUTING -i eno1 -p tcp --dport 8443 -j DNAT --to 10.10.10.2:443

Comme ce pont n'a pas de port physique, un serveur DHCP y est parfaitement sûr et constitue un moyen raisonnable d'adresser vos invités.

Votre allocation IPv6 est un ensemble d'adresses individuelles, pas un préfixe délégué que vous pouvez découper. Elles sont listées dans le même e-mail d'installation, sous les IPv4, et elles se placent une à une exactement comme les adresses IPv4 : une sur l'hôte si vous voulez que l'hôte soit joignable, le reste sur les invités. L'installateur n'en configure aucune.

Configurez chacune avec une longueur de préfixe /64, et la passerelle est le préfixe suivi de ::1 — donc une adresse dans 2001:db8:1234::/64 utilise 2001:db8:1234::1. Sur l'hôte, ajoutez une strophe IPv6 à côté du pont existant :

iface vmbr0 inet6 static
    address 2001:db8:1234::2/64
    gateway 2001:db8:1234::1

Et dans un invité en mode pont :

iface ens18 inet6 static
    address 2001:db8:1234::5/64
    gateway 2001:db8:1234::1

Appliquez avec ifreload -a comme précédemment. Comme les adresses sont individuelles plutôt qu'un préfixe qui vous appartient, n'exécutez pas d'annonces de routeur et ne distribuez pas d'adresses qui ne vous ont pas été données. Si vous avez besoin de plus que ce que vous avez, demandez-nous.

Le DNS inverse vous appartient et vous pouvez le modifier, sur chaque adresse, sans ticket. Connectez-vous, ouvrez la page du serveur et trouvez le panneau Accès, réseau & rDNS. Chaque adresse du compte y est listée avec son enregistrement actuel et un bouton Modifier le rDNS. IPv4 et IPv6 fonctionnent toutes les deux.

Le formulaire accepte un nom d'hôte : lettres, chiffres, tirets et points uniquement, chaque libellé entre 1 et 63 caractères, au moins deux libellés, et il ajoute le point final pour vous. Les changements mettent quelques minutes à apparaître.

Si la machine envoie du courrier, définissez l'enregistrement inverse sur l'adresse d'où part réellement le courrier — ce qui, dans le modèle de sous-réseau privé ci-dessus, est l'adresse de l'hôte plutôt que celle de l'invité — et créez l'enregistrement direct correspondant chez votre propre fournisseur DNS. Les serveurs de réception du courrier vérifient que les deux concordent.