Reverse-Proxy / Weiterleitung für http(s)-Port von Subdomains, welches Paket ist dafür geeignet?

[Bodenseematze]

Hallo,

ich möchte über per DynDNS aktualisierten Subdomain-Namen (z.B. cloud.meinedomain.de) den http und https-Port auf interne Rechner / Port in meinem Netzwerk weiterleiten, d.h. wenn ich z.B.
https://cloud.meinedomain.de aufrufe, soll er den Web-Server auf einer internen Box ansprechen (auf einem eigenen Port), wenn ich aber
https://vpn.meinedomain.de anspreche, soll er das an einen anderen Rechner umleiten.
Beide Subdomain-Namen werden aber auf die selbe IP-Adresse (von meiner Fritzbox) aufgelöst.
Außerdem soll auch die Fritzbox selber noch über https ansprechbar bleiben (wenn auch nur von innen).

Geht das?
Wenn ja, mit welchen Freetz-NG-Paket kann ich das erreichen? Mit lighthttpd oder HAProxy oder tinyproxy oder...?
Und wie konfiguriere ich das dann?

[fda77]

Ich benutze dafür lighttpd. Dafür hab ich auch ein letsencrypt wirldcard zerifikat via dns. In meiner Domain hab ich auch alle Subdomains als Wildcard. So kann das nicht einfach gescannt werden.
Man kann statt Subdomains auch Subdirectories verwenden und braucht dann nur ein normales Zertifikat.
Intern nutze ich oft nur http Weiterleitungen

[Bodenseematze]

Kannst Du dafür mal Deine (anonymisierte) lighthttpd-Konfiguration posten?
Hast Du dann lighthttpd mit "Select ACME.sh" und / oder "Select dehydrated" compiliert?
Ich hatte es in der Vergangenheit nicht wirklich geschafft, lighthttpd auf der Box so zu konfigurieren, dass es funktioniert hätte ("als reverse proxy")...
Die LetsEncrypt-Zertifikatsverwaltung wollte ich eigentlich intern von der jeweiligen internen Box erledigen lassen (z.B. um ein von außen erreichbare Nextcloud-Instanz zu hosten...)

[fda77]

Bei mir hat nur der lighttpd ein öffentliches Zertifikat, da der alles transparent weiterleitet, ich finde da so einfacher. Der lighttpd ist mittleriweile aber auf einem Raspberry, ich hatte das früher auf einem avm geräte.

$HTTP["url"]  =~ "^/dyndns/(devicea|alias)/"             { proxy.server = ( "" =>  (( "host" => "192.168.178.2", "port" => 81   ))) }
$HTTP["host"] =~ "^deviceb\.dyndns\.(domaina|domb)\.de$" { proxy.server = ( "" =>  (( "host" => "192.168.178.3", "port" => 82   ))) }
$HTTP["host"] =~ "^devicec\.dyndns\.(domaina|domb)\.de$" { proxy.server = ( "" =>  (( "host" => "192.168.178.4", "port" => 83   ))) , ssl.pemfile = "/etc/../special.pem", ssl.ca-file = "/etc/.../special.pub" }

Mit Apache geht das aber auch!

Ich hab dns für eine subdomain meiner Domain zum kostenlosen https://dns.he.net/ weitergeleitet, und acme.sh hat dafür ein plugin für die dns-aktualisierung

[Bodenseematze]

das DynDNS läuft bei mir aktuell über das inadyn-mt-Paket und geht an Strato - bei denen habe ich Domains gehostet; funktioniert seit Jahren problemlos...

In Deinem Beispiel sind die beiden Namen, die von außen angesprochen werden "deviceb.dyndns.domaina.de" (alternativ "deviceb.dyndns.domb.de") und "devicec.dyndns.domaina.de" (alternativ "devicec.dyndns.domb.de") und die werden an internen Rechner "192.168.178.3:82" bzw. "192.168.178.4:83" umgelenkt, korrekt?
Einen Quell-Port hast Du nicht angegeben - ist das also nur für http?
Verstehe ich das richtig, dass bei den internen Servern dann der Hostname durch ihren eigenen ersetzt wird und der Rest der URL dort ankommt?
Wie funktioniert das mit dem Rückweg (Antworten)?

Und Deinen ersten Eintrag mit der URL verstehe ich auch nicht so ganz - heißt das, egal welcher Name angesprochen wird, sobald hinten dran "/dyndns/devicea/" oder "/dyndns/alias/" angegeben ist, wird das an "192.168.178.2:81" umgeleitet?
Auch hier: welches Protokoll ist dabei unerheblich?
Was kommt denn beim Server auf "192.168.178.2" genau an? Wird dort ebenfalls der host umgelabelt und der Rest der URL bleibt?

[fda77]

Ich benutze http und https, auf den Standardports. Für alles interne nutze ich "*.irgendwas.domain.de". Sowohl im DNS als auch für das Zertifikat. So hab ich "geheime" Namen (xx..irgendwas.domain.de) und man kommt nur mit diesem auf das interne Gerät. Das hilft gegen das Scannen. Für neue Geräte muss man dann nur was im Webserver ändern. Auch kann man von externe http-only Dinge (Freetz webif..) von extern via https ansprechen. Für die Weiterleitungen nutze ich die IPs

Das "URL" ist einfach eine Alternative, wenn man nur 1 dyndns Namen hat

[Bodenseematze]

Hmm, irgendwie überfordert mich die lighthttpd Konfigurationsseiten in Freetz-NG immer noch - was muss ich denn da zwingend einstellen und was kann ich für einen reinen Reverse-Proxy getrost ignorieren?
Und wie bekomme ich mod_proxy geladen - das Modul (ich habe beim compilieren mit ausgewählt) wird auf der Standard-Konfigseite überhaupt nicht erwähnt.
Ich habe jetzt mal auf der Unterseite "Erweitert" folgendes eingetragen:
server.modules += (mod_proxy)
Ist das so korrekt?

Und wo trage ich dann die Umleitungsregeln ein? Auch dort unter "Erweitert"?

[fda77]

Das "Zusätzliche Konfigurationsoptionen" wird an die config angehängt, da kommt alles rein was nicht sonstwie konfigurierbar ist.
Es könnte sein dass man das Modul nicht mehr laden muss, manche werden mittlerweil immer geladen. Schau auch ins syslog

[harryboo]

@Bodenseematze: Du kannst auch einfach das Paket tinyproxy benutzen. Die Konfiguration ist selbsterklaerend.
funktioniert allerdings nicht mit subdomains sondern mit erweiterungen nach dem hostname (https://meinedomain/freetz)

[fda77]

@harryboo: Ist damit SNI möglich, also mehrere https Hostnamen zu verschiedenen (internen) Servern?