[Sammelthread] Proxmox Stammtisch

[Skream]

Hi zusammen,

keine Ahnung ob ich hier richtig bin oder ob das Thema eher in den Bereich Linux/Ubuntu einzugliedern ist

Ich betreibe einen kleinen Homeserver mit Proxmox, auf welchem diverse LXC und VMs laufen.
Dabei läuft in einer VM Openmediavault, welche als NAS im Netzwerk dient. In einem LXC habe ich auf Ubuntu 18.04 TVHeadend als TV-Server eingerichtet. Nun möchte ich gerne von TVHeadend Sendungen direkt auf meinem NAS aufnehmen können.

Hierzu habe ich auf meinem OMV einen NFS-Share für mein Netz eingerichtet (192.168.178.0/24 und rw, da auch noch andere IP-Adressen darauf zugreifen) und in meinem LXC diesen Share entsprechend gemountet. Funktioniert auch so weit, ich kann sowohl mit root als auch mit hts (dem TVHeadend-User) auf diesen Share zugreifen.
Möchte ich jedoch mit TVHeadend etwas aufnehmen, erfolgt nach kurzer Zeit die Fehlermeldung, dass kein File erstellt wurde. Ich vermute, dass es irgendwie mit den Berechtigungen zu tun hat, da vermutlich hts nicht auf den Share schreiben darf, sondern nur root?

Hat jemand von euch Erfahrung, wie man das bewerkstelligen könnte?

 

[jimbolo]

Funktioniert auch so weit, ich kann sowohl mit root als auch mit hts (dem TVHeadend-User) auf diesen Share zugreifen.

Nur, weil du auf den Share zugreifen kannst und dein lokaler hts User in dem Ordner Dateien erstellen kann, heißt das noch nicht, dass du auch über NFS als "hts" zugreifst, geschweige denn über NFS auch mehr als Leserechte bekommst, oder?

 

[Skream]

Nur, weil du auf den Share zugreifen kannst und dein lokaler hts User in dem Ordner Dateien erstellen kann, heißt das noch nicht, dass du auch über NFS als "hts" zugreifst, geschweige denn über NFS auch mehr als Leserechte bekommst, oder?

Das stimmt natürlich, allerdings ging ich bisher immer davon aus, dass bei einer Konfiguration von 192.168.178.0/24 und RW (also Read und Write) alle im Netz befindlichen Geräte auf den Share lesend und schreibend zugreifen können.

Die Export-Datei des OMV sieht aktuell wie folgt aus:

Spoiler: Klick

# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
/export/Dokumente 192.168.178.0/24(fsid=1,rw,subtree_check,insecure)
/export/Media 192.168.178.0/24(fsid=2,rw,subtree_check,insecure)

# NFSv4 - pseudo filesystem root
/export 192.168.178.0/24(ro,fsid=0,root_squash,no_subtree_check,hide)

Kann natürlich sein dass ich hier ein vollkommen falsches Bild von der Thematik habe und lasse mich daher gerne belehren bzw. mir helfen, das Problem zu lösen

 

[Shihatsu]

Moin, ich mache gerade meine ersten Schritte mit opnSense. Dazu habe ich gleich mal ein paar Fragen.
Ich habe ein Netz (192.168.254.1/24) das durch meine Fritzbox als Router, Gateway und DHCP Server als Anker gebildet wird.
Dazu habe ich eine opnSense laufen, diese hat 2 physische Netzwerkschnittstellen und eine virtuelle (es ist eine proxmox-VM mit durch gereichter Karte).
An diesen beiden Ports hängt einmal WAN zur Fritzbox (per DHCP, ist damit im Netz der Fritze und die Fritzbox macht quasi noch NAT nach außen) und einmal LAN - das ist mein neues Netz (10.10.0.1/24).
In diesem neuen Netz befinden sich jetzt alle meine Clients, teilweise statisch, teilweise DHCP. Einer dieser Clients ist ein piHole mit unbound, der DNS für das Netz spielen soll.
Damit ich die Fritzbox noch erreichen kann, habe ich ein Single Gateway hinzugefügt (die opnSense selber) und eine Route "Fritzroute" angelegt, die über dieses Gateway auf 192.168.254.0/24 zeigt.

