Proxmox range IP FO ?

Dans le manager OVH, j'ai créé une MAC Address virtuelle pour cette IP
et je l'ai mise dans la définition Proxmox de l'interface eth0.

La 1ère IP répond, mais pas les suivantes...

Dois-je générer dans le manager OVH 15 autres MAC Address virtuelles ?
Et je les renseigne comment dans la définition Proxmox ou Ubuntu ?

J'essaye d'ajouter une Gateway (???) pour le range de 16 IP, mais pas sûr de la syntaxe.
Si j'ajoute les 2 lignes :

post-up ip addr add 123.123.123.192/28 dev eth0

Bonjour Didier,
oui il faudra associer une MAC virtuelle pour chaque adresse IP et un masque 255.255.255.255.
Car le gateway d'un container est toujours l'adresse IP du serveur .254

https://img.virtubox.net/images/2016/12/15/Screenshot20DFGMT.png

Il n'est pas possible de faire autrement car les distributions linux n'accepte pas d'avoir un gateway qui n'est pas dans le même sous réseau que l'adresse IP du container.
Sur une VM KVM, c'est la même chose mais il faut le faire à la main après l'installation.

Bonjour VirtuBox

Ok, j'ai bien compris l'association de la MAC Address Virtuelle, de l'adresse IP et du Gateway dans l'adresse se termine par .255 :wink:
C'est d'ailleurs ce que je fais actuellement, en dépannage.

Mon problème, ce sont **les ranges IPv4** .
Quand j'essaie de définir un RANGE IP, disons 123.123.123.192/28 (16 IPs)
la 1ère est accessible, pas les suivantes.

Oui, je pourrais définir plusieurs interfaces :
- eth0 = 123.123.123.192/32
- eth1 = 123.123.123.193/32
- eth2 = 123.123.123.194/32
- eth3 = 123.123.123.195/32
...

Mais...
D'abord, c'est lourd. Dommage d'avoir un sous-réseau, un range IP, et de devoir tout définir une adresse à la fois.
Mais surtout, **ça bloque car Proxmox 4.3 accepte maximum 10 interfaces par conteneur LXC !**
Alors, je fais quoi pour mes ranges de 16 IPs ? :anguished:
Pas envie de perdre 6 IPv4 pour chaque range (sur plusieurs conteneurs LXC)

Donc, je suis bloqué...

Si tu as une idée :smiley:

Merci et bonne journée.
Didier

Oui, je pourrais définir plusieurs interfaces :

Le gateway des containers est en .**254** pas en .255.
Pour ce qui est des IPs, pourquoi souhaitez vous les mettre sur un seul et même container ?
Vous pouvez très bien créer 16 containers avec votre block, toujours en suivant la même configuration.
Enfin vérifiez bien les options DNS du serveur hôtés qui ne sont pas toujours correctes :

https://img.virtubox.net/images/2016/12/15/Screenshot21.png

Bonjour VirtuBox

Oui, GW .254
c'est une faute de frappe.

Pourquoi plusieurs IPs par conteneur ?
Mais parce que j'ai ces blocs d' IPv4, et que dans certains cas il est préférable d'avoir des IPs différentes par sites.

- plus facile en HTTPS : même si on sait faire plusieurs sites sur une même IP, ça peut poser des problèmes de certificats sur des anciens OS et anciens navigateurs qui ne supportent pas le SNI (je sais, ça devient rare...)
- niveau référencement, les sites ne sont pas tous équivalents en qualité ni en contenu : pratique d'avoir des IPs différentes, que Google sépare bien les sites
- risques, spam etc : ça arrive rarement, mais une IP qui spam, ou autre problème, ça impactera moins les autres.

DNS : j'ai laissé ce qui était indiqué : "use host settings"
et ça semble fonctionner, car mes conteneurs LXC ont bien accès à Internet (sur la 1ère IP). La résolution DNS se fait correctement.

Merci et bon WE :slight_smile:

DNS : j'ai laissé ce qui était indiqué : "use host settings"
et ça semble fonctionner, car mes conteneurs LXC ont bien accès à Internet (sur la 1ère IP). La

Bonjour Didier,
étant donner la légèreté d'un container LXC, je ferais tout simplement tourner un site par container.
Car pour les ips additionelles il faut également ajouter la passerelles mais j'avoue ne pas avoir tester cet usage pour le moment.
Après pour la partie HTTPS et référencement, Cloudflare peut régler votre problème sans nécessiter la moindre IP failover.

Bonjour VurtuBox

CLoudflare pose parfois problème quand certaines de ses IP sont bloquées (c'est arrivé dans certains pays qui bloquent des sites sans précautions en bloquant simplement l' IP).

Mais ok, c'est une solution probablement.

A propose de CDN, as-tu testé le CDN OVH ?
:smile:

D'accord avec toi, il semble que LXC soit léger.
En Proxmox 3.4, OpenVZ était léger.

Au sujet des conteneurs, as-tu déjà utiliser les conteneurs Unprivileged ?
Proxmox 4.4 devrait permettre d'en créer facilement.

Upgrade 4.4 : on doit attendre un peu avant cet upgrade je présume ?
(je n'ai pas de clé pour le dépôt Proxmox professionnel).

Upgrade 4.4 : on doit attendre un peu avant cet upgrade je présume ?

Pour le VPN, non je n'ai pas testé celui d'OVH car si il propose de très bon prix pour le volume de data, je n'ai clairement pas besoin de plus de 30Go de CDN/mois.

Pour ce qui est des containers unprivileged, il y a juste à cocher la case lors de la création.
https://img.virtubox.net/images/2016/12/17/gui-create-ct-general.png

Et pour recevoir les upgrade proxmox, il n'est pas nécessaire d'avoir un abonnement proxmox, il faut simplement vérifier dans /etc/apt/sources.list.d/ que le dépot pve-entreprise n'est pas utilisé (ajouté un # devant la ligne) et que par contre le pve-no-subscription est bien actif. Après quoi les mises à jour peuvent se faire depuis l'interface proxmox

ok, je reviens à mes ranges IPv4

Dans mon range de 16 IPv4, je prend 2 IP, donc un range /31.
123.123.123.196
123.123.123.197

J'ai généré une Mac Address virtuelle OVH sur la .196
(pas sur la .197 ... car je ne saurais PAS assigner 2 MAC sur la même interface...)

Dans Proxmox 4.3, je crée eth4 sur ce conteneur.
eth4 avec la Mac Address virtuelle OVH
et comme range IPs :
IPv4 = 123.123.123.196/31 ... donc 2 IPv4
GW = 123.123.123.254

Dans VirtualMin, je crée un site de test "test196...) sur l' IP .196
ok, il répond.
Quand j'essaie de créer un site "test197" sur l' IP .197, VirtualMin refuse en me disant "IP n'existe sur aucune interface" ...
:persevere:
ah ? Mais eth4 ? son masque est 255.255.255.254, donc 2 IPv4 ?

Bon, ça pourrait être VirtualMin qui me pose problème.
Je vais manuellement définir un VirtualHost Apache2 avec l'IP 123.123.123.197


ServerName test197.monsite.be

Ce site ne répond pas !

Donc, définitivement, Proxmox 4.3 ne sait pas gérer des ranges IPs ?
et il est limité à 10 interfaces ...

Ok, je peux comprendre ton argument "pourquoi autant d' IPs dans un conteneur" ...
et je peux contourner en créant plusieurs conteneurs (par ex, 2 conteneurs et mettre 8 interfaces dans chaque)

ok...

et IPv6 ?
Je teste aussi IPv6 ...
Et je tombe sur les mêmes limitations : mes sites répondent sur la 1ère IPv6 du range, mais sur aucune autre.

Avec IPv6, on reçoit un range /64 par serveur dédié.
ça fait des Milliards (et même bcp plus) d' IPv6. :smile:

Je devrais donc pouvoir en attribuer des milliards ou des millions d' IPV6 par conteneur... mais je serai donc limité à 10 IPv6 ? :flushed:
hum...
ce n'est pas l'esprit IPv6 ça :sunglasses:

ok, je reconnais que je n'ai PAS besoin de milliers d' IPv6 par conteneur LXC... mais cette limitation surprend !
:smile:

Donc, je peux m'en sortir oui, avec plusieurs interfaces par conteneur, et dupliquer certains conteneurs (en fait, j'ai 1 seul CT avec 16 IPv4).
Mais je suis surpris par cette limitation de LXC...

Merci

"unprivileged container" : Ok !

Mais comme je suis en train de migrer mes conteneurs OpenVZ 4.3 vers LXC Proxmox 4.4, je n'ai pas vu cette option.
ça peut se modifier ensuite ?

Mise à jour :
- j'ai mis en commentaire le dépôt "enterprise.proxmox.com/debian"
- j'ai donc le dépôt "download.proxmox.com/debian"

Mais les màjs 4.4 ne sont pas encore dispo ?
Je remarque que certains ont testé 4.4.
Ou alors ils ont downloadé et installé à zéro...

J'ai l'impression que ce genre de màj est dispo en 1er sur "enterprise" ?

Ce n'est pas urgent pour moi, mais comme je change de serveur et je migre de 3.4 vers 4.3 ... ou 4.4 , j'aurais directement commencé avec la dernière version.

Mais comme je suis en train de migrer mes conteneurs OpenVZ 4.3 vers LXC Proxmox 4.4, je n'ai pas vu cette option.
ça peut se modifier ensuite ?

Pour les updates il faut ajouter le dépôt :
`deb http://download.proxmox.com/debian jessie pve-no-subscription`
Et la dispo est générale, tous mes serveurs sont déjà en 4.4 depuis vendredi.

Par contre la conversion OpenVZ vers LXC, les infos sont ici : http://pve.proxmox.com/wiki/Convert_OpenVZ_to_LXC

Merci pour le dépôt :
deb http://download.proxmox.com/debian jessie pve-no-subscription

Je ferai la modif et l'upgrade Proxmox 4.4 demain.

Pour le migration / conversion OpenVZ --> LXC, c'est bien ces infos que j'ai suivie. Pas de problème (à part les IP )

Bonne soirée :smile:

Je continue mes tests avec Proxmox 4.4 et des conteneurs LXC.

**J'en suis globalement très mécontent !** :rage:

A part le nouveau look de l'interface, très clair, ergonomique, pratique...
Le reste, il y a des choses qui ne fonctionnent pas, ou de façon aléatoire :slight_smile:

- je n'ai toujours pas trouvé comment mettre un **bloc IPv4 (ni IPv6) sur un conteneur LXC** :
Si j'indique dans l'interface 123.123.123.0/28 pour un bloc de 16 IPv4, seule la 1ère IP est utilisable !
(je n'avais jamais essayé en Proxmox 3.4)
Aucun conseil de config n'a résolu ce problème !

- **limitation à 10 interfaces** (en 3.4 je pouvais aller jusque 16, pas essayé plus)
Si la définition des blocs IPv4 fonctionnaient, je n'aurais pas besoin de plus de 2 ou 3 interfaces...

- si je contourne le problème de bloc IPv4 en mettant **plusieurs interfaces** :
eth0 = 123.123.123.1/32
eth1 = 123.123.123.2/32
eth2 = 123.123.123.3/32
toutes avec la gateway 123.123.123.254

_**Le fonctionnement est aléatoire**_ :flushed:
Parfois je peux faire un ping sur 123.123.123.1 mais les 2 autres ne répondent pas.
Je reboot le conteneur, et cette fois c'est l' IP 123.123.123.3 qui répond, mais plus la 1ère... :confused:
etc...
**Non, un comportement aléatoire, c'est catastrophique !**
**Je ne peux pas utiliser ça en Prod !** :rage:

- **impossibilité d'ajouter une interface avec IP quand le conteneur tourne** :
je démarre un conteneur avec eth0 = 123.123.123.1/32
Si j'ajoute une interface eth1 = 123.123.123.2/32 . Je sauve l'interface. L'adresse IP disparaît de l'interface :rage:
Je suis obligé de faire un STOP du conteneur pour ajouter mes interfaces avec IPv4, et ensuite de le redémarrer !

ça, je n'ai JAMAIS dû bricoler comme ça en Proxmox 3.4 OpenVZ !
Proxmox 3.4 avec des conteneurs OpenVZ, tout tournait impec, pratiquement jamais de problème...

Mais OpenVZ n'évolue plus et est "bloqué" avec un vieux kernel ...

Je continue mes tests et je cherche éventuellement un autre soft de virtualisation...

Bonne fête de Noël :smiley:
Didier

Bonjour Didier,

* Il faut nécessairement ajouter plusieurs interfaces, mettre 123.123.123.0/28 reviens à dire que la passerelle par défaut va être 123.123.123.14, mais n'ajoute qu'une seule IP au container.

La solution peut être de créer un bridge manuellement en indiquant la route en .254, mais il faudra tout de même ajouter les interfaces sur le container et la limitation sera toujours de 10.

Enfin, il n'est effectivement pas possible de modifier une configuration sur un container ou une VM sans la redémarrer, mais une partie des problèmes IPs vient du fonctionnement de base de debian/ubuntu qui n'autorise pas un gateway externe sous-réseau associé à une interface.

Bonjour Thomas

La limitation à 10 interfaces n'est pas hyper critique...
J'ai un seul conteneur où j'ai réellement un bloc de 16 IPv4. Je peux m'arranger.

Un bridge manuel ? ... mais s'il faut toujours ajouter les interfaces...
Mais ok, je peux essayer ça ?...

Je pense que le problème du réseau, ce sont les **MAC Addresses virtuelles** !
Si je défini un range 123.123.123.0/28 ... je n'arrive qu'à associer UNE SEULE Mac Address virtuelle OVH !
... et alors seul la 1ère IP répond.

Mais tout ça serait contournable, si c'était stable !

Mais si je crée 3 interfaces (avec leurs Mac Addresses virtuelles OVH et la même gateway 123.123.123.254) :
eth0 = 123.123.123.1/32
eth1 = 123.123.123.2/32
eth2 = 123.123.123.3/32 ...
ce n'est PAS STABLE :flushed:

Reboot après reboot, c'est une IP différente qui répond !
ça je ne comprend pas, et ce n'est PAS acceptable ni utilisable en Prod ! :flushed:

Comportement de Debian / Ubuntu : au niveau de la machine hôte Proxmox ? ou au niveau des conteneurs ?

Car j'avais ce genre de config avec 8 ou 16 interfaces en Proxmox 3.4 :slight_smile:

# Auto generated lo interface
auto lo
iface lo inet loopback

# Auto generated venet0 interface
auto venet0
iface venet0 inet manual
up ifconfig venet0 up
up ifconfig venet0 127.0.0.2
up route add default dev venet0
down route del default dev venet0
down ifconfig venet0 down


iface venet0 inet6 manual
up route -A inet6 add default dev venet0
down route -A inet6 del default dev venet0

auto venet0:0
iface venet0:0 inet static
address 123.123.123.65
netmask 255.255.255.255

auto venet0:1
iface venet0:1 inet static
address 123.123.123.66
netmask 255.255.255.255

auto venet0:2
iface venet0:2 inet static
address 123.123.123.67
netmask 255.255.255.255

auto venet0:3
iface venet0:3 inet static
address 123.123.123.70
netmask 255.255.255.255

auto venet0:4
iface venet0:4 inet static
address 123.123.123.72
netmask 255.255.255.255

auto venet0:5
iface venet0:5 inet static
address 123.123.123.73
netmask 255.255.255.255

auto venet0:6
iface venet0:6 inet static
address 10.0.0.59
netmask 255.255.255.255


C'est différent : on voit que ce sont des sous-interfaces ...

Mais en Proxmox 3.4, comme tu le vois, je ne devais pas mettre de Mac Addresses virtuelles OVH, ni indiquer de Gatexway !
_Tout était automatique !_

Je lançais un ping vers une nouvelle IP, avant même de la configurer.
J'ajoutais une interface avec une IP supplémentaire (sans stop/start)
et immédiatement le ping répondait !

Je présume que la sortie était par défaut l'interface "physique" càd vers la machine hôte.
Et c'était STABLE et modifiable sans devoir arrêter le conteneur ! (oui, même sur un conteneur Ubuntu 16.04...)

Dans la définition d'une interface en 4.4 LXC, il y a un masque réseau ( IPv4/CIDR ) ...
alors il sert à quoi ce CIDR ? :flushed:

Je veux bien te croire qu'une partie des problèmes viendraient du comportement "réseau" de la dernière version de Debian... mais pour moi, **c'est un IMMENSE retour en arrière !**

On quitte une version Proxmox 3.4 OpenVZ qui fonctionnait impec (je ne change car plus supportée et vieux kernel)
pour une version Proxmox 4.4 LXC avec plein de limitations et des bugs, instabilités ...
:confused:

Je vais me faire un conteneur de test avec un bloc IPv4/29 de 8 IPs.
Peut-être en bricolant au niveau interfaces ou sous-interfaces, en ajoutant les MAC Addresses virtuelles dans les sous-interfaces...
(ça me semble être une bonne piste ça : il manque l'association Mac Addresses virtuelles sur les IPs suivantes)

Ou alors, je testerai les VM.
C'est plus lourd, et rien ne dit que ça va fonctionner... si le blocage est au niveau machine hôte Proxmox, ça ne changera rien.

En attendant, je paye 2 gros serveurs alors que je pensais basculer sur le nouveau en 2 ou 3 semaines... :neutral_face:

Merci pour tes conseils et Bonnes fêtes.
Didier

Oui c'est ce que je commençais à penser.
Il faut bridger les IPs additionnelles dans votre container. Autrement dit ajouter une seule interface, et ajouter manuellement vos IPs additionnelles, car ajouter plusieurs interfaces et répéter le gateway par défault va toujours poser problème.
Je vais faire des tests concernant les MAC virtuelles car je n'ai pas eu à faire un bridge sur un container jusque là.

Le fait de multiplier les interfaces pour avoir plusieurs IPv4 123.123.123.1 , .2 et .3 , avec 3 fois la même gateway 123.123.123.254, ça doit poser problème !
C'est certainement ça le caractère aléatoire, que ça ping parfois sur une, parfois sur l'autre interface...

Oui en fait, en relisant un peu la doc OVH et celle de proxmox, il faut ajouter une seule interface, puis ajouter les IPs suivantes en tant qu'alias, un peu comme avec un bridge.
Des exemples sont disponibles sur la documentation OVH Canada : http://docs.ovh.ca/fr/guides-network-ipaliasing.html

@VirtuBox En commençant à faire ce test, je me rends compte que ça n'ira pas.

En **Proxmox 3.4 OpenVZ**, l'association Mac Address / IPv4 était automatique.
Pas besoin de créer une Mac Address virtuelle OVH.

En **Proxmox 4.4 LXC**, il faut absolument créer une Mac Address virtuelle OVH, et mettre cette MAC dans la config de l'interface via Proxmox...
Sans ça, l'interface n'est pas accessible et ne répond pas !

Alors, si j'ajoute des IPv4 en alias eth0:0, eth0:1... sur l'interface eth0 , comme se fera la correspondance avec les Mac Addresses OVH ?
Je ne pourrai mettre qu'une seule MAC sur la 1ère IPv4, celle de l'interface principale eth0.

Bon, je refais des tests de la façon classique, avec 10 interfaces eth maximum.

@VirtuBox Je viens de créer un nouveau conteneur LXC (sans privilège) .
J'ai créé dans Proxmox 4.4, les 8 interfaces :

auto lo
iface lo inet loopback
iface lo inet6 loopback

# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto eth0
iface eth0 inet static
address 123.123.5.144
netmask 255.255.255.255
# --- BEGIN PVE ---
post-up ip route add 123.123.5.254 dev eth0
post-up ip route add default via 123.123.5.254 dev eth0
pre-down ip route del default via 123.123.5.254 dev eth0
pre-down ip route del 123.123.5.254 dev eth0
# --- END PVE ---

auto eth1
iface eth1 inet static
address 123.123.5.145
netmask 255.255.255.255
# --- BEGIN PVE ---
post-up ip route add 123.123.5.254 dev eth1
post-up ip route add default via 123.123.5.254 dev eth1
pre-down ip route del default via 123.123.5.254 dev eth1
pre-down ip route del 123.123.5.254 dev eth1
# --- END PVE ---

auto eth2
iface eth2 inet static
address 123.123.5.146
netmask 255.255.255.255
# --- BEGIN PVE ---
post-up ip route add 123.123.5.254 dev eth2
post-up ip route add default via 123.123.5.254 dev eth2
pre-down ip route del default via 123.123.5.254 dev eth2
pre-down ip route del 123.123.5.254 dev eth2
# --- END PVE ---

auto eth3
iface eth3 inet static
address 123.123.5.147
netmask 255.255.255.255
# --- BEGIN PVE ---
post-up ip route add 123.123.5.254 dev eth3
post-up ip route add default via 123.123.5.254 dev eth3
pre-down ip route del default via 123.123.5.254 dev eth3
pre-down ip route del 123.123.5.254 dev eth3
# --- END PVE ---

auto eth4
iface eth4 inet static
address 123.123.5.148
netmask 255.255.255.255
# --- BEGIN PVE ---
post-up ip route add 123.123.5.254 dev eth4
post-up ip route add default via 123.123.5.254 dev eth4
pre-down ip route del default via 123.123.5.254 dev eth4
pre-down ip route del 123.123.5.254 dev eth4
# --- END PVE ---

auto eth5
iface eth5 inet static
address 123.123.5.149
netmask 255.255.255.255
# --- BEGIN PVE ---
post-up ip route add 123.123.5.254 dev eth5
post-up ip route add default via 123.123.5.254 dev eth5
pre-down ip route del default via 123.123.5.254 dev eth5
pre-down ip route del 123.123.5.254 dev eth5
# --- END PVE ---

auto eth6
iface eth6 inet static
address 123.123.5.150
netmask 255.255.255.255
# --- BEGIN PVE ---
post-up ip route add 123.123.5.254 dev eth6
post-up ip route add default via 123.123.5.254 dev eth6
pre-down ip route del default via 123.123.5.254 dev eth6
pre-down ip route del 123.123.5.254 dev eth6
# --- END PVE ---

auto eth7
iface eth7 inet static
address 123.123.5.151
netmask 255.255.255.255
# --- BEGIN PVE ---
post-up ip route add 123.123.5.254 dev eth7
post-up ip route add default via 123.123.5.254 dev eth7
pre-down ip route del default via 123.123.5.254 dev eth7
pre-down ip route del 123.123.5.254 dev eth7
# --- END PVE ---

Je n'ai pas modifié manuellement, juste ajouté les interfaces avec leurs MAC Adresses virtuelles OVH depuis Proxmox 4.4.

... et ça fonctionne !
Tous les pings répondent :sunglasses:

Mais ... pourtant j'avais fait un test avec un conteneur avec 3 IPv4 et le ping était aléatoire d'un reboot à l'autre...
Je vais comparer les fichiers /etc/network/interfaces ...