Files
management/shared/lab-netzwerk.md
T
Thore CimbalandClaude Fable 5 70e81e2ff1 feat: slice 2 - all eleven decisions ported to docs/adr
Gate 4, slice 2: decisions/0001-0011 moved via git mv with schema
frontmatter prepended (status and date taken from each body's own
Status line - 0007 stays proposed, its decision is open in #20; bodies
unchanged except relative links gaining one directory level). The old
scheme's README and template retire - their rules already live in
AGENTS.md section 6 and the neckbeard ADR template. Every reference to
decisions/ across the tree retargeted (root files, not-yet-moved
verfahren/hosts/shared files, design doc and session ADR frontmatter).

Verified: validate 0 errors (11 ported + 2 session ADRs + duplicate-id
guard), gen_status --check current with all 13 ADRs listed, drift
check 0 findings, negative test shows a cloned id 0012 firing the
duplicate check.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-11 12:00:00 +00:00

7.4 KiB
Raw Blame History

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 17 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):

  1. 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".
  2. 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.
  3. Docker-Routen-Kollision auf Overmind: Dokploys Bridge-Netze belegen zehn /20-Blöcke in 192.168.0.0/16; 192.168.0.0/20 verschluckte 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):

  1. 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!).
  2. 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.
  3. 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:

  1. Symptom präzisieren: Handshake kommt zustande? (wg show auf der UDM / Client-Log) — trennt Portweiterleitungs- von Routing-Problemen
  2. Fritzbox: Portfreigabe UDP (WireGuard-Port) → UDM noch vorhanden/korrekt? (FritzOS-Updates werfen gern Freigaben/Exposed-Host-Einstellungen um)
  3. DS-Lite ausgeschlossen (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.
  4. (entfällt — feste IP)
  5. UDM-Seite: WireGuard-Server-Config/Firewall-Regeln nach UniFi-OS-Updates prüfen; statische Route Fritzbox → VLAN gegenchecken
  6. Erst wenn 15 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 17 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).