DE602005000900T2 - Sichere und transparente virtuelle Privatnetzwerke - Google Patents

Sichere und transparente virtuelle Privatnetzwerke Download PDF

Info

Publication number
DE602005000900T2
DE602005000900T2 DE602005000900T DE602005000900T DE602005000900T2 DE 602005000900 T2 DE602005000900 T2 DE 602005000900T2 DE 602005000900 T DE602005000900 T DE 602005000900T DE 602005000900 T DE602005000900 T DE 602005000900T DE 602005000900 T2 DE602005000900 T2 DE 602005000900T2
Authority
DE
Germany
Prior art keywords
local
vpn
remote
transparent
service
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.)
Active
Application number
DE602005000900T
Other languages
English (en)
Other versions
DE602005000900D1 (de
Inventor
Mark D. Eagle Mountain Ackerman
Hashem Mohammad Salt Lake City Ebrahimi
Baber Provo Amin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Micro Focus Software Inc
Original Assignee
Novell Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Novell Inc filed Critical Novell Inc
Publication of DE602005000900D1 publication Critical patent/DE602005000900D1/de
Application granted granted Critical
Publication of DE602005000900T2 publication Critical patent/DE602005000900T2/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0209Architectural arrangements, e.g. perimeter networks or demilitarized zones
    • H04L63/0218Distributed architectures, e.g. distributed firewalls
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4641Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272Virtual private networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281Proxies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0414Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden during transmission, i.e. party's identity is protected against eavesdropping, e.g. by using temporary identifiers, but is known to the other party or parties involved in the communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823Network architectures or network communication protocols for network security for authentication of entities using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/166Implementing security features at a particular protocol layer at the transport layer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

  • Gebiet der Erfindung
  • Die Erfindung betrifft im Allgemeinen die Netzsicherheit und spezieller Techniken zum Managen von Kommunikationen vom Typ Virtuelles Privatnetz bzw. VPN (Virtual Private Network).
  • Hintergrund der Erfindung
  • Der Bedarf nach dem Erstellen sicherer logischer Netze über öffentliche und unsichere Kommunikationsleitungen wie z.B. das Internet wächst fortwährend. Organisationen wünschen und benötigen häufig sichere Kommunikationen mit fernen Clients oder Diensten. Als eine praktikable Sache sind dedizierte Kommunikationsleitungen und Ausrüstung keine variablen Optionen, da sie unnötig teuer sind und fortwährende Wartung und Unterstützung erfordern. Daher haben Organisationen für eine weniger teure Option und eine leichtere Option zur Implementierung und Verwendung entschieden. Diese Option wird als Virtual Private Network (VPN) bzw. Virtuelles Privatnetz bezeichnet.
  • Ein VPN verwendet ein unsicheres Netz (z.B. das Internet oder öffentliche Telekommunikationsinfrastruktur) zum Bereitstellen sicherer Kommunikationen zwischen fernen Clients oder Diensten. Ein VPN erfordert von Teilnehmern, dass sie eine Kommunikations-Infrastruktur haben zum Unterstützen gemeinsamer Verschlüsselung, Entschlüsselung, Sicherung und gewisse Protokolle. Daten werden von einem Teilnehmer verschlüsselt und unter Verwendung eines sicheren Protokolls zu einem anderen Teilnehmer getunnelt, wo diese Daten entschlüsselt und verwendet werden. In manchen Fällen ist selbst die Adresse der Teilnehmer in einem VPN verschlüsselt.
  • Mit VPN-Techniken gibt es lokale Rechenumgebungen, die lokalen Clients oder Diensten zugeordnet sind und eine ferne Rechenumgebung, die fernen Clients oder Diensten zugeordnet ist. Üblicherweise muss jeder lokale Client VPN-Kommunikationen unterstützen und direkt sichere Kommunikationen einrichten (z.B. Secure Sockets Layer (SSL) oder Transport Layer Security (TLS)) mit einem VPN-Server. Dies bedeutet, dass jeder lokale Client Client-seitige Software und eine kundenspezifische Konfiguration benötigt, um in einem gewünschten VPN mit einem fernen Client oder Dienst teilzuhaben.
  • Wie bereits ersichtlich, können Implementierungen konventioneller VPN-Techniken innerhalb lokaler Netzumgebungen eine Herausforderung darstellen und zeitaufwändig sein, da jeder Client der lokalen Umgebung konfiguriert werden muss, gewartet werden muss und unterstützt werden muss. Jedoch gibt es häufig kaum Bedenken, dass die Sicherheit von Kommunikationen innerhalb einer lokalen und vertrauenswürdigen Netzumgebung gefährdet wäre.
  • Das heißt, Sicherheitsbedenken werden hauptsächlich spezifischen Kommunikationen zugeordnet, die die lokale Netzumgebung verlassen oder in sie hineinkommen über unsichere Netzverbindung (z.B. das Internet). Demnach ist das Managen von VPN-Techniken bei allen individuellen lokalen Clients oder Diensten innerhalb der lokalen Netzumgebung übermäßig und nicht erforderlich, um geeignete Sicherheit bereitzustellen. Mit anderen Worten, ein einzelner lokaler Dienst könnte sicherstellen, dass alle lokalen Clients, die innerhalb eines VPN teilnehmen, sichere Kommunikationen über das unsichere Netz verteilen und empfangen mit gewünschten fernen Clients oder Diensten. Auf diese Weise können Clients oder Dienste in einem VPN über den Dienst teilhaben ohne irgendwelche individuelle spezifische Konfiguration, Unterstützung oder Wartung zu erfordern.
  • Ein anderer Nachteil traditioneller VPN-Techniken ist, dass das Zwischenspeichern von während einer VPN-Sitzung kommunizierter Daten nicht verfügbar ist. Dies bedeutet, dass Clients, die ihre eigene VPN-Sitzung managen, langsamere Kommunikationsraten erfahren mit ihren gewünschten fernen Clients oder Diensten. Demnach gibt es einen Bedarf zum Beschleunigen der Datenlieferung über lokales Zwischenspeichern zu lokalen Clients während VPN-Sitzungen.
  • Daher werden verbesserte Techniken zum transparenten Administrieren von VPNs benötigt.
  • WO-02/15514-A (Cyber IQ Systems) beschreibt ein VPN-Device-Clustering-System, das zwei oder mehr VPN-Vorrichtungen auf einer Seite eines virtuellen Privatnetzes mit einem ähnlichen Cluster-System von zwei oder mehr VPN-Vorrichtungen auf der anderen Seite eines virtuellen Privatnetzes verbindet. Das VPN-Device-Clustering-System schließt typischerweise eine Vielzahl von geclusterten Einheiten zur Redundanz ein, die die Schwierigkeiten vermeiden, die aufkommen mit einem einzelnen Ausfall. Beispielsweise können zwei Clustering-Einheiten in einer Aktiv-Passiv-Hochverfügbarkeits-Konfiguration verwendet werden. Clients sind vorkonfiguriert um in einer VPN-Kommunikation miteinander teilzuhaben. Die spezifische Zieladresse für das Ziel-VPN wird nicht tatsächlich durch den Client zugewiesen oder ist einem generischen Vorrat zugeordnet. Demnach sind keine spezifischen Zuweisungen von VPN-Vorrichtungen zu Clients bekannt, aber die VPN-Kommunikationen sind bekannt und in den Clients vorkonfiguriert.
  • EP-A-1,304,830 (Stonesoft Corp.) beschreibt zentralisiertes VPN-Management einer Vielzahl von VPN-Stellen mit Hilfe eines VPN-Informationsanbieters (VIP) bzw. VPN-Information-Provider. Das Management einer VPN-Vorrichtung ist verteilt, so dass mindestens ein Teil der VPN-Konfiguration zentral gemanagt wird ohne die Steuerung der Firewall-Regelgrundlage oder andere kritische lokale Konfiguration, die in der VPN-Vorrichtung verwendet wird, abzugeben.
  • Resümee der Erfindung
  • Die vorliegende Erfindung stellt Verfahren und Systeme zum Managen eines virtuellen Privatnetzes (VPN) in Übereinstimmung mit folgenden Ansprüchen bereit. In verschiedenen Ausgestaltungsformen der Erfindung werden Techniken präsentiert zum transparenten Administrieren eines VPN. Ein VPN dieser Erfindung schließt lokale Clients oder Dienste, einen lokalen transparenten VPN-Dienst, einen fernen transparenten VPN-Dienst und ferne Clients oder Dienste ein.
  • Der lokale transparente VPN-Dienst empfängt Kommunikationen, die durch die lokalen Clients oder Dienste zu vordefinierten Ports gerichtet sind. Diese Ports sind für VPN-Kommunikationen reserviert oder ihnen zugeordnet. Wenn ein lokaler Client eine Kommunikation zu einem dieser Ports richtet, leitet eine Vermittlung oder ein Router die Kommunikation zu dem lokalen transparenten VPN-Dienst zur Verarbeitung weiter. Der lokale transparente VPN-Dienst inspiziert die Kommunikation zum Zwecke des Bestimmens, ob die Kommunikation von Daten zufriedengestellt werden kann, die sich im lokalen Cache befinden, und wenn dies der Fall ist, werden solche Daten unmittelbar von dem lokalen Cache zu dem anfangs anfordernden lokalen Client geliefert.
  • Wenn die Kommunikation nicht von dem lokalen Cache zufriedengestellt werden kann, dann identifiziert der lokale transparente VPN-Dienst das spezifische VPN und den fernen Client oder Dienst, zu dem die Kommunikation gerichtet ist, übersetzt die Kommunikation und irgendwelche Adressen der Teilnehmer in geeigneter Weise und leitet die verschlüsselte Kommunikation über SSL oder über TSL zu dem fernen transparenten VPN-Dienst, welcher für den fernen Client Merkmale ausführt ähnlich denen des lokalen transparenten VPN-Dienstes.
  • Kurzbeschreibung der Zeichnungen
  • Es zeigt:
  • 1 eine Diagramm eines Architektur-Layouts für ein VPN-Managementsystem bzw. ein Managementsystem eines Virtuellen Privatnetzes;
  • 2 ein Ablaufdiagramm eines Verfahrens zum Organisieren von VPN-Kommunikationen;
  • 3 ein Ablaufdiagramm eines anderen Verfahrens zum Organisieren von VPN-Kommunikationen; und
  • 4 ein Diagramm eines VPN-Managementsystems.
  • Detaillierte Beschreibung der Erfindung
  • Wie hier und nachstehend verwendet, bedeutet "Client" eine elektronische Anwendung, ein "Dienst", ein Proxy, eine Recheneinrichtung oder ein System, das automatisiert sein kann oder mit dem ein Endbenutzer manuell interagieren kann.
  • Die Ausdrücke "lokale Netzumgebung" und "externe (ferne) Netzumgebung" werden hier und nachstehend verwendet. Lokale Netzumgebung bezieht sich auf physikalische oder logische Netzvorrichtungen und Dienste, die konfiguriert sind um in Bezug auf die Clients lokal zu sein und die mit den lokalen Clients interagieren. Dies bedeutet nicht, dass irgendeine spezielle Netzumgebung oder ein spezieller lokaler Client sich physikalisch an demselben geographischen Ort des lokalen Client befinden oder nahe bei demselben geographischen Ort des lokalen Client, obwohl dies in einigen Ausgestaltungsformen der Fall sein kann. Lokale Netzumgebungen können geographisch von dem physikalischen Ort des lokalen Client geographisch verteilt sein und eine logische lokale Netzumgebung des lokalen Client bilden. Eine externe Netzumgebung ist ein Netz, das nicht als lokal zu dem lokalen Client betrachtet wird. Ein ferner Dienst ist externen oder fernen Netzumgebungen zugeordnet und diese externen oder fernen Netzumgebungen werden als extern und fern gegenüber einer Netzumgebung eines lokalen Client betrachtet. Zudem sind die Begriffe lokal und fern oder extern relative Begriffe und hängen davon ab, wer irgendeine spezielle Transaktion durchführt. Demnach kann ein ferner Client eine lokale Netzumgebung in Bezug auf den fernen Client haben.
  • Sichere Kommunikationen beziehen sich auf Kommunikationen, die spezifische sichere Protokolle (z.B. SSL, TLS, etc.) erfordern, welche über vordefinierte Ports (z.B. 443 etc.) kommuniziert werden, die Kommunikationsvorrichtungen zugeordnet sind. Sichere Kommunikationen können sich auch auf irgendeine Form der Verschlüsselung oder der kundenspezifischen Verschlüsselung beziehen und auf ein Protokoll festgelegt sein, das verwendet wird zum gegenseitigen Einrichten sicherer Kommunikationen zwischen zwei oder mehr Einheiten. Demnach erfordert in vielen Fällen die Datenkommunikation unter Verwendung sicherer Kommunikationen eine Verschlüsselung. In einigen Beispielen verwendet diese Verschlüsselung Techniken einer Infrastruktur eines öffentlichen und privaten Schlüssels (PKI, vom englischsprachigen Ausdruck Private Key Infrastructure), welche auch Digitalzertifikate und Digitalsignaturen verwenden können. Unsichere Kommunikationen beziehen sich auf Kommunikationen, die unsichere Protokolle (z.B. HTIP etc.) verwenden und die definierte Ports (z.B. 80, etc.) der Kommunikationsvorrichtung verwenden, die sich von denen, die bei sicheren Kommunikationen verwendet werden, unterscheiden. Im Allgemeinen werden unsichere Kommunikationen auch keine Verschlüsselung einschließen.
  • Ein VPN ist ein logisches Netz, wobei zwei oder mehr Clients oder Dienste über ein unsicheres Netz (z.B. das Internet) in sicherer Weise interagieren. Die sichere Weise kann die Verwendung spezifischer Ports (z.B. 443, etc.) bedingen, die Verwendung von gegenseitig vereinbarten Protokollen (z.B. SSL, TSL, kundenspezifische Protokolle etc.) und die Verwendung von gegenseitig vereinbarter Verschlüsselung und Entschlüsselung. Traditionell erfordert ein VPN von jedem Client das Einschließen einer Konfiguration, sicherer Protokolle, Schlüsseln und Ähnlichem, die in jedem innerhalb eines VPN teilnehmenden Client vorliegen. Dies ist bei den hier dargelegten Lehren nicht der Fall. Ein lokaler transparenter VPN-Dienst agiert anstelle mehrerer Clients innerhalb von lokalen Netzumgebungen, um VPN-Verkehr zu managen. Ferne Clients und Dienste werden befähigt, über das VPN durch einen fernen transparenten VPN-Dienst zu interagieren.
  • Datenbeschleunigung bezieht sich auf die Fähigkeit zum Zwischenspeichern von Daten bevor ein Bedarf oder eine Anforderung für diese Daten auftritt. Irgendwelche konventionellen Cache-Dienste und Manager können bei den hier und nachstehend dargelegten Cache-Techniken mit Umgebungen dieser Erfindung verwendet werden. Demnach kann beispielsweise ein Cache-Manager bestimmen, wann gewisse Daten aus einem Cache auszuräumen sind und bestimmen, wann bestimmte Daten, die sich innerhalb des Cache befinden, veraltet sein können und erneuert oder aktualisiert werden sollten. Im Allgemeinen werden Daten mit Cache-Techniken beschleunigt weil der Cache näher bei einem Client sitzt und benötigte Daten in einem Speicher aufbewahrt, der schneller abgefragt und bezugrifft werden kann. Wenn demnach eine Anfrage nach speziellen Daten von einem lokalen Cache erfüllt werden kann, erfährt der anfordernde Client eine schnellere Ansprechzeit für diese Daten und es erscheint dem Client als ob die Daten beschleunigt worden wären, um eine Datenanforderung zu erfüllen.
  • Verschiedene Ausführungsformen dieser Erfindung können in existierenden Netzprodukten und Diensten implementiert werden. Beispielsweise werden die hier präsentierten Techniken in einigen Ausführungsformen als Ganzes oder teilweise in dem iChain- (registrierte Marke), Border-Manager- (registrierte Marke) und Excelerator- (registrierte Marke)-Produkten implementiert sein, die von Novell, Inc., aus Provo, Utah, vertrieben werden.
  • Sicherlich können die Ausführungsformen in einer Vielzahl von Architektur-Plattformen, Systemen oder Anwendungen implementiert werden. Beispielsweise können Abschnitte dieser Erfindung insgesamt oder teilweise in irgendeiner verteilten Architektur-Plattform, Betriebssystemen, Proxy-Diensten oder Browser-Client-Anwendungen implementiert werden. Jedwedes spezielles Architektur-Layout oder jedwede spezielle Implementierung, die hier dargelegt werden, sind zum Zwecke der Erläuterung und vollständigkeitshalber bereitgestellt und sind nicht dazu gedacht, die verschiedenen Aspekte der Erfindung einzuschränken.
  • 1 ist ein Diagramm, das ein beispielhaftes Architektur-Layout 100 für ein Virtuell-Privatnetz-Managementsystem bzw. VPN-Managementsystem repräsentiert. Die Architektur 100 ist innerhalb einer verteilten Client-Server-Architektur implementiert. Der Zweck der Architektur 100 ist, zu demonstrieren, wie verschiedene Einheiten konfiguriert und angeordnet sein können, um zu interagieren und ein VPN zu managen bzw. zu organisieren. In einigen Fällen lassen Einheiten die Beschleunigung von über das VPN eingeholten Daten zu.
  • Die Architektur 100 schließt einen oder mehrere lokale Clients 101A101B, einen lokalen transparenten VPN-Dienst 102, einen fernen transparenten VPN-Dienst 103, und einen oder mehrere ferne Clients/Dienste 104A104B ein. Es sollte bemerkt werden, dass die lokalen Clients 101A101B auch Dienste sein können. Der lokale transparente VPN-Dienst 102 kommuniziert direkt mit dem fernen transparenten VPN-Dienst 103 über ein unsicheres Netz (z.B. das Internet) unter Verwendung sicherer Kommunikationen wie z.B. SSL, TSL oder irgendein anderes gegenseitig bestätigtes Protokoll 110.
  • Während des Betriebs der Einheiten innerhalb der Architektur 100 sind die lokalen Clients 101A101B nicht vorkonfiguriert mit VPN-Fähigkeiten oder spezialisierter Software zum Verarbeiten von VPN-Kommunikationen. Stattdessen versuchen lokale Clients 101A101B mit einem spezifischen fernen Client/Dienst 104A oder 104B oder einer Gruppe von fernen Clients/Diensten 104A104B zu kommunizieren. Der lokale Client 101A oder 101B kann oder kann nicht wissen, dass seine Kommunikation mit dem gewünschten fernen Client/Dienst 104A oder 104B sicher über ein VPN erreicht wird. Beispielsweise kann ein Weiterleitungs- oder ein transparenter Proxy Kommunikationen eines lokalen Clients 101A oder 101B erfassen und jene Kommunikationen zu dem sicheren Port (z.B. 443) richten, der VPN-Verkehr zugeordnet ist. Der sichere Kommunikationsport wird durch einen Router oder eine Vermittlung (nicht in 1 gezeigt) überwacht, welcher bzw. welche eine Zieladresse für eine Kommunikation eines fernen Client/Dienstes 104A oder 104B, der dem VPN zugeordnet ist, erfasst. Dies veranlasst den Router oder die Vermittlung, die Kommunikation zu dem lokalen transparenten VPN-Dienst 102 weiterzuleiten.
  • Der lokale transparente VPN-Dienst inspiziert die abgefangene Kommunikation und bestimmt, ob die erforderliche Information oder die erforderlichen Daten aus einem lokalen Cache zufriedengestellt werden können, und wenn dies der Fall ist, liefert er diese Information oder die Daten zu dem lokalen Client 101A oder 101B aus dem lokalen Cache. In jenen Situationen ist, da der lokale transparente VPN-Dienst 102 als eine transparente Zwischenfunktion für die lokalen Clients 101A101B agiert, der lokale transparente VPN-Dienst 102 imstande, mit dem fernen transparenten VPN-Dienst 103 im Voraus einer spezifischen Kommunikation von einem der lokalen Clients 101A oder 101B zu kommunizieren, derart dass Daten durch den lokalen transparenten VPN-Dienst 102 voreingeholt werden können und der lokale Cache damit bestückt werden kann, organisiert werden kann und bezugrifft werden kann.
  • Traditionell sind VPN-Kommunikationen nicht imstande, innerhalb lokaler Umgebungen von Clients zwischengespeichert zu werden, da die sicheren Kommunikationstunnel zwischen Clients jedweden anderen Dienst davon abhalten, anstelle des Client zu agieren, um gewünschte Daten zwischenzuspeichern. Jedoch mit den hier dargelegten Lehren können Clients 101A101B und 104A104B eine beschleunigte Datenlieferung während VPN-Kommunikationen erfahren.
  • Wenn eine abgefangene VPN-Kommunikation nicht durch einen lokalen Cache zufriedengestellt werden kann, inspiziert der lokale transparente VPN-Dienst 102 die Kommunikation, um das geeignete VPN zu bestimmen, das basierend auf den Adressen der Teilnehmer angefordert wird (z.B. lokale und ferne Clients oder Dienste 101A oder 101B und 104A oder 104B). Dies ermöglicht es dem lokalen transparenten VPN-Dienst 102, einen benötigten fernen transparenten VPN-Dienst 103 zu identifizieren, mit dem der lokale transparente VPN-Dienst 102 kommuniziert.
  • Als Nächstes führt der lokale transparente VPN-Dienst 102 die erforderliche Verschlüsselung an der Kommunikation und optional an den Adressen der Teilnehmer aus. Die Verschlüsselung basiert auf dem identifizierten VPN, das den Teilnehmern und ihren Adressen zugeordnet ist. Die Verschlüsselung der Kommunikation wird dann über das unsichere Netz (z.B. das Internet) unter Verwendung eines sicheren Kommunikationsprotokolls (z.B. SSL, TLS, irgendein gegenseitig vereinbartes Protokoll, etc.) gesendet.
  • Die verschlüsselte Kommunikation wird an einem sicheren Port (z.B. 443) innerhalb der fernen Netzumgebung erfasst und in einer Weise ähnlich der, die oben diskutiert worden ist, weitergeleitet zu dem fernen transparenten VPN-Dienst 102. Der ferne transparente VPN-Dienst 103 entschlüsselt die Kommunikation und ggf. die Adressen und leitet die Kommunikation zu den erforderlichen fernen Clients/Diensten 104A104B zur Verarbeitung weiter.
  • Der anvisierte ferne Client/Dienst 104A oder 104B agiert an der Kommunikation und erzeugt eine Antwort, die zu dem lokalen Client 101A oder 101B gerichtet ist. Diese Antwort wird abgefangen und zu dem fernen sicheren Kommunikationsport gerichtet. Dort wird die Antwort wieder abgefangen und zu dem fernen transparenten VPN-Dienst 103 weitergeleitet, wo sie verschlüsselt wird und von dem fernen transparenten VPN-Dienst 103 über das unsichere Netz unter Verwendung eines sicheren Kommunikationsprotokolls (SSL oder TLS 110) zu dem lokalen transparenten VPN-Dienst 102 weitergegeben wird. Der lokale transparente VPN-Dienst 102 kann die Antwort und ihre Daten in einem lokalen Cache zwischenspeichern (im Cache) und liefert die Antwort zu dem ursprünglich anfordernden lokalen Client 101A oder 101B.
  • Der lokale transparente VPN-Dienst 102 und der ferne transparente VPN-Dienst 103 kommunizieren direkt miteinander über ein unsicheres Netz unter Verwendung sicherer Kommunikationen (z.B. Protokollen und/oder Verschlüsselung und Entschlüsselung). Jeder transparente VPN-Dienst 102 oder 103 kann mehrere Clients oder Dienste 101A oder 101B und 104A1048 bedienen, die in VPN-Interaktionen miteinander agieren. Demnach müssen individuelle Clients/Dienste 101A101B oder 104A104B nicht vorkonfiguriert, organisiert oder unterstützt werden für VPN-Kommunikationen und können trotzdem von VPNs ihren Nutzen ziehen und darin partizipieren mit den hier präsentierten Lehren. Zudem können die Clients/Dienste 101A101B und 104A104B bei einigen Ausführungsformen beschleunigte Datenlieferung während einer VPN-Sitzung erfahren, da die transparenten VPN-Dienste 102 oder 103 Daten vor einem Bedarf in einem Cache zwischenspeichern zum Zufriedenstellen einer empfangenen Kommunikation.
  • 2 ist ein Ablaufdiagramm eines Verfahrens 200 zum Organisieren von VPN-Kommunikationen. Das Verfahren 200 wird in einem Computer-lesbaren Medium implementiert, auf das über ein Netz zugegriffen werden kann. In einer Ausführungsform wird das Verfahren 200 als ein lokaler transparenter VPN-Dienst implementiert, welcher entworfen ist, um mit einem oder mehreren lokalen Clients oder Diensten zu interagieren und entworfen ist, um in sicherer Weise mit einem fernen transparenten VPN über ein unsicheres Netz zu interagieren. Der ferne transparente VPN-Dienst ist eine andere Verarbeitungsinstanz des Verfahrens 200, welche sich in einer externen oder fernen Netzumgebung befindet und Verarbeitungen durchführt. Die Verarbeitung des Verfahrens 200 wird hier und nachstehend als ein "lokaler transparenter VPN-Dienst" bezeichnet.
  • In einer Ausführungsform ist der transparente VPN-Dienst ein Dienst, dessen sich lokale Clients oder Dienste nicht bewusst sind. Das heißt, lokale Clients sind nicht vorkonfiguriert um direkt mit dem lokalen transparenten VPN-Dienst zu interagieren. In dieser Situation kann ein Router, eine Vermittlung oder ein Proxy verwendet werden zum Weiterleiten von Kommunikationen von den lokalen Clients zu dem lokalen transparenten VPN-Dienst. In einer abweichenden Ausführungsform sind die lokalen Clients konfiguriert, um VPN-Kommunikationen direkt zu dem lokalen transparenten VPN-Dienst zu senden.
  • Ein lokaler Client oder Dienst gibt eine Kommunikationsanfrage für einen fernen Client oder Dienst aus. Die Kommunikation ist gerichtet oder wird im Namen des lokalen Clients neu gerichtet zu einem spezifischen sicheren Kommunikationsport (z.B. 443, etc.), an dem ein Router oder eine Vermittlung die Kommunikation zu dem lokalen transparenten VPN-Dienst weiterleitet. Demgemäss empfängt bei 210 der lokale transparente VPN-Dienst eine Kommunikation von einem lokalen Client, die zu einem fernen Client oder Dienst gerichtet ist. Ferner wird diese Kommunikation bei 211 in einigen Ausführungsformen basierend auf dem Versuch des lokalen Client, auf einen definierten Port mit der Kommunikation zuzugreifen, erfasst.
  • Die Kommunikationen können auch auf dem stattfindenden Kommunikationstyp basieren. Beispielsweise können in einigen Ausführungsformen nur File-Transfer-Protocol- (FTP-) oder Transmission-Control-Protocol- (TCP-) Kommunikationstypen inspiziert und verarbeitet werden durch den lokalen transparenten VPN-Dienst. Demgemäss kann die Verarbeitung auf der Benutzung eines spezifischen Kommunikationsport basieren, auf einem spezifischen Kommunikationstyp (z.B. FTP, TCP, etc.) basieren oder auf einer Kombination eines spezifischen Kommunikationsports und eines spezifischen Kommunikationstyps basieren.
  • Bei 220 empfängt der lokale transparente VPN-Dienst die Kommunikation und identifiziert das VPN, das der Kommunikation zugeordnet ist. Hierzu inspiziert der lokale transparente VPN-Dienst die Adresse oder Einheit es lokalen Client und die Adresse oder Einheit des fernen Client oder Dienstes. Diese Information wird in einer Tabelle oder einer anderen Datenstruktur nachgeschaut zum Einholen der Identität der spezifischen VPN, das zwischen dem lokalen Client und dem fernen Client oder Dienst verwendet wird.
  • Sobald das spezifische VPN identifiziert ist, kann der lokale transparente VPN-Dienst die Verschlüsselung, den Schlüssel und jedwede Zertifikat-Information, die erforderlich ist zum Interagieren mit einem fernen transparenten VPN-Dienst, bei 221 einholen. Der ferne transparente VPN-Dienst ist eine ferne Verarbeitungsinstanz des lokalen transparenten VPN-Dienstes. Das heißt, der ferne transparente VPN-Dienst ist ein lokaler transparenter VPN-Dienst in Bezug auf den fernen Client oder Dienst.
  • In einigen Ausführungsformen wird bei 222 die ursprünglich empfangene Kommunikation durch den lokalen transparenten VPN- Dienst zum Zwecke des Bestimmens, ob sie aus einem lokalen Cache zufriedengestellt werden kann, inspiziert. Auf diese Weise interagieren der lokale transparente VPN-Dienst und der ferne transparente VPN-Dienst miteinander im Voraus und zu Zeiten, die abweichen von denen, zu denen ein ferner Client oder Dienst von einem lokalen Client abgefragt werden kann.
  • Während dieser Interaktionen holt der lokale transparente VPN-Dienst Daten, die dem fernen Client oder Dienst zugeordnet sind, von dem fernen transparenten VPN-Dienst und bewahrt diese Daten in einem lokalen Cache auf, der sich innerhalb der lokalen Netzumgebung des lokalen Client und des lokalen transparenten VPN-Dienstes befindet. Demnach kann der lokale transparente VPN-Dienst, wenn der lokale Client eine Kommunikation anfordert, den lokalen Cache inspizieren zum Bestimmen, ob diese Kommunikation lokal zufriedengestellt werden kann. Hierdurch erfährt der lokale Client eine beschleunigte Datenlieferung während einer VPN-organisierten Transaktion. konventionell ist dies nicht erreichbar gewesen.
  • In einer ähnlichen Weise kann der ferne transparente VPN-Dienst Daten von dem lokalen Client über den lokalen transparenten VPN-Dienst einholen und diese Daten in einem fernen Cache zwischenspeichern (Lokal-Cache gegenüber dem fernen Client oder Dienst und dem fernen transparenten VPN-Dienst), wo diese Daten verwendet werden können zum Beschleunigen einer Datenlieferung zu dem fernen Client oder Dienst, der über das VPN mit dem lokalen Client interagiert.
  • Bei 230 übersetzt der lokale transparente VPN-Dienst die ursprünglich empfangene Kommunikation und optional irgendwelche Adressen der einbezogenen Parteien (z.B. lokale und ferne Clients oder Dienste) in verschlüsselte Formate, die durch das VPN erfordert werden. Diese verschlüsselte Information wird dann unter Verwendung sicherer Kommunikationen (z.B. Protokolle und/oder Verschlüsselung und Entschlüsselung) zu dem fernen transparenten VPN-Dienst gesendet. Der ferne transparente VPN-Dienst empfängt diese verschlüsselte Kommunikation, entschlüsselt sie, identifiziert die Adresse des gewünschten fernen Client oder Dienstes und leitet die entschlüsselte Version lokal zu dem fernen Client oder Dienst weiter. Der ferne Client oder Dienst antwortet über einen definierten sicheren Kommunikations-Port (entweder direkt oder indirekt) innerhalb der fernen Netzumgebung. Diese Antwort wird zu dem fernen transparenten VPN-Dienst weitergeleitet, wo sie übersetzt wird und mit sicheren Kommunikationen zu dem lokalen transparenten VPN-Dienst gesendet wird.
  • Interaktionen zwischen den lokalen und fernen transparenten VPN-Diensten finden solange statt wie lokale und ferne Clients oder Dienste über das identifizierte VPN interagieren. Die transparenten VPN-Dienste agieren als Zwischenfunktionen für die lokalen und fernen Clients oder Dienste. Ein einzelner transparenter VPN-Dienst kann mehrere Clients oder Dienste bedienen, die sich innerhalb der lokalen Netzumgebung dieses transparenten VPN-Dienstes befinden.
  • Konventionell erfordert eine VPN-Transaktion von jedem Client oder Dienst, dass er speziell konfiguriert ist, gewartet wird und unterstützt wird zum Zwecke des Teilnehmens an VPN-Kommunikationen. Mit den Lehren dieser Erfindung ist dies nicht länger erforderlich, da alle Clients oder Dienste an einer Vielfalt von VPN definierten Kommunikationen mit allen Clients oder Diensten einer unterschiedlichen Umgebung teilhaben können, und alles was benötigt wird ein einzelner transparenter VPN-Dienst ist, der eine Betriebsinstanz hat, die in jeder Umgebung arbeitet. Demnach können zwei Dienste erreichen, was zuvor eine Modifikation aller Clients und Dienste, die an VPN-definierten Kommunikationen teilhaben wollten, erforderte.
  • Tatsächlich sind sich in einigen Ausgestaltungsformen die lokalen und fernen Clients nicht einmal der sicheren Kommunikationen und des VPNs, das zwischen ihren Kommunikationen miteinander verwendet wird, bewusst. Soweit es die Clients betrifft, glauben diese demnach, dass sie auf unsichere Weise miteinander kommunizieren, wenn tatsächlich eine Kommunikation zwischen ihnen über ein VPN über ein öffentliches oder anderweitig unsicheres Netz über die transparenten VPN-Dienste stattfindet.
  • 3 ist ein Ablaufdiagramm eines anderen Verfahrens 300 zum Organisieren von VPN-Kommunikationen. Das Verfahren implementiert ein Computerlesbares Medium und kann von jedwedem Netz oder eine Kombination von Netzen bezugrifft werden. In ähnlicher Weise zu dem Verfahren 200 der 2 oben kann das Verfahren 300 als ein lokaler transparenter VPN-Dienst betrachtet werden, der mit einer anderen Verarbeitungsinstanz von sich selbst (definiert als ein ferner transparenter VPN-Dienst) über ein Netz interagieren kann. Die beiden Verarbeitungsinstanz der transparenten VPN-Dienste organisieren VPN-Kommunikationen für mehrere Clients und Dienste.
  • Bei 310 empfängt der lokale transparente VPN-Dienst eine Kommunikation eines lokalen Client und fängt sie ab (kann auch die eines lokalen Dienstes sein). Die Kommunikation wird durch ihr Erfassen auf einem vordefinierten Port abgefangen, der durch den lokalen transparenten VPN-Dienst überwacht wird oder mitgehört wird, oder der durch einen Router oder eine Vermittlung überwacht wird, die automatisch Kommunikationen zu dem lokalen transparenten VPN-Dienst weiterleiten.
  • Der lokale transparente VPN-Dienst kann zum Organisieren zusätzlicher Kommunikationen verwendet werden, die einer Vielzahl von unterschiedlichen lokalen Clients zugeordnet sind, wie bei 321 beschrieben. Das heißt, der lokale transparente VPN-Dienst fängt VPN-Kommunikationen für lokale Clients oder Dienste, die sich innerhalb der lokalen Netzumgebung des lokalen transparenten VPN-Dienstes befinden, ab und organisiert sie.
  • Bei 320 wird die abgefangene Kommunikation von dem lokalen Client weitergeleitet und zur Verarbeitung von dem lokalen transparenten VPN-Dienst empfangen. Bei 330 wird diese Kommunikation inspiziert, um zu bestimmen, ob sie von einem lokalen Cache, der durch den lokalen transparenten VPN-Dienst organisiert und gewartet wird, zufriedengestellt werden kann.
  • Der lokale transparente VPN-Dienst interagiert mit seinem Gegenüber, dem fernen transparenten VPN-Dienst, unter Verwendung von sicheren Kommunikationen (z.B. Protokollen (SSL, TLS, etc.) und/oder Verschlüsselung und Entschlüsselung). Der lokale transparente VPN-Dienst kann demnach Daten im Voraus von einem oder mehreren fernen Clients oder Diensten über den fernen transparenten VPN-Dienst einholen. In ähnlicher Weise kann der ferne transparente VPN-Dienst Daten von einem oder mehreren lokalen Clients oder Diensten über den lokalen fernen transparenten VPN-Dienst einholen. Die Daten werden in Cache-Speichern gespeichert und organisiert, wobei ein Cache sich örtlich bei dem lokalen Client befindet und der andere Cache sich örtlich bei dem fernen Client oder Dienst befindet.
  • Wenn bei 330 die empfangene Kommunikation von dem Cache zufriedengestellt werden kann, dann wird der lokale Client bei 331 mit Daten aus dem lokalen Cache bedient. Auf diese Weise kann der lokale Client in einigen Fällen beschleunigte Datenlieferung erfahren, die den VPN-Interaktionen zuzuordnen ist. Dies ist konventionell bisher nicht erreichbar gewesen. Wenn jedoch bei 330 die empfangene Kommunikation nicht von dem lokalen Cache zufriedengestellt werden kann, dann wird bei 340 ein geeigneter ferner transparenter VPN-Dienst lokalisiert. Der lokale transparente VPN-Dienst kann mit einer Vielzahl ferner transparenter VPN-Dienste derart interagieren, dass bei 340 die Identität des benötigten fernen transparenten VPN-Dienstes basierend auf dem fernen Client oder Dienst, zu dem die Ursprungskommunikation gerichtet worden war, eingeholt werden.
  • Der lokale transparente VPN-Dienst und der ferne transparente VPN-Dienst interagieren miteinander über sichere Kommunikationen wie z.B. SSL oder TLS. In einigen Fällen können sichere digitale Zertifikate ausgetauscht werden und in einigen Fällen können die Kommunikationen oder Zertifikate gegenseitig oder einseitig digital signiert werden, wie bei 341 dargestellt.
  • Sobald die Identität des fernen transparenten VPN-Dienstes bekannt ist, wird die Kommunikation übersetzt (z.B. verschlüsselt) und über das geeignete VPN zu dem anvisierten fernen transparenten VPN-Dienst bei 342 gesendet. Die übersetzte Kommunikation wird über sichere Kommunikationen (z.B. SSL oder TLS) gesendet. Sobald die verschlüsselte Kommunikation von dem fernen transparenten VPN-Dienst empfangen wird, wird sie entschlüsselt und zu dem geeigneten fernen Client oder Dienst zur Verarbeitung gesendet.
  • Wenn verarbeitet, fängt der ferne transparente VPN-Dienst die Antwort des fernen Clients oder Dienstes ab, verschlüsselt sie und sendet sie auf sichere Weise über das VPN unter Verwendung sicherer Kommunikationen zu dem lokalen transparenten VPN-Dienst. Der lokale transparente VPN-Dienst entschlüsselt sie, führt optional ein Zwischenspeichern der zugeordneten Daten in dem lokalen Cache durch und liefert sie zu dem ursprünglich anfordernden lokalen Client.
  • Die transparenten VPN-Dienste agieren als VPN-Zwischenfunktionen oder Manager für VPN-Kommunikationen. Dies lässt zu, dass Daten während VPN-Kommunikationen zwischengespeichert werden und beschleunigt werden zum Liefern zu Clients oder Diensten und es lässt zu, dass mehrere Clients oder Dienste aktiv und in vorteilhafter Weise an VPN-Kommunikationen teilhaben können ohne das Erfordernis individueller Wartung, Unterstützung und Konfiguration, um dies zu erreichen.
  • 4 ist ein Diagramm zum Darstellen eines VPN-Managementsystems 400. Das VPN-Managementsystem 400 wird in einem Computerlesbaren Medium oder einem Medium, auf das ein Computer zugreifen kann, implementiert und auf dieses kann über irgendein Netz oder eine Kombination von Netzen zugegriffen werden. In einigen Ausführungsformen können Abschnitte des VPN-Managementsystems 400 unter Verwendung der Techniken implementiert werden, die oben in Bezug auf Verfahren 200 oder Verfahren 300 der 2 bzw. 3 dargelegt worden sind.
  • Das VPN-Managementsystem 400 schließt einen lokalen transparenten VPN-Dienst 401 ein und einen fernen transparenten VPN-Dienst 402. In einer anderen Ausführungsform schließt das VPN-Managementsystem 400 einen lokalen transparenten VPN-Dienst 401 ein und einen lokalen Kommunikationsport 401A.
  • Das VPN-Managementsystem 400 wird in einer Umgebung eines lokalen Client und in einer Umgebung eines fernen Client oder Dienstes betrieben. Jede getrennte Umgebung kann eine oder mehrere identische Einheiten einschließen. Beispielsweise kann die Umgebung des lokalen Client lokale Kommunikationsports 401A einschließen, lokale Router oder Vermittlungen 401B und einen lokalen Zwischenspeicher bzw. Cache 401C. Gleichzeitig kann die Umgebung des fernen Client oder Dienstes ferne Ports 402A einschließen, ferne Router oder Vermittlungen 402B und ferne Zwischenspeicher bzw. Cache 402. In einigen Ausführungsbeispielen können eine oder mehrere Einheiten weggelassen werden. Zudem brauchen die Umgebungen nicht identisch repliziert zu sein, wie in 4 zum Zwecke der Erläuterung dargestellt.
  • Die Umgebung des lokalen Client schließt mehrere Clients oder Dienste 410 ein. Jeder dieser Clients oder Dienste 410 kann an VPN-Kommunikationen über ein unsicheres Netz 415 mit mehreren fernen Clients oder Diensten 420 teilhaben, die sich in der Umgebung des fernen Client oder Dienstes befinden. Die lokalen und fernen Clients oder Dienste 410 und 420 brauchen nicht spezifisch konfiguriert zu sein, um an VPN-Kommunikationen teilzuhaben; stattdessen werden Details der VPN-Kommunikationen durch die beiden transparenten VPN-Dienst 401 und 402 organisiert. Jeder der transparenten VPN-Dienste 401 und 402 ist imstande, Kommunikationen, die zwischen ihnen auftreten, zu multiplexieren, zu verschlüsseln oder zu entschlüsseln, und Kommunikationen in sicherer Weise über SSL oder TLS zum Zwecke des Bewirkens eines angestrebten VPN zu senden. Tatsächlich kann es sein, dass sich die Clients in einigen Fällen tatsächlich nicht der sicheren Kommunikation mit anderen fernen Clients oder Diensten 420 bewusst sind.
  • Ein lokaler Client 410 gibt eine Kommunikation zu einem spezifischen sicheren Kommunikationsport 401A aus. Dies kann beispielsweise direkt (z.B. durch einen in 4 nicht gezeigten Weiterleitungs-Proxy) erreicht werden oder indirekt (z.B. durch einen in 4 nicht gezeigten transparenten Proxy). Der lokale transparente VPN-Dienst 401 hört an diesem Port nach VPN-Aktivität mit. Alternativ erfasst ein lokaler Router oder eine lokale Vermittlung 401B die Aktivität und basierend auf ihrem Typ (z.B. FTP, TCP, etc.) oder basierend darauf, wohin sie gerichtet ist (z.B. transparenter fernern Client oder Dienst 420), leitet er/sie die Aktivität weiter zu dem lokalen transparenten VPN-Dienst 401.
  • Sobald der lokale transparente VPN-Dienst 401 von einem lokalen Client oder Dienst 410 eine Kommunikation, die für einen fernen Client oder Dienst 420 bestimmt ist, über das unsichere Netz 415 empfängt, bestimmt der lokale transparente VPN-Dienst 401 die Identität des fernen transparenten VPN-Dienstes 402, mit dem er über das gewünschte VPN interagieren muss. Sobald dieser bekannt ist, können die Verschlüsselungs-, Entschlüsselungs-, Zertifizierungs-, Schlüssel- oder Multiplexierungs-Erfordernisse eingerichtet werden und die Kommunikation kann übersetzt werden und über das unsichere Netz 415 unter Verwendung sicherer Kommunikationen (z.B. Protokolle und/oder Verschlüsselung und Entschlüsselung) gesendet werden.
  • In einigen Ausführungsformen kann die Kommunikation durch den lokalen transparenten VPN-Dienst 401 zum Zwecke des Bestimmens, ob sie von Inhalten eines existierenden lokalen Cache 401C zufriedengestellt werden können, inspiziert werden, und wenn sie zufriedengestellt werden können, wird die von dem lokalen Client 410 stammende Kommunikation unmittelbar beantwortet mit sich in dem lokalen Cache 401C befindlichen Daten. Demnach kann in einigen Ausführungsformen der Client oder Dienst 410 und 420 eine beschleunigte Ansprechzeit und Datenlieferung erfahren wegen der Zwischenspeicherungsfähigkeit der transparenten VPN-Dienste 401 und 402. Das Zwischenspeichern ist nicht auf die Umgebung des lokalen Client beschränkt, da in einigen Ausführungsformen der ferne transparente VPN-Dienst 402 das Zwischenspeichern unter Verwendung seines fernen Caches 402C anstelle seines fernen Clients oder Dienstes 420 vornehmen kann.
  • Wenn eine Kommunikation nicht von einem Cache 401C oder 402C zufriedengestellt werden kann, dann verschlüsselt der geeignete transparente VPN-Dienst 401 oder 402 die Kommunikation und sendet die verschlüsselte Kommunikation über das unsichere Netz zu seinem gegenüberliegenden transparenten VPN-Dienst 401 oder 402. Hier wird die verschlüsselte Kommunikation entschlüsselt oder multiplexiert und zu dem geeigneten Client oder Dienst 410 oder 420 zur weiteren Verarbeitung und Beantwortung weitergeleitet. Die Antwort wird dann in derselben Weise wie die Kommunikation verarbeitet worden war, verarbeitet.
  • In einigen Ausführungsformen können die transparenten VPN-Dienste 401 und 402 mit digitalen Zertifikaten und/oder über digitale Signaturen interagieren. Tatsächlich kann der gewünschte Sicherheitspegel basierend auf den Bedürfnissen einer Organisation konfiguriert werden. Die Dienste 401 und 402 interagieren miteinander zum Zwecke des Erreichens von VPN-Kommunikationen anstelle von Clients oder Diensten 410 und 420 von ihren Umgebungen. Darüber hinaus werden in einigen Beispielfällen Daten zwischengespeichert und zur beschleunigten Lieferung bereitgestellt. Diese Vorteile sind mit konventionellen VPN-Techniken nicht erzielbar.
  • Obwohl spezifische Umgebungen dargelegt worden sind und hier beschrieben worden sind, werden Fachleute erkennen, dass jedwede Anordnung, die zum Erzielen desselben Zweckes kalkuliert wird, als Ersatz für die spezifischen gezeigten Ausgestaltungsformen verwendet werden kann. Diese Offenbarung ist dazu gedacht, alle Anpassungsmöglichkeiten oder Abwandlungen von einer Vielzahl von Ausgestaltungsformen der Erfindung abzudecken. Es muss verstanden werden, dass die obige Beschreibung nur in erläuternder Weise ausgeführt worden ist. Kombinationen der obigen Ausgestaltungsformen und andere Ausführungsformen, die nicht hier speziell beschrieben worden sind, werden Fachleuten auf das Durchsehen der obigen Beschreibung ersichtlich. Der Schutzbereich der verschiedenen Ausgestaltungsformen der Erfindung schließt alle anderen Anwendungen ein, in denen die obigen Strukturen und Verfahren verwendet werden.

Claims (21)

  1. Computer-implementiertes Verfahren zum Organisieren von Kommunikationen eines virtuellen Privatnetzes (VPN), umfassend: Empfangen (210) einer Kommunikation von einem lokalen Client (410), die zu einem fernen Client (420) gerichtet ist, über ein unsicheres Netz (415) bei einem lokalen transparenten VPN-Dienst (401); Identifizieren (220) eines der Kommunikation zugeordneten VPN; Übersetzen (230) der Kommunikation in ein verschlüsseltes Format zur Lieferung innerhalb des VPN; Senden (231) der übersetzten Kommunikation von dem lokalen transparenten VPN-Dienst (401) über das VPN zu einem fernen transparenten VPN-Dienst (402), der den VPN-Verkehr für den fernen Client organisiert durch Entschlüsseln und Zuführen der übersetzten Kommunikation zu dem fernen Client; dadurch gekennzeichnet, dass weder der lokale Client (410) noch der ferne Client (420) mit VPN-Fähigkeiten oder spezialisierter Software zum Verarbeiten von VPN-Kommunikationen vorkonfiguriert ist, und dass das Empfangen (210) die Schritte umfasst; Erfassen der Kommunikation von dem lokalen Client bei einem Weiterleitungs- oder Transparent-Proxy, Router oder einer entsprechenden Vermittlung (401B) jedes Mal, wenn der lokale Client versucht, Kommunikation in unsicherer Weise über ein Netz zu dem fernen Client über einen spezifizierten vordefinierten Kommunikationsanschluss (401A) zu senden; Abfangen der erfassten Kommunikation und Richten (211) von ihr von dem Proxy, Router oder der Vermittlung zu dem lokalen transparenten VPN-Dienst.
  2. Verfahren nach Anspruch 1, ferner das Interagieren (221) mit dem fernen transparenten VPN-Dienst (402) umfassend zum Organisieren zusätzlicher Kommunikationen zwischen dem lokalen Client und dem fernen Client über das VPN.
  3. Verfahren nach Anspruch 2, ferner das Zwischenspeichern (222) von von dem fernen transparenten VPN-Dienst (402) empfangenen Daten in einem lokalen Cash- bzw. Zwischenspeicher zum beschleunigten Liefern zu dem lokalen Client (410) umfassend.
  4. Verfahren nach Anspruch 1, wobei das Empfangen (210) der Kommunikation ferner das Empfangen der Kommunikation in mindestens einem von einem Dateienübertragungsprotokoll- bzw. File-Transfer-Protocol-Format (FTP-Format) und einem Sendesteuerprotokoll- bzw. Transmission-Control-Protocol-Format bzw. (TCP-Format) einschließt.
  5. Verfahren nach Anspruch 1, ferner das Kommunizieren mit dem fernen transparenten VPN-Dienst (402) über das unsichere Netz (415) über die SSL-Schicht bzw. Secure-Sockets-Layer oder TLS bzw. Transportschichtsicherheit (TLS) umfassend.
  6. Verfahren nach Anspruch 1, ferner umfassend: Inspizieren (330) der Kommunikation in Bezug auf das Bestimmen, ob die Kommunikation eine Abfrage für Daten ist, die sich in einem lokalen Cash-Speicher befinden (401C), und wenn das der Fall ist, Liefern (331) der Daten zu dem lokalen Client (410), und wenn es nicht der Fall ist, Lokalisieren (340) eines fernen transparenten VPN-Dienstes (402), der dem VPN zugeordnet ist, und wobei die Kommunikation in Formate übersetzt wird (342), die durch das VPN verwendet werden, und sicher über ein unsicheres Netz zu dem fernen transparenten VPN-Dienst gesendet werden zur Lieferung (343) an den fernen Client (420)
  7. Verfahren nach Anspruch 6, wobei das Inspizieren (330) ferner das Einrichten (341) sicherer Kommunikationen mit dem fernen transparenten VPN-Dienst (402) unter Verwendung von mindestens einem von SSL bzw. Secure-Sockets-Layer (SSL) und TLS bzw. Transport-Layer-Security (TLS) einschließt.
  8. Verfahren nach Anspruch 6, wobei das Inspizieren (330) ferner das Identifizieren des fernen transparenten VPN-Dienstes (402) als einen Dienst einschließt, der VPN-Verkehr für den fernen Client (420) organisiert.
  9. Verfahren nach Anspruch 6, ferner umfassend: Empfangen einer Antwort-Kommunikation von dem fernen Client (420) über den fernen transparenten VPN-Dienst (402), wenn die Kommunikation über das VPN gesendet worden ist, weil es von dem lokalen Cash (401C) nicht zufriedengestellt werden könnte; Übersetzen der Antwort basierend auf den Formaten des VPN; und Liefern der übersetzten Antwort an den lokalen Client.
  10. Verfahren nach Anspruch 6, ferner das Organisieren (321) zusätzlicher, zwischen einem oder mehreren unterschiedlichen fernen Clients (420) gerichteter Kommunikationen, die dem VPN zugeordnet sind, von einem oder mehreren unterschiedlichen lokalen Clients (410) umfassend, wobei der ferne transparente VPN-Dienst (402) die zusätzlichen Kommunikationen anstelle des einen oder der mehreren unterschiedlichen fernen Clients organisiert.
  11. Verfahren nach Anspruch 6, wobei das Empfangen ferner das Abfangen (310) der Kommunikation einschließt nach dem Erfassen, dass der lokale Client die Kommunikation nicht mit einem Hypertext-Transfer-Protocol (HTTP) sendet.
  12. Verfahren nach Anspruch 6, ferner das Interagieren (341) mit dem fernen transparenten VPN-Dienst mit gegenseitig signierten Zertifikaten umfassend, die zwischen den lokalen und den fernen transparenten VPN-Diensten während der Interaktionen ausgetauscht werden.
  13. Organisationssystem (400) eines virtuellen Privatnetzes (VPN), wobei weder ein oder mehrere lokale Clients (410) noch ein oder mehrere ferne Clients (420) mit VPN-Fähigkeiten oder spezialisierter Software zum Verarbeiten von VPN-Kommunikationen vorkonfiguriert sind, umfassend: einen lokalen transparenten VPN-Dienst (401); einen lokalen Weiterleitungs- oder Transparent-Proxy, Router oder eine entsprechende Vermittlung (401B), angepasst zum Erfassen einer Kommunikation von einem lokalen Client jedes Mal wenn der lokale Client versucht, die Kommunikation unsicher über ein Netz zu einem fernen Client über einen spezifisch vordefinierten lokalen Kommunikationsanschluss (401A) zu senden, und angepasst zum Abfangen der erfassten Kommunikation und zum Richten (211) von ihr von dem lokalen Proxy, Router oder der Vermittlung zu dem lokalen transparenten VPN-Dienst; einen fernen transparenten VPN-Dienst (402); einen fernen Weiterleitungs- oder Transparent-Proxy, Router oder eine entsprechende Vermittlung (402B), angepasst zum Erfassen einer Kommunikation von einem fernen Client jedes Mal, wenn der ferne Client versucht, die Kommunikation unsicher über das Netz zu einem lokalen Client über einen spezifischen vordefinierten fernen Kommunikationsanschluss (402A) zu senden, und angepasst zum Abfangen der erfassten Kommunikation und zum Richten (211) von ihr von dem fernen Proxy, Router oder der Vermittlung zu dem fernen transparenten VPN-Dienst.
  14. VPN-Organisationssystem nach Anspruch 13, ferner einen lokalen Zwischenspeicher bzw. Cash (401C) umfassend; wobei der lokale transparente VPN-Dienst (401) VPN-Verkehr für einen oder mehrere lokale Clients (410) und Dienstekommunikationen von jenen lokalen Clients mit Daten im lokalen Cash-Speicher (401C) wenn verfügbar abfängt und organisiert, und wenn die Daten nicht in dem lokalen Cash-Speicher verfügbar sind, der lokale transparente VPN-Dienst die Kommunikationen sicher zu dem fernen transparenten VPN-Dienst übermittelt zum Liefern und Bedienen durch einen oder mehrere ferne Clients (420), der bzw. die den fernen transparenten VPN-Dienst (402) organisiert bzw. organisieren.
  15. VPN-Organisationssystem nach Anspruch 13, wobei der lokale transparente VPN-Dienst (401) und der ferne transparente VPN-Dienst (402) über mindestens eines von Secure-Sockets-Layer (SSL) und Transport-Layer-Security (TLS) interagieren.
  16. VPN-Organisationssystem nach Anspruch 13, wobei der lokale transparente VPN-Dienst (102, 401) lokalen VPN- Verkehr für den einen oder die mehreren lokalen Clients (101, 410) abfängt durch Inspizieren von Kommunikationen, die von einem oder mehreren lokalen Clients stammen, unter Verwendung des Sendesteuerungsprorokolls bzw. Transmission-Control-Protocol (TCP) oder des Dateiübertragungsprotokolls bzw. File-Transfer-Protocol (FTP).
  17. VPN-Organisationssystem nach Anspruch 13, wobei die Kommunikationen zwischen den lokalen (102, 401) und den fernen (103, 402) transparenten VPN-Diensten mit gegenseitig ausgetauschten Zertifikaten auftreten.
  18. VPN-Organisationssystem nach Anspruch 13, wobei das System sich auf einem Server befindet und eine Vielzahl lokaler Clients (410) bedient, die den VPN-Kommunikationen zugeordnet sind.
  19. VPN-Organisationssystem nach Anspruch 13, wobei sich das System auf einem einzelnen Client befindet.
  20. Computerprogramm, das wenn es auf einem Computer oder in einem Computernetz ausgeführt wird, das Verfahren durchführt, wie es in einem der Ansprüche 1 bis 12 beansprucht wird.
  21. Computerprogramm nach Anspruch 20, wenn auf einem Maschinen-zugreifbaren Medium gespeichert.
DE602005000900T 2004-03-31 2005-02-14 Sichere und transparente virtuelle Privatnetzwerke Active DE602005000900T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US813990 2004-03-31
US10/813,990 US7353537B2 (en) 2004-03-31 2004-03-31 Secure transparent virtual private networks

Publications (2)

Publication Number Publication Date
DE602005000900D1 DE602005000900D1 (de) 2007-05-31
DE602005000900T2 true DE602005000900T2 (de) 2008-01-17

Family

ID=34887714

Family Applications (1)

Application Number Title Priority Date Filing Date
DE602005000900T Active DE602005000900T2 (de) 2004-03-31 2005-02-14 Sichere und transparente virtuelle Privatnetzwerke

Country Status (3)

Country Link
US (1) US7353537B2 (de)
EP (1) EP1583316B1 (de)
DE (1) DE602005000900T2 (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7353537B2 (en) 2004-03-31 2008-04-01 Novell, Inc. Secure transparent virtual private networks
US8903938B2 (en) 2007-06-18 2014-12-02 Amazon Technologies, Inc. Providing enhanced data retrieval from remote locations
US20100241712A1 (en) * 2009-03-23 2010-09-23 Siemens Aktiengesellschaft Method and System for a Distributed and Extensible Communication Framework
US8739244B1 (en) * 2011-06-07 2014-05-27 Riverbed Technology, Inc. Configuring and authenticating WAN optimization devices for accessing content delivery networks
US8782395B1 (en) 2011-09-29 2014-07-15 Riverbed Technology, Inc. Monitoring usage of WAN optimization devices integrated with content delivery networks
US9137162B2 (en) 2013-07-23 2015-09-15 Sap Se Network traffic routing optimization
US11088994B2 (en) 2017-12-01 2021-08-10 Twingate Inc. Local interception of traffic to a remote forward proxy

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6092200A (en) * 1997-08-01 2000-07-18 Novell, Inc. Method and apparatus for providing a virtual private network
US6079020A (en) * 1998-01-27 2000-06-20 Vpnet Technologies, Inc. Method and apparatus for managing a virtual private network
US6704282B1 (en) * 1999-06-30 2004-03-09 3Com Corporation VPN tunnel redirection
US6693878B1 (en) * 1999-10-15 2004-02-17 Cisco Technology, Inc. Technique and apparatus for using node ID as virtual private network (VPN) identifiers
US6654347B1 (en) * 1999-10-22 2003-11-25 Dell Usa L.P. Site-to-site dynamic virtual local area network
US6772226B1 (en) 2000-08-15 2004-08-03 Avaya Technology Corp. VPN device clustering using a network flow switch and a different mac address for each VPN device in the cluster
FI20011949A0 (fi) 2001-10-05 2001-10-05 Stonesoft Corp Virtuaalisen yksityisverkon hallinta
US7069336B2 (en) * 2002-02-01 2006-06-27 Time Warner Cable Policy based routing system and method for caching and VPN tunneling
US20040034702A1 (en) * 2002-08-16 2004-02-19 Nortel Networks Limited Method and apparatus for exchanging intra-domain routing information between VPN sites
US7353537B2 (en) 2004-03-31 2008-04-01 Novell, Inc. Secure transparent virtual private networks

Also Published As

Publication number Publication date
EP1583316B1 (de) 2007-04-18
DE602005000900D1 (de) 2007-05-31
US7353537B2 (en) 2008-04-01
EP1583316A1 (de) 2005-10-05
US20050246519A1 (en) 2005-11-03

Similar Documents

Publication Publication Date Title
EP2018015B1 (de) Verfahren und Vorrichtung für eine anonyme verschlüsselte mobile Daten- und Sprachkommunikation
DE60122782T2 (de) Adressierungsverfahren und system zur verwendung einer anycast-adresse
DE602005000900T2 (de) Sichere und transparente virtuelle Privatnetzwerke
EP1793525B1 (de) Verfahren zum Ändern eines Gruppenschlüssels in einer Gruppe von Netzelementen in einem Netz
DE60019997T2 (de) Ggesicherte Kommunikation mit mobilen Rechnern
DE60026838T2 (de) Dynamische verbindung zu mehreren quellen-servern in einem transcodierungs-proxy
DE60212289T2 (de) Verwaltung privater virtueller Netze (VPN)
DE60200451T2 (de) Herstellung einer gesicherten Verbindung mit einem privaten Unternehmensnetz über ein öffentliches Netz
US20180006816A1 (en) Session key repository
DE60121755T2 (de) Ipsec-verarbeitung
DE60307652T2 (de) Verfahren und System zur gesicherten Inhaltsüberlieferung
DE10392283T5 (de) System, Verfahren und Vorrichtung für verbündete einzelne Dienstleistungen mit Anmeldeverfahren beziehungsweise Sign-On-Dienstleistungen
EP3518489A1 (de) Verfahren und system zur offenlegung mindestens eines kryptographischen schlüssels
DE10037500A1 (de) Verfahren zur Schlüsselvereinbarung für eine kryptographisch gesicherte Punkt-zu-Multipunktverbindung
DE102015003235A1 (de) Verfahren und System zum Bereitstellen von Kommunikationskanälen, welche verschiedene sichere Kommunikationsprotokolle verwenden
EP1721235B1 (de) Kommunikationssystem und verfahren zur bereitstellung eines mobilen kommunikationsdienstes
DE112004000125T5 (de) Gesichertes Client-Server-Datenübertragungssystem
EP1709764A1 (de) Schaltungsanordnung und verfahren zur kommunikationssicherheit innerhalb von kommunikationsnetzen
WO2019242947A1 (de) Verfahren zur anbindung eines endgerätes in eine vernetzbare rechner-infrastruktur
EP2685682A2 (de) Verfarhen und System zur sicheren Nachrichtenübertragung
EP2575298B1 (de) Verfahren und Vorrichtung zur sicheren Abwicklung einer E-Mail-Kommunikation
EP2929672B1 (de) Arbeitsverfahren für ein system sowie system
DE60127187T2 (de) System und verfahren zur bereitstellung von diensten in virtuellen privatnetzen
DE102015119687B4 (de) Verfahren zum Generieren und/oder Übertragen einer verschlüsselten Nachricht
EP4243342A1 (de) Verfahren, vorrichtung und computerprogrammprodukt zur sicheren kommunikation über das internet

Legal Events

Date Code Title Description
8364 No opposition during term of opposition