Forum Linux.debian/ubuntu [RESOLU] Dédié OVH/Proxmox 7.2/Debian11 impossible d'utiliser mon bloc d'ip failover

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
1
16
août
2022

Dédié OVH/Proxmox 7.2/Debian11 impossible d'utiliser mon bloc d'ip failover

Bonjour,

Je suis très embêté : je n'arrive pas à faire communiquer mes vms kvm avec l'Internet sur Proxmox via mes adresses ip failover… C'est assez bizarre : je n'ai jusqu'ici jamais eu ce problème (je loue d'autres serveurs SoYouStart -mais loué sur SoYouStart quand c'était possible- pour lesquels cela fonctionne très bien).

En très bref :
* J'essaie de configurer sur l'hôte un bridge (vmbr0) sur lequel je branche la carte virtuelle de ma vm.
* depuis l'hôte ping 8.8.8.8 fonctionne.
* depuis la vm ping 8.8.8.8 renvoie Destination Host Unreachable :/
* depuis chez moi, un ping sur l'adresse de l'hôte fonctionne mais un ping sur l'adresse ip failover ne fonctionne pas.

Ça fait quelques jours que j'essaie différentes configurations et pour l'instant c'est l'échec et je n'ai plus d'idées.

Contexte :

J'utilise l'offre SYS-1-SSD-32 et un bloc de 4 ip failover (SoYouStart loué depuis OVH éco)
Proxmox 7.2-7 a été déployé via template ovh

Conf réseau de l'hôte

  • /etc/network/interfaces
auto lo
iface lo inet loopback

iface eno3 inet manual

iface eno4 inet manual

auto vmbr0
iface vmbr0 inet static
    address <ip_hôte>/24
    gateway <passerelle_hôte>
    bridge-ports eno3
    bridge-stp off
    bridge-fd 0
    hwaddress <mac_interface_physique>   #celle d'eno3, c'est apparemment nécessaire depuis version 7 de pve.
    post-up ip route add <ip_hôte>/32 dev vmbr0     #testé aussi sans cette ligne
    post-up ip route add <ip_failover>/32 dev vmbr0 #testé aussi sans cette ligne

