Je suis chez Ecowan, je oense que c’est ipv6 /64 (c’est ce que j’ai quand je fais un ip a )
Le /64 en question est probablement le réseau sur lequel est attaché le serveur, il faut que tu demandes à l’opérateur le préfixe qui t’a été assigné.
Là où c’est important, c’est que autant en IPv4 tu peux faire du NAT et de la redirection de ports, autant en IPv6 il est préférable de faire un réseau routé complet sur toutes tes VMs.
Attribution des IPs
En général, on t’attribue une seule IPv4 ou un nombre limité d’adresses IPv4, donc il n’y a pas d’autre choix que d’utiliser du NAPT (pour le trafic sortant) et du DNAT (pour le trafic entrant) pour adresser plusieurs VMs.
Et en général toujours, on t’attribue un préfixe IPv6 (au minimum d’une taille /64, mais souvent plus grand), dans lequel tu peux adresser toutes tes VMs voire redécouper. Je ne vais pas entrer dans le détail mais il y a plusieurs raisons pour lesquels on n’attribue jamais plus petit qu’un /64 IPv6. Personnellement tous mes hébergeurs, y compris associatifs, m’ont toujours fourni un préfixe suffisamment grand pour que je puisse router à l’intérieur de mon serveur (c’est à dire /56 ou /60 car plus le chiffre est petit, plus le préfixe est grand).
Adressage IPv4/IPv6 d’un Proxmox
Voici les principes que j’applique quand je fais l’adressage d’un proxmox en dual-stack IPv4/IPv6, avec quelques exemples issus de l’infra Gozmail (pas uniquement pour ton cas, je pense que cela peut être utile à d’autres).
1er principe : Réseau NATé IPv4 + réseau routé IPv6
Le premier principe que j’applique est que j’utilise un réseau NATé IPv4 et un réseau routé IPv6, c’est à dire que les VMs sont adressées sur un réseau IPv4 « privé » tandis qu’elles sont dans le même temps adressées sur un réseau IPv6 public et routé.
Dans l’exemple ci-dessous (infra Gozmail), j’ai l’adresse IPv4 publique 89.234.176.19/32 et le préfixe IPv6 2a00:5881:1044:d300::/56 qui ont été attribués à ce serveur par l’hébergeur (FAI Maison), à l’intérieur duquel le préfixe 2a00:5881:1044:d300::/64 est utilisé sur le lien entre le serveur et le routeur.
Pour ce faire, j’adresse le proxmox avec l’IPv4 publique et le préfixe IPv6 utilisé sur le lien physique :
eth0 : 89.234.176.19/32 | 2a00:5881:1044:d300::1/64
Sur le bridge vmbr0 qui contient le réseau de VMs, j’adresse les VMs avec un préfixe IPv4 « privé » (RFC 1918) et un second préfixe IPv6 /64 (à l’intérieur du préfixe qui m’a été attribué) :
vmbr0 : 192.168.10.0/24 | 2a00:5881:1044:d301::/64
±> vm1-eth0 : 192.168.10.1 | 2a00:5881:1044:d301::1
±> vm2-eth0 : 192.168.10.2 | 2a00:5881:1044:d301::2
±> vm3-eth0 : 192.168.10.3 | 2a00:5881:1044:d301::3
J’active le forwarding IPv4 et IPv6, et en IPv4 spécifiquement je mets en place les règles de masquerading pour le trafic sortant et de DNAT pour le trafic entrant.
2nd principe : Différenciation du nommage des VMs (pour l’administration) et des services
L’avantage d’avoir un réseau routé est qu’on peut accéder aux VMs pour l’administration sans faire de redirection de ports. Dans mes premiers déploiements, j’avais utilisé les mêmes noms de domaine pour nommer les service et pour administrer les VM. C’est une erreur, surtout si on utilise un adressage différent en IPv4 et IPv6, car dans ce cas on est obligé de configurer des redirections de port pour l’accès SSH.
Désormais, j’applique donc systématiquement le principe de distinguer les sous-domaines, et :
- Pour le nommage de l’hôte (proxmox), je déclare son IPv4 et son IPv6 publiques:
px.example.net. IN A 89.234.176.19
px.example.net. IN AAAA 2a00:5881:1044:d300::1
- Pour le nommage des VMs, je ne déclare que leur IPv6 publique:
vm1.px.example.net. IN AAAA 2a00:5881:1044:d301::1
vm2.px.example.net. IN AAAA 2a00:5881:1044:d301::2
vm3.px.example.net. IN AAAA 2a00:5881:1044:d301::3
- Pour le nommage des services, je déclare l’IPv4 publique (du proxmox) et l’IPv6 publique (de la VM qui héberge le service)
service1.example.net. IN A 89.234.176.19
service1.example.net. IN AAAA 2a00:5881:1044:d301::1
La quasi-totalité des hébergeurs résidentiels fournissent une connectivité IPv6 (parfois désactivée par défaut), donc ne pouvoir administrer ses VMs qu’en IPv6 n’est pas si handicapant qu’on puisse le croire. Sachant que au besoin, il est toujours possible d’utiliser un rebond SSH sur l’hôte pour accéder à la VM (ssh -J).
3eme principe : Utilisation de routeurs et de proxys applicatifs
Il est important de distinguer la fonction de routage/firewalling/NAT (qui opère au niveau 3/4) de la fonction de proxy (qui opère au niveau 5/6/7). Donc il faut les mettre dans des VMs séparées. Sur mes proxmox, la fonction de routeur est parfois assurée par une VM spécifique, et parfois assurée par l’hôte. En revanche, la fonction de proxy est toujours assuré par une VM.
En bref :
- Routeur : Assure le routage, le NAT, et le firewalling, pour différentier les services au niveau TCP (en fonction du numéro de port)
- Proxy : Assure la terminaison TLS et le front-end protocolaire, pour différentier les services au niveau applicatif (en fonction du nom de domaine ou de l’URL)
Il s’agit donc d’une différenciation à 2 niveaux. Au premier niveau, le routeur va agir en DNAT et répartir le traffic IPv4 sur les différentes VMs en fonction du port de destination (pour rappel le DNAT n’est pas nécessaire dans le cas d’IPv6 et on utilise un routage simple) :
- Ports 25, 143, 489, 587, 993, 4190 → VM mail
- Port 53 → VM DNS
- Ports 80, 443 → VM proxy HTTP
Au second niveau, pour les services qui doivent être différenciés au niveau applicatif, le proxy applicatif va répartir le traffic sur les différentes VM en fonction du NDD :
Configuration du proxy
Pour réagir par rapport à la question initiale :
Sur tous les proxy que j’ai configuré, j’ai utilisé un nginx en terminaison TLS et reverse proxy HTTP. C’est simple et ça fonctionne bien.
J’imagine qu’en lisant l’entête TLS SNI, il doit être possible de rediriger le trafic TLS vers la VM sans déchiffrer le trafic, je ne sais pas si c’est ce que tu entends par l’option 2 ?
Par ailleurs, si tu as les ressources suffisantes sur ton serveur, je suggérerais de ne pas mélanger des conteneurs et des VMs pour ne pas amener de l’hétérogénéité qui ne serait pas nécessaire.
