Ipv6 et machine virtuelle

Bonjour,

Voici trois jours que je m’arrache ce qu’il me reste de cheveux sur un problème que je n’arrive pas à comprendre.
Je suis en train créer une machine virtuelle sous Debian pour gérer, via ISPConfig, un serveur d’entreprise.
Pour ce faire j’utilise l’image « debian-12-nocloud-amd64.qcow2 ». Malheureusement cette machine semble incapable de se connecter en ipv6…
ping google.fr :

PING google.fr(par21s23-in-x03.1e100.net (2a00:1450:4007:81a::2003)) 56 data bytes
--- google.fr ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2025ms

L’adresse est bien comprise il me semble.
Je contourne le soucis via un script systeme:

[Unit]
Description=Enable IPv6

[Service]
Type=oneshot
ExecStart=/sbin/sysctl -w net.ipv6.conf.all.disable_ipv6=1
ExecStart=/sbin/sysctl -w net.ipv6.conf.default.disable_ipv6=1
ExecStart=/sbin/sysctl -w net.ipv6.conf.all.disable_ipv6=0
ExecStart=/sbin/sysctl -w net.ipv6.conf.default.disable_ipv6=0

[Install]
WantedBy=multi-user.target

Quand je le lance l’ipv6 fonctionne bien. Mais dès que je redémarre le serveur virtuel (ou pas) ça ne refonctionne plus, même si j’automatise le lancement du script.
J’ai lû que ce problème est redondant, mais je n’y ai pas trouvé de solution propre et stable.
Pourriez-vous, s’il vous plaît, m’aider à résoudre ce soucis ?

Je vous remercie.
Cordialement, Skwal.

Conseil : mettre les sorties machine au format « texte préformaté » pour éviter que le forum les altère (insertion d’hyperlien quand il croit détecter un URL, remplacement de caractères…)

Si on se fie à cette sortie, au moins la machine a une adresse IPv6 globale compatible avec l’adresse de destination, une route vers le réseau de destination dont le routeur est joignable puisque les paquets ont été émis sans recevoir de paquet ICMPv6 d’erreur en retour (à moins que tu n’aies pas attendu assez longtemps ou que quelque chose ait filtré les paquets ICMPv6 d’erreur, ce qui est mal).

Questions :

  • Comment la machine est-elle configurée pour l’IPv6 ? Statique, SLAAC, DHCPv6 ?

  • Par quels éléments de réseau passe la connectivité IPv6 de cette machine ?

  • Qu’est-ce qui t’a donné l’idée de ce script ? Pour moi la mise à 1 puis à 0 de net.ipv6.conf.default.disable_ipv6 n’a aucun effet. La mise à 1 puis à 0 de net.ipv6.conf.all.disable_ipv6 a pour effet d’effacer la configuration IPv6 existante, puis d’en récupérer une par SLAAC.

  • Quelles sont les sorties de ip -6 addr et ip -6 route avant et après l’exécution du script ?

Bonsoir @PascalHambourg ,

Merci pour ton conseil, mais c’est ce que j’ai fais pour tous les messages consoles…

Comment la machine est-elle configurée pour l’IPv6 ? Statique, SLAAC, DHCPv6 ?

Désolé, je ne saurais te dire…

Par quels éléments de réseau passe la connectivité IPv6 de cette machine ?

Pareil… J"ai juste lancé la machine virtuelle et laissé telle quelle hormis le petit script.

Qu’est-ce qui t’a donné l’idée de ce script ?

https://www.perplexity.ai
Étant seul et ayant un esprit… particulié… je me sert l’ia pour avancer et résoudre mes problèmes autant que possible. Elle m’a donc conseillé ce petit script qui semblait fonctionner.

La machine virtuelle est gérée via Qemu/libvirt, la connexion est en directe sur l’interface enp4s0 de l’hôte (Archlinux).

ip -6 addr (avant le script) :
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a01:e0a:385:7600::8d0d:9b65/128 scope global dynamic noprefixroute 
       valid_lft 64755sec preferred_lft 64755sec
    inet6 fe80::5054:ff:fe69:67ff/64 scope link 
       valid_lft forever preferred_lft forever

ip  -6 route (avant le script):
2a01:e0a:385:7600::/64 dev enp1s0 proto ra metric 100 expires 86250sec pref medium
fe80::/64 dev enp1s0 proto kernel metric 256 pref medium
default via fe80::f6ca:e5ff:fe49:707d dev enp1s0 proto ra metric 100 expires 1650sec mtu 1500 pref medium

ip -6 addr  (après le script)                                                                                                                                                          
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::5054:ff:fe69:67ff/64 scope link 
       valid_lft forever preferred_lft forever


ip -6 route:   (après le script)                                                                                                                                                ─╯
fe80::/64 dev enp1s0 proto kernel metric 256 pref medium

Je ne connaissais absolument pas SLAAC, jamais entendu parlé en fait.
Merci de m’avoir indiqué une direction, je n’y aurais jamais pensé seul. :+1:

Avant l’exécution du script, le préfixe IPv6 global 2a01:…/64 et la route par défaut sont obtenus par RA (router advertisement), l’adresse IPv6 semble obtenue par DHCPv6 (à cause du /128, ce serait /64 avec SLAAC).

Après l’exécution du script il n’y a plus ni adresse IPv6 globale (2a01:…) ni routes IPv6 globales. Il ne reste que les adresse et route link local (fe80:…), donc je ne vois pas comment la connectivité IPv6 vers internet pourrait fonctionner. Le ping vers google.fr ne devrait aboutir qu’en IPv4. À moins que tu n’aies pas attendu assez longtemps que l’IPv6 se reconfigure (cela peut prendre quelques minutes, le temps de recevoir la RA suivante).

J’ai du mal à comprendre et je m’en excuse, c’est aussi pour ça que je suis seul, je sais que ça peut être lourd…
Du coup tu m’as fais prendre conscience du RA.
Je ne saurais te dire pourquoi ça fonctionne mais ça fonctionne.
En discutant RA avec l’ia elle m’a conseillé d’utiliser « net.ipv6.conf.enp1s0.accept_ra=1 » et de redémarrer la connexion (systemctl restart systemd-networkd) et là ça fonctionne.
Mais il me faut me connecter à la MV pour relancer la connexion.

J’ai trouvé une solution via radvd, c’est sûrement temporaire mais la connexion est fonctionnelle dès le lancement de la machine.

J’ai installé radvd puis configuré, puis activé:
interface enp1s0 {
AdvSendAdvert on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;

prefix 2a01:e0a:385:7600::/64 {
    AdvOnLink on;
    AdvAutonomous on;
    AdvRouterAddr on;
};

};

Ensuite j’ai créé le fichier "sysctl -p /etc/sysctl.d/99-ipv6-accept-ra.conf ":
net.ipv6.conf.all.accept_ra=2
net.ipv6.conf.default.accept_ra=2
net.ipv6.conf.enp1s0.accept_ra=2

Puis appliqué les changements:
sysctl -p /etc/sysctl.d/99-ipv6-accept-ra.conf

Maintenant ça fonctionne. Je ne sais pas si c’est propre, si ça part vraiment d’un bug ou d’un problème de configuration de ma part (je ne suis pas un pro).
Mais si ça peut aider quelqu’un…
P.S: j’ai trouvé cette solution (temporaire?) avec l’ia et grâce à toi @PascalHambourg
Merci ! :slightly_smiling_face:

accept_ra=1 est déjà la configuration par défaut.

Sur l’hôte ou la machine virtuelle ? Vu le nom de l’interface réseau, je penche pour la machine virtuelle.

Non, c’est très sale. radvd est prévu pour être installé sur une machine faisant office de routeur IPv6, pas sur un hôte. D’autre part il risque de perturber le reste du réseau. Il vaudrait mieux comprendre pourquoi ça ne marche pas tout seul.

1 J'aime

J’ai installé radvd sur la machine virtuelle, je suis d’accord, j’aurais préféré comprendre également mais je ne sais pas si j’en suis capable et ça fait déjà trois jours que je suis sur ce problème…
En parcourant le web j’avais noté que ce « problème/bug (?) » ressortait mais il n’y a pas beaucoup de sujets sur ce soucis. Mais qu’il existait des solutions avec radvd.

https://thepoulpe.net/index.php?article24/mise-en-place-d-un-reseau-ipv6-deuxieme-partie

Je souhaite maintenant passer à autre chose, mais je reste à disposition pour tenter de résoudre ce problème autrement mais surtout proprement. :slightly_smiling_face:

Pour caractériser le problème il faudrait

  • identifier quel service gère le réseau (networking, NetworkManager, systemd-networkd, netplan…) et examiner sa configuration

  • remettre la machine virtuelle en configuration normale, notamment sans script, radvd ni tous ces sysctl

  • faire des captures de trafic sur toutes les interfaces réseau impliquées de la machine virtuelle et de l’hôte (physique, virtuelle et pont) pendant l’exécution d’un ping vers une adresse IPv6

A mon sens il faudrait enlever [BUG] du titre, ce qui est trompeur. Car ça ne semble pas être un Bug mais un manque de maîtrise du sujet.

1 J'aime

Je l’ai enlevé, mais je ne suis pas sûr que ce ne soit pas un bug. :wink:

Édition: C’était vraiment tout bête… qemu-guest-agent n’était pas activé sur la VM… Au cas où ça pourrait aider quelqu’un.

Merci !! :wink: :slightly_smiling_face: