topblog Ivoire blogs

mercredi, 16 mai 2012

CABLAGE RESEAU

 

 

·

 

1ère partie : le matériel


Préambule :

Le matériel dépend du prix que l'on est prêt à consacrer à l'opération et de la nature (volant ou fixe) du câblage que l'on compte réaliser.

 

Après avoir opté pour le coaxial en 1994 parce que c'était ce qu'il y avait de moins cher à mettre en oeuvre (pas besoin de concentrateur (hub), j'ai agrandi avec un hub en 1999 contraint et forcé par l'arrivée d'un modem-câble à la maison, pour l'accès internet. Rapidement, j'ai converti les machines les plus proches au RJ-45, ce qui ne m'a coûté que le câble car toutes mes anciennes cartes réseaux étaient des cartes duo (BNC/RJ-45) ou combo (AUI/BNC/RJ-45). En effet la fragilité du coaxial (essentiellement à cause des raccordements sertis) finissait par me donner de l'urticaire chaque fois qu'il fallait pourchasser la panne à travers le bureau et les chambres équipées.

Maintenant, j'en ai assez de me prendre les pieds dans les fils qui traînent partout (photo ci-contre) et j'ai donc décidé de câbler ma maison, le plus proprement possible

Evidemment, il existe tout un tas de situations intermédiaires entre les fils qui traînent partout et le câblage radical de la maison. Mettons simplement cela sur le compte de l'âge. De toute façon, ma maison est un vrai fatras et le restera toujours. Disons que, à partir de maintenant, le réseau n'y sera pour rien.

 

Inventaire d'une partie du matériel mis en oeuvre

 

Connecteur RJ-45 (parfois appelé plug RJ-45)

Embout protecteur (facultatif)

Le câble lui-même, ici en carton-dévidoir. La norme, elle, voudrait qu'on utilise uniquement du câble en touret de façon qu'il n'y ait aucun risque de torsion du câble lors de la pose. Le câble doit êtr de catégorie 5 (au moins). J'ai choisi le moins cher, donc non écranté (UTP= non blindé). Il est évident que cela impose un environnement totalement exempt de perturbations électromagnétiques. Cela ne me pose aucun problème en 10 Mb. Pour être tranquille, vous pouvez prendre du câble FTP.

La pince à sertir (indispensable). La pince ci-contre est une pince universelle. Coûteuse, elle peut-être remplacée avec profit par une pince RJ-45 aux alentours de 100-120 F en entrée de gamme.

Pince universelle à compléter avec les paires de machoires utilisées (dans notre cas, il faudra du RJ-45)

Prise murale double et ses accessoires, serre-câble, vis, collant double face, plaquettes signalétiques et notice de montage.

Vue des deux prises RJ-45, volets fermés

Ouverture d'un volet montrant les contacts

Prise double vue de l'intérieur

Code des couleurs, au niveau des contacts auto-dénudants, correspondant aux normes EIA/TIA 568A et 568B. Vous pourrez vérifier la norme 568B avec le tableau fourni dans la section suivante. On peut noter que la différence entre les deux consiste en une permutation des paires 1 et 2 (fils 1-2 et 3-6).

 

fabriquer un câble RJ-45/RJ-45

 

 

 

 

Sertir votre premier connecteur

 

Avant toute chose, si vous avez choisi de mettre des embouts protecteurs, enfilez cet embout sur le câble, partie évasée vers l'extrémité du câble. Si vous oubliez pour le premier vous pouvez encore l'enfiler dans l'autre sens par l'autre extrémité mais si vous oubliez le second alors que la première prise est sertie, alors c'est trop tard. Certains embouts maintenant peuvent se poser après coup car ils sont munis d'une charnière et de clips du cotés opposé pour les refermer ; c'est bien pour les distraits.

 

Si vous n'avez pas choisi l'option coûteuse, alors vous n'avez pas d'outil à dégainer les câbles. Vous pouvez agir de la façon suivante. Commencer à couper la gaine du câble avec précaution (j'utilise personnellement une paire de ciseaux pointus dont j'introduis une des pointes sous la gaine, pour entamer, et j'agrandis en écartant avec les doigts) jusqu'à pouvoir attraper correctement le fil à dégainer. Ce saisir de celui-ci et tirer pour continuer à couper la gaine.

 

Une fois le câble dégainé sur une longueur suffisante, couper la gaine et le fil à dégainer puis séparer les paires délicatement.

 

Enfiler l'embout de protection

Utilisation du fil à dégainer

Séparation des paires

 

Puis détoronner chaque paire et placer les fils dans leur position définitive, en suivant la norme choisie (ici, EIA/TIA 568B).

 

Ensuite, bien détordre les fils pour qu'ils soient le plus rectilignes possibles (sans les étirer) et les placer parallèlement les uns aux autres.

 

Norme EIA/TIA 568B

Séparation des fils
et mise en ordre

Fils ordonnés
avant égalisation

Prise RJ-45

Câble

Paire

Points

Couleur

2

1

Blanc/Orange

2

2

Orange

3

3

Blanc/Vert

1

4

Bleu

1

5

Blanc/Bleu

3

6

Vert

4

7

Blanc/Marron

4

8

Marron

 

Prendre la partie coupante de la pince à sertir et couper l'ensemble de façon que les extrémités des fils soient bien alignées et que leur longueur hors gaine ne soit pas trop importante. N'oubliez pas qu'il faudra que la gaine pénètre également dans le connecteur RJ-45, jusque sous le triangle de plastique qui bascule et la coince, lors du sertissage.

 

Maintenir les fils bien serrés et se saisir d'un connecteur RJ-45 maintenu contacts vers le haut. Engager maintenant, sans desserrer les doigts, les fils dans le connecteur.

 

Astuce : vous aller être obliger de desserrer vos doigts et de les reculer pour pouvoir enfoncer plus avant les fils. Or, à ce stade, ils ne sont pas encore engagés dans leurs canaux individuels. C'est là, en général, qu'ils se décroisent et qu'il faut les ressortir et recommencer. Pour éviter cela, introduire les fils avec une forte inclinaison verticale de façon que les fils touchent le plastique du connecteur à la fois en haut (du côté de vos doigts) et en bas (par leurs extrémités). Ensuite reculez tout doucement vos doigts en maintenant la pression des extrémités sur le plastique et pousser doucement jusqu'à ce que les fils commencent à s'engager dans leurs canaux individuels.

 

Dès que les fils commencent à s'engager dans leurs canaux individuels, s'arrêter pour vérifier qu'aucun d'entre eux ne s'est déplacé et que l'ordre est toujours respecté.

 

Avant de sertir, bien vérifier que les huits fils arrivent bien au bout de leur canal, au contact du plastique du bout de la prise. Il n'y a qu'à regarder la prise par en-dessous, puis de face pour le vérifier.

 

Vérification de l'ordre des fils,
avant la poussée finale

Vue de dessous,
en fin de course

Vue de face,
en fin de course

 

Maintenant, attrapez votre pince à sertir, mettez le connecteur en place jusqu'en butée (si la pince n'est pas munie de butée, faites jouer ce rôle à un de vos doigts) et serrez. Ceci a pour effet d'introduire les griffes des contacts dans les fils, en perçant l'isolant, et de bascule le prisme de plastique qui va coincer la gaine, à l'entrée du connecteur.

 

Câble droit et câble croisé



Câble droit :

Pour faire ce que l'on appelle un câble droit, vous devez sertir les deux prises RJ-45 de la même façon (même ordre des couleurs). Ce genre de câble est le plus courant. C'est par exemple le câble qui va d'une prise (ordinaire) du hub vers la prise de votre adaptateur réseau, sur le micro-ordinateur.

 

Dans les prises câblées à l'économie, il se peut que seules les paires 2 et 3 soient câblées. C'est non conforme, mais on ne peut pas dire que cela ne marche pas, du moins en 10 base T et 100 base T, puisque seules ces paires sont utilisées. De fait, si un jour vous êtes à l'étroit, vous ne pourrez pas mettre un dédoubleur de prise puisqu'il manquera 2 paires sur 4. Et puis si un jour on se retrouve face à une technologie qui occupe les 4 paires, il faudra refaire le travail. Pour ces raisons, je vous recommande de tout câbler.

 

Voici les tableaux de câblage de deux catégories de câbles courantes.

 

Câble norme EIA/TIA 568B
100 Ohms

Câble norme IBCS
120 Ohms

Prise 1

Prise 2

Points

Couleur

Points

Couleur

1

Blanc/Orange

1

Blanc/Orange

2

Orange

2

Orange

3

Blanc/Vert

3

Blanc/Vert

4

Bleu

4

Bleu

5

Blanc/Bleu

5

Blanc/Bleu

6

Vert

6

Vert

7

Blanc/Marron

7

Blanc/Marron

8

Marron

8

Marron

Prise 1

Prise 2

Points

Couleur

Points

Couleur

1

Gris

1

Gris

2

Blanc

2

Blanc

3

Rose

3

Rose

4

Orange

4

Orange

5

Jaune

5

Jaune

6

Bleu

6

Bleu

7

Violet

7

Violet

8

Marron

8

Marron

 

Câble croisé :

 

Pour un câble croisé, vous devez permuter respectivement les couleurs des paires 2 et 3 ainsi que celles des paires 1 et 4. Ce genre de câble sert, par exemple, à raccorder deux hubs quand aucun des deux ne dispose de ce que l'on appelle un port croisé (ou daisy-chain ou uplink ? ou ... etc.) ou surtout deux ordinateurs quand vous n'en avez que deux et que vous voulez économiser un hub.

 

Ci-dessous le tableau résumé. Les points sont numérotés de la même façon pour les deux prises, c'est-à-dire de gauche à droite, en regardant la prise par dessous (contacts dorés visibles vers vous).

 

Câble norme EIA/TIA 568B
100 Ohms

Câble norme IBCS
120 Ohms

Prise 1

Prise 2

Points

Couleur

Points

Couleur

1

Blanc/Orange

1

Blanc/ Vert

2

Orange

2

Vert

3

Blanc/Vert

3

Blanc/Orange

4

Bleu

4

Marron

5

Blanc/Bleu

5

Blanc/Marron

6

Vert

6

Orange

7

Blanc/Marron

7

Blanc/Bleu

8

Marron

8

Bleu

Prise 1

Prise 2

Points

Couleur

Points

Couleur

1

Gris

1

Rose

2

Blanc

2

Bleu

3

Rose

3

Gris

4

Orange

4

Marron

5

Jaune

5

Violet

6

Bleu

6

Blanc

7

Violet

7

Jaune

8

Marron

8

Orange

 

Contraintes de câblage :

 

Quelques contraintes à connaître (il y en a beaucoup) je ne cite que les plus importantes.

 

  • Ne pas tirer sur les câbles de façon à ne pas augmenter le pas de torsade
  • Ne pas couder le câble trop brutalement (rayon de courbure)
  • Une fois les fils coupés à la même longueur et sertis ils ne doivent pas être dépairés (torsade défaite) sur plus de 13mm (ce qui signifie forcément que le câble est bien serti sur sa gaine et non pas sur les fils).
  • Pour les câbles qui courent d'une pièce à l'autre de la maison, ne jamais dépasser 90m (bon je pense que ce problème ne concerne que les grands propriétaires terriens :-)
  • Eviter les perturbations électromagnétiques, surtout si le câble est non blindé. Cela veut dire : ne pas passer près des lampes au néon, des moteurs électriques, etc.

Je câble chez moi : La FAQ

 

 

 

 

· Quels sont les sortes de câblage possibles ?

· Quels sont les avantages qui restent au câble coaxial ?

· Comment relier deux ordinateurs en réseau sans hub ?

· Que signifient les sigles UTP, FTP, STP, SFTP ?

· Le câble UTP est-il suffisant pour câbler chez soi ?

· Pourquoi parle-t-on de double paire torsadée alors qu'il y a 4 paires de fils dans un cable RJ-45 ?

· Je ne comprends pas l'intérêt qu'il peut y avoir à sertir soi-même les câbles RJ-45. Pourquoi ne pas acheter des câbles déjà sertis ?

· Peut-on sur un cable serti, le désertir pour faire passer le fil dans un trou de mur par exemple, et le resertir après ?

· Est-on obligé d'avoir une pince à sertir pour enficher un connecteur RJ-45 ?

· Il existe des prises murales RJ-45. A quoi peuvent-elles servir ?

· Je souhaite savoir comment on peut réaliser un câble avec un connecteur RJ45 d'un côté et AUI de l'autre côté.

 

Une question vous taraude vraiment et ne figure pas dans cette FAQ, je tenterai d'y répondre si je ne suis pas trop assailli et ferai éventuellement figurer dans cette FAQ la question et la réponse. Ecrivez-moi.

 

Q. - Quels sont les sortes de câblage possibles ?

 

 

 

 

R.- Actuellement vous avez deux sortes de câblage possibles pour un réseau éthernet dont l'un, le coaxial fin (ou 10base2 ou encore "ethernet fin") doit être considéré comme en fin de vie, ne serait-ce que parce que vous ne dépasserez jamais le débit nominal de 10 Mb/s alors que le 100 Mb/s est en train de se généraliser. De plus vous aurez de plus en plus de mal à trouver des cartes réseau le supportant et celles-ci deviennent de plus en plus chères. L'autre type de câblage est la double paire torsadée. Il existe d'autres sortes comme la fibre optique, hors de propos dans le cadre d'un câblage à vocation familiale.

 

Q. - Quels sont les avantages qui restent au câble coaxial ?

 

 

 

 

R.- Plus guère d'avantages, si ce n'est de permettre l'utilisation de vieilles cartes réseau de récupération et de ne pas nécessiter d'équipement électronique de raccordement : hub (=concentrateur) ou switch (=commutateur). Mais vu le prix de ces derniers maintenant...

 

Q. - Comment relier deux ordinateurs en réseau sans hub ?

 

 

 

 

R.- Soit par des cartes réseau munies au moins d'une prise BNC et d'un câble coaxial plus deux bouchons terminateurs, soit par deux cartes réseau munies au moins d'une prise RJ45 (10baseT, 10/100baseT ou 100baseT) et d'un câble croisé RJ45-RJ45.

 

Q. - Que signifient les sigles UTP, FTP, STP, SFTP ?

 

 

 

 

R.- UTP = câble à paire torsadées (Twisted Pairs) non blindé. FTP = le même plus une feuille de blindage aluminium autour des paires. STP = le même que UTP mais avec une tresse métallique autour des paires. SFTP = possède à la fois la feuille de blindage alu et la tresse métallique.

 

Q. - Le câble UTP est-il suffisant pour câbler chez soi ?

 

 

 

 

R.- Evidemment ! A moins que vous n'ayez de fortes perturbations électromagnétiques dans votre maison, ce qui est tout de même assez rare. Vous éviterez cependant soigneusement de passer à proximité d'éventuels néons.

 

Q. - Pourquoi parle-t-on de double paire torsadée alors qu'il y a 4 paires de fils dans un cable RJ-45 ?

 

 

 

 

R.- Le 10BaseT et le 100BaseT n'utilisent que deux paires sur les 4.

 

Q. - Je ne comprends pas l'intérêt qu'il peut y avoir à sertir soi-même les câbles RJ-45. Pourquoi ne pas acheter des câbles déjà sertis ?

 

 

 


!!!!!!!!!!!!!!

R.- On a la longueur qu'on veut surtout quand on veut des câbles de plus de 10m, comme c'est le cas chez moi, entre les étages. De plus le prix du câbles au mètre par bobine de 300m (c'est ce que j'ai acheté) n'a rien à voir avec le prix du câble tout fait. Enfin, quand on a besoin d'un nouveau câble, ça prend 5 minutes.

 

Q. - Peut-on sur un cable serti, le désertir pour faire passer le fil dans un trou de mur par exemple, et le resertir après ?

 
   

 

R.- Oui avec un connecteur neuf, en coupant le câble au ras de l'ancien connecteur et en recommençant tout. Donc si j'ai bien compris l'esprit de la question... la réponse est non ; on ne peut pas désertir l'ancien connecteur et le remettre.

 

Q. - Est-on obligé d'avoir une pince à sertir pour enficher un connecteur RJ-45 ?

 
   

 

R.- Oui.

 

Q. - Il existe des prises murales RJ-45. A quoi peuvent-elles servir ?

 
   

 

R.- A éviter d'avoir des câbles qui traînent en permanence dans la pièce même quand il n'y a pas d'ordinateur connecté dessus (ordinateur portable, par exemple).

 

Q. - Je souhaite savoir comment on peut réaliser un câble avec un connecteur RJ45 d'un côté et AUI de l'autre côté.

 

 

 

 

R.- Cela n'est pas possible. Il faut un minimum d'électronique d'adaptation du signal. Par conséquent, il existe des appareils (des transceivers)qui sont munis d'une prise AUI à un bout et d'une RJ-45 à l'autre. Vous pourrez alors connecter votre équipement muni de la prise AUI et du transceiver par un câble RJ-45 standard de type droit ou croisé selon le type de liaion effectuée.

Remplacer un serveur Windows NT/2000 par Linux et SAMBA

 

 

 

 

Sommaire :

 

  • Etude de cas
  • Configuration
  • Exemple de fichier de configuration
  • Considérations Finales
  • Références: Bibliographie et outils
  • Copyright Notes

 

Résumé

 

Cet article ajoute des aspects présentés au préalable dans d'autres articles de LinuxFocus sur SAMBA, et sur son usage pour partager des ressources dans un environnement hétérogène Unix-Windows. Il se concentre plus précisément sur l'utilisation de Linux avec SAMBA pour fournir des services, habituellement fournis par les systèmes Windows.
Ce n'est pas seulement une démonstration de la puissance et de la souplesse de Linux, mais aussi un moyen d'en présenter les impacts économiques importants tels que :

 

  • Les économies sur le prix des licenses de serveurs Windows.
  • Une performance similaire ou meilleure peut être obtenue, parfois en utilisant moins de ressources matérielles que celles requises par un serveur Windows (en termes de processeur et mémoire)


Un serveur Linux avec SAMBA bien configuré peut se substituer à un serveur Windows NT/2000, peut facilement partager des répertoires, fournir un service Active Directory (ADS) mais peut aussi fonctionner en tant que contrôleur primaire de domaine (PDC), fournissant les services d'authentification avec les clients Windows 2000/NT/98/95, partageant les ressources (répertoires et imprimantes) et gérant les sessions utilisateur.
Cet article se concentre particulièrement sur ces aspects.


Comme résultat, dans de nombreux contextes où c'est la fonction primaire d'un serveur Windows, un serveur Linux avec SAMBA peut exécuter toutes les fonctions d'un serveur basé sur le système de Microsoft, sans changement sur les ordinateurs clients.
Pour les différentes étapes abordées, nous considérons que : SAMBA est déjà installé et fonctionne correctement sur la machine qui sera le serveur. Le lecteur connaît les concepts de base des serveurs Linux et Windows.

Etude de cas

 

Considérons un serveur Linux/SAMBA fonctionnant en tant que PDC, où chaque utilisateur authentifié a aussi accès à deux répertoires partagés sur le serveur, un dans une zone publique, et l'autre dans une zone privée. Au cours de cet article, il sera fréquent d'accéder à une zone privée, le répertoire personnel de chaque utilisateur.

Détails à considérer


Nom du serveur Linux/Samba NetBIOS :SMBServeur
Nom du domaine Windows (workgroup): LEDOMAINE
Partition privée de chaque usager: H: (Windows) => /home/ (Linux server)
Partition publique : P: (Windows) => /home/public


La figure 1 montre un simple réseau avec des ordinateurs clients fonctionnant sous Windows qui utilisent des ressources et des services d'un serveur Windows NT/2000. Ce serveur peut être remplacé par un serveur Linux/SAMBA.

Network diagram

Fig. 1 – PDC et serveur de fichiers sous Windows

Configuration

 

Etapes à suivre:

1) Créer les utilisateurs qui devront être authentifiés sur le serveur PDC (Linux et Samba).
Utiliser les commandes adduser,useradd ou userconf, ou d'autres utilitaires pour la gestion d'utilisateurs avec interface graphique (Webmin, Linuxconf, Yast, etc.).

 

