DYNDNS-Adresse leitet auf die Fritzbox um

[taddy]

Der Titel ist etwas kryptisch, aber ich versuche das Mal zu erklären.

Auf meinem Homeserver läuft ein Container mit Docker, Portainer, Traefik und Bitwarden.

Installiert nach https://youtu.be/BG71vhnGKc4

Funktioniert auch, zumindest teilweise.

Ich kann von außen mit der DYNDNS auf den Bitwarden-Dienst zugreifen, alles super.
Versuche ich aber im LAN die Adresse aufzurufen komme ich auf die Fritzbox Adresse, wenn ich mittels IP auf den Server zugreife, funktioniert dies zwar, da ich aber kein HTTPS auf dieser Adresse habe, kann ich den Dienst nicht nutzen.

Daher meine Frage, warum ich mit der DYNDNS Adresse auf die Fritzbox komme und wie ich eine Umleitung einbauen kann.

[sei laut]

[..]
Daher meine Frage, warum ich mit der DYNDNS Adresse auf die Fritzbox komme und wie ich eine Umleitung einbauen kann.
Was ist die dyndns Adresse: Sie ist die IP, wie du extern (in deinem Bespiel deine Fritzbox) erreichbar bist.
Es zeigt als intern UND extern auf die Fritzbox

Warum kommst du extern auf bitwarden, intern aber nicht?
Stichwort ist Portweiterleitung: die ist wohl nur für externe Verbdingen konfiguriert. Wobei ich nicht weiß, ob die Fitzbox das so auch für interne Verbindungen unterstützt.

[GanjaBob]

das der DynDNS auf deine FritzBox zeigt ist normal. Du musst halt noch den Port angeben wo deine Dienste laufen. Vielleicht hast du das im externen so probiert und intern ohne Portangabe? Bei meiner Fritze leitet er beides entsprechend um.

[taddy]

das der DynDNS auf deine FritzBox zeigt ist normal. Du musst halt noch den Port angeben wo deine Dienste laufen. Vielleicht hast du das im externen so probiert und intern ohne Portangabe? Bei meiner Fritze leitet er beides entsprechend um.

Ich müsste die Fritzbox dazu bringen Port 80 und 443 auf die IP vom Container zu bringen. Ich habe nun den Container auf Port 7000 laufen, damit kann ich intern über DYNDNS:7000 auch auf den Dienst zugreifen, aber leider ohne HTTPS. Hat mir also nicht weitergeholfen.

Gibt es eine Möglichkeit ein SSL Zertifikat für eine IP zu erstellen? Damit könnte ich Bitwarden auch über das LAN über HTTPS laufen lassen

[GanjaBob]

da müsstest du an der Fritze den Port 443 extern an die IP Adresse von deinem Container Port 7000 weiterleiten.

IP Adressen in Zertifikaten wird seit einer Weile von bestimmten Diensten nicht mehr unterstützt

[Gast]

Ich habe nun den Container auf Port 7000 laufen, damit kann ich intern über DYNDNS:7000 auch auf den Dienst zugreifen, aber leider ohne HTTPS. Hat mir also nicht weitergeholfen.



Wofür überhaupt HTTPS im LAN.
Du könntest natürlich ein selfsigned Zertifikat nehmen und die Warnung beim Zugriff wegklicken.

[taddy]

Ich merke schon, dass ich in diesem Tutorial irgendetwas nicht ganz in Ordnung war, oder ich nach 2malige Versuch etwas übersehen habe..

Ich muss mich mal umschauen, ob es im Netz eine anständige Anleitung gibt für so ein Projekt.
Nach kurzer Recherche sieht es nicht danach aus, als ob das ein einfaches Unterfangen werden wird.

Ansonsten muss ich halt bei Keepass bleiben, was aber leider nicht so gut implementierbar ist

[PatkIllA]

Gibt es eine Möglichkeit ein SSL Zertifikat für eine IP zu erstellen? Damit könnte ich Bitwarden auch über das LAN über HTTPS laufen lassen
Das Zertifikat passt doch im Internet auch nicht zur Adresse oder?

Ich kann bei all-inkl auch dyndns für eine Subdomain einrichten und dafür könnte man sich auch Let's Encrypt Zertifikat erzeugen lassen.

[Gast]

Kannst du in der Fritze der dynip domain statisch die interne IP zuordnen? Das wäre meiner Meinung nach die korrekteste herangehensweise. Du willst ja nicht jeden HTTP/HTTPS traffic, der intern an die Fritzbox geht an deinen Container weiterleiten.

[qiller]

Der Titel ist etwas kryptisch, aber ich versuche das Mal zu erklären.

Auf meinem Homeserver läuft ein Container mit Docker, Portainer, Traefik und Bitwarden.

Installiert nach https://youtu.be/BG71vhnGKc4

Funktioniert auch, zumindest teilweise.

Ich kann von außen mit der DYNDNS auf den Bitwarden-Dienst zugreifen, alles super.
Versuche ich aber im LAN die Adresse aufzurufen komme ich auf die Fritzbox Adresse, wenn ich mittels IP auf den Server zugreife, funktioniert dies zwar, da ich aber kein HTTPS auf dieser Adresse habe, kann ich den Dienst nicht nutzen.

Daher meine Frage, warum ich mit der DYNDNS Adresse auf die Fritzbox komme und wie ich eine Umleitung einbauen kann.

Du musst noch Split-DNS bei dir einrichten. Von außen ist die Sache klar und das funktioniert auch mit Portforwarding etc. Intern musst du deinen Clients nun verklickern, dass sie, wenn sie die DYNDNS-Adresse aufrufen, nicht deine öffentliche IP-Adresse nutzen sollen, sondern die interne von deinem Server. Das macht man, indem man den internen DNS-Resolvern einfach die DynDNS-Adresse + interne IP-Adresse des Servers mitteilt.

Das sieht dann so aus, dass du je nachdem, wo du dich mit deinen Clients befindest (intern oder extern), 2 unterschiedliche IP-Adressen auf dieselbe DynDNS-Adresse als Antwort bekommst.

intern:
myhost.dyndns.org 192.168.20.20

extern:
myhost.dyndns.org <deine öffentlich zugewiesene IP-Adresse deines Providers>

Wenn es keine Möglichkeit gibt, eigene DNS-Hosteinträge auf deinem DNS-Resolver hinzuzufügen (die FB kann das meines Wissens nach nicht), kannst du auch die hosts-Dateien auf den Clients bearbeiten. Besser ist es aber auf dem DNS-Resolver.

PS: Hab das bei uns mit unserer Nextcloud so gemacht. So hab ich intern vollen LAN-Speed und kann von überall aus per HTTPS ohne Zertifikatsfehler auf die (eigentlich externe) Nextcloud-URL zugreifen.

[sei laut]

Ich merke schon, dass ich in diesem Tutorial irgendetwas nicht ganz in Ordnung war, oder ich nach 2malige Versuch etwas übersehen habe.. [..]

