Aldevar

J’ai longuement hésité à mettre ce rapport de stage en ligne pour plusieurs raisons. Tout d’abord, ce rapport n’est pas vraiment représentatif du travail fournit. La majorité des solutions expliquées m’ont demandées beaucoup de temps de recherche et d’arrachage de cheveux (notamment pour la migration des comptes sous Lotus Notes). Ensuite, la qualité rédactionnel est loin d’être au rendez-vous. On m’a beaucoup reproché que ce rapport était trop technique et c’est plutôt vrai. Enfin, ce document ne décrit pas vraiment l’installation de Squid et d’Egroupware. Ces parties sont survolées et je m’attarde plus sur la résolution des problèmes rencontrés (résoudre un conflit de schéma LDAP quand on a jamais vu OpenLDAP de sa vie n’est pas chose aisée).

Un mois après la fin de la formation, je me décide tout de même à le mettre en ligne. Je pense que ce rapport décrit plutôt bien ce que peut être le métier de technicien réseau dans une administration ou une PME. Le problème lors de la mise en place d’un nouveau service n’est pas l’installation et la configuration de ce service mais la migration des anciens services utilisés vers les nouveaux. Surtout lorsque l’ancien service est un système propriétaire vieillissant (Je veux parler ici de Lotus Notes 5).

Squid est un proxy http très utilisé, dont j’ai pu découvrir une partie des possibilités. Egroupware est un groupware fournissant un agenda, un client mail, un carnet d’adresses, un système de réservations des ressources et plusieurs autres choses, le tout dans une interface web. Je vous invite à tester la demo sur le site du projet.

Ce rapport fait 38 pages et voici son sommaire :

1. Remerciements
2. Objectif du stage
3. L’entreprise
   1. Historique
   2. La structure actuelle
   3. Le service informatique
4. Spécifications
   1. Environnement de travail
   2. L’existant
   3. Besoins et contraintes
      1. Squid
      2. Egroupware
5. Mise en œuvre
   1. Proxy
      1. Planning prévisionnel
      2. Mise en œuvre
         1. Squid
         2. Sarg
         3. Squidguard
      3. Problèmes rencontrés
      4. Annexes
   2. eGroupware
      1. Schéma fonctionnel
      2. Planning previsionnel
      3. Mise en œuvre
         1. Configuration de openldap
      4. Problèmes rencontrés
         1. Conflit de schéma openldap
         2. Configuration de felamimail
      5. Préparation de la migration des utilisateurs
         1. Création du carnet d’adresses principal
         2. Importation des agendas Lotus Notes
         3. Importation des carnet d’adresse Lotus Notes
         4. Exportation des mails depuis LotusNotes dans eGroupware
         5. Importation mail depuis roundcube
      6. Annexes
6. Procédure de migration serveur
   1. Sur Revy
   2. Sur Revnew

Lien de téléchargement (pdf)

Suite de la Question Réseau Qui Va Bien, nouveau billet purement réseau donc. Je comptais me lancer dans la description des paquets TCP, mais je pense qu’il est plus intéressant de se pencher d’abord sur UDP avant d’appréhender TCP.

UDP (Pour User Datagram Protocol) se situe dans la couche 4 du modèle OSI (couche transport). Pour rappel, au niveau de la couche 3 (IP), les datagrammes sont routés d’une machine à une autre en fonction des adresses IP (en fait, le routage se fait en fonction de l’adresse réseau, voir QRQVB : L’adresse IP). Lors de cette opération de routage, aucune distinction n’est faite entre les différents services pour lesquels ces paquets peuvent être destinés. Que ce soit pour une connexion SSH (port 22) ou HTTP (port 80) ou autre, les datagrammes IP sont tous indifféremment mélangés.

La couche 4 du modèle OSI ajoute un mécanisme qui permet l’identification du service  concerné. Plusieurs programmes de plusieurs utilisateurs pouvant simultanément circuler sur le réseau, il est indispensable de faire un tri entre les applications. Ici, l’idée est d’associer la destination du paquet à une fonction. L’identification de cette fonction ce fait à l’aide d’un chiffre nommé Port.

En tête UDP

