Dieser Blog beschäftigt sich ja mit etlichen Themen rund um selbst gehostete (Web-)Anwendungen. Die eigene Cloud mit Nextcloud ist hierbei wohl das größte Themengebiet, aber es wurden auch andere Lösungen gezeigt, wie z.B. der eigene Firefox Sync Server.
Spätestens, wenn mehrere Webanwendungen auf einem (Home-)Server gehostet werden sollen, braucht man ein Konzept, um diese Anwendungen voneinander zu trennen. Über lange Zeit habe ich in diesem Blog immer die Variante bevorzugt, mehrere Webanwendungen einfach in verschiedenen Unterverzeichnissen des Webservers laufen zu lassen, wie bei diesem älteren Artikel über Nextcloud. In Zukunft werde ich diese Trennung eher über unterschiedliche (Sub)-Domains realisieren, siehe dazu der aktuelle Artikel zu Nextcloud. Darüber hinaus besteht noch eine dritte Möglichkeit, die Trennung durch die Verwendung unterschiedlicher Ports umzusetzen.
In diesem Artikel möchte ich daher nun genauer auf diese Varianten eingehen, Vor- als auch Nachteile beschreiben und die möglichen Webserver-Konfigurationen skizzieren. Die Ausführen sollen dabei eher allgemein gehalten und nicht an einer speziellen Webanwendung festgemacht werden.
Auch wenn in diesem Artikel nginx als Webserver verwendet wird, so sind die Konzepte auch auch andere Webserver (z.B. Apache) übertragbar.
Inhalt
Basics: Domains, Webserver und virtuelle Hosts
Zunächst soll kurz skizziert werden, was zum Hosten einer Webanwendung benötigt wird.
Domain
Erst einmal wird eine Domain benötigt, über die die Webanwendung später erreichbar sein soll. Im Heim-Bereich kommt hier oftmals eine DynDNS-Domain zum Einsatz, da ein privater Internet-Anschluss keine feste IP-Adresse hat. Einfach ausgedrückt mappt ein DynDNS-Dienst immer die Domain auf die aktuelle IP-Adresse.
Es gibt eine große Auswahl an DynDNS-Diensten. Aus Gründen des Datenschutzes sollte man dabei einen Anbieter wählen, dessen Server-Standort in Deutschland liegt. Einige empfohlene Anbieter sind z.B.:
Im Business-Bereich werden meist feste IP-Adressen verwendet, daher ist hier kein DynDNS-Dienst notwendig. Hier reicht es dann aus, einen A-Record (IPv4) bzw. einen AAAA-Record (IPv6) für die Domain zu setzen. Dies wird meist in der DNS-Verwaltung des Domain-Providers konfiguriert. Da sind das Vorgehen von Anbieter zu Anbieter unterscheidet, kann an dieser Stelle leider keine allgemeingültige Anleitung erfolgen.
Router-/Netzwerk-Konfiguration
Damit die später zu erstellende Webanwendung dann später auch im Internet erreichbar ist, müssen im Router noch Port-Forwardings definiert werden. Wichtig sind dabei die Ports 80 (HTTP) und 443 (HTTPS). Anfragen, wie über diese Ports eingehen, müssen auf den Server weitergeleitet werden, auf dem der Webserver (nginx) läuft.
Auch hier unterscheidet sich das Vorgehen je nach Router-Hersteller. Wie dies z.B. bei einer FritzBox eingerichtet werden kann, wird auf den AVM-Hilfeseiten erklärt.
Auf dem folgenden Screenshot sieht man die Einrichtung eines Port-Forwardings für Port 80. Analog ist dann mit dem Port 443 zu verfahren.
Bei Bedarf können hier auch andere Ports freigeschaltet werden. Dies muss dann später bei der Konfiguration der virtuellen Hosts beachtet werden.
Webserver
Als Webserver kommt im Rahmen des Artikels nginx zum Einsatz. Damit dieser eine Website ausliefern kann, wird mindestens ein virtueller Host (vHost) benötigt. Bei nginx wird ein vHost durch einen Server-Block definiert.
Im folgenden Beispiel werden zwei sehr einfache virtuelle Hosts definiert – einer für HTTP (Port 80) und einer für Port 443 (HTTPS). Beide bedienen die gleiche Domain und es wird einfach nur statischer Content (z.B. HTML) ausgeliefert, welcher im Verzeichnis /var/www/meinedomain.de liegt:
server {
# Virtual host 1:
# - Listens on port 80 (HTTP) - IPv4 and IPv6.
# - Is capable of serving requests for domain "meinedomain.de" and IP address 192.168.178.60 (local IP of server).
# - Forwards all requests to the second vHost (HTTPS).
listen 80 default_server;
listen [::]:80 default_server;
server_name meinedomain.de 192.168.178.60;
root /var/www/meinedomain.de;
location / {
# Enforce HTTPS
return 301 https://$server_name$request_uri;
}
}
server {
# Virtual host 2:
# - Listens on port 443 (HTTPS) - IPv4 and IPv6.
# - Is capable of serving requests for domain "meinedomain.de" and IP address 192.168.178.60 (local IP of server).
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name meinedomain.de 192.168.178.60;
# Certificates used
ssl_certificate /etc/letsencrypt/meinedomain1.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/meinedomain1.de/key.pem;
ssl_trusted_certificate /etc/letsencrypt/meinedomain1.de/ca.pem;
# Include headers and SSL specific stuff.
include /etc/nginx/snippets/ssl.conf;
include /etc/nginx/snippets/headers.conf;
root /var/www/meinedomain.de;
}
Hinweis: Die für einen HTTPS-vHost notwendige SSL-Konfiguration wird hier nicht genauer behandelt (bis auf die Einbindung der TLS-Zertifikate), da dies den Rahmen des Artikels sprengen würde. Daher wird diese Konfiguration den vHosts hier nur beispielhaft per „include“ hinzugefügt. Mehr Informationen zu Zertifikaten und der SSL-Paramter kann folgenden Artikeln entnommen werden:
- Let’s Encrypt Zertifikate mit acme.sh und nginx
- RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung)
- TLSv1.3 unter Ubuntu Server 18.04 LTS mit nginx
Die virtuellen Hosts werden normalerweise im Verzeichnis /etc/nginx/conf.d gespeichert (mit der Dateiendung .conf), so dass nginx diese beim Starten automatisch anzieht. Zur besseren Übersichtlichkeit wird meist eine Datei pro vHosts angelegt. Wenn – wie in diesem Beispiel – der virtuelle Host für HTTP lediglich für eine generelle Weiterleitung auf HTTPS gedacht ist, dann können beide vHosts auch in einer einzelnen Datei aufgeführt werden (z.B. unter /etc/nginx/conf.d/meinedomain.de.conf). Der Name dieser Datei ist prinzipiell egal, wichtig ist nur, dass die Dateiendung .conf lautet, sonst wird diese von nginx nicht geladen.
Die oben aufgeführte Konfiguration der virtuellen Hosts wäre eine Standard-Definition, wenn eben nur eine Webanwendung über eine Domain mit den Standard-Ports (80/443) betrieben werden soll.
Webanwendung
Die Webanwendung wird durch den Webserver gehostet (z.B. Nextcloud, Firefox Sync, etc.). Da sich dieser Artikel mit den verschiedenen Möglichkeiten des Hostings beschäftigt und keine zusätzliche Komplexität durch die Webanwendung selbst hinzugefügt werden soll, wird hier nur von einer einfachen statischen HTML-Website ausgegangen.
Mehrere Webanwendungen parallel hosten
Was passiert nun aber, wenn mehrere Webanwendungen parallel auf den gleichen Server gehostet werden sollen? Hier muss der Webserver auf Grund eines Requests eine Unterscheidung vornehmen können, welche Webanwendung ausgeliefert werden soll. Dazu müssen sich weitere virtuelle Hosts in mindestens einem Aspekt unterscheiden:
- Unterschiedliche Ports.
- Unterschiedliche Domains.
- Unterschiedlicher Pfade auf dem Webserver.
Daraus resultieren für das Vorhaben nun drei Möglichkeiten.
Ein virtueller Host pro Webanwendung (unterschiedliche Ports)
Die einfachste Möglichkeit besteht nun darin, dass man für jede Webanwendung einfach andere Ports verwendet.
Ein Beispiel mit zwei virtuellen Hosts für zwei Webanwendungen könnte dann wie folgt aussehen (der Einfachheit halber werden hier die vHosts für HTTP weggelassen und nur die vHosts für HTTPS gezeigt):
server {
# Virtual host 1/web application 1:
# - Listens on port 443 (HTTPS) - IPv4 and IPv6.
# - Is capable of serving requests for domain "meinedomain.de" and IP address 192.168.178.60 (local IP of server).
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name meinedomain.de 192.168.178.60;
ssl_certificate /etc/letsencrypt/meinedomain1.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/meinedomain1.de/key.pem;
ssl_trusted_certificate /etc/letsencrypt/meinedomain1.de/ca.pem;
# Include headers and SSL specific stuff.
include /etc/nginx/snippets/ssl.conf;
include /etc/nginx/snippets/headers.conf;
root /var/www/webapplication1;
}
server {
# Virtual host 2/web application 2:
# - Listens on port 444 (HTTPS) - IPv4 and IPv6.
# - Is capable of serving requests for domain "meinedomain.de:444" and IP address 192.168.178.60:444 (local IP of server).
listen 444 ssl http2;
listen [::]:444 ssl http2;
server_name meinedomain.de 192.168.178.60;
ssl_certificate /etc/letsencrypt/meinedomain1.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/meinedomain1.de/key.pem;
ssl_trusted_certificate /etc/letsencrypt/meinedomain1.de/ca.pem;
# Include headers and SSL specific stuff.
include /etc/nginx/snippets/ssl.conf;
include /etc/nginx/snippets/headers.conf;
root /var/www/webapplication2;
}
Beide vHosts „hören“ auf den Namen meinedomain.de, unterscheiden sich allerdings im verwendeten Port. Die relevanten Zeilen sind im obigen Beispiel markiert. Für Anwendung 1 ist dies der Standard-Port 443, für Anwendung 2 der Port 444 (dieser Port muss dann auch „offen“ sein, d.h. man benötigt ein weiteres Port-Forwarding).
Da sich die Domains hier nicht unterscheiden, kann aber das gleiche TLS-Zertikat zum Einsatz kommen.
Folglich landet man bei Webanwendung 1, wenn man im Browser nun https://meindomain.de aufruft. Die Angabe des Ports 443 ist hier nicht notwendig, da dies der Standard-Port für HTTPS ist und der Browser diesen automatisch nutzt.
Um Webanwendung 2 aufzurufen, muss der alternative Port 444 im Browser spezifiziert werden: https://meinedomain.de:444
Vorteile
- Einfache Trennung der einzelnen Webanwendungen mittels unterschiedlicher Ports.
- Keine zweite Domain benötigt: Beide Webanwendungen laufen über die gleiche Domain.
- Es wird nur ein TLS-Zertifikat benötigt.
- Anleitungen/Tutorials zu bestimmten Webanwendungen unter nginx können meistens einfach übernommen werden – hier muss dann lediglich der Port angepasst werden.
Nachteile
- Wenig komfortabel: Beim Aufruf der zweiten Webanwendung muss in sämtlichen Clients (z.B. Browser, Apps, etc.) immer der abweichende Port (444) mit angegeben werden. Falls hier z.B. eine App keinen alternativen Port zulässt, kann damit auch nicht auf die zweite Webanwendung zugegriffen werden.
- Weiteres Port-Forwarding benötigt: Für die zusätzlichen Port müssen weitere Port-Forwardings eingerichtet werden. Das widerspricht dem Konzept, dass man möglichst wenige Port-Forwardings konfigurieren sollte.
Ein virtueller Host pro Webanwendung (unterschiedliche Domains)
Wenn man nun keine vom Standard abweichenden Ports verwenden möchte, muss man ein anderes Kriterium nutzen, um eine saubere Trennung zu realisieren. Der zweite Lösungsansatz besteht nun darin, unterschiedliche Domains zu verwenden.
In unserem Beispiel könnte dies dann wie folgt aussehen. Es werden wieder nur die vHosts für HTTPS gezeigt:
server {
# Virtual host 1/web application 1:
# - Listens on port 443 (HTTPS) - IPv4 and IPv6.
# - Is capable of serving requests for domain "meinedomain1.de" and IP address 192.168.178.60 (local IP of server).
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name meinedomain1.de 192.168.178.60;
# IMPORTANT: You need a specific TLS certificate for meinedomain1.de
ssl_certificate /etc/letsencrypt/meinedomain1.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/meinedomain1.de/key.pem;
ssl_trusted_certificate /etc/letsencrypt/meinedomain1.de/ca.pem;
# Include headers and SSL specific stuff.
include /etc/nginx/snippets/ssl.conf;
include /etc/nginx/snippets/headers.conf;
root /var/www/webapplication1;
}
server {
# Virtual host 2/web application 2:
# - Listens on port 443 (HTTPS) - IPv4 and IPv6.
# - Is capable of serving requests for domain "meinedomain2.de".
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name meinedomain2.de;
# IMPORTANT: You need a specific TLS certificate for meinedomain2.de
ssl_certificate /etc/letsencrypt/meinedomain2.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/meinedomain2.de/key.pem;
ssl_trusted_certificate /etc/letsencrypt/meinedomain2.de/ca.pem;
# Include headers and SSL specific stuff.
include /etc/nginx/snippets/ssl.conf;
include /etc/nginx/snippets/headers.conf;
root /var/www/webapplication2;
}
Für beide Webanwendungen wird nun der gleiche Port (443) verwendet, jedoch unterschiedliche Domains: meinedomain1.de für Anwendung 1, meinedomain2.de für Anwendung 2. In den virtuellen Hosts wird dies über die Anweisung server_name angegeben (oben wieder markiert).
Eine Nebenwirkung hat dieses Konzept allerdings: Nur Webanwendung 1 ist nun noch über die lokale IP-Adresse des Servers erreichbar. Dies ist notwendig, da ja ansonsten wieder beide vHosts auf die gleiche IP-Adresse und den gleichen Port konfiguriert wären.
Im Browser kann man dann https://meinedomain1.de für Anwendung 1, https://meinedomain2.de für Anwendung 2 aufrufen.
Die Besonderheit dieser Lösung liegt nun in der Domain-Konfiguration: Beide Domains müssen auf die (Internet-)IP des Webservers auflösen. Bei statischen IP-Adressen kann dies einfach in der Verwaltung des Domain-Providers angegeben werden. Meistens gibt es hier einen Punkt zur DNS-Verwaltung von Domains. Hier müssen die sog. A-Records (für IPv4) und AAAA-Records (für IPv6) auf die entsprechenden IPs des Servers gesetzt werden.
Für diese Lösung werden übrigens nicht zwingend mehrere Second-Level-Domains (wie z.B. meinedomain1.de und meinedomain2.de) benötigt. Hier reicht auch eine Second-Level-Domain (meinedomain.de), zu der dann mehrere Sub-Domains erstellt werden (bielspielsweise app1.meinedomain.de und app2.meinedomain.de).
Im Heimbereich kommt darüber hinaus meist DnyDNS zum Einsatz. Hier wird die Konfiguration etwas umständlicher, da meistens nur eine einzige DynDNS-Domain im Router hinterlegt werden kann (z.B. bei einer FritzBox). Damit die zweite Domain nun ebenfalls „daheim am Router ankommt“, kann für die zweite Domain ein sog. CNAME-Record gesetzt werden (dies geschieht ebenfalls in der Domain-Verwaltung des Providers). Da sich das Vorgehen von Provider zu Provider unterscheidet, kann hierfür leider keine genaue Anleitung erfolgen. Der folgende Screenshot zeigt beispielhaft die Einrichtung eines CNAME-Records für eine Subdomain beim Provider All-Inkl (Affiliate-Link):
Vorteile
- Einfache Trennung der Webanwendungen auf Grund unterschiedlicher Domains.
- Keine zusätzlichen Port-Forwardings benötigt.
- Anleitungen/Tutorials zu bestimmten Webanwendungen unter nginx können meistens einfach 1:1 übernommen werden.
Nachteile
- Ggf. etwas kompliziertere Domain-Konfiguration erforderlich (v.a. bei der Verwendung von DynDNS).
- Es werden mehrere TLS-Zertifikate benötigt (eines pro Domain).
- Nur eine Webanwendung kann so konfiguriert werden, dass diese auf die lokale IP des Servers reagiert.
Webanwendungen in Unterverzeichnissen (mit Gateway-Host)
Wenn beide zuvor genannten Lösungen nicht umzusetzen sind, beispielsweise wenn nicht mehrere Domains zur Verfügung stehen und man keine zusätzlichen Ports freigeben möchte, kann man mehrere Webanwendungen auch in Unterverzeichnisses des Webservers hosten.
In diesem Fall wird die Webserver-Konfiguration etwas komplizierter, da man einen vorgeschalteten virtuellen Host („Gateway-Host“) benötigt, der alle Requests auf die Domain abfängt und diese anschließend an Hand des Verzeichnisses an weitere vHosts weiterleitet.
Eine solche Konfiguration könnte dabei wie folgt aussehen:
server {
# Gateway host handling all the requests.
# - Listens on port 443 (HTTPS) - IPv4 and IPv6.
# - Is capable of serving requests for domain "meinedomain.de" and IP address 192.168.178.60 (local IP of server).
# - Handles all SSL related stuff.
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name meinedomain.de 192.168.178.60;
ssl_certificate /etc/letsencrypt/meinedomain1.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/meinedomain1.de/key.pem;
ssl_trusted_certificate /etc/letsencrypt/meinedomain1.de/ca.pem;
# Include headers and SSL specific stuff.
include /etc/nginx/snippets/ssl.conf;
include /etc/nginx/snippets/headers.conf;
root /var/www/
# Disable access to the web root.
location = / {
deny all;
}
# Subdirectory for app 1 (https://meinedomain.de/app1)
location ^~ /app1 {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_pass http://127.0.0.1:81;
proxy_redirect off;
}
# Subdirectory for app 2 (https://meinedomain.de/app2)
location ^~ /app2 {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_pass http://127.0.0.1:82;
proxy_redirect off;
}
}
server {
# Virtual host for web application 1:
# - Only local (127.0.0.1), cannot be addressed directly (without gateway host).
# - Listens on port 81 (HTTP) - IPv4 and IPv6.
# - Is capable of serving requests for local IP address 127.0.0.1.
listen 81;
server_name 127.0.0.1;
location ^~ /app1 {
root /var/www/webapplication1;
}
}
server {
# Virtual host for web application 2:
# - Only local (127.0.0.1), cannot be addressed directly (without gateway host).
# - Listens on port 82 (HTTP - different port as for vHost serving web application 1) - IPv4 and IPv6.
# - Is capable of serving requests for local IP address 127.0.0.1.
listen 82;
server_name 127.0.0.1;
location ^~ /app2 {
root /var/www/webapplication2;
}
}
Der Gateway-Host nimmt hier alle Requests auf die Domain (oder lokale IP-Adresse des Servers) auf dem Standard-Port 443 (HTTPS) entgegen und ist für das SSL-Handling zuständig. Die Unterscheidung, welche Webanwendung nun gemeint ist, wird durch das Unterverzeichnis definiert (also https://meinedomain.de/app1 bzw. https://meinedomain.de/app2). Entsprechende Requests werden dann an die vHosts der jeweiligen Anwendung weitergeleitet (proxy_pass).
Die einzelnen Webanwendungen werden durch jeweils einen vitruellen Host abgebildet. Diese Hosts laufen rein lokal (127.0.0.1) auf unterschiedlichen Ports. Daher können diese vHosts nicht „von außen“ angesprochen werden, es muss immer erst der Gateway-Host passiert werden.
Vorteile
- Nur eine Domain notwendig.
- Es müssen keine zusätzlichen Port-Forwardings konfiguriert werden.
- Es wird lediglich ein TLS-Zertifikat für den Gatway-Host benötigt.
Nachteile
- Kompliziertere Konfiguration, da immer ein Routing vom Gateway-Host an die Anwendungs-vHosts implementiert werden muss.
- Anleitungen/Tutorials zu bestimmten Webanwendungen unter nginx können nicht einfach übernommen werden. Hier muss zunächst immer eine Lösung implementiert werden, die das Konzept des Gateway-Hosts berücksichtigt.
Empfehlung: Welche Lösung ist die beste?
Eine eindeutige Empfehlung kann an dieser Stelle nicht erfolgen, da dies auch immer von den individuellen Gegebenheiten/Bedürfnissen abhängt.
Dennoch ist meine bevorzugte Lösung die Trennung der einzelnen Webanwendungen durch unterschiedliche (Sub-)Domains. Auf diese Weise laufen alle Anwendungen auf den Standard-Ports 80 (HTTP) und 443 (HTTPS) und man spart sich einiges an Komplexität, die man mit einem Gateway-Host beachten müsste. Dadurch wird die gesamte Webserver-Konfiguration um einiges einfacher.
Überführung der Lösungen/Mischbetrieb
Abschließend noch der Hinweis, dass eine einmal umgesetzte Lösung nicht in Stein gemeißelt ist. Es ist jederzeit möglich, eineLösung in eine andere zu überführen. Normalerweise geschieht das dann einzig und allein über die Webserver-Konfiguration (vHosts) – die Konfiguration der Webanwendung muss meistens gar nicht geändert werden.
Die im Artikel gezeigten Beispiele für die einzelnen virtuellen Hosts von nginx können bei der Überführung der Lösungen hilfreich sein. Falls nach einer Änderung der Konfiguration die Webanwendung nicht mehr funktioniert, sollte auf jeden Fall ein Blick in das nginx Error-Log (/var/log/nginx/error.log) helfen. Meistens ist das Problem dann auf eine falsche Verzeichnisstruktur zurück zu führen – entweder die lokale Verzeichnisstruktur, oder aber die Struktur, die in den virtuellen Hosts konfiguriert wurde.
Man muss sich darüber hinaus auch nicht auf eine Lösung festlegen: Es ist genau so möglich, mehrere Lösungen parallel auf einem Server zu betreiben. So wäre es beispielsweise denkbar, dass zwei Webanwendungen unter den Domains meinedomain1.de/app1 und meinedomain1.de/app2 verfügbar sind und eine dritte Anwendung über meinedomain3.de erreichbar ist.
Fazit
Der Artikel hat drei Lösungsansätze aufgezeigt, wie unter nginx mehrere Webanwendungen parallel gehostet werden können und welche Vor- bzw. Nachteile die einzelnen Lösungen bieten. Wie immer gibt es hier nicht die eine richtige Lösung, da dies immer von den jeweiligen Anforderungen abhängt.
Welchen Ansatz bevorzugt ihr? Hinterlasst mir dazu doch einfach einen Kommentar.
Weiterführende Artikel
- Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
- Let’s Encrypt Zertifikate mit acme.sh und nginx
- RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung)
- TLSv1.3 unter Ubuntu Server 18.04 LTS mit nginx
- Eigener Firefox Sync Server mit nginx
- Nextcloud: Online-Office mit ONLYOFFICE (mit eigener Subdomain)
Hallo,
danke für die ausführliche Beschreibung.
Wenn ich nginx als „Webanwendungen in Unterverzeichnissen (mit Gateway-Host)“ laufen habe und nginx noch zusätzlich als reverse proxy einsetzen möchte, ist da speziell was zu beachten?
Bekomme es nicht hin.
https://meinedomain.de/bitwarden mag nicht
lasse ich bitwarden auf der Domain laufen,
https://meinedomain.de
funktioniert(reverse Proxy) es.
Danke und Grüße.
Hi,
hier kommt es natürlich immer auch auf die Webanwendung selbst an und was diese für Voraussetzungen bzgl. Konfiguration mitbringt.
Pauschal kann man das also leider nicht beantworten.
Was spezielles zu beachten gibt es meiner Meinung nach aber nicht.
Gruß,
Jan
Hallo und vielen Dank für deine hilfreichen und immer auch lehrreichen Anleitungen! Bezüglicher einer parallelen Installation von Nextcloud und Jitisi – welche der genannten Varianten würdest du empfehlen? Gibt es bei Jitsi neben Nextcloud etwas besonderes zu beachten?
Danke und viele Grüße!
Chris
Hi,
gerade für Jitsi würde ich die Nutzung mehrerer getrennten Domains/vHosts empfehlen. Generell ist die Trennung hier am einfachsten.
Gruß,
Jan
Dank deiner Anleitung ist es mir gelungen Nextcloud, Jitsi und WordPress elegant nebeneinander zu installieren. Vielen Dank!
Und wie ist Ihnen das gelungen? Kann ich da einen Tipp zu bekommen?
Eine Verständnisfrage: Wenn ich 3 parallele apps installieren möchte
nextcloud.meinedomain.de
jitsi.meinedomain.de
wordpress.meinedomain.de
muss ich dann für jede Subdomain die LetsEncrypt Zertifikate erstellen oder gibt es die Möglichkeit, das nur für die Hauptdomain „meinedomain.de“ zu tun und die Subdomains greifen darauf zurück ?
Oder hat es Vorteile für jede Subdomain eigene Zertifikate zu haben?
In Deinem Tutorial hat z.B. die subdomain nextcloud ein eigenes cert bekommen ..
https://decatec.de/home-server/nextcloud-auf-ubuntu-server-20-04-lts-mit-nginx-mariadb-php-lets-encrypt-redis-und-fail2ban/#Generierung_der_Zertifikate_fuer_HTTPS
Hi Robert,
ich trenne das immer gern auf: 1 Zertifikat für eine Anwendung/Domain. Das macht die Sache meiner Meinung nach übersichtlicher und man kann eben mal ein Zertifikat löschen, wenn nicht mehr benötigt.
Du kannst allerdings auch ein Zertifikat erstellen, welches für mehrere Webseiten/Domains gültig ist. Dazu übergibst du einfach mehrere Domains mittels des Parameters „-d“ an acme.sh, z.B. „acme.sh –issue -d nextcloud.meinedomain.de -d jitsi.meinedomain.de –keylength 4096 …“.
Das gleiche natürlich analog für die ECDSA-Zertifikate (falls benötigt/gewünscht).
Gruß,
Jan
Hallo Jan,
ich habe nach Deiner Anleitung eine sehr gut funktionierende NC installation. Mittlerweile auf Ubuntu 20.04. Meine Installation beruht noch auf der Konfiguration mit Subdirs https://meinedomain.de/nextcloud. Meine Frage ist: Ist es möglich den Aufruf auf https://meinedomain.de selbst zu schützen/ unsichtbar zu machen, sodass nichts kommt? Aktuell kommt bei mir ein „403 Forbidden“ und der Hinweis auf nginx als Server.
Wäre es aus Sicherheitsgründen nicht günstig diese Abfrage abweisen zu können?
Vielen Dank für ein kurzes Feedback
Thomas
Hi Thomas,
du kannst den Aufruf der Root-Domain nicht ganz unterbinden, da der Webserver ja hier automatisch den Request annimmt. Daher ist es meiner Minung nach das besten, dass einfach ein „Forbiidden“ kommt. Alternativ könntest du hier natürlich auch einfach eine weiße statische HTML-Seite ausliefern lassen. Welcher Webserver hier verwendet wird, bekommt ein Client aber auch über die Resopnse-Header raus, daher ist dies kein Sicherheits-Feature.
Gruß,
Jan
Hi,
schöne Anleitung. Danke dafür. Ich habe bei mir mal versucht die Variante 3 umzusetzen. Allerdings laufe ich noch in ein Problem.
Der Gatewayserverblock sieht so aus und scheint auch zu funktionieren. Ich komme auf die index.html im webroot:
server {
listen 80;
listen [::]:80;
server_name omvnas 192.168.178.12;
error_log /var/log/nginx/gateway_error.log;
access_log /var/log/nginx/gateway_access.log;
root /own_sites/;
# webroot, can be denied as well
location = / {
index index.html;
}
# Subdirectory for gcc2 productive
location ^~ /gcc2 {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_pass http://127.0.0.1:81;
proxy_redirect off;
}
}
Die Weiterleitung zur zweiten Location“gcc2″ auf dem virtuellen lokalen Host klappt auch soweit. Allerdings sucht dieser mir dann die dort gelagerte Webseite nicht an der richtigen Stelle und der virtuelle Host wirft mir dann einen Fehler. Der Server block für den virtuellem lokalen Host sieht so aus:
server {
listen 81;
server_name 127.0.0.1;
error_log /var/log/nginx/gcc2_prod_error.log;
access_log /var/log/nginx/gcc2_prod_access.log;
location ^~ /gcc2 {
root /own_sites/gcc2_prod;
index index.php;
}
….
}
Da steht noch php Geraffel drin, was ich hier erstmal rausgenommen habe, da es nichts zur Sache tun haben sollte. Der virtuelle Host sucht nun die Webseite nicht wie im root angegeben unter „/own_sites/gcc2_prod“ sondern unter „/own_sites/gcc2_prod/gcc2“, hängt also den location part nochmal an den root dran.
Soll das so sein, oder kann man das noch unterbinden? Ich hätte schon gerne, dass er dort sucht wie in root angegeben und würde ungern die seite noch eine ebene tiefer unter „gcc2 schieben wollen
Hi,
ist im „hinteren“ vHost die location hier korrekt (
location ^~ /gcc2 {)? Könnte das nicht einfachlocation ^~ / {heißen?Was passiert, wenn du hier die root-Direktive außerhalb des location-Blocks aufführst?
Gruß,
Jan
Vielen Dank für die guten Anleitungen auf deiner Seite. Ich habe hier schon viel gelernt.
Im Moment komme ich leider nicht weiter. Ich habe Nextcloud 20 laufen, aber noch so mit nginx konfiguriert, wie in deiner Anleitung für Version 18.
Nun versuche ich Pi-hole über nginx zum Laufen zu bringen. Ich komme leider nicht auf die Weboberfläche. Alles andere läuft bei Pi-hole.
Ich habe versucht eine Portweiterleitung auf das Piholeverzeichnis html zu machen. Das sieht so aus:
# Beginn Proxy für Pihole auf Port 83
location ^~ /pihole {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_pass http://127.0.0.1:83;
proxy_redirect off;
}
Die Pihole Konfiguration sieht so aus:
server {
# Virtual host for web application nextcloud:
# – Only local (127.0.0.1), cannot be addressed directly (without ga>
# – Listens on port 83 (HTTP) – IPv4 and IPv6.
# – Is capable of serving requests for local IP address 127.0.0.1.
listen 127.0.0.1:83;
server_name 127.0.0.1;
root /var/www/;
# location = /robots.txt {
# allow all;
# log_not_found off;
# access_log off;
# }
location ^~ /pihole{
autoindex off;
index pihole/index.php index.php index.html index.htm;
location /pihole {
expires max;
try_files $uri $uri/ =404;
}
location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
fastcgi_param FQDN true;
auth_basic „Restricted“; # For Basic Auth
auth_basic_user_file /etc/nginx/.htpasswd; # For Basic Auth
}
location /pihole/*.js {
index pihole/index.js;
auth_basic „Restricted“; # For Basic Auth
auth_basic_user_file /etc/nginx/.htpasswd; # For Basic Auth
}
location /pihole/admin {
root /var/www/html;
index index.php index.html index.htm;
auth_basic „Restricted“; # For Basic Auth
auth_basic_user_file /etc/nginx/.htpasswd; # For Basic Auth
}
location ~ /\.ht {
deny all;
}
}
}
Nach meinem Verständnis müsste doch jetzt unter http://www.meinedomain.de/pihole was passieren. Leider bekomme ich nur die Seite 404. Wo liegt da mein Fehler?
Hi Andreas,
zunächst einmal empfehle ich Pi-hole nicht neben einer anderen Webanwendung zu installieren. Meine Versuche dahingehend waren nicht gerade erfolgreich. Wenn irgendwie möglich, nimm am besten einen Raspi, oder eine VM. Das ist meist weniger stressig.
Wenn es denn unbedingt auf der gleichen Maschine sein muss, dann schau mal hier vorbei. Ziemlich weit unten hat mir jemand mal eine Anleitung für Pi-hole zukommen lassen. Der Artikel ist zwar schon recht alt, sollte im großen und ganzen aber noch Gültigkeit haben.
Zu deinem 404-Fehler: Schau hier mal in das Webserver-Log. Er sollte dir hier eigentlich sagen, welche Datei(en) er wo sucht (und nicht findet). Das könnte schon ein erster Anhaltspunkt sein.
Gruß,
Jan
Hallo vielen Dank für die super Anleitungen.
Ich habe die Variante 3 am laufen mit 2 Webservern die beiden unter der jeweiligen Subdomain energie.xxx.de und nextcloud.xxx.de erreichbar sind.
Problem ist das ich aber keine Dateien in die Cloud uploaden kann.
Einstellungen in der Nextcloud werden aber gespeichert.
Meine reverse.proxy.conf sieht so aus:
upstream php-handler {
server unix:/run/php/php7.4-fpm.sock;
}
server {
server_name energie.xxx.de;
location / {
proxy_pass http://192.168.1.6:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
client_max_body_size 1024;
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/energie.xxx.de/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/energie.xxx.de/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
server_name nextcloud.xxx.de;
location / {
proxy_pass http://192.168.1.8;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
proxy_redirect off;
proxy_buffering off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
add_header Cache-Control „public, max-age=15778463“;
add_header Strict-Transport-Security „max-age=15768000; includeSubDomains; preload;“ always;
add_header Referrer-Policy „no-referrer“ always;
add_header X-Content-Type-Options „nosniff“ always;
add_header X-Download-Options „noopen“ always;
add_header X-Frame-Options „SAMEORIGIN“ always;
add_header X-Permitted-Cross-Domain-Policies „none“ always;
add_header X-Robots-Tag „none“ always;
add_header X-XSS-Protection „1; mode=block“ always;
access_log off;
}
location = /.well-known/carddav {
return 301 $scheme://$host:$server_port/remote.php/dav;
}
location = /.well-known/caldav {
return 301 $scheme://$host:$server_port/remote.php/dav;
}
client_max_body_size 1024;
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/energie.xxx.de/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/energie.xxx.de/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = energie.xxx.de) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name energie.xxx.de;
listen 80;
return 404; # managed by Certbot
}
server {
if ($host = nextcloud.xxx.de) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name nextcloud.xxx.de;
listen 80;
return 404; # managed by Certbot
}
Muss ich den Fehler hier im Reverse-Proxy suchen oder in der Nextcloud installation?
Gruß
Ralf
Hi Ralf,
was passiert denn, wenn du eine Datei hochladen willst? Ohne Fehlermeldung o.ä. wird es hier denke ich schwierig, den Fehler zu finden.
Funktioniert der Upload, wenn du über die (LAN-)IP auf die Nextcloud zugreifst?
Gruß,
Jan
Hallo Jan,
eventuell passt die Frage hier nicht direkt dazu… ich stelle sie trotzdem mal.
Hast du eine Idee, woran es liegen kann, wenn webp-Dateien nicht mit http2-Protokoll ausgeliefert werden?
Der NGINX-Server ist soweit ich sehe korrekt eingerichtet.
Danke & Grüße
Frank
Hi Frank,
was heißt „nicht ausgeliefert“? webp ist ja ein „progressive Image“ Format, daher sollte dies gerade von HTTP/2 profitieren. Kommen dazu irgendwelche Logs (Server- als auch Client-seitig)?
Gruß,
Jan
Trotz http2 Konfiguration, liefert unsere WordPress Site alle Dateien in HTTP/1.1 aus – statt HTTP/2.
Betrifft Js, css und Bilddateien.
Egal was ich mache, Google PageSpeed Insight Test zeigt immer: „HTTP/2 verwenden“. Und listet entsprechend alle Dateien, die mit HTTP/1.1 kommen auf.
Ich habe HSTS with preload und HTTP/2 in NGINX aktiv und das vhost entsprechend konfiguriert. Zum Testen hatte ich auch cache und scriptminimizer ausgeschaltet, aber ohne Wirkung. Verstehe nicht, weshalb WordPress bzw. NGINX in HTTP/1.1 ausliefert?!
Wenn man die Seite (bzw. Server) auf HTTP2 Protokoll testet, wird es positiv bestätigt, inkl. ALPN. Der Header der Seite gibt korrekt HTTP/2 200 wieder. Ich habe grad keine Idee, was ich ändern oder prüfen muss.
Hast du eine Idee, wie ich das lösen kann?
Danke schonmal und Gruß
Frank
Hi Frank,
spontan fällt mir hier erst einmal nichts dazu ein. Aktivieren von HTTP/2 durch nginx sollte da eigentlich ausreichen.
Was passiert, wenn du hier mal z.B. eine Test-HTML-Seite erstellst (außerhalb von WordPress) und diese dann abrufst? Kommt diese dann mittels HTTP/2? Dann wüsste man zumindest einmal, dass dies ein WP-Problem ist.
Vielleicht spielt ja auch ein Plugin „verrückt“ – ich habe da schon so viele Probleme beobachten können, weil sich verschiedene Plugins in die Quere gekommen sind. Aber das ist ja die typische WordPress-Krankheit.
Gruß,
Jan
Hi Jan, danke für den Tipp, es mit einer neutralen HTML-Seite zu versuchen. Damit war – wie zu erwarten – alles GRÜN. Und alle Tests betreffend NGINX-Server zeigen mir dasselbe Ergebnis mit WP-Seiten. Warum Google dies anders auswertet?!
Denn egal was ich mache, Google PageSpeed Insight Test zeigt nach wie vor: „HTTP/2 verwenden“. Und listet entsprechend alle Dateien, die mit HTTP/1.1 kommen auf.
Ich bleib dran! Und werde berichten falls ich irgendwann dahinter komme, was das Problem dafür ist. Ist mir ein Rätsel. Danke für deinen Support hier!
Gruß Frank
Hallo,
Ich habe versucht mit ein vhost pro webanwendung roundcube aufzusetzen.
Leider bekomme ich nachdem ich roundcube heruntergeladen habe den installiert nicht geöffnet.
Muss ich im ngninx vhost mehr als nur das root Verzeichnis mit angeben?
Ich würde auf dem Server nur eine webanwendung laufen lassen wollen…
Ich habe den Fehler nicht gefunden und vielleicht weosst du ob es an den Rechten oder an der Konfiguration im vhost lag?
LG
Sam
Hi Sam,
ja, da sind durchaus noch weitere Anweisungen notwendig. Dies hängt leider immer sehr von der speziellen Anwendung ab, daher gibt es hier kein Patentrezept.
Für Roundcube sieht aber dies hier ganz gut aus.
Gruß,
Jan
Guten Tag, ich habe schon seid längerer zeit nach do einem artikel gesucht, deswegen erstmal danke. Num habe ich nach deiner anleitung NC aufgesetzt, würde jetzt aber gerne eine suchmaschine auf einer anderen domain hosten und in einem anderen LXC unter proxmox. Was muss denn konkret für die methode im NC container ändern und wie richte ich das dann bei der suchmaschine ein?
Hi Stefan,
mittlerweile präferiere ich die Umsetzung mit einem virtuellen Host pro Anwendung und die Aufteilung über unterschiedliche (Sub-)Domains.
Da du ja nur einmal Port 80 und 443 freigeben kannst, muss daher die SSL-Termination auch für die zweite Webanwendung auf der NC-Maschine erfolgen. Der entsprechende vHost (HTTPS) führt dann einfach einen proxy_pass auf den zweiten LXC-Container aus. Ggf. kann auf der zweiten Maschine dann ein selbst signiertes Zertifikat zum Einsatz kommen, ansonsten läuft diese Verbindung dann (LAN-intern) unverschlüsselt ab.
Gruß,
Jan
Hi Jan,
OK das habe ich soweit verstanden und ich halte diese Lösung ebenfalls für die Beste. Wenn ich NC wie im Artikel konfiguriert habe, muss ich dann daran noch etwas verändern oder reicht es in einem anderen LXC die oben genannte nginx config zu konfigurieren und kann dann nach deinen weiteren Anleitungen verfahren werden?
Vielen Dank und viele Grüße Stefan
Hi Stefan,
die NC-Config inkl. vHosts sollte soweit passen, lediglich das (Let’s Encrypt) Zertifikat wirst du auf dieser Maschine nicht mehr erneuern können – daher empfiehlt sich hier der Einsatz selbst signierter Zertifikate. Der vHost der „Proxy-Maschine“ muss dann für die NC-Domain einfach alles an die NC-Maschine weiter leiten. Evtl. muss man noch ein wenig an den Headern rumschrauben, so dass diese nicht doppelt gesetzt werden (das sollte dann an der Proxy-Maschine gemacht werden).
Gruß,
Jan
kleiner Tippfehler:
Die im Artikel gezeigten Beispiele für die einzelnen virtuellen Hosts von nginx können bei der Überführung der Lösungen hilfreich sein. Falls nach einer Änderung der Konfiguration die Webanwendung nicht mehr funktioniert, sollte auf jeden Fall ein Blick in das nginx Error-Log (/var/log/nginx/error.log) helfen. Meistens ist das Problem dann auf eine falsche Verzeichnisstruktur zurück zu führen – entweder die LOAKLE Verzeichnisstruktur, oder aber die STUKTUR, die in den virtuellen Hosts konfiguriert wurde.
Hi,
danke für den Hinweis, ist korrigiert.
Gruß,
Jan
Hi Jan, tolle Zusammenfassung, Danke dafür!
eine grundsätzliche Frage dazu:
Wie lassen sich die zwei grundsätzlichen Ansätze zur Auslieferungen verschiedener Services auf einem Server vergleichen?
1. Möglichkeit: nativ verschiedene Web-Anwendungen parallel installieren und per nginx zu separieren
2. Möglichkeit: die Webanwendungen virtualisieren und in Container ausführen.
Ich bin kein Fan von Docker und Co., da ich mehr RAM benötige und das Setup, obwohl es einfacher „aussieht“ im Unterbau komplexer ist. Und am Ende müssen die Rechenoperationen auf der verfügbaren Hardware verteilt werden, da macht es kein Unterschied ob aus VM oder nativer Installation?
Meiner Meinung nach lohnt es sich bei nur 2-3 Anwendung, diese nativ zu installieren und per nginx zu servieren. Vor allem wenn diese z.B. das selbe Datenbanksystem nutzen.
Stimmen meine Annahmen, oder ist es gar nicht so einfach das stärkere Konzept zu definieren?
Grüße Oli
Hi Oli,
Docker lohnt meiner Ansicht nach nur in vier Szenarien:
Für alle anderen Dinge mache ich aus den von dir genannten Gründen auch einen Bogen um Docker. V.a. muss man sich eh mit den nginx vHosts bzw. der SSL-Terminierung auf dem Docker-Host beschäftigen, da die meisten Container out of the box nur mit HTTP ansprechbar sind.
Letzten Endes ist es aber Geschmacksache bzw. hängt von deinen konkreten Anforderungen ab.
Gruß,
Jan
Hi Jan,
als Rückmeldung: Dein Beitrag hat meinem Verständnis von der (Docker)/nginx-Config ein Stückchen mehr auf die Sprünge geholfen. Dank Dir für Deine Zeit, die Dinge so ausführlich zu notieren und uns teilhaben zu lassen!
Gruß!
Thomas
Guten Morgen Jan,
ich habe gestern mal angefangen meinen Nextcloudserver neu aufzusetzen und habe mir gedacht wenn du schon dabei bist versuchst du den Webserver auch für mehrere Webseiten zu Konfigurieren. Habe mich für Methode 2 endschieden ist denke ich das beste für mich.
Grundsätzlich läuft das System wenn wie unten der erste Server auskommentiert ist läuft der Andere mit Zertifikat so wie er soll. Sobald ich aber den 2 Server mit dabei habe ist kein Webroot cloud. oder test. erreichbar. Noch zur Info cloud. hat noch kein Zertifikat die Adresse ist noch auf einem anderen Server Aktiv das sollte aber denke kein Problem sein.
Kann doch eigentlich nur eine Kleinigkeit sein hoffe ich, in der httpgateway.conf habe ich unter Server_name beide Adressen und die IP eingetragen. Das läuft auch und stellt auf Https um.
Gruß
Markus
# Set the `immutable` cache control options only for assets with a cache busting `v` argument
map $arg_v $asset_immutable {
„“ „“;
default „immutable“;
}
#server {
# listen 443 ssl http2;
# listen [::]:443 ssl http2;
# server_name cloud.efh.xxxx.net 192.168.125.96;
#
# # Path to the root of your installation
# root /var/www/nextcloud;
#
# # SSL configuration
# # RSA certificates
# ssl_certificate /etc/letsencrypt/cloud.efh.xxxx.net/rsa/fullchain.pem;
# ssl_certificate_key /etc/letsencrypt/cloud.efh.xxxx.net.de/rsa/key.pem;
# # ECC certificates
# ssl_certificate /etc/letsencrypt/cloud.efh.xxxx.net/ecc/fullchain.pem;
# ssl_certificate_key /etc/letsencrypt/cloud.efh.xxxx.net/ecc/key.pem;
#
# # This should be ca.pem (certificate with the additional intermediate certificate)
# # See here: https://certbot.eff.org/docs/using.html
# # ECC
# ssl_trusted_certificate /etc/letsencrypt/cloud.efh.xxxx.net/ecc/ca.pem;
#
# # Include SSL configuration
# include /etc/nginx/snippets/ssl.conf;
#
# # Include headers
# include /etc/nginx/snippets/headers.conf;
#}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name test.efh.xxxx.net 192.168.125.96;
# Path to the root of your installation
root /var/www/test;
# SSL configuration
# RSA certificates
ssl_certificate /etc/letsencrypt/test.efh.xxxx.net/rsa/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/test.efh.xxxx.net/rsa/key.pem;
# ECC certificates
ssl_certificate /etc/letsencrypt/test.efh.xxxx.net/ecc/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/test.efh.xxxx.net/ecc/key.pem;
# This should be ca.pem (certificate with the additional intermediate certific>
# See here: https://certbot.eff.org/docs/using.html
# ECC
ssl_trusted_certificate /etc/letsencrypt/test.efh.xxxx.net/ecc/ca.pem;
# Include SSL configuration
include /etc/nginx/snippets/ssl.conf;
# Include headers
include /etc/nginx/snippets/headers.conf;
// …
}
Hi Markus,
ich sehe hier nur ein Problem: Beim server_name ist beides Mal die lokale IP angegeben. Das darf denke ich nur bei einem Server so sein, ansonsten kann die Trennung hier nicht ordentlich durchgeführt werden. Eigentlich ist die IP-Adresse im server_name auch gar nicht notwendig, da du ja eh immer über die „richtigen“ Domains kommst.
Gruß,
Jan
Hi Jan,
super jetzt geht es ich hatte den 2 Server mit ner Klammer geschlossen da hatte er Probleme mit den location angaben. Die IP hatte ich nur unten mal zum testen dabei gemacht. Na dann will ich mal weitermachen mal schauen ob ich ohne Probleme den Rest hinbekommen, schönes Wochenenden.
Gruß
Markus
Hi Jan,
angenommen ich habe einen vServer und möchte Variante 2 (unterschiedliche Subdomains) nutzen:
Pack ich dann die vhost-Datei pro Subdaomain unter „/etc/nginx/sites-available/“und setzten dann einen Link zu „/etc/nginx/sites-enabled“?
Also z.B. /etc/nginx/sites-available/service_eins
„`
server {
listen: …
certifcate: …
location: …
}
„`
usw.
Hi Jim,
kommt darauf an, ob du nginx aus den Ubuntu-Paketquellen installierst, oder – wie in diesem Blog immer empfohlen – aus den nginx-Paketquellen. Bei der ersten Variante liegst du vollkommen richtig. Bei der zweiten Variante nutzt nginx nicht sites-available/sites-enabled, sondern /etc/nginx/conf.d. Wenn conf.d genutzt wird, dann daran denken, dass die vHost mit .conf enden müssen, damit diese beim Start von nginx angezogen werden.
Gruß,
Jan
ach, jetzt verstehe ich:
– alle vhosts in „/etc/nginx/conf.d/*.conf“
– alle TLS-Erweiterungen in „/etc/nginx/snippets/“
– und falls Variante 3 (Gatewayhost) genutzt wird, kommt dieser zusätzlich auch in „/etc/nginx/conf.d/“
Dank deines Artikel konnte ich im lokalen Heimnetz einen Raspi mit verschiedenen Services aufzusetzen. Nach Variante 2 mit Subdomains. Aufgelöst werden die Subdomains von meinem Pihole mit lokalen DNS-Records (also z.B. „music.raspi.fritz.box“ oder matrix.raspi.fritz.box jeweils auf 192.168.178.11)
„Containern“ konnte ich damit vermeiden. Und ich glaube dadurch, dass ich für alle Services das gleiche Datenbanksystem (PostgreSQL) verwende, relativ effizient die Ressourcen des Rapsis nutze.
Danke für deine tollen Beiträge zum Selbserhosten!!
Grüße Jim
Hi Jim,
ja, genau so kann so etwas umgesetzt werden.
Well done!
Gruß,
Jan
Nginx nimmt als Reverse Proxy auf dem Host verschlüsselte Anfragen an.
Danach werden diese dann aber unverschlüsselt an die Services, also z.B. http://localhost:4774, usw. weitergeleitet.
Wenn ich eine Firewall auf dem Host nutze und nur Port 80 und 443 freigebe, kann ein „bösartiger“ Webservice keine Ports nach außen öffnen. Soweit so gut.
Aber er könnte doch auf den Ports der anderen Webservices lauschen?
Lassen sich die einzelnen Webservices/Container noch zusätzlich absichern? (E2E?)
Freu mich über Rückmeldung!
Grüße Jim
Hi Jim,
Ports können im Normalfall nicht doppelt „belegt“ werden. Auf der anderen Seite: Wenn der Server kompromittiert ist, dann ist eh „Hopfen und Malz verloren“. In diesem Fall ist davon auszugehen, dass gar nichts mehr „sicher“ ist.
E2E ist außerhalb des Scopes für den Webserver, dies muss von der Anwendung selbst (bzw. den Clients kommen).
Gruß,
Jan
Hallo,
ich habe das versucht aber funktioniert bei mir nicht.
meine Webseite lauft auf port 5432 weil port 80 für apache2 oder andere reserviert ist .
Ich mochte eine vHost erstellen =
damit ich die Webseite mit meine domain.de erreiche
und nicht immer im Browser den Port angeben muss .
also domani.de eingeben und auf domain.de:5432 … landen
Wie muss meine vHost aussehen ?
Danke
Hi Sara,
wenn nicht die Standard-Ports 80/443 genutzt werden, ist die Port-Angabe im Browser leider zwingend erforderlich. Die Lösung wäre hier, alles nur auf Port 80/443 laufen zu lassen. Vor den Apache kann man da z.B. einen nginx als Reverse Proxy setzen, der erst einmal alle Requests entgegen nimmt und dann entsprechend (z.B. an Apache) weiterleitet.
Gruß,
Jan