[Sammelthread] Proxmox Stammtisch

@BobbyD
In Deinem Fall besteht Dein Cluster ja nur aus Member Servern, die aber ohne HA arbeiten -> also kein Quorum etc notwendig.
D.h. meine VMs werden nicht irgendwann in den Read Only Mode fallen? Das wäre natürlich ideal, danke Dir!
Screenshot 2024-06-25 095656.png
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
das wäre auch für mich eine interessante Neuigkeit, wenn das so geht. Kann man sich ja oft das Quorum sparen.
Dachte bisher echt, Quorumdevice bzw. ungerade Anzahl an Host ist ein MUß im Cluster.
Da werkelt man so lang schon mit Proxmox rum und lernt immer wieder neues dazu ;-)
 
das wäre auch für mich eine interessante Neuigkeit
Ich hab jetzt einen Node heruntergefahren und beobachte die Situation, noch beschwert sich nichts.
Beitrag automatisch zusammengeführt:

Dachte bisher echt, Quorumdevice bzw. ungerade Anzahl an Host ist ein MUß im Cluster.
Du solltest recht behalten. Wenn ich zwei Nodes von dreien herunterfahre und dann eine VM (ohne HA) heruntergefahren habe, so lässt sich diese anschließend nicht wieder starten.
Screenshot 2024-06-25 132208.png

😡
 
Zuletzt bearbeitet:
Du magst Recht haben, kann man so machen. Ist aber nicht das selbe, wie supaman geschrieben hat.
Hat ja auch niemand behauptet.

Mir gibt das erst mal Ruhe. Mittelfristig werde ich mich aber von dem Cluster trennen.
 
ja, Dir ist damit erst einmal geholfen. So kenne ich es auch, falls Quorum nicht erfüllt wird halt getrickst.

Es stand aber die Aussage im Raum, das man ohne HA kein Quorum benötigt.
 
Ich bräuchte mal eure Hilfe:

