Articles avec les mots clés ’dhcp’
DHCP Failover Auto Config Sync sous Windows Server 2012
Dans Windows Server 2012, le service DHCP peut être configuré pour fournir une haute disponibilité. Les baux d’adresses IP d’une étendue sont ainsi synchronisés entre deux serveurs DHCP en relation de basculement. Cependant, lorsque l’administrateur effectue des modifications dans la configuration d’une étendue, celle-ci n’est pas répliquée sur l’autre serveur DHCP.
L’outil DHCP Failover Auto Config Sync écrit en Windows PowerShell, permet de réaliser cette réplication automatiquement.
La documentation que je vous propose, présente cette problématique et met en œuvre l’outil DHCP Failover Auto Config Sync (DFACS) à travers un atelier pratique.
Télécharger la documentation sur DHCP Failover Auto Config Sync [1.33 Mo]
Problème de serveur DNS avec Windows 7 et dhcp (dans un cas bien particulier)
Imaginons un serveur isc dhcpd configuré de la sorte (centos 6.4) :
...
subnet 192.168.0.0 netmask 255.255.255.0 {
option domain-name-servers 192.168.0.1;
option routers 192.168.0.254;
authoritative;
deny client-updates;
deny
pool {
allow unknown-clients;
range 192.168.0.100 192.168.0.200;
}
host monposte.be-root.com {
option domain-name-servers 192.168.0.2;
hardware ethernet xx:xx:xx:xx:xx:xx;
fixed-address 192.168.0.10;
}
}
Symptômes :
Sur la machine monposte :
si l’on boote sur un livecd (ubuntu), nous obtenons comme paramètres via le dhcp 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.2 (les paramètres sont donc ceux attendus)
si l’on boote sur windows 7, nous obtenons comme paramètres via le dhcp 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.1 (le serveur dns n’est pas celui déclaré dans la section host. Il s’agit du dns déclaré dans la section subnet).
Si sous windows 7, nous effectuons un ipconfig /renew alors les parametres sont 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.2. Cependant, au redémarrage suivant, les paramètres sont de nouveau 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.1.
Analyse :
Si l’on sniffe l’echange entre le poste windows 7 et le serveur dhcp, on remarque :
-1 requête DHCP Request de la part du client
-1 réponse DHCP ACK de la part du serveur DHCP lui fournissant les paramètres 192.168.0.10/255.255.255.0 et le serveur DNS 192.168.0.2 (donc corrects).
-1 requête DHCP Inform de la part du client précisant sont adresse 192.168.0.10 et demandant les paramètres subnet mask/domain name/ router/ domain name server/…/private-proxy autodiscovery
-1 réponse DHCP ACK de la part du serveur dhcp lui fournissant la passerelle 192.168.0.254 et le dns 192.168.0.1 (donc erronés).
– …
A priori, tant que le client ne reçoit pas de réponses valides pour la recherche automatique de proxy, il continue a faire des requêtes DHCPInform toutes les 100 secondes.
La norme concernant les requêtes DCHP Inform stipule :
The server SHOULD check the network address in a DHCPINFORM message for consistency, but MUST NOT check for an existing lease.
Ainsi, le serveur dhcpd n’utilise pas les informations de son fichier de leases pour répondre avec les même paramètres que ceux envoyés lors du DHCP Request mais parcours le fichier de configuration.
Comme l’adresse ip indiquée dans la requête DHCP Inform fait partie du subnet 192.168.0.0, il répond avec les paramètres globaux de la zone.
Résolution :
On peut contourner de problème de plusieurs façons :
- Virer le paramètre authoritative dans le subnet. Le serveur ne répondra plus aux requêtes DHCP Inform … (moyen)
- Supprimer les déclarations globales de serveurs dns et les mettre par hôte/pool. (long et pas très pratique).
- Si l’on n’utilise pas la fonctionnalité de découverte automatique de proxy (wpad) : sur le client Windows7, lancer l’éditeur de base de registres.
Sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\Identifiant-de-l-interface , créer une clé nommée UseInform de type DWORD. Initialiser à la valeur 0.
Ainsi le client Windows 7 ne fera plus de requêtes DHCP Inform et donc conservera les informations retournées par lors de la première transaction DHCP Request.
Mise en place serveur DHCP couplé à un annuaire LDAP sous Centos 6
Dans cet article, nous allons voir comment faire en sorte qu’un serveur dhcp utilise une configuration stockée dans un annuaire ldap plutôt que dans des fichiers de configuration statiques.
Le serveur utilisé tourne sous Centos 6. Un minimum de connaissance d’openldap et dhcpds est requis puisque nous ne détaillerons pas les commandes utilisées.
Tout d’abord, nous allons procéder à l’installation des paquets openldap et dhcpd :
yum install dhcp openldap-servers
Le paquet dhcp fourni par la distribution contient nativement tout le nécessaire pour coupler le serveur à un annuaire LDAP.
Dans le fichier /etc/openldap/slapd.conf, rajoutons ces lignes :
include /etc/openldap/schema/dhcp.schema ... index dhcpHWAddress eq index dhcpClassData eq
Dans notre exemple, le fichier slapd.conf est configuré pour gérer l’arbre dc=be-root,dc=com.
Dans le fichier /etc/dhcpd/dhcpd.conf, supprimons tout le contenu existant et remplaçons le par :
ldap-server "localhost"; ldap-port 389; ldap-username "uid=dhcpdaemon,dc=be-root,dc=com"; ldap-password "blahblah"; ldap-base-dn "dc=be-root,dc=com"; ldap-method dynamic;
Voici le fichier LDIF utilisé pour créer la racine de l’annuaire LDIF ainsi que le compte uid=dhcpdaemon
utilisé par le serveur dhcp pour interroger la base :
dn: dc=be-root,dc=com
objectclass: top
objectclass: organization
objectclass: dcObject
structuralObjectclass: organization
dc: be-root
o: Annuaire
dn: uid=dhcpdaemon,dc=be-root,dc=com
objectclass: top
objectclass: inetOrgPerson
objectclass: Person
cn: Utilisateur pour daemon DHCP
givenName: dhcpdaemon
sn: dhcpdaemon
uid: dhcpdaemon
userPassword: {CRYPT}K3nDIt87oiYnA
Bien évidemment, ajustez les ACLs dans le fichier slapd.conf afin que l’utilisateur dhcpdaemon ait des droits suffisants.
Nous allons ensuite déclarer dans notre fichier LDIF une entrée permettant de déclarer un serveur dhcp ainsi que la configuration globale correspondante :
dn: cn=hostname_serveur_dhcp, dc=be-root, dc=com objectClass: top objectClass: dhcpServer cn: hostname_serveur_dhcp.be-root.com dhcpServiceDN: cn=configdhcp, dc=be-root, dc=com dn: cn=configdhcp, dc=be-root, dc=com cn: Configuration du serveur DHCP objectClass: top objectClass: dhcpService objectClass: dhcpOptions dhcpStatements: ddns-update-style none dhcpStatements: default-lease-time 3600 dhcpStatements: max-lease-time 7200 dhcpOption: domain-name-servers 10.0.2.2 dhcpPrimaryDN: cn=hostname_serveur_dhcp, dc=be-root, dc=com
Nous allons ensuite déclarer le subnet 10.0.2.0 comportant un pool allant de 10.0.2.10 à 10.0.2.20 dans le fichier LDIF :
dn: cn=10.0.2.0, cn=configdhcp, dc=be-root, dc=com cn: 10.0.2.0 objectClass: top objectClass: dhcpSubnet objectClass: dhcpOptions dhcpOption: routers 10.0.2.2 dhcpOption: subnet-mask 255.255.255.0 dhcpOption: broadcast-address 10.0.2.255 dhcpNetMask: 24 dhcpRange: 10.0.2.10 10.0.2.20
Nous pouvons également ajouter de l’adressage statique :
dn: cn=monpc, cn=configdhcp, dc=be-root, dc=com objectClass: top objectClass: dhcpHost cn: monpc dhcpHWAddress: ethernet 08:00:27:9B:3A:4D dhcpStatements: fixed-address 10.0.2.100
Bien évidemment, le fichier ldif doit être cohérent par rapport au fichier slapd.conf.
Il nous reste maintenant à utiliser la commande slapadd pour injecter notre fichier LDIF dans openldap et ensuite démarrer les services :
service slapd start service dhcpd start
Vérifiez les logs pour vous assurer du bon fonctionnement des services.
De plus, le serveur dhcpd-4.1.1 empaqueté avec la distribution Centos 6 fourni un script perl présent sous /usr/share/docs/dhcp-4.1.1/dhcpd-conf-to-ldap permettant de convertir un fichier dhcpd.conf existant au format ldif. La syntaxe est la suivante : perl /usr/share/docs/dhcp-4.1.1/dhcpd-conf-to-ldap < /etc/dhcpd/dhcpd.conf > output.ldif