Vaultwarden lokal, zerballert.

[delocke]

Hallo,
im Zuge des Neujahrsputzes habe ich Vaultwarden zerschossen. *rolleyes*

Ich habe AdGuard Home von der Syno runter geworfen und durch Diversion auf dem Router ersetzt. Danach hat alles wie gewohnt funktioniert. Dann habe ich die mich von der MacVlan Konfiguration trennen wollen und die .db im Docker Files Ordner gelöscht. Neugestartet und festgestellt, dass alle Docker laufen und funktionieren, lediglich der Vaultwarden Container lief zwar, aber ließ sich nicht mehr wie gewohnt über meineddns.synology.me nicht mehr aufrufen. Mist.

Eigentlich(TM), war Vaultwarden leicht installiert und funktional. Also neu versucht, aber ich bekomme nicht mehr die https Verbindung hin. Über die lokale IP komme ich zur Anmeldung, aber nur ungesichert; also, geht nicht.

Vielleicht sehe ich den Wald vor lauter Bäumen nicht.


Die DDNS Einstellungen, wobei die .49, die IP der Syno ist.



Der Reverse Proxy schaut so aus:



Der Container so:



Schaue ich mir das in Chrome an, bekomme ich das:




Bin ratlos, da ich nichts weiter verändert habe, Rebind ist deaktiviert etc.

 

[delocke]

Die Hauptroutingtabelle schaut seltsam aus, was Lan 2 angeht. Soll das so?

 

[Thonav]

Wieso steht beim DynDNS die IP Adresse der DS? Da gehört die externe Adresse des Routers rein. Stell das mal auf automatisch.

 

[delocke]

Das war schon auf automatisch und hat dann die externe IP meines DSL Anschlusses gezogen.
Gedanke ist, dass ich Vaultwarden ja nur lokal haben haben und das Zertifikat haben will, also, der Weg über extern gar nicht von Nöten ist. Deswegen die "Umbiegung"

 

[delocke]

gerade nochmal gedreht, keine Änderung.

des Weiteren in der Reverse-Proxy-Konfig nochmal nach Typos gesucht und nichts gefunden.

 

[ottosykora]

Das war schon auf automatisch und hat dann die externe IP meines DSL Anschlusses gezogen.

das wäre auch richtig so und dazu ist ja diese Funktion vorhanden

Zertifikat? Also wenn da was mit IP Adressen gehandhabt wird, gibt es keine Zertifikate dazu

 

[ottosykora]

Über die lokale IP komme ich zur Anmeldung, aber nur ungesichert; also, geht nicht.

das ist auch das Ziel der Sache: über lokale IP geht es nur ungesichert

 

[delocke]

Zertifikat? Also wenn da was mit IP Adressen gehandhabt wird, gibt es keine Zertifikate dazu

ich brauche ein https Verbindung zu Vaultwarden. Deswegen ja der Stunt über Synology.me. Wie geschrieben, ich habe nun den DDNS auf "Automatik" stehen. Allerdings bringt der Aufruf von meine.synology.me (an der das Zertifikat hängt) nicht nicht zurück auf die 192.168.0.49:5151; also, wo Vaultwarden lokal erreichbar ist.

 

[delocke]

So, nochmal mit frischem Kopf draufgeschaut.

Ping auf meine.synology.me löst auf meine externe IP auf. Passt.
Reverseproxy von meine.synology.me via https und Port443 geht auf die lokale IP der DS und den passenden Port von Vaultwarden.

Was habe ich noch versucht:
Diverse Neustarts von Router&DS.
Obwohl es in der Vergangenheit ohne Portweiterleitungen ging, erfolglos Portfreigaben eingerichtet.
Die Docker Network Config gelöscht.
Anderen Lan Port der DS genutzt und entsprechend umkonfiguriert.
Den Vaultwardencontainer neu aufgesetzt.

Alles ohne Erfolg. Bin recht ratlos. Verstehe nicht, warum es vor die Pumpe rennt. Leider ist Vaultwarden kein "nicetohave", sondern fundamental.

Ideen willkommen!

 

[alexhell]

Wenn du jetzt auf deine externe IP auflöst, hast du auch eine öffentliche IPv4? Weil wenn du vorher keine Ports gebraucht hast, dann hast du ja auf deine interne aufgelöst. Hast du das mal geprüft?

 

[delocke]

Ja, der Ping löst auf die externe, öffentliche IP des Anschlusses auf.
Eigentlich war ich sicher, bei der damaligen Einrichtung im DDNS, die interne IP der DS als externe Adresse angegeben zu haben. Hatte ds gestern Abend nochmals -sowohl die DS Adresse als auch die öffentliche- zu versuchen.
Beides erfolglos.

 

[alexhell]

Dann stell doch nochmal auf die interne um. Wenn er dann auf die interne auflöst, kommst du dann an die DS über https://dein-synoname.synology.me:5001? Wenn nein, dann muss die Anfrage ja von irgendwas geblockt werden. Ich kenn Diversion nicht, aber könnte das irgendwas blocken? Gibt es da ein Log für?

 

[plang.pl]

Ja, das mit intern passt schon so weit. Teste auch mal, ob die Adresse dann überhaupt korrekt aufgelöst wird (nslookup | intern)

 

[delocke]

Danke Alex,
es läuft wieder. Diversion war nicht das Problem, es war Unbound, der in den Logs einen Fehler hatte und die Nummer torpediert hat.
Einerseits bin ich erleichtert, dass es nun wieder läuft, aber andererseits ärgere ich mich, dass ich nicht an Unbound gedacht habe, den ich mit Diversion zusammen installiert hatte. Was allerdings tricky ist und die Fehlersuche erschwert hat, wenn unbound läuft und man meine-adresse.synology.me aufruft, wird die Seite offenbar aus dem Cache des Browsers geladen und erst bei der konkreten Anmeldung scheitert diese.
Anyway. Dank für den Support und hier meine Config für diejenigen, die Vaultwarden nur lokal im Netz laufen lassen wollen; und ja, es geht tatsächlich so einfach, wie ich es in Erinnerung hatte:




Danke und einen guten Start ins neue Jahr

 

[*kw*]

@delocke: ich konnte es nicht genau rauslesen, aber evtl. hilft dir bezüglich unbound dieser Hinweis?

 

[delocke]

Moin KW,
ich habe Unbound auf dem Router laufen und hatte da einen Fehler in der Config, der mir entgangen ist. Trotzdem ist der Hinweis interessant. Danke dafür!