Acheminement avec ExpressRoute pour Office 365

Important :  Cet article a été traduit automatiquement, voir l’avertissement. Vous pouvez consulter la version en anglais de cet article ici.

Pour bien comprendre le routage du trafic vers Office 365 à l’aide d’Azure ExpressRoute, vous devez bien connaître la Configuration requise pour le routage ExpressRoute ainsi que les Circuits ExpressRoute et domaines de routage. Ces articles énoncent les principes fondamentaux de l’utilisation d’ExpressRoute dont les clients Office 365 dépendront.

Voici quelques aspects clés abordés dans les articles ci-dessus que vous devez comprendre :

  • Les circuits ExpressRoute ne sont pas mappés à une infrastructure physique spécifique, mais Microsoft et un fournisseur d’homologation établissent pour vous une connexion logique à un emplacement d’homologation unique.

  • Il existe un mappage 1:1 entre un circuit ExpressRoute et une clé système du client.

  • Chaque circuit peut prendre en charge jusqu’à 3 relations d’homologation indépendantes (Public Azure, Privé Azure privé et Microsoft). Office 365 requiert l’homologation Microsoft.

  • Chaque circuit présente une bande passante fixe qui est partagée entre toutes les relations d’homologation.

  • L’ensemble des adresses IPv4 publiques et numéros AS qui seront utilisés pour le circuit ExpressRoute doivent être validés comme vous appartenant ou vous étant attribué exclusivement par le propriétaire de la plage d’adresses.

  • Les circuits ExpressRoute eux-mêmes sont globalement redondants et suivent des pratiques de routage BGP standard.

Pour plus d’informations sur les services pris en charge, les coûts et les détails de la configuration, voir la page Forum Aux Questions. Pour plus d’informations sur la liste des fournisseurs de connectivité prenant en charge l’homologation Microsoft, voir l’article sur les emplacements ExpressRoute. Nous avons également enregistré la série Formation sur Azure ExpressRoute pour Office 365 en 10 épisodes sur Channel 9 pour vous aider à bien comprendre les concepts.

Remarque : Azure ExpressRoute pour Office 365 ne fonctionne pas encore avec le protocole IPv6. Vous devez désactiver le protocole IPv6, sans quoi la connexion l’utilisera par défaut au lieu d’utiliser la connexion ExpressRoute.

L’infrastructure qui accepte le trafic du client pour les applications Office 365 est accessible via Internet et ExpressRoute, ou via plusieurs circuits ExpressRoute. Le trafic réseau d’Office 365 vers le réseau du client traverse ExpressRoute quand Internet et ExpressRoute sont disponibles. Cela introduit la possibilité d’une asymétrie d’itinéraire si le trafic en provenance du réseau du client préfère emprunter l’itinéraire Internet. Les itinéraires asymétriques sont problématiques parce que des appareils qui exécutent une inspection des paquets avec état peuvent bloquer un trafic de retour suivant un chemin différent de celui suivi par les paquets sortants.

Quand un ordinateur de client établit une connexion à Office 365 via Internet, les points de terminaison du client associés à la demande doivent être un routables publiquement. Cela vaut également pour les connexions établies par le client via ExpressRoute. Avec de nombreux clients s’homologuant directement auprès de Microsoft, disposer d’adresses privées permettant une duplication entre clients n’est pas réalisable.

Voici des scénarios dans le cadre desquels des communications sont établies à partir d’Office 365 vers votre réseau locale :

Pour que Microsoft re-route vers votre réseau ces flux de trafic bidirectionnel, les itinéraires BGP vers vos appareils locaux doivent être partagés avec Microsoft.

Pour vous connecter à Office 365 via un circuit ExpressRoute, vous devez configurer une relation homologation en utilisant le domaine de routage d’homologation Microsoft. Les homologations Public Azure et Privé Azure ne sont pas requises pour Office 365. En revanche, certains services liés à Office 365 requièrent le domaine de routage Public Azure. Par exemple, Azure RemoteApp et le pack d’administration Office 365 sont conçus en complément de Microsoft Azure. Étant donné qu’il s’agit d’applications intégrées dans Azure, certains points de terminaison sont disponibles via une homologation Public Azure.

D’autres applications telles que Office 365 Video sont des applications Office 365. Toutefois, l’application Office 365 Video est constituée de trois composants distincts : le portail, le service de diffusion en continu et le réseau de distribution de contenu. Le portail réside dans SharePoint Online, le service de diffusion en continu dans Azure Media Services, et le réseau de distribution de contenu dans le CDN Azure. Le tableau suivant décrit ces composants.

Composant

Application sous-jacente

Domaine de routage

Utiliser

Portail Office 365 Video

SharePoint Online

Homologation Microsoft

Configuration, chargement

Service de diffusion en continu Office 365 Video

Azure Media Services

Homologation Public Azure

Service de diffusion en continu utilisé en cas d’indisponibilité de la vidéo à partir du CDN

Réseau de distribution de contenu Office 365 Video

CDN Azure

Aucun

Source principale de téléchargement/diffusion en continu de la vidéo. En savoir plus sur la mise en réseau d’Office 365 Video.

Si Azure RemoteApp, le pack d’administration Office 365 et Office 365 Video sont les seules applications qui ont des dépendances matérielles par rapport au domaine de routage Public Azure, d’autres applications pourraient avoir ces dépendances à l’avenir. Pour comprendre quelles Office 365 fonctionnalités et les applications sont disponibles, voir l’article sur les points de terminaison Office 365. Il existe une colonne pour chaque application répertoriée, qui indique si la fonctionnalité est disponible ou non à l’aide d’une homologation Microsoft.

Chacune de ces fonctionnalités Office 365 disponibles à l’aide de Microsoft peering sont répertoriées dans l' article de points de terminaison Office 365 par type d’application et nom de domaine complet. La raison d’utiliser le nom de domaine complet dans les tableaux est de permettre aux clients de gérer le trafic à l’aide de fichiers PAC ou autres configurations de proxy, consultez notre guide aux fichiers de Gestion des points de terminaison Office 365 PAC par exemple. Les adresses IP chacune des applications, sont décomposées au niveau de l’application et non au niveau de la fonctionnalité. Pour chaque application qui n’est disponible sur ExpressRoute, les plages d’adresses IP sont mentionnées dans une table distincte et les plages d’adresses IP qui sont disponibles par le biais d’internet uniquement et internet et ExpressRoute sont détaillées.

Ces adresses IP sont regroupées dans des balises de communauté BGP afin de faciliter la gestion du routage. Les balises de communauté utilisées sont les suivantes :

Balise de chaîne de communauté

Applications incluses

Exchange

Exchange Online

Exchange Online Protection

Skype Entreprise

Skype Entreprise Online

SharePoint

SharePoint Online

Autres services Office 365

Portail et services partagés

Authentification et identité

Office Online

La plupart des noms de domaine complets répertoriés en tant que publiés dans ExpressRoute et internet sont exhaustive. Dans certains cas, nous avons utilisé un caractère générique dans un nom de domaine complet dans une situation où un ou plusieurs sub-connues sont publiés différemment le nom de domaine complet caractère générique au niveau supérieur. Cela se produit généralement lorsque le caractère générique représente une longue liste de serveurs qui sont publiés à ExpressRoute et à internet et un petit ensemble sous-adresse de serveurs ou les enregistrements CNAME qui est publiés uniquement vers internet ou vice versa. Reportez-vous aux tableaux ci-dessous pour comprendre où se trouvent les différences.

Ce tableau affiche les noms de domaine complets (FQDN) avec caractère générique qui sont annoncés sur Internet et Azure ExpressRoute, et les sous-FQDN qui sont annoncés uniquement sur Internet.

FQDN avec caractère générique annoncés sur ExpressRoute et Internet

Sous-FQDN annoncés uniquement sur Internet

*.microsoftonline.com

click.email.microsoftonline.com

portal.microsoftonline.com

provisioningapi.microsoftonline.com

adminwebservice.microsoftonline.com

*.officeapps.live.com

NexusRules.officeapps.live.com

Nexus.officeapps.live.com

odc.officeapps.live.com

odc.officeapps.live.com

cdn.odc.officeapps.live.com

ols.officeapps.live.com

ocsredir.officeapps.live.com

ocws.officeapps.live.com

ocsa.officeapps.live.com

En règle générale, les fichiers PAC sont destinées à envoyer des demandes de réseau à ExpressRoute publiés points de terminaison directement au circuit et toutes les autres requêtes réseau à votre serveur proxy. Si vous configurez un fichier PAC ainsi, composez votre fichier PAC dans l’ordre suivant :

  1. Incluez les sous-FQDN de la colonne deux du tableau ci-dessus en haut de votre fichier PAC, pour envoyer le trafic à votre proxy. Nous avons introduit un exemple de fichier PAC à utiliser dans notre article sur la gestion des points de terminaison Office 365.

  2. Incluez tous les FQDN marqués comme annoncés sur ExpressRoute dans cet article sous la première section, pour envoyer le trafic directement à votre circuit ExpressRoute.

  3. Incluez l’ensemble des autres points de terminaison ou règles de réseau sous ces deux entrées, pour envoyer le trafic vers votre proxy.

Ce tableau affiche le caractère générique connues qui sont publiés à internet uniquement avec les noms de sub FQDN qui sont publiés Azure ExpressRoute et à internet. Pour votre fichier PAC ci-dessus, les noms de domaine complets dans deux colonnes dans le tableau ci-dessous sont répertoriés comme publiés dans ExpressRoute dans le lien référencé, ce qui signifie qu’ils doivent figurer dans le deuxième groupe d’entrées dans le fichier.

FQDN avec caractère générique annoncés uniquement sur Internet

Sous-FQDN annoncés sur ExpressRoute et Internet

*.office.com

*.outlook.office.com

home.office.com

portal.office.com

www.office.com

*.office.net

agent.office.net

*.office365.com

outlook.office365.com

smtp.office365.com

*.outlook.com

*.protection.outlook.com

*.mail.protection.outlook.com

*.windows.net

login.windows.net

Pour router vers l’application Office 365 de votre choix, vous devez déterminer un certain nombre de facteurs clés.

  1. La bande passante dont nécessite l’application. Échantillonnage existant l’utilisation est la méthode uniquement fiable pour déterminer ceci dans votre organisation. Utilisez notre calculatrices uniquement pour valider le test.

  2. Emplacements de sortie à partir desquels vous voulez que le trafic réseau quitte votre réseau. Vous devez planifier une réduction au minimum de la latence du réseau pour la connectivité à Office 365, car la latence a une incidence sur les performances. Skype Entreprise utilisant la voix et la vidéo en temps réel, il est particulièrement susceptible d’offrir une latence réseau médiocre.

  3. Nécessité ou non que tout ou partie de vos emplacements réseau tirent parti d’ExpressRoute.

  4. Emplacements à partir desquels le fournisseur réseau de votre choix propose ExpressRoute.

Une fois que vous déterminez les réponses à ces questions, vous pouvez configurer un circuit ExpressRoute répondant aux besoins de bande passante et l’emplacement. Réseau plus aide à la planification, reportez-vous à la réseau Office 365 guide d’optimisation et l' étude de cas Microsoft sur la façon dont Microsoft gère réseau la planification des performances.

Exemple 1 : emplacement géographique unique

Cet exemple est un scénario présentant une société fictive nommée Trey Research, disposant d’une implantation géographique unique.

Les employés de Trey Research sont autorisés à se connecter uniquement aux services et sites web sur Internet que le service de sécurité autorise explicitement sur les deux proxys sortants situés entre le réseau d’entreprise et le fournisseur de services Internet.

Recherche trois envisage d’utiliser Azure ExpressRoute pour Office 365 et reconnaît que certains types de trafic tels que le trafic destiné à réseaux ne pourront Router via la ExpressRoute pour connexion Office 365 de distribution de contenu. Dans la mesure où toutes les voies de circulation déjà aux périphériques proxy par défaut, ces demandes continueront à fonctionner comme auparavant. Une fois que recherche trois détermine qu’elles peuvent correspondent à la configuration requise pour le routage Azure ExpressRoute, ils continuer pour créer un circuit, configurez le routage et lier le nouveau circuit ExpressRoute à un réseau virtuel. Une fois la configuration Azure ExpressRoute fondamentale est en place, recherche trois ajoute les points de terminaison Office 365 pris en charge par ExpressRoute pour Office 365 à un fichier de configuration (PAC) automatique du proxy ou une URL pour acheminer le trafic avec des données spécifiques du client sur le ExpressRoute pour les connexions Office 365 direct.

Comme illustré dans le diagramme suivant, Trey Research peut satisfaire l’exigence de router le trafic Office 365 sur Internet, et un sous-ensemble du trafic sur ExpressRoute, en utilisant une combinaison de routage et de modifications de configuration du proxy sortant.

  1. Une URL ou un fichier de configuration (PAC) automatique du proxy est utilisé pour acheminer le trafic via un point de sortie internet distinct pour Azure ExpressRoute pour Office 365.

  2. Les clients sont configurés avec un itinéraire par défaut vers les proxys de Trey Research.

Dans ce scénario exemple, Trey Research utilise un appareil proxy sortant. De même, les clients qui n’utilisent pas Azure ExpressRoute pour Office 365 peuvent utiliser cette technique pour router le trafic en fonction du coût d’inspection du trafic destiné à des points de terminaison bien connus acceptant des volumes élevés.

Les noms de domaine complets (FQDN) acceptant les volumes les plus élevés pour Exchange Online, SharePoint Online et Skype Entreprise Online sont les suivants :

Réseau de périmètre du client ExpressRoute
  • outlook.office365.com

  • outlook.office.com

  • <nom-locataire>.sharepoint.com

  • <nom-locataire>-my.sharepoint.com

  • <nom-locataire>-<application>.sharepoint.com

  • *.Lync.com

Plus d’informations sur le déploiement et la gestion des paramètres de proxy dans Windows 8 et garantissant Qu'office 365 n’est pas limité par votre proxy.

Avec un seul circuit ExpressRoute, il n’y a pas de haute disponibilité pour Trey Research. En cas de panne, au niveau de Trey, d’une paire redondante de périphériques de périmètre qui assurent la connectivité ExpressRoute, il n’existe pas de circuit ExpressRoute supplémentaire vers lequel opérer le basculement. Cela met Trey Research en position délicate, car un basculement vers Internet nécessite une reconfiguration manuelle et, dans certains cas, de nouvelles adresses IP. Si Trey souhaite ajouter la haute disponibilité, la solution la plus simple consiste à ajouter des circuits ExpressRoute.

Le dernier scénario, celui du routage du trafic Office 365 sur ExpressRoute, constitue le fondement d’une architecture de routage encore plus complexe. Quel que soit le nombre d’emplacements, le nombre de continents où se situent les emplacements, le nombre de circuits ExpressRoute et ainsi de suite, la possibilité de router du trafic tant via Internet que via ExpressRoute est requise.

Les questions supplémentaires auxquelles doivent répondre les clients disposant de plusieurs implantations dans des zones géographiques diverses sont les suivantes :

  1. Un circuit ExpressRoute est-il indispensable dans chaque emplacement ? En cas d’utilisation de Skype Entreprise, ou si le client se soucie de la sensibilité à la latence de SharePoint Online ou d’Exchange Online, un circuit ExpressRoute est recommandé sur chaque continent où le client a bureaux. Pour plus de détails, voir le guide sur la qualité des médias et la connectivité réseau de Skype Entreprise.

  2. Si un circuit ExpressRoute n’est pas disponible dans une région particulière, comment router le trafic destiné à Office 365 ?

  3. Quelle est la méthode préconisée pour consolider le trafic dans le cas de réseaux comportant de nombreux emplacements de petite taille ?

Chacune de ces questions a trait à un défi unique qui vous oblige à évaluer votre propre réseau ainsi que les options proposées par Microsoft.

Préoccupation

Composants réseau à évaluer

Circuits dans plusieurs emplacements

Le coût, la latence et les besoins en bande passante doivent être comparés.

Utilisez le coût d’itinéraire BGP, des fichiers PAC et une traduction d’adresses réseau (NAT) pour gérer le routage avec plusieurs circuits.

Routage à partir d’emplacements sans un circuit ExpressRoute

Un transfert DNS peut être utilisé pour permettre à des bureaux distants de découvrir le point de terminaison approprié.

Les clients du bureau à distance doivent avoir un itinéraire disponible donnant accès au circuit ExpressRoute.

Consolidation de bureau de petite taille

La bande passante disponible et l’utilisation des données doivent être comparées avec soin.

Remarque : Si l’itinéraire n’est disponible, quel que soit l’emplacement physique, Microsoft préfère ExpressRoute à Internet.

Chacune de ces préoccupations doit être prise en considération pour chaque réseau. Voici un exemple.

Exemple 2 : plusieurs zones géographiques

Cet exemple est un scénario présentant une société fictive nommée Humongous Insurance, disposant de plusieurs implantations géographiques.

Humongous Insurance est géographiquement dispersé, avec des bureaux dans le monde entier, qui doivent implémenter ExpressRoute Azure pour Office 365 afin de conserver la majorité de leur trafic Office 365 sur des connexions réseau directes. Humongous Insurance dispose également de bureaux sur deux autres continents. Les employés du bureau distant où ExpressRoute n’est pas envisageable vont devoir re-router vers l’une des deux implantations principales pour pouvoir utiliser une connexion ExpressRoute.

Le principe directeur consiste à acheminer le trafic destiné à Office 365 vers un centre de données Microsoft le plus rapidement possible. Dans cet exemple, Humongous Insurance doit décider si son bureau distant doit router via Internet pour accéder à un centre de données Microsoft via une connexion quelconque le plus rapidement possible, ou router via un réseau interne pour accéder à un centre de données Microsoft via une connexion ExpressRoute le plus rapidement possible.

L’architecture de centres de données, de réseaux et d’applications de Microsoft est conçue pour recevoir des communications globalement disparates, et les acheminer de la manière la plus efficace possible. Des demandes destinées à Office 365 qui restent sur des réseaux de client plus longtemps que nécessaire ne peuvent pas tirer parti de cette architecture.

Dans le cas de Humongous Insurance, l’entreprise devrait procéder en fonction des applications qu’elle a l’intention d’utiliser via ExpressRoute. Par exemple, si elle est cliente de Skype Entreprise Online, ou si elle prévoit de tirer parti de la connectivité ExpressRoute lors de la connexion à des réunions Skype Entreprise Online externes, la conception recommandée par le guide sur la qualité des médias et la connectivité réseau de Skype Entreprise est de mettre en service un circuit ExpressRoute supplémentaire pour le troisième emplacement. Cela peut être plus onéreux sur le plan de la mise en réseau, mais des demandes de routage d’un continent vers un autre avant une remise à un centre de données Microsoft peuvent entraîner une expérience médiocre ou inutilisable dans le cadre de réunions et communications Skype Entreprise Online.

Si Humongous Insurance n’utilise pas ou n’envisage pas de tirer parti de Skype Entreprise Online, un routage du trafic réseau destiné à Office 365 vers un continent disposant d’une connexion ExpressRoute peut être réalisable. Dans les deux cas, un routage du trafic destiné à Internet vers Internet au niveau du site local est recommandé pour tirer parti des réseaux de distribution de contenu dont dépend Office 365.

Géographie multiple ExpressRoute

Lorsque Humongous Insurance planifie sa stratégie en rapport avec sa dispersion géographique, plusieurs éléments sont à prendre en considération concernant la taille du circuit (évoquée ici), le nombre de circuits, le basculement et d’autres aspects.

Avec ExpressRoute situé dans un emplacement et plusieurs régions tentant d’utiliser le circuit, Humongous Insurance veut s’assurer que les connexions avec Office 365 à partir du bureau distant soient envoyées au centre de données Office 365 le plus proche du siège central et reçues par celui-ci. Pour ce faire, Humongous Insurance implémente un DNS de transfert afin de réduire le nombre de boucles et de recherches DNS requis pour établir la connexion appropriée avec l’environnement Office 365 le plus proche du point de sortie Internet du siège social. Pour en savoir plus, voir également Affecter un redirecteur conditionnel pour un nom de domaine.