C'est à peu près le paramétrage par défaut par le template d'ovh… j'ai essayé l'ajout des routes (post-up) suite à la lecture de différents fils (par exemple ici : https://community.ovh.com/t/mise-en-place-de-vm-avec-ip-publique-sur-proxmox-6-resolu/28479/19) mais ça n'a pas suffit.

L'hôte ping Internet et résout les noms DNS.

Conf de la vm
C'est une debian 11 toute fraîchement installée…

  • /etc/network/interface
auto lo
iface lo inet loopback

auto ens18
iface ens18 inet static
   address <ip_failover>
   netmask 255.255.255.255
   broadcast  <ip_failover>
   dns-nameservers 8.8.8.8
   post-up ip route add <passerelle_de_l'hote>/32 dev ens18
   post-up ip route add default via <passerelle_de_l'hote>
   pre-down ip route del default via <passerelle_de_l'hote>
   pre-down ip route del <passerelle_de_l'hote> dev ens18

Bien sûr j'ai configuré l'adresse mac virtuelle de ma vm avec celle fournie par ovh.

Résultats de quelques commandes de vérification

  • Sur l'hôte pve
root@xxx:~# ip add
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 
       valid_lft forever preferred_lft forever
2: eno3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
    link/ether <mac_interface_physique> ff:ff:ff:ff:ff:ff
    altname enp3s0f0
3: eno4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether <mac_seconde_interface_physique> brd ff:ff:ff:ff:ff:ff
    altname enp3s0f1
6: vmbr0v1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether <mac_je_ne_sais_pas_d'où_elle_sort> brd ff:ff:ff:ff:ff:ff
7: eno3.1@eno3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0v1 state UP group default qlen 1000
    link/ether <mac_interface_physique> brd ff:ff:ff:ff:ff:ff
15: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether  <mac_interface_physique> brd ff:ff:ff:ff:ff:ff
    inet <ip_hôte>/24 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::xxx/64 scope link 
       valid_lft forever preferred_lft forever
16: tap100i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr100i0 state UNKNOWN group default qlen 1000
    link/ether <mac_je_ne_sais_pas_d'où_elle_sort_2> brd ff:ff:ff:ff:ff:ff
17: fwbr100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether <mac_je_ne_sais_pas_d'où_elle_sort_3> brd ff:ff:ff:ff:ff:ff
18: fwpr100p0@fwln100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0v1 state UP group default qlen 1000
    link/ether  <mac_je_ne_sais_pas_d'où_elle_sort_4> brd ff:ff:ff:ff:ff:ff
19: fwln100i0@fwpr100p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr100i0 state UP group default qlen 1000
    link/ether  <mac_je_ne_sais_pas_d'où_elle_sort_5> brd ff:ff:ff:ff:ff:ff
  • Sur la vm
root@xxx:~# ip add
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 
       valid_lft forever preferred_lft forever
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether <mac_virtuelle> brd ff:ff:ff:ff:ff:ff
    altname enp0s18
    inet <ip_failover>/32 brd <ip_failover> scope global ens18
       valid_lft forever preferred_lft forever
    inet6 fe80::xxx/64 scope link 
       valid_lft forever preferred_lft forever

root@xxx:~# ip route show
default via <passerelle_hôte> dev ens18 
<passerelle_hôte> dev ens18 scope link 
169.254.0.0/16 dev ens18 scope link metric 1000

Mode rescue
En suivant https://docs.ovh.com/fr/dedicated/network-bridging/#resolution-des-defauts, je ping L'IP failover depuis chez moi : c'est bien un problème de conf (et/ou de règles réseau d'ovh dont je n'ai pas connaissance).

Pourtant cette conf fonctionne ailleurs (serveur SoYouStart loué chez SoYouStart).

Je sèche et je fini donc par jeter cette bouteille à la mer avant de jeter mon pc par la fenêtre. Une super moule pour me venir en aide ?

Merci !

  • # ouvre un ticket

    Posté par  (site web personnel) . Évalué à 2.

    y a quelque année j'avais eu le même problème
    c'est ovh qui ne routait pas mon ip failover.
    As tu essayé avec une autre ip failover et une autre adresse mac ?

    • [^] # Re: ouvre un ticket

      Posté par  . Évalué à 1.

      Hello,

      Merci de t'intéresser à mon problème.

      En fait, en mode rescue, j'arrive à pinger l'IP FO donc OVH la route à priori… Dans ces cas là le support va à tous les coups me renvoyer dans mes cordes en mode "c'est la conf" (bon c'est la conf de leur template et leur doc qui n'est pas à jour je pense).

      Mais t'as raison, je vais tester avec une autre VM, une autre MAC virtuelle et une autre FO. Des fois que.

      Et je vais quand même tenter d'ouvrir un ticket, on sais jamais.

      ++

      • [^] # Re: ouvre un ticket

        Posté par  . Évalué à 2.

        Bon bon bon,

        Le problème est résolu.

        J'ai testé avec une autre VM/MAC/IP FO et là PAF, contre toute attente, ça a fonctionné. Oo Comprend pas.

        OK me dis-je, ces routes ajoutées sur l'hyperviseur me semblent inutiles, je vais les virer pour voir : je modifie /etc/network/interfaces (suppression des lignes post-up) et je lance un petit systemctl restart networking.service. POUF Ça ping plus… Qu'à cela ne tienne, je les remet. systemctl restart networking.service et paf ça ping toujours plus. Oo Comprend de moins en moins.

        Reboot pour voir (je suis vraiment désespéré) ? Ça reping… mais toujours pas sur ma première VM/MAC/FO.

        Bon quand même je tiens un truc (après 2 jours de surplace ça me remotive). Je fais quelques essais et je rererecheck tout partout.

        Au final :
        * Apparemment, systemctl restart networking.service et POUF ça marche plus (même si on a rien modifié de la conf). Reboot et PAF ça remarche. Et aussi, pas besoin des routes sur l'hyperviseur (je trouvais ça bizarre quand même). Donc en gros, changement de conf réseau sur l'hyperviseur via les fichier, faut redémarrer. Vous savez pourquoi vous ?
        * Mystère de la première interface ? à force que ça marche pas à cause du premier problème et de bidouiller dans proxmox, j'avais mis VLAN=1 au lieu de NoVLAN sans faire exprès. Là je suis juste un peu nul.

        Punaise de clicobidule, des fois c'est pratique et des fois ça te fait perdre 3 jours.

        Voilà voilà, tout le monde se ping dans la joie et l’allégresse et je suis content.

        Merci :)

        ++

        • [^] # Re: ouvre un ticket

          Posté par  (site web personnel) . Évalué à 2. Dernière modification le 17 août 2022 à 14:53.

          contant que ça marche :-)
          j'ai aussi un soyoustart mais j'utilise pas les templates d'ovh
          j'ai installé le mien en mai avec la console de gestion du serveur (c'est apparemment nouveau ça et c'est bien pratique), il faut d'abord installer une fois à vide une debian.
          Puis via la console d'administration tu fais rebooter le serveur sur une iso de proxmox (qui est sur ton disque dur) et ça marche nickel

          j'ai pas d'ajout de route, mon /etc/network/interfaces ressemble à ceci:

          auto lo
