Proxmox Server mit GRE

Wenn Du möchtest, dass die Container auf den Proxmox-Servern keine eigene GRE-Verbindung aufbauen müssen, kannst Du die GRE-Tunnel auf den Hosts einrichten.

Hierzu benuzten wir unsere GRE-Befehle die im Interface zu sehen sind, jedoch ohne den Teil mit ip addr add

Beispiel:

ip tunnel add gre1 mode gre local 138.201.250.10 remote 5.230.205.35 ttl 255
ip addr add 10.6.6.2/30 dev gre1
ip link set gre1 up ip rule add from 5.230.228.0 table 20 prio 1
ip rule add from 5.230.228.1 table 20 prio 1
ip rule add from 5.230.228.2 table 20 prio 1
ip rule add from 5.230.228.3 table 20 prio 1
ip route add default via 10.6.6.1 dev gre1 table 20

dann müssen wir noch v4-Forwarding aktivieren: echo 1 > /proc/sys/net/ipv4/ip_forward

===== In Proxmox Bride anlegen =====

  • Melde Dich auf dem Proxmox-Webinterface an und wähle den gewünschten Host aus.
  • Wählen in der linken Menüleiste den Eintrag von gewünschten Server aus und klicke auf den Reiter „Network“.
  • Klicke auf die Schaltfläche „Create“ und wähle „Linux Bridge“ als Typ aus.
  • Gebe einen Namen für die Bridge ein, z.B. „vmbr0“.
  • Wähle das gewünschte physische Netzwerk-Interface aus, das mit der Bridge verbunden werden soll. Wenn Du mehrere Netzwerk-Interfaces hast, wähle das Interface aus, das die Verbindung zum Rest des Netzwerks herstellt, z.B. eth0.
  • Aktiviere die Option „Autostart“, damit die Bridge automatisch beim Start des Hosts gestartet wird.
  • Klicke auf „Create“, um die Bridge zu erstellen.




==== neuer Container hinzufügen =====

Um in Proxmox einen neuen Container mit einer bestimmten IP-Adresse zu erstellen, kannst Du die folgenden Schritte ausführen:


Nachdem Du den Container erstellt hast, kannst Du diesen starten und darauf zugreifen, indem Du die IP-Adresse verwendest, die Du ihm zugewiesen hast. Wenn Du weitere Netzwerk-Interfaces hinzufügen möchtest, kannst Du die oben genannten Schritte befolgen, um die Netzwerkkonfiguration des Containers anzupassen. Beachte jedoch, dass Du auch auf dem Host-System entsprechende Netzwerkkonfigurationen durchführen musst, damit das neue Interface des Containers korrekt funktioniert.

Ist es auch irgendwie möglich dass ich mein Öffentliches IPv6 Netz mit dem Noez-GRE Tunnel mischen kann und so DualStack an die VMs geben kann?
Oder geht da nur IPv4 an den VMs?

Noez bietet bisher keine IPv6-Adressen über den Tunnel an.

Wenn du bereits ein IPv6 Subnetz beispielsweise durch deinen Anbieter oder durch Tunnelbroker hast, dann kannst du das über eine zweite virtuelle Netzwerkkarte einfach an deine VMs und Container weiterrouten.

Okay.
Andere Frage ich erreich meine VM tatsächlich nicht. habe aber alles so wie hier in diesem Tutorial gemacht.

Ist die Firewall für den Container oder deiner VM aktiv? In dem Screenshot oben ist die Firewall aktiv?

Ansonsten wären weitere Informationen über dein Setup sinnvoll.

Firewall vom Proxmox auf Datacenter ebenene ist Aus. Somit hat der Haken bei der VM keinerlei wirkung.

Heißt die VMs sind nach aussen/innen hin komplett offen.

Mein Setup ist 1:1 genau wie in dem Beitrag oben. Welche infos wünscht du noch?

Was funktioniert bei dir gerade genau nicht? Die IPv4 oder die IPv6 konfiguration?

Bei Hetzner ist es beispielsweise so, dass du IPv6 zwingend gerouten musst (bridgen geht da nicht, da du für die IPv6 Adressen keine MAC-Adresse hinterlegen kannst).

Eine Konfiguration dafür ist Proxmox VE Installieren und Konfigurieren zu sehen.

Wie bei IPv4 muss auch bei IPv6 das Routing erlaubt werden. Das geht mit der Einstellung „net.ipv6.conf.all.forwarding“.

Also Als Allererstes.

Mein Server steht bei mir Zuhause im Keller.
Da is nix mit Routen oder sonst wass.

Am Proxmox liegt n Ganzes /64er V6 Netz an.

Auf die Haupt v6 IP Ist der GRE Tunnel Geschaltet, dieser soll jetzt mit der vmbr1 die IPs meines bei Noez gebuchten Netzes an die VMs geben, mit einer Zweiten Bridge richte ich dann v6 ein.

Heißt v6 läuft über vmbr0 und v4 über die an GRE gebridgte vmbr1

meine VMs bekommen mit der o.g. config aber keine v4 verbindung.

