Quelques outils de diagnostic DNS

Le DNS (Domain Name System) est un service exceptionnellement critique de n’importe quel réseau et de l’Internet. Cette semaine, j’ai eu l’occasion de plancher sur de nombreuses problématiques DNS dans le cadre de la fusion de deux serveurs DNS assez conséquents.

Dans cet article, je parlerais uniquement de BIND car il s’agit de la référence en terme de serveurs DNS. Je supposerais également que vous utilisez Linux. Et oui, BIND ça fonctionne également sous Windows. Je l’ai même déjà en production sur du Windows… Cela fait un petit pincement au coeur je vous assure.

dig

Le premier outil totalement indispensable est la commande dig. Elle permet d’interroger sélectivement des serveurs DNS. De plus, elle affiche une bonne quantité d’information quant à la requête effectuée. Cette commande sera donc particulièrement utile pour vérifier le bon fonctionnement de votre serveur DNS.

antoine@ks:~$ dig @ns0.infoclip.fr www.infoclip.fr
; <<>> DiG 9.3.4-P1.2 <<>> @ns0.infoclip.fr www.infoclip.fr
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47195
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; QUESTION SECTION:
;www.infoclip.fr.               IN      A
;; ANSWER SECTION:
www.infoclip.fr.        86400   IN      A       217.25.177.18
;; AUTHORITY SECTION:
infoclip.fr.            86400   IN      NS      ns0.infoclip.fr.
infoclip.fr.            86400   IN      NS      ns1.infoclip.fr.
;; ADDITIONAL SECTION:
ns0.infoclip.fr.        86400   IN      A       217.25.176.28
ns0.infoclip.fr.        86400   IN      AAAA    2001:1650:0:1001::2
ns1.infoclip.fr.        86400   IN      A       194.29.206.67
;; Query time: 5 msec
;; SERVER: 217.25.176.28#53(217.25.176.28)
;; WHEN: Fri Feb 12 10:23:54 2010
;; MSG SIZE  rcvd: 145

host

La commande host est un outil particulièrement utile pour créer des scripts utilisant des informations DNS. Elle permet d’afficher très simplement des informations en rapport avec un nom de domaine telles que les serveurs DNS d’autorité, les MX ou le SOA.

antoine@ks:~$ host -t MX lemonde.fr

lemonde.fr mail is handled by 5 smtp0.lemonde.fr.

lemonde.fr mail is handled by 10 smtp1.lemonde.fr.

antoine@ks:~$ host -t ns lemonde.fr

lemonde.fr name server nsc.bookmyname.com.

lemonde.fr name server nsa.bookmyname.com.

lemonde.fr name server nsb.bookmyname.com.

antoine@ks:~$ host -t soa lemonde.fr

lemonde.fr has SOA record nsa.bookmyname.com. hostmaster.bookmyname.com. 1265963399 43200 3600 604800 3600

named-checkconf

L’outil named-checkconf est fourni avec BIND par défaut mais semble relativement peu connu. Cet utilitaire permet de vérifier la syntaxe d’un fichier de configuration. En sachant que BIND est assez peu tolérant des erreurs, cet outil vous évitera quelques mauvaises surprises.

named-checkconf /etc/named.conf

named-checkzone

Une fois que la configuration de BIND est correcte, il est intéressant de vérifier les zones. Je pense que cette vérification doit être périodique car les erreurs passent facilement inaperçue dans les zones. Cet utilitaire va vérifier la syntaxe de vos zones.

named-checkzone domaine.tld /var/named/domaine.tld

Au final, je pense que ces quelques outils devraient vous permettre de pouvoir mieux diagnostiquer d’éventuels soucis de résolutions de noms de domaine.

Définition du « Cloud Computing »

Je profite de cette journée de vacances pour prendre le temps de blogger sur un sujet d’actualité mais surtout particulièrement à la mode. Certains préfèreront le terme « trendy » mais je trouve que ca fait peut être un peu beaucoup pour une technique informatique. J’aurais l’occasion de revenir sur le sujet du cloud computing plus d’une fois. Je ne ferais cependant pas une série d’articles liés mais différents aspects à visée plus ou moins objective.

L’objectif de cet article est de présenter les différentes définitions du cloud computing que l’on peut trouver sur le web et de les comparer. Afin d’avoir un premier élément de définition, nous pouvons nous rendre sur Wikipedia qui définit le cloud computing comme suit.

L’informatique dans les nuages (en anglais, cloud computing) est un concept majeur faisant référence à l’utilisation de la mémoire et des capacités de calcul des ordinateurs et des serveurs répartis dans le monde entier et liés par un réseau, tel Internet (principe de la grille informatique).

Tout d’abord, Wikipedia France traduit cloud computing par le terme informatique dans les nuages. Cette traduction est une traduction très littérale qui, selon moi, s’adapte relativement mal en Français. A défaut d’une meilleure traduction, je continuerais à utiliser le terme anglais beaucoup plus répandu.

Ensuite, intéressons-nous à la définition proposée par Wikipedia. Cette définition ressemble beaucoup plus à un slogan marketing qu’à une véritable définition d’un concept informatique. Elle commence par préciser qu’il s’agit d’un concept majeur. Cette affirmation est soutenue par un rapport Gartner cité en bas de page. Sans questionner le point de vue de ces analystes, cette définition s’attache en premier lieu à définir la taille de ce concept avant même d’avoir précisé de quoi il s’agissait.

De plus, l’utilisation de capacités de calcul et de mémoire d’ordinateurs via Internet est loin d’être quelque chose de récent ni de propre au cloud computing. Une application web est une utilisation de capacité de calcul via Internet et ce n’est pas pour autant qu’il s’agit d’une nouveauté ou bien même de cloud computing. La fin de la définition fait allusion au grid computing qui est une technique bien différente du cloud computing du fait qu’elle soit conçue pour effectuer du calcul distribué.

Nous pouvon ensuite nous tourner vers la définition proposée par Wikipedia en Anglais en espérant obtenir un résultat plus probant.

In concept, it is a paradigm shift whereby details are abstracted from the users who no longer need knowledge of, expertise in, or control over the technology infrastructure « in the cloud » that supports them. Cloud computing describes a new supplement, consumption and delivery model for IT services based on Internet, and it typically involves the provision of dynamically scalable and often virtualized resources as a service over the Internet.

Pour les francophones, voici la traduction « best effort » que je propose de cette définition.

Conceptuellement, il s’agit d’un changement fondamental se traduisant par une abstraction de l’infrastructure technologique désormais transposée « dans les nuages ». Ce changement fondamental implique que les utilisateurs n’aient plus besoin d’une connaissance ou d’une maitrise de l’infrastructure technologique. Le cloud computing est un technique basée sur un nouveau modèle de consommation et d’utilisation des TIC basées sur Internet. Typiquement, cela inclut la mise à disposition de ressources extensible à la volée et, souvent, virtualisées par le biais d’Internet.

Cette définition semble convenir bien mieux à l’idée du cloud computing qui est traitée régulièrement sur Internet. Je trouve que cela décrit beaucoup mieux le concept et la pratique du cloud computing. Nous remarquons également que la page Wikipedia en Anglais sur le cloud computing précise bien que ce n’est pas la même chose que le grid computing. Promis, je ne l’avais pas vu avant.

Au final, la définition du cloud computing est relativement compliquée à poser étant donné la jeunesse de la technique. De plus, le succès de cette technique incite tous les vendeurs de solutions informatiques à se mettre à l’heure du cloud computing moyennant une définition approximative de ce concept. Dans un prochain article, nous essayerons de trouver une définition plus pratique du cloud computing.

Cloisonnement d’un réseau à l’aide de VRF : Mise en place

stepfinal2Ce billet fait suite au premier billet traitant du sujet du cloisonnement d’un réseau à l’aide de VRF. Le premier billet avait pour objectif dans présenter la plateforme d’expérimentation que nous avons mis en place. Dans ce billet, nous allons nous intéresser à la configuration basique des équipements Cisco que nous avions à notre disposition. Dans un troisième et dernier billet, je présenterais la configuration du BGP permettant le propagation de routes sélectives entre les différentes VRF.

A titre de rappel, je vous renvois vers le précédent billet pour le schéma topologique qui vous permettra de comprendre plus facilement les configurations effectuées ici.

Configuration basique

Afin de pouvoir se retrouver plus facilement parmi tous nos équipements, nous allons paramétrer le nom d’hôte de nos différents équipements conformément au schéma.

ROUTER(config)# hostname ROUTEUR1

ROUTER(config)# hostname ROUTEUR2

Nous allons ensuite configurer les différentes interfaces IP de notre routeur de tête précédemment nommé ROUTEUR1.

ROUTEUR1(config)#interface Fa0/0

ROUTEUR1(config-if)#no ip address

ROUTEUR1(config-if)#shutdown

ROUTEUR1(config-if)#interface Fa0/1

ROUTEUR1(config-if)# ip address 192.168.100.1 255.255.255.0

ROUTEUR1(config-if)#exit

Nous allons ensuite configurer les routes statiques vers les réseaux raccordés directement sur notre second routeur. Il serait possible d’utiliser un protocole de routage mais par simplicité, nous avons choisi d’implémenter des routes statiques.

ROUTEUR1(config)# ip classless

ROUTEUR1(config)# ip route 192.168.0.101.0 255.255.255.0 192.168.100.2

ROUTEUR1(config)# ip route 192.168.0.102.0 255.255.255.0 192.168.100.2

ROUTEUR1(config)# ip route 192.168.0.103.0 255.255.255.0 192.168.100.2

La configuration de ce premier routeur se résume à ces commandes simples. Ce routeur est essentiellement un routeur témoin qui nous permettra de valider nos tests.

Configuration des VRF

Nous allons ensuite nous attaquer à la configuration des VRF sur notre second routeur. Pour rappel, les VRF sont des instances de tables de routage. Nous allons créer une VRF par zone de notre schéma. Nous en avons donc distingué 5 : client1, client2, prod et interco. Chaque zone aura donc sa propre VRF ce qui nous permettra d’avoir un cloisonnement finement paramétrable.

Tout d’abord, nous allons donc créer les VRF. Nous attribuerons un « Route Distinguisher » ou RD à chaque VRF. Un RD est un identifiant unique permettant d’identifier les routes associées à une VRF. Nous nous baserons sur ce critère lorsque nous ferons de la propagation de routes entre les différentes VRF.

ROUTEUR2(config)# ip vrf client1

ROUTEUR2(config-vrf)# rd 200:1

ROUTEUR2(config)# ip vrf client2

ROUTEUR2(config-vrf)# rd 300:1

ROUTEUR2(config)# ip vrf prod

ROUTEUR2(config-vrf)# rd 100:1

ROUTEUR2(config)# ip vrf interco

ROUTEUR2(config-vrf)# rd 400:1

Une fois toutes les VRF créées, nous allons configurer les différentes interfaces selon le schéma défini préalablement.

ROUTEUR2(config)# interface Fa0/0

ROUTEUR2(config-if)# description OUTBOUND

ROUTEUR2(config-if)# ip vrf forwarding interco

ROUTEUR2(config-if)# ip address 192.168.100.2 255.255.255.0

ROUTEUR2(config)# interface Fa0/1

ROUTEUR2(config-if)# description PROD

ROUTEUR2(config-if)# ip vrf forwarding prod

ROUTEUR2(config-if)# ip address 192.168.101.1 255.255.255.0

ROUTEUR2(config)# interface Fa1/0

ROUTEUR2(config-if)# description CLIENT1

ROUTEUR2(config-if)# ip vrf forwarding client1

ROUTEUR2(config-if)# ip address 192.168.102.1 255.255.255.0

ROUTEUR2(config)# interface Fa2/0

ROUTEUR2(config-if)# description CLIENT2

ROUTEUR2(config-if)# ip vrf forwarding client2

ROUTEUR2(config-if)# ip address 192.168.103.1 255.255.255.0

ROUTEUR2(config)# ip route 0.0.0.0 0.0.0.0 192.168.100.1

