labnet: LABNET-01 Durchbruch - Port-Konflikt mit FritzOS-WireGuard, Tunnel steht auf 51840

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

shared/lab-netzwerk.md

@@ -9,8 +9,25 @@ Route in der Fritzbox für das Lab-VLAN.
 
 ## LABNET-01 — WireGuard-Roadwarrior ins Lab kaputt (seit einigen Monaten)
 
-**Status:** offen — **blockiert gitops#48** (Issue-Migration: Erreichbarkeits-
-Entscheidung ist „WireGuard statt GitLab exponieren")
+**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).
+
+**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: