Skip to main content

17 septembre 2026

Utilisation d'un équilibreur de charge ou d'un proxy inverse pour activer l'accès externe à Omnissa Access

Pendant le déploiement d'Omnissa Access, l'instance d'Omnissa Access est configurée à l'intérieur du réseau interne. Un équilibreur de charge ou un proxy inverse, comme Unified Access Gateway, NSX® Advanced Load Balancer™, Apache ou Nginx, est un composant requis de chaque déploiement d'Omnissa Access et doit être installé dans la zone DMZ avant de commencer le déploiement.

L'équilibreur de charge ou le proxy inverse fournit le point d'entrée unique nécessaire pour dimensionner votre environnement dans le temps, ajouter des instances pour la redondance et 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.

Capture d'écran de proxy d'équilibreur de charge externe avec des machines virtuelles

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.

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 (ATS) 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'équilibreur de charge utilise des chiffrements qui fournissent une confidentialité persistante. Les suites de chiffrements suivants répondent à l'exigence suivante :

    • ECDHE_ECDSA_AES et ECDHE_RSA_AES en mode GCM (AES-GCM avec SHA-256/384)
    • Toute suite de chiffrement TLS 1.3 (toutes les suites TLS 1.3 sont conçues pour fournir une confidentialité persistante)

    Comme indiqué dans la documentation de sécurité de la plate-forme Apple :

    « Par défaut, App Transport Security limite la sélection de chiffrements pour inclure uniquement les suites qui fournissent une confidentialité persistante, notamment ECDHE_ECDSA_AES et ECDHE_RSA_AES en mode Galois/compteur (GCM)… Les serveurs doivent prendre en charge TLS 1.2 et la confidentialité persistante, et les certificats doivent être valides et signés à l'aide de SHA-256 ou d'une sécurité renforcée avec une clé RSA de 2 048 bits au minimum ou une clé de courbe elliptique de 256 bits. »

Cette page vous a-t-elle été utile ?

Envoyer un commentaire sur cette rubrique

Cette rubrique vous a-t-elle été utile ?

N'indiquez aucune information personnelle ou confidentielle.

Génération du lien…