Breadcrumbs

Netzwerkkonfiguration der IGEL Universal Management Suite

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

Beispiele zur Konfiguration von Reverse Proxies finden Sie unter:

Für Anleitungen zur Konfiguration eines AWS Application Load Balancers (ALB) für die Installation eines IGEL UMS Servers auf einer Amazon Elastic Compute Cloud (EC2) Instanz siehe:

UMS Netzwerkkonfigurationen

Das Diagramm zeigt eine Netzwerkkonfiguration mit möglichen Netzwerkgrenzen, an denen Netzwerkkomponenten wie Reverse Proxies, Proxies, Firewalls und Load Balancer platziert werden können.

UMS Network Configuration.png


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 zwischen Gerät und ICG / UMS

Die Kommunikation der Geräte mit der UMS oder dem ICG besteht aus zwei verschiedenen Typen: reguläre HTTPS-Aufrufe für die Gerätere­gistrierung und eine WebSocket-Verbindung mit Mutual TLS für das Gerätemanagement. Diese müssen bei der Konfiguration von Proxy, Reverse Proxy und Firewall berücksichtigt werden.

Device to UMS ICG.png

Kommunikation zwischen UMS und ICG

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

Unbenanntes Diagramm.png

Wenn eine Netzwerkkomponente zwischen diesen Servern eingesetzt wird, müssen diese Verbindungen berücksichtigt werden. Verbindungsprobleme können auftreten, wenn Deep Packet Inspection (DPI) auf einer Firewall aktiviert ist. Das Kapitel SSL Offloading gilt nur für Verbindungen zwischen Gerät und UMS / ICG. Für die Kommunikation zwischen ICG und UMS wird es nicht unterstützt.

Kommunikation über Reverse Proxy

Das Diagramm zeigt die Verbindung zwischen Gerät und UMS über eine Netzwerkkomponente wie Azure Application Gateway. Die erforderlichen Verbindungen für SSL Offloading sind aufgeführt. Das Diagramm zeigt eine HTTPS-Verbindung, die für das Onboarding (Client-Zertifikatsanforderung) erforderlich ist, sowie die anschließende WebSocket-Verbindung, bei der Mutual TLS und die Weiterleitung des Client-Zertifikats erforderlich sind.

Communication via Reverse Proxy.png

Kommunikation über Azure Application Gateway

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

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

Communication vie Azure.png


Der HTTPS-Listener für das Geräte-Onboarding kann den Standard-HTTPS-Port (443) verwenden und direkt an die UMS weiterleiten.
In diesem Beispiel lauscht der HTTPS-Listener für die WebSocket-Verbindung auf Port 8443 und verwendet Mutual TLS zur Überprüfung des Client-Zertifikats und fügt dieses dem Request-Header hinzu, sodass die UMS es überprüfen kann.

SSL Passthrough

SSL Passthrough leitet verschlüsselten HTTPS-Datenverkehr vom Client zum Server und zurück weiter, ohne ihn zu entschlüsseln oder einer Deep Packet Inspection zu unterziehen. Der HTTPS-Datenverkehr wird nicht verändert, daher sollte diese Konfiguration von Netzwerkkomponenten keine Auswirkungen auf die Funktionalität von ICG oder UMS haben. Weitere Informationen finden Sie in der Dokumentation Ihrer Webkomponente.


Beispiel

nginx – mögliche Konfiguration für Passthrough:

## 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 die nginx-Konfigurationsdatei eingefügt werden.

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 Netzwerkkomponente die SSL-Verbindung terminiert und die Daten entschlüsselt. Diese entschlüsselten Daten können direkt an den Server gesendet werden, der ebenfalls entschlüsselte Daten an die Netzwerkkomponente zurücksendet, die die Verschlüsselung übernimmt.

Die Netzwerkkomponente kann den entschlüsselten Datenverkehr auch prüfen und vor dem Weiterleiten an den Server erneut verschlüsseln. Die UMS unterstützt derzeit nur diese Art der Kommunikation mit verschlüsselten Daten. Das Diagramm zeigt die erforderlichen Schritte für SSL Offloading auf der Netzwerkkomponente in Richtung Gerät zur UMS.

SSL Offloading.png


Schritte zur Konfiguration von SSL Offloading auf einer Netzwerkkomponente:

  • Konfigurieren Sie einen Listener für die SSL-Terminierung. Dazu gehören:

    • Port: UMS Web Port

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

  • Konfigurieren Sie die Client-Zertifikatsprüfung und die Weiterleitung des Client-Zertifikats. Dazu gehören:

    • SSL Client-Zertifikatsprüfung

    • Auslesen des SSL Client-Zertifikats und Hinzufügen zu einem Forwarded Header

  • Konfigurieren Sie bei Bedarf den WebSocket Upgrade Header

Die Verarbeitung weitergeleiteter Client-Zertifikate muss auf der UMS-Seite aktiviert werden. Die 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 konfiguriert werden. Der Wert des X-SSL-CERT-Headers kann geändert werden, beachten Sie jedoch, dass der entsprechende Wert auch in der Konfiguration der Netzwerkkomponente angepasst werden muss.
Die ICG-Konfiguration ist analog, mit Ausnahme der Parameter für ICG Port, ICG Key und ICG Zertifikat.
Die Verarbeitung weitergeleiteter Client-Zertifikate muss auch auf der ICG-Seite aktiviert werden. Die Konfigurationsdatei befindet sich unter (Install Dir)/IGEL/icg/usg/conf/application-prod.yml

Erforderliche Funktionen der Netzwerkkomponente

Client-Zertifikatsprüfung und Weiterleitung

Ein OS12-Gerät verwendet zwei Arten von Verbindungen zur UMS: eine direkte HTTPS-Verbindung für das Onboarding und den Erhalt eines Client-Zertifikats sowie eine WebSocket-Verbindung für das Gerätemanagement mit Mutual TLS.
Daher muss der verwendete Reverse Proxy mindestens eine der folgenden Konfigurationsoptionen unterstützen: 

  • Die Client-Zertifikatsprüfung ist optional, sodass die Verbindung immer weitergeleitet wird, das Zertifikat jedoch nur hinzugefügt wird, wenn ein gültiges Zertifikat übermittelt wurde. Zusätzlich muss der WebSocket Upgrade unterstützt werden. 

    F5 BIG-IP Konfigurationsbeispiel:

    image-2024-2-2_10-50-9.png



  • Pfadabhängige Weiterleitung muss unterstützt werden. Der NGINX Reverse Proxy unterstützt diesen Typ. Die Auflistung zeigt eine Konfiguration für den WebSocket-Endpunkt, der ein Client-Zertifikat erfordert, dieses dem HTTP-Header hinzufügt und den WebSocket Upgrade Header ergänzt. Siehe auch NGINX Beispielkonfiguration für Reverse Proxy in IGEL OS mit SSL Offloading.

    Die andere Konfiguration wird für den Onboarding-Endpunkt benötigt.

    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 (d.h. zwei Virtual Server / Listener) auf dem Reverse Proxy / Load Balancer. Ein Endpunkt ist für das Geräte-Onboarding konfiguriert und ein weiterer für die WebSocket-Verbindung.

    Azure Application Gateway Konfigurationsbeispiel:

    image-20240508-092352.png

UMS HA Umgebung mit Reverse Proxy, Load Balancer

Die Verbindung zwischen Gerät und UMS / ICG kann lastverteilt werden.
Das UMS Web-Zertifikat und das ICG-Zertifikat müssen zur IP-Adresse oder zum Fully Qualified Domain Name der Server und der konfigurierten Netzwerkkomponente passen. Berücksichtigen Sie die Subject Alternative Names des Zertifikats. Wildcard-Zertifikate sind möglich. Achten Sie darauf, die UMS Clusteradresse und die UMS Public Address korrekt zu setzen.
Das Beispiel zeigt eine nginx-Upstream-Serverkonfiguration mit mehreren UMS-Servereinträgen.

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;
 }


HA.png

IGEL Cloud Service Konfiguration

Die Kommunikation zur IGEL Cloud kann ebenfalls durch Netzwerkkomponenten beeinflusst werden. Beim Geräte-Onboarding über den Onboarding Service muss der OBS für das Gerät erreichbar sein. Der UMS Server stellt ebenfalls Verbindungen zu den IGEL Cloud Services her. Die erforderlichen erreichbaren Dienste sind 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 konfiguriert werden. Eine Netzwerkkomponente wie eine Firewall mit aktivierter Deep Packet Inspection kann zu Verbindungsproblemen führen.

IGEL Cloud Configuration.png

UMS Endpoint-Pfade für die Reverse-Proxy-Integration

Die für OS 12 Geräteverbindungen zur UMS (über einen Reverse Proxy) erforderlichen Pfade sind:

  • 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 erfolgt immer über TLSv1.3.


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

  • /wums-app/*

  • /webapp/*

Die Gerätekommunikation erfolgt über TLSv1.2 oder TLSv1.3.