Lors de l’étude des datagramme IP, nous avions vu le contenu de l’entête du paquet (partie verte). Ici,  nous allons observer le contenu de l’entête du message (partie jaune) lorsque l’on traite un paquet UDP.

Le paquet UDP est composé de 8 octets.

Les 2 premiers octets contiennent le port source. Codé sur 16 bits donc. C’est le numéro de port de l’émetteur du paquet. C’est aussi le numéro de port sur lequel le destinataire doit envoyer sa réponse.

Les octets 3 et 4 stockent le port de destination. C’est sur ce port que sera remis le paquet lors de sa livraison à la machine ciblée.

Le port étant un entier positif de 16 bits, on en déduit que les bornes sont 0 – 65535 (2^16). Cependant, le port 0 n’est pas exploitable.

Les octets 5 et 6 contiennent la longueur de l’entête UDP et du message. Sa longueur minimal est 8 (entête UDP avec 0 données à transporter) et sa longueur maximal 2^16 = 65535 (64ko).

Les 2 derniers octets contiennent le cheksum. C’est la somme de contrôle de l’entête UDP et des données qui suivent.

Ports réservés

Toute machine qui utilise la pile TCP/IP se doit de connaitre un certains nombre de services bien connus, aussi appelé « well known port number » pour pouvoir dialoguer avec les autres machines sur internet. Sur une machines Unix, cette liste est placée dans le fichier /etc/services et se doit d’être lisible par tous les utilisateurs et toutes les applications. Voici un extrait du contenu de ce fichier :

Nom             Port/Protocol     Commentaire

netstat		15/tcp
 qotd		17/tcp		quote
 msp		18/tcp		# message send protocol
 msp		18/udp
 chargen	19/tcp		ttytst source
 chargen	19/udp		ttytst source
 ftp-data	20/tcp
 ftp		21/tcp
 fsp		21/udp		fspd
 ssh		22/tcp		# SSH Remote Login Protocol
 ssh		22/udp
 telnet		23/tcp
 smtp		25/tcp		mail
 time		37/tcp		timserver
 time		37/udp		timserver
 rlp		39/udp		resource	# resource location
 nameserver	42/tcp		name		# IEN 116
 whois		43/tcp		nicname
 tacacs		49/tcp				# Login Host Protocol (TACACS)
 tacacs		49/udp
 re-mail-ck	50/tcp				# Remote Mail Checking Protocol
 re-mail-ck	50/udp
 domain		53/tcp				# name-domain server
 domain		53/udp
 mtp		57/tcp				# deprecated
 tacacs-ds	65/tcp				# TACACS-Database Service
 tacacs-ds	65/udp
 bootps		67/tcp				# BOOTP server
 bootps		67/udp
 bootpc		68/tcp				# BOOTP client
 bootpc		68/udp
 tftp		69/udp
 gopher		70/tcp				# Internet Gopher
 gopher		70/udp
 rje		77/tcp		netrjs
 finger		79/tcp
 www		80/tcp		http		# WorldWideWeb HTTP
 www		80/udp				# HyperText Transfer Protocol

Les ports 1 à 1023 sont réservés aux « well known ports ». Ils ne peuvent être utilisés que par des applications qui s’exécutent avec des droits privilégiés (root). Les autres ports peuvent être utilisés librement sans privilège particulier et sont en général employés par les applications clientes. Par exemple, sur ma machine, en ce moment, mon client IRC utilise le port 59175 pour communiquer avec le serveur irc holmes.freenode.net.

Mode non connecté

Contrairement à TCP, UDP est conçu pour permettre un échange de données entre 2 applications sans échange préliminaire. UDP est utilisé si les données à transmettre n’ont pas besoin d’être fragmentées en plusieurs paquet. La paquet est ainsi envoyé sans s’assurer qu’il arrive bien à destination. UDP est appelé mode de transport non connecté par opposition à TCP. Plus particulièrement, les paquets a destination d’une application UDP sont conservés dans une pile de type FIFO. Si l’application destinatrice ne les “consomme” pas assez rapidement, les plus anciens paquets risquent d’être écrasés par les plus récents… Un risque supplémentaire de perte de données.

Nous verrons comment TCP peut palier à ce problème dans la prochaine QRQVB

