Thore CimbalandClaude Fable 5
830c740a58
- ADR-0004: Status akzeptiert; real gebaute Architektur v2 dokumentiert (UniFi bietet kein WG-Site-to-Site -> UDM-Server + CFGMON als Client mit 'Networks Behind Client'), inkl. Messwerten aus dem Negativtest - AAR Lab-Seite: 5 Befunde, Eingrenzungsmethodik, 5 Lehren (u.a. 'Server'-Auswahl erfasst nur das Tunnel-Subnetz; Portbedingung gehoert in beide Portfelder) - README: Uebergabe-Issue-Ausnahme als auslaufend markiert - shared/lab-netzwerk.md: beide WG-Zugaenge tabellarisch Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
5.4 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.
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) |
Bestandsdoku (Soll-Konfiguration, Diagnose-Merksätze): homelab/docs → MorninglightMountain.
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.