ARTICLE · 03.10.2026

VPN Management in iTop – Tunnel, Endpoints und Zugriffsregeln dokumentieren

VPN Management erweitert iTop um die strukturierte Dokumentation von VPN-Infrastrukturen. Tunnel, Endpunkte, Peers und Zugriffsregeln werden zentral erfasst, miteinander verknüpft und durch Governance- und Review-Informationen ergänzt.

Extension: VPN Management

Extension-Code: vpn-management

Version: 1.3.2

Mindestversion iTop: 3.3.0

Abhängigkeiten: - iTop Configuration Management 3.3.0 - TeemIP Framework 3.0.0

Dieser Leitfaden beschreibt, wie reale VPN-Infrastrukturen fachlich in der Extension dokumentiert werden sollen. Er ist weder Bedienungsanleitung noch technische Entwicklerdokumentation.

1. Zweck und Geltungsbereich

Die Extension dient zur protokollneutralen Dokumentation von VPN-Infrastrukturen. Unterstützt werden im Datenmodell insbesondere WireGuard, IPsec, OpenVPN, SSL-VPN, GRE und sonstige VPN-Technologien.

Screenshot 2026-09-29 191244.webp

Das Modell trennt bewusst zwischen:

dem logischen VPN (VPNTunnel), den lokalen VPN-Instanzen (VPNEndpoint), optionalen technischen Peer-Beziehungen (VPNPeer), den fachlich dokumentierten Kommunikationsfreigaben (VPNAccessRule), und den strukturiert zugeordneten TeemIP-Subnetzen (lnkVPNPeerToIPSubnet). Vorhandene iTop- und TeemIP-Objekte sollen nach Möglichkeit wiederverwendet und verknüpft werden. Dazu gehören insbesondere Organization, Location, ConnectableCI, IPInterface, Software und IPSubnet.

2. Was wird dokumentiert -- und was nicht?

Dokumentiert werden
  • Existenz und Zweck eines VPNs
  • verwendete VPN-Technologie
  • VPN-Topologie
  • Betriebsstatus
  • Betreiber/Provider
  • VPN-Netz
  • beteiligte Endpunkte
  • Standort eines Endpunkts
  • zugrunde liegender Host bzw. CI
  • IP-Interface
  • eingesetzte VPN-Software
  • lokale VPN-Adresse
  • Listen-Port und öffentlicher Endpunkt
  • Rollen der Endpunkte
  • Public Keys bzw. Zertifikatsreferenzen
  • technische Peer-Beziehungen
  • entfernte Netze / Allowed Networks
  • strukturierte TeemIP-Subnetze
  • fachlich dokumentierte Kommunikationsbeziehungen mit Protokoll, Ports, Dienst und Aktion
  • Referenzen auf extern gespeicherte Credentials
Nicht in iTop gespeichert werden sollen
  • Private Keys
  • Preshared Keys
  • Passwörter
  • API-Secrets
  • Tokens
  • Recovery Codes
  • sonstige geheime Authentisierungsdaten

    Hierfür ist ausschließlich eine Referenz auf ein geeignetes Secret-Management-System zu hinterlegen.

3. Dokumentationsmodell

VPN-Tunnel-Topo.ewbp

Grundregel

Ein VPNTunnel beschreibt den VPN-Verbund als Ganzes. Ein VPNEndpoint beschreibt eine konkrete lokale Instanz dieses VPNs. Ein VPNPeer beschreibt bei Bedarf die technische Sicht eines Endpunkts auf eine Gegenstelle. Eine VPNAccessRule beschreibt, welche Kommunikation über bzw. innerhalb dieses VPNs fachlich vorgesehen ist.

4. Objekttypen und reale Bedeutung

4.1 VPNTunnel -- das logische VPN

Was repräsentiert das Objekt?

Ein VPNTunnel repräsentiert ein fachlich zusammengehöriges VPN bzw. einen VPN-Verbund.

Beispiele:
  • Administrations-VPN
  • Standortkopplung Werk ↔ Rechenzentrum
  • Monitoring-VPN
  • Remote-Access-VPN
  • WireGuard-Verbund für Servermanagement
Wann wird ein neues VPN angelegt?

Ein neues VPNTunnel-Objekt wird angelegt, wenn eine eigenständige VPN-Infrastruktur mit eigenem Zweck, Teilnehmerkreis oder Betriebslebenszyklus existiert.

Wann wird kein neues VPN angelegt?
Nicht für:
  • jeden einzelnen Peer,
  • jeden Client,
  • jede Tunnelrichtung,
  • jeden Port,
  • jede erlaubte Kommunikationsbeziehung.
Diese Sachverhalte gehören in VPNEndpoint, VPNPeer bzw. VPNAccessRule.
Technisch verpflichtende Angaben
  • Name (geerbt über FunctionalCI)
  • Organisation (org_id, geerbt)
  • VPN-Typ (vpn_type)
  • Topologie (topology)
  • VPN-Status (vpn_status)
  • Fachlich empfohlene Angaben
  • Zweck (purpose)
  • Anbieter/Betreiber (provider_id), falls vorhanden
  • VPN-Netz (vpn_subnet_id), sofern ein eigenes VPN-Subnetz existiert
  • Beschreibung
  • mindestens die tatsächlich beteiligten Endpunkte

Unterstützte VPN-Typen:

  • WireGuard
  • IPsec
  • OpenVPN
  • SSL-VPN
  • GRE
  • Other

Unterstützte Topologien:

  • Point-to-Point
  • Hub-and-Spoke
  • Mesh
  • Remote Access
  • Other

Status:

  • Implementation
  • Production
  • Inactive
  • Obsolete

Außerbetriebnahme:

Ein nicht mehr produktives VPN sollte nicht gelöscht werden, wenn die historische Dokumentation erhalten bleiben soll.

Empfohlener Ablauf:

Status auf inactive setzen, sobald es nicht mehr verwendet wird. Endpunkte und Peers entsprechend deaktivieren. Zugriffsregeln deaktivieren. Nach endgültiger Ablösung VPN auf obsolete setzen. Beschreibung um Ablöse-/Nachfolgereferenz ergänzen, sofern erforderlich.

5. VPNEndpoint -- konkrete VPN-Instanz

Was repräsentiert ein Endpoint?

Ein VPNEndpoint ist die lokale VPN-Instanz auf einem realen System,Gerät oder Interface.

Beispiele:
  • WireGuard auf einem VPS
  • WireGuard auf OPNsense
  • IPsec-Gateway einer Firewall
  • VPN-Client eines Admin-PCs
  • VPN-Instanz eines Monitoring-Servers
Wann wird ein Endpoint angelegt?

Für jedes System bzw. jede eigenständig zu dokumentierende VPN-Instanz, die an dem VPN teilnimmt.

Wann wird kein neuer Endpoint angelegt?
Nicht für:
  • eine reine Kommunikationsfreigabe,
  • ein Zielnetz,
  • einen Port,
  • einen Dienst,
  • dieselbe lokale Instanz nur deshalb, weil mehrere Peers existieren.
Soweit vorhanden, sollten folgende Objekte verknüpft werden:
  • Location → physischer/logischer Standort
  • ConnectableCI → Host, Server, Netzwerkgerät etc.
  • IPInterface → tatsächlich verwendetes Interface
  • Software → eingesetzte VPN-Software Damit bleibt das VPN-Modell mit der übrigen CMDB verbunden.
Technisch verpflichtende Angaben:
  • Name
  • zugehöriges VPN (vpn_id)
  • Rolle
  • Endpoint-Status
Fachlich empfohlene Angaben:
  • Standort
  • CI / Host
  • IP-Interface
  • VPN-Software
  • lokale VPN-Adresse
  • Listen-Port
  • öffentlicher Endpoint
  • Public Key, sofern fachlich zulässig und sinnvoll
  • Zertifikatsreferenz bei zertifikatsbasierten Verfahren
  • Credential Provider
  • Credential-Referenz
  • Credential-Zweck
  • Beschreibung
  • Rollen

Unterstützt werden:

  • Hub
  • Gateway
  • Server
  • Client
  • Site
  • Admin
  • Monitoring
  • Security
  • Spoke
  • Other

Die Rolle soll die fachliche Funktion im VPN beschreiben, nicht den allgemeinen Gerätetyp.

6. VPNPeer -- technische Gegenstellenbeziehung

Was repräsentiert ein Peer?

VPNPeer beschreibt eine optionale technische Verbindung aus Sicht eines lokalen VPN-Endpunkts zu einer Gegenstelle.

Dies ist besonders für WireGuard sinnvoll, kann aber auch bei anderen VPN-Technologien verwendet werden.

Wann wird ein Peer angelegt?

Wenn die konkrete technische Gegenstellenkonfiguration dokumentiert werden soll, z. B.:

  • welcher Remote-Endpunkt konfiguriert ist,
  • welche Remote-Adresse bzw. welcher Port verwendet wird,
  • welche Netze über diesen Peer erreichbar sind,
  • welche Authentisierungsart verwendet wird,
  • ob Persistent Keepalive eingesetzt wird.
Wann wird kein Peer benötigt?

Wenn für den Dokumentationszweck die Endpunkte und die fachlichen Zugriffsregeln ausreichen und keine technische Peer-Konfiguration dokumentiert werden soll.

Remote-Endpunkt

Ist die Gegenstelle ebenfalls als VPNEndpoint desselben VPNs vorhanden, sollte sie über remote_endpoint_id verknüpft werden.

Dadurch wird eine bereits dokumentierte Gegenstelle wiederverwendet.

Ein Remote Public Key sollte insbesondere dann separat gepflegt werden, wenn die Gegenstelle nicht als eigener Endpoint mit Public Key modelliert ist.

Technisch verpflichtende Angaben
  • Name
  • lokaler Endpoint
  • Authentisierungstyp
  • Rolle
  • Peer-Status
  • Fachlich empfohlene Angaben
  • Remote Endpoint
  • Remote-Adresse
  • Remote-Port
  • Authentisierung
  • Remote Public Key, falls erforderlich
  • Allowed Networks
  • strukturierte TeemIP-Subnetze
  • Persistent Keepalive
  • Credential-Referenz
  • Beschreibung

Authentisierungsarten:

  • Public Key
  • Certificate
  • PSK
  • Username/Password
  • Mixed
  • None
  • Other

Wichtig: Der Wert psk dokumentiert die verwendete Authentisierungsmethode. Der PSK selbst darf nicht in iTop gespeichert werden.

7. VPNAccessRule -- fachliche Kommunikationsbeziehung

Was repräsentiert eine Zugriffsregel?

Eine VPNAccessRule dokumentiert erlaubte, gesperrte oder rein dokumentarisch erfasste Kommunikation innerhalb bzw. über ein VPN.

Sie ist keine automatische Firewall-Regel und ersetzt keine Firewall-Konfiguration.

Mögliche Quellen:
  • Quell-Endpunkt
  • Quell-Netz als Text
  • Mögliche Ziele
  • Ziel-Endpunkt
  • Ziel-CI
  • Ziel-Netz als Text
  • Weitere Angaben
  • Protokoll
  • Ports
  • Dienst
  • Aktion
  • Status
  • Beschreibung

Unterstützte Protokolle:

  • TCP
  • UDP
  • TCP/UDP
  • ICMP
  • Any
  • Other

Aktionen -> Das Dashboard zeigt die vorgesehenen Kategorien:

  • Allow
  • Deny
  • Document

Empfohlene Verwendung:

  • allow -> Eine Kommunikation ist vorgesehen bzw. freigegeben.
  • deny -> Eine explizit relevante Sperre soll dokumentiert werden.
  • document -> Die Kommunikationsbeziehung soll dokumentiert werden, ohne daraus eine Freigabeentscheidung abzuleiten.

8. TeemIP-Subnetze

Die Extension unterstützt zwei unterschiedliche Verwendungszwecke für Subnetze.

VPN-Netz am VPNTunnel vpn_subnet_id beschreibt das dem VPN selbst zugeordnete Netz.

Beispiel:

VPN: Management-VPN

VPN-Netz: 10.20.0.0/24

Erreichbare Netze am VPNPeer

Über allowed_subnets_list können vorhandene IPSubnet-Objekte strukturiert einem Peer zugeordnet werden.

Diese Beziehung wird über lnkVPNPeerToIPSubnet hergestellt.

Empfehlung:

Existiert das Netz bereits in TeemIP, sollte die strukturierte Verknüpfung verwendet werden.

allowed_networks eignet sich ergänzend für:

  • nicht in TeemIP gepflegte Netze,
  • externe Netze,
  • Sonderangaben,
  • technische Angaben, die nicht sinnvoll als IPSubnet modelliert werden können.
  • Ein vorhandenes TeemIP-Subnetz sollte nicht ausschließlich als Freitext dupliziert werden.

9. Namenskonventionen

Die folgenden Regeln sind Empfehlungen und werden vom Datenmodell nicht technisch erzwungen.

VPN

<VPN-Zweck>-<Technologie>

Beispiele:
  • Management-WireGuard
  • Standortkopplung-Werk1-RZ-IPsec
  • RemoteAccess-Administratoren

Endpoint

<System>-<VPN/Rolle>

Beispiele:
  • VPS01-WireGuard
  • OPNsense-HQ-WireGuard
  • AdminPC-Andreas
  • Prometheus-VPN
  • Wazuh-VPN

Peer

<lokaler Endpoint> -> <Gegenstelle>

Beispiele:
  • VPS01 -> Prometheus
  • VPS01 -> Wazuh
  • VPS01 -> AdminPC

Zugriffsregel

<Quelle> -> <Ziel> : <Dienst>

Beispiele:
  • Prometheus -> VPS : Node Exporter
  • VPS -> Wazuh : Wazuh Agent
  • AdminPC -> VPS : SSH

10. Beziehungen und fachliche Bedeutung

Beziehung Bedeutung

  • VPNTunnel → VPNEndpoint Teilnehmer bzw. lokale VPN-Instanzen
  • VPNTunnel → VPNAccessRule dokumentierte Kommunikationsbeziehungen
  • VPNTunnel → Organization Anbieter/Betreiber
  • VPNTunnel → IPSubnet VPN-eigenes Netz
  • VPNEndpoint → Location Standort der lokalen Instanz
  • VPNEndpoint → ConnectableCI reales System/Gerät
  • VPNEndpoint → IPInterface verwendetes Interface
  • VPNEndpoint → Software verwendete VPN-Software
  • VPNEndpoint → VPNPeer technische Peer-Konfiguration
  • VPNPeer → VPNEndpoint Gegenstelle innerhalb desselben VPNs
  • VPNPeer → IPSubnet über den Peer erreichbares TeemIP-Netz
  • VPNAccessRule → VPNEndpoint Quelle/Ziel als VPN-Teilnehmer
  • VPNAccessRule → ConnectableCI konkretes Zielsystem

11. Typische Anwendungsfälle

11.1 Site-to-Site-VPN

Ausgangssituation Zwei Standorte sind dauerhaft über IPsec oder WireGuard gekoppelt.

Vorhandene CIs:

  • Firewall Standort A
  • Firewall Standort B
  • Standorte
  • Interfaces
  • LAN-Subnetze in TeemIP

Neu anzulegen:

  • 1 × VPNTunnel
  • 2 × VPNEndpoint
  • optional technische VPNPeer-Objekte
  • relevante VPNAccessRule-Objekte

Ergebnis: Site-to-Site-VPN.webp

Typ Quelle Ziel
Endpoint / Peer Firewall-Werk-A Firewall-Werk-B
Endpoint / Peer Firewall-Werk-B Firewall-Werk-A
Access Rule LAN-A LAN-B
Access Rule LAN-B LAN-A

Vollständigkeitsprüfung:

  • beide realen Gateways verknüpft
  • Standorte gepflegt
  • VPN-Typ und Topologie gepflegt
  • relevante Netze strukturiert zugeordnet
  • Kommunikationsfreigaben dokumentiert

11.2 Remote-Access-VPN

Ausgangssituation Administratoren greifen über ein VPN auf interne Systeme zu.

Modellierung VPNTunnel: Admin-RemoteAccess ├── Endpoint: VPN-Gateway ├── Endpoint: Admin-PC-01 ├── Endpoint: Admin-Laptop-02 └── Access Rules ├── Admin-PC-01 -> Management-Netz : HTTPS/SSH └── Admin-Laptop-02 -> Management-Netz : HTTPS/SSH Die Topologie sollte remote_access verwenden.

Ein Client wird als eigener Endpoint dokumentiert, wenn er als relevanter, dauerhaft verwalteter Teilnehmer in der CMDB nachvollziehbar sein soll.

Bei einer großen, dynamischen Benutzerpopulation kann eine Einzelmodellierung jedes Clients fachlich ungeeignet sein. Das aktuelle Datenmodell enthält jedoch keine eigene Benutzer-/VPN-Zugangsgruppe; eine solche Aggregation wäre eine mögliche Erweiterung.

11.3 Management-VPN mit WireGuard

Ausgangssituation Ein zentraler VPS verbindet:

Admin-PC Prometheus/Webserver Wazuh/Security-System Das VPN dient ausschließlich Management und Monitoring.

VPNTunnel Name: Management-WireGuard VPN-Typ: WireGuard Topologie: Hub-and-Spoke Status: Production Zweck: Geschützter Management- und Monitoring-Zugriff VPN-Netz: vorhandenes TeemIP-Subnetz Endpunkte Management-WireGuard ├── VPS │ Rolle: Hub/Gateway │ ├── Admin-PC │ Rolle: Admin │ ├── Prometheus │ Rolle: Monitoring │ └── Wazuh Rolle: Security Jeder Endpoint sollte nach Möglichkeit mit seinem realen ConnectableCI, IPInterface, Location und ggf. Software verknüpft werden.

Technische Peers Am VPS können z. B. dokumentiert werden:

VPS -> Admin-PC VPS -> Prometheus VPS -> Wazuh Je nach gewünschter Dokumentationstiefe können zusätzlich die jeweiligen Gegenrichtungen modelliert werden.

Zugriffsregeln Prometheus -> VPS : Node Exporter / TCP 9100 / allow VPS -> Wazuh : Wazuh Agent / relevante Ports / allow Admin-PC -> VPS : SSH / TCP 22 / allow Admin-PC -> Grafana : HTTPS / allow Admin-PC -> Wazuh Dashboard : HTTPS / allow Die Access Rules dokumentieren die gewünschte Kommunikation. Sie ersetzen nicht die tatsächliche Firewall-Regel.

12. Peer hinzufügen

Wenn einem vorhandenen VPN ein neuer Teilnehmer hinzugefügt wird:

Prüfen, ob das reale Gerät/System bereits als CI vorhanden ist. Vorhandenes Location, ConnectableCI, IPInterface und Software wiederverwenden. Neuen VPNEndpoint im bestehenden VPNTunnel anlegen. Rolle und Status festlegen. technische Adressdaten pflegen. Credential nur als Referenz dokumentieren. erforderliche VPNPeer-Beziehungen anlegen. erreichbare TeemIP-Subnetze zuordnen. erforderliche VPNAccessRule-Objekte ergänzen. Nicht für jeden neuen Teilnehmer ein neues VPNTunnel anlegen.

13. Peer entfernen

Bei dauerhafter Entfernung eines Teilnehmers:

Peer-Verbindungen auf inactive bzw. später obsolete setzen. Endpoint auf inactive setzen. betroffene Access Rules prüfen und deaktivieren. bei endgültiger Stilllegung Endpoint auf obsolete setzen. das zugrunde liegende CI nicht löschen, wenn es unabhängig vom VPN weiter existiert.

  1. Sicherheits- und Datenschutzregeln Niemals in iTop speichern PrivateKey = ... PresharedKey = ... Password = ... Token = ... RecoveryCode = ... Zulässig Credential Provider: passbolt Credential Reference: passbolt:// Credential Purpose: WireGuard PSK VPS ↔ Admin-PC Die Extension unterstützt als Credential Provider:

none passbolt bitwarden vault itop other Die Referenz darf keine geheime Information selbst enthalten.

Public Keys können dokumentiert werden, da sie definitionsgemäß nicht geheim sind. Trotzdem sollte geprüft werden, ob betriebliche Vorgaben eine Einschränkung verlangen.

15. Vollständigkeitscheck / Definition of Done

Ein VPN gilt fachlich als ausreichend dokumentiert, wenn mindestens Folgendes nachvollziehbar ist:

Welches reale VPN wird abgebildet? Welchem Zweck dient es? Welche Technologie wird eingesetzt? Welche Topologie liegt vor? Welchen Betriebsstatus hat es? Welches VPN-Netz wird verwendet, sofern vorhanden? Wer betreibt das VPN, sofern relevant? Welche realen Endpunkte nehmen teil? Sind vorhandene CIs statt Doppelobjekten verknüpft? Sind relevante Standorte gepflegt? Sind Interfaces und Software verknüpft, sofern bekannt? Sind Rollen der Endpunkte korrekt? Sind technische Peer-Beziehungen dokumentiert, soweit erforderlich? Sind erreichbare Netze möglichst über TeemIP referenziert? Sind relevante Kommunikationsfreigaben als Access Rules dokumentiert? Sind keine Private Keys, PSKs oder Passwörter in iTop gespeichert? Verweisen Credential-Felder nur auf ein Secret-System? Stimmen Status von VPN, Endpunkten, Peers und Regeln mit der Realität überein?

16. Typische Fehlmodellierungen

Fehler: Ein VPN pro Peer Falsch:

VPN VPS-Admin VPN VPS-Prometheus VPN VPS-Wazuh wenn alle drei Verbindungen fachlich Teil desselben Management-VPNs sind.

Besser:

VPNTunnel: Management-WireGuard ├── VPS ├── Admin ├── Prometheus └── Wazuh Fehler: Gerät als Freitext duplizieren Falsch:

Endpoint Beschreibung: "läuft auf Server VPS01" obwohl VPS01 bereits als ConnectableCI existiert.

Besser:

connectableci_id -> VPS01 Fehler: vorhandenes Subnetz nur in Allowed Networks schreiben Wenn ein Netz bereits in TeemIP existiert, sollte es strukturiert verknüpft werden.

Fehler: Access Rule mit Firewall-Regel gleichsetzen VPNAccessRule dokumentiert die vorgesehene Kommunikation. Die Extension implementiert ausweislich der analysierten Dateien keine automatische Firewall-Konfiguration.

Fehler: Secrets in Credential Reference Die Credential Reference ist kein Secret-Feld.

Fehler: Public und Private Key verwechseln public_key und remote_public_key sind für öffentliche Schlüssel vorgesehen. Private Keys gehören niemals in diese Felder.

17. Vollständiges Beispiel -- WireGuard Management-VPN

Reale Situation Ein VPS bildet den zentralen WireGuard-Hub. Drei Teilnehmer verbinden sich:

Admin-PC Prometheus-Server Wazuh-Server Das Netz ist 10.20.0.0/24.

Schritt 1 -- vorhandene Objekte Vorhandene CIs werden wiederverwendet:

Server/VPS: VPS01 Server: PROM01 Server: WAZUH01 PC: ADMIN01 IPSubnet: 10.20.0.0/24 Locations: entsprechend der realen Standorte Software: WireGuard, sofern im Softwarebestand vorhanden Schritt 2 -- VPN VPNTunnel Name: Management-WireGuard VPN Type: wireguard Topology: hub_spoke VPN Status: production Purpose: Management, Monitoring und Security-Kommunikation VPN Subnet: 10.20.0.0/24 Schritt 3 -- Endpunkte VPNEndpoint: VPS01-WireGuard VPN: Management-WireGuard CI: VPS01 Role: hub Status: active Local Address: 10.20.0.1 Listen Port: Public Endpoint: <DNS/IP:Port> Credential Provider: Credential Reference:

VPNEndpoint: ADMIN01-WireGuard VPN: Management-WireGuard CI: ADMIN01 Role: admin Status: active Local Address: 10.20.0.2

VPNEndpoint: PROM01-WireGuard VPN: Management-WireGuard CI: PROM01 Role: monitoring Status: active Local Address: 10.20.0.3

VPNEndpoint: WAZUH01-WireGuard VPN: Management-WireGuard CI: WAZUH01 Role: security Status: active Local Address: 10.20.0.4 Schritt 4 -- Peers VPNPeer: VPS01 -> ADMIN01 Local Endpoint: VPS01-WireGuard Remote Endpoint: ADMIN01-WireGuard Authentication: public_key Role: management Status: active

VPNPeer: VPS01 -> PROM01 Local Endpoint: VPS01-WireGuard Remote Endpoint: PROM01-WireGuard Authentication: public_key Role: monitoring Status: active

VPNPeer: VPS01 -> WAZUH01 Local Endpoint: VPS01-WireGuard Remote Endpoint: WAZUH01-WireGuard Authentication: public_key Role: security Status: active Schritt 5 -- Zugriffsregeln VPNAccessRule Name: PROM01 -> VPS01 : Node Exporter Source Endpoint: PROM01-WireGuard Target Endpoint: VPS01-WireGuard Protocol: tcp Ports: 9100 Service: Node Exporter Action: allow Status: active Weitere Regeln werden analog für die tatsächlich zugelassenen Management- und Security-Dienste dokumentiert.

Ergebnis Management-WireGuard │ ├── VPS01-WireGuard [Hub] │ ├── Peer -> ADMIN01 │ ├── Peer -> PROM01 │ └── Peer -> WAZUH01 │ ├── ADMIN01-WireGuard [Admin] ├── PROM01-WireGuard [Monitoring] ├── WAZUH01-WireGuard [Security] │ └── Access Rules ├── PROM01 -> VPS01 : Node Exporter ├── VPS01 -> WAZUH01 : Wazuh └── ADMIN01 -> Management-Ziele : Management-Dienste