Configuration ip proxmox problématique

svp, ça fait 3 jours que je suis dessus je m'arrache les cheveux :/.
En proxmox 3 avec une config similaire ça marchait, mais là sous proxmox 5, niet

Bonjour
il y a beaucoup de choses qui fonctionnaient très bien en Proxmox 3.4 OpenVZ
et qui ne fonctionnent plus en Proxmox 4 ou 5 basé sur LXC.

- ajout d' IP "on the fly" ... faut arrêter le conteneur
- réduction de la taille des conteneurs (si tu augmentes pour un problème temporaire, tu ne sais plus réduire la taille)
- plusieurs IPs sur un conteneur ... ça ne fonctionne QUE si tu as des conteneurs "unpriviledge" ...
càd PAS si tu as juste transféré tes anciens conteneurs OpenVZ
- si tu mets plusieurs IP sur un conteneur "normal", aléatoirement à chaque démarrage, une seule des IP fonctionne :-(

- en Proxmox 3 OpenVZ : pas besoin de jouer avec les Mac Addresses virtuelles. OpenVZ se débrouillait tout seul...
- pas d'isolement des ressources CPU etc, sauf si tu as un conteneur unpriviliedge
par ex, dans un HTOP, tu vois TOUS les cpu et tu vois la charge globale du serveur, et pas de ton conteneur (sauf si unpriviledge)

Globalement, ma migration de Proxmox 3.4 OpenVZ vers Proxmox 4.3 LXC a été TRÈS pénible !
J'ai perdu un temps énorme et j'ai dû conserver 2 serveurs en simultanés beaucoup plus longtemps que prévu.
J'ai dû dédoubler les conteneurs venant d' OpenVZ, uniquement car j'avais 2 ou 3 IPs...
ça me bouffe des ressources ram et disque...

C'est très décevant...
J'avais un serveur Proxmox 3.4 OpenVZ qui était SOLIDE, efficace, souple, rapide.
J'ai maintenant un serveur Proxmox 4.3 (puis 5.2) avec des problèmes multiples, moins stable, qui consomme beaucoup plus car j'ai dû copier 2 ou 3x le même conteneur car plusieurs IPs etc.

Je n'ai pas bien suivi ton problème d' IP FO, mais si c'est le fait de mettre plusieurs IPs sur le même conteneur, ça n'ira que si tu as un conteneur Unpriviledge...

Didier

merci pour cette réponse. Quand as tu eu ces problèmes ? Parce que apparemment il existe la commande pct resize pour redimensionner un container lxc.
SI ça se trouve, d'autres problèmes ont étés "corrigés" aussi ...

non, pct resize ne fonctionne, d'après ce que j'ai lu, QUE pour augmenter la taille d'un conteneur !

https://serverfault.com/questions/784890/how-to-shrink-the-disk-of-a-lxc-container-on-proxmox-4

\+?\d+(\.\d+)?[KMGT]?
The new size. With the + sign the value is added to the actual size of the volume and without it,
the value is taken as an absolute one. **Shrinking disk size is not supported**.

C'est très limitatif !
Tu as un process qui a bouffé ta place disque (des backups par ex), si tu augmentes la taille le temps de trouver ce qui se passe et de faire du nettoyage, IMPOSSIBLE en suite de réduire la taille.

Ou alors, tu dois créer un nouveau conteneur vide, refaire toute la config et déplacer tous tes sites et data.

pfffff...

J'ai eu tous ces problèmes en déplaçant mes conteneurs OpenVZ Proxmox 3.4 vers le nouveau serveur Proxmox 4.3 LXC.
J'ai simplement restauré les backups des conteneurs.
Démarré...

Puis j'ai eu la très mauvaise surprise de découvrir que les conteneurs qui avaient 4 ou 5 IPs (une par site important), certains sites ne fonctionnaient pas car, aléatoirement, UNE SEULE IP fonctionnait à la fois.

Je pensais basculer de l'ancien serveur Proxmox 3.4 vers le nouveau 4.3 en 2 semaines...
ça m'a pris plus de 2 mois !
(ok, pas dispo tout le temps)
Les problèmes, je ne les ai pas compris tout de suite...

Par ex aussi, malgré qu'il semble qu'on puisse spécifier une IP avec un MASQUE (/32 ... /28...) et bien NON ! Il faut définir les IP une à la fois, chacune avec un /32 ...

Je n'ai pas compris tout de suite non plus qu'il fallait créer des Mac virtuelles dans le manager OVH et les définir manuellement (....) dans chaque interface des conteneurs.

Avec Proxmox 3.4 OpenVZ, c'était tout à fait automatique. Jamais dû créer une Mac Virtuelle...

Et quand tu as 16 IPs, il faut générer 16 Mac virtuelles ... et le manager OVH ne te permet pas de générer les 16 Mac en un coup. Il faut attendre que la 1ère soit crée pour faire la 2ème, etc ...

:-(

même si j'utilise NAT tu penses que je dois autoriser les macs des conteneurs dans les ips failover ?
Et si deux vm peuvent accéder à la même ip publique, on fait comment du coup ?

moi ce n'est pas une ip aléatoirement qui marche, mais juste la première configurée qui marche
en j'ai juste l'ip qui est dans la route par défaut qui fonctionne

en fait si j'utilise tcpdump sur l'hote, je vois le paquet partir et la réponse arriver, mais ça n'arrive pas jusqu'à la vm

Je pensais basculer de l'ancien serveur Proxmox 3.4 vers le nouveau 4.3 en 2 semaines...
ça m'a pris plus de 2 mois !
(ok, pas dispo tout le temps)
Les problèmes, je ne les ai pas compris tout de suite...

Par ex aussi, malgré qu'il semble qu'on puisse spécifier une IP avec un MASQUE (/32 ... /28...) et bien NON ! Il faut définir les IP une à la fois, chacune avec un /32 ...

Si vous utilisez un NAT, il n'est pas nécessaire d'utiliser des MACS virtuelles sur vos containers. Par contre pour chaque IP Failover, il faut associer une MAC virtuelle pour chaque interface réseau d'un container. Sinon le traffic ne sera pas routé vers l'IP de votre container.

La documentation Proxmox explique tout cela en détail : https://pve.proxmox.com/wiki/OVH
Vous pouvez également trouver la version français dans la doc ovh.ca : http://docs.ovh.ca/fr/guides-network-bridging.html

j'ai déjà regardé les liens, mais ça ne correspond pas vraiment à ma config, vu que j'utilise nat et masquerade (voir premier post)

Peut-être oui, mais je n'avais JAMAIS dû générer une Mac Address Virtuelle dans la manager OVH avec l'ancien Proxmox OpenVZ... souple, rapide, efficace.
A part l’esthétique très réussie, le nouveau Proxmox ne m'a pas apporté grand chose, sauf des problèmes et un manque de souplesse...

ajout d' IP "on the fly" ... faut arrêter le conteneur
réduction de la taille des conteneurs (si tu augmentes pour un problème temporaire, tu ne sais plus réduire la taille)
plusieurs IPs sur un conteneur ... ça ne fonctionne QUE si tu as des conteneurs "unpriviledge" ...
càd PAS si tu as juste transféré tes anciens conteneurs OpenVZ
si tu mets plusieurs IP sur un conteneur "normal", aléatoirement à chaque démarrage, une seule des IP fonctionne :-(
en Proxmox 3 OpenVZ : pas besoin de jouer avec les Mac Addresses virtuelles. OpenVZ se débrouillait tout seul...
pas d'isolement des ressources CPU etc, sauf si tu as un conteneur unpriviliedge
par ex, dans un HTOP, tu vois TOUS les cpu et tu vois la charge globale du serveur, et pas de ton conteneur (sauf si unpriviledge)

Pour un NAT, il suffit d'ajouter un bridge (attention il faut redémarrer le serveur pour appliquer la configuration) :

https://img.virtubox.net/images/2017/12/01/Screenshot197.png

Puis utiliser :
```
iptables -t filter -A FORWARD -o vmbr0 -j ACCEPT
iptables -t filter -A FORWARD -i vmbr0 -j ACCEPT

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o vmbr0 -j MASQUERADE
```
Pour utiliser notre bridge en tant que NAT. Pour les containers, il suffit alors de définir l'IP et le gateway.

```text je l'ai déjà fait, voiir ci après la config de l'hote

auto vmbr1
iface vmbr1 inet manual
bridge_ports dummy0
bridge_stp off
bridge_fd 0

auto vmbr0
iface vmbr0 inet static
address (external ip 1)
netmask 255.255.255.0
gateway (external ip 1).254
broadcast (external ip 1).255
bridge_ports eth0
bridge_stp off
bridge_fd 0
network (external ip 1).0

auto vmbr100
iface vmbr100 inet static
address 192.168.0.254
netmask 255.255.255.0
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 '192.168.0.0/24' -o vmbr0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '192.168.0.0/24' -o vmbr0 -j MASQUERADE
post-up iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 1022 -j DNAT --to 192.168.0.1:22


auto vmbr2
iface vmbr2 inet static
address (external ip 2)
netmask 255.255.255.255


auto vmbr101
iface vmbr101 inet static
address 192.168.1.254
netmask 255.255.255.0
bridge_ports none
bridge_stp off
bridge_fd 0
post-up iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT --to-source (external ip 2)
post-down iptables -t nat -D POSTROUTING -s 192.168.1.0/24 -j SNAT --to-source (external ip 2)

Et la config de la vm :


et voici se qu'il se passe quand je tape ces commandes dans la vm :
curl "http: wtfismyip.com/text" --interface venet1 -4
(timeout)
curl "http: wtfismyip.com/text" --interface venet0 -4
(external ip 1)
curl "http: wtfismyip.com/text" --interface 192.168.1.1 -4
(timeout)
curl "http: wtfismyip.com/text" --interface 192.168.0.1 -4
(external ip 1)


et quand je tape les mêmes commandes dans l'hote :
curl "http: wtfismyip.com/text" --interface 192.168.0.254 -4
(external ip 1)
curl "http: wtfismyip.com/text" --interface 192.168.1.254 -4
(external ip 2)
curl "http: wtfismyip.com/text" --interface vmbr0 -4
(external ip 1)
curl "http: wtfismyip.com/text" --interface vmbr2 -4
(timeout)

je n'ai donc accès qu'à une seule ip depuis la VM.
j'ai tenté de faire les 2 commandes
iptables -t filter -A FORWARD -o vmbr0 -j ACCEPT
iptables -t filter -A FORWARD -i vmbr0 -j ACCEPT

mais ça n'a rien changé ```

Bridge, jamais testé.
Mais donc, c'est un NAT hide ?
càd que les sessions sortantes du conteneur ou VM sont vues de l'extérieur comme venant de l' IP du serveur Proxmox ?

ok, simple...
mais je voulais éviter cela et, niveau référencement et sécurité, avoir des IPs différentes par conteneurs, parfois par sites web (pour les plus importants).

plusieurs IP, ça évite aussi d'avoir une IP blacklistée par un forum qui spam car pas à jour ;-)

ma config c'est dans mon exemple le port 1022 redirige vers la vm sur le port 22, tout le reste dans la vm n'est pas joignable
et ensuite que ce soit la vm ou l'hote, tout ce qui part depuis 192.168.0.X utilise l'ip externe 1
et 192.168.1.X utilise l'ip externe 2

ok, je me rappelle sur l'ancien serveur, j'avais fait du NAT en entrée pour du SSH.
J'avais aussi un numéro de port différent par Conteneur !
du genre
ct234 : port 1234 --> SSH 22 conteneur 234
ct 238 : port 1238 --> SSH 22 conteneur 238
etc

ça fonctionnait bien.
Mais finalement, je n'ai pas bcp utilisé ces numéros de port SSH

oui c'est ce que j'ai fait, ça ça marche, mais c'est dans le sens inverse qui ne marche pas :)
utiliser une ip externe au choix depuis ma vm

et sur l'hote, ça "marche", avec les 2 ips, mais bizarrement si je met le nom de l'interface qui contient l'ip2, ça ne marche pas

```text info supplémentaire, si je tape
tcpdump -eni vmbr0 port 80

pour voir le traffic sur l'interface vmbr0, et que je tape sur la vm
curl "http://wtfismyip.com/text" --interface 192.168.0.1 -4
je vois bien les paquets qui partent et reviennent avec l'adresse mac X
et si je tape
curl "http://wtfismyip.com/text" --interface 192.168.1.1 -4
je vois pareil les paquets qui partent et reviennent avec la même adresse mac X, mais rien n'arrive jusqu'à la vm, ça reste coincé dans l'hote ```

hello,
je suis toujours bloqué à la recherche d'aide,
merci :)

Tu as bien généré une MAC Address virtuelle OVH pour cette IP dans le Manager OVH ?
Et tu l'as bien assignée dans la configuration de ton interface pour cette VM dans Proxmox ?
(question simple... mais parfois on oublie un truc, ou on fait une petite erreur...)

Bonnes fêtes. Didier

merci de ta réponse et bonne fêtes.
j'ai cependant trouvé ma solution, et non je n'ai pas de mac virtuelle, ce n'est pas nécessaire dans ma configuration nat.
la solution était de mettre rp_filter = 2 sur la vm
et proxy_ndp = 1 sur l'hote

en Proxmox 3 OpenVZ : pas besoin de jouer avec les Mac Addresses virtuelles. OpenVZ se débrouillait tout seul...

Oh je déterre un vieux topic, mais en même temps, c'est toujours d'actualité.

Avec OpenVZ, c'était simple, très simple ...
LXC, une grosse daube, rien de logique ... Gestion calamiteuse des IP failover, pas de réel quota intégré, franchement, c'est un retour en arrière.
Sans parler des configs de LXC 1, 2 3 et 4 qui changent tous les 4 matins, on est très très loin de l'esprit "Linux" :-(

Encore en 2020 je dois me battre entre des OpenVZ et les nouveaux LXC.
En plus sur 2 serveurs fraichement installés chez OVH :
Fedora 32 : LXC ne fonctionne plus depuis FC31, suite à un bug non encore corrigé
Proxmox 6 (avec LXC 4) : création de VM via interface graphique, puis lancement : ben aucune VM ne démarre ...
Bref j'ai du installer une ... Debian 8 avec LXC 1, qui au moins fonctionne ...

Avec systemd, la fin de rsyslog, et les packages qui sont de plus en plus brouillons et développés à la va vite histoire de faire bien au café du coin, c'est de pire en pire Linux et c'est très dommage ... (Bon, on reste au dessus de Windows, c'est déjà ça ... mais on en rejoins la vision ...).

A une époque où on veut tout virtualiser, ben les outils actuels ne permettent pas de le faire sans problème et sans se retrouver dans une usine à gaz, c'est malheureux ...

Bonjour,

Il ne me semble pas que lxc soit un problème comme tu l'indique.
Pour Proxmox6, il y a une mise à jour kernel à faire je pense, et donc un reboot du serveur dédié pour que les conteneurs lxc puissent démarrer correctement.
En effet, ce n'est pas explicite mais avant de prendre en main un serveur fraichement installé, je conseille de faire l'upgrade et un reboot pour garantir de partir sur de bonnes bases.

Qu'est qui pose problème pour la gestion des ip avec lxc ?
De plus avec l'interface proxmox, il est assez simple de les configurer et d'avoir des ipfailover fonctionnelles rapidement.
Il faut peut-etre prendre en compte que le conteneur doit avoir 1 seule tâche et qu'il est peut-être nécessaire de diviser le nombre de machine pour mieux répartir les services.

Je pense que tu bloques sur pas grand chose et que cela peut s'améliorer.

Bon courage
https://www.captainadmin.com

Qu'est qui pose problème pour la gestion des ip avec lxc ?
De plus avec l'interface proxmox, il est assez simple de les configurer et d'avoir des ipfailover fonctionnelles rapidement.

J'approuve. Et pourtant j'en ai eu des galères. Mais ça ne venait pas de Proxmox/LXC.