Linux/Tunnel

Virtuelle Schnittstellen: Tunnels

Linux hat viele Arten von Tunneln unterstützt, aber neue Benutzer können durch die Unterschiede verwirrt sein und nicht wissen, welche für einen bestimmten Anwendungsfall am besten geeignet ist

• In diesem Artikel gebe ich eine kurze Einführung in die häufig verwendeten Tunnelschnittstellen im Linux-Kernel.
• Es gibt keine Code-Analyse, nur eine kurze Einführung in die Schnittstellen und ihre Verwendung unter Linux
• Jeder mit einem Netzwerkhintergrund könnte an diesen Informationen interessiert sein
• Eine Liste der Tunnelschnittstellen sowie Hilfe zur spezifischen Tunnelkonfiguration kann mit dem Befehl iproute2 ip link help abgerufen werden.

Nach der Lektüre dieses Artikels wissen Sie, was diese Schnittstellen sind, welche Unterschiede es zwischen ihnen gibt, wann sie verwendet werden und wie man sie erstellt

IPIP-Tunnel

IPIP-Tunnel ist, wie der Name schon sagt, ein IP-over-IP-Tunnel, definiert in RFC 2003

• Der IPIP-Tunnel-Header sieht wie folgt aus

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

So erstellen Sie einen IPIP-Tunnel: 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
Add a remote internal subnet route if the endpoints don't belong to the same subnet
# 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

Der SIT-Tunnel-Header sieht wie folgt aus:

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

So erstellen Sie einen SIT-Tunnel:

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

• Der Tunnelheader sieht wie folgt aus:

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

So erstellen Sie einen ip6tnl-Tunnel:

# 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

So erstellen Sie einen VTI-Tunnel:

# 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.
• Der GRE-Header sieht wie folgt aus:

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.

So erstellen Sie einen GRE-Tunnel:

# 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

So erstellen Sie einen GRETAP-Tunnel:

# ip link add name gretap1 type gretap local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR

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:

# 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 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:

# 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

The first command configured a FOU receive port for IPIP bound to 5555; for GRE, you need to set ipproto 47

• 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:

# 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

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:

# ip link add name geneve0 type geneve id VNI remote REMOTE_IPv4_ADDR

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:

# ip link add dev erspan1 type erspan local LOCAL_IPv4_ADDR remote REMOTE_IPv4_ADDR seq key KEY erspan_ver 1 erspan IDX
or
# 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

Add tc filter to monitor traffic
# 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

Summary

Here is a summary of all the tunnels we introduced

Tunnel/Link Type	Outer Header	Encapsulate Header	Inner Header
ipip	IPv4	None	IPv4
sit	IPv4	None	IPv4/IPv6
ip6tnl	IPv6	None	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

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

If you want to learn more, read this article: Introduction to Linux interfaces for virtual networking

1. https://developers.redhat.com/blog/2019/05/17/an-introduction-to-linux-virtual-interfaces-tunnels