Avant toute chose, il nous paraît nécessaire d'expliquer le fonctionnement de la pile TCP/IP mise en oeuvre dans un Intranet. Pour cela, nous nous servirons du modèle OSI et d'un cas pratique.
Nous avons un ordinateur (que nous nommerons HAL) relié à un réseau Ethernet via un adaptateur réseau. Nous passerons rapidement sur les deux premières couches du modèle OSI. Sachez simplement que HAL est doté d'un identifiant physique unique (adresses MAC) sur ce réseau, cette adresse permet de le localiser physiquement.
Contrairement à d'autres suites de protocoles, la pile TCP/IP ne se contente pas de ces adresses. En effet, la localisation physique ne correspond pas toujours à l'organisation voulue du réseau. De fait, il est difficile de connaître ces adresses, lorsque les stations sont séparées par plusieurs intermédiaires ; cela n'est facile que lorsque les stations sont adjacentes. Ainsi, on remarquera qu'à partir de la couche de réseau du modèle OSI (la troisième), une adresse logique est attribuée à HAL ; son adresse MAC correspond dès lors à une adresse IP (Internet Protocol). C'est donc cette adresse qui sera utilisée dans la suite de la pile TCP/IP. On notera au passage que les protocoles ARP (Adresse Resolution Protocol) et RARP (Reverse ARP) permettent de convertir l'une en l'autre...
L'Internet Protocol nous sera fort utile dans la suite de l'exercice, nous allons donc le décrire un peu plus. Il sert à acheminer les paquets au sein d'un réseau ; des données sont donc ajoutées au paquet. Ce datagramme est constitué d'informations nécessaires au routage des paquets aux travers de réseaux complexes et multiples. Trois d'entres elles nous intéressent tout particulièrement : l'adresse source, l'adresse destinataire, le protocole.
Les deux premières indiquent, sur chaque paquet, d'où vient le paquet (à qui répondre) et où doit-il parvenir (qui il concerne). Elles sont notés sous la forme d'adresse IP : une suite de 4 ou 8 octets (suivant la version du protocole utilisé).
La troisième information qui nous intéresse indique quel protocole suit... Autrement dit, quel protocole trouverons nous pour ce paquet sur la couche OSI suivante, la couche de transport (TCP, UDP ou autre).
Passons donc au niveau suivant du modèle OSI, la couche de transport (la quatrième). En général, c'est le Transmission Control Protocol (TCP) qui est utilisé, il s'assure que le paquet arrive en bon état, établissant un système de session. Grossièrement, l'expéditeur envoie ses paquets, le destinataire les reçoit, vérifie leur intégrité et confirme ou non la bon réception au près de l'expéditeur qui réagira en fonction.
Il introduit alors une notion importante : les ports. Afin de réaliser ses opérations de contrôle sans limiter les échanges des deux correspondants, il a fallu mettre en place un système identifiant les services concernés, et ce de manière générique. Ces ports sont codés sur 16 bits, ce qui octroie 65536 ports TCP à chaque adresse IP d'un même réseau. A chacun de ses ports peut correspondre, dans les couches plus élevées, un logiciel. On dira que ce logiciel écoute ce port ; l'usage de ce port lui est donc réservé (si des paquets arrivaient sur ce port sans être destiné à ce logiciel, ils seraient ignorés, ou créeraient une erreur).
Dans l'objectif de normaliser tout cela, l'Iana s'est chargé d'assigner certains ports à des application ou à des services bien connus. Ainsi, on dénombre trois catégories de port :
Bien évidemment, l'assignation des ports aux services reste à l'entière discrétion de l'administrateur réseau... Il n'y a rien d'obligatoire.
Le datagramme du protocole TCP indique donc le port source (le port sur lequel le logiciel demandant attend sa réponse) et le port de destination (le port sur lequel le logiciel serveur est sensé écouter). S'ajoute un certain nombre d'information de vérification des données...
Pour résumer, lorsque HAL envoie une requête sur un serveur distant, il émettra des paquets d'octets, contenant tous – et entre autres choses – sa propre adresse IP (IPHAL), l'IP du serveur, et le numéro du protocole utilisé dans la couche supérieure. S'en suit alors l'entête TCP, qui indique un port source (TCPHAL) et un port destinataire.
Quand le serveur recevra ces paquets, il analysera l'en-tête TCP et passera les données à l'application assignée au port mentionné dans les paquets en tant que port de destination. Après traitement, la réponse sera renvoyée. Les adresses IP ainsi que les ports source/destination seront alors inversés...
Comme nous l'avons vu, les logiciels sont liés à leur port d'écoute respectif ; un même port ne pouvant être assigné simultanément qu'à une seule application.
Théoriquement, nous devrions donc avoir autant de logiciel que port, soit 65536.
Cependant, en pratique certaines applications requièrent plus d'un port pour fonctionner. C'est le cas, par exemple, du File Transfert Protocol (FPT).
En outre, certains protocoles (Peer to Peer, par exemple) utilisent l'User Datagram Protocol au lieu de TCP. UDP utilise également une logique de port, toutefois, les ports TCP et UDP ne sont pas confondus !
Nous avons déjà expliqué son fonctionnement, en voici donc un schéma.

