-
Vorliegende
Erfindung betrifft Computersysteme, insbesondere virtuelle private
Netzwerke (VPNs) und insbesondere eine elastische Implementation
eines VPN.
-
Eine
VPN ist eine Verbindung zwischen zwei Standorten, die das Aussehen
einer zweckbestimmten Verknüpfung
hat, die bei einem zeitanteiligen Netzwerk auftritt, wie z.B. dem
Internet oder einer direkten RAS (Fern-Zugriffs-Service) Einwähl-Verbindung.
Verwendet man eine Technik, die als „Tunneltechnik" bekannt ist, werden
Datenpakete über
das zeitanteilige Netzwerk in einen privaten „Tunnel" zwischen den Standorten übertragen.
Die Tunneltechnik ist die Einkapselung eines Datenpaketes, z.B.
eines IP- (Internet-Protokoll) Paketes innerhalb eines anderen IP-Paketes,
nachdem das Datenpaket verschlüsselt
worden ist. Das äußere Paket
hat eine andere Bestimmungs-IP-Adresse als das innere Paket und
wird verwendet, um das innere verschlüsselte Paket an einen VPN-Sicherheits-Zugang
an einem Standort zu richten, wo die äußere Schicht abgenommen, das
innere Paket entschlüsselt
und an die entsprechende einer Anzahl von Bestimmungen innerhalb
des Standortes gesendet werden kann. Wenn der Zugang fehlerhaft
ist, ist keine Verbindung zu diesen Bestimmungen möglich.
-
K.
K. Varguese Panicker et al „An
improved scheme for self-healing in ATM networks" aus Computer Communications, Elsevier
Science Publishers BV, Amsterdam NL, Band 22, Nr. 15–16 vom
25. September 1999 (25.09.1999), Seiten 1400–1414 beschreiben in selbst
heilendes Netzwerk, das Fehler, z.B. Verknüpfungs/Knoten-Fehler detektieren
und die fehlerhaften Verbindungen automatisch unter Verwendung verteilter Steuermechanismen
umleiten kann. Es wird ein Schema zum Selbstheilen in ATM- Netzwerken angeboten, das
auf dem Konzept von Reserve-Virtual-Pfaden (VPs) basiert. Ein Virtual-Pfad
ist eine logische Verbindung zwischen zwei Knoten.
-
Aufgabe
der Erfindung ist, eine Anordnung vorzuschlagen, die sicher stellt,
dass ein vollständiger
oder teilweiser Fehler eines Zugangs (z.B. ein Fehler eines von
zwei oder von beiden Schnittstellen auf die angeschlossenen Netzwerke)
nicht zum Fehlen einer Verbindung führt.
-
Nach
einem Aspekt der Erfindung wird ein Computersystem vorgeschlagen
mit einem ersten Knoten, der mit einem zweiten Knoten über einen
einer Vielzahl von dritten Knoten verbindbar ist, mit Datenverbindungen
zwischen dem ersten Knoten und dem entsprechenden dritten Knoten,
die verschlüsselt
sind, mit einer Vorrichtung zum Auswählen eines dritten Knotens
und zum Herstellen einer verschlüsselten
Verbindung zwischen dem ersten Knoten und dem ausgewählten dritten
Knoten, mit einer Vorrichtung zum Detektieren eines anschließenden Fehlers
des ausgewählten
dritten Knotens, und mit einer Vorrichtung zum Auswählen eines weiteren
dritten Knotens sowie zum Herstellen einer verschlüsselten
Verbindung zwischen dem ersten Knoten und dem anderen ausgewählten dritten
Knoten, wobei der erste Knoten und die Vielzahl von dritten Knoten
ein virtuelles privates Netzwerk darstellen, in welchem Datenverbindungen
zwischen dem ersten Knoten und jedem der dritten Knoten mit einem
entsprechenden Nachrichten-Verschlüsselungs-Code verschlüsselt sind,
der nach einem entsprechenden Authentisierungs-Prozess aufgebaut
wird, wobei die Vorrichtung zum Auswählen des dritten Knotens einen
Code-Management-Service umfasst, der einen dritten Knoten aus der
Vielzahl auswählt
und der versucht, den entsprechenden Authentisierungsprozess damit
bei einer Anfrage durch den ersten Knoten für einen entsprechenden Nachrichten-Verschlüsselungs-Code
auszuführen,
und wobei bei einer erfolgreichen Authentisierung der erste Knoten
und der ausgewählte
dritte Knoten den entsprechenden Nachrichten-Verschlüsselungs-Code
pufferspeichern.
-
Nach
einem weiteren Aspekt der Erfindung wird ein Verfahren zum Detektieren
eines Knotenfehlers und zum Verbinden mit einem anderen Knoten in
einem Computersystem vorgeschlagen, bei dem ein erster Knoten mit
einem zweiten Knoten über
einen einer Vielzahl von dritten Knoten verbunden wird, Datenverbindungen
zwischen dem ersten Knoten und dem einen der dritten Knoten verschlüsselt werden,
wobei das Verfahren zum Detektieren eines Fehlers des einen der
dritten Knoten nach dem Authentisieren und dem Verbinden des ersten
Knotens damit sowie zum Herstellen einer Verbindung des ersten Knotens
mit einem anderen der dritten Knoten und zum Durchführen von
Schritten angewendet wird, bei denen der erste Knoten ein Fehler-Detektionssignal
an den einen dritten Knoten zu einem vorbestimmen Zeitpunkt sendet,
wobei dann, wenn der eine dritte Knoten in Betrieb ist, er eine
Antwort auf das Fehler-Detektionssignal zum ersten Knoten sendet, und
falls keine Antwort innerhalb eines vorbestimmten Zeitintervalls
aufgenommen wird, der erste Knoten entweder eine Verbindung mit
einem anderen der dritten Knoten, der vorher authentisiert war,
herstellt oder versucht, einen anderen der dritten Knoten zu authentisieren
und mit ihm eine Verbindung herzustellen, und wobei der erste Knoten
und die Vielzahl von dritten Knoten ein virtuelles privates Netzwerk
bilden, in welchem Datenverbindungen zwischen dem ersten Knoten
und jedem der dritten Knoten mit einem entsprechenden Nachrichten-Verschlüsselungs-Code
verschlüsselt
werden, und wobei ein entsprechender Nachrichten-Verschlüsselungs-Code
nach jeder Authentisierung aufgebaut wird.
-
Ausführungsformen
der Erfindung werden nachstehend in Verbindung mit den Zeichnungen
beschrieben, in denen
-
1 eine
beispielhafte Ausführungsform
eines herkömmlichen
VPN-Netzwerkes, und
-
2 schematisch
eine Ausführungsform
nach vorliegender Erfindung zeigt.
-
In 1 sind
zwei Computer (Knoten) 1, 2 über eine Datenverbindung 3 miteinander
verbunden, die beispielsweise aus einer direkten RAS-Einwähl-Verbindung
oder dem Internet besteht. Die Computer 1 und 2 sind
mit einer entsprechenden VPN-Software 1a, 2a versehen,
damit ein Informationsaustausch dazwischen über die Verknüpfung 3 verschlüsselt werden;
die Computer 1, 2 und die Verknüpfung 3 können als
ein verschlüsseltes
Netzwerk miteinander bildend angesehen werden. Der Computer 2 ist über ein
LAN 4 (LAN = lokales Bereichsnetzwerk) mit drei Computern
(Knoten) 5, 6 und 7 verbunden, die Personalcomputer
(PC) sein können.
Der Datenaustausch zwischen den Computern 2, 5, 6 und 7 über das
LAN 4 sind nicht verschlüsselt. In den 1 und 2 ist
eine verschlüsselte
Datenverbindung durch eine stärker
ausgezogene Linie als die nicht verschlüsselte Datenverbindung dargestellt.
Der Computer 2 weist einen Zugangs-Server auf, der die verschlüsselten
und die nicht verschlüsselten
Netzwerke miteinander koppelt. Die Computer 5, 6 und 7,
die als Ziel-Maschinen
bezeichnet werden können,
haben jeweils eine entsprechende IP-Adresse, die in der Zeichnung
mit 10.0.0.1, 10.0.0.2 und 10.0.0.3 bezeichnet sind. Der Computer 1,
der ein Notebook-Computer sein kann, und der als Kunde bezeichnet
wird, hat eine IP-Adresse, die in der Zeichnung mit 100.0.0.1 bezeichnet ist,
während
der Zugangs-Server 2 eine IP-Adresse hat, die in der Zeichnung
mit 200.0.0.254 angegeben ist. Die Strategie-Datei 1b des
Kunden 1 weist eine Tunnel-Einstellung auf, die für den Zugangs-Server 2 angibt, welche
Zielmaschinen bzw. ihre IP-Adressen hinter dem Zugang-Server 2 angeordnet
sind. Die Strategie-Datei kann ferner Tunnel-Einstellungen für andere Zugangs-Server/Ziel-Maschinen
umfassen. Die Tunnel-Einstellung
für die
dargestellte Anordnung ist so wie in der Zeichnung (Tunnel 1)
angegeben. Die Anordnung nach 1 kann das
Software-Produkt, das mit SafeGuard VPN von Utimaco Safeware AG
bezeichnet ist, verwenden, um die Datenübertragung zu verschlüsseln. Im
Falle der Verwendung von SafeGuard VPN und wenn die Tunnel-Einstellung angewendet
wird, wird die GSS (Generic Security Services) Codeaustausch zwischen
dem Kunden 1 und dem Zugang 2 anstelle zwischen
dem Kunden 1 und einer der Target-Maschinen 5, 6, 7 verwendet.
Der Kunde und der Server besitzen IP-Filter 1c, 2c zum
Extrahieren von Daten, die für
sie bestimmt sind, oder im Falle eines Zugangs-Servers für jede Target
IP-Adresse dahinter, z.B. 10.0.0.1 bis 10.0.0.3. In dem IP-Filter
für jede
Target-Adresse hinter dem Zugang 2 wird ein Dialog-Code
für diesen
Zugang zum Verschlüsseln
verwendet. Dieser Dialog-Code wird in Cache-Speichern 1d und 2d gespeichert.
-
Falls
Daten von der Kunden-Maschine 1 zur Ziel-Maschine 5 gesendet
werden sollen, wird ein Datenpaket mit einer Sender-Adresse 100.0.0.1
und einer Empfänger-Adresse
10.0.0.1 an der Kunden-Maschine 1 verschlüsselt und
in ein anderes Paket mit der Sender-Adresse 100.0.0.1, aber einer
Empfänger-Adresse 200.0.0.254
an den Zugangs-Server 2 übertragen,
wobei die Außenlage
entfernt wird, während
das innere Paket entschlüsselt
und an eine Ziel-Maschine 5 unverschlüsselt gesendet wird.
-
Es
ist nur ein Zugang für
einen gegebenen Bereich von IP-Adressen, z.B. Ziel-Maschinen spezifiziert. Wenn
somit der Zugang 2 fehlerhaft wird, ist keine weitere Datenverbindung
mit dem LAN 4 hinter dem Zugang 2 möglich, es
sei denn, dass ein zweiter Zugang (nicht dargestellt) installiert
ist, und die Verfahrensweise der Kunden-Maschine entsprechend rekonfiguriert
wird.
-
Falls
ein zweiter Zugang verfügbar
ist, muss der Kunde 1 in der Lage sein, einen neuen Pfad
hinter den Zugängen
mit Durchlaufzeit zu finden, ohne dass eine manuelle Rekonfiguration
erforderlich wird. Es gibt zwei Punkte, die beachtet werden müssen, um
ein Fehler-Toleranzsystem zu erzielen. Als erstes muss der vollständige GSS-Code-Austausch und der
Dialog-Code-Aufbau mit ein und demselben Zugang erfolgen, es kann nicht
mit dem einen begonnen und mit dem anderen geendet werden, und während es
verhältnismäßig einfach ist,
eine Liste von Zugängen
in der Strategiedatei 1b des Kunden zu spezifizieren, die
einer nach dem anderen durchprobiert werden müssen, solange bis ein erfolgreicher
Dialog-Code-Aufbau erzielt worden ist, muss ein Fehler eines Zugangs
in irgendeiner Weise detektiert werden, nachdem ein Dialog bereits
aufgebaut worden ist.
-
Vorliegende
Erfindung verwendet eine erneute Authentisierung, um eine Zugangs-Fehler-Toleranz zu erreichen.
Mehr als ein Zugang (Knoten) wird für einen gegebenen Bereich von
IP-Adressen definiert. Dies wird als ein Zugangs-Cluster bezeichnet.
In 2 ist ein solches Cluster aus drei Zugängen (Knoten) 21, 22, 23 dargestellt.
Wenn eine Dialog-Code-Anfrage durch den Kunden 1 für eine IP-Adresse
in diesem gegebenen Bereich ausgegeben worden ist, wählt eine
Vorrichtung, z.B. ein Code-Management-Service KMS 8 willkürlich einen
Zugang aus dem Cluster, z.B. 21, und versucht eine Authentisierung,
z.B. mit Hilfe der Herstellung einer Verbindung zu dem gewählten Zugang
und der Durchführung
eines Code-Aufbau-Protokoll-Austausches. Schlägt die Authentisierung fehl,
wird sie mit dem nächsten
spezifizierten Zugang, z.B. 22, in einem Rundum-Betrieb
versucht. Schlägt
eine Authentisierung bei allen Zugängen 21– 23 fehl,
wird die Code-Anfrage zurückgewiesen.
-
Ist
jedoch eine Authentisierung erfolgreich verlaufen, wird der Dialog-Code,
der für
diesen Zugang, z.B. 21 generiert worden ist, zum Kunden-IP-Filter 1c zurückgeführt und
sowohl bei dem Kunden als auch am Zugang in Cache-Speichern 21d, 1d gespeichert,
wodurch die Daten zwischen dem Kunden und dem Zugang und bei beiden
verschlüsselt/entschlüsselt übertragen
werden können.
Ein unterschiedlicher Dialog-Code wird jedem Zugang zugeordnet,
so dass dann, wenn Daten von dem Kunden 1 zur Ziel-Maschine 5 über den
Zugangs-Server 21 gesendet werden, jedoch eine Antwort
von der Ziel-Maschine 5 zum Kunden 1 über einen unterschiedlichen
Zugangs-Server 22 läuft,
ein neuer Dialog und ein anderer Dialog-Code notwendig ist, um die
Zugangs/Kunden-Verbindung aufzubauen.
-
Um
den Fehler eines Zugangs, z.B. 21 im Anschluss an den Aufbau
eines Dialogs für
die spezielle Zugangs-Verbindung zum Kunden 1 (Kunde 1/Zugang 21)
zu detektieren, überträgt das Filter 1c des
Kunden IP ein Fehler-Detektionssignal, die sogenannten „Heartbeat"- (Herzschlag-)-Pakete
an den Zugang 21 oder das Filter 21c des Zugangs
IP überträgt, das
erforderlich ist, um mit einer Antwort darauf anzusprechen. Wenn eine
Antwort auf ein solches Paket an dem Filter 1c des Kunden
IP innerhalb einer vorbestimmten Zeitdauer, z.B. n Sekunden, die
einstellbar ist, nicht ankommt, wird ein zweites Fehler-Detektionssignal
an das Filter 1c des Kunden IP gesendet. Wenn immer noch
keine Antwort eingeht, sucht das Filter 1c des Kunden IP,
um festzustellen, ob bereits ein Dialog-Code für einen anderen Zugang im Cluster
aufgebaut worden ist, zu dem der fehlerhafte Zugang gehört. Wenn
ein solcher Code für
einen anderen Zugang bereits aufgebaut ist, macht das Filter 1c des
Kunden IP automatisch Gebrauch von diesem anderen Zugang, z.B. 22,
anstatt des fehlerhaften Zugangs. Der Dialog-Code des fehlerhaften
Zugangs 21 wird von dem Cache-Speicher 1d beim
Kunden 1 entfernt. Wenn kein derartiger aufgebauter Code
für einen
anderen Zugang in dem Cluster vorhanden ist, gibt das Filter 1c des
Kunden IP eine Code-Anfrage an den Code-Management-Service 8 für einen
anderen Zugang im Cluster. Wenn diese Code-Anfrage fehlerhaft ist, der Code-Management-Service
jedoch in dem Authentisierungs-Prozess
mit einem anderen Zugang im Cluster erfolgreich ist, setzt er einfach
den geeigneten Code, und das Filter 1c des Kunden IP benutzt
ihn von da an.
-
Um
die Arbeitsbelastung für
den Zugang zu verringern, werden die „Heartbeat"-Nachrichten
nur gesendet, wenn ein Dialog-Code aufgebaut worden ist, jedoch
kein Paket aus dem Zugang während
der letzten n Sekunden empfangen worden ist. Solange Pakete von
dem Zugang innerhalb des obigen Zeitintervalls aufgenommen werden,
wird der Zugang als in Betrieb befindlich angesehen. Wenn das Filter
des Kunden IP Dialog-Codes über
mehr als einen Zugang in einem Cluster aufgebaut hat, werden Heartbeat-Nachrichten
nur an den Zugang gesendet, der für Kommunikationen verwendet
wird, die von dem Kunden stammen.
-
Eine
weitere Reduzierung der Arbeitsbelastung, insbesondere für RAS-Umgebungen,
kann dadurch erreicht werden, dass der Heartbeat als „verzögert" konfiguriert wird,
d.h. das Aussenden des Heartbeat-Paketes auf der Kundenseite wird
verzögert,
bis der Kunde IP (Nutzlast) Pakete an den jeweiligen Zugang ohnehin
zu senden hat. Dieses Verhalten verhindert das Herstellen aller
unnötigen
Verbindungen zwischen dem Kunden und dem Zugang in früheren Leerlaufzeiten.
Im Falle eines Fehlers des entsprechenden Zugangs geht jedoch eine
bestimmte Anzahl von IP-Nutzlast-Paketen verloren, und eine Wiederherstellung
der Verbindung nimmt mehr Zeit in Anspruch als sonst notwendig wäre. Beide
Heartbeat-Betriebsarten, sofortige und verzögerte, sind durch eine Einstellung
in der Strategie-Datei 1b des Kunden konfigurierbar.
-
Heartbeat-Nachrichten
werden in gleicher Weise eingeschlossen wie eine normale Kommunikation gestaltet
wird. Dies ist erforderlich, damit die Pakete über die gleiche Route geliefert
werden können,
z.B. über einen
Feuerwall, der so gestaltet ist, dass er nur verschlüsselte Pakete
durchlässt.
In dem speziellen Fall, bei dem die „Tunnels" nach RFC1827 kreiert werden und dann
mindestens ein ESP (Einkapselungs-Sicherheits-Nutzlast) in jeder Betriebsart
verwendet wird, wird das Heartbeat-Paket dadurch detektiert, dass
ein SPI (Sicherheits-Parameter-Index) von Ox FFF FFFFF angewendet
wird. Das Zugangs-IP-Filter spricht auf jedes Paket an, das einen
solchen SPI mit einem gleichen Paket in entgegengesetzter Richtung
enthält.
Das Paket wird nie entschlüsselt
und enthält
keine brauchbaren Information. Der SPI wird einfach bewertet.
-
Diese
Lösung
verursacht eine Menge an erneuter Authentisierung an den verbleibenden
Zugängen, wenn
einer fehlerhaft ist. Zur Verteilung der Authentisierungs-Belastung
im Falle eines Fehlers verteilt der Code-Management-Service KMS 8 die
Reihenfolge der spezifizierten Cluster-Zugänge wahllos jedesmal, wenn er
ihn aus der Strategie-Datei 1b ausliest
und bevor er ihn in den Kunden-IP-Filter 1c leitet. Der
Kunden-Filter 1c selbst sucht die Zugänge in einem Cluster in sequentieller
Reihenfolge durch.
-
Diese
wahllose Verteilung bewirkt eine verteilte Belastung an den Zugängen, selbst
wenn alle Kunden, die in einer bestimmten VPN miteinander verbindbar
sind, zufällig
identische Strategien haben. Die wahllose Verteilung der Cluster-Mitglieder
kann über
eine Strategie-Datei-Einstellung abgeschaltet werden, und zwar in solchen
Fällen,
in denen eine spezifische Reihenfolge erwünscht ist, z.B. Hauptsysteme
mit hoher Leistung und Reservesysteme mit geringer Leistung.
-
Wenn
ein schadhafter Zugang neu aktiviert wird, wird er automatisch verwendet,
sobald ein Kunde eine Authentisierung einleitet und diesen Zugang
ausprobiert, weil er der nächste
auf der Liste ist. Wenn andererseits eine Kommunikation aus dem
Zugang begonnen wird, wird ein neuer Dialog-Code mit dem Kunden aufgebaut,
und damit erreicht, dass der Kunde diesen Zugang wieder verwenden
kann. Wenn insbesondere der reaktivierte Zugang der bevorzugte Zugang
des Kunden ist, beginnt der Kunde den Zugang zu verwenden, sobald
der Dialog-Code mit dem Zugang aufgebaut worden ist.
-
Nachstehend
werden einige Aspekte der vorbeschriebenen Methoden im einzelnen
erläutert.
Die VBN-Software, die bei den Kunden, z.B. 1, und Zugängen, z.B. 21, 22, 23 (2),
wie mit 1a, 21a, 22a, 23a angegeben,
betrieben wird, ermöglicht
es, eine einzelne Tunneladresse für eine einzige IP-Adresse oder
einen Bereich von Adressen zu spezifizieren. Andererseits kann anstelle
einer Tunnel-Adresse ein Cluster für eine einzelne IP-Adresse
oder einen Bereich von IP-Adressen definiert werden. Ein bezeichnetes
Cluster ist in der Strategie innerhalb eines zusätzlichen Abschnittes, der mit
CLUSTER bezeichnet ist, definiert. Es wird ein neues Statement angegeben,
das aus einem neuen Codewort (mit „Cluster" bezeichnet) und einer oder mehreren IP-Adressen besteht,
die durch mindestens eine Leerstelle voneinander getrennt sind.
-
Beispielsweise
-
[CLUSTER]
-
- Cluster 1 = 143.1.0.64 143.1.1.157
- Cluster 2 = 143.1.0.63 143.1.0.65 143.1.0.66
-
Die
unterstützte
Syntax eines Policen-Eintrags in dem neuen „CLUSTER" Abschnitt muss in dem folgenden Format
geschrieben werden:
'Cluster' <nr> '=' <IP
address> ['' <IP
address>]
-
Wenn
ein Kommunikations-Partner (Ziel) hinter einem Zugangs-Cluster positioniert
ist, der die aktuelle Authentisierung und/oder Verschlüsselungs/Entschlüsselungs-Aufgaben
durchführt,
muss der Code-Management-Service-Prozess die Adressen eines möglichen
Tunnels des Zugang-Clusters kennen. Wenn nur ein Zugang vorhanden
ist, kann ein Tunnel-Eintritt in der üblichen Weise spezifiziert
werden, obgleich ein Cluster definiert und dann dem Tunnel-Zugang
hinzuaddiert werden kann; wenn jedoch zwei oder mehr Zugänge vorhanden
sind, muss das Cluster definiert werden und das entsprechende Cluster
dem Tunnel-Eintritt anstelle einer einzigen Tunnel-Adresse hinzuaddiert
werden.
-
Die
Syntax für
einen einzelnen Tunnel-Eintritt ist wie folgt:
'Tunnel' <nr> '=' <start
address> ['-' <end
address>]''(<tunnel
address>) 'Cluster' <nr>/'AUTO')
-
Das
folgende Beispiel von möglichen
Strategie-Datei-Einträgen
unter Verwendung der vorstehenden Beispiele stellt die Syntax klar.
-
[TUNNEL]
-
- Tunnel 1 = 143.1.0.24–143.1.0.30
Cluster 1
-
(Dies
bedeutet, dass von der IP-Adresse 143.1.0.24 zu der IP-Adresse 143.1.0.30
jede IP-Adresse durch das Cluster 1 nach der Tunnel-Methode aufgegeben
wird, so dass entweder der Zugang 143.1.0.64 oder der Zugang 143.1.1.157
verwendet wird, um die tatsächliche
Authentisierung und/oder Verschlüsselungs-Entschlüsselungs-Aufgaben
durchzuführen.
Tunnel
2 = 143.1.0.24–143.1.0.30
143.1.1.160
-
(Dies
ist auch ein gültiger
Eintrag, der bedeutet, dass der Zugang 143.11.160 verwendet wird,
um die tatsächliche
Authentisierung und/oder Verschlüsselungs/Entschlüsselungs-Aufgaben
durchzuführen.
-
Eine
automatisch detektierte RAS-Server-Adresse kann an eine Adresse
oder ein Zugangs-Cluster durch den folgenden Eintrag in dem Tunnel-Abschnitt
umgeleitet werden:
'Redirect
Tunnel' <nr> '=' <server address>'' (<tunnel-address>/Cluster' <nr>)
-
Um
die Arbeitsbelastung zu verteilen, verteilt der Code-Management-Service
die Reihenfolge der spezifizierten Zugangs-Adressen für alle Tunnel-Eingänge wahllos
und zwar jedesmal, wenn er den Service aus der Strategie-Datei abliest
und bevor er ihn an den Kunden-IP-Filter leitet.
-
Um
den Fehler eines Zugangs festzustellen, sendet das Kunden-IP-Filter „Heartbeat" Pakete an den Zugang
als Antwort durch das Zugangs-IP-Filter. Wenn die Antwort auf ein
solches Paket nicht innerhalb von n Sekunden ankommt, wird ein zweites
Paket gesendet. Um diese „Ansprechzeit" zu konfigurieren,
ist ein Statement in dem GENERAL – Abschnitt der Strategie-Datei
erforderlich:
'Heartbeat
Ansprechzeit '=' <Anzahl von Sekunden>
-
Wenn
ein solcher Eintrag nicht vorhanden ist, wird der Standardwert des
Kunden-IP-Filters
verwendet.
-
Um
die Arbeitsbelastung für
den Zugang zu verringern, werden „Heartbeat"-Nachrichten
nur gesendet, wenn ein Dialog-Schlüssel aufgebaut worden ist und
kein Paket aus dem Zugang während
der letzten n Sekunden empfangen worden ist. Solange Pakete von
dem Zugang innerhalb des obigen Zeitintervalls empfangen werden,
wird der Zugang als im Betrieb befindlich angesehen. Wenn das Kundenfilter
Dialog-Schlüssel aufweist,
die für
mehr als einen Zugang in einem Cluster errichtet worden sind, werden
Heartbeat-Nachrichten nur an den Zugang gesendet, der für Kommunikationen
verwendet wird, die von dem Kunden stammen. Um diese Funktionalität zu stützen, wird
ein weiterer Eintrag in den GENERAL-Abschnitt der Strategie-Datei
eingeführt.
'Heartbeat Verzögerungszeit''=' <Anzahl von Sekunden>
-
Wenn
kein solcher Eintrag vorhanden ist, wird der Standardwert des Kunden-IP-Filters
verwendet.
-
Um
die Heartbeat-Funktionalität
unwirksam zu machen, wird ein weiterer neuer Strategie-Datei-Eintrag
in den GENERAL-Abschnitt erforderlich: 'Heartbeat' '=' (NEIN/VERZÖGERT/SOFORT)
| Heartbeat
= NEIN | sperrt
die Heartbeat-Funktionalität,
d.h. dass keine Heartbeat-Pakete gesendet werden. |
| Heartbeat
= VERZÖGERT | verzögert das
Absenden von Heartbeat-Paketen an die Kundenseite solange, bis der
Kunde IP-Pakete an den entsprechenden Zugang gesendet hat. |
| Heartbeat
= SOFORT | das
Kunden-IP-Filter sendet Heartbeat-Pakete an den Zugang ohne jede
Verzögerung. |
-
Bei
fehlender Angabe werden keine Heartbeat-Pakete gesendet.
-
Zusammenfassend
erläutert
die Erfindung Mittel bzw. Schritte, die ein Computersystem in die
Lage versetzen, einen ersten Knoten mit einem zweiten Knoten über einen
einer Vielzahl von dritten Knoten zu verbinden, und Kommunikationen
zwischen den ersten und dritten Knoten, die verschlüsselt sind,
wenn der dritte Knoten im Betrieb ausfällt, herzustellen. Fehlerdetektions-Nachrichten
werden gesendet und wenn sie nicht zu dem entsprechenden Zeitpunkt
beantwortet werden, wird ein weiterer dritter Knoten für die Anwendung
ausgewählt.
Wenn der letztere nicht bereits authentisiert ist, d.h. nicht in
einem geeigneten Zustand für
eine verschlüsselte
Kommunikation ist, muss er zuerst authentisiert werden und es muß beispielsweise
ein entsprechender Nachrichten-Verschlüsselungs-Schlüssel erstellt
werden.