Kannst du die interne Gateway-Adresse vom Host aus pingen?
Das wäre erstmal das wichtigste, weil das würde zeigen, dass der GRE-Tunnel an sich funktionieren würde.

Du schreibst, dass deine VMs keine Verbindung bekommen. Heißt das, dass es beim Host mit der IPv4 Konfig funktioniert?

Hast du in deinem Router zu Hause GRE Traffic erlaubt? Ich habe bisher nur davon gelesen, es aber noch nicht ausprobiert.

Hast du die Mtu der Bridge festgelegt?

iface ....
    mtu 1456 # 40 Byte für IPv6 + 4 Byte für GRE

Container adaptieren die MTU dann automatisch.
Bei VMs muss bei der Netzwerkkarte entweder 1456 (also der konkrete Wert) oder 1 (1 ist ein Sonderwert und bedeutet, übernehme von Bridge) festgelegt werden.

Mehr fällt mir gerade auf die schnelle auch nicht mehr ein…

Also,

Gateway ist anpingbar sogar von der VM aus.
kann z.b. Google nicht anpingen.

in meiner Unifi DreamMachine ist die IPv6 Adresse von Proxmox als Exposed Host hinterlegt heißt alle Ports und Protokolle sind offen.

Die Hinterlegte MTU ist aktuell 1448.
Keine ahnung warum aber die ist irgendwie vorgegeben vom gre interface.

Wenn ich die IP an GRE dierekt hinterlege ist diese erreichbar via externem ping nur halt in der VM hinter der vmbr1 nicht.

zudem hab ich dass gefühl dass nach ein paar min die gre1 interface die verbindung verliert weil ich die dann neustarten muss um den gateway anzupingen …

Also mit der Dream Machine kenne ich mich leider absolut nicht aus, aber das was du mir da schilderst kommt mir bekannt vor.

Ich habe mal versucht den GRE-Tunnel zu Natten. Sodass sich ein eigenständiger Container für die Terminierung und Routing kümmern kann. Das ging komplett in die Hose. Es ging immer nur ganz kurz. Ich bin zu dem Schluss gekommen, dass es an iptables liegen muss. iptables kann (soweit ich weiß) nur statefull natten. Weshalb der state wohl nach ein paar Sekunden abgelaufen ist und somit alles gedroppet wurde.
Ich habe dann davon abgesehen es so zu machen, obwohl es mit nftables machbar sein sollte.

Kann es sein, dass die DreamMachine eine Art Deep Paket Inspection macht?

Was mich bei der MTU noch wundert ist, warum 1448? Klar kann man eine geringere verwenden, aber 1448 sieht mir ziemlich konkret aus. Auch weil es genau 8 Bytes kleiner als 1456 ist. Kann es sein, dass die DreamMachine oder auf dem Proxmox Host ein Key oder die Sequence numbers aktiviert wurden (beide können unabhängig voneinander aktiviert werden, die MTU sinkt jeweils um 4 Byte)?

Ouh wait. My brain it not braining anymore. Die 8 Bytes unterschied kommen vom der Internetverbindung…

ein DPI macht die UDM nicht.
Der Proxmox host ist ja komplett auf sich gestellt die UDM reicht alles an Proxmox weiter ohne ausnahme.

ein NAT versuche ich ja auch nicht zu erstellen. ich geh ja 1:1 nach der anleitung hier oben vor. also kein NAT meinerseits.

Die MTU ist wohl von der UDM auf 1448 beschränkt da ich ja einen Vodafone Kabel anschluss habe.

Aufbau im Keller: Vodafone Bridge Router → UDM-Pro → Proxmox

Muss ich vlt eventuell sogar ne Statische Route in der UDM hinterlegen für die IPs?

Damit interner Traffic nicht erst aufwendig über das halbe Internet und zurück geroutet wird, wäre das bei dir sinnvoll. Sollte aber erstmal nichts mit dem Problem zutun haben.

Willst du dich morgen am späten Nachmittag/frühen Abend mal über Discord unterhalten? Mir fällt grad nichts mehr ein, aber vielleicht kriegen wir es so zusammen hin.

können wir versuchen ja.

1 Like

Bin mal im offtopic-Channel. Falls ich wieder raus gehen sollte, schreib jSchoen an.

Moin, die VMs können sich jedoch untereinander erreichen, gibt es da vllt eine Lösung?

From 172.25.64.13: icmp_seq=1 Redirect Host(New nexthop: 172.25.64.14)
From 172.25.64.13: icmp_seq=2 Redirect Host(New nexthop: 172.25.64.14)
From 172.25.64.13: icmp_seq=3 Redirect Host(New nexthop: 172.25.64.14)
From 172.25.64.13: icmp_seq=4 Redirect Host(New nexthop: 172.25.64.14)
From 172.25.64.13: icmp_seq=5 Redirect Host(New nexthop: 172.25.64.14)
From 172.25.64.13: icmp_seq=6 Redirect Host(New nexthop: 172.25.64.14)
From 172.25.64.13 icmp_seq=7 Time to live exceeded
From 172.25.64.13 icmp_seq=8 Time to live exceeded
From 172.25.64.13 icmp_seq=9 Time to live exceeded