Assurez-vous que les usagers ont seulement accès aux services de Linux/SAMBA (si vous le souhaitez), ce qui implique qu'ils n'ont pas accès au shell Linux. A cette fin, ils auront /dev/null comme répertoire personnel et /bin/false comme shell.

2) Convertissez les usagers Unix en usagers Linux/Samba/Windows, en créant le fichier smbpasswd.

cat /etc/passwd | mksmbpasswd.sh > /etc/samba/smbpasswd

 

Une autre méthode consiste à exécuter les commandes de SAMBA pour la création d'utilisateurs et la définition de mots de passe.

 

smbadduser
smbpasswd

Ces commandes fonctionnent de façon similaire aux commandes adduser et passwd.

3) Editez le fichier de configuration Sambe (smb.conf), en vous assurant d'inclure ou de supprimer les commentaires des options ci-dessous:


netbios name = SMBServer
workgroup = THEDOMAIN
server string = Linux Samba NT Server
log file = /var/log/samba/%m.log
max log file = 0
security = user
encrypt password = yes
smb password file = /etc/samba/smbpasswd
ssl CA certificate = /usr/share/ssl/.... (retirer commentaire)
socket options = (retirer commentaire)
local master = yes
preferred master = yes
domain master = yes
domain logons = yes
logon script = logon.bat
wins support = yes


Note:
Pour un login spécifique à chaque utilisateur, remplacer le script de logon par %U.bat, ainsi, chaque utilisateur a un "script de logon" avec son nom d'utilisateur; %u peut aussi être utilisé. Si vous souhaitez gérer le groupe auquel l'utilisateur appartient, vous pouvez utiliser %g ou %G. La signification de ces paramètres ou d'autres se trouvent dans le manuel.(man smb.conf)

4) Créez les ressources partagées
Editez le fichier smb.conf et commentez tous les exemples de partages, en faisant les modifications nécessaires pour ajouter les informations suivantes:

[netlogon]
comment = Initialization Scripts
path = /home/netlogon
read only = yes
guest ok = yes
browseable = no

[home]
comment = User Directory
path = /home/%U
browseable = yes
writable = yes

[public]
comment = Public Directory
path = /home/public
browseable = yes
writable = yes
guest ok = yes
create mask = 0777
force create mask = 0777


Sauvegardez le fichier smb.conf

5) Vouz pouvez vérifier la conformité de smb.conf en utiliant la commande :


testparm

Cette commande analyse le fichier smb.conf et rapporte les erreurs qui y sont trouvées.

6) Créez les répertoires /home/netlogon et /home/public avec les permissions 0754(netlogon) and 0777 (public).

7) Editez le fichier de script Logon: logon.bat.
Important : Utilisez un éditeur de texte pour Windows/DOS (comme Notepad ou Edit) pour créer le fichier logon.bat (afin de le sauvegarder dans un format texte MS); vous pouvez aussi utiliser un éditeur sous Linux, et convertir au bon format de texte. Par exemple, vim, a une commande ":set textmode" permettant d'obtenir un fichier avec les fins de lignes MS.


net time SMBServer /y (vous pouvez aussi utiliser: /yes au lieu de /y )
net use H: SMBServerhome -y
(vous pouvez aussi utiliser: /yes ou /y au lieu de -y )
net use P: SMBServerpublic -y

8) Insérez l'information SMBServer dans le fichier lmhosts
Editez le fichier /etc/samba/lmhosts (ou /etc/lmhosts) et ajoutez-y une ligne avec l'information de votre SMBServer :

SMBServeur, i.e: 192.168.0.10 SMBServer

9) Démarrez/redémarrez le démon Samba (smbd)

service smb restart

Si ça ne fonctionne pas correctement sur votre distro Linux, vous pouvez utiliser :

ps -auxgx | grep smb
kill -9 <# ID de processus de smb>
smbd


10) Utilisez smbclient pour vérifier que la configuration indiquée précédemment fonctionne correctement.

smbclient -L //SMBServeur

Si "Password:" est affiché, pressez "Enter" et les ressources partagées du serveur seront affichées.

11) Effectuez un login de client, à partir d'une autre machine Windows, dans le domaine LEDOMAINE, avec un nom d'utilisateur Linux/Samba créé préalablement (voir étapes 1 et 2).

Sous Windows, l'ordinateur client devrait être configuré comme suit:

 

Démarrer => Paramètres => Panneau de contrôle => Réseau => Client pour Réseaux Microsoft => Propriétés.

 

Une méthode très similaire peut être utilisée pour les clients Windows NT/2000 (Workstation/Professional), bien que la séquence puisse être différente.

Choisissez l'option "Démarrer une session de domaine Windows NT/2000" et tapez ce domaine: LEDOMAINE (WORKGROUP).

 

Exemple de fichier de configuration

 

Voici une configuration complète de Samba, qui a été testée avec plusieurs distributions de Linux. Le lecteur peut la modifier pour obtenir les résultats escomptés présentés dans cet article. Chaque instruction est commentée.

Un dernier conseil pour ceux qui désirent une configuration rapide de Samba. Vous pouvez installer Webmin et/ou SWAT pour configurer d'une façon plus conviviale.

 

#============================================================#
# /etc/smb.conf
#------------------------------------------------------------------------------------------------------------#
# Fichier de configuration principal de SAMBA
# Sélectionnez les paramètres selon vos besoins
#------------------------------------------------------------------------------------------------------------#
# Testé avec les systèmes: Solaris et les distributions Linux:
# RedHat 6.0, 7.0 y 7.1
# Solaris 7
# Slackware 7.x
# Mandrake 6.1, 7.0 y 8.1
# SuSe 7.2
#------------------------------------------------------------------------------------------------------------#
# derniers changements: 08/12/2001
# Sebastian Sasias - sasias(at)linuxmail(dot)org
# Commentaires traduits de l'anglais
# Note du traducteur: Les titres de paramètres avant "=" doivent rester tels quel. #============================================================#
#
# Ce fichier a été développé selon les spécifications du fichier
# SAMBA, du manuel smb.conf(5)
#
# NOTE: Après avoir édité ce fichier, testez-le avec
# la commande "testparm"
#
#======================== Options Globales =======================#
#
# Configuration Générale
#
[global]
#.......................................................................................................................................#
# workgroup = Domaine-NT ou nom-de-WorkGroup, ie: LEDOMAINE

# Domaine PDC
workgroup = LEDOMAINE
#.......................................................................................................................................#
# Nom annoncé aux autres ordinateurs
netbios name = SMBServeur
#.......................................................................................................................................#
# Le commentaire suivant apparaîtra dans le "Voisinage réseau"
server string = Serveur de test SAMBA
#.......................................................................................................................................#
# Cette ligne est importante pour des raisons de sécurité
# pour permettre la connexion à des ordinateurs spécifiques du réseau local.
# Par exemple, ici, l'accès est permis aux ordinateurs connectés au réseau 192.168.8.0
# Classe C commune) et à partir de l'interface "loopback".
# Pour plus de détails, lire la page man du fichier smb.conf
# Ex. : les ressources partagées ne peuvent être utilisées que par des ordinateurs dont l'adresse IP commence
# par 192.168.8 et par 127 (en commentaires sur la ligne suivante)
; hosts allow = 192.168.8. 127.
#.......................................................................................................................................#
#Pour charger une liste d'imprimantes au lieu de les
# énumérer, utilisez:

; load printers = yes
#.......................................................................................................................................#
# Remplacer le chemin du fichier printcap :
; printcap name = /etc/printcap
#.......................................................................................................................................#
# Sous SystemV les propriétés de noms printcap pour lpstat doivent permettre
# d'obtenir automatiquement une liste d'imprimantes à partir du spool

# de SystemV (Belle répétition :-)
; printcap name = lpstat
#.......................................................................................................................................#
# Il ne devrait pas être nécessaire de spécifier le type de système d'impression à moins qu'il ne soit pas standard
# Les systèmes actuellement supportés sont:
# bsd, sysv, plp, lprng, aix, hpux, qnx
; printing = bsd
#.......................................................................................................................................#
# Décommentez pour obtenir un compte d'invité (guest)
# vous devez l'ajouter à /etc/passwd sinon, l'utilisateur "nobody" sera utilisé
; guest account = pcguest
#.......................................................................................................................................#
# Pour obliger l'utilisation d'un fichier log distinct pour chaque ordinateur
# se connectant au serveur SAMBA
log file = /var/log/samba/log.%m
#.......................................................................................................................................#
# Pour limiter la taille de fichiers log (en Ko).
max log size = 50
#.......................................................................................................................................#
# Voir security_level.txt pour plus de détails
# Indique la méthode de validation des mots de passe
# User level security = chaque utilisateur avec son mot de passe (smbpasswd)
security = user
#.......................................................................................................................................#
# Si security = server la validation sera faite à partir d'un autre serveur
# Utiliser la valeur "password server" seulement avec security = server

# password server = [Adresse IP du serveur d'authentification].
; password server =
#.......................................................................................................................................#
# Pour crypter les mots de passe. Veuillez lire ENCRYPTION.TXT,

# Win95.txt et WinNT.txt dans la documentation Samba.
# N'activez cette option que si vous avez suffisamment de connaissances sur cette propriété.
# Information: Win95, Win98 et WinNT envoient des mots de passe cryptés.
encrypt passwords = yes
#.......................................................................................................................................#
# Les lignes suivantes servent à personnaliser less configurations
# de chaque ordinateur sur le réseau. %m est remplacé par le nom
# NetBios de la machine qui se connecte.
; include = /usr/local/samba/lib/smb.conf.%m
#.......................................................................................................................................#
# La documentation et certains "trucs" disent

# que l'option suivante donne de bonnes performances. Essayez !
# Voir speed.txt et les pages de manuel pour plus ample information
socket options = TCP_NODELAY
#.......................................................................................................................................#
# Configuration Samba pour utiliser plusieurs cartes réseau

# Pour pouvoir utiliser plusieurs cartes réseaux,
# elles doivent être listées ici. Comme dans l'exemple ci-dessous.
# Lire les pages de manuel pour plus de détails.
; interfaces = 192.168.8.2/24 192.168.12.2/24
#.......................................................................................................................................#
# Options de contrôle de l'explorateur:

# Définir "local master = no" pour que Samba ne soit pas le maître explorateur du réseau.
local master = yes
#.......................................................................................................................................#
# "OS Level" indique la précédence du serveur dans le choix du

# master browser. La valeur par défaut est communément suffisante
; os level = 33
#.......................................................................................................................................#
# Domain Master définit Samba comme maître explorateur de domaine.

# Ceci permet à Samba d'agir au titre de contrôleur de domaine et aussi de "voir"
# les ordinateurs des différents sous-réseaux TCP/IP
# Ne l'utilisez pas si vous avez déjà un contrôleur de domaine NT/2000 qui effectue cette tâche.

domain master = yes
#.......................................................................................................................................#
# "Preferred Master" oblige Samba à choisir un explorateur local par défaut au démarrage

# et augmente légèrement ses chances de le devenir.
# Si on a plus d'un serveur, "Preferred Master" deviendra le "favori"
#quand les clients chercheront un serveur dans la liste
preferred master = yes
#.......................................................................................................................................#
# A n'utiliser que s'il y a déjà un serveur NT/2000 fonctionnant comme PDC.

# (primary domain controller).
; domain controller =
#.......................................................................................................................................#
# Pour définir Samba comme serveur de logon pour le domaine

# pour les stations Windows 9x/Me.
domain logons = yes
#.......................................................................................................................................#
# Si vous utilisez "domain logons" il vous faut un script de logon

# pour chaque ordinateur ou chaque utilisateur

; logon script = %m.bat

# Pour un script spécifique à chaque utilisateur :
; logon script = %U.bat
#.......................................................................................................................................#
# Où stocker les profils itinérants (seulement pour Win95 et WinNT)
# %L remplace le nom NetBIOS du serveur, %U remplace le nom de l'utilisateur

# Il faut "décommenter" le partage [Profiles] ci-dessous

; logon path = %LProfiles%U
#.......................................................................................................................................#
# Support de Windows Internet Name Service (WINS):

# WINS Support - indique à NMBD d'activer son serveur WINS.
# WINS protocol, convertit les noms de machines en adresses IP,
# il fonctionne comme le DNS de TCP/IP.
; wins support = yes
#.......................................................................................................................................#
# WINS Server - indique aux composants NMBD de Samba d'agir comme client WINS

# SAMBA peut être serveur WINS ou client WINS,
# mais pas les deux en même temps.
# Ici, on doit spécifier le serveur WINS
; wins server = 192.168.8.1
#.......................................................................................................................................#
# WINS proxy - Demande à Samba de répondre aux requêtes de résolution de noms pour les clients non WINS

# On doit avoir au moins un serveur WINS sur le réseau pour que cette option fonctionne.
# La valeur par défaut est NO.
; wins proxy = yes
#.......................................................................................................................................#
# DNS Proxy - demande à Samba de résoudre les noms NetBIOS ou pas, par le nslookup de DNS.
# La valeur par défaut pour la version 1.9.17 est "yes",
# qui a changé depuis la version 1.9.18 en "no".

# Ici nous pouvons indiquer à SAMBA si la résolution de nom se fera par DNS ou pas.
# dns proxy = yes
# dns proxy = no (la résolution de nom se fera par lmhosts )
#........................................................................................................................................#
# Si "logon drive" n'est pas spécifié, Z: sera automatiquement "monté"
logon drive = P:
#.......................................................................................................................................#
#Quand un login se produit, ce script est éxécuté: /etc/samba/netlogon/SAMBA.BAT
# et "monte" les unités de disques par "net use"
logon script = SAMBA.BAT

#====================== Définitions de partages ========================#

# Répertoire personnel pour chaque utilisateur

# Unité P:

[homes]
comment = Répertoires personnel
browseable = no
writable = yes
readonly = no
force create mode = 0700
create mode = 0700
force directory mode = 0700
directory mode = 700

#------------------------------------------------------------------------------------------------------------#
# Répertoire des fichiers temporaires

# Unité T:

[tmp]
comment = Fichiers temporaires
path = /tmp
readonly = no
public = yes
writable = yes
force create mode = 0777
create mode = 0777
force directory mode = 0777
directory mode = 0777

#------------------------------------------------------------------------------------------------------------#
# CD-ROM du serveur

# Unité L:

[cdrom]
comment = CD-ROM
path = /mnt/cdrom
public = yes
writable = no

#------------------------------------------------------------------------------------------------------------#
# Groupe, correspondant à /home/grp.name_group
# /home/user/group est un lien vers /home/grp.name_group
# grp.name_group a les permissions 770
# Unité G:

[group]
comment = Directory of Group
path = /home/%u/group
writable = yes
readonly = no
force create mode = 0770
create mode = 0770
force directory mode = 0770
directory mode = 0770

#------------------------------------------------------------------------------------------------------------#
# Cette unité sert aux applications et installations de logiciels,

# logiciels corporatifs, etc.
# Les permissions de /net et /net/install sont 755, i.e: ici, root en est le propriétaire
# Unité N:

[net]
comment = Directory Net
path = /net
writable = yes
readonly = no
force create mode = 0750
create mode = 0750
force directory mode = 0750
directory mode = 0750

#------------------------------------------------------------------------------------------------------------#
[netlogon]
comment = Service d'accès au réseau
path = /etc/samba/netlogon
guest ok = yes
writable = no
locking = no
public = no
browseable = yes
share modes = no

#------------------------------------------------------------------------------------------------------------#

Considérations Finales

 

SAMBA ainsi que d'autres outils pour Linux évoluent continuellement, et il se peut donc que certains détails présentés ici ne soient plus d'actualité. En fait, au cours de l'évolution de SAMBA, certains noms de paramètres dans les fichiers de configuration ont légèrement changé, avec comme objectif d'obtenir une meilleure structure.

Si pendant la configuration de SAMBA vous obtenez des messages d'erreurs concernant des paramètres inconnus, vous avez deux solutions au problème :

  • Regarder le fichier smb.conf installé par défaut, qui contient généralement des lignes commentées au sujet des "paramètres problématiques"
  • Lire la documentation de SAMBA, en commençant par le fichier qui décrit les changements survenus depuis les dernières versions.

 

Références: Bibliographie et outils

 

 

L´auteur

 

Il utilise Linux depuis plusieurs années comme outil de développement de solutions technologiques.
Il travaille sur le contrôle d'équipement avec Linux : traitement de signal, communication et sécurité de réseaux.
Professionel en Electronique - Automatisation et en Informatique.
Il a contribué au développement de logiciel libre sous GNU/GPL.



Traduit en Français par :
Jean-François Messier

 

Ajouts de ressources Web dans les Références par :
Olivier Maréchal

Firewall : Origine et Fonctionnement

 

 

 

 

Origine du "firewall"

 

On désigne sous le nom de Firewall un dispositif, placé au point de connexion d'un système (ou groupe de systèmes) avec l'extérieur, et qui permet de contrôler les flux entrant ou sortant.

Ce dispositif était initialement conçu pour empêcher le piratage, et de cette finalité vient l'origine du terme employé. Un firewall, ou pare-feu, est en effet une barrière qui empêche la propagation d'un incendie. Il s'agit en général d'un système de portes ou de cloisons fixes ou amovibles, ignifugées et complètement étanches, placées aux endroits stratégiques d'un bâtiment. Leur fermeture en cas d'incendie permet de contenir le feu dans des zones réduites, d'où il ne se propagera pas.

De la même façon, un firewall était à l'origine placé en un point stratégique d'un réseau, afin d'éviter que l'incendie que représentait la compromission d'une ou plusieurs machines du système ne se répande en direction des serveurs stratégiques.

On peut donc traduire firewall par pare-feu, ou mur pare-feu. Le terme “mur de feu” qu'on rencontre parfois est en revanche un contre-sens.

Aujourd'hui, les fonctions d'un firewall se sont étendues, puisqu'il est aussi bien question d'empêcher la compromission de machines du réseau que d'empêcher la sortie de certaines informations du réseau local, voire l'utilisation de certains logiciels, par exemple de type IRC.

 

Que protège-t-on, et contre quoi


Installer un firewall n'est pas une fin en soi. On dit souvent que son installation ne protège que le sommeil de l'administrateur, mais certainement pas le réseau ! En fait, il convient avant tout de savoir ce que l'on veut protéger, et de quoi... En fonction de cette analyse, on décidera si un firewall s'avère utile, où le placer et comment le paramétrer.

Ces concepts paraissent évidents, mais combien de systèmes sont faciles à compromettre parce que cette réflexion a été menée trop vite, voire pas du tout ! A quoi sert-il en effet de mettre un firewall en entrée sur le serveur Web, si une machine du réseau est publiquement accessible à tout visiteur ? A quoi bon construire une zone de décontamination, si tous les commerciaux emportent chez eux leur portable, d'où ils surferont sur le Net sans filtre et récolteront toutes les backdoors du monde sous la forme de kits d'accès à des sites disons... plus visuels qu'intellectuels ? Sans parler des pseudo cracks du dernier logiciel à la mode, criblés de javascripts et de Troyens... Un pare-feu n'est pas plus utile sur un système couvert de failles de protocoles, ou d'applications dites faibles... On oublie souvent que le trou principal s'appelle le port 80, et qu'il faudrait presque protéger chaque segment du réseau... nous y reviendrons dans le cours IDS.

Quoi qu'il en soit, la première question à se poser est : quelles sont les machines que je veux protéger, et comment accède-t-on à ces machines ? Il ne sert à rien d'installer un Raptor à 7000 euros sur un serveur NT 4 qui est un simple serveur de fichiers, même si l'on tient à ses fichiers chéris... Raptor n'arrêtera pas par ailleurs un virus, ou une injection PHP bien conçue. Nous y reviendrons dans la partie strucutures de réseau.

 

Les différents types de firewall

 

 

 

 

Cas initial: un réseau sans firewall


Une connexion client serveur peut se produire de différentes manières. Pour prendre un exemple simple, analysons une connexion Web dans laquelle un navigateur va lire la page d'accueil d'un site quelconque, puis va se connecter sur un serveur de mail.

Dans la pratique, le navigateur constitue un client http qui va demander au serveur http la page que l'on veut lire. Cette demande prend la forme d'une requête http, dans laquelle le client explicite la page qui est demandée, et donne aussi d'autres informations, comme la version du navigateur utilisé, la langue, etc.

Cette requête est encapsulée dans une communication TCP, qui décompose la requête en segments, et chaque segment est envoyé dans un sens ou dans l'autre par l'intermédiaire d'adresses IP.

HTTP est un protocole non connecté. Cela signifie que, une fois la connexion avec le fournisseur d'accès établi, la demande de la page n'obéit pas à une nécessité d'authentification. Le navigateur, anonyme, demande une page accessible publiquement, et le serveur la renvoie, sans connaître autre chose du client que son adresse IP, puis coupe la connection.

Dans le cas d'une connexion à un serveur Webmail, il y a nécessité d'une authentification : autrement dit, le serveur va demander aux clients, en plus de sa requête, de s'authentifier, sous la forme d'un nom d'utilisateur est d'un mot de passe. Sans autre paramétrage, ces informations apparaissent en clair dans les fragments envoyés. Par la suite, le contenu des messages qui est renvoyé par le serveur circulent en clair jusqu'au client.

Ces informations s'appuient, outre l'adresse IP, sur un numéro de port, qui permet d'identifier quelle application est concernée par les informations. C'est ce qui permet à un fenêtre de lire la page web, pendant que l'autre lit les mails. Ces ports fonctionnent des deux côtés, une machine de l'extérieur peut tout à fait appeler un serveur mail interne, même si cette demande paraît abhérente du point de vue de l'utilisation du réseau.

Premier type : firewall simple, ou stateless


Pour se protéger de la lecteure des informations qui circulent en clair, la meilleure solution est le cryptage. Le firewall est difficilement opérant à cet égard.

En revance, la première entreprise de filtrage consiste à autoriser ou interdire certaines adresses IP, et certains ports, en entrée et en sortie de la connection Internet.

Il paraît évident qu'on interdira à une machine de l'internet de demander le serveur mail interne, si des commerciaux ne sont pas supposés accéder au réseau depuis l'extérieur. Classiquement, on interdira aussi le requêtes externes sur le port 139, celui du partage windows. On interdira aussi les requêtes internes venant de l'extérieur, autrement dit une machine qui prétendrait avoir une IP du réseau, et qui se trouverait sur l'internet, évitant ainsi une partie de l'IP spoofing. On empêchera enfin les requêtes broadcast ou multicast dans un sens ou dans l'autre, pour éviter les DOS ou DDOS.

Cette interdiction peut se programmer sur une machine spécifique, qui comportera deux cartes réseau, l'une tournée vers le réseau, l'autre vers l'internet. On peut aussi paramétrer certains routeurs directement, et certains switchs. De fait, il s'agit ici d'une mise en oeuvre simple. La machine filtrante examine chaque paquet, l'accepte, le rejette ou le transmet ailleurs, selon des principes très basiques.

Cette machine a rarement besoin d'être très puissante, contrairement aux idées reçus, puisque son travail est minimaliste.

Le défaut de ce type de firewalling est son aspect manichéen. On interdit ou on autorise un port par exemple en général, sans se préoccuper de savoir s'il est parfois normal (et parfois non) d'autoriser ce port. De la sorte, ce type de filtrage est souvent soit trop restrictif et bloquant pour l'activité du réseau, soit inefficace... Par exemple, une base de données SQL Server locale qui devra se connecter en synchronisation ou distribution avec une application externe au réseau local pourra ouvrir un port aléatoirement choisi au dessus de 1024, ce qui oblige à laisser tous les ports de cette tranche ouverts. Mais c'est aussi un de ces ports qu'ouvrira un Troyen pour permettre le contrôle du serveur d'authentification ! Ce principe est donc très vite limité.

Deuxième type : Firewalls élaborés : stateful


Il s'agit de la première des deux réponses possibles aux limitations du firewall stateless. Son principe consiste à enregistrer les connections que lit le firewall, et à maintenir un état de ces connections, afin d'appuyer sa politique de filtrage.

Ainsi, plutôt que d'autoriser ou non un port 1433, on autorisera les demandes de connection en provance du réseau local et les réponses externes. On peut aller plus loin, en exigeant par exemple qu'un paquet entrant ne soit autorisé que s'il répond à une requête sortante. De la sorte, on limite les risques d'intrusion.

Cependant, comme on le verra plus loin, la mise en oeuvre de ce filtrage requiert de la prudence, afin de ne pas par exemple empêcher lres requêtes DNS extérieures, le cas échéant, ou interdire les connections extérieures voulues (ICQ et autres).

Par ailleurs, il faut examiner si le firewall connaît tous les protocoles utilisés sur le réseau ! En effet, certains d'entre eux nécessitent l'ouverture et la fermeture de ports changeants, comme par exemple FTP, et ce firewall ne les filtrera correctement que s'il les prend en charge dans sa rédaction.

Le choix d'un firewall stateful repose donc sur cet examen, mais aussi sur son mécanisme de fonctionnement interne.

En effet, ce type de filtrage tend à ralentir le réseau, et pose un problème en cas de paquets mal formés. Certains firewalls statefuls examinent les en-tête TCP pour établir la position du paquet dans la transaction (SYN, ACK, etc.), ce qui améliore la performance et la fluidité, et limite les besoins du tampon de la machine filtrante : un simple examen suffit àdécider du sort du paquet.

Cependant, si une telle optique paraît attirante, elle offre peu de protection face aux paquets forgés manuellement, et spécifiquement destinés à tromper ce type de système (un attaquant extérieur envoie un paquet avec les drapeaux SYN ACK au lieu de SYN seul, ce qui laisse croire au firewall que ce paquet répond à une demande de connection interne, et le laisse passer).

Un autre mécanisme consiste donc à garder en mémoire les transactions en cours pendant une certaine durée (souvent de l'ordre de la minute), afin d'établir précisément la position du paquet, sans abus possible. Cependant, ce type de mise en oeuvre est beaucoup plus lourd en ressources et en baisse de performance. Le problème est aussi de savoir quelle est la durée nécessaire de ce tampon (le temps du timeout du keep alive, ou plus ?).

Enfin, ce type de firewall, comme le premier, ne protège pas complètement le réseau d'attaques sur des ports autorisés ! Ainsi, on pourra tout à fait autoriser la connection de la base SQL Server évoquée plus haut, sans réaliser que la requête envoyée est un 'drop database', ce que le pare feu ne prend pas en compte. De même, de nombreuses failles de IIS se fondent sur des requêtes sur le port 80, qui sont a priori autorisées, puisque 'naturelles' !

Troisième type : proxy applicatif


Il s'agit de la réponse la plus récente aux problèmes évoqués plus haut. Là, le firewall joue un rôle proche de celui du proxy, c'est à dire qu'il traite les demandes en lieu et place du réseau interne, examine les réponses du réseau externe, et décide de la politique à appliquer en conséquence.

L'intérêt est que l'examen ne porte plus sur une connection, mais sur le contenu des paquets. En d'autres termes, le filtrage portera sur le contenu.

Ainsi, le 'drop database' évoqué plus haut, en provenance de l'extérieur, sera rejeté systématiquement. L'objectif est de déterminer ce qui constitue un paquet mal formé, de le re-former si possible avant de le transmettre, ou de le rejeter s'il est excessivement déformé (ainsi, un 'select * form clients' pourra être lu comme 'select * from clients', mais pas un 'select from clients'), mais aussi de repérer ce qui constitue une attaque manifeste (bogues connus, ou injections de type 'drop database' ou autres injections SQL, mais aussi PHP ou champs de formulaires complétés de façon étrange).

Les grands firewalls d'aujourd'hui offrent ce niveau de protection, qui est le plus haut. C'est le cas de Raptor ou Sidewinder, par exemple.

Cependant, on voit bien que ce filtrage ne fonctionne que si le firewall connaît le protocole filtré. Pourquoi 'toto or 1=1” est-il inacceptable comme mot de passe dans un formulaire1 ?

La conséquence est d'une part qu'il faut que tous les protocoles utilisés sur le réseau soient pris en charge par le firewall, ce qui interdit certains protocoles, trop rares ou qui ne sont pas maîtrisés par les concepteurs de la solution choisie, d'autre part s'attendre à ce que ce type de firewall présente des problèmes de fonctionnement, liés à certaines bizarreries des protocoles, auxquelles les concepteurs n'ont pu faire face (c'est le cas des nombreux buffer overflows dont la possibilité est régulièrement découverte dans tel ou tel protocole, et qu'évidemment les concepteurs du proxy applicatif installé antérieurement dans l'entreprise n'ont pas protégé, ou de 'surprises' qui font qu'en filtrant telle exécution on interdise telle autre dont on a besoin et qui ne semble pourtant pas liée directement à la première).

Par ailleurs, la création de ce type de produit consiste à implémenter une foule de protocoles sur une application supplémentaire, ce qui ouvre la porte bien sûr à de nombreuses failles spécifiques, en plus des failles propres aux protocoles ! (un exemple typique2 est le processus TCP CONNECT, autorisé par de nombreux proxies applicatifs, et pour cause (!), mais qui permettaient du coup d'utiliser le firewall comme relais d'attaque vers un autre système !).

Enfin, il faut noter que la mise en oeuvre de ce type de protection ralentit considérablement le réseau, puisqu'il ne s'agit plus d'examiner chaque paquet l'un à la suite de l'autre, mais bien toute la séquence qui doit être transmise !

Conclusion


On voit donc qu'il n'existe pas de solution miracle concernant le firewalling. Chaque solution offre ses avantages et ses limitations. Idéalement, on mettra en place un proxy applicatif, précédé d'un firewall stateful. Mais il faudra garder en mémoire que la solution implémentée, si elle est fonctionnelle à un instant t, nécessite cependant une surveillance permanente afion de détecter les faiblesses qu'elle ne corrige pas, ou celles nouvellement apparues.

 

Mise en place des firewalls

 

 

 


Une fois que les principes de ce que l'on veut installer sont clairs, il convient d'examiner à quel emplacement du réseau on va placer tel ou tel outil. A cet égard, on distingue la position des filtres de celles des analyseurs de contenu.

Filtres


On en a déterminé deux types : les routeurs équipés de fonction de firewalling, et les firewalls positionnés sur des machines spécifiques.

Routeurs/switches

 

 

 

 

Principes


Ces deux outils d'interconnection peuvent être paramétrés comme filtre. Leur action se place au niveau IP (couche 3) ou TCP (couche 4). Mais il faut remarquer qu'il s'agit d'extensions des fonctionnalités de base de ces objets, puisqu'un switch fonctionne en couche 2, et ne se préoccupe normalement pas de l'adresse IP, et encore moins du protocole, et le routeur ne s'intérésse supposément qu'à la couche 3.

L'implémentation la plus simple prend la forme d'acces-list, dans laquelle on va autoriser ou refuser en couche 3 telle ou telle adresse, ou telle tranche d'adresses. Les limitations apparaissent vite, comme on l'a vu plus haut.

C'est donc naturellement que les listes d'accès passent en mode “étendu” ces dernières années, pour examiner le protocole envoyé ou le port, montant en couche 4.

Cependant, le travail d'un routeur est... de router ! Ajouter des access-lists trop complexes alourdit considérablement le travail de routage. On a donc souvent tendance à limiter l'examen des en-têtes à la présence ou l'absence d'un flag SYN.

Par ailleurs, ce type de fitrage présente deux faiblesses majeures : d'abord, le routeur est crédule ! Il croit le champ adresse-source : il est donc susceptible de répondre au spoofing IP3. Par ailleurs, un routeur transmet toujours un paquet de moins de 68 octets (RFC 791). Or la constitution d'un paquet TCP permet de placer le flag SYN vers la fin de cette limite4, et, même en son absence, un routeur transmettra le paquet, ce qui autorise un hack fragmenté.

Certains routeurs plus récents et plus évolués ont des optimisations dans ce domaine, mais ils restent coûteux. De plus, encore une fois, le travail d'un routeur... est de router, il est plus logique de s'en tenir conceptuellement à ce principe. Les access-list seront mises en place, mais dans une logique administrative, afin d'interdire au service compta d'accéder au port 153 du serveur marketing, par exemple, mais pas dans l'idée de faire office de firewall complet.

Mise en place


Le routeur sera connecté en général à l'Internet. Celui-là fera l'objet d'un paramétrage interdisant le spoofing (on refuse le réseau interne s'il entre par l'Internet) et on ne filtre pas en sortie.

Les routeurs internes au réseau auront le paramétrage requis par la disposition spécifique locale, comme décrit plus haut (exemple comptabilité-marketing), et ne filtreront pas l'Internet.

Firewalling

 

 

 

 

Principes


Nous n'évoquons ici que le cas du Firewall Stateful.

Dans une situation idéale, il se place derrière le routeur connecté à l'internet, et dispose de deux sorties : l'une vers un brin réseau qui représente le LAN, un autre vers un autre sous-réseau, qui contient les machines lisibles depuis l'Internet, telles que serveur de mail ou serveur Web. Ces machines sont accessibles, et leur compromission, idéalement, n'affecte pas le LAN. Elles sont en quelques sortes isolées, et constituent une forme de tampon entre l'intérieur et l'extérieur. On appelle parfois cette zone une DMZ (De Militarised Zone, en référence au no man's land créé entre les deux Corées après la guerre).

On verra plus bas que ce type de firewall filtre un paquet en entrée, forward ou sortie, c'est à dire au moment où il pénètre dans le firewall, au moment où il doit circuler dans le firewall, ou en sortie après traitement. Ce procédé permet notamment de rejeter certains paquets avant qu'ils n'affectent la pile IP du firewall lui-même.

Mise en place


Dans cette configuration, on autorisera les flux en provenance de l'Internet, mais à la seule destination de la DMZ.
On autorisera aussi les entrées et sorties en port 25 du serveur smtp.
Du réseau interne vers la DMZ, on autorisera les flux type smtp, pop et http, ainsi que les accès ssh depuis les IP internes des administrateurs.

Proxy applicatifs

 

 

 

 

Principes


Bien qu'on décrive cette implémentation comme représentant le niveau le plus haut du filtrage, on retiendra cependant qu'elle implique un ralentissement notable de flux du réseau : quoi qu'en disent les fabricants, un proxy applicatif, par définition, fonctionne en couche 7 ! Il faut donc remonter les couches, ce qui est plus long mécaniquement que de filtrer en couche 3 ou 4.

Par ailleurs, on gardera en mémoire les réserves émises plus haut.

Mise en place


Dans la mesure du possible, on positionnera ces dispositifs en renforcement des firewalls statefuls, en accès des machines supportant les applications stratégiques (et elles seules). Cet outil pourra donc tout à fait être positionné en plusieurs endroits du réseau, avec un paramétrage spécifique à chaque point. La difficulté provient du fait que ce type de filtre permet en général un firewalling stateful, et qu'on tend soit à les positionner à la position des firewalls statefuls, ce qui pose un problème de débit et risque d'interdire des flux qu'on souhaiterait autoriser en fonction de leur source ou leur destination finale, soit à les positionner en position proxy applicatif, ce qui laisse la porte ouverte à des tentatives de pénétration basées sur les protocoles. Dans le cas d'une implémentation unique, la position firewall reste à privilégier.

Conclusion

 

 

 

  • La mise en place d'un firewall reste une étape importante dans une démarche de sécurité, mais elle doit rester un simple outil. Un réseau, même protégé par un pare-feu, reste vulnérable. Dès lors qu'on DROP certains paquets, une pirate attentif remarquera évidemment qu'un tel paquet devrait produire un RESET et non une absence de réponse. Il en déduira donc la présence du firewall et pourra reconstituer ses règles, détecter quels ports sont ouverts, puis encapsuler dans ces ports une attaque vers d'autres ports. Il n'y a pas de solution miracle, seul un monitoring permanent permettra de détecter ces tentatives. On pourra d'ailleurs s'aider d'outils de détection d'intrusion, comme snort, qui reste, même s'ila beacuoup été décrié (mais c'est souvent une sorte de mode), l'un des meilleurs IDS disponible grâce à son excellente base de données sur les outils d'intrusion. Mais ceci est l'objet d'un autre cours...

Paramétrage du BIOS

 

 

 

 

L'article n'est plus tout jeune, mais il reste en ligne car certains d'entre vous peuvent encore y trouver une utilitée ;)

 

Attention : Toute manipulation de BIOS risque d'entraver le bon fonctionnement de votre PC, son paramétrage influt sur les performances de votre PC, en mieux, ou moin bien si le paramétrage est mauvais.

 

Le BIOS que nous allons étudier est destinée aux possesseurs de machines équipées du BIOS Award. C'est l'un des plus répandus, bien que les autres restent assez similaires en terme de fonctionnalités. Cependant, vous vous apercevrez qu'il n'y a pas deux BIOS identiques sur deux PC différents, Tout dépend de la carte mère.

 

BIOS Features Setup :Accédez donc au BIOS (touche "Suppr" au démarrage) puis commencez par regarder ce que l'entrée "BIOS Features Setup" vous réserve. Cette section vous permet de configurer votre système pour les opérations de base : la vitesse du système, la séquence de démarrage, les opérations clavier, la sécurité, etc.

 

Virus Warning : cette entrée permet d'activer l'anti-virus du BIOS. Il est cependant très limité car il ne fait qu'intercepter toute tentative de modification du secteur de démarrage, et génère une interruption du système pour demander à l'utilisateur s'il veut continuer le cas échéant. Nous vous conseillons de désactiver cette option car elle crée un conflit grave lors de l'installation de Windows 95.

 

Cpu Internal Cache/External Cache : ces deux catégories accélèrent les accès mémoire, mais cela dépend fortement de l'architecture de la carte mère et du CPU. Il est conseillé de faire des bench marks avec cette option activée et désactivée pour déterminer le meilleur choix.

 

Quick Power On Self Test : lorsque cette option est active (Enabled), le démarrage de l'ordinateur est nettement accéléré car le BIOS ne fait plus l'ensemble des vérifications. Si votre ordinateur est stable, activez cette option.

 

Boot Sequence : Si vous ne démarrez jamais l'ordinateur sur une disquette, sélectionnez l'ordre C, A, cela accélère le démarrage de l'ordinateur car il n'allume plus le lecteur de disquettes pour vérifier Si une disquette "bootable" est présente.

 

Boot Up Floppy Seek : permet au BIOS de déterminer lors du démarrage la nature du lecteur de disquettes pour savoir Si elles sont en 40 ou 80 pistes. Cela s'avère désuet de nos jours, désactivez-le pour gagner du temps. Boot Up NumLock Status : placez-le sur "On" pour pouvoir utiliser les chiffres du pavé numérique.

 

Boot Up System Speed : positionnez cette option sur "High", sauf , si vous désirez ralentir votre PC. IDE HDD Block Mode : positionnez-le sur "Enabled" pour permettre des accès disque sur de larges blocs de données au lieu d'octets individuels. Le système s'en trouve accéléré.

 

Gate A20 option : cela permet d'adresser la mémoire au-delà des 1 Mo. Placez-le sur "Fast" pour que la carte mère le fasse , sinon c'est le clavier qui le gère de manière bien plus lente.

 

Memory Parity Check : activez l'option si vous désirez vérifier la parité de la mémoire, pour éviter des erreurs si celle-ci est peu fiable. Si vous n'avez jamais rencontré de problème, désactivez-le, cela fait gagner du temps au démarrage.

 

Typematic Rate Setting : activez cette option pour pouvoir taper plusieurs fois un caractère en laissant le doigt appuyé sur la touche, sinon la répétition est désactivée.

 

Typematic Rate: cela vous permet de définir le nombre de caractères par seconde émis par le clavier lorsque vous laissez le doigt sur une touche.

 

Typematic Delay : ici, vous définissez l'intervalle de temps d'attente avant que se déclenche la répétition de la touche.

 

Security Option : choisissez "System" pour interdire le démarrage sile mot de passe rentré est invalide, et "Setup" pour seulement limiter l'accès au paramétrage du BIOS.

 

System BIOS Shadow : activez-le pour copier le BIOS dans la RAM, cela lui confère un accès plus rapide. Mais cela peut être sans effet sur certains systèmes, selon l'architecture.

 

Video BIOS Shadow : c'est exactement le même principe pour le BIOS de la carte vidéo cette fois-ci. C8000-CFFFF Shadow à E8000-EFFFF : ces catégories déterminent si les ROM optionnelles sont copiées en mémoire RAM pour accélérer leur accès. Les ROM optionnelles sont par exemple le support SCSI présent sur la carte mère.

 

Chipset Features Setup : La partie "Chipset Features Setup" dépend plus de la carte mère et risque donc de différer selon les constructeurs. L'ensemble des entrées qui figurent ci-dessous permettent également de configurer le PNP/PCI, mais c'est loin d'être une liste exhaustive. Seul ont été sélectionné des options qui influent directement sur les performances de l'ordinateur.

 

16 bits ISA 1/0 Command WS : le système est nettement plus rapide que ses périphériques. Ce paramètre permet de définir le temps de réponse des périphériques avant qu'une erreur soit générée ou que des données soient perdues. Plus la valeur est importante, plus le système est fiable. Cependant, Si les périphériques sont de très bonne qualité, diminuez cette valeur pour accélérer la machine.

 

AGP Aperture Size : plus la valeur est importante, plus les accès à la mémoire graphique seront rapides, car ils ne nécessiteront aucune translation.

 

Auto Configuration : activez cette option Si vous êtes néophyte, le système se paramétrera selon la détection des périphériques.

 

Auto Detect DIMM/PCI Clk : pour réduire les interférences électromagnétiques, le système coupe l'horloge pour les siots DIMM et PCI non utilisés. Activez donc cette option.

 

Cache Read Burst : c'estl'option typique à ne pas modifier. Le fabriquant de la carte mère la prédéfinit de manière optimum selon la vitesse de la mémoire cache. Cela est également valable pour d'autres options semblables comme "Cache Write Wait State", "CAS Pulse" Width ou CPU Core Voltage.

 

CPU Addr. Pipelining : cette option, lorsqu'elle est activable, accélère énormément les traitements, car les adresses sont calculées parallèlement au traitement des données.

 

CPU Host/PCI Clock : par défaut, le BIOS utilise les valeurs d'horloge du CPU et du bus PCI. La modification peut éventuellement améliorer les performances, mais également altérer le bon fonctionnement (plantages). Après tests, vous pourrez savoir si la différence de performances est visible. CPU to PCI (Write) Buffer/Post: activez cette option car elle compense la différence de vitesse entre le CPU et le bus PCI en gérant un système de buffer, dans lequel le CPU écrit sans attendre la fin d'écriture, ce qui lui permet de continuer sur d'autres instructions pendant ce temps.

 

DMA Clock : permet de définir la vitesse de l'accès direct à la mémoire. La vitesse la plus haute risque de ne pas être supportée par les composants (plantage). À vous de définir la bonne limite.

 

DRAM Fast Leadoff, DRAM Posted Write Buffer : activez systématiquement ces options pour améliorer les performances.

 

DRAM Read Burst (B/E/F) : plus la valeur est faible, plus l'accès mémoire est rapide, dans la limite des capacités des barettes mémoire installées.

 

Graffic Posted Write Buff : activez l'option pour bénéficier du buffer graphique interne, ce qui permet au processeur de vaquer à d'autres tâches.

 

L1 Cache Policy : Write Back est un mécanisme de gestion du cache plus performant que Write Through.

 

L2 Cache Size : 512 MB n'est à sélectionner que Si le système a plus de 64 Mo de RAM.

 

PCI Burst : activez cette option pour bénéficier du meilleur protocole de gestion des accès PCI (plus de données sont transférées simultanément).

 

PCIto CPU Write Posting : cette option activée permet au PCI d'écrire tandis que le CPU est occupé.

 

PNP OS Installed : choisissez "Yes" Si Windows 95/98 est installé.

 

L'ensemble des astuces citées dans l'article ne doit pas vous empêcher de lire les recommandations figurant sur la documentation de votre carte mère. Le site MISFU décline toute responsabilité quant aux dysfonctionnements résultant d'une manipulation du BIOS.

DHCP (Dynamic Host Configuration Protocol)

 

 

 

 

1 - Définition
2 - Références
3 - Fonctionnement
4 - Les baux
5 - Dynamique ou pas ?
6 - Les requêtes et les messages DHCP
7 - Les messages DHCP
7.1 - Dialogue avec le serveur
7.2 - Format de la trame BOOTP/DHCP
7.3 - Passage d'options
8 - Le serveur Dhcp
8.1 - Où trouver un serveur DHCP ?
8.2 - Compilation du serveur
8.3 - Le fichier dhcpd.conf
8.3.1 - Les paramètres globaux
8.3.2 - shared-network
8.3.3 - subnet
8.3.4 - host
8.3.5 - group
8.3.6 - Les options
8.3.7 - Exemple de fichier dhcpd.conf
8.4 - Lancer le démon dhcpd
8.5 - Exécuter le démon à chaque démarrage (pour Linux)
8.6 - Documentation
9 - Configuration des clients
9.1 - Tout pour contrôler, réparer etc
9.2 - Windows 95/98
9.2.1 - Configuration
9.2.2 - Vérification
9.3 - Windows NT4/2000/XP
9.3.1 - Configuration
9.3.2 - Vérification
9.4 - Linux
9.4.1 - Configuration
9.4.2 - Vérifiez l'état de votre connexion
9.4.3 - Particularités du client DHClient
10 - Savoir "Sniffer"
10.1 - En-têtes de trames
10.2 - Détail des trames
10.2.1 - Le DHCP Discover
10.2.2 - Un petit ping...
10.2.3 - Offre d'un nouveau bail
10.2.4 - Demande du Bail de la part du client
10.2.5 - Le serveur est d'accord
10.3 - Notes supplémentaires
10.3.1 - Duplication d'adresse
10.3.2 - Pas de réponse
10.4 - Renouvellement d'un bail en cours de validité
10.4.1 - Quand ça se passe bien...
10.4.2 - Et quand ça se passe mal
11 - Suivi du document

 

1 - Définition

 

DHCP signifie Dynamic Host Configuration Protocol. Il s'agit d'un protocole qui permet à un ordinateur qui se connecte sur un réseau local d'obtenir dynamiquement et automatiquement sa configuration IP.

Le but principal étant la simplification de l'administration d'un réseau. On voit généralement le protocole DHCP comment distribuant des adresses IP, mais il a été conçu au départ comme complément au protocole BOOTP (Bootstrap Protocol) qui est utilisé par exemple lorsque l'on installe une machine à travers un réseau (on peut effectivement installer complètement un ordinateur, et c'est beaucoup plus rapide que de le faire en à la main). Cette dernière possibilité est très intéressante pour la maintenance de gros parcs machines.

Les versions actuelles des serveurs DHCP fonctionne pour IPv4 (adresses IP sur 4 octets). Une spécification pour IPv6 (adresses IP sur 16 octets) est en cours de développement par l'IETF.

 

2 - Références

 

Les incontournables RFCs :

- RFC951 : Bootp
- RFC1497 : Options vendor extensions
- RFC1541 : Définition du protocole Dhcp
- RFC1542 : Interaction entre Bootp et Dhcp
- RFC2131 : Complément à la Rfc 1541
- RFC2132 : Complément aux options vendor extensions

Spécifications et API Java : dhcp.org
Le site de l'ISC : http://www.isc.org
Le site de Microsoft : BOOTP, DHCP, DNS servers (en anglais)

 

3 - Fonctionnement

 

DHCP fonctionne sur le modèle client-serveur : un serveur, qui détient la politique d'attribution des configurations IP, envoie une configuration donnée pour une durée donnée à un client donné (typiquement, une machine qui vient de démarrer). Le serveur va servir de base pour toutes les requêtes DHCP (il les reçoit et y répond), aussi doit-il avoir une configuration IP fixe. Dans un réseau, on peut donc n'avoir qu'une seule machine avec adresse IP fixe : le serveur DHCP. Le protocole DHCP s'appuie entièrement sur BOOTP : il en reprend le mécanisme de base (ordre des requêtes, mais aussi le format des messages). DHCP est une extension de BOOTP.

Quand une machine vient de démarrer, elle n'a pas de configuration réseau (même pas de configuration par défaut), et pourtant, elle doit arriver à émettre un message sur le réseau pour qu'on lui donne une vraie configuration. La technique utilisée est le broadcast : pour trouver et dialoguer avec un serveur DHCP, la machine va simplement émettre un paquet spécial, dit de broadcast, sur l'adresse IP 255.255.255.255 et sur le réseau local. Ce paquet particulier va être reçu par toutes les machines connectées au réseau (particularité du broadcast). Lorsque le serveur DHCP reçoit ce paquet, il répond par un autre paquet de broadcast contenant toutes les informations requises pour la configuration. Si le client accepte la configuration, il renvoit un paquet pour informer le serveur qu'il garde les paramètres, sinon, il fait une nouvelle demande.

Les choses se passent de la même façon si le client a déjà une adresse IP (négociation et validation de la configuration), sauf que le dialogue ne s'établit plus avec du broadcast.

 

4 - Les baux

 

Pour des raisons d'optimisation des ressources réseau, les adresses IP sont délivrées pour une durée limitée. C'est ce qu'on appelle un bail (lease en anglais). Un client qui voit son bail arriver à terme peut demander au serveur un renouvellement du bail. De même, lorsque le serveur verra un bail arrivé à terme, il émettra un paquet pour demander au client s'il veut prolonger son bail. Si le serveur ne reçoit pas de réponse valide, il rend disponible l'adresse IP. C'est toute la subtilité du DHCP : on peut optimiser l'attribution des adresses IP en jouant sur la durée des baux. Le problème est là : si toutes les adresses sont allouées et si aucune n'est libérée au bout d'un certain temps, plus aucune requête ne pourra être satisfaite.

Sur un réseau où beaucoup d'ordinateurs se connectent et se déconnectent souvent (réseau d'école ou de locaux commerciaux par exemple), il est intéressant de proposer des baux de courte durée. A l'inverse, sur un réseau constitué en majorité de machines fixes, très peu souvent rebootées, des baux de longues durées suffisent. N'oubliez pas que le DHCP marche principalement par broadcast, et que cela peut bloquer de la bande passante sur des petits réseaux fortement sollicités.

 

5 - Dynamique ou pas ?

 

Un serveur DHCP est censé fournir des adresses dynamiques (un même ordinateur peut recevoir successivement 2 adresses différentes), mais il peut fournir une adresse IP fixe à un client bien particulier. Ceci ne doit être utilisé que de manière modérée, sinon, le serveur DHCP ne sert à peu près plus à rien, mais cela peut se révéler utile pour fournir l'adresse IP au serveur TFTP qui va servir pour le boot à distance des machines.

 

6 - Les requêtes et les messages DHCP

 

On pourrait croire qu'un seul aller-retour peut suffire à la bonne marche du protocole. En fait, il existe plusieurs messages DHCP qui permettent de compléter une configuration, la renouveler... Ces messages sont susceptibles d'être émis soit par le client pour le ou les serveurs, soit par le serveur vers un client :

 TCPIP IPV6 VOIP VPN IP IPV4 TCPIP


La valeur entre parenthèses est utilisées pour identifier ces requêtes dans les messages DHCP. Voir les options DHCP.

La première requête émise par le client est un message DHCPDISCOVER. Le serveur répond par un DHCPOFFER, en particulier pour soumettre une adresse IP au client. Le client établit sa configuration, demande éventuellement d'autres paramètres, puis fait un DHCPREQUEST pour valider son adresse IP. Le serveur répond simplement par un DHCPACK avec l'adresse IP pour confirmation de l'attribution. Normalement, c'est suffisant pour qu'un client obtienne une configuration réseau efficace, mais cela peut être plus ou moins long selon que le client accepte ou non l'adresse IP ou demande des infos complémentaires...

Pour demander une nouvelle adresse, le chronogramme-type est le suivant :

 TCPIP IPV6 VOIP VPN IP IPV4 TCPIP


Pour renouveler une adresse, le fonctionnement est le suivant (les 2 serveurs connaissent le client) :

 TCPIP IPV6 VOIP VPN IP IPV4 TCPIP

 

7 - Les messages DHCP

 

7.1 - Dialogue avec le serveur

 

Les messages DHCP sont transmises via UDP. Bien que peu fiable, ce protocole suffit au transport des paquets simples sur réseau local, et surtout il est très léger, donc intéressant pour les petits systèmes (du genre le micro bout de programme qui fait la requête DHCP lorsque le PC se met en route). De facto, DHCP fonctionne aussi en mode non connecté. Le client n'utilise que le port 68 pour envoyer et recevoir ses messages de la même façon, le serveur envoie et reçoit ses messages sur un seul port, le port 67.

 

7.2 - Format de la trame BOOTP/DHCP

 

La trame DHCP est en fait la même que BOOTP, et a le format suivant (les chiffres entre parenthèses indique la taille du champ en octets) :

 TCPIP IPV6 VOIP VPN IP IPV4 TCPIP


- op : vaut 1 pour BOOTREQUEST (requête client), 2 pour BOOTREPLY (réponse serveur)
- htype : type de l'adresse hardware (adresse MAC, par exemple. Voir Rfc 1340

)

- hlen : longueur de l'adresse hardware (en octet). C'est 6 pour une adresse MAC
- hops : peut être utilisé par des relais DHCP
- xid : nombre aléatoire choisi par le client et qui est utilisé pour reconnaître le client
- secs : le temps écoulé (en secondes) depuis que le client a commencé sa requête
- flags : flags divers
- ciaddr : adresse IP du client, lorsqu'il en a déjà une
- yiaddr : la (future ?) adresse IP du client
- siaddr : adresse IP du (prochain) serveur à utiliser
- giaddr : adresse IP du relais (passerelle par exemple) lorsque la connexion directe client/serveur n'est pas possible
- chaddr : adresse hardware du client
- sname : champ optionnel. Nom du serveur
- ile : nom du fichier à utiliser pour le boot
- options : Champs réservé Rfc 2132. Dans une précédente RFC, la taille de ce champ était limitée (limité à 64 octets par exemple pour la première version de Bootp) ; maintenant, il n'y a plus de limitation. Dans tous les cas, un client DHCP doit être prêt à recevoir au minimum 576 octets, mais la possibilité lui est offerte de demander au serveur de restreindre la taille de ses messages.

 

7.3 - Passage d'options

 

Le passage de paramètres (nom de la machine...) se fait par l'intermédiaires d'options. Les options sont documentées dans la Rfc 2132. Elles portent toutes un numéro qui les identifie. Par exemple, l'option 15 est celle qui permet de donner au client le nom de domaine du réseau. Il est bien entendu possible d'envoyer plusieurs options dans le même message DHCP ; dans tous les cas, que l'on ne transmette qu'une seule option utile ou plusieurs, on doit toujours finir la zone d'options par une option 255 (end). Le format des options est le suivant :

 TCPIP IPV6 VOIP VPN IP IPV4 TCPIP


Le numéro de l'option n'est codé que sur 1 octet, donc il ne peut y avoir que 256 options possibles. L'octet 2 code la longueur du champ de données qui suit. Il ne tient donc pas compte des 2 octets de code d'option et de longueur.

Certaines options ne comportent pas de données complémentaires, comme l'option 255. Dans ce cas, il n'y a ni champ de longueur ni champ de données. Les messages DHCP vus dans le chapitre précédent

(DHCPACK...) sont tout simplement une option ! Il s'agit de l'option 53 qui comporte un champ de données de longueur 1 contenant le numéro identifiant la requête (1 pour DHCPDISCOVER...). Les 4 premiers octets du champ d'options doivent être initialisés respectivement avec les valeurs 99, 130, 83 et 99 (valeurs en décimal). Cette séquence est appelée le "magic cookie" (gateau magique en français).

Le client DHCP a la possibilité d'imposer au serveur DHCP une taille maxi pour le champ d'options (option 57). La conséquence d'une telle limitation est que le serveur peut manquer de place pour envoyer toutes les options souhaitées. Pour répondre à ce problème, le serveur est autorisé à utiliser les champs sname et file pour finir son envoi. Le client est averti de cet usage par un option 52 dans la zone d'options.

 

8 - Le serveur Dhcp

 

8.1 - Où trouver un serveur DHCP ?

 

 

L' Internet Software Consortium

développe un serveur DHCP pour le monde du logiciel libre. C'est le serveur DHCP le plus répandu, et celui qui "suit" au mieux les Rfcs. L'une des principales innovations est la possibilité de mettre à jour un DNS dynamiquement en fonction des adresses IP fournies par le serveur DHCP. Pour information, le première draft sur le DNS dynamique date de mars 1996... Microsoft a bien entendu son propre serveur DHCP pour Windows. Seule la version pour Windows 2000 Server permet de mettre à jour les DNS dynamiquement avec DHCP. Le reste de cette section traite de l'installation et de la configuration d'un serveur DHCP sous système Unix. L'exemple pris est celui d'un serveur fourni par l'ISC.

 

8.2 - Compilation du serveur

 

La première étape de la réalisation d'un serveur DHCP est bien entendu sa compilation. Allez sur le site de l' ISC

et téléchargez une version d'un serveur DHCP ou téléchargez simplement ma versionqui, bien que vieille, prend en charge la mise a jour de DNS. Copier le fichier dans un répertoire.

Décompressez l'archive : tar xzf dhcp-2.0b1pl6.tar.gz

Déplacez-vous dans le répertoire (commande cd), et tapez : ./configure

Cela va générer les fichiers Makefile correspondant à votre système. Tapez ensuite make pour compiler le serveur et enfin make install pour installer le serveur.

Avant de faire le ./configure, il est hautement recommandé de lire le fichier README qui explique comment installer correctement le serveur. Par exemple, pour ma version, tapez ./configure --with-nsupdate pour compiler le serveur avec le support Dynamic DNS update. make install copiera les fichiers perl dans le répertoire /usr/local/DHCP-DNS-0.52mdn.

 

8.3 - Le fichier dhcpd.conf

 

Ce fichier est la base de la configuration du serveur. Par défaut, il se trouve dans le répertoire /etc/, mais vous pouvez le mettre n'importe où. il est composé de plusieurs sections, chacune limitée par des accolades { et } :

- des paramètres globaux qui s'appliquent à tout le fichier,
- shared-network,
- subnet,
- host,
- group.

Chaque section peut contenir des paramètres et des options.
Une section group peut contenir des sections host. Au début du fichier, on peut placer des paramètres globaux, comme par exemple la durée des baux, les adresses des DNS... Chaque ligne du fichier de configuration doit se terminer par un ;, sauf lorsqu'il y a une accolade. Les commentaires sont possibles en ajoutant un # en début de ligne.

 

8.3.1 - Les paramètres globaux

 

Ils peuvent être un peu tout et n'importe quoi, pourvu qu'ils aient une signification applicable à toutes les déclarations du fichier. Par exemple, on peut redéfinir la durée des baux (max-lease-time et default-lease-time), empêcher le serveur de répondre à des requêtes venant d'hôtes non déclarés (deny unknown-clients;), indiquer le nom de domaine que les machines doivent utiliser, les serveurs DNS...

Voir un exemple

.

 

8.3.2 - shared-network

 

Ce paramètre est utilisé pour regrouper plusieurs zones subnet lorsque ceux-ci concerne le même réseau physique. Les paramètres rentrés en début de zone seront utilisés pour le boot des clients provenant des sous-réseaux déclarés, à moins de spécifier pour certains hôtes de ne pas booter (zone host). Son utilisation se rapproche de celle de host ; il faut toutefois l'utiliser systématiquement que le réseau est divisé en différents sous-réseaux administrés par le serveur DHCP.

Syntaxe :

shared-network FOO-BAR
{
filename "boot";

subnet 192.168.2.0 netmask 255.255.255.224
{
range 192.168.2.10 192.168.2.30;
}

subnet 192.168.2.32 netmask 255.255.255.224
{
range 192.168.2.40 192.168.2.50;
}

}

 

8.3.3 - subnet

 

subnet permet de définir les sous-réseaux sur lesquels le serveur DHCP doit intervenir. C'est la partie la plus importante du fichier de configuration du serveur DHCP ; sans ça, votre serveur ne marchera jamais.

La syntaxe exacte pour cette zone est comme suit :

subnet numero_sous-reseau netmask netmask
{
[ paramètres globaux... ]
[ déclarations... ]
}

numero_sous-reseau et netmask sont donnés sous format adresse IP pointées. Un exemple se trouve juste au dessus, dans la partie décrivant la zone shared-network.

On peut bien entendu commencer la zone par des paramètres globaux qui ne seront appliqués que pour les ordinateurs de ce sous-réseau. Par exemple, le nom de domaine à appliquer sur ce sous-réseau (option domain-name). Ensuite, on peut ajouter des déclarations d'hôtes. Le paramètre global indispensable est :

range [ dynamic-bootp ] adresse_inferieure [ adresse_superieure ] qui définit la zone d'adresses IP (limitée par adresse_inferieure et adresse_superieure) que le DHCP peut distribuer. Plusieurs range peuvent se suivre. On peut ne pas spécifier d'adresse supérieure, cela revient à ne considérer qu'une seule adresse IP distribuable (celle indiquée, bien sûr). dynamic-bootp doit être mis pour indiquer que le DHCP doit répondre aux requêtes BOOTP en donnant une adresse de cette plage.

 

8.3.4 - host

 

Ce mot permet de déclarer des machines que le DHCP doit connaître et leur appliquer une configuration particulière. Vous n'êtes pas obligé d'utiliser cette zone, mais elle est par exemple indispensable lorsque vous avez déclaré deny unknown-clients; en début de fichier pour empêcher le serveur DHCP de répondre à des requêtes provenant d'hôtes non déclarés.

host est utilisé de la façon suivante :

host nom
{
paramètres...
}

Un hôte peut être reconnu de deux façons : en utilisant son nom (le nom qui suit le mot clé host) ou en utilisant son adresse hardware (ethernet ou token-ring). Dans ce dernier cas, il faut ajouter une ligne dans la déclaration host : hardware ethernet|token-ring adresse-hardware;. Il est fortement recommandé d'authentifier les ordinateurs à partir de leur adresse hardware plutôt que leur nom, surtout qu'il sont supposés ne pas posséder de véritable nom Internet et que l'on peut redéfinir ce nom.

Un point important : c'est dans une déclaration host que l'on décide d'attribuer une adresse fixe ou non à un hôte. Il suffit alors d'utiliser une ligne comme celle-ci : fixed-address 192.168.2.4;. ATTENTION ! Toute adresse IP attribuée de manière fixe ne doit pas faire partie des zones d'adresses IP déclarées avec range... (zone subnet).

 

8.3.5 - group

 

Cette zone est simplement utilisée pour rassembler plusieurs déclarations (de toute sorte, y compris d'autres déclarations group) pour leur appliquer des différents paramètres. Exemple :

group
{
option domain-name "bar.org";
option routers 192.168.1.254;

host foo1
{
...
}

host foo2
{
...
}

}

 

8.3.6 - Les options

 

Les paramètres qui doivent commencer avec option sont les options définies dans la Rfc 2132. Il y en a environ 60 définies dans la Rfc, mais le serveur peut en gérer jusqu'à 254 (les options 0 et 255 sont réservées). Pour trouver les options possibles et leur nom, vous pouvez consulter le fichier common/tables.c des sources du serveur. ATTENTION ! les noms des options peut varier d'une version de serveur à une autre.

Le format des valeurs des options est donné dans ce même fichier au début ("format codes:"). Les options plus utiles sont les suivantes :

- subnet-mask (option 1) qui indique le masque de sous-réseau pour la configuration IP,
- routers (option 3) qui indique les routeurs à utiliser,
- domain-name-servers (option 6) qui indique les DNS à utiliser. On peut aussi bien donner le nom que l'adresse IP (!)
- host-name (option 12) qui indique au client quel nom d'hôte il doit prendre,
- domain-name (option 15) qui fournit au client le nom du domaine arpa dans lequel il se trouve,
- broadcast-address (option 28) qui indique l'adresse de broadcast en vigueur sur le réseau,
- dhcp-lease-time (option 51) qui indique au client la durée de validité du bail.
- D'autres options (60 en particulier) permettent de personnaliser les messages DHCP circulant sur le réseau.

 

8.3.7 - Exemple de fichier dhcpd.conf

 

- max-lease-time 240;
- default-lease-time 240;
- deny unknown-clients;
- option domain-name "bar.com";
- option domain-name-servers foo1.bar.com, foo2.bar.com;

subnet 192.168.1.0 netmask 255.255.255.0
{
range 192.168.1.2 192.168.1.100;
range 192.168.1.110 192.168.1.254;
option broadcast-address 192.168.1.255;
}

group
{
option routers 192.168.2.101;

host foo3
{
hardware ethernet 00:c0:c3:11:90:23;
option host-name pc3;
}

host foo4
{
hardware ethernet 00:c0:c3:cc:0a:8f;
fixed-address 192.168.1.105;
}

}

host foo5
{
hardware ethernet 00:c0:c3:2a:34:f5;
server-name "bootp.bar.com";
filename "boot";
}

Explications :

Les cinq premières lignes définissent les paramètres globaux. Les 2 premiers concernent les baux (leases). La ligne suivante dit au serveur de ne pas répondre aux requêtes DHCP venant d'hôtes qu'il ne connaît pas (i.e. non définis dans dhcpd.conf). On définit enfin les paramètres du domaine du réseau (nom de domaine et serveurs DNS).

On définit ensuite le sous-réseau sur lequel le serveur DHCP est censé intervenir : c'est la ligne "subnet...". Dans ce sous-réseau, on dit au serveur de ne fournir des adresses IP que dans les plages d'adresses définies par les lignes "range...". la dernière ligne de la section définit l'adresse de broadcast à utiliser sur le sous-réseau.

On crée ensuite un groupe dont le but est uniquement de fournir des adresses de passerelles à des machines bien déterminées (par leur adresse MAC). On remarque que foo4.bar.com obtiendra une adresse IP fixe.

foo5, enfin, sera une machine qui bootera à travers le réseau, en se connectant au serveur TFTP bootp.bar.com, et booter avec le fichier boot.

 

8.4 - Lancer le démon dhcpd

 

Pour lancer le serveur, il faut d'abord être root sur le système. Il suffit ensuite de taper la commande suivante :

dhcpd -lf fichier_de_leases -cf fichier_de_config adpateur1 adapteur2...



le serveur DHCP va alors se lancer sur les adaptateurs réseau adapteur1, adapteur2..., en trouvant sa configuration dans le fichier fichier_de_config et en utilisant le fichier fichier_de_leases pour stocker ses baux. Sans tous les arguments, le serveur DHCP va aller chercher ses fichiers dans des emplacements déterminés au moment de la compilation, dans le fichier includes/dhcpd.h et utiliser eth0 comme interface par défaut. Vous pouvez bien entendu modifier tout ça.

 

8.5 - Exécuter le démon à chaque démarrage (pour Linux)

 

Pour lancer le démon au démarrage de votre machine, il faut d'abord placer un script shell de lancement du démon dans le répertoire /etc/rc.d/init.d/. Ce script va en fait gérer le démarrage et l'arrêt de dhcpd. Ce fichier n'est hélas par fourni avec les archives de l'ISC. Vous pouvez le créer vous même en vous inspirant des autres scripts figurant dans le répertoire ou simplement reprendre:

 

# Source networking configuration.
. /etc/sysconfig/network

# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0

[ -f /usr/sbin/dhcpd ] || exit 0
[ -f /etc/dhcpd.conf ] || exit 0
[ -f /var/dhcpd/dhcpd.leases ] || touch /var/dhcpd/dhcpd.leases

# See how we were called.
case "$1" in
start)
# Start daemons.
echo -n "Starting dhcpd: "
daemon /usr/sbin/dhcpd -lf /var/dhcpd/dhcpd.leases -cf /etc/dhcpd.conf eth0
touch /var/lock/subsys/dhcpd
;;
stop)
# Stop daemons.
echo -n "Shutting down dhcpd: "
killproc dhcpd
echo
rm -f /var/lock/subsys/dhcpd
;;
restart)
$0 stop
$0 start
;;
status)
status dhcpd
;;
*)
echo "Usage: dhcpd {start|stop|restart|status}"
exit 1
esac