Das Tutorial ist interessant. Man kann bestimmt noch was dazwischen packen. Dein Problem ist, dass du dich nicht mit der Thematik beschäftigen willst. Das geht spätestens morgen schief, wenn es ein Update gab. (morgen als Synonym für die Zukunft) :D

Dein Problem hat qiller ganz gut zusammengefasst und er hat halt recht, dass die fritzbox sowas nicht kann.

Aber was ich nicht verstehe: Warum will man extern und intern den gleichen Namen haben? Ich würde intern das mit dem internen Namen aufrufen und extern halt über dyndns.
Vermutlich ist die Lösung zu einfach.

[PatkIllA]

Aber was ich nicht verstehe: Warum will man extern und intern den gleichen Namen haben? Ich würde intern das mit dem internen Namen aufrufen und extern halt über dyndns.
Vermutlich ist die Lösung zu einfach.Wegen Zertifikaten vielleicht. Das ist in internen Netzen fürn Eimer, wenn man nicht was einkaufen will.
Wobei es doch auch mit dem externen Namen klappt solange man online ist. Geht halt intern ebenfallse übers Gateway und portweiterleitung.

Habt ihr alle noch echte IPv4 Adressen?

[qiller]

Spätestens bei mobilen Clients, die man intern UND extern nutzt, fällt man damit auf die Nase oder es wird unpraktisch (VPN einrichten etc.). Geht natürlich alles, aber ich finds immer besser, wenn man sich einfach eine saubere URL/Domain merken kann und die Netzwerke die Zuordnung zur IP automatisch regeln. Das mit den behobenen Zertifikatsfehlern ist dann noch der Bonus.

[sei laut]

Spätestens bei mobilen Clients, die man intern UND extern nutzt, fällt man damit auf die Nase oder es wird unpraktisch (VPN einrichten etc.). Geht natürlich alles, aber ich finds immer besser, wenn man sich einfach eine saubere URL/Domain merken kann und die Netzwerke die Zuordnung zur IP automatisch regeln. Das mit den behobenen Zertifikatsfehlern ist dann noch der Bonus.
Stimmt, ich hab nicht zuende gedacht.
Daher hab ich das nicht zuhause gehostet. (zumindest nichts, was ich extern und intern nutze)

[taddy]

Das Tutorial ist interessant. Man kann bestimmt noch was dazwischen packen. Dein Problem ist, dass du dich nicht mit der Thematik beschäftigen willst. Das geht spätestens morgen schief, wenn es ein Update gab. (morgen als Synonym für die Zukunft) :D

Dein Problem hat qiller ganz gut zusammengefasst und er hat halt recht, dass die fritzbox sowas nicht kann.

Aber was ich nicht verstehe: Warum will man extern und intern den gleichen Namen haben? Ich würde intern das mit dem internen Namen aufrufen und extern halt über dyndns.
Vermutlich ist die Lösung zu einfach.

Das Problem ist nicht, dass ich mich nicht damit beschäftigen will, sondern die Tatsache, dass ich absolut keinen Plan davon habe.
Ich habe eine rein naturwissenschaftliche Ausbildung und habe mir mein restliches IT Wissen ausschließlich autodidaktisch beigebracht.

Mir sagen also ReverseProxy und restliche Spielereien halt auf anhieb nix. Ich bin ja froh, dass ich das Basic Linux so langsam auf die Kette bekomme.

Wie von PatKilla schon beschrieben hätte ich kein Problem damit, wenn ich wüsste, wie ich einer internen IP ein Zertifikat verpassen kann, auch ein Bereich in dem ich völlig blank bin.

Ich könnte natürlich den gehosteten Bitwarden Dienst nutzen, aber vllt kennt ihr den Drang sensible Daten bei sich zu hause und nicht in einer Cloud zu haben, auch wenn ich Bitwarden nicht unterstelle, dass die nicht auch auf die Vaults achten würden.

@Patkilla: Ich habe trotz Vodafone Kabel noch eine echte 4er IP, sonst würde ich mein VPN auch nicht nutzen können, habe die solange genervt bis sie mir eine gegeben haben, die Ausrede HomeOffice kam da nicht ungelegen.

[qiller]

...
Wie von PatKilla schon beschrieben hätte ich kein Problem damit, wenn ich wüsste, wie ich einer internen IP ein Zertifikat verpassen kann, auch ein Bereich in dem ich völlig blank bin.
...
Ganz ehrlich, wenn du jetzt sowieso schon eine Linuxkiste da stehen hast, die dauerhaft läuft, dann würde ich mich eher mit DNS-Resolvern beschäftigen (z.B. unbound, pihole etc.) und diesen dann per DHCP an deine Clients als DNS-Resolver verteilen. Das kann die FritzBox nämlich:
https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=73175&stc=1&d=1608636903
In unbound selber oder in der hosts-Namensauflösung deines Linux kannst du dann wieder das Split-DNS konfigurieren, was ich oben schon erwähnt habe. Das coole mit einem eigenen DNS-Resolver ist, du kannst da komplette Listen von externen DNS-Resolvern hinterlegen, die dann z.B. auch verschlüsselt abgefragt werden können (DNS-over-TLS, DoT). Man könnte z.B. auch Malware-Domain-Blocklisten einbauen (pihole). DNS-Namensauflösung ist durchaus ein Thema, womit man sich beschäftigen sollte. Ist immerhin eine der wichtigsten Kernkomponenten des Internets.

[Screemer]

läuft bei dir nicht sowieso schon pihole oder erinnere ich mich da falsch? das ist ein dns resolver. dem kannst du auch sagen, dass er den externen aufruf der dydns ip nicht ins nirvana schickt sondern eben auf deine interne ip des containers umleitet.

[lumines]

Wenn du der einzige Nutzer deiner Dienste bist, dann kannst du natürlich auch einfach selbst CA spielen. Du musst dann nur auf deinen eigenen Geräten dein Root-Zertifikat installieren und die entsprechend erzeugten Zertifikate / Keys bei deinen Diensten hinterlegen (vermutlich eher beim Reverse Proxy, wenn alles per HTTP abläuft). Das hier dürfte dich interessieren: https://github.com/jsha/minica

Warum überhaupt zu Hause hosten? vServer bekommt man für einen Apfel und ein Ei mit statischer IP.

[taddy]

@Quiller und Screemer

Ja, bei mir läuft ein RPi mit PiHole, Unbound und PIVPN. (Was ich noch nicht auf dem Proxmox erstellt bekommen habe)

Ich bin mir gerade nicht ganz sicher, wie ich das anstellen soll, vermutlich über die HOSTS Datei, oder?
Läuft dann der oben erwähnte Container oder wäre ein Bitwarden mit NGINX Unterbau einfacher/empfehlenswerter?

Folgende Tuts habe ich gefunden und scheinen für mich "nachvollziehbar"

https://bowlerdesign.tech/posts/how-to-self-host-bitwarden-on-ubuntu-server/

https://dennisnotes.com/note/20180627-ubuntu-18.04-nginx-setup/

[qiller]

@Quiller und Screemer

Ja, bei mir läuft ein RPi mit PiHole, Unbound und PIVPN. (Was ich noch nicht auf dem Proxmox erstellt bekommen habe)

Ich bin mir gerade nicht ganz sicher, wie ich das anstellen soll, vermutlich über die HOSTS Datei, oder?


Na das ist doch super. Glaube beim pihole kann man das sogar einfach in der Weboberfläche hinterlegen: https://mbuege.com/2020/07/27/eigene-dns-eintrage-mit-pihole-verwalten/

...sieht zumindest danach aus. Alternativ hat er da ja auch die hosts-Datei erwähnt. Und deine FB hast du per DHCP auch angewiesen, deinen pihole als DNS-Resolver zu nutzen? Oder trägst bei deinen Clients überall manuell den pihole als DNS-Server ein?

[taddy]

Na das ist doch super. Glaube beim pihole kann man das sogar einfach in der Weboberfläche hinterlegen: https://mbuege.com/2020/07/27/eigene-dns-eintrage-mit-pihole-verwalten/

...sieht zumindest danach aus. Alternativ hat er da ja auch die hosts-Datei erwähnt. Und deine FB hast du per DHCP auch angewiesen, deinen pihole als DNS-Resolver zu nutzen? Oder trägst bei deinen Clients überall manuell den pihole als DNS-Server ein?

Nein, der RPI ist in der FritzBox eingetragen und läuft auch einwandfrei.

Domain
ta***.dynv6.net

IP
192.168.178.50

Funktioniert leider noch nicht :confused:

[qiller]

Na was spuckt denn ein
nslookup ta***.dynv6.net
an einem Client in deinem Netz aus. Da muss dann ja die interne IP zurückgegeben werden, wenn die DNS-Caches alle gelöscht/flushed wurden.

[taddy]

Na was spuckt denn ein
nslookup ta***.dynv6.net
an einem Client in deinem Netz aus. Da muss dann ja die interne IP zurückgegeben werden, wenn die DNS-Caches alle gelöscht/flushed wurden.

Wir kommen voran, in kleinen Trippelschritten...

Non-authoritative answer:
Name: t*n.dynv6.net
Address: 178.200.46.13
Name: t*n.dynv6.net
Address: 2a02:908:1700:9:78a4:9ece:ddc1:5088

Interessant, die IP gibt es garnicht. Anpingen geht, aber weder die Fritzbox, die NetscannerApp auf dem Handy noch der PiHole kennt diese IP.

Rufe ich nun die DNS auf (innen und außen) komm ich auf die Fritzbox (Abfrage von Name und Passwort, also der Außenlogin)
Stelle ich den Bitwarden Container auf Port 7000 klappt es. Aber ich bekomme trotzdem die Meldung, dass ich intern kein SSL habe.

[qiller]

Eigentlich sollte da ja deine öffentliche IP-Adresse deines Anschlusses erscheinen, wenn du von extern abfragst. Du hast leider den abgefragten Server nicht mit angegeben - steht in der Regel dadrüber (zumindest beim Windows nslookup). Da müsste dann die IP vom RPI erscheinen, und als Anwort solltest du die IP-Adresse deines Bitwarden-Servers bekommen, wenn alles ordentlich konfiguriert ist.

Auf jeden Fall bekommst du keine private IP-Adresse zurückgemeldet, also kann das auch noch gar nicht gehen. Du kannst auch mal manuell den abgefragten Server angeben:

nslookup ta***.dynv6.net 192.168.20.2

192.168.20.2 steht dann für die IP deines RPIs. Dann weißt du wenigstens schonmal, ob der RPI richtig konfiguriert ist.

[taddy]

nn weißt du wenigstens schonmal, ob der RPI richtig konfiguriert ist.

root@HomeServer:~# nslookup ta*.dynv6.net 192.168.178.112
Server: 192.168.178.112
Address: 192.168.178.112#53

Name: ta*.dynv6.net
Address: 192.168.178.50
Name: ta*.dynv6.net
Address: 2a02:908:1700:9:78a4:9ece:ddc1:5088

Also die Rückmeldung passt schonmal

Hier nochmal die Screens von Portainer und Traefic

https://abload.de/thumb/1k5jr8.png (https://abload.de/image.php?img=1k5jr8.png)
https://abload.de/thumb/2g8jef.png (https://abload.de/image.php?img=2g8jef.png)

[qiller]

Also wenn ich das richtig sehe, ist also 192.168.178.50 ne Art Reverse-Proxy (ist das dieses Traefik?, hab ich noch nie von gehört^^) und der leitet auf den Bitwarden-Container mit IP 172.18.0.3 weiter. Sollte gehen.

Jetzt musst du dich nur fragen, welchen DNS-Resolver deine Clients per default nutzen. Die müssen natürlich dann deinen RPI anfragen, wo du pihole/unbound installiert hast. Dann sollten deine Clients auch die 192.168.178.50 als Antwort auf die Anfrage für ta*.dynv6.net bekommen, wenn sie sich im internen Netz befinden.

Edit: Im Grunde musst du 2 verschiedene Anworten bekommen:

intern:
nslookup ta*.dynv6.net 192.168.178.112

Name: ta*.dynv6.net
Address: 192.168.178.50

extern:
nslookup ta*.dynv6.net 8.8.8.8

Name: ta*.dynv6.net
Address: <deine aktuelle,öffentliche IP deines Anschlusses>

Dann hast du Split-DNS auf Resolver-Seite richtig eingerichtet.

[taddy]

Also wenn ich das richtig sehe, ist also 192.168.178.50 ne Art Reverse-Proxy (ist das dieses Traefik?, hab ich noch nie von gehört^^) und der leitet auf den Bitwarden-Container mit IP 172.18.0.3 weiter. Sollte gehen.

Jetzt musst du dich nur fragen, welchen DNS-Resolver deine Clients per default nutzen. Die müssen natürlich dann deinen RPI anfragen, wo du pihole/unbound installiert hast. Dann sollten deine Clients auch die 192.168.178.50 als Antwort auf die Anfrage für ta*.dynv6.net bekommen, wenn sie sich im internen Netz befinden.

Edit: Im Grunde musst du 2 verschiedene Anworten bekommen:

intern:
nslookup ta*.dynv6.net 192.168.178.112

Name: ta*.dynv6.net
Address: 192.168.178.50

extern:
nslookup ta*.dynv6.net 8.8.8.8

Name: ta*.dynv6.net
Address: <deine aktuelle,öffentliche IP deines Anschlusses>

Dann hast du Split-DNS auf Resolver-Seite richtig eingerichtet.

178.50 ist der Container auf dem Proxmox, Installiert ist (wie im Video vorgenommen) Docker, Portainer, Traefik (das ist dann der ReverseProxy) und Bitwarden.

nslookup ta*.dynv6.net 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Name: ta*.dynv6.net
Address: 178.200.46.13
Name: ta*.dynv6.net
Address: 2a02:908:1700:9:78a4:9ece:ddc1:5088

Das ist also die ominöse IP die ich absolut nicht zuordnen kann, diese IP existiert in meinem Netz anscheinend nicht (weder FritzBox, PiHole noch der LAN-Scanner listet diesen Port auf, Ping gibt aber eine Antwort)

BTW: In der aktuellen Konfiguration bekomme ich auf diesen beiden IPs "404 page not found".

Edit: nslookup
Standardserver: UnKnown
Address: 2a02:908:1794:92e0:8771:92b2:9074:7781 Ergibt im LAN die Ausgabe des Pis

[qiller]

Na wie lautet denn deine aktuelle, öffentliche IPv4-Adresse (https://www.wieistmeineip.de/)? Wenn das nicht die 178.200.46.13 ist, hast du entweder gar keine eigene IPv4-Adresse und hängst hinter einem NAT-Anschluss (DSLite, dann ist 178.200.46.13 das NAT-Gateway deines Providers) oder deine dynv6.net-Geschichte funktioniert nicht richtig.

Edit: Sollte ja auch die Fritzbox direkt auf der ersten Seite anzeigen, welche IP du vom Provider bekommen hast.

[taddy]

Na wie lautet denn deine aktuelle, öffentliche IPv4-Adresse (https://www.wieistmeineip.de/)? Wenn das nicht die 178.200.46.13 ist, hast du entweder gar keine eigene IPv4-Adresse und hängst hinter einem NAT-Anschluss (DSLite, dann ist 178.200.46.13 das NAT-Gateway deines Providers) oder deine dynv6.net-Geschichte funktioniert nicht richtig.

Edit: Sollte ja auch die Fritzbox direkt auf der ersten Seite anzeigen, welche IP du vom Provider bekommen hast.

178.200.46.13 ist echt meine IP, die 178 ähnelt so der Internen, dass ich nichtmal auf die Idee gekommen bin, dass es meine eigene AußenIP sein könnte

[qiller]

Also Portweiterleitung etc. passt. Sogar https-Weiterleitung ist aktiv. Mit der IP kommt zwar eine Zertifikatsfehlermeldung vom Self-Signed Zertifikats des Traefic Reverse Proxies, aber das ist normal. Wenn du deine dynv6-Domain ansurfst, sollte auch der richtige vHost im Treafic-Reverse-Proxy angesprochen werden und dann sollte auch das richtige Zertifikat ausgeliefert werden (falls es richtig eingerichtet wurde). Ich geh mal davon aus, dass im Tutorial letsencrypt verwendet wird, dann sollte der Browser auch ein von letsencrypt unterschriebenes Zertifikat bekommen (ohne Zertifikatsfehlermeldung).

Dass da ne simple 404-Seite kommt, wenn man die IP ansurft, sollte auch passen (find ich sogar gut so). IP = default vHost in Webservern und wenn der nicht eingerichtet ist, sollte da auch nix kommen, außer ne Fehlerseite.

Entscheidend ist, was kommt, wenn du deine dynv6-Domain ansurfst. Da sollte eigt. der Reverse-Proxy-vHost anspringen und der wiederum holt sich seinen anzuzeigenden Inhalt vom Bitwarden.

Ebenfalls wichtig ist dann auch noch, wo der http-/web-root liegt. Manche packen ja ihren Kram gerne in Unterverzeichnisse, weil da noch anderer Kram drauf läuft:

- https://ta*.dynv6.net/bitwarden
- https://ta*.dynv6.net/nextcloud
- https://ta*.dynv6.net/wordpress
...

Dann bekommt man beim Direktaufruf der Domain ohne Angabe des URL-Unterordners auch ne Fehlermeldung (je nach Konfig 403/404), wenn da keine index.html/php drin liegt, oder der Reverse-Proxy nicht direkt auf die Unterordner weiterleitet.

Als letzte Hürde könnte es auch eine sogenannte "erlaubte Domainliste" geben. Sowas gibts z.B. bei Nextcloud, wo man dann in der config.php angeben muss, unter welchen Domainnamen und IP-Adressen die Nextcloud-Instanz erreichbar sein soll. Ich geh erstmal nicht davon aus, dass das bei dir der Fall ist und wenn, dann muss das Tutorial ja schon dafür gesorgt haben, dass zumindest deine dynv6-Domain in so einer Liste drin steht.

[taddy]

So, ich habe nochmal alle Einträge überprüft und anhand des Tutorials verglichen.

Alles so wie es sein soll.
ABER: Keine Ahnung ob und wieso, anscheinend kann ich keine weitere Spezifizierung meiner Adresse eingeben. Also weder bitwarden.* noch */bitwarden funktioniert. (Eintrag geändert in .toml und in Portainer)

Nehme also die RootAdresse, die verweißt ja auch mittels nslookup geprüft auf den Server. Aber statt irgendeiner Adresse vom Server bekomme ich diese verfluchte Fritzbox Seite.
Könnte sich vllt irgendjemand vom Fach das mal irgendwann (momentan schlechter Zeitpunkt ;D) per TeamViewer oder wie auch immer anschauen?

[myMind]

Dazu fällt mir folgendes ein:

1. Das was qiller gesagt hat, nämlich die interne IP-Auflösung muss überall innerhalb deines LANs über einen DNS-Alias auf die interne IP verweisen. Überall heißt auch innerhalb der Netzwerke die Dockerseitig aufgespannt werden. Also auch wenn Du in einen Container hineingehst, sollte ta*.dynv6.net auf die LAN-lokale IP aufgelöst werden. Besonders da wo kein DHCP verwendet wird hinschauen, dass der separate DNS-Server eingetragen ist und nicht die Fritz!Box. Kurzgesagt muss DNS erstmal korrekt funktionieren.

2. Du kannst mit Routen (.../bitwarden) oder mit Subdomains (bitwarden. ...) arbeiten. Wenn Du mit Subdomains arbeitest (so wie im Video), musst Du auch für diese entsprechende Aliase im DNS konfigurieren. Also die IP für deinen Docker-Host "meintollerhost.meinheimnetz.de" muss dann einen Alias für ta*.dynv6.net und bitwarden.ta*.dynv6.net haben.

3. In den Diensten wie Bitwarden kann man oft die eigene URL angeben (z.B. "Server-Basis-URL"). Dort muss der DNS-Name verwendet werden, keine IP. Im Video wird das wohl über ein "Label" gesteuert (traefik.frontend.rule).

4. Was siehst Du in der Browser-Konsole beim Seitenaufruf (F12)?

Der Meilenstein wäre eigentlich, dass du mindestens immer auf dem Traefik landest. Bis dahin ist wahrscheinlich DNS noch nicht richtig oder IPs verwendet, wo DNS-Namen hin sollten.

[qiller]

Ka, was für ne FB-Seite das sein soll. Meinst du die Administrations-Weboberfläche? Die kann man ja (hoffentlich?) nur aus dem internen Netzwerk ansteuern. Also von außen sieht das mit den Portweiterleitungen erstmal gut aus. Man bekommt ne verschlüsselte 404-Seite und keine fritzBox-Seite o.ä., wenn man die IP ansurft. Ich kenn halt deine URL nicht und kann so schlecht die Namensauflösung und vhost-Zuordnung testen. Was passiert denn, wenn du mitm Handy auf "mobile Datenverbindung" (also WLAN aus, LTE an) wechselst und dann deine Domain ansurfst? Das ist dann quasi die Verbindung "von außen". Wenn das Tutorial alles richtig macht, sollte da ja was kommen (und nicht irgendeine FB-Seite), und wenns nur ne Fehlermeldung vom Reverse-Proxy oder Webserver ist. Wenn du deine Tests immer von innen machst, kann da auch ein Redirect o.Ä. noch stattfinden oder dein Client, mit dem da testest, greift auf eine falsche IP zu (z.B. die der FB), wenn du deine dynv6-Domain ansurfst.

Edit: Danke myMind, hab leider keine zeit, mir das Tut anzuschauen.

[taddy]

Dazu fällt mir folgendes ein:

1. Das was qiller gesagt hat, nämlich die interne IP-Auflösung muss überall innerhalb deines LANs über einen DNS-Alias auf die interne IP verweisen. Überall heißt auch innerhalb der Netzwerke die Dockerseitig aufgespannt werden. Also auch wenn Du in einen Container hineingehst, sollte ta*.dynv6.net auf die LAN-lokale IP aufgelöst werden. Besonders da wo kein DHCP verwendet wird hinschauen, dass der separate DNS-Server eingetragen ist und nicht die Fritz!Box. Kurzgesagt muss DNS erstmal korrekt funktionieren.

2. Du kannst mit Routen (.../bitwarden) oder mit Subdomains (bitwarden. ...) arbeiten. Wenn Du mit Subdomains arbeitest (so wie im Video), musst Du auch für diese entsprechende Aliase im DNS konfigurieren. Also die IP für deinen Docker-Host "meintollerhost.meinheimnetz.de" muss dann einen Alias für ta*.dynv6.net und bitwarden.ta*.dynv6.net haben.

3. In den Diensten wie Bitwarden kann man oft die eigene URL angeben (z.B. "Server-Basis-URL"). Dort muss der DNS-Name verwendet werden, keine IP. Im Video wird das wohl über ein "Label" gesteuert (traefik.frontend.rule).

4. Was siehst Du in der Browser-Konsole beim Seitenaufruf (F12)?

Der Meilenstein wäre eigentlich, dass du mindestens immer auf dem Traefik landest. Bis dahin ist wahrscheinlich DNS noch nicht richtig oder IPs verwendet, wo DNS-Namen hin sollten.

Hallo danke für deine Mühen,
1) Der Server ansich gibt meine AußenIP an, der Container an sich spuckt bei Lookup die Interne IP aus.
2) habe bitwarden.* mal eingerichtet und prüfe es gleich. Momentan bekomme ein Serverseite 404, sieht eigentlich vielversprechend aus. Im Host hatte ich es die Tage testweise eingetragen
3)Frontendrule wurde immer auf die Root oder auf bitwarden.* geändert
4)https://abload.de/thumb/175j0o.png (https://abload.de/image.php?img=175j0o.png) https://abload.de/thumb/2xzjgc.png (https://abload.de/image.php?img=2xzjgc.png) https://abload.de/thumb/305k5l.png (https://abload.de/image.php?img=305k5l.png)

Der Traefik läuft auf Port 8080, rufe ich t*dynv6.net:8080 intern auf erscheint auch Traefik, anscheinend wird also der Server gefunden, springt dann aber doch auf die Fritte um

@Quiller, der Fernzugriff ist deaktiviert, ich komme trotzdem auf diese Seite (Zu sehen am Screenshot)
Den Zugriff von außen teste ich mittels Datenverbindung am Handy.

Die VPN URL schicke ich dir per PN, ich möchte sie ungern hier im Forum stehen haben, man weiß ja nie.

[qiller]

Also von außen mit meinem IPv4-Anschluss funktioniert alles einwandfrei, sogar übers Smartphone mit LTE-Datenverbindung. Und auch Zertifikat passt. Das ist wenn, ein Problem von deinem internen Netz, DNS-Auflösung etc.

[taddy]

Habs nun auch zuhause geschafft, allerdings auf einem anderen Port.. ABER ich bekomme von außen ein Zertifikat, von innen, nicht...

Nun ist die Frage, ob ich den wirklich einen Passwortmanager unverschlüsselt betreiben möchte. Im Lan kein Thema, im Internet eine Katastrophe.

[myMind]

Habs nun auch zuhause geschafft, allerdings auf einem anderen Port.. ABER ich bekomme von außen ein Zertifikat, von innen, nicht...

Nun ist die Frage, ob ich den wirklich einen Passwortmanager unverschlüsselt betreiben möchte. Im Lan kein Thema, im Internet eine Katastrophe.
Willst Du nicht. Ich würde sogar eher noch überlegen, weitere Sicherheitsmechanismen einzubauen, als weniger (VPN, fail2ban, ...). Jeder weitergeleitete Port steht erstmal schutzlos im Internet. Die veröffentlichten Anwendungen sollten gut darauf vorbereitet sein.

