Composants requis pour l’accès des utilisateurs externes
Dernière rubrique modifiée : 2012-10-17
La plupart des composants de périphérie sont déployés sur un réseau de périmètre (également connu sous l’appellation de sous-réseau filtré ou DMZ). Les deux composants suivants forment la topologie de périphérie du réseau de périmètre. Sauf indication contraire, les composants sont inclus dans les trois architectures de référence et sont présents dans le réseau de périmètre. Ces composants de périphérie sont les suivants :
Serveur(s) Edge
Proxy inverse
Équilibrage de la charge pour les topologies Edge mises à l’échelle (avec charge DNS équilibrée ou un programme d’équilibrage de la charge matérielle)
Pare-feu
Directeur (dans un réseau interne)
Serveur Edge
Le serveur Edge contrôle le trafic traversant le pare-feu et l’utilisation du déploiement interne par les utilisateurs externes. Il exécute les services suivants :
Service Edge d’accès Le service Edge d’accès fournit un point de connexion unique sécurisé qui est utilisé pour le trafic SIP (Session Initiation Protocol) à la fois sortant et entrant.
Service Edge de conférence web Le service Edge de conférence web permet aux utilisateurs externes de participer à des réunions organisées au sein de votre déploiement Microsoft Lync Server 2010 interne.
Service Edge A/V Le service Edge A/V rend l’audio, la vidéo, le partage d’applications et le transfert de fichiers accessibles aux utilisateurs externes. Vos utilisateurs peuvent ajouter l’audio et la vidéo aux réunions qui incluent des participants externes et les partager directement avec un utilisateur externe dans des sessions point à point. Le service Edge A/V fournit également une prise en charge pour le partage du Bureau et le transfert de fichiers.
Les utilisateurs externes autorisés peuvent accéder aux serveurs Edge pour se connecter à votre déploiement Lync Server interne. Toutefois, les serveurs Edge ne donnent pas accès au réseau interne.
.gif "note") Remarque : |
|---|
| Les serveurs Edge sont déployés pour fournir des connexions pour les clients Lync et les autres serveurs Edge (comme dans les scénarios de fédération). Ils ne sont pas conçus pour autoriser les connexions d’autres types de client d’extrémité ou de serveur. Le serveur de passerelle XMPP peut être déployé pour autoriser les connexions avec les partenaires XMPP configurés. Le serveur Edge et la passerelle XMPP peuvent uniquement prendre en charge les connexions d’extrémité à partir de ces types de client et de fédération. |
Proxy inverse
Un proxy inverse est un composant d’infrastructure requis pour la plupart des scénarios que vous activez dans le cadre de Microsoft Lync Server 2010. La majorité des déploiements utilisent le proxy inverse existant que vous avez déjà installé et configuré dans votre organisation. En général, de nouvelles règles de publication seront requises et aucune modification ne doit être apportée à vos règles de serveur proxy existantes. Les certificats mis à jour ou nouveaux sont courants pour gérer les nouvelles règles de publication. Les types de proxy inverse incluent notamment :
Microsoft Internet and Acceleration Server (ISA) 2006 avec Service Pack 1
La configuration d’une passerelle Microsoft Threat Management Gateway 2010 de base est utilisée pour l’exemple de déploiement dans Déploiement des serveurs Edge. Microsoft Threat Management Gateway 2010 et Microsoft Internet and Acceleration Server (ISA) 2006 avec Service Pack 1 sont semblables en termes de configuration de la publication pour Lync Server 2010. Pour plus d’informations, voir Configurer les règles de publication Web pour un pool interne unique dans la documentation de déploiement.
Microsoft Threat Management Gateway (TMG) 2010
Pour plus d’informations sur la configuration de Microsoft Threat Management Gateway (TMG) 2010 en tant que proxy inverse pour votre déploiement Lync Server 2010, voir Configurer les règles de publication Web pour un pool interne unique dans la documentation de déploiement.
Serveurs proxy inverse tiers qui peuvent être configurés pour publier du contenu HTTP et HTTPS interne
Pare-feu tiers qui permettent de publier du contenu HTTP et HTTPS interne
D’autres appareils et équipements non répertoriés, tels que les programmes d’équilibrage de la charge matérielle et les équipements de moteur de contenu HTTP peuvent aussi être en mesure de fournir les fonctions requises.
Pour obtenir des informations sur la configuration d’appareils, serveurs et équipements tiers, voir la documentation du fournisseur tiers sur la configuration de la publication.
.gif "important") Important : |
|---|
| La colocalisation du serveur Edge et d’un proxy inverse n’est pas une option de configuration valide. Le serveur Edge doit rester un rôle à usage unique pour gérer les fonctionnalités de protocole d’initiation de session, de conférence web et audio/vidéo (ainsi que d’autres types de média) pour votre déploiement. |
Le proxy inverse est requis pour les actions suivantes :
permettre aux utilisateurs de participer à des réunions ou à des conférences à distance via des URL simples ;
permettre aux utilisateurs externes de télécharger le contenu de réunions ;
permettre aux utilisateurs externes de développer des groupes de distribution ;
permettre à l’utilisateur d’obtenir un certificat utilisateur pour l’authentification basée sur un certificat client ;
permettre aux utilisateurs distants de télécharger des fichiers à partir du serveur de carnet d’adresses ou soumettre des requêtes au service de requête web du carnet d’adresses ;
permettre aux utilisateurs distants d’obtenir des mises à jour de logiciels clients et de périphériques ;
permettre aux appareils mobiles de découvrir automatiquement les serveurs frontaux qui proposent des services de mobilité ;
permettre d’envoyer des notifications push aux appareils mobiles depuis les services de notification push Office 365 ou Apple.
| Remarque : |
|---|
| Les utilisateurs externes ne doivent pas nécessairement disposer d’une connexion VPN à votre organisation pour participer aux communications basées sur Lync Server. Ceux connectés au réseau interne de votre organisation via un VPN contournent le proxy inverse. |
Pare-feu
Vous pouvez déployer votre topologie de périmètre avec un seul pare-feu externe ou un pare-feu interne et un pare-feu externe. Les architectures de référence incluent deux pare-feu. Il est recommandé d’utiliser deux pare-feu pour garantir le routage strict d’un côté du réseau à l’autre et protéger votre déploiement interne derrière deux niveaux de pare-feu.
Directeur
Dans Lync Server 2010, un directeur constitue un rôle serveur distinct dans Lync Server 2010 qui n’héberge pas de comptes d’utilisateur ni ne fournit d’informations de présence ou de services de conférence. À la place, il peut servir de serveur du tronçon suivant interne vers lequel un serveur Edge achemine le trafic SIP entrant destiné aux serveurs internes. Le directeur authentifie les requêtes entrantes et les redirige vers le pool ou le serveur central de l’utilisateur.
Si votre organisation prévoit d’activer l’accès externe, nous vous recommandons de déployer un directeur. En authentifiant le trafic SIP entrant qui provient des utilisateurs distants, le directeur décharge les serveurs frontaux du pool de la charge supplémentaire occasionnée par les procédures d’authentification des utilisateurs distants. Il aide aussi à isoler les serveurs centraux et les pools de serveurs frontaux du trafic malveillant, tel que les attaques par déni de service. Si le réseau est inondé par du trafic externe non valide dans le cadre d’une telle attaque, tout ce trafic s’arrête au niveau du directeur et les utilisateurs internes ne devraient observer aucune incidence sur les performances. Pour plus d’informations sur l’utilisation des directeurs, voir Directeur.
Programmes d’équilibrage de la charge matérielle
La topologie Edge consolidée et mise à l’échelle de Lync Server 2010 est optimisée pour l’équilibrage de la charge DNS des nouveaux déploiements fédérés principalement avec d’autres organisations qui utilisent Lync Server 2010. Si, dans l’un des scénarios suivants, la haute disponibilité est requise, vous devez utiliser un programme d’équilibrage de la charge matérielle sur les pools de serveurs Edge pour prendre en charge ce qui suit :
fédération avec des entreprises qui utilisent Office Communications Server 2007 R2 ou Office Communications Server 2007 ;
messagerie unifiée Exchange pour les utilisateurs distants ;
connectivité avec les utilisateurs de solution PIC.
Pour savoir si votre programme d’équilibrage de la charge matérielle prend en charge les fonctionnalités requises par Lync Server 2010, voir « Partenaires d’équilibrage de la charge de Lync Server 2010 », à l’adresse https://go.microsoft.com/fwlink/?linkid=202452&clcid=0x40C.
Conditions requises pour le programme d’équilibrage de la charge matérielle du proxy inverse : remarques générales
Le mode DNAT (Destination Network Address Translation), qui utilise l’adresse IP de destination entrante de l’adresse IP virtuelle (VIP) du programme d’équilibrage de la charge, est converti en adresse IP de destination du serveur. Votre fournisseur de programme d’équilibrage de la charge peut suggérer l’utilisation du mode SNAT (Source Network Address Translation). Examinez attentivement le type de traduction d’adresses réseau utilisé, et notez qu’il est unique au programme d’équilibrage de la charge matérielle et est une relation entre l’adresse IP virtuelle (VIP) du programme d’équilibrage de la charge matérielle et les serveurs hébergés. Il est différent de la traduction d’adresses réseau gérée au niveau des pare-feux de périmètre.
Utilisez l’affinité des sources (également appelée affinité TCP, voir la documentation du fournisseur). Le trafic d’une seule session doit être associé à la même destination (le serveur). Dans le cas de sessions multiples à partir d’une seule source, les sessions peuvent êtres associées à différents serveurs de destination, en utilisant l’affinité des sources pour fournir l’état de la session.
À moins que d’autres informations (besoins en termes de performances, définitions de test, normes ou documentation du fournisseur) le dictent, le délai d’inactivité TCP doit être défini sur 30 minutes (1 800 secondes).
.gif "warning") Avertissement : |
|---|
| Vous ne pouvez pas utiliser l’équilibrage de la charge DNS sur une interface et l’équilibrage de la charge matérielle sur une autre. Sur les deux interfaces, vous devez utiliser soit l’équilibrage de la charge matérielle, soit l’équilibrage de la charge DNS. Il n’est pas possible de combiner les deux. |
| Remarque : |
|---|
| Si vous utilisez un programme d’équilibrage de la charge matérielle, celui déployé pour les connexions au réseau interne doit être configuré pour équilibrer uniquement la charge liée au trafic en direction du service d’accès Edge et au service Edge A/V. Celui-ci ne peut pas équilibrer la charge du trafic vers le service Edge de conférence web. |
| Remarque : |
|---|
| La fonctionnalité DSR (Direct Server Return) NAT n’est pas prise en charge avec Lync Server 2010. |
Conditions requises pour le programme d’équilibrage de la charge matérielle des serveurs Edge exécutant le service Edge A/V
Les conditions requises pour le programme d’équilibrage de la charge matérielle des serveurs Edge exécutant le service Edge A/V sont spécifiées ci-après :
Désactivez le nagling TCP pour les ports internes et externes 443. Le nagling est le processus qui consiste à combiner plusieurs petits paquets en un seul paquet plus volumineux, afin de rendre la transmission plus efficace.
Désactivez le nagling TCP pour la plage de ports externes 50 000 – 59 999.
N’utilisez pas NAT sur le pare-feu interne ou externe.
L’interface interne Edge doit se trouver sur un autre réseau que l’interface externe Edge Server, et le routage entre elles doit être désactivé.
L’interface externe du serveur Edge exécutant le service Edge A/V doit utiliser les adresses IP routables publiquement, mais aucune NAT ou traduction de port sur n’importe quelle adresse IP externe Edge.
Conditions requises pour le programme d’équilibrage de la charge matérielle des services web
Les conditions requises pour le programme d’équilibrage de la charge matérielle des services web du directeur et du pool de serveurs frontaux sont spécifiées ci-après :
Pour les adresses IP virtuelles (VIP) des services web externes, définissez la persistance basée sur les cookies selon chaque port pour les ports externes 4443, 8080 sur le programme d’équilibrage de la charge matérielle. Pour Lync Server 2010, la persistance basée sur les cookies signifie que plusieurs connexions issues d’un seul client sont toujours envoyées à un seul serveur pour maintenir l’état de la session. Pour configurer la persistance basée sur les cookies, le programme d’équilibrage de la charge doit déchiffrer et rechiffrer le trafic SSL. Par conséquent, tout certificat affecté au nom de domaine complet (FQDN) des services web externes doit se voir aussi attribuer l’adresse IP virtuelle (VIP) 4443 du programme d’équilibrage de la charge matérielle.
Pour les adresses IP virtuelles (VIP) des services web, définissez la persistance Source_addr (port interne 80, 443) sur le programme d’équilibrage de la charge matérielle. Pour Lync Server 2010, la persistance Source_addr (adresse source) signifie que plusieurs connexions issues d’une seule adresse IP sont toujours envoyées à un seul serveur pour maintenir l’état de la session.
Utilisez un délai d’inactivité TCP de 1 800 secondes.
Sur le pare-feu situé entre le proxy inverse et le programme d’équilibrage de la charge matérielle du pool du tronçon suivant, créez une règle autorisant le trafic https: sur le port 4443, entre le proxy inverse et le programme d’équilibrage de la charge matérielle. Le programme d’équilibrage de la charge matérielle doit être configuré pour écouter sur les ports 80, 443 et 4443.