iface lo inet loopback

iface eno3 inet manual

auto vmbr0
iface vmbr0 inet static
        address 8.8.8.8/24
        gateway 8.8.8.254
        bridge-ports eno3
        bridge-stp off
        bridge-fd 0

iface eno4 inet manual

          bonne continuation sous proxmox

          • [^] # Re: ouvre un ticket

            Posté par  . Évalué à 1. Dernière modification le 17 août 2022 à 15:14.

            Avant je partais d'une debian puis j'installais pve… mais je partais quand même du template debian d'ovh/SoYouStart/whatever. J'ai jamais pensé à faire l'installation moi même depuis une iso (je savais même pas qu'on pouvait) et il n'y avait pas de template debian 11 mais que 10. Voilà voilà, ma vie.

            L'idée c'était aussi de gagner du temps… c'est raté du coup :D

            En tous cas j'ai bien la même chose dans /etc/network/interfaces et ça roule. C'est le systemctl restart etc qui m'a mis dedans.

            ++ et merci encore

  • # mac non autorisée

    Posté par  . Évalué à 3.

    de ce que je vois tu as fais toutes les etapes sur les machines,

    mais en plus de l'ip failover, il te faut creer une adresse MAC dans la console OCH, puis donner cette adresse MAC à ta VM

    inconvenient, la VM ne peut plus basculer d'un serveur à l'autre sans modifier la console OVH (cela peut se scripter en utilisant l'API)

    • [^] # Re: mac non autorisée

      Posté par  . Évalué à 1.

      Hello,

      Merci à toi aussi de te pencher sur mon souci.

      J'ai bien demandé une MAC virtuelle associée à l'IP FO et j'ai bien conf la carte de la VM pour qu'elle l'utilise. J'ai vérifié 50 fois et je ne vois pas de faute de frappe :/

      Pour le coup, ça me dérange pas trop de devoir passer par la console OVH : c'est semi-artisanal, j'ai pas un gros troupeau.

      ++

      • [^] # Re: mac non autorisée

        Posté par  . Évalué à 3.

        un truc bete, le firewall du proxmox est actif ? et sur la VM ?

        • [^] # Re: mac non autorisée

          Posté par  . Évalué à 1.

          Sur la VM non et sur Proxmox oui, mais comme expliqué plus haut ça fonctionne dorénavant.
          Merci en tous cas.

  • # Commentaire supprimé

    Posté par  . Évalué à 1. Dernière modification le 07 octobre 2022 à 08:40.

    Ce commentaire a été supprimé par l’équipe de modération.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.