Jetzt geht es daran aus diesem einen Netz viele segmentierte Netze via VLANs zu machen.
Grundsätzlich habe ich das Thema verstanden, aber beim "ausprobieren" und folgen diverser "Guides" habe ich gleich am Anfang schon ein Problem, das ich erst einmal nachvollziehen will, bevor ich weitermache - ich will das verstehen. Sobald ich ein VLAN hinzufüge (Parent interface LAN, VLAN tag 11, VLAN priority Best Effort, Description testVLAN11), verliere ich komplett die Gateway-funktionalität der opnSense - intern erreiche ich noch alles, extern nicht. Löschen des VLANs reicht auch nicht als Lösung, sondern ich muss tatsächlich unter Interfaces -> Overview -> WAN Interface auf DHCP Reload gehen um wieder eine Gateway funktionalität zu haben.

Warum ist das so, was passiert dort, und vor allem: Was mache ich falsch und wo könnte ich anfangen mich reinzulesen zu diesem Problem?

Danke und LG.

 

[jimbolo]

In diesem neuen Netz befinden sich jetzt alle meine Clients, teilweise statisch, teilweise DHCP. Einer dieser Clients ist ein piHole mit unbound, der DNS für das Netz spielen soll.

Der Vollständigkeit halber sei erwähnt, dass du Unbound auch einfach nativ auf der OPNsense laufen lassen kannst. DNS-Blocklisten dann entweder direkt mit Unbound oder mit BIND (oder weitere). Wenn du aus Gründen unbedingt PiHole willst, dann würde ich auf der OPNsense Unbound auf Port 53 als DNS-Server laufen lassen und die Anfragen von der OPNsense aus in Richtung PiHole leiten. Die Clients bekommen die DNS Antworten dann von der OPNsense, das Filtern passiert im PiHole.

Zweite Möglichkeit wäre, das PiHole im Proxmox zu virtualisieren, aber warum es ausgerechnet eine weitere Appliance sein muss, erschließt sich mir nicht.

Damit ich die Fritzbox noch erreichen kann, habe ich ein Single Gateway hinzugefügt (die opnSense selber) und eine Route "Fritzroute" angelegt, die über dieses Gateway auf 192.168.254.0/24 zeigt.

Wieso brauchst du da eine Route? Die OPNsense Appliance sollte das eigentlich auch ohne statische Route hinbekommen, sofern die Adressbereiche einem NIC zugeordnet und die OPNsense als Router eingetragen sind.

Zu deiner Frage: zeichne mal einen Netzwerkplan, was du da genau vorhast. Das macht es leichter zu helfen.

 

[Shihatsu]

Ja, ich will aus Gründen piHole verwenden, die Gründe sind: Ich kenne es, es läuft und ich werde später daran gehen. Warum das benutzen von Unbound für port53? Was ist hier der Vorteil bzw. der Hintergrund? Im Moment kriegen alle DHCP-Clients die 10.10.0.2 als DNS-Server zugewiesen, alle statischen haben sie eingetragen. Warum den "Umweg" über die opnSense?
Es ist btw. im opnSense virtualisiert - zur Hälfte. Die zweite Hälfte ist ein "echter" piHole, der im Warmstandby läuft. Das waren mal 2 Raspberrys. An das Thema will ich später, eins nach dem anderen.

Ohne die Route komme ich nicht auf die Fritzbox. Das mag an meiner Unkenntnis liegen. Was meinst du genau mit dem letzten Satz?

 

[jimbolo]

Warum das benutzen von Unbound für port53?

Wenn der Fokus bei dir Filtern von Blocklisten ist und du keine hübsche GUI brauchst, reichen ein paar Haken in der OPNsense und Unbound filtert dir die Listen ebenfalls. Wenn du später ohnehin planst, vom piHole wegzugehen (lese ich so raus), dann regelt die OPNsense die ganzen DNS-Anfragen jetzt schon für alle Clients, indem du halt Unbound auf der OPNsense am Laufen hast, wobei alle Anfragen von der OPNsense an die piHole Appliance gehen. piHole antwortet der OPNsense und die OPNsense antwortet den Clients. Den Clients bleibt verborgen, wo genau die Antwort herkommt, bzw. ob die OPNsense direkt die Rootserver anfunkt oder den Umweg über PiHole geht.