exit 0

Faites un chmod 755 dhcpd pour mettre les bons droits.

Il faut maintenant dire à GNU/Linux d'exécuter ce script au démarrage. Cela se fait en créant des liens symboliques dans les répertoires /etc/rc.d/rcx.d/ avec x un entier correspondant au runlevel auquel le démon doit être lancé. Faites simplement chkconfig --add dhcpd, cela va créer les liens symboliques pour vous.

Vous pouvez maintenant redémarrer votre ordinateur, le serveur DHCP sera lancé automatiquement.

ATTENTION ! Il se peut que linuxconf prenne le contrôle du serveur DHCP. Si vous voulez garder indéprendante la gestion de votre serveur DHCP (comme c'est par exemple le cas pour moi car j'ai modifié la script /etc/rc.d/init.d/dhcpd), désactivez la prise en charge de dhcpd dans linuxconf.

 

8.6 - Documentation

 

La commande make install a dû installer sur votre système les manuels du serveur. Pour y accéder, tapez simplement :

- man dhcpd pour connaître le fonctionnement du démon dhcpd,
- man dhcpd.conf pour savoir comment écrire et configurer le fichier dhcpd.conf,
- man dhcpd.leases pour avoir des informations sur les baux du serveur DHCP.

Cette doc n'est toutefois ni très simple ni complète. Les options ne sont par exemple pas détaillées. La meilleure documentation est finalement de loin la Rfc qui pour une fois a la bonne idée d'être claire et concise.

 

9 - Configuration des clients

 

Vous devez aller dans la configuration TCP/IP, enlever tout ce qu'il y a concernant l'IP, le masque de sous réseau, DNS, passerelle et juste dire que vous voulez une configuration dynamique (DHCP). Relancez vos services réseaux, la méthode la plus simple et la plus bestiale étant le "reboot", et voilà. Une fois le système remonté, vous devez avoir hérité d'une configuration automatique.

 

9.1 - Tout pour contrôler, réparer etc

 

Dans cette partie nous verrons, suivant le système employé,

-

Windows 95/98

-

Windows NT4/2000/Xp

-

Linux (Mandrake 9)

quels sont les outils pour contrôler l'état du client DHCP. Je demande aux utilisateurs de Be/OS, de MAC/OS et de tous ceux que j'oublie, de bien vouloir m'excuser de ne pas leur apporter mon soutien. J'ai déjà dans mon petit bureau (4 M2) trois PC dont un sur lequel sont installés trois systèmes, je n'ai plus de place...

 

9.2 - Windows 95/98

 

9.2.1 - Configuration

 

Par le panneau de configuration, icône "réseau", cliquez sur "TCP/IP -> . L'adresse IP doit être configurée dynamiquement, c'est d'ailleurs le choix par défaut à l'installation.

 

9.2.2 - Vérification

 

Si vous avez un bail en cours de validité, la commande "winipcfg" vous affiche les choses suivantes:

 TCPIP IPV6 VOIP VPN IP IPV4 TCPIP


ATTENTION! Windows 95 et 98 installent également le client PPP dont nous n'avons rien à faire... Ce client apparaît également dans la liste des interfaces réseau.
Vérifiez bien que vous pointez sur votre carte Ethernet et pas sur le client PPP...

Si vous cliquez sur le bouton "Plus d'info>>":

 TCPIP IPV6 VOIP VPN IP IPV4 TCPIP


Ici, c'est le bouton "Renouveler" qui sera votre seul secours en cas de problèmes. Notez que les rubriques "Bail obtenu" et "Expiration du bail" contiennent des valeurs calculées par votre machine. Le serveur DHCP ne donne que la durée.

 

9.3 - Windows NT4/2000/XP

 

9.3.1 - Configuration

 

La configuration se fait dans le panneau de configuration, icône "réseau", onglet "protocoles", puis "propriétés" de TCP/IP. Là, vous avez indiqué que la carte doit recevoir une adresse IP dynamiquement.

 

9.3.2 - Vérification

 

Tapez dans une console, la commande "ipconfig"

 TCPIP IPV6 VOIP VPN IP IPV4 TCPIP


Votre adresse doit être affichée. Si vous voulez tous les détails, utilisez la commande "ipconfig /all":

 TCPIP IPV6 VOIP VPN IP IPV4 TCPIP


La commande "ipconfig" permet également:

- De résilier le bail: "ipconfig /release"
- De renouveler le bail: "ipconfig /renew"

C'est cette commande qui est à utiliser pour essayer de récupérer une adresse IP lorsque vous avez des problèmes.

Notes :

- Les rubriques "Bail obtenu" et "Expiration du bail" contiennent des valeurs calculées par votre machine. Le serveur DHCP ne donne que la durée.
- La commande en mode graphique "winipcfg" n'existe pas nativement sous Windows NT mais vous pouvez la récupérer dans le kit de ressources techniques (téléchargeable sur le site MS en cherchant bien :-). N'essayez pas d'utiliser celle de Windows 95/98, les dll winsock32 utilisées ici ne sont pas compatibles.

 

9.4 - Linux

 

9.4.1 - Configuration

 

Avec cet OS c'est beaucoup plus compliqué, parce qu'il y a beaucoup plus de configurations possibles. La configuration utilisée dans l'exposé est la suivante:

- Un portable Compaq équipé d'une carte réseau D-LINK PCMCIA
MANDRAKE 8.2
Eth0 et configurée avec DHClient.

Notez que DHClient n'est pas le seul client possible. Vous pouvez parfaitement le remplacer par PUMP, DHCPXD ou par DHCPCD. Tous ces clients sont disponibles dans la distribution Mandriva (anciennement Mandrake), qui installe d'ailleurs DHCPCD par défaut, et non pas celui que j'utilise.

- DHCPCD semble avoir la préférence du distributeur. Je n'ai jamais rencontré de problèmes avec, mais je ne l'utilise normalement pas pour la raison suivante: Son paramétrage ne se fait que par la ligne de commande, ce qui oblige à aller modifier des scripts pas toujours faciles à trouver si l'on veut par exemple utiliser son propre DNS à la place de celui proposé dans le bail.
- PUMP Fonctionne également sans problèmes, il dispose d'un fichier de configuration /etc/pump.conf dans le quel on peut par exemple spécifier très simplement que l'on ne veut pas modifier le paramétrage du DNS avec l'information récupérée par DHCP. (Le ou les DNS sont inscrits dans le fichier /etc/resolv.conf).
- Je n'ai pas vraiment étudié DHCPXD qui fonctionne lui aussi sans difficultés. Il dispose d'un répertoire /etc/dhcpxd dans lequel vous trouverez quelques fichiers qui vous donneront toutes les indications sur le bail en cours.

DHCLIENT a ma préférence. Il est écrit par

ISC

(les auteurs de BIND le fameux DNS et DHCPD lque nous utilisons ici, c'est dire qu'ils savent de quoi ils parlent :). Ce client cumule à mon sens tous les avantages:

- Un fichier de configuration /etc/dhclient.conf sans doute encore plus performant que celui de PUMP. Notez que ce fichier n'existe pas dans la distribution Mandriva, il vous faudra éventuellement le créer si vous ne voulez pas vous contenter du fonctionnement par défaut.
- Des scripts optionnels exécutés automatiquement avant l'obtention du bail et après l'obtention du bail, avec à disposition des variables contenant toutes les informations recueillies par le client auprès du serveur. Très pratique par exemple pour vous envoyer par mail l'adresse courante de votre machine si celle-ci change; dans le cas par exemple où vous avez besoin de vous y connecter à distance par telnet ou ssh.
- Il tient un historique des baux obtenus dans le fichier /var/lib/dhcp/dhclient.leases

Son seul inconvénient est sa richesse. Il n'est pas le plus facile à mettre en oeuvre.

 

9.4.2 - Vérifiez l'état de votre connexion

 

Dans /etc/sysconfig/network-scripts, il y a un fichier intitulé : ifcfg-eth0. Il doit contenir au moins ces lignes :

DEVICE="eth0"
BOOTPROTO="dhcp"
IPADDR=""
NETMASK=""
ONBOOT="yes"


C'est assez parlant pour ne pas nécessiter d'explications particulières.

La commande "ifconfig eth0" devrait vous donner quelque chose comme ceci :

 TCPIP IPV6 VOIP VPN IP IPV4 TCPIP


Si rien n'apparaît, c'est que votre interface n'est pas activée. Essayez alors ifup eth0 :

 TCPIP IPV6 VOIP VPN IP IPV4 TCPIP


Cette commande affiche l'état de Eth0, mais elle ne donne pas toutes les informations que l'on obtient sous Windows avec winipcfg ou ipconfig. Si vous voulez tout savoir, il faut aller dans le répertoire "/var/lib/dhcp" et regarder le fichier dhclient.leases. Celui-ci contient l'historique des dialogues DHCP :

lease
{
interface "eth0";
fixed-address 192.168.0.8;
option subnet-mask 255.255.255.0;
option routers 192.168.0.253;
option dhcp-lease-time 3600;
option dhcp-message-type 5;
option domain-name-servers 192.168.0.253;
option dhcp-server-identifier 192.168.0.253;
option domain-name "maison.mrs";
renew 2 2002/12/10 08:49:42;
rebind 2 2002/12/10 09:14:05;
expire 2 2002/12/10 09:21:35;
}


Notez que ce fichier peut être beaucoup plus long. Cherchez dedans le dernier bail obtenu. Constatez que vous avez bien la trace de toutes les informations que notre serveur DHCP est capable d'envoyer à ses clients.

 

9.4.3 - Particularités du client DHClient

 

Grâce aux informations conservées dans ce fichier dhclient.leases, ce client adopte un comportement un peu particulier, que l'on ne retrouve pas dans celui de Microsoft, par exemple.

Lorsqu'un hôte a obtenu un premier bail de la part du DHCP, l'adresse du serveur DHCP est conservée et, même après extinction et redémarrage de l'hôte au bout d'un temps bien supérieur à la durée de son bail, le client commencera par envoyer directement un DHCP request au serveur qu'il connaît. Cette particularité peut dérouter lorsque l'on espionne les dialogues DHCP sur le réseau.

 

10 - Savoir "Sniffer"

 

Un "sniffer" n'est pas un outil pour se "shooter", mais pour analyser les données qui se trimbalent sur le réseau. C'est un outil d'administrateur, qui est capable du meilleur comme du pire. Si vous voulez jouer avec, il en existe un tout à fait convenable et gratuit, aussi bien en version Linux que Windows, c'est Ethereal.
Il nécessite l'installation de la librairie libpcap, disponible elle aussi sous Linux comme sous Windows.

Nous allons juste ici analyser une capture de trames correspondant au dialogue DHCP, et constater que, lorsque ça va bien, ça se passe comme c'est dit dans les livres, ce qui est un peu réconfortant.

La manipulation est faite avec un client sous Windows XP.


10.1 - En-têtes de trames

 

 TCPIP IPV6 VOIP VPN IP IPV4 TCPIP


1 - Notre client se réveille, il n'a pas d'IP et utilise 0.0.0.0 pour faire un "broadcast général (255.255.255.255)". C'est le DHCP Discover.
2 - Notre serveur DHCP, qui a l'intention d'offrir à ce client l'IP 192.168.0.9, fait un ping sur cette adresse, histoire de voir si elle est réellement disponible sur le réseau.
3 - Comme il ne reçoit pas de réponse à son ping, il offre cette adresse au client.
4 - Le client fait alors un DHCP Request
5 - Le serveur accepte
6 - Le client fait un broadcast ARP pour vérifier de son côté que l'IP 192.168.0.9 n'est pas dupliquée sur le réseau.
7 - idem
8 - idem
9 - Là, commence le verbiage propre aux réseaux Microsoft...

Note à propos du ping :.
Ce ping fait "perdre" une seconde au processus d'attribution d'un bail. En effet, le serveur attend pendant une seconde une éventuelle réponse. Si vous êtes absolument sûr de votre réseau, vous pouvez désactiver ce ping dans le fichier de configuration de DHCPd, mais je ne vous le conseille pas.

 

10.2 - Détail des trames

 

Ce qui suit représente l'interprétation exhaustive des trames par le "sniffer". Il est évident qu'en lecture directe sur le réseau, on ne verrait qu'une suite d'octets difficilement interprétable par l'esprit humain.

La lecture en est certes un peu fastidieuse, mais elle est riche d'enseignements... Les points les plus importants sont marqués en gras.

 

10.2.1 - Le DHCP Discover

 

 TCPIP IPV6 VOIP VPN IP IPV4 TCPIP

 

10.2.2 - Un petit ping...

 

 TCPIP IPV6 VOIP VPN IP IPV4 TCPIP


Pas de réponse au ping, on peut continuer tranquille...

 

10.2.3 - Offre d'un nouveau bail

 

 TCPIP IPV6 VOIP VPN IP IPV4 TCPIP


Le serveur DHCP vient de proposer une configuration au client.

 

10.2.4 - Demande du Bail de la part du client

 

Il faut aussi, maintenant que le client fasse une demande explicite pour ce bail. N'oublions pas qu'il pourrait y avoir plusieurs DHCP qui répondent, il faut donc qu'il y ait une confirmation au serveur choisi par le client.

 TCPIP IPV6 VOIP VPN IP IPV4 TCPIP


C'est presque fini, il ne reste plus au serveur qu'à confirmer l'attribution de ce bail.

 

10.2.5 - Le serveur est d'accord

 

 TCPIP IPV6 VOIP VPN IP IPV4 TCPIP


Pas besoin de regarder de près ce qu'il se passe dans les broadcasts ARP que le client fait par la suite.

 

10.3 - Notes supplémentaires

 

10.3.1 - Duplication d'adresse

 

Que se serait-il passé, si l'adresse proposée par le serveur (ici 192.168.0.9) avait été déjà utilisée par un autre noeud du réseau ?

Je ne vous assommerai pas encore une fois avec un sniff, croyez-moi sur parole, j'ai fait la manip pour vérifier.

Dans ce cas, le serveur recevra un "echo reply" de la part du noeud utilisant cette IP et ne répondra pas au Discover. Le client, ne recevant pas de réponse, enverra un nouveau discover et le serveur lui proposera une autre IP.

 

10.3.2 - Pas de réponse

 

Et si le client qui a pris l'IP 192.168.0.9 ne répond pas aux pings ?

Ce sera la catastrophe annoncée. Le bail sera alloué et il y aura une duplication de l'IP sur le réseau. Mais les broadcast ARP fait par le client qui a reçu l'IP dupliquée mettra à jour cette duplication et la configuration échouera.