Nous avons donc configuré les différentes interfaces, les différentes VRF ainsi que l’association des VRF aux interfaces. Si nous n’avions pas eu suffisamment de ports physiques, il vous est tout à fait possible de créer des sous-interfaces 802.1Q qui fonctionneront de manière identiques aux interfaces physiques.

Dans le prochain billet, je détaillerais la configuration du protocole de routage afin de redistribuer les routes de manière sélective parmi toutes nos VRF.

Articles de la série

Configurer un switch Cisco sous MacOS

CISCO LOGOCela fait désormais un an que je suis utilisateur assidu de MacOS. J’ai toujours réussi à faire ce que je faisais sur PC sur MacOS à quelques exceptions près. Ces deux exceptions sont les jeux 3D spécifiques Windows (Flight Simulator entre autre) et l’administration d’un équipement réseau via port série.

Les MacBook Pro ne sont pas dotés d’un port série. J’ai donc du commander un adaptateur USB-Série sur Ebay pour une somme tout à fait correcte dont je ne me souviens plus. On en trouve actuellement pour moins d’une dizaine d’euros. Vous allez cependant devoir vous armer de patience car ils sont le plus souvent expédiés de Chine. Voici à quoi ressemble ce fameux adaptateur.

usbserie

Il fonctionne parfaitement sous Ubuntu. Je n’ai eu aucune difficulté particulière. Une simple recherche Google et l’installation d’un driver a suffit pour le faire fonctionner. Je souhaitais cependant le faire fonctionner sur mon MacBook car il est quand même bien plus pratique de déplacer un portable qu’une tour.

La première action à effectuer est de récupérer le pilote adapté à l’adaptateur que vous avez acheté. Le problème est qu’il n’y a strictement rien marqué dessus. Ayant précédemment fait l’installation sous Ubuntu, j’avais réussi à déterminer qu’il s’agissait d’un PL2303. Ces adaptateurs semblent très répandus. Il y a donc beaucoup de chances que si le votre ressemble au mien, ce soit la même chose. Vous trouverez le pilote du PL2303 sur le site d’Apple. Vous allez devoir redémarrer votre poste pour finaliser l’installation du pilote.

Ensuite, il va falloir se connecter au périphérique que vous avez raccordé à l’autre bout de votre câble série. Sur Windows, vous auriez eu HyperTerminal qui remplit très bien ses fonctions. Sur MacOS, il est visiblement possible de faire fonctionner Minicom. Je n’ai pas du tout réussi… Fink et apt-get n’ont pas réussi à le trouver dans leurs dépôts. Je me suis donc lancé dans l’utilisation de screen. Dans mon cas, mon adaptateur était reconnu sous le nom /dev/cu.PL2303-00002006.

Il va falloir aller configurer les paramètres du port série du système. Dans le fichier /etc/gettytab, vous devriez trouver des lignes commencant par « serial. « . Effacez (ou commentez) toutes celles ne contenant pas 9600. Sauvegardez le fichier et exécuter la commande suivante :

stty -f /dev/cu.serial

Si la première ligne de la réponse est « speed 9600 baud; », votre port série est bien configuré. Vous pouvez ensuite accéder au périphérique en exécutant la commande suivante :

screen /dev/cu.PL2303-00002006

Vous devriez pouvoir accéder à votre périphérique. Une fois que vous aurez fini la configuration, vous pouvez quitter le screen en tapant « Cmd A » puis « Cmd . ».

Je pense que ce tutoriel devrait être utile à quelques personnes car cette configuration n’est pas forcément aisée à faire. Je me suis aidé d’un sujet sur le site d’Apple et d’un tutoriel du site MacOSHints.

Cloisonnement d’un réseau à l’aide de VRF : Introduction

stepfinal2Je vais commencer une nouvelle série d’article plus orientée vers le réseau. Je n’ai eu que relativement peu d’occasions de parler de réseau sur ce blog mais je vais me rattraper quelque peu. Cette série devrait comporter 3 articles voire peut être un peu plus, en fonction de mon humeur. Elle est le résultat d’une journée d’expérimentation effectuée avec un collègue dans le cadre de mon stage. Dans ce billet d’introduction, je vais présenter l’objectif de l’expérimentation, le matériel utilisé et la topologie.

