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 routen das Paket: ndppd installiert werden auf Host A.

apt install ndppd -y

Dann erstellen wir eine Konfiguration in /etc/ndppd.conf

proxy eth0 {
    rule {{Erste-Single-IPv6}}/128 {
        static
    }

    rule {{Erste-Zweite-IPv6}}/128 {
        static
    }
  ...
}

# Jetzt aktivieren wir den NDP Proxy Daemon
systemctl enable ndppd --now

Somit werden die routen + systemd Service 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: gretap
            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 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:

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

Und um die Regeln dauerhaft zu speichern:

apt-get install iptables-persistent -y

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 🙂