☰

Mehrere Anwendungen von zu Hause aus hosten

tag-icon • tag-icon networking dns ssl nginx dynamic-dns
Mehrere Anwendungen von zu Hause aus hosten

Ich hoste mehrere Anwendungen von zu Hause aus. Meine aktuelle „schmutzige“ Lösung besteht darin, mehrere Ports in meinem Router weiterzuleiten. Der Nachteil ist, dass ich mir merken muss, welche Ports welche Anwendung bedienen. Außerdem gibt es Dienste/Anwendungen, die vorne ein Nginx benötigen, um TLS-gesicherte Verbindungen bereitzustellen, z. B. Nextcloud.

Ich möchte die Dinge aufräumen. Die ideale Lösung wäre, ein Letsencrypt-Wildcard-Zertifikat zu erhalten und in Nginx so etwas wie (gekürzte Pseudokonfiguration) zu haben:

server {
    server_name nextcloud.mydyndnsdomain.org;
    location / {
        proxy_pass https://internalip:port;
    }
}
server {
    server_name someotherapplication.mydyndnsdomain.org;
    location / {
        proxy_pass https://internalip:anotherport;
    }
}

Das Problem ist, dass ich keinen DynDNS-Anbieter finde, der Subdomains zulässt. Mehrere Hostnamen sind zulässig, aber keine Subdomains dazu.

Eine andere Lösung, die mir in den Sinn gekommen ist, wäre etwa diese:

server {
    server_name mydyndnsdomain.org;
    location /nextcloud/ {
        proxy_pass https://internalip:port;
    }
    location /someotherapplication/ {
        proxy_pass https://internalip:anotherport;
    }
}

Das Problem ist, dass, sobald ich beispielsweise mit Nextcloud arbeite, weitere Links nicht mehr funktionieren, da das /nextcloud/in der URL fehlt. Daher wäre die "korrektere" Version davon

server {
    server_name mydyndnsdomain.org;
    location /nextcloud/ {
        redirect 301 https://internalip:port;
    }
    location /someotherapplication/ {
        redirect 301 https://internalip:anotherport;
    }
}

Das Problem ist, dass ich nicht mehr von einer sicheren TLS-Verbindung profitiere und im Router immer noch Ports weiterleiten muss und so weiter und so fort.

Oder ich registriere natürlich mehrere Hostnamen bei meinem DynDNS-Anbieter. Dann bräuchte ich aber wieder mehrere Zertifikate und bin auf eine bestimmte Anzahl von Hostnamen beschränkt. Und muss mir merken, welche Anwendung unter welchem ​​Hostnamen ausgeliefert wird.

Meine Frage ist also, wie machen das andere Leute? Was ist die empfohlene Lösung? Oder habe ich aufgrund meiner schlechten Nginx-Kenntnisse etwas falsch verstanden?

Antwort1

Alle drei Methoden lassen sich relativ einfach umsetzen.

Das Problem ist, dass ich keinen DynDNS-Anbieter finde, der Subdomains zulässt. Mehrere Hostnamen sind zulässig, aber keine Subdomains dazu.

Kaufen Sie Ihre eigene Domain. Dann können Sie so viele Subdomains darunter erstellen, wie Sie möchten. Es gibt zwei Möglichkeiten, wie Sie die Adressen dynamisch aktualisieren können:

Mach es selbst:Kaufen Sie Ihre eigene Domäne, hosten Sie ihre Nameserver bei einem DNS-Anbieter, der über eine Art API verfügt, stellen Sie sicher, dass für die DNS-A-Einträge eine ausreichend niedrige TTL konfiguriert ist (z. B. 5–10 Minuten) und das war‘s – Sie haben Ihr eigenes „DyndNS“ mit unbegrenzten Subdomänen.

Die Certbot/LetsEncrypt-Community könnte eine gute Quelle für kompatible (d. h. automatisierbare) DNS-Anbieter sein, da DNS-basierte Challenges eine Voraussetzung für den Erhalt eines Wildcard-Zertifikats von LetsEncrypt sind, sodass Sie diese Funktionalität ohnehin benötigen. (Nicht, dass Sie wirklich ein Wildcard-Zertifikat benötigen …)

Es besteht kaum ein Unterschied zwischen der Aktualisierung von TXT-Einträgen durch Certbot für LE-Herausforderungen und der Aktualisierung von A-Einträgen durch einen Dyndns-Client. Einige DNS-Anbieter verfügen sogar über eine mit Dyndns-Updatern kompatible API.


¹ Der Nameserver-Host muss nicht derselbe Ort sein wie der Registrar, der Ihnen die Domain verkauft hat – alle Registrare erlauben Ihnen, die Nameserver-Adressen zu ändern, so dass Sie beispielsweise eine Domain bei Namecheap kaufen, aber DNS bei Linode oder Route53 oder was auch immer am bequemsten ist, hosten können.

² Das Einzige, was bleibt, ist dieinternAusbreitungsverzögerung zwischen den Nameservern der DNS-Anbieter – während die meisten Anbieter mit der Bereitstellung der neuen Datensätze beginnen, sobald Sie diese übermitteln, gibt es immer noch einige, die ihre Datenbanken nur alle 10–15 Minuten neu laden. Seien Sie also bei diesen Anbietern vorsichtig, wenn Sie extrem schnelle Aktualisierungen benötigen.


Aktuellen Anbieter verwenden:Kaufen Sie Ihre eigene Domain und verwenden Sie CNAME-Einträge, um die verschiedenen Subdomains auf Ihren bestehenden DynDNS-Namen zu verweisen. Dies erfordert keine zusätzliche Einrichtung, weder von Seiten des DynDNS-Anbieters (dieser kann einen Resolver, der einem CNAME folgt, nicht von einem unterscheiden, der nur eine direkte Abfrage macht), noch von Ihrer Seite (die Verwendung von CNAME ist für HTTP und TLS unsichtbar). Jeder normale Nameserver reicht ebenfalls aus, da die CNAME-Einträge selbst nicht aktualisiert werden müssen.

Wenn der CNAME vorhanden ist, besuchen Sie beispielsweisehttps://cloud.example.comSie erhalten automatisch die IP-Adresse von example.dyndns.org, aber Nginx erkennt Sie dennoch als Versuch, cloud.example.com zu besuchen und wählt den richtigen Server{}-Block und das richtige Zertifikat aus.

Diese Option hat zwei Nachteile: Sie verwalten nun die Konfiguration der Domäne überzweiDienste, und Sie sind immer noch auf IP-Adressaktualisierungen beschränkt – Sie können dies höchstwahrscheinlich nicht für LE-DNS-Herausforderungen verwenden, also kein Wildcard-Zertifikat für Sie.

sobald ich beispielsweise mit Nextcloud arbeite, funktionieren weitere Links nicht mehr, da /nextcloud/ in der URL fehlt.

Die meisten Webanwendungen können so konfiguriert werden, dass sie sich an jeder beliebigen Basis-URL befinden. Nextcloud hat beispielsweise dieüberschreibeWebRootOption dafür.

Daher wäre die "korrektere" Version

redirect 301 https://internalip:port;

Nein, wenn Sie die Apps von außen zugänglich machen möchten, dann sollten Sie dasexternAdresse (und Port) – der Sinn von Weiterleitungen besteht darin, dass sie vom Client verwaltet werden und externe Clients keine Verbindung zu Ihrer internen IP-Adresse herstellen können.

Das Problem ist, dass ich nicht mehr von einer sicheren TLS-Verbindung profitiere

Wenn Ihre Weiterleitungen auf unterschiedliche Ports derselben DynDNS-Domäne verweisen, hindert Sie nichts daran, TLS auf allen diesen mehreren Ports derselben Domäne bereitzustellen, selbst wenn Sie dasselbe Zertifikat verwenden.

Wenn einige Webanwendungen ein Frontend für TLS benötigen, konfigurieren Sie einfach dasselbe Nginx mit mehreren server{}Blöcken listenauf unterschiedlichen Ports. Auf Port 443 können Sie beispielsweise Weiterleitungen bereitstellen und auf Port 8443 einen Proxy /zu Nextcloud einrichten.

verwandte Informationen