Proxmox | Mehrere VMs öffentlich erreichbar machen - Fritzbox 6591 Cable

[Stefan.M1990]

Hallo CB-Community,

ich habe eine Frage hinsichtlich der Realisierung von einem Proxmox Heimserver.
Diesen möchte ich für interne sowie externe Zwecke nutzen.

Mein Ziel:
Mein generelles Ziel ist es, auf diesem Heimserver diverse virtuelle Maschinen zu erstellen wie z.B. zwei kleine Webserver sowie Testsysteme, die "von außen" nicht erreichbar sein sollen. Somit würde ich folgendes Szenario bilden:

Hardware (1700X,32GB)	Heimserver	nur internes Netzwerk
VM1	Webserver01	öffentlich erreichbar machen
VM2	Webserver02	öffentlich erreichbar machen
VM3	Testserver01	nur internes Netzwerk
VM4	Testserver02	nur internes Netzwerk

Als Router nutze ich eine AVM Fritzbox 6591 Cable.

Mein Problem:
Nach längerem ausprobieren musste ich feststellen, dass ich über das DynDNS (Fritzbox) nur eine IP Adresse "durchgeschleift" bekomme. Somit konnte ich erfolgreich realisieren, dass Webserver01 über meine Domain erreichbar ist. Nun finde ich leider keine Möglichkeit, den zweiten Server ebenfalls öffentlich erreichbar zu machen, da ich über mein DynDNS(Fritzbox) nur einen DynDNS Account eintragen kann. Gibt es hier eine Lösung oder einen komplett anderen Ansatz, wie ich solch eine Thematik angehen sollte?

Ich hoffe die Informationen reichen, ansonsten bitte gezielt nachfragen... versuche bestmöglich die Fragen zu beantworten.
Vielen Dank im Voraus.

Viele Grüße
Stefan

 

[Deeen]

Wenn die virtuellen Maschinen über unterschiedliche Ports erreichbar wären, würde das schon gehen. VM1 auf 8443, VM2 auf 8444 z.B., so dann die Forwarding Regeln in der Fritzbox einstellen.

 

[Departet]

Oft können DynDNS Einträge auch vom OS aktualisiert werden. Je nach Anbieter gibt es Software dafür. Dann nur noch die entsprechenden Ports öffnen (sollte ja schon passiert sein).
Also Software auf Server 1 & 2 mit den jeweiligen DynDNS Daten und dann sollte es laufen.

 

[Deeen]

Alternativ wäre auch ein Reverse-Proxy (z.B. als VM0) denkbar.

 

[spcqike]

wie @Deeen sagte, suchst du einen Reverse-Proxy.
Das ist deine einzig sinnvolle Möglichkeit das zu realisieren.

Dein DynDNS zeigt nach Hause auf die Fritzbox. diese leitet POrt 80 und 443 an deinen Reverse-Proxy weiter. Jenachdem, welche DNS anfragt, gibt dieser Seite A oder Seite B aus.

bspw. hast du ein DynDNS für deine Hauptdomain "Domain.TLD". Dann benötigst du sinnvoller Weise auch Subdomains, anhand derer du deine Dienste/Services unterscheidest. (Sub1.Domain.TLD, Sub2.Domain.TLD) Die Subdomains können einfache CNAME Einträge beim "Domainverwalter" sein, verweisen/nutzen also die gleiche IP, die auch die Hauptdomain verwendet.

Der Reverse-Proxy erkennt, dass Domain.TLD oder Sub1.Domain.TLD oder Sub2.Domain.TLD angefragt wurde und liefert zu jeder Anfrage die passende Seite.

Der Reverse-Proxy kann/sollte auch gleichzeitig die HTTPS Zertifikate (Lets Encrypt mit Certbot) holen und passend ausliefern, damit die modernen Browser da keine PRobleme machen.

Es ist nicht ratsam, einfach Portweiterleitungen wie "8080 -> Webserver01:80" und "9080->Webserver02:80" einzurichten. Das gibt bei vielen Browsern und Anwendungen Probleme. von HTTPS ganz zu schweigen.


Eine weitere Empfehlung:
Guck dir Docker an und arbeitet dich ein bisschen damit ein. Viele Vorhaben lassen sich prima mit Docker und Containern realisieren. Es braucht wahrscheinlich keine zwei VMs für zwei Webserver. Es reichen zwei Container auf einer VM. Das reduziert den Wartungsaufwand (Updates der VM) und Overhead (Ressourcen, die die VM/das OS benötigt, Festplattenspeicher, RAM, CPU ...) ungemein, ebenso wie das Risiko einer SIcherheitslücke in einem der Dienste. Der Container an sich ist bereits isoliert und kommt nicht ohne weiteres "raus", also in dein Netzwerk.

Es gibt genug gute Anleitungen, wie man einen Reverse-Proxy mit php Containern betreibt und das Ganze auch mit automatischen Lets Encrypt Zertifikaten hinbekommt.

edit:
Da du nach mehreren DynDNS gefragt hast:
Wenn du mehrere Domains registriert hast, kannst du auch die erste Domain per DynDNS anmelden/registrieren, und die zweite als CNAME anlegen, der einfach auf die erste Domain zeigt. Alternativ in der Fritzbox auf Benutzerdefiniert gehen und ein Skript wie
"https://dyndns.strato.com/nic/update?hostname=domain.tld&mx=mail.domain.tld" benutzen. In meinem Fall (Strato) sieht es so aus. der MX Record (für die Emails) darf kein CNAME sein, aber die Fritzbox kann den MX Record nicht direkt setzen, nur über diesen Weg. GGF. kann man so auch mehrere Hostnames mit einmal setzen lassen.
Oder man verwendet einen anderen Dienst / Cronjob / Container zum aktualisieren der DynDNS Einträge.

 

[ayngush]

Bevor ich in Proxmox eine VM mit Docker aufsetze, benutze ich doch lieber gleich die Linux Container (LXC) Virtualisierung von Proxmox.
Docker ist ja am Ende nichts anderes, nur mit unnötigen Overhead in Form von nicht vertrauenswürdigen, schlecht gewarteten Repositorys drum herum.

Der Rest wurde ja oben schon genannt und grob umrissen nochmal:

• Öffentliche Domain mit DNS-Verwaltung besorgen
• CNAME Einträge von Subdomains auf die DYN-Domain einrichten
• Reverse Proxy mit namensbasierten Routen aufsetzen, der dann die Anfragen für sub1.domain.invalid auf Server 1 schickt und sub2.domain.invalid auf Servber 2 usw.
• Ein Lets Encrypt Wildcard-Zertifikat für *.domain.invalid besorgen, welches auf dem Reverse-Proxy läuft.
• Mit unbound einen Split Brain DNS Resolver aufsetzen für die Verteilung intern/extern.
• Ein weiteres Wildcard-Zertificat für *.home.domain.invalid besorgen für die internen Webserver und die interne DNS-Zone.

 

[ARNOFPS]

Die vorgeschlagenen Lösungen sind gut, aber fraglich, ob ihm das jetzt weiterhilft, denn ich glaube, dass OP das grundsätzlich mit den Ports und IPs nicht verstanden hat... siehe...

Nun finde ich leider keine Möglichkeit, den zweiten Server ebenfalls öffentlich erreichbar zu machen, da ich über mein DynDNS(Fritzbox) nur einen DynDNS Account eintragen kann.

@Stefan.M1990

Dein Kabel Anschluss Zuhause hat nur eine IP-Adresse. Hier gilt es zu unterscheiden, ob du eine native IPV4 bekommst oder nur IPV6 nativ angebunden hast. Lies mal hier zum Unterschied.

Was DynDNS tut, ist nur einen Verweis (DNS Eintrag, A- oder AAAA-Record) auf deine aktuelle IP-Adresse anzulegen (diese kann sich ja durch eine Neuverbindung von deinem Kabelrouter jederzeit ändern). Ein weiterer DynDNS Account würde hier nix bringen, weil es immer wieder nur die gleiche IP-Adresse wäre. Wenn es multiple Domains sein sollen, kannste auch einfach einen CNAME-Eintrag bei einer anderen Domain manuell auf die DynDNS Adresse setzen, hat den gleichen Effekt, CNAME ist eine Art "Veweis" auf einen anderen DNS-Record.

Aber... pro IP-Adresse ist ein Port nur einmal verfügbar.
Ein Webserver nutzt für HTTP Port 80 und für HTTPS Port 443.

Kurz gesagt: Mehrere Webserver über Port 80 über eine IP-Adresse ist schlicht nicht möglich.

Daher die Vorschläge hier mit dem Reverse Proxy, der stattdessen auf den Port 80 "hört" und je nach Anfrage diese dann intern an eine andere IP oder einen anderen Port weiterleitet.

 

[Deeen]

Oder wie ganz zu Anfang bereits gesagt, einfach unterschiedliche Ports für die VMs nehmen, wenn nichts dagegen spricht im Browser http://dyndnszeugs:8444 aufzurufen.

 

[Tokolosh]

Das halte ich aber für keine gute Idee, dagegen spricht einiges. Also, wenn dann sollte man das auch vernünftig machen:

• Reverse Proxy, der SSL terminiert
• SSL Zertifikate
• HTTP to HTTPS redirect (Anfragen auf port 80 -> 443)

Im Jahre 2021 sollte es schon SSL + Zertifikat sein für öffentliche HTTP Requests.

 

[Deeen]

Mein Favorit wäre auch ein Reverse-Proxy (Trafik o.ä.), aber jede VM für sich kann auch HTTPS sprechen. Am Ende muss der TE sich entscheiden.

 

[DerMuuux]

Ich werfe hier mal den Nginx-Proxy-Manager in den Raum. Damit sollte es möglich sein mehrere Webseiten über eine IP und den Port 80 ansprechen zu können. Dank der GUI ist das alles auch recht komfortabel einzurichten.

Ansonsten kann ich, wie bereits andere schon gesagt haben, nur sagen, dass es durchaus Sinn ergibt nicht für alles eine eigene VM zu betreiben und stattdessen auf Docker oder LXCs zurück zu greifen.