GRETAP und Netplan – Linux GRE Routing in Proxmox Tutorial

Willkommen!

Herzlich Willkommen zu diesem Tutorial 🙂

In diesem Tutorial werden wir folgende Inhalte zeigen und erklären:

1. GRE Tunnel Einleitung

Was ist also nun GRE? GRE ist ein Protokoll, was eben die Möglichkeit bietet, von Server zu Server eine Verbindung herzustellen. Dazu gibt es immer jeweils pro Interface zwei der Peers die sich verbinden und es somit auch reintheoretisch IPv4 oder auch IPv6 rüber routen lassen. Aber auch Interne Netzwerke für nur reinen Internen Datenaustausch wären möglich.

Das Generic Routing Encapsulation (GRE) ist ein Netzprotokoll, welches dazu dient, andere Protokolle einzukapseln und so in Form eines Tunnels über das Internet Protocol (IP) zu transportieren.

Wikipedia.org

Gibt es also somit auch die Möglichkeit, GRE als Bridge in Proxmox zu verwenden?

GRETAP wäre hierfür die Einfachste Umsetzung. GRETAP fungiert über Layer2 und GRE über Layer3. Die aktuellen Forschungen via Netplan GRETAP zu bridgen über Layer2 werden hier heute vorgestellt.

Auch das Layer 3 GRE wäre genauso möglich hier ist nur der Unterschied das wir automatische Skripte (.sh – Bash) erstellen müssten um das ganze bei jeden reboot, anzulegen.

Der Unterschied das GRE (Layer 3) noch über den Host B intern muss und dort mit IP Rules, IP Route Tables und Internen Gateways einsatzbereit gemacht werden muss.

GRETAP (Layer 2) Bridge geht somit direkt von Host B zu Host A und Host B wäre somit nur der Client des Verbindungsaufbaus und nicht der zweite zusätzliche Router. Letztendlich muss aber trotzdem IPv4.Forward aktiviert werden oder auch Optional IPv6.All.Forwarding in der /etc/sysctl.conf.

2. GRE Tunnel erstellen

Wir verwenden hierzu das Netplan.io Paket in Linux. Dieses kann entweder als Hauptfunktion im Netzwerk fungieren (Zumeist bei Ubuntu Systemen ab Werk aktiv) oder auch bei Debian Systemen seperat.

Keine Sorge, auch wenn Ihr jetzt das Netplan.io nachinstalliert, gehen dabei keine derzeitigen Netzwerkeinstellungen weg. Denn Netplan übernimmt nur das was man Ihn auch sozusagen mitteilt das was man erstellen, übernehmen oder ändern möchte 🙂

# Wir installieren Netplan auch auf Host A
apt install netplan.io -y

# Auf Server A
echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp
echo 1 > /proc/sys/net/ipv6/conf/default/proxy_ndp
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
echo "net.ipv6.conf.all.forwarding=1" >> /etc/sysctl.conf
sudo sysctl -p

# Achtung: Nur Temporär aktiv - Für Fix in z.B /etc/network/interfaces als Post-up speichern.
post-up echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp
post-up echo 1 > /proc/sys/net/ipv6/conf/default/proxy_ndp

Proxy ARP ist notwendig um eben alle Interfaces die Kommunikation und die Auflösung von IP zu MAC zu gestatten. Somit können direkt die Statischen Routen für Öffentliche IP-Adressen die über GRE rüber geroutet werden als aktive Verbindung erkannt werden über ARP.

Wichtig:

Für IPv6 muss hierfür für die Statischen IPv6 via ip neighbour auf permanent gesetzt werden.

Anmerkung: IPv6 ist noch in der sogenannten Tests Phase. Ich kann nicht bei jedem Provider garantieren dass die routen direkt schalten. Bei z.B Hetzner würden keine Probleme auftauchen aber bei anderen die eine andere Haupt Gateway Einstellung haben kann sich dies verzögert schalten je nachdem was euer Provider für Setups hat.