Une grande partie du travail sur les forums concernant les logiciels libres est d’obtenir plus d’informations sur les problèmes des novices. Il est très agréable d’aider les autres comme il peut être assez agaçant d’essayer d’aider quelqu’un qui ne montre aucun effort pour s’aider lui-même. Je ne pense pas que cela soit dû à de la fainéantise de la part de celui qui pose la question. C’est simplement parce que les novices ne connaissent pas les premières étapes de résolution des problèmes sur GNU/Linux et ne savent pas quels types d’informations rechercher ni comment les obtenir. J’espère que ce petit guide sera utile pour ceux qui font leurs premiers pas sur linux.

I -  Diagnostiquer soi-même

1 – La première étape est la collecte d’informations.

Si un programme plante ou ne fait pas ce qu’il est censé faire, il faut se poser et réfléchir calmement. Ouvrez un nouveau fichier dans votre éditeur de texte favori et écrivez-y ce que vous faisiez quand le problème est apparu ainsi que tous les messages d’erreurs reçus. Ces messages d’erreurs doivent être recopiés exactement tel qu’ils sont apparus. Utilisez le copier/coller si cela est possible.

Ouvrez un terminal et tapez tail /var/log/messages. Cette commande affichera les 10 dernières lignes des logs du système. Si celui ci contient un ou des messages qui sont clairement en rapport avec votre problème, recopiez les également. Les erreurs des applications graphiques sont en général dans le fichier .Xsession-errors ou .xsession-errors dans votre dossier /home. La commande pour visualiser les 10 dernières lignes est donc tail ~/.xsession-errors. Comme pour le fichier /var/log/messages, ajoutez les lignes en rapport avec votre problème dans votre fichier de départ.
Si vous n’avez trouvé aucune information dans ces fichiers, essayez de lancer l’application concernée depuis votre terminal. Lors de l’apparition du bug, des messages devraient s’afficher.

Si votre système ne démarre plus suite à un problème, démarrez alors sur une autre distribution (soit en dual-boot si vous en avez soit depuis un live-cd). Il est toujours bon d’avoir un live-cd sous la main pour ce genre d’opération. Une fois que vous avez démarré sur le live-cd, montez votre partition root et récupérez les informations dans les fichiers cités plus haut.

2 – Le problème est-il reproductible?

S’il est possible de reproduire le problème facilement, faites-le. N’oubliez pas de le faire sur des fichiers peu important ou sur une copie du fichier concerné afin de ne pas endommager vos données.

3 – Est-ce un problème matériel ?

Les problèmes non reproductibles sont souvent dus au matériel. Si vous pensez que c’est le cas, regardez alors dans le fichier /var/log/boot ainsi que /var/log/kern.log ou /var/log/kernel.log suivant votre distribution pour voir si le kernel reconnait bien votre matériel. Ce fichier étant très long, la commande tail ne vous sera pas d’un grand secours. Utilisez plutôt less /var/log/boot et parcourez les pages à la recherche d’un message en rapport avec votre problème. Recopiez également ce message dans votre fichier de départ.

4 – Lisez la documentation du programme.

Ceci est à faire en particulier si le programme ne réagit pas de la manière souhaitée. Lisez l’aide en ligne du programme et utilisez également le manuel universel (dans un terminal : man nom_du_programme).

5 – Recherchez votre message d’erreur sur internet

Copiez/collez le message d’erreur dans un moteur de recherche ou un meta-moteur tel que ixquick et ajoutez-y le nom du programme. Vous trouverez certainement des messages sur des forums d’utilisateurs qui ont le même problème que vous. Lisez le thread complet, vous y trouverez peut-être une solution.

6 – Réfléchissez avec logique

Si, arrivé ici, vous commencez à avoir une idée sur la cause du problème, vous pouvez peut être tester cette idée. Il y a beaucoup de petites commandes simples qui peuvent vous aider à recueillir plus d’informations sur votre problème et votre système, qui vont seront d’un grand secours. lspci pour lister votre matériel, lsusb pour lister les périphériques usb, cat /proc/cpuinfo pour avoir les caractéristiques de votre CPU, free -m pour connaitre le taux de charge de votre RAM

7 – Maintenant, vous pouvez penser à demander de l’aide.

Si après tout ça, vous n’avez toujours pas résolu votre problème, il est temps de demander de l’aide sur un forum d’utilisateurs. Avant de passer à cette étape, rappelez vous que les utilisateurs des forums ne sont pas payés pour répondre à vos questions. Ce sont seulement des utilisateurs ayant une certaine expérience et qui font cela bénévolement.

II – Obtenir de l’aide

1 – D’abord, observer

Commencez par choisir votre forum. Il est préférable dans un premier temps de choisir le forum de votre distribution, puis le forum du programme concerné. Si ce forum possède une FAQ, lisez-la. Lisez aussi les règles du forum. Si votre question ne respecte pas les règles, il y a de grandes chances pour que vous n’obteniez pas de réponse.

2 – Ne soyez pas hors-sujet

Trouvez le sous-forum qui correspond à votre problème. Ne postez pas votre message dans plusieurs sous-forums, ceci est très mal vu.

3 – Choisissez bien le titre de votre topic.

N’utilisez pas de sujet tel que « Besoin d’aide » ou « J’ai un problème ». Ceci a tendance à irriter les gens. Votre titre doit indiquer le plus clairement quel problème vous avez. Ainsi, une personne qui pense pouvoir vous aider sera plus encline à lire votre sujet et poster une réponse. Soyez aussi précis que possible. Par exemple « Impossible d’obtenir une adresse IP » sera plus utile que « Je n’arrive pas à aller sur internet ».

4 – Donnez des informations

Dans le corps de votre message, donnez le nom et la version de votre distribution, le nom et la version du programme utilisé et les informations sur votre matériel si cela est nécessaire. Recopiez-y aussi les messages d’erreurs (c’est là que le fichier que vous avez créé au devient utile). Indiquez ce que vous avez fait pour tenter de résoudre le problème. En faisant cela, vous montrerez aux autres que vous ne vous êtes pas jeté sur le forum dès que le problème est apparu.

5 – Pas de langage SMS

Ça saoule! Ça n’aide pas à vous faire comprendre et on vous répondra d’autant moins.

6 – Ne perdez pas une opportunité d’apprendre

Ne suivez pas les conseils aveuglément. Vous êtes ici pour apprendre quelque chose. Si on vous demande d’utiliser un outil en ligne de commande, utilisez les pages man pour savoir à quoi sert cet outil. Vous pourrez ensuite réutiliser cet outil si vous rencontrez un problème similaire. Si on vous demande de poster un fichier pour plus d’informations, recherchez l’utilité de ce fichier. Les fichiers systèmes importants possèdent souvent une page man dédiée.

7 – Dites merci

Les logiciels libres reposent sur la communauté. Personne n’est payé pour vous aider. Les personnes qui vous aident le font car elles ont elles-mêmes reçu de l’aide dans le passé et veulent rendre la pareille. En plus de dire merci, vous pouvez également aider les autres qui ne savent peut-être pas quelque chose que vous savez. Vous ressentirez alors une certaine satisfaction que les logiciels propriétaires ne peuvent vous apporter.

Second opus de cette nouvelle catégorie d’article : QRQVB, la Question Réseau Qui Va Bien!

Arpès avoir expliqué ce qu’était une adresse IP dans la dernière QRQVB, je me suis rendu compte que plusieurs éléments étaient manquant pour une bonne compréhension de l’article. Et parmis ces éléments indispensables à la bonne compréhension des mécanismes des réseaux informatiques, il y a le modèle OSI (Open Systems Interconnexion).

Définition

Le modèle OSI est une norme définie par l’ISO pour permettre l’interconnexion des systèmes. Il propose un modèle d’architecture réseau afin de s’assurer que tous les systèmes interconnectés puissent communiquer entre eux quel que soit le constructeur du materiel. Les constructeurs informatiques ont proposé des architectures réseaux propres à leurs équipements. Par exemple, IBM a proposé SNA, DEC a proposé DNA… Ces architectures ont toutes le même défaut : du fait de leur caractère propriétaire, il n’est pas facile des les interconnecter, à moins d’un accord entre constructeurs.

