¶ TP DHCP
01/12/2022 : la dév est morte il y a quelques mois, et avec elle ce beau TP. N'hésitez pas à le refaire ou à le dockeriser.
13/12/2022 : Le beau tp à été refait, n'hésitez pas à le faire.
Merci à seberus pour ce beau TP !
¶ Pré-requis :
¶ Introduction
Kea est un package proposant un serveur DHCP open-source et souvent bien plus complet que le DHCP natif de debian. A MiNET nous utilisons deux serveurs KEA pour donner aux adhérents les IP nécessaires, ces serveurs sont liés par ce que l’on appelle « High Availability » ce qui permet de conserver en permanence un serveur en état de travail et l’autre en état de repos. De cette manière si l’un des serveurs tombe l’autre reprend la main.
Dans ce TP nous allons apprendre à configurer un serveur KEA simple.
Les machines que nous utiliserons sont présentes sur le cluster de développement et sont respectivement :
- f-dhcp-serveur : 192.168.103.172
- f-dhcp-client : 192.168.103.173
Vos identifiants pour vous connecter en SSH sur ces machines
User : naina
Password : j3 su1s 1 p3t1t 1A !!!
Afin de démarrer correctement le TP nous allons remettre les machines à leur état initial.
Pour ce faire, rendez-vous dans l’interface graphique de Proxmox, puis dans le menu de chaque machine allez dans l’onglet « Backup » et faites une restoration de la backup [BASE].
¶ Installation de Kea
Pour installer le package correspondant à kea, il faut ajouter un dépôt de package particulier car kea n’est pas compris dans les dépots par défaut de debian.
En exportant les proxy, nous allons utiliser directement le programme d’installation de ces dépôts, proposé par le site officiel de kea.
- Exporter les proxys, et taper la commande suivante :
curl -1sLf \
'https://dl.cloudsmith.io/public/isc/kea-2-1/setup.deb.sh' \
| sudo -E bash
Je ne sais plus exporter les proxys !
export http_proxy="http://192.168.103.61:82/"
export https_proxy="http://192.168.103.61:82/"
-
Pour vérifier si les dépots sont bien installés, on peut regarder le contenu du dossier /etc/apt/sources.list.d/. Y a-t-il les dépots correspondants à kea ?
-
Installons à present le package de kea-dhcp4 :
apt install isc-kea-dhcp4-server
Si l’installation se passe correctement, vous devriez avoir un dossier /etc/kea/
Est-il présent ?
¶ Mise en place du Vlan de simulation
Le but de ce TP est de simuler un vlan qu’on appelera « vlan 765 » dans lequel se trouveront les machines client et serveur. Les requêtes DHCP ne passeront et ne seront écoutées alors que dans ce vlan pour ne pas polluer le vlan de développement.
Le serveur DHCP devra fournir des IP dans la plage (autrement appelée pool) 192.168.1.0/24
Dans proxmox il est possible de créer ce que l’on appelle des bridge pour lier des interfaces à des vlan particuliers. Un bridge se comporte comme un switch virtuel entre les VM/CT présents dans la machine. De plus en sortie/entrée de la machine hôte, le bridge utilise l’interface physique en travaillant dans le vlan qui a été assignée. (exemple si les nœuds de développement veulent communiquer ensemble dans le vlan 103 le bridge utilise le port physique dans le vlan 103).
Exemple des bridge créés sur la dev :
- Vmbr0 : bridge lié au vlan 103 du cluster de dév
- Vmbr3 : bridge lié au vlan publique de développement (ip publiques)
- Vmbr147 : bridge lié au vlan147 du local
Le bridge vmbr765 existe déjà sur la machine hôte mais il faut à présent créer des interfaces dans les machines qui nous intéressent et les lier à ce bridge. Pour cela rendez-vous dans la configuration des container, dans network, et créez une interface réseau appelée eth1. Pour le DHCP l’IP doit être 192.168.1.1. Pour le client nous chercherons une IP par DHCP !
Une fois cela fait, nous avons désormais ces deux machines dans le vlan 765 !
¶ Configuration basique de Kea
Il ne reste plus qu’à configurer kea-dhcp4 pour répondre aux exigences suivantes :
- L’interface écoutée doit être eth1
- Le subnet utilisé sera 192.168.1.0/24
- La pool s’étend de 192.168.1.2 à 192.168.1.254
- Le routeur par défaut est 192.168.1.2
Tips
La configuration se modifie dans la section « subnet4 » pour les trois dernières exigences.ATTENTION : Pensez à commenter toutes les réservations d’IP, sinon Kea voudra attribuer des IP qui ne sont pas comprises dans la pool et ne démarrera donc pas !
- Redémarrer le service kea pour prendre en compte les modifications.
Comment redémarrer un service ?
service isc-kea-dhcp4-server restart
Pour réaliser notre test, allons sur le client.
- Vérifiez dans une premier temps que vous n’avez pas d’IP.
Mon IP ?
ip a
- Si vous possédez déjà une IP ce n’est pas drôle donc relâchons la lease !
Lease ?
dhclient -r
- Si vous ne possédez pas d’IP faisons une demande DHCP manuelle :
dhclient -i eth1
- Vérifier le résultat :
ip a
Votre machine a-t-elle une IP ? Laquelle ?
Quel est le routeur par défaut mis en place ?
¶ Réservations
En fait nous vous avons un peu menti, à MiNET nous utilisons en effet des serveurs DHCP mais contrairement à ce que vous venez de mettre en place… nos IP sont statiques !
C’est-à-dire que chaque machine a une IP spécifique qui ne changera pas ce qui permet de retracer en cas de problème. Pour cela nous utilisons ce que l’on appelle des réservations, c’est-à-dire que nous lions une adresse mac à une adresse IP.
- Trouver l’adresse MAC de votre client. Quelle est-elle ?
Attention : Nous cherchons l’adresse de la bonne interface…
Pour réaliser la réservation, allons dans la config de kea dans le serveur :
2) Dans la catégorie « reservations » de votre configuration du subnet réalisez une réservation
pour votre adresse mac en donnant l’IP 192.168.1.79.
« hw-address » : « <mac> »
« ip-address » : « 192.168.1.79 »
Pour vérifier le fonctionnement nous relâchons de nouveau la lease côté client et nous la
redemandons.
dhclient -r
dhclient -i eth1
¶ Ajout d'une option de DNS
DNS signifie Domain Name System. Un serveur DNS est une sorte de dictionnaire qui associe des nom de domaine à des IP (par exemple minet.net est associé à 157.159.40.103).
Dans une machine il faut définir les IP de ses DNS pour que la machine sache où aller demander la résolution de nom de domaine. A MiNET nos DHCP dans la lease renseignent les IP de nos propres DNS (ns1 et ns2) ce qui fait que nos adhérents passent directement par ces DNS pour la navigation sur internet.
Mettons en place une configuration DNS (fictif) via le DHCP !
De retour dans votre configuration kea, aller dans la section « option-data » générale déjà existante, plus haut dans la configuration.
-
Mettre en place une option « domain-name-servers » désignant « 192.168.103.54 » comme DNS.
Relâchez de nouveau la lease, redemandez la. -
Quel est le contenu de /etc/resolv.conf ? Voyez-vous l’IP de votre DNS ?
Bravo, maintenant plus qu’à créer un vrai serveur DNS… bientôt
¶ Réservation via une vue SQL
On vous a encore menti, ou presque. Nos réservations ne sont pas effectuées dans le fichier de configuration de kea, mais dans une base de données MySQL.
¶ Petit point explicatif :
Lorsqu’un adhérent ajoute un appareil sur ADH6, une IP est assignée par adh6 à cet appareil selon le vlan de l’adhérent (157.159.41.0/24 pour U1 …) et les IP disponibles. Cette IP est
donc stockée dans une table spécifique.
Kea va ensuite à chaque demande d’IP lire dans la base de données pour regarder quelle IP était prévue pour l’appareil qui demande.
Nous allons dans cette section simuler ce type de réservation.
Pour démarrer cette partie il vous faut aller dans les backup de la machine « f-dhcpserver » et restoration la backup « mysqlreservationbase ».
Nous sommes gentils donc un serveur mysql-server est déjà installé sur la machine « f-dhcpserver ».
Kea utilise une architecture particulière dans la base de données avec des tables spécifiques.
Créons dans un premier temps cette architecture dans une nouvelle base de données sql.
¶ Création de la database :
- Rentrons dans le serveur mysql :
mysql -ple password estj3 su1s 1 p3t1t 1A !!!Les commandes suivantes permettent de créer la database dhcp, de créer un user qui aura les permissions de travailler dans cette database.
CREATE DATABASE dhcp;
CREATE USER ‘dhcp’@’localhost’ IDENTIFIED BY ‘j3 su1s 1 p3t1t 1A !’;
GRANT ALL PRIVILEGES ON dhcp.* TO ‘dhcp’@’localhost’;
Pour utiliser les commandes qui vont suivre, on exécute également la commande suivante
dans le serveur mysql :
set @@global.log_bin_trust_function_creators = 1;
Il ne reste plus qu’à mettre en place l’architecture nécessaire pour kea.
Pour cela nous utiliserons le package « kea-admin » qui est déjà installé.
Quittons le serveur mysql : quit.
La commande suivante pour permettre d’introduire les tables nécessaires dans la database
dhcp que vous avez créée :
kea-admin db-init mysql -u database-user -p database-password -n database-name
- Retournons dans le serveur mysql, quelles sont les tables présentes dans la database dhcp ?
J'ai la flemme de chercher sur Stack Overflow
SHOW DATABASES;
USE dhcp;
SHOW tables;
- Créeons une table vm qui contiendra la liste des adresses mac et les adresses IP liées pour simuler le fonctionnement réel des réservations à MiNET.
CREATE TABLE vm (
id bigint(10) primary key auto_increment not null,
ip varchar(20) not null,
mac varchar(20) not null
);
- Introduisez votre résérvation.
insert into vm(mac,ip) values(‘adressemac’, ‘192.168.1.56’);
-
Configurez kea pour qu’il cesse de distribuer des IP dynamiquement via sa pool et qu’il lise dans la DB. Vous devriez trouver les lignes correspondantes à la DB dans la config, commentées.
-
Dans la configuration de la DB ajoutez « readonly : true » car kea n’a pas besoin d’écrire mais juste des lire les données. Cela supprime des tests amenant à des erreurs à chaque redémarrage de kea.
-
Supprimez la pool présente dans la configuration « subnet4 » que vous aviez réalisé précédemment.
-
Supprimez la réservation que vous avez réalisé en dur dans la config.
-
Faites une release puis une demande de lease, obtenez-vous une IP ?
Pourquoi ?
Eh… non et c’est normal ! Kea ne lit pas dans la table que vous venez de créer, donc pour le moment elle n’est pas bien utile… Par contre nous savons que kea lit dans la table « hosts » qui a une structure spécifique.L’astuce alors est de créer une vue SQL qui a exactement les mêmes colonnes que la table hosts mais dont certaines colonnes sont issues de la table VM.
Définition de vue sql :
"Une vue est une table virtuelle, c'est-à-dire dont les données ne sont pas stockées dans une
table de la base de données, et dans laquelle il est possible de rassembler des informations
provenant de plusieurs tables."
-
Donnez la structure de la table hosts à l’heure actuelle. Les colonnes qui nous intéressent sont dhcp_identifier et ipv4_address et nous souhaitons que ces colonnes soient remplies avec les données de la table vm.
-
Supprimons la table hosts.
SET foreign_key_checks = 0;
Drop table hosts;
- Créons maintenant la vue, à vous de compléter la commande !
CREATE VIEW hosts AS
select vm.id AS 'host_id',
unhex(REPLACE(…,':','')) AS 'dhcp_identifier',
0 AS 'dhcp_identifier_type',
1 AS 'dhcp4_subnet_id',
1 AS 'dhcp6_subnet_id',
inet_aton(…) AS 'ipv4_address',
NULL AS 'hostname',
"ALL" AS 'dhcp4_client_classes',
NULL AS 'dhcp6_client_classes',
NULL AS 'dhcp4_next_server',
NULL AS 'dhcp4_server_hostname',
NULL AS 'dhcp4_boot_file_name',
NULL AS 'user_context',
NULL AS 'auth_key'
FROM vm
WHERE … LIKE "%.%.%.%";
SET foreign_key_checks = 1;
- Que contient la vue ? Si vous avez bien fait votre travail, vous devriez voir une ligne renseignée.
Note : les colonnes ipv4_address et dhcp_identifier ont des formats particuliers et les données
que vous avez entré dans la table vm sont converties pour y correspondre, d’où les fonctions
« inet_aton » et « unhex ».
Testez de nouveau l’attribution d’IP.
Bravo ! Vous avez configuré votre premier serveur kea avec réservation SQL 