VPN-Tunnel - Beschreibung und Verwendung von GRE-Protokoll 47-Paketen

Dieser Artikel ist eine Übersetzung des folgenden englischsprachigen Artikels der Microsoft Knowledge Base:
241251 VPN Tunnels - GRE Protocol 47 Packet Description and Use

Zusammenfassung

Das GRE-Protokoll (GRE = Generic Route Encapsulation) wird in Verbindung mit PPTP (Point-to-Point Tunneling Protocol) verwendet, um virtuelle private Netzwerke (Virtual Private Networks, VPNs) zwischen mehreren Clients oder zwischen Clients und Servern zu erstellen.

Weitere Informationen

Zu den häufigsten Implementierungen gehört das Einsetzen der VPN-Technologie von Microsoft zwischen zwei RRAS-Servern (RRAS = Routing and Remote Access Services), die für LAN-zu-LAN-Routing konfiguriert sind. Dies zeigt das folgende Beispiel:


Lclient L-RRAS ===== VPN ===== R-RRAS Rclient
| IP | | Internet | | IP |
-------------- ------------------- --------------
Um die Verwendung von GRE bei der Erstellung und Verwendung von VPNs besser nachvollziehen zu können, ist es wichtig, die Paketstruktur zu verstehen. Nachdem die PPTP-Überwachungssitzung eröffnet wurde, wird GRE verwendet, um die Daten oder die Nutzlast auf sichere Art und Weise einzukapseln. Weitere Informationen zu PPTP finden Sie im folgenden Artikel der Microsoft Knowledge Base:

241252 VPN-Tunnels PPTP-Protokollbeschreibung von Paket und Einsatz
Das von Microsoft für das Einkapseln von Daten verwendete GRE-Paketformat weist die folgende allgemeine Form auf:


+-----------------------------------+
| Data Link- (D/L) Vorspann |
+-----------------------------------+
| IP-Vorspann |
+-----------------------------------+
| GRE-Vorspann |
+-----------------------------------+
| PPP-Vorspann |
+-----------------------------------+
| Verschlüsselte PPP-Nutzlast |
+-----------------------------------+
| Data Link-Nachspann |
+-----------------------------------+
Die Daten oder die Nutzlast, die den Tunnel passieren werden, erhalten einen PPP-Header (PPP = Point-to-Point Protocol) und werden dann in ein GRE-Paket platziert. In dem GRE-Paket werden die Daten zwischen den beiden Tunnelendpunkten transportiert. Nachdem das GRE-Paket sein finales Ziel (den Endpunkt des Tunnels) erreicht hat, wird es verworfen. Dann wird das eingekapselte Paket an sein endgültiges Ziel übermittelt.

Dem vorstehenden Diagramm entsprechend wird ein IP-Paket (IP = Internet Protocol) vom Lclient zunächst an den L-RRAS-Server übermittelt. Das IP-Paket wird verschlüsselt, mit einem zusätzlichen PPP-Header versehen und dann in ein GRE-Paket platziert. Im nachstehenden Diagramm steht "PPP Stub" und nicht "PPP Header", weil der PPP-Header zusammen mit den Daten verschlüsselt wird. Das GRE-Protokoll kann den PPP-Header zwar nicht sehen, weiß aber, dass ein solcher existiert. Das GRE-Paket mit den eingekapselten und verschlüsselten Daten wird mit dem endgültigen Ziel "R-RRAS-Server" durch das Internet gesendet. Der R-RRAS-Server löscht GRE-Header und PPP-Header und übermittelt dann die entschlüsselten Daten (IP-Paket) an den Rclient.


Lclient L-RRAS ===== VPN ===== R-RRAS Rclient
| IP | | Internet | | IP |
-------------- ------------------- --------------
D/L-Vorspann D/L-Vorspann D/L-Vorspann
IP-Vorspann IP-Vorspann IP-Vorspann
Nutzlast GRE-Vorspann Nutzlast
PPP-Stub
Nutzlast (verschlüsselt)

