Bitwarden / Vaultwarden via VPN erreichen ohne externen Zugriff mittels Domain

H3llF15H · 15. Januar 2023

Hallo allerseits!

Vaultwarden habe ich vor gut 1,5 Jahren mittels irgendwelchen Anleitungen zusammengefrickelt. Derzeit läuft es mit selbsterstellen Zertifikaten welche auf den Endgeräten manuell installiert werden müssen. Sehr unschön. Des Weiteren habe ich das Problem, das sich die Instanz nicht updaten lässt. Dies mag auch an meinem zwar gewachsenen Linux-Erfahrungen liegen, würde mich aber dennoch als Laie bezeichnen. Bis dato einziger Vorteil: Vaultwarden ist nur über VPN erreichbar.

Nun ist mein Ziel folgendes:

Bitwarden nach offizieller Anleitung selbst hosten (Virtuelle Maschine (VM), Debian 11.6)
kein Zugriff über das Internet mittels Domain und Portfreigabe, sondern nur über VPN
Bereitstellung des Dienstes für andere, häuslich getrennte, Familienmitglieder (VPN)
Alternativ auch gerne Vaultwarden, Nginx als Reserve-Proxy wäre dafür vorhanden
Keine selbsterstellen Zertifikate.

Ist-Situation:

Internetanschluss: Vodafone Cable Max 1000 mit angeblicher statischer IP (diese ändert sich sporadisch wenn seitens Vodafone die Verbindung gekappt wird, andernfalls bleibt diese Tage, Wochen, Monate dieselbe).
Router: Fritz!Box 6660 Cable
Domain bei Strato vorhanden, bei der x-beliebige Sub-Domains angelegt werden können (SSL-Verschlüsselung via Wildcard für alle (Sub-)Domains vorhanden
DynDNS ist im Router hinterlegt um die WireGuard nach der Änderung einer IP "den Weg zu weisen". Nennen wir die Subdomain wireguard.strato.de
AdGuard Home läuft als DNS-Server auf einer VM

Was bisher geschah:

Bitwarden nach dieser Anleitung ans Laufen gebracht, Update von Version 2022.12.0 auf 2023.1.0 funktionierte ohne Probleme
Dazu hab ich eine Sub-Domain angelget pwmanager.strato.de, A-Record mit der aktuellen IP meines Internetanschlusses versehen.
Port 80 und Port 443 für den Host der Bitwarden-VM in der FB6660 Cable freigegeben

Mein Problem mit dieser Konstelation:

Bitwarden ist mittels Sub-Domain pwmanager.strato.de aus dem Internet erreichbar. Auch wenn ich z.B. über Mobilfunk meine externe IP im Browser eingebe wird auf die zuvor genannte Sub-Domain verwiesen
Ich habe keine Möglichkeit gefunden nur mittels VPN gesichert auf Bitwarden zuzugreifen (https wird ja gefordert.

abschließende Fragen:

Habt Ihr Lösungsansätze um mein Vorhaben umzusetzen?
Wie kann ich die Ports 80 & 443 von Bitwarden (oder auch Vaultwarden) dauerhaft ändern ohne dass ein Update diese später wieder auf 80 & 443 setzt? Falls später andere Dienste hinzukommen würden, die ebenfalls auf Port 80 und 443 hören stehe ich da wieder mit meinem kurzen Hemd.

Kurzes Zitat aus der Hilfe von Bitwarden:

Standardmäßig wird Bitwarden über die Ports 80 (http) und 443 (https) auf dem Hostrechner bedient. Öffnen Sie diese Ports, damit Bitwarden von innerhalb und/oder außerhalb des Netzwerks erreicht werden kann.. Dies suggeriert mir, dass es dafür eine Lösung geben muss.

Vielen Dank für eure Hilfestellung und Unterstützung!

Schöne Grüße

Sebastian

cloudman · 15. Januar 2023

Tailscale verwenden wäre am einfachsten

H3llF15H · 15. Januar 2023

Danke für Deine Rückmeldung.

Magst Du mir auch kurz erklären worin Du den Vorteil siehst, bzw. wie Tailscale mich nach vorne bringt? Ich kenne den Dienst nicht.

Korben2206 · 15. Januar 2023

H3llF15H schrieb:
Nun ist mein Ziel folgendes:

kein Zugriff über das Internet mittels Domain und Portfreigabe, sondern nur über VPN

H3llF15H schrieb:
Ist-Situation:

Domain bei Strato vorhanden, bei der x-beliebige Sub-Domains angelegt werden können (SSL-Verschlüsselung via Wildcard für alle (Sub-)Domains vorhanden

DynDNS ist im Router hinterlegt um die WireGuard nach der Änderung einer IP "den Weg zu weisen". Nennen wir die Subdomain wireguard.strato.de

Das passt irgendwie nicht zusammen... wenn du nur VPN nutzen willst brauchst du kein DynDNS oder eine Portfreigabe. Und wenn du DynDNS und Portfreigabe nutzt, ist die Seite von außen für jeden erreichbar... da musst du dich schon entscheiden...
Ich wüsste jedenfalls nicht wie man das unter einen Hut bringen könnte..

Einfach VPN einrichten und Vaultwarden über den lokalen DNS (oder halt direkt über die IP) einrichten. Fertig.

cloudman · 15. Januar 2023

Schau dir mal Tailscale.com an.
Keine Ports müssen geöffnet werden.
Wireguard als Protokoll
Alle Clients bekommen feste IPs und bilden ein Netzwerk.
Falls man keine Client Software installieren kann setzt man einen Routing Client ein.
Das ganze funktioniert deshalb so einfach weil sich die Clients mit einem "Vermittlungsrechner' von Tailscale verbinden. Der macht nichts anderes als den Clients zu sagen wie die Partner erreicht werden können. Die Datenverbindung läuft nicht über deren Server sonder direkt zwischen den Clients (Wireguard Mesh)

H3llF15H · 15. Januar 2023

Korben2206 schrieb:
wenn du nur VPN nutzen willst brauchst du kein DynDNS oder eine Portfreigabe

In diesem Fall schon, sei denn ich habe da was missverstanden.
WireGuard läuft auf einer virtuelle Maschine, da WireGuard für die FB6660 noch nicht ausgerollt wurde.
DynDNS wird in diesem Fall benötigt um das Sub-Domain für WireGuard immer die aktuelle externe IP mitzuteilen. Leider geht damit auch eine Portfreigabe einher.

Korben2206 schrieb:
Einfach VPN einrichten und Vaultwarden über den lokalen DNS (oder halt direkt über die IP) einrichten. Fertig.

Leider ist das nicht so einfach, denn es benötigt ein SSL-Zertifikat um über https auf Vaultwarden / Bitwarden zugreifen zu können (http wird abgelehnt).

@cloudman
Danke für die Ausführung. Mein Ziel ist es, das nur am Rande, so wenig übers Internet machen zu müssen wie es nur geht. Beispiel: meine Daten liegen in keiner Cloud, sondern sind via VPN auf meinem NAS zu erreichen.

Yuuri · 15. Januar 2023

H3llF15H schrieb:
Vaultwarden habe ich vor gut 1,5 Jahren mittels irgendwelchen Anleitungen zusammengefrickelt.

Das compose File hätte gereicht, gar nur der vaultwarden Eintrag, wenn du caddy nicht nutzen willst.

H3llF15H schrieb:
Des Weiteren habe ich das Problem, das sich die Instanz nicht updaten lässt.

Weil? Du musst doch nur das Tag ändern und neu starten.

H3llF15H schrieb:
Bitwarden nach offizieller Anleitung selbst hosten (Virtuelle Maschine (VM), Debian 11.6)

Die Anforderungen des offiziellen Servers sind halt nicht für einfache Hostings gemacht. Unified ist da gemächlicher, aber auch erst Beta. Was erhoffst du dir durch den Einsatz der "großen" Instanz?

H3llF15H schrieb:
Bitwarden ist mittels Sub-Domain pwmanager.strato.de aus dem Internet erreichbar. Auch wenn ich z.B. über Mobilfunk meine externe IP im Browser eingebe wird auf die zuvor genannte Sub-Domain verwiesen

Leite es halt nicht weiter. Du musst ja irgend einen HTTP Server (Reverse Proxy) laufen lassen, der auf den Container weiterleitet. Direkt die Container Ports (80 + 443) weiterleiten ist nicht wirklich schlau. Das beantwortet implizit auch deine letzte Frage.

cloudman · 15. Januar 2023

Tailscale ist eben eine VPN Lösung die sehr einfach zu konfigurieren ist.
Da liegt nichts in der Cloud.
Du kannst dir den Tailscale Koordinerungsserver wie einen DNS Server vorstellen.

H3llF15H · 15. Januar 2023

Yuuri schrieb:
Das compose File hätte gereicht, gar nur der vaultwarden Eintrag, wenn du caddy nicht nutzen willst.

Wenn das so einfach wäre, wäre es auch möglich die Ports einfach zu ändern. Funktioniert leider nicht und mit meinem Wissen kann ich das Problem nicht bestimmen.

Das ich Caddy nicht nutzen will habe ich nicht gesagt

Nginx stünde zur Verfügung und macht nichts anderes als Caddy auch.

Yuuri schrieb:
Weil? Du musst doch nur das Tag ändern und neu starten.

Wie gesagt: es ist 1,5 Jahre her und ist zusammengefrickelt. Daher mein Neustart.

Yuuri schrieb:
Die Anforderungen des offiziellen Servers sind halt nicht für einfache Hostings gemacht. Unified ist da gemächlicher, aber auch erst Beta. Was erhoffst du dir durch den Einsatz der "großen" Instanz?

Könntest Du dies bitte etwas ausführen? Was meinst Du mit "einfachem hosting", "unified" und "großer Instanz"?

Yuuri schrieb:
Du musst ja irgend einen HTTP Server (Reverse Proxy) laufen lassen

Der wird automatisch mit dem Bitwarden-Skript installiert. Auf die Instanz habe ich keinen Einfluss. Bevor es zu Verwechslungen kommt: der von mir oben angesprochene Reserve-Proxy (Nginx) habe ich selbst aufgesetzt um ggf. eine Lösung für Vaultwarden zu finden.

MadMax_87 · 15. Januar 2023

cloudman schrieb:
Tailscale ist eben eine VPN Lösung die sehr einfach zu konfigurieren ist.
Da liegt nichts in der Cloud.
Du kannst dir den Tailscale Koordinerungsserver wie einen DNS Server vorstellen.

Tailscale hat nen "Koordinierungs-Server" , den nur sie betrieben, wenn ich mich auf die 60 sek google suche stürtze.
"Nichts mit Cloud"??? JA, weil es in "deren" Cloud liegt....
Ich hätte da schwere Bauchschmerzen, wenn meine Keys bei denen rumliegen, bzw. durch die erstellt werden...

H3llF15H · 15. Januar 2023

Hinzukommt, dass in der Hilfe von Bitwarden selbst erwähnt wird, dass es ein externer Zugriff nicht zwangsläufig Pflicht ist, so interpriere ich:

Standardmäßig wird Bitwarden über die Ports 80 (http) und 443 (https) auf dem Hostrechner bedient. Öffnen Sie diese Ports, damit Bitwarden von innerhalb und/oder außerhalb des Netzwerks erreicht werden kann.. Dies suggeriert mir, dass es dafür eine Lösung geben muss.

cloudman · 15. Januar 2023

MadMax_87 schrieb:
Tailscale hat nen "Koordinierungs-Server" , den nur sie betrieben, wenn ich mich auf die 60 sek google suche stürtze.
"Nichts mit Cloud"??? JA, weil es in "deren" Cloud liegt....
Ich hätte da schwere Bauchschmerzen, wenn meine Keys bei denen rumliegen, bzw. durch die erstellt werden...

Stimmt so nicht. Manchmal braucht es eben mehr als nur 60s Google.
Tailscale ist ein Zero Trust Netzwerk (gibt noch andere) alle haben gemeinsam, dass die Keys den Client nicht verlassen

Your data is end-to-end encrypted and transmitted point-to-point. Your devices’ private encryption keys never leave their respective nodes, and our coordination server only collects and exchanges public keys. DERP relay servers do not log your data — you can confirm this yourself as the code is open-source. Even when your connection uses a DERP relay server, the only data Tailscale could see and capture is encrypted

https://tailscale.com/security/#:~:text=Tailscale sees your metadata, not your data&text=We don't want your,collects and exchanges public keys.

Yuuri · 15. Januar 2023

H3llF15H schrieb:
Wenn das so einfach wäre, wäre es auch möglich die Ports einfach zu ändern.

Dann mach das doch. Du kannst das erstens im Mapping beim Deployment machen, aber weiterhin auch im Reverse Proxy. Ports im Container ändern zu wollen ist absolut überflüssig. Es ist auch nicht Aufgabe des Containers die Ports zu ändern. Theoretisch ist es auch komplett egal welche Ports exposed werden bzw. überhaupt ob.

Deine Aufgabe ist es, diese sicher einzubinden. Das heißt nicht, dass der Container im Host Network Mode laufen soll, sondern dass du einen Reverse Proxy davor packst und hierbei mittels Subdomain oder Pfad das Auftreffen der Pakete an deinen gewollten Container weiterleitest. Hierbei musst du vom Container nichts nach außen leiten (und das solltest du standardmäßig auch gar nicht), sondern routest intern auf dem Server weiter.

Einige Container geben auch nicht die Ports 80 oder 443, sondern bspw. 8080, 8888 oder 8443 weiter. Sowas kann man in Production nicht verwenden. Aufgabe hierbei ist es wiederum, dass der Reverse Proxy Pakete auf Port 80 annimmt und diesen an den Container an Port 8080 weiterreicht. Du machst hier also simples Routing bzw. ein NAT auf dem Server.

H3llF15H schrieb:
Könntest Du dies bitte etwas ausführen? Was meinst Du mit "einfachem hosting", "unified" und "großer Instanz"?

Das klassische Bitwarden Setup ist für große Deployments ausgelegt. Nicht umsonst besteht das Setup aus mehreren Containern, nutzt ne MSSQL DB, hat Mindestanforderungen von 2+ GB usw. Wenn du da ne Hand voll User drauf hosten willst, ist das kompletter Overkill und auf kleinen Geräten ggf. noch nicht mal ansatzweise möglich.

bitwarden_rs kam dann und implementierte die offene Spec in Rust neu und läuft u.a. standardmäßg mit ner SQLite DB. Kleiner Vorteil dadurch: Premium Features werden ebenso mit implementiert. Anforderung: 0, selbst ein Raspberry kann das hosten und auch kleinste VPS. Reicht für wenige User komplett aus.

Die Unified Beta von Bitwarden jetzt ist auch deutlich entschlackter und läuft auch mit MySQL oder PostgreSQL und erfordert auch lediglich nur noch 200 MB.

H3llF15H schrieb:
Der wird automatisch mit dem Bitwarden-Skript installiert.

Ganz ehrlich: Den Installer hab ich sofort aufgegeben und mit bitwarden_rs hantiert. Der Installer war leider komplett unfähig mit Dockers User Namespaces umzugehen, weshalb ich permanent in Permission-Fehler gerannt bin und das Deployment somit unmöglich war.

H3llF15H schrieb:
Hinzukommt, dass in der Hilfe von Bitwarden selbst erwähnt wird, dass es ein externer Zugriff nicht zwangsläufig Pflicht ist, so interpriere ich:

Du musst dir ja prinzipiell nur ein Zertifikat besorgen (Wildcard?) und für einen Domain Namen einen Eintrag im DNS Server im Netzwerk machen (und dafür sorgen, dass DNS Queries über das VPN geroutet werden). Das muss von außen dann nicht mal erreichbar sein. Wenn du eh schon nen DNS Server aufgesetzt hast, kannst du doch einfach Einträge dafür vornehmen, die nur innerhalb des Netzwerks gültig sind. Das erreichst du in nginx ganz einfach, wenn du die listen Direktive im server Block entsprechend anpasst und nicht auf *, 0.0.0.0 oder $externeIP lauscht, sondern einzig auf 192.168.0.0/24 oder was deine lokale Range eben ist. Dann ist pwmanager.domain.tld nur über 192.168.0.0/24 statt 0.0.0.0 erreichbar, ergo nur im Netzwerk und nicht übers gesamte Internet.

Korben2206 · 15. Januar 2023

H3llF15H schrieb:
In diesem Fall schon, sei denn ich habe da was missverstanden.
WireGuard läuft auf einer virtuelle Maschine, da WireGuard für die FB6660 noch nicht ausgerollt wurde.
DynDNS wird in diesem Fall benötigt um das Sub-Domain für WireGuard immer die aktuelle externe IP mitzuteilen. Leider geht damit auch eine Portfreigabe einher.

Ok, aber doch nur den Port für die Wireguard-Verbindung. 80 & 443 dann ja nicht, oder?

H3llF15H · 16. Januar 2023

@Yuuri
Vielen Dank für Deine Zeit und ausgeführten Meinung. Leistung wäre nicht das Problem, da die VMs alle auf einem TS-673A laufen. Jedoch habe ich eingesehen, dass Bitwarden ggü. Vaultwarden tatsächlich vermutlich Overkill ist und Vaultwarden "toleranter" in der Konfigurierung ist.

Da in Deiner Ausführung viele Informationen sind und ich mir die eine oder andere erst anlesen muss, werde ich versuchen diese in einer Testumgebung nachvollziehen zu können. Vor allem mit einem Reverse-Proxy muss ich mich noch genauer auseinander setzen. Ziel ist es einfach nur mittels VPN ins Heimnetzt zu gelangen und nicht über irgendwelche Portfreigaben.

@Korben2206
Korrekt. Für WireGuard ist nur der Standardport freigegeben.

h00bi · 16. Januar 2023

H3llF15H schrieb:
Vaultwarden habe ich vor gut 1,5 Jahren mittels irgendwelchen Anleitungen zusammengefrickelt.

H3llF15H schrieb:
Bitwarden nach dieser Anleitung ans Laufen gebracht, Update von Version 2022.12.0 auf 2023.1.0 funktionierte ohne Probleme

Du hast also Vaultwarden durch den neuen Bitwarden Unified ersetzt oder wie ist das zu verstehen?

Unified ist noch im beta Status.
https://www.computerbase.de/forum/threads/sammelthread-bitwarden-unified-beta.2121798/

Ich kann dir nur wärmstens empfehlen bei Vaultwarden zu bleiben.
Wenn du ein funktionierendes* Wildcard Zertifikat per letsencrypt/certbot DNS Challenge erstellst, brauchst du keine offenen Ports außer für die eingehende VPN Verbindung.

*"funktionierend" deshalb, weil in der armv7 (RasPi) Version von einigen nginx proxy manager Docker Images noch einer veraltete Certbot Version läuft, mit der keine DNS Challenges möglich sind.
mit der x64 Version von https://hub.docker.com/r/jc21/nginx-proxy-manager funktioniert das einwandfrei, weil hier schon certbot 2.x integriert ist. Das sollte für dein TS-673A passen.

Port 80 brauchst du nur für Zertifikate per http Challenge. Per DNS Challenge brauchst du keine Ports öffnen, dein (dyn)DNS Anbieter muss das aber unterstützen. Welchen Anbieter nutzt du?
Port 443 kannst du dicht machen wenn du von extern keinen Zugang willst.

H3llF15H · 16. Januar 2023

h00bi schrieb:
Du hast also Vaultwarden durch den neuen Bitwarden Unified ersetzt oder wie ist das zu verstehen?

Fast richtig

Mit Unified habe ich nichts an der Mütze, habe ich auch nirgendwo erwähnt.
Derzeit arbeite ich an einem Plan meine 1,5 Jahre alte Vaultwarden-Installation (durch Bitwarden) zu ersetzen. Es spricht aber auch nichts gegen Vaultwarden.

h00bi schrieb:
Ich kann dir nur wärmstens empfehlen bei Vaultwarden zu bleiben.

Yuuri hat quasi schon in die selbe Kerbe geschlagen und zugegebenermaßen hätte ich nach seinen Ausführungen kein Problem damit.

h00bi schrieb:
Wenn du ein funktionierendes* Wildcard Zertifikat per letsencrypt/certbot DNS Challenge erstellst, brauchst du keine offenen Ports außer für die eingehende VPN Verbindung.

In der aktuellen Bitwarden-Installation, die ich momentan ausprobiere, scheint das SSL-Zertifikat zu funktionieren. Andernfalls hätte ich vermutlich von extern mittels Browser keinen Zugriff auf Bitwarden.

h00bi schrieb:
Welchen Anbieter nutzt du?

Strato, mit dem Paket "SSL Starter Wildcard (DV)".

h00bi · 16. Januar 2023

Strato ist im nginx proxy manager nicht als DNS Provider integriert.
Wenn strato dir das Zertifikat ausstellt (für wie lange?) müsstest du es halt weiterhin selbst austauschen.
Ich habe meine Domain extra deswegen zu Netcup gelegt, weil Netcup per API über nginx proxy manager ansteuerbar ist.

Das ist aber auch kein Problem, wenn du keine http Challenge für das Zertifikat brauchst, dann muss auch Port 80 nicht nach außen offen sein.

Nutzt du dafür Docker auf deiner NAS?

Bei mir sieht das mit Docker so aus....
Vaultwarden lauscht innerhalb des Containers auf Port 80. Von Docker wird Port 6000 weitergeleitet.

nginx proxy manager lauscht auf Port 80 ....

forciert SSL ....

und leitet die Anfrage mit Zertifikat weiter auf Port 6000, wo Vaultwarden dann antwortet.

So gibts für dich keinen Grund einen Port aufzumachen.

EDIT: und ja, ich verwende Vaultwarden absichtlich mit Versionsangabe statt mit :latest weil ich keine semi-automatischen Updates will.

H3llF15H · 22. Januar 2023

Hallo allerseits,

da ich, wie jeder andere Bürger der BRD auch, gesundheitlich angeschlagen bin habe ich noch nicht die meiste Zeit gefunden mich meinem Vorhaben zu widmen. Gerne würde ich euch aber meinen Status Quo kurz darlegen (auch wenn er derzeit vom eigentlichen Ziel abweicht) und euch ein paar Fragen stellen.

Aktueller Aufbau:

Domain

Code:

meinedomain.de          # als DynDNS auf meiner FrizuBox hinterlegt
    proxy.meinedomain.de        # CNAME meinedomain.de, zwecks Aktualisierung der IP
    vaultwarden.meinedomain.de    # CNAME meinedomain.de, zwecks Aktualisierung der IP

Fritz!Box 6660 Cable

Code:

DynDNS aktiviert
Portfreigabe 80 & 443 für den Proxymanager (NGINX)

Virtuelle Maschinen

Code:

VM1: NGINX-Proxy
VM2: Vaultwarden

In NGINX habe ich einen Proxy Host hinzugefügt vaultwarden.meinedomain.de auf die VM2, inkl. einem SSL-Zertifikat von Let´s Encrypt. Das SSL-Zertifikat ließ sich ohne Probleme ausstellen und kann Vaultwarden mittels https erreichen. Funktioniert.

Nun zum Problem: wenn ich via Smartphone und mobilen Daten vaultwarden.meinedomain.de aufrufe, zeigt mir Chrome eine unsichere Verbindung an. Mit einem Service von IONOS habe ich prüfen lassen, ob die SSL-Zertifikate ordnungsgemäß installiert wurden - dies ist der Fall. Gegengeprüft habe ich es, in dem ich nachträglich die Portfreigabe auf einen anderen Host verwies. Hier war das Ergebnis ein falsch installiertes Zertifikat. So wie erwartet. Den Cache vom Browser zu löschen brachte keinen Erfolg.

Nun interessiert mich eins: weshalb habe ich von extern eine ungesicherte Verbindung auf Vaultwarden?

Vielen Dank für eure Geduld

€DIT:

man sollte auch mal https:// eingeben anstatt nur vaultwarden.meinedomain.de. Dann kommt man auch zu einer verschlüsselten Verbindung.

Nächste Frage: ist es umsetzbar, dass man auch ohne https einzugeben eine verschlüsselte Verbindung bekommt? Funktioniert bei computerbase.de und allen anderen Seiten ja auch.

Yuuri · 27. Januar 2023

H3llF15H schrieb:
Nun zum Problem: wenn ich via Smartphone und mobilen Daten vaultwarden.meinedomain.de aufrufe, zeigt mir Chrome eine unsichere Verbindung an.

Was ist denn die genaue Fehlermeldung? "Unsichere Verbindung" kann alles von ungültig, falsche Domain, falsches Datum, zurückgezogen, ... bedeuten.

H3llF15H schrieb:
Nun interessiert mich eins: weshalb habe ich von extern eine ungesicherte Verbindung auf Vaultwarden?

Weil du im Proxy höchstwahrscheinlich wie gesagt einfach auf Port 80 und 443 lauschst. Siehe dazu meinen letztens Absatz in #13. Wie sieht dein listen im Host aus?

H3llF15H schrieb:
Nächste Frage: ist es umsetzbar, dass man auch ohne https einzugeben eine verschlüsselte Verbindung bekommt? Funktioniert bei computerbase.de und allen anderen Seiten ja auch.

Du setzt einfach nen Host, der einzig auf https umleitet.

Code:

server {
    listen 192.168.0.2:80;
    listen [fd00::2]:80;

    server_name sub.domain.tld;

    access_log /var/log/nginx/sub.domain.tld.http.access.log;
    error_log /var/log/nginx/sub.domain.tld.http.error.log;

    return 301 https://$host$request_uri;
}

Bitwarden / Vaultwarden via VPN erreichen ohne externen Zugriff mittels Domain

Vice Admiral

Commander

Vice Admiral

Lt. Commander

Commander

Vice Admiral

Fleet Admiral

Commander

Vice Admiral

Lt. Commander

Vice Admiral

Commander

Fleet Admiral

Lt. Commander

Vice Admiral

Fleet Admiral

Vice Admiral

Fleet Admiral

Vice Admiral

Fleet Admiral

Ähnliche Themen