• Keine Ergebnisse gefunden

Zwangsweises Tunneling bedeutet, dass ein Nutzer bzw. Client,

248

der sich in das Internet einwählt, stets nur zu einem vordefinierten Unternehmensstandort weitergeleitet wird, und nicht selbst entscheiden kann, ob ein Tunnel aufgebaut wird.

249

Der jeweilige Anbieter des Internetzugangs schafft regelmäßig an seinem Internetzugangsknoten (PoP bzw. Einwahlserver oder Vermittlungsstelle)

250

oder auf einer Datenbank, auf welche der Internetzugangsknoten Zugriff nimmt, und die die notwendigen Parameter für die Datenweiterleitung enthält,

244 Lipp, VPN, S. 177/265/326. Mindestvoraussetzung der Kommunikation ist eine dynamische IP-Adresse.

245 Siehe das obige Beispiel auf S. 44. Aus Sicherheitsgründen muss allerdings eine Verbindung zu einer (anderen) mittels Gateway gesicherten Stelle aufgebaut werden.

246 Nicht nur der Erwerb zusätzlicher Hardware bedeutet zusätzliche Kosten, sondern auch statische IP-Adressen, die sich Anbieter –aufgrund ihrer Knappheit – oftmals sehr teuer bezahlen lassen (vgl. etwa Lipp, VPN, S. 177).

247 Tunnel-Startpunkt kann unter Umständen ebenso der PoP des Anbieters sein. Siehe hierzu Lipp, VPN, S. 178/289, der darauf verweist, dass in die PoPs spezielle Funktionen

implementiert werden müssen, um entsprechende Tunnel aufbauen zu können (siehe außerdem die nachfolgenden Ausführungen zum zwangsweisen Tunneling).

248 In den obigen Beispielen (Gateway-VPN und Software-VPN) sind Clients etwa die Telearbeiter, Externe oder Mitarbeiter innerhalb einer Zweigstelle. Zum Begriff des Client-Server-Prinzips siehe außerdem die Ausführungen auf S. 43.

249 Lipp, VPN, S. 178/292; Buckbesch/Köhler, Virtuelle Private Netze, S. 15/16. Siehe auch zur Erklärung des zwangsweisen Tunneling auch S. 12 des Whitepaper von Microsoft

