Telematikinfrastruktur (TI) für charly VM

Die Telematikinfrastruktur (TI) ist das digitale Gesundheitsnetzwerk für Deutschland. Die charly VM ermöglicht die Anbindung an die TI über verschiedene Verbindungsmethoden.

Überblick

Die TI-Anbindung ermöglicht:

Zugriff auf TI-Dienste (eRezept, eAU, KIM)
Sichere Kommunikation im Gesundheitswesen
Konnektor-basierte oder VPN-basierte Verbindungen

Entscheidungshilfe: Welche Konfiguration benötige ich?

Die 5 Konfigurationstypen im Überblick

Typ	Szenario	Erkennungsmerkmal	Details
1. Optimales Netzwerk	Direkter Konnektor	Konnektor im gleichen Subnetz	→ Details
2. VPN Gateway	Visionmaxx/Teleconnect	Dediziertes VPN-Gateway vorhanden	→ Details
3. Komplexe Routen	Spezielle Netzwerke	Mehrere route-add Befehle erhalten	→ Details
4. CGM Managed	Rechenzentrum	Zusätzliche IP-Adresse benötigt	→ Details
5. VPN Fallback	TIaaS/RISE	WireGuard/OpenVPN Datei erhalten	→ Details

Schnellkonfiguration

Fall 1: Optimales Netzwerk

charly-server vm set-connector

Fall 2: VPN Gateway

charly-server vm set-connector -via <vpn-gateway-ip>

Fall 3: Komplexe Routen

charly-server vm get-ti-routes
# JSON bearbeiten
charly-server vm set-ti-routes <pfad-zur-json>

Fall 4: CGM Managed

charly-server vm set-connector -Via <gateway-ip> -AdditionalIP <zusaetzliche-ip/subnet>

Fall 5: VPN Fallback

# WireGuard
charly-server vm wireguard configure /pfad/zu/wg0.conf
charly-server vm wireguard connect
charly-server vm set-connector

# OpenVPN
charly-server vm openvpn configure /pfad/zu/client.ovpn user pass
charly-server vm openvpn connect
charly-server vm set-connector

Wie erkenne ich die aktive Konfiguration?

charly-server vm test-network

Die Ausgabe zeigt:

"Konnektor direkt erreichbar" → Fall 1 (Optimales Netzwerk)
"TI-Routen über Gateway: X.X.X.X" → Fall 2 (VPN Gateway) oder Fall 3 (Komplexe Routen)
"Zusätzliche IP konfiguriert: X.X.X.X" → Fall 4 (CGM Managed)
"WireGuard aktiv" oder "OpenVPN aktiv" → Fall 5 (VPN Fallback)

Nicht unterstützte Szenarien

Manuelle Konfiguration erforderlich

Folgende Szenarien erfordern einen kostenpflichtigen Termin mit dem Fuchs-Team: - Konfiguration mehrerer separater IP-Adressen für unterschiedliche Konnektoren - Spezielle VLAN-Konfigurationen - Komplexe Firewall-Regeln auf VM-Ebene

Detaillierte Konfigurationsanleitungen

Konfiguration 1: Optimales Netzwerk (Direkter Konnektor)

Wann verwenden?

Konnektor ist direkt erreichbar (im gleichen Subnetz)
Physische Konnektoren wie Kokobox
TI-Routen werden automatisch vom Hauptgateway verwaltet
Netzwerk-Administrator hat Routen bereits korrekt konfiguriert

Voraussetzungen

Konnektor im Netzwerk erreichbar
Konnektor in charly konfiguriert
Netzwerkrouting zum Konnektor möglich

Schritt-für-Schritt Einrichtung

1. Automatische Erkennung (empfohlen)

charly-server vm set-connector

Das System:

Liest alle konfigurierten Konnektoren aus der charly-Datenbank
Testet die LDAP-Konnektivität (Port 389/636)
Wählt automatisch den ersten erreichbaren Konnektor

2. Manuelle Konfiguration (falls automatische Erkennung fehlschlägt)

charly-server vm set-connector -ip 192.168.1.50

Beispiel-JSON-Konfiguration

Wenn Sie die Routen manuell konfigurieren möchten:

ti-routes.json:

[
  {
    "to": "10.30.0.0/15",
    "via": "192.168.1.50",
    "comment": "TI RU Network direkt via Konnektor (ohne VPN Gateway)"
  },
  {
    "to": "100.102.0.0/15",
    "via": "192.168.1.50",
    "comment": "TI PU Network direkt via Konnektor (ohne VPN Gateway)"
  }
]