Cette situation ne devrait pas se produire sur un réseau proprement configuré. Elle ne devrait apparaître que s'il y a un utilisateur malveillant sur le réseau, qui force une configuration statique quand il ne le faut pas et qui bloque volontairement les échos ICMP.

Pour ceux qui n'ont pas peur de se plonger dans les Rfcs, vous trouverez celle qui traite du protocole Dhcp la Rfc 2131.

 

10.4 - Renouvellement d'un bail en cours de validité

 

Lorsque la durée du bail est inférieure à " l'uptime" du client, autrement dit, si votre client reste connecté plus longtemps que la durée de validité de son bail, il va devoir le renouveler.

Pour visualiser cette procédure, nous faisons un petit test, en diminuant la durée de vie du bail à quatre minutes, et nous sniffons :

 

10.4.1 - Quand ça se passe bien...

 

 TCPIP IPV6 VOIP VPN IP IPV4 TCPIP


Ca semble suffisamment parlant, au bout d'environ 120 secondes, soit 50% de la durée de vie du bail, le client essaye de le renouveler. Ca se passe bien, puisque le serveur répond toute de suite et ça repart pour 4 minutes. Inutile de regarder le détail des trames.

 

10.4.2 - Et quand ça se passe mal

 

Nous allons faire la même chose, mais en simulant une panne de serveur DHCP :

 TCPIP IPV6 VOIP VPN IP IPV4 TCPIP

Mais elle aurait pu mal finir, si ça avait été une bonne, vraie, grosse panne du serveur. En effet, une fois le bail expiré, le client perd bel et bien son IP et est éjecté de fait du réseau... Du temps où les câblés Wanadoo fonctionnaient sur ce système, ils n'ont pas manqué d'assister quelques fois à ce désolant spectacle.

 

11 - Suivi du document

 

En juin 2003, par

Christian, Ajout des chapitres 9 et 10 apportant les clients et des analyses de trames.

En septembre 2000, par Sylvain, création du document.

En Juin 2005, par Christophe Bruggeman, Ajout de quelques modification.

Le protocle TCP/IP et internet

 

 

 

 

Introduction

 

Quelques mots sur le protocole TCP/IP.

TCP/IP est un ensemble de logiciels développés au fil des années (à partir des années 70 déjà) qui constituent un "langage universel" de communication informatique à travers le monde. Le protocole devait posséder les qualités suivantes :

  1. une bonne reprise après panne
  2. la capacité à gérer un taux élevé d'erreurs
  3. une faible surcharge des données
  4. la capacité de se prolonger sans difficultés dans des sous-réseaux
  5. l'indépendance par rapport à un fournisseur particulier ou un type de réseau

A partir du 1er janvier 1983, seuls les paquets TCP/IP ont été transmis sur le réseau Arpanet (précurseur d'Internet). 1983 est donc en quelque sorte l'année de naissance d'Internet.

Il faut encore rajouter que TCP/IP se compose de deux protocoles distincts, IP et TCP, dont j'explique plus loin les rôles respectifs.

 

Le protocole IP

 

Le Protocole Internet ou IP (Internet Protocol) est la partie la plus fondamentale d'Internet. Si vous voulez envoyer des données sur internet, vous devez les "emballer" dans un paquet IP. Je parlerai plus loin de ces paquets IP. Il faut savoir pour l'instant que ces derniers ne doivent pas être trop gros; la plupart du temps, ils ne peuvent pas contenir toute l'information qu'on voudrait envoyer sur Internet, et cette dernière doit par conséquent être fractionnée en de nombreux paquets IP.

 

Les paquets IP, outre l'information, sont constitués d'un en-tête contenant l'adresse IP de l'expéditeur (votre ordinateur) et celle du destinataire (l'ordinateur que vous voulez atteindre), ainsi qu'un nombre de contrôle déterminé par l'information emballée dans le paquet : ce nombre de contrôle, communément appelé en-tête de total de contrôle, permet au destinataire de savoir si le paquet IP a été "abîmé" pendant son transport.

 

L'adresse IP

 

Une des choses les plus intéressantes du protocole TCP/IP est d'avoir attribué un numéro fixe, comme un numéro de téléphone, à chaque ordinateur connecté sur Internet; ce numéro est appelé l'adresse IP. Dans le cadre du standard actuel - IPV4 -, les adresses sont codés sur 32 bits. Ainsi, tout ordinateur sur Internet, par exemple le vôtre lorsque vous vous connectez par l'entremise de votre provider, se voit attribuer une adresse de type a.b.c.d (où a,b,c,d sont des nombres compris entre 0 et 255), par exemple 202.15.170.1. Dès ce moment, vous êtes le seul au monde à posséder ce numéro, et vous y êtes en principe directement atteignable.

 

Un rapide calcul vous montre qu'il y a, en théorie, un maximum de 2564 = 4'294'967'296 adresses possibles, ou, en d'autres termes, d'ordinateurs directement connectables, ce qui est plus que suffisant même à l'échelle mondiale (du moins à l'heure actuelle !). En fait, il y a beaucoup moins d'adresses que ce nombre impressionnant, car de nombreux numéros IP ne sont pas autorisés ou sont utilisés à des fins "techniques".

Pour l'ordinateur, cette adresse IP est codée en binaire (4 x 8 bits = 32 bits). Par exemple,

 

202

15

170

1

11001010

00001111

10101010

00000001

 

Il est clair que pour nous les humains, il est plus facile de retenir 202.15.170.1 que 11001010000011111010101000000001 !

 

Les différents types de réseaux

 

L'adressage a été structuré logiquement dans une architecture de réseaux et de sous-réseaux. N'importe qui ne peut s'approprier librement une adresse IP : ces dernières sont régies par un organisme international, l'Internic, qui délivre les différentes adresses ou plutôt les classes de réseaux.

  • Dans un réseau de classe A, l'Internic fixe les 8 premiers bits (dits bits de poids fort) sous la forme 0xxxxxxx; les 24 autres bits sont laissés à l'administration de l'acquéreur du réseau de classe A. Dans un tel réseau, les adresses IP sont donc de type F.b.c.d où F (fixé par L'Internic) va de 0 à 126, les valeurs b, c et d étant laissées librement administrables par l'acquéreur. De grandes sociétés ont ce type de réseau; par exemple, Hewlett-Packard possède le réseau 16.b.c.d (qu'on note aussi 16.0.0.0). Vous noterez que seuls 127 réseaux de ce type sont disponibles.

 

  • Dans un réseau de classe B, l'Internic fixe les 16 premiers bits sous la forme 10xxxxxx yyyyyyyy, ce qui donne des réseaux de type F.G.0.0 où F (128-191) et G (0 à 255) sont fixés par le NIC.

 

  • Dans un réseau de classe C, l'Internic fixe les 24 premiers bits sous la forme 110xxxxx yyyyyyyy zzzzzzzz, ce qui donne des réseaux de type F.G.H.0 où F (192-223), G et H (0-255) sont fixés par le NIC.

 

  • Tout le réseau 127.0.0.0 (qu'on peut voir comme un réseau de classe A) n'est pas attribué par l'Internic, car l'adresse 127.0.0.1, dite adresse de boucle, est réservée à des fins techniques. Dommage, car 24 millions d'adresses sont ainsi perdues !

 

  • De plus, l'Internic n'attribue pas non plus certains réseaux qui sont laissés à des fins privées. Ces plages d'adresses généralement non routées par les fournisseurs d'accès, en d'autres termes des plages attribuables tout à fait légalement pour des réseaux internes, vont

de 10.0.0.0 à 10.255.255.255
de 172.16.0.0 à 172.31.255.255
de 192.168.0.0 à 192.168.255.255

 

Typiquement, si vous créez votre propre réseau local en TCP/IP, vous utiliserez pour vos ordinateurs ce type d'adresses.

Il me faut encore rajouter que certaines adresses d'un réseau quelconque ne sont pas attribuables à un ordinateur précis, mais joue un rôle "technique" dans TCP/IP.

 

Prenons l'exemple d'un réseau de classe C comme 192.168.0.x, x pouvant varier entre 0 et 255.
Cette plage d'adresses doit être indiquée de manière officielle, et on utilise pour cela l'adresse générale 192.168.0.0, ce qui veut dire "toutes les adresses comprises entre 192.168.0.0 et 192.168.0.255". Remarquez que cela signifie que vous ne pourrez jamais attribuer l'adresse 192.168.0.0 à un ordinateur précis, puisque cette dernière fait référence à tout le réseau.

 

Il existe une autre adresse IP réservée : l'adresse de diffusion (broadcast). C'est la dernière adresse du sous-réseau, dans notre cas 192.168.0.255. Il s'agit de l'adresse que vous utilisez pour diffuser un message vers chaque ordinateur du sous-réseau concerné.

 

Finalement, vous devez réserver une adresse IP du routeur par défaut (gateway) : c'est l'adresse "passerelle" qui permettra à des paquets IP de "quitter" votre sous-réseau.

 

La subdivision en sous-réseaux

 

Comment un ordinateur transmet-il l'information (les paquets IP) à son destinataire ? Une partie de la réponse se trouve dans le fonctionnement du protocole IP.

 

Généralement, un ordinateur ne peut transmettre directement un paquet IP qu'à un ordinateur situé sur le même sous-réseau. Par exemple, un ordinateur possédant l'adresse IP 192.168.0.2 pourra directement envoyer de l'information à un ordinateur "voisin" d'adresse 192.168.0.20, mais il ne pourra pas le faire avec un ordinateur d'adresse 194.38.175.55. Pour simplifier, on dira en première approche qu'un ordinateur ne peut communiquer directement qu'avec un ordinateur possédant les trois premiers nombres de l'adresse IP identiques. Cette remarque n'est malheureusement pas théoriquement juste (même si en pratique, c'est assez souvent le cas pour des réseaux simples). En fait, c'est le concept de masque de sous-réseau qui définit ce qu'un ordinateur peut "voir" ou ne pas voir.

 

Le masque de sous-réseau que vous avez peut-être eu l'occasion d'utiliser, si vous utilisez TCP/IP pour un réseau local, est 255.255.255.0. Ce masque veut dire que l'ordinateur concerné peut "voir" (ou communiquer avec) tous les ordinateurs possédant les trois premiers nombres de l'adresse IP identiques, comme je l'ai indiqué à l'exemple précédent. Comment fonctionne ce système à première vue aussi compliqué ?

 

En fait, admettons que l'ordinateur A d'adresse IP 199.34.57.10 veuille envoyer un paquet IP à l'ordinateur B d'adresse IP 199.34.57.20. A priori, A ne sait pas s'il peut communiquer directement avec B. Pour cela, il utilise le masque de sous-réseau 255.255.255.0 qu'on lui a imposé. Il "convertit" le tout en binaire, ce qui donne :

11111111

11111111

11111111

00000000

masque sous-réseau

11000111

00100010

00111001

00001010

adresse de A

11000111

00100010

00111001

00010100

adresse de B

 

L'ordinateur A doit s'assurer que partout où le masque de sous-réseau a une valeur de 1, la valeur binaire de son adresse IP corresponde à celle de B. Dans l'exemple ci-dessus, il n'est pas difficile de voir que c'est le cas; finalement, les 8 derniers bits de valeur 0 indiquent que le dernier nombre de l'adresse IP est indifférent pour A : ce dernier verra donc tous les ordinateurs d'adresse 199.34.57.x, x étant compris entre 0 et 255.

 

Cet exemple paraît trivial, pourtant de nombreux réseaux comportent des masques de sous-réseaux moins compréhensibles (pas uniquement des 0 et des 255), comme par exemple 255.255.255.224. Si vous refaites le même raisonnement, vous verrez qu'avec un tel masque, l'ordinateur 192.168.0.2 ne peut directement communiquer avec l'ordinateur 192.168.0.100 ! En fait, les 256 adresses de ce réseau de classe C seront comme subdivisées en 8 sous-réseaux de 32 ordinateurs.
Ainsi, les ordinateurs 192.168.0.0 à 192.168.0.31 pourront communiquer entre eux, de mêmes que les ordinateurs 192.168.0.32 à 192.168.0.63,

les ordinateurs 192.168.0.64 à 192.168.0.95,
les ordinateurs 192.168.0.96 à 192.168.0.127,
les ordinateurs 192.168.0.128 à 192.168.0.159,
les ordinateurs 192.168.0.160 à 192.168.0.191,
les ordinateurs 192.168.0.192 à 192.168.0.223,
et les ordinateurs 192.168.0.224 à 192.168.0.255,

mais ces sous-réseaux ne pourront pas communiquer directement entre eux.

 

Cette subdivision d'un réseau de classe C en plusieurs sous-réseaux peut être utile pour un fournisseur d'accès. Vous pouvez calculer aisément les masques de sous-réseaux suivants selon le nombre de sous-réseaux que vous souhaitez créer.

 

nombre de sous-réseaux

IP par sous-réseau

masque de sous-réseau

1

256

255.255.255.000

2

128

255.255.255.128

4

64

255.255.255.192

8

32

255.255.255.224

16

16

255.255.255.240

32

8

255.255.255.248

 

En fait, nous avons vu au paragraphe précédent que pour chaque sous-réseau il faut déduire trois adresses IP non attribuables à un ordinateur :

  1. l'adresse de sous-réseau (généralement le premier IP du sous-réseau), par exemple a.b.c.0 pour un réseau composé d'un seul sous-réseau, ou a.b.c.64 pour le troisième sous-réseau d'un réseau divisé en 8 sous-réseaux.
  2. l'adresse de diffusion (généralement le dernier IP du sous-réseau), par exemple, en reprenant les deux exemples précédents, a.b.c.255 ou a.b.c.95.
  3. l'adresse du routeur par défaut dont je parle un peu plus loin, par exemple a.b.c.1 ou a.b.c.65.

Chaque sous-réseau "perd" donc trois adresses IP; il s'ensuit qu'une subdivision excessive d'un réseau n'est pas avantageuse (on divise rarement au-delà de 8 sous-réseaux).

 

Le routage des paquets IP et le protocole TCP

 

Revenons à notre ordinateur A d'adresse 192.168.0.2 (mettons-lui un masque de sous-réseau de 255.255.255.0). Admettons qu'il veuille envoyer un paquet IP à ordinateur B d'adresse 192.170.0.4. En utilisant le masque de sous-réseau, A comprend qu'il ne peut atteindre directement B. Que fait-il donc ? Il envoie sans réfléchir le paquet IP à l'adresse du routeur par défaut (disons que ce dernier a été défini comme 192.168.0.254).

 

Qu'est-ce que ce routeur ? Le routeur est une machine pouvant "jouer sur plusieurs sous-réseaux" en même temps. Typiquement, si on utilise un ordinateur, ce dernier possèdera deux cartes réseaux (ou plus), l'une connectée sur l'un des sous-réseaux (dans notre cas, disons qu'elle possède l'adresse 192.168.0.254), l'autre connectée sur l'autre sous-réseau (disons 192.170.0.192). S'il utilise le bon logiciel, un tel ordinateur est capable de faire transiter des paquets IP du réseau 192.168.0.0 vers le réseau 192.170.0.0, et inversément bien sûr.

 

Deux petites remarques s'imposent. Tout d'abord, vous l'aurez compris, c'est donc grâce à des routeurs que différents sous-réseaux d'un réseau de classe C peuvent communiquer entre eux, par exemple l'ordinateur 192.168.0.2 avec l'ordinateur 192.168.0.120 d'un réseau de classe C subdivisé en 8 sous-réseaux (masque de sous réseau 255.255.255.224). La seconde remarque est d'ordre plus pratique : vous retiendrez que Windows 95 n'est pas capable de faire du routage, bien qu'il soit tout à fait possible d'installer deux cartes réseaux (avec des IP différents) dans un ordinateur tournant sous ce système; par contre, Windows NT 4.0, même en version Workstation, est capable d'une telle fonction.

 

Question pertinente : pourquoi subdiviser et ne pas faire de "méga" réseaux ?
Les deux points suivants expliquent en partie pourquoi on procède ainsi.

 

  1. Limiter le trafic sur un tronçon donné. Imaginons deux réseaux locaux A et B séparés par un routeur. Lorsque des ordinateurs de A discutent avec des ordinateurs de B, le routeur a pour rôle de transmettre l'information du réseau A vers le réseau B (et inversément). Par contre, si des ordinateurs de A s'échangent entre eux des données, il n'y a pas de raison qu'ils encombrent inutilement le trafic sur le réseau B, et c'est bien pour cette raison que les réseaux A et B sont distincts.

    Autre évidence : si le réseau A tombe en panne, le réseau B n'en est pas affecté. C'est d'ailleurs l'avantage principal de subdiviser : éviter qu'un ennui technique qui pourrait rester localisé ne perturbe la totalité du réseau
  2. Autre aspect non négligeable : le broadcast (diffusion). Vous ne le savez peut-être pas, mais dans votre dos, les ordinateurs sont de grands bavards : ils ne cessent de causer entre eux pour signaler leur présence ou se mettre d'accord sur les protocoles qu'ils sont capables de comprendre. Pensez un peu si Internet n'était constitué que d'un seul segment : le broadcast seul des ordinateurs utiliserait l'intégralité de la bande passante avant même qu'un seul octet de données ait pu être transmis ! Pour cette raison, le travail des routeurs est non seulement de faire transiter les paquets IP, mais aussi de filtrer le broadcast local qui n'intéresse pas la planète entière. Vous comprendrez par là que les routeurs jouent un rôle essentiel pour éviter la saturation du trafic.

Disons encore quelques mots sur l'acheminement des paquets IP. Vous comprenez maintenant que lorsqu'un ordinateur doit acheminer un paquet IP, il vérifie tout d'abord s'il peut le transmettre directement (grâce au masque de sous-réseau); s'il ne peut pas, il l'envoie bêtement, sans réfléchir, au routeur par défaut. A partir de là, les routeurs sont généralement configurés pour savoir où diriger les paquets IP qui leur sont confiés; les routeurs bavardent entre eux (à l'aide de protocoles particuliers de routage, RIP ou OSPF par exemple) pour savoir quelle est la meilleure route (la plus courte généralement) pour qu'un paquet IP atteigne sa destination. De même, si une route est soudainement interrompue, les routeurs sont capables de se reconfigurer et proposer des nouvelles routes de secours.

 

Or le protocole IP néglige un point crucial : il ne vérifie nullement le bon acheminement des paquets IP. En d'autres termes, l'ordinateur expéditeur, dans le protocole IP, ne fait qu'envoyer le paquet IP plus loin; il ne s'intéresse pas du tout de savoir si le paquet a bien été reçu ou s'il a été endommagé pendant le transfert !

 

Qui doit donc assurer l'intégrité point à point, si ce n'est IP ? La réponse : son copain, TCP.

 

Le protocole de contrôle de transmission ou TCP (Transmission Control Protocol) vérifie donc le bon acheminement d'un paquet IP. Cela se fait de la façon suivante. Admettons que A veuille transmettre un paquet IP à B. A envoie (un peu à l'aveugle) son paquet IP à B, un peu comme une bouteille à la mer. Tant que A ne recevra pas un accusé de réception de B lui indiquant que ce dernier a bien reçu le paquet IP dans son intégrité (grâce à l'en-tête de total de contrôle), il renverra à intervalles réguliers le même paquet IP à B. Il n'arrêtera d'envoyer ce paquet qu'à la confirmation de B. Ce dernier agira ensuite de même s'il doit transmettre le paquet plus loin. Si B constate que le paquet qu'il a reçu est abimé, il n'enverra pas de confirmation, de manière à ce que A lui renvoie un paquet "neuf".

 

TCP fournit d'autres services sur lequels je ne m'attarderai pas ici. On résumera rapidement les principales fonctionnalités du protocole TCP ainsi :

 

  • l'établissement d'une liaison
  • le séquençage des paquets
  • le contrôle de flux
  • la gestion d'erreurs
  • le message d'établissement d'une liaison

 

On entend par "contrôle de flux" la capacité de TCP, entre autres, de reconstituer l'information originale à partir de paquets IP arrivés (souvent) dans le désordre le plus absolu.

 

C'est aussi TCP qui gère la notion de "sockets" (ports) dont je parle dans la partie concernant la façon de configurer un réseau local et le connecter à Internet.

 

Le système de désignation de noms (DNS)

 

Maintenant que vous avez compris (j'espère !) comment circulent les paquets IP à travers Internet, il me reste à donner rapidement quelques explications sur le système de désignation de noms, en anglais Domain Name System (DNS). Vous avez vu plus haut que tout ordinateur connecté à Internet possède un numéro IP qui lui est propre. Pour communiquer avec un autre ordinateur, il vous faut connaître son adresse IP. Or, lorsque vous "surfez" sur le net, vous écrivez très rarement de tels numéros dans votre browser. C'est tout simplement que vous faites appel, sans le savoir, à un serveur DNS.

 

Un serveur DNS est simplement une machine qui associe le numéro IP à une adresse plus facilement mémorisable, bref une sorte d'annuaire téléphonique pour Internet. Ainsi, la machine qui répond lorsque vous tapez http://www.microsoft.com dans votre browser possède en fait l'adresse IP 207.68.137.65. Si vous tapiez http://207.68.137.65, vous obtiendriez exactement le même résultat. Un (ou plusieurs) serveur DNS se trouvent généralement chez votre provider; vous avez d'ailleurs sûrement reçu une feuille de configuration vous indiquant une ou deux adresses IP pour ces serveurs lors de la configuration de votre connexion à votre provider.

 

Une manière simple de constater l'utilité d'un serveur DNS est d'ouvrir (sous Windows 95) une fenêtre DOS, et de taper ping 'adresse de l'hôte', par exemple ping www.microsoft.com. "Ping" est une fonction très utile dans l'établissement de réseau : c'est une commande qui envoie un paquet IP tout simple à un ordinateur et lui demande simplement de répondre.
Sous Windows 95, quatre paquets IP sont envoyés, et si vous avez avez tapé 'ping www.microsoft.com' par exemple, votre ordinateur devrait ensuite vous écrire une ligne de type :

pinging www.microsoft.com [207.68.137.65] with 32 bytes of data

 

suivie de quatre lignes de la forme :

 

reply from 207.68.137.65: bytes=32 time=550ms TTL=128

 

 

Ces quatre dernières lignes vous indiquent que le serveur Microsoft a répondu à vos appels et vous montrent le temps total qu'a pris la transaction pour chaque ping (par exemple 550 millisecondes). Vous noterez surtout que le serveur DNS de votre provider aura fait automatiquement la translation www.microsoft.com <-> 207.68.137.65.

 

PS : J'ai parlé plus haut de l'adresse IP réservée 127.0.0.1, dite adresse de boucle; un ping sur cette adresse correspond à un ping "sur soi-même", ce qui permet de tester la bonne marche de la carte réseau.

 

Résumé et exemples

 

Résumons en quelques points ce que nous avons vu sur les réseaux TCP/IP.

 

  1. Chaque ordinateur sur Internet possède une adresse IP, par exemple 195.235.4.6
  2. Les adresses IP définissent les termes de réseaux ou de sous-réseaux. C'est un organisme international, l'Internic, qui attribue les différentes adresses ou les différents réseaux (classe A, B, C). Ce sont ensuite les entreprises qui ont acheté les réseaux qui peuvent les subdiviser en sous-réseaux grâce à l'utilisation de masques de sous-réseaux adéquats.
  3. De nombreuses adresses IP ne sont pas utilisées.
    • L'Internic tout d'abord conserve des adresses utilisables à des fins privées, par exemple les adresses de type 192.168.0.x
    • L'administrateur d'un réseau doit toujours mettre de côté trois adresses IP par sous-réseau : l'adresse de sous-réseau (par exemple 192.168.0.0), l'adresse de diffusion (par exemple 192.168.0.255) et l'adresse du routeur par défaut.

 

 

  1. Pour communiquer, l'ordinateur expéditeur fragmente l'information à envoyer en de nombreux paquets IP qui contiennent, outre l'information, les adresses IP de l'expéditeur et du destinataire ainsi qu'un en-tête de total de contrôle.
  2. Les paquets IP ne peuvent être transmis directement qu'à un ordinateur du même sous-réseau (défini par le masque de sous-réseau). Si l'ordinateur destinataire ne peut être atteint, l'ordinateur expéditeur envoit le paquet IP à l'adresse du routeur par défaut qui lui a été spécifié.
  3. Le routeur est une machine qui fait transiter les paquets d'un réseau à un autre (ou d'un sous-réseau à un autre) et qui utilise donc plusieurs adresses IP (une sur chacun des sous-réseaux couverts). Par exemple, un routeur possédant les deux adresses IP 196.129.0.1 et 197.160.40.91 peut faire passer des paquets IP du réseau 196.129.0.0 au réseau 197.160.40.0, et inversément.
  4. Le protocole IP ne s'occupe que de l'acheminement des paquets IP. La vérification du transfert de l'intégrité des données est effectuée par le protocole TCP.

 

Si vous désirez maintenant approfondir un peu le sujet, consultez le chapitre suivant, le protocole TCP/IP (avancé).

Le modèle TCP/IP Introduction

 

 

 

 

Introduction

 

TCP/IP désigne communément une architecture réseau, mais cet acronyme désigne en fait 2 protocoles étroitement liés : un protocole de transport, TCP (Transmission Control Protocol) qu'on utilise "par-dessus" un protocole réseau, IP(Internet Protocol). Ce qu'on entend par "modèle TCP/IP", c'est en fait une architecture réseau en 4 couches dans laquelle les protocoles TCP et IP jouent un rôle prédominant, car ils en constituent l'implémentation la plus courante. Par abus de langage, TCP/IP peut donc désigner deux choses : le modèle TCP/IP et la suite de deux protocoles TCP et IP.

Le modèle TCP/IP, comme nous le verrons plus bas, s'est progressivement imposé comme modèle de référence en lieu et place du modèle OSI. Cela tient tout simplement à son histoire. En effet, contrairement au modèle OSI, le modèle TCP/IP est né d'une implémentation ; la normalisation est venue ensuite. Cet historique fait toute la particularité de ce modèle, ses avantages et ses inconvénients.

L'origine de TCP/IP remonte au réseau ARPANET. ARPANET est un réseau de télécommunication conçu par l'ARPA (Advanced Research Projects Agency), l'agence de recherche du ministère américain de la défense (le DOD : Department of Defense). Outre la possibilité de connecter des réseaux hétérogènes, ce réseau devait résister à une éventuelle guerre nucléaire, contrairement au réseau téléphonique habituellement utilisé pour les télécommunications mais considéré trop vulnérable. Il a alors été convenu qu'ARPANET utiliserait la technologie de commutation par paquet (mode datagramme), une technologie émergeante promettante. C'est donc dans cet objectif et ce choix technique que les protocoles TCP et IP furent inventés en 1974. L'ARPA signa alors plusieurs contrats avec les constructeurs (BBN principalement) et l'université de Berkeley qui développait un Unix pour imposer ce standard, ce qui fut fait.

 

Description du modèle

 

2.1 - Un modèle en 4 couches

 

Le modèle TCP/IP peut en effet être décrit comme une architecture réseau à 4 couches :

 

 

Le modèle OSI a été mis à côté pour faciliter la comparaison entre les deux modèles.

 

2.2 - La couche hôte réseau

 

Cette couche est assez "étrange". En effet, elle semble "regrouper" les couches physique et liaison de données du modèle OSI. En fait, cette couche n'a pas vraiment été spécifiée ; la seule contrainte de cette couche, c'est de permettre un hôte d'envoyer des paquets IP sur le réseau. L'implémentation de cette couche est laissée libre. De manière plus concrète, cette implémentation est typique de la technologie utilisée sur le réseau local. Par exemple, beaucoup de réseaux locaux utilisent Ethernet ; Ethernet est une implémentation de la couche hôte-réseau.

 

2.3 - La couche internet

 

Cette couche est la clé de voûte de l'architecture. Cette couche réalise l'interconnexion des réseaux (hétérogènes) distants sans connexion. Son rôle est de permettre l'injection de paquets dans n'importe quel réseau et l'acheminement des ces paquets indépendamment les uns des autres jusqu'à destination. Comme aucune connexion n'est établie au préalable, les paquets peuvent arriver dans le désordre ; le contrôle de l'ordre de remise est éventuellement la tâche des couches supérieures.

Du fait du rôle imminent de cette couche dans l'acheminement des paquets, le point critique de cette couche est le routage. C'est en ce sens que l'on peut se permettre de comparer cette couche avec la couche réseau du modèle OSI.

La couche internet possède une implémentation officielle : le protocole IP (Internet Protocol).

Remarquons que le nom de la couche ("internet") est écrit avec un i minuscule, pour la simple et bonne raison que le mot internet est pris ici au sens large (littéralement, "interconnexion de réseaux"), même si l'Internet (avec un grand I) utilise cette couche.

 

2.4 - La couche transport

 

Son rôle est le même que celui de la couche transport du modèle OSI : permettre à des entités paires de soutenir une conversation.

Officiellement, cette couche n'a que deux implémentations : le protocole TCP (Transmission Control Protocol) et le protocole UDP (User Datagram Protocol). TCP est un protocole fiable, orienté connexion, qui permet l'acheminement sans erreur de paquets issus d'une machine d'un internet à une autre machine du même internet. Son rôle est de fragmenter le message à transmettre de manière à pouvoir le faire passer sur la couche internet. A l'inverse, sur la machine destination, TCP replace dans l'ordre les fragments transmis sur la couche internet pour reconstruire le message initial. TCP s'occupe également du contrôle de flux de la connexion.

UDP est en revanche un protocole plus simple que TCP : il est non fiable et sans connexion. Son utilisation présuppose que l'on n'a pas besoin ni du contrôle de flux, ni de la conservation de l'ordre de remise des paquets. Par exemple, on l'utilise lorsque la couche application se charge de la remise en ordre des messages. On se souvient que dans le modèle OSI, plusieurs couches ont à charge la vérification de l'ordre de remise des messages. C'est là une avantage du modèle TCP/IP sur le modèle OSI, mais nous y reviendrons plus tard. Une autre utilisation d'UDP : la transmission de la voix. En effet, l'inversion de 2 phonèmes ne gêne en rien la compréhension du message final. De manière plus générale, UDP intervient lorsque le temps de remise des paquets est prédominant.

 

2.5 - La couche application

 

Contrairement au modèle OSI, c'est la couche immédiatement supérieure à la couche transport, tout simplement parce que les couches présentation et session sont apparues inutiles. On s'est en effet aperçu avec l'usage que les logiciels réseau n'utilisent que très rarement ces 2 couches, et finalement, le modèle OSI dépouillé de ces 2 couches ressemble fortement au modèle TCP/IP.

Cette couche contient tous les protocoles de haut niveau, comme par exemple Telnet, TFTP (trivial File Transfer Protocol), SMTP (Simple Mail Transfer Protocol), HTTP (HyperText Transfer Protocol). Le point important pour cette couche est le choix du protocole de transport à utiliser. Par exemple, TFTP (surtout utilisé sur réseaux locaux) utilisera UDP, car on part du principe que les liaisons physiques sont suffisamment fiables et les temps de transmission suffisamment courts pour qu'il n'y ait pas d'inversion de paquets à l'arrivée. Ce choix rend TFTP plus rapide que le protocole FTP qui utilise TCP. A l'inverse, SMTP utilise TCP, car pour la remise du courrier électronique, on veut que tous les messages parviennent intégralement et sans erreurs.

 

Comparaison avec le modèle OSI et critique

 

Comparaison avec le modèle OSI

 

Tout d'abord, les points communs. Les modèles OSI et TCP/IP sont tous les deux fondés sur le concept de pile de protocoles indépendants. Ensuite, les fonctionnalités des couches sont globalement les mêmes.

Au niveau des différences, on peut remarquer la chose suivante : le modèle OSI faisait clairement la différence entre 3 concepts principaux, alors que ce n'est plus tout à fait le cas pour le modèle TCP/IP. Ces 3 concepts sont les concepts de services, interfaces et protocoles. En effet, TCP/IP fait peu la distinction entre ces concepts, et ce malgré les efforts des concepteurs pour se rapprocher de l'OSI. Cela est dû au fait que pour le modèle TCP/IP, ce sont les protocoles qui sont d'abord apparus. Le modèle ne fait finalement que donner une justification théorique aux protocoles, sans les rendre véritablement indépendants les uns des autres.

Enfin, la dernière grande différence est liée au mode de connexion. Certes, les modes orienté connexion et sans connexion sont disponibles dans les deux modèles mais pas à la même couche : pour le modèle OSI, ils ne sont disponibles qu'au niveau de la couche réseau (au niveau de la couche transport, seul le mode orienté connexion n'est disponible), alors qu'ils ne sont disponibles qu'au niveau de la couche transport pour le modèle TCP/IP (la couche internet n'offre que le mode sans connexion). Le modèle TCP/IP a donc cet avantage par rapport au modèle OSI : les applications (qui utilisent directement la couche transport) ont véritablement le choix entre les deux modes de connexion.

 

Critique

 

Une des premières critiques que l'on peut émettre tient au fait que le modèle TCP/IP ne fait pas vraiment la distinction entre les spécifications et l'implémentation : IP est un protocole qui fait partie intégrante des spécifications du modèle.

Une autre critique peut être émise à l'encontre de la couche hôte réseau. En effet, ce n'est pas à proprement parler une couche d'abstraction dans la mesure où sa spécification est trop floue. Les constructeurs sont donc obligés de proposer leurs solutions pour "combler" ce manque. Finalement, on s'aperçoit que les couches physique et liaison de données sont tout aussi importantes que la couche transport. Partant de là, on est en droit de proposer un modèle hybride à 5 couches, rassemblant les points forts des modèles OSI et TCP/IP :


Modèle hybride de référence


  • C'est finalement ce modèle qui sert véritablement de référence dans le monde de l'Internet. On a ainsi gardé la plupart des couches de l'OSI (toutes, sauf les couches session et présentation) car correctement spécifiées. En revanche, ses protocoles n'ont pas eu de succès et on a du coup gardé ceux de TCP/IP.

 

 

20:22 Écrit par Kpanou dans PC Personnel Compunter | Lien permanent | Commentaires (0) | |  del.icio.us | | Digg! Digg |  Facebook | | Pin it! |  Imprimer | | |

Les commentaires sont fermés.