cfgmon: IPv6-Freigabe geprueft, Risiko praezisiert

Die Inbound-Regel fuer TCP 443 in der Hetzner-Cloud-Firewall enthaelt
laut Console beide Eintraege, 0.0.0.0/0 und ::/0. Der vermutete
IPv6-Fallstrick besteht also nicht.

Quelle ist ausdruecklich die Console, keine Messung: vom Host aus ist
die Cloud-Firewall unsichtbar, es gibt keinen zweiten Host fuer eine
Rueckverbindung und Traefik laeuft ohne Access-Log. Ebenso festgehalten,
dass die Ausstellung vom 30.07. um 12:00 UTC nichts ueber IPv6 aussagt --
zu dem Zeitpunkt hatte selendis noch keinen AAAA-Record.

Damit bleibt als Risiko nur, ob die Ports bis zur Erneuerung offen
bleiben; der Normalzustand ist hier eingeschraenkt. Option A um einen
Kalendereintrag auf Mitte September ergaenzt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Thore Cimbal
2026-07-30 12:00:00 +00:00
co-authored by Claude Opus 5
parent 8e98a39447
commit a5eacfe39e
+30 -13
View File
@@ -58,23 +58,40 @@ Eine IP-Allowlist ist **keine** Option: Let's Encrypt veröffentlicht seine
Validierungs-IPs nicht und prüft seit Einführung der Multi-Perspective Validation
aus mehreren Regionen gleichzeitig.
**IPv6 ist der Fallstrick.** `rohana`, `selendis` (und noch `www.*`, siehe
[ZONE-01](../shared/zone-axion1337.md)) haben AAAA-Records auf
`2a01:4f8:c17:93eb::1`. Damit validiert LE **bevorzugt über IPv6**. Die
Hetzner-Cloud-Firewall braucht für 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.
**IPv6 war der vermutete Fallstrick — geprüft und in Ordnung.** `rohana`, `selendis`
(und noch `www.*`, siehe [ZONE-01](../shared/zone-axion1337.md)) haben AAAA-Records
auf `2a01:4f8:c17:93eb::1`. Damit validiert LE **bevorzugt über IPv6**. Die
Hetzner-Cloud-Firewall kennt kein familienübergreifendes „any": das Feld *Source IPs*
ist eine Liste, `0.0.0.0/0` deckt IPv6 **nicht** mit ab, `::/0` muss separat drinstehen.
Vom Host aus ist das **nicht verifizierbar**: eine Verbindung auf die eigene
öffentliche Adresse läuft lokal und sagt nichts über den Weg von außen. Das
Ausliefern über IPv6 funktioniert (`rohana` und `selendis` antworten mit 200,
Traefik lauscht auf `[::]:443`) — das ist aber nicht dasselbe wie von außen
erreichbar.
Stand 2026-07-30 enthält die Inbound-Regel für TCP 443 **beide** Einträge — vom User
in der Hetzner-Console nachgesehen. Damit ist der IPv6-Pfad frei.
Diese Angabe stammt **nicht** aus einer Messung von diesem Host aus, sondern aus der
Console. Vom Host ist es nicht verifizierbar: die Cloud-Firewall liegt außerhalb des
Systems, `iptables` und `ufw` sagen nichts darüber (und Root gibt es hier nicht), eine
Verbindung auf die eigene öffentliche Adresse läuft lokal, es gibt keinen zweiten Host
für eine Rückverbindung, und Traefik läuft ohne Access-Log — es existieren also auch
keine historischen Client-IPs. Für eine Prüfung von hier aus wäre ein
Hetzner-API-Token mit Read-Berechtigung nötig.
Auch die erfolgreiche Ausstellung vom 2026-07-30 um 12:00 UTC belegt IPv6 **nicht**:
zu dem Zeitpunkt existierte für `selendis` noch kein AAAA-Record, LE hat also über
IPv4 validiert. Die Erneuerung Ende September ist der erste Lauf, der IPv6 überhaupt
versucht.
**Damit bleibt als Risiko nur, ob die Ports offen bleiben.** Sie wurden am
2026-07-30 für die Ausstellung geöffnet; der Normalzustand dieser Umgebung ist, 80
und 443 aus Sicherheitsvorsicht auf die eigene IP zu beschränken. Werden sie wieder
zugezogen, scheitert die Erneuerung Ende September genau wie heute Mittag — und zwar
still.
**Nächster Schritt:** Entscheidung zwischen
- **A — Port 443 zur Erneuerung öffnen**, für IPv4 *und* IPv6. Nichts umbauen, aber
alle ~60 Tage daran denken, und das Scheitern fällt nicht auf.
- **A — Ports offen lassen** bzw. zur Erneuerung wieder öffnen. Nichts umzubauen,
aber alle ~60 Tage daran zu denken, und ein Fehlschlag fällt erst auf, wenn jemand
die Seite aufruft. Wenn A, dann mit einem Kalendereintrag auf **Mitte September**,
nicht auf das Ablaufdatum.
- **B — auf DNS-01 umstellen** (empfohlen). Validierung über einen TXT-Record,
**kein offener Port nötig**, läuft bei dichter Firewall durch. Braucht ein
API-Token für die Zone bei IONOS, als Secret für Traefik hinterlegt. Ermöglicht