# Dienst installation

OpenVPN - Server

# OpenVPN Site-to-Site Server für Phoenix-Contact-Router: zwei sichere Serverprofile

**Stand:** 27. Mai 2026

**Ziel dieses Dokuments:** Es beschreibt zwei getrennte OpenVPN-Serverinstanzen auf einem Linux-Server.

<div class="callout" id="bkmrk-modern.conf%3A-maximal">1. **modern.conf**: maximal gehärtet für aktuelle OpenVPN-Clients.
2. **compat.conf**: weiterhin sehr sicher, aber bewusst kompatibler für ältere Industrie-/Phoenix-Contact-Geräte.

</div>Beide Varianten sind für geroutete Site-to-Site-Tunnel gedacht. Das ist für dein Szenario richtig: Ein Phoenix-Contact-Router verbindet sich als OpenVPN-Client, teilt sein lokales LAN über den Tunnel und erreicht umgekehrt das zentrale LAN.

## 1. Quellen und Grundannahmen

Dieses Dokument orientiert sich vor allem an der offiziellen OpenVPN-2.6-Dokumentation, der OpenVPN-Hardening-Dokumentation, der OpenVPN-Dokumentation zu client-spezifischen Regeln und Easy-RSA. Wikipedia wird nur für die allgemeine Einordnung von OpenVPN als TLS-basiertes VPN über UDP/TCP erwähnt. Produktiv relevante Optionen werden aus der OpenVPN-Dokumentation abgeleitet, weil Wikipedia nicht deine Firewall administriert. Zum Glück.

