Auteur Sujet: Ipv6 avec serveur dédié, ESXi et VM... (Lu 3463 fois)

David M. · « **le:** 03 juin 2021 à 12:38:44 »

Bonjour à tous,

Je galère un peu avec IPv6 depuis que j'ai changé de serveur, et j'ai remarqué que je n'étais pas le seul ^^
Je précise que j'ai lu intégralement les deux fils suivants : https://lafibre.info/scaleway/configurer-une-ipv6-online-net-sur-ubuntu-18-04/ et https://lafibre.info/scaleway/configurer-une-ipv6-sur-un-serveur-dedibox-avec-ubuntu-18-04/
Ca a apporté déjà pas mal d'eau à mon moulin, mais pas encore assez, malheureusement ^^

Faisons les choses avec méthode.

Tout d'abord, ce que j'avais avec mon ancien serveur (Egalement chez Online) depuis 2015 :
Un serveur dédié avec un ESXi et plusieurs VM dessus.
- Une VM plesk avec 2 IPv4 failover et un /64 IPv6 que j'avais créé sur mon compte Online.
- D'autres VM avec des IPv4 FO, sans IPv6.
- Je précise que l'ESXi n'était pas configuré en IPv6. Il communiquait avec internet uniquement via l'IPv4 du serveur physique. Les VM, elles, n'utilisaient que des IPFO.

A l'époque, j'étais encore moins compétant en IPv6, mais j'avais suivi le tuto d'online et ça a fonctionné pendant presque 7 ans (oui, je sais, j'ai tardé avant de changer mon serveur, mais c'est un autre débat ^^ )
J'avais donc juste ma VM plesk qui avait un certain nombre d'IPv6 (une par site web, une bonne vingtaine au total), configurée avec le fichier interfaces de cette façon (sur Ubuntu 16.04) :

Code: [Sélectionner]

iface eth0 inet6 static
    up /sbin/ifconfig eth0 inet6 add 2001:xxxx:xxxx:xxxx::1:1
    up /sbin/ifconfig eth0 inet6 add 2001:xxxx:xxxx:xxxx::1:2
    up /sbin/ifconfig eth0 inet6 add 2001:xxxx:xxxx:xxxx::1:3
    up /sbin/ifconfig eth0 inet6 add 2001:xxxx:xxxx:xxxx::1:4
    up /sbin/ifconfig eth0 inet6 add 2001:xxxx:xxxx:xxxx::1:5
    up /sbin/ifconfig eth0 inet6 add 2001:xxxx:xxxx:xxxx::2:1
    up /sbin/ifconfig eth0 inet6 add 2001:xxxx:xxxx:xxxx::1:2
    up /sbin/ifconfig eth0 inet6 add 2001:xxxx:xxxx:xxxx::1:3
    # etc...
    
    address 2001:xxxx:xxxx:xxxx::1
    netmask 64
    accept_ra 1
    pre-up dhclient -cf /etc/dhcp/dhclient6.conf -pf /run/dhclient6.eth0.pid -6 -P eth0
    pre-down dhclient -x -pf /run/dhclient6.eth0.pid

Bref, ça fonctionnait impeccable.

Maintenant, le nouveau serveur.
A nouveau un serveur physique avec un ESXi dessus (juste plus récent), toujours sans IPv6, avec une VM Plesk et ses 2 IPFO (v4) et de l'IPv6 bancal (je détaille après), et d'autres VM avec des IPFO (v4)

Sur ma nouvelle VM Plesk, qui tourne maintenant en Ubuntu 20.04 et avec netplan (que je n'avais jamais utilisé jusqu'à maintenant... -_- ), j'ai suivi à la lettre le tuto d'Online.
Voilà le détail :
Tout d'abord, pour netplan : J'ai deux fichiers. Celui créé à l'install d'Ubuntu Server 20.04 et celui créé par Plesk, mais normalement, ça ne gêne pas.
/etc/netplan/00-installer-config.yaml :

