Surcharger le DNS utilisé par dhclient

La configuration DNS sous UNIX est située dans le fichier /etc/resolv.conf.

Dans une configuration classique pour un serveur ce fichier est statique. Il est créé lors de la première installation en se référant au paramétrage spécifié dans l’installeur.

Pour une configuration dynamique en DHCP, généralement un client, c’est le binaire dhclient qui va s’occuper de modifier les lignes de configuration afin de mettre les DNS reçus via DNS ainsi que les zones de recherches et suffixe DNS.

Le principal problème que nous allons essayer de résoudre ici est essentiellement une problématique de type cloud. Continuer à lire

Relai DHCP sous Debian

Le relai DHCP permet d’isoler son serveur DHCP autoritaire du réseau de ses clients.

Que le serveur DHCP soit sous UNIX ou sur un OS propriétaire (ce qui est dommage), le relai DHCP va permettre aux clients d’interroger un DHCP en utilisant ce relai comme proxy.

Un relai DHCP est un outil très simple utilisant un système ajoutant le réseau source (connu par le relai DHCP) et un nombre de sauts (utile si vous souhaitez chaîner plusieurs relais DHCP, mais non recommandé en terme de latence).

Installation

Installez le paquet isc-dhcp-relay.

Configuration

Bien que le prompt isc-dhcp-relay vous offre la possibilité de configurer directement le service, nous allons le configurer manuellement. Ouvrez le fichier /etc/default/isc-dhcp-relay

Editez ensuite la ligne SERVERS afin d’ajouter une liste de serveurs DHCP autoritaires et la ligne INTERFACES afin de spécifier les interfaces sur lesquelles votre DHCP va écouter.

Relancez ensuite le service isc-dhcp-relay

UCARP

 Introduction

UCARP est une implémentation alternative au protocole VRRP de FreeBSD et CISCO. Il permet de mettre en place un IP failover (autrement dit la redondance de service pour la haute disponibilité). De ce fait, grâce à UCARP, si vous avez un serveur redondé de votre serveur IMAP et SMTP, si le principal vient à tomber, la définition même d’UCARP permettra à votre réplicat de prendre le relai jusqu’à ce que le maître revienne à la normale.

Ce tutoriel aura pour but de définir comment mettre en place le failover. Pour la synchronisation des données, consultez les tutoriaux appropriés sur notre site ou Internet. Veuillez juste noter que si votre synchronisation est une synchronisation de type maître -> esclave et non maître <-> esclave vous risquez de perdre des données qui se retrouveraient uniquement sur le réplicat lors de la remise en service du serveur maître.

Le principe d’UCARP est le partage d’une adresse IP et adresse MAC sur le réseau. Nous allons ici étudier le principe UCARP sous Debian. Continuer à lire

Migrer des bornes lourdes en bornes légères

Le réseau évolue, se complexifiant et se centralisant, aux moyens de contrôleurs. Le WiFi est une des premières technologies à avoir évoluer afin de centraliser son intelligence autour d’un contrôleur.

Chez CISCO on retrouve une gamme de contrôleurs WLC 55XX destinés à gérer un ensemble de bornes légères.

Dans ce tutoriel nous allons migrer des bornes WiFi 1242AG de 2006 en bornes légères et les relier à un contrôleur WLC 5500 (version 7) de 2013 Continuer à lire

Comparaison de performances IPv4/IPv6

Suite à notre récent peering BGPv4 sur le réseau Renater et notre demande en IPv6, je me suis penché cet après midi sur un petit benchmark de performances. Je souhatais donc vous partager le résultat de ce test

IPv4+IPv6 comparisonGlobalement sur les BSD les performances IPv4/IPv6 sont équivalentes, même en passant par des routeurs OpenBSD (traitement soft). On remarquera néanmoins qu’un équipement CISCO (chassis 4500 de 2006) qui fait du traitement soft a de très grandes difficultés à router les paquets (2.3Mo/sec au lieu des 48Mo/sec d’IPv4).

Script PHP: envoi de commandes sur un ensemble d’équipements réseau

Suite à un désespoir aujourd’hui, à cause d’un contrôleur WiFi CISCO qui déconne mais également d’un besoin d’envoyer des commandes sur l’ensemble de notre parc de bornes WiFi, j’ai développé un script qui permet d’envoyer des commandes à un ensemble d’équipements réseau (sous peine d’avoir les mêmes logins partout).

Le script lit 2 fichiers:

  • Liste des adresses des équipements (adresse IPv4)
  • Liste des commandes à exécuter (dans l’ordre)

Ensuite pour chaque équipement il va exécuter les commandes spécifiées. Continuer à lire

Mise en place de pare-feu/routeurs hautement disponibles avec CARP et pfsync + GRE et OSPF et IPSEC

Introduction

Nous allons voir dans cette article comment mettre en place de la haute disponibilité sur pare-feu en utilisant CARP et pfsync. Ensuite nous relierons deux sites par un tunnel GRE chiffré en IPSEC.

Ce tutoriel est réalisé sous Virtualbox.

Schéma global de la solution:

Infrastructure Continuer à lire

PPTPD (Poptop)

Introduction

Les tunnels PPTP sont des tunnels qui sont intégrés nativement dans la plupart des OS depuis une dizaine d’années. S’appuyant sur PPP et ajoutant une couche d’authentification plus robuste voire du chiffrement, ils permettent aux utilisateurs distants de pouvoir se connecter à leur réseau d’entreprise. Continuer à lire

ISC-DHCP-Server: problèmes courants

Introduction

Cet article a pour but de détailler et d’aider à résoudre les problèmes courants pouvant être recontrés sur ISC-DHCP-Server (dhcpd).

Erreur « no free leases »

Cette erreur survient lorsque le DHCP ne peut pas fournir d’adresses IP, que ce soit parce que tous les baux ont été pris ou bien que votre subnet DHCP ne délivre aucune IP dynamiquement.

Pour le résoudre trois choix:

  • Augmentez la taille du réseau (changement de masque) et/ou le range d’adresses distribuables
  • Supprimez les baux DHCP inutiles dans le dhcpd.leases (dangeureux !)
  • Réduisez la durée de vie des baux (default-lease-time et max-lease-time) du subnet

Erreur « peer holds all free leases »

Cette erreur ne peut être obtenue que dans le cas d’une configuration de dhcp en failover/load-balacing. Elle signifie que l’autre DHCP a libéré tous les baux, ou n’a que des baux vides. Elle survient lorsqu’un client fait une requête DHCP sur une zone en erreur, et uniquement lorsque la zone est pleine.

Pour résoudre ce problème, surveillez bien que l’autre DHCP peut distribuer des adresses sur le réseau mentionné. En redémarrant le second DHCP, l’erreur suivante s’est produite:

Il faut vérifier 3 points:

  • Vous avez fait une erreur lors de la déclaration du subnet, l’IP n’est pas bonne
  • Vous avez oublié d’inclure le fichier de configuration du subnet
  • Votre DHCP n’écoute pas sur l’interface du subnet (netstat -an)

Bind9(named) + isc-dhcp-server: Mise à jour DNS Dynamique

Introduction

Ce tutoriel fait suite à une erreur rencontrée sur un service ISC-dhcpd OpenBSD et un service bind9 à mettre en corrélation, l’erreur d’origine était:

Dans un réseau avec adresses IP dynamiques, il est intéressant d’utiliser des noms DNS afin de retrouver les machines. Ces noms doivent évoluer avec la configuration du réseau. Il existe une mécanique interne à named (bind) et isc-dhcpd permettant de relier le DHCP et le DNS afin que les mises à jour soient faites entre les 2 services/hôtes.

Cette mécanique utilise le principe du RNDC, qui est une clé partagée, et permet ainsi d’assurer l’authentification des services entre eux.

Dans ce tutoriel nous partirons du principe que chaque machine est à la fois DHCP et DNS. Continuer à lire

Configurer 802.1X sur un port

Introduction

Il est de plus en plus courant dans le monde de l’entreprise d’utiliser du 802.1X afin de sécuriser son réseau et le dynamiser. Cela nécessite une légère augmentation de la bande passante et un serveur dédié avec un CPU robuste et des accès aux données rapides. Nous allons voir rapidement comment mettre en place du 802.1X sur un switch CISCO Continuer à lire

Management de stack CISCO

Introduction

Je vous propose ici d’apprendre les rudiments du stacking. Nous étudierons ici comment bien remplacer un switch dans un stack. Pour l’ajout et la suppression nous y reviendrons plus tard.

Un stack de switch consiste à mettre en cascade les switch via le connecteur dédié, situé à l’arrière de l’équipement. Il existe deux types de stack CISCO, le stackwise, présent sur les séries 3750, et le flexstack, présent sur les séries 2960. La techonologie stackwise permet d’intégrer jusqu’à 9 switches dans la pile tandis que flexstack n’en permet que 5. Continuer à lire