<table id="bkmrk-quelle-wof%C3%BCr-sie-hie"><thead><tr><th>Quelle</th><th>Wofür sie hier verwendet wird</th></tr></thead><tbody><tr><td>[OpenVPN 2.6 Manual](https://openvpn.net/community-docs/community-articles/openvpn-2-6-manual.html)</td><td>Direktiven wie `server`, `data-ciphers`, `tls-groups`, `tls-crypt-v2`, `ccd-exclusive`, `iroute`, `keepalive`, `explicit-exit-notify`.</td></tr><tr><td>[OpenVPN Hardening Wiki](https://community.openvpn.net/Pages/Hardening)</td><td>Begründung für `tls-version-min 1.2` und allgemeine TLS-Härtung.</td></tr><tr><td>[OpenVPN Client-Specific Rules](https://openvpn.net/community-docs/configuring-client-specific-rules-and-access-policies.html)</td><td>Nutzung von `client-config-dir`, festen Client-IP-Adressen und Firewall-Policy je Client.</td></tr><tr><td>[OpenVPN Compression Wiki](https://community.openvpn.net/Pages/Compression)</td><td>Begründung, warum Kompression deaktiviert bleibt.</td></tr><tr><td>[Easy-RSA Dokumentation](https://easy-rsa.readthedocs.io/en/latest/)</td><td>PKI-, CA-, Zertifikats- und CRL-Erstellung.</td></tr><tr><td>[Wikipedia: OpenVPN](https://de.wikipedia.org/wiki/OpenVPN)</td><td>Allgemeine Einordnung: OpenVPN ist ein freies VPN über verschlüsselte TLS-Verbindungen und kann UDP oder TCP verwenden.</td></tr></tbody></table>

## 2. Zielbild

Wir bauen kein Layer-2-Bridging mit TAP. Wir bauen geroutete Layer-3-Tunnel mit TUN. Das ist stabiler, besser kontrollierbar und für Site-to-Site-Netze sauberer.

```text
Zentrales LAN:
  10.10.0.0/24

OpenVPN modern:
  Instanz:          modern.conf
  Port:             UDP/1194
  TUN-Interface:    tun0
  VPN-Netz:         10.255.0.0/24
  Beispielclient:   phoenix-modern-werk1
  Client-VPN-IP:    10.255.0.10
  LAN hinter Client:192.168.101.0/24

OpenVPN kompatibel:
  Instanz:          compat.conf
  Port:             UDP/1195
  TUN-Interface:    tun1
  VPN-Netz:         10.254.0.0/24
  Beispielclient:   phoenix-legacy-werk1
  Client-VPN-IP:    10.254.0.10
  LAN hinter Client:192.168.201.0/24
```

**Wichtig:** Die LAN-Netze hinter den Phoenix-Geräten müssen eindeutig sein. Zwei Standorte mit demselben Netz, etwa zweimal `192.168.0.0/24`, machen sauberes Routing unmöglich. Dann brauchst du 1:1-NAT oder eine Umnummerierung. Umnummerierung ist meistens die bessere Lösung, auch wenn Menschen dabei gern so tun, als wäre ein IP-Plan eine Naturkatastrophe.

## 3. Warum zwei getrennte OpenVPN-Instanzen?

Eine einzelne OpenVPN-Instanz kann theoretisch moderne und ältere Clients bedienen. Praktisch verwässerst du damit die starke Konfiguration, weil du Legacy-Fallbacks zulässt. Besser ist die Trennung:

<table id="bkmrk-instanz-ziel-sicherh"><thead><tr><th>Instanz</th><th>Ziel</th><th>Sicherheitsentscheidung</th></tr></thead><tbody><tr><td>`modern.conf`</td><td>Neue Clients mit aktueller OpenVPN-/TLS-Unterstützung.</td><td>Starke Kurvengruppen, AEAD-Cipher, `tls-crypt-v2`, keine CBC-Fallbacks.</td></tr><tr><td>`compat.conf`</td><td>Ältere Phoenix-/Industrieclients, die moderne Optionen nicht zuverlässig können.</td><td>Weiterhin TLS 1.2+, Zertifikate, CRL, `tls-auth`, keine Kompression, aber zusätzlicher CBC-Fallback.</td></tr></tbody></table>

Wenn du zwei öffentliche IP-Adressen hast, kannst du beide Instanzen auf Port 1194 betreiben und jeweils an eine andere IP binden. Wenn du nur eine öffentliche IP hast, müssen die Ports verschieden sein. Dieses Dokument nutzt daher `1194` für modern und `1195` für kompatibel.

## 4. Sicherheitsprinzipien

1. **Ein Zertifikat pro Standort.** Kein Zertifikat wird mehrfach verwendet.
2. **Ein Common Name pro Standort.** Der Dateiname in `ccd` entspricht genau dem Common Name des Zertifikats.
3. **Ein Standortnetz pro Zertifikat.** Das wird mit `iroute` gebunden.
4. **`ccd-exclusive`.** Clients ohne CCD-Datei werden abgewiesen.
5. **Keine Kompression.** Kompression in verschlüsselten Tunneln ist ein historischer Fußtritt in Richtung Sicherheitsproblem.
6. **CRL aktiv.** Verlorene Geräte werden über Zertifikatssperrlisten entfernt.
7. **Keine überlappenden Netze.** Routing braucht Eindeutigkeit. Überraschend, ich weiß.
8. **Firewall erzwingt die Policy.** OpenVPN routet, die Firewall entscheidet.
9. **CA-Key nicht dauerhaft auf dem VPN-Server.** Idealerweise liegt die CA auf einer separaten Admin-Maschine.

## 5. Installation auf Debian/Ubuntu

Die folgenden Befehle sind für Debian/Ubuntu-artige Systeme geschrieben. Bei RHEL/Rocky/Alma sind Paketmanager und Gruppennamen anders. Das Konzept bleibt gleich.

```bash
sudo apt update
sudo apt install -y openvpn easy-rsa nftables
sudo systemctl enable --now nftables
```

### 5.1 Befehl-für-Befehl-Erklärung

<table id="bkmrk-befehl-was-macht-er%3F"><thead><tr><th>Befehl</th><th>Was macht er?</th><th>Warum so?</th><th>Alternativen</th></tr></thead><tbody><tr><td>`sudo apt update`</td><td>Aktualisiert die lokale Paketliste des Systems.</td><td>Ohne aktuelle Paketliste installiert `apt` eventuell alte oder nicht auffindbare Pakete.</td><td>`apt-get update` ist die ältere, skriptfreundliche Variante. Auf RHEL-Systemen wäre es z. B. `dnf makecache`.</td></tr><tr><td>`sudo apt install -y openvpn easy-rsa nftables`</td><td>Installiert OpenVPN, Easy-RSA und nftables.</td><td>`openvpn` ist der VPN-Dienst, `easy-rsa` erzeugt Zertifikate und CRLs, `nftables` stellt die Firewall.</td><td>Statt `nftables` könntest du `iptables`, `ufw` oder eine externe Firewall verwenden. Für Server ist nftables heute die sauberere Wahl.</td></tr><tr><td>`sudo systemctl enable --now nftables`</td><td>Aktiviert nftables dauerhaft und startet es sofort.</td><td>`enable` sorgt für Start beim Booten, `--now` startet den Dienst direkt.</td><td>Man kann Firewallregeln auch über ein zentrales Firewall-System setzen. Lokal ist trotzdem sinnvoll, weil ein VPN-Server niemals blind vertrauen sollte.</td></tr></tbody></table>

## 6. Verzeichnisstruktur anlegen

```bash
sudo install -d -m 750 /etc/openvpn/server/modern
sudo install -d -m 750 /etc/openvpn/server/modern/ccd
sudo install -d -m 750 /etc/openvpn/server/compat
sudo install -d -m 750 /etc/openvpn/server/compat/ccd
```

<table id="bkmrk-befehl-was-macht-er%3F-1"><thead><tr><th>Befehl</th><th>Was macht er?</th><th>Warum so?</th><th>Alternativen</th></tr></thead><tbody><tr><td>`sudo install -d -m 750 /etc/openvpn/server/modern`</td><td>Legt das Verzeichnis für die moderne Instanz an.</td><td>`install -d` erstellt ein Verzeichnis. `-m 750` setzt Rechte: Besitzer darf alles, Gruppe darf lesen/betreten, andere dürfen nichts.</td><td>`mkdir -p` plus `chmod` geht auch, ist aber ein Befehl mehr. Weil wir hier angeblich Ordnung wollen, nutzen wir `install`.</td></tr><tr><td>`sudo install -d -m 750 /etc/openvpn/server/modern/ccd`</td><td>Legt das CCD-Verzeichnis der modernen Instanz an.</td><td>Hier liegen später Dateien wie `phoenix-modern-werk1`. OpenVPN liest daraus feste IPs und `iroute`-Einträge.</td><td>Man könnte `ccd` auch woanders speichern, aber unterhalb der Instanz bleibt es verständlich.</td></tr><tr><td>`sudo install -d -m 750 /etc/openvpn/server/compat`</td><td>Legt das Verzeichnis für die kompatible Instanz an.</td><td>Trennung verhindert, dass Schlüssel, CRLs oder CCD-Dateien versehentlich zwischen modern und legacy vermischt werden.</td><td>Eine gemeinsame Struktur wäre möglich, aber schlechter auditierbar.</td></tr><tr><td>`sudo install -d -m 750 /etc/openvpn/server/compat/ccd`</td><td>Legt das CCD-Verzeichnis der kompatiblen Instanz an.</td><td>Auch ältere Geräte bekommen feste Zuordnungen über CN, feste VPN-IP und entferntes LAN.</td><td>Keine gute Alternative, wenn du pro Zertifikat ein Netz sauber binden willst.</td></tr></tbody></table>

## 7. PKI-Strategie

Für die sauberste Trennung nutzt jede Instanz ihre eigene PKI:

- `~/easy-rsa-modern` für moderne Clients.
- `~/easy-rsa-compat` für ältere Clients.

Das ist administrativ etwas mehr Arbeit, aber sicherer. Wenn ein Legacy-Bereich kompromittiert wird, ist der moderne Bereich nicht automatisch dieselbe Vertrauensdomäne. Man könnte eine gemeinsame Root-CA mit getrennten Intermediate-CAs bauen. Für viele kleinere Betriebsumgebungen sind zwei getrennte Easy-RSA-PKIs einfacher.

## 8. Moderne PKI erstellen

```bash
make-cadir ~/easy-rsa-modern
cd ~/easy-rsa-modern

./easyrsa init-pki
./easyrsa build-ca
./easyrsa build-server-full modern-server nopass
./easyrsa build-client-full phoenix-modern-werk1 nopass
./easyrsa gen-crl
```

### 8.1 Erklärung der Befehle

<table id="bkmrk-befehl-was-macht-er%3F-2"><thead><tr><th>Befehl</th><th>Was macht er?</th><th>Warum so?</th><th>Optionen / Alternativen</th></tr></thead><tbody><tr><td>`make-cadir ~/easy-rsa-modern`</td><td>Erstellt ein Arbeitsverzeichnis mit Easy-RSA-Dateien.</td><td>Die PKI wird getrennt von der Systemkonfiguration vorbereitet. Das ist übersichtlicher und reduziert versehentliches Überschreiben.</td><td>Du kannst auch ein anderes Verzeichnis nehmen, z. B. `/root/easy-rsa-modern`. Idealerweise liegt die CA aber nicht dauerhaft auf dem VPN-Server.</td></tr><tr><td>`cd ~/easy-rsa-modern`</td><td>Wechselt in das neue Easy-RSA-Verzeichnis.</td><td>Die nächsten Befehle müssen im Easy-RSA-Verzeichnis ausgeführt werden.</td><td>Mit absoluten Pfaden geht es auch, ist aber unleserlicher.</td></tr><tr><td>`./easyrsa init-pki`</td><td>Initialisiert die PKI-Struktur unter `pki/`.</td><td>Erzeugt Verzeichnisse und Datenbanken für Zertifikate, Schlüssel und Seriennummern.</td><td>`init-pki` löscht/initialisiert die PKI. Auf produktiven CAs also nicht gedankenlos wiederholen. Menschen lieben destruktive Befehle mit harmlosen Namen.</td></tr><tr><td>`./easyrsa build-ca`</td><td>Erzeugt die Certificate Authority.</td><td>Die CA signiert später Server- und Client-Zertifikate. Der private CA-Key ist das wichtigste Geheimnis.</td><td>`build-ca nopass` wäre möglich, ist aber für eine CA nicht empfehlenswert. Eine CA sollte mit Passwort geschützt sein.</td></tr><tr><td>`./easyrsa build-server-full modern-server nopass`</td><td>Erzeugt und signiert ein Serverzertifikat mit Namen `modern-server`.</td><td>`nopass` sorgt dafür, dass OpenVPN beim Dienststart kein Passwort interaktiv abfragen muss.</td><td>Ohne `nopass` wird der private Schlüssel verschlüsselt. Das ist sicherer, aber für automatischen Serverstart unpraktisch. Alternativ kann man mit `askpass` arbeiten.</td></tr><tr><td>`./easyrsa build-client-full phoenix-modern-werk1 nopass`</td><td>Erzeugt ein Clientzertifikat für den Standort `phoenix-modern-werk1`.</td><td>Der Name wird zum Common Name und muss später exakt als CCD-Dateiname verwendet werden.</td><td>Für Benutzerlaptops wäre ein passwortgeschützter Key besser. Für Phoenix-Router ist `nopass` oft nötig, weil das Gerät beim Booten kein Passwort eintippen kann.</td></tr><tr><td>`./easyrsa gen-crl`</td><td>Erzeugt die Zertifikatssperrliste `crl.pem`.</td><td>OpenVPN prüft damit, ob ein Clientzertifikat gesperrt wurde.</td><td>Nach jedem `revoke` musst du `gen-crl` erneut ausführen und die neue CRL auf den Server kopieren.</td></tr></tbody></table>

## 9. Moderne PKI-Dateien auf den Server kopieren

```bash
sudo install -m 644 pki/ca.crt /etc/openvpn/server/modern/pki-ca.crt
sudo install -m 644 pki/issued/modern-server.crt /etc/openvpn/server/modern/modern-server.crt
sudo install -m 600 pki/private/modern-server.key /etc/openvpn/server/modern/modern-server.key
sudo install -m 644 pki/crl.pem /etc/openvpn/server/modern/crl.pem

sudo install -d -m 750 /etc/openvpn/server/modern/pki
sudo install -d -m 750 /etc/openvpn/server/modern/pki/issued
sudo install -d -m 700 /etc/openvpn/server/modern/pki/private

sudo cp pki/ca.crt /etc/openvpn/server/modern/pki/ca.crt
sudo cp pki/issued/modern-server.crt /etc/openvpn/server/modern/pki/issued/modern-server.crt
sudo cp pki/private/modern-server.key /etc/openvpn/server/modern/pki/private/modern-server.key
sudo cp pki/crl.pem /etc/openvpn/server/modern/crl.pem

sudo chown -R root:root /etc/openvpn/server/modern
sudo chmod 600 /etc/openvpn/server/modern/pki/private/modern-server.key
sudo chmod 644 /etc/openvpn/server/modern/crl.pem
```

**Hinweis:** In der Praxis brauchst du die ersten vier `install`-Zeilen nicht, wenn du direkt die strukturierte Variante darunter verwendest. Ich zeige sie trotzdem, weil `install -m` verständlich macht, dass Dateirechte kein Deko-Element sind. Für die eigentliche Dokumentation ist die strukturierte Variante mit `pki/ca.crt`, `pki/issued` und `pki/private` die relevante.

### 9.1 Erklärung der wichtigsten Kopierbefehle

<table id="bkmrk-befehl-was-macht-er%3F-3"><thead><tr><th>Befehl</th><th>Was macht er?</th><th>Warum so?</th><th>Optionen / Alternativen</th></tr></thead><tbody><tr><td>`sudo install -d -m 750 .../pki`</td><td>Erstellt ein PKI-Unterverzeichnis für die Instanz.</td><td>Die Pfade in `modern.conf` sind dadurch klar und getrennt.</td><td>Du könntest die Dateien direkt unter `/etc/openvpn/server/modern` ablegen, aber Unterordner sind sauberer.</td></tr><tr><td>`sudo install -d -m 700 .../pki/private`</td><td>Erstellt das private Schlüsselverzeichnis mit strengeren Rechten.</td><td>Private Schlüssel sollen nicht von normalen Benutzern lesbar sein.</td><td>`750` wäre möglich, aber `700` ist konservativer.</td></tr><tr><td>`sudo cp pki/ca.crt ...`</td><td>Kopiert das öffentliche CA-Zertifikat.</td><td>Der Server braucht die CA, um Clientzertifikate zu prüfen.</td><td>Die CA-Datei ist öffentlich. Sie ist nicht geheim. Der CA-Key ist geheim und gehört nicht hierher.</td></tr><tr><td>`sudo cp pki/issued/modern-server.crt ...`</td><td>Kopiert das Serverzertifikat.</td><td>OpenVPN präsentiert dieses Zertifikat den Clients.</td><td>Der Name ist frei wählbar, muss aber zur Config passen.</td></tr><tr><td>`sudo cp pki/private/modern-server.key ...`</td><td>Kopiert den privaten Server-Key.</td><td>Ohne privaten Schlüssel kann der Server sein Zertifikat nicht nutzen.</td><td>Der Key muss geschützt werden. Verlust oder Diebstahl bedeutet: Serverzertifikat neu erzeugen und altes sperren.</td></tr><tr><td>`sudo cp pki/crl.pem ...`</td><td>Kopiert die CRL.</td><td>OpenVPN kann gesperrte Clientzertifikate ablehnen.</td><td>Die CRL muss erneuert werden, nachdem Zertifikate widerrufen wurden.</td></tr><tr><td>`sudo chown -R root:root ...`</td><td>Setzt root als Besitzer.</td><td>Systemkonfiguration soll nicht normalen Benutzern gehören.</td><td>Je nach Distribution kann eine OpenVPN-Gruppe genutzt werden. Das sollte bewusst passieren, nicht zufällig.</td></tr><tr><td>`sudo chmod 600 ...modern-server.key`</td><td>Nur root darf den privaten Schlüssel lesen/schreiben.</td><td>Minimiert Risiko durch lokale Benutzer.</td><td>Wenn OpenVPN nach dem Start Rechte abgibt, liest es den Key vorher. `600` ist daher meistens korrekt.</td></tr><tr><td>`sudo chmod 644 ...crl.pem`</td><td>Macht die CRL für den OpenVPN-Prozess lesbar.</td><td>Nach Rechteabgabe an `nobody` muss OpenVPN die CRL weiterhin lesen können.</td><td>`640 root:nogroup` ist restriktiver, setzt aber korrekte Gruppe voraus.</td></tr></tbody></table>

## 10. Moderne TLS-Crypt-v2-Schlüssel erzeugen

```bash
sudo openvpn --genkey tls-crypt-v2-server /etc/openvpn/server/modern/tc2-server.key

sudo openvpn   --tls-crypt-v2 /etc/openvpn/server/modern/tc2-server.key   --genkey tls-crypt-v2-client /etc/openvpn/server/modern/phoenix-modern-werk1-tc2.key

sudo chmod 600 /etc/openvpn/server/modern/tc2-server.key
sudo chmod 600 /etc/openvpn/server/modern/phoenix-modern-werk1-tc2.key
```

<table id="bkmrk-befehl-was-macht-er%3F-4"><thead><tr><th>Befehl</th><th>Was macht er?</th><th>Warum so?</th><th>Optionen / Alternativen</th></tr></thead><tbody><tr><td>`openvpn --genkey tls-crypt-v2-server ...`</td><td>Erzeugt den serverseitigen Schlüssel für `tls-crypt-v2`.</td><td>`tls-crypt-v2` schützt den TLS-Kontrollkanal und erlaubt client-spezifische Schlüssel.</td><td>`tls-crypt` ist kompatibler, nutzt aber einen gemeinsamen statischen Schlüssel. `tls-auth` ist noch kompatibler, schützt aber nicht die Vertraulichkeit des Kontrollkanals.</td></tr><tr><td>`openvpn --tls-crypt-v2 ... --genkey tls-crypt-v2-client ...`</td><td>Erzeugt einen client-spezifischen `tls-crypt-v2`-Schlüssel.</td><td>Jeder Client bekommt einen eigenen Zusatzschlüssel. Das passt zur Idee: ein Zertifikat, ein Standort, ein Schlüssel.</td><td>Du kannst optionale Metadaten in Clientkeys einbetten. Für eine klare Betriebsdokumentation reicht der einfache Weg.</td></tr><tr><td>`chmod 600 ...`</td><td>Schränkt den Zugriff auf die Schlüsseldateien ein.</td><td>TLS-Crypt-Schlüssel sind geheim. Wer sie hat, kommt zwar ohne Zertifikat nicht rein, aber er reduziert deine Schutzschicht.</td><td>`640` mit dedizierter Gruppe ist möglich, wenn du sauber mit Gruppenrechten arbeitest.</td></tr></tbody></table>

## 11. Moderne OpenVPN-Serverkonfiguration

Datei:

```text
/etc/openvpn/server/modern.conf
```

```conf
port 1194
proto udp4
dev tun0
topology subnet

server 10.255.0.0 255.255.255.0

client-config-dir /etc/openvpn/server/modern/ccd
ccd-exclusive

route 192.168.101.0 255.255.255.0

ca /etc/openvpn/server/modern/pki/ca.crt
cert /etc/openvpn/server/modern/pki/issued/modern-server.crt
key /etc/openvpn/server/modern/pki/private/modern-server.key

dh none
tls-groups X25519:secp256r1:X448:secp384r1

tls-server
remote-cert-tls client
verify-client-cert require

tls-version-min 1.2
data-ciphers AES-256-GCM:CHACHA20-POLY1305:AES-128-GCM
auth SHA256
tls-cert-profile preferred

tls-crypt-v2 /etc/openvpn/server/modern/tc2-server.key

allow-compression no
crl-verify /etc/openvpn/server/modern/crl.pem

keepalive 10 60
explicit-exit-notify 1
persist-key
persist-tun

user nobody
group nogroup

verb 3
```

### 11.1 Jede Zeile der modernen Konfiguration erklärt

<table id="bkmrk-zeile-was-macht-sie%3F"><thead><tr><th>Zeile</th><th>Was macht sie?</th><th>Warum diese Wahl?</th><th>Alternativen / Hinweise</th></tr></thead><tbody><tr><td>`port 1194`</td><td>OpenVPN lauscht auf UDP-Port 1194.</td><td>1194 ist der offiziell/typisch verwendete OpenVPN-Port. Im betrieblichen Umfeld ist der Default sinnvoll, weil Firewalls, Doku und Monitoring dadurch klar bleiben.</td><td>Du könntest den Port ändern, etwa auf `443` oder `11940`, um den Dienst etwas zu verschleiern. Das ist aber keine echte Sicherheit und führt im Betrieb gern zu Verwirrung.</td></tr><tr><td>`proto udp4`</td><td>Nutzt UDP über IPv4 als Transportprotokoll.</td><td>UDP ist für VPN-Tunnel meist besser als TCP, weil TCP-over-TCP bei Paketverlust schlecht performt. `udp4` erzwingt IPv4.</td><td>Alternativen: `udp` für IPv4/IPv6 je nach System, `tcp-server` für TCP, `tcp4-server` für TCP nur IPv4. TCP nur verwenden, wenn UDP nicht möglich ist.</td></tr><tr><td>`dev tun0`</td><td>Erstellt oder nutzt das TUN-Interface `tun0`.</td><td>TUN ist Layer 3 und ideal für Routing zwischen Netzen. Der feste Name erleichtert Firewallregeln.</td><td>Alternative: `dev tun` lässt OpenVPN automatisch wählen. `dev tap` wäre Layer-2-Bridging und für dieses Site-to-Site-Konzept nicht empfehlenswert.</td></tr><tr><td>`topology subnet`</td><td>Vergibt Client-IP-Adressen wie in einem normalen Subnetz.</td><td>Damit kann ein Client z. B. `10.255.0.10/24` bekommen. Das ist verständlicher als alte /30-Paarungen.</td><td>Alternative: `topology net30` für sehr alte Clients. Für moderne und die meisten industriellen Geräte ist `subnet` sinnvoller.</td></tr><tr><td>`server 10.255.0.0 255.255.255.0`</td><td>Aktiviert Servermodus und definiert das VPN-Transfernetz.</td><td>Der Server bekommt üblicherweise `10.255.0.1`, Clients erhalten Adressen aus `10.255.0.0/24`. Dieses Netz ist nur für den Tunnel.</td><td>Du kannst jedes private, nicht überlappende Netz verwenden, z. B. `10.8.0.0/24`. Wichtig ist: keine Überschneidung mit LANs.</td></tr><tr><td>`client-config-dir /etc/openvpn/server/modern/ccd`</td><td>Aktiviert client-spezifische Konfigurationsdateien.</td><td>Jeder Standort bekommt eine Datei mit seinem Common Name. Darin stehen feste VPN-IP und `iroute`.</td><td>Der Pfad ist frei wählbar. Trennung je Instanz verhindert Fehlzuordnungen.</td></tr><tr><td>`ccd-exclusive`</td><td>Nur Clients mit vorhandener CCD-Datei dürfen verbinden.</td><td>Das ist für Site-to-Site wichtig: Kein Zertifikat soll ohne explizite Netzzuordnung online gehen.</td><td>Ohne diese Option könnten gültige Zertifikate ohne definierte Policy verbinden. Das ist für Betriebsnetze unsauber.</td></tr><tr><td>`route 192.168.101.0 255.255.255.0`</td><td>Fügt auf Serverseite eine Route zum entfernten Standortnetz hinzu.</td><td>Der Linux-Kernel gibt Pakete zu diesem Netz an OpenVPN. OpenVPN braucht zusätzlich das passende `iroute` in der CCD-Datei.</td><td>Für jeden Standort kommt eine weitere `route`-Zeile dazu. Bei vielen Standorten kann Routenmanagement über Scripts oder Konfigurationsmanagement erfolgen.</td></tr><tr><td>`ca .../ca.crt`</td><td>Pfad zum CA-Zertifikat.</td><td>Damit prüft der Server, ob Clientzertifikate von der richtigen CA signiert wurden.</td><td>Die CA-Datei ist öffentlich. Der private CA-Key darf nicht auf den VPN-Server.</td></tr><tr><td>`cert .../modern-server.crt`</td><td>Pfad zum Serverzertifikat.</td><td>Der Server weist sich damit gegenüber Clients aus.</td><td>Der Name ist frei, muss aber mit der Datei existieren.</td></tr><tr><td>`key .../modern-server.key`</td><td>Pfad zum privaten Server-Schlüssel.</td><td>Der private Schlüssel gehört zum Serverzertifikat und muss geheim bleiben.</td><td>Rechte: üblicherweise `600 root:root`.</td></tr><tr><td>`dh none`</td><td>Deaktiviert klassische statische DH-Parameter.</td><td>Wir nutzen moderne elliptische Gruppen über `tls-groups`. Das ist für neue Clients zeitgemäßer.</td><td>Für Legacy-Clients kann stattdessen `dh /pfad/dh.pem` nötig sein. Genau darum gibt es die zweite Instanz.</td></tr><tr><td>`tls-groups X25519:secp256r1:X448:secp384r1`</td><td>Legt erlaubte TLS-Gruppen/Kurven in Prioritätsreihenfolge fest.</td><td>X25519 ist eine moderne Standardwahl. secp256r1 ist sehr kompatibel. X448 und secp384r1 bieten weitere starke Optionen.</td><td>Alternative: Option weglassen und Bibliotheksdefaults nutzen. Oder `ecdh-curve prime256v1` für ältere Clients, aber das ist weniger modern.</td></tr><tr><td>`tls-server`</td><td>Setzt diese Instanz explizit in die TLS-Serverrolle.</td><td>Im Servermodus meist implizit, aber lesbar und eindeutig.</td><td>Normalerweise reicht `server ...`. Explizit schadet hier nicht.</td></tr><tr><td>`remote-cert-tls client`</td><td>Prüft, ob die Gegenstelle ein Client-Zertifikat verwendet.</td><td>Verhindert, dass Zertifikate mit falscher Rolle akzeptiert werden.</td><td>Nicht weglassen. Alternativ gibt es spezifischere Prüfungen über `verify-x509-name`, die zusätzlich genutzt werden können.</td></tr><tr><td>`verify-client-cert require`</td><td>Erzwingt ein gültiges Clientzertifikat.</td><td>Ohne gültiges Zertifikat keine Verbindung. Das ist zentral für Site-to-Site.</td><td>Der Default ist in vielen Fällen bereits `require`, aber explizit dokumentiert ist besser.</td></tr><tr><td>`tls-version-min 1.2`</td><td>Erlaubt nur TLS 1.2 oder höher.</td><td>TLS 1.0/1.1 gehören nicht mehr in ein neues betriebliches VPN.</td><td>Noch härter wäre TLS 1.3-only, aber das bricht viele Clients. Für OpenVPN-Umgebungen ist TLS 1.2+ der realistische harte Mindeststandard.</td></tr><tr><td>`data-ciphers AES-256-GCM:CHACHA20-POLY1305:AES-128-GCM`</td><td>Liste erlaubter Datenkanal-Cipher.</td><td>Nur moderne AEAD-Cipher. Kein CBC-Fallback in der modernen Instanz.</td><td>Du könntest `AES-128-GCM` vor `CHACHA20-POLY1305` setzen, wenn AES-Hardwarebeschleunigung erwartet wird. Wichtig: kein `BF-CBC`.</td></tr><tr><td>`auth SHA256`</td><td>Setzt SHA-256 als HMAC-Digest für relevante Kontroll-/Nicht-AEAD-Fälle.</td><td>SHA-256 ist ein robuster Standard. Bei AEAD-Ciphers ist der Datenkanal bereits integriert authentifiziert.</td><td>Alternativen: `SHA384` oder `SHA512`. SHA1 nicht neu verwenden.</td></tr><tr><td>`tls-cert-profile preferred`</td><td>Verlangt brauchbare Zertifikats-/Signaturalgorithmen.</td><td>Schiebt alte SHA1-/zu schwache Zertifikate aus dem Weg.</td><td>Bei sehr alten Geräten kann `legacy` nötig sein. In diesem Dokument bleiben auch ältere Geräte bei neu erzeugten Zertifikaten, daher `preferred`.</td></tr><tr><td>`tls-crypt-v2 .../tc2-server.key`</td><td>Aktiviert TLS-Crypt-v2 für den Kontrollkanal.</td><td>Beste Wahl für moderne Setups: client-spezifische Zusatzschlüssel, Schutz vor Scans und Müllpaketen.</td><td>Alternativen: `tls-crypt` oder `tls-auth`. Für Legacy nutzen wir bewusst `tls-auth`.</td></tr><tr><td>`allow-compression no`</td><td>Verbietet Kompression.</td><td>Kompression in verschlüsselten Tunneln erhöht Angriffsfläche und ist für Site-to-Site meist unnötig.</td><td>Nicht `compress` setzen. Auch nicht „nur testweise“, diese berühmten letzten Worte der IT.</td></tr><tr><td>`crl-verify .../crl.pem`</td><td>Aktiviert Prüfung der Zertifikatssperrliste.</td><td>Verlorene oder kompromittierte Clients können gesperrt werden.</td><td>Ohne CRL musst du im Ernstfall CA oder Serverpolicy gröber ändern. CRL ist Pflicht für sauberen Betrieb.</td></tr><tr><td>`keepalive 10 60`</td><td>Sendet Keepalive-Pings und erkennt tote Verbindungen.</td><td>Gerade Mobilfunk-/Industrieverbindungen profitieren davon.</td><td>Alternative: manuell `ping` und `ping-restart` setzen. `keepalive` ist die einfache Form.</td></tr><tr><td>`explicit-exit-notify 1`</td><td>Informiert UDP-Clients beim Serverstopp/Restart.</td><td>Clients reconnecten sauberer und schneller.</td><td>Nur für UDP sinnvoll. Bei TCP nicht verwenden.</td></tr><tr><td>`persist-key`</td><td>Liest Schlüssel bei internen Restarts nicht neu.</td><td>Hilft, wenn OpenVPN nach Start Rechte reduziert.</td><td>Weglassen ist möglich, aber weniger robust.</td></tr><tr><td>`persist-tun`</td><td>Hält das TUN-Interface bei Restarts offen.</td><td>Verhindert unnötiges Interface-Flapping und reduziert Routingstörungen.</td><td>Weglassen führt zu mehr Bewegung im Netzwerkstack. Betrieb mag keine Bewegung.</td></tr><tr><td>`user nobody`</td><td>OpenVPN läuft nach Initialisierung als Benutzer `nobody`.</td><td>Reduziert Schaden bei Prozesskompromittierung.</td><td>Manche Distributionen nutzen einen dedizierten Benutzer wie `openvpn`. Das ist sogar besser, wenn vorhanden.</td></tr><tr><td>`group nogroup`</td><td>OpenVPN wechselt in die Gruppe `nogroup`.</td><td>Passend zu `nobody` auf Debian/Ubuntu.</td><td>Auf RHEL heißt die Gruppe oft `nobody`. Mit `getent group nogroup` prüfen.</td></tr><tr><td>`verb 3`</td><td>Setzt das Log-Level auf normalen Betriebswert.</td><td>Genug Informationen für Betrieb, nicht zu viel Rauschen.</td><td>Für Fehlersuche kurzzeitig `verb 4` oder `verb 5`. Nicht dauerhaft extrem hoch loggen.</td></tr></tbody></table>

## 12. Moderne CCD-Datei für einen Phoenix-Standort

Datei:

```text
/etc/openvpn/server/modern/ccd/phoenix-modern-werk1
```

```conf
ifconfig-push 10.255.0.10 255.255.255.0
iroute 192.168.101.0 255.255.255.0
push "route 10.10.0.0 255.255.255.0"
```

<table id="bkmrk-zeile-was-macht-sie%3F-1"><thead><tr><th>Zeile</th><th>Was macht sie?</th><th>Warum diese Wahl?</th><th>Alternativen / Hinweise</th></tr></thead><tbody><tr><td>`ifconfig-push 10.255.0.10 255.255.255.0`</td><td>Weist diesem Client immer die feste VPN-IP `10.255.0.10` zu.</td><td>Feste Tunnel-IP macht Firewallregeln, Logs und Betrieb nachvollziehbar.</td><td>Bei `topology net30` wäre die Syntax anders: dann braucht man ein IP-Paar. Mit `topology subnet` ist diese Form korrekt.</td></tr><tr><td>`iroute 192.168.101.0 255.255.255.0`</td><td>Sagt OpenVPN intern: Dieses entfernte LAN gehört zu genau diesem Client.</td><td>Das ist der Kern deines „ein Zertifikat = ein Netzwerk“-Modells.</td><td>Ohne `iroute` kennt der Linux-Kernel vielleicht die Route, aber OpenVPN weiß nicht, zu welchem Client das Paket soll.</td></tr><tr><td>`push "route 10.10.0.0 255.255.255.0"`</td><td>Sendet dem Client eine Route zum zentralen LAN.</td><td>Der Phoenix-Router weiß dadurch, dass `10.10.0.0/24` über den VPN-Tunnel erreichbar ist.</td><td>Viele Industrieclients ignorieren Push-Routen oder konfigurieren Remote Networks im Webinterface. Dann diese Route dort manuell eintragen.</td></tr></tbody></table>

## 13. Moderne Instanz aktivieren

```bash
sudo install -m 640 modern.conf /etc/openvpn/server/modern.conf
sudo openvpn --config /etc/openvpn/server/modern.conf --test-crypto
sudo systemctl enable --now openvpn-server@modern
sudo systemctl status openvpn-server@modern
```

<table id="bkmrk-befehl-was-macht-er%3F-5"><thead><tr><th>Befehl</th><th>Was macht er?</th><th>Warum so?</th><th>Optionen / Alternativen</th></tr></thead><tbody><tr><td>`sudo install -m 640 modern.conf /etc/openvpn/server/modern.conf`</td><td>Kopiert die Konfigurationsdatei an den OpenVPN-Serverpfad.</td><td>`640` verhindert unnötige Lesbarkeit durch normale Benutzer.</td><td>Du kannst auch direkt mit einem Editor in `/etc/openvpn/server/modern.conf` schreiben.</td></tr><tr><td>`sudo openvpn --config ... --test-crypto`</td><td>Testet kryptografische Optionen der Konfiguration.</td><td>Findet Fehler bei Ciphers, TLS-Gruppen oder Pfaden früher.</td><td>Zusätzlich `sudo openvpn --config ...` im Vordergrund starten, wenn du detaillierte Fehlermeldungen brauchst.</td></tr><tr><td>`sudo systemctl enable --now openvpn-server@modern`</td><td>Aktiviert und startet die systemd-Instanz `modern`.</td><td>OpenVPN lädt dabei `/etc/openvpn/server/modern.conf`.</td><td>Nur starten: `systemctl start ...`. Nur Boot-Aktivierung: `systemctl enable ...`.</td></tr><tr><td>`sudo systemctl status openvpn-server@modern`</td><td>Zeigt Dienststatus und letzte Logs.</td><td>Erste Prüfung, ob der Dienst läuft.</td><td>Detaillierter: `journalctl -u openvpn-server@modern -f`.</td></tr></tbody></table>

## 14. Kompatible PKI erstellen

```bash
make-cadir ~/easy-rsa-compat
cd ~/easy-rsa-compat

./easyrsa init-pki
./easyrsa build-ca
./easyrsa build-server-full compat-server nopass
./easyrsa build-client-full phoenix-legacy-werk1 nopass
./easyrsa gen-crl
```

Die Befehle entsprechen der modernen PKI. Der wichtige Unterschied ist nicht Easy-RSA selbst, sondern die spätere OpenVPN-Konfiguration. Auch ältere Geräte sollen neue, saubere Zertifikate bekommen. Altgerät heißt nicht: altes SHA1-Zertifikat aus irgendeinem Export von 2014 behalten, nur weil es noch blinkt.

## 15. Kompatible PKI-Dateien kopieren

```bash
sudo install -d -m 750 /etc/openvpn/server/compat/pki
sudo install -d -m 750 /etc/openvpn/server/compat/pki/issued
sudo install -d -m 700 /etc/openvpn/server/compat/pki/private

sudo cp pki/ca.crt /etc/openvpn/server/compat/pki/ca.crt
sudo cp pki/issued/compat-server.crt /etc/openvpn/server/compat/pki/issued/compat-server.crt
sudo cp pki/private/compat-server.key /etc/openvpn/server/compat/pki/private/compat-server.key
sudo cp pki/crl.pem /etc/openvpn/server/compat/crl.pem

sudo chown -R root:root /etc/openvpn/server/compat
sudo chmod 600 /etc/openvpn/server/compat/pki/private/compat-server.key
sudo chmod 644 /etc/openvpn/server/compat/crl.pem
```

## 16. Kompatible TLS-Auth- und DH-Dateien erzeugen

```bash
sudo openvpn --genkey secret /etc/openvpn/server/compat/ta.key
sudo chmod 600 /etc/openvpn/server/compat/ta.key

sudo openssl dhparam -out /etc/openvpn/server/compat/dh.pem 3072
sudo chmod 644 /etc/openvpn/server/compat/dh.pem
```

<table id="bkmrk-befehl-was-macht-er%3F-6"><thead><tr><th>Befehl</th><th>Was macht er?</th><th>Warum so?</th><th>Optionen / Alternativen</th></tr></thead><tbody><tr><td>`sudo openvpn --genkey secret .../ta.key`</td><td>Erzeugt einen statischen Schlüssel für `tls-auth`.</td><td>`tls-auth` ist älter und breiter unterstützt als `tls-crypt-v2`. Es schützt den Kontrollkanal per HMAC gegen fremde Pakete.</td><td>`tls-crypt` wäre besser, wenn das Altgerät es unterstützt. `tls-crypt-v2` ist modern, aber auf älteren Appliances oft nicht verfügbar.</td></tr><tr><td>`sudo chmod 600 .../ta.key`</td><td>Beschränkt Zugriff auf den statischen Schlüssel.</td><td>Der Key ist geheim und wird auch auf dem Client gebraucht.</td><td>Bei Verteilung an Phoenix-Geräte sicher übertragen, z. B. per SFTP, nicht per E-Mail im Klartext, weil wir keine Museumsführung durch Sicherheitsfehler brauchen.</td></tr><tr><td>`sudo openssl dhparam -out .../dh.pem 3072`</td><td>Erzeugt klassische Diffie-Hellman-Parameter mit 3072 Bit.</td><td>Das ist kompatibler als moderne ECDH-only-Konfigurationen und bleibt trotzdem stark genug für eine Legacy-Instanz.</td><td>`4096` ist möglich, aber langsamer. `2048` ist kompatibler/schneller, aber weniger großzügig bei der Sicherheitsmarge.</td></tr><tr><td>`sudo chmod 644 .../dh.pem`</td><td>Macht die DH-Parameter lesbar.</td><td>DH-Parameter sind nicht geheim; OpenVPN muss sie lesen können.</td><td>`640` mit passender Gruppe ist möglich.</td></tr></tbody></table>

## 17. Kompatible OpenVPN-Serverkonfiguration

Datei:

```text
/etc/openvpn/server/compat.conf
```

```conf
port 1195
proto udp4
dev tun1
topology subnet

server 10.254.0.0 255.255.255.0

client-config-dir /etc/openvpn/server/compat/ccd
ccd-exclusive

route 192.168.201.0 255.255.255.0

ca /etc/openvpn/server/compat/pki/ca.crt
cert /etc/openvpn/server/compat/pki/issued/compat-server.crt
key /etc/openvpn/server/compat/pki/private/compat-server.key

dh /etc/openvpn/server/compat/dh.pem

tls-server
remote-cert-tls client
verify-client-cert require

tls-version-min 1.2
data-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC
cipher AES-256-CBC
auth SHA256
tls-cert-profile preferred

tls-auth /etc/openvpn/server/compat/ta.key 0

allow-compression no
crl-verify /etc/openvpn/server/compat/crl.pem

keepalive 10 60
explicit-exit-notify 1
persist-key
persist-tun

user nobody
group nogroup

verb 3
```

### 17.1 Jede Zeile der kompatiblen Konfiguration erklärt

<table id="bkmrk-zeile-was-macht-sie%3F-2"><thead><tr><th>Zeile</th><th>Was macht sie?</th><th>Warum diese Wahl?</th><th>Alternativen / Hinweise</th></tr></thead><tbody><tr><td>`port 1195`</td><td>OpenVPN lauscht für die kompatible Instanz auf UDP-Port 1195.</td><td>Da `1194` bereits von `modern.conf` genutzt wird, braucht diese Instanz einen zweiten Port.</td><td>Mit zwei öffentlichen IPs könnte auch diese Instanz Port `1194` nutzen, gebunden an eine andere IP. Auf einer IP müssen Ports verschieden sein.</td></tr><tr><td>`proto udp4`</td><td>Nutzt UDP über IPv4.</td><td>Auch für Altgeräte ist UDP normalerweise zuverlässiger für VPN als TCP.</td><td>TCP ist möglich, wenn Firewalls UDP blockieren. Dann `proto tcp4-server`, aber nur als Notlösung.</td></tr><tr><td>`dev tun1`</td><td>Nutzt ein eigenes TUN-Interface für die kompatible Instanz.</td><td>Getrennt von `tun0`, damit Firewallregeln klar zwischen modern und legacy unterscheiden können.</td><td>Automatische Benennung mit `dev tun` ist bequemer, aber schlechter für eindeutige Firewallregeln.</td></tr><tr><td>`topology subnet`</td><td>Verwendet normales Subnetzmodell für Client-IP-Zuweisung.</td><td>Auch viele ältere Geräte kommen damit klar. Es macht CCDs lesbarer.</td><td>Wenn ein sehr alter Client Probleme macht, kann `topology net30` nötig sein. Dann müssen `ifconfig-push`-Zeilen angepasst werden.</td></tr><tr><td>`server 10.254.0.0 255.255.255.0`</td><td>Definiert das VPN-Transfernetz der kompatiblen Instanz.</td><td>Getrennt vom modernen Netz, damit Logs, Routen und Firewallregeln eindeutig bleiben.</td><td>Jedes private, nicht überlappende Netz ist möglich. Nicht dasselbe Netz wie bei modern verwenden.</td></tr><tr><td>`client-config-dir /etc/openvpn/server/compat/ccd`</td><td>Aktiviert CCD-Dateien für Legacy-Clients.</td><td>Auch ältere Geräte werden pro Common Name fest gebunden.</td><td>Pfad frei wählbar, aber pro Instanz getrennt halten.</td></tr><tr><td>`ccd-exclusive`</td><td>Nur Clients mit CCD-Datei dürfen verbinden.</td><td>Gerade im Legacy-Bereich willst du keine Überraschungsclients.</td><td>Weglassen wäre bequemer und schlechter. Bequemlichkeit ist der natürliche Feind des Audits.</td></tr><tr><td>`route 192.168.201.0 255.255.255.0`</td><td>Serverroute zum Legacy-Standortnetz.</td><td>Der Kernel gibt Pakete zu diesem Netz an die OpenVPN-Instanz.</td><td>Für jeden Legacy-Standort eigene Route hinzufügen.</td></tr><tr><td>`ca .../ca.crt`</td><td>CA der kompatiblen PKI.</td><td>Getrennte Vertrauensdomäne für Legacy-Clients.</td><td>Du könntest eine gemeinsame CA nutzen, aber getrennt ist sauberer.</td></tr><tr><td>`cert .../compat-server.crt`</td><td>Serverzertifikat der kompatiblen Instanz.</td><td>Separates Zertifikat verhindert Vermischung mit modern.</td><td>Name frei wählbar, Datei muss existieren.</td></tr><tr><td>`key .../compat-server.key`</td><td>Privater Serverkey der kompatiblen Instanz.</td><td>Muss geheim bleiben.</td><td>Rechte restriktiv setzen.</td></tr><tr><td>`dh /etc/openvpn/server/compat/dh.pem`</td><td>Nutzt klassische Diffie-Hellman-Parameter.</td><td>Das ist für ältere Clients zuverlässiger als ECDH-only mit `dh none`.</td><td>Moderner wäre `dh none` plus `ecdh-curve` oder `tls-groups`. Für Legacy ist klassische DH robuster.</td></tr><tr><td>`tls-server`</td><td>Setzt TLS-Serverrolle.</td><td>Eindeutige Rollenverteilung.</td><td>Meist durch `server` implizit.</td></tr><tr><td>`remote-cert-tls client`</td><td>Prüft Client-Zertifikatrolle.</td><td>Auch alte Geräte sollen korrekte Clientzertifikate nutzen.</td><td>Nicht weglassen.</td></tr><tr><td>`verify-client-cert require`</td><td>Erzwingt Clientzertifikate.</td><td>Ohne Zertifikat keine Verbindung.</td><td>Benutzer/Passwort zusätzlich möglich, aber für Router-Site-to-Site normalerweise nicht nötig.</td></tr><tr><td>`tls-version-min 1.2`</td><td>Erlaubt TLS 1.2 oder höher.</td><td>Das ist die harte Untergrenze. TLS 1.0/1.1 wird nicht zugelassen.</td><td>Wenn ein Gerät nur TLS 1.0 kann, sollte es ersetzt oder isoliert werden. Eine produktive Betriebsverbindung mit TLS 1.0 ist keine „Kompatibilität“, sondern eine Altlast mit Netzwerkkabel.</td></tr><tr><td>`data-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC`</td><td>Erlaubt moderne GCM-Cipher und als letzten Fallback AES-256-CBC.</td><td>GCM bleibt bevorzugt. CBC wird nur zugelassen, damit ältere Clients ohne moderne Cipher-Aushandlung funktionieren.</td><td>Härter wäre ohne CBC. Genau das macht `modern.conf`. Schwächer wäre Blowfish/Camellia/3DES. Nicht verwenden.</td></tr><tr><td>`data-ciphers-fallback AES-256-CBC`</td><td>Fallback für Clients ohne moderne Data-Cipher-Negotiation.</td><td>Manche ältere OpenVPN-Clients können die neue Cipher-Aushandlung nicht sauber. Dieser Fallback hält sie kompatibel.</td><td>Nur setzen, wenn du solche Geräte wirklich brauchst. Nicht in der modernen Instanz verwenden.</td></tr><tr><td>`cipher AES-256-CBC`</td><td>Legacy-Hinweis für ältere Clients/Kompatibilität.</td><td>Ältere Clientkonfigurationen erwarten oft explizit `cipher AES-256-CBC`. In neueren OpenVPN-Versionen ist `data-ciphers` maßgeblich.</td><td>Auf modernen Clients besser GCM nutzen. Diese Zeile ist bewusst Legacy-Futter.</td></tr><tr><td>`auth SHA256`</td><td>HMAC-Digest SHA-256.</td><td>Für CBC und `tls-auth` relevant und sicherer als SHA1.</td><td>SHA384/SHA512 möglich, aber SHA256 ist breit kompatibel und sicher.</td></tr><tr><td>`tls-cert-profile preferred`</td><td>Erzwingt moderne Zertifikatsqualität.</td><td>Wir erzeugen neue Zertifikate, also gibt es keinen Grund für schwache Zertifikate.</td><td>Falls ein Altgerät alte SHA1-Zertifikate zwingend braucht, wäre `legacy` möglich. Das ist hier bewusst nicht empfohlen.</td></tr><tr><td>`tls-auth .../ta.key 0`</td><td>Aktiviert HMAC-Schutz für den TLS-Kontrollkanal. `0` ist die Server-Key-Direction.</td><td>Sehr kompatibel und trotzdem nützlich gegen fremde Pakete/Scans.</td><td>Besser wäre `tls-crypt`, falls der Client es kann. `tls-crypt-v2` ist die moderne Variante, aber weniger kompatibel.</td></tr><tr><td>`allow-compression no`</td><td>Verbietet Kompression.</td><td>Auch für Legacy bleibt Kompression aus. Kompatibilität ist kein Freifahrtschein für bekannte Angriffsflächen.</td><td>Nicht `compress` setzen. Wenn ein Altclient Kompression erzwingt, muss dessen Konfig angepasst werden.</td></tr><tr><td>`crl-verify .../crl.pem`</td><td>Prüft gesperrte Zertifikate.</td><td>Geräte können verloren gehen oder ausgemustert werden. CRL macht Sperrung sauber möglich.</td><td>CRL regelmäßig nach Widerruf erneuern.</td></tr><tr><td>`keepalive 10 60`</td><td>Prüft Tunnel-Lebendigkeit.</td><td>Gerade Mobilfunkrouter brauchen robuste Reconnect-Erkennung.</td><td>Werte können erhöht werden, wenn instabile Mobilfunkstrecken sonst zu hektisch reconnecten.</td></tr><tr><td>`explicit-exit-notify 1`</td><td>Informiert UDP-Clients beim Serverstopp.</td><td>Sauberere Reconnects.</td><td>Bei TCP nicht verwenden.</td></tr><tr><td>`persist-key`</td><td>Hält Key-Material über interne Restarts.</td><td>Hilft bei Dienste-Reconnects nach Rechteabgabe.</td><td>Weglassen selten sinnvoll.</td></tr><tr><td>`persist-tun`</td><td>Hält TUN-Interface offen.</td><td>Stabilere Routen und weniger Flapping.</td><td>Weglassen erzeugt mehr Interface-Bewegung.</td></tr><tr><td>`user nobody`</td><td>Reduziert Prozessrechte.</td><td>Besser als dauerhaft root.</td><td>Dedizierter OpenVPN-Benutzer ist noch sauberer, wenn Distribution ihn anbietet.</td></tr><tr><td>`group nogroup`</td><td>Reduziert Gruppenzugehörigkeit.</td><td>Debian/Ubuntu-kompatibel.</td><td>Auf anderen Distributionen prüfen.</td></tr><tr><td>`verb 3`</td><td>Normales Log-Level.</td><td>Geeignet für Dauerbetrieb.</td><td>`verb 4` zur Fehlersuche, danach zurück.</td></tr></tbody></table>

## 18. Kompatible CCD-Datei für einen Phoenix-Standort

Datei:

```text
/etc/openvpn/server/compat/ccd/phoenix-legacy-werk1
```

```conf
ifconfig-push 10.254.0.10 255.255.255.0
iroute 192.168.201.0 255.255.255.0
push "route 10.10.0.0 255.255.255.0"
```

<table id="bkmrk-zeile-was-macht-sie%3F-3"><thead><tr><th>Zeile</th><th>Was macht sie?</th><th>Warum diese Wahl?</th><th>Alternativen / Hinweise</th></tr></thead><tbody><tr><td>`ifconfig-push 10.254.0.10 255.255.255.0`</td><td>Feste VPN-IP für den Legacy-Phoenix.</td><td>Logs und Firewallregeln bleiben eindeutig.</td><td>Bei `net30` andere Syntax nötig.</td></tr><tr><td>`iroute 192.168.201.0 255.255.255.0`</td><td>Bindet das entfernte Legacy-LAN an genau diesen Client.</td><td>Kern des Site-to-Site-Routings.</td><td>Pro Client nur die Netze eintragen, die wirklich hinter diesem Router liegen.</td></tr><tr><td>`push "route 10.10.0.0 255.255.255.0"`</td><td>Teilt dem Client die Route zum zentralen LAN mit.</td><td>Damit Rückverkehr sauber über den Tunnel geht.</td><td>Wenn das Phoenix-Gerät Push-Routen ignoriert, Route im Phoenix-Webinterface als Remote Network setzen.</td></tr></tbody></table>

## 19. Kompatible Instanz aktivieren

```bash
sudo install -m 640 compat.conf /etc/openvpn/server/compat.conf
sudo openvpn --config /etc/openvpn/server/compat.conf --test-crypto
sudo systemctl enable --now openvpn-server@compat
sudo systemctl status openvpn-server@compat
```

## 20. IP-Forwarding aktivieren

```bash
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-openvpn-routing.conf
sudo sysctl --system
```

<table id="bkmrk-befehl-was-macht-er%3F-7"><thead><tr><th>Befehl</th><th>Was macht er?</th><th>Warum so?</th><th>Optionen / Alternativen</th></tr></thead><tbody><tr><td>`echo ... | sudo tee ...`</td><td>Schreibt die Kernel-Option für IPv4-Forwarding in eine persistente sysctl-Datei.</td><td>Der Server muss Pakete zwischen LAN und VPN weiterleiten dürfen.</td><td>Temporär ginge `sudo sysctl -w net.ipv4.ip_forward=1`, ist aber nach Reboot weg.</td></tr><tr><td>`sudo sysctl --system`</td><td>Lädt alle sysctl-Konfigurationen neu.</td><td>Die Änderung wird sofort aktiv, ohne Reboot.</td><td>`sudo sysctl -p /etc/sysctl.d/99-openvpn-routing.conf` lädt nur diese Datei.</td></tr></tbody></table>

## 21. Firewall mit nftables

Datei:

```text
/etc/nftables.conf
```

```nft
table inet filter {
  chain input {
    type filter hook input priority filter;
    policy drop;

    iif lo accept
    ct state established,related accept

    udp dport 1194 accept
    udp dport 1195 accept

    ip saddr 10.10.0.0/24 tcp dport 22 accept
  }

  chain forward {
    type filter hook forward priority filter;
    policy drop;

    ct state established,related accept

    iif "tun0" ip saddr 192.168.101.0/24 ip daddr 10.10.0.0/24 accept
    oif "tun0" ip saddr 10.10.0.0/24 ip daddr 192.168.101.0/24 accept

    iif "tun1" ip saddr 192.168.201.0/24 ip daddr 10.10.0.0/24 accept
    oif "tun1" ip saddr 10.10.0.0/24 ip daddr 192.168.201.0/24 accept
  }
}
```

### 21.1 Erklärung der Firewall-Regeln

<table id="bkmrk-regel-was-macht-sie%3F"><thead><tr><th>Regel</th><th>Was macht sie?</th><th>Warum so?</th><th>Optionen / Alternativen</th></tr></thead><tbody><tr><td>`table inet filter`</td><td>Erstellt eine Tabelle für IPv4 und IPv6.</td><td>Auch wenn wir hier IPv4 routen, ist `inet` ein moderner Standard.</td><td>`table ip filter` nur für IPv4 wäre auch möglich.</td></tr><tr><td>`chain input`</td><td>Regeln für Verkehr zum VPN-Server selbst.</td><td>Schützt den Serverdienst und Adminzugänge.</td><td>Input ist nicht Forwarding. Das wird gern verwechselt, weil Netzwerkbegriffe offenbar absichtlich Menschen ärgern.</td></tr><tr><td>`policy drop`</td><td>Standard: alles verwerfen, was nicht erlaubt ist.</td><td>Whitelist-Prinzip. Sicherer als nachträglich Dinge zu verbieten.</td><td>Für Testbetrieb kann `accept` helfen, produktiv ist `drop` besser.</td></tr><tr><td>`iif lo accept`</td><td>Erlaubt Loopback-Verkehr.</td><td>Lokale Prozesse brauchen Loopback.</td><td>Nicht entfernen. Viele Dienste erwarten das.</td></tr><tr><td>`ct state established,related accept`</td><td>Erlaubt Antworten zu bestehenden Verbindungen.</td><td>Ohne diese Regel würde selbst erlaubter Verkehr keine Rückantwort bekommen.</td><td>Connection Tracking ist Standard bei zustandsbehafteten Firewalls.</td></tr><tr><td>`udp dport 1194 accept`</td><td>Erlaubt moderne OpenVPN-Instanz.</td><td>Notwendig für `modern.conf`.</td><td>Wenn du Port änderst, hier mitändern.</td></tr><tr><td>`udp dport 1195 accept`</td><td>Erlaubt kompatible OpenVPN-Instanz.</td><td>Notwendig für `compat.conf`.</td><td>Bei zwei öffentlichen IPs und gleichem Port anders lösen.</td></tr><tr><td>`ip saddr 10.10.0.0/24 tcp dport 22 accept`</td><td>Erlaubt SSH nur aus dem zentralen LAN.</td><td>Adminzugang sollte nicht aus dem Internet offen sein.</td><td>Besser: dediziertes Adminnetz, Jump Host oder Out-of-band-Management.</td></tr><tr><td>`chain forward`</td><td>Regeln für weitergeleitete Pakete zwischen VPN und LAN.</td><td>Site-to-Site-Verkehr läuft durch Forwarding, nicht Input.</td><td>Hier liegt die eigentliche Zugriffskontrolle.</td></tr><tr><td>`iif "tun0" ip saddr 192.168.101.0/24 ip daddr 10.10.0.0/24 accept`</td><td>Erlaubt Verkehr vom modernen Phoenix-LAN ins zentrale LAN.</td><td>Nur das erwartete Quellnetz darf über `tun0` kommen.</td><td>Noch restriktiver: nur einzelne Zielhosts und Ports erlauben.</td></tr><tr><td>`oif "tun0" ip saddr 10.10.0.0/24 ip daddr 192.168.101.0/24 accept`</td><td>Erlaubt Rück-/Hinverkehr vom zentralen LAN zum modernen Phoenix-LAN.</td><td>Bidirektionaler Site-to-Site-Zugriff.</td><td>Für reine Fernwartung kann man Richtung und Ports stärker einschränken.</td></tr><tr><td>`iif "tun1" ... 192.168.201.0/24 ...`</td><td>Erlaubt Verkehr vom kompatiblen Phoenix-LAN ins zentrale LAN.</td><td>Legacy-Clients werden getrennt von modern behandelt.</td><td>Bei höherem Risiko Legacy nur zu einzelnen Wartungsservern zulassen.</td></tr><tr><td>`oif "tun1" ... 192.168.201.0/24 ...`</td><td>Erlaubt Verkehr vom zentralen LAN zum kompatiblen Phoenix-LAN.</td><td>Notwendig für bidirektionale Kommunikation.</td><td>Ports einschränken, wenn möglich.</td></tr></tbody></table>

Regeln laden:

```bash
sudo nft -c -f /etc/nftables.conf
sudo systemctl reload nftables
sudo nft list ruleset
```

<table id="bkmrk-befehl-was-macht-er%3F-8"><thead><tr><th>Befehl</th><th>Was macht er?</th><th>Warum so?</th><th>Optionen / Alternativen</th></tr></thead><tbody><tr><td>`sudo nft -c -f /etc/nftables.conf`</td><td>Prüft die Syntax, ohne Regeln zu laden.</td><td>Verhindert, dass du dich mit einer kaputten Firewall selbst aussperrst.</td><td>Immer vor Reload ausführen. Wirklich.</td></tr><tr><td>`sudo systemctl reload nftables`</td><td>Lädt die Firewallregeln neu.</td><td>Aktiviert die neue Policy.</td><td>`restart` geht auch, `reload` ist meist sauberer.</td></tr><tr><td>`sudo nft list ruleset`</td><td>Zeigt aktive nftables-Regeln.</td><td>Kontrolle, ob wirklich geladen wurde, was dokumentiert ist.</td><td>Für gezielte Analyse: `nft list table inet filter`.</td></tr></tbody></table>

## 22. Rückrouten im zentralen LAN

Alle Systeme im zentralen LAN müssen wissen, wie sie die Phoenix-Netze erreichen. Am besten setzt du die Routen auf dem zentralen LAN-Gateway.

```bash
ip route add 192.168.101.0/24 via 10.10.0.5
ip route add 192.168.201.0/24 via 10.10.0.5
```

`10.10.0.5` ist hier die LAN-IP des OpenVPN-Servers.

<table id="bkmrk-befehl-was-macht-er%3F-9"><thead><tr><th>Befehl</th><th>Was macht er?</th><th>Warum so?</th><th>Optionen / Alternativen</th></tr></thead><tbody><tr><td>`ip route add 192.168.101.0/24 via 10.10.0.5`</td><td>Sagt dem LAN-Gateway: Das moderne Phoenix-LAN erreichst du über den OpenVPN-Server.</td><td>Ohne Rückroute gehen Antworten ins Default-Gateway und verschwinden.</td><td>Wenn der OpenVPN-Server selbst das Default-Gateway des LANs ist, brauchst du diese Zusatzroute eventuell nicht.</td></tr><tr><td>`ip route add 192.168.201.0/24 via 10.10.0.5`</td><td>Dasselbe für das kompatible Phoenix-LAN.</td><td>Jedes entfernte LAN braucht eine Route.</td><td>Bei vielen Standorten statische Routen zentral dokumentieren oder per Routingprotokoll lösen.</td></tr></tbody></table>

## 23. Clientdateien für Phoenix-Geräte

### 23.1 Moderne Variante

Auf das Phoenix-Gerät bzw. in dessen OpenVPN-Client-Konfiguration gehören:

- `ca.crt`
- `phoenix-modern-werk1.crt`
- `phoenix-modern-werk1.key`
- `phoenix-modern-werk1-tc2.key` für `tls-crypt-v2`
- Serveradresse/FQDN
- Port `1194`
- UDP
- TUN/routed mode
- lokales Netz `192.168.101.0/24`
- Remote-Netz `10.10.0.0/24`

### 23.2 Kompatible Variante

- `ca.crt`
- `phoenix-legacy-werk1.crt`
- `phoenix-legacy-werk1.key`
- `ta.key` für `tls-auth`
- Key direction beim Client: `1`
- Serveradresse/FQDN
- Port `1195`
- UDP
- TUN/routed mode
- lokales Netz `192.168.201.0/24`
- Remote-Netz `10.10.0.0/24`

**Kein NAT auf dem Phoenix aktivieren**, wenn echte bidirektionale Site-to-Site-Kommunikation gewünscht ist. NAT nur verwenden, wenn Netze überlappen oder ein Gerät technisch nicht sauber routen kann. NAT macht Fehler nicht weg, es zieht ihnen nur eine Jacke an.

## 24. Zertifikat widerrufen

Wenn ein Gerät verloren geht, ausgetauscht oder kompromittiert wird:

```bash
cd ~/easy-rsa-modern
./easyrsa revoke phoenix-modern-werk1
./easyrsa gen-crl
sudo cp pki/crl.pem /etc/openvpn/server/modern/crl.pem
sudo systemctl reload openvpn-server@modern
```

Für die kompatible Instanz entsprechend:

```bash
cd ~/easy-rsa-compat
./easyrsa revoke phoenix-legacy-werk1
./easyrsa gen-crl
sudo cp pki/crl.pem /etc/openvpn/server/compat/crl.pem
sudo systemctl reload openvpn-server@compat
```

<table id="bkmrk-befehl-was-macht-er%3F-10"><thead><tr><th>Befehl</th><th>Was macht er?</th><th>Warum so?</th><th>Optionen / Alternativen</th></tr></thead><tbody><tr><td>`./easyrsa revoke NAME`</td><td>Markiert das Zertifikat als widerrufen.</td><td>Das Zertifikat soll nicht mehr verbinden dürfen.</td><td>Name muss dem Zertifikatsnamen/Common Name entsprechen.</td></tr><tr><td>`./easyrsa gen-crl`</td><td>Erzeugt eine aktualisierte CRL.</td><td>OpenVPN liest nicht die Easy-RSA-Datenbank, sondern die CRL-Datei.</td><td>Nach jedem Widerruf erforderlich.</td></tr><tr><td>`sudo cp pki/crl.pem ...`</td><td>Kopiert die neue CRL in den OpenVPN-Pfad.</td><td>Nur dann nutzt der Server den neuen Sperrstand.</td><td>Mit Konfigurationsmanagement automatisieren, wenn viele Standorte existieren.</td></tr><tr><td>`sudo systemctl reload ...`</td><td>Lädt den OpenVPN-Dienst neu.</td><td>Damit die neue CRL verwendet wird.</td><td>Wenn Reload nicht reicht, `restart`. Kurze Unterbrechung beachten.</td></tr></tbody></table>

## 25. Wichtige Tests

```bash
sudo openvpn --version
sudo openvpn --show-groups
sudo openvpn --show-ciphers
sudo openvpn --show-digests

journalctl -u openvpn-server@modern -f
journalctl -u openvpn-server@compat -f

ip addr show tun0
ip addr show tun1
ip route

ping 10.255.0.10
ping 192.168.101.1
ping 10.254.0.10
ping 192.168.201.1
```

<table id="bkmrk-befehl-was-pr%C3%BCft-er%3F"><thead><tr><th>Befehl</th><th>Was prüft er?</th><th>Warum wichtig?</th></tr></thead><tbody><tr><td>`openvpn --version`</td><td>OpenVPN-Version und verwendete Crypto-Bibliothek.</td><td>Optionen wie `tls-groups` hängen von Version und Bibliothek ab.</td></tr><tr><td>`openvpn --show-groups`</td><td>Verfügbare TLS-Gruppen/Kurven.</td><td>Wichtig für die moderne Instanz.</td></tr><tr><td>`openvpn --show-ciphers`</td><td>Verfügbare Datenkanal-Cipher.</td><td>Prüft, ob GCM/ChaCha20/CBC verfügbar sind.</td></tr><tr><td>`openvpn --show-digests`</td><td>Verfügbare HMAC-Digests.</td><td>Prüft SHA256-Unterstützung.</td></tr><tr><td>`journalctl -u ... -f`</td><td>Live-Logs der Instanz.</td><td>Beste erste Diagnose bei Verbindungsproblemen.</td></tr><tr><td>`ip addr show tun0/tun1`</td><td>Existenz und IPs der Tunnelinterfaces.</td><td>Zeigt, ob OpenVPN Interface und Server-IP gesetzt hat.</td></tr><tr><td>`ip route`</td><td>Kernel-Routingtabelle.</td><td>Prüft, ob Routen zu entfernten LANs existieren.</td></tr><tr><td>`ping ...`</td><td>Basis-Erreichbarkeit.</td><td>Ping ist kein vollständiger Test, aber ein guter Anfang. Danach Porttests machen.</td></tr></tbody></table>

## 26. Typische Fehlerbilder

<table id="bkmrk-symptom-wahrscheinli"><thead><tr><th>Symptom</th><th>Wahrscheinliche Ursache</th><th>Prüfung</th><th>Lösung</th></tr></thead><tbody><tr><td>Client verbindet, LAN dahinter ist nicht erreichbar.</td><td>`iroute` fehlt oder falscher CCD-Dateiname.</td><td>`journalctl`, CCD-Datei, Common Name prüfen.</td><td>CCD-Datei exakt nach CN benennen und `iroute` setzen.</td></tr><tr><td>Server-LAN erreicht Phoenix, aber Antwort kommt nicht zurück.</td><td>Rückroute im zentralen Gateway oder Phoenix-LAN fehlt.</td><td>`ip route` auf Gateway/Phoenix prüfen.</td><td>Route zum Gegennetz über OpenVPN/Phoenix setzen.</td></tr><tr><td>TLS-Handshake schlägt bei modern fehl.</td><td>Client unterstützt `tls-crypt-v2`, `tls-groups` oder Cipher nicht.</td><td>Logs mit `verb 4`, Clientfähigkeiten prüfen.</td><td>Gerät in kompatible Instanz verschieben.</td></tr><tr><td>Kompatibler Client verbindet nicht wegen Cipher.</td><td>Client nutzt anderen Legacy-Cipher.</td><td>Clientconfig prüfen: `cipher`.</td><td>Client auf `AES-256-CBC` stellen. Keine Blowfish-Fallbacks neu einführen.</td></tr><tr><td>Clientzertifikat wird abgelehnt.</td><td>Falsche CA, CRL, Zertifikatsrolle oder Ablaufdatum.</td><td>`openssl x509 -in client.crt -text -noout`.</td><td>Neues Zertifikat erzeugen und korrekt verteilen.</td></tr><tr><td>OpenVPN startet nicht nach `user nobody`.</td><td>Dateien nach Rechteabgabe nicht lesbar, oft CRL.</td><td>`journalctl` prüfen.</td><td>CRL lesbar machen, z. B. `chmod 644 crl.pem` oder passende Gruppe setzen.</td></tr></tbody></table>

## 27. Optionen, die bewusst nicht verwendet werden

<table id="bkmrk-option-warum-nicht%3F-"><thead><tr><th>Option</th><th>Warum nicht?</th></tr></thead><tbody><tr><td>`duplicate-cn`</td><td>Würde erlauben, dass mehrere Clients dasselbe Zertifikat nutzen. Das zerstört dein Modell „ein Zertifikat = ein Netzwerk“. Nicht verwenden.</td></tr><tr><td>`client-to-client`</td><td>Würde VPN-Clients untereinander sprechen lassen. Für zentrale Fernwartung meist unnötig und riskant. Nur aktivieren, wenn Standort-zu-Standort-Kommunikation ausdrücklich benötigt wird.</td></tr><tr><td>`push "redirect-gateway def1"`</td><td>Würde gesamten Internetverkehr des Clients über den VPN-Server schicken. Für Site-to-Site-Fernwartung unnötig.</td></tr><tr><td>`compress`</td><td>Kompression bleibt aus Sicherheitsgründen deaktiviert.</td></tr><tr><td>`compat-mode`</td><td>OpenVPN warnt, dass diese Option Defaults auf weniger empfohlene Werte zurücksetzen kann. Besser einzelne Kompatibilitätsoptionen bewusst setzen.</td></tr><tr><td>`cipher BF-CBC`</td><td>Blowfish/CBC ist historischer Altbestand und gehört nicht in neue Konfigurationen.</td></tr><tr><td>`tls-version-min 1.0`</td><td>Für neue betriebliche Setups nicht mehr akzeptabel. Wenn ein Gerät das braucht, gehört es in ein stark isoliertes Migrationsprojekt, nicht in normale Produktion.</td></tr></tbody></table>

## 28. Wann welche Instanz?

<table id="bkmrk-ger%C3%A4t%2Fclient-instanz"><thead><tr><th>Gerät/Client</th><th>Instanz</th><th>Begründung</th></tr></thead><tbody><tr><td>Aktueller OpenVPN-Client 2.5/2.6, aktueller Linux-/Windows-Client, moderne Appliance.</td><td>`modern.conf`</td><td>AEAD-Cipher, `tls-crypt-v2`, moderne Gruppen, keine Legacy-Fallbacks.</td></tr><tr><td>Phoenix-/Industriegerät mit Unterstützung für AES-GCM und tls-crypt-v2.</td><td>`modern.conf`</td><td>Wenn getestet stabil: modern verwenden.</td></tr><tr><td>Phoenix-/Industriegerät mit älterem OpenVPN-Stack, kein tls-crypt-v2, eventuell nur AES-256-CBC.</td><td>`compat.conf`</td><td>Weiterhin TLS 1.2+, Zertifikate, CRL und Firewall, aber mit Legacy-Fallback.</td></tr><tr><td>Gerät kann nur TLS 1.0, Blowfish oder Kompression.</td><td>Keine der beiden Instanzen ohne Sonderfreigabe.</td><td>Das ist nicht „älter“, das ist ein Sicherheitsproblem mit Gehäuse. Ersatz oder isolierte Übergangslösung planen.</td></tr></tbody></table>

## 29. Betriebs-Checkliste

- Für jeden Standort eindeutiges LAN-Netz vergeben.
- Pro Standort eigenes Zertifikat erzeugen.
- Common Name exakt dokumentieren.
- CCD-Datei mit exakt gleichem Namen erstellen.
- Feste VPN-IP vergeben.
- `iroute` für das entfernte Standortnetz setzen.
- `route` in der Serverinstanz ergänzen.
- Firewallregel für genau dieses Standortnetz ergänzen.
- Rückroute im zentralen LAN setzen.
- Phoenix-Firewall für VPN ↔ LAN konfigurieren.
- Keine Kompression.
- Kein `duplicate-cn`.
- CRL nach jedem Widerruf neu erzeugen und verteilen.
- Logs prüfen und Zertifikatsablauf überwachen.

## 30. Kurzfazit

`modern.conf` ist die Zielkonfiguration: stark, sauber und ohne Legacy-Ballast. `compat.conf` ist die pragmatische Betriebsvariante für ältere Phoenix-/Industrieclients: weiterhin kontrolliert, getrennt, mit Zertifikaten, CRL, Firewall und TLS 1.2+, aber mit bewusstem AES-256-CBC-Fallback und `tls-auth`.

Der entscheidende Sicherheitsgewinn entsteht nicht durch eine einzelne magische Zeile. Er entsteht durch die Kombination aus getrennter Instanz, eindeutiger PKI, `ccd-exclusive`, `iroute`, festen IPs, restriktiver Firewall, deaktivierter Kompression und sauberer Zertifikatssperrung. Kryptografie ist wichtig, aber Routingfehler und Copy-Paste-Zertifikate ruinieren dir den Tag meist schneller. Menschen nennen das dann „gewachsene Infrastruktur“.