Bitwarden (Docker) auf QNAP - wie Zugriff über Internet?

[TWIN013]

Hallo zusammen!

Nachdem ich mit meinen Experimenten bzgl. Pi-Hole und Unbound unter Docker auf QNAP Systemen mittlerweile erfolgreich war, wollte ich mich an ein weiteres Projekt wagen: Bitwarden. Der Container läuft und ist unter seiner internen IP (192.168.1.40, Container läuft im Bridge Modus unter eigener IP) auch abrufbar. Nur wie komme ich jetzt von außen, sprich übers Netz an Bitwarden heran?
Rufe ich von außen die xyz.myqnapcloud.com:443 auf, so lande ich ja auf der Login-Seite der QNAP.
Meine erste Idee war dazu in der UDM-Pro ein Portforwarding einzurichten, so dass z.B. der externe Port 445 intern auf die IP des Bitwarden Containers Port 443 weitergeleitet wird, im Beispiel also xyz.myqnapcloud.com:445. Leider war die Idee nur in der Theorie gut, denn da passiert einfach nichts.
Einen integrierten Reverse Proxy wie bei Synology scheint es ja leider nicht zu geben, so dass mir momentan ein wenig die Ideen ausgehen... für Denkanstösse wäre ich sehr dankbar!

 

[Bodennebel]

Hilft das eventuell? https://forum.qnapclub.de/thread/46065-reverse-proxy-empfehlung-der-community/

Bin aber kein Experte auf dem Gebiet.

 

[chainr3action]

Was ist der Grund für den Bridge Modus? Wäre doch einfacher, wenn du die NAS IP verwendest und dann einfach die Ports beim Erstellen des Containers entsprechend mappst ( -p 445:443)?

Und das DynDNS Zeug von QNAP ist eh nicht so toll. Das könntest du doch auch mit deinem UDM Pro machen oder? Dann kannst du dort auch sauber deine Freigaben pflegen, ohne dass dir dein NAS dazwischen pfuscht.

 

[TWIN013]

@chainr3action Um den Grund mit einem Wort zu beschreiben: Unwissenheit.
Kann ich diese Portumleitung in Docker auch irgendwie über die Umgebungsvariablen eintragen? Meine Kenntnisse der CLI unter Docker sind gleich Null.

Eine DDNS in der UDMP hatte ich ebenfalls mal eingetragen, war mir jedoch nicht sicher, ob das auch funktioniert hat - wie testet man sowas? Die QNAP war jedenfalls unter der xyz.afraid.org Adresse nicht erreichbar.

 

[chainr3action]

Wenn du DDNS im Unifi Controller konfigurierst ist ja auch erstmal nur sichergestellt, dass deine (sich ändernde) externe IP, die du von deinem Provider erhältst, immer über eine gleichbleibende URL erreichbar ist. Welche Services du dann freigibst bleibt dir überlassen. Du gehst im Unifi Controller dann auf Port Forwarding und trägst dort IP und Port des NAS ein und den externen Port unter dem es dann erreichbar sein soll.

Ich bin jetzt auch kein Pro was Docker betrifft. Und von der QNAP Container Station halte ich auch nicht viel. Wobei ich sagen muss, dass ich mir die Software schon länger nicht mehr angesehen hab. Vielleicht hat sich da inzwischen was getan.
Jedenfalls löschst du normalerweise einfach den Bitwarden Container und erstellst ihn mit den richtigen Settings neu. Die Daten und Einstellungen des Containers sollten auf einem persistenten Volume auf dem Host/NAS liegen, wenn du es richtig eingerichtet hast. Beim Neuerstellen des Containers gibst du das Volume wieder an und hast alle Daten wieder.
So macht man später dann auch Updates. Man lädt das neue Docker Image und erstellt den Container neu wobei man wieder auf die bestehenden Daten verweist.

 

[TWIN013]

Die Sache mit den persistenten Volumes ist mir vom Prinzip her klar, habe ich z.B. beim Pi-Hole Container ja ebenfalls gemacht, nur: woher weiß man, welche Verzeichnisse für welchen Container persistent angelegt werden müssen? Bei Pi-Hole heißen sie /etc/pihole und /etc/dnsmasq.d, wo sieht man, wie sie bei Unbound, Bitwarden oder was auch immer heißen müssen?
Genauso die Sache mit dem Portmapping - wird das ebenfalls in den Umgebungsvariablen gemacht, oder muss ich dazu in die CLI?

 

[chainr3action]

Das muss entweder der Software Hersteller oder der Image Hersteller angeben.
Falls du das hier verwendest:
https://hub.docker.com/r/bitwardenrs/server
Da steht dabei: This will preserve any persistent data under /bw-data/, you can adapt the path to whatever suits you.
Da steht auch dabei wie man die Ports setzt. Das macht man normalerweise eben im Terminal/CLI.
docker run -d --name bitwarden -v /bw-data/:/data/ -p 80:80 bitwardenrs/server:latest

