IGEL Universal Management Suite Netzwerkkonfiguration

Dieser Artikel beschreibt die Integration der Universal Management Suite (UMS) und des IGEL Cloud Gateway (ICG) mit Netzwerkomponenten wie Firewalls und Reverse Proxys.

Beispiele für die Konfiguration eines Reverse Proxys finden Sie unter:

UMS Netzwerkkonfigurationen

Das Diagramm zeigt eine Netzwerkkonfiguration mit möglichen Netzwerkgrenzen, an denen Komponenten wie Reverse Proxys, Proxys, Firewalls und Loadbalancer platziert werden können.

Typischerweise gibt es drei verschiedene Positionen für diese Komponenten:

• Gerät und ICG Server

• Gerät und UMS Server

• ICG und UMS Server

Verbindungstypen zwischen Gerät und UMS

Für eine erfolgreiche Konfiguration ist es wichtig, die verschiedenen Verbindungstypen zu verstehen.

Kommunikation vom Gerät zur ICG / UMS

Die Kommunikation der Geräte mit der UMS oder ICG besteht aus zwei verschiedenen Typen: Reguläre HTTPS-Aufrufe für die Geräteregistrierung sowie eine WebSocket-Verbindung mit gegenseitiger TLS-Authentifizierung (Mutual TLS) für das Gerätemanagement. Diese Kommunikationsarten müssen bei der Konfiguration von Proxy, Reverse Proxy und Firewall berücksichtigt werden.

Kommunikation von der UMS zum ICG

Die Kommunikation von der UMS zum ICG basiert ebenfalls auf WebSocket-Verbindungen und regulären HTTPS-Aufrufen. Jede Anfrage wird von der UMS initiiert und verwendet gegenseitige TLS-Authentifizierung (Mutual TLS). Für diese Verbindungen kann in der UMS ein HTTPS-Proxy konfiguriert werden.

Falls sich eine Netzwerkomponente zwischen diesen Servern befindet, beachten Sie die folgenden Verbindungen. Verbindungsprobleme können auftreten, wenn auf einer Firewall Deep Packet Inspection (DPI) aktiviert ist. Das Kapitel SSL-Offloading gilt ausschließlich für die Verbindung vom Gerät zur UMS / zum ICG. Es wird nicht für die Kommunikation zwischen ICG und UMS unterstützt.

Kommunikation über Reverse Proxy

Das Diagramm zeigt die Verbindung vom Gerät zur UMS über eine Netzwerkomponente wie z. B. das Azure Application Gateway. Dabei sind die für SSL-Offloading erforderlichen Verbindungen aufgeführt. Es wird eine HTTPS-Verbindung benötigt, die für das Device Onboarding (inkl. Anforderung eines Client-Zertifikats) verwendet wird. Anschließend erfolgt eine WebSocket-Verbindung, bei der Mutual TLS sowie das Weiterleiten des Client-Zertifikats erforderlich sind.

Kommunikation über Azure Application Gateway

Einige Reverse Proxys wie NGINX unterstützen eine Mutual-TLS-Konfiguration mit optionaler Client-Zertifikatsprüfung. Solche Reverse Proxys können beide für die UMS erforderlichen Verbindungen mit einem einzigen konfigurierten Listener verarbeiten. Das Azure Application Gateway unterstützt diese Funktion jedoch nicht. Die beiden verwendeten Verbindungstypen müssen separat behandelt werden. Dementsprechend muss die Konfiguration des Azure Application Gateway zwei separate Listener mit den entsprechenden Regeln enthalten.

Die UMS unterstützt die Trennung von Onboarding- und WebSocket-Verbindungen. Das folgende Diagramm zeigt eine Übersicht über die Verbindung eines Geräts zur UMS über das Azure Application Gateway.

Der HTTPS-Listener für das Device Onboarding kann den Standard-HTTPS-Port (443) verwenden und leitet die Verbindung direkt an die UMS weiter. In diesem Beispiel lauscht der HTTPS-Listener für die WebSocket-Verbindung auf Port 8443 und nutzt Mutual TLS für die Prüfung des Client-Zertifikats. Dieses Zertifikat wird dem Request Header hinzugefügt, sodass die UMS es verifizieren kann.

SSL Passthrough

SSL Passthrough leitet den verschlüsselten HTTPS-Datenverkehr vom Client zum Server und zurück ohne Entschlüsselung oder Deep Packet Inspection weiter. Da der HTTPS-Verkehr dabei nicht verändert wird, hat diese Konfiguration von Netzwerkomponenten keinen Einfluss auf die Funktionalität von ICG oder UMS. Bitte beachten Sie die Dokumentation Ihrer Web-Komponente für die entsprechenden Einstellungen.

Beispiel

nginx - eine mögliche Passthrough-Konfiguration:

CODE

## tcp LB and SSL passthrough for backend ##
stream {
	upsream umsserver{
		server 192.168.1.100:8443 max_fails=3 fail_timeout=10s;
		server 192.168.1.100:8443 max_fails=3 fail_timeout=10s;
	}
	server{
		listen 443;
		proxy_pass umsserver;
		proxy_next_upstream on;
	}
}

Die Konfiguration muss in der nginx-Konfigurationsdatei hinzugefügt werden:

CODE

user nginx;
worker_process auto;
error_log /var/log/nginx/error.log warn;
pid		  /var/run/nginx.ped;
events{
	worker_connections 1024;
}
http {
	include		/etc/nginx/mime.types;
	default_type application/octet-stream;
	sendfile	on;
	#tcp_nopush		on;
	keepalive_timeout 65;
	#gzip on;
	include/etc/nginx/conf.d/*.conf;
}
include/etc/nginx/passthrough.conf;

SSL Offloading

SSL Offloading bedeutet, dass die Netzwerkomponente die SSL-Verbindung terminiert und die Daten entschlüsselt. Die entschlüsselten Daten können direkt an den Server weitergeleitet werden. Dieser sendet seinerseits unverschlüsselte Daten an die Netzwerkomponente zurück, welche die erneute Verschlüsselung übernimmt.

Alternativ kann die Netzwerkomponente den entschlüsselten Datenverkehr inspizieren und ihn anschließend erneut verschlüsseln, bevor sie ihn an den Server weiterleitet. Die UMS unterstützt aktuell ausschließlich diese zweite Variante der Kommunikation, bei der die Daten verschlüsselt bleiben, bis sie die UMS erreichen. Das folgende Diagramm zeigt die erforderlichen Schritte für SSL Offloading auf der Netzwerkomponente in Richtung Gerät zur UMS.

Schritte zur Konfiguration von SSL Offloading auf einer Netzwerkomponente:

• Listener für die SSL-Terminierung konfigurieren. Dies umfasst:

  • Port: UMS-Web-Port

  • Schlüssel und Zertifikat: UMS-Web-Schlüssel und UMS-Web-Zertifikat

• Client-Zertifikatsprüfung und Weiterleitung konfigurieren. Dies umfasst:

  • SSL-Client-Zertifikatsprüfung aktivieren

  • SSL-Client-Zertifikat lesen und in einen Forwarded Header einfügen

• Falls erforderlich, konfigurieren Sie den WebSocket Upgrade Header

Die Verarbeitung von weitergeleiteten Client-Zertifikaten muss auf UMS-Seite aktiviert werden. Die zuständige Konfigurationsdatei ist:
(Install Dir)/IGEL/RemoteManager/rmguiserver/conf/appconfig/application.yml.

igel:
 client-cert-forwarding:
	enabled: false
	client-cert-forwarded-header: X-SSL-CERT

Setzen Sie client-cert-forwarding enabled auf true.

Der Forwarding Header kann angepasst werden. Der Standardwert ist X-SSL-CERT. Wenn dieser Wert geändert wird, muss er auch in der Konfiguration der Netzwerkomponente entsprechend angepasst werden.
Die Konfiguration auf ICG-Seite erfolgt analog zur UMS, mit Ausnahme der Parameter für Port, Schlüssel und Zertifikat des ICG.
Auch auf dem ICG muss die Verarbeitung weitergeleiteter Client-Zertifikate aktiviert werden.
Die zuständige Konfigurationsdatei befindet sich im Verzeichnis (Install Dir)/IGEL/icg/usg/conf/application-prod.yml

Erforderliche Funktionen der Netzwerkkomponente

Prüfung und Weiterleitung von Client-Zertifikaten

Ein Gerät mit IGEL OS 12 verwendet zwei Verbindungstypen zur UMS. Die erste ist eine direkte HTTPS-Verbindung, über die das Gerät registriert wird und ein Client-Zertifikat erhält. Die zweite ist eine WebSocket-Verbindung für das Gerätemanagement mit Mutual TLS.
Der eingesetzte Reverse Proxy muss mindestens eine der folgenden Konfigurationsoptionen unterstützen:

• Die Client-Zertifikat-Prüfung ist optional. Die Verbindung wird in jedem Fall weitergeleitet, jedoch wird das Zertifikat nur dann hinzugefügt, wenn ein gültiges Client-Zertifikat übermittelt wurde. Zusätzlich muss die Unterstützung für das WebSocket-Upgrade vorhanden sein.

  Beispielkonfiguration für F5 BIG-IP:

  

  
  
  

• Pfadabhängige Weiterleitung muss von der Netzwerkomponente unterstützt werden. Der NGINX Reverse Proxy unterstützt diese Art der Konfiguration. In der folgenden Auflistung wird eine Konfiguration für den WebSocket-Endpunkt gezeigt. Dieser benötigt ein Client-Zertifikat, das dem HTTP-Header hinzugefügt wird. Zusätzlich wird der WebSocket-Upgrade-Header gesetzt. Siehe auch NGINX-Beispielkonfiguration für Reverse Proxy in IGEL OS mit SSL Offloading.

Die andere Konfiguration ist für den Onboarding-Endpunkt erforderlich.

NGINX-Konfigurationsbeispiel:

# Configuration for WebSocket Endpoints
 location~/device-connector/device/(ws-connect|portforwarding) {
	proxy_pass https://umsserver;
	proxy_set_header X-SSL-CERT $ssl_client_escaped_cert;# client certificate in current connection
	proxy_set_header Upgrade $http_upgrade; #Set upgrade header
	proxy_set_header Connection $connection_upgrade;
}
#Configuration for all other endpoints
 location / {
	proxy_pass https//umsserver;
	proxy_ssl_trusted_certificate ssl/ssl-cert-chain.cer;
	proxy_ssl_protocols TLSv1.3;
}

• Konfiguration von zwei Endpunkten (also zwei virtuellen Servern oder Listenern) auf dem Reverse Proxy oder Loadbalancer. Ein Endpunkt ist für das Device Onboarding konfiguriert, der andere für die WebSocket-Verbindung.

Beispielkonfiguration für Azure Application Gateway:

UMS-HA-Umgebung mit Reverse Proxy, Loadbalancer

Die Verbindung vom Gerät zur UMS oder zum ICG kann über einen Loadbalancer verteilt werden.
Das UMS-Webzertifikat und das ICG-Zertifikat müssen zur IP-Adresse oder zum vollständig qualifizierten Domainnamen (FQDN) der Server und der konfigurierten Netzwerkkomponente passen. Dabei sind die Subject Alternative Names (SANs) des Zertifikats zu berücksichtigen. Wildcard-Zertifikate können verwendet werden. Stellen Sie sicher, dass sowohl die Cluster-Adresse der UMS als auch die öffentliche UMS-Adresse korrekt gesetzt sind.
Das Beispiel zeigt eine nginx-Upstream-Serverkonfiguration mit mehreren Einträgen für UMS Server.

upstream umsserver {
	server 192.168.27.96:8843 max_fails=3 fail_timeout=10s;
 	server 192.168.27.96:8843 max_fails=3 fail_timeout=10s;
 	server 192.168.27.96:8843 max_fails=3 fail_timeout=10s;
 }

Konfiguration des IGEL Cloud Services

Die Kommunikation mit der IGEL Cloud kann ebenfalls durch Netzwerkomponenten beeinflusst werden. Auch der UMS Server stellt Verbindungen zu den IGEL Cloud Services her. Zu den dafür erforderlichen Diensten zählen der Onboarding Service (OBS), das IGEL License Portal (ILP), das IGEL App Portal und der Insight Service. Diese Verbindungen können über einen Proxy erfolgen, müssen jedoch in der UMS entsprechend konfiguriert werden. Eine Netzwerkomponente wie eine Firewall mit aktivierter Deep Packet Inspection kann zu Verbindungsproblemen führen.

UMS Endpunktpfade für die Integration eines Reverse Proxys

Die folgenden Pfade sind für die Verbindung von IGEL OS 12-Geräten zur UMS über einen Reverse Proxy erforderlich:

• Root-Pfad: /device-connector/device/*

• Detaillierte Pfade:

  • /device-connector/device/ws-connect

  • /device-connector/device/portforwarding

  • /device-connector/device/.well-known/est/*

• App-Proxy-Pfad: /ums-appproxy/*

Die Gerätekommunikation ist immer TLSv1.3.

Falls die UMS Web App über einen Reverse Proxy genutzt werden soll, sind folgende Pfade erforderlich:

• /wums-app/*

• /webapp/*

Die Gerätekommunikation ist TLSv1.2 oder TLSv1.3.