Code: [Sélectionner]

# This is the network config written by 'subiquity'
network:
  renderer: networkd
  ethernets:
    ens192:
      dhcp4: no
      dhcp6: no
      addresses:
      - 212.xxx.xxx.xxx/32
      - 212.xxx.xxx.yyy/32
      gateway4: 163.xxx.xxx.xxx
      nameservers:
        addresses:
        - 8.8.8.8
        - 8.8.4.4
      routes:
        - to: 163.xxx.xxx.xxx/32
          via: 212.xxx.xxx.xxx
          scope: link
    ens224:
      addresses:
      - 192.168.100.1/24
  version: 2

Précision : l'interface ens224 est connecté sur un switch virtuel de mon ESXi qui permet à mes VM de communiquer ensemble sans passer par internet, c'est tout.

/etc/netplan/10-plesk.yaml :

Code: [Sélectionner]

network:
  version: 2
  renderer: networkd
  ethernets:
    ens192:
      addresses:
        - 2001:xxxx:xxxx:xxxx::1/64
        - 2001:xxxx:xxxx:xxxx::1:1/64
        - 2001:xxxx:xxxx:xxxx::1:2/64
        - 2001:xxxx:xxxx:xxxx::1:3/64
        - 2001:xxxx:xxxx:xxxx::1:4/64
        - 2001:xxxx:xxxx:xxxx::1:5/64
        - 2001:xxxx:xxxx:xxxx::2:1/64
        - 2001:xxxx:xxxx:xxxx::2:2/64
        - 2001:xxxx:xxxx:xxxx::2:3/64
        - 2001:xxxx:xxxx:xxxx::2:4/64
#etc.

Ca fonctionne... Ou pas.

En gros, ce que j'ai noté, c'est que chaque fois que le dhclient fait une requête, ça échoue, et ça fait sauter ma config IPv6 (quand je fais un ip a, je n'ai plus une seule IPv6 qui apparait en dehors de l'IPv6 locale). Je stoppe dhclient, je refais un netplan apply, et c'est reparti, je ping en IPv6, et mes sites sont joignables en IPv6 aussi.

Concernant DHClient, voici ce que me renvoie un journalctl -xe :

Code: [Sélectionner]