Ich habe einen Proxmox-Server mit 3 NICs.
Zwei NICs sind im Subnetz 192.168.123.x
Eine NIC ist direkt an einer Firewall angeschlossen, hier ist eine externe IP (sagen wir mal "111.111.111.11" mit den Ports 80 und 443 verfügbar (kein interner IP-Bereich verfügbar, d.h. kein destination NAT; das ist leider auch nicht änderbar).


Über diese externe IP möchte ich mehrere Dinge verfügbar machen (Nexctcloud, Bookstack und sowas), weshalb das über einen Reverse Proxy gehen muss. Da mir hier aber die internen IPs fehlen, muss ich ja denke ich einen Router ala Opnsense dahinter setzen (also Firewall --> Opnsense --> Reverse Proxy --> Nextcloud/Bookstack). Ist das korrekt so?


Das hier ist die Host-Netzwerkconfig

NICs Host.png


Und das hier von Opnsense:

NICs Opnsense.png

Ob da jetzt so viele NICs von Nöten sind, zweifle ich gerade ein wenig.

So kann ich aber über vmbr0 auf die GUI von Opnsense zugreifen.


So sieht die GUI aus:

Opnsense.png

Was muss ich jetzt machen? Ich möchte, dass auf "WAN" die externe IP "111.111.111.11" anliegt und den Traffic auf "OPT1" bzw. net1 der VM bzw. vmbr3 des Hosts geht. VMBr3 soll dann auch intern einen DHCP-Bereich (sagen wir mal 10.0.0.1/24) haben, wo dann der Reverse Proxy/Nextcloud/Bookstack zu erreichen sind.

Wie mache ich das?
 
Kannst du dazu mal ein Bildchen malen?
Spontan hoert sich‘s so an als waer ne weitere Firewall mit HAPROXY von noeten. Aber ich verstehe nicht ganz wieso der Host ganz exklusiv diese Nic mit der Public Ip hat. Muss der Rest nicht ins Internet?

Gehoert die Firewall ‚vornedran‘ dir oder nutzt du das Ding einfach mit?
 
ich blicke da absolut nicht durch. Wenn ich nun der nextcloud VM direkt die NIC
 
das hat irgendwie die Forensoftware verschluckt :fresse:

@home habe ich vollständigen Zugriff auf die komplette IT-Infrastruktur, wo ich das mit einem separaten VLAN, DMZ und Reverse Proxy gelöst habe.

Hier habe ich aber leider keinen Zugriff auf die Firewall/Router, was die ganze Sache etwas komplizierter macht.

Ich erkläre es mal genauer:


Es sind mehrere externe IPs verfügbar, eine davon (111.111.111.11; natürlich nur ein Platzhalter) hat einen A-Record auf die Domain "cloud.net.de".
Server besitzt 3x NIC; zwei davon gehen auf den internen Switch, eine geht direkt an die Firewall. Hier sind die Ports 80 und 443 freigegeben.

Nun möchte ich auf die Nextcloud instanz verfügbar machen über die Domain "cloud.net.de". Ich habe versucht eine Opnsense, dann eine Pfsense oder gar einen Nginx Proxy Manager (und zusätzlich noch einen plain nginx reverse proxy) dazwischen zu schalten; aber nichts hat funktioniert.

Deshalb versuche ich nun direkt die Nextcloud an die IP zu hängen und schalte ufw bzw. die Proxmox-Firewall davor.

Das hier ist die Netzwerk-Konfig des Servers:

Server NIC.png

Und das hier die NC Instanz:

NC NIC.png


Aber selbst wenn ich sämtliche Firewalls in Proxmox deaktiviere, ich kann nicht auf cloud.net.de zugreifen. Ein nmap aus dem LAN auf cloud.net.de zeigt:
Code:
PORT    STATE  SERVICE
22/tcp  open   ssh
80/tcp  open   http
110/tcp open   pop3
443/tcp closed https

Ein nmap aus dem WAN (anderer Server, ca. 15 km Luftlinie) liefert nichts zurück.

So langsam habe ich keine Ahnung, warum ich das nicht hinbekomme...

Selbst ein Ping aus dem WAN ist nicht möglich.
 
Echt komisch:

Laptop an den Router/Firewall, dann IP vergeben (111.111.111.11) mit passendem Gateway und Subnetzmaske und es funktioniert. Reiche ich die NIC vom Proxmox-Server direkt an eine Ubuntu-VM durch, dann funktionierts.

Wenn ich aber die Bridge an die VM mit der entsprechenden NIC gebe, dann die IP einstelle, funktioniert es NICHT. Auch in der LXC funktioniert es nicht.

Jemand eine Idee??
 
Ich würde gerne einen Linux-Container in Proxmox mit dem Socks Proxy "Dante-Server" aufsetzen. Leider ist die APT Version weiterhin veraltet (1.4.2). Scheint auch so Absicht von dem Entwickler zu sein.
Es gibt z.B. ein aktuelleres als Snap (1.4.3). Aber mit Snap hatte ich schon Probleme, solche als Container laufen zu lassen. Das wollte mehr Rechte, was ich aber nicht einsehe.
Meine Frage, gibt es andere Empfehlungen für "Paket-Manager oder Stores" oder wie immer sich das schimpft für Debian/Ubuntu oder müsste ich auf ein anderes Linux im Container umschwenken?
Linux Noob hier.
 
Zuletzt bearbeitet:
Echt komisch:

Laptop an den Router/Firewall, dann IP vergeben (111.111.111.11) mit passendem Gateway und Subnetzmaske und es funktioniert. Reiche ich die NIC vom Proxmox-Server direkt an eine Ubuntu-VM durch, dann funktionierts.

Wenn ich aber die Bridge an die VM mit der entsprechenden NIC gebe, dann die IP einstelle, funktioniert es NICHT. Auch in der LXC funktioniert es nicht.

Jemand eine Idee??

Also Passthrough funktioniert, aber Bridge über proxmox nicht?
Je nachdem welcher Hoster das ist, könnte da ein Mac Adressen Filter die Ursache sein.
Ist denn die Bridge erreichbar, wenn du ihr eine IP gibst?
 
Ich würde gerne einen Linux-Container in Proxmox mit dem Socks Proxy "Dante-Server" aufsetzen. Leider ist die APT Version weiterhin veraltet (1.4.2). Scheint auch so Absicht von dem Entwickler zu sein.
Es gibt z.B. ein aktuelleres als Snap (1.4.3). Aber mit Snap hatte ich schon Probleme, solche als Container laufen zu lassen. Das wollte mehr Rechte, was ich aber nicht einsehe.
Bin jetzt auf Debian-Container gewechselt mit der veralteten Version von Dante Socks Proxy via apt. Sollte egal sein, da nur intern angeboten. Hab dann einen Container als Template definiert und dann vier linked Clones gemacht. Das spart sicher haufenweise Ressourcen.

Während die pfSense als VM direkt auf dem Hyper-V-Host läuft, laufen die Container auf Proxmox, welches ebenfalls als VM auf Hyper-V läuft (nested). Jedem Container ist durch die pfSense ein anderes Privacy-VPN-Gateway zugeordnet. Und so hab ich für jedes VPN-Gateway einen eigenen Socks Proxy am Start. Fun Times. :wink:
Screenshot 2024-07-06 160811.png
 
Zuletzt bearbeitet:
Der Cluster ist jetzt Geschichte. Habe einen Node separiert, da ich den noch brauche, und den Rest platt gemacht. Bin jetzt Cluster-frei.
 
Echt komisch:

Laptop an den Router/Firewall, dann IP vergeben (111.111.111.11) mit passendem Gateway und Subnetzmaske und es funktioniert. Reiche ich die NIC vom Proxmox-Server direkt an eine Ubuntu-VM durch, dann funktionierts.

Wenn ich aber die Bridge an die VM mit der entsprechenden NIC gebe, dann die IP einstelle, funktioniert es NICHT. Auch in der LXC funktioniert es nicht.

Jemand eine Idee??
Warum macht du in der Sense keinen HAProxy auf?
Jaja, für das ganze Nextcloud-Gedöns braucht man drölf Regeln dafür, aber dafür läufts dann auch, wenns mal läuft. =)
Real Server:
1720468476275.png

