Pendant le déploiement d'Omnissa Access, l'instance d'Omnissa Access est configurée à l'intérieur du réseau interne. Si vous voulez fournir un accès au service aux utilisateurs qui se connectent à partir de réseaux externes, vous devez installer un équilibreur de charge ou un proxy inverse tel que NSX® Advanced Load Balancer, Apache, Nginx ou F5 dans la zone DMZ.
Un équilibreur de charge ou un proxy inverse est requis avant le déploiement d'Omnissa Access si vous souhaitez avoir la possibilité de dimensionner votre environnement à l'avenir. Sans cela, vous ne pourrez pas ajouter d'instances ultérieurement pour prendre en charge la redondance ou distribuer le trafic dans votre déploiement. La haute disponibilité nécessite un équilibreur de charge (les déploiements à nœud unique ne sont pas pris en charge).
Le diagramme suivant montre l'architecture de déploiement de base que vous pouvez utiliser pour activer l'accès externe.
Remarque : le même nom de domaine complet d'Omnissa Access est utilisé pour les accès interne et externe dans ce déploiement.
Spécifier le nom de domaine complet d'Omnissa Access lors du déploiement
Pendant le déploiement du dispositif Omnissa Access, vous devez utiliser un nom de domaine complet unique et le numéro de port d'Omnissa Access. Ces valeurs doivent pointer vers le nom de domaine complet auquel vous voulez que les utilisateurs finaux accèdent.
La machine Omnissa Access s'exécute toujours sur le port 443. Vous pouvez utiliser un autre numéro de port pour l'équilibreur de charge. Si vous utilisez un numéro de port différent, vous devez le spécifier au moment du déploiement. N'utilisez pas le numéro de port 8443, car il s'agit du port d'administration d'Omnissa Access qui est unique pour chaque machine d'un cluster.
Paramètres de l'équilibrage de charge à configurer
Les paramètres de l'équilibreur de charge à configurer incluent l'activation des en-têtes X-Forwarded-For et la définition correcte du délai d'expiration de l'équilibreur de charge. En outre, l'approbation SSL doit être configurée entre la machine Omnissa Access et l'équilibreur de charge.
-
En-têtes X-Forwarded-For
Vous devez activer les en-têtes X-Forwarded-For sur votre équilibrage de charge. Cela détermine la méthode d'authentification. Consultez la documentation du fournisseur de votre équilibreur de charge pour plus d'informations.
-
Délai d'expiration de l'équilibreur de charge
Pour qu'Omnissa Access fonctionne correctement, vous devrez peut-être augmenter la valeur par défaut du délai d'expiration des demandes de l'équilibreur de charge. Cette valeur est définie en minutes. Si la valeur du délai d'expiration est trop faible, l'erreur suivante peut se produire : « Erreur 502 : Le service est indisponible ».
-
Ne pas bloquer les cookies de session
Ne bloquez pas les cookies de session en ajoutant des règles à l'équilibrage de charge. L'ajout de ces règles à l'équilibrage de charge peut générer un comportement incohérent et des demandes en échec.
-
Prise en charge de WebSocket
L'équilibreur de charge doit prendre en charge WebSocket pour activer les canaux de communication sécurisés entre les instances de connecteur et les nœuds Omnissa Access.
Pour votre déploiement, si Workspace ONE Hub Services est intégré, la prise en charge de WebSocket est requise pour les notifications de Hub Services. Par conséquent, la prise en charge de WebSocket doit être prévue pour les navigateurs et les terminaux des utilisateurs finaux.
-
Chiffrements avec confidentialité persistante
Les exigences Apple iOS d'App Transport Security sont utilisées pour l'application Workspace ONE sur iOS. Pour que les utilisateurs puissent se servir de l'application Workspace ONE sur iOS, l'équilibrage de charge doit être chiffré avec confidentialité persistante. Les chiffrements suivants répondent à cette exigence :
ECDHE_ECDSA_AES et ECDHE_RSA_AES en mode GCM ou CBC
comme indiqué dans le document Sécurité iOS d'iOS 11 :
« App Transport Security fournit des exigences de connexion par défaut pour que les applications respectent les meilleures pratiques des connexions sécurisées lors de l'utilisation des API NSURLConnection, CFURL ou NSURLSession. Par défaut, App Transport Security limite la sélection de chiffrement pour inclure uniquement les suites qui fournissent une confidentialité persistante, notamment ECDHE_ECDSA_AES et ECDHE_RSA_AES en mode GCM ou CBC. »
Cette page vous a-t-elle été utile ?