Mein DNS-Filter läuft auf Port 53530, Unbound auf Port 53.

Bekomme ich eine DNS-Anfrage auf :53 wird diese an :53530 weitergeleitet, bearbeitet und Unbound antwortet meinen Clients. Das funktioniert wunderbar, da Unbound einfach sehr gut in OPNsense integriert ist. Daher der Vorschlag, wenn du schon auf OPNsense setzt, die Topologie möglichst simpel zu halten, um den Konfigurationsaufwand und die Fehleranfälligkeit zu minimieren.

Annahme:

igb0: 10.0./16
igb1: 192.168/16

Wenn die OPNsense routet, kommen die Pakete von 10.0.0.100 (Beispiel) zu 192.168.0.100 problemlos an. Auch ohne statische Route. Natürlich vorausgesetzt du hast eine Firewallregel, die dies erlaubt. Hast du eine solche dedizierte Regel erstellt?

Letzter Satz: Boxen und Pfeile mit IP-Adressräumen und VLANs aufzeichnen und als Bild hochladen, dann ist es leichter, deine Infrastruktur zu verstehen.

 

[Shihatsu]

Ich werde später an meiner DNS-Thematik schrauben und komme dann gerne auf die Tips zurück, aber wie gesagt: eins nach dem anderen, und das ist etwas das klappt - ich möchte mich jetzt auf dinge die fehlen oder nicht klappen fokussieren. Die Anregungen sind aber gut, ich schaue mir das später mal in Ruhe an.

"Natürlich vorrausgesetzt du hast eine Firewallregel" - habe ich nicht. Ich habe mich mit den Firewallregeln noch nicht beschäftigt, das wollte ich im Zuge der VLANs tun. auch hier gilt: Es klappt ja mit der statischen Route, auch das fasse ich im Moment nicht an, ich möchte erst mal die VLANs zum laufen kriegen - so mein ursprünglicher Gedanke - ich mag hier ungern ein weiteres "Fass aufmachen".

Hast du eine Idee warum ich keinerlei Gateway-funktionalität habe, sobald ich ein VLAN hinzufüge? Gerade um so etwas zu vermieden habe ich halt noch keinerlei Firewall-Regeln außer den beiden bekannten Regeln zum Thema LAN (Default allow LAN to any rule & Default allow LAN IPv6 to any rule). Ich verstehe nicht warum das hinzufügen eines VLANs in der Grundkonfiguration meine Gateway-Funktionalität nach außen komplett blockt. Woher kommt das?

Zum Thema Diagramm: Ich suche gerade nach einer FLOSS-Software dafür - gibt es da Tips? Im Moment gibt es da aber auch nicht viel zu verstehen:
TAE - Fritzbox mit DHCP für 192.168.254.1/24 - WAN Interface der OPNsense - OPNsense - LAN Interface der OPNSense mit 10.10.0.1/24 - Clients mit 10.10.0.x, beispielsweise die piHole-VM mit 10.10.0.2.
Außer der Route zur Erreichung der Fritzbox und dem dafür benötigten Single Gateway habe ich nichts geändert an der Grundkonfiguration.

Edit: Es liegt definitiv an der Route und dem Gateway. Beides weg - VLAN anlegen führt nicht zu sofortigem Verlust der Gateway-Funktionalität. Witziger weise kann ich die Fritzbox trotzdem noch erreichen. Nun gut. Ich les mich dann mal in die Firewallregeln ein und werd bestimmt bald wieder völlig dumme Fragen stellen. Und nebenbei ein Tool zum malen suchen. Auf der Arbeit tät ich Visio nehmen, aber daheim möchte ich gerne komplett FLOSS bleiben.

Edit2: Wie krieg ich denn jetzt eine Proxmox-VM in das VLAN und die nach aussen geroutet. Ich habe eine Linux-VM gestartet, die an die interne Bridge gehängt, diese ist VLAN-aware, und hab der VM manuell eine IP aus der Range meines VLANs gegeben. Eigentlich sollte das doch schon reichen, aber von dieser VM komme ich dann nirgendswohin. Huom.

 

[jimbolo]

Edit2: Wie krieg ich denn jetzt eine Proxmox-VM in das VLAN und die nach aussen geroutet. Ich habe eine Linux-VM gestartet, die an die interne Bridge gehängt, diese ist VLAN-aware, und hab der VM manuell eine IP aus der Range meines VLANs gegeben. Eigentlich sollte das doch schon reichen, aber von dieser VM komme ich dann nirgendswohin. Huom.

Ich habe bei mir keine VLANs in Betrieb, daher bin ich mir nicht mehr ganz sicher (schon etwas her). Aber war es bei OPNsense nicht so, dass man bei Anlegen eines VLANs quasi ein neues (virtuelles) Interface bekommt, das dann entsprechend auch bei den Firewall-Regeln eine Rolle spielt? Das würde erklären, warum kein Paket durchkommt.

Am besten am Ende mal eine "Catchall" Regel machen, um zu sehen, welche Pakete von der OPNsense weggeblockt werden. Dort sollten deine Anfragen dann im Log erscheinen. Von dort aus kannst du dann weiter probieren.

Ansonsten ist Tagged vs. Untagged bei VLANs immer so eine typische Stelle, an der man den Haken falsch setzt und am Ende gar nichts mehr funktioniert. Mit den Routen und Gateways bin ich mir nach wie vor nicht sicher. Ich nutze selber auch verschiedene Netze und bei mir braucht es keine manuellen Routen. Am besten mal mit "traceroute" schauen was vor sich geht.

Wenn du bewusst was ins VLAN routen möchtest kann die Sache wieder anders aussehen. In diesem Fall kann es schon sein, dass eine Route fehlt.

P.S. Wenn du nicht unbedingt bewusst IPv6 brauchst, mach' am besten eine Floating-Rule, die IPv6 komplett blockt. Dann bist du den Kram schonmal los.

P.P.S. Wenn man nicht allzu viele VMs nutzt, bietet es sich an, das VLAN und die Proxmox ID irgendwie in die IP-Adresse der VM zu codieren, bspw. 172.16.<VLAN-ID>.<Proxmox-ID>. So lässt es sich besser arbeiten (meine persönliche Erfahrung).

P.P.P.S. (wow!) Deine Frage hat eigentlich nichts mit Proxmox zu tun, sondern wäre im OPNsense Forum besser aufgehoben. Der Proxmox-seitige Teil läuft ja.

 

[Shihatsu]

Ich glaube ich bin eher hier richtig, denn ich verorte mein Problem tatsächlich in Proxmox. Ich habe jetzt auch mal einen physischen Host angehangen, das will auch nicht so wirklich.
Mein Setup sieht folgendermassen aus:

Proxmox sieht folgendermaßen aus:

auto lo
iface lo inet loopback

iface eno1 inet manual

iface eno2 inet manual

auto vmbr0
iface vmbr0 inet manual
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0

auto vmbr1
iface vmbr1 inet static
        address 10.10.0.11/24
        gateway 10.10.0.1
        bridge-ports eno2
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

Wie weiter vorgehen? Eigentlich ist das ja recht einfach was ich machen will. Aber irgendwie scheint es keine vernünftige Anleitung für "OPNsense inside proxmox with VLANs" zu geben.

 

[jimbolo]

P6 hat einen VLAN Tag, ich sehe aber keinen Tag in Proxmox oder sonst wo ... so wie es dargestellt ist, wird der Traffic P6 im Switch mit VLAN 11 getaggt. Aber wie routet der Switch denn genau? So wie es dargestellt ist ist es zumindest mir nicht ersichtlich.

 

[Shihatsu]

Im Switch habe ich ein VLAN angelegt, diesem den Tag 11 gegeben und dem Port 6 zugewiesen. Sobald ich jetzt aber den Proxmox Port 1 ebenfalls als Member in das VLAN reinnehme, habe ich kein Internet mehr - also quasi ein ähnliches Verhalten wie bei den VMs. Irgendwas grundsätzliches scheint hier zu fehlen.

 

[jimbolo]

Dann stimmt am Switch etwas nicht. Wenn du am Switch ein VLAN Tag einstellst und trotzdem noch durch bis zur Fritz!Box kommst, dann ist an dieser Stelle schon etwas schief gelaufen.

 

[Shihatsu]

Komme ich nicht. Der Laptop der an port6 hängt hat gar kein Netzwerk. Zumindest dann nicht wenn ich ihn aus dem "native VLAN" (1) raus schmeiße. Dann kriegt er keine IP (Erwartung: Er kriegt eine 10.10.10.x IP). Wenn ich einfach nur VLAN11 für den port6 aktiviere, ohne das "default VLAN" für diesen Post von 1 auf 11 zu stellen dann kriegt er eine "normale" 10.10.0.x IP (und ich komme bis zur Fritzbox und ins Internet). Was zur Hölle.

 

[Shihatsu]

Das ganze läuft nun - warum auch immer benötigt OPNSense nach hinzufügen eines VLANs einen reboot oder eine Neukonfiguration an der Konsole - GUI reicht nicht. Strange.

Sodele, nächste doofe Frage, diesmal zu VLANs:
OPNSense virtualisiert in Proxmox. an der OPNSense hängt ein MikroTik Switch. VMs die ich mit dedizierte NIC versorge und an den Mikrotik hänge und den Switch für den Tag sorgen lasse funktionieren.
Wie kriege ich jetzt VMs in VLANs, wenn die keine dedizierte NIC kriegen sollen? Ich habe folgende Netzwerk-Konfigration:

auto lo
iface lo inet loopback

<-irrelevante interfaces rausgeschnitten->

iface enp35s0f0 inet manual

auto enp35s0f0.10
iface enp35s0f0.10 inet static
        address 10.10.10.11/24

auto enp35s0f0.90
iface enp35s0f0.90 inet static
        address 10.10.90.11/24

auto vmbr0
iface vmbr0 inet manual
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0

auto vmbr1
iface vmbr1 inet static
        address 10.10.0.11/24
        gateway 10.10.0.1
        bridge-ports enp35s0f0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

Die VLAN-Tags 10 und 90 funktionieren am switch ohne Probleme mit physischen Clients. Sie sind in der opnSense angelegt und die Firewall ist auf. enp35s0f0 hängt am Switch an einem port der auf "admit all" und PVID=1 steht (ein "Trunk" also). Was ist falsch?

 

[MisterY]

na für VLAN 90 setzt du als Netzwerkkarte der VM die "bridge" auf vmbr1 und das wars. Nichts bei VLAN Tag eintragen.

Eigentlich benötigt enp35s0f0 auf keiner VLAN-ID eine IP direkt eingetragen. Es reicht, wenn du nur den vmbr-dingern eine IP vergibst.

 

[Shihatsu]

Zur Hülf:
Änderungen an der Hardware, pci Adressen geändert. Unter anderem die der eingebauten GPU und die von den onboard SATA Controllern. Einer war durchgereicht an eine TrueNAS-VM. Also den alten falschen entfernt und den richtigen durchgereicht und die VM gestartet. Doof nur das ich den controller erwischt habe an der die pve-Platte selber hängt. Und nu? Any Ideas? Meine beste Idee ist jetzt die Boot-Platte an einen anderen Controller anzuschließen - gibts einen besseren Weg? Die VM die "stört" bootet automatisch nachdem das System oben ist...

 

[aXu]

live linux und die conf der vm bearbeiten

 

[Shihatsu]

Es erweist sich als überaus schwierig ein Live-Linux mit ZFS-Support zu finden...

 

[P0stbote]

Müssten die aktuellen Ubuntus nicht ZFS mitbringen?
Ansonsten eigene Archiso mit ZFS bauen, geht relativ easy. Hab hier sonst auch bestimmt noch eine rumfliegen.

 

[Shihatsu]

Naja, nö, die müssen alle ZFS quasi "nachinstallieren" - die Mühle hat aber in der derzeitigen Verfassung nichtmal Internet - ich könnte im Strahl kotzen. Ich versuch mir mal nen Arch zusammenzufrickeln - mir will an der Stelle mal wieder nicht in den Kopf warum es das nicht gibt. Manchmal ist Linux lächerlich unreif.
Edit: Na super, die ersten Treffer dazu führen zu Skripten die mit Fehlern um sich schmeissen - ich glaub ich installier das Proxmox neu, das nervt echt ziemlich hart gerade... Meine VMs sind alle auf ner seperaten Disk und das Datenarray ist auch völlig losgelöst. Neumachen sollte schneller gehen. Sowas nervt hart, drecks Frickelei.

 

[aXu]

You might not be able to see the files in /etc/pve if you boot from an iso. Because the problem is caused by PCI passthrough, I suggest editing the boot menu (press the 'e'-key) and removing the intel_iomm=on or amd_iommu=on from the kernel parameters. Then the VMs won't be able to do passthrough and Proxmox should start normally (except for failing to start those VMs).

Wäre ein anderer Ansatz. keine iommu und VT im Bios deaktivieren. dann vm conf bearbeiten und dann wieder zurück auf normal

 

[Shihatsu]

Uhm das ist eine gute Idee. Ich hab mitlerweile proxmox auf ner anderen Platte installeirt um zus chauen ob es nicht so geht - meine Platte mit den VMs ist ebenfalls im System und mittels zpool import -f auf importiert. Auf der Konsole sehe ich die auch sauber mittels df -h. Aber wie krieg ich die nun wieder in die pve-gui?

 

[aXu]

die confs fehlen. binde doch die orginale pve platte nun auch ein, editiere die conf files und dann wieder zum ursprünglichen setup umbauen.

Manual: qm.conf - Proxmox VE

pve.proxmox.com

 

[VirtuGuy]

Es erweist sich als überaus schwierig ein Live-Linux mit ZFS-Support zu finden...

DIe Proxmox VE Installer ISO bringt alles notwendige mit.

 

[Shihatsu]

Watt? Zu einfach. Wer kommt denn auf so was. Das ist doch völlig abstrakt....



O man. Tisch. Kopf. Danke!

 

[Olaf16]

Proxmox 7.0 auf Basis D11 draußen seit gestern. Schon jemand getestet?

 

[sashXP]

Bei mir (Neuinstallation) läuft die Beta und auch jetzt die final problemlos.

6x LXC und 1x VM

 

[morph027]

Wollte in-place upgraden, da steht aber noch, dass ich auf den PBS 2.0 warten muss

Vielleicht installier ich aber einfach neu....

 

[sashXP]

...ok, ich habe 6 LXC und einer funktioniert unter 7 nicht mehr richtig. Merkwürdigerweise habe ich mehrere Docker installationen in den LXCs und nur eine Installation funktioniert nicht. Hat von Euch jemand einen Tipp?

Jul 07 20:05:49 server4711 dockerd[822]: time="2021-07-07T20:05:49.879938649Z" level=error msg="failed to mount overlay: invalid argument" storage-driver=overlay2
Jul 07 20:05:49 server4711 dockerd[822]: time="2021-07-07T20:05:49.880115881Z" level=error msg="[graphdriver] prior storage driver overlay2 failed: driver not supported"

Auf dem Host sind die AUFS und OVERLAYFS Module geladen. Da musste ich manuell nichts tun, ist mittlerweile wohl standardmäßig so.


OK, ich habe gerade folgendes gefunden und das Verzeichnis gelöscht:

error creating overlay mount to /var/lib/docker/overlay2/<...>/merged: device or resource busy · Issue #711 · docker/for-linux

This is a bug report This is a feature request I searched existing issues before opening this one Expected behavior No errors Actual behavior error creating overlay mount to /var/lib/docker/overlay...

github.com

udo systemctl stop docker
sudo rm -rf /var/lib/docker
sudo systemctl start docker