-
Die
vorliegende Erfindung betrifft ein Datenkommunikationssystem, insbesondere
ein in einem Netzwerkzugriffsserver implementiertes Zugriffsverfahren,
das es Endbenutzern ermöglicht,
auf das Kernnetz zuzugreifen.
-
Der
Rahmen dieser Erfindung betrifft die Art und Weise, in der Einzelpersonen
und Firmen Zugang zu zusammengeschalteten Datenkommunikationsnetzen
gewährt
wird. Zusammengeschaltete Datenkommunikationsnetze bestehen zum
Beispiel aus dem öffentlichen
Internet und einer Vielzahl von durch Dritte betriebenen virtuellen
privaten Netzen (Virtual Private Networks – VPNs). Diese Dritt-VPNs (third
party VPNs) können
Firmennetze, also Intranets, sein, bei denen externer Zugriff scharf
kontrolliert wird, zum Beispiel durch Firewalls. Externer Zugriff
auf ein Dritt-VPN muss jedoch zum Beispiel auf Reisen befindlichen
Mitarbeitern ermöglicht
werden, damit diese mittels Laptops von beliebigen Aufenthaltsorten
oder bei der elektronischen Heimarbeit auf das Intranet zugreifen
können.
Diese Art von externen Zugriffen auf Dritt-VPNs werden üblicherweise durch
einen Zugriffsdienstanbieter, der einen Netzwerkzugriffsserver (Network
Access Server – NAS) hat,
ermöglicht.
-
Solche
VPNs und ihre Realisierung sind beschrieben in Gleeson et al, „RFC 2764:
A framework for IP based virtual private networks", 2.2000, IETF, abgerufen
aus dem Internet am 9.3.04, ftp://ftp.isi.edu/in-notes/rfc2764.txt; XP864260.
-
Mehrere
von Zugriffsdienstanbietern vorgeschlagene Mehrwehrtdienste setzen
voraus, dass ein Endbenutzer, der über einen NAS mit einem Dritt-VPN
in Verbindung steht, ohne Trennung von dem Dritt-VPN gleichzeitig
auf ein lokales Dienstnetz, „lokales
VPN" genannt, zugreifen
kann, das dem NAS zugeordnet ist und üblicherweise von dem Zugriffsdienstanbieter
betrieben wird.
-
Ein
Problem im Zusammenhang mit dieser Art von gleichzeitigem Zugriff
entsteht durch Adressierverfahren. Heterogene zusammengeschaltete Netze
werden durch alle Adressierverfahren harmonisiert, die das Internet-Protokoll (IP) oder
eine seiner Varianten unterstützen. Üblicherweise
und aufgrund der beschränkten
Anzahl von IP-Adressen, die einem Zugriffsdienstanbieter zur Verfügung steht,
verwendet der NAS überlappende
Adresspools für
unterschiedliche VPNs. Infolgedessen kann zwei Benutzern, die über denselben
NAS mit zwei verschiedenen Dritt-VPNs verbunden sind, dieselbe IP-Adresse zugeordnet
sein. Aufgrund der IP-Adresse und der Identität des VPN, aus dem eine Nachricht
gesendet wurde, kann der NAS die beiden Benutzer mit derselben IP-Adresse
eindeutig unterscheiden.
-
Dies
wird problematisch, wenn einer dieser Benutzer gleichzeitig mit
einer identischen weiteren Kommunikationseinrichtung verbunden werden möchte, ohne die
Verbindung mit dem entsprechenden Dritt-VPN auszulösen. Eine
solche Kommunikationseinrichtung kann ein Server sein, der zu einem „lokales
VPN" genannten VPN
gehört,
welches dem NAS zugeordnet ist und sich im Besitz eines Zugriffsdienstanbieters
befindet. In diesem Fall ist der NAS nicht mehr in der Lage, die
beiden Benutzer zu unterscheiden, da beide dieselbe IP-Adresse haben
und Nachrichten aus demselben lokalen VPN erhalten.
-
Ein
verbreitetes Verfahren zur Lösung
dieses Problems besteht darin, im NAS eine Netzadressenumsetzung
(Network Address Translation – NAT) einzuführen. Bei
diesem Lösungsansatz
wird die IP-Adresse des Benutzers im NAS selbst so umgesetzt, dass
für eine
Kommunikation in Richtung des Servers des lokalen VPN jeder Benutzer
eine eindeutige IP-Adresse zu haben scheint. Dieser Lösungsansatz
hat eine Reihe von wichtigen Nachteilen: Erstens führt er zu
einer starken Belastung des NAS, da jedes zwischen dem Benutzer
und dem lokalen VPN fließende
IP-Paket umgesetzt und folglich modifiziert werden muss. Neuere
Varianten des IP-Protokolls, wie z.B. IPsec, basieren darauf, dass
Pakete zwischen den Endpunkten nicht verändert werden sollten, während NAT
sie verändert.
Folglich sind durch diese Lösung
die Protokolle und damit die Dienste, die angeboten werden können, einigen
Beschränkungen
unterworfen.
-
Ein
anderes Verfahren zur Lösung
dieses Problems besteht darin, dem Benutzer mehrere IP-Adressen
zuzuordnen. Je nachdem, ob eine bestimmte Anwendung einem Dritt-VPN
oder den Diensten im lokalen VPN zugeordnet ist, wird die Anwendung
eine andere Adresse zum Senden ihrer Pakete verwenden. Diese Lösung setzt
voraus, dass ein gut gesteuerter Mechanismus vorhanden ist, um für jede Anwendung
vorzugeben, welche IP-Adresse sie zu einem bestimmten Zeitpunkt
zu verwenden hat. Dies ist extrem schwierig zu gewährleisten,
wenn dieselbe Anwendung verwendet wird, um anschließend auf
Dienste in verschiednen VPNs zuzugreifen, z.B. wenn der Benutzer
von einem URL in VPN 1 zu einem URL in VPN 2 browst. Mit anderen
Worten, die Realisierung der Lösung
ist äußerst aufwendig,
da der Zugriffsdienstanbieter typischerweise keine Kontrolle über die
auf dem Benutzerendgerät
ablaufenden Anwendungen und Protokollstapel hat.
-
Eine
besondere Aufgabe der vorliegenden Erfindung besteht darin, ein
Verfahren anzugeben, das für
den Endbenutzer transparent bleibt, da keiner der Endbenutzer sich
um einen Mechanismus zur Unterscheidung mehrerer IP-Adressen zu
kümmern braucht.
-
Eine
weitere Aufgabe der Erfindung besteht darin, ein Verfahren anzugeben,
das den NAS nicht zu sehr überlastet.
-
Diese
und andere, aus dem Folgenden hervorgehende Aufgaben werden durch
ein Verfahren gelöst,
das es einem Benutzer, der in einem NAS als bereits mit einem als
Host-VPN bezeichneten VPN verbunden registriert ist, ermöglicht,
mit mindestens einer nicht zum Host-VPN gehörenden Kommunikationseinrichtung
zu kommunizieren, wobei der NAS über
ein Datenkommunikationsnetz auf die Kommunikationseinrichtung und
eine Vielzahl von VPNs zugreifen kann. Das Verfahren umfasst einen
Schritt, bei dem Nachrichten, die zu einer Kommunikation zwischen
dem Benutzer und der Kommunikationseinrichtung gehören, über einen
logischen Kanal zwischen dem NAS und der Kommunikationseinrichtung übertragen
werden, wobei der logische Kanal durch eine Kennung des Host-VPN
bezeichnet wird.
-
Dieses
Verfahren hat den Vorteil, dass es keine Änderung von IP-Paketen erfordert.
-
Die
vorliegende Erfindung betrifft ferner einen Netzwerkzugriffsserver
nach Anspruch 8.
-
Weitere
Merkmale und Vorteile der Erfindung werden aus der nachfolgenden
Beschreibung einer bevorzugten Realisierung anhand von Beispielen, die
keine Beschränkung
der Erfindung darstellen, und aus den beigefügten Zeichnungen deutlich,
in denen:
-
1 eine
physikalische Architektur von zusammengeschalteten Datenkommunikationsnetzen zeigt,
bei der die vorliegenden Erfindung angewendet werden kann; und
-
2 ein
Ausführungsbeispiel
eines NAS gemäß der vorliegenden
Erfindung zeigt.
-
1 zeigt
eine physikalische Architektur von zusammengeschalteten Datenkommunikationsnetzen,
die mehrere VPNs 151, 152, 153 und Zugangsnetze 121, 122 umfasst,
welche über
ein Kernnetz 14, zum Beispiel das öffentliche Internet oder Mietleitungen,
miteinander verbunden sind.
-
Endbenutzer 111,
..., 114 sind über
die Zugangsnetze 121, 122 mit NASs 131, 132 verbunden. Die
NASs 131, 132 ermöglichen es den Endbenutzern 111,
..., 114, auf das Kernnetz 14 und die zusammengeschalteten
Datenkommunikationsnetze 151, ..., 153 zuzugreifen.
Einige zu den verschiedenen VPNs 151, ..., 153 gehörende Server
sind in der Figur als Beispiel dargestellt. Die Server 161 und 162 gehören zum
VPN 151, der Server 163 gehört zum VPN 152 und
der Server 164 zum VPN 153. Diese Server enthalten
VPN-spezifische Informationen und unterstützen vorzugsweise Funktionen
wie z.B. Authentifizierung und Berechtigungszuweisung.
-
Das
VPN 151 spielt insofern eine privilegierte Rolle, als es
vorzugsweise dem NAS 131 zugeordnet ist und im Folgenden
als „lokales
VPN" bezeichnet wird.
Zum Beispiel befinden sich der NAS sowie das lokale VPN im Besitz
ein und desselben Zugriffsdienstanbieters. Dies ist jedoch für die Erfindung nicht
zwingend. Die VPNs 152 und 153 sind vorzugsweise
Dritt-VPNs, zum Beispiel Firmennetze, also Intranets.
-
Das
lokale VPN 151 kann mit dem Kernnetz 14 in der
in der Figur dargestellten Weise verbunden sein. Alternativ kann
das lokale VPN 151 auch direkt mit dem NAS 131 verbunden
sein. Mehrere unterschiedliche NASs 131, 132 können demselben
lokalen VPN 151 zugeordnet sein.
-
Die
Zugangsnetze 121 und 122 können übliche Fernsprechnetze, wie
PSTN oder ISDN, oder Kabelnetze sowie Funknetze sein.
-
Wenn
die Zugangsnetze 121, 122 übliche Fernsprechnetze sind,
umfassen die NASs 131, 132 analoge Modems zum
Abschluss von analogen PSTN-Verbindungen. Bei einer digitalen ISDN-Verbindung
braucht das Signal nicht demoduliert zu werden. Die NASs 131, 132 umfassen
außerdem
eine Router-Funktion und einen Gateway zum Kernnetz.
-
In
der nachfolgenden Beschreibung wird die Erfindung anhand eines Beispiels
erläutert.
Bei diesem Beispiel wird angenommen, dass der Benutzer 111 mit
dem zum VPN 152 gehörenden
Server 163 kommuniziert. Diese Kommunikation läuft auch über den
NAS 131. Vorzugsweise wird nun eine Situation betrachtet,
in der eine Verbindung zwischen dem Benutzer 111 und dem
VPN 152 sowie zwischen dem Benutzer 112 und dem
VPN 153 aufgebaut ist. Diese Verbindungen sind vorzugsweise
als Point-to-Point-Protokoll-Verbindungen
(PPP-Verbindungen) zwischen den Benutzern 111 bzw. 112 und dem
NAS 131 in Kombination mit geeigneten Leitwegtabelleneinstellungen
im NAS 131 realisiert. Jede andere in einem Zugangsnetz üblicherweise verwendete
Verbindungsart ist ebenfalls möglich.
-
Während eines
Verbindungsaufbaus wird dem Benutzer, der die Verbindung wünscht, für die Dauer
der Verbindung eine IP-Adresse zugewiesen. Außerdem zeigt während des Verbindungsaufbaus jeder
Benutzer 111, 112 dem NAS 131 an, mit
welchem VPN er verbunden werden will.
-
Da
dem NAS 131 üblicherweise
ein begrenzter Pool von IP-Adressen
zur Verfügung
steht, kann eine einzelne IP-Adresse
verschiedenen, zur gleichen Zeit mit dem NAS 131 verbundenen
Benutzern zugeordnet werden, vorausgesetzt, dass die Benutzer mit
unterschiedlichen VPNs verbunden werden wollen. Für diesen
Fall wird der Benutzer durch die IP-Adresse allein nicht eindeutig
identifiziert. Somit wird der Benutzer im NAS nur durch die Zuordnung zwischen
dem VPN, mit dem ein Benutzer verbunden ist, und der IP-Adresse
des Benutzers eindeutig identifiziert. In diesem Beispiel wird angenommen,
dass während
des Verbindungsaufbaus dem Benutzer 111 und dem Benutzer 112 vom
NAS 131 dieselbe IP-Adresse zugewiesen wird. Dies entspricht
der obigen Darstellung, denn beide möchten mit unterschiedlichen
VPNs verbunden werden.
-
Während des
Verbindungsaufbaus füllt
der NAS 131 eine Tabelle mit Informationen über Verbindungen,
die zwischen den an NAS 131 angeschlossenen Benutzern 111, 112 und
den VPNs 152, 153 herzustellen sind. Diese Informationen
bleiben in der Tabelle für
die gesamte Dauer einer Verbindung gespeichert. Ein Eintrag dieser
Tabelle umfasst vorzugsweise eine für das Zugangsnetz 121 spezifische Benutzeridentifikation
(z.B. eine Rufnummer), die dem Benutzer zugeordnete IP-Adresse und
eine VPN-Kennung,
die angibt, mit welchem VPN der Benutzer aktuell verbunden ist.
-
Angenommen,
der Benutzer 111 möchte
parallel zu den bereits aufgebauten Verbindungen gleichzeitig mit
dem im lokalen VPN 151 angeordneten Server 161 kommunizieren,
ohne seine Verbindung mit dem VPN 152 auszulösen. Eine
für den
Server 161 bestimmte Nachricht, welche die Quelladresse
des Benutzers 111 und die Ziel-IP-Adresse des Servers 161 enthält, wird
an den NAS 131 gesandt. Der NAS 131 erkennt, dass,
obwohl der Benutzer 111 bereits mit dem VPN 152 verbunden
ist, die die Ziel-IP-Adresse des Servers 161 enthaltende
Nachricht an das VPN 151 weiterzuleiten ist.
-
Angenommen,
der Server 161 beantwortet diese Nachricht mit einer an
den Benutzer 111 gerichteten Antwortnachricht, dann würde er eine
IP Nachricht erstellen, die als Zieladresse die in der empfangenen
Nachricht festgestellte IP-Adresse des Benutzers 111 enthält. Nach
Empfang dieser Antwortnachricht ist der NAS 131 nicht in
der Lage, eindeutig zu identifizieren, dass diese Antwortnachricht
für den Benutzer 111 bestimmt
ist, da der Benutzer 112 dieselbe IP-Adresse hat.
-
Erfindungsgemäß wird,
sobald der NAS 131 erkennt, dass eine Nachricht für einen
Server 161 bestimmt ist, der nicht zu dem VPN 152 gehört, in Bezug
auf welches der Benutzer 111 als bereits verbunden registriert
ist, die Nachricht auf einen logischen Kanal geleitet, der als Kanalkennung
die Kennung des VPN 152 aufweist, bezüglich dessen der Benutzer 11 als
bereits verbunden registriert ist.
-
Das
Prinzip der logischen Kanäle
ist dem Fachmann für
sich bekannt und wird mittels mehrerer Verfahren realisiert.
-
Die
Realisierung eines logischen Kanals zwischen dem NAS 131 und
dem VPN 152 kann zum Beispiel mittels Kapselung erfolgen.
Der NAS 131 muss dabei jede für den Server 161 bestimmte
Nachricht in einem Packet einkapseln, dessen Header-Teil eine Kennung
des VPN enthält,
bezüglich
dessen der Benutzer als bereits verbunden registriert ist. Eine „Tunneling" genannte Sonderform
der Kapselung kann ebenfalls verwendet werden. Ein Prinzip des Tunneling
besteht darin, Protokolldaten, die einer bestimmten Schicht im OSI-Kommunikationsmodell entsprechen,
in anderen Protokolldaten einzukapseln, die derselben Schicht im
OSI-Kommunikationsmodell entsprechen. Dies ist vorteilhaft in heterogenen
Netzen für
Geheimhaltungs- und Sicherheitsangelegenheiten.
-
Wenn
der Server 161 eine Nachricht zu beantworten hat, die vom
Benutzer 111 gesendet und über einen logischen Kanal mit
einer der Kennung des VPN 152 entsprechenden Kanalkennung
empfangen wurde, sendet er eine Antwortnachricht über denselben
logischen Kanal zurück.
Nach Empfang der Antwortnachricht im NAS 131 identifiziert
Letzterer die Kennung des logischen Kanals, auf dem die Nachricht
empfangen wurde, und koppelt die Nachricht aus dem logischen Kanal
aus. Der NAS 131 kann eindeutig identifizieren, für welchen
Benutzer die Antwortnachricht bestimmt ist, da er auf die in der Antwortnachricht
enthaltene IP-Adresse sowie auf die Kennung des VPN, mit dem der
Benutzer bereits verbunden ist, zugreifen kann. Mit diesem Informationspaar
ist der NAS in der Lage, den Benutzer 111 eindeutig zu
identifizieren.
-
Ein
Vorteil dieses Verfahrens besteht darin, dass es für die Endbenutzer
transparent ist.
-
2 zeigt
ein Ausführungsbeispiel
eines NAS gemäß der vorliegenden
Erfindung. Der NAS 20 enthält eine Weiterleitungsmaschine 21,
eine logische Kanalsteuerung 22, ein Routing-Teil 23 und
eine Tabelle 24. Ferner umfasst er drei Schnittstellen:
eine erste Schnittstelle 201 für den Zugang zum Netz und zu
Benutzern, eine zweite Schnittstelle 202 zu einem lokalen
VPN (lokales VPN 151 in 1) und eine dritte
Schnittstelle 203 zu Dritt-VPNs (VPNs 152 und 153 in 1).
-
Die
erste Schnittstelle 201 ist mit der Weiterleitungsmaschine 21 verbunden,
die wiederum an die logische Kanalsteuerung 22 und an das
Routing-Teil 23 angeschlossen ist. Die logische Kanalsteuerung 22 ist
mit der zweiten Schnittstelle 202 und das Routing-Teil
mit der dritten Schnittstelle 203 verbunden. Die logische
Kanalsteuerung 22 sowie das Routing-Teil 23 haben
Zugriff auf die Tabelle 24. Die Tabelle 24 ist
eine Datenbank mit Einträgen,
welche die bereits aufgebauten Verbindungen zwischen einem Benutzer
und einem Dritt-VPN registrieren. Jeder Eintrag umfasst eine Benutzeridentifikation,
die spezifisch für
das Zugangsnetz ist, mit dem dieser Benutzer verbunden ist, die
IP-Adresse dieses Benutzers und eine Kennung des Dritt-VPN, mit
dem der Benutzer verbunden ist. Es können auch andere Informationen
in jedem Eintrag enthalten sein.
-
Nach
Empfang einer Nachricht in der ersten Schnittstelle 201 prüft die Weiterleitungsmaschine 21,
ob diese Nachricht für
das lokale VPN oder für
ein Dritt-VPN, mit dem der Benutzer bereits verbunden ist, bestimmt
ist. Diese Prüfung
erfolgt durch Auswertung der in der Nachricht enthaltenen Ziel-IP-Adresse.
-
Ist
die Nachricht für
ein Dritt-VPN bestimmt, wird sie transparent zum Routing-Teil 23 weitergeleitet
und über
die dritte Schnittstelle 203 übertragen.
-
Ist
die Nachricht für
das lokale VPN bestimmt, wird sie zur logischen Kanalsteuerung 22 weitergeleitet.
Die logische Kanalsteuerung 22 überprüft die in der Nachricht enthaltene
Quell-IP-Adresse und sucht in der Tabelle 24, ob dieser
Benutzer bereits mit einem Dritt-VPN verbunden ist. Ist dies der
Fall, dann koppelt sie die Kennung des Dritt-VPN aus, mit dem der
Benutzer bereits verbunden ist. Dann leitet die logische Kanalsteuerung 22 die
Nachricht auf einen logischen Kanal, der als Kanalkennung die Kennung
des Dritt-VPN oder eine daraus eindeutig abgeleitete Kennung aufweist.
Wenn der Benutzer nicht mit einem VPN verbunden ist, wird eine vorgegebene
reservierte logische Kanalkennung zum Senden der Nachricht an das
lokale VPN verwendet.
-
Nach
Empfang einer Nachricht in der zweiten Schnittstelle 202 ist
die logische Kanalsteuerung 22 dafür zuständig festzustellen, ob und
mit welcher VPN der Benutzer, für
den diese Nachricht bestimmt ist, bereits verbunden ist. Zu diesem
Zweck koppelt die logische Kanalsteuerung 22 die Kennung
des logischen Kanal aus, auf dem die Nachricht über die Schnittstelle 202 empfangen
wurde. Die VPN-Kennung kann mit der Kennung des logischen Kanals identisch
sein oder mittels einer Zuordnungstabelle (in 2 nicht
dargestellt) eindeutig daraus abgeleitet werden.
-
Die
logische Kanalsteuerung 22 koppelt außerdem die in der Nachricht
enthaltene Ziel-IP-Adresse aus. Dann sucht sie in der Tabelle 24 den
der IP-Adresse entsprechenden Benutzer und die VPN-Kennung. Damit
ist der Benutzer, zu dem die Nachricht zu übertragen ist, eindeutig identifiziert. Dann
wird die Nachricht zur Weiterleitungsmaschine 21 übertragen,
die sie über
die erste Schnittstelle 201 an den identifizierten Benutzer
sendet.
-
Alternativ
zu dem oben beschriebenen Ausführungsbeispiel
kann die Tabelle 24 nicht im NAS 20 enthalten
sein. Die Tabelle 24 kann selbständig und für den NAS 20, aber
auch für
andere, außerhalb
des NAS angeordnete Module, insbesondere für in einem Server im lokalen
VPN angeordnete Module, zugreifbar sein. Die Tabelle 24 kann
auch von verschiedenen NASs gemeinsam genutzt werden.
-
Gemäß einem
weiteren Ausführungsbeispiel der
Erfindung ist es vorstellbar, dass zwei getrennte NASs den Empfang
einer Nachricht in der ersten Schnittstelle 201 und den
Empfang einer Nachricht in der zweiten Schnittstelle 202 getrennt
behandeln.