Vaultwarden - Zugriff über https nicht mehr möglich

[Benie]

Das funktioniert aber nicht zum ersten Einrichten von Vaultwarden., zum späteren Zugriff ist das möglich.

 

[crammaster]

1. Ist das nicht das erste einrichten, er hat Vaultwarden schon davor benutzt
2. Habe ich bei der Ersteinrichtung den Container auch über IP + Port angesprochen

Frage: Warum soll das nicht funktionieren?

EDIT: funktioniert mit der internen IP ausnahmslos nur mit einer Synology DDNS

Diese Aussage ist falsch, ich nutze dafür einen NGINX Proxy Manager und Domain Validation.

 

[Benares]

@Benie, die Umsetzung https->http soll ja (später) der Reverse Proxy machen, oder? Aber dazu muss zuerst mal http lokal funktionieren.

 

[OlliF69]

Mit der IP der Synology konnte ich in der Vergangenheit immer zugreifen.
Jetzt prüfe ich die CONF von Vaultwarden und richte parallel ein komplett neues Zertifikat mit subdomains ein.

 

[crammaster]

Also kommst du immer noch nicht drauf?

Das mit den Subdomains, darum kannst du dich noch kümmern wenn es wieder von lokal aus funktioniert.

 

[OlliF69]

Nein, immer noch kein Zugriff. Reboote gerade das NAS neu.

 

[crammaster]

Sieht bei mir ähnlich aus.

Und wenn du als Domain mal "http://192.168.178.99:5151" einträgst, also deine IP vom NAS + Port

Container neustart nicht vergessen

Edit: Habe gerade mal meinen Container neu gestartet und mir mal das Log angesehen. Nach dem ganzen unofficial blabla kommt nur die Zeile:

2024-07-28T14:11:05.052011762Z [2024-07-28 16:11:05.051][start][INFO] Rocket has launched from http://0.0.0.0:80

Das "http://0.0.0.0:80" steht dort, weil ich den Eintrag "ROCKET_ADDRESS" (0.0.0.0) habe.

 

[OlliF69]

Gerade das NAS neu gestartet und mit http://192.168.178.99:5151/ einen Anmeldeversuch ausgeführt - kein Zugriff !
Habe alle Freigaben in der Fritzbox heraus genommen. Greife zum Test schliesslich nur lokal zu. aber es geht nicht.

 

[crammaster]

Mir ist gerade aufgefallen, das der blöde Container Manager die neusten Einträge nicht nach unten packt, sondern nach oben.

Bei dir steht "Rocket has launched from http://127.0.0.1:80". Das heißt der Server läuft schon mal.

Jetzt setzt mal die Variable ROCKET_ADDRESS mit 0.0.0.0 und guck mal was passiert.

 

[Benie]

Weil Vaultwarden für die erste Einrichtung eines Vaultwardenserver

Aber dazu muss zuerst mal http lokal funktionieren.

Das Problem ist Vaultwarden kann ohne SSL nicht eingerichtet werden, und deshalb auch letztendlich mehr oder weniger hierfür https:// Zwang.

@crammaster

Es stimmt zwar schon, daß hier in diesem Fall Vaultwarden bereits eingerichtet ist, aber mir stellt sich die Frage, nachdem hier einiges an Wurm drinn zu sein scheint, ob das dann ohne https wieder hingebogen werden kann.

 

[OlliF69]

Ahhhh... Zauberei. Yippie... ich komme wieder auf meinen SAFE auf Vaultwarden - perfekt!

 

[crammaster]

Und was war es? xD

 

[Benares]

@Benie, ich kenne Vaultwarden nicht. Heißt das, dass man ihn nicht über http ansprechen kann?
Dann dürfte auch ein Reverse Proxy mit Ziel http://localhost:5151 nicht funktionieren.

 

[OlliF69]

Dieser Eintrag in den Einstellungen des Containers hat geholfen:
ROCKET_ADDRESS mit 0.0.0.0

So, jetzt an die Portfreigaben und die nächsten Schritte testen...

ABER: Schon mal besten Dank bis hierhin - beruhigt, dass der Zugriff so schon mal geht.

 

[Benie]

@Benares

Ich muß zugestehen, ich weiß da nicht mehr jeden einzelnen Schritt.
Aber auch ich stand seinerzeit vor dem Problem, daß Vaultwarden eben SSL für die Einrichtung nach installation verlangt hat. und wie auch eigentlich überall zu lesen, läuft die Vaultwardengeschichte immer in Verbindung mit https:// DDNS und Reverseproxy. Ich habe in der Zwischenzeit geggoogelt was geht und habe nichts gefunden, daß die Einrichtung rein über die IP möglich ist.

Ich nutze ja auch Vaultwarden über VPN über die interne IP, nachdem es alles eingerichtet ist, funktioniert das jetzt auch nur mit der internen IP und Port. Ich habe nur keine Lust, auch nicht auf einer VM alles runter zu schmeißen und alles von vorne weg inkl. der installation unter Docker durchzuspielen um zu zeigen wo es dann genau klemmt. Es sei denn mir ist was gänzlich unbekannt, hierfür bin ich sehr offen, weil es würde einiges für viel leichter machen.

Egal wann, ich habe die Einrichtung gleich immer von Anfang an nur auf diese weiße eingerichtet, darum kam ich garnicht mehr an das SSL Problem.

Aber dieses Thema, taucht auch hier im Forum immer wieder auf.

 

[crammaster]

Das Problem ist Vaultwarden kann ohne SSL nicht eingerichtet werden, und deshalb auch letztendlich mehr oder weniger hierfür https:// Zwang.

Hab gerade mal zum Spaß, ein Vaultwarden Container erstellt und konnte direkt via NAS-IP + Port drauf zugreifen. Kein SSL Zwang.

Kann natürlich sein, das du deinen Container anders aufgebaut hast und somit dieser SSL Zwang bestehen kann.

und wie auch eigentlich überall zu lesen, läuft die Vaultwardengeschichte immer in Verbindung mit https:// DDNS und Reverseproxy. Ich habe in der Zwischenzeit geggoogelt was geht und habe nichts gefunden, daß die Einrichtung rein über die IP möglich ist.

Auf welche Quellen beziehst du dich?

 

[Benie]

OK, da wäre halt die jaml dazu interessant, vielleicht taucht dieses Problem in der Tat nur dann auf wenn man über die DDNS zugreifen möchte.
Das war aber Notwendig, den die Möglichkeit über die Interne IP zugreifen gibt es erst seit DSM 7.2 oder sogar etwas später meine ich.
Bei gelegenheit werde ich mal Den Container neu aufsetzten und das dann mal anschauen.

 

[crammaster]

Ich nutze zum Beispiel den DDNS-Dienst von Synology nicht, sondern lasse über die Fritzbox meine DynDNS Adresse bei Strato befüllen. Die Subdomain leite ich dann via CNAME-Record auf DynDNS-Adresse um. Der Rest macht der Reverse Proxy. Deswegen skippe ich die ersten Schritte mit dem erstellen des SSL Zertifikats von Marius immer.

Wenn der Container später läuft und so funktioniert wie ich das will, erstelle ich die Subdomain, richte Reverse Proxy ein und beantrage dann das Zertifikat über die DSM. Bis dahin arbeite ich mit der NAS-IP + Port.

Den Container habe ich zu Zeiten von DSM 6.X zusammen geschustert und schon dort konnte direkt mit der IP drauf zugreifen.

vielleicht taucht dieses Problem in der Tat nur dann auf wenn man über die DDNS zugreifen möchte

Solange man https nutzen möchte, ja. Mit den richtigen Einstellungen kannst du auch http nutzen, nur halt nicht empfehlenswert im Internet.

 

[Benie]

OK, da wäre halt die jaml dazu interessant

Vielleicht kannst Du diese mal hier noch posten.

 

[crammaster]

Habe den Container nicht über Stacks zusammen gebaut, sondern als Container direkt.

Name: Such dir was aus xD
Image: vaultwarden/server:latest
Port: 80 -> 6969
Volume: /volume1/docker/vaultwarden-test (Host) -> /data (Container)
Env: ROCKET_ADDRESS = 0.0.0.0; ROCKET_PORT = 80; ROCKET_PROFILE = release; TZ = Europe/Berlin

Nutze von Marius nicht die PostGres Version, sondern die Standart MySQL Version. Sollte aber keinen Unterschied machen.