ip -6 neigh add proxy Eure-erste-IPv6/128 dev eth0 nud permanent
ip -6 neigh add proxy Eure-zweite-IPv6/128 dev eth0 nud permanent
...

# Examples
root@vServer:~# ip a
---
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
---
# Unser Haupt vServer Device ist also eth0

ip -6 neigh add proxy fdde:8031:f79f:8ac5::1/128 dev eth0 nud permanent
ip -6 neigh add proxy fdde:8031:f79f:8ac5::2/128 dev eth0 nud permanent

Somit werden die routen dauerhaft aktiv gehalten für IPv6.

Das kann bei IPv6 Routing Problemen helfen. 🙂

Hier bitte speichern: /etc/netplan/tunnel1.yaml

# Für IPv4 Tunnels auf Server A  
network:
    renderer: networkd
    tunnels:
        tunnel1:
            mode: gretap
            local: Deine-IPv4-von-ServerA
            remote: Deine-IPv4-von-ServerB
            addresses:
                - InternalSubnet/30
            routes:
                - to: Statische-v4/32
                  via: InternalGateway-254/32
                - to: Statische-v4/32
                  via: InternalGateway-254/32

Und für den IPv6 Tunnel Aufbau:

# Für IPv6 Tunnels auf Server A  
network:
    renderer: networkd
    tunnels:
        tunnel1:
            mode: ip6gretap
            local: Deine-IPv6-von-ServerA
            remote: Deine-IPv6-von-ServerB
            addresses:
                - InternalSubnet/30
            routes:
                - to: Statische-v4/32
                  via: InternalGateway/32
                - to: Statische-v4/32
                  via: InternalGateway/32

Hier sind zwei der Netplan Examples. Diese könnnen auch für mehrere Tunnels über Netplan verwendet werden. Achtet dabei bei Duplizieren auf: Tunnel1 => Tunnel2 für das nächste Interface und immer höher. Die Interfaces dürfen nicht in z.B zwei verschiedenen Konfigurationen gleichzeitig heißen.

Auch im IPv6 Tunnel Aufbau Example wäre es möglich bei aktiven v6 GRE’s, Öffentliche IP-Adressen sei es IPv4 oder IPv6 zu routen. Jeweils pro Route muss zumeist ein Internal Gateway mit genannt werden.

Diesen könnt Ihr beliebig zuweisen 🙂

Tipps & Tricks.

Um z.B die Subnetze gleich zu halten und nicht Gateways mit Öffentlichen IP-Adressen extra zu verbrauchen: Nimmt einfach die Gleiche Subnetz Range und setzt hier einen selbst zugewiesenen Gateway. Im Endeffekt setzen wir einfach eine Globale IPv4 oder v6 auf das Lokal Interface als Gateway bei Host A. Dabei muss nicht zwingend diese Adresse dem Server zugewiesen werden:

Sagen wir ich habe eine IPv4 Range von: 5.230.92.0/24 => Ich setze Beispielswiese den Gateway (Nicht davon direkt auf Host A den echten Gateway der vom Provider kommt) sondern einfach 5.230.92.254.

Nochmal zu erläuterung:

Gateway => 5.230.92.254 => Gilt somit für meine Öffentlichen IP-Adressen innerhalb des GRE Tunnels. (Simuliert).

# Jetzt testen wir alle Konfigurationen und bestätigen die Änderungen nochmals mit ENTER
sudo netplan try

3. Die Unterschiede zu ip6gretap und gretap

Im Endeffekt nutzen wir bei GRETAP das IPv4-Protokoll zum Verbindungsaufbau.

Es ist das älteste Protokoll seit sozusagen der Entstehung des Internets.

Somit wäre automatisch ip6 GRETAP die moderne Lösung für den Verbindungsaufbau.

Manche setzen sogar aktiv darauf auf v6 Verbindungen da es ein

1. Neues Protokoll ist

2. Man die Möglichkeit hat sogar innerhalb der Tunnelverbindung auch IPv4 Adressen zu routen

3. Es die Stabilität verbessert

4. Host B mit Host A verbinden

Und wo ein Tunnel Anfängt, kommt er auch irgendwann zu seinem Ziel. 🙂

Das wäre der Host B denn dieser baut jetzt eine Tunnel Verbindung zum Host A auf.

Hier bitte speichern: /etc/netplan/tunnel1.yaml

# Auf Host B für den IPv4 Tunnel Aufbau
network:
    renderer: networkd
    bridges:
        vmbr1:
            interfaces: [ tunnel1 ]
    tunnels:
        tunnel1:
            mode: gretap
            local: Deine-IPv4-von-ServerB
            remote: Deine-IPv4-von-ServerA

# Auf Host B für den IPv6 Tunnel Aufbau
network:
    renderer: networkd
    bridges:
        vmbr1:
            interfaces: [ tunnel1 ]
    tunnels:
        tunnel1:
            mode: ip6gretap
            local: Deine-IPv6-von-ServerB
            remote: Deine-IPv6-von-ServerA

In diesem Example sagen wir Netplan, dass wir er eine vmbr1 Birdge anlegen soll und diese mit tunnel1 verbinden (Bridged) soll.

Die vmbrX können immer je nach neuer Tunnelverbindung hochgezählt werden. Genauso auch bei tunnel1, tunnel2 etc. 🙂

# Jetzt testen wir alle Konfigurationen und bestätigen die Änderungen nochmals mit ENTER
sudo netplan try

Damit auch Proxmox die neue vmbrX erkennen kann, muss diese noch in /etc/network/interfaces hinterlegt werden.

# Am Ende der Netzwerk Config
iface vmbr1 inet manual
# Oder für IPv6 Tunnel Bridge
iface vmbr1 inet6 manual

# Jetzt Reloaden wir die Netzwerkkonfiguration
ifreload -a

Jetzt nur noch speichern und fertig! 🙂 Jetzt sehen wir in der Proxmox GUI unter Netzwerk das die z.B vmbr1 zu sehen ist und auch somit nutzbar ist.

5. Tipps & Tricks.

Um MTU und Geschwingkeitsprobleme beheben zu können, helfen zumeist folgende Befehle auf Host A:

# Für IPv4
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -t mangle -A OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# Für IPv6

ip6tables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
ip6tables -t mangle -A OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Und um die Regeln dauerhaft zu speichern:

apt-get install iptables-persistent -y
# Firewall Regeln dauerhaft speichern
iptables-save > /etc/iptables/rules.v4
ip6tables-save > /etc/iptables/rules.v4

Man wird während des Installierens aufgefordert zweimal mit Enter zu bestätigen. Das machen wir und danach ist alles im System dauerhaft gespeichert und das auch wenn der Server mal einen Neustart benötigt 🙂

Wichtige Informationen um GRE und GRETAP

Seit neustem ist mir nach Feedback aufgefallen dass bei manchen Providern eine Verbindungen nicht zu stande kommt da z.B die vom Provider vorgeschaltete DDoS Mitigration oder andersweitigen Firewall Systeme per Haus GRE Protokoll blockieren. Das kann ein Grund dafür sein dass GRE schwer zu filtern ist in bestimmten Angriffsmustern.

Das nicht nur die jeweilige Person darunter schaden nimmt zwecks Ausfällen und Blockieren des Traffics, sondern ist auch zumeist wie eine offene Schwachstelle in der DDoS Mitigration wenn man das Protokoll zulässt.

Was ich aber auch im allgemeinen hier auf meinen Blog als zweite Lösung mit Wireguard in kürze Lösen möchte.

Auch möchte ich meine Erfahrungen zwecks Routing bei verschiedenen Hosting Providern teilen und werde noch eine Auflistung verschiedener Prepaid Providern veröffentlichen und Ihr könnt euch dann für eure Anwendungsfälle das beste Bild machen können wo man am Besten IPv4 und IPv6 Adressen fürs routen herbekommen kann.