L'IP sert à l'acheminement du paquet, et permettra au destinataire de connaître l'adresse de réponse. Le TCP indique quel logiciel (par l'intermédiaire du numéro de port) du destinataire est concerné. Il connaîtra également le port à indiquer lors de sa réponse, pour que le logiciel émetteur réceptionne la réponse.
Nous avons vu que les stations d'un réseau possédaient une adresse IP. La question est désormais de savoir comment elles l'obtiennent. Il existe deux méthodes, correspondant très souvent à deux types d'adresses : fixes (ou statiques) ou bien dynamiques.
Lorsque l'adresse IP est fixe, la station la spécifie elle-même, d'après sa configuration, et la garde autant de temps que dure sa connexion au réseau. Dans ce cas, il est plus simple d'assurer une continuité de service (notamment dans le cas d'une IP assignée par un FAI par exemple).
Lorsque l'adresse est dynamique, elle la demande auprès d'un serveur DHCP (Dynamic Host Configuration Protocol) qui lui fournie son adresse IP, ainsi que les adresses IP des principaux éléments du réseau (Passerelle, DNS... etc.).
Grâce au DHCP, chaque station du réseau se verra attribuer une adresse IP et un bail, au delà duquel l'adresse sera renouvelée si besoin. L'utilisateur n'a pas à intervenir. Avec un serveur DHCP tel que ISC DHCP (Linux) par exemple, on peut paramétrer des pools d'adresses IP et à l'intérieur de celles-ci des ranges d'adresses c'est-à-dire des plages d'adresses IP attribuables. Ainsi, on peut définir des groupes de PC clients suivant les besoins et on facilite l'administration en cas de problème. Par exemple, sur un sous-réseau 192.168.16.0 on pourrait avoir un pool contenant 2 plages (ranges) d'adresses IP différentes telles que : 192.168.16.5 à 192.168.16.99 et 192.168.16.120 à 192.168.16.180.
En définissant ainsi des plages d'adresses, l'administrateur réseau se facilite la vie à chaque fois qu'il doit ajouter un PC client dans un service car le serveur DHCP se charge d'attribuer l'adresse automatiquement suivant les définitions renseignées.
Par ailleurs, le nombre restreint d'adresse IP (2(8*4) soit moins de 4,3 Milliards) nous oblige à recourir au Network Adress Translation (NAT). Cette technologie permet à un réseau de se doter de sa propre adresse IP – dite publique –, au sein d'un autre réseau comme internet. Dans ce cas de figure (très répandu actuellement), les stations situées dans le premier réseau, ont donc des adresses IP propre à ce réseau – on dit alors de leur adresse qu'elles sont privées. Lorsqu'elles communiquent sur Internet, la passerelle NAT modifie les datagrammes du protocole IP et TCP/UDP, remplaçant l'adresse IP source par l'adresse IP publique du réseau et le port source (pour gérer les conflits, lorsque plusieurs stations du réseau indiquent le même port source). Et inversement lors de la réception des réponses.
On parle alors d'adresse IP Officielle lorsqu'elle est attribué (souvent dynamiquement) par un fournisseur d'accès à Internet. Les adresses Non-officielles correspondent à une adresse IP configurée statique, attribuée manuellement, mais dans le domaine public (Internet). Aujourd'hui, il est presque impossible de configurer ses adresses IP ainsi sur Internet. C'est pourquoi on emploie fort peu souvent ce terme.
Nous utiliserons l'exemple d'Intranet de Dimitri. Notons que les postes 2, 3 et 4 pourront se connecter à Internet par l'intermédiaire du poste 1 (serveur).