Le modèle OSI ne précise pas vraiment les services et protocoles à utiliser pour chaque couches. Il décrit plutot ce que doivent faire ces couches. Je sais que ça ne parait pas très clair pour le moment, mais ça va le devenir.

Schéma du modèle

Le modèle OSI est donc représenté en 7 couches distinctes. J’ai ici représenté 2 machines (à gauche et à droite) pour bien montrer que lors de la communication de 2 hôtes, chaque couche ‘discute’ directement avec la couche équivalente de l’hôte d’en face.

1°) Couche Physique

La couche physique s’occupe de la transmission des bits de façon brute sur un canal de communication. Plus clairement, elle est typiquement représentée par votre carte réseau et sa prise ethernet (et non pas le protocole ethernet!!).

La couche phyique discute directement avec l’hôte suivant sur le réseau. C’est à dire que lors d’une communication sur internet, cette couche ne s’occupe de l’envoie des données que vers la machine suivante, en général un routeur.

La couche physique traite exclusivement avec des bits 0 et 1 et normalise l’écriture de ces bits (une tension de 5V corespond à un 1, -5V un 0).

2°) Couche Liaison

La couche de liaison (ou liaison de donnée)  est un liant entre les 2 couches physiques des hôtes en communications. Elle fractionne les données en trames et tente d’exempter la couche physique des erreurs de transmissions.  Elle doit être capable de renvoyer une trame lorsqu’il y a un problème sur la ligne et intègre également un système de gestion de flux pour éviter les engorgements. Par exemple une carte 100Mb/s relié à une carte 1Gb/S doivent pouvoir communiquer sans que la carte 100Mb/s recoive 10x trop de données.

L’unité d’information de cette couche est donc la trame qui est composé de quelques centaines d’octets.

3°) Couche Réseau

La couche réseau construit la liaison de bout en bout lors de la communication de 2 hôtes. C’est la seule couche directement concernée par la topologie du réseau. Elle va trouver la route parmis les routeurs pour atteindre l’hôte cible.

Lors d’un envoie de données, 2 paquets différents peuvent emprunter des routes différentes suivant l’architecture du réseau et ses point d’engorgement.

C’est la dernière couche supportée par TOUTES les machines du réseau (hôtes, switchs, routeurs, serveurs). Son unité d’information est le paquet.

4°) Couche Transport

Cette couche est responsable du bon acheminement des messages complets au destinataire. Le rôle principal de la couche transport est de prendre les messages de la couche session, de les découper s’il le faut en unités plus petites et de les passer à la couche réseau et inversement du coté du recepteur.

Comme on l’a vu dans la couche réseau, 2 paquets d’un même message peuvent prendre des routes différentes et donc arriver dans le désordre. Le rôle de la couche transport est donc de remettre ces paquets dans l’ordre. Elle peut aussi gérer le multiplexage lors de communications multiples entre 2 mêmes hôtes (par exemple une connexion http et ftp sur le même canal).

Son unité d’information est le message.

5°) Couche Session

Le service principale de la couche session est la synchronisation des communications. Qui veut parler? Qui parle? Elle permet aussi de prendre des ‘snapshots’ des flots de données pour pouvoir reprendre le dialogue là où il en était avant une coupure du canal de communication.

6°) Couche Présentation

La couche présentation est chargée du codage des données de la couche application. En effet, toutes les couches plus basses transportent des octets sans chercher comprendre leur signification. Ici, elle va s’occuper d’encoder du texte, des images, de la video, de la voix etc… en données transportables, c’est à dire en octet.

7°) Couche Application

Cette couche est le point de contact entre l’utilisateur et le réseau. Elle lui apporte l’interface lui permettant de communiquer avec celui ci (messagerie, http, ftp etc…).

Exemples de protocoles

1. Physique → biphase, bipolaire simple
2. Liaison → ATM, Ethernet, PPP, TokenRing, Fiber Distributed Date Interface (FDDI)
3. Réseau → IP, IPX, ICMP
4. Transport → TCP, UDP (pour les plus connus)
5. Session → SIP, Appletalk
6. Présentation → ASCII, Unicode, ASN.1, Videotex
7. Application → HTTP, SMTP, POP, FTP, DNS, SNMP

Source : Wikipedia, frameip, RFC

Chose promise, chose due !

Comme je vous l’avais annoncé dans ce billet, j’étais depuis un moment sur la rédaction d’un dossier de veille technologique sur la virtualisation de serveurs. Dossier demandé par mon formateur de l’afpa. Ce dossier est enfin terminé. Il a pour titre exact « Virtualisation de serveurs – Solutions Open Source », dont voici le sommaire :

1.Les principes de la virtualisation
1.1.Partage d’un serveur
1.2.Objectif de la virtualisation
1.3.Bref historique
1.4.Hyperviseur
1.5. Performances et rendement
1.6.Sécurité
1.7.Administration
1.8.Contrôle des ressources
2.État de l’art
2.1.L’isolation
2.2.Virtualisation complète
3.Les Principales Solutions
3.1. OpenVZ
3.2.Xen
4.Domaines d’application
4.1.Hébergement VDS
4.2.Plateforme de validation de développement
4.3.Haute disponibilité
5.Le stockage
5.1.Différents besoins
5.2.Stockage en réseau
6.Conclusion

Le pdf, de 19 pages, est disponible à cette adresse.

Dans cette nouvelle catégorie (la Question Réseau Qui Va Bien), je vous propose de (re)découvrir avec moi, quelques notions fondamentales de réseau. Ces articles s’adressent en particulier à ceux qui souhaitent comprendre les mécanismes d’Internet et/ou du routage en WAN ou en LAN. J’essaierai d’être le plus clair possible. Si vous trouvez des erreurs, non-sens dans ces articles, je suis ouvert à toutes critiques, corrections.
Et pour inaugurer cette catégorie, commençons donc par l’adresse IP.

Définition :

Une adresse IP identifie de manière unique une machine ainsi que le réseau sur lequel elle est située. Chaque adresse est une série de 4 octets dont une partie correspond à l’identificateur du réseau et l’autre partie à l’identificateur de la machine.
Exemple d’adresse IP : 172.19.174.125.

Concrètement, qu’est ce que cela signifie? En fait, puisque les machines ne savent traiter qu’avec des nombres binaires (0 ou 1) l’adresse est codée en binaire sur 4 octets. Sachant qu’un octet correspond à 8 bits, cela nous donne, pour chaque octet 256 possibilités (2^8) pour une valeur comprise en 0 et 255.

Allons un peu plus loin!

C’est bien sympa d’avoir une adresse, encore faut-il qu’on puisse m’y contacter! On vient de voir dans la définition que l’adresse IP est divisée en 2 sous parties : l’identificateur de réseau et l’identificateur d’hôte. C’est là qu’intervient le masque de réseau. Alors puisque je ne suis pas fort en blablatage, je vais plutôt vous montrer un exemple.
Voici une adresse IP : 192.168.1.15
Voici un masque de réseau : 255.255.255.0

En fait, pour être plus précis, les bits se situant dans la partie de l’identificateur réseau sont tous positionés sur 1 et les bits de la partie hôte sur 0. En procédant à une opération de ET logique entre l’adresse IP et le masque de réseau, on trouve l’adresse réseau. Les opérations de ET logique suivent cette règle :

0 ET 0 = 0
0 Et 1 = 0
1 ET 0 = 0
1 ET 1 = 1

Grâce à cette adresse réseau, un routeur pourra déterminer quel chemin doivent emprunter nos paquets IP. Pour bien comprendre ce système, nous allons jouer un peu avec le binaire, même si je sais que ça va en rebuter plus d’un :p

Ceci est important puisque c’est de cette manière qu’on va pouvoir déterminer le nombre maximal de machines qui peuvent appartenir à un réseau. Il faut également savoir que sur 1 réseau, 2 adresses sont réservées. L’adresse ‘bits hôte à 0′ car c’est elle qui va définir justement l’adresse de notre réseau, comme on vient de le voir, et l’adresse ‘bits hôte à 1′ car elle correspond à l’adresse de diffusion (broadcast). L’adresse de broadcast est nécéssaire pour diffuser un message sur tout le réseau. Le message de ce genre le plus classique est la requête ARP. Celle çi permet à une machine de trouver une autre machine sur le réseau en l’appelant.

