# 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](https://git.lab/axion1337.chat/management/-/issues/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

- ✅ **Eingelöst am 2026-08-02 (LABNET-03, [#13](https://git.lab/axion1337.chat/management/-/issues/13)):**
  Übergabe-Issues können nicht nur umziehen — sie sind umgezogen
  ([#25](https://git.lab/axion1337.chat/management/-/issues/25),
  [#26](https://git.lab/axion1337.chat/management/-/issues/26)), der Gitea-Tracker ist
  leer, die Vorlage liegt als GitLab-Issue-Template, und die Ausnahme aus ADR-0002 ist
  zurückgebaut. Damit hat dieser Tunnel seinen ersten inhaltlichen Zweck erfüllt.
- 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.
  **Nachtrag 2026-08-02:** Die Ausnahme besteht weiter, wird aber nicht mehr von Hand
  aufgelöst. Der Schedule-Job `canonize_rotation` im gitops-Repo holt die Rotation
  täglich von git.lab aus nach. Damit hängt sie nicht mehr am Tunnelzustand — der
  Job läuft im Lab und erreicht Gitea öffentlich. Das war der eigentliche Grund für
  die Ausnahme; sie ist jetzt automatisiert statt terminiert.
- 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](../verfahren/aar/2026-08-01-labnet02-lab.md).