Remarques :
Bien qu'il n'y ait que trois stations derrière le serveur, un commutateur améliorerait les performances.
Il n'y a aucun firewall sur l'installation. A moins que le modem ait une fonction firewall ou que le serveur fasse office de firewall, il faudrait en installer un pour garantir un minimum de sécurité face aux intrusions venant d'Internet.
Une solution plus performante serait d'installer une passerelle NAT avec fonction de pare-feu et DHCP, entre le modem et le serveur. Enfin les stations seraient raccordées à cette passerelle. Le trafic serait alors mieux réparti, et la charge du serveur fortement allégée.
1°) pour un intranet domestique :
Pour un intranet domestique, il faut utiliser des adresses IP dites "privées" ou "réservées". On les appelle aussi "non-routables" ; puisque ces adresses « n'existe pas » depuis l'extérieur du réseau. On gardera donc un réseau de classe C, selon la RFC 1918 : de 192.168.0.0 à 192.168.0.255. Les adresses sont attribuées par un serveur DHCP.
2°) pour un intranet domestique en liaison permanente :
Il faudra dans ce cas utiliser des adresses IP privées, comme précédemment mais en ayant une adresse IP publique, routable à l'extérieure du réseau. Il faudra donc d'un point de vue matériel posséder un routeur pour les connexions entrantes et sortantes vers Internet car lui seul aura la possibilité de traduire les adresses du réseau local (donc des adresses privées) en adresses globales routables via le NAT (Network Adress Translation).
On pourra garder un réseau classe C, selon la RFC 1918 : de 192.168.0.0 à 192.168.0.255. Les adresses sont attribuées par un serveur DHCP (probablement intégré au routeur du réseau). On prévoit un groupe d'adresses IP Statiques (le DHCP ne devra pas attribuer d'adresses IP dans cette plage d'IP).
3°) pour un intranet professionnel avec des fonctions élémentaires :
Un réseau de Classe B avec 255 réseaux de classe C, selon la RFC 1918, de 172.16.0.0 à 172.16.255.255. Plusieurs DHCP hiérarchisés... Certains réseaux de classe C seront statiques (Pour les serveurs). Une passerelle NAT autorisera certains autres réseaux de classe C à accéder à Internet.
4°) pour un intranet professionnel sophistiqué :
Jusqu'à 16 réseaux de classe B, de 172.16.0.0 à 172.32.255.255 voire 1 réseau de classe A de 10.0.0.0 à 10.255.255.255. Adressage presque entièrement dynamique, avec un réseau de serveurs DNS mis à jour automatiquement.
Quels sont dans ces 4 cas les contraintes fortes qui doivent exister sur les firewall, sur les adresses IP, sur les DMZ etc... (N'hésitez pas à redéfinir des termes spécifiques comme DMZ, à préciser leur intérêt et à donner un ou des exemples).
Les contraintes sont d'ordre sécuritaire. Le choix des adresses IP se portera sur des adresses de classe A, B ou C suivant le nombre de postes connectés au réseau. Pour rappel la classe A permet la connection de 16777214 ordinateurs, la calsse B permet la connection de 65534 ordinateurs et la classe C permet la connection de 254 ordinateurs.
Quoi qu'il en soit, le choix d'adresses IP "privées" constitue déjà un premier filtre puisqu'elles ne sont pas "visibles" depuis l'extérieur du réseau (généralement depuis Internet).
Un second filtre sera mis en place par le biais de 2 firewalls pour constituer une zone démilitarisée (DMZ). L'un entre les postes clients et les machines dans la DMZ (serveurs) et l'autre entre les machines de la DMZ et le routeur donnant accès à l'extérieur (Internet). Ce faisant, on sécurise un peu plus le réseau en établissant des "ponts". Ainsi, même si une des machines située dans la DMZ venait à être compromise, le pare-feu restant entre elle et le réseau local jouerait son rôle de filtre.
Les firewalls devront être configurés de manière à accepter les entrées/sorties des machines désignées comme permises et bloquer les autres. Pour ce faire, mettra en place les règles adéquates.
Sources :
http://abcdrfc.free.fr/rfc-vf/rfc1918.html
http://free-eos.adullact.net/Manuels/ManuelServeur1.3/ipaddress.html
http://www.vulgarisation-informatique.com/creer-reseau-local.php
Les noms de domaines sont formés à partir de plusieurs labels, séparés par des points. Le derniers constituant est appelé Top Level Domain (TLD). Les labels de niveau inférieurs sont tous des sous-domaines du TLD : sous-domaine2.sousdomaine1. domaine_primaire.
Les noms de domaines sur Internet sont gérés en France par l'AFNIC (Association Française pour le Nommage Internet en Coopération). Elle s'occupe des .fr et .re (Ile de la Réunion). Chaque pays se voit attribuer une extension propre. Par exemple en France c'est .fr, aux USA c'est .us, en Russie .ru, etc.
Concernant les noms de domaines hors pays (.com, .biz, .net, .org etc), ils sont gérés par Internic (http://www.internic.net). C'est une société basée aux Etats-Unis. Les extensions sont alors en 3 ou 4 lettres au lieu de 2 pour les pays.
Les noms de domaine ne s'achète pas, simplement, on loue les droits d'exploitation de ces noms de domaine. Ce sont les registrars qui s'occupe de louer et de proposer aux clients des Domain Name System (DNS) fiable, avec des système de redondance.
Sur internet, ils sont primordiaux, puisqu'il est impossible pour le commun des mortels de connaître les adresses IP des serveurs distants.
Sur intranet, le principe est le même. Pour mettre en oeuvre des noms de domaine, il faut mettre en place un serveur de noms ou serveur DNS. Le serveur DNS conserve en mémoire les correspondances entre les adresses IP et les noms qui leur sont assignés. C'est la résolution de nom. A noter qu'une même adresse IP peut être liée à plusieurs noms de domaine.
D'après le nom, le serveur DNS peut également retrouver l'adresse IP de la machine c'est le Reverse Lookup ou résolution inverse.
Un serveur DNS ne contient en lui-même que peu d'information ce qui le contraint à interroger d'autres serveur DNS lorsque la requête ne trouve pas de réponse dans sa liste de noms. C'est pourquoi, dans de grands Intranet, on trouve un réseau de DNS complet.
Au sein d'un intranet complexe, différents nom de domaine peuvent être donnés à des serveurs internes. Bien évidemment, ces noms de domaine sont souvent indépendant de ceux régulés sur Internet. Par exemple, les ressources documentaires sont publiées sur l'Intranet, dans un serveur HTTP. On peut affilier l'adresse IP de ce serveur à un nom de domaine : 'ressources.intranet'.
La gestion et l'accès à n'importe quel élément du réseau peuvent alors être incroyablement simplifiés, notamment pour les employés non-spécialistes.
Proposition de dénomination :
Notre entreprise se nomme Groupe4. Nous avons un nom de domaine et un site Internet. Notre nom de domaine est groupe4.com.
Plan de dénomination de notre Intranet :
Pour faciliter l'administration ainsi que la mémorisation par les utilisateurs, nous décidons de nommer notre intranet par : intra.groupe4.com (depuis Internet).
En interne, un serveur DNS permettra de nommer les différents groupe et serveurs du réseau. Depuis l'extérieur, des préfixes permettront d'obtenir le même résultat.
Notre Intranet est constitué de :
Nous décidons de nommer les sous-réseaux respectivement :
Comme nous n'avons que 2 sous-réseaux, nous choisissons de retenir des adresses IP de classe C de type 192.168.0.0.
Le serveur se verra assigner l'adresse IP 192.168.0.1. La partie DNS du serveur assurera la résolution de nom. Le serveur HTTP se verra attribuer le nom : intra.groupe4 pour l'accès interne (c'est-à-dire depuis l'intérieur de l'Intranet). Ainsi pour chaque utilisateur du réseau, il faudra saisir dans un navigateur : http://intra.groupe4/etc. pour accèder aux services Intranet de l'entreprise.
Les postes clients du sr1 se verront assigner la plage d'adresses :
192.168.1.1 à 192.168.1.10 (au cas où des PC portables par exemple seraient amenés à se connecter le DHCP leur attribuerait directement une adresse IP).
Les postes du sr2 se verront assigner la plage d'adresses :
192.168.2.1 à 192.168.2.10 (cf raison ci-dessus)
Ci-dessous un schéma de la topologie retenue pour l'Intranet Groupe4 :