labnet: LABNET-01 GELOEST - drei gestapelte Ursachen dokumentiert, git.lab vom Handy erreichbar

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj

shared/lab-netzwerk.md

@@ -9,10 +9,29 @@ Route in der Fritzbox für das Lab-VLAN.
 
 ## LABNET-01 — WireGuard-Roadwarrior ins Lab kaputt (seit einigen Monaten)
 
-**Status:** DURCHBRUCH 2026-08-01 ~14:40 — Tunnel steht über 5G (Handshake +
-stabile Keepalives). Rest: VPN-Clients erreichen das Lab-VLAN noch nicht
-(git.lab lädt nicht, öffentliche Seiten via Tunnel ja) — DNS- vs.
-Firewall-Unterscheidungstest läuft (IP-Direktzugriff 10.58.73.17/.1 vom Handy).
+**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 auf neue Adresse (10.58.74.2/32) und Endpunkt
+`178.25.213.70:51840` nachziehen (sorb, 2 min). ⚠️ 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