Mal wieder Proxmox und Hetzner

[meyergru]

Vorausgeschickt sei, dass ich die Konfiguration schon am laufen habe, damit gibt es aber ein Problem:

# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

auto lo
iface lo inet loopback

iface lo inet6 loopback

auto eth0
iface eth0 inet static
        address 65.99.98.21/32
        gateway 65.99.98.1
        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up echo 1 > /proc/sys/net/ipv6/conf/eth0/forwarding
        post-up iptables -t nat -A PREROUTING -i eth0 -p tcp -d 65.99.98.21 -j DNAT --to 172.17.17.1
        post-up iptables -t nat -A PREROUTING -i eth0 -p udp -d 65.99.98.21 -j DNAT --to 172.17.17.1

iface eth0 inet6 static
        address 2a01:4f9:9999:8888:7777::6666/128
        address 2a01:4f9:9999:8888:172::2/128
        gateway fe80::1

auto vmbr0
iface vmbr0 inet static
        address 65.99.98.21/32
        bridge-ports none
        bridge-stp off
        bridge-fd 0
#Proxmox WAN Bridge

iface vmbr0 inet6 static
        address 2a01:4f9:9999:8888:4e8c::6666/80

auto vmbr1
iface vmbr1 inet static
        address 172.17.17.0/31
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        post-up   iptables -t nat -A POSTROUTING -s '172.17.17.1/31' -o eth0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '172.17.17.1/31' -o eth0 -j MASQUERADE
#OPNsense WAN - Proxmox LAN

iface vmbr1 inet6 static
        address 2a01:4f9:9999:8888:172::2/80
        post-up ip -6 route add 2a01:4f9:9999:8888:173::/80 via 2a01:4f9:9999:8888:172::1
        post-up ip -6 route add 2a01:4f9:9999:0000::/64     via 2a01:4f9:9999:8888:172::1

auto vmbr2
iface vmbr2 inet static
        address 192.168.17.2/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        post-up ip route add 192.168.0.0/16 via 192.168.17.1 dev vmbr2
#LAN bridge

iface vmbr2 inet6 static

source /etc/network/interfaces.d/*

Mein Ziel war es, mit nur einer routebaren IPv4 auszukommen (65.99.98.1 - die stimmen natürlich alle nicht). Eine der VMs ist eine OpnSense VM, die als WAN 172.17.17.1 und als Gateway 172.17.17.0 hat (bei IPv6 2a01:4f9:9999:8888:172::1 und 2a01:4f9:9999:8888:172::2 als Gateway). Ich habe mir zur Erleichterung neben dem /64er Subnetz einen zusätzlichen /56er Präfix geben lassen. Auf diese Weise kann ich an vmbr1 als WAN und vmbr2 als LAN unterschiedliche IPv6 nehmen und die OpnSense per SLAAC IPs verteilen lassen. vmbr2 hat auch RFC1981-IPs (192.168.17.0/24).

Somit können alle VMs im LAN per IPv6 über die OpnSense laufen und per IPv4 entweder per Port-Forwarding oder mittels eines Reverse-Proxies.
Ausgehende Verbindungen per IPv6 sind kein Problem, die IPs werden aus dem /56er Subnetz genommen (fest oder IPv6 Privacy). Ausgehendes IPv4 läuft per NAT erst von der OpnSense auf 172.17.17.1 und dann nochmals NAT auf die endgültige IP 65.99.98..


Soweit so gut, funktioniert ganz gut.


Allerdings ist es lästig, dass aus SIcht der OpnSense die WAN-IP eben die 172.17.17.1 ist. Wenn man nämlich entsprechende DNAT-Regeln definiert, um beispielsweise Port 53 (DNS) auf eine interne Maschine weiterzuleiten, werden auch mit Port-Reflection Zugriffe vom LAN oder von der OpnSense selbst nicht auf das interne Ziel umgeleitet. Ähnliches gilt beim Zugriff aus dem LAN auf API-Funktionen per HTTP(s) auf die offiziellen IPs.

Möglicherweise könnte man das mit geschickten Regeln umschiffen - zumindest für das LAN, allerdings ist das unintuitiv.



Was mir vorschwebt, ist eine Konfiguration, bei der vmbr0 keine IPv4, sondern nur die IPv6 2a01:4f9:9999:8888:7777::6666/128 erhält, um ggf, einen Notfall-Zugriff auf den PVE zu ermöglichen. vmbr1 soll als reine Bridge erlauben, dass die OpnSense die offizielle IP 65.99.98.1 übernimmt (plus eine IPv6). vmbr2 kann so bleiben, wie es ist.


Ich kenne die entsprechenden Anleitungen für gerouteten und gebridgten Aufbau. Mein Problem liegt darin, dass ich nun eigentlich vmbr1 mit eth0 als Bridge-Interface konfigurieren müsste, damit die OpnSense selbst aktiv werden kann (mal ganz abgesehen davon, dass ich deren MAC bei Hetzner nicht aktivieren kann, weil für das erste Interface nur die Hardware-MAC genommen und nicht geändert werden kann).

Andererseits weiß ich nicht, wie ich die Notfall-IPv6 dann konfigurieren müsste.


Hat jemand so etwas am Laufen?

 

[Falk R.]

Ich habe soetwas nicht am laufen und würde das auch nie so machen. Dein Host ist die ganze Zeit frei im Internet erreichbar und soetwas mag ich nicht. Bei mir bekommt die OPNsense die öffentliche IP und der Host hat nur noch eine intere IP hinter der Sense.

 

[meyergru]

Das ist nicht richtig. Die einzige IP, mit der der Proxmox erreichbar ist, wäre bei meiner angestrebten Lösung eine IPv6, die niemand erraten kann.
Natürlich habe ich auf der OpnSense ein VPN aufgesetzt, das den Zugriff auf das LAN ermöglicht.

Auch bei meiner aktuellen Lösung ist das unproblematisch, weil alle IPv4-Ports an die OpnSense durchgeleitet werden und zusätzlich natürlich die Proxmox-Firewall aktiv ist. Zugriff auf den Promox-Host gibt es also nur per IPv6 (viel Spaß beim Erraten!) und auf dedizierte Ports.

Aber abgesehen davon: Wie sieht Deine /etc/network/interfaces aus? Du hast das Problem offenbar nicht, weil Du wirklich eth0 voll bridgest?
Wie löst Du das Problem mit der MAC?

 

[Falk R.]

Das ist nicht richtig. Die einzige IP, mit der der Proxmox erreichbar ist, wäre bei meiner angestrebten Lösung eine IPv6, die niemand erraten kann.
Natürlich habe ich auf der OpnSense ein VPN aufgesetzt, das den Zugriff auf das LAN ermöglicht.

Auch bei meiner aktuellen Lösung ist das unproblematisch, weil alle IPv4-Ports an die OpnSense durchgeleitet werden und zusätzlich natürlich die Proxmox-Firewall aktiv ist. Zugriff auf den Promox-Host gibt es also nur per IPv6 (viel Spaß beim Erraten!) und auf dedizierte Ports.

OK, wenn du alles sauber trennst, aber leider sieht man ganz viele offen erreichbare PVE.

Aber abgesehen davon: Wie sieht Deine /etc/network/interfaces aus? DU hast das Problem offenbar nicht, weil Du wirklich eth0 voll bridgest?
Wie löst Du das Problem mit der MAC?

Welches problem mit der MAC? Du kannst ja theoretisch der Sense auch die MAC der physischen NIC geben, wenn du die NIC nur als Bridge ohne Interface nutzt. Du kannst natürlich auch die NIC an die VM durchreichen oder deine virtuelle NIC freischalten lassen.

 

[meyergru]

Ja, klar - einen offenen PVE sollte man vermeiden, der Normalfall ist immer, über das VPN zu gehen.

Ich habe jetzt eine Anleitung gefunden, bei der jemand dem physischen Interface eine andere MAC zugewiesen hat und dann in der OpnSense dem WAN-Interface die vorhandene MAC gegeben. Das würde aber in Kombination mit einer Notfall-IPv6 wohl nicht gehen, oder eben nur über die OpnSense, die dann wieder auf dem kritischen Pfad liegt.

Ist halt alles nicht so einfach, wenn man nicht per Netzwerk auf die OpnSense bzw. den Proxmox kommt. Eine Fehlkonfiguration führt zum Verbindungsverlust und eine Lara hilft auch nur bedingt, weil man damit weder auf den PVE noch auf die OpnSense kommt.

Ich fürchte, so etwas klappt nur mit einer zweiten IP (die dann eine zweite MAC erlaubt). Oder man muss darauf verzichten und aktiviert im Notfall per Rescue-System eine alternative Netzwerk-Konfiguration, bei der man danach auf den PVE direkt draufkommt und dort ggf. einen alten Snapshot zurückholt.

Ich probiere das nochmal, wenn ich den Server komplett umgezogen habe mit dem alten Server...

 

[Falk R.]

Ja, klar - einen offenen PVE sollte man vermeiden, der Normalfall ist immer, über das VPN zu gehen.

Ich habe jetzt eine Anleitung gefunden, bei der jemand dem physischen Interface eine andere MAC zugewiesen hat und dann in der OpnSense dem WAN-Interface die vorhandene MAC gegeben. Das würde aber in Kombination mit einer Notfall-IPv6 wohl nicht gehen, oder eben nur über die OpnSense, die dann wieder auf dem kritischen Pfad liegt.

Ist halt alles nicht so einfach, wenn man nicht per Netzwerk auf die OpnSense bzw. den Proxmox kommt. Eine Fehlkonfiguration führt zum Verbindungsverlust und eine Lara hilft auch nur bedingt, weil man damit weder auf den PVE noch auf die OpnSense kommt.

Ich fürchte, so etwas klappt nur mit einer zweiten IP (die dann eine zweite MAC erlaubt). Oder man muss darauf verzichten und aktiviert im Notfall per Rescue-System eine alternative Netzwerk-Konfiguration, bei der man danach auf den PVE direkt draufkommt und dort ggf. einen alten Snapshot zurückholt.

Genau das ist das Problem. Entweder ich habe nicht so hohe Anforderungen und kämpfe im Notfall mit dem Rescue System oder wenn man es einfach und schnelles Troubleshooting haben will, zweite IP.

 

[meyergru]

So, ich weiß jetzt, wie das funktioniert. Ganz grob beschrieben hier: https://github.com/boost-next/proxmox-single-node

Aber:

1. Ohne LARA ist das einzurichten praktisch unmöglich, weil man es auf Anhieb nie perfekt hinbekommt.
2. Man muss mit der OpnSense auch ziemlich herumtricksen, um die Konfiguration vorab so hinzustellen, dass es nachher funktioniert, ohne sich im laufenden Betrieb ins Knie zu schießen (man kann nur wenige Einstellungen per Konsole ändern, für vieles bräuchte man Netzwerkzugriff).
3. Es gibt ein paar Probleme, die vermutlich mit der Verhinderung des MAC-Spoofings zu tun haben. Der Zugriff mit der IPv6 über den Proxmox auf der Bridge funktioniert nur begrenzt lange, danach ist er weg. Offenbar werden die Neighbor-Einträge STALE.
   In dem Repo wird ein Hintergrund-Job gestartet, der alle 10 Sekunden den Neighbor-Cache flusht. Das geht zwar, aber bestehende IPv6-Verbindungen können dabei gelegentlich abreißen. Ich habe es auch mal mit PERMANENT-Einträgen versucht, aber auch die werden dann stale.
4. Außerdem funktioniert nur eine einzige IPv6, bei mehreren gibt es Stress.
   

Das alles fiele wohl mit einer zweiten IP weg - nicht so sehr wegen der IP selbst, sondern, weil man im Robot bei Hetzner dann eine zweite MAC anlegen kann.

Oder man verzichtet eben ganz auf den Fallback und nutzt ggf. eine alternative /etc/network/interfaces, wenn man mal etwas vergurkt hat. Ist halt ewiges Rumgegurke mit einem Rescue-System, potentiell verkompliziert durch einen QEMU, den man braucht, um den Proxmox zu starten (a. wegen ZFS und b. weil /etc/pve nicht auf dem Root-Dateisystem liegt, sondern ein Fuse-FS ist).