-- The job identifier is 2171009 and the job result is done.
Jun 03 10:07:38 e-concept-applications.fr systemd[1]: Starting ISC DHCP client to send DUID for IPv6 and add IPv6 to interface...
-- Subject: A start job for unit dhclient6.service has begun execution
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- A start job for unit dhclient6.service has begun execution.
--
-- The job identifier is 2171009.
Jun 03 10:07:38 e-concept-applications.fr audit[550473]: AVC apparmor="DENIED" operation="open" profile="/{,usr/}sbin/dhclient" name="/proc/550473/task/550474/comm" pid=550473 comm="dhclient" requested_mask="wr" denied_mask="wr" fsuid=0 o>Jun 03 10:07:38 e-concept-applications.fr audit[550473]: AVC apparmor="DENIED" operation="open" profile="/{,usr/}sbin/dhclient" name="/proc/550473/task/550475/comm" pid=550473 comm="dhclient" requested_mask="wr" denied_mask="wr" fsuid=0 o>Jun 03 10:07:38 e-concept-applications.fr audit[550473]: AVC apparmor="DENIED" operation="open" profile="/{,usr/}sbin/dhclient" name="/proc/550473/task/550476/comm" pid=550473 comm="dhclient" requested_mask="wr" denied_mask="wr" fsuid=0 o>Jun 03 10:07:38 e-concept-applications.fr dhclient[550473]: Internet Systems Consortium DHCP Client 4.4.1
Jun 03 10:07:38 e-concept-applications.fr kernel: audit: type=1400 audit(1622714858.592:5083): apparmor="DENIED" operation="open" profile="/{,usr/}sbin/dhclient" name="/proc/550473/task/550474/comm" pid=550473 comm="dhclient" requested_ma>Jun 03 10:07:38 e-concept-applications.fr kernel: audit: type=1400 audit(1622714858.592:5084): apparmor="DENIED" operation="open" profile="/{,usr/}sbin/dhclient" name="/proc/550473/task/550475/comm" pid=550473 comm="dhclient" requested_ma>Jun 03 10:07:38 e-concept-applications.fr kernel: audit: type=1400 audit(1622714858.592:5085): apparmor="DENIED" operation="open" profile="/{,usr/}sbin/dhclient" name="/proc/550473/task/550476/comm" pid=550473 comm="dhclient" requested_ma>Jun 03 10:07:38 e-concept-applications.fr dhclient[550473]: Internet Systems Consortium DHCP Client 4.4.1
Jun 03 10:07:38 e-concept-applications.fr dhclient[550473]: Copyright 2004-2018 Internet Systems Consortium.
Jun 03 10:07:38 e-concept-applications.fr dhclient[550473]: Copyright 2004-2018 Internet Systems Consortium.
Jun 03 10:07:38 e-concept-applications.fr dhclient[550473]: All rights reserved.
Jun 03 10:07:38 e-concept-applications.fr dhclient[550473]: All rights reserved.
Jun 03 10:07:38 e-concept-applications.fr dhclient[550473]: For info, please visit https://www.isc.org/software/dhcp/
Jun 03 10:07:38 e-concept-applications.fr dhclient[550473]: For info, please visit https://www.isc.org/software/dhcp/
Jun 03 10:07:38 e-concept-applications.fr dhclient[550473]:
Jun 03 10:07:38 e-concept-applications.fr dhclient[550473]: Listening on Socket/ens192
Jun 03 10:07:38 e-concept-applications.fr dhclient[550473]: Listening on Socket/ens192
Jun 03 10:07:38 e-concept-applications.fr dhclient[550473]: Sending on   Socket/ens192
Jun 03 10:07:38 e-concept-applications.fr dhclient[550473]: Sending on   Socket/ens192
Jun 03 10:07:38 e-concept-applications.fr dhclient[550473]: PRC: Previous lease is devoid of active addresses.
Jun 03 10:07:38 e-concept-applications.fr dhclient[550473]: PRC: Soliciting for leases (INIT).
Jun 03 10:07:39 e-concept-applications.fr dhclient[550473]: XMT: Forming Solicit, 0 ms elapsed.
Jun 03 10:07:39 e-concept-applications.fr dhclient[550473]: XMT:  X-- IA_PD 56:00:71:77
Jun 03 10:07:39 e-concept-applications.fr dhclient[550473]: XMT:  | X-- Request renew in  +3600
Jun 03 10:07:39 e-concept-applications.fr dhclient[550473]: XMT:  | X-- Request rebind in +5400
Jun 03 10:07:39 e-concept-applications.fr dhclient[550473]: XMT: Solicit on ens192, interval 1030ms.
Jun 03 10:07:39 e-concept-applications.fr dhclient[550473]: XMT: Solicit on ens192, interval 1030ms.
Jun 03 10:07:39 e-concept-applications.fr multipathd[731]: sda: add missing path
Jun 03 10:07:39 e-concept-applications.fr multipathd[731]: sda: failed to get udev uid: Invalid argument
Jun 03 10:07:39 e-concept-applications.fr multipathd[731]: sda: failed to get sysfs uid: Invalid argument
Jun 03 10:07:39 e-concept-applications.fr multipathd[731]: sda: failed to get sgio uid: No such file or directory
Jun 03 10:07:40 e-concept-applications.fr dhclient[550473]: XMT: Forming Solicit, 1030 ms elapsed.
Jun 03 10:07:40 e-concept-applications.fr dhclient[550473]: XMT:  X-- IA_PD 56:00:71:77
Jun 03 10:07:40 e-concept-applications.fr dhclient[550473]: XMT:  | X-- Request renew in  +3600
Jun 03 10:07:40 e-concept-applications.fr dhclient[550473]: XMT:  | X-- Request rebind in +5400
Jun 03 10:07:40 e-concept-applications.fr dhclient[550473]: XMT: Solicit on ens192, interval 1980ms.
Jun 03 10:07:40 e-concept-applications.fr dhclient[550473]: XMT: Solicit on ens192, interval 1980ms.
Jun 03 10:07:42 e-concept-applications.fr dhclient[550473]: XMT: Forming Solicit, 3010 ms elapsed.
Jun 03 10:07:42 e-concept-applications.fr dhclient[550473]: XMT:  X-- IA_PD 56:00:71:77
Jun 03 10:07:42 e-concept-applications.fr dhclient[550473]: XMT:  | X-- Request renew in  +3600
Jun 03 10:07:42 e-concept-applications.fr dhclient[550473]: XMT:  | X-- Request rebind in +5400
Jun 03 10:07:42 e-concept-applications.fr dhclient[550473]: XMT: Solicit on ens192, interval 3850ms.
Jun 03 10:07:42 e-concept-applications.fr dhclient[550473]: XMT: Solicit on ens192, interval 3850ms.
Jun 03 10:07:46 e-concept-applications.fr dhclient[550473]: XMT: Forming Solicit, 6860 ms elapsed.
Jun 03 10:07:46 e-concept-applications.fr dhclient[550473]: XMT:  X-- IA_PD 56:00:71:77
Jun 03 10:07:46 e-concept-applications.fr dhclient[550473]: XMT:  | X-- Request renew in  +3600
Jun 03 10:07:46 e-concept-applications.fr dhclient[550473]: XMT:  | X-- Request rebind in +5400
Jun 03 10:07:46 e-concept-applications.fr dhclient[550473]: XMT: Solicit on ens192, interval 7570ms.
Jun 03 10:07:46 e-concept-applications.fr dhclient[550473]: XMT: Solicit on ens192, interval 7570ms.
Jun 03 10:07:48 e-concept-applications.fr systemd[1]: dhclient6.service: start operation timed out. Terminating.
Jun 03 10:07:48 e-concept-applications.fr systemd[1]: dhclient6.service: Killing process 550476 (dhclient) with signal SIGKILL.
Jun 03 10:07:48 e-concept-applications.fr systemd[1]: dhclient6.service: Failed with result 'timeout'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- The unit dhclient6.service has entered the 'failed' state with result 'timeout'.
Jun 03 10:07:48 e-concept-applications.fr systemd[1]: Failed to start ISC DHCP client to send DUID for IPv6 and add IPv6 to interface.
-- Subject: A start job for unit dhclient6.service has failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- A start job for unit dhclient6.service has finished with a failure.
--
-- The job identifier is 2171009 and the job result is failed.

