Hallo Freunde,
Angenommen ich habe Domain Pizzasebastian.de und mehrere Dienste auf meinem Server (192.168.178.69) auf Port 2000 - 2010 laufen. Kann ich das irgendwie so verknüpfen dass Ich z.b. folgendes habe: Dienst1.pizzasebastian.de -> 192.168.178.69:2002 Dienst2.pizzasebastian.de -> 192.168.178.69:2005
(Ohne das nur stumpf weitergeleitet wird, im Browser sollte schon die Domain stehen)
Die Addresse sollte aber auch nur aus dem Netz erreichbar sein, also ich möchte kein Port dafür öffnen (oder ähnliches)
Du brauchst einen proxy der auf Port 80 (oder 443 mit SSL) hört. Der Proxy leitet dann auf die Dienste weiter. Recht einfach zu konfigurieren ist der Nginx Proxy Manager https://nginxproxymanager.com/
Dann musst du noch einen lokalen DNS Eintrag setzen: ein A Record von *.Pizzasebastian.de auf die IP Adresse. DNS kannst du in einigen Routern direkt setzen. Alternativ kannst du auch einen pihole nutzen.
Alternativ kann ich Caddy sehr empfehlen.
Hat ebenso HTTPS fest eingebaut und nutzt sehr einfache, aber mächtige Konfigurationsdateien statt eines GUI.
Einfaches Beispiel für einen solchen Anwendungszweck:
abc.example.com { reverse_proxy localhost:2000 } xyz.example.com { reverse_proxy localhost:2020 }
Damit ist der Dienst auf Port 2000 unter https://abc.example.com zu erreichen bzw. der Dienst auf Port 2020 unter https://xyz.example.com.
Ein Hochwähl für caddy
Wenn du lokal mit caddy arbeiten willst musst du aber das automatische https umgehen, das funktioniert nur wenn caddy auch richtig von außen erreichbar ist. Für .local geht das nicht. Um das funktieren zu lassen schreib einfach
http://dienst.local { Reverse_proxy 192.168.xxx.xxx:xxx }
Ich nutze dafür ein Wildcard-Zertifikat (via DNS Challenge).
Hat den Vorteil, dass beliebige, auch ausschließlich lokale Subdomains genutzt werden können und die einzelnen Subdomains nicht bei crt.sh auftauchen. Hat aber den Nachteil, dass man caddy mit zusätzlichen Modulen installieren muss.
Auch ne Variante. Mir wäre für Lokal zu viel Aufwand :)
alternativ pizzasebastian.de als A record und die dienste als cname, wobei es dafuer hier eigentlich keinen grund gibt.
So funktioniert das nicht. Der Port muss trotzdem angegeben werden beim Aufruf wenn du keinen Reverse Proxy auf dem Default Port hast.
Aeh, ja, missverstaendlich beschrieben. Natuerlich reicht das nicht aus, ich habe mich dabei lediglich auf DNS bezogen.
Also entweder Dienst1.pizzasebasitan.de:2000, dann kann man sich die einzelne Dienste aber auch sparen, oder eben mit verschiedenen “Dienten” und dann mit nem reverse proxy, ja.
Okay aber dann kann ich auf der gleichen IP nur 1 bzw 2 Dienste laufen lassen oder?
Nein so viele du willst, der reverse proxy (in diesem Fall nginx) kann anhand des Host-Headers an den richtigen Dienst leiten. In deb Host Header schreiben die Browser/Clients die Host Angabe in der Url, nicht die IP des Hosts. Also da steht bei einer Anfrage an abc.bla.com der wert abc.bla.com drin und bei def.bla.com entsprechend def.bla.com drin. Auch wenn für die gleiche IP hinterlegt ist.
Edit: Das was du möchtest ist ein reverse proxy, unter dem Stichwort findest du viele Infos.
Okay das nginx installier ich mir morgen mal. Das läuft dann quasi so: Domain1 -> nginx -> Port 10 Domain2 -> nginx -> Port 20
Wobei ich dann port 80 bzw 443 trotzdem öffnen muss oder?
Und das domain1/2 Richtung nginx zeigt mach ich dann in der domainverwaltung.
Korrekt, auf Port 80 und 443 sitzt dann nginx und leitet an den echten dienst weiter (und schickt die antwort zurück)
okay. Wie sieht sowas sicherheitstechnisch aus? Also ich habe z.b. Nodered, Uptime Kuma, Homeassistant, WikiJS, Grafana, Duplicati und noch ein paar weitere Dienste am laufen. Die haben zwar alle eingerichtete Login Pages aber wie viel größer wird das Risiko für einen Angriff?
Also ich bin jetzt kein super duper Experte und so pauschal lässt es sich nicht beantworten. Aber im Grunde ist das Szenario dass einer deiner Dienste übernommen werden könnte und die Frage ist auf wieviel kann der Dienst dann zugreifen? Wenn alles auf dem gleichen System unter root läuft ohne SeLinux o.Ä. sieht’s übel aus ;)
80/443 müssen dann offen sein. Alle anderen Ports kannst du dann sogar schließen, weil das dann alles intern über loopback vom proxy gehandelt wird. Ich empfehle Traefik (mit Docker), das kann dir mit ACME automatisch für deine Services Zertifikate generieren und die Kommunikation absichern. Vom Nginx Proxy Manager würde ich etwas Abstand halten, da wurden lange existierende gravierende Sicherheitslücken gefunden. Nginx (was drunter liegt) ist aber sehr robust.
Wenn deine Dienste in Docker laufen, würde ich Traefik empfehlen. Einmal eingerichtet, musst du nur noch label an die Container Anhängen und Traefik kümmert sich um Subdomains
Wenn man sich einmal in Traefik eingearbeitet hat, ist das so viel einfacher als jedes Mal die nginx Config anzupassen
Sollte über einen Reverse Proxy mit nginx oder ähnlichem gut zu lösen sein.
Ist recht easy. Einmal pro Domain
certbot
ausführen um ein Zertifikat zu bekommen, im Router die Domains auf den lokalen Server auflösen lassen und dann mit NGINX virtual hosts für jede Domain erstellen, die viaproxy-pass
auf die jeweilige IP samt Port zeigen.
Klingt vielleicht kompliziert, ist aber eigentlich super easy, wenn man weiß wie es geht.Falls man noch nie mit NGINX gearbeitet hat, ist die Konfiguration vielleicht etwas kompliziert. Viele bevorzugen deswegen mittlerweile Caddy, aber damit hab ich keine Erfahrung.
EDIT:
certbot
ist hier komplett optional, aber dann hat man auch eine sichere Verbindung zum Server und keine Sicherheitswarnungen.Man kann
certbot
auch mehrere Domains geben, damit er ein einziges Zertifikat für alle (Sub-)Domains generiert. Und man braucht auch kein Zertifikat für eine HTTPS-Verbindung zum Server, aber wenn man keins hat meckert der Browser berechtigterweise rum, weil dann das Risiko eines Man-in-the-middle-Angriffs besteht.Hier auch ein gutes Tutorial für einen Nginx reverse proxy: https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-as-a-reverse-proxy-on-ubuntu-22-04
Und man braucht auch kein Zertifikat für eine HTTPS-Verbindung zum Server
Na, irgendein Zertifikat braucht man schon, wenn auch nicht unbedingt ein signiertes.
wenn man hinnimmt, dass die Verbindung zwischen proxy und origin unverschlüsselt über http läuft braucht man gar kein Zertifikat
Gestern noch ein Video dazu gesehen und auch schon angefangen. Funktioniert gut:
Eine Option wäre noch dem Server mehrere feste IPS zu geben. Jeder der beiden Dienste kriegt ne eigene.
DNS sagt nur welche IP genutzt wird. Dem entsprechend wird bei http standardmäßig von Port 80 ausgegangen.
Ansonsten eine der Reverse Proxy Lösung der anderen Kommentare benutzen.