INFO - Bug Debian 11 & Webmin/Virtualmin

Bonjour,

Dans tous les cas, ovh utilise le dhcp pour configurer ses serveurs physiques.
Il est recommandé pour des ip fixes de faire une configuration dans un fichier du serveur.

Il ne sert à rien d'être dépendant d'un système externe tel que le dhcp pour faire fonctionner son serveur, en cas d'incident du service dhcp par exemple, tu perdrais la main sur ta machine alors que le réseau peut fonctionner correctement.

ip fixe --> conf en dur sur le serveur

Bon courage
Captainadmin

Oui en effet.

Utiliser le dhcp est sans aucun doute avantageux pour OVH car cela lui offre plus de souplesse, elle qui doit gérer des variations colossales de serveurs et d'Ip suivant les commandes et fin de services de milliers, millions de clients.

Vu de notre coté client OVH, sauf pour de grands comptes ou dans certaines circonstances pour par exemple "masquer" des IP et réseaux internes importants de serveurs, l'IP fixe est bien préférable.

Bonjour,

Pour information c'est pas un bug debian/virtualmin ce genre de choses arrivent quand le DHCP de OVH a des problèmes car d'autres personnes ont remontée les même soucis sur des OS différents.

Autre infos, pour retirer proprement la config réseau de cloud-init il faut :
[quote]
To disable cloud-init's network configuration capabilities, write a file /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
network: {config: disabled}
[/quote]

Cordialement, janus57

Bonjour Janus,

Oui pour le DHCP OVH bien entendu Debian et Virtualmin ne sont pas en cause.

Merci pour l'information complémentaire et l'option visant l'inactivation du fichier 50-cloud-init.

C'est une possibilité et dans ce cas, outre l'inactivation de 50-cloud-init, il faudra reporter (correctement) dans le fichier /etc/network/interfaces les parties présentes dans 50-cloud-init.
Attention: faire des sauvegardes et bien configurer faute de planter votre serveur avec tous vos sites !

Personnellement, je privilégie toujours le plus possible de rester/laisser les choses en conformité avec le "produit" de chaque fournisseur et d'intervenir le moins possible dans les fichiers correspondants.
C'est une meilleure garantie de stabilité, d'évolution et pour éviter des problèmes et bien du travail car bien entendu, comme c'est le cas ici entre Debain 11 et Webmin/Virtualmin, le problème est lié au fait que les produits des uns et des autres n'évoluent pas en même temps et peuvent prendre parfois de nouveaux chemins et voire devenir incompatibles.
D'ailleurs Debian a fait le choix (intelligent je trouve) de passer par un système d'inclusion de fichiers paramètres/config séparées.

Bien à vous,
Pierre

Ma proc Debian 11 pour le réseau (IP modifiées) :

**Récupérer les infos**
`ip route`
->
> default via 94.23.6.254 dev eno1 onlink
> 94.23.6.0/24 dev eno1 proto kernel scope link src 94.23.6.55

**suppression cloud-init :**
> apt remove cloud-init
> rm -f /etc/network/interfaces.d/50-cloud-init

**Conf IP "primaire" :**
`nano /etc/network/interfaces.d/50-debian`
->
> auto lo
> iface lo inet loopback

> auto eno1
> allow-hotplug eno1
> iface eno1 inet static
> address 94.23.6.55
> netmask 255.255.255.0
> gateway 94.23.6.254
> dns-nameserver 1.1.1.1
> dns-nameserver 8.8.8.8

**Ajout des alias IP failover :**
`nano /etc/network/interfaces.d/99-failover`
->
> auto eno1:1
> iface eno1:1 inet static
> address 87.98.189.55
> netmask 255.255.255.255
> broadcast 87.98.189.55

> auto eno1:2
> iface eno1:2 inet static
> address 178.32.156.55
> netmask 255.255.255.255
> broadcast 178.32.156.55

`reboot`

/etc/network/interfaces.d/50-cloud-init

Bonjour @TTY

Que fais-tu de tout le bazar IPv6 (près de 300 lignes) donc voici un tout petit extrait du 50-cloud-init ?

iface enp3s0 inet6 static
address 2001:41d0:a:316f::1/56
dns-nameservers 2001:41d0:3:163::1
gateway 2001:41d0:a:31ff:ff:ff:ff:ff
...
pre-down route del -A inet6 2001:41d0:a:3162::/64 gw 2001:41d0:a:31ff:ff:ff:ff:ff || true
post-up route add -A inet6 2001:41d0:a:31fe::/64 gw 2001:41d0:a:31ff:ff:ff:ff:ff || true
pre-down route del -A inet6 2001:41d0:a:31fe::/64 gw 2001:41d0:a:31ff:ff:ff:ff:ff || true
post-up route add -A inet6 2001:41d0:a:3162:8000::/65 gw 2001:41d0:a:31ff:ff:ff:ff:ff || true
pre-down route del -A inet6 2001:41d0:a:3162:8000::/65 gw 2001:41d0:a:31ff:ff:ff:ff:ff || true
post-up route add -A inet6 2001:41d0:a:31ff:8000::/65 gw 2001:41d0:a:31ff:ff:ff:ff:ff || true
....

Hello @Fritz2cat,

Je désactive IPV6 (aucun intérêt pour moi tant que l'on ne peut pas les déplacer comme les V4) :

echo "net.ipv6.conf.all.disable_ipv6 = 1" > /etc/sysctl.d/70-disable-ipv6.conf
sysctl -p -f /etc/sysctl.d/70-disable-ipv6.conf

Bonjour @Fritz2cat et @TTY,

Comme quoi il n'existe pas qu'une seule solution ;-)
A chacun celle qui lui convient le mieux dans son contexte.

Mais le plus important est dans le principe qui au fond ici dans chaque solution reste le même, que l'on désactive le /etc/network/interfaces.d/50-cloud-init, ou comme @TTY qu-on remplace le fichier, ou que l'on mette tout dans le fichier /etc/network/interfaces, il faut mettre les bonnes lignes et syntaxes dont on a besoin, dans son propre contexte et fonction de son approche.
Tu ne vas pas gérer 1 à 10 IP qui ne bougent jamais ou peu comme tu vas gérer 100, 1000+ IP qui bougent très régulièrement toutes ou les unes et les autres...

Pour les IPv6, il est vrai qu'elles sont plus compliquées à gérer, et que beaucoup pour ne pas dire le plus grand nombre ne les reconnaît même pas ou ne les utilise pas encore.
Mais là aussi, les grands groupes, les réseaux très conséquents et ceux qui ont besoin de nombreuses IP sont plus concernés et intéressés.
Enfin, inévitablement les IPv6 vont devenir prédominantes avec le temps, alors c'est pas mal non plus de se familiariser avec elles.
Dernier petit avantage, les bloc Ripe IPv4 additionnelles sont désormais facturées par OVH alors que les IPv6/64 sont elles incluses dans l'offre serveur OVH (pour le moment).

Pierre

Enfin, inévitablement les IPv6 vont devenir prédominantes avec le temps, alors c'est pas mal non plus de se familiariser avec elles.

C'est sûrement vrai...
Le problème c'est que ça fait bien 20 ans que j'entends ça.
En attendant, l'IPV6 complexifie la config des outils comme iptables, fail2ban, Portsentry, Crowdsec ... Ce qui augmente :
- la charge marchine pour le filtrage
- la surface d'attaque
- les coûts

Pour un truc qui ne me sert pas (pas de FO), je n'en voie pas l’intérêt.
Comme tu le dis, tout est question de contexte :)