Verbindung unterbrochen - Debugging Hilfe benötigt

IPv64.net - Services
, ,
1

Hallo zusammen,

ich habe einen Glasfaser-Anschluss (CG/Nat) und nutze daher für den Zugriff auf lokale Ressourcen ein CDN (alternative Lösungswege sind in diesem Forum dazu schon ausgiebig beleuchtet worden). Zu dem CDN gibt es natürlich eine DynDNS-Domain und verschiedene SubDomains, die alle über das CDN auf das CDN-Backend laufen. Meine lokale Ressource, die hinter dem Backend hängt ist nicht die Fritzbox, sondern ein traefik - die IPv6 des traefik kommuniziert er selbst per DynDNS-Update. Zertifikate bezieht der traefik selbst von LetsEncrypt automatisch für jeden Service.

Das funktioniert alles normal und gut, bis vorgestern - meine Services sind nicht mehr erreichbar.

Das Debugging habe ich von beiden Seiten begonnen.

  • Schritt 1: Mein traefik bzw. die einzelnen Services werden intern für Testzwecke mit dev.local erreicht und whoami.dev.local zeigt mir das gewünscht Ergebnis → traefik funktioniert damit zunächst einmal (Zertifikate noch außen vorgelassen).
  • Schritt 2: FritzBox - Portfreigabe auf 443 für Gerät vorhanden
  • Schritt 3: DynDNS - der IPv6-Präfix in meiner Fritzbox und die individuelle IPv-6 Adresse meines traefik habe ich geprüft, sie sind korrekt aktualisiert. Ich habe korrekterweise auch nur einen AAAA-Eintrag.
  • Schritt 4: DNS - von einem dritten, unabhängigen Rechner außerhalb meines Netzes mit nslookup meineDomain.tld und nslookup sub.meineDomain.tld geprüft - das Ergebnis ist die korrekte Adresse des CDN (an dieser Stelle die IPv4).
  • Schritt 5: CDN-Backend - curl -I https://sub.meineDomain.tld zeigt mir:
...
* connect to <CDN-IPv4> port 443 from <Internet-Host> port 50960 failed: Connection refused
* Failed to connect to <sub.meineDomain.tld> port 443 after 65 ms: Couldn't connect to server
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Closing connection
curl: (7) Failed to connect to <sub.meineDomain.tld> port 443 after 65 ms: Couldn't connect to server

Und da stehe ich nun und komme nicht mehr weiter. Die Portfreigabe auf der Fritzbox ist gelöscht und neu eingerichtet worden, die Fritzbox hat das neueste OS 8.22 und wurde auch neu gestartet. Meine LE-Zertifikate schließe ich bei connection refused aus. DynDNS und CDN scheinen für mich zu funktionieren, aber irgendwo zwischen CDN-Backend und meinem traefik klemmt´s.

Kann mir jemand mit dem nächsten Schritt helfen?

2

Kurze Ergänzung: ich hatte das CDN im Nachgang zu meinem Hilferuf leicht verändert (Caching deaktiviert), um eine neues Deployment zu triggern. Das läuft jetzt schon länger und ich sehe nur den drehenden Kreis - wahrscheinlich klemmt das CDN. Vielleicht lege ich es später noch einmal neu an, nachdem ich es löschen konnte …

3

ich konnte ein ähnliches Phänomen beobachtet seit gestern Abend (ca. 21:30 Uhr). Ich habe heute morgen eine zweite Dydns Adresse zum CDN (ohne Set DNS, Reverse Proxy etc. zu aktivieren) hinzugefügt um zu schauen, ob das CDN irgendwie reagiert. Die Erstellung hat geklappt, aber das löschen scheint nicht zugehen. Auch bei mir ist der Status seit längerem jetzt bei beiden der drehende Kreis. Da bei aktiven CDN das löschen nicht möglich ist (Fehler: Permission Denied"), habe ich den AAAA Record gelöscht, somit konnte ich meine Haupt DynDns Adresse löschen. Jetzt habe ich im CDN eine “.” Domain und meine zweite Test Domain die mit dem drehenden Kreis versehen ist, jedoch konnte ich meine Haupt Adresse neu anlegen und Schritt für Schritt das CDN wieder aufbauen. Meine Dienste im Homelab scheinen jetzt erstmal wieder erreichbar zu sein.

4

Mein CDN hatte jetzt nach längerer Wartezeit den Status fully-activated bekommen und einzelne Services waren auch direkt erreichbar. In Summe ist aber alles noch sehr volatil und ich warte noch einen Moment ab.
Kann jemand erklären, was zwischen CDN-Backend und meiner lokalen Ressource noch alle passiert? Oder anders herum: war ich mit meinem Debugging eigentlich schon am Ziel und habe nur die Ziellinie nicht gesehen?

5

Es funktioniert wieder alles. Da hat sich im CDN wohl was verklemmt