[Proxmox|HA-OS|Nginx] HA extern erst Stunden nach DNS-Update erreichbar

Installation, HW & HA-OS
1

Hallo liebe Community,

ich habe das seltsame Problem, dass meine Home-Assistant Installation, für die ich externen Zugriff eingerichtet habe, erst in den Nachmittagsstunden von außen erreichen kann. Dies ist jeden Tag so. So sieht meine Home-Server Landschaft aus:

  • Auf einem HP-Elitedesk läuft Proxmox
  • Dort ist HA-OS als VM eingerichtet
  • Nginx Proxy Manager läuft parallel als Proxmox Container
  • Es gibt noch weitere Dienste, z.B. Adguard Home, jeweils als eigener Container in Proxmox.
  • Alle Dienste haben eine feste lokale IP, sowohl client-seitig festgelegt, als auch in der FritzBox
  • Die Internetverbindung wird jede Nacht zwischen 3 und 4 Uhr kurz getrennt → neue WAN-IP. Dies habe ich bewusst so eingestellt, damit ich den Zeitpunkt kenne, wann die WAN-IP wechselt.

Ich verfüge über eine eigene Domain bei netcup. Die dortigen DNS-Einträge ändere ich jede Nacht um 4:05 mit einem cron-job. Dort wird dann die neue WAN-IP eingetragen. So betreibe ich sozusagen mein eigenes Dyndns.

Im Nginx habe ich ein wildcard-Zertifikat über Let’s Encrypt erstellt. Dieses ist also ausgestellt auf *.domain.de und kann für alle entsprechenden Subdomains verwendet werden. Ich gehe da für meine Geräte, die ich von extern erreichen will, nach diesem Namensschema vor:

https://dienst.gerät.domain.de

Dieses Konstrukt funktioniert fast zuverlässig - fast, denn NUR mit Homeassistant klappt es nicht… erst nach ein paar Stunden ist die Oberfläche von außen zu erreichen.

Andere Dienste sind kurz nach IP-Update und DNS-Update von außen erreichbar. Intern, über die LAN-IP, ist HomeAssistant immer erreichbar, es geht nur morgens bis mittags von extern über die domain nicht.

Ich bin da etwas ratlos, denn die üblichen Tipps die man so findet, wenn etwas mit dem externen Zugriff und Nginx nicht klappt, funktionieren nicht bzw. habe ich eh schon angewendet.

  • Websockets sind in Nginx aktiviert
  • Das SSL-Zertifikat ist genutzt und “Force SSL” ist auch aktiv

Wenn ich morgens oder Mittags auf mein Home Assistant via URL zugreifen möchte, erscheint nur der bekannte Ladebildschirm:

image
image629×1143 14 KB

Übrigens ist es mit der App auf dem Smartphone genau so.

Da es NUR mit Home-Assistant nicht richtig gut klappt, vermute ich dort ein Konfigurationsproblem, aber ausschließen kann ich nichts.

Also frage ich nun hier. Hat jemand eine Idee, wo ich noch suchen kann oder was ich probieren kann?

Vorab schonmal danke für’s Lesen - ist ja doch länger geworden.
Viele Grüße

2

Ich habe zur weiteren Ursachenforschung einmal einen Cloudflare Zugang über meine Domain eingerichtet, also einen CF-Tunnel angelegt, die Nameserver meiner Domain auf Cloudflare umgebogen und in HA das Addon installiert.
Wie erwartet klappt das “leider” ohne Probleme. Darüber ist auch mein HomeAssistant jederzeit von außen zu erreichen, sowohl über den Browser als auch über die App.
Es klappt “leider”, weil ich gehofft hatte, dass ich ggf. ein paar Ursachen ausschließen kann, wenn hier auch Probleme auftauchen, wie eine gelegentliche Nicht-erreichbarkeit.
Aus meiner Sicht gibt es jetzt noch zwei weitere Dinge die ich ausprobieren kann.

  • Bekanntes Konstrukt (siehe oben) aber mit Reconnect zu einem anderen Zeitpunkt, z.B. 10 Uhr morgens. Ich könnte kurz davor prüfen, ob HA erreichbar ist. Wenn nach dem reconnect und dem Update der DNS Einträge HA unerreichbar ist, alle anderen von außen erreichbaren Dienste schon, hat es irgend etwas mit dem Wechsel der IP zu tun.
  • DuckDNS anstelle meines eigenen DynDNS Konstrukts. Zunächst würde ich HA nur über die DuckDNS Domain ansprechen. Wenn das zuverlässig geht, gehe ich einen Schritt weiter mit einem CNAME Eintrag für meine Netcup Domain.

Ich halte euch auf dem Laufenden.

Viele Grüße

3

Hast Du mal eine DNS Abfrage gemacht, welche IP aufgerufen werden soll, wenn es gerade umgestellt ist und nicht funktioniert?

Ich hätte hier primär den DNS Cache im Verdacht. Und das ist unabhängig von HA.

1 „Gefällt mir“
4