Voici un exemple de capture de trame avec wireshark :

Le premier paquet est donc une requête ARP. La machine source envoie ce message sur tout le réseau : ‘who has 192.168.1.51?  Tell 192.168.1.25′. La machine qui a pour IP 192.168.1.51 envoie donc sa réponse directement à 192.168.1.15 et lui dit que c’est l’adresse MAC 00:0a:78:9e:8a qui possède cette IP. (Je me demande si j’aurais pas du expliquer les couches OSI avant!). Tout ça pour vous dire que l’adresse IP ‘bits hôte à 1′ est donc reservée pour ce type de message.

Dimensionnement de réseau

Puisque le masque de réseau détermine le nombre maximal de machines sur un réseau et que les adresses IP ne sont pas illimitées, on va pouvoir travailler sur le dimensionnement du réseau en modifiant le masque. En effet, il est possible d’emprunter des bits à la partie hôte pour les donner à la partie réseau. Par exemple, le masque 255.255.255.0 permet d’avoir 256-2 = 254 hôtes différents sur le même réseau. Hors, rares sont ceux qui disposent de 254 machines à interconnecter.

Admettons que mon réseau possède l’ip 192.168.1.0 (totalement au hasard!) de masque 255.255.255.0 . Je dispose de 5 machines à connecter sur ce réseau, jamais plus.

• Si je garde 1bit dans la partie hôte, je vais disposer de 2^1 = 2 hôtes possibles.  On vient de voir plus haut que 2 adresses sont reservées sur le réseau, (sisi, rapellez vous, juste au dessus!). Donc 2-2 = 0, ce qui me fait 0 hôte disponible.
• Si je garde 2 bits pour ma partie hôte, il va me rester (2^2)-2 = 2 hôtes possibles. Ce n’est toujours pas suffisant!!
• Si je garde 3 bits pour la partie hôtes, j’obtiens (3^2)-2 = 6 hôtes possibles. Ouf!! j’ai assez de place pour caser mes machines. On va donc construire notre masque de réseau en gardant ces 3 bits sur 0, ce qui nous donne :

11111111.11111111.11111111.11111    000
Partie réseau                                         Partie hôte
Ce qui, transformé en décimal nous donne un masque : 255.255.255.248.

Ce qu’on vient de faire ici, c’est de créer des sous réseaux du réseau 192.168.1.0. Plusieurs sous réseaux composé chacun de 8 adresses IP.

Sous réseau 1 : de 192.168.1.0 à 192.168.1.7 (avec 192.168.1.0 adresse de sous réseau et 192.168.1.7 adresse de broadcast)

Sous réseau 2 : de 192.168.1.8 (adresse du réseau) à 192.168.1.15 (adresse de broadcast)

Sous réseau 3 : de 192.168.1.16(adresse du réseau) à 192.168.1.23 (adresse de broadcast)

etc etc..

dernier sous réseau : de 192.168.1.248 (adresse de réseau) à 192.168.1.255 (adresse de broadcast)

Voilà donc ce qui se cache derrière les adresses IP. Plus mon sous réseau sera petit, moins j’aurais de broadcast sur ce réseau. Parce que mine de rien ça papote pas mal la dedans et ça a tendance à broadcaster dans tous les sens. Malheureusement, le broadcast n’est pas gratuit. Il coûte de la bande passante. Et quand la bande passante sature, on commence à perdre des paquets.

C’est pour ca qu’il est important, en entreprise en tout cas, de bien calculer le dimensionnement de son réseau et l’adressage IP de l’entreprise, sans oublier de prévoir que si l’entreprise s’agrandit, il va falloir rajouter des hôtes sur certains sous réseaux et en plus ajouter un nouveau sous réseau à notre entreprise pour y connecter un nouveau batiment par exemple. Ça a vite tendance à tourner cacahuète si on fait pas attention.

Voilà, j’espère que ce premier article sur les fondamentaux du réseau vous aura plus. Peut être même que certains y auront appris 2-3 trucs. Le prochain article de cette catégorie traitera a priori du modèle OSI, ou alors de TCP/IP… on verra.