verfahren: AAR LABNET-02 -- Aufloesung: Server-Key der Uebergabe war falsch

Der Handshake stand am 2026-08-01 ~21:15. Ursache des tagelangen Schweigens
war der in management#2 (Kommentar 399) als bestaetigt uebergebene UDM-Server-
PublicKey, der zu keinem Server auf der UDM gehoert. Nachtrag 2 dokumentiert
Eingrenzungsweg (tcpdump beidseitig, wg show am Geraet), Endzustand und Lehren.
Der Portversatz Fritzbox/UDM war ein realer zweiter Fehler, allein aber nicht
hinreichend.

verfahren/aar/2026-08-01-labnet02-cfgmon.md

@@ -134,3 +134,41 @@ Plausibilität), war hier auf die eigene Arbeit nicht angewendet worden.
 Handshake** (`0 B received` nach 13 Minuten Keepalive). Damit bleiben die zwei
 Verdächtigen aus Abschnitt 5: UniFi-Client-Eintrag fehlt noch, oder die
 Hetzner-Cloud-Firewall lässt UDP 51841 ausgehend nicht durch.
+
+## 7. Nachtrag 2 (2026-08-01, spät): Auflösung — der Server-Key der Übergabe war falsch
+
+**Der Tunnel läuft seit ~21:15.** Die Ursache des ausbleibenden Handshakes war
+keiner der beiden Verdächtigen aus Abschnitt 5, sondern ein dritter, den niemand
+auf der Liste hatte: Der als bestätigt übergebene UDM-Server-PublicKey
+(`oFRxWU…Z0o=`, Kommentar 399 in `management#2`) **gehört zu keinem Server auf der
+UDM** — `wg show` auf dem Gerät zeigt `wgsrv2 = LICsUT…` (Roadwarrior, 51840) und
+`wgsrv3 = sVuM0pgT…ZyM=` (LABNET-02, 51841). Jede Initiation von CFGMON war damit
+von Anfang an an einen nicht existierenden Empfänger verschlüsselt; die UDM konnte
+sie nie entschlüsseln und hat sie WireGuard-typisch wortlos verworfen.
+
+**Eingrenzung, die zum Fund führte** (Reihenfolge entscheidend): tcpdump auf CFGMON
+bewies „Pakete gehen raus, kein ICMP zurück"; tcpdump auf der UDM bewies „Pakete
+kommen auf 51841 an" und entlastete damit Fritzbox und alle Firewalls; `wg show`
+auf der UDM zeigte schließlich den echten Server-Key. Der Fritzbox/UDM-Portversatz
+(51820 vs. 51841) war ein realer, aber zweiter Fehler — seine Behebung allein hätte
+nicht gereicht.
+
+**Endzustand CFGMON:** `lab.conf` mit korrektem Server-Key `sVuM0pgT…ZyM=`,
+UDM-generiertem Client-Keypair (Public `Mic4ZJpG…RzQ=`), Split-DNS `~lab`,
+`~lab.de`, `~axion1337.de`, `~axionlabs.de` über `10.58.73.1`; aXionLabs-Root-CA
+im Truststore (verifiziert gegen die git.lab-Kette und per Fingerprint-Abgleich
+gegen die step-ca, Port 666). Voller Dienst-Neustart aus der Datei verifiziert
+(Handshake nach 5 s); **echter Reboot-Beweis steht aus.**
+
+**Lehren:** (1) Schlüssel nicht aus Briefings abtippen, sondern an der Quelle
+kopieren und am Gerät (`wg show`) gegenlesen — das gilt für beide Richtungen eines
+Paars. (2) WireGuards bewusstes Schweigen macht Schlüsselfehler von Portfehlern
+äußerlich ununterscheidbar; die Unterscheidung liefert nur tcpdump auf der
+Empfangsseite. (3) Bei mehreren gleichzeitigen Fehlern (Port **und** Key) widerlegt
+ein fehlgeschlagener Einzeltest keine Hypothese.
+
+**Offen nach diesem Nachtrag:** Testreihe 1–7 (inkl. Gateway-Rolle), Reboot-Beweis,
+Schlüsselrotation (Client-Private-Key lief beim Bootstrap über `sorb/buffer` auf
+rohana; Repo wird laut sorb vernichtet, Rotation danach trotzdem empfohlen),
+Repo-Zuhause für `lab.conf` + systemd-Drop-in (zurückgestellt bis nach der
+Testreihe).