Thore CimbalandClaude Fable 5
830c740a58
- ADR-0004: Status akzeptiert; real gebaute Architektur v2 dokumentiert (UniFi bietet kein WG-Site-to-Site -> UDM-Server + CFGMON als Client mit 'Networks Behind Client'), inkl. Messwerten aus dem Negativtest - AAR Lab-Seite: 5 Befunde, Eingrenzungsmethodik, 5 Lehren (u.a. 'Server'-Auswahl erfasst nur das Tunnel-Subnetz; Portbedingung gehoert in beide Portfelder) - README: Uebergabe-Issue-Ausnahme als auslaufend markiert - shared/lab-netzwerk.md: beide WG-Zugaenge tabellarisch Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
3.6 KiB
0004 — Site-to-Site-VPN Hetzner-Projektnetz ↔ Lab, schaltbar über die UDM
Status: akzeptiert (umgesetzt und abgenommen 2026-08-01, Testreihe 1–7 in management#12) · Datum: 2026-08-01 · Entscheider: sorb
Kontext
Das Lab ist die Quelle der Wahrheit (ADR-0002), aber die Hetzner-Hosts erreichten
git.lab nicht — das erzwang beim Cutover die Übergabe-Issue-Ausnahme. Ein
dauerhafter Zugang von exponierten Servern ins Heimnetz soll es trotzdem nicht sein.
Entscheidung
Ein eigener WireGuard-Tunnel (getrennt vom Roadwarrior) verbindet das
Hetzner-Projektnetz 10.0.0.0/24 mit dem Lab-VLAN 10.58.73.0/24. Der An/Aus-Schalter
liegt in der UniFi-UI; die Hetzner-Seite ist passiv und kann den Tunnel nicht selbst
öffnen (Bedarfsfall-Prinzip, Kontrolle im Lab).
Wie es tatsächlich gebaut wurde (Architektur v2)
Der ursprüngliche Entwurf sah die UDM als Initiator gegen einen WireGuard-Listener auf CFGMON vor. UniFi bietet Site-to-Site jedoch nur als OpenVPN/IPsec an; WireGuard existiert dort ausschließlich als Server — dafür mit der Option „Networks Behind Client". Die Richtung wurde deshalb gedreht:
| UDM | zweiter WG-Server „Matrix", UDP 51841, Tunnelnetz 10.58.75.0/24, „Alternate Address for Clients" = 178.25.213.70 |
| Client „Hetzner" | 10.58.75.2, Networks Behind Client = 10.0.0.0/24 |
| CFGMON | WG-Client/Initiator, dauerhaft aktiv (enable) + PersistentKeepalive 25; AllowedIPs nur 10.58.73.0/24, 10.58.75.1/32; Split-DNS nur ~lab → 10.58.73.1; ip_forward + iptables-ACCEPT in DOCKER-USER (ufw ist dort inaktiv), kein NAT |
| Fritzbox | Portfreigabe UDP 51841 → 192.168.178.20 |
| Hetzner | Netz-Range auf 10.0.0.0/8 erweitert, Route 10.58.73.0/24 → 10.0.0.3 — damit erreichen alle Server im Netz das Lab ohne eigene Konfiguration |
| UniFi-Firewall | Trennung vom Roadwarrior über Quell-/Ziel-IP (10.58.75.0/24 + 10.0.0.0/24), nicht über eine eigene Zone: erlaubt sind nur 10.58.73.17:443 (git.lab/Registry) und 10.58.73.1:53 (DNS); IoT und Arbeit sind für alle VPNs komplett gesperrt |
Konsequenzen
- Übergabe-Issues können jetzt nach git.lab umziehen; die Ausnahme aus ADR-0002 wird in einem Folge-Issue zurückgebaut.
- Abschaltung wirkt in unter 4 s, Rückkehr nach dem Einschalten in ~8 s ohne Eingriff auf der Hetzner-Seite (gemessen 2026-08-01 23:21–23:23).
- Ein kompromittierter Hetzner-Host sieht bei offenem Tunnel nur git.lab:443 und den Lab-DNS; bei geschlossenem Schalter gar nichts.
- Preis der Richtungsdrehung: eine Portfreigabe am Heimanschluss (im Ursprungsentwurf nicht nötig). Bewertung: akzeptabel, da nur UDP 51841 und WireGuard auf unbekannte Peers still schweigt.
- Der TURN-Rotations-CronJob trifft nur bei eingeschaltetem Tunnel auf git.lab — seine Gitea-PR-Ausnahme bleibt bewusst bestehen.
- game.axion1337.de profitiert erst nach Aufnahme in den vSwitch (GAME-01).
Verworfene Alternativen
- UDM als Initiator (Ursprungsentwurf): von UniFi nicht angeboten.
- Einzelne Roadwarrior-Profile pro Server: Schalter läge auf den exponierten Hosts, Key-Streuung, kein Site-Routing.
- Tunnel dauerhaft an: widerspricht dem Bedarfsfall-Prinzip ohne echten Gewinn.
- git.lab öffentlich exponieren: größte Angriffsfläche, klar verworfen.
- Eigene UniFi-Zone für den Tunnel: technisch nicht möglich (VPN-Server bleiben in der VPN-Zone), siehe AAR Lab-Seite.