Promox derrière une IP

rodinux · Juillet 17, 2024, 12:27

Bonjour,

Je cherche de l’aide pour mettre en place un configuration réseau sur un Promox qui n’a qu’une IP… Chose que nous avons déjà fait sur un.autre node Promox., mais là je galère…

sekil · Juillet 17, 2024, 6:00

C’est tout un sujet !

Je peux t’aider puisque j’en ai mis plusieurs en prod dans ce style, par contre où est-ce que tu bloques, et de quel type d’aide as-tu besoin ?

Tu as une seule IPv4 ? Possibilité ou non d’en récupérer une seconde ?
Tu as un préfixe IPv6 ou pas ? Possibilité ou non d’en récupérer un ?

rodinux · Juillet 18, 2024, 8:07

Sur ce Promox il y a juste une IPv4. Il me semble que cette IP est déjà derrière un NAT…

J’ai ajouter une interface vmbr1 pour avoir des IP en 10.30.30.* en éditant ainsi /etc/network/interfaces

auto lo
iface lo inet loopback

iface eno1 inet manual

iface eno1.2 inet manual

iface eno2 inet manual

iface eno3 inet manual

iface eno4 inet manual

auto vmbr0v2
iface vmbr0v2 inet static
	address XXX.XX.XX.8/24
	gateway XXX.XX.XX.1
	bridge-ports eno1.2
	bridge-stp off
	bridge-fd 0

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


