FR 2843508 A1 20040213 FR 0210001 A 20020806 PROCEDE ET ARCHITECTURE DE COMMUNICATION ENTRE UN EQUIPEMENT CLIENT ET UN MODULE INTERMEDIAIRE SITUES TOUS LES DEUX SUR UN RESEAU LOCAL. L'invention concerne la mise en oeuvre efficace d'un système de contrôle d'accès à un réseau informatique. Les systèmes de contrôle d'accès authentifient, autorisent, ouvrent et ferment l'accès à un réseau plus vaste (en général l'Internet public) pour des ordinateurs reliés à 10 un réseau local. Traditionnellement, ces systèmes de contrôle d'accès se situent au niveau du réseau local. Une application typique de cette invention concerne l'équipement d'un hôtel souhaitant offrir un accès Internet haut-débit à ses clients, sans pour autant avoir 15 à gérer la complexité des multiples paramétrages de connexion de chaque utilisateur, ni les différentes logiques de facturation du service, nécessaires pour contrôler cet accès. De manière spécifique, l'invention permet à un 20 serveur Web centralisé de gérer tous les aspects de l'interface utilisateur, de l'authentification, de l'autorisation en fonction de paramètres divers et de pouvoir se limiter à quelques instructions très simples au système de contrôle d'accès afin qu'il puisse ouvrir ou 25 fermer l'accès à des utilisateurs sur le réseau local. tat de l'art L'état de l'art dans les réseaux haut-débit peut être groupé en deux catégories: 1.Le contrôle d'accès centralisé RADIUS 30 2. Le contrôle d'accès géré localement 1. Le contrôle d'accès centralisé RADIUS Cette approche est caractérisée par: a) Un contrôleur d'accès local simplifié sur le réseau entre l'utilisateur et Internet, avec une page Web 35 requérant un nom et un mot de passe b) Un serveur centralisé RADIUS qui conserve trace des utilisateurs autorisés, leur nom et leur mot de passe, ainsi que les paramètres d'accès permettant de définir les droits d'utilisation d'un visiteur. Un utilisateur se connectant via un tel système passerait typiquement par les étapes suivantes: - L'utilisateur demande l'accès à une page Web depuis son navigateur - Le contrôleur d'accès redirige la demande 10 d'accès vers le serveur Web du contrôleur d'accès - Le serveur Web du contrôleur d'accès produit une page de connexion standard demandant à l'utilisateur son nom et son mot de passe. - L'utilisateur entre ces informations - Le contrôleur d'accès envoie ces informations (souvent via Internet) au serveur central RADIUS - Le serveur central RADIUS répond au contrôleur d'accès avec une autorisation, ou un refus 20 d'accès - En cas d'autorisation, le contrôleur d'accès ouvre l'accès au réseau, en fonction des instructions reçues du serveur central RADIUS. Cette méthode possède deux limitations: 1 Les options d'authentification offertes à l'utilisateur se limitent à un nom et un mot de passe. Cette méthode est bien adaptée en environnement d'entreprise, qui possède une liste fixe et connue a 30 priori d'utilisateurs, mais elle est très mal adaptée pour les lieux publics o les visiteurs ne sont pas connus a priori (hôtels, aéroports, cafés) et changent très souvent. 2.Les pages Web vues par l'utilisateur dans le 35 cadre du processus d'identification doivent être adaptées et mises à jour pour chaque site, ce qui est coteux et difficile à gérer. 2. Le contrôle d'accès géré localement par l'administrateur réseau Une méthode alternative permet de résoudre la première limitation mentionnée ci-dessus, mais pas la seconde. Elle consiste à installer une machine serveur conservant l'ensemble des pages Web, bases de données et de paramètres d'autorisation - tout au niveau local. Toutefois, les limitations de cette approche sont les suivantes: l'installation et la maintenance d'un tel système sont complexes. Chaque site possède sa propre configuration, son propre jeu de pages Web, de paramètres 15 d'autorisation, etc. Les mises à jour deviennent problématiques dès que le nombre de sites gérés devient important. L'interface avec les données centralisées est complexe. Elle nécessite que des standards très stricts 20 soient établis pour les protocoles d'autorisation entre le contrôleur d'accès et le serveur centralisé. Toute déviation de ces standards nécessite en effet une mise à jour coordonnée de la logique d'autorisation sur chacun des points d'accès locaux des contrôleurs. On connaît également dans l'art antérieur la demande de brevet internationale WO 9840990 divulguant une méthode permettant à un dispositif utilisateur configuré pour communiquer avec un réseau personnel de communiquer avec un réseau étranger, comprenant les étapes consistant a: i) connecter le dispositif utilisateur au réseau étranger; ii) intercepter les paquets transmis du dispositif utilisateur, qui seraient dans un autre cas 35 jetés par les dispositifs du réseau étranger afin de déterminer sans connaissance préalable les paramètres réseau du dispositif utilisateur; iii) utiliser les paramètres réseau déterminés pour déterminer s'il faut intercepter les paquets suivants; i v) modifier automatiquement les paquets transmis depuis le dispositif utilisateur en fonction des paramètres réseau du dispositif utilisateur et des paramètres réseau du réseau étranger. Cette méthode de l'art antérieur comporte l'inconvénient que seuls certains paquets sont interceptés, ce qui induit une logique assez complexe dans le dispositif chargé d'intercepter les paquets pour déterminer quels paquets intercepter. Cette méthode de l'art antérieur comporte l'inconvénient que seuls certains paquets sont interceptés, ce qui induit une logique assez importante dans le dispositif chargé d'intercepter les paquets pour déterminer quels paquets intercepter. 20 Problème technique résolu par l'invention La présente invention entend remédier aux inconvénients de l'art antérieur en fournissant une méthode pour centraliser tous les éléments de l'interface 25 utilisateur et du contrôle d'accès de multiples sites sur un serveur Web centralisé. Sur chaque site, au niveau du réseau local, un agent logiciel, appelé dans la suite de ce document " module intermédiaire ", tourne sur une machine placée 30 entre les ordinateurs clients des utilisateurs du réseau et le réseau externe haut-débit (ou le routeur établissant la connexion à ce réseau). Ce module intermédiaire a la possibilité d'ouvrir ou de fermer l'accès au réseau pour chaque utilisateur. Il dirige également toutes les requêtes des utilisateurs non identifiés vers le serveur Web central. Le serveur Web central contrôle le module intermédiaire, et lui indique quand ouvrir ou fermer l'accès au réseau pour tel ou tel utilisateur. Le problème technique que l'invention entend résoudre est de pouvoir contrôler un module intermédiaire connecté à un réseau local protégé par un pare-feu (firewall) ou un routeur, à partir d'un serveur distant, 10 ceci sans ouvrir de brèche dans le pare-feu. Par conséquent, l'invention résout deux problèmes concrets: 1.Lorsque l'ordinateur client et le module intermédiaire sont situés derrière un pare-feu, le serveur 15 Web central ne peut pas identifier l'ordinateur client en utilisant une variable que le module intermédiaire pourra comprendre. Lorsqu'un ordinateur client se connecte au serveur Web central, celui-ci a deux façons de l'identifier: 20 * Par son adresse IP * Par la session Web Mais aucune de ces informations ne convient pour que le serveur Web central base ses instructions au module intermédiaire: * L'adresse IP: lorsque le réseau local est derrière un pare-feu, le serveur Web ne connaît que l'adresse IP du pare-feu, et non l'adresse du client. Tous les ordinateurs clients situés derrière le pare-feu semblent ainsi avoir la même adresse IP. * Session Web: la session Web est connue du serveur Web, mais elle n'est pas compréhensible par le module intermédiaire, qui ne peut identifier l'ordinateur client que par son adresse sur le réseau local. 2.Lorsque le module intermédiaire est situé 35 derrière un pare-feu, le serveur Web central ne peut pas lui envoyer d'instruction à moins d'ouvrir des brèches dans le pare-feu, ce qui est le plus souvent exclu. Si le serveur Web central gère les authentifications des clients, il lui est nécessaire de 5 pouvoir envoyer des instructions au module intermédiaire pour l'ouverture ou la fermeture de l'accès pour tel ou tel utilisateur. Mais par définition, un pare-feu est conçu pour rejeter tout appel entrant du réseau extérieur. Pour ce faire, la présente invention est du type 10 décrit ci-dessus et elle est remarquable dans son acceptation la plus large, en ce qu'elle concerne un système de contrôle d'accès à un réseau public par des postes clients comportant un réseau local sur lequel sont connectés les ordinateurs clients, au moins un ordinateur 15 client possédant une carte d'interface réseau ayant son identification MAC unique, un routeur/parefeu protégeant le réseau local d'attaques extérieures et fournissant un service de traduction d'adresse afin que de multiples clients puissent partager la même adresse IP 20 publique/routable, une connexion à Internet ou tout autre réseau externe et un serveur Web connecté à Internet ou tout autre réseau, caractérisé en ce que ledit système comporte en outre un ordinateur équipé d'un module intermédiaire et possédant au moins deux cartes 25 d'interface réseau placées en mode " promiscuous " afin qu'elles reçoivent tous les paquets circulant sur le réseau, l'une desdites cartes étant connectée au réseau local, l'autre étant connectée au routeur/pare-feu, le module intermédiaire étant constitué par un moyen 30 d'interception de tout le trafic en émission ou en réception au niveau de chaque ordinateur client et d'examen du trafic et de transport des données entre lesdites deux cartes réseau, pour rediriger le trafic vers de nouvelles destinations. Selon une première variante, ledit module intermédiaire est un module logiciel installé sur un ordinateur. Selon une deuxième variante, ledit module intermédiaire est un équipement matériel. De préférence, le module intermédiaire comporte un moyen pour modifier la commande sans changer ni la taille, ni le nombre de paquets de la communication. L'invention concerne aussi un procédé de communication entre un équipement client et un module intermédiaire situés tous les deux sur un réseau local et un équipement distant situé sur un réseau distant caractérisé en ce que: - l'équipement client initie une connection avec l'équipement distant; - l'équipement distant encapsule au moins une commande pour le module intermédiaire dans ses communications avec l'équipement client; le module intermédiaire intercepte chaque communication entre l'équipement client et l'équipement distant, la transfère au destinataire et agit selon ladite commande encapsulée. Avantageusement, ladite étape d'interception 25 consiste à: - le module intermédiaire intercepte la communication provenant de l'équipement client et la transfère à l'équipement distant; - le module intermédiaire identifie les paramètres d'adresse de l'équipement client sur le réseau local; - l'équipement distant établit une session unique avec l'équipement client; - l'équipement distant et le module intermédiaire établissent un identifiant commun de la connexion du client sur le réseau local; L'étape d'encapsulation consiste à ce que 5 l'équipement distant et le module intermédiaire échangent des commandes administratives concernant l'équipement client, en utilisant ledit identifiant commun. Selon une variante, l'étape d'établissement d'un 10 identifiant commun est réalisée selon les étapes suivantes: - l'équipement distant répond à l'équipement client en lui transmettant une instruction de redirection vers un document situé sur un deuxième équipement distant, 15 ledit document comprenant un champ prédéfini; - l'équipement client se connecte audit document à travers le module intermédiaire; - le module intermédiaire intercepte la communication et remplace le champ prédéfini par un 20 identifiant des paramètres d'adresse de l'équipement client sur le réseau local; - le deuxième équipement distant reçoit la communication transmise par le module intermédiaire, ladite communication contenant un identifiant de la 25 session unique et l'identifiant des paramètres d'adresse sur le réseau local ajouté par le module intermédiaire; - le deuxième équipement distant associe l'identifiant de session à l'identifiant des paramètres d'adresse. De préférence, l'étape d'établissement d'un identifiant commun est réalisée selon les étapes suivantes: - l'équipement distant répond à une requête de l'équipement client en incluant dans la réponse un 35 paramètre unique; - le module intermédiaire intercepte ladite réponse et associe ledit paramètre unique avec les paramètres d'adresse de l'équipement client sur le réseau local. Avantageusement, l'étape d'établissement d'un identifiant commun est réalisée selon les étapes suivantes: - l'équipement distant répond à une requête de l'équipement client; - ladite réponse contient une instruction de redirection de l'équipement client vers document contenant un paramètre unique; - le module intermédiaire intercepte la communication provenant du client et associe ledit 15 paramètre unique avec les paramètres d'adresse de l'équipement client sur le réseau local. Selon une variante, l'équipement distant répond à une demande de l'équipement client en encapsulant dans cette réponse une commande de déclenchement à l'intention 20 du module intermédiaire afin de générer une action du module intermédiaire. De préférence, le module intermédiaire intercepte ladite commande de déclenchement dans la communication de l'équipement distant vers l'équipement client. Cette 25 commande de déclenchement implique que le module intermédiaire envoie une requête à l'équipement distant pour obtenir des instructions. L'équipement distant répond à la requête du module intermédiaire. Selon un mode de mise en oeuvre particulier - l'équipement client retourne un message à l'équipement distant, contenant ladite commande de déclenchement; - le module intermédiaire intercepte ladite commande de déclenchement dans la communication de 35 l'équipement client vers l'équipement distant; - ladite commande de déclenchement implique que le module intermédiaire envoie une requête à l'équipement distant pour obtenir des instructions; - l'équipement distant répond à la requête du module intermédiaire. L'invention sera mieux comprise à la lecture de la description qui suit, se référant aux dessins annexés concernant un exemple non limitatif de réalisation, o: - La figure 1 illustre une vue globale de 10 l'architecture; - La figure 2 illustre un premier mode de réalisation de l'invention pour identifier l'ordinateur client sur le réseau local; - La figure 3 illustre un deuxième mode de réalisation de l'invention pour identifier l'ordinateur client sur le réseau local; - La figure 4 illustre un troisième mode de réalisation de l'invention pour identifier l'ordinateur client sur le réseau local; - La figure 5 illustre un premier mode de réalisation de l'invention pour envoyer des instructions à l'agent local; - La figure 6 illustre un deuxième mode de réalisation de l'invention pour envoyer des instructions à 25 l'agent local. Architecture L'invention décrite de façon schématique en référence à la figure 1 utilise les éléments 30 d'architecture suivants: a Un réseau local o sont connectés les ordinateurs clients (ce peut être n'importe quel type de réseau, par exemple Ethernet, sans fil, DSL, etc.) * Un ou plusieurs ordinateurs clients (chacun possède une carte d'interface réseau ayant son identification MAC unique) * Une machine sur laquelle tourne le module 5 intermédiaire, possédant au moins deux cartes d'interface réseau. Une carte est connectée au réseau local, l'autre est connectée au routeur/pare-feu (voir ci-dessous). Ces cartes sont toutes deux placées en mode " promiscuous " afin qu'elles reçoivent tous les paquets circulant sur le 10 réseau. * Un routeur/pare-feu qui protège le réseau local d'attaques extérieures et fournit un service de traduction d'adresse afin que de multiples clients puissent partager la même adresse IP publique/routable. * Une connexion à Internet ou tout autre réseau externe * Un serveur Web connecté à Internet ou tout autre réseau. L'architecture du système est donnée en figure 1. Dans l'invention, le module intermédiaire intercepte tout le trafic en émission ou en réception au niveau de chaque ordinateur client. Il examine le trafic et transporte les données entre ses deux cartes réseau, redirigeant le trafic vers de nouvelles destinations comme 25 indiqué ci-dessous. Identifier l'ordinateur client sur le réseau local Lorsqu'un nouveau client se connecte au réseau local, il commence à envoyer des paquets sur le réseau. Ces paquets peuvent comprendre, entre autres, des requêtes 30 DHCP, des annonces réseau, des requêtes ARP pour des serveurs locaux, des appels Internet, etc. Le module intermédiaire intercepte ces paquets et les traite de la manière suivante: * Tous les paquets sont inspectés pour vérifier 35 qu'il s'agit bien d'un nouveau client (identifié par son adresse MAC). Lorsqu'un nouveau client est détecté, il est ajouté à la liste des ordinateurs clients connus. * Toutes les requêtes DHCP sont envoyées sur le réseau externe (o un serveur DHCP doit être installé). De 5 manière similaire, les réponses DHCP sont renvoyées à l'ordinateur client sur le réseau interne. Cela permet aux ordinateurs clients activant DHCP d'obtenir une information IP correcte sur le réseau externe. * Toutes les requêtes ARP pour la résolution 10 d'adresse MAC d'une adresse IP font l'objet d'une réponse avec l'adresse MAC du routeur du réseau externe. * Toutes les demandes de résolution de nom de domaine sont envoyées à un serveur DNS (Domain name server) qui est accessible au réseau local (il peut être 15 situé sur le réseau externe, ou via le fournisseur d'accès Internet du réseau local). Les réponses du DNS sont envoyées à l'ordinateur client. Les noms de domaine qui ne peuvent être résolus par le serveur DNS local (par exemple les noms de domaine locaux, spécifiques pour un réseau 20 d'entreprise) sont associés à une adresse IP par défaut. * Toutes les autres requêtes TCP/IP sont envoyées à un serveur Web centralisé sur un port spécifié (ou un ensemble de ports). Ceci est fait en remplaçant l'adresse IP de destination de chaque paquet avec l'adresse IP du 25 serveur Web centralisé, et le numéro du port par l'un des ports que le serveur Web centralisé écoute, et l'adresse MAC par l'adresse MAC du routeur sur le réseau externe. Le serveur Web centralisé reçoit les requêtes TCP/IP de tous les ordinateurs clients. Concernant les 30 requêtes utilisant le protocole http, il est configuré pour accepter aussi bien les requêtes standards que proxy. Lorsque ces requêtes sont des requêtes standards, le serveur répond au client par une redirection http vers un document nommé XXX dans la suite de l'exposé. Dans une des réalisations de l'invention (comme indiqué sur la figure 2), XXX possède une forme particulière, et comprend un paramètre prédéterminé. Ce paramètre s'appelle " magic-string " dans la suite de ce 5 document. Le serveur cible de la redirection est le serveur Web central. Si la requête initiale provenait d'un navigateur Web, alors le navigateur reçoit la commande redirect, et suit donc l'instruction de redirection. Le module intermédiaire intercepte les requêtes http de l'ordinateur client contenant la magic-string, remplace celle-ci par l'information sur l'ordinateur client qui a envoyé le paquet en premier, puis envoie le paquet ainsi modifié sur le serveur spécifié par l'URL. 15 L'information sur l'ordinateur contient typiquement: * Le code unique identifiant le site (cela permet à un serveur central de travailler simultanément avec de multiples sites et de multiples modules intermédiaires) * L'identifiant de l'ordinateur client sur le 20 réseau local (c'est généralement une référence unique créée par le module intermédiaire, mais il peut également inclure l'adresse MAC de l'ordinateur client) La longueur de la magic-string (en caractères) est identique à celle de l'identifiant de l'ordinateur client 25 sur le réseau local. Cela permet d'assurer que le nombre de paquets transitant par le module intermédiaire reste inchangé. Le serveur Web central reçoit le paquet avec la magic- string modifiée. Il dispose alors de l'information 30 sur l'ordinateur client, et notamment: * L'identifiant de l'ordinateur client sur le réseau local (en un format que le module intermédiaire peut comprendre) * L'identifiant du site o l'ordinateur client est connecté * En outre, le serveur a une session Web active avec le navigateur Web sur l'ordinateur client. Le serveur Web central guide l'utilisateur pendant le processus d'identification. Lorsqu'il a réussi à 5 identifier un nouvel utilisateur, il créé une commande administrative destinée au module intermédiaire afin que celui-ci puisse ouvrir l'accès Internet, en identifiant l'ordinateur local correspondant par une adresse locale en un format compris par le module intermédiaire. La commande 10 administrative peut alors désactiver également l'envoi systématique des paquets TCP/IP sur le serveur Web central. Dans une autre réalisation de l'invention (décrite en figure 3), XXX contient un code unique crée par le 15 serveur Web central dans un format et une position prédéfinis. Le module intermédiaire intercepte ce code unique, et associe le code unique à l'adresse locale de l'ordinateur client sans modifier les informations destinées au client. A partir de ce moment, le serveur Web 20 central peut créer des commandes d'administration pour le module intermédiaire en utilisant ce code unique pour identifier l'ordinateur client. Enfin, dans une autre réalisation de l'invention (décrite en figure 4), XXX contient un code unique crée 25 par le serveur Web central. Ce code unique a un format et une position prédéfinis. L'ordinateur client reçoit la commande de redirection, renvoie une nouvelle requête pour obtenir XXX. Le module intermédiaire intercepte cette commande émise avec ce code unique, associe ce code à 30 l'adresse de l'ordinateur local de l'ordinateur client et envoie la requête au serveur désigné dans la commande de redirection. A partir de ce moment, le serveur Web central peut envoyer des commandes d'administration au module intermédiaire en utilisant ce code unique pour identifier 35 l'ordinateur client. Envoyer des instructions au module intermédiaire Lorsque le processus d'identification d'un nouveau client est terminé, le serveur Web central a besoin de pouvoir indiquer au module intermédiaire qu'il doit ouvrir 5 l'accès au réseau au client. Or, lorsque le module intermédiaire est situé derrière un pare-feu, ce dernier bloque ce type de commande, car elle provient de l'extérieur du réseau local. C'est l'objet même d'un parefeu. L'invention résout cette difficulté en faisant du module intermédiaire l'initiateur de toute communication avec le serveur Web central. Lorsque le serveur Web central possède des commandes destinées au module intermédiaire, il insère 15 dans sa prochaine réponse à une requête http venant d'un client passant par l'intermédiaire une commande poussant le client à effectuer une requête vers un nouveau document nommé YYY et contenant un texte ou objet pré-déterminé qui sert de déclencheur au module intermédiaire et nommé 20 " déclencheur " dans la suite de l'exposé. Cette requête peut être initiée soit par une demande de redirection http vers YYY, soit par l'inclusion dans le document renvoyé d'un lien vers YYY. Exemple: image dans document HTML dont la source est YYY. Dans une des mises en euvre de l'invention (cf. figure 5), le module intermédiaire intercepte tous les paquets de l'ordinateur client, et " voit " la requête pour YYY de l'ordinateur client et contenant le déclencheur. Le module intermédiaire contacte alors le 30 serveur Web central par une requête http. Le serveur répond à cette requête avec un bloc de données contenant la commande qu'il souhaite communiquer au module intermédiaire. Cette commande contient l'adresse locale de l'ordinateur client et les conditions dans lesquelles l'accès au réseau doit être ouvert (par exemple: durée, limitation en volume, etc.) Le pare- feu voit la session http entre le module intermédiaire et le serveur Web central comme une session 5 http classique, en rien différente d'une autre session http entre un client et un serveur. Tant que le serveur Web central répond à une requête provenant de derrière le pare-feu, les données sont transférées par le pare-feu. Dans une autre mise en oeuvre de l'invention (cf. 10 figure 6), le module intermédiaire intercepte tous les paquets provenant du serveur Web central destinés à l'ordinateur client, et " voit " le déclencheur. prédéfini dans le nouveau document. Le module intermédiaire, sans influer sur la communication entre le client et le 15 serveur, contacte alors le serveur Web central avec une requête http. Le serveur répond à cette requête avec un bloc de données contenant la commande qu'il souhaite communiquer au module intermédiaire. Cette commande contient l'adresse locale de l'ordinateur client et les 20 conditions dans lesquelles l'accès au réseau doit être ouvert (par exemple: durée, limitation en volume, etc.) Dans tous les cas, la création d'une communication entre le module intermédiaire et le serveur Web central n'interrompt pas la communication entre le client et le 25 serveur Web central. Celle-ci continue d'être active et de passer à travers le module intermédiaire. REVENDICATIONS 1 - Système de contrôle d'accès à un réseau public par des postes clients comportant un réseau local sur 5 lequel sont connectés les ordinateurs clients, au moins un ordinateur client possédant une carte d'interface réseau ayant son identification MAC unique, un routeur/pare-feu protégeant le réseau local d'attaques extérieures et fournissant un service de traduction d'adresse afin que de 10 multiples clients puissent partager la même adresse IP publique/routable, une connexion à un réseau externe [comme par exemple Internet] et un serveur Web connecté à un réseau [comme par exemple Internet], caractérisé en ce que ledit système comporte en outre un ordinateur équipé d'un 15 module intermédiaire et possédant au moins deux cartes d'interface réseau placées en mode " promiscuous " afin qu'elles reçoivent tous les paquets circulant sur le réseau, l'une desdites cartes étant connectée au réseau local, l'autre étant connectée au routeur/pare-feu, le 20 module intermédiaire étant constitué par un moyen d'interception de tout le trafic en émission ou en réception au niveau de chaque ordinateur client et d'examen du trafic et de transport des données entre lesdites deux cartes réseau, pour rediriger le trafic vers 25 de nouvelles destinations. 2 - Système de contrôle d'accès selon la revendication 1, caractérisé en ce que ledit module intermédiaire est un module logiciel installé sur un 30 ordinateur. 3 - Système de contrôle d'accès selon la revendication 1, caractérisé en ce que ledit module intermédiaire est un équipement matériel. 4 - Système de contrôle d'accès selon l'une quelconque des revendications précédentes, caractérisé en ce que le module intermédiaire comporte un moyen pour modifier la commande sans changer ni la taille, ni le nombre de paquets de la communication. - Procédé de communication entre un équipement client et un module intermédiaire situés tous les deux sur un réseau local et un équipement distant situé sur un 10 réseau distant, caractérisé en ce que: - l'équipement client initie une connection avec l'équipement distant; - l'équipement distant encapsule au moins une commande pour le module intermédiaire dans ses 15 communications avec l'équipement client; - le module intermédiaire intercepte chaque communication entre l'équipement client et l'équipement distant, la transfère au destinataire et agit selon ladite commande encapsulée. 6 - Procédé de communication selon la revendication , caractérisé en ce que l'action du module intermédiaire consiste à modifier la commande sans changer ni la taille, ni le nombre de paquets de la communication. 25 7 Procédé de communication selon l'une des revendications 5 à 6, caractérisé en ce que ledit module intermédiaire est un module logiciel installé sur un ordinateur. 8 - Procédé de communication selon l'une quelconque des revendications 5 à 7, caractérisé en ce que l'étape d'interception consiste à: - le module intermédiaire intercepte la communication provenant de l'équipement client et la transfère à l'équipement distant; - le module intermédiaire identifie les paramètres d'adresse de l'équipement client sur le réseau local; - l'équipement distant établit une session unique avec l'équipement client; l'équipement distant et le module intermédiaire établissent un identifiant commun de la connexion du client sur le réseau local; et en ce que l'étape d'encapsulation consiste en particulier à ce que l'équipement distant et le module intermédiaire échangent des commandes administratives 15 concernant l'équipement client, en utilisant ledit identifiant commun. 9 - Procédé de communication selon la revendication 8, caractérisé en ce que l'étape d'établissement d'un 20 identifiant commun est réalisée selon les étapes suivantes: - l'équipement distant répond à l'équipement client en lui transmettant une instruction de redirection vers un document situé sur un deuxième équipement distant, 25 ledit document comprenant un champ prédéfini; - l'équipement client se connecte audit document à travers le module intermédiaire; - le module intermédiaire intercepte la communication et remplace le champ prédéfini par un 30 identifiant des paramètres d'adresse de l'équipement client sur le réseau local; - le deuxième équipement distant reçoit la communication transmise par le module intermédiaire, ladite communication contenant un identifiant de la session unique et l'identifiant des paramètres d'adresse sur le réseau local ajouté par le module intermédiaire; - le deuxième équipement distant associe l'identifiant de session à l'identifiant des paramètres d'adresse. - Procédé de communication selon la revendication 8, caractérisé en ce que l'étape d'établissement d'un identifiant commun est réalisée selon 10 les étapes suivantes: - l'équipement distant répond à une requête de l'équipement client en incluant dans la réponse un paramètre unique; - le module intermédiaire intercepte ladite réponse et associe ledit paramètre unique avec les paramètres d'adresse de l'équipement client sur le réseau local. 11 - Procédé de communication selon la 20 revendication 8, caractérisé en ce que l'étape d'établissement d'un identifiant commun est réalisée selon les étapes suivantes: - l'équipement distant répond à une requête de l'équipement client; - ladite réponse contient une instruction de redirection de l'équipement client vers document contenant un paramètre unique; - le module intermédiaire intercepte la communication provenant du client et associe ledit 30 paramètre unique avec les paramètres d'adresse de l'équipement client sur le réseau local. 12 - Procédé de communication selon l'une quelconque des revendications 5 à 7, caractérisé en ce 35 que: - l'équipement distant répond à une demande de l'équipement client en encapsulant dans cette réponse une commande de déclenchement à l'intention du module intermédiaire afin de générer une action du module intermédiaire. 13 - Procédé de communication selon la revendication 12, caractérisé en ce que: - le module intermédiaire intercepte ladite commande de déclenchement dans la communication de l'équipement distant vers l'équipement client; - ladite commande de déclenchement implique que le module intermédiaire envoie une requête à l'équipement distant pour obtenir des instructions; - l'équipement distant répond à la requête du module intermédiaire. 14 - Procédé de communication selon la revendication 12, caractérisé en ce que: - l'équipement client retourne un message a l'équipement distant, contenant ladite commande de déclenchement; - le module intermédiaire intercepte ladite commande de déclenchement dans la communication de 25 l'équipement client vers l'équipement distant; - ladite commande de déclenchement implique que le module intermédiaire envoie une requête à l'équipement distant pour obtenir des instructions; - l'équipement distant répond à la requête du 30 module intermédiaire.