Thore CimbalandClaude Fable 5
164d96dddd
sorb hat das VPN-Thema am 2026-08-02 fuer abgeschlossen und validiert erklaert. Das Dokument trug das nicht: Es listete unten 'Offene Punkte' mit #11 und #12, und der abgearbeitete Diagnose-Plan von LABNET-01 stand ohne Kennzeichnung mitten im Text, als waere er noch zu tun. - Banner oben: abgeschlossen und validiert, keine offenen Issues, alles Folgende ist Bestand und Historie - Die Abschnittsueberschrift 'Offene Punkte' war schlicht falsch - jetzt 'Zugehoerige Issues - alle geschlossen', mit Tabelle statt Liste - Der Diagnose-Plan bekommt einen Warnhinweis: abgearbeitet und ueberholt, steht nur als Beleg der Ursachensuche da Abgegrenzt: #13 (LABNET-03) und #15 (CFGMON-15) tragen LABNET im Text, gehoeren aber nicht zum VPN-Thema und bleiben offen - der eine ist der Rueckbau der Gitea-Ausnahme, der andere Credential-Hygiene, bei der ein Widerruf still einen Push-Mirror brechen kann. Beides steht jetzt ausdruecklich da, damit die Abnahme nicht faelschlich auch diese beiden mit einschliesst. Issues #11 und #16 sind mit Begruendung geschlossen. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
7.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.
✅ 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).