Infrastructure Seveur Proxmox 1IP V4/V6 plusieurs VMs

Bonjour,

Je vais prendre un nouveau serveur dédié pour heberger des services perso et pour une association avec deux voir trois NDD.

Je souhaiterais votre avis sur l’architecture que je pense déployer (sachant que c’est que de l’amateurisme).

Donc en gros :

  • Proxmox avec 1IPv4 et 1V6 (je suis complètement débutant en IP V6),
  • Une VM OpenSense (un intérêt ou pas ?)
  • Un LXC (Nginx Proxy Manager avec Crowdsec)
  • VM Yunohost Perso
  • VM Yunohist Asso

Version sans pare-feu
En gros les NDD pointent vers le LXC NPM+crowdsec
Ou je fais :

  • Soit une redirection sans SSL *.ndd1.fr vers IP VM1, *.ndd2.fr vers IP VM2, etc etc
    Gestion des ssl via Yunohost

  • Soit gestion SSL via NPM et donc chaque sous domaine doit être effectués a la main vers l’IP:port.

Ou alors ca va pas du tout je débloque?

Merci d’avance

En plus simple, tu pourrais mettre en œuvre ce qui est proposé sur ce lien:

En gros, un yunohost en frontal qui fait reverse proxy pour l’autre yunohost. (après le proxmox donne une souplesse pour réaliser des snapshots)

Merci @ljf c’etait un peu toi que j’interpelé par ces questions car je crois savoir que tu geres des instances Yunohost

Je n’ai pas prescisé mais je ne compte pas me servir de la fonction mail de Yunohost, trop souvant spamlisté (lorsque j’avais mon serveur Yunohost, peut etre que ca a changé).

Je vais regarder ca mais on commence a toucher du dur lol.

En gros j’envoie les NDD depuis OVH vers une VM YNH qui les rediriges (comment ??) vers mes differentes instances ?

  1. Le SNI Foward est deja implementé dans YNH ? ou c’est a titre experimental ?

  2. Il faut que je modifie le fichier Nginx a la mano ?

Ben le lien que je t’ai filé est une fonctionnalité qui n’est pas encore présente dans YunoHost. Mais tu peux t’inspirer des configurations pour faire la même chose.

Sinon, moi j’utilise dans ce genre de cas, j’utilise un VPN ARN (avec vpnclient). Note que si tu as pas de sous, tu peux payer ton VPN ARN en monnaie libre (Ĝ1), même si il reste l’adhésion à 15€.

Ca me rajout une complication en plus lol.

Juste pour savoir ,

Mettre un NPM en front ca le ferais pas ?

Si ça le fait

Ok je vais aller simple alors et puis monter en competence au fur a mesure :wink:

A ton avis un interet a mettre un parefeu avant tout ca ? sachant que je vais mettre un NPM avec Crowdsec (qui fait parefeu) ?

Avant de répondre sur le reste, je vais réagir sur ce point. Quand tu dis qu’on t’a fourni 1 IPv6, est-ce réellement 1 IPv6 (c’est à dire un /128 IPv6) ? On ne t’a pas fourni un préfixe (/64, /60, /56, etc) ?

Bonsoir et merci 0pour ton intéressement.

Je suis chez Ecowan, je pense que c’est ipv6 /64 (c’est ce que j’ai quand je fais un ip a)

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.

1 Like

Hiho good people,

J’arrive un peu après la guerre, mais est-ce qu’un HA Proxy ne ferait pas l’affaire dans ce genre de situation ? Je l’utilise pour héberger plusieurs services (e.g. hedgedoc, uptime Kurma, etc. sur des noms de domaine différents) sur une même machine et ça se passe plutôt bien.

En quelques mots, HA Proxy permet non seulement le load balancing, mais également (si l’on a qu’un serveur pour chaque service) de la répartition basique de requêtes sur plusieurs services, quelque soit le protocole. S’il y a de nombreux services la conf pourrait être trapue, mais peut-être pas plus que de gérer une instance plus complexe en front-end.

Peut-être qu’il me manque des éléments ; si j’ai loupé quelque chose d’évident, toutes mes excuses. :wink:

@sekil Merci pour ces explications assez claires.

Tu viens de m’eclairscir un point avec l’adresse IPv6 que je n’avais jamais compris.

Donc si comprend bien et avec les elements suivant ipv4 xxx.xxx.xxx.xxx/24 et ipv6 feXX::2XX:a2XX:feXX:2aXX/64. et sulement pour les VMs

  1. Je créé un vmbr0 avec pour IPv4 192.168.10.0/24, une IPV6 feXX::2XX:a2XX:feXX:2aXX/64 (adresse public) associé au port enp1s0

  2. je créé mes VM avec un eadresse IPV4 dans le reseau 192.168.10.x et une ipv6 avec adresse public feXX::2XX:a2XX:feXX:2aXX::X

  3. Le forwarding IPV4 s’active dans le fichier /etc/sysctl.conf

  4. Pour l’IPv6 il n’y a rien a forwarder vu que c’est une adresse public de type feXX::2XX:a2XX:feXX:2aXX::X

  5. j’envoie :

  • nddYNH1 vers l’adresse IPv6 de la VM1 feXX::2XX:a2XX:feXX:2aXX::1
  • nddYNH2 vers l’IPv6 de la VM2 feXX::2XX:a2XX:feXX:2aXX::2

Par contre je n’ai pas tout compris sur le routeur et les DNS

Merci encore

Non tu n’arrive pas apres la guerre je suis toujours bloqué. :upside_down_face:

Arf, oui mais là non. :wink:

L’adresse fe80:… est une adresse spéciale. C’est ce qu’on appelle une adresse lien-local qui est générée automatiquement par l’OS sur toutes les interfaces et qui sert à faire fonctionner les protocoles réseau qui fonctionnent sur le lien : Lien-local - Livre IPv6

Ces adresses ne sont pas globales, pas routables, et ne peuvent donc pas être utilisées pour adresser des services ou des machines sur Internet.

Il faut que tu demandes à ton hébergeur quel est ton préfixe IPv6 public si tu veux pouvoir le configurer.

Est-ce que ça veut dire que tu vas mettre tes VMs et ton interface physique sur le même bridge ? Si c’est le cas, pour moi ce n’est pas une bonne pratique parce que tu vas assigner des IPv4 privées à tes VMs et utiliser du routage.

Il est préférable de choisir entre les 2 options :

  • Soit tu bridges ton interface physique avec les interfaces des VMs, auquel cas tu utilises du bridging et non du routage et donc chaque VM nécessitant un accès Internet doit avoir une IP.
  • Soit tu ne bridges pas ton interface physique avec les interfaces des VMs, auquel cas tu utilises du routage.
    Une voie hybride est possible mais soyons clair, la configuration sera plus complexe.

Bah si tu utilises du routage, par définition il faut activer le forwarding (forwarding = routage). Si tu utilises du bridging, effectivement il n’y a pas besoin d’activer le forwarding.

Cf ci-dessus, des adresses fe80 ne permettent pas d’adresser des machines sur Internet.

Effectivement, ce cas d’usage fait normalement partie des fonctions de base de HAProxy. Personnellement je n’ai jamais utilisé HAProxy donc je te fais confiance. :wink:

ce serait trop simple :wink: je vais voir avec eux

Je comprend qu’il est preferable de faire un VMBR par VM ?

Non, ce n’est pas ce que j’ai dit.

Il faut 1 bridge (vmbr0 par exemple) :

  • sur lequel sont attachées toutes les VM
  • mais sur lequel n’est pas attaché l’interface ethernet physique du serveur

Mais j’ai peut-être mal compris ta phrase : « Je créé un vmbr0 (…) associé au port enp1s0 »

Ok non non c’est moi qui avait mal compris.

Et donc dans ce cas ton VMBR0 il communique comment sur internet ? via le Pare feu avec son WAN sur enp1s0 et son LAN sur vmbr0 ?