Professional Documents
Culture Documents
Flux Applicatifs
Cache Web
ISA Server 2000
LDAP
GAIO Pascal
Filière Télécommunication
Introduction
Les chapitre 1,2 et 3, traiteront du cache Web standard, c’est-à-dire lorsque n’importe
qui se connecte sur Internet. Le but sera de déterminer quelles données seront stockées
chez le client et ce que le serveur Web garde comme informations après son passage.
Nous regarderons diverses commandes http qui modifient le comportement du cache
du côté client.
Dans une seconde partie, j’utiliserai un logiciel appelé ISA Server 2000 (Internet
Security and Acceleration Server 2000) en tant que proxy et serveur de cache.
Ainsi je regarderai ce qu’apporte de plus d’ajouter un proxy entre un client et un
serveur, par rapport à une connexion directe entre les deux. L’installation d’un logiciel
comme ISA Server, devrait théoriquement accélérer les accès aux sites Web. Mais est-
ce vraiment un gain important ou est-ce simplement une mascarade comme la plupart
des logiciels qui se disent accélérateurs d’accès aux sites alors qu’ils ne font que de
charger en cache les liens sur les pages que l’on visite pendant que l’utilisateur ne fait
rien ? Ce logiciel ISA Server 2000 fonctionne-t-il sur le même principe ? Nous
démontrerons dans les chapitres 4,5 et 6 comment ISA Server 2000 fait pour accélérer
les accès aux pages sur Internet.
Dans une troisième partie, nous allons regarder les possibilités des annuaires LDAP.
Pour cela, il va falloir étudier comment construire un annuaire et par la suite, étudier
les principes qu’offre le protocole LDAP (chapitre 7 et 8). Ensuite nous allons étudier
les 2 principales applications des annuaires LDAP. Soit les références sur d’autres
serveurs (referall chapitre 9) et la copie de base de données (replication chapitre 10).
Dans une dernière étape consacrée au protocole LDAP, j’utiliserai un Firewall Check
Point afin de gérer des accès à un serveur Web. Ces accès seront définis sur un
annuaire LDAP. Pour mon étude, j’ai utilisé le serveur LDAP iPlanet Directory Server
5.0 pour la gestion de l’annuaire.
Flux Applicatif 2
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Remerciements
A M.Dutheil, qui m’a indiqué les points importants à étudier lors de notre entretien.
A M.Jenny, professeur de diplôme qui m’a assisté durant ces trois mois.
A M.Garcia, qui m’a aidé lors de la mise en place des annuaires LDAP.
A tous mes collègues de diplôme pour leur aide apportée durant ces trois mois.
A tous ceux avec qui j’ai pu discuter et qui m’ont apporté leurs idées.
Convention Typographique
Tous les textes soulignés sont des liens vers des sites
Flux Applicatif 3
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Flux Applicatif 4
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Flux Applicatif 5
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Flux Applicatif 6
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Le cache (aussi appelé antémémoire) est l'espace sur le disque dur et dans la mémoire
vive (RAM) de notre ordinateur où notre navigateur enregistre les copies des pages
Web consultées récemment. Le navigateur se sert du cache comme mémoire à court
terme. Au lieu de télécharger une image d'un site que l’on vient de visiter, il charge
l'image enregistrée du cache (chapitre 1.2.1), ce qui accélère la navigation.
Le cache est donc un système conçu pour améliorer le rendement de l’utilisation
d'Internet en réduisant les accès au réseau.
Avant de commencer à étudier les diverses fonctionnalités des caches, j’ai essayé de
trouver de la documentation sur le sujet. Cependant, je savais que cela allait être
difficile du fait qu’Internet Explorer 5.0 / 6.0 est un produit de la gamme Microsoft et
la documentation que j’allais trouver serait maigre (Microsoft gardant certaines
données secrètes à l’utilisateur). Après plusieurs jours de recherches, les informations
collectées étaient très basiques. Les renseignements qui en ressortent sont : « comment
vider le cache », « limiter la taille du cache » ou « effacer les cookies », mais rien ne
montre à quels endroits sont stockés les informations du cache mis à part ceux visibles
par tout le monde à travers l’explorateur Windows (Internet Temporary Files par
exemple).
C’est donc par une méthode de scrutation des dossiers et des registres que j’ai
recherché les emplacements de ces caches. Cette méthode n’est cependant pas la
meilleure parce qu’elle est longue et pénible.
C’est pourquoi certains logiciels ont été créés afin de faciliter la tâches des utilisateurs.
Leurs caractéristiques seront énoncées au chapitre 1.1.2.
Flux Applicatif 7
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Afin de nous aider à mieux comprendre les phénomènes de cache sur les machines
possédant Internet Explorer 5.0 (Netscape n’étant pas traité dans mon diplôme), nous
avons à disposition plusieurs outils trouvés sur Internet afin de trier les informations
du cache. Au niveau du cache, il n’y a pas de différences majeures entre Internet
Explorer 5.0 et ses versions supérieures.
En effet, certains logiciels nous permettent de voir directement les cookies qui sont
présents dans notre cache tandis que d’autres nous permettent uniquement de
visualiser les fichiers qui s’y trouvent.
J’ai donc téléchargé plusieurs de ces logiciels qui me semblaient intéressants et les ai
comparés.
Voici donc la liste des logiciels trouvés et une appréciation sur leurs caractéristiques.
UnMozify http://www.evolve.co.uk/unmozify/
Commentaire : intéressant par le fait qu’il nous permet de visualiser toutes les pages
consultées. Il nous permet aussi de voir l’heure d’accès aux pages d’un site et de
mettre en archive les pages consultées. Ainsi on pourra consulter des pages d’un site
même après avoir vidé le cache.
Cache http://www.webknacks.com/download.htm
Auditor
Commentaire : Version Shareware. Pas très utile à moins de l’utiliser pour trier les
caches en fonctions des types de données stockées (son, image, text, etc…)
Rappel : Un cookie est un petit fichier texte envoyé par un serveur sur notre
ordinateur lors de la connexion sur le site. Ce petit fichier enregistre un
certain nombre d'informations du client, qui pourront être relues et
modifiées ultérieurement si notre ordinateur se connecte à nouveau au
serveur qui a créé le cookie en question. Il sert en quelque sorte à
identifier l’ordinateur qui se connecte au site.
Flux Applicatif 8
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Dans ce chapitre, je vais montrer ce qui se passe au niveau du cache du côté client.
En effet, lorsqu’un client se connecte sur un site en tapant l’url correspondant, le
serveur Web va envoyer certaines informations concernant la page à afficher outre la
page en question. Ces données vont être stockées sur le disque dur du client.
Userx est l’administrator dans mon cas . Sinon c’est le nom de l’utilisateur en cours
qui est présent.
Flux Applicatif 9
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Cependant ce chemin peut être modifié. En effet, lorsque l’on accède aux propriétés
d’Internet Explorer, nous avons plusieurs possibilités, dont une est celle qui concerne
le chemin où seront stockés les données.
(dans la barre de menu cliquer sur tools et Internet Options)
Dans mon mémoire, je ne parlerai que du cache au niveau http. Cependant, il faut
savoir qu’au niveau du cache ftp, le comportement est identique à celui http. Lors de
l’étude LDAP, j’ai constaté que les données transmises au niveau de la base de
données n’étaient pas stockées chez le client.
J’en déduis que pour le protocole http et ftp le fonctionnement du cache est
sensiblement le même, tandis que pour le protocole LDAP, il n’y a pas de mise en
cache des données.
Flux Applicatif 10
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Les données qui se trouvent dans ce répertoire Temporary Internet Files, peuvent être
supprimées. Si le cache est supprimé, cela aura pour conséquence le téléchargement
complet des pages visitées auparavant et dont les fichiers ont été effacés par cette
opération.
Cette opération a pour effet, de vider le cache. La comparaison ci-dessous montre bien
que les fichiers du cache ont été vidés.
Avant Après
Flux Applicatif 11
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Cependant, comme on peut le constater, tous les fichiers textes, images, html etc…
correspondant aux pages où l’on s’est connecté se sont effacés à l’exception des
cookies.
Il existe pourtant encore une trace des passages sur les sites après avoir tout effacé
dans ce répertoire. En effet, à chaque fois que l’on visite un url, un historique des
pages visitées est remis à jour.
1.2.3 L’historique
L’historique est présent afin de stocker les pages visitées lors des anciennes sessions.
Il permet non seulement de savoir l’url tapé mais aussi sur quelles pages du site et à
quelle heure, l’utilisateur s’y est connecté. De plus il nous permet de savoir quelles
sont les recherches qui ont été effectuées sur un moteur de recherche. (www.google.ch
par exemple)
Userx est l’administrator dans mon cas . Sinon c’est le nom de l’utilisateur en cours
qui est présent.
Flux Applicatif 12
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Je peux donc aller voir pour chaque jour, les pages consultées pour chaque utilisateur.
En effet, lorsque l’on navigue sur Internet, nous avons un menu déroulant qui nous
facilite la tache, afin de ne pas taper entièrement l’url à chaque fois que l’on veut
accéder à une page.
Ce menu déroulant est la copie conforme de l’historique et est stocké dans les registres
Windows contrairement à l’historique, qui lui est stocké sur le disque dur de
l’utilisateur. Ces registres sont accessibles en faisant
Flux Applicatif 13
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Une deuxième option existe dans ce menu déroulant. Cela s’appelle la saisie semi-
automatique. Son principe consiste à taper plusieurs lettres et les sites visités avec ces
premières lettres apparaissent dans le menu.
Flux Applicatif 14
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Les deux urls correspondent exactement. Il en est de même pour tous les autres.
Ces paramètres de la saisie semi-automatique, peuvent être modifié dans Tools ->
Internet options -> Content -> Personnal informations -> AutoComplete
Flux Applicatif 15
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
L’étude de protocole montrera comment les paquets sont transmis entre le client et le serveur
Web. Dans l’état des choses, on peut simplement dire qu’un échange de données au niveau
http est présent.
Get Request
Response (Data)
Flux Applicatif 16
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Mais voici réellement ce qui c’est passé sans que l’on s’en aperçoive.
Je vois donc la première page de mon site car je n’ai été que sur celle-ci.
Ensuite, dans le Temporary Internet Files, je trouverai les fichiers chargés lors de
l’accès à la page.
Œ Œ • Ž •
Œ Avec la date d’expiration des fichiers dans le cache (sert à tester la validité du fichier
local)
• Avec la date de la dernière modification de la page (sert au serveur à savoir s’il y a eu
modification sur la page entre la dernière connexion et l’heure courante)
Ž Avec la date du dernier accès fait par le client
• Avec la date de la dernière vérification faite par le client sur la page
Flux Applicatif 17
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
En effet, il faut savoir que les données des registres se modifient uniquement lorsque
la page en question est quittée. Il faut que l’on ferme Internet Explorer pour que les
valeurs soient affectées. Le simple fait de quitter le site et accéder à une autre page ne
suffit pas.
C’est donc uniquement lorsque je quitterai Internet Explorer que mes registres seront
mis à jour.
Je ferme donc simplement la fenêtre du browser et le site www.eig.unige.ch apparaît
dans le registre.
Flux Applicatif 18
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
A première vue, il est normal de penser que lorsque je me connecte à un site avec les
fichiers de la page dans mon cache, l’affichage de celle-ci se fasse plus rapidement du
fait qu’elle est chargée localement. Cependant à la suite de plusieurs essais, il s’est
avéré que cela n’était pas toujours le cas.
En effet il existe encore des requêtes entre le client et le serveur Web afin de vérifier si
des modifications ont été faites sur le site.
De plus ces temps de réponses sont sensibles à la charge sur le réseau. Il se peut que
notre page se trouve déjà en cache et que celle-ci mette plus de temps à se charger que
si l’on accède au site pour la première fois car la réponse du serveur Web est tardive.
C’est pourquoi dans les options d’Internet Explorer, nous pouvons sélectionner divers
modes de chargement de la page en fonction du cache. Ceux-ci seront détaillés dans le
chapitre 2.
Les tests effectués, concernent les charges engendrées sur le réseau lorsque le client
possède ou non le cache et le temps que l’on met pour charger la page entièrement.
Flux Applicatif 19
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Nous voyons très bien ici, que le cache joue un rôle important dans le nombre de bytes
échangés entre le client et le serveur.
En regardant plus attentivement, les échanges entre le client et le serveur Web, on
s’aperçoit que lors du premier accès (sans cache du côté client), le serveur Web dit au
client de stocker en cache les données transmises. Lors d’un prochain accès, suivant le
résultat du test du champ Expires, les données seront chargées du cache ou non.
Voici un organigramme qui montre comment est géré le cache du côté client.
www.microsoft.com
Server Web
Non. Fichiers
encore valides
Alors chargement
de la page depuis
le cache
Flux Applicatif 20
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Une fois les premiers tests effectués, nous pouvons voir que si le cache est présent ou
non sur le disque cela change quelques données.
En effet, on peut voir que les bytes échangés sont réduit de 80 % si la page est
présente dans le cache.
Cette réduction est due en partie au client avec un gain de 20% sur les bytes envoyés et
surtout grâce au serveur qui a un gain de 85% environ sur ses bytes envoyés. Suivant
les pages sur lesquelles on se connecte, ces valeurs vont varier. Par exemple, lors
d’une connexion au site www.hotmail.com, le gain sur les bytes échangés est de 65%
(75% client, 60% serveur).
Cette variation dépend de la quantité des données à transmettre. En effet, plus cette
quantité est importante, plus le nombre de bytes envoyés avec un cache présent chez
l’utilisateur sera réduit. Ainsi le gain sera augmenté.
Je voulais faire une étude plus réaliste du gain en temps, mais le réseau « Internet » de
l’école étant quasiment identique en prestation que le réseau « Intranet » , je ne
voyais aucune différence au niveau d’un éventuel gain de temps. C’est pourquoi je
n’ai pas été plus loin dans cette étude.
Cependant, malgré le gain de bytes échangés, le temps d’accès à la page n’en n’est pas
réduit. En effet, ce temps de réponse est en fonction de la charge du réseau, qui elle est
très variable. Pour le site de Microsoft, nous n’avons aucun gain de temps malgré un
grand gain de bytes échangés. Au contraire lors de l’accès au site de Hotmail, le temps
de réponse est réduit de moitié. Ceci prouve bien qu’une étude sur le temps de réponse
ne peut pas être juste dans le cas où l’on accède à des sites sur Internet.
Flux Applicatif 21
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Lorsque l’on a déjà la page d’un site dans le cache, nous pouvons y accéder grâce à
l’historique (chargement toujours effectué depuis le cache), en tapant soit l’adresse
(chargement de la page dépendant des dates d’expirations) ou lorsque l’on y est déjà,
faire un refresh de la page pour voir si des modifications ont été faites sur celle-ci.
Cependant, le comportement du cache n’est pas le même dans tout les cas.
En effet, lorsque je suis sur une page et je fais un refresh avec la touche F5, le client va
faire une requête au serveur Web pour savoir si des modifications sont intervenues
depuis son dernier accès.
Les dates d’expiration dans ce cas n’ont plus lieu d’être.
Get Request
If modified since (Last Modified)
Server Web
Response OK ou Not modified
Client
Une requête sera automatiquement faite sur le serveur pour savoir si une modification
est intervenue.
La réponse retournée par le serveur sera soit Not modified (pas de modification sur le
serveur Web) et la page sera chargée depuis le cache du client, soit OK (modification
sur le serveur Web entre le dernier accès et l’heure courante) et les nouvelles données
seront transmises par le serveur Web.
Un deuxième moyen de rafraîchir une page est de retaper l’url en question. On peut
même penser à quitter Internet Explorer et revenir. C’est une forme de
rafraîchissement.
Dans ce cas, les dates de validité des fichiers sont nécessaires. En effet, lorsque le
client possède déjà la page dans son cache et que celui-ci entre un url et presse
ENTER, alors ces dates vont être testées. Si elles sont encore valides, la page sera
chargée du cache sinon une requête sera faite au serveur.
Flux Applicatif 22
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Client
Les fichiers stockés
dans le cache sont-ils
encore valides ?
Test du champ Expires
Oui
Get Request
Non If modified since (Last Modified)
Cache
client Response OK ou Not modified
Server Web
Dans les deux cas énoncés précédemment, si la page n’a pas été modifiée sur le
serveur Web, aucune donnée utile ne sera renvoyée au client. Cependant il existe un
moyen de recharger la page entièrement et que toutes les données soient retransmises
par le serveur Web même si aucune modification n’a eu lieu sur celui-ci. Il suffit de
taper la touche Shift et F5.
Cache
Refresh avec Shift + F5
client Pas de
requêtes
Get Request
If modified since (Last Modified)
Pragma : no-cache
Flux Applicatif 23
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Une question vient à l’esprit lorsque plusieurs utilisateurs sont sur une même machine
à des moments différents. Est-ce qu’il se peut que l’un bénéficie du cache de l’autre ?
Pour répondre à cette question, j’ai fait un test en me connectant au site
www.hotmail.com et j’ai testé la charge du réseau lorsque le cache est présent ou non
sur le disque dur de la machine, mais à un autre endroit que dans le cache de
l’utilisateur qui à la session courante. Par exemple, dans le cache d’un autre utilisateur.
A l’aide de ces mesures on se rend bien compte qu’un autre utilisateur qui possède
déjà le cache de la page accédée, n’affecte en rien les performances de l’utilisateur
avec la session courante.
De ce fait l’utilisateur connecté ne fera aucun gain de temps ni de charge sur le réseau
si un autre utilisateur local possède dans son cache la page demandée.
J’en conclus donc que le cache soit présent ou non chez un autre utilisateur connecté
sur la même machine ne change en rien dans le cache de l’autre utilisateur. Ils sont
donc complètement indépendants.
Flux Applicatif 24
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Ceci est certainement fait pour des questions de confidentialité. De ce fait même en
ayant les droits ou en s’étant procuré les droits administrateur, il est impossible de voir
le cache d’un autre utilisateur.
Pour mieux comprendre ce phénomène, j’ai fait une représentation graphique des
différents cas présentés tout au long de ce sous-chapitre.
Flux Applicatif 25
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
De plus, j’ai essayé de me connecter depuis une machine distante sur une machine
dont je connaissais le mot de passe de l’administrateur et j’ai regardé le cache d’un
utilisateur.
J’ai remarqué que le même phénomène se produisait.
Soit que je voyais le cache de la personne qui était connectée en ce moment sur la
machine sur laquelle est effectuée la requête.
Machine A Machine B
Connexion à distance
Compte administrateur
En outre j’ai essayé de partager le répertoire Internet Temporary Files où est stocké le
cache d’un utilisateur. Lorsque je me connecte à distance sur cet utilisateur pour
visualiser le contenu de ce fichier, j’obtiens le même résultat que précédemment. Soit
que le répertoire est remapé et c’est le contenu de ma machine qui s’affiche.
A la suite de ces diverses études, j’en conclu finalement que le cache est indépendant
entre chaque utilisateur et en plus, un utilisateur ou administrateur n’a pas le droit de
voir le cache d’un autre.
Cependant, ces résultats me surprennent. En effet, j’imagine mal dans le réseau d’une
entreprise, qu’aucune personne ne puisse voir le cache de la personne connectée sur
une machine.
De ce fait je pense que l’on peut changer ces caractéristiques mais étant donné
qu’aucune documentation à ce sujet n’est présente sous la moindre forme sur Internet
et que sans doute Microsoft garde ses nouvelles plus ou moins secrètes, je ne
m’attarderai pas plus sur ce problème. De plus cela ne nous apprendrai pas grand
chose sur le comportement du cache. C’est pourquoi je laisserai cette étude en l’état.
(M.Dutheil étant du même avis).
Flux Applicatif 26
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Lorsque l’on se connecte à un site pour la première fois, les documents sont mis en cache
chez le client. Par la suite les données seront chargées entièrement ou partiellement en
fonction des paramètres dans le cache
Pour mes tests j’ai utilisé Internet Explorer 5.0 et 6.0. Il se comporte au niveau du cache,
exactement de la même façon.
Dans les chapitres qui suivront, je vais traiter toutes les options d’Internet Explorer (au
nombre de quatre) dans le détail. Ainsi pour chaque option, je ferai une analyse de protocole
dans le cas où le cache est présent sur le disque et dans le cas où il ne l’est pas.
Flux Applicatif 27
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Au contraire, si le cache est présent sur le disque, alors les données de la page seront
toujours rechargées localement.
Comme on peut le constater, l’option Never, ne charge qu’une seule fois la page. Une
fois que celle-ci s’y trouve, elle sera toujours chargée depuis le cache. Dans le cas où
la page aurait changé de forme, des liens ne fonctionneront peut-être plus, des
nouveautés ne seront pas perçues ou des images ne seront pas remises à jour.
Flux Applicatif 28
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Cette option est celle qui vient par défaut lorsque l’on installe Internet Explorer.
En regardant les principes de celle-ci, nous nous rendons bien compte qu’il est normal
par rapport aux autres de l’avoir mise par défaut.
En effet si lors de la première connexion au site, la page se met dans le cache comme
avec les autres options, une fois que l’on se reconnecte au site, cette option va regarder
la validité des fichiers se trouvant dans le cache (chapitre 1.3).
Oui
fichiers
expirés
Client
Get request www.eig.unige.ch
If-Modified-Since: Tue, 08 May 2001 12:30:10 GMT
Response
OK si le fichier a été modifié après la dernière Server Web
connexion du client et envoi des DATAs. Sinon Not
Modified et la page sera chargée depuis le cache de
l’utilisateur. Les dates de validité (champ Expires par
Non. Fichiers
encore valides exemple) seront changées.
Alors chargement
de la page depuis
le cache
Je vais maintenant détailler un peu plus une séquence Request – Response afin de voir
les données qui sont transmises en plus de celles pour afficher la page.
Tous les paquets Request et Response vu, sont de la même forme que ceux présenté
dans les pages suivantes.
Flux Applicatif 29
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Voici les principaux paramètres concernant le cache que l’on retrouve dans ce paquet.
GET /images/supix.gif
Referer: http://www.eig.unige.ch/
Connection: Keep-Alive
Ce type de connexion est très répandu. En effet lors d’une connexion à un site,
le client et le serveur vont transférer des données. Lors de cet échange, il se
peut que la connexion doive être coupée en raison d’un mauvais mot de passe
rentré ou d’une redirection sur une autre page. Dans le cas où le mode Keep-
Alive est activé, cette connexion reste active. Ce qui a pour but de diminuer le
trafic sur le réseau. Ce mode est donc très intéressant lorsque beaucoup de
personnes se connectent en même temps sur le site.
Flux Applicatif 30
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Voici les principaux paramètres concernant le cache que l’on retrouve dans ce paquet.
Les fichiers n’ayant pas été modifiés sur le site depuis la dernière visite, la réponse du
serveur Web sera du type Document not modified.
De ce fait les données seront chargées du cache. Celles-ci seront cependant remises à
jour avec une date de validité qui aura changé.
Ceci a pour objectif d’avoir une réduction du trafic dans le cas où le client est en train
de naviguer et revient souvent sur cette même page.
Si cependant, le serveur Web a subi des modifications entre temps, alors la réponse de
celui-ci sera OK et les données de la page seront transmises au client.
La question qui me viens à l’esprit est : comment fait le serveur à savoir si le client a
déjà les données de la page en cache ou non ?
Pour le savoir, il suffit de comparer 2 analyses de protocoles (avec une autre option) et
de voir la différence lorsque le client possède le cache ou non.
On s’aperçoit vite que lors du premier paquet GET request lorsque le cache est
présent, une ligne de commande est présente en plus.
Cette ligne de commande demande au serveur Web si la page que le client à visité a
été modifiée ou non. Or si le client pose cette question c’est qu’il possède déjà le cache
dans sa machine. Dans le cas contraire, il ne la posséderait pas.
Flux Applicatif 31
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Lorsque le client se connecte au site, il doit pour la première fois ouvrir Internet
Explorer. A partir de ce moment, toute page visitée pour la première fois, après
réouverture d’Internet Explorer sera remise en cache. Si sans avoir fermé la fenêtre de
navigation je revisite une page, alors celle-ci sera entièrement chargée du cache.
Ici je fais l’exemple comme pour toutes les autres options, en me connectant au site
www.eig.unige.ch
Si par exemple, je quitte cette page et je navigue, tout se passe comme si c’était la
première fois que je consultais les pages. C’est au moment où je me reconnecte sur
l’url déjà tapé, que les propriétés de cette option, vont se faire remarquer.
En effet, comme on peut voir avec l’analyse de protocole suivante, je n’ai aucun
paquet http qui passe entre le client et le serveur suite à la reconnexion au site sans
avoir quitter au préalable Internet Explorer.
Flux Applicatif 32
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Cette option, a pour objectif de charger automatiquement les pages depuis le cache
lorsque je garde Internet Explorer ouvert. Aucune demande ne sera donc faite au
serveur Web.
Cependant, lorsque que je ferme Internet Explorer et le rouvre, pour aller consulter la
même page, les données seront à nouveau stockées dans le cache mais comme pour
l’option automatically, la validité des fichiers va être testée pour le renvoi par le
serveur Web de données plus récentes.
En résumé, lorsque l’on quitte Internet Explorer, les données d’un url sont toujours en
cache, celui-ci se comporte exactement comme l’option Automatically . Ce n’est que
lorsque l’on garde Internet Explorer ouvert que l’option joue un rôle en chargeant
automatiquement les données du cache (comme l’option Never).
Flux Applicatif 33
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Client
www.eig.unige.ch
Oui
Oui
Affichage de la
page depuis le
cache
Flux Applicatif 34
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Cette option, comme son nom l’indique va recharger les données de la page à chaque
fois que l’on visite la page en question même si les données sont déjà stockées dans le
cache.
Au contraire des autres options, celle-ci ne testera pas des heures de validité dans le
cache mais regardera chaque fois s’il y a des modifications sur la page.
Cache
Aucune requête
pour savoir s’il y
a un cache valide
Client
Get request www.eig.unige.ch
If-Modified-Since: Tue, 08 May 200112:30:10 GMT
Response
Ok ou No t modified suivant la date du paquet Server Web
précédent
Flux Applicatif 35
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Dans ce chapitre j’essayerai de résumé brièvement toutes ces options et ces principes.
Pour avoir plus de détails sur chaque option, se référer au chapitre concerné.
Option Fonctionnalités
Lorsque l’on accède pour la première fois au site, les
Never
données de la page seront mises en cache. Lors d’un
prochain accès, les pages seront réaffichées depuis le
Chapitre 2.1
cache et ne seront pas remises à jour.
Lorsque l’on accède pour la première fois au site, les
données de la page seront mises en cache. Lors d’un
prochain accès, le client va regarder la validité des
fichiers qui se trouvent dans le cache à l’aide de
l’heure de validité de ceux-ci (champ Expires). S’ils
Automatically
sont encore valides alors la page sera affichée depuis le
cache. Dans le cas contraire, le client va demander
Chapitre 2.2
pour chaque fichier, si celui-ci a été modifié ou non
(champ Last Modified ) et suivant le résultat, les
données dans le cache seront modifiées ou non.
Cependant, lorsque le client se sera reconnecté sur la
page, une nouvelle heure de validité sera présente.
Lorsque l’on accède pour la première fois au site, les
données de la page seront mises en cache. Lors d’un
prochain accès, dans le cas ou Internet Explorer n’a
Every time you pas été fermé, la page concernée sera entièrement
start Internet Explorer chargée depuis le cache (idem option Never). Dans le
cas contraire, donc si Internet Explorer a été fermé
Chapitre 2.3 entre-temps, le client va devoir recharger le cache de la
page en demandant au serveur Web si les fichiers se
trouvant sur la page ont été modifiés (champ Last
Modified) ou non (idem mode Automatically).
Lorsque l’on accède pour la première fois au site, les
données de la page seront mises en cache. Lors d’un
Every visit to the page
prochain accès, le client demandera au serveur Web si
les fichiers se trouvant sur la page ont été modifiés ou
Chapitre 2.4 non (champ Last Modified ). Il n’y a pas dans ce cas
d’heure de validité.
Flux Applicatif 36
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Avant de regarder les commandes propres au cache, il faut créer notre site.
Pour cela, j’ai récupéré la page du site du laboratoire de transmissions de données. Pour
récupérer le fichier, il suffit simplement de faire un save as de la page.
Le serveur Web que j’ai créé (Machine Vectra 11 , IP = 129.194.187.52) se trouve sur
une machine Windows 2000 Professional. Je vais donc devoir installer IIS 5.0 pour
gérer mon site Web.
Pour cela, il suffit d’installer un nouveau composant Windows depuis le CD
d’installation de la version Windows 2000 Server par exemple.
Ensuite, il faut que je configure IIS. Je dois donc définir la page par défaut de mon
site. Les paramètres du site sont accessibles sous : IIS -> Vectra11 -> Default Web
Site -> Properties. Sous l’onglet Documents, j’insérerai la première page de mon site.
Flux Applicatif 37
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
De plus, il faut indiquer le répertoire où se situe cette page. Dans notre cas il se trouve
sous c:\site .
Maintenant que nous avons installé le serveur Web, il nous suffit de le gérer. Le but ici
est de regarder les commandes http que l’on peut avoir sur le serveur Web. De ce fait,
je ne m’attarderai pas sur des problèmes d’authentifications sur le serveur Web.
Flux Applicatif 38
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Plusieurs méthodes sont possibles afin d’envoyer des commandes pour stocker en
cache les données depuis le serveur.
La première consiste à mettre des commandes directement dans la page html. Ceci est
donc du ressort du programmateur de la page.
Pour cela, on utilise des Meta Tag qui sont plus ou moins semblables aux entêtes http.
Cependant je ne les étudierai pas dans mon mémoire.
Une deuxième méthode (celle que j’étudierai) est celle qui nous permet depuis IIS de
mettre des entêtes HTTP personnalisées sur le site Web.
En effet, dans ces entêtes, il nous suffit de taper les commandes HTTP et le tour est
joué. Cette méthode est plus facile à mettre en œuvre c’est pourquoi j’ai décidé de
l’étudier.
Ces commandes peuvent être insérées sous l’onglet HTTP Headers dans les propriétés
du site Web. (voir chapitre 3.3)
Les commandes principales concernant la mise en cache se trouvent dans la RFC 2616
chapitre 13 et 14 principalement.
Flux Applicatif 39
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
C’est l’endroit où l’on rentre les commandes http. Pour cela, il faut cliquer sur add et
rentrer les commandes.
Dans la fenêtre qui nous apparaît, il faut taper cache-control dans le premier champ et
le type de commande que l’on veut.
Par exemple : cache-control et max-age = 120
Toutes les commandes peuvent être tapées une par une par cette méthode. Cependant,
en ce qui concerne les commandes pour l’expiration du cache comme max-age, sur ce
même onglet, nous avons la possibilité de choisir des dates d’expirations de façon plus
simple sans connaître les commandes http.
Flux Applicatif 40
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
En effet, on peut avoir les paramètres Expire Immediately, Expire after ou Expire.
Pour cela, cliquer sur la case Enable Content Expiration dans la figure dans la figure
de la page précédente.
Expire est identique à taper : Expire : Thu 13 Dec 2001 18 :00 :00 GMT
Elle est présente pour simplifier la commande max-age. En effet, la valeur de max-age
étant en seconde, il est plus facile de rentrer une date que de devoir calculer le nombre
seconde qu’il y a d’ici la date d’expiration choisie.
Flux Applicatif 41
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Comme énoncé dans le chapitre 3.4, cette commande a pour but de forcer le browser
ou le proxy à ne pas mettre en cache les données. Pour vérifier cela, j’ai fait une étude
de protocole et voici ce que j’ai pu en tirer.
Cache
client
vide
Get Request
Response OK
Client Cache -control : no-cache
Server Web
Si l’on regarde l’état du cache après cette opération, on constate qu’il est bel et bien
vide.
Cette commande est souvent utilisée sur des sites qui demandent une authentification.
Typiquement, ce sont les sites de messagerie ou les sites sécurisés où cette commande
est le plus fréquemment utilisée.
Flux Applicatif 42
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Cache
client
présent
Get Request
If modified since (Last Modified)
La différence avec la commande no-cache, c’est que maintenant des données sont
stockées dans le cache. Cependant, la date d’expiration des fichiers sera de 120
secondes. Ce qui correspond donc a 2 minutes. Ainsi lorsque l’on regarde notre cache
on s’aperçoit que la date d’expiration du fichier sera de 2 minutes plus vieille que celle
de la date du dernier accès.
Si le serveur Web répond Not modified, cela veut dire que le fichier n’a pas été
modifié depuis le dernier accès. Donc le champ Last Modified ne changera pas.
Au contraire si le serveur Web répond OK, il a donc modifié des données sur la page
accédée, alors ce champ Last Modified aura une nouvelle valeur.
Flux Applicatif 43
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Il est normal que lorsque les clients se connectent sur le serveur Web, ils laissent une
trace de leur passage.
Ainsi à l’aide d’IIS , nous pouvons avoir un fichier log qui nous servira pour savoir qui
s’est connecté.
Ces fichiers log sont au nombre de 4 et le format peut être choisi dans l’onglet Web
Site.
Nous pouvons aussi choisir quelles seront les données affichées dans ce fichier.
Une liste avec des choix multiples peut être modifiée dans Extended Properties
Cependant, ces fichiers log ne servent pas vraiment. Certes ils nous renseignent sur qui
s’est connecté sur notre site mais ces renseignements ne sont pas trop importants pour
l’administrateur, si ce n’est pour des détections d’intrusions. Pour cela, il faudrait
installé un firewall ou un proxy afin de surveiller beaucoup mieux qui se connecte sur
notre serveur.
C’est pourquoi je ne m’attarderai pas plus sur ces fichiers log.
Flux Applicatif 44
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Avec ce deuxième chapitre, nous avons pu montrer les emplacements du cache du côté
client ainsi que les commandes qui doivent être écrites du côté serveur afin que le
cache soit plus ou moins contrôlé.
Cependant, le cache qui a aussi un rôle de réduction de temps d’accès aux pages, n’est
pas vraiment efficace suivant les commandes http présentent sur une page html. C’est
pourquoi lors d’une seconde phase, nous étudierons le phénomène d’accélération des
accès aux sites grâce au cache avec un logiciel appelé ISA (Internet Security and
Acceleration) qui lui a la fonctionnalité de réduire le temps d’accès aux pages. Dans
quelle mesure ? A quel prix ? Toutes ces questions seront traitées dans les chapitres
suivants (voir chapitre 4 à 6).
Flux Applicatif 45
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Chapitre 4
ISA Server
Première Partie
Lors du chapitre précédent, nous avons pu constater que le cache d’un utilisateur n’était pas
visible par quelqu’un d’autre. De ce fait aucune machine ne bénéficiera du cache de la page
visitée qui est déjà stockée chez un autre utilisateur.
Le logiciel ISA (Internet Security and Acceleration) propose un Firewall ainsi qu’un serveur
de cache réuni en un seul logiciel.
Dans mon diplôme, je ne m’attarderai pas sur les fonctionnalités du Firewall, mais me
concentrerai uniquement sur la partie cache et proxy.
Ainsi à l’aide de ce logiciel, nous pourrons faire bénéficier un autre utilisateur du cache
présent sur une autre machine. Les accès à Internet, devraient théoriquement, être plus rapide.
C’est pourquoi dans les chapitres 5 et 6, je vais tester les différentes possibilités qu’offre ce
logiciel, afin d’améliorer ce phénomène. Dans ce premier chapitre je résumerai brièvement les
possibilités qu’offre ISA Server. Pour ne pas charger cette partie, j’ai fait un guide d’ISA
Server beaucoup plus complet en annexe, une théorie sur les possibilités de ce logiciel serait
trop volumineuse. De plus, cela ne nous apporterait pas beaucoup sur la compréhension de ce
logiciel au niveau traitement des données reçues et analyses de protocole.
Si l’on regarde la documentation sur le site de Microsoft (fondateur du logiciel), on s’aperçoit
que plusieurs avantages devraient être tiré en installant dans notre réseau un serveur ISA.
Selon le nombre d’utilisateurs et la place que l’on réserve dans le cache, il faut
augmenter respectivement la taille de la mémoire vive et la taille du disque dur.
Flux Applicatif 46
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Ce mode est celui que nous allons utilisé. En effet, il nous servira à faire la
comparaison entre une connexion avec un serveur de cache et l’étude précédente qui
était de se connecter simplement à un serveur Web. Ainsi nous pourrons constater la
différence entre ces deux modes et voir si ce logiciel est un investissement intéressant
pour les entreprises et si oui dans quelles mesures.
Les temps d’accès sont-ils vraiment améliorés et de combien ? Les utilisateurs dans le
réseau peuvent-ils bénéficier du cache des autres ? Toutes ces questions seront traitées
dans le chapitre 5.
Internet
Client
Server ISA
mode Cache
Ce mode d’installation ne sera pas traité dans l’étude d’ISA. En effet, le but est de
tester la problématique du cache et non de la sécurité des utilisateurs qui se trouvent
derrière celui-ci, ni de la sécurité du serveur lui-même.
Lorsque l’on installe le Firewall et le mode cache, il est préférable de les installer
chacun sur une machine différente.
Internet
Client
Flux Applicatif 47
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Ce mode est un mixte des deux. Il permet non seulement de stocker le cache des
utilisateurs comme dans le mode cache, il permet aussi d’avoir les propriétés du
Firewall installées sur la même machine. Si l’on veut installer un vrai Firewall et non
simplement un filtre, il faut installer les deux modes séparément. Cependant, si l’on
veut juste faire un filtrage des paquets, on peut utiliser le mode integrated . Lorsque
l’on veut publier notre site sur Internet depuis l’intérieur du réseau, nous sommes
forcés d’avoir au moins le mode Integrated à disposition si l’on veut un minimum de
sécurité. En effet, lors de la publication du site Web, il faut des filtres pour ne pas
laisser pénétrer tout le monde dans le réseau.
Internet
Client
Server ISA
mode Integrated
L’installation doit se faire avec le CD Standard Edition si possible. Etant donné que
dans le laboratoire de transmission de données, la version disponible est Entreprise
Edition, je suis obligé d’installer celle-ci.
Cela ne pose pas de problème si ce n’est que cette version a un coût beaucoup plus
cher par rapport à la version Standard.
Ensuite je n’utiliserai que le mode cache. L’étude du cache étant la partie essentielle
de ce rapport.
Au début, j’ai utilisé une seule carte ethernet. C’est la configuration qui est
recommandée dans tout les documents trouvés sur ISA Server.
Par la suite j’utiliserai une deuxième carte et je verrai la différence. Voir Annexe
Guide d’ISA Server.
Une fois que l’on a installé le logiciel, nous avons plusieurs moyens de mettre en
cache les données reçues par le serveur Web.
Flux Applicatif 48
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Avec ISA Server installé en mode cache, nous avons la possibilité de stocker des pages
d’une façon dynamique. En effet, il est possible qu’ISA fasse des requêtes sur le
serveur Web sans qu’aucun client fasse de demande. Ce mode s’appelle Active Cache.
Bien sûr, le mode cache par défaut n’a pas cette option. Il est simplement configuré
pour que toutes les pages qui traversent ISA, soient stockées avec une date de validité
plus ou moins grande selon les paramètres choisis. Ce mode s’appelle HTTP Cache.
Un troisième mode de cache qui est l’Advanced Caching ne sera pas traité avec une
étude de protocole particulière. Celui-ci permet de créer certaines règles sur les
fichiers qui nous arrivent. Par exemple, de ne pas stocker les pages plus grandes que x
bytes.
Un dernier mode de mise en cache, est la mise en cache automatique mais non plus en
fonction des paramètres d’Active Caching. Cette fois il faut rentrer directement une
heure, une date et le site sur lequel on veut charger la page.
Pour finir un mode Scheduled Caching, nous permet de dire à ISA d’aller charger une
page à une date donnée.
En résumé les différents mode de mise en cache sont :
• Http Caching
• Active Caching
• Advanced Caching
• Scheduled Caching
Afin d’accéder à ces options, sous Cache Configuration, cliquer sur Properties.
Pour plus de détails sur les modes Advanced Caching et Scheduled Caching, consulter
l’annexe Guide d’ISA Server.
Flux Applicatif 49
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
C’est le mode par défaut d’ISA Server. Lorsqu’un client effectue une requête sur le
serveur Web, il doit passer par le proxy. Celui-ci va alors regarder dans son cache, s’il
possède la donnée recherchée. Si tel est le cas, il regarde si cette donnée est encore
valide ou non. Suivant le résultat de ce test, il va aller rechercher les données sur le
serveur Web et va envoyer depuis son cache les données au client. Le temps de
stockage peut varier suivant la configuration du serveur ISA. Voir guide d’ISA Server
en annexe.
Non
Internet
Stockage des
données.
Response Avec date de Response
validité suivant
Les paramètre de
http Caching
Flux Applicatif 50
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Lorsque le client accède à un site Web, les pages en questions sont mises en cache
suivant les paramètre de http Cache. Cependant ces fichiers peuvent arriver à
expiration. C’est pourquoi ce type de cache est présent. Si une page est modifiée
souvent, alors il serait dommage qu’à chaque fois que le client se connecte sur celle -ci,
il doive la recharger. Or avec Active Caching, c’est le serveur qui fera la requête
automatiquement sans qu’aucune requête ne soit émise par un client.
La fréquence de mise à jour des pages peut être gérer. Voir guide d’ISA server en
annexe.
Internet
Response Response
Temps
d’expiration
de la page
Request
Remise à jour
Aucuns paquets du cache Response
Flux Applicatif 51
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Lorsque le client se connecte sur un serveur Web à travers ISA, il doit utiliser une
connexion de type proxy. Il faut donc modifier une option dans Internet Explorer.
Elle s’effectue sous l’onglet Advanced.
Il faut sélectionner Use http 1.1 through proxy connections au lieu de Use http 1.1.
Ainsi on voit qu’Internet Explorer, peut être utilisé de 4 manières différentes. La
première est celle qui consiste à ne cocher aucune des deux cases énoncées
précédemment, le browser utilise alors le protocole HTTP 1.0 pour communiquer avec
le serveur Web. Si la première case uniquement est cochée, cela signifie que l’on
utilise le protocole HTTP 1.1. Si l’on coche uniquement la deuxième case, nous
utiliserons alors le protocole HTTP 1.1 à travers le proxy et le protocole HTTP 1.0
pour une requête sans proxy.
Si les deux cases sont cochées, alors le protocole HTTP 1.1 sera toujours utilisé.
Flux Applicatif 52
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Pour connaître les modifications entre HTTP 1.0 et HTTP 1.1, consulter l’adresse :
http://groups.yahoo.com/group/http-wg/message/8289
Tout ces champs auront une influence sur le comportement du cache et donc du
serveur ISA. Nous les verrons plus en détails dans les chapitres 5 et 6.
Flux Applicatif 53
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Chapitre 5
ISA Server
Deuxième Partie
5.1 Introduction
Dans les chapitres qui vont suivre, je vais essayer de présenter les différents modes de
fonctionnement du serveur ISA avec pour chacun des tests. Une étude de protocole
sera faite afin de comprendre le fonctionnement du logiciel.
La première partie servira à comprendre les principes de fonctionnement avec un seul
client connecté sur le serveur de cache. Nous montrerons ainsi la différence avec la
partie cache Web (chapitre 1 et 2). Nous comparerons une connexion avec ou sans
proxy.
Une deuxième partie sera consacrée à ajouter un deuxième client afin de lui faire
bénéficier du cache d’un autre utilisateur. Pour rappel, ceci n’était pas possible avec un
cache Web traditionnel (chapitre 1).
Toutes ces mesures se feront avec une seule carte Ethernet.
Une troisième étude se fera avec la même configuration client mais avec 2 cartes
Ethernet. Ainsi nous verrons les problèmes de routage entre cartes et regarderons ce
que cela apporte de plus au niveau de la sécurité.
Une quatrième et dernière étude, portera sur le reverse proxy. Celui-ci étant souvent
utilisé, nous essayerons d’expliquer ses principes.
Flux Applicatif 54
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
A l’aide de cette figure très importante pour la compréhension, nous pouvons effectuer
les tests nécessaire à la compréhension des transferts de données entre les différentes
machines.
Flux Applicatif 55
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
5.3 Test avec un seul client et une carte Ethernet sur ISA
L’architecture du réseau lorsque l’on installe une seule carte Ethernet est la plus
simple. En effet, le réseau a la typologie suivante :
Client
Internet
Serveur Web
Serveur ISA
En effet, lorsque l’on utilise une seule carte Ethernet, il faut savoir que le serveur ISA
récupère les données du client pour les renvoyer via la même carte sur le serveur Web.
Flux Applicatif 56
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Response OK Response OK
Via ISA Server From Server Web
to Client to ISA Server
Cache-Control : max-age = 900 Cache -Control : max-age = 900
Expires : Wed, 17 Oct 2001 15:44:44 GMT Expires : Wed, 17 Oct 2001 15:44:44 GMT
Date : Wed, 17 Oct 2001 15:29:44 GMT Date : Wed, 17 Oct 2001 15:29:44 GMT
Last Modified : Wed, 17 Oct 2001 12:05:41 GMT Last Modified : Wed, 17 Oct 2001 12:05:41 GMT
Données utiles de la page Données utiles de la page
Lors de cette première étude, nous voyons tout de suite les modifications, suite au
proxy installé, entre le client et le serveur Web.
En effet, maintenant le client envoie le paramètre Proxy Connection.
Quand au serveur ISA il modifie un champ http. Le champ Source Adress est remplacé
par un Via .
En ce qui concerne les réponses, on voit que l’on a simplement un Source Adress qui
est remplacé par un Via . Sinon la réponse du serveur Web au serveur ISA est tout à
fait identique à la réponse du serveur ISA au client.
Ici le paramètre max-age est présent (voir chapitre 3.4.2). La différence entre la Date
et Expires est exactement la valeur de max-age. En effet, 900 secondes = 15 minutes =
15h44 – 15h29 (Date – Expires).
Maintenant une date d’expiration est valide. Si l’on refait un requête sur la page, alors
aucun paquet ne devrait sortir du client tant que les fichiers ne sont pas expirés du côté
client.
Flux Applicatif 57
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Ici le client qui effectue le rafraîchissement, envoie dans son paquet http Get Request,
le paramètre Last Modified. Dans mon cas il vaut : 17 Oct 12h05. Ainsi le serveur
Web va regarder cette date pour savoir si une modification est intervenue.
Ici, Last Modified , nous donne la date d’expiration des fichiers dans le cache. Le
serveur renvoie le paramètre Not modified et renvoi la même date (Last Modified)
qu’auparavant. Ce qui est normal vu qu’aucune modification n’est intervenue sur la
page consultée.
Si cette modification est parvenue entre temps, alors le serveur Web envoie un OK et
retransmet les données modifiées, et le paramètre Last Modified aura une nouvelle
valeur.
Flux Applicatif 58
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Une question qui vient à l’esprit est : Comment se fait-il que du côté ISA je sois avec
le http cache en mode Frequently et que le client envoie un paramètre If modified
Since (Last modified) ? En effet, lorsque l’on se trouve en mode Frequently, le cache
ne doit jamais être valide ni du côté ISA ni du côté client.
La réponse est simple. Il suffit de lire la petite remarque lorsque l’on configure les
différentes options du mode http Caching.
Mettre en cache
les données à
moins que la
source indique
l’expiration de la
page.
De ce fait, si le serveur Web envoie une date d’expiration, celle-ci prendra le dessus
sur le type d’option du serveur ISA. C’est-à-dire que si le serveur Web envoie un max-
age = 900, et que le serveur ISA est configuré pour avoir un cache qui expire
immédiatement, les données du serveur Web, forcent alors à avoir une validité des
fichiers dans le serveur ISA et chez le client, de 900 secondes.
Flux Applicatif 59
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Le cas précédent, montrait comment réagissait le serveur ISA lorsque le serveur Web
envoyait un paramètre max-age = xxx. Maintenant je vais regarder le cas où le serveur
Web envoie un no-cache.
Ce qui devrait maintenant se passer, c’est que le serveur ISA devra toujours recharger
les données du serveur Web du fait qu’il ne les possédera pas dans son cache vu la
commande http no-cache envoyée.
Voyons si tel est bien le cas :
Premier accès sans le cache du côté client mais avec le cache du côté ISA.
Cette commande Age peut servir lorsque l’on cascade plusieurs serveurs ISA. Ainsi le
serveur pourra savoir si les données qui lui sont transmises sont encore valides ou non.
Flux Applicatif 60
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Il pourra les accepter ou les rejeter suivant les critères de mise en cache de chacun des
serveur ISA cascadé.
En ce qui concerne le client, cette commande n’affecte en rien l’affichage de la page.
Elle est transparente.
Cela pose un petit problème au niveau du proxy. En effet, celui-ci ayant dans son
cache les données, lorsque le client demande la page, c’est le proxy qui va la lui
renvoyé. Les paramètres de mise en cache envoyés seront donc les anciennes valeurs.
Ainsi ce n’est qu’au deuxième accès que la modification sera prise en compte.
Le champ cache control sera à nouveau présent avec max-age = 900 et avec cache
control = no-cache.
Ainsi les données stockées dans le cache de l’utilisateur, n’auront pas une expiration
immédiate comme avec no-cache mais celle-ci sera de 15 minutes (max-age = 900
secondes).
Client
Serveur ISA Serveur Web
Response OK
les données cache control = 900
données de la données de
de la page Not Modified la page
page stockée
sont stockées data non prise en compte car Not cache control : no-cache demandée
Modified envoyé par le serveur Web :
validité du cache cache control = no-cache J'ai reçu Not Modified
selon ISA = 900 sec alors prends les données
qui sont dans mon cache
et je t'envoie ausi les
données du serveur Web
pour que tu les stockes.
données de la
page envoyée
Flux Applicatif 61
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Lors de la réponse du serveur ISA au client, celui-ci envoi les nouvelles données
concernant la mise en cache du côté client. Mais le serveur ISA envoi aussi son
ancienne valeur du cache. En effet, si le serveur Web envoi un Not modified au serveur
ISA, alors celui-ci croit que la page n’a pas été modifiée et le paramètre no-cache ne
sera pris en compte que lors de la prochaine connexion au site.
Si l’on regarde le cache du côté client, on s’aperçoit que la date d’expiration des
fichiers est bel et bien de 15 minutes. Cependant lors de la prochaine connexion, le
paramètre no cache sera envoyé tout seul. Ce n’est donc que lors d’une deuxième
connexion au site que les dates d’expiration du cache seront correctes.
La raison de tout ceci est que si l’on avait entré ces modifications dans la page html en
code pur, le serveur Web aurait renvoyé un OK pour dire que la page était modifiée et
dans ce cas, les dates de validité auraient été modifiées correctement.
C’est un des problème que l’on peut rencontrer lorsque l’on utilise cette méthode au
lieu de programmer en html pur les pages Web.
Le client n’ayant pas les données de la page demandée dans le cache, car ayant reçu la
commande no-cache lors du dernier accès, il renvoie le paramètre pragma : no-cache
au serveur ISA. Celui-ci en faisant la requête successive, fera de même du fait que lui
non plus n’a plus la page en cache.
Flux Applicatif 62
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Lors du chapitre 5.4.2, nous avons vu le cas où le client rafraîchissait sa page en tapant
sur la touche F5. Mais que se passe-t-il si maintenant si je tape le nom du site
entièrement et je fais ENTER ?
Avant de répondre en faisant une étude de protocole, il faut savoir que comme pour le
cache Web classique (sans le serveur ISA), Internet Explorer va tester si les fichiers
stockés dans le cache sont encore valides ou non.
Si la réponse est non, alors le comportement lorsque l’on tape ENTER sur Internet
Explorer est identique à lorsque l’on tape F5. Si ISA est en mode Frequently, il faudra
à chaque fois rechargé la page. Ainsi pour voir l’analyse de protocole, se référer au
chapitre 5.4.2 (Cache présent valide sur le client et sur ISA avec rafraîchissement F5)
Client
Serveur Web
Serveur ISA
Oui
Non
Est-ce que les données
dans mon cache sont Idem Chapitre 5.4.2
encore valides ?
Lors des chapitres précédents, nous avions regardé les paquets qui traversaient le
serveur ISA lors d’un accès par un client sur un serveur Web. Cependant dans le mode
Frequently, les pages n’étaient pas stockées dans le cache d’ISA. En fait ISA ne jouait
que le rôle de proxy et non de cache. Maintenant, je vais regarder ce qui se passe
lorsque le serveur ISA possède les données de la page dans son cache.
Normalement du fait que les pages sont accessibles sur le serveur ISA, aucune requête
ne devrait sortir de celui-ci.
Flux Applicatif 63
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
5.5.1 Aucun cache présent sur le client mais présent sur ISA.
Le premier cas que je vais regardé est celui où le serveur ISA possède le cache de la
page accédée par le client. Imaginons que le client ne la possède plus car il a effacé le
contenu de son cache.
Si les fichiers stockés dans le cache de ISA ne sont plus valides et qu’aucune
modification n’est advenue, alors le cas énoncé à la page précédente est correct.
Dans le cas où la page a été modifiée entre temps, alors le serveur Web répondra OK
au lieu de Not modified et il transmettra les données modifiées.
On remarque que quelque soit la réponse du serveur Web au serveur ISA, celui-ci
répondra au client OK. Ce qui est tout à fait normal car le client ne possédant aucune
donnée dans son cache, il faut que le serveur ISA les lui envoi.
Flux Applicatif 64
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Lorsque que le cache est présent chez le client, deux cas se présentent, Le premier est
lorsque le cache est présent et encore valide, le deuxième lorsqu’il ne l’est plus.
Dans le premier des cas, si le cache est encore valide chez le client alors les données
seront chargées depuis le cache local. Deuxième cas, elles seront chargées depuis le
serveur ISA.
Client
Serveur Web
Serveur ISA
Oui
Ici l’Age représente la durée de stockage de la page sur le serveur ISA depuis son
dernier accès au site
Flux Applicatif 65
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Les deux cas traités dans le chapitre précédent, sont les seuls où l’on peut voir le
comportement du mode Normally . En effet, dans les autres cas, le serveur Web envoi
une commande de type cache-control = xxx, et c’est cette commande qui prend alors
le dessus.
Donc, si ISA reçoit une commande HTTP de ce type, le mode Normally réagi
identiquement au mode Frequently ainsi qu’à tout les autres modes. C’est pourquoi je
ne ferai pas d’autres tests pour des modes de mise en cache.
Afin de voir le fonctionnement du cache dans d’autres cas, se référer au chapitre 5.4
(mode Frequently).
Flux Applicatif 66
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Nous avons pu voir le comportement de 2 modes de mise en cache. Les autres modes
fonctionnent identiquement à ceux-ci mais avec une durée de mise en cache différente
(stockage de la page dans le serveur ISA variant suivant la configuration du serveur
ISA).
Par contre ce que l’on peut dire c’est que suivant le mode de configuration du serveur
ISA, les requêtes se feront ou non sur le serveur Web.
Client
Serveur Web
Serveur ISA
Est-ce que je possède Get Request Est-ce que je possède Get Request
la page en cache ? Non la page en cache ? Non
Oui Oui
Au niveau de la requête sur la page, les cases teintées de gris, sont les cas où le mode
Frequently peut se trouver. Dans le mode Normally, tous les cas peuvent être
possibles.
Ici bien sûr on suppose que le serveur Web, n’envoie aucun type de commandes
spéciales sur la mise en cache des données. (voir chap 5.10)
Flux Applicatif 67
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Ce mode de mise en cache ne fonctionne pas sur le principe du client qui fait une
requête au serveur ISA, comme pour les autres modes.
En effet, ce mode de mise en cache se fait automatiquement sans l’intervention du
client.
Pour ce mode de mise en cache, je n’ai utilisé que le mode Frequently. Les autres
modes étant identiques sur le principe de fonctionnement, si ce n’est que la fréquence
des requêtes sur le serveur Web sera réduite.
De plus, toutes les autres options vont réactualiser les pages dans le cache suivant des
critères que ne peut régler l’administrateur avec le simple CD d’installation du
logiciel.
Les critères de rafraîchissement des pages sont : fréquentation du site, délai
d’expiration, charge du réseau.
Client
Serveur Web
Serveur ISA
Get Request
Via ISA Server
Aucun paquet n’est transmis Active Caching Request
dans ce mode c’est le serveur Connection : Keep-Alive
ISA qui gère seul le If modified Since (Expires)
rafraîchissement des pages.
Response Not modified
Expire : 14h23
Date : 14h21
Cache control : max-age = 120
Comme on peut le remarquer, ici le serveur ISA fait une requête sur le serveur Web.
La requête étant faite pour remettre à jour le cache, alors celui-ci envoi une commande
Active Caching Request. Le serveur qui reçoit cette commande, réagi de la même
façon qu’auparavant et donne l’information au serveur ISA s’il y a eu des
modifications sur la page qu’il accède.
La commande max-age dit au serveur ISA, que les données seront stockées et retenues
comme valide pendant 120 secondes. Du fait que l’on se trouve en mode Frequently ,
chaque moitié de ce temps (60 secondes), le serveur ISA ira redemander au serveur
Web si des modifications ont eu lieu.
Flux Applicatif 68
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Tous les tests effectués jusqu’à présent étaient basés entre un échange
client - serveur ISA - serveur Web. Mais maintenant, je vais rajouter un deuxième
client afin de voir si celui-ci peut bénéficier du fait que quelqu’un d’autre soit déjà allé
visiter la page qu’il demande. Normalement, le serveur ISA ayant déjà en cache la
page, celui-ci ne devrait faire aucune requête vers l’extérieur.
Pour rappel lorsqu’au début de mon diplôme je me connectais sur un serveur Web
directement, un autre utilisateur, sur la même machine, ne pouvait pas bénéficier de
mon cache.
Cache du
site Web
du client A
Echange uniquement si les
Client A fichiers ne sont plus valides
dans le cache d’ISA.
Serveur Web
Serveur ISA
Client B
On remarque bien dans le diagramme en flèche, que le nouveau client peut bénéficier
du fait qu’un autre utilisateur soit déjà allé visiter le site sur lequel il veut se connecter.
On peut donc en tirer la conclusion que lorsque l’on a plusieurs clients connectés sur
le serveur ISA, tous peuvent bénéficier du cache des différentes pages visitées par le
autres.
Flux Applicatif 69
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Tous les tests intéressants au niveau d’une configuration avec une seule carte Ethernet
étant conclus, je vais maintenant rajouter une deuxième carte Ethernet. Ce qui aura
pour effet d’isoler les deux parties du réseau.
Au préalable il me faudra configurer la table de routage du serveur ISA afin que les
deux cartes communiquent et vice-versa.
Pour se faire, il suffit de dire à une des cartes , de donner l’adresse du gateway comme
l’adresse IP de la deuxième carte.
ISA Server
Avec cette configuration la table de routage se met toute seule à jour et de façon
permanente.
Ainsi avec ce type de configuration, tout paquet qui arrivera vers le serveur ISA sera
toujours redirigé vers le serveur Web mais avec une adresse source qui ne sera plus la
même que l’adresse qui servira à recevoir les données du client.
Response Response
From Server ISA From Server Web
Adr IP 10.0.0.20 To Server ISA
To Client 10.0.0.1 Adr IP
129.194.184.99
Au niveau de l’étude de protocole, celle -ci se fait de la même manière, avec les mêmes
commandes que lorsque l’on avait une seule carte.
Malheureusement, en rajoutant une carte, des questions de sécurité sont résolues mais
l’accès au serveur Web est beaucoup plus lent. Ces ralentissements sont très
difficilement calculables car ils sont très variables. L’ordre de grandeur reste
cependant en secondes.
Flux Applicatif 70
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
En effet Windows 2000 ne gère pas très bien les 2 cartes Ethernet ensemble. M.Borsa
aussi diplômant, a rencontré pas mal de problèmes avec une configuration présentant 2
cartes Ethernet. Pour ma part j’en ai rencontrés aussi, car lorsque l’on modifie certains
paramètres (passage du mode proxy en mode standard par exemple sur le browser), le
système ne fonctionne plus. Soit il faut attendre longtemps, soit booter les machines
client et serveur.
Ma configuration étant simple (peu de machines), cela ne pose pas trop de problèmes.
Cependant d’un instant à l’autre, le système devient instable sans aucune modification
de ma part.
Il peut arriver que le serveur Web tombe en panne ou soit en réfection. De ce fait,
personne ne peut plus accéder à une page du site. Cependant avec le serveur ISA, si le
serveur Web est down, alors il va envoyer les données stockées dans son cache aux
clients.
Warning : 111 ISA Server. Some of this informations may be out of date
because of network problems. An attempt to reposnd this r equest from a remote
location was unsuccessful. The response has an expired version of the object
found in the cache.
Warning : 110 ISA Server. Some of this informations may be out of date
Lorsque le serveur Web est tombé, le serveur ISA, s’il possède les pages en cache,
peut envoyé les données de celles-ci à un client. Par contre comme on peut voir, un
message d’erreur est envoyé afin de communiquer au client qu’il y a un problème
réseau et que les données envoyées peuvent être périmées.
Pour le client, c’est comme si rien ne s’était passé. Pour lui, le serveur est toujours
accessible. Ces warnings sont présents surtout lorsque l’on cascade des serveurs ISA.
Une entreprise possédant un serveur ISA peut refuser d’afficher des pages périmées.
Flux Applicatif 71
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Certaines commandes http ont été découvertes grâce à l’utilisation du serveur ISA et
de la connexion proxy.
Commande Explication
Cette commande signifie que lorsqu’on se connecte sur le
Proxy connection : Keep-Alive serveur ISA en mode proxy la connexion se fait en mode
keep -alive.
Cette commande est présente uniquement lors de
l’utilisation d’un proxy ou d’un gateway.
Elle fait simplement l’intermédiaire entre le client et le
Via serveur Web. Avec cette méthode on peut savoir du côté
serveur Web si la demande vient d’un client ou si elle a été
redirigée comme avec un serveur proxy.
(voir chapitre 14.45 RFC 2616)
Cette commande nous renseigne sur la date d’expiration du
Expire fichier.
(voir chapitre 14.21 RFC 2616)
Cette commande nous renseigne sur la date de connexion
Date au site.
(voir chapitre 14.18 RFC 2616)
Cette commande nous donne la différence entre l’heure
courante et l’heure de la dernière connexion. Cette valeur
sert uniquement au serveur ISA. Ainsi le client peut savoir
Age
si les données envoyées par le serveur ISA sont récentes ou
non.
(voir chapitre 14.16 RFC 2616)
Cette commande est envoyée par le serveur ISA lorsque
celui-ci veut remettre à jour son cache de façon
Active Caching Request
automatique. Cette commande n’a pas d’influence sur la
réponse du serveur Web.
Il existe cependant plusieurs commandes http qui font que le serveur ISA ne mettra
pas en cache les données. Ce sont souvent celles qui concernent les problèmes
d’authentification.
Ces commandes sont :
voir page :
http://www.microsoft.com/TechNet/prodtechnol/isa/proddocs/isadocs/cmt_cachewhat.asp
Flux Applicatif 72
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Lorsque l’on se connecte à un site avec un de ces paramètres sur le serveur Web, alors
les données ne seront pas stockées dans le cache ISA. Cette étude a déjà été menée
lorsque l’on se connectait sur le serveur Web et celui-ci nous retournait une commande
cache control : no-cache. C’est pourquoi je ne la referai pas ici.
Comme lorsque l’on était dans la configuration Client - Serveur Web (chapitre 3.5),
des fichiers log peuvent être créés. Même si ceux-ci ont plus d’informations que les
fichiers log sur IIS, ils restent pauvres. C’est pourquoi je ne les étudierai pas en détail.
En effet, ce que l’on peut en tirer comme informations se trouve dans une liste que
l’on peut configurer.
Elle se trouve sous : Monitoring dans la fenêtre principale du serveur ISA
Flux Applicatif 73
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Avec l’installation d’un tel logiciel, nous remarquons que les données transférées entre
le serveur de cache ISA et le serveur Web sont diminuées. En effet, les données étant
stockées dans le serveur ISA, lorsqu’un client se connecte sur une page, alors celui-ci
se verra envoyer les données directement depuis ce serveur. Certes des requêtes
existent entre le serveur ISA et le serveur Web mais c’est juste pour savoir si des
fichiers ont été modifiés depuis le dernier accès sur la page et si le serveur ISA
possède dans son cache la page demandée.
Il faut savoir que généralement, le client se trouve dans un réseau local avec des
liaisons à 10 ou 100 Mbits/s. Ce chiffre est de beaucoup supérieur à la liaison physique
entre le serveur ISA et le serveur Web.
De ce fait lorsque le serveur ISA possède les données dans le cache, celles-ci sont très
rapidement chargées (vitesse du réseau local).
Les résultats que je trouve sont faussés par le fait que je ne simule que 2 clients et non
un réseau complet de clients. Par faute de temps, je ne pourrai pas tester le cas plus
réel en simulant un nombre plus grand de clients.
De plus, le réseau de l’EIG étant très rapide, je ne vois pas de différence lorsque je me
connecte sur un site Web avec ou sans le serveur ISA.
Ce que je constate c’est qu’en rajoutant une deuxième carte Ethernet sur le serveur
ISA, cela ralenti beaucoup le système.
A cause des problèmes énoncés tout au long de ce chapitre, je n’irai pas plus loin dans
l’étude de gain de temps avec ISA. Il faut savoir que dans un cas réel le serveur ISA
devrait avoir un bon rendement au niveau du gain de temps. Mais de toute façon il est
sûr qu’un gain important au niveau du trafic est perçu (0 paquet sortant du serveur ISA
si le cache est encore valide ou quelques paquets de demande si la page a été modifiée
dans le cas où le cache ISA est expiré).
Une chose importante que l’on a avec le serveur ISA, est que l’adresse source que ce
soit avec une configuration d’une ou deux cartes Ethernet, ne sera jamais celle du
client mais toujours celle du serveur ISA.
Flux Applicatif 74
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Lors des chapitres précédents, nous avons toujours testé le cas où le serveur Web se trouvait
hors de l’entreprise. Maintenant, je vais tester le cas où le serveur Web se trouve à l’intérieur
de l’entreprise avec une adresse privée, et un client se connecte sur celui-ci via l’adresse
publique du proxy. Le fait d’accéder à un serveur interne depuis l’extérieur s’appelle donc
reverse proxy.
Le but de cette fonction est d’isoler le serveur Web interne de l’entreprise par rapport à
l’extérieur. En effet, souvent les serveurs font l’objet d’attaques de personnes mal
intentionnées. A l’aide de cette fonction de reverse proxy, on fait croire au client qu’il se
connecte sur une adresse IP pour accéder à la page de l’entreprise, mais avec la fonction NAT
(Network Adress Translator), l’adresse du serveur Web n’est pas celle que le client tape.
Client
IP : 129.194.184.206
MASK 255.255.252.0 IP : 10.0.0.1
GATEWAY : 129.194.184.3 MASK 255.255.255.0
GATEWAY : 10.0.0.20
IP : 129.194.184.99 IP : 10.0.0.20
MASK 255.255.252.0 MASK 255.255.255.0
GATEWAY : 10.0.0.20 GATEWAY : 129.194.184.99
Internet
IP : 129.194.184.203
MASK 255.255.252.0
GATEWAY : 129.194.184.3
Client
ISA Server, nous permet de réaliser cette fonction de reverse proxy. Dans un cas réel, il
faudrait installer un Firewall afin que personne n’accède au serveur Web interne sans
s’authentifier. La fonction NAT du serveur ISA devrait être aussi installée.
Cependant pour installer la fonction NAT et/ou Firewall sur le serveur ISA qui se trouve
installé en mode cache, il faudrait installer le mode Integrated (voir chapitre 4.4).
C’est pourquoi ISA propose un service de publication du serveur Web interne simplifié.
Afin de l’installer correctement, il faut lui donner quelques paramètres. Voici en résumé les
paramètres à entrer.
Flux Applicatif 75
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Tout d’abord, il faut ouvrir ISA Management. Ensuite sous Netserver1 et properties,
on obtient une fenêtre
En cliquant sur Add, il faut rajouter la règle qui dit sur quelle adresse IP, le serveur
ISA va écouter les requêtes des clients. Les paramètres à choisir sont les suivants :
Champs Paramètres
Server Netserver1
IP Adress 129.194.184.99
Display Name Optionnel, nous permet de rentrer un nom plus
représentatif que le nom de la machine.
Authentification Integrated, Basic, Client Certificate. Ce champ nous
permet de dire comment le client doit s’authentifier sur le
serveur ISA pour accéder au serveur Web.
Server Certificate Si le mode d’authentification doit demander un certificat,
il faut entré ici le nom du certificat.
Flux Applicatif 76
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Maintenant que nous avons dit sur quelle adresse IP les clients se connectent, il faut
encore pouvoir diffuser les données du serveur Web vers l’extérieur. Pour cela il faut
aller dans Publishing -> Web Publishing Rules -> New.
Adresse
du serveur
Web interne
Maintenant le serveur Web est prêt à être vu par les clients externes à l’entreprise. Il
reste à effectuer quelques tests afin de voir la différence entre une connexion en mode
proxy et en mode reverse proxy.
Flux Applicatif 77
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Lorsque le client se connecte sur le serveur Web d’une entreprise, il doit taper
www.domaine.ch par exemple. Dans mon cas, pour simplifier la chose, je n’ai pas mis
de serveur DNS (donc pas d’ Active Directory, ni de création de domaine). C’est
pourquoi lorsque celui-ci se connecte sur le serveur, il devra taper l’adresse IP pour s’y
connecter. Soit 129.194.184.99. Le serveur ISA se chargera de router la requête vers le
serveur Web interne.
Get Request
From Client
to 129.194.184.99
Client
Serveur Web
Serveur ISA
Connexion impossible
Il faut une
authentification pour
exécuter la requête
OK
On tape les données du Login et Get Request
login et du password et password Via ISA 10.0.0.20
éventuellement du acceptés Host 10.0.0.1
domaine If modified Since (Last Modified)
(voir chapitre 11.3 partie Referer http://129.194.184.99
codage Base 64)
Response Response
Not Modified ou OK Not Modified ou OK
Date : Date Date : Date
Cache control : max-age = 60 Cache control : max-age = 60
Flux Applicatif 78
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Lors de cette première acquisition, nous remarquons que plusieurs commandes http
sont venues s’ajouter à celles précédemment utilisées en mode proxy.
Celles-ci sont :
Commandes Fonctionnalités
Host Cette commande indique simplement le nom ou l’adresse que
l’on veut atteindre
Voir RFC 2616 chapitre 14.23
Referer Cette commande sert au serveur Web pour savoir à qui il doit
répondre.
Voir RFC 2616 chapitre 14.36
En ce qui concerne la commande Referer, elle est toujours présente dans le paquet
http, mais elle nous aide à mieux comprendre le principe du Reverse Proxy. C’est
pourquoi je l’ai décrite ici. On la retrouve également dans le mode proxy.
On voit donc que le serveur ISA, demande d’abord une authentification de différents
types suivant sa configuration. Le client entre le login et le password (Codage en Base
64). Si le login et le password sont corrects, alors il envoie une requête au serveur
Web pour savoir si la page a été modifiée ou non. Il rajoute dans les commandes le
champ Host et Referer comme énoncé ci-dessus. La réponse du serveur est simple. Il
dit simplement au serveur ISA si la page a été modifiée et l’heure de la connexion,
avec bien sûr le champ http concernant la validité de la page max-age = xxx ou autre.
Dans le cas où le login et le password sont erronés, alors le serveur ISA refuse l’accès
et affiche au bout de trois erreurs, une page indiquant que la connexion est impossible.
Le principe que j’avais exposé pour le proxy qui concerne la validité des fichiers sur
ISA est aussi valable en reverse proxy.
C’est pourquoi je ne traiterai pas tous les cas possibles comme je l’ai fait en mode
proxy.
Je pense que l’acquisition de la page précédente, suffit à la compréhension du reverse
proxy.
Il reste un point à faire. C’est celui, où plusieurs clients accèdent à la même page en
même temps.
Flux Applicatif 79
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Maintenant, je vais simuler un deuxième client qui se connecte sur le même serveur
Web au même moment que le premier client.
Les deux clients qui se connectent, doivent s’authentifier. Une fois cette étape passée,
le serveur Web ou le Serveur ISA (suivant les paramètres du cache de ISA) doit
retourner les données au client.
La première requête arrive au serveur Web, si les données ne sont pas dans le cache.
Cependant, si ISA possède les données de la page dans son cache mais expirées, il va
tout de même demander au serveur Web si les données ont été modifiées.
Si oui elles sont renvoyées et stockées dans le cache. Sinon le serveur Web envoie Not
modified.
Si l’on admet qu’ISA ne possède pas la page en cache, alors la première requête du
premier client aura une réponse du serveur.
La requête du deuxième client n’ira pas jusqu’au serveur Web mais s’arrêtera au
serveur ISA puisqu’entre temps, ISA aura stocké la page accédée par le premier client
dans son cache.
Dans le cas où les données dans le cache d’ISA sont encore valides, celles-ci seront
entièrement chargée depuis ISA (comme pour le proxy) et aucune requête ne sera faite
au serveur Web.
Get Request Œ
from client A
Client A To Server Web Serveur ISA Serveur Web
Œ
Get Request • Login et Password Première requête
from client B Client A et Client B qui arrive
To Server Web OK Get Request
If modified Since (Date)
Client B
Response Œ Response Œ
OK ou not modified OK ou not modified
à la première requête à la première requête
Response •
OK ou not modified
à la deuxième requête
Flux Applicatif 80
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
6.3 Conclusion
L’étude d’ISA à montré qu’il est possible simplement avec le mode cache, de créer un
serveur de cache, un proxy et un reverse proxy.
Ce dernier étant néanmoins restreint du fait qu’aucune sécurité « sévère » n’est
implémentée sur le serveur ISA lorsque l’on installe uniquement le mode cache. Dans
le cas ou l’on installe le mode integrated, alors le serveur devient beaucoup plus sûr au
niveau des accès (IP Packet Filtering actif).
Ce type de serveur (au niveau cache) est intéressant lorsque la connexion vers
l’extérieur n’a pas un trop gros débit utile. En effet, plus le débit utile est grand, plus le
gain que l’on aura avec un serveur de ce type sera petit.
En ce qui concerne son installation, elle est très simple. Il suffit de suivre les
indications qui apparaissent à l’écran et le tour est joué.
Flux Applicatif 81
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Il y a encore quelques années, lorsqu’une entreprise possédait une base de donnée, elle devait
la tenir à jour régulièrement. Ce phénomène s’est compliqué avec l’arrivée de plusieurs bases
de données au sein d’une même entreprise. Imaginons par exemple, que celle -ci se divise en
départements, que chacune possède une base de données identique (par exemple de clients) et
que celui-ci change d’adresse. Celle-ci doit être modifiée dans chacun des serveurs et de façon
manuelle.
Maintenant, si plusieurs entreprises sont sur des systèmes d’exploitations différents et qu’elles
se partagent des bases de données, il n’est pas possible de faire une duplication de la base. Il
faut reprendre la base de données à zéro et ajouter une par une les données inscrites.
C’est pourquoi est né le protocole LDAP (Lightweight Directory Access Protocol). Il permet
de gérer les modifications de données dans la base et de faire en sorte que celles-ci se
répercutent sur les autres serveurs même sur les systèmes d’exploitations différents. Il permet
aussi de copier des bases de données complètes (Replication) ou d’aller consulter une autre
base de données distante (Referral).
De plus ce protocole s’applique donc à tout système d’exploitation. Le serveur LDAP ainsi
que le browser du côté client peuvent parfaitement fonctionner sous Windows, Linux ou Unix.
Avec LDAP, nous ne parlerons plus de base de données mais d’annuaire. Sa fonction
première est de retourner un ou plusieurs attributs d’un objet suivant des critères de recherche.
Un annuaire LDAP peut être représenté sous forme d’un arbre de la manière suivante.
o=eig
ou = telecommunication ou = informatique
uid = pgaio
Lorsque l’on recherche une donnée dans l’annuaire LDAP, celle-ci prendra un temps quasi
nul. En effet, nous n’avons pas besoin de scruter l’annuaire comme on le fait avec une base de
données pour trouver la valeur recherchée. Cet fois, l’emplacement de la valeur recherchée est
connue car à l’arborescence de l’annuaire.
Flux Applicatif 82
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Le protocole LDAP est normalisé et défini par la RFC 2251. Dans sa version 3, il
définit la communication serveur/serveur ainsi que les referrals. En ce qui concerne la
réplication, la RFC n’a pas encore été crée mais un semblant de RFC est présent à
l’adresse http://globecom.net/ietf/draft/draft-merrells-ldup-model-01.txt.
Dans la version 2 du protocole, il n’était pas possible de faire des referral ainsi que de
la replication. (voir l’adresse ci-dessous pour les différence entre LDAP V2 et V3).
http://developer.novel.com/research/devnotes/1998/august/02/d980802_.pdf
Un annuaire LDAP a des attributs normalisés. Lorsque l’on crée notre annuaire, nous
le créons sous forme d’un arbre. Ce qui facilite la recherche dans l’annuaire. Chaque
entrée de l’annuaire aura un DN (Distinguish Name) unique, qui correspondra à
l’endroit où se trouve l’objet en question.
Exemple d’annuaire :
o = entreprise
ou = Genève ou = Vaud
uid = d
uid = b
uid = b
uid = d
uid = x
uid = y
uid = b
uid = x
uid = a
uid = c
uid = e
uid = c
Flux Applicatif 83
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
D’autres attributs existent, cependant, je ne les énoncerai pas ici. Pour les consulter, se
référer au très bon document sur le site :
http://www-sop.inria.fr/semir/personnel/Laurent.Mirtain/ldap-livre.html
Ces attributs sont classés dans un tableau toujours à cette même adresse. En voici un
petit résumé.
L’attribut général s’appelle ObjectClass. Sans cette classe, on ne pourrait pas ajouter
par exemple, un utilisateur. C’est elle qui va gérer toutes les possibilités d’entrées dans
l’annuaire LDAP.
Type d’attribut Attributs optionnels possibles
Mail
Mobile
ObjectClass : inetOrgPerson
Défini les entrées pour les personnes Postal Adress
Common Name (obligatoire)
Surname (obligatoire)
Telephone Number
ObjectClass : organizationalUnit
Défini les entrées pour les Organization Unit Postal Adress
Description
Telephone Number
ObjectClass : organization Postal Adress
Défini les entrées pour les organisations Description
BusinessCategory
Flux Applicatif 84
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Ainsi les commandes qui peuvent être effectuées seront définies dans le tableau de la
page suivante.
Lors d’une recherche d’une donnée, celle-ci peut s’effectuer sur plusieurs niveau de
l’annuaire. Le champ scope défini cette profondeur.
o=eig
Scope = base
ou = telecommunication ou = informatique
uid = toto
Flux Applicatif 85
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
o=eig
ou = telecommunication ou = informatique
uid = toto
o=eig
Scope = subtree
ou = telecommunication ou = informatique
uid = toto
En ce qui concerne le choix du client, il y avait aussi deux possibilités. Soit le logiciel
sur une base JAVA ou un soft tournant sur Windows uniquement. Mon choix c’est
finalement porter sur le premier, car le client qui tournait sous Windows ne me
permettait pas de faire des recherches dans l’annuaire. De plus la version freeware que
l’on trouve sur Internet du logiciel tournant sur Windows est limitée.
Flux Applicatif 86
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Tout d’abord, il faut charger le logiciel iPlanet Directory Server 5.0 sur le site
www.iplanet.com
Ensuite, il faut le décompresser et pour finir l’installer. Je ne décrirai pas l’installation
dans ce chapitre car elle est plus que basic. Il suffit juste d’indiquer les mots de passe à
utiliser et le nom de l’administrateur qui peut se connecter sur ce serveur en plus du
Directory Manager qui est un « super administrateur ». C’est lui qui peut modifier des
données dans l’annuaire et à distance via le browser du client.
Deux logiciels sont à notre disposition, le premier est un browser LDAP sur un plate-
forme JAVA.
Il suffit de le télécharger à l’adresse http://www.iit.edu/~gawojar/ldap . Pour
l’installation, il suffit de suivre le guide d’installation fourni sur le site. De plus il nous
faudra télécharger JAVA. Toute la procédure est indiquée dans le document.
Ce logiciel se nomme : LDAP Browser/Editor 2.8.1
Après avoir installé les deux logiciels et les avoir comparé, j’estime que le premier est
sensiblement meilleur, car il permet de rechercher une donnée dans l’annuaire auquel
on se connecte.
Client LDAP Re
fer
Server iPlanet ral
EIG
Server iPlanet
Professeurs
Flux Applicatif 87
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
o=eleves
Liste d'élèves
Flux Applicatif 88
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
o=professeurs
Maintenant que nous avons créé nos annuaires, il reste à ajouter des membres dans des
groupes. En effet, un élève appartient à une classe bien définie (TE3 ou IN3 en
l’occurrence) et de même pour un professeur.
Cependant le fait de créer des membres posent quelques problèmes. Nous pouvons
créer des membres statiques ou dynamiques. Il faut savoir que l’ajout d’un membre
statique peut se faire uniquement d’un point de vue local. C’est-à-dire, que l’utilisateur
qui va être choisi doit se trouver dans l’annuaire de la machine en question. Nous ne
pouvons donc pas faire un referral sur un autre serveur et créer un membre statique
d’un groupe local qui se trouve sur une machine distante.
Referall
serveur iPlanet LOCAL Liste d'élèves
sur le serveur iPlanet
o=eig
DISTANT
uid = PGaio
uid = DCotte
ou = telecommunication ou = informatique uid = PLogean
uid = MPasquali
uid = YSouchon
uid = SBorsa
uid = SBancal
cn = TE3
Flux Applicatif 89
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
A cause de cette restriction, j’ai dû créé des membres dynamiques. Cependant, deux
configurations sont possibles avec les membres dynamiques. La première consiste à
créer sur le serveur distant des groupes de membres statiques. Ainsi la gestion des
membres ne se fera pas sur le serveur local.
o=eleves
ou = telecommunication ou = informatique
Comme on peut le voir sur ce schéma, nous avons à l’intérieur du serveur distant, une
liste d’élèves en vrac, avec la création d’un groupe de membres statiques
correspondant aux élèves de la TE3. A l’aide d’un referral sur le serveur o=eleves, je
pourrai créer des membres dynamique du groupe TE3 distant sur mon serveur local.
o=eleves
ou = telecommunication ou = informatique
uid = PGaio
uid = DCotte
uid = PLogean
Membres Dynamiques uid = MPasquali
uid = YSouchon
avec lien sur un uid précis uid = SBorsa
uid = SBancal
Flux Applicatif 90
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Avec cette seconde architecture, l’administrateur local, peut gérer les membres de
l’annuaire distant.
Pour ma part je considère la première solution comme la plus simple au niveau de la
gestion des membres. Certes le fait que l’administrateur distant ne veuille pas gérer les
membres des autres est un problème mais il me semble que dans une entreprise
sérieuse, la gestion des utilisateurs ne doit pas poser de problèmes de ce genre.
7.6 Conclusion
Flux Applicatif 91
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Dans ce chapitre, je vais présenter le protocole LDAP à un niveau beaucoup plus approfondi.
Je ne me contenterai pas d’énoncer ces principes comme au chapitre 7, mais j’irai dans l’étude
au niveau hexadécimal du protocole.
En effet, la première partie de ce chapitre consistera à comprendre comment le protocole
LDAP est transmis. Comme pour TCP ou IP, j'essayerai de faire ressortir la structure de la
trame du protocole LDAP.
Par la suite j’étudierai un simple échange LDAP lorsque l’on accède à un annuaire.
Je ferai aussi une étude sur le comportement d’un referral.
Pour terminer, je ferai une réplication entre deux serveurs et regarderai toujours au niveau du
protocole, ce que cela engendre comme trafic.
Cependant, avant de regarder attentivement les paquets qui sont transmis, regardons comment
se passe un échange entre client et serveur LDAP.
Connexion TCP
Lorsque l’on initialise la connexion avec l’annuaire, une connexion TCP est tout d’abord
établie. Ensuite c’est une connexion LDAP qui est établie par le biais des paquets Bind
Request et Bind Response. Une fois connecté, le client fait une recherche (Search Request) sur
le serveur LDAP et celui-ci lui renvoie les données avec Search Response. Une fois que le
serveur a envoyé toutes les données, alors celui-ci envoi Search Response Simple pour dire
qu’il a fini d’émettre.
Le numéro inscrit à côté de ces paquets est le numéro d’application LDAP.
Tout les paquets seront décrits en détail dans les chapitres suivants.
Flux Applicatif 92
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Ainsi chaque paquet de type ASN1 (donc chaque paquet LDAP) est composé d’un
champ type (Type) suivi d’un champ longueur (Length), suivi d’un champ contenu
(Content).
Dans le cas où le champ Length est nul (00), le champ Content ne sera pas transmis.
7 6 5 4 3 2 1 0
Primitive
Type Class Tag Value
Construct
Les deux premiers bits de ce champ type contiennent des informations sur le type des
informations qui seront transmises. Voici les différents cas possibles :
Ces deux types sont les plus répandus dans le standard LDAP. Cependant, il en existe
encore deux qui sont plus spécifiques aux programmeurs d’une entreprise.
Flux Applicatif 93
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Le type de classe Universal est le seul à être normalisé. Dans le tableau ci-dessous, je
vais énoncés quelque unes des valeurs possibles. Pour voir toutes les valeurs possibles,
consulter le site http://people.ne.mediaone.net/wasser/ASN1/BasicEncodingRules.html
Suivant les types de ces valeurs, ceux-ci seront alors définis comme primitifs (0) ou
construits (1). Cela affectera la valeur du bit N°5 du champ Type.
Un type primitif contient une seule valeur dans son champ Content, tandis que le type
Construit, peut contenir plusieurs valeurs à la suite.
Primitif
Type Tag Type des données
construit
Universal 1 Primitif Boolean
Universal 2 Primitif Integer
Universal 3 Primitif Bit String
Universal 4 Primitif Octet String
Universal 5 Primitif Null
Universal 6 Primitif Object Identifier (OID)
Universal 10 Primitif Enumerated
Universal 16 Construit Sequence
Universal 17 Construit Set
Il nous reste maintenant, à définir la valeur du champ Tag Value. Cette valeur est
simplement la valeur soit universal soit de l’application utilisée. Par exemple, si je
veux faire une application LDAP de type Search Request ces 8 bits seront :
7 6 5 4 3 2 1 0
0 1 0 0 0 0 1 1
}
Flux Applicatif 94
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Avec le tableau de la page précédente, nous voyons que LDAP à défini des numéros
d’applications pour chacune de ses requêtes ou réponses.
En effet, voici les commandes LDAP les plus courantes.
le second champ présent dans une structure de type ASN1 est le champ Length . Celui-
ci à priori nous indique simplement la longueur des données du champ Content.
Cependant, si ce champ est plus petit que 128 bits, alors la valeur hexadécimale du
champ Length sera de la longueur du champ Content. Si le nombre de bits dépassent
cette valeur alors le champ Length indiquera 81 en hexadécimal et la longueur du
champ content sera définie dans l’octet suivant. Il se peut cependant que le champ
Content soit d’une longueur indéfinie. Dans ce cas le champ Length indiquera toujours
la valeur 80 en hexadécimale. Ce cas peut se produire lorsque l’on transmet le sommet
d’un arbre sans savoir qui se trouve en dessous ou lorsque le décodage n’arrive pas à
ce faire.
Flux Applicatif 95
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Si l’on a le type primitif comme Type Class, alors dans le champ Content, il y aura
uniquement, la donnée correspondant à ce type.
Au contraire, si on a le type construit, cela veut dire que dans ce champ, plusieurs
valeurs seront transmises.
Maintenant que nous avons décrit toutes les possibilités qu’offre LDAP au niveau de
son protocole, il reste à étudier un paquet pour que l’explication soit plus parlante.
Pour cela j’ai choisi un paquet Search Response que je détaillerai de fond en comble.
Il faut bien se rendre compte que la structure de ce paquet est la même que pour un
autre. C’est pourquoi je n’en étudierai qu’un seul.
Flux Applicatif 96
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
TCP :
Length 96 bytes
Source port : 389
Destination port : 4300
Flux Applicatif 97
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Regardons plus en détail ces parties de paquets. Il faut toujours tenir d’œil, la forme
d’une trame : Type, Lenght, Content
Flux Applicatif 98
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
A l’aide de ces captures, on remarque bien que la suite Type, Length, Content est bel et
bien respectée. Ensuite suivant le type de données à transmettre, le codage va être
différent (Application Search Request(63), Application Search Response (65), etc…).
De plus lorsque l’on veut transmettre plusieurs données de même type, il n’est pas
nécessaire de renvoyer un nouveau paquet entier avec le champ type = universal ou
Application par exemple. C’est le cas dans le dernier paquet traité.
Flux Applicatif 99
Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal
Laboratoire de transmission de données Session 2001
Lorsque j’accède à un annuaire, je dois me connecter sur celui-ci. Je dois tout d’abord
effectuer une connexion TCP classique, puis une connexion LDAP.
Pour cela, deux paquets servent à la connexion. Le paquet Bind Request qui demande
la connexion et le paquet Bind Response qui répond à la requête avec des paramètres
suivant le résultat de la requête.
Connexion TCP
Dans le paquet Bind Request, plusieurs informations sont envoyées par le client.
En effet, celui-ci envoie aussi la version du protocole choisi, le nom de la personne qui
se connecte sur l’annuaire et le type d’authentification sur le serveur. Il faut juste
savoir que l’on peut se connecter sur le serveur en anonyme ou en authentifié, ce qui
impliquera des restrictions sur les possibilités de gestion de l’annuaire. Les options
avancées d’authentification servent lors de l’accès par d’autres serveurs pour une
réplication par exemple.
Dans le cas où le serveur ne peut pas être atteinte, la connexion TCP n’arrivera pas à
s’établir et de ce fait aucun paquet LDAP ne sera émis. Il faut obligatoirement que la
connexion TCP soit ouverte pour que le premier paquet Bind Request soit émis.
Une fois connecté correctement, il faut que le serveur LDAP envoie les données au
client. Comme pour tout échange LDAP client-serveur, c’est le client qui commence
l’échange.
SearchRequest (3)
SearchResponse (4)
SearchResponseSimple (5)
Client
Server iPlanet
Le client qui fait la requête, envoie cette fois-ci beaucoup plus de données au serveur.
En effet, si l’on regarde la RFC 1777 ou 2251 qui définit exactement les champs
transmis, on s’aperçoit que les plus importants sont :
LDAP: ProtocolOp: SearchRequest (3)
SearchRequest ::= LDAP: MessageID
[APPLICATION 3] SEQUENCE { LDAP: ProtocolOp = SearchRequest
baseObject LDAPDN, LDAP: Base Object = o=eleves, o=eig
scope ENUMERATED { }, LDAP: Scope = Single Level
sizeLimit INTEGER (0 .. maxInt), LDAP: Deref Aliases = Always Deref Aliases
timeLimit INTEGER (0 .. maxInt), LDAP: Size Limit = No Limit
} LDAP: Time Limit = No Limit
Le serveur a maintenant reçu la requête de la part du client., il est prêt à lui envoyer les
données. Il le fait simplement en indiquant, le chemin de la donnée dans l’arbre. Si par
exemple un user (uid) est dans l’annuaire Elèves et dans la classe TE3.
o=Elèves
cn = TE3
uid = toto
Une fois que le serveur a renvoyé toutes les données qui se trouvent chez lui, il envoi
un paquet Search Response Simple au client pour lui dire que la transaction est
terminée.
Dans ce paquet est envoyé le paramètre success.
Lorsque je me connecte sur mon serveur iPlanet par le biais du client LDAP, j’ai la
possibilité d’ajouter de nouveaux utilisateurs dans le cas où je me connecte en tant que
« Super Manager ». En effet, une seule personne est apte à modifier des données dans
l’annuaire LDAP. Dans mon cas, il s’appelle Directory Manager (nom par défaut dans
le serveur iPlanet 5.0).
Ainsi une fois connecté avec ce login et son mot de passe correspondant, je peux
ajouter un utilisateur. Dans le cas où je me connecte sous un autre compte valide, je ne
pourrai que consulter les données de l’annuaire.
SearchRequest (3)
SearchResponse (4)
Client
Server iPlanet
SearchResponseSimple (5)
Si l’on regarde de plus prêt les paquets Add Request et Add Response voici ce que l’on
obtient.
On voit très bien ici que le nouveau compte a été créé dans l’annuaire à l’emplacement
cn=gaio, o=eleves, o=eig et que les champs entrés lors de l’activation du compte sont
sn=pascal et cn=gaio. Ces deux champs sont ceux à remplir obligatoirement lors de la
création de l’utilisateur.
En ce qui concerne la réponse du serveur, elle dit simplement que le nouvel utilisateur
a été ajouté.
Les paquets suivants (Search) sont présents afin d’afficher physiquement la nouvelle
valeur entrée sur le browser du client.
Client
Server iPlanet
LDAP: ProtocolOp: DelRequest (10) LDAP: ProtocolOp: DelResponse (11)
LDAP: MessageID LDAP: MessageID
LDAP: ProtocolOp = DelRequest LDAP: ProtocolOp = DelResponse
LDAP: Object Name = cn=gaio, o=eleves, o=eig LDAP: Result Code = Success
Nous avons aussi la possibilité d’effacer directement toute une branche de l’annuaire.
Afin que le client puisse effacer toutes les données de l’arbre, il faut qu’il connaisse
toutes les données se trouvant dans la branche. Pour cela, le client va effectuer un
search Request sur toute la branche et effacer une par une toutes les données qui s’y
trouvent. Pour finir il effacera le haut de la branche. Ici la branche o=eleves contient
une seule donnée (uid = pgaio).
Il se peut que le serveur LDAP soit hors service (machine éteinte ou serveur arrêté)
pour diverses raisons. De ce fait, plus personne ne devrait pouvoir consulter des
données dans celui-ci. Nous avons vu dans le chapitre 5 concernant ISA Server ce qui
se passait au niveau protocole lorsqu’un serveur Web était hors service. Voyons
comment cela se passe avec un serveur LDAP.
Il faut rappeler que pour atteindre un serveur LDAP il faut d’abord établir une
connexion TCP puis une connexion LDAP. De ce fait si j’essaye de me connecter sur
le serveur alors que celui-ci est éteint, c’est au niveau TCP que la connexion
n’aboutira pas (après plusieurs essais de connexion).
TCP SYN
TCP SYN
TCP SYN
Client
Server iPlanet
Maintenant, je prends le cas où l’on est connecté depuis un moment sur l’annuaire
LDAP via le browser du client et que le serveur s’arrête brusquement.
Les connexions TCP et LDAP sont établies.
Si l’on essaye d’atteindre une donnée voici ce qui arrive.
Remarque :
La fréquence entre deux paquets Search Request est toujours multipliée par deux entre
chaque paquet.
Il est possible de se connecter avec des paramètres spéciaux sur le serveur iPlanet. En
effet, le client peut demander à ce que le serveur ne lui envoie pas toutes les données
de son annuaire lors de la connexion. C’est le but du paramètre Size Limit. Il permet de
limiter les données transmises par le serveur LDAP. Prenons l’exemple d’un annuaire
qui contient 500 données. Moi client, je ne veux pas que le serveur me retourne ses
500 données, car je perdrai du temps. Ainsi je lui dit de m’envoyer uniquement 50
éléments de son annuaire.
Il faut bien voir que c’est le client qui envoit ce paramètre au serveur lorsqu’il se
connecte sur l’annuaire et fait sa première recherche.
Mais voyons au niveau du protocole comment cela se passe.
Pour ma part j’ai configuré le client pour qu’il n’accepte qu’une seule donnée (Size
Limit = 1)
SearchRequest (3)
Size Limit = 0x00000001
SearchResponse (4)
SearchResponseSimple (5)
success
SearchResponse (4)
SearchResponseSimple (5)
Size Limit Exceeded
Après cette étude de protocole, on constate que le serveur LDAP a envoyé deux
données malgré que le paramètre Size Limit est de 1. Cela vient du fait que ce
paramètre affecte le nombre de données transmises par niveau de l’annuaire.
Ainsi, si j’ai un annuaire qui est construit de façon « horizontal», alors une seule
donnée par niveau sera retournée au client (voir figure de la page suivante)
o=eig Niveau 0
Niveau 1
ou = telecommunication ou = informatique
Niveau 2
cn = TE3 cn = TE2 cn = IN3 cn = IN2
uid = dcotte
Seules les données en gras seront retournées au client. Le reste sera ignoré.
La priorité des données envoyées sont en fonction de l’ordre alphabétique.
Lorsque le serveur veut envoyer une autre donnée se trouvant sur le même niveau de
l’arbre, celui-ci se refuse de le faire ayant reçu le paramètre Size Limit = 1 du client.
Par contre, il peut envoyer plusieurs données sur un niveau différent. Ainsi le serveur
LDAP envoi un message d’erreur au client en lui disant Size Limit Exceeded . Ce
message inclus dans le paquet Search Reponse Simple indique que les données
transmises ont étés faites correctement mais qu’il a envoyé la capacité maximale
requise par le client.
Pour mieux comprendre le phénomène du Size Limit par niveau, prenons le cas où Size
Limit = 2.
o=eig Niveau 0
Niveau 1
ou = telecommunication ou = informatique
Niveau 2
cn = TE3 cn = TE2 cn = IN3 cn = IN2
Ici on se rend bien compte que le paramètre Size Limit n’est valable que pour un seul
niveau et pas pour tout l’arbre.
Il se peut parfois que ce soit le serveur qui ferme la connexion. Ceci pour plusieurs
raisons par exemple quand l’administrateur le force à redémarrer. Dans ce cas c’est le
serveur qui envoie la commande Unbind Request. Le client comprend qu’il doit fermer
la connexion.
Mais généralement c’est le client qui se déconnecte de l’annuaire et c’est donc lui qui
envoie cette commande.
Unbind Request
Client
Server iPlanet
8.10 Conclusion
Dans ce chapitre, nous avons vu les différents paquets ainsi que les différents
paramètres qui sont transmis à l’intérieur. Il est évident que lorsque l’on regarde la
RFC 2251 ou 1777, cela correspond exactement à ce que l’on a au niveau de
l’analyseur de protocole. Ce qui facilite grandement la compréhension des différents
paquets émis.
Ce que l’on peut constater, c’est que c’est toujours le client qui effectue les opérations
d’ajout, d’effacement des données ou autre chose encore. Le serveur n’est là « que
pour répondre ». A chaque Request du client, le serveur effectue l’opération et répond
par un paquet Response s’il doit transmettre une donnée et un paquet Response Simple
lorsqu’il a terminé de transmettre ses données.
Je constate donc que le protocole LDAP n’est pas très compliqué et qu’il fonctionne
sur un échange de Question-Réponse. De plus les commandes utilisées pour les
applications LDAP sont très faciles à comprendre et selon moi très explicites. En effet,
pour effacer une donnée, on a un paquet Del Request, pour ajouter une donnée, un
paquet Add Request. Je pourrai tous les citer, mais cela sera à chaque fois la même
chose. Des mots simples pour une meilleure compréhension, voilà que je retiens de
plus frappant du protocole LDAP.
Il se peut certaines fois que des données ne soient pas toutes stockées dans un même annuaire
et que le serveur renvoie au client l’adresse d’un autre serveur LDAP où il peut aller chercher
l’information demandée.
Ce principe de renvoie de référence s’appelle un Referral.
Ce mécanisme est assez simple à comprendre mais il faut tenir compte de plusieurs
restrictions.
Lorsque l’on fait un referral d’un serveur vers un autre, la branche sur laquelle on accède doit
porter le même nom et être du même type (o, ou , cn, etc…) que d’où part le renvoi de
référence.
o=eig
ou = telecommunication ou = informatique
t
incorrect
rrec rect
Referral
Ref
al inco incor e
cor rral
ferr ype rec
Re é et t t
érron
nom
Un autre problème qui peut se créer avec ces referrals, c’est le cas où l’on ne fait pas attention
et plusieurs referrals sont présents sur le même serveur. Il peut y avoir un interblocage.
Annuaire A
Re
ral
fer
fer
ral
Re
INTERBLOCAGE
Referral
Annuaire B Annuaire C
Un referral LDAP contient un url qui sera renvoyé au client. Les informations
transmises dans ce referral sont :
Par exemple, un client qui recherche la liste d’élèves aura deux moyens de l’atteindre.
Soit en se connectant sur le serveur des élèves, soit en se connectant au serveur de
l’eig qui fera un referral sur le serveur des élèves.
Ici le port par défaut du protocole LDAP est 389. Il est cependant possible comme
pour HTTP (port 80), de modifier le numéro de port à sa guise.
Il existe plusieurs types de referrals. Le plus couramment utilisé est le smart referral.
Il consiste simplement à renvoyer au client l’adresse d’un second serveur sur lequel il
pourra trouver la donnée.
o=eig
Serveur A
ou = telecommunication ou = informatique
uid=dcotte cn = sbancal
Le deuxième type de referral est le default referral. Lorsque que le client recherche
une donnée et que le serveur ne la possède pas, alors il renverra au client l’adresse
d’un autre serveur sur laquelle il pourra éventuellement trouver l’information
recherchée.
Default Referral
o=eig o = eig
ou = telecommunication ou = informatique
cn = IN3 cn = IN2
cn = TE3 cn = TE2
Serveur A Serveur B
Smart Referral
pas d'informations Information
trouvées sur le dn trouvée
recherché
cn = IN2
Ici le client fait la recherche de
dn : uid=dcotte, cn=IN2, ou=informatique, o=eig
sur le Serveur A de l’eig
uid=dcotte cn = sbancal
Serveur C
Information
retournée
au client
Default Referral
Le principe de default referral ne sera pas étudié dans ce chapitre. Seul le smart
referral fera l’objet d’une étude détaillée.
Lorsque l’on se connecte sur un serveur et que celui-ci renvoie au client un referral,
c’est le client qui se connecte sur le serveur référencé.
Connexion TCP
Connexion TCP
Par rapport à un simple recherche, on voit qu’un paquet Search Response Reference
est envoyé par le serveur iPlanet.
Ainsi le paquet important ici, est le paquet Search Reponse Reference. C’est là où
l’adresse du serveur référencé va être transmis.
Search Request
sur o=eleves
Server iPlanet
Search Request
Client sur o=eleves
Search Response
uid=dcotte , uid = sbancal
9.5 Conclusion
Dans ce chapitre, j’ai défini comment mettre en œuvre les referrals et comment ils
fonctionnent. Il faut bien avoir à l’esprit que le serveur LDAP ne fait qu’indiquer au
client sur quel autre serveur LDAP il peut trouver l’information. Il n’est en aucun cas
responsable de rediriger la recherche. Il faut aussi bien comprendre que lors d’un
referral, les types des attributs (o, ou, cn, etc..) doivent être identiques entre les deux
serveurs. Il faut aussi que les noms correspondent.
Le principe de referral est assez simple dans son concept, c’est pourquoi je n’irai pas
plus loin dans son analyse.
J’ai, dans la mise en place des referalls, eu un problème sur le serveur iPlanet. En
effet, lorsque je crée le referall sur un autre serveur, le browser d’iPlanet, ne
fonctionne plus. En effet, la souris passe du sablier à la flèche et le serveur iPlanet est
bloqué. Si je me connecte distance avec un autre browser LDAP, le referall s’effectue
correctement.
J’en déduis que le browser proposé avec le serveur iPlanet à un bug. En effet, la
version utilisée pour mon diplôme a été téléchargée depuis Internet. Peut-être que la
version payante n’a pas ce problème. Il faudrait tester cela.
Le principe du referral est de partager les annuaires. Ainsi chacun des serveurs LDAP dans le
réseau, ont plusieurs informations mais pas la totalité.
Cependant, une fois que nous avons créé notre annuaire, il faut faire en sorte que la totalité
des données soient sauvegardées sur une autre machine au cas où un problème surgirait. Le
referral ne faisant qu’un lien sur un autre serveur, il faut trouver un moyen de copier les
données d’une database. C’est pourquoi le protocole LDAP a défini une norme appelée
Replication.
La réplication peut se faire uniquement entre serveurs.
Concernant la configuration des serveurs pour effectuer une réplication, consulter l’annexe
Tutorial iPlanet.
Ce type de transfert à l’aide d’un fichier de type LDIF, peut être considéré comme une
forme de réplication. En effet, le fait de stocker les informations de l’annuaire et de les
transférer sur un autre serveur peut s’assimiler à ce que fait la réplication de type
LDAP. Soit de copier l’intégralité ou une partie de l’annuaire sur un autre serveur
LDAP.
Lorsque l’on sauvegarde une base de données sous la forme LDIF, celui-ci sera sous
forme de texte. Ce qui n’est pas très pratique pour modifier des données, une
représentation graphique de la base de données est plus facile à gérer.
Afin de faciliter la tache des utilisateurs, il a été mis en place un protocole pour
communiquer entre serveur. Ce protocole n’est pas encore sous forme de RFC. Il est
toujours à l’état expérimental.
Connexion TCP
Bind Request
BindResponse
Search Request
Search Reponse
Extended Response
Deux paquets supplémentaires apparaissent dans cet échange par rapport à un accès
standard. Ce sont les paquets Extended Request et Response. Nous verrons par la suite
que dans les paquets Search Request et Response, des données concernant la
configuration des serveurs seront transmises. Tous ces paquets seront décrits dans le
détail au niveau du protocole dans le chapitre 10.3.
Lorsque l’on fait ce type de réplication, seul les données modifiées dans l’annuaire
entre la dernière réplication effectuée et l’heure courante, seront transmises.
Extended Request
Extended Reponse
Add Request
Add Response
Extended Request
Lors du transfert de données, un paquet Add Request est présent, c’est là que l’on
envoie la donnée à ajouter dans l’annuaire distant.
Tous ces paquets seront décrits au niveau protocole de façon approfondie au chapitre
10.4.
Si l’on regarde de plus prêt chaque paquet, on s’aperçoit qu’un échange au niveau de
la configuration est transmise entre serveurs. Ces paramètres sont transmis à travers
des OID (Object Identifier). Ces OIDs sont standardisés et définis sur le site
http://www.alvestrand.no/objectid/. Pour trouver un OID particulier, taper le numéro
de celui-ci avec .html à la suite de l’adresse donnée auparavant.
Il faut savoir qu’un OID est une suite de numéro séparé par des points qui servent à
définir un standard.
Par exemple, l’OID 2.16.840.1.113730.3 veut dire :
Maintenant que nous avons tous les éléments en main, nous pouvons comprendre les
paquets transmis ainsi que leurs attributs.
Si l’on regarde la figure du chapitre 10.2.1, on voit que les 3 premiers paquets ne
changent pas lors d’un échange traditionnel. Cependant à partir du paquet Search
Request, nous avons des choses intéressantes à étudier.
Search Request
LDAP : Attribute Type : objectclass
LDAP : Attribute Value : supportedcontrol
LDAP: Attribute Value : supportedextension
Le serveur qui possède les données va demander au serveur qui les recevra (serveur
repliqué), quels sont les objectclass qu’il accepte.
Ainsi dans le paquet suivant, le serveur repliqué va envoyé sous forme d’OIDs les
paramètres objectclass qu’il accepte.
Search Response
Attribute Type = supportedcontrol
2.16.840.1.113730.3.4.2
2.16.840.1.113730.3.4.3
2.16.840.1.113730.3.4.4
2.16.840.1.113730.3.4.5
1.2.840.113556.1.4.473
2.16.840.1.113730.3.4.9
2.16.840.1.113730.3.4.16
2.16.840.1.113730.3.4.15
2.16.840.1.113730.3.4.17
2.16.840.1.113730.3.4.14
1.3.6.1.4.1.1466.29539.12
2.16.840.1.113730.3.4.13
2.16.840.1.113730.3.4.18
Attribute Type = supportedextension
2.16.840.1.113730.3.5.7
Server iPlanet 2.16.840.1.113730.3.5.8
Server iPlanet
2.16.840.1.113730.3.5.3 répliqué
2.16.840.1.113730.3.5.5
2.16.840.1.113730.3.5.6
2.16.840.1.113730.3.5.4
Je ne définirai pas tout ce que les serveurs acceptent comme attributs. Il faut savoir
que ce sont des standards. Pour consulter les différents OIDs voir les annexes, où j’ai
synthétisé tous les OIDs utilisés dans ces échanges.
Le paquet suivant est de type Search Response Simple. Il est présent juste pour
informer le serveur que les informations envoyées par le paquets Search Response sont
terminées.
Extended Request
Ensuite des couples de paquets Extended Request et Response sont présents afin de
transmettre les données au consommateur.
Extended Request
LDAP: Request Name = 2.16.840.1.113730.3.5.6
Extended Reponse
(success)
Extended Request
LDAP: Request Name = 2.16.840.1.113730.3.5.5
LDAP : Control Type = 2.16.840.1.113730.3.4.2
Extended Response
Success
Connexion TCP
Bind Connexion
Search Request
Quelles sont les attributs que tu supportes ?
Search Response
Voici les attributs que je supporte
Extended Request
Server iPlanet Voilà ce que j'ai dans mon annuaire Server iPlanet
répliqué
Extended Response
Ok Success j'ai reçu tes données
Extended Request
J'ai fini d'envoyer des données ; on se quitte
Connexion Connexion
close Extended Response close
Success
Cette partie traitait de l’envoi de la database complète. Il faut savoir que l’architecture
des deux bases de données (une sur chaque serveur) qui effectuent la réplication
doivent avoir la même architecture.
Cependant, le trafic généré avec une réplication totale est très grand. Cela peut aller
jusqu’au Giga Bytes. C’est pourquoi il est préférable parfois d’utiliser la deuxième
méthode qui consiste à n’envoyer que les modifications qui ont été faites sur la
database après la dernière réplication.
Une fois la connexion TCP effectuée, le premier couple de paquets LDAP présent est
de type Extended Request et Response. C’est ensuite que les paquets deviennent plus
intéressants.
Si aucune modification n’a eu lieu sur le serveur, alors aucun paquet à part ’louverture
et la fermeture de la connexion de réplication ne seront présents.
Dans mon cas, j’ai ajouté un utilisateur (uid = dcotte). Voilà ce que l’on constate au
niveau du protocole.
Add Request
Divers Attributs Transmis concernant l'utilisateur
Abandon Request
Pour avoir la définition des différents attributs, consulter le document Tutorial iPlanet
en annexe.
Add Request
DATA utilisateur 1
Add Request
DATA utilisateur 2
Add Request
DATA utilisateur 3
Add Request
DATA utilisateur 4
Add Request
Server iPlanet DATA utilisateur 5 Server iPlanet
répliqué
Abandon Request
Ensuite comme pour la plupart des paquets Request, une réponse est envoyée par le
consommateur.
Add Response
Success
La réponse à ce paquet nous indique si les données ont été reçues correctement ou non.
Comme lors d’une déconnexion LDAP (Unbind Request), il n’y a pas de réponse à la
commande Abandon Request. Les deux parties savent qu’elles doivent arrêter là le
transfert des données.
Afin de conclure la réplication, deux paquets sont envoyés de la même manière que
pour l’initialisation mais cette fois-ci pour conclure l’échange..
Extended Request
LDAP: Request Name = 2.16.840.1.113730.3.5.5
LDAP : Control Type = 2.16.840.1.113730.3.4.2
Extended Response
Success
Unbind Request
On peut résumé l’échange de données entre les deux serveurs de la manière suivante.
Extended Request
début de la réplication
Extended Response
ok je suis prêt
Add Request
voici un nouvel utilisateur ajoute-le dans ta liste
Abandon Request
c'est fini. C'était la dernière donnée à ajouter
Add Response
ok success
10.5 Conclusion
Dans ce chapitre, nous avons vu comment faire une réplication. Il ne faut pas oublier
que normalement, le but de la réplication est de sauvegarder toutes les données
régulièrement. C’est pourquoi lors de l’installation de la réplication sur le serveur
iPlanet nous avons une option de configuration pour la fréquence des réplications entre
serveurs. Il faut savoir aussi que cela engendre un trafic assez grand car l’annuaire
atteint parfois 1 Giga Bytes dans les grandes entreprises. C’est pourquoi la réplication
se fait généralement la nuit.
Pour ma part, j’ai utilisé le logiciel iPlanet Directory Server 5.0 pour effectuer les tests
de réplication. Il se peut que d’autres logiciels aient des options différentes de celles
proposées ici.
En effet, un serveur LDAP n’est pas défini comme une norme et l’utilisateur peut créer
son annuaire comme il l’entend. Les logiciels ont eux aussi différentes possibilités.
Ce logiciel peut soit répliquer uniquement les modifications soit tout l’annuaire.
Il offre par contre la possibilité de gérer les heures où l’on veut faire la réplication.
Après avoir passé 3 semaines sur ce logiciel, je le considère comme bon pour faire de
la réplication car il n’est pas trop compliqué à utiliser et fonctionne relativement bien.
Dans les chapitres précédents, nous avons vu les possibilités offertes par un annuaire LDAP.
Cependant, cela ne nous sert pas à grand chose si cette annuaire n’est pas dédié à une
application particulière.
C’est pourquoi, nous avons décidé d’utiliser l’annuaire LDAP dans un cas plus réel.
Tout d’abord, nous voulions faire une authentification d’un client sur un routeur Cisco.
Malheureusement, ceux que nous avons dans le laboratoire (Cisco 2600) ne supportent pas le
protocole LDAP.
Nous avons donc décidé d’utiliser le Firewall Check Point afin que lorsque l’on accède à un
serveur Web, celui-ci va aller contrôler le login et le password du client qui s’y connecte sur
le serveur LDAP.
Voici l’architecture que nous avons utilisée :
Firewall
Check Point
V 4.1
SP5 IIS 5.0
Win NT 4 SP2
IE 6.0 Server Win 2k
SP2 Server
Win 2k Pro IP Machine = 129.194.184.82
IP Machine = 10.0.0.1 IP Machine = 10.0.0.2
IP = 129.194.184.206
Internet
Client
Firewall Check Point Server Web
IP Web par translation (NAT)
129.194.186.210
Server LDAP
iPlanet Directory Server 5.0
IP Machine = 10.0.0.3
iPlanet 5.0
SP2
Win 2k Pro
Une configuration du Firewall est nécessaire afin que celui-ci accède au serveur LDAP pour
authentifier le client. En annexe, j’ai fait un tutorial qui explique comment configurer le
Firewall (Annexe C).
La connexion entre le Firewall et le serveur Web était déjà effectuée précédemment par
M.Borsa (diplômant dans le laboratoire), je n’ai fait que reprendre ce que lui avait déjà fait.
Une fois que l’on a configuré correctement le Firewall, il nous faut créer un compte
utilisateur sur le serveur iPlanet. C’est avec ce compte que l’on se connectera au
serveur Web qui se trouve derrière le Firewall.
Pour cela, j’ai créé une nouvelle base de donnée appelée o=firewall, et j’ai créé un
utilisateur appelé pgaio.
Avec gaio comme nom et pascal comme prénom, ce qui correspond par défaut à un
uid=pgaio. Cet uid peut être modifié lors de la création de l’utilisateur. Voir captures
ci-dessous.
Login = pgaio
Password = labotd
Pour installer une nouvelle base de données ainsi que pour ajouter un nouvel
utilisateur, se référer à l’annexe C.
Les requêtes du client qui se connecte sur le serveur Web, vont être interceptées par le
Firewall (protocole http uniquement).
Le Firewall va lui répondre en lui disant que la connexion est impossible car il doit
s’identifier.
Firewall
Check Point
V 4.1
SP5 IIS 5.0
Win NT 4 SP2
IE 6.0
Server Win 2k
SP2
Server
Win 2k Pro
IP Machine = 129.194.184.82
IP Machine = 10.0.0.1 IP Machine = 10.0.0.2
IP = 129.194.184.206
Get Request
129.194.186.210
Reponse
Unauthorized authentification requise
Client
Get Request 129.194.186.210
login et password Firewall Check Point Server Web
IP Web par translation (NAT)
129.194.186.210
Server LDAP
iPlanet Directory Server 5.0
IP Machine = 10.0.0.3
iPlanet 5.0
SP2
Win 2k Pro
Le message « FW-1 Reason: no user » venant de la commande realm, est celui qui
nous apparaît dans la boîte de dialogue (voir page précédente), lorsque le serveur nous
demande une authentification.
C’est le browser (dans mon cas Internet Explorer 6.0) qui va afficher la boîte de
dialogue pour que l’utilisateur s’authentifie correctement à l’aide des champs
mentionnés ci-dessus.
Maintenant que la boîte de dialogue a été ouverte, le client doit entrer les données pour
s’authentifier sur le Firewall à travers l’annuaire LDAP.
Séquence Caractères
0 … 25 «A » … «Z »
26 … 51 «a » … «z» Codage Base 64
52 … 61 « 0 » … «9 »
62 «+»
63 «/ »
Exemple :
Le login et le password que j’ai tapé sont :
Login = pgaio
Password = labotd
Le client envoie son login et son password via le protocole http. Le Firewall va
chercher dans l’annuaire LDAP si les données entrées par l’utilisateur sont correctes
via le protocole LDAP.
Pour cela il va rechercher dans l’annuaire (défini lors de la configuration du Firewall),
s’il existe un uid=pgaio.
Si oui l’annuaire lui renvoie le chemin où il peut le trouver (uid=pgaio,o=firewall).
Ensuite il va se connecter à l’annuaire avec le password et le login que l’utilisateur a
taper en envoyant la commande Bind Request. L’annuaire accepte ou non la connexion
à l’annuaire. S’il l’accepte, cela veut dire que le password correspond bien au login et
la réponse sera Bind Response = success.
Firewall
Check Point
V 4.1
SP5 IIS 5.0
Win NT 4 SP2
IE 6.0 Server Win 2k
SP2 Server
Win 2k Pro IP Machine = 129.194.184.82
IP Machine = 10.0.0.1 IP Machine = 10.0.0.2
IP = 129.194.184.206
Internet
Sea
Client rch
Req
ue
Firewall Equ st o=f Server Web
ality irew
Check Point ma all (w
tch
Sea uid= hole s IP Web par translation (NAT)
pga ubtre 129.194.186.210
uid uid= rch R io e)
=p pga espo
io,o n
gaio
,o= =fire se
firew B wall
all ; ind R
aut e
hen quest
tific
atio
Bin n sim
dR ple
esp = la
suc ons bot
ces e d
s
Server LDAP
iPlanet Directory Server 5.0
IP Machine = 10.0.0.3
iPlanet 5.0
SP2
Win 2k Pro
Si la réponse du serveur LDAP est success, alors le client sera authentifié correctement
et une connexion sera ouverte entre le client et le serveur Web à travers le Firewall.
Cet échange ne nous intéresse pas trop.
Il faut savoir que le protocole utilisé est uniquement du http et est le même (au niveau
http) que lors d’une connexion client serveur.
HTTP HTTP
Response Response
Data du site web Data du site web
L’échange est maintenant terminé. Le client ayant reçu les données correctement.
Il se peut que l’utilisateur qui se connecte sur le serveur Web, se trompe en tapant son
password lors de l’authentification. L’objectif de ce chapitre est de montrer comment
réagi le Firewall et le serveur LDAP lorsqu’un tel cas se produit.
J’utilise toujours l’utilisateur pgaio pour me connecter. Son password correct est
labotd. Cependant il se trompe et tape obaltd.
C’est une fois que le client a entré son login et son password erroné que des choses
intéressantes arrivent.
En effet, le Firewall fait toujours la requête sur le serveur LDAP pour savoir s’il existe
un utilisateur appelé pgaio.
Mais cette fois-ci lorsque le Firewall essayera de se connecter avec le password erroné
(obaltd), le serveur LDAP renverra dans son paquet Bind Response la valeur Invalid
Credentials qui correspond à une erreur de type password erroné.
Firewall
Check Point
V 4.1
SP5 IIS 5.0
Win NT 4 SP2
IE 6.0 Server Win 2k
SP2 Server
Win 2k Pro IP Machine = 129.194.184.82
IP Machine = 10.0.0.1 IP Machine = 10.0.0.2
IP = 129.194.184.206
Internet
Sea
Client rch
Req
ue
Firewall Equ st o=f Server Web
ality ire
Check Point ma wall (w
tch IP Web par translation (NAT)
uid= hole s
Se pga ubtr 129.194.186.210
uid= arch R io ee)
uid pga espo
=p io ,o= nse
gaio firew
,o=
firew Bin all
Par la suite, le Firewall proposera all ; d Re
aut que
hen st
d’entrer à nouveau le password et refera Bin
tific
atio
n sim
Inva d Res
la même opération d’authentification lid C pon
red se
ple
=o
balt
d
jusqu’à trois fois. Cette valeur peut-être ent
ials
iPlanet 5.0
SP2
Win 2k Pro
Maintenant, il se peut que le login que tape l’utilisateur soit lui aussi erroné. A
première vue et sans faire d’étude de protocole, je dirai que lorsque le Firewall essaye
de trouver l’uid correspondant, le serveur LDAP lui renverra directement une erreur et
l’échange s’arrêtera là.
Pour la partie connexion cela se passe toujours de la même façon jusqu’à ce que
l’utilisateur entre son login erroné et son password.
J’utilise toujours l’utilisateur toto pour me connecter mais cette fois-ci il entre le login
ogaio au lieu de pgaio. Son password est correct (labotd).
Firewall
Check Point
V 4.1
SP5 IIS 5.0
Win NT 4 SP2
IE 6.0 Server Win 2k
SP2 Server
Win 2k Pro IP Machine = 129.194.184.82
IP Machine = 10.0.0.1 IP Machine = 10.0.0.2
IP = 129.194.184.206
Internet
Client
Firewall Server Web
Sea
Check Point rch
Req IP Web par translation (NAT)
u
Equ est o= 129.194.186.210
ality firew
ma all (w
tch
Sea
rch uid= hole s
Res oga ubtr
io ee)
pon
suc se
ces Simp
s le
Il est normal qu’un utilisateur navigue sur Internet et qu’il revienne plusieurs fois sur
le site authentifié. Il est clair que le rôle du cache est toujours valide en ce qui
concerne les échanges http (voir chapitre 1, 2 et 3 et plus particulièrement le chapitre
1.5 pour l’étude du cache Web). Cependant en ce qui concerne les login et password,
je constate que ceux-ci sont pendant un certain temps, stockés dans le Firewall.
Ainsi si j’accède au site Web pour la deuxième fois après un certain temps, le Firewall
ne testera pas le login et le password entré par l’utilisateur à travers le serveur LDAP
car ces données sont stockées localement. Je ne peux malheureusement pas tester ce
temps de stockage en cache des utilisateurs, car le laboratoire ne possède pas la licence
LDAP pour le Firewall Check Point. Ainsi sans cette licence, je peux utiliser le
protocole LDAP pour accéder à un serveur LDAP, par contre je ne peux pas gérer cet
accès. Par exemple, je ne peux pas modifier les options qui font que les données de
l’utilisateur, une fois authentifié sur le serveur LDAP, seront stockées pendant un
certain temps dans la base de données du Firewall.
11.7 Conclusion
L’annuaire qui doit servir à valider l’accès à un site Web nécessitant une
authentification de l’utilisateur a donc été créé avec succès. La mise en œuvre est assez
rapide mais la gestion n’a pas pu se faire à cause de ce manque de licence. Cependant,
nous avons vu comment était transmis les données entre les différentes machines
(annuaire LDAP – Firewall – Client). L’accès fonctionne correctement et si le serveur
LDAP ne fonctionne plus, personne ne pourra se connecter au serveur Web.
Chapitre 12 : Bibliographie
Tous les documents avec une étoiles sur le côté, sont des documents indispensables à la bonne
compréhension du sujet.
Site consultés :
http://www.isoc.org/isoc/whatis/conferences/inet/96/proceedings/a4/a4_3.htm
Site très complet qui nous présente le cache de façon complète. Assez compliqué à
comprendre mais très intéressant.
http://www.alianwebserver.com/informatique/internet/http/default.htm#Gestion%20de
s%20caches
Site très intéressant sur les principes http, cache et Internet. Très intéressant mais ne
rentre, malheureusement, pas beaucoup dans les détails.
Livre consulté :
Livre en Anglais mais très facile à comprendre. Il présente les points les plus
importants du logiciel et est très détaillé lorsqu’il s’agit de configurer un élément du
serveur ISA.
Sites consultés :
* http://microsoft.supinfo.com/articles/isa/
Site qui nous renseigne sur les possibilités d’ISA et de configuration du logiciel selon
ce que l’on veut faire. Très utile. C’est un résumé du livre que j’ai consulté.
* http://www.adsl-facile.com/Dossiers/ISAServer/
Document très intéressant qui montre comment configurer ISA Server et qui décrit ces
fonctionnalités. C’est une sorte de tutorial. Très bon document.
* http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/isa/
proddocs/isadocs/CMT_CacheAbout.asp
Présentation du fonctionnement du cache d’ISA Server. Très bon document
Partie LDAP
Livre consulté :
Livre qui présente les possibilités de LDAP. Bon pour les principes LDAP au niveau
des annuaires. Au niveau des referrals, c’est correct, mais au niveau réplication, pas
beaucoup d’informations.
En général, bon livre pour débuter avec LDAP mais ne rentre pas assez dans les
détails.
Sites consultés :
http://www.iit.edu/~gawojar/ldap/index.html
Site qui permet de télécharger le browser LDAP sous java
http://globecom.net/ietf/draft/draft-merrells-ldup-model-01.txt
Sorte de RFC sur la réplication
http://asn1.elibel.tm.fr/en/biblio/asn1-presentation_fichiers/frame.htm
Site complet sur l’ASN1. Très intéressant.
http://www.vijaymukhi.com/vmis/ber.htm
Site qui permet d’avoir des informations sur le codage ber afin de décoder l’ASN1
utilisé dans le protocole LDAP
* http://cui.unige.ch/eao/www/memoires/Hugentobler/certnum.html
Exemple concret de décodage de l’ASN1 sur un certificat.
* http://people.ne.mediaone.net/wasser/ASN1/BasicEncodingRules.html
Site très bon pour la compréhension du codage ber (le site le plus complet sur le sujet)
http://database.sarang.net/database/ldap/presentation/index.htm
Présentation sous forme de slide de LDAP en général. Très bon pour comprendre les
principes
* http://www-sop.inria.fr/semir/personnel/Laurent.Mirtain/ldap.html
Très bon document. Tutorial LDAP très complet.
* http://www.cru.fr/ldap/tutorial/tutorial_ldap.pdf
Très bon document. Tutorial LDAP très complet.
* http://www.alvestrand.no/objectid/
Seul site trouvé qui décrit précisément tout les OIDs. Unique inconvénient, le site n’a
pas été remis à jour depuis 1998.
http://www.ldapzone.com/cgi-bin/01/index.cgi
Forum LDAP. Site généralement fréquenter par des programmateurs LDAP.
http://www.crackinguniversity2000.it/Paper/LDAP-FAQ-23.htm
Réponse à des questions standard sur LDAP
http://www.ldapguru.com/
Site qui propose d’importantes informations à tous les niveaux LDAP.
http://listes.cru.fr/wws/arc/ldap-fr/2001-11/thrd1.html#00001
Forum LDAP du site cru.fr. Réponse généralement dans la demi-journée qui suit la
question.
http://docs.univ-nancy2.fr/ldap/
section LDAP de l’université de Nancy. Très intéressant mais malheureusement les
applications créées sont très souvent sous Linux.
http://developer.novel.com/research/devnotes/1998/august/02/d980802_.pdf
Très bon document qui montre les différences entre le protocole LDAP Version 2 et la
version 3.
RFC :
* http://www.hotldap.com/standards/index.html
Liste de toutes les RFC faisant référence au protocole LDAP
http://www.crackinguniversity2000.it/Paper/LDAP-RFCs.htm
Idem. Liste de toutes les RFC. La présentation est moins claire mais il y a beaucoup
plus d’informations sur les RFC. Une description est faite pour chacune des RFC
présentées.
Sites consultés :
www.allasso.fr/base/docs/1967035335.PDF
Site qui montre les possibilités offertes par le Firewall Check Point
* http://support.checkpoint.com/kb/docs/public/firewall1/4_1/pdf/opsec_fw.pdf
Site qui présente comment configurer LDAP avec le Firewall Check Point. La
démonstration est faite avec un serveur LDAP Novell. Voir les annexes pour iPlanet
Conclusion
Ces trois mois passés dans le laboratoire, afin de réaliser mon travail de diplôme,
m’ont permis d’apprendre la gestion d’un projet sur une durée beaucoup plus longue
que j’en avais l’habitude. J’ai pu me rendre compte de la difficulté à gérer ce type de
projet sur plusieurs mois.
En ce qui concerne le travail effectué pendant ces trois mois, je pense que les résultats
obtenus correspondent aux objectifs fixés.
En effet, en ce qui concerne la partie qui consistait à étudier le cache Web, après
diverses difficultés, j’ai enfin pu faire ressortir les différents endroits où le cache était
stocké en utilisant le browser Internet Explorer 5.0 et 6.0. Mais certaines données
stockées ne seront jamais visibles, Microsoft gardant des données secrètes à
l’utilisateur (stockage de plusieurs informations en RAM).
Par la suite en installant ISA Server, j’ai constaté que le gain au niveau des échanges
de données n’était pas négligeable. En effet, lorsque le serveur ISA possède les
données d’une page dans son cache, aucun paquet n’est transmis entre ISA et le
serveur Web. Ainsi il n’y aura aucun trafic sortant et tout se fera localement. De ce fait
les accès sur cette page se feront très rapidement (vitesse du réseau local). Le test du
gain de temps n’a pas pu être fait.
Par la suite j’ai pu mettre en œuvre un reverse proxy et j’ai pu constater qu’au niveau
http, le mode proxy ou reverse proxy fonctionne de la même manière.
Pour moi le logiciel ISA Server est un bon investissement dans le cas où le flux sortant
pour les connexions à Internet n’est pas très élevé.
Pour finir, j’ai pu mettre en place un annuaire LDAP et regarder les principales
fonctionnalités du protocole LDAP. J’ai pu démontrer comment fonctionnait un
referall et surtout comment fonctionnait une réplication entre serveurs.
De plus j’ai pu mettre en œuvre une petite application qui permet à un Firewall Check
Point d’authentifier un client à travers un annuaire LDAP.
Je considère donc que j’ai atteint les objectifs fixés et je pense que les résultats
obtenus, correspondent aux attentes qui m’étaient demandées tout au long de mon
diplôme.
GAIO Pascal
5.1 Introduction.............................................................................................................................................................. 54
5.2 Fonctionnement du Serveur ISA ........................................................................................................................... 55
5.3 Test avec un seul client et une carte Ethernet sur ISA ...................................................................................... 56
5.4 Mode http Header Frequently............................................................................................................................... 57
5.4.1 Commande max-age envoyée par le serveur Web....................................................................................... 57
5.4.2 Cache présent valide sur le client et sur ISA avec rafraîchissement F5 ................................................... 58
5.4.3 Cas où le serveur Web envoi un no-cache ..................................................................................................... 60
5.4.4 Cache présent sur le client et sur ISA avec rafraîchissement ENTER...................................................... 63
5.5 Mode http Header Normally ................................................................................................................................ 63
5.5.1 Aucun cache présent sur le client mais présent sur ISA............................................................................. 64
5.5.2 Cache présent sur le client et présent sur ISA.............................................................................................. 65
5.5.3 Les autres cas ..................................................................................................................................................... 66
5.5.4 Différences entre les modes http Caching .................................................................................................... 67
5.6 Mode Active Caching ............................................................................................................................................ 68
5.7 Ajout d’un deuxième client .................................................................................................................................. 69
5.8 Fonctionnement du serveur ISA avec 2 cartes Ethernet .................................................................................. 70
5.9 Server Web Down................................................................................................................................................... 71
5.10 Les principales commandes HHTP rencontrées .......................................................................................... 72
5.11 Les fichiers LOG ............................................................................................................................................... 73
5.12 Qu’a-t-on gagné avec ISA ? ............................................................................................................................ 74