Linux/Tunnel: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
 
(95 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''Linux/Tunnel''' - Linux Tunnelschnitstellen


== An introduction to Linux virtual interfaces: Tunnels ==
== Beschreibung ==
Linux has supported many kinds of tunnels, but new users may be confused by their differences and unsure which one is best suited for a given use case. In this article, I will give a brief introduction for commonly used tunnel interfaces in the Linux kernel. There is no code analysis, only a brief introduction to the interfaces and their usage on Linux. Anyone with a network background might be interested in this information. A list of tunnel interfaces, as well as help on specific tunnel configuration, can be obtained by issuing the iproute2 command <code>ip link help</code>.
=== Virtuelle Schnittstellen ===
; Linux unterstützt viele Arten von Tunneln
Einführung in die häufig verwendeten Tunnelschnittstellen im Linux-Kernel
* was Schnittstellen sind
* welche Unterschiede es gibt
* wann sie verwendet werden
* wie man sie erstellt
* welche für einen bestimmten Anwendungsfall geeignet ist


This post covers the following frequently used interfaces:
Eine Liste der Tunnelschnittstellen sowie Hilfe zur spezifischen Tunnelkonfiguration kann mit dem Befehl iproute2 <code>ip link help</code> abgerufen werden


* IPIP Tunnel
=== Überblick ===
* SIT Tunnel
* ip6tnl Tunnel
* VTI and VTI6
* GRE and GRETAP
* IP6GRE and IP6GRETAP
* FOU
* GUE
* GENEVE
* ERSPAN and IP6ERSPAN
 
After reading this article, you will know what these interfaces are, the differences between them, when to use them, and how to create them.
 
== IPIP Tunnel ==
IPIP tunnel, just as the name suggests, is an IP over IP tunnel, defined in <nowiki>RFC 2003</nowiki>. The IPIP tunnel header looks like:
 
[[File:ipip.png|600px]]
 
It's typically used to connect two internal IPv4 subnets through public IPv4 internet. It has the lowest overhead but can only transmit IPv4 unicast traffic. That means you '''cannot''' send multicast via IPIP tunnel.
 
IPIP tunnel supports both IP over IP and MPLS over IP.
 
'''Note''': When the <code>ipip</code> module is loaded, or an IPIP device is created for the first time, the Linux kernel will create a <code>tunl0</code> default device in each namespace, with attributes <code>local=any</code> and <code>remote=any</code>. When receiving IPIP protocol packets, the kernel will forward them to <code>tunl0</code> as a fallback device if it can't find another device whose local/remote attributes match their source or destination address more closely.
 
Here is how to create an IPIP tunnel:
<code>On Server A:</code>
<code># ip link add name ipip0 type ipip local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR</code>
<code># ip link set ipip0 up</code>
<code># ip addr add INTERNAL_IPV4_ADDR/24 dev ipip0</code>
<code>Add a remote internal subnet route if the endpoints don't belong to the same subnet</code>
<code># ip route add REMOTE_INTERNAL_SUBNET/24 dev ipip0</code>
<code>On Server B:</code>
<code># ip link add name ipip0 type ipip local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR</code>
<code># ip link set ipip0 up</code>
<code># ip addr add INTERNAL_IPV4_ADDR/24 dev ipip0</code>
<code># ip route add REMOTE_INTERNAL_SUBNET/24 dev ipip0</code>
'''Note:''' Please replace <code>LOCAL_IPv4_ADDR</code>, <code>REMOTE_IPv4_ADDR</code>, <code>INTERNAL_IPV4_ADDR</code>, <code>REMOTE_INTERNAL_SUBNET</code> to the addresses based on your testing environment. The same with following example configs.
 
== SIT Tunnel ==
SIT stands for Simple Internet Transition. The main purpose is to interconnect isolated IPv6 networks, located in global IPv4 internet.
 
[[File:sit.png|600px]]
 
Initially, it only had an IPv6 over IPv4 tunneling mode. After years of development, however, it acquired support for several different modes, such as <code>ipip</code> (the same with IPIP tunnel), <code>ip6ip</code>, <code>mplsip</code>, and <code>any</code>. Mode <code>any</code> is used to accept both IP and IPv6 traffic, which may prove useful in some deployments. SIT tunnel also supports ISATA, and here is a usage example.
 
The SIT tunnel header looks like:
 
When the <code>sit</code> module is loaded, the Linux kernel will create a default device, named <code>sit0</code>.
 
Here is how to create a SIT tunnel:
<code>On Server A:</code>
<code># ip link add name sit1 type sit local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR mode any</code>
<code># ip link set sit1 up</code>
<code># ip addr add INTERNAL_IPV4_ADDR/24 dev sit1</code>
Then, perform the same steps on the remote side.
 
== ip6tnl Tunnel ==
ip6tnl is an IPv4/IPv6 over IPv6 tunnel interface, which looks like an IPv6 version of the SIT tunnel. The tunnel header looks like:
 
[[File:ip6tnl.png|600px]]
 
ip6tnl supports modes <code>ip6ip6</code>, <code>ipip6</code>, <code>any</code>.  Mode <code>ipip6</code> is IPv4 over IPv6, and mode <code>ip6ip6</code> is IPv6 over IPv6, and mode <code>any</code> supports both IPv4/IPv6 over IPv6.
 
When the <code>ip6tnl</code> module is loaded, the Linux kernel will create a default device, named <code>ip6tnl0</code>.
 
Here is how to create an ip6tnl tunnel:
<code># ip link add name ipip6 type ip6tnl local LOCAL_IPv6_ADDR remote REMOTE_IPv6_ADDR mode any</code>
 
== VTI and VTI6 ==
Virtual Tunnel Interface (VTI) on Linux is similar to Cisco's VTI and Juniper's implementation of secure tunnel (st.xx).
 
This particular tunneling driver implements IP encapsulations, which can be used with xfrm to give the notion of a secure tunnel and then use kernel routing on top.
 
In general, VTI tunnels operate in almost the same way as ipip or sit tunnels, except that they add a fwmark and IPsec encapsulation/decapsulation.
 
VTI6 is the IPv6 equivalent of VTI.
 
Here is how to create a VTI tunnel:
<code># ip link add name vti1 type vti key VTI_KEY local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR</code>
<code># ip link set vti1 up</code>
<code># ip addr add LOCAL_VIRTUAL_ADDR/24 dev vti1</code>
<code># ip xfrm state add src LOCAL_IPv4_ADDR dst REMOTE_IPv4_ADDR spi SPI PROTO ALGR mode tunnel</code>
<code># ip xfrm state add src REMOTE_IPv4_ADDR dst LOCAL_IPv4_ADDR spi SPI PROTO ALGR mode tunnel</code>
<code># ip xfrm policy add dir in tmpl src REMOTE_IPv4_ADDR dst LOCAL_IPv4_ADDR PROTO mode tunnel mark VTI_KEY</code>
<code># ip xfrm policy add dir out tmpl src LOCAL_IPv4_ADDR dst REMOTE_IPv4_ADDR PROTO mode tunnel mark VTI_KEY</code>
You can also configure IPsec via libreswan or strongSwan.
 
== GRE and GRETAP ==
Generic Routing Encapsulation, also known as GRE, is defined in <nowiki>RFC 2784</nowiki>
 
GRE tunneling adds an additional GRE header between the inside and outside IP headers. In theory, GRE could encapsulate any Layer 3 protocol with a valid Ethernet type, unlike IPIP, which can only encapsulate IP. The GRE header looks like:
 
Note that you can transport multicast traffic and IPv6 through a GRE tunnel.
 
When the <code>gre</code> module is loaded, the Linux kernel will create a default device, named <code>gre0</code>.
 
Here is how to create a GRE tunnel:
<code># ip link add name gre1 type gre local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR [seq] key KEY</code>
While GRE tunnels operate at OSI Layer 3, GRETAP works at OSI Layer 2, which means there is an Ethernet header in the inner header.
 
Here is how to create a GRETAP tunnel:
<code># ip link add name gretap1 type gretap local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR</code>
 
== IP6GRE and IP6GRETAP ==
IP6GRE is the IPv6 equivalent of GRE, which allows us to encapsulate any Layer 3 protocol over IPv6. The tunnel header looks like:
 
 
 
IP6GRETAP, just like GRETAP, has an Ethernet header in the inner header:
 
Here is how to create a GRE tunnel:
<code># ip link add name gre1 type ip6gre local LOCAL_IPv6_ADDR remote REMOTE_IPv6_ADDR</code>
<code># ip link add name gretap1 type ip6gretap local LOCAL_IPv6_ADDR remote REMOTE_IPv6_ADDR</code>
 
== FOU ==
Tunneling can happen at multiple levels in the networking stack. IPIP, SIT, GRE tunnels are at the IP level, while FOU (foo over UDP) is UDP-level tunneling.
 
There are some advantages of using UDP tunneling as UDP works with existing HW infrastructure, like RSS in NICs, ECMP in switches, and checksum offload. The developer's patch set shows significant performance increases for the SIT and IPIP protocols.
 
Currently, the FOU tunnel supports encapsulation protocol based on IPIP, SIT, GRE. An example FOU header looks like:
 
Here is how to create a FOU tunnel:
<code># ip fou add port 5555 ipproto 4</code>
<code># ip link add name tun1 type ipip remote 192.168.1.1 local 192.168.1.2 ttl 225 encap fou encap-sport auto encap-dport 5555</code>
The first command configured a FOU receive port for IPIP bound to 5555; for GRE, you need to set <code>ipproto 47</code>. The second command set up a new IPIP virtual interface (tun1) configured for FOU encapsulation, with dest port 5555.
 
'''Note''': FOU is not supported in Red Hat Enterprise Linux.
 
== GUE ==
Generic UDP Encapsulation (GUE) is another kind of UDP tunneling. The difference between FOU and GUE is that GUE has its own encapsulation header, which contains the protocol info and other data.
 
Currently, GUE tunnel supports inner IPIP, SIT, GRE encapsulation. An example GUE header looks like:
 
Here is how to create a GUE tunnel:
<code># ip fou add port 5555 gue</code>
<code># ip link add name tun1 type ipip remote 192.168.1.1 local 192.168.1.2 ttl 225 encap gue encap-sport auto encap-dport 5555</code>
This will set up a GUE receive port for IPIP bound to 5555, and an IPIP tunnel configured for GUE encapsulation.
 
'''Note''': GUE is not supported in Red Hat Enterprise Linux.
 
== GENEVE ==
Generic Network Virtualization Encapsulation (GENEVE) supports all of the capabilities of VXLAN, NVGRE, and STT and was designed to overcome their perceived limitations. Many believe GENEVE could eventually replace these earlier formats entirely. The tunnel header looks like:
 
which looks very similar to VXLAN. The main difference is that the GENEVE header is flexible. It's very easy to add new features by extending the header with a new Type-Length-Value (TLV) field. For more details, you can see the latest geneve ietf draft or refer to this What is GENEVE? article.
 
Open Virtual Network (OVN) uses GENEVE as default encapsulation. Here is how to create a GENEVE tunnel:
<code># ip link add name geneve0 type geneve id VNI remote REMOTE_IPv4_ADDR</code>
 
== ERSPAN and IP6ERSPAN ==
Encapsulated Remote Switched Port Analyzer (ERSPAN) uses GRE encapsulation to extend the basic port mirroring capability from Layer 2 to Layer 3, which allows the mirrored traffic to be sent through a routable IP network. The ERSPAN header looks like:
 
The ERSPAN tunnel allows a Linux host to act as an ERSPAN traffic source and send the ERSPAN mirrored traffic to either a remote host or to an ERSPAN destination, which receives and parses the ERSPAN packets generated from Cisco or other ERSPAN-capable switches. This setup could be used to analyze, diagnose, and detect malicious traffic.
 
Linux currently supports most features of two ERSPAN versions: v1 (type II) and v2 (type III).
 
Here is how to create an ERSPAN tunnel:
<code># ip link add dev erspan1 type erspan local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR seq key KEY erspan_ver 1 erspan IDX</code>
<code>or</code>
<code># ip link add dev erspan1 type erspan local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR seq key KEY erspan_ver 2 erspan_dir DIRECTION erspan_hwid HWID</code>
<code>Add tc filter to monitor traffic</code>
<code># tc qdisc add dev MONITOR_DEV handle ffff: ingress</code>
<code># tc filter add dev MONITOR_DEV parent ffff: matchall skip_hw action mirred egress mirror dev erspan1</code>
 
== Summary ==
Here is a summary of all the tunnels we introduced.
{| class="wikitable"
{| class="wikitable"
!Tunnel/Link Type
!Tunnel/Link Typ
!Outer Header
!Äußerer Header
!Encapsulate Header
!Encapsulate Header
!Inner Header
!Innerer Header
|-
|-
|ipip
|ipip
|IPv4
|IPv4
|None
|Keine
|IPv4
|IPv4
|-
|-
|sit
|sit
|IPv4
|IPv4
|None
|Keine
|IPv4/IPv6
|IPv4/IPv6
|-
|-
|ip6tnl
|ip6tnl
|IPv6
|IPv6
|None
|Keine
|IPv4/IPv6
|IPv4/IPv6
|-
|-
Zeile 250: Zeile 91:
|}
|}


; Hinweis
: Konfigurationen in diesem Artikel sind flüchtig
:* Gehen bei einen Server-Neustart verloren
:* Soll die Konfiguration nach einem Neustarts erhalten bleiben, können Netzwerkkonfigurationsdämonen wie [[NetworkManager]] oder distributionsspezifische Mechanismen verwendet werden
== Anwendung ==
=== IPIP-Tunnel ===
IPIP-Tunnel ist ein IP-over-IP-Tunnel ([[RFC 2003]])
; Tunnelheader
[[File:ipip.png|500px]]
Er wird typischerweise verwendet, um zwei interne IPv4-Subnetze über das öffentliche IPv4-Internet zu verbinden
* Er hat den geringsten Overhead, kann aber nur IPv4-Unicast-Verkehr übertragen
* Das bedeutet, dass Sie '''nicht''' Multicast über IPIP-Tunnel senden können
IPIP-Tunnel unterstützt sowohl IP über IP als auch MPLS über IP


'''Note''': All configurations in this tutorial are volatile and won’t survive a server reboot. If you want to make the configuration persistent across reboots, consider using a networking configuration daemon, such as NetworkManager, or distribution-specific mechanisms.
; Hinweis
: Wenn das <code>ipip</code>-Modul geladen wird oder ein IPIP-Gerät zum ersten Mal erstellt wird, erstellt der Linux-Kernel ein <code>tunl0</code>-Standardgerät in jedem Namensraum mit den Attributen <code>local=any</code> und <code>remote=any</code>
:* Wenn der Kernel IPIP-Protokollpakete empfängt, leitet er sie an <code>tunl0</code> als Ausweichgerät weiter, wenn er kein anderes Gerät finden kann, dessen local/remote-Attribute besser zur Quell- oder Zieladresse passen


If you want to learn more, read this article: Introduction to Linux interfaces for virtual networking
; Erstellung eines IPIP-Tunnels
Auf Server A
# ip link add name ipip0 type ipip local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR
# ip link set ipip0 up
# ip addr add INTERNAL_IPV4_ADDR/24 dev ipip0
 
Hinzufügen einer entfernten internen Subnetz-Route, wenn die Endpunkte nicht zum selben Subnetz gehören
# ip route add REMOTE_INTERNAL_SUBNET/24 dev ipip0
 
Auf Server B
# ip link add name ipip0 type ipip local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR
# ip link set ipip0 up
# ip addr add INTERNAL_IPV4_ADDR/24 dev ipip0
# ip route add REMOTE_INTERNAL_SUBNET/24 dev ipip0
 
; Hinweis
: Bitte ersetzen Sie <code>LOCAL_IPv4_ADDR</code>, <code>REMOTE_IPv4_ADDR</code>, <code>INTERNAL_IPV4_ADDR</code>, <code>REMOTE_INTERNAL_SUBNET</code> durch die Adressen, die Ihrer Testumgebung entsprechen
:* Dasselbe gilt für die folgenden Beispielkonfigurationen
 
=== SIT-Tunnel ===
SIT steht für Simple Internet Transition
* Das Hauptzweck besteht darin, isolierte IPv6-Netze, die sich im globalen IPv4-Internet befinden, miteinander zu verbinden
 
Ursprünglich hatte es nur einen IPv6-über-IPv4-Tunneling-Modus
* Nach jahrelanger Entwicklung wurden jedoch verschiedene Modi unterstützt, wie <code>ipip</code> (gleichbedeutend mit IPIP-Tunnel), <code>ip6ip</code>, <code>mplsip</code>, und <code>any</code>
* Der Modus <code>any</code> wird verwendet, um sowohl IP- als auch IPv6-Verkehr zu akzeptieren, was sich bei einigen Einsätzen als nützlich erweisen kann
* Der SIT-Tunnel unterstützt auch ISATA, und hier ist ein Anwendungsbeispiel
 
; Tunnelheader
[[File:sit.png|500px]]
 
Wenn das <code>sit</code>-Modul geladen wird, erstellt der Linux-Kernel ein Standardgerät mit dem Namen <code>sit0</code>
 
; Erstellung eines SIT-Tunnels
Auf Server A
# ip link add name sit1 type sit local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR mode any
# ip link set sit1 up
# ip addr add INTERNAL_IPV4_ADDR/24 dev sit1
 
Führen Sie dann die gleichen Schritte auf der entfernten Seite durch
 
=== ip6tnl Tunnel ===
ip6tnl ist eine IPv4/IPv6 over IPv6-Tunnelschnittstelle, die wie eine IPv6-Version des SIT-Tunnels aussieht
 
; Tunnelheader
[[File:ip6tnl.png|500px]]
 
ip6tnl unterstützt die Modi <code>ip6ip6</code>, <code>ipip6</code>, <code>any</code>. Modus <code>ipip6</code> ist IPv4 über IPv6, und Modus <code>ip6ip6</code> ist IPv6 über IPv6, und Modus <code>any</code> unterstützt sowohl IPv4/IPv6 über IPv6
 
Wenn das <code>ip6tnl</code>-Modul geladen wird, erstellt der Linux-Kernel ein Standardgerät mit dem Namen <code>ip6tnl0</code>
 
; Erstellung eines ip6tnl-Tunnels
# ip link add name ipip6 type ip6tnl local LOCAL_IPv6_ADDR remote REMOTE_IPv6_ADDR mode any
 
=== VTI und VTI6 ===
Virtual Tunnel Interface (VTI) unter Linux ist ähnlich wie Ciscos VTI und Junipers Implementierung von Secure Tunnel (st.xx)
 
Dieser spezielle Tunneltreiber implementiert IP-Kapselungen, die mit xfrm verwendet werden können, um den Eindruck eines sicheren Tunnels zu erwecken und dann Kernel-Routing zu verwenden
 
Im Allgemeinen funktionieren VTI-Tunnel fast genauso wie ipip- oder sit-Tunnel, mit dem Unterschied, dass sie ein fwmark und IPsec-Kapselung/Dekapselung hinzufügen
 
VTI6 ist das IPv6-Äquivalent von VTI
 
; Erstellung eines VTI-Tunnels
# ip link add name vti1 type vti key VTI_KEY local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR
# ip link set vti1 up
# ip addr add LOCAL_VIRTUAL_ADDR/24 dev vti1
 
# ip xfrm state add src LOCAL_IPv4_ADDR dst REMOTE_IPv4_ADDR spi SPI PROTO ALGR mode tunnel
# ip xfrm state add src REMOTE_IPv4_ADDR dst LOCAL_IPv4_ADDR spi SPI PROTO ALGR mode tunnel
# ip xfrm policy add dir in tmpl src REMOTE_IPv4_ADDR dst LOCAL_IPv4_ADDR PROTO mode tunnel mark VTI_KEY
# ip xfrm policy add dir out tmpl src LOCAL_IPv4_ADDR dst REMOTE_IPv4_ADDR PROTO mode tunnel mark VTI_KEY
 
Sie können IPsec auch über libreswan oder strongSwan konfigurieren
 
=== GRE und GRETAP ===
Generic Routing Encapsulation, auch bekannt als GRE, ist definiert in <nowiki>RFC 2784</nowiki>
 
GRE-Tunneling fügt einen zusätzlichen GRE-Header zwischen den inneren und äußeren IP-Header ein
* Theoretisch kann GRE jedes Layer-3-Protokoll mit einem gültigen Ethernet-Typ einkapseln, im Gegensatz zu IPIP, das nur IP einkapseln kann
 
; Tunnelheader
[[File:gre.png|600px]]
 
Beachten Sie, dass Sie Multicast-Verkehr und IPv6 durch einen GRE-Tunnel transportieren können
 
Wenn das Modul <code>gre</code> geladen wird, erstellt der Linux-Kernel ein Standardgerät mit dem Namen <code>gre0</code>
 
; Erstellung eines GRE-Tunnels
# ip link add name gre1 type gre local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR [seq] key KEY
Während GRE-Tunnel auf OSI-Schicht 3 arbeiten, arbeitet GRETAP auf OSI-Schicht 2, was bedeutet, dass ein Ethernet-Header im inneren Header vorhanden ist
 
[[Datei:gretap.png|700px]]
 
; Erstellung eines GRETAP-Tunnels
# ip link add name gretap1 type gretap local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR
 
=== IP6GRE und IP6GRETAP ===
IP6GRE ist das IPv6-Äquivalent von GRE, das es uns ermöglicht, jedes Schicht-3-Protokoll über IPv6 zu kapseln
 
; Tunnelheader
[[File:gre6.png|700px]]
 
IP6GRETAP hat, genau wie GRETAP, einen Ethernet-Header im inneren Header:
 
[[File:gre6tap.png|700px]]
 
; Erstellung eines GRE-Tunnels
# ip link add name gre1 type ip6gre local LOCAL_IPv6_ADDR remote REMOTE_IPv6_ADDR
# ip link add name gretap1 type ip6gretap local LOCAL_IPv6_ADDR remote REMOTE_IPv6_ADDR
 
=== FOU ===
Tunneling kann auf mehreren Ebenen des Netzwerkstapels stattfinden
* IPIP-, SIT- und GRE-Tunnel sind auf der IP-Ebene angesiedelt, während FOU (foo over UDP) ein Tunneling auf UDP-Ebene ist
 
Es gibt einige Vorteile bei der Verwendung von UDP-Tunneln, da UDP mit der bestehenden HW-Infrastruktur zusammenarbeitet, wie RSS in NICs, ECMP in Switches und Prüfsummen-Offload
* Das Patch-Set des Entwicklers zeigt erhebliche Leistungssteigerungen für die Protokolle SIT und IPIP
 
Derzeit unterstützt der FOU-Tunnel Encapsulation-Protokolle, die auf IPIP, SIT und GRE basieren
 
; Tunnelheader
[[File:fou.png|600px]]
 
; Erstellung eines FOU-Tunnels
# ip fou add port 5555 ipproto 4
# ip link add name tun1 type ipip remote 192.168.1.1 local 192.168.1.2 ttl 225 encap fou encap-sport auto encap-dport 5555
 
Der erste Befehl konfiguriert einen FOU-Empfangsport für IPIP, der an 5555 gebunden ist; für GRE müssen Sie <code>ipproto 47</code> einstellen
* Der zweite Befehl richtet eine neue virtuelle IPIP-Schnittstelle (tun1) ein, die für FOU-Kapselung konfiguriert ist, mit dem Zielport 5555
 
; '''Hinweis'''
: FOU wird in Red Hat Enterprise Linux nicht unterstützt
 
=== GUE ===
Generic UDP Encapsulation (GUE) ist eine weitere Art von UDP-Tunneling
* Der Unterschied zwischen FOU und GUE besteht darin, dass GUE einen eigenen Encapsulation Header hat, der die Protokollinformationen und andere Daten enthält
 
Derzeit unterstützt GUE-Tunnel die innere IPIP-, SIT- und GRE-Kapselung
 
; Tunnelheader
[[File:gue.png|600px]]
 
; Erstellung eines GUE-Tunnels
# ip fou add port 5555 gue
# ip link add name tun1 type ipip remote 192.168.1.1 local 192.168.1.2 ttl 225 encap gue encap-sport auto encap-dport 5555
Dies richtet einen GUE-Empfangs-Port für IPIP ein, der an 5555 gebunden ist, und einen IPIP-Tunnel, der für GUE-Kapselung konfiguriert ist
 
; Hinweis
: GUE wird in Red Hat Enterprise Linux nicht unterstützt
 
=== GENEVE ===
Generic Network Virtualization Encapsulation (GENEVE) unterstützt alle Funktionen von VXLAN, NVGRE und STT und wurde entwickelt, um deren vermeintliche Einschränkungen zu überwinden.
 
* Viele glauben, dass GENEVE diese früheren Formate irgendwann vollständig ersetzen könnte.
 
; Tunnelheader
[[File:geneve.png|600px]]
 
das VXLAN sehr ähnlich sieht
* Der Hauptunterschied besteht darin, dass der GENEVE-Header flexibel ist.
* Es ist sehr einfach, neue Funktionen hinzuzufügen, indem man den Header mit einem neuen Type-Length-Value (TLV) Feld erweitert.
* Weitere Einzelheiten finden Sie im neuesten GENEVE-ietf-Entwurf oder in diesem Artikel Was ist GENEVE?
 
Open Virtual Network (OVN) verwendet GENEVE als Standardkapselung
 
; Erstellung eines GENEVE-Tunnels
# ip link add name geneve0 type geneve id VNI remote REMOTE_IPv4_ADDR
 
=== ERSPAN und IP6ERSPAN ===
Encapsulated Remote Switched Port Analyzer (ERSPAN) verwendet GRE-Kapselung, um die grundlegende Port-Spiegelungsfunktion von Layer 2 auf Layer 3 zu erweitern, wodurch der gespiegelte Verkehr durch ein routingfähiges IP-Netzwerk gesendet werden kann
 
; Tunnelheader
[[Datei:erspan.png|700px]]
 
Der ERSPAN-Tunnel ermöglicht es einem Linux-Host, als ERSPAN-Verkehrsquelle zu fungieren und den gespiegelten ERSPAN-Verkehr entweder an einen entfernten Host oder an ein ERSPAN-Ziel zu senden, das die von Cisco- oder anderen ERSPAN-fähigen Switches generierten ERSPAN-Pakete empfängt und analysiert
* Diese Einrichtung kann zur Analyse, Diagnose und Erkennung von bösartigem Datenverkehr verwendet werden
 
Linux unterstützt derzeit die meisten Funktionen von zwei ERSPAN-Versionen: v1 (Typ II) und v2 (Typ III)
 
; Erstellung eines ERSPAN-Tunnels
# ip link add dev erspan1 type erspan local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR seq key KEY erspan_ver 1 erspan IDX
oder
# ip link add dev erspan1 type erspan local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR seq key KEY erspan_ver 2 erspan_dir DIRECTION erspan_hwid HWID
 
tc-Filter zur Überwachung des Datenverkehrs hinzufügen
# tc qdisc add dev MONITOR_DEV handle ffff: ingress
# tc filter add dev MONITOR_DEV parent ffff: matchall skip_hw action mirred egress mirror dev erspan1
 
== Konfiguration ==
=== Dateien ===
<noinclude>
 
== Anhang ==
=== Siehe auch ===
{{Special:PrefixIndex/{{BASEPAGENAME}}}}
----
ip link help
 
==== Dokumentation ====
===== Man-Page =====
===== Info-Pages =====
==== Links ====
===== Projekt =====
===== Weblinks =====
# https://developers.redhat.com/blog/2019/05/17/an-introduction-to-linux-virtual-interfaces-tunnels
# https://developers.redhat.com/blog/2019/05/17/an-introduction-to-linux-virtual-interfaces-tunnels
# https://developers.redhat.com/blog/2018/10/22/introduction-to-linux-interfaces-for-virtual-networking
[[Kategorie:Linux/Netzwerk]]
</noinclude>

Aktuelle Version vom 24. November 2024, 10:57 Uhr

Linux/Tunnel - Linux Tunnelschnitstellen

Beschreibung

Virtuelle Schnittstellen

Linux unterstützt viele Arten von Tunneln

Einführung in die häufig verwendeten Tunnelschnittstellen im Linux-Kernel

  • was Schnittstellen sind
  • welche Unterschiede es gibt
  • wann sie verwendet werden
  • wie man sie erstellt
  • welche für einen bestimmten Anwendungsfall geeignet ist

Eine Liste der Tunnelschnittstellen sowie Hilfe zur spezifischen Tunnelkonfiguration kann mit dem Befehl iproute2 ip link help abgerufen werden

Überblick

Tunnel/Link Typ Äußerer Header Encapsulate Header Innerer Header
ipip IPv4 Keine IPv4
sit IPv4 Keine IPv4/IPv6
ip6tnl IPv6 Keine IPv4/IPv6
vti IPv4 IPsec IPv4
vti6 IPv6 IPsec IPv6
gre IPv4 GRE IPv4/IPv6
gretap IPv4 GRE Ether + IPv4/IPv6
ip6gre IPv6 GRE IPv4/IPv6
ip6gretap IPv6 GRE Ether + IPv4/IPv6
fou IPv4/IPv6 UDP IPv4/IPv6/GRE
gue IPv4/IPv6 UDP + GUE IPv4/IPv6/GRE
geneve IPv4/IPv6 UDP + Geneve Ether + IPv4/IPv6
erspan IPv4 GRE + ERSPAN IPv4/IPv6
ip6erspan IPv6 GRE + ERSPAN IPv4/IPv6
Hinweis
Konfigurationen in diesem Artikel sind flüchtig
  • Gehen bei einen Server-Neustart verloren
  • Soll die Konfiguration nach einem Neustarts erhalten bleiben, können Netzwerkkonfigurationsdämonen wie NetworkManager oder distributionsspezifische Mechanismen verwendet werden

Anwendung

IPIP-Tunnel

IPIP-Tunnel ist ein IP-over-IP-Tunnel (RFC 2003)

Tunnelheader

Er wird typischerweise verwendet, um zwei interne IPv4-Subnetze über das öffentliche IPv4-Internet zu verbinden

  • Er hat den geringsten Overhead, kann aber nur IPv4-Unicast-Verkehr übertragen
  • Das bedeutet, dass Sie nicht Multicast über IPIP-Tunnel senden können

IPIP-Tunnel unterstützt sowohl IP über IP als auch MPLS über IP

Hinweis
Wenn das ipip-Modul geladen wird oder ein IPIP-Gerät zum ersten Mal erstellt wird, erstellt der Linux-Kernel ein tunl0-Standardgerät in jedem Namensraum mit den Attributen local=any und remote=any
  • Wenn der Kernel IPIP-Protokollpakete empfängt, leitet er sie an tunl0 als Ausweichgerät weiter, wenn er kein anderes Gerät finden kann, dessen local/remote-Attribute besser zur Quell- oder Zieladresse passen
Erstellung eines IPIP-Tunnels

Auf Server A 

# ip link add name ipip0 type ipip local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR
# ip link set ipip0 up
# ip addr add INTERNAL_IPV4_ADDR/24 dev ipip0

Hinzufügen einer entfernten internen Subnetz-Route, wenn die Endpunkte nicht zum selben Subnetz gehören 

# ip route add REMOTE_INTERNAL_SUBNET/24 dev ipip0

Auf Server B 

# ip link add name ipip0 type ipip local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR
# ip link set ipip0 up
# ip addr add INTERNAL_IPV4_ADDR/24 dev ipip0
# ip route add REMOTE_INTERNAL_SUBNET/24 dev ipip0
Hinweis
Bitte ersetzen Sie LOCAL_IPv4_ADDR, REMOTE_IPv4_ADDR, INTERNAL_IPV4_ADDR, REMOTE_INTERNAL_SUBNET durch die Adressen, die Ihrer Testumgebung entsprechen
  • Dasselbe gilt für die folgenden Beispielkonfigurationen

SIT-Tunnel

SIT steht für Simple Internet Transition

  • Das Hauptzweck besteht darin, isolierte IPv6-Netze, die sich im globalen IPv4-Internet befinden, miteinander zu verbinden

Ursprünglich hatte es nur einen IPv6-über-IPv4-Tunneling-Modus

  • Nach jahrelanger Entwicklung wurden jedoch verschiedene Modi unterstützt, wie ipip (gleichbedeutend mit IPIP-Tunnel), ip6ip, mplsip, und any
  • Der Modus any wird verwendet, um sowohl IP- als auch IPv6-Verkehr zu akzeptieren, was sich bei einigen Einsätzen als nützlich erweisen kann
  • Der SIT-Tunnel unterstützt auch ISATA, und hier ist ein Anwendungsbeispiel
Tunnelheader

Wenn das sit-Modul geladen wird, erstellt der Linux-Kernel ein Standardgerät mit dem Namen sit0

Erstellung eines SIT-Tunnels

Auf Server A 

# ip link add name sit1 type sit local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR mode any
# ip link set sit1 up
# ip addr add INTERNAL_IPV4_ADDR/24 dev sit1

Führen Sie dann die gleichen Schritte auf der entfernten Seite durch

ip6tnl Tunnel

ip6tnl ist eine IPv4/IPv6 over IPv6-Tunnelschnittstelle, die wie eine IPv6-Version des SIT-Tunnels aussieht

Tunnelheader

ip6tnl unterstützt die Modi ip6ip6, ipip6, any. Modus ipip6 ist IPv4 über IPv6, und Modus ip6ip6 ist IPv6 über IPv6, und Modus any unterstützt sowohl IPv4/IPv6 über IPv6

Wenn das ip6tnl-Modul geladen wird, erstellt der Linux-Kernel ein Standardgerät mit dem Namen ip6tnl0

Erstellung eines ip6tnl-Tunnels
# ip link add name ipip6 type ip6tnl local LOCAL_IPv6_ADDR remote REMOTE_IPv6_ADDR mode any

VTI und VTI6

Virtual Tunnel Interface (VTI) unter Linux ist ähnlich wie Ciscos VTI und Junipers Implementierung von Secure Tunnel (st.xx)

Dieser spezielle Tunneltreiber implementiert IP-Kapselungen, die mit xfrm verwendet werden können, um den Eindruck eines sicheren Tunnels zu erwecken und dann Kernel-Routing zu verwenden

Im Allgemeinen funktionieren VTI-Tunnel fast genauso wie ipip- oder sit-Tunnel, mit dem Unterschied, dass sie ein fwmark und IPsec-Kapselung/Dekapselung hinzufügen

VTI6 ist das IPv6-Äquivalent von VTI

Erstellung eines VTI-Tunnels
# ip link add name vti1 type vti key VTI_KEY local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR
# ip link set vti1 up
# ip addr add LOCAL_VIRTUAL_ADDR/24 dev vti1

# ip xfrm state add src LOCAL_IPv4_ADDR dst REMOTE_IPv4_ADDR spi SPI PROTO ALGR mode tunnel
# ip xfrm state add src REMOTE_IPv4_ADDR dst LOCAL_IPv4_ADDR spi SPI PROTO ALGR mode tunnel
# ip xfrm policy add dir in tmpl src REMOTE_IPv4_ADDR dst LOCAL_IPv4_ADDR PROTO mode tunnel mark VTI_KEY
# ip xfrm policy add dir out tmpl src LOCAL_IPv4_ADDR dst REMOTE_IPv4_ADDR PROTO mode tunnel mark VTI_KEY

Sie können IPsec auch über libreswan oder strongSwan konfigurieren

GRE und GRETAP

Generic Routing Encapsulation, auch bekannt als GRE, ist definiert in RFC 2784

GRE-Tunneling fügt einen zusätzlichen GRE-Header zwischen den inneren und äußeren IP-Header ein

  • Theoretisch kann GRE jedes Layer-3-Protokoll mit einem gültigen Ethernet-Typ einkapseln, im Gegensatz zu IPIP, das nur IP einkapseln kann
Tunnelheader

Beachten Sie, dass Sie Multicast-Verkehr und IPv6 durch einen GRE-Tunnel transportieren können

Wenn das Modul gre geladen wird, erstellt der Linux-Kernel ein Standardgerät mit dem Namen gre0

Erstellung eines GRE-Tunnels
# ip link add name gre1 type gre local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR [seq] key KEY

Während GRE-Tunnel auf OSI-Schicht 3 arbeiten, arbeitet GRETAP auf OSI-Schicht 2, was bedeutet, dass ein Ethernet-Header im inneren Header vorhanden ist

Erstellung eines GRETAP-Tunnels
# ip link add name gretap1 type gretap local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR

IP6GRE und IP6GRETAP

IP6GRE ist das IPv6-Äquivalent von GRE, das es uns ermöglicht, jedes Schicht-3-Protokoll über IPv6 zu kapseln

Tunnelheader

IP6GRETAP hat, genau wie GRETAP, einen Ethernet-Header im inneren Header:

Erstellung eines GRE-Tunnels
# ip link add name gre1 type ip6gre local LOCAL_IPv6_ADDR remote REMOTE_IPv6_ADDR
# ip link add name gretap1 type ip6gretap local LOCAL_IPv6_ADDR remote REMOTE_IPv6_ADDR

FOU

Tunneling kann auf mehreren Ebenen des Netzwerkstapels stattfinden

  • IPIP-, SIT- und GRE-Tunnel sind auf der IP-Ebene angesiedelt, während FOU (foo over UDP) ein Tunneling auf UDP-Ebene ist

Es gibt einige Vorteile bei der Verwendung von UDP-Tunneln, da UDP mit der bestehenden HW-Infrastruktur zusammenarbeitet, wie RSS in NICs, ECMP in Switches und Prüfsummen-Offload

  • Das Patch-Set des Entwicklers zeigt erhebliche Leistungssteigerungen für die Protokolle SIT und IPIP

Derzeit unterstützt der FOU-Tunnel Encapsulation-Protokolle, die auf IPIP, SIT und GRE basieren

Tunnelheader

Erstellung eines FOU-Tunnels
# ip fou add port 5555 ipproto 4
# ip link add name tun1 type ipip remote 192.168.1.1 local 192.168.1.2 ttl 225 encap fou encap-sport auto encap-dport 5555

Der erste Befehl konfiguriert einen FOU-Empfangsport für IPIP, der an 5555 gebunden ist; für GRE müssen Sie ipproto 47 einstellen

  • Der zweite Befehl richtet eine neue virtuelle IPIP-Schnittstelle (tun1) ein, die für FOU-Kapselung konfiguriert ist, mit dem Zielport 5555
Hinweis
FOU wird in Red Hat Enterprise Linux nicht unterstützt

GUE

Generic UDP Encapsulation (GUE) ist eine weitere Art von UDP-Tunneling

  • Der Unterschied zwischen FOU und GUE besteht darin, dass GUE einen eigenen Encapsulation Header hat, der die Protokollinformationen und andere Daten enthält

Derzeit unterstützt GUE-Tunnel die innere IPIP-, SIT- und GRE-Kapselung

Tunnelheader

Erstellung eines GUE-Tunnels
# ip fou add port 5555 gue
# ip link add name tun1 type ipip remote 192.168.1.1 local 192.168.1.2 ttl 225 encap gue encap-sport auto encap-dport 5555

Dies richtet einen GUE-Empfangs-Port für IPIP ein, der an 5555 gebunden ist, und einen IPIP-Tunnel, der für GUE-Kapselung konfiguriert ist

Hinweis
GUE wird in Red Hat Enterprise Linux nicht unterstützt

GENEVE

Generic Network Virtualization Encapsulation (GENEVE) unterstützt alle Funktionen von VXLAN, NVGRE und STT und wurde entwickelt, um deren vermeintliche Einschränkungen zu überwinden.

  • Viele glauben, dass GENEVE diese früheren Formate irgendwann vollständig ersetzen könnte.
Tunnelheader

das VXLAN sehr ähnlich sieht

  • Der Hauptunterschied besteht darin, dass der GENEVE-Header flexibel ist.
  • Es ist sehr einfach, neue Funktionen hinzuzufügen, indem man den Header mit einem neuen Type-Length-Value (TLV) Feld erweitert.
  • Weitere Einzelheiten finden Sie im neuesten GENEVE-ietf-Entwurf oder in diesem Artikel Was ist GENEVE?

Open Virtual Network (OVN) verwendet GENEVE als Standardkapselung

Erstellung eines GENEVE-Tunnels
# ip link add name geneve0 type geneve id VNI remote REMOTE_IPv4_ADDR

ERSPAN und IP6ERSPAN

Encapsulated Remote Switched Port Analyzer (ERSPAN) verwendet GRE-Kapselung, um die grundlegende Port-Spiegelungsfunktion von Layer 2 auf Layer 3 zu erweitern, wodurch der gespiegelte Verkehr durch ein routingfähiges IP-Netzwerk gesendet werden kann

Tunnelheader

Der ERSPAN-Tunnel ermöglicht es einem Linux-Host, als ERSPAN-Verkehrsquelle zu fungieren und den gespiegelten ERSPAN-Verkehr entweder an einen entfernten Host oder an ein ERSPAN-Ziel zu senden, das die von Cisco- oder anderen ERSPAN-fähigen Switches generierten ERSPAN-Pakete empfängt und analysiert

  • Diese Einrichtung kann zur Analyse, Diagnose und Erkennung von bösartigem Datenverkehr verwendet werden

Linux unterstützt derzeit die meisten Funktionen von zwei ERSPAN-Versionen: v1 (Typ II) und v2 (Typ III)

Erstellung eines ERSPAN-Tunnels
# ip link add dev erspan1 type erspan local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR seq key KEY erspan_ver 1 erspan IDX
oder
# ip link add dev erspan1 type erspan local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR seq key KEY erspan_ver 2 erspan_dir DIRECTION erspan_hwid HWID

tc-Filter zur Überwachung des Datenverkehrs hinzufügen
# tc qdisc add dev MONITOR_DEV handle ffff: ingress
# tc filter add dev MONITOR_DEV parent ffff: matchall skip_hw action mirred egress mirror dev erspan1

Konfiguration

Dateien

Anhang

Siehe auch

ip link help

Dokumentation

Man-Page
Info-Pages

Links

Projekt
Weblinks
  1. https://developers.redhat.com/blog/2019/05/17/an-introduction-to-linux-virtual-interfaces-tunnels
  2. https://developers.redhat.com/blog/2018/10/22/introduction-to-linux-interfaces-for-virtual-networking
Abgerufen von „https://wiki.foxtom.de/index.php?title=Linux/Tunnel&oldid=116500“