Thore CimbalandClaude Fable 5
fdf30d42e1
- decisions/: ADR-Verzeichnis mit Template + 0001-0005 (git.lab-Kanonik, Lab-Cutover, CVE-Meldeweg, Site-to-Site-VPN-Design, Framework-Wahl) - vision/: je eine Vision fuer Community/Tool/Plattform (Entwuerfe) - roadmap.md: Linien, Meilenstein-Kandidaten, Kadenz - hosts/+shared/: offene Punkte -> Issues #1-#12 im management-Projekt (IDs bleiben in den Titeln), Dateien halten Bestand + Historie - README: Framework, Board/status-Labels (WIP-Limit 2), Topologie Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
4.8 KiB
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.
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 (gemeinsame Session, braucht Zugriff auf beide Router-UIs):
- 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".
Offene Punkte → git.lab-Issues
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.