Bref, clairement, ça passe pas.
A noter que le dhclient a bien du fonctionner à un moment donné, puisque mon /64 IPv6 est routé. Mais j'ai fais tellement de test dans tous les sens que j'ai peut-être fait une boulette...
Voilà la config du dhclient :
dhclient6.conf :

Code: [Sélectionner]

interface "ens192" {
        send dhcp6.client-id 00:00:00:00:00:00:00:00:00:00;
}

(avec le bon DUID, j'ai vérifié plusieurs fois, c'est bien celui de mon /64)

dhclient6.vars :
# For dhclient6.service, provide IPv6 IP, desired prefix, and interface

Code: [Sélectionner]

DH6IP=2001:xxxx:xxxx:xxxx::1
DH6PF=64
DH6IF=ens192

/etc/systemd/system/dhclient6.service :

Code: [Sélectionner]

[Unit]
Description=ISC DHCP client to send DUID for IPv6 and add IPv6 to interface
After=network.target
Wants=network.target network-online.target
Before=network-online.target
ConditionPathExists=/etc/dhcp/dhclient6.conf
ConditionPathExists=/etc/dhcp/dhclient6.vars

[Service]
EnvironmentFile=/etc/dhcp/dhclient6.vars
Type=forking
Restart=always
RestartSec=2s
TimeoutSec=10s
ExecStart=/sbin/dhclient -1 -v -pf /run/dhclient6.pid -cf /etc/dhcp/dhclient6.conf -lf /var/lib/dhcp/dhclient6.leases -6 -P ${DH6IF}
ExecStartPost=/sbin/ip -6 addr add ${DH6IP}/${DH6PF} dev ${DH6IF}
ExecStop=/sbin/ip -6 addr del ${DH6IP}/${DH6PF} dev ${DH6IF}
ExecStop=/sbin/dhclient -r -v -pf /run/dhclient6.pid -cf /etc/dhcp/dhclient6.conf -lf /var/lib/dhcp/dhclient6.leases -6 ${DH6IF}
PIDFile=/run/dhclient6.pid

[Install]
WantedBy=multi-user.target network-online.target

J'ai aussi saisi les commandes IPTABLES du tuto d'online pour limiter le flood du dhclient6 (ça inspire vachement confiance, quand même, dhclient6... -_- )

Voilà pour l'état des lieux.

De ce que j'ai compris de mes différentes lectures, pour l'instant, l'IPv6 fonctionne sur ma VM Plesk, mais quand le bail de l'IPv6 va expirer, celle-ci ne sera plus routée, et je vais me retrouver coincé.

Du coup, avez-vous une idée pour que le dhclient fonctionne correctement ?

Dans un second temps, j'aimerais au passage pouvoir mettre de l'IPv6 aussi sur mes autres VM. Est-ce que je n'ai qu'à refaire la même chose avec d'autres /64 sur lesdites VM ? Ou est-ce qu'il faut complètement changer la config pour que ça soit l'hyperviseur ESXi qui fasse la requête DHCPv6 sur le /56 complet et qui ensuite routera les IPv6 sur les VM ? Si c'est ce 2nd cas de figure, je ne sais absolument pas comment faire, donc j'aurai là aussi besoin d'aide...

Bref, prenons les choses dans l'ordre. Si quelqu'un peut m'aider à refaire fonctionner mon dhclient, ça serait super

(Ou si qqn à une autre solution plus viable, je suis également preneur et ouvert à toute suggestion !

)

Merci par avance pour vos réponses, et désolé pour le pavé, mais je me suis dit qu'en donnant un maximum de détails, ça serait plus facile d'aider

Kedare · « **Réponse #1 le:** 03 juin 2021 à 14:55:30 »

Hello.

J'ai un peu de mal a comprendre le soucis exactement.

Si je comprend bien tes VM ont leurs interfaces montées sous forme de bridge sur l'interface publique de ton serveur ? (du coup un subnet par VM et pas une subnet routé vers une vm de routage sur ton hyperviseur puis après tu redistibue des IPv6 de ton subnet sur chaque VM via un réseau privé sur ton hyperviseur, perso je préfère la deuxième approche mais il faut pouvoir gérer une VM pour le routage type VyOS ou autre, ca te permet en même temps de faire tout ton filtrage a un seul endroit)

Pour ton prefixe effectivement il ne peut être routé qu'a un seul endroit a la fois (si dans ton cas tu le réutilise sur le nouveau serveur, il faut bien le release avant (tu peux regarder ici https://lafibre.info/scaleway/stabilite-dipv6-sur-dedies-et-vm-chez-scaleway/msg872267/#msg872267 pour le moment les prefixes ne sont pas automatiquement release des anciens serveurs quand tu migre ton prefixe mais ca va changer dans quelques semaines)

As tu un ticket ouvert de notre coté ?
Si non peut tu m'indiquer ton prefix en privé que je regarde au niveau des logs ?

Si tes VM sont mappés directement sur ton port publique dans ce cas la tu peut refaire la même procédure pour chaque VM (tu alloue un /64 sur ta console Online avec un duid différent pour chaque VM)

