SSL Fehler bei Zugriff auf Nextcloud Instanz im lokalen Netzwerk

[--------]

Hallo zusammen,

ich bin mir nicht ganz sicher ob dieser Beitrag wirklich in dieses Unterforum gehört. Wenn das nicht der Fall sein sollte, bitte einfach verschieben.

Kurz als Hintergrundinfo: Ich hoste seit einigen Jahren meine eigene Nextcloud Instanz auf einem alten PC in unserem Netzwerk.
Diese läuft in einem Docker Container und ist auch von außen (aus dem Internet) zugänglich.
Dazu verwende ich Caddy 2 als Reverse Proxy, der sich bis jetzt auch immer sehr zuverlässig darum gekümmert hat, dass die Seite mit einem Let's Encrypt TLS Zertifikat abgesichert ist.
Bei der FritzBox ist sowohl DynDNS auf unsere Domain eingerichtet, als auch eine Portfreigabe für Caddy (Port 443 und 80).

Konkret sieht die Struktur also so aus: Internet/ LAN - FritzBox - Caddy - Nextcloud

Bis jetzt hat das auch alles super funktioniert und wenn ich aus dem Internet, also nicht aus dem lokalen Netzwerk auf die Nextcloud zugreifen möchte, klappt das auch nach wie vor ohne Probleme.
Nur seit kurzem bekomme ich, wenn ich aus dem lokalen Netzwerk jetzt auf die Nextcloud zugreifen möchte, diesen Fehler in Firefox angezeigt:

nc.meineDomain.de verwendet ein ungültiges Sicherheitszertifikat.

Dem Zertifikat wird nicht vertraut, weil es vom Aussteller selbst signiert wurde.

Fehlercode: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT

Der Zertifikat dazu ist tatsächlich ein selbstsigniertes, wobei ich überhaupt keine Ahnung habe, wo das herkommt (Screenshot findet ihr im Anhang).
Irgendwie glaube ich, das die FritzBox da beim Zugriff aus dem lokalen Netzwerk dazwischenfunkt.
Was ich dazusagen sollte: Ich habe letztens die DynDNS Einstellungen so bearbeitet, dass auch die IPV6 Adresse geupdatet wird, aber eigentlich sollte das doch keinen Unterschied machen oder?

Vielleicht hatte irgendwer von euch ja schon mal so ein Problem oder weiß, was man da machen sollten.
Vielen Dank

 

[DJKuhpisse]

Was ich dazusagen sollte: Ich habe letztens die DynDNS Einstellungen so bearbeitet, dass auch die IPV6 Adresse geupdatet wird, aber eigentlich sollte das doch keinen Unterschied machen oder?

Für das Zert macht IPv4/IPv6 keinen Unterschied, aber man sollte IPv6 nutzen, wenn es geht, denn IPv4 hat einen zu kleinen Adressraum und es gibt einen besseren Nachfolger.
EDIT: für was ist der Reverse-Proxy?
Greifst du intern auf dem Reverse-Proxy oder auf den Webserver direkt zu?

 

[--------]

Ja das mit IPV6 ist mir klar, aber für alle Geräte/ User/ Netzwerke die noch kein IPV6 unterstützen brauche ich nach wie vor die IPV4 Adresse (die man als Vodafone Business Kunde auch Gott sei Dank noch kriegt).

Der Reverse-Proxy ist einerseits dafür um bei Let's Encrypt sich um das HTTPS Zertifikat zu kümmern (Caddy macht sowas automatisch).
Auf der anderen Seite hoste ich nicht nur eine Nextcloud, sondern auch andere Dienste wie Jellyfin, etc. Diese sind alle jeweils über eine Subdomain verfügbar (nc.domain.de, jellyfin.domain.de, etc.), die aber als CNAME Eintrag alle auf die Haupt-Domain und damit auf die gleiche IP zeigen.

Ich hab immer noch nicht ganz verstanden wie das funktioniert, aber irgendwie friemelt Caddy die Requests dann wieder auseinander und leitet je nach Subdomain die Anfragen an den richtigen Port und somit an den richtigen Docker Container weiter.

Auch aus dem internen Netzwerk läuft alles über den Reverse-Proxy, damit ich auch hier HTTPS verwenden kann.

 

[DJKuhpisse]

Auch aus dem internen Netzwerk läuft alles über den Reverse-Proxy, damit ich auch hier HTTPS verwenden kann.

Dann musst du da mal schauen, wo das selbstsignierte Zertifikat herkommt. Ggf. mal in den Logs vom Proxy nachsehen.

 

[--------]

Das ist eine ziemlich gute Frage, die ich mir noch nicht erklären kann.
In den Logs vom Reverse-Proxy finde ich einige Fehlermeldungen, die aber wahrscheinlich davon kommen, dass die Verbindungen wegen des kaputten Zertifikats abgebrochen werden.
Bspw hier:

{
    "level": "error",
    "ts": 1647609011.435679,
    "logger": "http.log.error",
    "msg": "read tcp 172.17.0.5:38084->192.168.0.81:3012: read: connection reset by peer",
    "request": {
        "remote_addr": "178.202.244.87:49975",
        "proto": "HTTP/1.1",
        "method": "GET",
        "host": "pw.domain.de",
        "uri": "/notifications/hub?access_token=xxx",
        "headers": {
            "Sec-Websocket-Version": [
                "13"
            ],
            "Sec-Fetch-Site": [
                "same-origin"
            ],
            "Accept": [
                "*/*"
            ],
            "Connection": [
                "keep-alive, Upgrade"
            ],
            "Sec-Fetch-Dest": [
                "websocket"
            ],
            "Upgrade": [
                "websocket"
            ],
            "Sec-Websocket-Key": [
                "xxx"
            ],
            "Cache-Control": [
                "no-cache"
            ],
            "User-Agent": [
                "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:98.0) Gecko/20100101 Firefox/98.0"
            ],
            "Accept-Language": [
                "en-US,en;q=0.5"
            ],
            "Accept-Encoding": [
                "gzip, deflate, br"
            ],
            "Origin": [
                "moz-extension://b8283335-f8c9-3946-bae6-75ec9e4db43f"
            ],
            "Sec-Websocket-Extensions": [
                "permessage-deflate"
            ],
            "Sec-Fetch-Mode": [
                "websocket"
            ],
            "Pragma": [
                "no-cache"
            ]
        },
        "tls": {
            "resumed": true,
            "version": 772,
            "cipher_suite": 4865,
            "proto": "http/1.1",
            "proto_mutual": true,
            "server_name": "pw.domain.de"
        }
    },
    "duration": 0.000807453,
    "status": 502,
    "err_id": "i7we1brjb",
    "err_trace": "reverseproxy.statusError (reverseproxy.go:886)"
}

 

[DJKuhpisse]

Da steht nix vom Zert, das ist interner Traffic. Connection reset könnte ein TCP-RST sein. Beobachte das zur Not mit Wireshark.

 

[--------]

Ich bin mir ziemlich sicher, dass das Traffic ist, der vom LAN auf den Bitwarden Server (noch so ein Service, der hinter dem Reverse Proxy läuft) zugreifen möchte.
"192.168.0.81:3012" ist nämlich die Adresse unter der der Bitwarden Websocket erreichbar ist.

Ich werde mal versuche Wireshark da irgendwie dran zu hängen, wobei ich kein Experte mit der Anwendung bin.

 

[DJKuhpisse]

Ich bin mir ziemlich sicher, dass das Traffic ist, der vom LAN auf den Bitwarden Server (noch so ein Service, der hinter dem Reverse Proxy läuft) zugreifen möchte.
"192.168.0.81:3012" ist nämlich die Adresse unter der der Bitwarden Websocket erreichbar ist.

Ich werde mal versuche Wireshark da irgendwie dran zu hängen, wobei ich kein Experte mit der Anwendung bin.

Du musst die dahinterliegenden Protokolle verstehen.
Ein gesetztes RST-Flag gibt es bei TCP z.B. auch dann, wenn auf dem Port kein Serverdienst läuft.

 

[--------]

Ja das stimmt natürlich, der Webservice läuft aber auf jeden Fall, sonst könnte ich ja nicht aus dem WAN auf Bitwarden, Nextcloud etc. zugreifen.

Die Wireshark Analyse war aber tatsächlich ganz aufschlussreich, auch wenn ich ungern das ganze Protokoll hier posten möchte.
Anscheinend bekommt mein PC auf die DNS AAAA-Anfrage zum meiner Nextcloud Domain jetzt tatsächlich eine IPV6 Adresse als Antwort zurück (zusätzlich zur IPV4 Adresse auf die A Anfrage).
Diese beiden Adressen zeigen direkt auf meinen Router, also die FritzBox.

Firefox scheint nun die Anfrage auch an die IPV6 Adresse des Routers zu schicken.
Dementsprechend geht auch das TLS Client Hello direkt an den Router.
Ich dachte jetzt, dass der Router (wie bei IPV4) die Anfrage an meinen Reverse-Proxy weiterleitet.
Vermutlich geht da aber irgendetwas schief, das Server Hello kriege ich nämlich auch von der IPV6 Adresse des Routers zurück.
Das würde auch erklären warum ich in diesem selbstsignierten Zertifikat die ganzen FritzBox Domains hab.

Ich denke ich habe da irgendeinen Fehler bei der Portweiterleitung oder bei der DynDNS Konfiguration.
In der Portweiterleitung von der FritzBox steht nämlich bei IPV4 die eine öffentliche IP Adresse des Routers, bei IPV6 aber jeweils die IP(V6) Adressen des Servers, wo auch der Reverse-Proxy läuft.

Muss ich dem DynDNS Dienst für IPV6 die IPV6 Adresse des Reverse Proxys mittteilen und nicht die des Routers? Aber dann nur für meine Subdomains, die über den Reverse-Proxy laufen? Geht sowas überhaupt?

Ich bin ziemlich verwirrt, wie man vielleicht merkt...

Edit: Ich glaub ich bin mit meiner IPV4/ IPV6 Dual-Stack Konfiguration genau in das Problem hineingelaufen, welches in diesem Beitrag erklärt wird: https://decatec.de/home-server/dynd...tzbox-mit-ipv4-und-ipv6-dual-stack-betreiben/

 

[DJKuhpisse]

Muss ich dem DynDNS Dienst für IPV6 die IPV6 Adresse des Reverse Proxys mittteilen und nicht die des Routers? Aber dann nur für meine Subdomains, die über den Reverse-Proxy laufen? Geht sowas überhaupt?

Ich würde den DynDNS auf dem Reverse-Proxy laufen lassen. Dass das auf dem Router funktioniert ist IPv4-NAT geschuldet, was eine Notlösung aufgrund der Adressknappheit ist. Lasse z.B. ddclient auf dem Server laufen. Bei IPv6 schickt der die eigene globale IPv6-Adresse an den DynDNS-Anbieter, bei IPv4 nutzt er die Methode Web um die öffentliche IP des Routers herauszubekommen.

 

[--------]

Jep genau das versuche ich auch gerade einzurichten. Denke das ist der Fehler
Ja mega, hab ddclient auf dem Server eingerichtet und jetzt klappts endlich wieder. Vielen Dank für deine Hilfe!

 

[--------]

So ganz perfekt scheint es wohl leider doch noch nicht zu funktionieren.
Ich kriege zwar keine Zertifikatsfehler mehr, weil der AAAA DNS Eintrag jetzt nicht mehr auf die IPV6 Adresse meiner Fritzbox zeigt, aber die IPV6 Verbindung scheint nach wie vor noch nicht so ganz zu klappen.

Aus meinem lokalen Netzwerk kann ich einen Ping6 ausführen auf die Domain, aus dem WAN allerdings nicht.
Wenn ich mich die Nextcloud Website aufrufe, verwendet Firefox laut Wireshark auch wieder die IPV4 Adresse.

Dabei habe ich eigentlich in der Fritzbox die korrekte Interface ID von meinem Server eingetrage, Ping6 freigegeben und Port 80 und 443 auch für die IPV6 Adresse freigegeben.

Docker habe ich nach dieser Anleitung so konfiguriert, dass die Container jetzt auch unter IPV6 erreichbar sein sollten:

Eingebundener Inhalt

Youtube

youtube.com/watch/?v=FOFTEsgxro4:243

An dieser Stelle findest du externe Inhalte von Youtube. Zum Schutz deiner persönlichen Daten werden externe Einbindungen erst angezeigt, wenn du dies durch Klick auf "Alle externen Inhalte laden" bestätigst: Alle externen Inhalte laden Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit werden personenbezogene Daten an Drittplattformen übermittelt.
Für mehr Informationen besuche die Datenschutz-Seite.

Aber ich glaube nicht, dass es an Docker liegt, wenn ich schon keinen Ping6 durch bekomme, zumindest nicht aus dem WAN.

Noch irgenwelche Ideen?

 

[DJKuhpisse]

Kannst du mal deinen Domainnamen nennen? Ich teste das dann mal von hier und schaue, was kommt.