[Résolu] VirtualBox / DHCP / 'adaptateur réseau hôte' et PXE

[Kuro_Tsuki]

Bonjour à tous,

Je m’excuse par avance pour mon titre qui je l’avoue n’est pas très clair.

Mon but est de tester l’installation d’une Debian via un boot par le réseau.
Pour m’éviter de jongler avec deux claviers, deux souris, deux moniteurs etc… j’ai choisi de tester le tout sous VirtualBox avant de le faire en vrai.
Pour recevoir les fichiers nécessaires à l’installation, le PC invité (virtualisé) à besoin de recevoir une configuration réseau (via un serveur DHCP) du PC hôte.

J’ai fait :

debian:~# tunctl -t tap0 -u root
Set 'tap0' persistent and owned by uid 0
debian:~# brctl addbr br0
debian:~# ifconfig eth0 0.0.0.0 promisc
debian:~# brctl addif br0 eth0
debian:~# ifconfig br0 192.168.1.102
debian:~# brctl addif br0 tap0
debian:~# ifconfig tap0 up

mais le PC invité indique qu’il ne reçoit aucune offre de DHCP alors qu’il y a bien des “DHCPOFFER from <@MAC> via eth0” dans les logs.

Remarquez que j’ai tout fait en root pour être sûr que le problème ne vienne pas des droits.
Notez aussi que si je remplace ‘ifconfig br0 192.168.1.102’ par ‘dhclient br0’ alors j’obtiens “No DHCPOFFERS received. No working leases in persistent database - sleeping.”

Je poste ici mes fichiers de configurations :
+ /etc/default/dhcp3-server

#Si je met INTERFACES="eth0", DHCP rétorque "Not configured to listen on any interfaces" INTERFACES=""

+ /etc/network/interfaces

[code]
auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet dhcp[/code]

+ /etc/dhcp3/dhcpd.conf

ddns-update-style none;
ddns-updates off;
server-name "MonDHCP";
authoritative;
option T150 code 150 = string;
deny client-updates;
one-lease-per-client false;
allow bootp;
allow booting;

option subnet-mask 255.255.255.0;
default-lease-time 6000;
max-lease-time 7200;
option time-offset -3600;
log-facility local7;

option domain-name-servers 90.5.223.212;

subnet 192.168.0.0 netmask 255.255.255.0 {
    interface eth0;
    range 192.168.0.1 192.168.0.254;
    default-lease-time 6000;
    max-lease-time 7200;
    option subnet-mask 255.255.255.0;
    option time-offset -3600;
}

Si je met ‘adaptateur réseau hôte’ en spécifiant tap0, jai droit à :

Si quelqu’un à une idée, suggestion ou a besoin de plus de précisions, je suis ouvert

Merci par avance

[PascalHambourg]

Il n’y a pas que le titre qui n’est pas très clair !

Pourquoi créer un pont entre tap0 et eth0 ?

De quel serveur DHCP eth0 obtient-elle sa configuration IP ?
Si eth0 doit être intégrée au pont br0, il ne faut pas lui attribuer une configuration IP dans /etc/network/interfaces, c’est à br0 qu’il faut l’attribuer. En fait eth0 doit quasiment disparaître partout au profit de br0.

Le serveur DHCP est sur la machine hôte ? Sert-il d’autres machines que la machines virtuelle ?

Si le serveur DHCP doit être accessible par la machine virtuelle, il doit écouter sur br0 et non eth0. Mais l’adresse IP 192.168.1.102 configurée sur br0 ne correspond pas au sous-réseau 192.168.0.0/24 défini dans dhcpd.conf.

mais le PC invité indique qu’il ne reçoit aucune offre de DHCP alors qu’il y a bien des “DHCPOFFER from <@MAC> via eth0” dans les logs.

DHCPOFFER ou DHCPDISCOVER ?

[Kuro_Tsuki]

Alors,

Pourquoi créer un pont entre tap0 et eth0 ?

VirtualBox offre quatre ‘modes’ réseau à savoir
[ul][li]Non attaché donc aucune connexion[/li]
[li]NAT qui permet l’utilisation d’Internet depuis le PC invité
Mais ceci ne marche pas pour les serveurs dont DHCP.[/li]
[li]Réseau interne qui permet de mettre en réseau (uniquement) plusieurs machines virtuelles[/li]
[li]et adaptateur réseau qui (si j’ai bien compris) permet d’avoir le PC invité présent dans le LAN (comme un vrai PC donc)[/li][/ul]

