FR2843508A1 - Procede et architecture de communication entre un equipement client et un module intermediaire situes tous les deux sur un reseau local - Google Patents
Procede et architecture de communication entre un equipement client et un module intermediaire situes tous les deux sur un reseau local Download PDFInfo
- Publication number
- FR2843508A1 FR2843508A1 FR0210001A FR0210001A FR2843508A1 FR 2843508 A1 FR2843508 A1 FR 2843508A1 FR 0210001 A FR0210001 A FR 0210001A FR 0210001 A FR0210001 A FR 0210001A FR 2843508 A1 FR2843508 A1 FR 2843508A1
- Authority
- FR
- France
- Prior art keywords
- equipment
- intermediate module
- client
- remote
- network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2854—Wide area networks, e.g. public data networks
- H04L12/2856—Access arrangements, e.g. Internet access
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
La présente invention concerne 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.Elle concerne aussi un système pour la mise en oeuvre d'un tel procédé.
Description
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.
Claims (8)
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.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0210001A FR2843508A1 (fr) | 2002-08-06 | 2002-08-06 | Procede et architecture de communication entre un equipement client et un module intermediaire situes tous les deux sur un reseau local |
| AU2003274228A AU2003274228A1 (en) | 2002-08-06 | 2003-08-05 | Method and architecture for communication between a client equipment and an intermediary module which are both located on a local network |
| PCT/FR2003/002467 WO2004015953A2 (fr) | 2002-08-06 | 2003-08-05 | Procede et architecture de communication entre un equipement client et un module intermediaire situes tous les deux sur un reseau local |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0210001A FR2843508A1 (fr) | 2002-08-06 | 2002-08-06 | Procede et architecture de communication entre un equipement client et un module intermediaire situes tous les deux sur un reseau local |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2843508A1 true FR2843508A1 (fr) | 2004-02-13 |
Family
ID=30470965
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0210001A Pending FR2843508A1 (fr) | 2002-08-06 | 2002-08-06 | Procede et architecture de communication entre un equipement client et un module intermediaire situes tous les deux sur un reseau local |
Country Status (3)
| Country | Link |
|---|---|
| AU (1) | AU2003274228A1 (fr) |
| FR (1) | FR2843508A1 (fr) |
| WO (1) | WO2004015953A2 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR3004827A1 (fr) * | 2013-04-19 | 2014-10-24 | Hopi | Procede pour l'utilisation a distance d'un lecteur usb de carte a puce associe a une carte professionnelle de sante ou a une carte patient dite carte vitale et systeme associe. |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20060200612A1 (en) * | 2005-03-02 | 2006-09-07 | Laurence Hamid | Method and protocol for transmitting extended commands to USB devices |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0986229A2 (fr) * | 1998-09-09 | 2000-03-15 | JSB Software Technology plc | Procédé et système pour surveillance et contrôle de l'accès au réseau |
| US6119236A (en) * | 1996-10-07 | 2000-09-12 | Shipley; Peter M. | Intelligent network security device and method |
| WO2001017193A2 (fr) * | 1999-08-30 | 2001-03-08 | Nortel Networks Limited | Protocole internet transparent du type « bump in the wire » |
| US20020035639A1 (en) * | 2000-09-08 | 2002-03-21 | Wei Xu | Systems and methods for a packet director |
-
2002
- 2002-08-06 FR FR0210001A patent/FR2843508A1/fr active Pending
-
2003
- 2003-08-05 AU AU2003274228A patent/AU2003274228A1/en not_active Abandoned
- 2003-08-05 WO PCT/FR2003/002467 patent/WO2004015953A2/fr not_active Application Discontinuation
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6119236A (en) * | 1996-10-07 | 2000-09-12 | Shipley; Peter M. | Intelligent network security device and method |
| EP0986229A2 (fr) * | 1998-09-09 | 2000-03-15 | JSB Software Technology plc | Procédé et système pour surveillance et contrôle de l'accès au réseau |
| WO2001017193A2 (fr) * | 1999-08-30 | 2001-03-08 | Nortel Networks Limited | Protocole internet transparent du type « bump in the wire » |
| US20020035639A1 (en) * | 2000-09-08 | 2002-03-21 | Wei Xu | Systems and methods for a packet director |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR3004827A1 (fr) * | 2013-04-19 | 2014-10-24 | Hopi | Procede pour l'utilisation a distance d'un lecteur usb de carte a puce associe a une carte professionnelle de sante ou a une carte patient dite carte vitale et systeme associe. |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2004015953A2 (fr) | 2004-02-19 |
| AU2003274228A1 (en) | 2004-02-25 |
| AU2003274228A8 (en) | 2004-02-25 |
| WO2004015953A3 (fr) | 2004-04-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8261057B2 (en) | System and method for establishing a virtual private network | |
| US7376715B2 (en) | Asynchronous hypertext messaging system and method | |
| EP0721271B1 (fr) | Système de contrôle d'accès à des machines informatiques connectées en réseau privé | |
| AU770584B2 (en) | Secured session sequencing proxy system and method therefor | |
| EP1494391A1 (fr) | Procédé de configuration automatique d'un routeur d'accès, compatible avec le protocole DHCP, pour effectuer un traitement automatique spécifique des flux IP d'un terminal client | |
| FR2801754A1 (fr) | Methode pour assigner une double adresse ip a un poste de travail relie a un reseau de transmission de donnees ip | |
| EP3588903A1 (fr) | Procédé, dispositif et serveur de distribution sécurisée d'une configuration à un terminal | |
| EP1964359B1 (fr) | Procede et systeme de mise a jour des conditions d'acces d'un dispositif de telecommunication a des services delivres par un reseau de telecommunication | |
| EP1672849B1 (fr) | Procédé d'exploitation d'un réseau informatique local relié à un réseau distant privé par un tunnel IPsec | |
| WO2004086719A2 (fr) | Systeme de transmission de donnees client/serveur securise | |
| WO2007031654A1 (fr) | Procede, passerelle, systeme d'exploitation et systeme de gestion d'entree | |
| FR2843508A1 (fr) | Procede et architecture de communication entre un equipement client et un module intermediaire situes tous les deux sur un reseau local | |
| EP3087719B1 (fr) | Procédé de ralentissement d'une communication dans un réseau | |
| EP1704682B1 (fr) | Systeme de communication entre reseaux ip prives et publics | |
| FR2843847A1 (fr) | Systeme permettant d'etablir une connexion telnet avec un dispositif eloigne depourvu de modem | |
| EP1471713B1 (fr) | Procédé et système de contrôle d'accès à des sites internet au moyen d'un serveur cache | |
| FR2872980A1 (fr) | Procede, dispositif et systeme de protection d'un serveur contre des attaques de deni de service | |
| FR2955727A1 (fr) | Procede securise d'acces a un reseau et reseau ainsi protege | |
| EP1432213A1 (fr) | Plate-forme de médiation et réseau de transport de messages | |
| WO2005091565A1 (fr) | Procede de controle d’acces a un reseau d’un terminal source utilisant un tunnel en mode bloquant | |
| FR2878346A1 (fr) | Procede et systeme de mesure de l'usage d'une application | |
| WO2007074308A1 (fr) | Procede et systeme de connexion a un service |