David M. · « **Réponse #2 le:** 03 juin 2021 à 15:29:12 »

Alors, je vais essayer de schématiser :
Hyperviseur (machine physique) : connecté uniquement en IPv4 avec l'IP fixe du serveur.

VM Plesk : Connectée via un vswitch (donc en bridge, effectivement) sur lequel se trouve également l'interface physique du serveur. Sur la VM, j'ai paramétré deux IPv4 FO (IPFO groupées sur la même MAC, qui est paramétrée dans la VM), et un /64 IPv6 (avec le dhclient qui bugue).
Les autres VM : IPv4 only, toutes en IPFO, connectées sur le même vswitch (donc toujours en bridge, chacune avec une IPFO différente).

Voilà le schéma du vswitch remonté par ESXi :

Pour le préfixe, non, effectivement, pas de release effectué sur l'ancien serveur (je ne savais pas qu'il fallait le faire...

). Je t'ai envoyé mon préfixe en message privé avec les ID de l'ancien et du nouveau serveur.

Pas de ticket ouvert de votre côté. Je me suis dit que comme c'était un pb de config côté OS, ça ne passerait pas.

Citer

Si tes VM sont mappés directement sur ton port publique dans ce cas la tu peut refaire la même procédure pour chaque VM (tu alloue un /64 sur ta console Online avec un duid différent pour chaque VM)

==> Donc en théorie, un dhclient par VM ne pose pas de pb, tant que c'est avec un /64 différent, un DUID différent (logique), et que l'interface de chaque VM est sur le même vswitch (en bridge, quoi) ?

Merci pour ces premiers éléments de réponse, en tout cas !

David

Kedare · « **Réponse #3 le:** 03 juin 2021 à 15:56:57 »

Le release peut être fait depuis le nouveau serveur (il faut juste bien suivre la procédure indiqué sur l'autre topic en attendant le fix définitif d'ici quelques semaines).

La en regardant les logs coté DHCPv6, je vois bien ton préfixe routé vers une VM de ton nouveau serveur (et la ::1 ping bien).

Un dhclient par VM ne devrait pas être un soucis.

David M. · « **Réponse #4 le:** 03 juin 2021 à 16:04:36 »

Citation de: Kedare le 03 juin 2021 à 15:56:57

Le release peut être fait depuis le nouveau serveur (il faut juste bien suivre la procédure indiqué sur l'autre topic en attendant le fix définitif d'ici quelques semaines).

Ok, je vais voir pour faire la manip, histoire d'être sûr. Question bête : On le fait comment, le release ? Avec dhclient ? Si je peux avoir la commande... (désolé pour mon ignorance sur ce point...)

Citation de: Kedare le 03 juin 2021 à 15:56:57

La en regardant les logs coté DHCPv6, je vois bien ton préfixe routé vers une VM de ton nouveau serveur (et la ::1 ping bien).

Ok. Merci pour la vérif. Du coup, pourquoi mon DHClient n'obtient pas de réponse et plante ? C'est lié au fait que je n'avais pas fait de release ?

Citation de: Kedare le 03 juin 2021 à 15:56:57

Un dhclient par VM ne devrait pas être un soucis.

Bon, ça, c'est une bonne nouvelle.

Reste à faire en sorte que ça fonctionne ^^

Du coup, une autre question, dont je pense que j'ai une partie de la réponse dans le message précédent :
J'ai une de mes VM (pas celle avec de l'IPv6) qui fait également routeur sur IPv4 sur une autre interface connectée à un vswitch "privé", si je puis dire. Ca me permet d'avoir internet sur d'autres VM sans IPFO supplémentaire. Ca fonctionne très bien, pas de souci de ce côté. (C'est configuré avec UFW pour les redirections de port et le routage).

Si j'ai bien compris ce qui a été dit dans la 1ère réponse, si je veux ajouter de l'IPv6 sur les VM qui sont connectées sur le vswitch privé, là, il faut que je configure un /64 sur ma VM "routeur", et que cette même VM "routeur" route ensuite les IPv6 vers les autres VM ?
Si oui, la question qui tue : On fait comment ?

(Je n'ai jamais fait ça en IPv6...

)

Kedare · « **Réponse #5 le:** 03 juin 2021 à 16:16:18 »

Citation de: David M. le 03 juin 2021 à 16:04:36

Ok, je vais voir pour faire la manip, histoire d'être sûr. Question bête : On le fait comment, le release ? Avec dhclient ? Si je peux avoir la commande... (désolé pour mon ignorance sur ce point...)

Alors pour release, tu dois bien avoir le fichier de config avec le bon duid bien sûr, puis tu peux utiliser ces commandes la (il faut adapter le nom de fichiers de config et d'interface)

Code: [Sélectionner]

dhclient -cf /etc/dhcp/dhclient6.conf -6 -P -v enp94s0f0         # To request, as root
dhclient -cf /etc/dhcp/dhclient6.conf -6 -P -v enp94s0f0 -r      # To release, as root

Citation de: David M. le 03 juin 2021 à 16:04:36

Ok. Merci pour la vérif. Du coup, pourquoi mon DHClient n'obtient pas de réponse et plante ? C'est lié au fait que je n'avais pas fait de release ?
Bon, ça, c'est une bonne nouvelle. Reste à faire en sorte que ça fonctionne ^^

C'est pas normal que tu n'ai pas de réponse, ca peut arriver si le DUID ne correspond pas typiquement,
Tu as toujours ce soucis du coup ?

Citation de: David M. le 03 juin 2021 à 16:04:36

Du coup, une autre question, dont je pense que j'ai une partie de la réponse dans le message précédent :
J'ai une de mes VM (pas celle avec de l'IPv6) qui fait également routeur sur IPv4 sur une autre interface connectée à un vswitch "privé", si je puis dire. Ca me permet d'avoir internet sur d'autres VM sans IPFO supplémentaire. Ca fonctionne très bien, pas de souci de ce côté. (C'est configuré avec UFW pour les redirections de port et le routage).

Si j'ai bien compris ce qui a été dit dans la 1ère réponse, si je veux ajouter de l'IPv6 sur les VM qui sont connectées sur le vswitch privé, là, il faut que je configure un /64 sur ma VM "routeur", et que cette même VM "routeur" route ensuite les IPv6 vers les autres VM ?
Si oui, la question qui tue : On fait comment ? (Je n'ai jamais fait ça en IPv6... )

Voila, tu vas juste configurer le dhcpv6-pd sur ta VM routeur, tu aura ensuite tout le /64 (ou autre) routé vers celui ci, ensuite sur l'interface coté interne de ta VM tu peux mapper une IP type ::1 ou autre, et activer le SLAAC pour que derrière tes VM récupère automatiquement une IPv6 dans ce subnet.
Si ta VM de routage est sous Ubuntu tu peux regarder cette doc: https://www.linuxtopia.org/online_books/network_administration_guides/Linux+IPv6-HOWTO/hints-daemons-radvd.html

David M. · « **Réponse #6 le:** 03 juin 2021 à 16:21:14 »

Citation de: Kedare le 03 juin 2021 à 16:16:18

Alors pour release, tu dois bien avoir le fichier de config avec le bon duid bien sûr, puis tu peux utiliser ces commandes la (il faut adapter le nom de fichiers de config et d'interface)

Code: [Sélectionner]
dhclient -cf /etc/dhcp/dhclient6.conf -6 -P -v enp94s0f0 # To request, as root dhclient -cf /etc/dhcp/dhclient6.conf -6 -P -v enp94s0f0 -r # To release, as root

Super, merci ! Je teste ça dans la soirée

Citation de: Kedare le 03 juin 2021 à 16:16:18

C'est pas normal que tu n'ai pas de réponse, ca peut arriver si le DUID ne correspond pas typiquement,
Tu as toujours ce soucis du coup ?

Pas encore testé, j'évite de trop bidouiller pendant la journée pour pas trop impacter les clients (et comme dhclient fait tomber l'IPv6 à chaque fois quand il n'a pas de réponse...)
A tout hasard, est-ce qu'il y aurait pu avoir un blocage côté DHCP pour cause de flood ? (Je n'ai lancé les commandes IPTABLES pour limiter ça qu'aujourd'hui)

Sinon, pour le dhclient6.conf, j'en ai vu qui avaient en plus une instruction request; comme ci-dessous. Est-ce utile ?

Code: [Sélectionner]

interface "ens192" {
        send dhcp6.client-id 00:00:00:00:00:00:00:00:00:00;
        request;
}

Citation de: Kedare le 03 juin 2021 à 16:16:18

Voila, tu vas juste configurer le dhcpv6-pd sur ta VM routeur, tu aura ensuite tout le /64 (ou autre) routé vers celui ci, ensuite sur l'interface coté interne de ta VM tu peux mapper une IP type ::1 ou autre, et activer le SLAAC pour que derrière tes VM récupère automatiquement une IPv6 dans ce subnet.
Si ta VM de routage est sous Ubuntu tu peux regarder cette doc: https://www.linuxtopia.org/online_books/network_administration_guides/Linux+IPv6-HOWTO/hints-daemons-radvd.html

Je vais regarder ça. la VM routeur est justement sur Ubuntu.
Va falloir regarder ensuite comme activer Slaac, mais ça devrait jouer

Kedare · « **Réponse #7 le:** 03 juin 2021 à 18:05:19 »

Le blocage en cas de flood shut le port du serveur donc non ce n'est pas ca qui bloque si non tu l'aurais remarqué

Le n'ai jamais utilisé le request dans la configuration dhclient6 et jamais eu de soucis sans personnellement.

David M. · « **Réponse #8 le:** 04 juin 2021 à 09:23:38 »

Bonjour à tous,

Bon, j'avance dans tout ça !

Déjà, j'ai trouvé pourquoi le dhclient bloquait... Un truc tellement con...
Au début, ça fonctionnait... Mais entre temps, j'avais activé le parefeu Plesk...

Et comme il y avait une règle "IPv6 Neighbor Discovery" de base, j'avais cru que c'était bon... Et ensuite, j'avais complètement zappé ce point.

Bref, j'ai refais une règle sur le 546/UDP et le dhclient fonctionne.

Par contre, ça me fait quand même sauter toutes mes IP, je suis obligé de refaire un netplan apply après.
Une idée ?

Kedare · « **Réponse #9 le:** 04 juin 2021 à 10:45:01 »

dhclient te fait sauter tes IP ou netplan te fait sauter tes IP ?

Netplan ne supporte pas les prefix delegation d'après ce bug : https://bugs.launchpad.net/netplan/+bug/1771886

Tu peux par exemple remplacer netplan par autre chose comme indiqué ici : https://www.medo64.com/2020/07/ipv6-prefix-delegation-with-netplan/
Tu peux aussi choisir de retourner sur ifupdown : https://techpiezo.com/linux/switch-back-to-ifupdown-etc-network-interfaces-in-ubuntu/

Je recommande chaudement le pattern ou tu expose juste une VM de type routeur/firewall qui supporte tout ça par défaut (opnsense par exemple) et redistribue ensuite les IPv6 via SLAAC automatiquement sur ton réseau interne. Il faut que je fasse une page de documentation à propos de comment faire ça.

David M. · « **Réponse #10 le:** 04 juin 2021 à 11:20:51 »

C'est DHClient qui fait sauter les IP.

Je vais voir pour repasser sur ifupdown, ça, au moins, je connais bien.

Après, pour les VM qui n'ont pas d'interface en bridge directement sur la carte physique du serveur, c'est ce que je ferai, oui, une VM routeur et le reste en SLAAC.

Merci pour les réponses !
Je vous tiens au jus une fois les modifs appliquées.