From fa5c7a86816cce1783ac20423d3ae3ae688da798 Mon Sep 17 00:00:00 2001 From: Thore Cimbal Date: Sat, 1 Aug 2026 12:00:00 +0000 Subject: [PATCH] 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 | 38 +++++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/verfahren/aar/2026-08-01-labnet02-cfgmon.md b/verfahren/aar/2026-08-01-labnet02-cfgmon.md index 7e58c28..09814ef 100644 --- a/verfahren/aar/2026-08-01-labnet02-cfgmon.md +++ b/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).