Thore CimbalandClaude Fable 5
92b448fe30
Gate 4, slice 3: verfahren/, hosts/, vision/ and shared/ moved via git mv - six AARs to docs/aar/ (four harvested by the 2026-08-09 retro, two open), procedures and host knowledge to docs/wiki/ (admin, deployment, architecture, new area vision), the retro protocol and the commit mapping table to docs/sources/ (protokolle/, migration/). New: the wiki index linking every page, and the mirror-topology page carrying the why-two-places reasoning verbatim from the old CLAUDE.md (F-013 preserved). All moved-path references retargeted; the link checker drove the sweep to zero. pruefe_prosa.py added (pattern C+D): SHA citations resolve via repo, mapping table, optional component clones or a curated exemption list (documented dead Gitea-force-push commits, a vendor-repo tag, an Authentik uid that is hex but no git SHA, the external neckbeard reference); wiki task prose without an issue reference errors, with a visible pragma for deliberate checklists; the dead-tracker denylist now covers every mirrored repo's retired Gitea tracker (F-005) - two links re-verified against live GitLab titles and retargeted, five defused into honest historical citations. Verified: validate 0/0, gen_status --check current, drift 0. Demo on the pre-migration state fires 6 findings (3 orphaned SHAs, 3 task blocks); on the current tree exactly the 3 F-004 task blocks remain - they turn green in slice 4 when the issues exist, which is why pruefe_prosa joins CI only then. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
7.5 KiB
type, area, related
| type | area | related |
|---|---|---|
| wiki-page | architecture |
Lab-Netzwerk (Heimnetz: Fritzbox + UDM Pro)
Themen rund um das Homelab-Netz selbst — Router-Kaskade, VLANs, VPN-Zugänge. Hosts im Lab: Overmind (git.lab, hosts/overmind.md), der Mac. Kaskade: Fritzbox (WAN) → UDM Pro, kein Doppel-NAT, statische Route in der Fritzbox für das Lab-VLAN.
✅ Das VPN-Thema ist abgeschlossen und validiert (sorb, 2026-08-02). Beide Zugänge laufen und sind abgenommen, ADR-0004 steht auf akzeptiert (Testreihe 1–7 in #12). Es gibt dazu keine offenen Issues mehr — auch die Restpunkte #11 (MacBook-Profil) und #16 (LABNET-04, Feinschliff an den UniFi-Regeln) sind geschlossen. Alles Folgende ist Bestand und Historie, keine offene Arbeit.
Zwei WireGuard-Zugänge (Stand 2026-08-01, beide gelöst/abgenommen):
| Zugang | Server | Port | Tunnelnetz | Zweck |
|---|---|---|---|---|
| Roadwarrior „Thore" | UDM | 51840 | 10.58.74.0/24 | Handy/MacBook ins Lab (LABNET-01) |
| Site-to-Site „Matrix" | UDM | 51841 | 10.58.75.0/24 | Hetzner-Netz 10.0.0.0/24 ↔ Lab (LABNET-02, ADR-0004) |
Verhältnis zu homelab/docs
Die Tabelle oben steht absichtlich doppelt. Maßgeblich für die Soll-Konfiguration ist homelab/docs → MorninglightMountain (dort auch Portfreigaben, Firewall-Zonen, Diagnose-Merksätze) — dieses Repo führt die Historie: was wann warum geändert wurde und mit welchem Issue.
Der Grund für die Doppelung ist der Mirror-Geltungsbereich aus der
CLAUDE.md: Die Gruppe homelab hat bewusst keine Mirrors und
ist von außerhalb des Labs nicht lesbar. Wer ohne Tunnel nachsehen muss, welcher
Tunnel überhaupt auf welchem Port liegt, findet es nur hier. Deshalb hält dieses
Dokument einen Kurzüberblick vor — Ports, Tunnelnetze, Zweck — und nichts
darüber hinaus. Bei Widerspruch gilt homelab/docs.
LABNET-01 — WireGuard-Roadwarrior ins Lab kaputt (seit einigen Monaten)
Status: GELÖST 2026-08-01 ~15:20 — git.lab lädt vom Handy über 5G/VPN. ✅
Damit ist die Cutover-Voraussetzung für gitops#48 erfüllt.
Drei gestapelte Ursachen (jede verdeckte die nächste):
- Privater Endpunkt in jeder UDM-generierten Client-Config (UDM kennt hinter
der Fritzbox ihre öffentliche IP nicht) → Fix: Endpunkt
178.25.213.70; dauerhaft gelöst über UniFi-Option „Alternate Address for Clients". - FritzOS reserviert UDP 51820 für seinen eigenen WireGuard-Stack — die Portfreigabe 51820→UDM lief ins Leere (erklärt die „invalid response"-Stürme im Juli: zwei WG-Stacks auf einem Port) → Fix: UDM-WG auf 51840.
- Docker-Routen-Kollision auf Overmind: Dokploys Bridge-Netze belegen zehn
/20-Blöcke in 192.168.0.0/16;
192.168.0.0/20verschluckte das VPN-Subnetz 192.168.5.0/24 → Antworten an VPN-Clients endeten in der Bridge (SYN kam an, SYN-ACK verschwand — exakt der Chrome-Connection-Timeout, während Ping/DNS/ fremde Hosts funktionierten) → Fix: VPN-Subnetz auf 10.58.74.0/24 (Docker fasst 10.x nie an).
Restarbeiten: MacBook-WG-Profil → Issue #11. ⚠️ Latente Wiederholungsgefahr
notiert: Overminds Docker-Pool deckt auch 192.168.176.0/20 ab = kollidiert mit
dem Fritzbox-Netz 192.168.178.x — aktuell folgenlos, aber bei künftigen Subnetz-
Entscheidungen 192.168.x auf Overmind grundsätzlich meiden (oder Docker
default-address-pools begrenzen).
Bestätigte Ursachenkette (Diagnose-Session 2026-08-01):
- Handy-Profil „@home" hatte seit 07.07. die private UDM-WAN-IP (192.168.178.20) als Endpunkt — die UDM kennt hinter der Fritzbox ihre öffentliche IP nicht und schreibt sie in jede generierte Config (⚠️ gilt für ALLE künftig exportierten Profile: Endpunkt manuell auf 178.25.213.70 ändern!).
- Nach Endpunkt-Fix weiter tot: FritzOS reserviert UDP 51820 für seinen EIGENEN WireGuard-Stack — die alte Portfreigabe 51820→UDM lief ins Leere (erklärt auch die „invalid response"-Stürme im Juli: zwei WG-Stacks auf einem Port). Fix: UDM-WG auf 51840 umgezogen + Freigabe angepasst.
- Server + Schlüssel waren nie das Problem (WLAN-Handshake bewies beides).
Danach nur noch der ursprüngliche Blocker-Vermerk: blockierte gitops#48 (Erreichbarkeits-Entscheidung „WireGuard statt exponieren")
sorb hatte einen funktionierenden VPN-Zugang fürs Handy ins Lab; seit einigen Monaten „funktioniert das nicht mehr sauber" (Symptome noch zu präzisieren: Handshake? Routing nur teilweise? DNS?). Setup-Rahmen laut sorb (2026-08-01): UDM Pro hinter Fritzbox, ohne doppeltes NAT, statische Route in der Fritzbox für das VLAN.
Diagnose-Plan von VOR der Lösung — ⚠️ abgearbeitet und überholt, steht hier nur als Beleg, wie die Ursachen eingekreist wurden. Nichts davon ist zu tun:
- Symptom präzisieren: Handshake kommt zustande? (
wg showauf der UDM / Client-Log) — trennt Portweiterleitungs- von Routing-Problemen - Fritzbox: Portfreigabe UDP (WireGuard-Port) → UDM noch vorhanden/korrekt? (FritzOS-Updates werfen gern Freigaben/Exposed-Host-Einstellungen um)
DS-Liteausgeschlossen (sorb 2026-08-01: Dualstack + feste IPs) — damit auch kein DynDNS-Drift möglich. Verdacht konzentriert sich auf: FritzOS-Update warf die UDP-Portfreigabe um, UniFi-OS-Update veränderte WG-Server/Firewall, oder die statische Route griff nach Änderung nicht mehr.- (entfällt — feste IP)
- UDM-Seite: WireGuard-Server-Config/Firewall-Regeln nach UniFi-OS-Updates prüfen; statische Route Fritzbox → VLAN gegenchecken
- Erst wenn 1–5 sauber: Client-Profil fürs Handy neu ausstellen, git.lab-DNS (Lab-Resolver) in die AllowedIPs/DNS-Konfig aufnehmen — Erfolgsbeweis = Issue-Board vom Handy über VPN erreichbar
Verwandt: gitops#48 (Cutover erst nach Lösung), perspektivisch ersetzt ein funktionierender Roadwarrior auch Ad-hoc-Wünsche wie „GitLab exponieren".
Zugehörige Issues — alle geschlossen
Seit dem Framework-Umbau (2026-08-01) leben offene Punkte als Issues im management-Projekt; die IDs bleiben in den Issue-Titeln erhalten. Dieses File hält nur noch Bestand und Historie.
Zum Netz/VPN ist nichts mehr offen (Stand 2026-08-02):
| Issue | Thema | Stand |
|---|---|---|
| #11 | LABNET-01-Rest — MacBook-WireGuard-Profil | geschlossen |
| #12 | LABNET-02 — Site-to-Site-VPN (Design: ADR-0004) | geschlossen, Testreihe 1–7 protokolliert |
| #16 | LABNET-04 — Feinschliff UniFi-Regeln | geschlossen |
Zwei Punkte tragen zwar LABNET im Text, gehören aber nicht zum VPN-Thema und bleiben offen: #13 (LABNET-03, Rückbau der Gitea-Ausnahme für Übergabe-Issues — durch den Tunnel erst möglich geworden, aber eine Repo-Frage) und #15 (CFGMON-15, Widerruf der Einmal-Tokens aus der LABNET-02-Nacht — Credential-Hygiene, und der Widerruf kann still einen Push-Mirror brechen, solange dessen hinterlegtes Token unbekannt ist).