Quelques principes de base | (Haut de page) |

Les réseaux possèdent des architectures en couches. Chacune est indépendante des autres et communique seulement avec celles juste au dessus et juste en dessous (dans la théorie, car ce beau modèle est parfois un peu cassé). C'est pour cela que l'on parle de pile TCP/IP. Les couches sont numérotées en partant du bas (le matériel) jusqu'en haut (l'application utilisateur).

Lorsque l'on envoie des données, elles traversent les couches de manière décroissante, passent par le réseau, et les remontent de manière croissante sur une machine distante pour atteindre l'application de l'autre côté.

Et en fait chaque couche rajoute des informations en debut des données du niveau précédent (en-tête ou header en anglais) pour créer alors de nouvelles données qui sont transmises au niveau en dessous. Un petit schéma suit. D(X) désigne les données de niveau X, E(X) l'en-tête de niveau X

Utilisateur
....

                      +-------+
                      |  D(N) |  Niveau N
                      +-------+


               +------+-------+
               |E(N-1)|  D(N) |  Niveau N-1
               +------+-------+


        +------+--------------+
        |E(N-2)|     D(N-1)   |  Niveau N-2
        +------+--------------+


 +------+---------------------+
 |E(N-3)|       D(N-2)        |  Niveau N-3
 +------+---------------------+

.... 
Matériel

Ce qu'il est important de voir, c'est que D(N-1)=E(N-1)+D(N). En langage clair ce qui est dit au dessus : chaque niveau rajoute aux données du niveau d'au-dessus son en-tête avant de les transmettre au niveau suivant.

Et de l'autre côté, c'est exactement l'inverse. Chaque couche enlève les informations la concernant pour transmettre à celle supérieure seulement les informations utiles pour celle-ci. On a alors : D(N)=D(N-1)-E(N-1).

L'en-tête TCP comprend le numéro de port, le numéro de segment, le numéro d'acquittement et une somme de contrôle (checksum) entre autres.

L'en-tête IP contient l'adresse IP, le numéro de datagramme, le TTL,...

Chaque niveau X peut selon les besoins découper les données D(X+1) en plusieurs morceaux avant de rajouter son en-tête et les transmettre au niveau en dessous.

Prenons à présent un exemple appliqué à la vie courante. Entre parenthèses sont les concepts informatiques correspondants.

Dans une université (ordinateur), un professeur (utilisateur) veut transmettre un rapport (données comme un mail ou un fichier) à un autre professeur d'une autre université. Il le donne au secrétariat (la couche TCP) qui va s'en charger. La personne du secrétariat decide de diviser le rapport en plusieurs chapitres (segments TCP) pour le transmettre. Dans chaque chapitre, elle rajoute une page (en-tête TCP) sur laquelle elle demande au secrétariat de l'autre université (la couche TCP du côté destinataire) de bien vouloir la prevenir lorsque ce chapitre aura été reçu. Elle rajoute aussi le numéro du bureau du professeur dans l'autre université (numéro de port).

Chaque chapitre est ensuite passé au service courrier (la couche IP). Celui-ci le découpe en paquets de 2 pages (les datagrammes IP), car leurs enveloppes ne peuvent contenir plus (la taille maximale est le MTU). La page qui contient les informations rajoutées par le secrétariat n'est pas considerée comme différente des autres par le service courrier. C'est une page de plus et c'est tout (D(N-1)=E(N-1)+D(N)). Sur chaque enveloppe, on met l'adresse du destinataire, le numéro du chapitre contenu pour pouvoir ensuite savoir lesquelles vont ensemble (IP identification). Et pour les réorganiser un numéro de séquence qui va croissant sur chaque enveloppe d'un chapitre donné (fragmentation offset).

Les enveloppes ne sont pas directement amenées au destinataire, Mais au bureau de poste le plus proche. De ce bureau, on l'envoie dans un centre de tri, et ainsi de suite de centre en centre (routeurs, passerelles,...)

La lettre a une destination finale, mais il y a plusieurs chemins pour y parvenir avec différentes étapes intermédiaires (c'est le routage).

Parfois la lettre peut tourner en rond. Si on en expédie une de Paris vers Toulon par exemple, elle va passer par Lyon, Marseille puis Toulon. Mais il se peut qu'une fois à Marseille elle revienne sur Lyon, puis aille à Nice, revienne sur Marseille,... Dans ce cas, l'expéditeur met une série de petites cases à cocher sur l'enveloppe. A chaque bureau de poste, on coche une de ces petites cases. Si un bureau voit arriver une lettre où toutes les cases sont cochées, elle est considérée comme perdue et est détruite (le Time To Live, ou TTL, est un compteur décrémenté à chaque passage par une machine).

Le service courrier de l'autre université reçoit toutes les enveloppes. Il sort les pages des enveloppes qu'il jette a la poubelle (D(N)=D(N-1)-E(N-1), le niveau supérieur se moque de l'en-tête du niveau inférieur), met ensemble celles qui correspondent au même chapitre puis les réorganise (défragmentation des datagrammes). Dès qu'un chapitre est complet, il est passé au secrétariat. Celui-ci voit alors la 1ère page où une confirmation est demandée, ainsi que le numéro du bureau du professeur. Il enlève cette page et il écrit sur une nouvelle page qu'il a bien reçu ce chapitre et l'adresse au secrétariat de l'université émettrice (acquittement TCP). Dès que tous les chapitres sont reçus, le rapport est transmis au professeur qui peut le lire sans problème car les pages d'informations et les enveloppes ont ete enlevées. Il a juste un rapport tel qu'il était au depart.

Si le secrétariat émetteur ne reçoit pas de confirmation de réception d'un chapitre au bout d'un certain temps (timeout) il le renvoit alors.

Il faut bien noter ici que le service courrier ne garantissait absolument pas que les lettres arrivent bien. C'est le service secrétariat qui se trouve au-dessus qui ajoute cette notion de vérification et l'assurance que les chapitres arrivent bien à destination (TCP est un protocole fiable au dessus d'un protocole non fiable, IP).

Si le rapport comprend 45 chapitres, il serait long d'attendre un accusé de réception pour chacun avant d'envoyer le suivant. On peut alors décider d'en envoyer 4 d'un coup. Ensuite dès que l'on reçoit l'accusé d'un de ceux-là, on envoie le 5ème. Le 1er arrivé ne sera pas forcément le 1er chapitre à cause de la possibilité de chemins différents des différentes pages. On sera en gros toujours en attente de 4 accusés de réception simultanément (c'est le mécanisme de fenêtrage TCP où l'on a une fenêtre dite glissante).

Tout se passe en quelque sorte comme si entre les deux universités les services équivalents communiquaient directement entre eux. Le 1er demande à l'autre de confirmer réception des chapitres. Celui-ci le fera en répondant à cette demande. Bien sûr tout ceci va passer par le service courrier et par la poste, mais on a une liaison virtuelle entre ces services.

L'adresse IP | (Haut de page) |

Pour identifier une machine sur Internet, il faut quelque chose qui soit unique afin de la distinguer de toutes les autres. Pour cela il y a l'adresse IP. Celle-ci est de la forme :

a.b.c.d

Où a, b, c et d sont 4 nombres compris entre 0 et 255.

C'est avec cette adresse numérique que l'on peut communiquer avec un ordinateur, comme l'on communique avec une personne en connaissant son adresse postale.

Les sociétés ont généralement des adresses fixes qui leur sont réservées. Les adresses se lisent de gauche à droite. La partie gauche désigne la partie correspondant au sous-réseau, et la partie droite aux machines dans ce sous-réseau. Pour noter une adresse de réseau, on remplace la partie spécifique par des 0. Par exemple, une entreprise a réservé les adresses allant de 220.158.35.0 à 220.158.35.255. On notera alors l'adresse de son réseau :

220.158.35.0

Et celle-ci ne pourra pas être utilisée pour désigner une machine. La dernière adresse est utilisée pour le broadcast. Ceci permet d'envoyer à toutes les machines du sous-réseau. Dans ce cas, il s'agira donc de 220.158.35.255. Les adresses valables pour les machines iront donc en fait de 220.158.35.1 à 220.158.35.254.

Un particulier se connecte à Internet par l'intermédiaire d'un FAI. Celui-ci a réservé sa plage d'adresses IP. Et quand un utilisateur se connecte, il lui assigne une adresse dans son domaine de valeurs. Elle est aléatoire. Mais dans la pratique, on peut avoir la même adresse plusieurs fois de suite, car pendant un certain temps (variable selon les fournisseurs) la même sera assignée.

Avec GNU/Linux, pour connaître votre adresse IP, vous pouvez utilisez la commande :

Suivi éventuellement du nom de l'interface par laquelle vous être connecté à Internet. Si c'est un modem qui est utilisé, ce sera probablement ppp0. Pour une connexion directe avec une carte réseau, eth0. Pour la déterminer, vous pouvez lire la dernière colonne de la commande suivante :

La notion de ports | (Haut de page) |

Une machine a une seule adresse IP (elle peut en avoir plusieurs s'il s'agit d'une passerelle, mais ce n'est pas le but de cette explication). Or cette machine peut faire office de serveur web, FTP ou autre. Elle peut de plus en même temps permettre de surfer sur le net, récuperer des mails et dialoguer sur IRC (chat).

Lorsqu'une autre machine veut lui envoyer des informations, comment peut-elle avec une seule adresse indiquer à qui elle veut l'envoyer ? Comment le destinataire sait-il que ces données reçues sont à destination du serveur web, du client irc ou du logiciel de mail ? Réponse : avec les ports. C'est maintenant qu'intervient la comparaison (entre parenthèses seront les concepts informatiques correspondants).

Imaginez un immeuble (ordinateur) comprenant plusieurs bureaux (ports). Cet immeuble a dans l'annuaire une seule adresse (adresse IP). Lorsqu'une personne (serveur/autre programme client) souhaite envoyer du courrier à une personne (service/programme client) dans un bureau en particulier, il doit ajouter à l'adresse le numéro de bureau precis (numéro de port). Un coursier interne à l'immeuble se charge ensuite de re-distribuer le courier. Maintenant plusieurs cas sont possibles.

- Le bureau est occupé par une personne qui s'attendait à recevoir du courrier (cela correspond au cas où un serveur tourne sur ce port, ou alors votre programme client reçoit des réponses à des requêtes).

- Le bureau est vide. Le courrier est ré-expédié à son destinataire (connexion refusée).

- Le bureau était à l'origine vide, mais un petit malin s'est faufilé et s'y est installé. Il va alors accueillir dans son bureau du courrier et en expédier vers l'extérieur. Il pourra même, étant dans le bâtiment, récuperer des données dans d'autres bureaux et les envoyer (c'est ce que fait un cheval de troie).

Si le concierge (administrateur) est consciencieux et répertorie clairement quels bureaux sont occupés ou non, et empêche quiconque de s'installer dans un bureau (exécution d'un programme infecté par le cheval de troie), la sécurité sera suffisante.

Pour être bien sûr, il peut toutefois engager une personne (firewall/pare-feu) qui va trier le courrier. Celui-ci sera à l'entrée du bâtiment. Chaque lettre arrivant porte la mention du bureau destinataire. Cette personne examine alors son cahier de consignes (règles de filtrage) pour déterminer si oui ou non la lettre doit être acheminée vers ce bureau. Les consignes peuvent décider que c'est un expéditeur en particulier qui ne peut pas écrire à certains bureaux (filtrage sur l'IP source). Que personne ne peut écrire à un bureau donné (filtrage d'un port) ainsi que d'autres consignes plus complexes.

De plus les consignes peuvent spécifier soit que les lettres refusées seront ré-expédiées à l'émetteur (REJECT - connexion refusée) soit que les lettres seront purement détruites (DROP - port filtré). L'expéditeur se rendra compte au bout d'un certain temps (timeout) que, n'ayant pas eu de réponse à son courrier, celui-ci a ete jeté.

Ainsi, même si quelqu'un arrive à s'installer dans un bureau vide, il ne pourra de toutes façons pas recevoir de lettres car celles-ci seront refusées par le vigile si les consignes ont bien été créées.

Et puis parfois lorsque l'on achète un immeuble, sans le savoir il y a des squatteurs dans certains bureaux qui y restent. Si on ne prend pas la peine de fouiller entièrement le bâtiment et que l'on n'installe pas de personne pour vérifier le courrier à l'entrée, ceux-ci pourront recevoir des lettres, peut-être même piégées (exploitation de failles de sécurite sur certains services).

Le DNS | (Haut de page) |

Le DNS permet la conversion des noms en adresses IP. En fait sur Internet tout fonctionne par adresse IP. Mais comme cela n'est pas très pratique à manipuler, il y a le DNS.

C'est comme un annuaire qui associe à un nom explicite une adresse IP (comme l'annuaire associe au nom de la personne un numéro de téléphone).