Da du bei der Container Station soweit ich das sehe die GUI benutzen MUSST, bleibt dir nichts anderes übrig, als die Doku zu lesen. Laut Anleitung von QNAP zur Container Station gehst du beim Erstellen auf Advanced und dann Network. Da kannst du das Port Mapping eintragen.

 

[TWIN013]

So, ich kann erfreulicherweise ein paar Erfolge vermelden: die Portweiterleitungen kann man unter "Netzwerk" tatsächlich manuell vergeben, der Bitwarden-Server ist jetzt auch von extern erreichbar. Das Datenverzeichnis nennt sich trotz Verwendung des von Dir genannten Containers allerdings nur /data, weshalb auch immer... Dateien werden im zugewiesenen Verzeichnis abgelegt.

Jetzt stehe ich noch vor einer (vermeintlich letzten) Hürde: bei Verwendung von MS Edge (Chromium) verlangt Bitwarden eine gesicherte Verbindung, die er offensichtlich nicht bekommt. Ein aktuelles Zertifikat ist auf der QNAP installiert, aber das alleine scheint zum Herstellen einer gesicherten Verbindung nicht zu genügen. Woran liegt das?

Ergänzung: die Verbindung zur QNAP-GUI wird sehr wohl als gesichert angezeigt, obwohl sich die Verbindungen jetzt ja eigentlich nur im verwendeten Port unterscheiden...

 

[EscoR]

Hallo,

ich glaube ich habe das gleiche „Problem“ wie TWIN013
ich versuche mir gerade ebenfalls Bitwarden_rs einzurichten.
Ich verwende eine Fritzbox 7490 und ein Qnap TVS-472XT.
Ich habe mir bei https://ddnss.de einen Dyndns eingerichtet und diese in der Fritzbox hinterlegt.
Des Weiteren habe ich in der Fritzbox die Portweiterleitung vom Nas auf den Port 443
Eingerichtet. Ich komme also wenn ich https://Meinesubdomain.ddnss.de:433 im Browser eingeben auf mein NAS.

In der Container Station habe ich also bitwardenrs/server:latest installiert und gehe jetzt über
Einstellungen -> Netzwerk.

Dort komme ich zu folgender Maske.

Diese kann ich allerdings nicht ganz nachvollziehen.
Kannst du mir das etwas erklären?
was trage ich da jetzt ein?

Host ist die 433 und dann zu der Container ip?
das hat eben nicht funktioniert.

Vielen Dank.

 

[TWIN013]

Hi!

Also diesen Teil hatte ich ja irgendwann hinbekommen: es funktioniert tatsächlich so, dass Du hier den Port der Qnap (Host) auf den Port des Containers "umbiegst". In der Fritze musst Du natürlich den Host-Port auf die Qnap auch freigeben, um von außen darauf zugreifen zu können.

 

[EscoR]

Vielen Dank für die schnelle Antwort.
Ich werde es heute Abend nochmal versuchen.

Wenn ich noch nachfragen darf, wie hast du die Problemematik mit der SSL-Verschlüsselung gelöst?
Ich wollte Let’s Encrypt nutzen aber so wie ich das sehe, müsste ich manuell alle drei Monate das Zertifikat erneuern.

Ich habe gerade gelesen, per reverse proxy über Ngnix oder treafik wäre ein "wechsel" auch automatisch machbar.

bitte nicht falsch verstehen, ich erwarte keine Anleitung oder ähnliches ein Tip oder Denkanstoss reicht mir vollkommen. Es geht ausschließlich darum nicht in die falsche Richtung zu "probieren".

 

[TWIN013]

Nein alles gut, ich bin ja auch froh, wenn mir geholfen wird. Die SSL Sache stellt für mich leider immer noch den Punkt dar, an dem ich nicht weiter komme. Ehrlich gesagt bin ich selbst für LetsEncrypt zu planlos...
Der Reverse Proxy war auch meine erster Ansatz - bei einer Synology wird der mitgebracht und ist wohl recht einfach einzusetzen, allerdings waren alle Anleitungen, die ich zu dem Thema gefunden habe, weit über meinen Linux-Kenntnissen...

 

[Tokolosh]

Reverse Proxies wie Traefik haben ein Plugin für LetsEncrypt und übernehmen die LetsEncrypt Zertifikat Beantragung automatisch. D.h. kein manuelles Erstellen von SSL Zertifikaten. Allerdings muss deine Domain dann von einem der unterstützten Provider verwaltet werden.

https://doc.traefik.io/traefik/https/acme/#providers

Außerdem gibt es noch ein weiteres Bitwarden OpenSource Clone Projekt, das kompatibel zu allen Bitwarden Clients ist und auch die normalerweise kostenpflichtigen Premiumfeatures anbietet.

https://github.com/dani-garcia/bitwarden_rs

 

[TWIN013]

Das Problem der Portumleitung bekam ich irgendwann ja gelöst, von daher würde ein ReverseProxy wie Traefik für mich eine wahrscheinlich größere Hürde darstellen, als Bitwarden selbst. Die Installation (und Erstellung) eines Zertifikats in den laufenden Bitwarden-Server ist mir allerdings nach wie vor ein Rätsel.

@Tokolosh Ist dieser Schritt bei der _RS Variante denn ebenfalls erforderlich?

 

[Tokolosh]

Es gibt öfters die Möglichkeit TLS bei den Services selber einzustellen. Auch bei bitwarden_rs: Enable HTTPS

Allerdings wird hier auch ein Reverse Proxy empfohlen. Ich würde meine containerisierten Anwendungen auch untereinander per http kommunizieren lassen und die SSL/TLS-Terminierung von Außen einem Reverse Proxy überlassen. So ist man gut aufgestellt. Bei Traefik füge ich neuen Services einfach ein paar labels in der docker-compose.yml hinzu und es werden automatisch Zertifikate generiert von Traefik. Also einmal eingestellt und Traefik übernimmt den Job für dich. Wie gesagt, das geht nur, wenn deine Domain von einem bestimmten DNS Providern verwaltet wird. Aber das ist keine wirklich Hürde. Falls du mal eine Config brauchst oder noch mehr Infos möchtest, sag Bescheid.

 

[TWIN013]

@Tokolosh Ich fürchte ich bräuchte mehr als nur ein wenig Hilfe.

SSL/TLS-Terminierung - Ich weiß was SSL bedeutet, beim Rest bin ich raus...
Bei Traefik füge ich neuen Services einfach ein paar labels in der docker-compose.yml hinzu - wenn man weiß wie...

Aber ich bin ja lernfähig, also wenn Du Lust, Laune und vor allem Geduld hast hier ein kleines "How-to" mit einem Linux-Planlosen aufzuziehen, dann sehr, sehr gerne!

 

[Tokolosh]

Ja, ich geb zu die Lernkurve ist etwas steil bei Traefik. Ich wusste jetzt nicht wieviel Vorkenntnisse vorhanden sind, weil hier schon von Reverse Proxy etc gesprochen wurde. hab nicht alles detailliert verfolgt und wollte nur etwas zu bitwarden_rs erwähnen, da es eine sehr gute Alternative zum eigentlichen Bitwarden-Server ist.

Ich weiß nicht, ob ich die Zeit habe ein HowTo zu verfassen. Aber ich denke ich könnte dir eine funktionierende Beispiel docker-compose.yml config zukommen lassen am Wochenende.

Zu SSL Terminierung:
Was ich damit meine ist, dass der ReverseProxy quasi die Anlaufstelle all der HTTP/HTTPS Requests auf eine bestimmte Domain von Außen ist. Du richtest z.B. bitwarden.mydomain.com ein und sagst dem Reverseproxy, dass er, wenn er Anfragen zu dieser domain bekommt sie an den entsprechenden Service (den Bitwarden container) weiterleiten soll. Deshalb Reverse proxy, weil von außen nach innen. dabei ist es dir dann egal, ob der Verkehr von Proxy zu App unverschlüsselt ist, da die Kommunikation eh nur im privaten Netzwerk statt findet. Der Service kann auch auf irgend einem Port laufen. Das ist der Gedanke dahinter. somit musst du dich nicht bei jedem Service, den du nutzen willst darum kümmern, wie du dort SSL verarbeiten kannst. Die meisten containerisierten Anwendungen werden auch nur genau so entwickelt. Sie bringen einen Webserver mit, der nur auf HTTP requests auf port 3000 z.B. hört. Sowas würde man grundsätzlich nicht von Außen verfügbar machen. Deswegen der ReverseProxy-Ansatz. Dort müsstest du nur eine Konfiguration anpassen und sagen, dass der neue Service mit der Domain myservice.mydomain.com jetzt bitte auf diesen docker container mit diesem port "zeigt". Dadurch, dass docker seine Services per Namen findet, können dir auch sämtliche internen IPs egal sein.

Hoffe, dass dieser kleine Anriss etwas mehr erklärt und nicht nur noch mehr verwirrt.

 

[TWIN013]

Die Frage kann ich mit einem deutlichen Jein beantworten.

Ja zum Thema ReverseProxy, aber mit der von Dir angebotenen Beispieldatei wäre ich wahrscheinlich schon stark überfordert. In der QNAP einen Container zum Laufen bringen geht gerade noch so, Ports und permanente Verzeichnisse hinzufügen auch, aber das wars auch schon...