(http://download.microsoft.com/download/f/3/c/f3c3a5f6-cb26-4188-a23f-278106e32566/vpnoverview.pdf - Website vom 30.09.2006).

250 Siehe hierzu S. 29.

die Voraussetzungen für die Weiterleitung in die Firmenzentrale.

251

Teilweise werden zu diesem Zwecke – ebenso wie im Rahmen des Internet-Access- so genannte RADIUS-Server eingesetzt,

252

wobei zum zusätzlichen Schutz der ausgetauschten Benutzerkennung und des Passwortes eine symmetrische Verschlüsselung eingesetzt werden kann.

253

Diesen vordefinierten Tunnel („compulsary Tunnel“) durch das Internet kann das PC-Endgerät bzw. der Nutzer nicht verlassen, da er statische Eigenschaften aufweist.

254

Der Nutzer hat keinen Einfluss auf den Aufbau des Tunnels.

Voraussetzung für dieses Modell des zwangsweisen Tunneling ist der Einsatz des oben behandelten Protokolls L2TP.

255

Auch beim zwangsweisen Tunneling ist daher eine zusätzliche Datenverschlüsselung erforderlich, etwa durch die Verwendung des Tunneling-Protokolls IPSec,

256

wobei diese Verschachtelung von L2TP und IPSec –zumindest zurzeit - auf dem Markt nur von wenigen Dienstanbietern angeboten wird.

257

251 Siehe auch Lipp, VPN, S. 285/289, der darauf hinweist, dass die für das zwangsweise Tunneling erforderlichen Funktionalitäten meist auf den PoPs der Service Provider und/oder Carriern (Netzeigentümern) bzw. auf einer Datenbank, auf die der PoP Zugriff nimmt, implementiert sind (vgl. insgesamt Lipp, VPN, S. 178/292/305 ff.).

252 Siehe zur Funktion des Radius-Servers S. 29. Lienemann, Virtuelle Private Netzwerke, S.119 führt zum zwangsweisen Tunneling aus, dass die Authentifizierung meist auf dem RADIUS-Server stattfindet.

253 Böhmer, Virtual Private Networks, S. 200 (in der ersten Auflage).

254 Böhmer, Virtual Private Networks (2. Auflage), S. 216. Siehe hierzu auch Buckbesch/Köhler, Virtuelle Private Netze, S. 103 ff., die an einem Beispiel ausführen, dass in der Datenbank des Servers zu jedem Nutzer fixiert werden kann, auf welchen Tunnel-Endpunkt dieser zu leiten ist, womit automatisch ein weitergehender Tunnel zum Endpunkt aufgebaut wird. Der Nutzer hat hierbei keinen Einfluss darauf, zu welchem Endpunkt er weiterverbunden wird

(Buckbesch/Köhler, Virtuelle Private Netze, S. 105).

255 Lienemann, Virtuelle Private Netzwerke, S. 118; Lipp, VPN, S. 178.

256 Siehe Lipp, VPN, S. 182; Buckbesch/Köhler, Virtuelle Private Netze, S. 105. L2TP (siehe zu diesem Protokoll S. 35) ist ein Protokoll, welches das zwangsweise Tunneling ermöglicht, hat hingegen keine eigenen Sicherheitsmechanismen (siehe Lipp, VPN, S. 182, der darauf verweist, dass L2TP kein Sicherheitsprotokoll ist). IPSec, welches Datenverschlüsselung beinhaltet, erfordert allerdings, dass der Client selbständig entscheidet, von welchem Startpunkt und zu welchem Endpunkt ein Tunnel aufgebaut werden soll, da nur in diesem Falle die

Verschlüsselung zwischen Client und Firmenzentrale erreicht werden kann (vgl. Lipp, VPN, S.

182). Daher kommt eine so genannte Verschachtelung von IPSec und L2TP in Betracht (Lipp, VPN, S. 182) mit der Folge, dass zwischen Client (etwa dem Mitarbeiter einer Zweigstelle, Telearbeiter oder Externen) und Firmenzentrale eine verschlüsselte Verbindung besteht, aber dennoch der Client mittels L2TP zwangsweise zur Firmenzentrale getunnelt wird. Anderenfalls beginnt der Tunnel erst im PoP des Providers, so dass der PoP damit Tunnel-Startpunkt ist, wobei in diesem Falle allein mittels L2TP ausschließlich ein unverschlüsselter Tunnel zwischen PoP und Firmenzentrale aufgebaut wird, sofern nicht der Anbieter des Internetzugangs die Verschlüsselung für den Kunden vornimmt. Diese Variante wird auch als Enterprise-Modell bezeichnet (vgl. Lipp, S. 171).

257 Lipp, VPN, S. 186. Siehe aber zu dieser Möglichkeit das Angebot von T-Online „SecureVPN-Benutzerhandbuch“, S. 226.

Der Internetzugangspunkt bzw. die nachgeschaltete Datenbank oder RADIUS-Server übernimmt beim zwangsweisen Tunneling einen Teil der

Benutzerauthentifizierung im VPN, wobei die weitere Identifizierung im Gateway stattfindet.

258

Diese Authentifizierung kann dadurch erfolgen, dass jedem Kunden eine lediglich einmal vergebene Einwahlnummer zugewiesen wird, mit der er sich bzw. die von ihm legitimierten Nutzer, insbesondere seine Mitarbeiter, bei dem Anbieter des Internetzugangs einwählt, und anhand derer dem Anbieter sofort bekannt ist, dass ein Tunnel zum Unternehmen XY aufzubauen ist.

259

Eine weitere Möglichkeit besteht darin, dem einzelnen Nutzer eine Kennung zu geben, mit welcher er sich in das Netz des Anbieters einwählt, und anhand derer der Anbieter die Zuordnung zu einem Unternehmen vornimmt.

260

Bei der Benutzerkennung kann es sich gegebenenfalls um Eigennamen der Nutzer, Passwörter oder Zertifizierungsverfahren/Zertifikate handeln.

261

Ein Teil der Benutzerauthentifizierung kann beispielsweise durch Vor- und Nachname des einzelnen Nutzers festgelegt werden, die dem Anbieter bekannt gegeben werden und die er stets einem Unternehmen zuordnet. Wählt sich beispielsweise ein „Martin Müller“ aus dem Unternehmen X in das Netz des Anbieters ein, kann der Anbieter mittels einer vorangegangen Speicherung dieser Identifikationsmerkmale an seinem Internetzugangspunkt bzw. in einer Datenbank, auf die der Internetzugangspunkt Zugriff nimmt, die Zuordnung zwischen Martin Müller und dem Unternehmen X vornehmen.

Dies erfolgt entweder durch ein so genanntes Präfix (vorangestellte Kennung) oder Suffix (angehängte Kennung), so dass die Zuordnung in der Datenbank des Anbieters beispielsweise martin.mueller@Unternehmen-X lautet.

262

Darüber hinaus kann sich der Nutzer zusätzlich durch Passwörter und/oder digitalen Zertifikaten

263

authentifizieren.

258 Siehe Lipp, VPN, S. 286 ff.

259 Lipp, VPN, S. 287/288/292; vgl. zur Einwahlnummer auch Buckbesch/Köhler, Virtuelle Private Netze, S. 15/16.

260 Lipp, VPN, S. 287; Buckbesch/Köhler, Virtuelle Private Netze, S. 16.

261 Lipp, VPN, S. 56, 145 ff.

262 Lipp, VPN, S. 287.

263 Siehe zu digitalen Signaturen und digitalen Zertifikaten die Ausführungen von Lipp, VPN, S.

150 ff.

Außerdem ist es seitens des Anbieters ebenso möglich, den Nutzern als

Benutzernamen unterschiedliche Ziffernkombinationen bereit zu stellen, welche diese bei Einwahl ins Netz angeben müssen.

264

So ist dementsprechend ebenso eine Authentifizierungsmethode durchführbar, nach welcher dem Anbieter die Nutzer nicht zwangsläufig namensmäßig

bekannt gegeben werden müssen, sondern der Anbieter seinem

Vertragspartner bzw. Kunden mehrere (ziffernmäßige) Benutzernamen

bereitstellt, dieser anschließend an seine Nutzer in eigenständiger Verwaltung

weitergibt.

265