Der Protokollheader

Um zu verstehen, wie das GRE-Protokoll als einkapselndes Protokoll arbeitet, müssen Sie das Headerformat des Protokolls betrachten. Der von Microsoft implementierte GRE-Paketheader hat das folgende Format:


0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R|K|S|s|Recur|A| Flags | Ver | Protokolltyp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Schlüssel (HW) Nutzlastlänge | Schlüssel (LW) Aufruf-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequenznummer (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bestätigungsnummer (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In der folgenden Tabelle sind die einzelnen Felder mit einer detaillierteren Beschreibung ihrer Funktion und den Parametern, die verwendet werden können, aufgelistet.

   +-----------------------------------------------------------------------+
| C | (Bit 0) Prüfsumme vorhanden. Auf null (0) gesetzt. |
+-----------------------------------------------------------------------+
| R | (Bit 1) Routing vorhanden. Auf null(0) gesetzt. |
+-----------------------------------------------------------------------+
| K | (Bit 2) Schlüssel vorhanden. Auf null(0) gesetzt. |
+-----------------------------------------------------------------------+
| | (Bit 3) Sequenznummer vorhanden. Auf eins (1) gesetzt, falls |
| S | ein Nutzlast-(Daten-) -paket vorhanden ist. Auf null (0) |
| | gesetzt, wenn keine Nutzlast vorhanden ist (GRE-Paket dient |
|.......| nur der Bestätigung). |
+-----------------------------------------------------------------------+
| s | (Bit 4) Strict Source Route vorhanden. Auf null (0) gesetzt. |
+-----------------------------------------------------------------------+
| Recur | (Bits 5-7) Rekursionskontrolle. Auf null (0) gesetzt. |
+-----------------------------------------------------------------------+
| | (Bit 8) Bestätigungssequenznummer vorhanden. Auf eins (1) |
| A | gesetzt, falls das Paket die Bestätigungsnummer zur |
| | Bestätigung zuvor übermittelter Daten enthält. |
+-----------------------------------------------------------------------+
| Flags | (Bits 9-12) Muss auf null (0) gesetzt sein. |
+-----------------------------------------------------------------------+
| Ver | (Bits 13-15) Muss 1 enthalten (erweitertes GRE). |
+-----------------------------------------------------------------------+
|=======================================================================|
+-----------------------------------------------------------------------+
| Protokolltyp | Gesetzt auf Hexziffer 880B (für PPP). |
+-----------------------------------------------------------------------+
| Schl. (HW) Nutzlastlänge| (Obere 2 Oktetts des Schlüssels) Größe der |
| | Nutzlast ohne GRE-Vorspann. |
+-----------------------------------------------------------------------+
| Schl. (LW) Aufruf-ID | (Untere 2 Oktetts) Enthält die Aufruf-ID |
| | des Peers für die Sitzung, zu der das |
| | Paket gehört. |
+-----------------------------------------------------------------------+
| Sequenznummer | Enthält die Sequenznummer der Nutzlast. |
| | Vorhanden, falls S-Bit (Bit 3) eins (1) ist.|
+-----------------------------------------------------------------------+
| | Enthält die Sequenznummer des GRE-Pakets |
| Bestätigungsnummer | mit der höchsten Nummer, das von dem sen- |
| | denden Peer für diese Benutzersitzung |
| | empfangen wurde. Vorhanden, falls A-Bit |
| | (Bit 8) eins (1) ist. |
+-----------------------------------------------------------------------+

Verbesserungen

Das GRE-Protokoll weist jetzt einige beachtliche Verbesserungen auf, die aus den Antworten auf "Request for Comments (RFC) 2637" abgeleitet wurden.

  • Ein Feld "Bestätigungsnummer" (Acknowledgment Number): Dieses Feld wird verwendet, um zu ermitteln, ob ein bestimmtes GRE-Paket oder ein Satz mit mehreren Paketen das andere Ende des Tunnels erreicht hat. Diese Bestätigungsmöglichkeit wird nicht in Verbindung mit einer Neuübertragung von Benutzerdatenpaketen verwendet. Sie wird stattdessen eingesetzt, um die Übertragungsrate für durch den Tunnel zu übermittelnde Benutzerdatenpakete für eine bestimmte Benutzersitzung zu ermitteln.
  • Tunnelportabilität: Der Nutzlastbereich enthält ein PPP-Datenpaket ohne begrenzend wirkende, medienspezifische Elemente.
  • Sequenznummernüberwachung: Die Sequenznummern für diese Funktion werden pro Paket vergeben. Die Sequenznummer für jede Benutzersitzung wird am Anfang der Sitzung auf Null gesetzt. Jedem Paket mit einer Nutzlast, das für eine bestimmte Benutzersitzung versendet wird (und ein auf eins gesetztes S-Bit oder Bit 3 beinhaltet), wird die nächsthöhere Sequenznummer für diese Sitzung zugewiesen.
  • Verwendung von Piggyback-Bestätigungen: Dieses Protokoll ermöglicht es, Bestätigungen zusammen mit den eigentlichen Daten zu übermitteln und das Protokoll somit effizienter zu machen, wodurch gleichzeitig der Pufferungsbedarf für Pakete reduziert wird.

Netzwerkmonitor-Ablaufverfolgung

Sie sollten diverse Aspekte beachten, wenn Sie sich eine Netzwerkmonitor-Ablaufverfolgung ansehen. Die Flagzusammenfassung (Flags Summary) wird aus dem Hexadezimalwert der ersten 16 Bits gebildet. In dem nachstehenden Beispielpaket ergibt die Flagzusammenfassung 12.417 oder 0x3081h. Der Microsoft-Netzwerkmonitor-Parser zeigt die Versionsnummer im Bitfeld "Flags Summary" zwar nicht an, sie ist jedoch dort vorhanden. Gehen wir etwa von dem folgenden Beispielpaket aus:


GRE: Flags Summary = 12417 (0x3081)
GRE: 0............... = Checksum Absent
GRE: .0.............. = Routing Absent
GRE: ..1............. = Key Present
GRE: ...1............ = Sequence Number Present
GRE: ....0........... = Strict Source Route Absent
GRE: ........1....... = Acknowledge Sequence Number Present
GRE: Recursion Control = 0 (0x0)
GRE: Ver = 1 (0x1)
GRE: Protocol Type = 0x880B
GRE: Key Length = 90 (0x5A)
GRE: Key Call ID = 32768 (0x8000)
GRE: Sequence Number = 16 (0x10)
GRE: Ack Number = 15 (0xF)
Die ersten 8 Bits sind 00110000, was einen Hexadezimalwert von 30 ergibt. Die nächsten 8 Bits sind 10000001, was einen Hexadezimalwert von 81 ergibt. Der Wert der Flagzusammenfassung ist also 0x3081h oder 12.417 im Dezimalsystem.

Bitte beachten Sie: Bei diesem Artikel handelt es sich um eine Übersetzung aus dem Englischen. Es ist möglich, dass nachträgliche Änderungen bzw. Ergänzungen im englischen Originalartikel in dieser Übersetzung nicht berücksichtigt sind. Die in diesem Artikel enthaltenen Informationen basieren auf der/den englischsprachigen Produktversion(en). Die Richtigkeit dieser Informationen in Zusammenhang mit anderssprachigen Produktversionen wurde im Rahmen dieser Übersetzung nicht getestet. Microsoft stellt diese Informationen ohne Gewähr für Richtigkeit bzw. Funktionalität zur Verfügung und übernimmt auch keine Gewährleistung bezüglich der Vollständigkeit oder Richtigkeit der Übersetzung.
Eigenschaften

Artikelnummer: 241251 – Letzte Überarbeitung: 05.06.2007 – Revision: 1

Feedback