Backend Pool:
1720468553285.png

Public Service:
1720468635310.png
1720468737211.png

Conditions:
1720468809777.png
1720468918015.png
1720469021493.png

(caldav stellvertretend für die ganzen restlichen conditions)
Rules:
1720469187626.png
1720469098802.png
1720469137361.png

Falls du Hilfe brauchst, sag Bescheid.
 
@Weltherrscher Das kann ich gerne machen, aber soweit bin ich noch nicht.

Ich habe mal ein Schaubild erstellt:


Server.png




Der Server hat mehrere NICs.
- Eine davon (enp4s0f0) ist direkt an den Router angeschlossen, wo es eine Portweiterleitung auf 80 und 443 gibt. Ein A-Record ("cloud.test.com") auf die IP 111.111.111.11 ist vorhanden (Gateway: 111.111.111.1, Subnetz /29).
- Zwei NICs (eno1 bzw vmbr0 und enp4s0f1) sind an einen Switch angeschlossen. Darüber greife ich (über eno1) auf den Server zu über die IP 192.168.123.200.

Dann habe ich für ein internes Routing innerhalb von PVE die bridge vmbr4 erstellt (IP: 10.0.0.1/24). Dies habe ich um die iptables Einträge (schwarzes Bild) erweitert, genau wie vmbr0

Die Opnsense-VM besitzt drei virtuelle Netzwerkkarten:
- net0 = LAN --> um auf Opnsense zugreifen zu können über die IP 192.168.123.242
- net1 = WAN --> hier habe ich die öffentliche IP eingetragen
- net2 = OPT1 --> Für die kommunikation zur Nextcloud, da unter keinen umständen ein Bösewicht über die externe IP in das LAN kommen darf. Dieser Port hat die IP 10.0.0.2

Die Nextcloud besitzt eine einzige Schnittstelle auf vmbr4 mit der IP 10.0.0.101 und dem Gateway 10.0.0.1. DNS = 1.1.1.1

Was funktioniert:
- Von der Nextcloud-CT kann ich überall hinpingen; ausnahme: 10.0.0.2 (also OPT1 von Opnsense)
- Zugriff auf die Webgui von opnsense über 192.168.123.242

Was nicht funktioniert:
- 10.0.0.2 anzupingen
- von Opnsense irgendwo hinzupingen
- Updates mittels Opnsense zu ziehen "Fetching changelog information, please wait... fetch: https://pkg.opnsense.org/FreeBSD:13:amd64/24.1/sets/changelog.txz: Host does not resolve"


Was mache ich falsch bzw. wo ist der Fehler?
 
@MisterY Ich würde an deiner Stelle einen Profi beauftragen... :rolleyes2:
Davon ab, warum NATest Du das WAN in Proxmox, wenn Du mehrere NICs hast und einen Switch?
 
Ich kann und möchte keinen Profi beauftragen.

Wo Nate ist das denn? Falls du meinst: ich möchte nextcloud nicht im 192.168.123.0 Netz haben. Es soll absolut separiert sein.

Oder soll ich: der enp4s0f0 die IP 111.111.111.11 geben, mittels IP Tables den Port 80 und 443 an einen nginx Reverse Proxy weiterleiten (im 10.0.0.0 Netz) und von dort dann an die nextcloud? Also ohne opnsense? Und dann mittels ufw und fail2ban arbeiten?
 
Zuletzt bearbeitet:
Warum firewallst du die OPNsense in Proxmox (firewall=1 in den VM-Netzwerkkarten-Optionen)?
 
Das ist standardmäßig aktiv. Die Firewall in den Optionen vom "Cluster", Node und LXC sind deaktiviert.
 
ich habe es nun so gelöst, ohne opnsense: enp4s0f0 (direkt angeschlossen am Router) geht zur vmbr3. Die vmbr4 hat im Proxmox-Host die IP 10.0.0.1/24.

etc/network/interfaces habe ich bei vmbr4 folgendes hinzugefügt:

Code:
auto vmbr4
iface vmbr4 inet static
        address 10.0.0.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        post-up   echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up   iptables -t nat -A POSTROUTING -s '10.0.0.0/24' -o vmbr0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '10.0.0.0/24' -o vmbr0 -j MASQUERADE

Nextcloud hat die IP 10.0.0.102 und gateway 10.0.0.1 auf der Bridge vmbr4 und manuell den DNS-Server auf 1.1.1.1 gesetzt.
der Reverse Proxy hat die IP 10.0.0.10 und gateway 10.0.0.1 auf der vmbr4, und manuell den DNS-Server auf 1.1.1.1 und 8.8.8.8 gesetzt. Weiterhin hat der reverse proxy die externe IP 111.111.111.11/29 und Gateway 111.111.111.1 auf vmbr3.

das funktioniert soweit, ich kann die nextcloud nun erreichen. Was aber komisch ist: ich kann auf dem reverse proxy (bare nginx; kein reverse proxy manager) mittels certbot nur Zertifikate erhalten, wenn ich die Verbindung der vmbr4 trenne. Woran liegt das und wie kann ich das beheben? Das bedeutet nämlich, dass Auto-renewal nicht funktionieren wird.
 
Kanbn es sein, dass das Netzwerk in der /etc/networks (oder so) ganz oben steht?
Dann wird es als Default genutzt und wenn das nicht routable ist, kommste damit halt auch nicht raus.
Ich habe den Fall aktuell in der Mediaserver-VM, TV-Streams von der Fritze zu Jellyfin gehen über ein extra Kabel, weil ich zu doof bin, das in der OPNsense durchzureichen.
Allerdings schiebt er diese virtuelle Netzwerkkarte immer an die letzte Stelle (192er Netz von der Fritze, standard habe ich 172er Netze von der OPNsense).
Das bringt Jellyfin total durcheinander, er versucht immer von nem 172er Netz den Stream zu holen.
Aber sobald ich die Netzwerke händisch umsortiere (das 192er als erstes in der Datei anordne) klappts. :wall:

//Edith:
In der Fritze ist die 192er IP für Internet gesperrt, deshalb geht die VM dann für externe Sachen wieder aufs 172er Netz.
 
Erinnert mich an meinen Ärger mit SMB. Sobald man mehr als eine mögliche Verbindung hat, kann es unangenehm werden, auch weil Windows sich nicht um IP-Adressen schert. Keine Ahnung, ob das jetzt auch bei euren Problemen der Fall sein kann. :shot:
 
Ich brauche eine schnelle Entscheidungshilfe.

Ich will alle meine Raspberry Pis einmotten und auf einem Proxmox konsolidieren. Meine Anforderung sind wenig Stromverbrauch, mindestens 3 interne Festplatten und max 600€.

Folgende ziehe ich in Betracht, weiß aber nicht, was davon am beasten geeignet ist.

71liuwCpfpL._AC_SL1500_.jpg


71eGA84CWHL._AC_SL1500_.jpg


71maiy8FO9L._AC_SL1500_.jpg


71+LNPEmVfL._AC_SL1500_.jpg


Für welchen würdet ihr euch entscheiden und warum?

Und ja, vermutlch sind alle überdimensioniert, aber es soll auch für viele Jahre reichen.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh