\documentclass{article}
\usepackage{a4}
\usepackage{latexsym}
\usepackage{vmargin}
\setmarginsrb{72pt}{72pt}{72pt}{72pt}{0pt}{0pt}{10pt}{10pt}
\usepackage[french]{babel}

\begin{document}

\title{La IP-WHATIS en fran\c cais}
\author{J\'er\^ome Petazzoni, skaya@mail.dotcom.fr}
\maketitle
\tableofcontents
\newpage

%    <td align="right"><h6>...ou tout ce que vous avez jamais voulu savoir sur le TCP/IP (entre
%    autres) sans jamais oser le demander</h6>

%<!-- LASTUPDATEBEGIN -->vendredi 2 avril 1999<!--LASTUPDATEEND -->

\section{Pr\'eambule}

Ce document n'est pas une ``Howto'', qui indique 
comment faire telle ou telle chose (en g\'en\'eral sous Linux), mais 
une ``Whatis'', c'est-\`a-dire un petit background culturel pour 
ceux et celles qui veulent comprendre quelquechose aux r\'eseaux TCP/IP. 
La plupart de ces informations me viennent du NAG (disponible sur 
http://the-floyd.dyndns.org/~skaya/nag/
ou partout ailleurs, et entre autres sous forme imprim\'ee chez O'Reilly). Il existe une excellente
traduction française de ce livre, qui s'appelle Administration R\'eseau Sous Linux ; 
sa port\'ee ne se limitant pas au monde Linux, je ne peux que recommander vivement sa lecture. 

Faites moi plaisir : si vous relevez des fautes (de grammaire, d'orthographe, mais aussi
de fond), signalez-le moi afin que j'apporte les corrections n\'ecessaires. N'h\'esitez pas 
non plus \`a m'envoyer un mail pour me dire ce que vous pensez de ce document ; si je reçois
suffisamment de commentaires positifs, ça m'incitera \`a pondre d'autres doc sur ce sujet
ou d'autres.

\section{Quelques bases techniques}

Cette section n'est pas vraiment n\'ecessaire pour utiliser un r\'eseau IP. Mais pour en
administrer un, il est indispensable de ma\^itriser quelques bases ; ne serait-ce que pour
dissiper la confusion fr\'equente entre IP et TCP...

\subsection{Le protocole IP}

IP veut dire ``Internet Protocol''. Et Internet veut dire ``INTERconnexion
of NETworks'', ce qui veut dire que IP est particuli\`erement adapt\'e pour faire
communiquer entre eux plusieurs r\'eseaux distincts - par exemple, le Palo Alto Research
Center (le c\'el\`ebre PARC) et le petit LAN de 486 de la maison. Du point de vue de IP,
rien ne distingue un serveur Dec Alpha \`a 1 gigahertz, derri\`ere sa liaison \`a 100
megabits/seconde, d'un modeste 386 cach\'e derri\`ere une liaison PPP \`a 2400 bits/seconde.

IP est un protocole orient\'e ``paquet'' ; on dit aussi parfois
``trame''. Cela signifie que pour envoyer des donn\'ees \`a quelqu'un, on fait comme
pour une lettre ou un paquet postal : on pr\'epare ce qu'on veut envoyer, on met le tout
dans une enveloppe, on r\`egle quelques d\'etails concernant l'enveloppe (paiement, adresse
du destinataire...) et on envoie. Rien ne nous garantit que l'enveloppe va arriver dans
les d\'elais, ni m\^eme qu'elle va arriver ; et si on en envoie plusieurs, elles peuvent
arriver dans le d\'esordre. Sur un r\'eseau, c'est encore pire : les paquets peuvent m\^eme
arriver clon\'es en plusieurs exemplaires!

(NB : la philosophie ``paquet'' s'oppose \`a la philosophie du ``circuit
virtuel'', qui est une m\'ethode employ\'ee, par exemple, pour le t\'el\'ephone...)

IP en soit ne sert pas \`a transporter de l'information directement. En fait, le
protocole IP sert de support \`a d'autres protocoles, les plus courants \'etants ICMP, UDP et 
TCP -- un peu de la m\^eme mani\`ere qu'un r\'eseau local Ethernet, qui peut servir \`a transporter 
des donn\'ees IPX ou TCP/IP. 

Un paquet IP
comporte typiquement l'adresse de son exp\'editeur, l'adresse du destinataire, et tout le
reste d\'epend du ``sous-protocole'' utilis\'e (attention, je dis ``sous-protocole'' 
mais certains pourraient, avec raison d'ailleurs, dire ``sur-protocole'' ; 
c'est un point de vue tout relatif).

\subsubsection{Les adresses}

En ce qui concerne les adresses, ce sont les fameux ``dotted quads'', de 32
bits (soit 4 octets) du genre 134.157.0.129 ; ce qui permet th\'eoriquement plus de 4
milliards d'adresses ; en r\'ealit\'e il y en a beaucoup moins. Explications. Les cr\'eateurs
du protocole IP on d\'ecid\'e qu'il y aurait 3 classes de r\'eseaux. Les r\'eseaux de classe
A, qui seraient peu nombreux, mais permettraient un tr\`es grand nombre de machines. A
savoir : 127 r\'eseaux (1.0.0.0 \`a 127.0.0.0) de 16 millions de machines chacun (\`a peu
pr\`es). Ensuite, 16320 r\'eseaux de classe B (de 128.0.0.0 \`a 191.155.0.0),  pouvant
chacun accueillir 65024 h\^otes. Enfin, 2 millions (\`a peu pr\`es) de r\'eseaux de classe C
(de 192.0.0.0 \`a 223.255.255.0) comportant chacun 254 adresses. Les adresses restantes
(224.0.0.0 et au dessus) sont r\'eserv\'ees pour des usages particuliers comme le
multicasting, par exemple (mais c'est une autre histoire).

Notons qu'\`a chaque fois, quelques adresses ont \'et\'e r\'eserv\'ees pour l'usage interne.
Il s'agit du r\'eseau de classe A (10.*.*.*), des r\'eseaux de classe B (172.16.0.0 \`a 
172.31.0.0), et des 256 r\'eseaux de classe C (192.168.*.*) ; ces adresses
sont destin\'ees aux r\'eseaux IP non reli\'es \`a Internet - ou du moins, pas directement.
Quand un routeur voit une telle adresse comme source ou comme destination d'un paquet, il
en d\'eduit que c'est un h\^ote d'un r\'eseau priv\'e qui a laiss\'e s'\'echaper un paquet, et
il ne le fait pas passer. Je parlerai de ces adresses sous le nom d'adresses priv\'ees
(``private addresses'', dans le RFC1918), et un r\'eseau
compos\'e de telles adresses sera de la m\^eme façon appel\'e ``r\'eseau priv\'e'', ou
\`a la rigueur ``r\'eseau interne''. Ne pas confondre avec le terme ``Intranet'', 
qui appartient plus au langage marchand que technique, et qui peut d\'esigner
un r\'eseau priv\'e aussi bien qu'un r\'eseau derri\`ere un Firewall, ou encore un r\'eseau
non IP!

% lien vers RFC1918

\subsubsection{Un mot sur le routage}

C'est IP qui est responsable de l'acheminement des paquets ; c'est-\`a-dire que des
paquets contenant des donn\'ees ICMP, TCP ou UDP seront rout\'es exactement de la m\^eme
façon (sauf exceptions vicieuses, du genre un firewall qui emp\^eche certains paquets de
passer ; mais c'est un autre probl\`eme). De façon g\'en\'erale, un h\^ote ne sait pas en
d\'etail comment faire parvenir ses paquets \`a destination (NB : h\^ote d\'esigne tout ce qui
a une adresse IP : un serveur, une station de travail, un routeur, un hub intelligent, une
cafeti\`ere... si si, je suis s\'erieux!). Dans le pire des cas, il suffit \`a un h\^ote de
savoir comment joindre son routeur, sa ``gateway''. Ensuite, c'est ce routeur qui
prendra des d\'ecisions, et qui passera les paquets \`a telle ou tel autre routeur, et ce
jusqu'\`a ce qu'on arrive au r\'eseau de la machine de destination. Exactement comme pour
une lettre \`a la poste : celui qui poste la lettre ne sait pas forc\'ement par où elle va
passer. Elle va \^etre achemin\'ee de centre de triage en centre de triage, jusqu'\`a arriver
au bureau de poste du destinataire où le facteur s'occupe de la derni\`ere \'etape.

En g\'en\'eral, les routeurs qui font un ``vrai'' travail de routage (par
opposition au travail plus simple pour relier 2 r\'eseaux, par exemple) ont des tables plus
ou moins importantes qui les aident \`a savoir par où faire transiter les paquets, et ces
routeurs \'echangent des tas d'informations entre eux afin de mettre ces tables \`a jour ;
ainsi, si quelque part, quelquechose tombe en panne, le traffic sera redirig\'e par un
autre chemin sans que les utilisateurs s'en rendent compte (enfin, eux ils verront peut
\^etre que ça rame \`a fond, mais les applications n'ont pas conscience de ce genre de
choses - quoi que... - et elles ne planteront pas - quoi que...). 

Le routage ``tout b\^ete'', comment ça marche? Prenons l'exemple d'un h\^ote sur un r\'eseau
local, lequel r\'eseau local est reli\'e \`a Internet par un routeur. On va dire que
l'adresse de cet h\^ote est 192.168.6.201. L'adresse du r\'eseau est donc 192.168.6.0, et on
admettra que le routeur a pour adresse 192.168.6.3. Cet h\^ote aura une table de routage
primitive, indiquant : ``si tu as des paquets pour 192.168.6.201, ils sont pour toi,
prends les. Si tu as des paquets pour 192.168.6.*, ils sont pour quelqu'un sur le r\'eseau
local, envoie les sur la carte r\'eseau. Si tu as des paquets pour *.*.*.*, c'est pour le
monde ext\'erieur, envoie les au routeur, 192.168.6.3, et il se d\'ebrouillera''.
Noter que l'ordre est important : si on avait mis la derni\`ere entr\'ee en premier, tous
les paquets auraient \'et\'e dirig\'es vers le routeur, MAIS l'h\^ote n'aurait jamais r\'eussi
\`a joindre ce routeur, puisqu'il n'est pas dans la table de routage. Ou plut\^ot : il y
est, mais comme le syst\`eme de routage s'arr\^ete \`a la premi\`ere correspondance trouv\'ee,
il ne serait jamais arriv\'e \`a l'entr\'ee correspondante. (Pour tout faire passer par le
routeur, il aurait fallu remplacer 192.168.6.* par 192.168.6.3).

Petite note technique concernant l'ordre d'examen des diff\'erentes routes : il arrive
aussi qu'on examine d'abord les routes les plus ``pr\'ecises'', c'est-\`a-dire en g\'en\'eral
celles qui pointent sur des h\^otes, avant d'examiner celles, plus g\'en\'erales, d\'esignant
des r\'eseaux. La ``pr\'ecision'' d'une route est donn\'ee par son masque.

NB : un routeur qui relie plusieurs r\'eseaux entre eux a une adresse sur chaque
r\'eseau. Une m\^eme machine peut donc avoir plusieurs adresses IP, ça ne pose pas de
probl\`eme. En g\'en\'eral, on a une adresse par interface (c'est \`a dire par carte
r\'eseau/modem/etc.), mais on peut aussi avoir plusieurs adresses par interface - cela sert
en g\'en\'eral \`a faire du Virtual Hosting, voir plus bas. 

Inversement, rien n'emp\^eche d'assigner
la m\^eme adresse \`a plusieurs interfaces -- mais c'est pour des situations bien particuli\`eres.
Cela ne permet pas, par exemple, de r\'ealiser de la r\'epartition de charge (\emph{load balancing}) ;
il faut des drivers (voire des cartes r\'eseaux) \'etudi\'es pour.

%  lien vers virtual hosting

\subsection{Les protocoles port\'es par IP}

Il y en a un bon paquet... (sans jeu de mots). Pour en avoir une petite liste non
exhaustive, regarder le fichier /etc/protocols sous Unix... Je vais parler ici de ceux qui
sont le plus souvent utilis\'es dans mon entourage. 

\subsubsection{ICMP}

Internet Control Message Protocol sert, comme son nom l'indique, \`a passer des messages
de contr\^ole. Hum. Voil\`a qui est clair. C'est le protocole utilis\'e, par exemple, par les
fantastiques programmes ``ping'' et ``traceroute'' (accessoirement, ce dernier utilise 
aussi UDP). Le premier envoie des
paquets \`a un h\^ote, ces paquets lui demandant ``r\'eponds moi'' ; et cet h\^ote,
bienveillant, lui r\'epond ; le programme affiche lorsqu'il reçoit ces r\'eponses, et
affiche aussi le temps \'ecoul\'e entre la question et la r\'eponse. Cela permet de tester
une connexion IP quand rien ne marche : si on arrive \`a ``pinger'' une machine
mais qu'\`a part ça, elle ne r\'epond pas, c'est probablement qu'elle est l\'eg\`erement
plant\'ee ou qu'on lui a dit de ne pas r\'epondre ; si on n'arrive pas \`a la
``pinger'', c'est qu'elle est probablement \'eteinte ; et enfin, si on n'arrive pas
\`a ``pinger'' le routeur qui dessert cette machine, hum, alors c'est normal que la
machine elle m\^eme ne r\'eponde pas (\`a moins bien sûr que le routeur ait \'et\'e inform\'e
de ne pas r\'epondre aux pings...).

Autre utilisation d'ICMP : la transmission d'informations de routage. Si
un routeur doit transmettre un paquet qui a emprunt\'e un d\'etour, il peut envoyer un message
ICMP \`a l'exp\'editeur pour lui indiquer une route plus directe. Cela arrive, par exemple,
quand le routeur re\c coit un paquet venant d'un r\'eseau, destin\'e \`a ce m\^eme r\'eseau.
Ce m\'ecanisme n'est efficace que pour des
topologies simples ; ensuite, on utilise les programmes {\tt gated} ou {\tt routed},
par exemple.

On peut aussi utiliser ICMP sur un firewall, lorsqu'un h\^ote externe essaie de contacter
un h\^ote interne alors qu'on a bloqu\'e l'acc\`es : on envoie alors un message pour
signifier ``acc\`es refus\'e, passez votre chemin''. Cela se traduit en g\'en\'eral par un 
``no route to host''.

\subsubsection{UDP}

Un peu plus \'evolu\'e, le User Datagram Protocol sert, lui, \`a transporter des donn\'ees.
Pour une fois. Il offre un autre avantage sur ICMP : il comprend la notion de
``port'' ; c'est-\`a-dire que chaque h\^ote qui comprend le protocole UDP peut
recevoir et \'emettre en utilisant 65536 ports diff\'erents. Ce qui permet de mieux
diff\'erencier les connexions et d'\'eviter aux donn\'ees des diff\'erents programmes de
communication de se m\'elanger joyeusement. Ainsi, au lieu d'\^etre oblig\'e d'avoir une
machine pour g\'erer le serveur NFS, une pour le yellow page, une derni\`ere pour le DNS,
on leur assigne chacun un port bien d\'efini ; et lorsqu'on souhaite s'adresser au
service DNS, on sait qu'il faut s'adresser au port 53.

En effet, certains de ces ports sont \`a peu pr\`es
standardis\'es ; i.e. on y trouve quasiment toujours les m\^emes services. Pour une liste,
consulter /etc/services sous Unix. Noter aussi que sous Unix, les ports en dessous du port
1024 ne sont utilisables que par l'utilisateur privil\'egi\'e (``root''), ce qui
peut consituer une forme tr\`es primitive d'authentification (si une connexion vient
d'un port en dessous du port 1024, c'est qu'elle a \'et\'e \'etablie par un programme
privil\'egi\'e, et inversement, lorsqu'on s'adresse \`a une machine sur un de ces ports,
on sait que le programme qui prend la connexion en charge n'est pas celui de n'importe
quel utilisateur, mais bien celui assign\'e par l'administrateur de la machine).

Les inconv\'enients d'UDP sont ceux inh\'erents \`a IP, ce qui signifie que les
paquets peuvent arriver en retard, ou dans le d\'esordre, ou en plusieurs exemplaires,
ou ne pas arriver du tout. Il faut donc prendre en compte ce facteur d'incertitude quand on
compte l'utiliser... En pratique, sur un r\'eseau local, UDP est fiable quasiment \`a 100\%
(sauf en cas de congestion du r\'eseau), mais d\`es que quelques routeurs viennent se m\^eler
\`a l'histoire, ne plus trop compter sur ce taux d'erreur.

\subsubsection{TCP}

Ah, on entre dans les choses int\'eressantes. Tout comme UDP, le Transmission Control
Protocol dispose de 65536 ports. Attention, ces ports sont compl\`etement ind\'ependants des
ports UDP! On peut avoir un programme utilisant le port 80 en UDP et un autre l'utilisant
en TCP, sans aucun probl\`eme. Cela ne devrait pas \'etonner ceux qui ont compris que les
ports ne d\'ependent pas d'IP, mais de TCP ou UDP.

Le gros point fort de TCP est qu'il est orient\'e connexion, alors que UDP \'etait
orient\'e datagramme (ou paquet) ; tout comme le t\'el\'ephone par rapport aux lettres (pour
ceux qui sont avec nous depuis le d\'ebut de cette \'emission). Ce qui veut dire que les
donn\'ees qu'on envoie arriveront, et en plus elles arriveront dans l'ordre et en un seul
exemplaire. Par contre, elles arriveront un petit peu moins vite (du moins, quand il y a
des erreurs \`a corriger) et on perd un peu en d\'ebit ; mais c'est peu de chose (\`a peine
1 \% sur un r\'eseau 10 megabits/seconde). En fait,
il y a 3 cas où il est int\'eressant d'utiliser de l'UDP \`a la place du TCP : quand où il
est important que les messages arrivent vite (exemple : les jeux) ; quand les messages \`a
\'echanger sont tellement brefs qu'\'etablir une connexion TCP prendrait trop de temps
(exmple : le DNS) ; et quand on veut un protocole ``stateless'', c'est \`a dire que
le serveur peut red\'emarrer sans causer la d\'econnexion des clients (exemple : le NFS).

\subsection{Le support mat\'eriel}

La connaissance intime du fonctionnement exact du mat\'eriel n'est pas indispensable
pour bien configurer son r\'eseau ; c'est n\'ecessaire uniquement pour d\'epanner des
conflits d'IRQ ou d'autres aberrations propres au monde PC. Cependant, je vais ici parler
un tout petit peu des diff\'erents supports physiques ou non qui peuvent faire transiter
des paquets IP.

\subsubsection{Ethernet (ou r\'eseau local en g\'en\'eral)}

C'est le plus souvent utilis\'e dans les entreprises, les universit\'es, les \'ecoles, et
les petits r\'eseaux locaux qu'on se bricole \`a la maison. Le d\'ebit peut \^etre modeste
(entre 100 et 1000 ko/seconde pour du 10 megabits) ou plus important (plusieurs 
megaoctets par seconde en 100 megabits) ; avec la baisse r\'ecente des prix du mat\'eriel
100 megabits/seconde, ce dernier devient envisageable pour les particuliers.

Ces d\'ebits sont parfaitement adapt\'es \`a du partage de fichiers l\'egers, de la
messagerie, etc. ; et avec du bon mat\'eriel, on peut envisager des applications
plus exigeantes. Un d\'etail int\'eressant : sur un r\'eseau local, on peut envoyer des
paquets en ``broadcast'', c'est \`a dire faire en sorte que toutes les machines du
r\'eseau local reçoivent ce paquet, sans pour autant charger davantage le r\'eseau. 
Mais pour cela il faut utiliser un protocole orient\'e paquet, ce qui exclut TCP.

La configuration typique d'un h\^ote en r\'eseau local est celle \'evoqu\'ee plus haut :
une entr\'ee de routage pour le r\'eseau local, où se trouve le point d'acc\`es au monde
ext\'erieur, et une entr\'ee pour diriger les paquets vers ce point d'acc\`es. Parfois, on
trouve un deuxi\`eme routeur permettant de joindre un autre r\'eseau (imaginons une
entreprise avec 2 r\'eseaux distincts, dont l'un reli\'e \`a Internet ; on peut imaginer pas
mal de possibilit\'es pour le routage : si le routeur qui relie les 2 r\'eseaux entre eux
est celui qui relie le tout \`a Internet, c'est comme avant ; par contre si il n'est
visible que depuis l'un des r\'eseaux, il peut \^etre configur\'e pour rediriger tous les
paquets destin\'es \`a l'autre r\'eseau vers l'autre routeur, reliant les 2 r\'eseaux ; ou
alors chaque h\^ote peut avoir dans sa table de routage le routeur pour Internet ET le
routeur qui relie les deux r\'eseaux).

\subsubsection{PPP}

Point-to-Point-Protocol est utilis\'e traditionnellement pour les liaisons par modem. De
façon plus g\'en\'erale, \`a partir du moment où deux machines peuvent communiquer \`a
travers quelquechose qui ressemble \`a un p\'eriph\'erique en mode caract\`ere, PPP peut marcher 
(un p\'eriph\'erique en mode caract\`ere, c'est quelquechose que l'on peut utiliser comme
un tuyau ; ce qu'on y \'ecrit ressort de l'autre c\^ot\'e dans le m\^eme ordre. Exemple : une 
ligne s\'erie).
Ainsi, en utilisant pty-redir ou d'autres outils, on peut faire marcher PPP... via une
liaison telnet. Les petits fut\'es vont remarquer que c'est un peu inutile puisque si on
peut faire un telnet, c'est qu'on a d\'ej\`a une liaison qui marche ; et bien lisez la fin
de ce document au sujet des VPN...

\subsubsection{Encapsulation}

L'encapsulation, c'est faire passer un protocole dans un autre. Un petit exemple : un
h\^ote est perdu au fin fond d'un r\'eseau IPX. Beurk! Tout passe par IPX, aucun acc\`es
TCP/IP en vue. Sauf... sauf \`a l'autre bout du r\'eseau, derri\`ere 10 routeurs (tous IPX), il y a une
machine qui a un acc\`es IP. Cette machine va \'etablir une liaison IPX avec celle qui est
isol\'ee, et ensuite tous les paquets IP seront relay\'es par cette liaison IPX.
Évidemment, cela demande du logiciel sp\'ecial de part et d'autre. Un autre int\'er\^et de
l'encapsulation est de permettre le ``roaming'' ; par exemple pour un portable qui
se d\'eplace souvent et qui a une adresse IP changeante, et qui veut avoir toujours la
m\^eme adresse. Il fait comme plus haut : il a un h\^ote qui se charge de prendre ses
paquets (dirig\'es vers son adresse fixe) et il les redirige par le biais de son adresse
mobile.

\section{Administration d'un r\'eseau IP}

Maintenant, abordons quelques probl\`emes plus ou moins cruciaux, qui viendront t\^ot ou
tard se poser d\`es lors qu'on administre un r\'eseau en IP, qu'il s'agisse d'un WAN de
plusieurs milliers de postes ou d'un petit r\'eseau local avec 2 ordinateurs en LAN dont un
reli\'e en PPP \`a internet. On va surtout aborder pas mal de ``recettes'' qui
marchent, ou qui marchent moins bien mais qu'il faut conna\^itre parce qu'elles sont
utilis\'ees \`a gauche ou \`a droite.

\subsection{Le pool d'adresses est limit\'e}

Premi\`ere constatation : nous ne sommes plus \`a l'aube d'Internet, et on manque
d'adresses IP. La preuve? Si on en avait assez, on aurait toujours la m\^eme adresse en se
connectant par son provider habituel. En fait, les providers font une allocation
d'adresses IP dynamique : ils ont un stock de, mettons, 200 adresses pour 1000 abonn\'es
(en g\'en\'eral, ils ont au moins un r\'eseau de classe C, c'est \`a dire 254 adresses, mais
il faut r\'eserver des adresses pour les routeurs, les serveurs web, mail, ftp... et puis,
le provider n'a peut-\^etre que 200 modems, de toute façon). Chaque modem a une adresse IP
qui lui est assign\'ee, et quand on appelle le provider, on tombe sur le premier modem
disponible - pas forc\'ement toujours le m\^eme...

Il est possible de demander une adresse IP statique, mais en g\'en\'eral ça coûte cher.
Afin d'avoir une illusion d'adresse IP fixe, on peut utiliser le service dyndns 
(http://www.dyndns.org) qui permet d'associer une adresse du genre
toto.dyndns.org \`a une adresse IP, et de changer cette assignation \`a chaque fois qu'on
change d'adresse.

% lien vers dyndns.org

Autre situation dans laquelle on manque d'adresses : prenons le cas d'une petite
Universit\'e, ou un gros Lyc\'ee, qui dispose d'un r\'eseau de classe C mais qui a plus de
300 machines. Ou encore, un particulier avec un acc\`es Internet - donc une seule adresse -
mais plusieurs machines \`a connecter. Plusieurs solutions sont possibles.

\subsubsection{DHCP, bootp, rarp...}

Le RARP (Reverse Address Resolution Protocol) n'est pas vraiment \'etudi\'e au d\'epart
pour r\'esoudre notre probl\`eme, mais il est un peu l'anc\^etre des 2 autres. Commençons
par le commencement, \`a savoir l'ARP : Address Resolution Protocol. Sur un r\'eseau
Ethernet, quand une machine doit envoyer un paquet \`a une autre, elle doit conna\^itre
l'adresse Ethernet de cette derni\`ere. Les adresses Ethernet sont sur 6 octets, du genre
00:80:c0:45:7a:99. Afin d'apprendre cette adresse, l'exp\'editeur utilise le protocole ARP
(en gros, il crie tr\`es fort sur le r\'eseau : ``Qui est 192.168.9.1?'' et
l'int\'eress\'e lui r\'epond ``Moi, 00:05:00:cf:a0:4b''). On a d\'evelopp\'e plus tard
le RARP, qui permet \`a une machine sans disque dur (ou m\^eme avec) qui ne conna\^it pas son
adresse IP, mais qui conna\^it son adresse Ethernet, de s'autoconfigurer via le r\'eseau
avec l'aide d'un serveur.

L'int\'er\^et de ces techniques est d'installer la m\^eme configuration \`a l'octet pr\`es sur
un ensemble de machine, puis que ces machines puissent se diff\'erencier les unes des
autres et obtenir les fichiers de configurations qui leur sont propres via le r\'eseau,
aupr\`es d'un serveur central.

Traditionnellement, les stations Sun qui doivent booter en ``diskless'' font
une requ\^ete RARP, puis, connaissant leur adresse IP et celle de la machine qui a r\'epondu
\`a leur requ\^ete RARP, elles demandent via le protocole tftp un fichier \`a cette machine.
Ce fichier, tr\`es petit (quelques dizaines de ko) va ensuite \^etre ex\'ecut\'e, et appeler
un serveur bootparam en RPC (diff\'erent de bootp!), afin d'obtenir l'adresse du serveur
qui h\'eberge ses fichiers. Ensuite, le noyau va \^etre r\'ecup\'er\'e depuis ce serveur via le
protocole NFS, et \^etre ex\'ecut\'e. L'enfance de l'art, quoi :-).

Pour simplifier un peu les choses, le protocole bootp est apparu. Il combine le RARP et
le bootparam, puisqu'il permet \`a une machine d'apprendre son adresse IP, et
\'eventuellement une foule de param\`etres, comme : l'adresse du serveur DNS, du routeur
local, le masque de sous-r\'eseau, le serveur qui h\'eberge ses fichiers, le noyau \`a
utiliser, etc. Sur certaines stations DEC et sur les Powermac (par exemple), la machine
fait une requ\^ete bootp, puis t\'el\'echarge le noyau via tftp, et le noyau est ex\'ecut\'e
directement.

Enfin, le DHCP (Dynamic Host Configuration Protocol) est apparu afin de combler
quelques lacunes du bootp. Le DHCP permet de transmettre des param\`etres du serveur vers
le client, mais aussi du client vers le serveur (exemple : sous MS Winzob configur\'e pour
obtenir une adresse IP en DHCP, l'ordinateur envoie au serveur le nom sous lequel il
appara\^it dans le voisinage r\'eseau). De plus, le DHCP exploite le concept de
``bail'' (``lease'', en anglais), pour g\'erer les adresses dynamiques :
quand un h\^ote demande au serveur DHCP de lui fournir une adresse IP, le serveur indique
pendant combien de temps cette adresse va \^etre valide. C'est au client de renouveler le
bail avant la fin de la p\'eriode de validit\'e s'il veut conserver son adresse. Les baux
peuvent \^etre aussi courts que 15 minutes (pour un banc de test TCP/IP) et aussi longs que
plusieurs ann\'ees (dans une universit\'e où le parc ne bouge que tous les ans, aux
vacances).

On entend aussi parfois parler de PXE ; le PXE est une m\'ethode de boot reposant enti\`erement
sur le r\'eseau. Ce n'est pas \`a proprement parler un protocole, puisqu'il utilise le DHCP et le
TFTP ; on le trouve sur certaines cartes r\'eseau et sur les PCs ``diskless'', sans lecteur de
disquette ni lecteur de CD-ROM.

\subsubsection{D\'ecoupage en ``subnets''}

Prenons maintenant le cas d'une organisation qui a 1 r\'eseau de classe C attribu\'e,
mais qui a physiquement 2 r\'eseaux distincts, avec chacun une petite quantit\'e de machines
(disons une centaine maximum). Mais pour des raisons X ou Y, on veut pouvoir contr\^oler le
traffic entre les 2 r\'eseaux ; ou plus simplement, les 2 r\'eseaux sont distincts et
reli\'es par un modem ou n'importe quelle liaison de type point \`a point. Il est possible
de d\'ecouper une tranche d'adresses en plusieurs sous-tranches, qu'on appelle des
subnets... tout simplement.

Pour bien comprendre comment ça marche, examinons ce qui se passe dans le cas
g\'en\'eral, en interne. Le syst\`eme d'exploitation n'a pas conscience de r\'eseaux de classe
A, B, ou C. Ce qu'il conna\^it, c'est l'adresse de la machine, l'adresse du r\'eseau, le
masque du r\'eseau et l'adresse de broadcast. Ces termes n'auront plus de secret dans
quelques minutes... L'adresse de la machine : voil\`a un concept pas tr\`es difficile.
L'adresse du r\'eseau : il s'agit du pr\'efixe commun \`a tous les h\^otes d'un r\'eseau ;
conventionnellement, on met \`a z\'ero la partie de l'adresse r\'eserv\'ee aux h\^otes. Le
masque du r\'eseau : c'est l'adresse 255.255.255.255, en mettant \`a z\'ero la partie de
l'adresse r\'eserv\'ee aux h\^otes. L'adresse de broadcast : c'est - en g\'en\'eral - l'adresse
du r\'eseau, en mettant \`a 1 tous les bits de la partie de l'adresse r\'eserv\'ee aux h\^otes.
Aha, je suis sûr que personne n'a compris, aussi voici quelques exemples.

\begin{verbatim}
<table border="2" cellpadding="2">
  <tr>
    <td align="left">Une machine</td>
    <td align="left">Une autre machine</td>
    <td align="left">R\'eseau</td>
    <td align="left">Masque</td>
    <td align="left">Broadcast</td>
  </tr>
  <tr>
    <td align="left">192.168.6.1</td>
    <td align="left">192.168.6.53</td>
    <td align="left">192.168.6.0</td>
    <td align="left">255.255.255.0</td>
    <td align="left">192.168.6.255</td>
  </tr>
  <tr>
    <td align="left">10.0.51.12</td>
    <td align="left">10.6.0.0</td>
    <td align="left">10.0.0.0</td>
    <td align="left">255.0.0.0</td>
    <td align="left">10.255.255.255</td>
  </tr>
  <tr>
    <td align="left">134.157.96.28</td>
    <td align="left">134.157.65.20</td>
    <td align="left">134.157.64.0</td>
    <td align="left">255.255.192.0</td>
    <td align="left">134.157.127.255</td>
  </tr>
</table>
</center></div>

\end{verbatim}

Hum, ceux qui suivent vont halluciner quand ils vont voir la 3\`eme ligne... Qui est
pourtant parfaitement correcte. Si vous comprenez les 2 premi\`eres lignes, mais pas la
3\`eme, regardez ce que donne en binaire cette 3\`eme ligne :

\begin{verbatim}

<table border="2" cellpadding="2">
  <tr>
    <td>Une machine</td>
    <td>134.157.96.28</td>
    <td><u><strong>10000110.10011101.01</strong></u>100000.00011100</td>
  </tr>
  <tr>
    <td>Une autre</td>
    <td>134.157.65.20</td>
    <td><u><strong>10000110.10011101.01</strong></u>000001.00010100</td>
  </tr>
  <tr>
    <td>R\'eseau</td>
    <td>134.157.64.0</td>
    <td><u><strong>10000110.10011101.01</strong></u>000000.00000000</td>
  </tr>
  <tr>
    <td>Masque</td>
    <td>255.255.192.0</td>
    <td><u><strong>11111111.11111111.11</strong></u>000000.00000000</td>
  </tr>
  <tr>
    <td>Broadcast</td>
    <td>134.157.127.255</td>
    <td><strong><u>10000110.10011101.01</u></strong>111111.11111111</td>
  </tr>
</table>
</center></div>

\end{verbatim}

C'est un r\'eseau de classe B et demi... Ou plus exactement, un subnet d'un r\'eseau de
classe B. On peut ainsi diviser un r\'eseau de 65000 h\^otes en 2 r\'eseaux de 32000 et
quelques, ou 4 r\'eseaux de 16000 et quelques, ou encore un de 32000 et 2 de 16000, etc.
J'esp\`ere sinc\`erement que j'ai \'et\'e assez clair... Sinon, pas d'inqui\'etude : quand on
g\`ere des r\'eseaux avec des adresses priv\'ees, on peut toujours se d\'ebrouiller sans
subnet, et quand on g\`ere des r\'eseaux  avec des ``vraies'' adresses Internet,
eh bien on est cens\'e \^etre assez comp\'etent pour ma\^itriser ça :-). Exercice : en
supposant que l'administrateur du site de tout \`a l'heure s'est vu attribuer les adresses
193.1.2.*, calculer les adresses r\'eseaux, les masques et les broadcast des 2 subnets.

\subsubsection{Mise en place d'un r\'eseau priv\'e ; d'une DMZ}

Mais certains ne trouveront pas leur bonheur dans les solutions \'evoqu\'ees plus haut.
Soit parce qu'ils ne peuvent accepter une solution bas\'ee sur des adresses dynamiques
(toutes les machines doivent pouvoir fonctionner en m\^eme temps), ou parce qu'ils ne
peuvent diviser en subnet puisque de toute façon ils n'ont pas assez d'adresses IP. La
solution est alors de mettre en place un r\'eseau interne, avec - histoire de faire ça
bien - une DMZ.

Le r\'eseau priv\'e sera un r\'eseau avec des adresses priv\'ees (voir au d\'ebut de ce
document pour un rappel \`a ce sujet). Pour acc\'eder \`a Internet, les machines du r\'eseau
priv\'e utiliseront un syst\`eme de mandatement (le fameux ``proxy'') ou de
traduction d'adresses (on voit parfois translation, de l'anglais ``translate'').
De plus amples d\'etails sont disponibles plus loin, mais pour sch\'ematiser, elles
demanderont \`a une machine - qui elle, aura une ``vraie'' adresse IP - de faire le
relais pour elles. Quant \`a la DMZ, il s'agit d'un r\'eseau qui a donc de
``vraies'' adresses IP, et qui se trouve g\'en\'eralement entre les routeurs
d'acc\`es \`a Internet et le r\'eseau interne. DMZ signifie DeMilitarized Zone. Elle contient
en g\'en\'eral les serveurs devant \^etre accessibles \`a la fois depuis l'int\'erieur et
l'ext\'erieur, par exemple : le serveur de messagerie.

Notons qu'en r\`egle g\'en\'erale, une machine situ\'ee sur le r\'eseau priv\'e ne peut \^etre
serveur - au sens conventionnel du terme ; plus simplement, il est techniquement
impossible d'\'etablir une connexion depuis l'ext\'erieur vers une de ces machines.
Attention, ça ne veut pas dire que les donn\'ees ne passent que dans un sens ; ça veut
dire que dans le meilleur des cas, une machine de l'int\'erieur peut \'etablir une connexion
vers l'ext\'erieur, et ensuite des donn\'ees peuvent transiter par cette connexion dans les
deux sens ; mais l'inverse est impossible (tout simplement parce que les machines du
r\'eseau interne, vues de l'ext\'erieur, n'existent pas puisqu'elles n'ont pas de
``vraie'' adresse IP!). Et comme pour 99\% de serveurs, c'est le client qui
\'etablit la connexion...

Voir plus loin pour des explications plus d\'etaill\'ees sur les firewall.

\subsection{Le virtual hosting}

Changeons un peu de sujet. Le virtual hosting n'est pas une fonctionalit\'e capitale du
protocole IP, mais c'est utile de savoir que ça existe. Imaginons que l'on veuille
h\'eberger 2 serveurs Web, disponibles sous les noms www1.toto.com et www2.toto.com, mais
qu'on ne dispose que d'une seule machine (les temps sont durs). C'est possible : il suffit
de s'arranger pour que www1.toto.com corresponde \`a l'adresse, mettons, 192.168.12.1 et
www2.toto.com, 192.168.12.2. Ensuite, on va attribuer \`a la machine qui va h\'eberger les
sites, ces 2 adresses IP. Et le programme serveur se d\'ebrouillera pour r\'eagir de façon
diff\'erente selon qu'il est contact\'e sur une adresse ou sur l'autre. Cela peut marcher
pour d'autres choses que les serveurs Web, bien sûr.

Note : pour le cas particulier des serveurs Web, il est possible de r\'ealiser du
Virtual Hosting avec une seule adresse IP, car le nom du serveur est sp\'ecifier dans
la requ\^ete. Pour les autres protocoles, le Virtual Hosting n\'ecessite g\'en\'eralement plusieurs
adresses IP.

\section{Quelques mots sur la s\'ecurit\'e et le concept de firewall}

T\^ot ou tard, il faudra s'occuper du probl\`eme de la s\'ecurit\'e, c'est \`a dire les
petits malins qui vont essayer de p\'en\'etrer le r\'eseau depuis l'ext\'erieur. Dans le
meilleur des cas, cela se traduira par un ``nuke'' de quelques b\'ecanes, ce qui se
r\'esout par un reboot ; mais un intrus pourrait aussi s'introduire sur un ordinateur, et
copier des fichiers ``int\'eressants'' et g\'en\'eralement secrets (mots de passe,
comptabilit\'e d'une entreprise, plans des catacombes, organigramme du RPR, analyse de la
robe de Monica Lewinsky...). Afin de permettre aux utilisateurs normaux de continuer de
travailler sans avoir \`a entrer des mots de passes et se soumettre \`a des scans de r\'etine
toutes les 5 minutes, mais de couper les ponts avec les ind\'esirables venant de
l'ext\'erieur, on met en place des firewall.

Un firewall, ça peut \^etre un simple routeur intelligent (cisco, ascend...) que l'on
peut contr\^oler \`a distance, depuis l'int\'erieur du r\'eseau ; cela peut \^etre aussi un
terrible serveur surpuissant \'equip\'e d'une panoplie logicielle monstrueuse. La solution
la plus intelligente consiste \`a prendre une machine de performances modestes (inutile de
d\'eployer un Pentium pour g\'erer un traffic de quelques dizaines de ko/seconde, un 386
suffit), mais robuste et stable (pas de cartes m\`eres overclock\'ees, de toute façon le
modem reste \`a 14400 bits/seconde). Le choix le plus important est celui du syst\`eme
d'exploitation. On \'eliminera d'entr\'ee Windows ou tout autre syst\`eme de nature instable,
ou lent, ou peu souple. Si on opte pour un Unix gratuit et libre, on a le choix entre
Linux (se tourner alors vers Debian ou Jurix, en \'evitant soigneusement RedHat) et *BSD ; 
NetBSD est plus stable que Linux, et pour mettre l'accent sur la s\'ecurit\'e on choisira 
OpenBSD. Sinon, le bon vieux DOS peut aussi faire l'affaire, mais les logiciels 
sont beaucoup moins puissants et assez limit\'es...

De mani\`ere g\'en\'erale, un bon firewall doit \^etre strictement imp\'en\'etrable de
l'ext\'erieur. Il doit \^etre impossible de toucher \`a quoi que ce soit sans \^etre \`a
l'int\'erieur du site, ou tout du moins sur une liaison s\'ecuris\'ee, crypt\'ee et
authentifi\'ee (ssh est pratique pour cela). Pour \'eviter tout trou de s\'ecurit\'e
intempestif, on chassera du firewall tous les serveurs - web, mail, TOUT doit
dispara\^itre. Ensuite, on peut se consacrer \`a la configuration du firewall.

Dernier d\'etail : il faut bien sûr se pr\'emunir de toute agression externe, mais il
faut aussi pr\'evoir le cas de maladresses internes qui pourraient ouvrir des br\`eches dans
le syst\`eme de s\'ecurit\'e, exemple : un employ\'e qui lance le serveur Web de Trompe-Page
(au hasard) et qui permet du coup \`a un intrus d'acc\'eder \`a la totalit\'e du disque dur,
et entre autres \`a des fichiers sensibles.

\subsection{Le filtrage}

C'est ce qu'on utilise dans le cas où, sans le firewall, toutes les machines seraient
accessibles. C'est \`a dire que chaque machine a une ``vraie'' adresse IP et est
susceptible d'\^etre attaqu\'ee, et chaque machine est susceptible de devoir utiliser les
services de l'ext\'erieur. Le filtrage consiste \`a bloquer ou laisser passer des paquets IP
suivant certains crit\`eres. Attention, il s'agit le plus souvent de crit\`eres simples ; ne
pas esp\'erer bloquer les paquets ``qui contiennent un virus'' ou ``qui
essaient de pirater le site''. On peut filtrer :

\subsubsection{...par adresse (niveau IP)}

Si l'on a remarqu\'e que des voyous localis\'es sur piratez.org essaient de s'introduire
sur le site, on peut dire au firewall de tout laisser passer, sauf les paquets en
provenance et \`a destination de ce site. Un bon firewall qui fonctionnerait de la sorte
interdirait plut\^ot tous les paquets, sauf ceux qui viennent de sites ``sûrs''.
En fait, en g\'en\'eral les firewalls interdisent tout traffic, sauf le traffic avec
certains h\^otes de la DMZ - et encore, pas tous.  

\subsubsection{...par protocole}

L'UDP \'etant rarement utilis\'e pour dialoguer avec Internet (on l'utilise
majoritairement pour le NFS, un syst\`eme de partage de fichiers en r\'eseau), on bloque
g\'en\'eralement toutes les communications UDP depuis ou vers Internet. De plus, comme la
plupart des programmes qui utilisent UDP passent par le syst\`eme RPC, ils n'utilisent pas
forc\'ement toujours les m\^emes ports, et on ne peut m\^eme pas esp\'erer filtrer par service
(voir ci dessous).

Quant \`a l'ICMP, il peut \^etre utilis\'e par des intrus pour ``sonder'' un site,
et estimer la topologie interne d'un r\'eseau, en faisant par exemple des calculs de delta
sur les diff\'erents pings, ou en faisant des traceroute. Certains administrateurs filtrent
donc ICMP. De la m\^eme mani\`ere, au lieu de renvoyer des message ICMP disant ``cet
h\^ote est derri\`ere un firewall, passez votre chemin'', ils ne renvoient rien du tout
(autant laisser l'ennemi dans l'ignorance la plus noire).

\subsubsection{...par service (niveau TCP ou UDP)}

Le filtrage par service est possible pour le TCP et l'UDP, mais est surtout utilis\'e en
TCP car les ports UDP peuvent changer (\`a cause du RPC). Le filtrage par service consiste
tout simplement \`a interdire ou autoriser des connexions en fonction des ports utilis\'es.
Exemple : interdire tous les ports sortants, sauf le 80 (utilis\'e par les serveurs Web).
Inconv\'enient : si un serveur diff\'erent (IRC, par exemple) accepte des connexions sur le
port 80, ça passera ; et \`a l'inverse, si un serveur Web attend des connexions sur un
autre port, ça ne passera pas.

Façon plus \'el\'egante de r\'ealiser un acc\`es ``Web seulement'' : utiliser un
serveur mandataire (``proxy'', pour ceux qui, comme moi, n'arrivent plus \`a parler
français). Voir plus bas pour plus de d\'etails. Noter qu'on peut aussi utiliser le bit
d'ACK comme r\`egle de filtrage, ce qui permet de n'autoriser que les connexions sortantes
(une machine \`a l'int\'erieur peut contacter une machine de l'ext\'erieur, mais pas
l'inverse). Et \'evidemment, toutes ces r\`egles peuvent se combiner dans tous les sens, de
façon par exemple \`a tout interdire, sauf toutes les connexions venant d'un autre site
(d'une filiale par exemple) et les connexions depuis quelques serveurs bien choisis vers
notre serveur SMTP sur le port 25 (protocole et port g\'en\'eralement utlis\'es pour relayer
du traffic e-mail).

\subsection{Toujours plus de s\'ecurit\'e}

On peut bien sûr aller encore plus loin! Les m\'ethodes que je vais \'evoquer ici sont
non seulement parmis les plus sûres, mais aussi parmis les plus simples \`a mettre en
oeuvre. G\'enial, non? Par contre, elles sont aussi les plus restrictives... Tout en
laissant aux utilisateurs des machines du r\'eseau priv\'e une marge de manoeuvre que je
juge acceptable.

\subsubsection{Mandatement ou relais (serveur proxy)}

Utilis\'e le plus souvent de façon consciente pour le Web et le ftp, mais aussi de
façon inconsciente pour le DNS, les news et le mail. Prenons un exemple
``inconscient'', le DNS. Le DNS est le service qui permet de traduire
``kangaroo.krypton.fr'' en 192.168.5.1. Ce service est en UDP, sur le port 53.
Comment faire pour permettre aux machines du r\'eseau priv\'e d'utiliser DNS sans leur
ouvrir un port UDP vers le reste du monde? Tout simplement en installant un serveur DNS \`a
l'int\'erieur du r\'eseau. Comme dans la plupart des cas, c'est d\'ej\`a fait... Ensuite, il
suffit d'autoriser les traffic UDP sur le port 53, mais uniquement pour le serveur DNS.
G\'en\'eralement, les serveurs DNS sont configur\'es de façon \`a r\'esoudre d'eux m\^eme les
adresses locales (le serveur DNS de toto.com conna\^it les adresses de toutes les machines
de son domaine - logique), et \`a relayer la requ\^ete \`a un autre serveur lorsqu'ils
ignorent la r\'eponse. Ils gardent ensuite cette r\'eponse en m\'emoire pour r\'ef\'erence
ult\'erieure.

Autre exemple d'utilisation naturelle d'un syst\`eme de relais : l'e-mail, et aussi je
suppose la plupart des messageries \'electroniques. Lorsqu'on envoie un message \`a
quelqu'un sur un site, on ne contacte jamais directement la machine de l'utilisateur, ni
m\^eme parfois le serveur de messagerie du site : on envoie le courrier \`a son serveur SMTP, et
lui va le transmettre au serveur du site du destinataire. Dernier exemple : les forums de
discussion USENET (les fameux ``newsgroups'') ; quand un site monte son propre
serveur news, cela permet aux utilisateurs d'y avoir acc\`es sans se connecter \`a
l'ext\'erieur. Tous ces serveurs -- DNS, mail, news se trouvent g\'en\'eralement dans la DMZ,
ou, pour les petits sites, sur le firewall (ce qui est extr\^emement d\'econseill\'e!)

Petite note culturelle : on traduit parfois ``gateway'' par passerelle, et on
est alors amen\'e a employ\'e ce terme pour d\'esigner un routeur. Comme me l'a fait
remarquer quelqu'un qui semble en conna\^itre assez long sur ce sujet :-), un
routeur d\'esigne un \'el\'ement mat\'eriel (avec \'eventuellement un peu de logiciel)
destin\'e, comme son nom l'indique, \`a router des paquets, c'est \`a dire les envoyer vers
tel ou tel endroit afin de les approcher de leur destination finale. Exemple de routeur :
les plus ou moins petites bo\^ites magiques portant des \'etiquettes prestigieuses comme
Cisco, Ascend... Ou encore, une machine sous Linux avec le noyau appropri\'e. Une
passerelle, par contre, est essentiellement logicielle, exemple : un serveur de messagerie
qui relaie du courrier \'electronique.

Ensuite, les exemples ``conscients'' : c'est le cas du proxy Web. Dans la
plupart des navigateurs actuels, on peut sp\'ecifier un ``serveur proxy'', et au
lieu de contacter directement le site, le navigateur demandera \`a ce fameux serveur de
faire la requ\^ete \`a sa place. L\`a encore, ce serveur est dans la DMZ. Il existe aussi
certains firewall (exemple : le syst\`eme SOCKS) qui permettent d'ouvrir arbitrairement des
ports, moyennant un compte sur le firewall. Ainsi on peut communiquer plus librement, mais
chaque connexion est enregistr\'ee dans un ``log'' (fichier journal) qui servira en
cas d'incident de s\'ecurit\'e.

\subsubsection{Translation d'adresses (masquerading, NAT)}

C'est le syst\`eme fr\'equemment utilis\'e sous Linux ou *BSD, et qui a un tr\`es grand
m\'erite : il ne demande aucune configuration sur le client (hormis l'adresse IP, r\'eseau
et routeur ; et encore, en DHCP cela peut \^etre enti\`erement automatis\'e). Cela fonctionne
comme un mandatement g\'en\'eralis\'e. Le serveur responsable de cette op\'eration a dans sa
table de routage ou de firewall une entr\'ee du type ``masquerade tous les paquets
venant du r\'eseau X, destin\'es au r\'eseau Y, sur le port Z''. En g\'en\'eral, X d\'esigne
le r\'eseau interne, Y le r\'eseau Internet, et Z tous les ports (sauf si on veut
restreindre \`a l'usage du Web, par exemple). Concr\`etement, lorsque le serveur reçoit un
paquet venant du r\'eseau X et destin\'e au r\'eseau Y, il ``maquille'' ce paquet, en
faisant croire qu'il vient de lui-m\^eme ; et il note le port source qu'il utilise de son
c\^ot\'e. Et ensuite il l'envoie sur Y. Lorsque les r\'eponses arrivent - sur le port source,
qu'il a not\'e - il remaquille les paquets et les renvoie \`a l'h\^ote du r\'eseau X, qui n'y
voit que du feu.

C'est \`a ce jour la seule solution que je connaisse qui marche sur toutes les
plateformes sans installation d'aucun logiciel particulier. Les gens pointilleux
remarqueront un d\'etail : cela ne peut marcher que pour les protocoles où il y a une
notion de port, puisque j'ai parl\'e de port source. Eh bien ça marche aussi pour ICMP,
mais au lieu de noter le port, le serveur note un num\'ero de s\'equence. 

La traduction d'adresses, comme tous les autres syst\`emes de mandatement, a cela de
magique qu'un h\^ote du r\'eseau priv\'e a un acc\`es quasi illimit\'e au monde ext\'erieur,
mais que le monde ext\'erieur ne peut en aucun cas s'introduire sur le r\'eseau priv\'e,
puisque les h\^otes de ce r\'eseau n'existent pas, de l'ext\'erieur. Le seul moyen est alors
de s'introduire dans le firewall - ce qui est tr\`es difficile, puisque nous avons
consciencieusement d\'esactiv\'e tous les serveurs, et tous les moyens d'acc\`es ext\'erieurs.

\subsubsection{Utilisation de ``jetons''}

C'est le principe expliqu\'e plus haut pour les firewall de type SOCKS : lorsqu'un
utilisateur veut acc\'eder au monde ext\'erieur, il doit effectuer une certaine manoeuvre
(exemple : faire un telnet sur un h\^ote, se loger et lancer un certain programme), ce qui
lui ouvre un acc\`es vers l'ext\'erieur. L'int\'er\^et principal est de pouvoir garder traces
de toutes les demandes effectu\'ees par les utilisateurs, et aussi d'avoir un syst\`eme qui
marche pour la plupart des applications (pour un firewall SOCKS, il faut une application
``socksifi\'ee'', ce qui demande au moins une recompilation - pas de probl\`eme sous
Unix, mais sous Windows... ouh l\`al\`a...). C'est cependant peu pratique de devoir faire un
telnet \`a chaque fois qu'on veut acc\'eder au r\'eseau ; de plus les utilisateurs peuvent
\^etre tent\'es de faire un petit programme qui automatise le telnet en tapant leur login et
leur mot de passe ; et quelqu'un pourrait r\'ecup\'erer ce programme et en extraire ces
informations, usurpant l'identit\'e de l'utilisateur.

\section{Cerise sur le g\^ateau : le VPN}

Cette section est encore en d\'eveloppement. Tout ce que je peux dire, c'est que le VPN
permet \`a des petits r\'eseaux locaux comme ceux que nous avons tous (quelques machines en
LAN, avec une liaison PPP \`a internet) de se relier les uns aux autres afin de communiquer
de façon transparente. Cela repose sur l'utilisation de PPP et d'encapsulation des
donn\'ees, et d'une dorsale virtuelle... (envoyez le g\'en\'erique de twilight zone, ça le
fait!!!)

\section{Remerciements}

À ceux et celles qui m'ont envoy\'e des corrections. Si vous souhaitez que votre
nom apparaisse, envoyez moi un mail (je ne voulais pas le faire sans autorisation).

Sp\'eciale d\'edicace \`a : (par ordre analphab\`etique)

Amfo - c'est lui qui, le premier, a commis l'erreur de me passer la distrib infomagic
automne 96. Ensuite, c'est avec l'aide de son NAG en français que j'ai configur\'e mon
r\'eseau local. Merci Julien...\newline
Krystal - mais tu vas le lire ce putain de NAG ou il faut que je te le fasse bouffer?!?\newline
Shadow - VMS Ope'lato'l Awaiting Inst'luctions :-)

... et tous les garçons et les filles qui, ici ou l\`a, sont root sur un Linux, un
*BSD, ou n'importequoi d'autre qui a le goût d'Unix. (Et il ne suffit pas de taper ``root'' dans le
login windows! Usurpateurs!)

\end{document}
