Ahaa…und das hat nichts mit dem Schutz der Daten zu tun 
Wirst du aus meinem Munde nicht hören! Wenn du weißt, wie hier die SuFu funktioniert, findest du genügend Themen und Posts von mir, die den ursprünglichen Gedanken und Zweck eines VPN in jeglicher Art darlegen ! Das die heutzutage übliche Definition, die ca. 99% der Internet-Nutzer darunter verstehen, nur noch im Ansatz etwas damit zu tun hat, musst du mir bestimmt nicht erklären 
Und wenn du der Meinung bist, VPN mit seinen Protokollen und Sicherheitstechniken in 10 Sätzen umschreiben zu können, dann benutze zumindest die richtigen 10 Sätze, die dabei in dem riesigen Thema auch am Besten noch einen Zusammenhang ergeben!!
===================================================================================
Schutzziele in der Netzwerktechnik:
- Daten gegen Verlust sichern (Datensicherheit)
- Daten gegen Diebstahl sichern (Datenschutz)
- Daten gegen Manipulation sichern (Datenintegrität)
- unbefugten Informationsgewinn (Verlust der Vertraulichkeit)
- unbefugte Modifikation von Information (Verlust der Integrität)
- unbefugte Beeinträchtigung der Funktionalität (Verlust der Verfügbarkeit)
VPN-Tunnel
Für das Tunneling gibt es zwei Ansätze. Im ersten Ansatz wird auf der Schicht 3 des OSI-Schichtenmodells das Tunneling aufgebaut. Dabei wird zur Adressierung der Schicht bzw. der Datenpakete das Internet Protocol (IP) verwendet. Man spricht dann vom IP-in-IP-Tunneling. In der Regel wird IPsec für diese Lösung verwendet.
Ein anderer Ansatz greift direkt auf der Schicht 2 des OSI-Schichtenmodells ein. Hier wird das Datenpaket der Schicht 3 verschlüsselt und dann mit der physikalischen Adresse adressiert. In der Regel werden PPTP oder L2TP für diese Lösung verwendet.
Encapsulation
Die zentralen Funktionen in der IPsec-Architektur sind das AH-Protokoll (Authentification Header), das ESP-Protokoll (Encapsulating Security Payload) und die Schlüsselverwaltung (Key Management). Authentizität, Vertraulichkeit und Integrität erfüllt IPsec durch AH und ESP.
Für den Aufbau eines VPN gibt es in IPsec den Authentication Header (AH) und den Encapsulating Security Payload (ESP). Beide können gemeinsam oder eigenständig genutzt werden. In beiden Verfahren findet eine gesicherte Übertragung statt.
Das AH-Protokoll sorgt für die Authentifizierung der zu übertragenen Daten und Protokollinformationen. Das ESP-Protokoll erhöht die Datensicherheit in Abhängigkeit des gewählten Verschlüsselungsalgorithmus.
IPsec setzt kein bestimmtes Verschlüsselungs- und Authentifizierungsverfahren voraus.
IKE und IKEv2:
Es gibt zwei Wege für die Verwaltung und Verteilung der Schlüssel innerhalb eines VPNs. Neben der reinen manuellen Schlüsselverwaltung, kann auch das Internet Key Exchange Protocol (IKE) eingesetzt werden.
Vor der geschützten Kommunikation müssen sich die Kommunikationspartner über die Verschlüsselungsverfahren und Schlüssel einig sein. Diese Parameter sind Teil der Sicherheitsassoziation (Vertrauensstellungen) und werden von IKE/IKEv2 automatisch ausgehandelt und verwaltet.
Das Internet-Key-Exchange-Protokoll dient der automatischen Schlüsselverwaltung für IPsec. Es verwendet das Diffie-Hellman-Verfahren zum sicheren Erzeugen von Schlüsseln über ein unsicheres Netz. Auf Basis dieses Verfahren wurden einige Schlüsselaustauschverfahren entwickelt, die zum Teil die Grundlage für Internet Key Exchange bilden.
IKE basiert auf dem Internet Security Association and Key Management Protocol (ISAKMP). ISAKMP ist ein Regelwerk, das das Verhalten der beteiligten Gegenstellen genau festlegt. Wie das zu erfolgen hat, legt IKE fest. Die Flexibilität von IKE äußert sich in seiner Komplexität. Wenn unterschiedliche IPsec-Systeme keine Sicherheitsassoziationen austauschen können, dann liegt das meistens an einer fehlerhaften IKE-Implementierung oder fehlende Verschlüsselungsverfahren.
Version 2 des Internet-Key-Exchange-Protokolls (IKEv2) vereinfacht die Einrichtung eines VPNs. Es ist wesentlich einfacher, flexibler und weniger fehleranfällig. Insbesondere soll das Mobility and Multihoming Protocol (MOBIKE) dafür sorgen, dass IPSec-Tunnel in mobilen Anwendungen erheblich zuverlässiger funktionieren.
IKEv2 korrigiert einige Schwachstellen bzw. Probleme der Vorgänger-Version. Die Definition wurde in ein Dokument zusammengefasst, der Verbindungsaufbau vereinfacht und viele Verbesserungen hinzugefügt. Insgesamt ist IKEv2 weniger komplex als die Vorgänger-Version. Das erleichtert die Implementierung, verringert Fehler und erhöht somit die Sicherheit.
Das schonmal zu IPSec (Tunnel-Protokoll) und IKE (reine Schlüsselverwaltung) 
Aber bevor man überhaupt mit diesen Themen anfängt, sollte man erstmal wissen, was für ein VPN zum Einsatz kommen soll
Typische VPN-Szenarien:
- Site-to-Site-VPN / LAN-to-LAN-VPN / Gateway-to-Gateway-VPN
- End-to-Site-VPN / Host-to-Gateway-VPN / Remote-Access-VPN
- End-to-End-VPN / Host-to-Host-VPN / Remote-Desktop-VPN / Peer-to-Peer-VPN
VPN-Verbindung / IPSec in der praktischen Umsetzung:
Die Netzwerkteilnehmer im LAN 1 können auf das LAN 2 zugreifen bzw. umgekehrt die Teilnehmer aus LAN 2 auf das LAN 1. Die Verbindung über das Internet läuft über einen verschlüsselten Tunnel ab.
Die beiden Firewalls müssen beim Verbindungsaufbau ihre Identität eindeutig nachweisen. Somit ist unberechtigter Zugang ausgeschlossen. Die Kommunikation über das Internet erfolgt verschlüsselt. Sollte ein Dritter die Datenpakete protokollieren erhält er nur Datenmüll.
Damit das Routing zwischen den Netzen funktioniert müssen die Adressbereiche innerhalb der Netze unterschiedlich sein. Da die Netze sich nach der Zusammenschaltung wie eines verhalten, dürfen IP-Adressen nicht doppelt vorkommen. Deshalb muss vorab auf beiden Seiten ein eigener Adressbereich, also unterschiedliche Subnetze, konfiguriert werden. (Thema Subnetting / Supranetting)
Wenn aber z.B. NAT-Router in beiden Netzen vorhanden sind, kann trotz legitimen Schlüsselaustausch über IKE die eigentliche VPN-Verb. immer noch an NAT scheitern (Stichwort: Verfälschung IPSec-Pakete durch neu zugewiesene IP-Adressen)
Um diesem Problem zu entgehen, wird die IPSec-Erweiterung NAT-Traversal eingesetzt, die Bestandteil von IKE / IKEv2 ist.
Damit IPsec-Verbindungen mit NAT-Traversal möglich sind, müssen die Firewalls auf beiden Seiten die verschlüsselten Datenpakete durchlassen. Die Authentifizierung erfolgt über den UDP-Port 500 oder 4500. In der Regel müssen diese Ports in der Firewall geöffnet werden.
Die verschlüsselten Datenpakete werden über das IP-Protokoll 50, dem ESP (Encapsulated Security Payload), oder dem IP-Protokoll 51, AH (Authentication Header), verschickt.
Der sichere Transport von UDP-Paketen wird durch geeignete Maßnahmen im ISAKMP erreicht. So kann man auf das verbindungsorientierte TCP verzichten. Auf diese Weise haben auch viele Angriffsversuche keine Chance.
BTW:
Nicht nur ausschließlich bei VPN sind die MTU-Werte geringer, als der restliche Netzwerkdurchsatz an Datenpaketen!!
Path MTU Discovery (RFC 1191)
Path MTU Discovery bei IPv4 sieht vor, dass das DF-Bit (Don’t Fragment) im IP-Header gesetzt wird. Mit diesem Flag bekommen die Router auf dem Weg zum Empfänger mitgeteilt, dass dieses Paket nicht fragmentiert werden darf. Wenn der Router es zerschneiden muss, dann verwirft er es und schickt eine Mitteilung an den den Absender mit der Fehlermeldung zurück, dass das Paket zu groß ist und wie groß das Paket maximal groß sein darf (MTU). Der Client schickt dann das Paket mit der kleineren MTU, in der Hoffnung, dass es jetzt durchgeht. Wenn nicht, dann muss der Client das Paket noch mal verkleinern. Solange, bis das Paket erfolgreich beim Empfänger ankommt.
(MTU = Maximum Transmission / Transfer - Unit)
Für die Fehlermeldung ist ICMP verantwortlich. Leider gibt es einige Paranoide Netzwerk-Administratoren, die in den Netzwerken, die sie betreuen, die ICMP-Pakete von Firewalls sperren bzw. verwerfen lassen. Das heißt, das ursprüngliche Datenpaket wird nie beim Empfänger ankommen und der wird nie erfahren, worin das Problem liegt.
Dieses Problem tritt zum Beispiel bei VPN-Verbindungen auf. Hier müsste wegen dem Tunneling die MTU meist kleiner sein.
P.S.
Natürlich meldet der Benutzer sich in Domänen-Netzwerken mit seinem Passwort an - das diesem Nutzer dann auch parallel Berechtigungen innerhalb seiner OU zufallen und das Zertifikat sowieso im Hintergrund abgerufen wird, nennt man blöde „Benutzerverwaltung“ ! Natürlich kann man das per Smartcard und / oder USB-Key (what ever) erledigen - trotzdem müssen alle Authentifizierungsmerkmale des Nutzers im Einzelnen im Netzwerk gegengeprüft werden, z.B. über eine interne CA usw.
Früher gabs in jedem Firmen-Laptop die Möglichkeit, sich per Smartcard im Unternehmensnetzwerk zu authentifizieren - macht heute keine Sau mehr, da viel zu kompliziert und fehleranfällig!! Und wenns Läppi geklaut wird inkl. SC, dann guckste nur noch dämlich…