Exemple la machine avec le nom www.kernel.org a en fait comme adresse IP 204.152.189.116 Lorsque l'on tape son adresse dans un navigateur (ou tout autre logiciel) il va d'abord demander aux serveurs DNS son IP et ensuite c'est elle qui est utilisée.

Viennent des détails plus techniques à présent sur le DNS.

On dit qu'un serveur fait autorité sur un (ou plusieurs) domaines. Il y a par exemple un serveur DNS qui gère le nom de domaine org et un qui gère linux.org Le caractère de séparation est le . (point).

Ceux-ci sont organisés de manière hiérarchique. Le point d'entrée est un des serveurs racines (root servers). Il y en a 13 dans le monde.

Ils connaissent le (ou les) serveur(s) qui gèrent les principaux domaines: com, fr, org, net,...

Tous les serveurs gérant des domaines ont leurs adresses IP enregistrées dans leur base.

Par exemple, un utilisateur abonné chez Wanadoo et passant par leur serveur DNS qu'il a configuré sur ma machine (il faut bien avoir l'IP en dur d'un serveur).

Pour lui ce sera son point d'entrée dans l'arborescence DNS.

Il veut accéder à la machine de nom www.wanadoo.fr tout d'abord. Là il demande donc à ce serveur DNS qui connaît directement son adresse.

Ensuite il veut accéder à www.google.fr. Le serveur Wanadoo voit que ce n'est pas chez lui. Il connaît probablement le serveur DNS qui gère le domaine .fr Il va donc lui demander quel serveur gère le (sous-)domaine google.fr. Celui-ci est ensuite interrogé pour donner l'adresse IP qu'il connaît directement.

Si maintenant il veut accéder à ftp.kernel.org, le serveur DNS Wanadoo va remonter jusqu'à un serveur racine pour savoir qui gère .org, et ainsi de suite...

Un serveur peut gérer plusieurs domaines, comme plusieurs serveurs peuvent gérer un même domaine (ils seront utilisés à tour de rôle aléatoirement ou selon la charge de chacun).

Les serveurs doivent connaître au moins leur père (le niveau au dessus), leurs enfants (les sous domaines) et bien sûr les adresses des machines dans ce domaine (pour lesquelles il fera lui-même la conversion).

Une adresse DNS se lit de droite à gauche (contrairement à une adresse IP) du plus général au plus spécifique. La dernière partie la plus à gauche désigne le nom de machine et tout le reste le domaine. Exemple :

www.linux.org

linux est un sous domaine du domaine org et www est le nom de la machine dans le domaine linux.org

Un cas un peu particulier à noter dans la gestion DNS, les serveurs de mail. On peut directement écrire un mail à tian@c-sait.net par exemple.

Or c-sait.net est un nom de domaine. Mais il y a dans ce domaine une machine qui gère les mails (pop3.c-sait.net dans ce cas). En fait on envoie donc un mail à tian@pop3.c-sait.net

Il y a une entrée spéciale dans la configuration du serveur DNS qui est le MX. Quand on envoie un mail à tian@c-sait.net, le serveur DNS est interrogé pour lui demander quelle machine gère les mails, et c'est ensuite à celle-ci que le mail est envoyé (Il peut en fait y avoir plusieurs MX avec des priorités).

Le reverse DNS est ce qui permet de passer d'une adresse IP à un nom DNS. L'inverse de ce qu'il y avait précédemment.

En fait plutôt que d'avoir un autre protocole pour gérer cela, c'est DNS lui-même qui est utilisé.

Pour cela il existe un domaine spécial, in-addr.arpa

Pour passer d'une adresse à son nom, on la met à l'envers (une IP se lisant en sens inverse d'un nom DNS ) et on lui ajoute à la fin le nom de domaine. Pour l'exemple plus haut (www.kernel.org 204.152.189.116) on a donc :

116.189.152.204.in-addr.arpa

Qui va en fait être considéré comme un nom de machine/domaine. On parcourt alors les DNS comme précédemment en partant de la racine, puis in-addr, ensuite 204,... Le domaine qui gèrera la fin de l'adresse (189.116 dans ce cas), sera celui faisant autorité sur le domaine kernel.org.