Reverse Proxy Empfehlung der Community

Liebe QNAP-Gemeinde,

nach längerem Forschen habe ich mich nun doch entschlossen, einen Hilferuf im Forum abzusetzen.

Ich bin auf der Suche nach einer sinnvollen Struktur, um meine unterschiedlichen Web-Services, die auf unterschiedlichen Servern im lokalen Netz laufen, über die Ports 80 bzw. 443 verschlüsselt nach außen zugänglich zu machen. Eigentlich dachte ich, spätestens seit den Virtualisierungsmöglichkeiten der QNAP und da viele User in ihrer Firma ausschließlich über die Ports 80 und 443 arbeiten können, wäre dies ein häufig anzutreffendes Problem. Im Forum findet sich aber keine einheitliche Vorgehensweise.

Bislang hatte ich eine ältere TS-119 PII, auf der ein Zarafa-Server lief, der im Web-Server der QNAP als Unterordner verfügbar war. Jetzt bin ich stolzer Besitzer einer TS253A (QTS 4.3.3) und habe hier eine Univention-VM mit Kopano laufen, die beeindruckend performant ist (ich nutze sie nur im Familienkreis -> 4 User).

Dadurch ergeben sich zwei unterschiedliche IPs und unterschiedliche Ports, um die Services von Kopano und QNAP zu nutzen. Die QNAP hängt direkt an einer FritzBox, auf der zwar Ports geroutet werden können, die aber keine subdomain- oder ordnerabhängige Portweiterleitung unterstützt.

Wenn ich es recht verstanden habe, ist ergo ein Proxy als Reverse Proxy nötig was auch aus Sicherheitsgründen schlau wäre. Nun habe ich drei Varianten angetestet, bin aber mit meinem gefährlichen Halbwissen bislang nicht weiter gekommen, weshalb ich die Gemeinde um Rat fragen wollte, welche Konfiguration generell erfahrungsgemäß einfach zu verwalten und sinnvoll ist.

Meine bisherigen Versuche und Erfahrungen:
- Apache des QNAP als Reverse Proxy einrichten
Leider ist es gar nicht so einfach, manuelle Konfigurationen vorzunehmen. Eine Lösung, die ich im Forum gefunden habe, erstellt erst einen vhost, weil dessen Konfigurationen nicht automatisch zurückgesetzt werden, und versucht dann diesen vhost als Reverse Proxy zu betreiben. Hat - offen gestanden - bei mir nicht funktioniert. Ich habe die Umleitung per Subdomain und per Subfolder ausprobiert, wobei ich die Subdomain bei Strato auf dieselbe dynamische IP weitergeleitet habe, wie die Ausgangs-Domain.

- QNAP Proxy Server:
Zum Caching und als Schutzmechanismus leicht zu verwalten und sicherlich sinnvoll, Reverse_Proxy aber nur per manueller Konfiguration möglich, wobei ich den Eindruck hatte, dass hier die Vorkonfiguration, die für die QNAP nötig ist, mit den Reverse_Proxy-Einstellungen kollidieren. Zumindest schien es mir sinnvoller eine separate Lösung zu fahren, die real/virtuell zwischen der FritzBox und der QNAP hängt.

- SQUID auf dem Univention-Kopano-Server als APP nachinstalliert
Auch hier wäre eine manuelle Konfiguration nötig, bei der ich den Eindruck hatte, dass ähnliche Kollateral-Effekte, wie bei der Installation des QNAP-Proxy-Servers auftreten. Wiederum erschien mir eine separat Lösung zweckmäßiger.

- Traefik in einem Docker-Container
Hier hänge ich gerade. Habe es nicht soweit gebracht, als dass ich das Web-Interface zu Gesicht bekommen hätte. Es könnte daran liegen, dass hierzu erst die virtuellen/realen Netzwerkschnittstellen so geschaltet werden, dass Traefik nicht mit anderen, auf Port 80 laufenden Services, kollidiert. Da bin ich aber noch nicht weiter gekommen.

Ihr seht - viele Versuche, wenig Erfolge. Deshalb bitte ich Euch um einen Tipp, der näheres Einarbeiten lohnt

Vielleicht noch ein paar Worte zu meinem Szenario:
- ich möchte folgende Dienste/Sevices möglichst verschlüsselt auf Port 443 extern nutzen
* QNAP-Webdav (intern IP 1, QNAP-https-Webserverport)
* QNAP-Webserver (intern IP1, QNAP-https-Webserverport)
* Kopano Webapp (intern IP2, Kopano-https-Webserverport)
* Kopano ActiveSync (intern IP2, Kopano-https-Webserverport)
* QNAP-FileStation (intern IP1, QNAP-System-Webserverport)
* QNAP-PhotoStation (intern IP1, QNAP-System-Webserverport)

Ich hänge an einer 50/10Mbit-Leitung mit einer FritzBox 7560, habe die Domain bei Strato und verbinde sie per dyndns zur FritzBox. Auch der MX-Record ist gesetzt und Kopano/postfix läuft als eigenständiger Mailserver und versendet und empfängt wunderbar Mails. Hier möchte ich zukünftig noch das Spam-Management optimieren, aber das ist OffTopic. Von außen kann ich nur die Ports 80 und 443 verwenden. Mein derzeitiger Trick ist, die FritzBox den QNAP-https-Webserverport auf Port 80 zu routen und die Kopano-https-Services auf Port 443, weshalb keine Homepage und auch keine QNAP-eigenen Services verfügbar sind. Nicht schick, aber im Moment ausreichend.

Ich würde mich über alle Tipps freuen.

Herzliche Grüße,

Marco

Hallo,

die QNAP ist so potent.

Virtualisierung, Linux nativ - wenn man will, Container, zwei Netzwerkanschlüsse, das müsste sich doch ohne extra Gerät auf der QNAP bewerkstelligen lassen - oder?

Liebe Grüße,

Marco

Herzlichen Dank!

So gehe ich das mal an und berichte dann.

Ich werd's auch mal mit ner VM mit Ubuntu-Server versuchen, zumal man dann später vielleicht noch einen DNS für das lokale Netz draufpacken könnte. Die Container sind zwar schlanker, aber etwas komplizierter zu modifizieren.

Wie viel Speicher hast du der VM zugewiesen?

Liebe QNAPler,

inzwischen habe ich NGINX wunderbar installiert und im lokalen Netz auch die Proxyweiterleitung per Eintrag in den Config-Dateien wunderbar umgesetzt.

Das heißt, wenn ich in /etc/hosts/ die entsprechenden Einträge vornehme werde ich per subdomain z.B. qnap.ubuntuserver von NGINX weitergeleitet an die Anmeldeseite des QNAP. Unter etc/hosts ist dabei der ubuntuserver auf die IP des NGINX gesetzt und qnap.ubuntuserver ebenso, damit die Anfrage auch tatsächlich über den NGINX per Proxyweiterleitung läuft.

So weit - so gut.

Jetzt habe ich selbiges von außen probiert. Dazu habe ich bei strato eine subdomain eingerichtet und die auch per proxy auf die selbe IP geleitet, auf der sich die FritzBox befindet, die die Ports an den NGINX weiterleitet.

Komischerweise erreiche ich so zwar zuverlässig NGINX, aber die Subdomains werden dann nicht mehr intern weitergeleitet.

Könnte mir jemand einen Tipp geben, wo mein Denkfehler ist? Bei Strato habe ich die Weiterleitung von der Subdomain auf die Domain
eingerichtet (die per Dyndns auf die FritzBox zeigt), in der Adresszeile des Browsers steht die Subdomain weiterhin drin und müsste doch dann auch als Weitergabe beim NGINX ankommen - oder?!

Liebe Grüße,

Marco

Weltklasse - es läuft!

Ganz vielen lieben Dank!!!

Mein Fehler war, dass ich den CN-Eintrag vornehmen musste, anstatt eine Weiterleitung einzurichten. Bei der Weiterleitung geht allem Anschein nach der Subdomain-Anteil verloren, was bei einem CN-Eintrag nicht der Fall ist. Deshalb funktionierte die Proxyweiterleitung nicht.

Falls das jemand mit zwei Sätzen begründen kann, würde ich mich freuen.

Ich bin völlig begeistert. Die Last ist marginal, es läuft alles über den NGINX in der VM, der hat die Firewall an und holt sich per CertBot automatisch ein neues LetsEncrypt-Zertifikat.

Toll!!!

Hallo Snowbox,

ich habe zunächst eine virtuelle Maschine hochgezogen mit Ubuntu 16.04 LTS Serverversion ohne Schnickschnack. Ich habe ihr nur einen Kern und 512MB zugewiesen, weil bei mir außer der Verteilung nichts darauf läuft. Darauf habe ich per apt NGINX installiert. Anschließend habe ich unter /etc/nginx/sites-available einzelne Konfigurationsdateien für jede Umleitung erstellt. Deren Inhalt sieht jeweils so aus:

server {listen 80;server_name kopano.*;location / {proxy_pass http://192.168.178.39;   }}

Zuletzt musst du noch Softlinks unter /etc/nginx/sites-enabled erstellen, damit die Konfigurationen auch berücksichtigt werden - und natürlich NGINX neustarten.

Anschließend habe ich mich in CertBot eingelesen:

https://certbot.eff.org

Die Installation ist denkbar einfach und es ist sehr gut dokumentiert.

Wenn man dabei die automatische https-Umleitung aktiviert, hängt der Certbot noch zusätzlich:

if ($scheme != "https") {
        return 301 https://$host$request_uri;
    } # managed by Certbot

an deine Konfigurationsdateien dran und jede http-Abfrage wird in https umgeleitet.

Zuletzt habe ich in der Fritzbox per Port-Forwarding alles, was auf 80 bzw. 443 rein bzw. rausgeht auf den besagten NGINX geroutet.

Wichtig ist, dass du in der Domainverwaltung deines Providers, bei dem du deine Domain hast (in meinem Falle Strato), den CN-Eintrag so setzt, dass alle von dir verwendeten Subdomains an deine Hauptdomain weitergeleitet werden. Diese Weiterleitung erhält den subdomain-Anteil derart, dass er von NGINX erkannt und an die enstprechend IP im LAN weitergeleitet wird.

Hilft dir das weiter?

Liebe Grüße,

Marco

Lieber Hassan,

sorry - ich hab nicht mitbekommen, dass Du gepostet hast.

Brauchst Du die Config noch?

Liebe Grüße,

Marco

Ergänzung:

Aus aktuellem Anlass habe ich meine Reverse-Proxy-Konfiguration erneut angepasst, weil interessanterweise gerade Safari-Clients SSL-verbundene Seiten nicht korrekt angezeigt haben. Für Safari bzw. Apple-Clients ist es wichtig, in den globalen SSL-Parametern z. B. in der default-Konfigurationsdatei (sie liegt in /etc/nginx/sites-available/default) von NGINX folgendes im listen 443 ssl -Block einzutragen:

ssl_session_cache shared:SSL:50m;

Ich hoste auch Mattermost, weshalb hier 50m angemessen sind, andernfalls reichen auch 10m.

Liebe Grüße

Hallo

"Sehr fit" wäre schön - bin ich aber gewiss nicht. Deshalb kann ich Dir leider nur meine NGINX-config geben. Damit funktioniert auch der VNC-Zugang auf die virtuellen Maschinen der Virtualization Station im Browser (bei mir Firefox). Was nicht funktioniert ist der Consolenzugang auf Container der Containerstation im Browser, aber das ist mir aus Sicherheitsgründen auch recht.

Hier die config für den ssl Block bzw. den Port 443, sofern er über die entsprechende Subdomain angesprochen wird:

upstream qnapbackend {
   server 192.168.....:....; # hier die LAN-IP und den SSL-Port der QNAP eintragen
   keepalive 32;
   }

server {
    listen 443 ssl http2;
    server_name SUBOMAIN.* www.SUBDOMAIN.*; # hier die Sub-Domain eintragen, die man als Weiterleitung verwenden möchte

    location / {
       client_max_body_size 1000M;
       add_header Vary Accept-Encoding;
       proxy_hide_header Upgrade;
       proxy_cookie_path / "/; HTTPOnly; Secure";
       proxy_set_header Connection "";
       proxy_set_header Host $http_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 $scheme;
       proxy_set_header X-Frame-Options SAMEORIGIN;
       proxy_pass https://qnapbackend;
       proxy_buffering off;
       #proxy_http_version 2;
    }

    ssl_certificate /etc/letsencrypt/live/DEINDOMAINNAME.DE/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/DEINDOMAINNAME.DE/privkey.pem; # managed by Certbot
    ssl_session_timeout 1d;
    keepalive_timeout 300s;
    ssl_protocols TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
    ssl_prefer_server_ciphers on;
    add_header Strict-Transport-Security max-age=15768000;
    ssl_stapling on;
    ssl_stapling_verify on;

    location ~ /qvs {
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "upgrade";
       client_max_body_size 100M;
       proxy_set_header Host $http_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 $scheme;
       proxy_set_header X-Frame-Options SAMEORIGIN;
       proxy_buffers 256 16k;
       proxy_buffer_size 16k;
       client_body_timeout 60;
       send_timeout 300;
       lingering_timeout 5;
       proxy_connect_timeout 90;
       proxy_send_timeout 300;
       proxy_read_timeout 600s;
       proxy_pass https://qnapbackend;
    }
}

Ich kann Dir viele der Config-Parameter nicht erläutern. Die meisten habe ich von der QNAP selbst übernommen, nachdem ich mir dort die Einstellungen des Web-Servers angeschaut habe. Wenn ich mich recht erinnere läuft auf der QNAP ein Apache - vielleicht findest Du dort ja sogar die richtigen Einstellungen für deinen Webserver.

Damit alle Anfragen von http auf https umgeleitet werden reicht bei NINX folgende config-Einstellung aus:

server {
    listen 80;
    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    }
}

Ich hoffe das hilft Dir ein wenig.

Falls jemand Sicherheitsrelevante Bedenken zu den Einstellungen hat würde ich mich freuen, hier davon zu erfahren.

Liebe Grüße,

Marco