From b067c9367739ed4e8a7803806f721ea4dacc92bf Mon Sep 17 00:00:00 2001 From: Claude Date: Thu, 30 Jul 2026 14:37:38 +0200 Subject: [PATCH] BACKLOG.md: auf zentrales Backlogs-Repo verweisen Die offenen Punkte betreffen inzwischen mehrere Hosts, dieses Repo beschreibt aber einen Stack auf einem Host. Inhalte sind nach sorb/Backlogs umgezogen und dort pro Host strukturiert; hier bleibt nur der Verweis, damit die Liste nicht an zwei Stellen auseinanderlaeuft. Die Historie der urspruenglichen Eintraege bleibt bis 25bb5dd erhalten. Co-Authored-By: Claude Opus 5 --- BACKLOG.md | 216 ++++------------------------------------------------- 1 file changed, 14 insertions(+), 202 deletions(-) diff --git a/BACKLOG.md b/BACKLOG.md index 50700ed..0a7b804 100644 --- a/BACKLOG.md +++ b/BACKLOG.md @@ -1,209 +1,21 @@ # Backlog -Offene Punkte, die bewusst nicht sofort erledigt wurden. Stand: 2026-07-30. +Umgezogen. Offene Punkte werden zentral über alle Hosts hinweg geführt: ---- +**→ [sorb/Backlogs](https://rohana.axion1337.de/sorb/Backlogs)** -## 1. Zertifikatserneuerung braucht offene Ports — oder Umstellung auf DNS-01 +Für den Monitoring-Stack in diesem Repo relevant: -**Status:** offen, zeitkritisch ab ca. **2026-09-28** +- [hosts/cfgmon.md](https://rohana.axion1337.de/sorb/Backlogs/src/branch/main/hosts/cfgmon.md) + — Zertifikatserneuerung, nicht versionierter Portainer-Stack, offener + Remote-Write-Receiver, Grafana-API-Credentials +- [hosts/game.md](https://rohana.axion1337.de/sorb/Backlogs/src/branch/main/hosts/game.md) + — die beiden down-Targets auf `157.90.155.206` +- [shared/zone-axion1337.md](https://rohana.axion1337.de/sorb/Backlogs/src/branch/main/shared/zone-axion1337.md) + — DNS-Zone und Mail-Policy -Das Cert für `selendis.axion1337.de` wurde am 2026-07-30 ausgestellt und läuft am -**2026-10-28** ab. Traefik erneuert automatisch ca. 30 Tage vorher, also ab -**Ende September 2026**. +Der Grund für den Umzug: dieses Repo beschreibt einen Stack auf einem Host, die +offenen Punkte betreffen inzwischen mehrere. Ein Backlog an zwei Stellen läuft +auseinander, deshalb hier nur der Verweis und keine eigene Liste. -Traefik ist auf TLS-ALPN-01 konfiguriert -(`--certificatesresolvers.letsencrypt.acme.tlschallenge=true`). Diese Challenge -läuft ausschließlich über **Port 443, erreichbar aus dem offenen Internet**. Ist -der Port zu diesem Zeitpunkt in der Hetzner-Cloud-Firewall gesperrt, scheitert die -Erneuerung still mit: - -``` -urn:ietf:params:acme:error:connection :: Timeout during connect (likely firewall problem) -``` - -Traefik liefert dann sein Default-Self-Signed-Cert aus — Browser und `curl` brechen -mit Zertifikatsfehler ab. **Das betrifft auch Gitea** (`rohana.axion1337.de`, -Cert im selben Resolver), also die Erreichbarkeit dieses Repos per HTTPS. - -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 -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: - -- **A — Port 443 zur Erneuerung öffnen.** Nichts umbauen, aber alle ~60 Tage - daran denken. Fehleranfällig, weil das Scheitern nicht auffällt, bis jemand die - Seite aufruft. -- **B — auf DNS-01 umstellen** (empfohlen). Validierung über einen TXT-Record, - **kein offener Port nötig**, Erneuerung läuft bei komplett dichter Firewall - durch. Voraussetzung: API-Token des DNS-Providers für `axion1337.de`, hinterlegt - als Secret für Traefik. Ermöglicht zusätzlich Wildcard-Certs - (`*.axion1337.de`), was künftige Subdomains ohne Portöffnung abdeckt. - -**Nächster Schritt:** Entscheidung A oder B. Bei B: DNS-Provider benennen und -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. Siehe Punkt 3 für die -vollständige DNS-Bereinigung. - ---- - -## 3. DNS-Bereinigung bei IONOS - -**Status:** `rohana` und `selendis` werden vom User direkt umgesetzt (2026-07-30), -`game` / `matrix` / `ftp` / Apex noch offen - -Die Zone liegt bei IONOS (`ns10xx.ui-dns.*`), Zonentransfer ist verweigert — die -Records unten stammen aus gezielten Abfragen und der IONOS-Oberfläche, die Liste -ist daher **nicht garantiert vollständig**. Für eine vollständige Prüfung entweder -die ungefilterte IONOS-Liste durchgehen oder die Certificate-Transparency-Logs -abfragen. - -IONOS legt beim Anlegen einer Subdomain automatisch einen kompletten Mail-Satz mit -an (MX, SPF, DKIM-CNAMEs, `autodiscover`) und ein `www.`-Paar — auch für Hosts, auf -denen nie Mail läuft. Bei `selendis` und `matrix` ist das passiert, bei `rohana` und -`game` nur das `www.`-Paar. - -### Warum nicht einfach löschen - -Ersatzloses Entfernen der Mail-Records ist die schlechtere Variante: - -- Ohne SPF existiert **keine** Aussage darüber, wer als dieser Name senden darf. - Das bestehende `~all` ist nur Softfail und wird von vielen Empfängern - akzeptiert — eine ungenutzte Subdomain mit gültigen MX und Softfail-SPF ist ein - brauchbarer Spoofing-Vektor. -- **Fehlt ein MX-Record, weichen Absender per RFC 5321 auf A/AAAA aus.** Mail an - `@rohana.axion1337.de` würde also Port 25 auf `188.245.193.243` ansprechen. - -Richtig ist daher, „hier gibt es keine Mail" explizit zu erklären: Null-MX -(RFC 7505), SPF `-all`, DMARC `p=reject`. - -### rohana.axion1337.de - -Löschen: `A www.rohana`, `AAAA www.rohana` - -Anlegen: - -| Typ | Name | Wert | -|---|---|---| -| MX | `rohana` | `.` (Priorität 0) | -| TXT | `rohana` | `v=spf1 -all` | -| TXT | `_dmarc.rohana` | `v=DMARC1; p=reject;` | - -Nicht anfassen: `A rohana`, `AAAA rohana` — daran hängen Gitea und das Zertifikat. - -### selendis.axion1337.de - -Löschen: `MX mx00.ionos.de`, `MX mx01.ionos.de`, -`CNAME s1-ionos._domainkey.selendis`, `CNAME s2-ionos._domainkey.selendis`, -`CNAME s42582890._domainkey.selendis`, `CNAME autodiscover.selendis`, -`A www.selendis`, `AAAA www.selendis` - -Ändern — **den bestehenden TXT editieren, nicht einen zweiten anlegen** (zwei -SPF-Records auf einem Namen ergeben einen PermError, die Prüfung fällt komplett -aus): `v=spf1 include:_spf-eu.ionos.com ~all` → `v=spf1 -all` - -Anlegen: `MX selendis` = `.` (Priorität 0), `TXT _dmarc.selendis` = -`v=DMARC1; p=reject;` - -Nicht anfassen: `A selendis`, `AAAA selendis`. - -Vorab prüfen: ob im IONOS-Mail-Bereich ein Postfach oder eine Weiterleitung für -`selendis.axion1337.de` existiert. Wenn ja, entfallen die MX-Änderungen. - -Falls die IONOS-Oberfläche `.` als MX-Ziel ablehnt: MX löschen und nur die TXT- -Records setzen. `-all` und `p=reject;` greifen trotzdem. - -### Noch offen - -- **`www.game`, `www.matrix`** (A-Records): dasselbe überflüssige Muster, aber auf - fremden Hosts — nicht verifiziert, ob dort etwas darauf hört. -- **`matrix.axion1337.de`**: gleicher Mail-Satz wie `selendis`, aber **erst prüfen**, - ob der Matrix-Server Benachrichtigungsmails mit Absender - `…@matrix.axion1337.de` verschickt. Wenn ja, müssen SPF und DKIM dort bleiben und - auf den echten Absender zeigen. `autodiscover.matrix` kann in jedem Fall weg — - Matrix-Föderation läuft über `.well-known` bzw. SRV. -- **`ftp.axion1337.de`** → `217.160.233.227`: IONOS-Default aus dem Hosting-Paket, - zeigt auf IONOS und nicht auf eigene Infrastruktur. Löschen, falls dort kein FTP - genutzt wird. -- **Apex-DMARC ist `v=DMARC1; p=none;`** — reines Monitoring, kein Schutz. Ohne - `sp=`-Angabe erben alle Subdomains dieses `p=none`. `sp=reject` am Apex wäre der - effiziente Hebel für alle Subdomains inklusive künftiger, **aber erst nach** - Klärung von `matrix`, sonst bricht dessen Mailversand. -- **`game.axion1337.de` ist `157.90.155.206`** — derselbe Host wie in Punkt 2, den - Prometheus per roher IP scrapt. Der Name wäre die wartbarere Variante. - ---- - -## 2. Pterodactyl-Host 157.90.155.206 nicht erreichbar — 2 Prometheus-Targets down - -**Status:** offen, Ursache liegt außerhalb dieses Hosts - -Zwei Scrape-Targets sind seit Längerem down — bereits vor dem Monitoring-Rework, -also **kein Regressionsschaden** aus der Umstellung: - -| Job | Target | Fehler | -|---|---|---| -| `gameserver_cadvisor` | `157.90.155.206:8080` | `context deadline exceeded` | -| `pterodactyl_host_node` | `157.90.155.206:9100` | `context deadline exceeded` | - -Der Host antwortet von `188.245.193.243` aus **nicht auf Ping** (100 % packet -loss) und auf keinem der beiden Ports. Das Problem ist also nicht die -Prometheus-Konfiguration, sondern die Erreichbarkeit des Zielhosts. Mögliche -Ursachen, von wahrscheinlich nach unwahrscheinlich: - -1. Hetzner-Cloud-Firewall des Pterodactyl-Hosts lässt `188.245.193.243` nicht auf - 8080/9100 — passend zum restriktiven Firewall-Setup. -2. cAdvisor und node-exporter laufen dort nicht (mehr) bzw. binden nur auf - `127.0.0.1`. -3. Host ist abgeschaltet oder umgezogen (IP veraltet). - -**Nächster Schritt:** auf dem Pterodactyl-Host prüfen, ob die beiden Exporter -laufen und worauf sie binden, und die Firewall dort für `188.245.193.243` auf -8080/9100 öffnen. Idealerweise nicht öffentlich, sondern über das private Netz — -dieser Host hat `10.0.0.3/32` auf `enp7s0`; wenn der Pterodactyl-Host im selben -Hetzner-vSwitch liegt, sollte über die privaten IPs gescrapt werden statt über -die öffentlichen. Dann sind dafür gar keine offenen Ports im Internet nötig. - -Solange offen: die beiden Targets in Grafana/Alertmanager als *known down* -behandeln, damit sie kein Dauer-Alerting erzeugen. - ---- - -## Weitere Beobachtungen (nicht beauftragt, aber notiert) - -- **Prometheus Port 9090 ist öffentlich und ohne Auth erreichbar.** Nötig, weil - k3s-Cluster und Matrix-Server per `--web.enable-remote-write-receiver` dorthin - pushen. Ein offener Remote-Write-Receiver erlaubt Fremden aber das - **Einspeisen beliebiger Metriken** und das Auslesen aller Daten. Sollte per - Hetzner-Cloud-Firewall auf die Absender-IPs beschränkt werden — der Hinweis - steht als Kommentar in `monitoring/docker-compose.yml`, ist aber noch nicht - umgesetzt. Gleiches gilt für **Loki auf 3100**. -- **Grafana-Admin-Credentials aus `.env` greifen nicht für die HTTP-API.** Der - Live-Admin wurde offenbar irgendwann in der UI geändert; `GF_SECURITY_ADMIN_*` - wirkt nur beim allerersten Start mit leerem Volume. Verifikation läuft deshalb - über `grafana.db` statt über die API. Kein Defekt, aber bei künftigen Checks - wissen. +Die Historie der ursprünglichen Einträge steht in diesem Repo bis Commit `25bb5dd`.