BACKLOG.md: IPv6 und www.rohana ergaenzen
rohana, www.rohana und selendis haben jetzt AAAA-Records auf 2a01:4f8:c17:93eb::1. Let's Encrypt validiert damit bevorzugt ueber IPv6, die Hetzner-Firewall braucht fuer 443 also eine Regel mit Quelle ::/0 zusaetzlich zu 0.0.0.0/0 -- sonst scheitert die Erneuerung Ende September trotz offenem IPv4. Ausliefern ueber IPv6 funktioniert bereits (rohana und selendis antworten mit 200, Traefik lauscht auf [::]:443). www.rohana matcht keinen Traefik-Router und liefert das Traefik-Default- Cert aus. Bei einer Subdomain ist das www.-Praefix ueberfluessig; Empfehlung ist Loeschen der beiden Records statt Router + Cert-SAN. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
+24
@@ -30,6 +30,14 @@ Eine IP-Allowlist für die Let's-Encrypt-Server ist **keine** Option: LE
|
|||||||
veröffentlicht seine Validierungs-IPs nicht und prüft seit Einführung der
|
veröffentlicht seine Validierungs-IPs nicht und prüft seit Einführung der
|
||||||
Multi-Perspective Validation aus mehreren Regionen gleichzeitig.
|
Multi-Perspective Validation aus mehreren Regionen gleichzeitig.
|
||||||
|
|
||||||
|
**IPv6 beachten (Stand 2026-07-30):** `rohana`, `www.rohana` und `selendis` haben
|
||||||
|
inzwischen AAAA-Records auf `2a01:4f8:c17:93eb::1`. Damit validiert Let's Encrypt
|
||||||
|
**bevorzugt über IPv6**. Die Hetzner-Cloud-Firewall braucht für Port 443 deshalb
|
||||||
|
eine Regel mit Quelle `::/0` — `0.0.0.0/0` deckt IPv6 **nicht** mit ab. Fehlt sie,
|
||||||
|
scheitert die Erneuerung, obwohl IPv4 offen ist. Vom Host aus lässt sich das nicht
|
||||||
|
verifizieren (Verbindung auf die eigene öffentliche Adresse läuft lokal), das muss
|
||||||
|
in der Hetzner-Konsole geprüft werden.
|
||||||
|
|
||||||
Zwei Wege:
|
Zwei Wege:
|
||||||
|
|
||||||
- **A — Port 443 zur Erneuerung öffnen.** Nichts umbauen, aber alle ~60 Tage
|
- **A — Port 443 zur Erneuerung öffnen.** Nichts umbauen, aber alle ~60 Tage
|
||||||
@@ -44,6 +52,22 @@ Zwei Wege:
|
|||||||
**Nächster Schritt:** Entscheidung A oder B. Bei B: DNS-Provider benennen und
|
**Nächster Schritt:** Entscheidung A oder B. Bei B: DNS-Provider benennen und
|
||||||
API-Token bereitstellen, dann Traefik-Resolver umstellen.
|
API-Token bereitstellen, dann Traefik-Resolver umstellen.
|
||||||
|
|
||||||
|
### Nebenpunkt: `www.rohana.axion1337.de` löschen
|
||||||
|
|
||||||
|
Der Record (A + AAAA) wurde nach IONOS-Default-Muster angelegt. Bei einer
|
||||||
|
Subdomain ist ein `www.`-Präfix überflüssig — das Muster gilt für Apex-Domains
|
||||||
|
(`axion1337.de` / `www.axion1337.de`, dort bei IONOS sinnvoll). `rohana` ist
|
||||||
|
bereits der Hostname des Dienstes.
|
||||||
|
|
||||||
|
Aktueller Zustand: kein Traefik-Router matcht den Namen, Traefik liefert sein
|
||||||
|
`TRAEFIK DEFAULT CERT` aus, TLS bricht mit Zertifikatsfehler ab. Der Name
|
||||||
|
funktioniert also ohnehin nicht.
|
||||||
|
|
||||||
|
**Empfehlung:** A- und AAAA-Record für `www.rohana` löschen. Es geht nichts
|
||||||
|
verloren. Die Alternative — Router plus Cert-SAN für den zweiten Namen — bedeutet
|
||||||
|
mehr Teile, die bei jeder Erneuerung mitvalidieren müssen, ohne Nutzen. Für
|
||||||
|
`selendis` aus demselben Grund kein `www.` anlegen.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 2. Pterodactyl-Host 157.90.155.206 nicht erreichbar — 2 Prometheus-Targets down
|
## 2. Pterodactyl-Host 157.90.155.206 nicht erreichbar — 2 Prometheus-Targets down
|
||||||
|
|||||||
Reference in New Issue
Block a user