Möglicherweise ist der TTL (TimeToLife) Wert für deinen DNS-Eintrag zu hoch. Normalerweise ändert sich eine IP nicht so oft, also wird der TTL auf Stunden oder einen Tag gesetzt. Bei dynamischen Adressen ist das natürlich Käse.

Wieso trennst du deine Verbindung überhaupt vorsorglich? Gibt es auch im 3ten Jahrtausend noch Provider die jede Nacht die Leitung kappen?

1 „Gefällt mir“
5

Wenige Minuten nach der Neu-Verbindung ist die neue WAN-IP auf meine domain gemapped. Das Prüfe ich mit https://www.whatsmydns.net/
Eine 24h Zwangstrennung wird von der Telekom zwar nicht durchgeführt, aber manchmal wird eben doch getrennt. Dann kontrolliere ich lieber den Zeitpunkt. Leider kann man etwa auf der Fritzbox nur eine Trennung alle 24 Stunden (und nicht etwa alle 14 Tage) einstellen.
Wie lange es dauert, bis spätestens von Anbieterseite die Zwangstrennung erfolgt, habe ich aber tatsächlich noch nicht ausprobiert.

Wo sehe ich denn, welche IP im DNS-Cache hinterlegt ist bzw. wie leere ich den aktiv oder automatisch?
TTL aber auch Cache dürften aber auch dafür sorgen, dass andere Dienste zunächst nicht erreichbar sind oder? Die sind jedoch ansprechbar.

6

Du kannst Deinen DNS abfragen oder schlicht einen Ping auf die Domain senden und schauen, auf welche IP das Ganze auflöst.

7

Da deine anderen Services, so wie du schreibst, von außen erreichbar sind, würde ich zumindest die externe DNS-Auflösung ausschließen. Wie leitest du denn im NGINX auf den HA weiter, über die IP oder über den Hostname?

8

Ich leite an die statisch vergebene IP von HA weiter.

Beim ping auf die domain und subdomain antwortet meine WAN-IP. Das funktioniert also.

Ich habe inwzischen die Cloudflare Lösung zurückgebaut, weil ich trotz korrekter Nameserver und MX-Einträge irgendwann keine E-Mails mehr empfangen konnte. Anfangs hat das funktioniert. Ist blöd, wenn das irgendwann, ohne dass ich etwas geändert habe, nicht mehr geht. Merkt man ja auch nicht sofort. Jetzt bin ich wieder bei meiner eigenen Lösung, dem cron job und dem DNS update via API - mit den alten Problemen…

9

Hast Du grundlegende Dinge wie die TTL, die hier mehrfach angesprochen wurde, mal geprüft?

Du erzählst, was alles nicht funktioniert. Auf konkrete Fragen zur Lösungsfindung gehst Du aber nicht ein.

Außerdem ist es übrigens unsinnig, täglich die Verbindung selbst zu trennen, wenn dies sonst nicht passieren würde.
Eine Prüfung, ob die aktuelle IP noch korrekt ist, wäre deutlich sinnvoller.

10

Die TTL liegt bei 300.

Ping auf die Domain löst eine Antwort von meiner aktuell gültigen WAN IP aus (habe ich oben geschrieben).

Gefragt wurde auch ob ich auf den hostname oder ip umleite. Ich leite auf die IP um (habe ich oben geschrieben).

Aber ja du hast recht, es ist suboptimal, ständig zu trennen. Ich kannte zunächst aber keinen Weg, per API zu prüfen, ob die A bzw. AAAA Einträge noch zur aktuellen WAN IP passen. Daher hatte ich es bis gestern eben so gelöst wie oben beschrieben.

Aber ich habe kürzlich ein Skript gefunden, dass mittels der API zuerst prüft, ob die DNS Einträge noch aktuell sind. Damit kann ich den cron job etwa alle 5 Minuten ausführen und die tägliche Trennung meinerseits deaktivieren.

Theoretisch sollte sich das Problem damit erheblich minimieren und nur dann auftreten, wenn dann mal von Seiten der Telekom eine Trennung und Neuverbindung mit dann neuer WAN IP erfolgt.

Danke für die bisherige Hilfestellung. Ich werde mal berichten, wie es von nun an läuft.

11

Per Uptime Robot zu prüfen, ob noch extern erreichbar, wäre eine einfache Möglichkeit gewesen. :wink:

Dass E-Mails auf einer dynamischen IP-Adresse Probleme bereiten, finde ich im Übrigen nicht verwunderlich. Bei ausgehenden E-Mails würde mich eher wundern, wenn die Spamfilter diese nicht direkt ablehnen.

12

Ich betreibe nicht meinen Eigenen Mailserver. Ich habe meine E-Mails bei Netcup und bin eben unter mail@domain.de erreichbar. Beim Umbiegen der Nameserver auf Cloudflare müssen dort dann die entsprechenden MX-Einträge gemacht werden. Das hat anfangs funktioniert und irgendwann nicht mehr.

13

Dann ist es aber ein DNS Problem bzw. Problem mit falschen Einstellungen. :wink: