Herzlich Willkommen!
Herzlich Willkommen zu den Erweiterten Tutroial über GRE Tunnel mit Proxmox 🙂 Heute werden wir eine Linux Brücke erstellen über Proxmox, womit man die Möglichkeit hat, externe IP-Adressen rüber zu routen und damit dann zu virtualisieren. Der Vorteil beim Hosting Provider Noez ist, dass die IPv4-Preise sehr gering sind. Nur 0,50 Euro je IPv4 Adresse. Ich habe auch bereits ein Erfahrungsbericht über Noez veröffentlicht. Nun werden wir uns in diesem Tutorial nochmals näher mit beschäftigen und sende euch natürlich wieder Examples raus für’s testen 🙂
1. Trage bei Noez deinen Ziel-Server ein
2. Code Beispiele für die Konfiguration mit GRE
auto vmbr2
iface vmbr2 inet static
address Erste-Noez_IP-von-GRE
netmask # Bei subnetzen immer die Netzmaske anpassen. z.B /27, /28, /26, /32 etc.
bridge_ports none
bridge_stp off
bridge_fd 0
up ip link set dev gre1 up
pre-up /root/gre.sh # Pfad bitte zu euren anpassen.
pre-up ip link add name gre1 type gretap local HauptIP-vom_Server remote Noez_Remote_IP ttl 255
pre-up ip addr add Internal-Subnet/30 dev gre1
pre-up ip route add default via Internal-Gateway dev gre1
post-up ip link set vmbr2 mtu 1462
post-down ip link set dev gre1 down
post-down ip link del gre1
#noez-gre
nano /root/gre.sh
#!/bin/sh
# Mein Pfad war ursprünglich: /root/gre.sh
# Gre Tunnel erstellen
ip tunnel add gre1 mode gre local HauptIP-vom_Server remote Noez_Remote_IP ttl 255
ip addr add 172.18.185.58/30 dev gre1
ip link set gre1 up
sudo ip route add 5.230.xxx.xx/27 dev vmbr2 # Hier dein Subnetz eintragen also erste IP vom ganzen Subnetz vom z.B /27 Subnetz.
# Für einzelne IPs geht dies so
sudo ip route add 5.230.xxx.x1/32 dev vmbr2
sudo ip route add 5.230.xxx.x2/32 dev vmbr2
# also jede einzelne IPv4 mit der Netzmaske /32 zur route hinzufügen.
# Standardroute hinzufügen
ip route add default via Internal-Gateway dev gre1 table 20
sudo brctl addif vmbr2 gre1
# Jetzt setzen wir das Skript noch rechte.
sudo chmod 777 /root/gre.sh
# Jetzt muss nur noch das Netzwerk neugestartet werden.
sudo service networking restart
# Mein Output nach den Netzwerk Reload
sudo service networking status
● networking.service - Network initialization
Loaded: loaded (/lib/systemd/system/networking.service; enabled; preset: enabled)
Active: active (exited) since Sat 2023-08-12 11:40:18 UTC; 1 day 10h ago
Docs: man:interfaces(5)
man:ifup(8)
man:ifdown(8)
Main PID: 156418 (code=exited, status=0/SUCCESS)
CPU: 1.478s
Aug 12 11:40:17 pve.anuacp.de sudo[156561]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
Aug 12 11:40:17 pve.anuacp.de sudo[156561]: pam_unix(sudo:session): session closed for user root
Aug 12 11:40:17 pve.anuacp.de sudo[156566]: root : PWD=/ ; USER=root ; COMMAND=/usr/sbin/brctl addif vmbr2 gre1
Aug 12 11:40:17 pve.anuacp.de sudo[156566]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
Aug 12 11:40:17 pve.anuacp.de sudo[156566]: pam_unix(sudo:session): session closed for user root
Aug 12 11:40:17 pve.anuacp.de networking[156435]: warning: vmbr2: pre-up cmd '/root/gre.sh' failed: returned 1 (Cannot find device "vmbr2"
Aug 12 11:40:17 pve.anuacp.de networking[156435]: bridge vmbr2 does not exist!
Aug 12 11:40:17 pve.anuacp.de networking[156435]: )
Aug 12 11:40:17 pve.anuacp.de /usr/sbin/ifup[156435]: warning: vmbr2: pre-up cmd '/root/gre.sh' failed: returned 1 (Cannot find device "vmbr2"
bridge vmbr2 does not exist!
)
Aug 12 11:40:18 pve.anuacp.de systemd[1]: Finished networking.service - Network initialization.
Dort sind natürlich kleinere Fehler zu sehen diese können aber ignoriert werden. Denn vmbr2 wurde bereits im Anschluss vom networking service aktiviert. Also, sobald vmbr2 bei Proxmox erscheint und dort aktiv auf ja steht dann gilt nichts weiter zu beachten.
Was bedeuten die Code Examples?
Ersetze deine IPs von denen die Du beispielsweise bei Noez gemietet hast:
- Internal-Subnet => Bei Noez unter Kundebereich => Services => Auf Produkt gehen => Auf Aktionen und kopiere dir das Internal-Subnet/30 und füge es im Code Example wo es auch steht ein.
- Internal-Gateway => Wo oben im gleichen Prozess bis hin zu Aktionen und dann ersetze im Code jeweils mit gleicher Bezeichnung das Internal-Gateway zu deinem.
- Trage deine IPv4-Adressen mit exat gleicher Netzmaske in das gre.sh Skript ein. Solltest du nur einzelne IPv4-Adressen gebucht haben und kein Subnetz, so nutzt immer die Netzmaske /32 und kopiere sudo ip route add … so viel bis alle deine IPs im gre.sh Skript vorhanden sind.
Dies muss nicht zwingend vorkommen aber kann. Mit einer neuen Mac Adressen generierung ist das Problem gelöst. Dazu unter der VM im Anschluss auf Netzwerkkarte gehen und mac rauslöschen bis auto steht und dann auf ok.
Damit dies sich ändert muss mindestens ein LXC Container oder KVM unter dieser Linux Bdrige betrieben werden. Danach, wenn man erfolgreich Gateway und IP in KVM oder LXC eingegeben wurde, geht die vmbr2 Bridge im UP Modus.
Für mein Setup die erste IP vom Noez IP Pool. Also wie oben in der Netzwerk Konfiguration zu sehen im Bereich: address Erste-Noez_IP-von-GRE.
- Achte darauf das net.ipv4.ip_forward aktivert ist. Dieser Schritt wird weiter unten beschrieben.
- Achte darauf die richitge IPv4-Adresse bei Noez im Kundeninterface eingetragen habt. Der GRE Tunnel ist nur dann erreichbar, wenn local und remote die jweiligen IPs übereinstimmen im zusammenhang von der eingetragenden Noez Ziel-Server-IP im Kunden Interface.
- Wenn es Probleme mit dem Netzwerk gibt z.B MTU Problem so setzt die passende MTU für die Linux Bridge: sudo ip link set vmbr2 mtu 1462
3. So kannst Du überprüfen ob alles funktioniert
# Mit dem Befehl ip a und Zusätzlich mit: | grep kannst Du den aktuellen Linux Bridge status von z.B vmbr2 überprüfen.
ip a | grep vmbr2
# Output Example
166: vmbr2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1462 qdisc noqueue state UP group default qlen 1000
inet 5.230.226.96/27 scope global vmbr2
182: veth100i0@if181: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1462 qdisc noqueue master vmbr2 state UP group default qlen 1000
190: veth100i1@if189: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1462 qdisc noqueue master vmbr2 state UP group default qlen 1000
192: veth100i2@if191: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1462 qdisc noqueue master vmbr2 state UP group default qlen 1000
196: veth100i3@if195: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1462 qdisc noqueue master vmbr2 state UP group default qlen 1000
Sollte also bei der z.B vmbr2 Bridge erst down stehen und nicht up, so erstellt eine VM und prüft nach erfolgreicher Konfiguration der VM ob hier vmbr2 dann auf up geht.
ip route show
# Example Output
# Hier werden die aktiven routen angezeigt. Achte dabei ob alles passt mit deiner Linux Bridge z.B vmbr2.
default via 172.31.1.1 dev vmbr0 proto kernel onlink
5.230.226.96/27 dev vmbr2 proto kernel scope link src 5.230.226.96
172.18.185.56/30 dev gre1 proto kernel scope link src 172.18.185.58
root@pve:~#
nano /etc/sysctl.conf
net.ipv4.ip_forward=1 # Bitte dies in sysctl auf aktiv setzen.
# Im Anschluss übernehmen wir die neue Konfiguration.
sudo sysctl -p
Support
Da dies ein etwas aufwendiger Schritt für mancher sein kann, biete ich kostenlosen Discord, Email oder TeamSpeak Support an. Ich versuche dann für den jeweilen Nutzer ein gutes Routing zu schaffen und das auch natürlich alles funktioniert. Sollte noch etwas in diesem Beitrag fehlerhaft sein oder man mir eine Verbesserung geben möchte bezüglich GRE oder auch Allgemein, so könnt Ihr natürlich einen Kommentar auf diesem Beitrag verfassen oder das Kontaktformular vom Blog nutzen. 🙂
Kontakt auf meinen anderen Kanälen
- Discord Name: rawnetworks
- Twitter: Hier klicken
- TeamSpeak: janhill.eu
- Email: privat@janhill.email
Schreibe einen Kommentar