Verifizierung

charly-server vm test-network

Erwartete Ausgabe:

Konnektor direkt erreichbar
TI connectivity confirmed

Troubleshooting

Problem: "Konnektor nicht gefunden"

# Lösung 1: Manuell IP angeben
charly-server vm set-connector -ip <konnektor-ip>

# Lösung 2: Konnektor in charly prüfen
# Öffnen Sie charly → Stammdaten → Konnektor-Einstellungen

Konfiguration 2: VPN Gateway

Wann verwenden?

Ein dediziertes VPN-Gateway wurde bereitgestellt
Visionmaxx oder Teleconnect haben einen Windows VPN-Client installiert
Sie haben eine Gateway-IP-Adresse erhalten
TI-Provider hat ein VPN-Gateway in Ihrem Netzwerk installiert

Voraussetzungen

VPN-Gateway im Netzwerk installiert und erreichbar
Gateway-IP-Adresse bekannt
VM mit statischer IP konfiguriert (bei Verwendung des VIA-Parameters)

Statische IP erforderlich

Bei Verwendung des VIA-Parameters muss die VM eine statische IP-Adresse haben. Falls noch nicht konfiguriert: charly-server vm ip-config

Schritt-für-Schritt Einrichtung

1. Konnektor mit VPN-Gateway konfigurieren

charly-server vm set-connector -via <vpn-gateway-ip>

# Beispiel:
charly-server vm set-connector -via 10.0.0.1

2. Mit spezifischer Konnektor-IP

charly-server vm set-connector -ip 192.168.100.50 -via 10.0.0.1

Beispiel-JSON-Konfiguration

ti-routes.json:

[
  {
    "to": "192.168.100.50/32",
    "via": "10.0.0.1",
    "comment": "Konnektor-Endpunkt via VPN Gateway"
  },
  {
    "to": "10.30.0.0/15",
    "via": "10.0.0.1",
    "comment": "TI RU Network (Referenzumgebung) via VPN Gateway"
  },
  {
    "to": "100.102.0.0/15",
    "via": "10.0.0.1",
    "comment": "TI PU Network (Produktionsumgebung) via VPN Gateway"
  }
]

Verifizierung

charly-server vm test-network

Erwartete Ausgabe:

TI-Routen über Gateway: 10.0.0.1
TI connectivity confirmed

Troubleshooting

Problem: "VIA Gateway nicht erreichbar"

# Lösung: VM-Gateway anpassen
charly-server vm ip-config
# Gateway so konfigurieren, dass VIA-Gateway erreichbar wird

Konfiguration 3: Komplexe TI-Routing

Wann verwenden?

Sie haben ein Skript mit mehreren "route add" Befehlen erhalten
Spezielle Netzwerk-Anforderungen mit mehreren Routen
Abweichende TI-Netzwerkbereiche vom Standard
Standard-Routing funktioniert nicht
Spezielle Routing-Tabellen vom IT-Dienstleister erhalten

Voraussetzungen

Liste der erforderlichen Routen vom IT-Dienstleister
Verständnis der Netzwerk-Topologie
Gateway-IPs für verschiedene Netzwerksegmente

Schritt-für-Schritt Einrichtung

1. Aktuelle Konfiguration herunterladen

charly-server vm get-ti-routes

Dies öffnet automatisch einen Editor mit der aktuellen Konfiguration.

2. JSON-Datei anpassen

Bearbeiten Sie die Datei basierend auf Ihren Anforderungen.

3. Konfiguration anwenden

charly-server vm set-ti-routes <pfad-zur-json-datei>

Beispiel-JSON-Konfiguration

ti-routes.json für komplexe Netzwerke:

[
  {
    "to": "10.30.0.0/15",
    "via": "192.168.1.254",
    "comment": "TI RU Network via Router"
  },
  {
    "to": "100.102.0.0/15",
    "via": "192.168.1.254",
    "comment": "TI PU Network via Router"
  },
  {
    "to": "172.16.0.0/24",
    "via": "192.168.1.254",
    "comment": "Spezielles Konnektor-Subnetz"
  },
  {
    "to": "10.200.0.0/24",
    "via": "192.168.1.254",
    "comment": "KIM-Server Netzwerk"
  },
  {
    "to": "192.168.200.0/24",
    "via": "192.168.1.254",
    "comment": "Zusaetzliche TI-Dienste"
  }
]

Verifizierung

charly-server vm test-network

Prüfen Sie speziell:

Alle konfigurierten Routen sind aktiv
Spezielle Netzwerke erreichbar

Troubleshooting

Problem: Routen werden nicht angewendet

# Von der VM aus prüfen:
charly-server vm ssh
ip route | grep -E "(10.30|100.102)"

# Netplan manuell anwenden:
sudo netplan apply

Konfiguration 4: CGM Managed Connector

Wann verwenden?

CGM Cloud Connector oder Managed Connector im Rechenzentrum
Benötigt zusätzliche IP-Adresse für die VM
CGM hat ein Gateway-Gerät in der Praxis installiert
Bei CGM Managed Connectors, die eine separate IP für die Kommunikation benötigen

Voraussetzungen

CGM Cloud Connector in der Infrastruktur bereitgestellt
Zusätzliche IP-Adresse von CGM erhalten
CGM Gateway-IP bekannt
VM mit statischer IP konfiguriert

Wichtig

CGM muss Ihnen eine zusätzliche IP-Adresse zur Verfügung stellen. Diese IP muss im CGM-Netzsegment liegen.

Schritt-für-Schritt Einrichtung

1. Automatische Konnektor-Erkennung mit zusätzlicher IP

Windows:

charly-server vm set-connector -Via 10.10.105.254 -AdditionalIP 10.10.105.20/24

Linux/macOS:

charly-server vm set-connector via=10.10.105.254 additional-ip=10.10.105.20/24

2. Manuelle Konnektor-IP mit zusätzlicher IP

Windows:

charly-server vm set-connector -IP 172.18.4.105 -Via 10.10.105.254 -AdditionalIP 10.10.105.20/24

Linux/macOS:

charly-server vm set-connector ip=172.18.4.105 via=10.10.105.254 additional-ip=10.10.105.20/24

Was passiert bei der Konfiguration?

1. Validierung

Prüfung des Gateway-Parameters (Pflicht bei zusätzlicher IP)
Validierung des IP-Formats (CIDR-Notation erforderlich)
Gateway-Erreichbarkeit testen

2. Konfigurationserstellung

/srv/charly/config/ti-routes.json wird generiert mit:
TI RU-Netzwerk Route (10.30.0.0/15)
TI PU-Netzwerk Route (100.102.0.0/15)
Konnektor-spezifische Route mit zusätzlicher IP

3. Netzwerk-Anwendung

Generierung von /etc/netplan/60-ti-routes.yaml
Zusätzliche IP wird zum Netzwerkinterface hinzugefügt
Alle Routen werden über das angegebene Gateway konfiguriert
Konfiguration wird ohne VM-Neustart angewendet

Beispiel-JSON-Konfiguration

ti-routes.json für CGM:

[
  {
    "to": "10.30.0.0/15",
    "via": "10.10.105.254",
    "comment": "TI RU Network via CGM Gateway"
  },
  {
    "to": "100.102.0.0/15",
    "via": "10.10.105.254",
    "comment": "TI PU Network via CGM Gateway"
  },
  {
    "to": "172.18.4.105/32",
    "via": "10.10.105.254",
    "comment": "CGM Managed Connector im Rechenzentrum",
    "additional_ip": "10.10.105.20/24"
  }
]

Generierte Netplan-Konfiguration:

network:
  version: 2
  ethernets:
    enp0s1:
      addresses:
        - 10.10.105.20/24      # Zusätzliche IP für CGM
      routes:
        - to: 10.30.0.0/15
          via: 10.10.105.254
        - to: 100.102.0.0/15
          via: 10.10.105.254
        - to: 172.18.4.105/32
          via: 10.10.105.254

Verifizierung

Von Windows Host:

charly-server vm test-network

Von der VM:

# IP-Adressen prüfen
ip addr show enp0s1

# Routen prüfen
ip route | grep -E "(10.30|100.102|172.18)"

# Verbindung testen
ping -c 1 10.10.105.254  # Gateway
ping -c 1 172.18.4.105   # Konnektor

Troubleshooting

Problem: "via parameter is mandatory when using additional-ip"

Lösung: Immer Gateway mit -Via (Windows) oder via= (Linux) angeben

Problem: "When additional_ip is configured, all routes must use the same gateway"

Lösung: Alle Routen in ti-routes.json müssen dasselbe Gateway verwenden

Problem: Gateway nicht erreichbar

Konfiguration wird trotzdem angewendet
Routen werden aktiv, sobald Gateway erreichbar ist
Mit test-network Verbindung nach Netzwerk-Etablierung prüfen

Problem: Netzwerkverbindung nach Konfiguration verloren

System hat automatisches Rollback bei Verbindungsverlust
Prüfen, dass zusätzliche IP nicht mit bestehender Konfiguration kollidiert

Konfiguration vollständig entfernen:

# Alle TI-Routen und zusätzliche IPs löschen
sudo rm /srv/charly/config/ti-routes.json
sudo rm /etc/netplan/60-ti-routes.yaml
sudo netplan apply

Wichtige Hinweise

Zusätzliche IP wird auf demselben Interface (enp0s1) wie primäre IP angewendet
Alle TI-Routen MÜSSEN bei zusätzlicher IP dasselbe Gateway verwenden
Konfiguration bleibt über VM-Neustarts erhalten
Änderungen werden sofort ohne VM-Neustart angewendet
Die 60-ti-routes.yaml wird automatisch verwaltet - nicht manuell bearbeiten
Hinweis: Alle Routen mit additional_ip müssen das gleiche Gateway verwenden

Konfiguration 5: VPN Fallback (WireGuard/OpenVPN)

Wann verwenden?

Teleconnect kann kein VPN-Gateway installieren
Sie haben eine WireGuard (.conf) oder OpenVPN (.ovpn) Konfigurationsdatei erhalten
Die VM soll die gleiche VPN-Verbindung wie der Host nutzen
Als Fallback-Lösung, wenn kein dediziertes VPN-Gateway verfügbar ist
Bei TI-as-a-Service (TIaaS) Providern wie RISE

Voraussetzungen

Statische IP erforderlich

VPN-Tunnel benötigen eine statische IP-Konfiguration der VM. Falls noch nicht konfiguriert: charly-server vm ip-config

Exklusivität

WireGuard und OpenVPN können nicht gleichzeitig verwendet werden. Beim Konfigurieren eines VPN-Typs muss eine eventuell vorhandene Konfiguration des anderen Typs zuerst deinstalliert werden.

WireGuard (empfohlen für neue Installationen)

WireGuard ist eine moderne, schnelle und einfache VPN-Lösung mit state-of-the-art Kryptographie.

Voraussetzungen

WireGuard-Konfigurationsdatei (.conf) vom TI-Provider. Dies muss eine neue Datei sein speziell für die charly-VM.
Keine zusätzlichen Zugangsdaten erforderlich (Authentifizierung über Schlüssel)
Ausgehende UDP-Verbindungen zum WireGuard-Port erlaubt (meist 51820)

Schritt-für-Schritt Einrichtung

0. WireGuard Konfiguration vom TI-Provider erstellen lassen:

Die charly-VM benötigt eine eigene WireGuard Konfiguration. Daher muss der TI-Provider ein eigenes Paket für die VM erstellen und zur Verfügung stellen. Die Konfiguration des Windows/macOS Hosts darf nicht doppelt verwendet werden.

1. WireGuard konfigurieren:

Windows:

charly-server vm wireguard configure C:\pfad\zu\wg0.conf

macOS/Linux:

charly-server vm wireguard configure /pfad/zu/wg0.conf

RISE-TIGW Integration

Bei RISE-TIGW Paketen verwenden Sie die mitgelieferte VPN_000001.conf:

charly-server vm wireguard configure /pfad/zu/RISE-TIGW_Paket_*/VPN_000001.conf

Vorherige set-connector Konfiguration

Sollte bereits eine TI-Routen Konfiguration mittels charly-server vm set-connector erfolgt sein, so muss diese entfernt werden.

2. Verbindung herstellen:

charly-server vm wireguard connect

3. Status prüfen:

charly-server vm wireguard status

Die Ausgabe zeigt:

Verbindungsstatus
VPN-IP-Adresse
Endpoint-Informationen
Letzter Handshake
Übertragungsstatistiken

4. Konnektor automatisch erkennen:

charly-server vm set-connector

5. Verbindung trennen:

charly-server vm wireguard disconnect

6. Konfiguration vollständig entfernen:

charly-server vm wireguard uninstall

OpenVPN

OpenVPN ist eine bewährte, flexible VPN-Lösung mit breiter Kompatibilität.

Voraussetzungen

OpenVPN-Konfigurationsdatei (.ovpn)
Zugangsdaten vom TI-Provider
Ausgehende VPN-Verbindungen erlaubt

Schritt-für-Schritt Einrichtung

1. VPN konfigurieren:

Windows:

$password = Read-Host -AsSecureString "Passwort"
charly-server vm openvpn configure -ConfigFilePath C:\vpn\client.ovpn -Username user -Password $password

macOS/Linux:

charly-server vm openvpn configure /path/to/client.ovpn username password

2. Verbindung herstellen:

charly-server vm openvpn connect

3. Status prüfen:

charly-server vm openvpn status

4. Konnektor automatisch erkennen:

charly-server vm set-connector

5. Verbindung trennen:

charly-server vm openvpn disconnect

6. Konfiguration vollständig entfernen:

charly-server vm openvpn uninstall

Auto-Reconnect (beide VPN-Typen)

Die VM überwacht die VPN-Verbindung automatisch alle 5 Minuten und stellt sie bei Bedarf wieder her:

Verbindungsstatus wird geprüft
Bei Verbindungsverlust automatische Neuverbindung
Ereignisse werden protokolliert:
WireGuard: /var/log/wireguard/health.log
OpenVPN: /var/log/openvpn-health.log

RISE-TIGW spezifische Integration

Bei Verwendung des RISE TI-Gateway Pakets:

Dateien im RISE-Paket:
VPN_000001.conf: WireGuard-Konfiguration (erforderlich)

Automatische Konnektor-Erkennung:

# WireGuard einrichten mit RISE-Konfiguration
charly-server vm wireguard configure /pfad/zu/VPN_000001.conf
charly-server vm wireguard connect

# Konnektor wird automatisch erkannt (aus charly-Datenbank)
charly-server vm set-connector

Routing: Die WireGuard-Konfiguration enthält bereits alle notwendigen TI-Routen in den AllowedIPs.

Troubleshooting VPN-Verbindungen

WireGuard-Probleme

Status prüfen:

charly-server vm wireguard status

Logs prüfen:

charly-server vm ssh
sudo journalctl -u charly-wireguard -f

Manuelle Neuverbindung:

charly-server vm wireguard disconnect
charly-server vm wireguard connect

OpenVPN-Probleme

Status prüfen:

charly-server vm openvpn status

Logs prüfen:

charly-server vm ssh
sudo tail -f /var/log/openvpn.log

Manuelle Neuverbindung:

charly-server vm openvpn disconnect
charly-server vm openvpn connect

Problem: "OpenVPN/WireGuard blockiert set-connector"

# Lösung: Erst VPN entfernen
charly-server vm openvpn uninstall
# oder
charly-server vm wireguard uninstall

# Dann Konnektor konfigurieren
charly-server vm set-connector

Empfehlung

Für neue Installationen und TIaaS-Umgebungen empfehlen wir WireGuard aufgrund der besseren Performance und einfacheren Konfiguration. OpenVPN sollte nur verwendet werden, wenn spezielle Anforderungen dies erfordern oder bestehende Infrastruktur dies vorgibt.

Gemeinsame Funktionen und Referenz

TI-Routing Grundlagen

Netzwerkbereiche

Die TI verwendet spezielle IP-Bereiche gemäß gematik-Spezifikation:

Bereich	CIDR	IP-Range	Beschreibung
RU (Referenzumgebung)	10.30.0.0/15	10.30.0.0 - 10.31.255.255	Test- und Referenzumgebung
PU (Produktionsumgebung)	100.102.0.0/15	100.102.0.0 - 100.103.255.255	Produktive TI-Dienste und offene Fachdienste

Routing-Konfiguration

Das System richtet automatisch die erforderlichen Routen ein:

Bei Konnektor-Konfiguration: Routen via Konnektor-IP
Bei OpenVPN: Routen werden vom VPN-Gateway gepusht
Bei WireGuard: Routen über AllowedIPs konfiguriert

Vereinfachte TI-Prüfung

Die VM prüft die TI-Erreichbarkeit mit einem zweistufigen Ansatz:

Primärtest: Direkter Test des TI-IDP Endpoints

https://idp.zentral.idp.splitdns.ti-dienste.de/.well-known/openid-configuration

Fallback: Nur wenn der IDP-Endpoint nicht erreichbar ist:
Suche nach PU-Routen (100.102.0.0/15)
Warnung bei Abweichung von der gematik-Spezifikation
Hinweis zur Klärung mit TI-Provider

JSON-Schema für ti-routes.json

Wichtige Felder:

to: Zielnetzwerk in CIDR-Notation (z.B. "10.30.0.0/15")
via: Gateway-IP für die Route
comment: Beschreibung der Route (optional aber empfohlen)
additional_ip: Zusätzliche IP für die VM (nur bei CGM-Szenarien)

Allgemeines Format:

[
  {
    "to": "NETZWERK/CIDR",
    "via": "GATEWAY-IP",
    "comment": "Beschreibung",
    "additional_ip": "IP/CIDR"  // Optional, nur bei CGM
  }
]

Netzwerk-Diagnose

Umfassender Netzwerktest

charly-server vm test-network

Testet automatisch:

Netzwerk-Konfiguration: IP-Adresse, Gateway, DNS
Grundlegende Konnektivität: Gateway, DNS, Internet
TI-Routing: RU/PU-Routen und TI-Endpunkte
Konnektor-Verbindungen: Erreichbarkeit konfigurierter Konnektoren
KIM-Verbindungen: POP3/SMTP-Endpoints

Anwendungsfälle

Nach Netzwerk-Änderungen: Validierung neuer Konfigurationen
Bei Verbindungsproblemen: Schnelle Fehlerdiagnose
Nach Konnektor-Konfiguration: Überprüfung der Einrichtung
Regelmäßige Überprüfung: Proaktive Wartung

Konnektortausch

Bei einem Konnektorwechsel in der Praxis:

1. Neuen Konnektor in charly einrichten

Detaillierte Anleitung in der charly-Hilfe

2. Konnektor-Konfiguration aktualisieren

charly-server vm set-connector

Oder bei speziellen Routing-Anforderungen:

charly-server vm set-connector -ip <neue_ip> -via <router_ip>

3. KIM Client Modul anpassen

Wichtig

Das KIM Client Modul muss separat auf den neuen Konnektor umgestellt werden. Dies liegt außerhalb der Verantwortung von charly-server.

4. Funktionsprüfung durchführen

Netzwerk-Test:
```
charly-server vm test-network
```
TI-Monitor prüfen: Überprüfen Sie im TI-Monitor, ob der neue Konnektor erkannt wird.
eRezept-Test: Erstellen Sie ein Test-eRezept zur Validierung.
KIM-Test: Senden Sie eine KIM-Testmail.

Verifizierung: Läuft mein System korrekt?

Schnell-Check nach der Konfiguration

# 1. Netzwerk-Test
charly-server vm test-network

# 2. TI-Monitor in charly prüfen
# Öffnen Sie charly und navigieren Sie zum TI-Monitor

# 3. Test-eRezept erstellen (optional)
# In charly ein Test-Rezept erstellen

# 4. KIM-Testmail senden (optional)
# Eine Test-KIM-Nachricht versenden

Erfolgs-Indikatoren

✅ System läuft korrekt wenn:

test-network zeigt "TI connectivity confirmed"
Konnektor wird im TI-Monitor als "erreichbar" angezeigt
eRezepte können signiert werden
KIM-Nachrichten können gesendet/empfangen werden

⚠️ Konfiguration prüfen wenn:

test-network zeigt Fehler bei TI-Routen
Konnektor im TI-Monitor als "nicht erreichbar" erscheint
Timeout-Fehler beim Signieren auftreten

Allgemeines Troubleshooting

TI-Dienste nicht erreichbar

Netzwerktest durchführen:
```
charly-server vm test-network
```
Bei fehlenden Routen:
Konnektor-Konfiguration prüfen
Bei VPN: Verbindungsstatus prüfen mit wireguard status oder openvpn status
Bei abweichenden Routen:
Prüfen ob PU-Route vom Standard (100.102.0.0/15) abweicht
Mit TI-Provider klären

Konnektor nicht erreichbar

Ping-Test:
```
ping <konnektor-ip>
```
Port-Test (LDAP):
```
telnet <konnektor-ip> 389
```
Alternative Konnektoren: Falls mehrere Konnektoren konfiguriert sind, testet die automatische Erkennung alle.

Best Practices

Sicherheit

Zugangsdaten: VPN-Passwörter sicher verwahren
Konfigurationsdateien: .ovpn und .conf Dateien vertraulich behandeln
Netzwerktrennung: TI-Traffic vom regulären Netzwerk trennen

Wartung

Regelmäßige Tests: Wöchentlicher test-network empfohlen
Backup vor Änderungen: Vor Konnektor-Wechsel Backup erstellen
Dokumentation: Netzwerk-Topologie und Routing dokumentieren

Performance

Route-Optimierung: Direkte Routen bevorzugen
VPN nur bei Bedarf: VPN nur wenn kein Konnektor direkt verfügbar
Monitoring: Verbindungslogs regelmäßig prüfen

Weiterführende Informationen

Version: 2.7.1

Datum der letzten Aktualisierung: 16.10.2025

Version: 2.7.0