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:
co-authored by
Claude Opus 5
parent
8e98a39447
commit
a5eacfe39e
+30
-13
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user