Effectivement, si ce que je raconte est faux, ça change tout.

De quel serveur DHCP eth0 obtient-elle sa configuration IP ?

Le serveur DHCP est présent sur le PC hôte.

Si eth0 doit être intégrée au pont br0, il ne faut pas lui attribuer une configuration IP dans /etc/network/interfaces, c’est à br0 qu’il faut l’attribuer. En fait eth0 doit quasiment disparaître partout au profit de br0.

Donc il faudrait que je remplace

allow-hotplug eth0 iface eth0 inet dhcp
par

allow-hotplug br0 iface br0 inet dhcp

Le serveur DHCP est sur la machine hôte ? Sert-il d’autres machines que la machines virtuelle ?

Oui // Non
J’ai deux PCs, deux moniteurs, deux claviers, deux souris, un câble type RJ45 et un modem USB pour l’accès au net, pas plus.

Si le serveur DHCP doit être accessible par la machine virtuelle, il doit écouter sur br0 et non eth0.

Dois-je donc mettre INTERFACES=“br0” dans /etc/default/dhcp3-server ?

Mais l’adresse IP 192.168.1.102 configurée sur br0 ne correspond pas au sous-réseau 192.168.0.0/24 défini dans dhcpd.conf.

Argg. Pas fait attention, désolé.
À force de lire plusieurs tutos par ci par là, je finis par faire les commandes sans réfléchir.

DHCPOFFER ou DHCPDISCOVER ?

Les deux :
DHCPDISCOVER from <@MAC_vBox_Adaptateur0> via eth0
DHCPOFFER on <@IP_inconnue> to <@MAC_vBox_Adaptateur0> via eth0

avec @IP_inconnue qui vaut 192.168.0.6 (adresse ip de eth0 ?) mais qui change à chaque fois. Je soupçonne DHCP mais si c’est le cas, cela signifie qu’il fait son boulot. Enfin, ça serait mieux si ifconfig me l’indiquait.

Mais comme ils ne sont pas dans le même réseau, c’est normal que ça ne marche pas.

Je vais faire les modifications que tu proposes et je reviendrait poster les résultats.

Encore merci.

[PascalHambourg]

VirtualBox offre quatre ‘modes’ réseau à savoir (…)

Je ne me souviens pas que VirtualBox gérait tout ça. Quand je l’avais utilisé, tout ce qu’il faisait c’était une liaison entre une paire d’interfaces ethernet virtuelles entre la machine hôte (tapX) et la machine virtuelle, et il fallait se débrouiller soi-même pour gérer les interfaces. Tu ne confondrais pas avec VMware ?

[quote]Les deux :
DHCPDISCOVER from <@MAC_vBox_Adaptateur0> via eth0
DHCPOFFER on <@IP_inconnue> to <@MAC_vBox_Adaptateur0> via eth0
[/quote]
D’accord mais le message avec “from <@MAC>” était bien un DHCPDISCOVER, pas un DHCPOFFER.

avec @IP_inconnue qui vaut 192.168.0.6 (adresse ip de eth0 ?)

C’est l’adresse IP que le serveur DHCP propose au client (la machine virtuelle). Je suppose que c’est bon.
Par contre l’interface n’est pas bonne. Je suppose qu’il se passe la chose suivante :

• La machine virtuelle envoie une requête DHCPDISCOVER en broadcast, qui est reçue par la machine hôte sur son interface tap0. Comme tap0 est pontée avec eth0 dans br0, le paquet est retransmis en sortie par eth0.

• dhcpd écoute à bas niveau sur eth0 (un peu comme ferait tcpdump ou wireshark) et voit passer le paquet (en sortie, mais peu importe apparemment) et y répond en envoyant un DHCPOFFER… mais sur eth0 et non br0. Du coup le paquet n’est pas retransmis sur tap0 et ne parvient pas à la machine virtuelle. Oui, c’est un peu compliqué les relations entre un pont et ses interfaces.

Tu peux créer un pont entre tap0 et eth0, mais comme je l’ai dit il faudra qu’il remplace eth0 partout (accessoirement je trouve bizarre d’utiliser allow-hotplug avec un pont et de configurer une interface en DHCP avec un serveur qui tourne sur la machine elle-même).

Mais tu peux aussi laisser les deux interface eth0 et tap0 indépendantes, avec deux réseaux séparés, configurer tap0 en statique et faire écouter dhcpd dessus.

Le pontage ne se justifie que si la machine virtuelle doit être dans le même réseau que ce qui est connecté à eth0.

[Kuro_Tsuki]

Je ne me souviens pas que VirtualBox gérait tout ça. Quand je l’avais utilisé, tout ce qu’il faisait c’était une liaison entre une paire d’interfaces ethernet virtuelles entre la machine hôte (tapX) et la machine virtuelle, et il fallait se débrouiller soi-même pour gérer les interfaces. Tu ne confondrais pas avec VMware ?

Ce qui est bien avec le monde du libre c’est que ça ne peut qu’évoluer.
Je ne sais pas quelle version tu as utilisée mais celle que j’ai (v 1.5.6) propose cela :

C’est l’adresse IP que le serveur DHCP propose au client (la machine virtuelle). Je suppose que c’est bon.

Ah ben oui, l’adresse IP de la machine virtuelle, évidemment.

Tu peux créer un pont entre tap0 et eth0, mais comme je l’ai dit il faudra qu’il remplace eth0 partout

Créer un pont entre tap0 et eth0 … c’est pas ce que je fais avec br0 ?

(accessoirement je trouve bizarre d’utiliser allow-hotplug avec un pont et de configurer une interface en DHCP avec un serveur qui tourne sur la machine elle-même).

Le système de boot par réseau implique la présence d’un serveur DHCP (attend un DHCPACK) même si ce dernier ne servira qu’une fois et pour une seule machine.

Quant au “allow-hotplug”, il permet la configuration de l’interface uniquement lorsque celle-ci devient active (au démarrage de la machine virtuelle).

Maintenant, lorsque la machine virtuelle démarre j’ai :
DHCPDISCOVER from <@MAC_VBox> via br0
DHCPOFFER on <@IP_Vbox> to <@MAC_br0> via br0

mais elle ne reçoit aucun des DHCPOFFER.
Pourtant s’ils sont envoyés sur br0, eth0 et tap0 devraient les recevoir, non ?

et eth0 dans tout ça ?

Enfin en tout cas, merci de on aide

[PascalHambourg]

Oups, ma mémoire me joue des tours. VirtualBox 1.3.8 dont j’ai retrouvé le manuel dans mes archives avait bien toutes ces options de gestion réseau. C’est certainement moi qui avais fait l’impasse à cause de leur faible intérêt.

Ce que j’essaie de dire, c’est que d’après ce que je comprends tu n’as pas besoin de créer un pont entre eth0 et tap0, c’est se compliquer la vie pour rien. Je ne sais pas à quoi est connectée eth0 de la machine hôte, mais tout ce dont tu as besoin est une connexion réseau entre la machine hôte et la machine virtuelle, avec un serveur DHCP qui écoute sur tap0 de la machine hôte. Le serveur DHCP n’a pas besoin d’écouter sur eth0, il ne fournit pas de bail à des machines extérieures. La machine virtuelle n’a pas besoin de communiquer avec l’extérieur. Dis-moi si je me trompe.

J’ai bien compris le but du serveur DHCP sur la machine hôte qui est de fournir une configuration à la machine virtuelle, mais je trouve curieux que eth0 ou br0 de la machine hôte soit configurée par ce serveur.

Quant au “allow-hotplug” sur br0, je doute que br0 change d’état au démarrage de la machine virtuelle.

[quote]DHCPDISCOVER from <@MAC_VBox> via br0
DHCPOFFER on <@IP_Vbox> to <@MAC_br0> via br0[/quote]
DHCPOFFER to <@MAC_br0> ? Normalement ça devrait être l’adresse MAC de la machine virtuelle.

[quote]mais elle ne reçoit aucun des DHCPOFFER.
Pourtant s’ils sont envoyés sur br0, eth0 et tap0 devraient les recevoir, non ?[/quote]
Non, normalement le DHCPOFFER devrait être retransmis seulement par tap0 car le pont devrait associer l’adresse MAC de la machine virtuelle à cette interface dans son cache MAC.

Tu pourrais faire une capture de paquets avec adresse MAC sur tap0 pour voir ce qui passe ? Ex: tcpdump -nvtei tap0

et eth0 dans tout ça ?

Ben, si j’ai bien compris elle sert à rien, non ?

[Kuro_Tsuki]

Ce que j’essaie de dire, c’est que d’après ce que je comprends tu n’as pas besoin de créer un pont entre eth0 et tap0, c’est se compliquer la vie pour rien.

Pourquoi faire simple quand on peut faire compliqué ?
Euh… non
Pourquoi faire compliqué quand on peut faire simple ?

Je ne sais pas à quoi est connectée eth0 de la machine hôte, mais tout ce dont tu as besoin est une connexion réseau entre la machine hôte et la machine virtuelle, avec un serveur DHCP qui écoute sur tap0 de la machine hôte.

Pour faire une connexion réseau entre les deux machines, il nous faut juste une interface.
Donc j’ai juste besoin de tap0 ?

Le serveur DHCP n’a pas besoin d’écouter sur eth0, il ne fournit pas de bail à des machines extérieures. La machine virtuelle n’a pas besoin de communiquer avec l’extérieur. Dis-moi si je me trompe.

Oui oui c’est ça.

J’ai bien compris le but du serveur DHCP sur la machine hôte qui est de fournir une configuration à la machine virtuelle, mais je trouve curieux que eth0 ou br0 de la machine hôte soit configurée par ce serveur.

Inutile en effet.

Quant au “allow-hotplug” sur br0, je doute que br0 change d’état au démarrage de la machine virtuelle.

Mais si je met “auto”, au démarrage, il va vouloir configurer br0… qui n’existe pas. C’est “brctl addbr br0” qui la créé et DHCP n’aime pas configurer des interfaces qui ne sont pas actives.
Enfin bon, c’est toi qui vois.

DHCPOFFER to <@MAC_br0> ? Normalement ça devrait être l’adresse MAC de la machine virtuelle.

Étourderie de ma part ?

Ben, si j’ai bien compris elle sert à rien, non ?

eth0 n’est reliée à rien donc pour l’instant oui elle ne sert à rien.

Bon alors je résume :
Nous avons deux machines, une hôte et une virtuelle.
Cette dernière a besoin de recevoir une configuration réseau en provenance de la machine hôte.
Pour relier les deux, nous avons besoin d’une interface virtuelle tap0.
Le serveur DHCP ainsi que la machine virtuelle écouterons sur cette interface.

donc :
+ /etc/default/interfaces

[code]auto lo
iface lo inet loopback

iface tap0 inet dhcp[/code]

+ /etc/default/dhcp3-server

INTERFACES=""

+ /etc/dhcp3/dhcpd.conf

[code]ddns-update-style none;
ddns-updates off;
server-name “MonDHCP”;
authoritative;
option T150 code 150 = string;
deny client-updates;
one-lease-per-client false;
allow bootp;
allow booting;

option subnet-mask 255.255.255.0;
default-lease-time 6000;
max-lease-time 7200;
option time-offset -3600;
log-facility local7;

subnet 192.168.0.0 netmask 255.255.255.0 {
interface tap0;
range 192.168.0.1 192.168.0.254;
default-lease-time 6000;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option time-offset -3600;
}[/code]

À ta demande :

[code]debian:/etc/init.d# tcpdump -nvtei tap0
tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes
08:00:27:04:b1:59 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 20, id 0, offset 0, flags [none], proto UDP (17), length 576) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:00:27:04:b1:59, length 548, xid 0x2804b159, secs 4, Flags [Broadcast]
Client-Ethernet-Address 08:00:27:04:b1:59 [|bootp]
00:ff:36:e3:24:54 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.0.7 tell 192.168.0.8
00:ff:36:e3:24:54 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, xid 0x2804b159, secs 4, Flags [Broadcast]
Your-IP 192.168.0.7
Client-Ethernet-Address 08:00:27:04:b1:59
sname “MonDHCP” [|bootp]
00:ff:36:e3:24:54 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.0.7 tell 192.168.0.8
08:00:27:04:b1:59 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 20, id 1, offset 0, flags [none], proto UDP (17), length 576) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:00:27:04:b1:59, length 548, xid 0x2904b159, secs 6, Flags [Broadcast]
Client-Ethernet-Address 08:00:27:04:b1:59 [|bootp]
00:ff:36:e3:24:54 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, xid 0x2904b159, secs 6, Flags [Broadcast]
Your-IP 192.168.0.7
Client-Ethernet-Address 08:00:27:04:b1:59
sname “MonDHCP” [|bootp]
00:ff:36:e3:24:54 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 192.168.0.7 tell 192.168.0.8
08:00:27:04:b1:59 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 20, id 2, offset 0, flags [none], proto UDP (17), length 576) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:00:27:04:b1:59, length 548, xid 0x2a04b159, secs 10, Flags [Broadcast]
Client-Ethernet-Address 08:00:27:04:b1:59 [|bootp]
00:ff:36:e3:24:54 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, xid 0x2a04b159, secs 10, Flags [Broadcast]
Your-IP 192.168.0.7
Client-Ethernet-Address 08:00:27:04:b1:59
sname “MonDHCP” [|bootp]
08:00:27:04:b1:59 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 20, id 3, offset 0, flags [none], proto UDP (17), length 576) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:00:27:04:b1:59, length 548, xid 0x2b04b159, secs 18, Flags [Broadcast]
Client-Ethernet-Address 08:00:27:04:b1:59 [|bootp]
00:ff:36:e3:24:54 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, xid 0x2b04b159, secs 18, Flags [Broadcast]
Your-IP 192.168.0.7
Client-Ethernet-Address 08:00:27:04:b1:59
sname “MonDHCP” [|bootp]

11 packets captured
11 packets received by filter
0 packets dropped by kernel
[/code]

avec

tap0 Link encap:Ethernet HWaddr 00:ff:36:e3:24:54 inet addr:192.168.0.8 Bcast:192.168.0.255 Mask:255.255.255.0

et 08002704B159 l’adresse MAC générée par VBox pour ma machine virtuelle.

Dans syslog, j’ai :
DHCPDISCOVER from <@MAC_VBox> via tap0
DHCPOFFER on 192.168.0.7 (@IP_MachineVirtuelle) to <@MAC_VBox> via tap0

Eh ben… le DHCPOFFER est envoyé à l’IP de la machine virtuelle, avec la bonne adresse MAC et via tap0 !
Alors qu’est-ce qui cloche ?

Merci merci de ta patience

[PascalHambourg]

Est-ce que maintenant ce qui s’affiche dans la console de la machine virtuelle diffère de la capture précédente ?

Il se trouve que j’avais justement testé le boot réseau avec VirtualBox, mais c’est fou comme on oublie quand on ne pratique pas. Il me semble qu’un client BOOTP a besoin que le serveur BOOTP/DHCP spécifie un fichier de démarrage et le serveur où le récupérer (par TFTP généralement). Or je ne vois pas de déclarations “filename” et “next-server” dans ton dhcpd.conf. C’est peut-être pour cela que la machine virtuelle ignore le DHCPOFFER.

[Kuro_Tsuki]

Super ça marche !

Tu avais raison, il me manquait les options “next-server” et “filename” pour lui dire quel fichier booter par le réseau !

Pour ceux que ça intéresse, je poste mes fichiers de configuration :

[ul][li] /etc/network/interface

[code]auto lo
iface lo inet loopback

auto tap0
iface tap0 inet static
address 192.168.0.11
gateway 192.168.0.11[/code]
[/li]
[li] /etc/default/dhcp3-server

INTERFACES=""

[/li]
[li] /etc/dhcp3/dhcpd.conf

[code]ddns-update-style none;
ddns-updates off;
server-name “MonDHCP”;
authoritative;
option T150 code 150 = string;
deny client-updates;
one-lease-per-client false;
allow bootp;
allow booting;

log-facility local7;

subnet 192.168.0.0 netmask 255.255.255.0 {
interface tap0;
range 192.168.0.1 192.168.0.254;
default-lease-time 6000;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
option time-offset -3600;

filename "pxelinux.0";
next-server 192.168.0.11;
option root-path "192.168.0.11:/pxeroot";

}[/code][/li][/ul]

J’ai suivi les instructions de cette page.

J’ai des problèmes de serveur NFS mais bon je vais voir ça avec ceux du forum de howtoforge.com.

En tous cas, merci, merci beaucoup.