source /etc/network/interfaces.d/*

J’ai mis en place une VM avec une instance Portainer sur une adresse IP locale 10.30.30.2.

Puis j’ai tenté de jouer avec des règles pour que certains ports puisse être joignable

-# VM-Docker2 10.30.30.2:9000  
 post-up iptables -t nat -A PREROUTING -p tcp -d 'XXX.XX.XX.8' --dport 9000 -i vmbr0v2 -j DNAT --to-destination 10.30.30.2:9000
-
-# VM-Docker2 10.30.30.2:8000
 post-up iptables -t nat -A PREROUTING -p tcp -d 'XXX.XX.XX.8' --dport 8000 -i vmbr0v2 -j DNAT --to-destination 10.30.30.2:8000

Mais ça ne semble pas fonctionner ainsi…

J’ai essayé aussi en ajoutant netmask 255.255.255.0 à vmbr0v2 et à vmbr1…

rodinux · Juillet 18, 2024, 8:27

Quoi que, il me semble que j’ai peut-être du mieux… des erreurs de ssl et de pare-feu sur l’adresse XXX.XX.XX.8:9000 et XXX.XX.XX.8:9443…

Je devrais commencer par installer soit un nginx-proxy, soit un traefik pour gérer les IPs…

LautreG · Juillet 18, 2024, 2:19

Oui, pour les services web, il te faut un Proxy-SNI.

Soit Nginx
Soit HA-Proxy (si tu veux gérer aussi les emails entrants)

sekil · Juillet 22, 2024, 7:45

Il faut être clair sur l’existant parce que de là influe beaucoup ce que tu peux faire et ce que tu ne peux pas faire. Déjà si tu es derrière un NAT il faut que le routeur ait lui-même défini des redirections de port ou une DMZ vers ton IP.

C’était aussi l’objet de mes questions, on peut faire une conf plus propre avec 2 IPv4 lorsque c’est possible parce qu’on peut en assigner une à l’hôte et l’autre aux VMs.

Et quand IPv6 est disponible, il faut en profiter pour le configurer parce que (outre le fait que ne pas configurer IPv6 en 2024 c’est aberrant), ça permet d’avoir un accès non NATé aux VMs, c’est particulièrement pratique pour un accès SSH par exemple.

J’aurais les remarques suivantes :

Dans ta configuration l’adresse assignée à vmbr1 est 10.30.30.0 (au sein d’un sous-réseau /24), ce qui est non conforme en IPv4, car la première et la dernière adresse du réseau sont réservées. En d’autres termes, pour un /24, les adresses X.Y.Z.0 et X.Y.Z.255 ne sont pas assignables. Je ne sais plus dans quelle mesure Linux le permet ou non.
A noter que iptables est obsolète, nft est la nouvelle interface de référence (en réalité iptables transcrit ses règles en règles nft)

Spécifier netmask 255.255.255.0 est équivalent à ajouter /24 à la fin de la directive address

sekil · Juillet 22, 2024, 7:47

Voici un exemple de ce qu’on peut faire en adressage réseau IPv4 + IPv6 sous Proxmox : Infrastructure Seveur Proxmox 1IP V4/V6 plusieurs VMs - #12 par sekil

rodinux · Juillet 22, 2024, 8:15

Ok, c’est vrai que pour l’instant on ne s’occupe pas de l’IPv6 dans nos infras… Je vais devoir plancher sur cette « aberration », il me semble…

J’avoue être un peu perdu pour l’instant. En tous les cas côté Promox il y a bien un fichier /etc/network/interfaces qui permet de jouet avec les iptables, mais par exemple sur la première VM où est installée Docker et Portainer, les fichiers de configurations network ne sont pas dans /etc/network/interfaces mais dans /etc/netplan/50-cloud-init.yaml

Voici ce que me renvoi ip a sur le serveur Promox sachant que l’interface natée du serveur est eno1.2

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:09 brd ff:ff:ff:ff:ff:ff
    altname enp1s0f0
    inet6 xxxx::xxxx:xxxx:xxxx:xx09/64 scope link 
       valid_lft forever preferred_lft forever
3: eno2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:0b brd ff:ff:ff:ff:ff:ff
    altname enp1s0f1
4: eno3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:0d brd ff:ff:ff:ff:ff:ff
    altname enp1s0f2
5: eno4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:0f brd ff:ff:ff:ff:ff:ff
    altname enp1s0f3
17: eno1.2@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0v2 state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:09 brd ff:ff:ff:ff:ff:ff
18: vmbr0v2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:09 brd ff:ff:ff:ff:ff:ff
    inet xxx.xx.xx.8/24 scope global vmbr0v2
       valid_lft forever preferred_lft forever
    inet6 xxxx::xxxx:xxxx:xxxx:xx09/64 scope link 
       valid_lft forever preferred_lft forever
19: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:cd brd ff:ff:ff:ff:ff:ff
    inet 10.30.30.0/24 scope global vmbr1
       valid_lft forever preferred_lft forever
    inet6 fe80::7ccd:e6ff:fe2f:4206/64 scope link 
       valid_lft forever preferred_lft forever
20: tap100i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr1 state UNKNOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:cd brd ff:ff:ff:ff:ff:ff

sekil · Juillet 22, 2024, 8:46

Pas exactement. /etc/network/interfaces est un fichier de configuration uniquement orienté sur la configuration réseau, et mais ne gère pas la configuration netfilter/iptables (il n’y a pas de directive native pour définir les règles iptables). Lorsqu’on voit des règles iptables dans des configurations /etc/network/interfaces, elles sont appelées via des directives post-up (qui permettent d’appeler des commandes shell arbitraires).

La configuration /etc/network/interfaces n’est pas la manière native et unique de configurer le réseau sous Linux, c’est seulement une des manières les plus utilisées. /etc/network/interfaces est la configuration du frontend de configuration ifupdown, particulièrement utilisé par les distributions basées sur Debian (dont Proxmox fait partie). Il existe de nombreuses autres frontend, notamment netplan, network-manager ou systemd-networkd.

Donc :

Tu définis ta configuration réseau via le frontend de configuration réseau utilisé par ta distribution (/etc/network/interfaces, network-manager, netplan, autre).
Au boot, lorsque les interfaces deviennent disponibles, ou lors d’événements particuliers, le frontend de configuration passe les commandes au noyau Linux pour pousser la configuration des interfaces.
Lorsque tu appelles la commande ip, c’est une interface directe et native donc tu accèdes à la configuration effective telle que chargée dans le noyau.

Enfin, dans ton conteneur docker, /etc/netplan/50-cloud-init.yaml est un fichier généré automatiquement par cloud-init, ce qui ne veut pas dire que c’est nécessairement cette configuration là qui est utilisée (elle l’est si-et-seulement-si netplan est installé).

Cloud-init est un système de gestion de configuration qui permet à ton hôte (Proxmox ici) de passer des informations de provisionnement à la VM ou au conteneur. Lorsque la VM ou le conteneur démarre, l’agent cloud-init installé dedans lit les informations fournies par l’hôte (par exemple ses informations réseau, son nom d’hôte, ou encore les clés SSH autorisées), et génère les fichiers de configuration pour configurer correctement le réseau de la VM/conteneur, son nom, et sa configuration SSH.

sekil · Juillet 22, 2024, 8:52

Quand tu dis natée, tu veux dire :

natée sur le Proxmox : auquel cas oui, c’est bien cette interface qui est natée d’après ta conf (ou plutôt le bridge vmbr0v2 qui intègre l’interface eno1.2)
ou bien natée en amont sur le routeur xxx.xx.xx.1

Ma question au sujet de ta remarque « Il me semble que cette IP est déjà derrière un NAT » portait sur l’environnement réseau dans lequel se situe le serveur, pas sur la configuration du serveur lui même. Parce que évidemment, s’il faut partager une IP pour plusieurs VM, il faudra forcément faire un DNAT pour le traffic entrant et un NAPT (=MASQUERADE) pour le traffic sortant.

LautreG · Juillet 23, 2024, 8:15

Il n’y a que Windows qui a du mal avec X.Y.Z.0, cela a peut être changé avec le temps.
Aucun soucis avec Linux, c’est une adresse comme les autres. C’est assignable, et ce n’est pas une adresse réservée.

Pour X.Y.Z.255 je n’en sais rien.