La problématique

Lorsque nous nous sommes lancés dans ces expériences, nous avions un objectif bien précis correspondant à la réalité d’une architecture actuellement en production. La problématique était d’isoler au niveau IP plusieurs clients pouvant potentiellement avoir des plages d’IP similaires. Plus concrètement, l’objectif était d’isoler chaque client dans sa « bulle de routage » afin de pouvoir avoir une plus grande liberté dans l’évolution de l’architecture et dans l’intégration de nouveaux clients.

Nous savions déjà qu’il était possible de résoudre le problème d’isolation par le biais des VRF de Cisco. Pour rappel, une VRF est une « bulle de routage » spécifique à un groupe de ports. Typiquement, une VRF correspond à un client spécifique. La véritable difficulté venait du fait que nous souhaitions également qu’il soit possible de communiquer de manière sélective entre les différentes VRF.

Le matériel utilisé

Afin de pouvoir tester la mise en place de cette idée, nous avons ressorti des équipements Cisco qui se trouvaient fortuitement sur notre chemin. Ce jour là, notre chemin a rencontré deux Cisco 7204 VXR ainsi que deux Cisco 2970G. Chaque 7204 VXR était doté d’une carte de supervision avec 2 ports 100Mbit/s ainsi que d’un module 1 interface 100Mbit/s supplémentaire. Nous avons donc mélangé tout ce matériel pour faire deux routeurs différents : le « Routeur 1  » sans module supplémentaire et le « Routeur 2  » avec les deux modules supplémentaires.

Voici une petite photo du montage que nous avons effectué.

matosLe « Routeur 1  » était le routeur du haut et le « Routeur 2  » était le routeur du bas. Au niveau des switchs, nous n’avons utilisé que celui du bas. Les ports 1 et 2 servaient pour le réseau « Interco ». Les ports 13 à 16 étaient le VLAN de Prod. Les ports 17 à 20 étaient le VLAN Client 1. Les ports 21 à 24 étaient les VLAN Client 2. Le câble permettait de relier le PC de test.

Topologie logique

Le schéma suivant représente la topologie logique que nous avons mis en place.

SchemaGlobalSmall

Le « Routeur 1  » est le routeur qui pourrait faire office de routeur de sortie vers Internet. La route par défaut de notre réseau pointera sur lui. Le « Routeur 2  » est le routeur « coeur » qui arbitrera toutes les VRF et les échanges de routes. Les trois switch du bas du schéma sont les différents LAN de nos clients. L’objectif sera de faire communiquer les LAN client avec le routeur 1 et le LAN de Prod.

Au final, cet article avait pour objectif de vous présenter la topologie et la problématique. Le prochain article s’attachera  la configuration des équipements et la mise en place des VRF.

Articles de la série

Livre sur le High Performance Computing

Je souhaite partager avec vous une petite trouvaille que j’ai faite dans ma boite mail ce matin. J’ai plus l’habitude de parler de virtualisation et de sécurité sur ce blog mais je vais également avoir l’occasion de vous parler de sujets différents.

Sun met à disposition sur son site Internet un ebook gratuit de la série « For Dummies » traduites en français par « pour les nuls » sur le « High Performance Computing » ou HPC. Mais qu’est ce que le HPC me diriez-vous ? Le HPC se traduit en Français par « Calcul à Haute Performance ». Il s’agit du domaine de l’informatique qui traite habituellement des superordinateurs dont l’objectif est d’effectuer des calculs massivement parallèles. On connait le HPC à travers les superordinateurs Cray ou Deep Blue d’IBM qui avait battu le champion du monde d’échecs.

hpcdummies

Vous pouvez vous procurer cet ebook gratuitement sur le site de Sun en cliquant ici.

Ce livre fait un tour d’horizon des technologies de HPC et tente d’expliquer comment ces technologies fonctionnent. Je ne l’ai pas encore lu en intégralité mais le peu que j’en ai lu est particulièrement intéressant. Ce livre est légèrement orienté vers les technologies Sun et AMD mais ce n’est pas systématique. Si vous n’êtes pas anglophone, c’est le moment ou jamais de s’y mettre.