Bei Punkt 4 von oben, ist die "Netzwerkanalyse" im Browser interessant, um zu schauen, welche Redirects (https://support.cloudflare.com/hc/en-us/articles/115003011091-3xx-Redirection)passiert sind. Also wenn Du sagst du gehst auf Seite X und findest dich plötzlich auf Seite Y wieder, könnte das aufgrund einer Anwendungsantwort mit 3xx passiert sein. Das kannst Du in der Netzwerkanalyse im Browser dann sehen. Die Frage war ja, wer schickt dich immer wieder zur Fritz!Box.

Was läuft jetzt auf welchem anderen Port? Ein anderer Port sollte nicht notwendig sein. Aber wenn ich das richtig verstehe, läuft DNS-seitig jetzt schon mal alles wie gewünscht. Von den Ports sollte es so funktionieren, dass Anfragen von außen über 80 und 443 hereinkommen und dann vom Traefik je nach Subdomain oder Route an die jeweiligen Services (hier Bitwarden) in das interne Netzwerk (z.B. 172.18.0.x) weitergeleitet werden. Ich würde mich erstmal mit Bitwarden-Testdaten auf unverschlüsselte Kommunikation fokussieren. Ganz zum Schluß, wenn alles funktioniert (inkl Zertifikate) würde ich zu einer Redirection im Traefik von 80 auf 443 raten, damit sichergestellt ist, dass immer verschlüsselt kommuniziert wird. Für den Anfang ist es praktisch das nicht zu haben, um die Zertifikatsproblematik für Tests erstmal ausklammern zu können.

Meilenstein 2: Alles funktioniert unverschlüsselt wie gewünscht über Port 80? Intern und extern?

Meilenstein 3: Zertifikate sind installiert und das automatische Renewal funktioniert (https://doc.traefik.io/traefik/https/acme/).

[taddy]

So ich habe im Moment nicht so viel Zeit daher eine kurzes Update:

Von Außen kann ich zuverlässig auf meinen Server zugreifen, intern ist Port 7000 auf 443 im Container verbunden.
Von Außen habe ich ein Zertifikat, von innen jedoch nicht.

ABER: Mittels Chrome PlugIn und AndroidApp kann ich mich mit dem Server verbinden und den Service auch nutzen. Auch wenn es ganz nett wäre, mit dem Browser auf den Server einzuloggen, so geht wenigstens die App.

@MyMind, Hardening werde ich noch durchführen. Fail2Ban ist fest geplant und 2FA müsste ich mir noch auf Handhabbarkeit genauer anschauen.

Das mit dem Redirect kommt mir auch merkwürdig vor. Ich habe mir dieses Redirect Path mal geladen:
Status Code URL IP Page Type Redirect Type Redirect URL
200 http://t*.dynv6.net/ 2a02:908:1700:9:78a4:9ece:ddc1:5088 normal none none

Auf dem Container läuft Portainer (:9000) Traefik (:8080) Bitwarden (:7000,:443,:80)

Das Zertifikat wurde automatisch mit der Installation von Bitwarden erstellt.

Dieses Thema Zertifikate scheint aber meine Fähigkeiten zu übersteigen, zumindest habe ich bislang im Netz nichts verständliches gefunden um zb. ein Zertifikat für meinen Proxmox, RasPi oder was auch immer zu installieren. Ansonsten könnte man ja auf die Idee kommen ein Zertifikat für die IP zu erstellen. Finde ich zb absolut unverständlich (https://github.com/dani-garcia/bitwarden_rs/wiki/Enabling-HTTPS)

[myMind]

So ich habe im Moment nicht so viel Zeit daher eine kurzes Update:

Von Außen kann ich zuverlässig auf meinen Server zugreifen, intern ist Port 7000 auf 443 im Container verbunden.
Korrigiert mich bitte, wenn ich da falsch liege, aber das ist nur der Noteingang, solange das Forwarding im Traefik nicht richtig tut. Ich mache solche Web-Geschichten auch noch nicht so lange.

Von Außen habe ich ein Zertifikat, von innen jedoch nicht.

Ein Standard-Setup ist, dass der Reverse-Proxy die Zertifikatsterminierung macht. D.h. Der Traefik verwaltet alle Zertifikate an seinem Eingang auf 443. Dazu müssen die Zertifikate im Traefik installiert sein oder man richtet Let's Encrypt so ein, dass das automatisch funktioniert (siehe oben verlinkte Anleitung). Dahinter geht es unverschlüsselt weiter vom Traefik zum Bitwarden (http).

Wenn Du mit Subdomains arbeitest, müssen die Zertifikate auch für diese gültig sein. Also entweder Wildcard-Zertifikate oder entsprechende Subject Alternative Names (SAN). Der Traefik muss dieses immer zurückliefern sobald jemand auf https://<service>.t*.dynv6.net/ oder https://t*.dynv6.net/ zurgreift. Das ist zumindest das Setup das ich kenne und wo ich mal davon ausgehe, dass es auch im Tutorial Video so gedacht ist.

ABER: Mittels Chrome PlugIn und AndroidApp kann ich mich mit dem Server verbinden und den Service auch nutzen. Auch wenn es ganz nett wäre, mit dem Browser auf den Server einzuloggen, so geht wenigstens die App.

Vermutlich nimmt die gerade immer den Weg außen herum über die FritzBox.

Das mit dem Redirect kommt mir auch merkwürdig vor. Ich habe mir dieses Redirect Path mal geladen:
Status Code URL IP Page Type Redirect Type Redirect URL
200 http://t*.dynv6.net/ 2a02:908:1700:9:78a4:9ece:ddc1:5088 normal none none

Das sieht nach IPv6 aus. Da bin ich leider nicht sehr sattelfest. Wessen IPv6 IP ist das? Falls das die der FritzBox ist, muss noch ein IPv6 IP Alias für t*.dynv6.net mit Verweis auf den Docker-Host in deinem lokalen DNS eingetragen werden. Das Ziel ist, dass alle lokalen Namensauflösungen von t*.dynv6.net über einen Alias auf den Docker-Host zeigen. Dort übernimmt der Traefik auf 443 und 80. Der Host selbst muss dann auch eine stabile IPv6 IP haben.

Auf dem Container läuft Portainer (:9000) Traefik (:8080) Bitwarden (:7000,:443,:80)

Portainer (:9000) : lokaler Verwaltungsport
Traefik (:8080) : lokaler Verwaltungsport
Bitwarden (:7000) : nur temporär. Soll wieder weg.
Bitwarden (:443,:80) : Kommunikation die über den Traefik nach außen geleitet wird. Eigentlich sollte hier nur :80 notwendig sein, da der Traefik https terminiert. Darum hast du http://172.18.0.3:80 als Backend im Traefik konfiguriert. Den 443 Port des Bitwarden kannst Du im Prinzip abschalten. Und achtung, der Port 80 liegt hier im 172.18.0.3, einem Docker-Internen Netzwerk. Den Host-Port-80 kennt nur der Traefik.

Das Schaubild aus dem Video ist auch dahingehend falsch, dass der Portainer genau gar nicht mit dem Traefik verbunden ist. Der Port 9000 ist einfach ein Host-Port, der in den Portainer gemappt ist.

Das Zertifikat wurde automatisch mit der Installation von Bitwarden erstellt.
Das ist vermutlich ein self signed Zertifikat. Richtig?
Dieses Thema Zertifikate scheint aber meine Fähigkeiten zu übersteigen, zumindest habe ich bislang im Netz nichts verständliches gefunden um zb. ein Zertifikat für meinen Proxmox, RasPi oder was auch immer zu installieren. Ansonsten könnte man ja auf die Idee kommen ein Zertifikat für die IP zu erstellen. Finde ich zb absolut unverständlich (https://github.com/dani-garcia/bitwarden_rs/wiki/Enabling-HTTPS)
Gewöhn dich dran. Anleitungen für die Zertifikatsinstallation sehen immer so schlimm aus. Der Mechanismuss ist aber in der Regel immer gleich. Dir fehlt da ein wenig Hintergrundwissen ohne das solche Anleitungen total kryptisch wirken.

Das Tutorial ist interessant. Man kann bestimmt noch was dazwischen packen. Dein Problem ist, dass du dich nicht mit der Thematik beschäftigen willst. Das geht spätestens morgen schief, wenn es ein Update gab. (morgen als Synonym für die Zukunft).
Das stimmt eben leider. Das Video ist in der Hinsicht, welche Funktionen Traefik (Reverse-Proxy) und Portainer (Container-Orchestrierung) bereitstellen einfach sehr dünn. Ich sehe das auch mehr als Teaser, um sich dann in die einzelnen Technologiestacks einzufuchsen.

Reverse-Proxy:

https Terminierung
Zertifikate

Typische Vertreter: Traefik, HA-Proxy, Ngnix

Container-Orchestrierung:

Steuerung und Parametrierung der Container

Typische Vertreter: Docker-Compose/Swarm, Kubernetes, Portainer, Rancher

[taddy]

Erstmal Danke für deine Ausführungen MyMind, die Tage nach Weihnachten haben mich ganz schön in Beschlag genommen.

Ich habe aber eine gute und eine schlechte Nachricht.. :freak:

Ihr wollt erst die schlechte? Alles klar:

Das Problem war IP6, wenn ich die URL intern ansteuer, dann biege ich IMMER auf die Fritzbox ab, egal was ich in piHole reinschreibe.

Und jetzt die GUTE NACHRICHT!

Scheiß auf IP6, im Container IP6 deaktiviert und intern die URL aufgerufen.. Der Scheiß läuft :tongue:

[qiller]

Jop, der Redirect-Path sah ja auch schon danach aus. Gut, dass du das Problem lösen konntest :>.

[Gast]

Hallo Leute mit Interesse lese ich hier mit.
Ich habe habe mir genau das gleiche Ding wie im YT Video erstellt.
Leider kann ich mich auch nicht per DNS Adresse von außen verbinden, ich kanndie DNS aufrufen dann kommt die Seite im Firefox mit "Mögliches Sicherheitsrisiko erkannt" dann sage ich Risiko akzeptieren und fortfahren und er verbindet sich per https und zeigt mir 404 page not found.

Ich habe es hier überflogen konnte aber nicht finden wie ihr es gemacht habt.
Was mich wundert sobald ich mich mit dem iPad verbinde klappt das.
Also auf die interne IP von aussen auch nicht

Der interne Port 7000 bei mir geht auch nicht da kommt dann immer der Hinweis ich soll im bitwarden_rs Wiki lesen da die https Verbindung nicht klappt.
Frage mich allerdings waum intern https.

Schlussfolgerung für mich der Aufruf per DNS Adresse funktioniert weil er mich ja weiterleitet, aber dann eben kommt die Bitwarden Oberfläche nicht.

[Simon Moon]

Ja, bei mir läuft ein RPi mit PiHole, Unbound und PIVPN. (Was ich noch nicht auf dem Proxmox erstellt bekommen habe)


auf dem unbound server:

/etc/unbound/unbound.conf

server:
# Local Network
local-data: "server.zuhause.lan. IN A 192.168.100.11"
local-data: "dynDNS.domain. IN A 192.168.100.101"
local-data: "client.local. IN A 192.168.100.102"
...
local-data-ptr: "192.168.100.11 server.zuhause.lan"
local-data-ptr: "192.168.100.101 dynDNS.domain"
local-data-ptr: "192.168.100.102 client.local"
...

[taddy]

Hallo Leute mit Interesse lese ich hier mit.
Ich habe habe mir genau das gleiche Ding wie im YT Video erstellt.
Leider kann ich mich auch nicht per DNS Adresse von außen verbinden, ich kanndie DNS aufrufen dann kommt die Seite im Firefox mit "Mögliches Sicherheitsrisiko erkannt" dann sage ich Risiko akzeptieren und fortfahren und er verbindet sich per https und zeigt mir 404 page not found.

Ich habe es hier überflogen konnte aber nicht finden wie ihr es gemacht habt.
Was mich wundert sobald ich mich mit dem iPad verbinde klappt das.
Also auf die interne IP von aussen auch nicht

Der interne Port 7000 bei mir geht auch nicht da kommt dann immer der Hinweis ich soll im bitwarden_rs Wiki lesen da die https Verbindung nicht klappt.
Frage mich allerdings waum intern https.

Schlussfolgerung für mich der Aufruf per DNS Adresse funktioniert weil er mich ja weiterleitet, aber dann eben kommt die Bitwarden Oberfläche nicht.


Hallo Gast, ich habe mich vor Ostern nochmal mit dem Projekt auseinander gesetzt.
Grund war hauptsächlich Unzufriedenheit. 1. Ich wollte die DYNDNS auf eine Subdomain legen und 2. eine Authentifizierung vor schalten.

Für letzteres gibt es zwar auch ein Tutorial Traefik und BasicAuth, versteht aber der nicht ITler nicht.
Traefik habe ich sowieso nie verstanden.

Die Auflösung der DNS habe ich damals ja per PiHole geregelt "DynDNS-Adresse -> Interne IP" funktioniert aber auch nur, wenn der Port auf 80 liegt.

Daher ist Port 7000 in diesem Projekt die falsche Idee.

Nun zu meinem Update: LXC Container neu erstellt und erst NGinx Proxy Manager erstellt

Ich finde NPM sehr einfach einzurichten und mit der GUI verstehe ich auch, WAS ich da mache.
Anschließend Portainer (Video von Dennis Schröder) und über Portainer dann BitwardenRS (ebenfalls aus dem Video). Bitwarden läuft auf 7000, funktioniert aber, da NPM das Zertikat regelt.

Mit NPM kann man auch problemlos BasicAuth aktivieren, allerdings musste ich merken, dass die Apps (Windows, Android und Chrome) damit nicht umgehen können. Ich verbinde die Apps nun per IP (das fehlende SSL Zertifikat stört die Apps nicht) und wenn ich mit dem Browser auf den Passwortmanager gehen will löse ich per URL auf und bekomme erst das BasicAuth Fenster angezeigt.

Läuft bei mir wunderbar und ich finde die Option nun viel besser. Bitwarden liegt auf einer Subdomain, ist mit BasicAuth gesichert und NPM kann auch noch verwendet werden um weitere Dienste umzuleiten.

Bei mir laufen nun auch noch Heimdall und Nextcloud über den NPM

auf dem unbound server:

/etc/unbound/unbound.conf

server:
# Local Network
local-data: "server.zuhause.lan. IN A 192.168.100.11"
local-data: "dynDNS.domain. IN A 192.168.100.101"
local-data: "client.local. IN A 192.168.100.102"
...
local-data-ptr: "192.168.100.11 server.zuhause.lan"
local-data-ptr: "192.168.100.101 dynDNS.domain"
local-data-ptr: "192.168.100.102 client.local"
...


Danke, ich habe es nun anders gelöst. Ich habe auf der VM nun Wireguard pur laufen und es funktioniert wunderbar.

https://abload.de/thumb/unbenanntbhjjy.jpg (https://abload.de/image.php?img=unbenanntbhjjy.jpg)

[Gast]

Vielen Dank taddy,

ich bin leider noch nicht der große Docker Kenner. Bei mir läuft alles zusammen auf dem Proxmox in einer Debain VM.
Mit nginx stehe ich irgendwie auf Kriegsfuß, besser mit den letsencrypt Zertifikaten... das hat bei mir noch nie richtig geklappt bzw. einmal sobald es an die Erneuerung ging funktionierte nichts mehr.

Der NPM läift in einem Docker Container bei dir..?

Unbound habe ich auch gelesen, kenne ich überhaupt gar nicht.
Ich verstehe auch nicht warum ich mit meinem iPad zugreifen kann und es öffnet sich Bitwarden und der Firefox, Chrome und Edge können es nicht.
Das ist alles ziemlich kompliziert, ich dachte es wäre einfacher zu lösen.
NPM schaue ich mir trotzdem mal an.
Vielen Dank

[Simon Moon]

npm ist doch der node package manager :|

[taddy]

npm ist doch der node package manager :|

Also für mich Nginx Proxy Manager;)

[Gast]

ich glaube ich werde das anders machen, ein LXC unter Proxmox mit Debian oder auch Ubuntu erstellen. Docker installieren und irgend ein Proxy Reverse damit ich dann auf Bitwarden komme mit der DNS Adresse...
Ich habe nur noch nicht das richtige gefunden....
In dem YouTube Video soll ja noch ein 3. Teil kommen, evtl. warte ich.

[lumines]

Ich will den Thread nicht derailen, aber dieses ganze Setup kommt mir schon enorm komplex für ein oder zwei Webdienste vor. Man könnte auch genau so gut bitwarden_rs als native Binary installieren und einen beliebigen Reverse Proxy vorschalten. Wenn ich das richtig sehe, unterstützt bitwarden_rs doch sogar als Datenbank SQLite. Noch ein Dienst weniger.

Ich denke bitwarden_rs mit SQLite als Datenbank und Caddy als Reverse Proxy (Caddy unterstützt Let's Encrypt / ACME und die Erneuerung von Zertifikaten nativ) wäre eher für Einsteiger geeignet als sich ein ganzes PaaS zu Hause aufzuziehen. Kann man sicher machen und vereinfacht vielleicht sogar Updates, aber man sollte sich schon fragen, ob das bei den paar Diensten vielleicht nicht ein kleines bisschen Overkill ist.

[Gast]

Ich will den Thread nicht derailen, aber dieses ganze Setup kommt mir schon enorm komplex für ein oder zwei Webdienste vor. Man könnte auch genau so gut bitwarden_rs als native Binary installieren und einen beliebigen Reverse Proxy vorschalten. Wenn ich das richtig sehe, unterstützt bitwarden_rs doch sogar als Datenbank SQLite. Noch ein Dienst weniger.

Ich denke bitwarden_rs mit SQLite als Datenbank und Caddy als Reverse Proxy (Caddy unterstützt Let's Encrypt / ACME und die Erneuerung von Zertifikaten nativ) wäre eher für Einsteiger geeignet als sich ein ganzes PaaS zu Hause aufzuziehen. Kann man sicher machen und vereinfacht vielleicht sogar Updates, aber man sollte sich schon fragen, ob das bei den paar Diensten vielleicht nicht ein kleines bisschen Overkill ist.
das probiere ich auch schon nebenbei... hatte mir das Video von Apfelcast angeschaut und hier wird erst einmal ein NGINX mit Weboberfläche installiert und dann muss man weiter schauen wie man den Bitwarden_rs dahinter bekommt.
Habe leider auch hier meine Probleme, weil Fehlermeldungen das weitere Setup blockieren.

[lumines]

das probiere ich auch schon nebenbei... hatte mir das Video von Apfelcast angeschaut und hier wird erst einmal ein NGINX mit Weboberfläche installiert und dann muss man weiter schauen wie man den Bitwarden_rs dahinter bekommt.

Um bitwarden_rs zu kompilieren, kannst du wahrscheinlich einfach diesem Tutorial folgen, bis du zu dem Abschnitt mit "supervisord" kommst: https://lab.uberspace.de/guide_bitwarden.html

Supervisord kannst du ignorieren, weil praktisch alle modernen Linux-Distributionen stattdessen systemd benutzen. Wenn du dabei hängst ein Service Unit File zu schreiben, kann ich dir da gerne aushelfen. Ausgehend von der supervisord-Konfiguration scheint das relativ trivial zu sein. Man muss nur einmal die .env-Datei als Environmentfile auslesen, weil bitwarden_rs daraus seine Konfiguration bezieht. Vielleicht setze ich bitwarden_rs nachher einmal selbst auf.

Wahrscheinlich willst du auch einen eigenen User auf deinem System für bitwarden_rs erstellen und im Service Unit File diesen User per User=bitwarden / Group=bitwarden angeben. Eventuell so (als root):


groupadd --system bitwarden
useradd --system \
--gid bitwarden \
--create-home \
--home-dir /var/lib/bitwarden \
--shell /usr/sbin/nologin \
--comment "bitwarden_rs" \
bitwarden


Wenn du Caddy als Reverse Proxy nutzt, besteht die minimalste Konfiguration für einen Reverse Proxy zu deinem lokalen Dienst wortwörtlich aus drei Zeilen (wohlgemerkt mit Zertifikat per Let's Encrypt) in der Caddyfile-Konfigurationsdatei, wenn Caddy einmal installiert wurde (https://caddyserver.com/docs/install#debian-ubuntu-raspbian):

Nach der Installation von Caddy muss er einmal gestartet werden. Per "enable" wird sichergestellt, dass Caddy auch nach einem Reboot automatisch gestartet wird. Als root:


systemctl start caddy
systemctl enable caddy


Mit "restart" wird er neu gestartet und liest dabei auch seine Konfiguration neu ein. Es gibt auch einen sanften Restart, aber dafür muss man ausschließlich die REST-API zur Konfiguration nutzen und das geht dann eventuell etwas zu sehr ins Detail.



<fqdn> {
reverse_proxy localhost:<port>
}


bitwarden_rs braucht ein bisschen mehr Konfiguration für Umleitungen auf Websockets etc., aber scheinbar haben die dafür schon eine fertige Konfiguration: https://github.com/dani-garcia/bitwarden_rs/wiki/Proxy-examples

Im Gegensatz zu nginx fragt Caddy auch erst die Staging-Server von Let's Encrypt an, damit du nicht in deren Rate Limiting läufst, falls du doch etwas falsch konfiguriert hast. Erst wenn Caddy erfolgreich ein Dummy-Zertifikat von den Staging-Servern bekommen kann, switcht er intern auf die richtigen Server und holt sich sein Zertifikat. Davon bekommst du nichts mit, das passiert vollkommen transparent für dich (genau wie die Erneuerung der Zertifikate). Wenn du von Let's Encrypt benachrichtigt werden willst, falls du doch einmal ein auslaufendes Zertifikat hast, kannst du deine E-Mail-Adresse im Caddyfile eintragen:

{
email <address>
}