Breadcrumbs

IGEL Universal Management Suite Netzwerkkonfiguration

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

Für Reverse-Proxy-Konfigurationsbeispiele siehe:

UMS Netzwerk-Konfigurationen

Das Diagramm zeigt eine Netzwerkkonfiguration mit möglichen Netzwerkgrenzen, wo Netzwerkkomponenten wie Reverse Proxies, Proxies, Firewalls und Loadbalancer platziert werden können.

Unknown Attachment


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

  • Gerät und ICG Server

  • Gerät und UMS Server

  • ICG und UMS Server

Verbindungsarten zwischen Gerät und UMS

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

Gerät an ICG / UMS Kommunikation

Die Kommunikation der Geräte zu UMS oder ICG besteht aus zwei verschiedenen Arten. Reguläre HTTPS-Aufrufe für die Geräteregistrierung und eine WebSocket-Verbindung mit Mutual TLS für die Geräteverwaltung. Diese müssen bei der Proxy-, Reverse-Proxy- und Firewall-Konfiguration berücksichtigt werden.

Unknown Attachment

UMS bis ICG Kommunikation

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

Unbenanntes Diagramm.png

Wenn eine Netzwerkkomponente zwischen diesen Servern platziert wird, sollten Sie auf diese Verbindungen achten. Verbindungsprobleme können auftreten, wenn die Deep Packet Inspection (DPI) in einer Firewall aktiviert ist. Das Kapitel SSL Offloading gilt nur für Verbindungen zwischen Geräten mit UMS / ICG. Es wird nicht für die Kommunikation zwischen ICG und UMS unterstützt.

Kommunikation über Reverse Proxy

Das Diagramm zeigt die Verbindung von Gerät zu UMS über eine Netzwerkkomponente wie Azure Application Gateway. Die erforderlichen Verbindungen sind für SSL Offloading aufgelistet. Das Diagramm zeigt eine HTTPS-Verbindung, die für das Onboarding des Geräts erforderlich ist (Anforderung von Client-Zertifikaten), und die folgende WebSocket-Verbindung, bei der die gegenseitige Weiterleitung von TLS und Client-Zertifikaten erforderlich ist.

Unknown Attachment

Kommunikation über Azure Application Gateway

Einige Reverse Proxies wie NGINX unterstützen eine wechselseitige TLS-Konfiguration mit optionaler Überprüfung von Client Zertifikaten. 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. Dementsprechend muss die Azure Application Gateway Konfiguration zwei separate Listener mit entsprechenden Regeln enthalten.

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

Unknown Attachment


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

SSL-Passthrough

SSL Passthrough leitet verschlüsselten HTTPS-Verkehr von einem Client zum Server und wieder zurück ohne Entschlüsselung oder Deep Packet Inspection. Der HTTPS-Verkehr wird nicht manipuliert, so dass diese Konfiguration von Netzwerkkomponenten keinen Einfluss auf die ICG- oder UMS-Funktionalität haben sollte. Die entsprechenden Einstellungen entnehmen Sie bitte der Dokumentation Ihrer Webkomponente.


Beispiel

nginx - eine mögliche Konfiguration von passthrough:

## tcp LB und SSL-Durchleitung für 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 der nginx-Konfigurationsdatei hinzugefü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 ein;
	include/etc/nginx/conf.d/*.conf;
}
include/etc/nginx/passthrough.conf;


SSL-Offloading

SSL Offloading bedeutet, dass die Netzwerkkomponente die SSL-Verbindung beendet und die Daten entschlüsselt. Diese entschlüsselten Daten können direkt an den Server gesendet werden, der die entschlüsselten Daten ebenfalls an die Netzwerkkomponente sendet, die die Verschlüsselung vornimmt.

Die Netzwerkkomponente kann den entschlüsselten Datenverkehr auch überprüfen und erneut verschlüsseln, bevor sie ihn an den Server sendet. Das UMS unterstützt bisher nur diese Art der Kommunikation mit verschlüsselten Daten. Das Diagramm zeigt die erforderlichen Aufgaben für SSL Offloading auf der Netzwerkkomponente für das Gerät in Richtung UMS.

SSL Offloading.png


Die Schritte zur Konfiguration von SSL Offloading einer Netzwerkkomponente:

  • Listener für SSL Termination konfigurieren. Dies beinhaltet:

    • Port: UMS Web Port

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

  • Konfigurieren Sie die Überprüfung von Client-Zertifikaten und die Weiterleitung von Client-Zertifikaten. Dies beinhaltet:

    • SSL-Client-Zertifikatsprüfung

    • Lesen des SSL-Client-Zertifikats und Hinzufügen zu einem weitergeleiteten Header

  • Wenn nötig, konfigurieren Sie den WebSocket Upgrade Header

Die Verarbeitung von weitergeleiteten Client Zertifikaten muss auf UMS Seite aktiviert werden. Die Konfigurationsdatei lautet
(Installationsverzeichnis)/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, aber achten Sie darauf, den entsprechenden Wert in der Konfiguration der Netzwerkkomponente zu ändern.
Die ICG-Konfiguration ist analog bis auf die Parameter ICG Port, ICG KEY und ICG Zertifikat.
Die Verarbeitung von weitergeleiteten Client Zertifikaten muss auch auf der ICG-Seite aktiviert werden.
Die Konfigurationsdatei ist (Install Dir)/IGEL/icg/usg/conf/application-prod.yml

Erforderliche Merkmale der Netzwerkkomponente

Prüfung und Weiterleitung von Client-Zertifikaten

Das OS12-Gerät verwendet zwei Arten von Verbindungen mit dem UMS. Die eine ist eine direkte https-Verbindung, um das Gerät einzubinden und ein Client-Zertifikat zu erhalten. Die andere ist eine WebSocket-Verbindung zur Verwaltung des Geräts mit gegenseitigem TLS.
So muss der verwendete Reverse Proxy mindestens eine der folgenden Konfigurationsoptionen implementieren:

  • Die Client-Zertifikat-Prüfung ist optional, so dass die Verbindung immer weitergeleitet wird, das Zertifikat aber nur hinzugefügt wird, wenn ein gültiges Zertifikat gesendet wurde. Außerdem muss das WebSocket Upgrade unterstützt werden.

    F5 BIG-IP-Konfigurationsbeispiel:

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



  • Pfadabhängige Weiterleitung Die Konfiguration muss unterstützt werden. Der NGINX Reverse Proxy unterstützt diesen Typ. Die Auflistung zeigt eine Konfiguration für den WebSocket-Endpunkt, für die das Client Zertifikat benötigt wird, fügen Sie es zum http-Header hinzu und fügen Sie den WebSocket Upgrade-Header hinzu. 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: 

    # Konfiguration für WebSocket-Endpunkte
 location~/device-connector/device/(ws-connect|portforwarding) {
	proxy_pass https://umsserver;
	proxy_set_header X-SSL-CERT $ssl_client_escaped_cert;# Client Zertifikat in der aktuellen Verbindung
	proxy_set_header Upgrade $http_upgrade; #Setzen des Upgrade-Headers
	proxy_set_header Verbinden $connection_upgrade;
}
#Konfiguration für alle anderen Endpunkte
 Standort / {
	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 virtuellen Servern / Listenern) auf dem Reverse Proxy / Loadbalancer. Ein Endpunkt wird für das Onboarding des Geräts konfiguriert und ein weiterer für die WebSocket-Verbindung.

Azure Application Gateway Konfigurationsbeispiel:

image-20240508-092352.png

UMS HA-Umgebung mit Reverse Proxy, Loadbalancer

Das Gerät zur UMS / ICG Verbindung kann lastverteilt werden.
Das UMS Web-Zertifikat und das ICG Zertifikat müssen mit der IP oder dem Fully Qualified Domain Name der Server und der konfigurierten Netzwerkkomponente übereinstimmen. Beachten Sie die Subject Alternative Names des Zertifikats. Wildcard-Zertifikate sind möglich. Achten Sie darauf, die UMS-Cluster-Adresse und die UMS-Öffentlichkeitsadresse 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-Dienst-Konfiguration

Die Kommunikation zur IGEL Cloud kann auch durch Netzwerkkomponenten beeinflusst werden. Im Falle des Geräte-Onboardings über den Onboarding Service muss der OBS für das Gerät erreichbar sein. Der UMS-Server verbindet sich ebenfalls mit den IGEL Cloud Services. Die erforderlichen erreichbaren Dienste sind hier der Onboarding Service (OBS), das IGEL License Portal (ILP), das IGEL App Portal und der Insight Service. Diese Verbindungen können über einen Proxy laufen, müssen aber in der UMS konfiguriert werden. Eine Netzwerkkomponente wie eine Firewall mit Deep Packet Inspection könnte zu Verbindungsproblemen führen.

IGEL Cloud Configuration.png

UMS Endpunktpfade für die Reverse-Proxy-Integration

Die Pfade, die für OS 12-Geräteverbindungen zum UMS (über einen Reverse-Proxy) benötigt werden, sind:

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

  • Detailpfade:

    • /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.