Generic Routing Encapsulation (oder GRE) ist ein Protokoll zum Einpacken von Datenpaketen in sekundäre Datenpakete, um eine Direktnetzwerkverbindung (Point-to-Point) aufzubauen.
Nach Lektüre dieses Artikels können Sie Folgendes:
Ähnliche Inhalte
Abonnieren Sie theNET, Cloudflares monatliche Zusammenfassung der beliebtesten Einblicke in das Internet!
Link zum Artikel kopieren
Generic Routing Encapsulation (oder GRE) ist ein Protokoll zur Einkapselung von Datenpaketen, die ein Routing-Protokoll innerhalb der Pakete eines anderen Protokolls verwenden. „Einkapseln“ bedeutet, dass ein Datenpaket in ein anderes Datenpaket eingepackt wird, so wie Sie eine Schachtel in eine andere Schachtel legen. GRE ist eine Möglichkeit, eine Direktverbindung (Point-to-Point) über ein Netzwerk einzurichten, um getrennte Netzwerke einfacher zu verbinden. Es arbeitet mit einer Vielzahl von Netzwerk-Layer-Protokollen.
Mithilfe von GRE können Protokolle verwendet werden, die ein Netzwerk normalerweise nicht unterstützt, da die Pakete in andere Pakete verpackt sind, die wiederum unterstützte Protokolle verwenden. Um zu verstehen, wie es funktioniert, stellen Sie sich den Unterschied zwischen einem Auto und einer Fähre vor. Ein Auto fährt auf dem Land über Straßen, während eine Fähre über Wasser fährt. Ein Auto kann normalerweise nicht auf dem Wasser fahren – dafür können Sie ein Auto aber auf eine Fähre verladen.
In dieser Analogie ist die Art des Geländes wie ein Netzwerk, das bestimmte Routing-Protokolle unterstützt, und die Fahrzeuge sind wie Datenpakete. GRE ist eine Möglichkeit, einen Pakettyp in einen anderen Pakettyp zu laden, sodass das erste Paket ein Netzwerk überqueren kann, das es normalerweise nicht überqueren könnte; so wie ein Fahrzeugtyp (das Auto) auf einen anderen Fahrzeugtyp (die Fähre) geladen wird, um Gelände zu überqueren, das es sonst nicht überqueren könnte.
Nehmen wir zum Beispiel an, ein Unternehmen muss eine Verbindung zwischen den lokalen Netzwerken (LANs) in zwei verschiedenen Büros herstellen. Beide LANs verwenden die neueste Version des Internet-Protokolls, IPv6. Um jedoch von einem Büronetzwerk in ein anderes zu gelangen, muss der Datenverkehr durch ein von einer dritten Partei verwaltetes Netzwerk geleitet werden – dieses ist jedoch etwas veraltet und unterstützt nur das ältere IPv4-Protokoll.
Mit GRE könnte das Unternehmen den Datenverkehr durch dieses Netzwerk senden, indem es IPv6-Pakete in IPv4-Pakete einkapselt. Um auf die Analogie zurückzukommen: Die IPv6-Pakete sind das Auto, die IPv4-Pakete sind die Fähre und das Drittnetz ist das Wasser.
Das Einkapseln von Paketen innerhalb anderer Pakete wird als „Tunneling“ bezeichnet. GRE-Tunnel werden normalerweise zwischen zwei Routern konfiguriert, wobei jeder Router als ein Ende des Tunnels fungiert. Die Router sind so eingerichtet, dass sie GRE-Pakete direkt untereinander senden und empfangen. Alle Router zwischen diesen beiden Routern öffnen die eingekapselten Pakete nicht; sie beziehen sich nur auf die Header, die die eingekapselten Pakete umgeben, um sie weiterzuleiten.
Um zu verstehen, warum dieser Prozess „Tunneling“ genannt wird, können wir die Analogie etwas anpassen. Wenn ein Auto von Punkt A auf der einen Seite eines Berges zu Punkt B auf der anderen Seite fahren muss, ist es am effizientesten, einfach mitten durch den Berg zu fahren. Ein gewöhnliches Auto ist jedoch nicht in der Lage, einfach durch massiven Fels hindurchzufahren. Also muss das Auto den gesamten Berg umfahren, um von Punkt A nach Punkt B zu gelangen.
Aber stellen Sie sich vor, dass man einen Tunnel durch den Berg gebaut hat. Jetzt kann das Auto direkt von Punkt A nach Punkt B fahren. Es ist jetzt viel schneller und kann etwas, das es ohne den Tunnel nicht hätte tun können.
Nun stellen Sie sich vor: Punkt A ist ein vernetztes Gerät, Punkt B ist ein weiteres vernetztes Gerät, der Berg ist das Netzwerk zwischen den beiden Geräten und das Auto sind Datenpakete, die von Punkt A zu Punkt B gelangen müssen. Stellen Sie sich vor, dieses Netzwerk unterstützt nicht die Art von Datenpaketen, die die Geräte an den Punkten A und B austauschen müssen. Wie ein Auto, das versucht, durch einen Berg zu fahren, können die Datenpakete nicht durchkommen und müssen unter Umständen einen viel längeren Weg über zusätzliche Netzwerke zurücklegen.
Aber GRE schafft einen virtuellen „Tunnel“ durch das „Berg“-Netzwerk, um die Datenpakete durchzulassen. So wie ein Tunnel eine Möglichkeit für Autos schafft, geradewegs durch Land zu fahren, so schaffen GRE (und andere Tunneling-Protokolle) eine Möglichkeit für Datenpakete, durch ein Netzwerk zu gehen, das sie nicht unterstützt.
Alle über ein Netzwerk gesendeten Daten werden in kleinere Teile – die Pakete – zerlegt. Und alle Pakete bestehen aus zwei Teilen: der Nutzlast (payload) und dem Header. Die Nutzlast ist der eigentliche Inhalt des Pakets, also die gesendeten Daten. Der Header enthält Informationen darüber, wo das Paket herkommt und zu welcher Gruppe von Paketen es gehört. Jedes Netzwerkprotokoll hängt an jedes Paket einen Header an.
GRE fügt jedem Paket zwei Header hinzu: den GRE-Header, der 4 Bytes lang ist, und einen IP-Header, der 20 Bytes lang ist. Der GRE-Header gibt den Protokolltyp an, der von dem eingekapselten Paket verwendet wird. Der IP-Header kapselt den Header und die Nutzlast des Originalpakets ein. Das bedeutet, dass ein GRE-Paket normalerweise zwei IP-Header hat: einen für das ursprüngliche Paket und einen, der durch das GRE-Protokoll hinzugefügt wurde. Nur die Router an jedem Ende des GRE-Tunnels beziehen sich auf den ursprünglichen, nicht-GRE-IP-Header.
MTU und MSS sind Messungen, die begrenzen, wie groß die Datenpakete sein dürfen, die sich über ein Netzwerk bewegen – genau wie es ein Gewichtslimit für Autos gibt, die eine Brücke überqueren. MTU misst die Gesamtgröße eines Pakets einschließlich der Header; MSS misst nur die Nutzlast. Pakete, die über die MTU hinausgehen, werden fragmentiert oder in kleinere Teile zerlegt, sodass sie durch das Netzwerk passen.
Wie bei jedem Protokoll erhöht die Verwendung von GRE die Größe der Datenpakete um einige Bytes. Dies muss in den MSS- und MTU-Einstellungen für Pakete berücksichtigt werden. Wenn die MTU 1.500 Bytes und die MSS 1.460 Bytes beträgt (um die Größe der erforderlichen IP- und TCP-Header zu berücksichtigen), führt das Hinzufügen von GRE-24-Byte-Headern dazu, dass die Pakete die MTU überschreiten:
1.460 Bytes [Nutzlast] + 20 Bytes [TCP-Header] + 20 Bytes [IP-Header] + 24 Bytes [GRE-Header + IP-Header] = 1.524 Bytes
Also werden die Pakete fragmentiert. Die Fragmentierung verlangsamt die Paketlieferzeiten und erhöht die Rechenleistung, da Pakete, die die MTU überschreiten, zerlegt und dann wieder zusammengesetzt werden müssen.
Dies kann man vermeiden, indem man die MSS reduziert, um die GRE-Header aufzunehmen. Wenn die MSS auf 1.436 statt auf 1.460 gesetzt wird, werden die GRE-Header berücksichtigt und die Pakete werden die MTU von 1.500 nicht überschreiten:
1.436 Bytes [Nutzlast] + 20 Bytes [TCP-Header] + 20 Bytes [IP-Header] + 24 Bytes [GRE-Header + IP-Header] = 1.500 Bytes
Dadurch vermeidet man zwar eine Fragmentierung, doch am Ende sind die Nutzlasten etwas kleiner, was bedeutet, dass zusätzliche Pakete benötigt werden, um die Daten auszuliefern. Wenn das Ziel beispielsweise darin besteht, 150.000 Bytes Inhalt (oder etwa 150 kB) zu liefern, und wenn die MTU auf 1.500 eingestellt ist und keine anderen Layer-3-Protokolle verwendet werden, vergleichen Sie, wie viele Pakete mit und ohne GRE erforderlich sind:
Die zusätzlichen zwei Pakete verzögern den Datentransfer um Millisekunden. Dank GRE können diese Pakete jedoch eventuell schnellere Netzwerkpfade nehmen, als dies normalerweise möglich wäre, wodurch sie die verlorene Zeit wieder aufholen können.
Bei einem Distributed-Denial-of-Service-(DDoS)-Angriff versucht ein Angreifer, einen bestimmten Server oder ein Netzwerk mit Junk-Netzwerkverkehr zu überlasten – es ist so ähnlich, wie ein Restaurant mit gefälschten Lieferaufträgen zu bombardieren, bis es legitime Kunden nicht mehr beliefern kann.
Wie jedes Netzwerkprotokoll kann auch GRE zur Durchführung von DDoS-Angriffen verwendet werden. Einer der größten DDoS-Angriffe, die jemals verzeichnet wurden, ereignete sich im September 2016. Er richtete sich gegen die Website eines Sicherheitsexperten und wurde mit Hilfe des Mirai-Botnetzes durchgeführt. Die Website wurde mit Paketen überhäuft, die das GRE-Protokoll verwendeten.
Im Gegensatz zu einigen anderen Protokollen kann die Quelle für GRE-Pakete nicht gefälscht oder manipuliert werden. (Beispiele für Protokolle, bei denen dies nicht der Fall ist, finden Sie in unseren Artikeln über SYN-Fluten und DNS-Amplification-Angriffe.) Um einen großen GRE-DDoS-Angriff durchzuführen, muss der Angreifer eine große Anzahl von realen Computergeräten in einem Botnet kontrollieren.
Cloudflare schützt vor DDoS-Angriffen auf dem Netzwerk-Layer aller Art, einschließlich Angriffen mit GRE. Cloudflare Magic Transit schützt On-Premise-, Cloud- und Hybrid-Netzwerke, indem die DDoS-Abwehrfunktionen des Cloudflare Global Networks auf die Netzwerkinfrastruktur erweitert werden. Jeder angreifende Netzwerkverkehr wird herausgefiltert, ohne dabei den legitimen Datenverkehr zu verlangsamen.
Damit Magic Transit den Netzwerk-Traffic der Kunden schützen und beschleunigen kann, muss das Cloudflare-Netzwerk sicher mit den internen Netzwerken der Kunden verbunden sein. Dafür ist das GRE-Tunneling äußerst nützlich. Mithilfe von GRE-Tunneling kann sich Magic Transit über das öffentliche Internet direkt und sicher mit den Netzwerken der Cloudflare-Kunden verbinden.
Magic Transit baut auf dem Cloudflare Anycast-Netzwerk auf. Das bedeutet, dass jeder Cloudflare-Server mit einer einzigen IP-Adresse als Endpunkt für einen GRE-Tunnel dienen kann, wodurch Single Points of Failure für GRE-Tunnelverbindungen eliminiert werden. (Cloudflare verwendet diesen Ansatz auch, um Magic WAN Kunden zu verbinden). Wenn Sie mehr über die Funktionsweise von Magic Transit erfahren möchten, besuchen Sie unsere Magic Transit-Produktseite.