Dans ce scénario, le trafic en provenance du bureau distant résoudrait l’infrastructure frontale d’Office 365 en Amérique du Nord, et tirerait parti d’Office 365 pour se connecter aux serveurs principaux en fonction de l’architecture de l’application Office 365. Par exemple, Exchange Online mettrait fin à la connexion en Amérique du Nord et ces serveurs frontaux se connecteraient au serveur de boîtes aux lettres principal où le client résiderait. Pour plus d’informations sur l’architecture de chaque application pour gérer la connectivité du client, voir la section consacrée à la connectivité du client.

Si Humongous Insurance dispose de bureaux d’importance majeure sur plusieurs continents, au minimum un circuit par continent est recommandé afin de réduire la latence pour des applications sensibles telles que Skype Entreprise. Si tous les bureaux sont situés sur un seul continent, ou s’ils ne collaborent pas en temps réel, la mise en service d’un point de sortie consolidé ou distribué est une décision revenant au client, qui dépend du nombre de personnes par emplacement, de l’utilisation d’applications à chaque emplacement, des exigences de haute disponibilité, et d’autres considérations. Lorsque plusieurs circuits sont disponibles, un routage BGP garantit le basculement au cas où un circuit deviendrait indisponible.

Pour en savoir plus, voir les exemples de configurations de routage et la rubrique https://docs.microsoft.com/fr-fr/azure/expressroute/expressroute-config-samples-nat.

Un routage sélectif avec ExpressRoute peut être nécessaire pour diverses raisons, par exemple, à des fins de test ou de déploiement graduel d’ExpressRoute vers un sous-ensemble d’utilisateurs. Différents outils sont à la disposition des clients pour router le trafic réseau Office 365 de manière sélective via ExpressRoute :

  1. Filtrage/répartition d’itinéraire : autorisation des itinéraires BGP vers Office 365 sur ExpressRoute, à un sous-ensemble de sous-réseaux ou routeurs. Route de façon sélective par segment réseau de client ou emplacement de bureau physique. Cela est courant pour un déploiement échelonné d’ExpressRoute pour Office 365.

  2. Fichiers PAC/URL: indication de router le trafic réseau destiné à Office 365 pour des noms de domaine complets (FQDN) spécifiques sur un chemin spécifique. Route de façon sélective par ordinateur client identifié par le déploiement du fichier PAC.

  3. Communautés BGP : filtrage basé sur des balises de communauté BGP permettant à un client déterminer les applications Office 365 qui circulent sur ExpressRoute et celles qui circulent sur Internet.

Vous pouvez utiliser ce lien pour revenir : https://aka.ms/erorouting

Rubriques connexes

Connectivité au réseau pour Office 365
Azure ExpressRoute pour Office 365
Gestion ExpressRoute pour Office 365 connectivité
planification réseau avec ExpressRoute pour Office 365
Mise en œuvre ExpressRoute pour Office 365
qualité Media et des performances pour la connectivité réseau dans Skype entreprise Online
optimiser votre réseau pour Skype entreprise Online
ExpressRoute et qualité de service dans Skype entreprise Online
appeler le flux à l’aide de ExpressRoute
BGP à l’aide des Communautés dans ExpressRoute pour Office 365 scénarios
Optimisation des performances d’Office 365 à l’aide des points de comparaison et de l’historique des performances
plan de résolution des problèmes de performancespour Office 365
Office 365 URL et plages d’adresses IP
Office 365 réseau et optimisation des performances

Remarque : Avertissement traduction automatique : cet article a été traduit par un ordinateur, sans intervention humaine. Microsoft propose cette traduction automatique pour offrir aux personnes ne maîtrisant pas l’anglais l’accès au contenu relatif aux produits, services et technologies Microsoft. Comme cet article a été traduit automatiquement, il risque de contenir des erreurs de grammaire, de syntaxe ou de terminologie.

Développez vos compétences
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoignez le programme Office Insider

Ces informations vous ont-elles été utiles ?

Nous vous remercions pour vos commentaires.

Merci pour vos commentaires. Il serait vraisemblablement utile pour vous de contacter l’un de nos agents du support Office.

×