Internetzugriff auf Proxmox VMs / Docker Container hinter OPNsense mit Reverse Proxy

[Johannes S]

Du betrachtest doch eher Outsourcing vs. Inhouse. Wenn du mir jemanden nennen kannst, der dir die externe Dienstleistung kubernetes spürbar günstiger als externes Proxmoxclustering anbietet, wäre das sogar eine Überlegungen wert.
Ich bleibe dabei, dass Docker primär die Verantwortlichkeit Richtung Hersteller verschiebt, der sich einen Scheißdreck um die BS-Basis kümmern *will*, der dich aber trotzdem im Fehlerfall für irgendwas in deiner Infrastruktur zur Verantwortung ziehen will!

Die Frage ist aber, ob das nun was Schlechtes ist. Wenn der Hersteller mir ein docker-image samt allen Abhängigkeiten zur Verfügung stellt, dann bin ich als Kunde/Endanwender nicht Schuld, wenn es nicht läuft (weil ich irgendeine Abhängigkeit übersehen habe beim Einrichten), sondern ich kann halt darauf verweisen, dass es eigentlich funktionieren sollte und die übliche Ausrede von Entwicklern "Bei mir geht es" oder "Betriebssystem x wird nicht unterstützt" nicht greift. Plus dass es eben das Deployment extrem vereinfacht.

Klagst du dann? Ich stelle im Fehlerfall einfach die Vorversions-VM her und informiere den Hersteller über einen Misserfolg, statt an meinem Virtualisierungshost rumzuschrauben.

Da ist aber unabhängig davon, ob auf der VM nun docker läuft oder nicht.

 

[Bu66as]

Ja, Docker gehört in eine eigene VM, nicht auf den PVE-Host. Der Host sollte schlank bleiben und nur Proxmox laufen. So hast du eine saubere Trennung und wenn im Container was schiefgeht, ist der Hypervisor nicht betroffen.

Mit OPNsense davor und VLANs bist du da schon auf nem guten Weg. Für den Reverse Proxy auf der OPNsense schau dir das Caddy- oder nginx-Plugin an, damit kannst du dann per VLAN gezielt nur die nötigen Ports zu den VMs durchreichen.

 

[spooner]

Super, danke euch.

Ja, auf der OPNsense hatte ich an Caddy oder HAProxy gedacht.
Ich denke der Caddy ist ausreichend.

 

[TErxleben]

Geschichten, die das Leben mit LXCs schreibt und es hierhin passt.

• Ich setze seit gefühlten Äonen Apache Guacamole als Fernsteuerungsproxy ein.
• irgendwann kam ich auf die naheliegende/dusselige Idee, selbiges zu virtualisieren
• Da ich damals noch dümmer als Heute war, habe ich das damals mittels LXC realisiert.
• Lief auch jahrelang ohne Probleme.
• selbst Updates waren Dank der Leistung von MysticRyuujin gut und schnell abgefiedelt
• Nun kam ich auf die Idee, das zu grundeliegende Ubuntu 20.04 zu aktualisieren.
• Upgrade auf 24.04 klappte mit Fummelei auch.
• Selbst ein Update von Guacamole von 1.5.5 auf 1.6.0 lief wie erwartet reibungslos.
• regelmäßige Updates der PVE-hosts sind eh obligatorisch und fanden immer statt.
• Innerhalb des Guacamole-Containers läuft auch jetzt augenscheinlich alles ohne Fehler.
• Dummerweise reconnecten die Clients in der neuen Umgebung nun dauernd.
• Vatti dachte, er braucht nur eine Sicherung der alten Version einspielen.
• Aber weit gefehlt. Auch diese reconnecten plötzlich aus heiterem Himmel.

Moral von der Geschicht:

• Kapsel immer in einer VM
• Damit sparst du dir Zeit bei der Fehlersuche bzw. ermöglichst sie erst.
• Warum stecken essentielle Dinge wie Apache-Gucacamole nicht in den offiziellen Debian-Repos?
• Obwohl die Apache-Foundation ja nun nicht gerade zu den Leichtgewichten gehört.
• Ich muss jetzt viel Zeit in Fehlersuche investieren, weil ich damals nicht ordentlich Isoliert habe.

 

[Johannes S]

Warum stecken essentielle Dinge wie Apache-Gucacamole nicht in den offiziellen Debian-Repos?

Weil sich bislang kein/e Freiwillige/r zum Maintainen gefunden hat, wäre meine Vermutung.

 

[spooner]

Hallo Zusammen,
ich muss meinen Thread noch mal wiederbeleben, da ich so langsam mit meinen Umstellungen weiterkomme.

Proxmox Umgebung steht, OPNsense sowie so, aber jetzt auch mit Caddy.
Jetzt habe ich die ersten VMs mit den Docker Containern am Rennen.

Jetzt eine Frage / Überlegung:
Bisher ist kein Dienst direkt aus dem Internet erreichbar.
Es gibt ein VLan mit Servern, da sind im Moment alle Server integriert.
Auch jetzt erst mal die Nextcloud, CRM, usw.
Über Unbound DNS sind die Systeme jetzt über einen externen DNS Namen erreichbar.
Langfristig soll aber z.B. die Nextcloud, das CRM direkt ohne VPN aus dem Internet erreichbar sein.

Jetzt meine Frage an euch:
Macht es sinn für alle externen Dienste ein eigenes VLan zu erstellen?
VLAN4711 = Nextcloud
VLAN4712 = CRM
VLAN4713 = usw.

Bringt das einen sicherheitstechnischen Mehrwert?
Oder ist es nur mehr Admin und Verwaltungsaufwand?

Viele Grüße
Arthur

 

[TErxleben]

Hallo Zusammen,
ich muss meinen Thread noch mal wiederbeleben, da ich so langsam mit meinen Umstellungen weiterkomme.

Proxmox Umgebung steht, OPNsense sowie so, aber jetzt auch mit Caddy.
Jetzt habe ich die ersten VMs mit den Docker Containern am Rennen.

Jetzt eine Frage / Überlegung:
Bisher ist kein Dienst direkt aus dem Internet erreichbar.
Es gibt ein VLan mit Servern, da sind im Moment alle Server integriert.
Auch jetzt erst mal die Nextcloud, CRM, usw.
Über Unbound DNS sind die Systeme jetzt über einen externen DNS Namen erreichbar.
Langfristig soll aber z.B. die Nextcloud, das CRM direkt ohne VPN aus dem Internet erreichbar sein.

Jetzt meine Frage an euch:
Macht es sinn für alle externen Dienste ein eigenes VLan zu erstellen?
VLAN4711 = Nextcloud
VLAN4712 = CRM
VLAN4713 = usw.

Bringt das einen sicherheitstechnischen Mehrwert?
Oder ist es nur mehr Admin und Verwaltungsaufwand?

Viele Grüße
Arthur

Das ergibt keinen Sinn. Ein VPN ist immer eine komplette, verschlüsselte Verbindung ins Zielnetz. Die Zugiffskontrolle erfolgt immer dort. Wenn man Dienste im Internet exponieren will/muss, dann ist ein VPN eher kontraproduktiv. Man muss schon dem SW-Anbieter trauen.
Apache-Webserver sind schließlich auch ganz ohne VPN erreichbar ;-)

 

[Browbeat]

Es ging doch gar nicht mehr um VPN sondern um seperate VLANS für die Dienste, die extern erreichbar sein sollen

Wenn die Dienste auf unterschiedichen VMs laufen, könntest du jeweils ein eigenes VLAN nutzen - aber wäre mir vermutlich zu viel (Wartungs)aufwand...

Zumal du es ja eh mit Caddy absicherst, Caddy nutzt du als Plugin direkt in OPNsense?

 

[spooner]

Ja, genau, ich für jeden Dienst / Docker Container eine eigene VM.
Und ich dachte es macht sinn für jede VM ein eigenes VLan einzurichten.
Klar, es ist etwas arbeit, aber wenn es mir Sicherheit bietet, dann ist es OK.
Ja, der Caddy läuft auf der OPNsense, das funktioniert super.

 

[Browbeat]

Wenn sie eh in separaten VMs laufen, dann kannst sie halt auch logisch mit eigenen VLANs abkoppeln - macht dann auch keinen großen Aufwand mehr

Dein Setup könnte für mich später nochmal interessant werden

 

[TErxleben]

Sorry für mein Lesen von VLAN und gedanklichem Verarbeiten als VPN.
Richtig Sinn bzw. Sicherheitsgewinn kann ich trotzdem nicht erkennen. Mich nerven schon VPNs, da sie zu gerne providerseitig unterbunden werden. Das ganze garniert mit nickligen Clients auf den Endgeräten ich schon schon eine mittelschwere Katastrophe.
Deshalb verwende ich als Ersatz inzwischen fast ausschließlich Apache Guacamole. Damit kann ich ziemlich feingranular Zugriffe erlauben oder es bleiben lassen. Somit bin ich im LAN mit seinen ohnehin vorhandenen VLANs.
Pro internem Client ein VLAN zu definieren wäre auch ein administrativer Affenaufwand und besser per MAC ACLs auf dem Switch aufgehoben.
Einen weiteren Sicherheitsgewinn kann ich nicht erkennen.
Der liegt in meinen Augen in der gewissenhaften Entscheidung, welche SW man weltweit exponiert und die Angriffsfläche möglichst klein zu halten.

 

[Bu66as]

Ich würde das nicht einfach als Mehraufwand abhaken. Der Unterschied liegt in der Kontrolle: Wenn die Nextcloud aus dem Internet übernommen wird und im selben Server-VLAN liegt wie CRM und der Rest, kann der Angreifer die anderen Systeme direkt auf L2 erreichen – die OPNsense sieht davon nichts.

Mit getrennten VLANs muss jeder Querzugriff über die Firewall. Genau da kannst du ihn blocken. Das funktioniert aber nur mit strikten Regeln: default deny zwischen den VLANs, Caddy kriegt nur Zugriff auf den einen Port des jeweiligen Dienstes, die exponierten VMs dürfen nichts ins interne Server-VLAN. Und outbound nur das freigeben, was wirklich gebraucht wird (Updates, Mail usw.). Wenn du einfach „any to any" erlaubst, hast du nur mehr Arbeit ohne Sicherheitsgewinn.

Als Mittelweg funktioniert auch ein einzelnes DMZ-VLAN für alles von außen, getrennt vom internen Server-VLAN. Die Trennung der DMZ-VMs untereinander machst du dann mit der PVE-Firewall auf VM-Ebene – die filtert direkt an der VM-NIC auf der Bridge und greift auch innerhalb desselben VLANs. Das mache ich bei Kunden öfter, weil man sich damit den VLAN-Wildwuchs auf Switch und OPNsense spart. Aber mit eigenen VMs pro Dienst ist deine Variante mit je einem VLAN auch völlig ok, wenn du das mit Aliases und Regel-Templates auf der OPNsense sauber hältst.