Implémentation d’ExpressRoute pour Microsoft 365
Cet article s’applique aux Microsoft 365 Entreprise.
ExpressRoute pour Microsoft 365 fournit un autre chemin de routage vers de nombreux services Microsoft 365 accessibles sur Internet. L’architecture d’ExpressRoute pour Microsoft 365 est basée sur la publicité de préfixes d’adresses IP publiques des services Microsoft 365 qui sont déjà accessibles via Internet dans vos circuits ExpressRoute provisionnés pour une redistribution ultérieure de ces préfixes IP dans votre réseau. Avec ExpressRoute, vous activez efficacement plusieurs chemins de routage différents, via Internet et expressRoute, pour de nombreux services Microsoft 365. Cet état de routage sur votre réseau peut représenter une modification significative de la façon dont votre topologie de réseau interne est conçue.
Remarque
Nous ne recommandons pas ExpressRoute pour Microsoft 365, car il ne fournit pas le meilleur modèle de connectivité pour le service dans la plupart des cas. Par conséquent, l’autorisation Microsoft est requise pour utiliser ce modèle de connectivité. Nous passons en revue chaque demande de client et nous n’autorisons ExpressRoute pour Microsoft 365 que dans les rares scénarios où cela est nécessaire. Pour plus d’informations, lisez le guide ExpressRoute pour Microsoft 365 et, après une révision complète du document avec vos équipes de productivité, de réseau et de sécurité, collaborez avec votre équipe de compte Microsoft pour soumettre une exception si nécessaire. Les abonnements non autorisés qui tentent de créer des filtres de routage pour Microsoft 365 recevront un message d’erreur.
Vous devez soigneusement planifier votre implémentation ExpressRoute pour Microsoft 365 afin de prendre en charge les complexités réseau d’un routage disponible via un circuit dédié avec des itinéraires injectés dans votre réseau principal et Internet. Si vous et votre équipe n’effectuez pas la planification et les tests détaillés de ce guide, vous risquez de subir une perte de connectivité intermittente ou totale aux services Microsoft 365 lorsque le circuit ExpressRoute est activé.
Pour réussir l’implémentation, vous devez analyser les exigences de votre infrastructure, passer en revue l’évaluation et la conception détaillées du réseau, planifier soigneusement le déploiement de manière intermédiaire et contrôlée, et créer un plan de validation et de test détaillé. Pour un environnement distribué de grande taille, il n’est pas rare que les implémentations s’étendent sur plusieurs mois. Ce guide est conçu pour vous aider à planifier à l’avance.
La planification de déploiements volumineux peut prendre six mois et inclure souvent des membres de l’équipe provenant de nombreux domaines de l’organization notamment la mise en réseau, les administrateurs de pare-feu et de serveur proxy, les administrateurs Microsoft 365, la sécurité, le support des utilisateurs finaux, la gestion de projet et le parrainage exécutif. Votre investissement dans le processus de planification réduit la probabilité que vous rencontriez des échecs de déploiement entraînant un temps d’arrêt ou une résolution des problèmes complexes et coûteux.
Nous nous attendons à ce que les conditions préalables suivantes soient remplies avant le démarrage de ce guide d’implémentation.
Vous avez effectué une évaluation réseau pour déterminer si ExpressRoute est recommandé et approuvé.
Vous avez sélectionné un fournisseur de services réseau ExpressRoute. Trouvez des détails sur les partenaires ExpressRoute et les emplacements de peering.
Vous avez déjà lu et compris la documentation ExpressRoute et votre réseau interne est en mesure de répondre aux prérequis ExpressRoute de bout en bout.
Votre équipe a lu tous les conseils et la documentation publics sur https://aka.ms/expressrouteoffice365, https://aka.ms/ertet a regardé la série De formation Azure ExpressRoute pour Microsoft 365 sur Channel 9 pour comprendre les détails techniques critiques, notamment :
Dépendances Internet des services SaaS.
Comment éviter les itinéraires asymétriques et gérer le routage complexe.
Comment incorporer des contrôles de sécurité, de disponibilité et de niveau application du périmètre.
Commencez par collecter les exigences
Commencez par déterminer les fonctionnalités et services que vous envisagez d’adopter dans votre organization. Vous devez déterminer quelles fonctionnalités des différents services Microsoft 365 seront utilisées et quels emplacements de votre réseau hébergeront les personnes utilisant ces fonctionnalités. Avec le catalogue de scénarios, vous devez ajouter les attributs réseau requis par chacun de ces scénarios . tels que les flux de trafic réseau entrant et sortant et si les points de terminaison Microsoft 365 sont disponibles sur ExpressRoute ou non.
Pour rassembler les exigences de votre organization :
Cataloguer le trafic réseau entrant et sortant pour les services Microsoft 365 que votre organization utilise. Consultez la page URL et plages d’adresses IP Microsoft 365 pour obtenir la description des flux requis par différents scénarios Microsoft 365.
Rassemblez la documentation de la topologie de réseau existante montrant les détails de votre réseau étendu interne et de la topologie, la connectivité des sites satellites, la connectivité utilisateur du dernier kilomètre, le routage vers les points de sortie du périmètre réseau et les services proxy.
Identifiez les points de terminaison de service entrants sur les diagrammes réseau auxquels Microsoft 365 et d’autres services Microsoft se connecteront, en affichant à la fois Internet et les chemins de connexion ExpressRoute proposés.
Identifiez tous les emplacements géographiques des utilisateurs et la connectivité WAN entre les emplacements, ainsi que les emplacements qui ont actuellement une sortie vers Internet et les emplacements proposés pour une sortie vers un emplacement de peering ExpressRoute.
Identifiez tous les appareils de périphérie, tels que les proxys, les pare-feu, etc., et cataloguez leur relation avec les flux transitant par Internet et ExpressRoute.
Indiquez si les utilisateurs finaux accèdent aux services Microsoft 365 via le routage direct ou le proxy d’application indirect pour les flux Internet et ExpressRoute.
Ajoutez l’emplacement de votre locataire et rencontrez-moi à votre diagramme réseau.
Estimez les performances réseau attendues et observées et les caractéristiques de latence entre les principaux emplacements utilisateur et Microsoft 365. Gardez à l’esprit que Microsoft 365 est un ensemble mondial et distribué de services et que les utilisateurs se connectent à des emplacements qui peuvent être différents de l’emplacement de leur locataire. Pour cette raison, il est recommandé de mesurer et d’optimiser la latence entre l’utilisateur et la périphérie la plus proche du réseau global Microsoft via des connexions ExpressRoute et Internet. Vous pouvez utiliser les résultats de l’évaluation du réseau pour faciliter cette tâche.
Répertoriez les exigences de sécurité réseau et de haute disponibilité de l’entreprise qui doivent être satisfaites avec la nouvelle connexion ExpressRoute. Par exemple, comment les utilisateurs continuent-ils à accéder à Microsoft 365 en cas de sortie Internet ou de défaillance du circuit ExpressRoute.
Documentez les flux réseau Microsoft 365 entrants et sortants qui utilisent le chemin Internet et ceux qui utilisent ExpressRoute. Les spécificités des emplacements géographiques de vos utilisateurs et les détails de la topologie de votre réseau local peuvent nécessiter que le plan soit différent d’un emplacement utilisateur à un autre.
Cataloguer votre trafic réseau sortant et entrant
Pour réduire le routage et d’autres complexités réseau, nous vous recommandons d’utiliser ExpressRoute pour Microsoft 365 uniquement pour les flux de trafic réseau requis pour passer par une connexion dédiée en raison des exigences réglementaires ou de l’évaluation du réseau. En outre, nous vous recommandons de mettre en scène l’étendue du routage ExpressRoute et d’aborder les flux de trafic réseau sortant et entrant en tant qu’étapes différentes et distinctes du projet d’implémentation. Déployer ExpressRoute pour Microsoft 365 pour les flux de trafic sortant uniquement initiés par l’utilisateur et laisser des flux de trafic réseau entrant sur Internet peut aider à contrôler l’augmentation de la complexité topologique et des risques liés à l’introduction de possibilités de routage asymétrique supplémentaires.
Votre catalogue de trafic réseau doit contenir la liste de toutes les connexions réseau entrantes et sortantes que vous aurez entre votre réseau local et Microsoft.
Les flux de trafic réseau sortant sont tous les scénarios dans lesquels une connexion est lancée à partir de votre environnement local, par exemple à partir de clients ou de serveurs internes, avec une destination des services Microsoft. Ces connexions peuvent être directes à Microsoft 365 ou indirectes, par exemple lorsque la connexion passe par des serveurs proxy, des pare-feu ou d’autres appareils réseau sur le chemin d’accès à Microsoft 365.
Les flux de trafic réseau entrant sont tous les scénarios dans lesquels une connexion est lancée à partir du cloud Microsoft vers un hôte local. Ces connexions doivent généralement passer par un pare-feu et une autre infrastructure de sécurité requise par la stratégie de sécurité du client pour les flux provenant de l’extérieur.
Lisez la section Assurer la symétrie des itinéraires pour déterminer quels services enverront le trafic entrant et recherchez la colonne marquée ExpressRoute pour Microsoft 365 dans l’article de référence sur les points de terminaison Microsoft 365 pour déterminer le reste des informations de connectivité.
Pour chaque service qui nécessite une connexion sortante, vous devez décrire la connectivité planifiée pour le service, notamment le routage réseau, la configuration du proxy, l’inspection des paquets et les besoins en bande passante.
Pour chaque service qui nécessite une connexion entrante, vous aurez besoin d’informations supplémentaires. Les serveurs dans le cloud Microsoft établissent des connexions à votre réseau local. Pour vous assurer que les connexions sont correctement établies, vous devez décrire tous les aspects de cette connectivité, notamment : les entrées DNS publiques pour les services qui accepteront ces connexions entrantes, les adresses IP IPv4 au format CIDR, l’équipement du fai qui est impliqué et la façon dont la NAT entrante ou la NAT source est gérée pour ces connexions.
Les connexions entrantes doivent être examinées, qu’elles se connectent via Internet ou ExpressRoute pour vous assurer que le routage asymétrique n’a pas été introduit. Dans certains cas, les points de terminaison locaux auxquels les services Microsoft 365 initient des connexions entrantes peuvent également avoir besoin d’être accessibles par d’autres services Microsoft et non-Microsoft. Il est primordial que l’activation du routage ExpressRoute vers ces services à des fins Microsoft 365 n’interrompe pas les autres scénarios. Dans de nombreux cas, les clients peuvent avoir besoin d’implémenter des modifications spécifiques à leur réseau interne, comme la nativité réseau basée sur la source, pour s’assurer que les flux entrants de Microsoft restent symétriques après l’activation d’ExpressRoute.
Voici un exemple du niveau de détail requis. Dans ce cas, Exchange Hybrid est acheminé vers le système local via ExpressRoute.
| Connection, propriété | Valeur |
|---|---|
| Direction du trafic réseau |
Entrant |
| Service |
Environnement Exchange hybride |
| Point de terminaison Microsoft 365 public (source) |
Exchange Online (adresses IP) |
| Point de terminaison local public (destination) |
5.5.5.5 |
| Entrée DNS publique (Internet) |
Autodiscover.contoso.com |
| Ce point de terminaison local sera-t-il utilisé par d’autres services Microsoft (non-Microsoft 365) |
Non |
| Ce point de terminaison local sera-t-il utilisé par les utilisateurs/systèmes sur Internet |
Oui |
| Systèmes internes publiés via des points de terminaison publics |
Exchange Server rôle d’accès client (local) 192.168.101, 192.168.102, 192.168.103 |
| Publication IP du point de terminaison public |
Vers Internet : 5.5.0.0/16 Vers ExpressRoute : 5.5.5.0/24 |
| Contrôles de sécurité/de périmètre |
Chemin d’accès Internet : chemin d’accès ExpressRoute DeviceID_002 : DeviceID_003 |
| Haute disponibilité |
Actif/actif sur 2 circuits géoredondants/ExpressRoute - Chicago et Dallas |
| Contrôle de symétrie de chemin |
Méthode : Chemin d’accès Internet NAT source : connexions entrantes NAT sources vers le chemin ExpressRoute 192.168.5.5 : Connexions NAT sources vers 192.168.1.0 (Chicago) et 192.168.2.0 (Dallas) |
Voici un exemple de service sortant uniquement :
| Connection, propriété | Valeur |
|---|---|
| Direction du trafic réseau |
Sortant |
| Service |
SharePoint |
| Point de terminaison local (source) |
Station de travail utilisateur |
| Point de terminaison Microsoft 365 public (destination) |
SharePoint (adresses IP) |
| Entrée DNS publique (Internet) |
*.sharepoint.com (et d’autres noms de domaine complets) |
| Références CDN |
cdn.sharepointonline.com (et d’autres noms de domaine complets) : adresses IP gérées par les fournisseurs CDN) |
| Publication IP et NAT en cours d’utilisation |
Chemin d’accès Internet/NAT source : 1.1.1.0/24 Chemin ExpressRoute/NAT source : 1.1.2.0/24 (Chicago) et 1.1.3.0/24 (Dallas) |
| Méthode de connectivité |
Internet : via le proxy de couche 7 (fichier .pac) ExpressRoute : routage direct (sans proxy) |
| Contrôles de sécurité/de périmètre |
Chemin Internet : DeviceID_002 Chemin ExpressRoute : DeviceID_003 |
| Haute disponibilité |
Chemin d’accès Internet : sortie Internet redondante Chemin ExpressRoute : routage actif/actif sur 2 circuits ExpressRoute géoredondants - Chicago et Dallas |
| Contrôle de symétrie de chemin |
Méthode : NAT source pour toutes les connexions |
Conception de la topologie de votre réseau avec connectivité régionale
Une fois que vous avez compris les services et les flux de trafic réseau associés, vous pouvez créer un diagramme réseau qui incorpore ces nouvelles exigences de connectivité et illustre les modifications que vous allez apporter à l’utilisation d’ExpressRoute pour Microsoft 365. Votre diagramme doit inclure :
Tous les emplacements utilisateur à partir desquels Microsoft 365 et d’autres services sont accessibles.
Tous les points de sortie Internet et ExpressRoute.
Tous les appareils sortants et entrants qui gèrent la connectivité à l’entrée et à l’extérieur du réseau, y compris les routeurs, les pare-feu, les serveurs proxy d’application et la détection/prévention des intrusions.
Destinations internes pour tout le trafic entrant, comme les serveurs ADFS internes qui acceptent les connexions à partir des serveurs proxy d’application web ADFS.
Catalogue de tous les sous-réseaux IP qui seront publiés
Identifiez chaque emplacement à partir duquel les utilisateurs accèderont à Microsoft 365 et répertoriez les emplacements de réunion qui seront utilisés pour ExpressRoute.
Emplacements et parties de votre topologie de réseau interne, où les préfixes IP Microsoft appris à partir d’ExpressRoute seront acceptés, filtrés et propagés.
La topologie du réseau doit illustrer l’emplacement géographique de chaque segment réseau et la façon dont il se connecte au réseau Microsoft via ExpressRoute et/ou Internet.
Le diagramme ci-dessous montre chaque emplacement où les utilisateurs utiliseront Microsoft 365, ainsi que les annonces de routage entrant et sortant vers Microsoft 365.
Pour le trafic sortant, les personnes accèdent à Microsoft 365 de l’une des trois manières suivantes :
Grâce à un lieu de rencontre dans Amérique du Nord pour les gens en Californie.
Par le biais d’un lieu de rencontre dans la région administrative spéciale de Hong Kong pour les gens dans la R.A.R. de Hong Kong.
Via Internet au Bangladesh, où il y a moins de personnes et aucun circuit ExpressRoute approvisionné.
De même, le trafic réseau entrant de Microsoft 365 est retourné de l’une des trois manières suivantes :
Grâce à un lieu de rencontre dans Amérique du Nord pour les gens en Californie.
Par le biais d’un lieu de rencontre dans la région administrative spéciale de Hong Kong pour les gens dans la R.A.R. de Hong Kong.
Via Internet au Bangladesh, où il y a moins de personnes et aucun circuit ExpressRoute approvisionné.
Déterminer l’emplacement de rencontre approprié
La sélection des emplacements de réunion, qui sont l’emplacement physique où votre circuit ExpressRoute connecte votre réseau au réseau Microsoft, est influencée par les emplacements à partir desquels les utilisateurs accèdent à Microsoft 365. En tant qu’offre SaaS, Microsoft 365 ne fonctionne pas sous le modèle régional IaaS ou PaaS de la même façon qu’Azure. Au lieu de cela, Microsoft 365 est un ensemble distribué de services de collaboration, où les utilisateurs peuvent avoir besoin de se connecter à des points de terminaison dans plusieurs centres de données et régions, qui peuvent ne pas nécessairement se trouver dans le même emplacement ou la même région où le locataire de l’utilisateur est hébergé.
Cela signifie que la considération la plus importante que vous devez prendre en compte lors de la sélection des emplacements de réunion pour ExpressRoute pour Microsoft 365 est l’emplacement à partir duquel les personnes de votre organization se connecteront. La recommandation générale pour une connectivité Optimale de Microsoft 365 est d’implémenter le routage, afin que les demandes des utilisateurs aux services Microsoft 365 soient transmises au réseau Microsoft via le chemin réseau le plus court, ce qui est également souvent appelé routage « patate chaude ». Par exemple, si la plupart des utilisateurs de Microsoft 365 se trouvent dans un ou deux emplacements, la sélection d’emplacements de réunion qui se trouvent à proximité la plus proche de l’emplacement de ces utilisateurs crée la conception optimale. Si votre entreprise a de grandes populations d’utilisateurs dans de nombreuses régions différentes, vous pouvez envisager d’avoir plusieurs circuits ExpressRoute et des lieux de rencontre. Pour certains de vos emplacements utilisateur, le chemin le plus court/le plus optimal vers le réseau Microsoft et Microsoft 365 n’est peut-être pas via vos points de rencontre internes WAN et ExpressRoute, mais via Internet.
Souvent, plusieurs emplacements de réunion peuvent être sélectionnés dans une région à proximité relative de vos utilisateurs. Remplissez le tableau suivant pour guider vos décisions.
Sites de rencontre ExpressRoute planifiés en Californie et à New York
| Emplacement |
Nombre de personnes |
Latence attendue sur le réseau Microsoft via la sortie Internet |
Latence attendue sur le réseau Microsoft via ExpressRoute |
|---|---|---|---|
| Los Angeles |
10 000 |
~15 ms |
~10 ms (via silicon valley) |
| Washington DC |
15 000 |
~20 ms |
~10 ms (via New York) |
| Dallas |
5,000 |
~15 ms |
~40 ms (via New York) |
Une fois que l’architecture réseau globale montrant la région Microsoft 365, les emplacements du fournisseur de services réseau ExpressRoute et la quantité de personnes par emplacement a été développée, elle peut être utilisée pour identifier si des optimisations peuvent être effectuées. Il peut également afficher les connexions réseau en épingle à cheveux globales où le trafic est acheminé vers un emplacement distant afin d’obtenir l’emplacement de rencontre. Si une épingle à cheveux sur le réseau global est découverte, elle doit être corrigée avant de continuer. Soit trouver un autre lieu de rencontre, ou utiliser des points de sortie internet sélectifs pour éviter l’épingle à cheveux.
Le premier diagramme montre un exemple de client avec deux emplacements physiques dans Amérique du Nord. Vous pouvez voir les informations sur les emplacements des bureaux, les emplacements des locataires Microsoft 365 et plusieurs choix pour les emplacements de réunion ExpressRoute. Dans cet exemple, le client a sélectionné l’emplacement de la réunion en fonction de deux principes, dans l’ordre :
Plus proche des personnes dans leur organization.
Plus proche d’un centre de données Microsoft où Microsoft 365 est hébergé.
En développant légèrement ce concept, le deuxième diagramme montre un exemple de client multi-national confronté à des informations et des décisions similaires. Ce client dispose d’un petit bureau au Bangladesh avec seulement une petite équipe de 10 personnes qui se concentrent sur l’augmentation de leur empreinte dans la région. Il y a un lieu de réunion à Chennai et un centre de données Microsoft avec Microsoft 365 hébergé à Chennai, donc un lieu de rencontre serait judicieux ; Cependant, pour 10 personnes, la dépense du circuit supplémentaire est lourde. Lorsque vous examinez votre réseau, vous devez déterminer si la latence impliquée dans l’envoi du trafic réseau sur votre réseau est plus efficace que de dépenser le capital pour acquérir un autre circuit ExpressRoute.
Sinon, les 10 personnes au Bangladesh peuvent avoir de meilleures performances avec leur trafic réseau envoyé via Internet au réseau Microsoft qu’ils ne le ferait sur leur réseau interne, comme nous l’avons montré dans les diagrammes d’introduction et reproduits ci-dessous.
Create votre plan d’implémentation ExpressRoute pour Microsoft 365
Votre plan d’implémentation doit englober à la fois les détails techniques de la configuration d’ExpressRoute et les détails de la configuration de toutes les autres infrastructures sur votre réseau, telles que les suivantes.
Planifiez les services répartis entre ExpressRoute et Internet.
Planifiez la bande passante, la sécurité, la haute disponibilité et le basculement.
Concevoir un routage entrant et sortant, y compris des optimisations de chemin de routage appropriées pour différents emplacements
Déterminez jusqu’où les itinéraires ExpressRoute seront publiés dans votre réseau et quel est le mécanisme permettant aux clients de sélectionner un chemin Internet ou ExpressRoute . par exemple, le routage direct ou le proxy d’application.
Planifier les modifications d’enregistrement DNS, y compris les entrées de l’Infrastructure de stratégie de l’expéditeur .
Planifiez la stratégie NAT, y compris la nat nat source sortante et entrante.
Planifier votre routage avec les chemins d’accès réseau Internet et ExpressRoute
Pour votre déploiement initial, il est recommandé d’utiliser Internet pour tous les services entrants, tels que la messagerie entrante ou la connectivité hybride.
Planifiez le routage LAN client final, comme la configuration d’un fichier PAC/WPAD, de la route par défaut, des serveurs proxy et des annonces de routage BGP.
Planifiez le routage du périmètre, y compris les serveurs proxy, les pare-feu et les proxys cloud.
Planifier la bande passante, la sécurité, la haute disponibilité et le basculement
Create un plan de bande passante nécessaire pour chaque charge de travail Microsoft 365 majeure. Estimer séparément les besoins en bande passante Exchange Online, SharePoint et Skype Entreprise Online. Vous pouvez utiliser les calculatrices d’estimation que nous avons fournies pour Exchange Online et Skype Entreprise comme point de départ. Toutefois, un test pilote avec un échantillon représentatif des profils utilisateur et des emplacements est nécessaire pour bien comprendre les besoins en bande passante de votre organization.
Ajoutez la façon dont la sécurité est gérée à chaque emplacement internet et de sortie ExpressRoute à votre plan, n’oubliez pas que toutes les connexions ExpressRoute à Microsoft 365 utilisent le peering public et doivent toujours être sécurisées conformément aux stratégies de sécurité de votre entreprise de connexion aux réseaux externes.
Ajoutez des détails à votre plan sur les personnes qui seront affectées par le type de panne et comment ces personnes seront en mesure d’effectuer leur travail à pleine capacité de la manière la plus simple.
Planifier les exigences en bande passante, y compris les exigences de Skype Entreprise sur la gigue, la latence, la congestion et la marge de travail
Skype Entreprise Online a également des exigences réseau supplémentaires spécifiques, qui sont détaillées dans l’article Qualité des médias et performances de connectivité réseau dans Skype Entreprise Online.
Lisez la section Planification de la bande passante pour Azure ExpressRoute. Lorsque vous effectuez une évaluation de la bande passante avec vos utilisateurs pilotes, vous pouvez utiliser notre guide Microsoft 365 réglage des performances à l’aide des bases de référence et de l’historique des performances.
Planifier les exigences de haute disponibilité
Create un plan de haute disponibilité pour répondre à vos besoins et l’incorporer dans votre diagramme de topologie de réseau mis à jour. Lisez la section Haute disponibilité et basculement avec Azure ExpressRoute.
Planifier les exigences de sécurité réseau
Create un plan pour répondre à vos exigences de sécurité réseau et l’incorporer dans votre diagramme de topologie réseau mis à jour. Lisez la section Application de contrôles de sécurité à Azure ExpressRoute pour les scénarios Microsoft 365.
Concevoir une connectivité de service sortant
ExpressRoute pour Microsoft 365 a des exigences réseau sortantes qui peuvent être inconnues. Plus précisément, les adresses IP qui représentent vos utilisateurs et réseaux vers Microsoft 365 et qui servent de points de terminaison sources pour les connexions réseau sortantes à Microsoft doivent respecter les exigences spécifiques décrites ci-dessous.
Les points de terminaison doivent être des adresses IP publiques inscrites auprès de votre entreprise ou auprès de l’opérateur qui vous fournit une connectivité ExpressRoute.
Les points de terminaison doivent être publiés auprès de Microsoft et validés/acceptés par ExpressRoute.
Les points de terminaison ne doivent pas être publiés sur Internet avec la même métrique de routage préférée ou plus.
Les points de terminaison ne doivent pas être utilisés pour la connectivité aux services Microsoft qui ne sont pas configurés sur ExpressRoute.
Si la conception de votre réseau ne répond pas à ces exigences, il existe un risque élevé pour vos utilisateurs de rencontrer des échecs de connectivité à Microsoft 365 et à d’autres services Microsoft en raison d’un routage noir ou asymétrique. Cela se produit lorsque les demandes adressées aux services Microsoft sont routées via ExpressRoute, mais que les réponses sont routées sur Internet, ou vice versa, et que les réponses sont supprimées par des périphériques réseau avec état tels que des pare-feu.
La méthode la plus courante que vous pouvez utiliser pour répondre aux exigences ci-dessus consiste à utiliser la traduction d’adresses réseau source, soit implémentée dans le cadre de votre réseau, soit fournie par votre opérateur ExpressRoute. Nat source vous permet d’extraire les détails et l’adressage IP privé de votre réseau Internet à partir d’ExpressRoute et ; couplé à des publicités de routage IP appropriées, fournissent un mécanisme facile pour garantir la symétrie des chemins. Si vous utilisez des périphériques réseau avec état spécifiques aux emplacements de peering ExpressRoute, vous devez implémenter des pools NAT distincts pour chaque peering ExpressRoute afin de garantir la symétrie des chemins.
En savoir plus sur la configuration requise de nat ExpressRoute.
Ajoutez les modifications pour la connectivité sortante au diagramme de topologie de réseau.
Concevoir la connectivité du service entrant
La plupart des déploiements Microsoft 365 d’entreprise supposent une certaine forme de connectivité entrante de Microsoft 365 vers des services locaux, tels que pour Exchange, SharePoint et Skype Entreprise scénarios hybrides, migrations de boîtes aux lettres et authentification à l’aide de l’infrastructure ADFS. Quand ExpressRoute vous activez un chemin de routage supplémentaire entre votre réseau local et Microsoft pour la connectivité sortante, ces connexions entrantes peuvent être affectées par inadvertance par le routage asymétrique, même si vous envisagez que ces flux continuent à utiliser Internet. Quelques précautions décrites ci-dessous sont recommandées pour vous assurer qu’il n’y a aucun impact sur les flux entrants basés sur Internet de Microsoft 365 vers les systèmes locaux.
Pour réduire les risques de routage asymétrique pour les flux de trafic réseau entrant, toutes les connexions entrantes doivent utiliser la traduction d’adresses réseau source avant d’être routées vers des segments de votre réseau, qui ont une visibilité de routage dans ExpressRoute. Si les connexions entrantes sont autorisées sur un segment réseau avec une visibilité de routage dans ExpressRoute sans NAT source, les requêtes provenant de Microsoft 365 entrent à partir d’Internet, mais la réponse qui retourne à Microsoft 365 préférera le chemin réseau ExpressRoute au réseau Microsoft, ce qui entraîne un routage asymétrique.
Vous pouvez envisager l’un des modèles d’implémentation suivants pour répondre à cette exigence :
Effectuez la traduction d’adresses réseau source avant que les requêtes soient acheminées vers votre réseau interne à l’aide d’un équipement réseau tel que des pare-feu ou des équilibreurs de charge sur le chemin d’accès d’Internet à vos systèmes locaux.
Assurez-vous que les itinéraires ExpressRoute ne sont pas propagés aux segments réseau où résident les services entrants, tels que les serveurs frontaux ou les systèmes proxy inverses, qui gèrent les connexions Internet.
La prise en compte explicite de ces scénarios dans votre réseau et la conservation de tous les flux de trafic réseau entrant sur Internet permettent de réduire le risque de déploiement et de fonctionnement du routage asymétrique.
Dans certains cas, vous pouvez choisir de diriger certains flux entrants sur des connexions ExpressRoute. Pour ces scénarios, prenez en compte les considérations supplémentaires suivantes.
Microsoft 365 peut uniquement cibler des points de terminaison locaux qui utilisent des adresses IP publiques. Cela signifie que même si le point de terminaison entrant local est exposé uniquement à Microsoft 365 sur ExpressRoute, il doit toujours avoir une adresse IP publique associée.
Toutes les résolutions de noms DNS effectuées par les services Microsoft 365 pour résoudre les points de terminaison locaux se produisent à l’aide du DNS public. Cela signifie que vous devez inscrire le nom de domaine complet des points de terminaison de service entrants aux mappages IP sur Internet.
Pour recevoir des connexions réseau entrantes via ExpressRoute, les sous-réseaux IP publics de ces points de terminaison doivent être publiés auprès de Microsoft via ExpressRoute.
Évaluez soigneusement ces flux de trafic réseau entrant pour vous assurer que la sécurité et les contrôles réseau appropriés leur sont appliqués conformément à la sécurité et aux stratégies réseau de votre entreprise.
Une fois que vos points de terminaison entrants locaux sont publiés sur Microsoft via ExpressRoute, ExpressRoute devient effectivement le chemin de routage préféré pour ces points de terminaison pour tous les services Microsoft, y compris Microsoft 365. Cela signifie que ces sous-réseaux de point de terminaison doivent être utilisés uniquement pour les communications avec les services Microsoft 365 et aucun autre service sur le réseau Microsoft. Dans le cas contraire, votre conception entraîne un routage asymétrique où les connexions entrantes d’autres services Microsoft préfèrent acheminer le trafic entrant sur ExpressRoute, tandis que le chemin d’accès de retour utilise Internet.
En cas d’arrêt d’un circuit ExpressRoute ou d’un emplacement de réunion, vous devez vous assurer que les points de terminaison entrants locaux sont toujours disponibles pour accepter les demandes sur un chemin réseau distinct. Cela peut signifier la publicité de sous-réseaux pour ces points de terminaison via plusieurs circuits ExpressRoute.
Nous vous recommandons d’appliquer la NAT source à tous les flux de trafic réseau entrant entrant dans votre réseau via ExpressRoute, en particulier lorsque ces flux traversent des périphériques réseau avec état tels que des pare-feu.
Certains services locaux, tels que le proxy ADFS ou la découverte automatique Exchange, peuvent recevoir des demandes entrantes des services Microsoft 365 et des utilisateurs d’Internet. Pour ces demandes, Microsoft 365 cible le même nom de domaine complet que les demandes des utilisateurs sur Internet. Autoriser les connexions utilisateur entrantes à partir d’Internet vers ces points de terminaison locaux, tout en forçant les connexions Microsoft 365 à utiliser ExpressRoute, représente une complexité de routage importante. Pour la grande majorité des clients, l’implémentation de scénarios complexes sur ExpressRoute n’est pas recommandée en raison de considérations opérationnelles. Cette surcharge supplémentaire inclut la gestion des risques de routage asymétrique et vous obligera à gérer soigneusement les publicités et les stratégies de routage sur plusieurs dimensions.
Mettre à jour votre plan de topologie réseau pour montrer comment éviter les itinéraires asymétriques
Vous souhaitez éviter le routage asymétrique pour vous assurer que les personnes de votre organization peuvent utiliser Microsoft 365 en toute transparence ainsi que d’autres services importants sur Internet. Il existe deux configurations courantes que les clients ont qui provoquent un routage asymétrique. C’est le moment de passer en revue la configuration réseau que vous envisagez d’utiliser et de case activée si l’un de ces scénarios de routage asymétrique peut exister.
Pour commencer, nous allons examiner quelques situations différentes associées au diagramme de réseau suivant. Dans ce diagramme, tous les serveurs qui reçoivent des demandes entrantes, tels que les serveurs ADFS ou hybrides locaux, se trouvent dans le centre de données du New Jersey et sont publiés sur Internet.
Bien que le réseau de périmètre soit sécurisé, aucune source NAT n’est disponible pour les requêtes entrantes.
Les serveurs du centre de données du New Jersey peuvent voir les itinéraires Internet et ExpressRoute.
Nous avons également des suggestions sur la façon de les corriger.
Problème 1 : Connexion cloud-local via Internet
Le diagramme suivant illustre le chemin d’accès réseau asymétrique pris lorsque votre configuration réseau ne fournit pas de NAT pour les requêtes entrantes à partir du cloud Microsoft sur Internet.
La requête entrante de Microsoft 365 récupère l’adresse IP du point de terminaison local à partir du DNS public et envoie la requête à votre réseau de périmètre.
Dans cette configuration défectueuse, aucune source NAT n’est configurée ou disponible sur le réseau de périmètre où le trafic est envoyé, ce qui entraîne l’utilisation de l’adresse IP source réelle comme destination de retour.
Le serveur de votre réseau achemine le trafic de retour vers Microsoft 365 via toute connexion réseau ExpressRoute disponible.
Le résultat est un chemin asymétrique pour ce flux vers Microsoft 365, ce qui entraîne une rupture de connexion.
Solution 1a : NAT source
L’ajout d’un NAT source à la requête entrante résout ce réseau mal configuré. Dans ce schéma :
La requête entrante continue d’entrer via le réseau de périmètre du centre de données du New Jersey. Cette fois, le NAT source est disponible.
La réponse du serveur est acheminée vers l’adresse IP associée au NAT source au lieu de l’adresse IP d’origine, ce qui entraîne le retour de la réponse le long du même chemin réseau.
Solution 1b : Étendue de la route
Vous pouvez également choisir de ne pas autoriser la publication des préfixes BGP ExpressRoute, en supprimant le chemin d’accès réseau secondaire pour ces ordinateurs. Dans ce schéma :
La requête entrante continue d’entrer via le réseau de périmètre du centre de données du New Jersey. Cette fois, les préfixes publiés par Microsoft sur le circuit ExpressRoute ne sont pas disponibles pour le centre de données du New Jersey.
La réponse du serveur est routée vers l’adresse IP associée à l’adresse IP d’origine sur le seul itinéraire disponible, ce qui entraîne le retour de la réponse le long du même chemin réseau.
Problème 2 : connexion cloud-local via ExpressRoute
Le diagramme suivant illustre le chemin d’accès réseau asymétrique pris lorsque votre configuration réseau ne fournit pas de NAT pour les demandes entrantes du cloud Microsoft sur ExpressRoute.
La requête entrante de Microsoft 365 récupère l’adresse IP à partir de DNS et envoie la requête à votre réseau de périmètre.
Dans cette configuration défectueuse, aucune source NAT n’est configurée ou disponible sur le réseau de périmètre où le trafic est envoyé, ce qui entraîne l’utilisation de l’adresse IP source réelle comme destination de retour.
L’ordinateur de votre réseau achemine le trafic de retour vers Microsoft 365 via toute connexion réseau ExpressRoute disponible.
Le résultat est une connexion asymétrique à Microsoft 365.
Solution 2 : NAT source
L’ajout d’un NAT source à la requête entrante résout ce réseau mal configuré. Dans ce schéma :
La requête entrante continue d’entrer via le réseau de périmètre du centre de données de New York. Cette fois, le NAT source est disponible.
La réponse du serveur est acheminée vers l’adresse IP associée au NAT source au lieu de l’adresse IP d’origine, ce qui entraîne le retour de la réponse le long du même chemin réseau.
Vérifier sur papier que la conception du réseau a une symétrie de chemin
À ce stade, vous devez vérifier sur papier que votre plan d’implémentation offre une symétrie de routage pour les différents scénarios dans lesquels vous utiliserez Microsoft 365. Vous identifierez l’itinéraire réseau spécifique qui doit être pris lorsqu’une personne utilise différentes fonctionnalités du service. Du réseau local et du routage WAN, aux appareils de périmètre, au chemin de connectivité ; ExpressRoute ou Internet, et sur la connexion au point de terminaison en ligne.
Vous devez le faire pour tous les services réseau Microsoft 365 précédemment identifiés comme des services que votre organization adoptera.
Il est utile de faire cette promenade papier des itinéraires avec une deuxième personne. Expliquez-leur d’où chaque tronçon réseau doit obtenir son itinéraire suivant et assurez-vous que vous êtes familiarisé avec les chemins de routage. N’oubliez pas qu’ExpressRoute fournit toujours un itinéraire plus étendu aux adresses IP du serveur Microsoft, ce qui lui permet de réduire le coût d’itinéraire qu’un itinéraire Internet par défaut.
Concevoir la configuration de la connectivité du client
Si vous utilisez un serveur proxy pour le trafic lié à Internet, vous devez ajuster les fichiers de configuration pac ou client pour vous assurer que les ordinateurs clients de votre réseau sont correctement configurés pour envoyer le trafic ExpressRoute souhaité à Microsoft 365 sans transiter par votre serveur proxy, et que le trafic restant, y compris un trafic Microsoft 365, est envoyé au proxy approprié. Lisez notre guide sur la gestion des points de terminaison Microsoft 365, par exemple, les fichiers PAC.
Remarque
Les points de terminaison changent fréquemment, aussi souvent qu’une fois par semaine. Vous devez uniquement apporter des modifications en fonction des services et des fonctionnalités que votre organization a adoptés pour réduire le nombre de modifications que vous devrez apporter pour rester à jour. Prêtez une attention particulière à la Date d’entrée en vigueur dans le flux RSS où les modifications sont annoncées et un enregistrement de toutes les modifications passées, les adresses IP qui sont annoncées peuvent ne pas être publiées ou supprimées de la publication tant que la date d’effet n’est pas atteinte.
Garantir la symétrie de l’itinéraire
Les serveurs frontaux Microsoft 365 sont accessibles sur Internet et ExpressRoute. Ces serveurs préféreront router vers des circuits locaux via des circuits ExpressRoute lorsque les deux sont disponibles. Pour cette raison, il existe une possibilité d’asymétrie des itinéraires si le trafic de votre réseau préfère être acheminé sur vos circuits Internet. Les itinéraires asymétriques sont un problème, car les appareils qui effectuent l’inspection des paquets avec état peuvent bloquer le trafic de retour qui suit un chemin différent de celui des paquets sortants suivis.
Que vous lancez une connexion à Microsoft 365 via Internet ou ExpressRoute, la source doit être une adresse routable publiquement. Avec de nombreux clients appairant directement avec Microsoft, il n’est pas possible d’avoir des adresses privées où la duplication est possible entre les clients.
Voici les scénarios dans lesquels les communications entre Microsoft 365 et votre réseau local sont lancées. Pour simplifier la conception de votre réseau, nous vous recommandons de router les éléments suivants sur le chemin Internet.
Les services SMTP tels que le courrier d’un locataire Exchange Online vers un hôte local ou la messagerie SharePoint envoyée de SharePoint à un hôte local. Le protocole SMTP est utilisé plus largement au sein du réseau de Microsoft que les préfixes d’itinéraire partagés sur les circuits ExpressRoute et la publicité de serveurs SMTP locaux sur ExpressRoute entraîne des échecs avec ces autres services.
ADFS lors de la validation du mot de passe pour la connexion.
Pour que Microsoft puisse rediriger vers votre réseau pour ces flux de trafic bidirectionnel, les itinéraires BGP vers vos appareils locaux doivent être partagés avec Microsoft. Lorsque vous publiez des préfixes de routage vers Microsoft via ExpressRoute, vous devez suivre les bonnes pratiques suivantes :
Ne publiez pas le même préfixe d’itinéraire d’adresse IP publique sur l’Internet public et sur ExpressRoute. Il est recommandé que les annonces de préfixe de routage BGP IP sur Microsoft sur ExpressRoute proviennent d’une plage qui n’est pas du tout annoncée sur Internet. Si cela n’est pas possible en raison de l’espace d’adressage IP disponible, il est essentiel de vous assurer que vous publiez une plage plus spécifique sur ExpressRoute que tous les circuits Internet.
Utilisez des pools d’adresses IP NAT distincts par circuit ExpressRoute et distincts de ceux de vos circuits Internet.
Tout itinéraire publié sur Microsoft attirera le trafic réseau de n’importe quel serveur du réseau de Microsoft, et pas seulement ceux pour lesquels les itinéraires sont publiés sur votre réseau via ExpressRoute. Publiez uniquement les itinéraires vers les serveurs où les scénarios de routage sont définis et bien compris par votre équipe. Publiez des préfixes d’itinéraire d’adresses IP distincts sur chacun des circuits ExpressRoute de votre réseau.
Haute disponibilité et basculement avec Azure ExpressRoute
Nous vous recommandons de provisionner au moins deux circuits actifs de chaque sortie avec ExpressRoute vers votre fournisseur ExpressRoute. Il s’agit de l’endroit le plus courant où nous constatons des échecs pour les clients et vous pouvez facilement les éviter en approvisionnant une paire de circuits ExpressRoute actifs/actifs. Nous recommandons également au moins deux circuits Internet actifs/actifs, car de nombreux services Microsoft 365 ne sont disponibles que sur Internet.
À l’intérieur du point de sortie de votre réseau se trouvent de nombreux autres appareils et circuits qui jouent un rôle essentiel dans la façon dont les gens perçoivent la disponibilité. Ces parties de vos scénarios de connectivité ne sont pas couvertes par les contrats SLA ExpressRoute ou Microsoft 365, mais elles jouent un rôle essentiel dans la disponibilité du service de bout en bout telle qu’elle est perçue par les personnes de votre organization.
Concentrez-vous sur les personnes qui utilisent et utilisent Microsoft 365, si une défaillance d’un composant affecte l’expérience des utilisateurs à utiliser le service, recherchez des moyens de limiter le pourcentage total de personnes affectées. Si un mode de basculement est complexe sur le plan opérationnel, tenez compte de l’expérience de récupération longue des utilisateurs et recherchez des modes de basculement opérationnels simples et automatisés.
En dehors de votre réseau, Microsoft 365, ExpressRoute et votre fournisseur ExpressRoute ont tous des niveaux de disponibilité différents.
Disponibilité du service
Les services Microsoft 365 sont couverts par des contrats de niveau de service bien définis, qui incluent des métriques de disponibilité et de disponibilité pour des services individuels. L’une des raisons pour lesquelles Microsoft 365 peut maintenir de tels niveaux de disponibilité de service élevés est la possibilité pour des composants individuels de basculer en toute transparence entre les nombreux centres de données Microsoft, à l’aide du réseau Microsoft mondial. Ce basculement s’étend du centre de données et du réseau aux points de sortie Internet multiples, et permet le basculement en toute transparence du point de vue des personnes qui utilisent le service.
ExpressRoute fournit un contrat SLA de disponibilité de 99,9 % sur des circuits dédiés individuels entre microsoft Network Edge et l’infrastructure du fournisseur ou du partenaire ExpressRoute. Ces niveaux de service sont appliqués au niveau du circuit ExpressRoute, qui se compose de deux interconnexions indépendantes entre l’équipement Microsoft redondant et l’équipement du fournisseur de réseau dans chaque emplacement de peering.
Disponibilité du fournisseur
- Les dispositions de niveau de service de Microsoft s’arrêtent à votre fournisseur ou partenaire ExpressRoute. C’est également le premier endroit où vous pouvez faire des choix qui influenceront votre niveau de disponibilité. Vous devez évaluer attentivement les caractéristiques de l’architecture, de la disponibilité et de la résilience que votre fournisseur ExpressRoute propose entre votre périmètre réseau et la connexion de vos fournisseurs à chaque emplacement de peering Microsoft. Portez une attention particulière aux aspects logiques et physiques de la redondance, de l’équipement de peering, des circuits WAN fournis par l’opérateur et de tous les services à valeur ajoutée supplémentaires tels que les services NAT ou les pare-feu managés.
Conception de votre plan de disponibilité
Nous vous recommandons vivement de planifier et de concevoir la haute disponibilité et la résilience dans vos scénarios de connectivité de bout en bout pour Microsoft 365. Une conception doit inclure :
Aucun point de défaillance unique, y compris les circuits Internet et ExpressRoute.
Réduction du nombre de personnes affectées et de la durée de cet impact pour la plupart des modes de défaillance prévus.
Optimisation du processus de récupération simple, reproductible et automatique à partir des modes de défaillance les plus attendus.
Prise en charge de toutes les demandes du trafic et des fonctionnalités de votre réseau par le biais de chemins redondants, sans dégradation substantielle.
Vos scénarios de connectivité doivent inclure une topologie de réseau optimisée pour plusieurs chemins réseau indépendants et actifs vers Microsoft 365. Cela permet d’obtenir une meilleure disponibilité de bout en bout qu’une topologie optimisée uniquement pour la redondance au niveau de l’appareil ou de l’équipement individuel.
Conseil
Si vos utilisateurs sont répartis sur plusieurs continents ou régions géographiques et que chacun de ces emplacements se connecte via des circuits WAN redondants à un emplacement local unique où se trouve un seul circuit ExpressRoute, vos utilisateurs auront moins de disponibilité de service de bout en bout qu’une conception de topologie réseau qui inclut des circuits ExpressRoute indépendants qui connectent les différentes régions à l’emplacement de peering le plus proche.
Nous vous recommandons de provisionner au moins deux circuits ExpressRoute avec chaque circuit se connectant à avec un emplacement de peering géographique différent. Vous devez provisionner cette paire de circuits actif/actif pour chaque région où les utilisateurs utiliseront la connectivité ExpressRoute pour les services Microsoft 365. Cela permet à chaque région de rester connectée lors d’un sinistre qui affecte un emplacement majeur tel qu’un centre de données ou un emplacement de peering. En les configurant comme actifs/actifs, le trafic des utilisateurs finaux peut être distribué sur plusieurs chemins d’accès réseau. Cela réduit l’étendue des personnes affectées pendant les pannes d’appareil ou d’équipement réseau.
Nous vous déconseillons d’utiliser un seul circuit ExpressRoute avec Internet comme sauvegarde.
Exemple : Basculement et haute disponibilité
La conception multigéographique de Contoso a fait l’objet d’une révision du routage, de la bande passante et de la sécurité, et doit maintenant faire l’objet d’une révision de haute disponibilité. Contoso considère que la haute disponibilité couvre trois catégories : résilience, fiabilité et redondance.
La résilience permet à Contoso de récupérer rapidement après des défaillances. La fiabilité permet à Contoso d’offrir un résultat cohérent au sein du système. La redondance permet à Contoso de se déplacer entre une ou plusieurs instances d’infrastructure mises en miroir.
Dans chaque configuration de périphérie, Contoso a des pare-feu, des proxys et des IDS redondants. Par Amérique du Nord, Contoso dispose d’une configuration de périphérie dans son centre de données Dallas et d’une autre configuration de périphérie dans son centre de données en Virginie. L’équipement redondant à chaque emplacement offre une résilience à cet emplacement.
La configuration réseau chez Contoso est basée sur quelques principes clés :
Dans chaque région géographique, il existe plusieurs circuits Azure ExpressRoute.
Chaque circuit d’une région peut prendre en charge tout le trafic réseau au sein de cette région.
Le routage préférera clairement l’un ou l’autre chemin en fonction de la disponibilité, de l’emplacement, etc.
Le basculement entre les circuits Azure ExpressRoute se produit automatiquement sans configuration ou action supplémentaire requise par Contoso.
Le basculement entre les circuits Internet se produit automatiquement sans configuration ou action supplémentaire requise par Contoso.
Dans cette configuration, avec une redondance au niveau physique et virtuel, Contoso est en mesure d’offrir une résilience locale, une résilience régionale et une résilience globale de manière fiable. Contoso a choisi cette configuration après avoir évalué un seul circuit Azure ExpressRoute par région, ainsi que la possibilité de basculer vers Internet.
Si Contoso n’a pas pu avoir plusieurs circuits Azure ExpressRoute par région, le routage du trafic provenant de Amérique du Nord vers le circuit Azure ExpressRoute en Asie-Pacifique ajoute un niveau de latence inacceptable et la configuration du redirecteur DNS requise ajoute de la complexité.
L’utilisation d’Internet comme configuration de sauvegarde n’est pas recommandée. Cela rompt le principe de fiabilité de Contoso, ce qui entraîne une expérience incohérente de l’utilisation de la connexion. En outre, une configuration manuelle est nécessaire pour basculer en tenant compte des publications BGP qui ont été configurées, de la configuration NAT, de la configuration DNS et de la configuration du proxy. Cette complexité de basculement supplémentaire augmente le temps de récupération et diminue leur capacité à diagnostiquer et à dépanner les étapes impliquées.
Vous avez toujours des questions sur la façon de planifier et d’implémenter la gestion du trafic ou Azure ExpressRoute ? Lisez le reste de nos conseils sur le réseau et les performances ou le FAQ Azure ExpressRoute.
Application de contrôles de sécurité à Azure ExpressRoute pour les scénarios Microsoft 365
La sécurisation de la connectivité Azure ExpressRoute commence par les mêmes principes que la sécurisation de la connectivité Internet. De nombreux clients choisissent de déployer des contrôles réseau et de périmètre le long du chemin ExpressRoute connectant leur réseau local à Microsoft 365 et à d’autres clouds Microsoft. Ces contrôles peuvent inclure des pare-feu, des proxys d’application, la prévention des fuites de données, la détection des intrusions, les systèmes de prévention des intrusions, etc. Dans de nombreux cas, les clients appliquent différents niveaux de contrôle au trafic lancé à partir d’un site local vers Microsoft, au trafic initié par Microsoft vers le réseau local du client, et au trafic initié à partir d’un site local vers une destination Internet générale.
Voici quelques exemples d’intégration de la sécurité au modèle de connectivité ExpressRoute que vous choisissez de déployer.
| Option d’intégration ExpressRoute | Modèle de périmètre de sécurité réseau |
|---|---|
| Colocalisé dans un échange cloud |
Installez ou utilisez une infrastructure de sécurité/de périmètre existante dans l’installation de colocalisation où la connexion ExpressRoute est établie. Utilisez l’installation de colocalisation uniquement à des fins de routage/interconnexion et les connexions de retour de l’installation de colocalisation vers l’infrastructure de périmètre/de sécurité locale. |
| Ethernet point à point |
Arrêtez la connexion ExpressRoute point à point dans l’emplacement de l’infrastructure de périmètre/de sécurité locale existante. Installez une nouvelle infrastructure de sécurité/de périmètre spécifique au chemin ExpressRoute et arrêtez la connexion point à point. |
| Any-to-Any IPVPN |
Utilisez une infrastructure de sécurité/de périmètre locale existante à tous les emplacements qui entrent dans l’IPVPN utilisé pour ExpressRoute pour la connectivité Microsoft 365. Épingle à cheveux IPVPN utilisée pour ExpressRoute pour Microsoft 365 vers des emplacements locaux spécifiques désignés comme sécurité/périmètre. |
Certains fournisseurs de services proposent également des fonctionnalités de sécurité/périmètre managées dans le cadre de leurs solutions d’intégration à Azure ExpressRoute.
Lorsque vous envisagez l’emplacement de la topologie des options de périmètre réseau/de sécurité utilisées pour ExpressRoute pour les connexions Microsoft 365, voici des considérations supplémentaires
La profondeur et le type des contrôles de sécurité/réseau peuvent avoir un impact sur les performances et la scalabilité de l’expérience utilisateur de Microsoft 365.
Les flux sortants (sur site-Microsoft>) et entrants (Microsoft local>) [si activés] peuvent avoir des exigences différentes. Celles-ci sont probablement différentes de celles du trafic sortant vers des destinations Internet générales.
Les exigences de Microsoft 365 pour les ports/protocoles et les sous-réseaux IP nécessaires sont identiques, que le trafic soit acheminé via ExpressRoute pour Microsoft 365 ou via Internet.
L’emplacement topologique des contrôles de sécurité/réseau client détermine le réseau final de bout en bout entre l’utilisateur et le service Microsoft 365 et peut avoir un impact substantiel sur la latence et la congestion du réseau.
Les clients sont encouragés à concevoir leur topologie de sécurité/périmètre pour une utilisation avec ExpressRoute pour Microsoft 365 conformément aux meilleures pratiques en matière de redondance, de haute disponibilité et de récupération d’urgence.
Voici un exemple de Contoso qui compare les différentes options de connectivité Azure ExpressRoute avec les modèles de sécurité de périmètre décrits ci-dessus.
Exemple : sécurisation d’Azure ExpressRoute
Contoso envisage d’implémenter Azure ExpressRoute et, après avoir planifié l’architecture optimale pour ExpressRoute pour Microsoft 365 et après avoir utilisé les conseils ci-dessus pour comprendre les besoins en bande passante, elle détermine la meilleure méthode pour sécuriser son périmètre.
Pour Contoso, une organization multinationale avec des emplacements sur plusieurs continents, la sécurité doit s’étendre à tous les périmètres. L’option de connectivité optimale pour Contoso est une connexion multipoint avec plusieurs emplacements de peering dans le monde entier pour répondre aux besoins de ses employés sur chaque continent. Chaque continent inclut des circuits Azure ExpressRoute redondants au sein du continent et la sécurité doit couvrir tous ces circuits.
L’infrastructure existante de Contoso est fiable et peut gérer le travail supplémentaire. Par conséquent, Contoso est en mesure d’utiliser l’infrastructure pour sa sécurité de périmètre Azure ExpressRoute et Internet. Si ce n’était pas le cas, Contoso pourrait choisir d’acheter plus d’équipement pour compléter son équipement existant ou pour gérer un autre type de connexion.
Planification de la bande passante pour Azure ExpressRoute
Chaque client Microsoft 365 a des besoins uniques en bande passante en fonction du nombre de personnes à chaque emplacement, de leur niveau d’activité avec chaque application Microsoft 365 et d’autres facteurs tels que l’utilisation d’équipements locaux ou hybrides et des configurations de sécurité réseau.
Une bande passante trop faible entraîne une congestion, des retransmissions de données et des retards imprévisibles. Une bande passante trop importante entraîne des coûts inutiles. Sur un réseau existant, la bande passante est souvent désignée sous la forme d’un pourcentage de la marge d’entrée disponible sur le circuit. Le fait d’avoir 10 % d’espace libre entraînera probablement des congestions et une marge de 80 % signifie généralement un coût inutile. Les allocations cibles d’espace libre classiques sont de 20 % à 50 %.
Pour trouver le bon niveau de bande passante, le meilleur mécanisme consiste à tester votre consommation réseau existante. Il s’agit de la seule façon d’obtenir une mesure réelle de l’utilisation et des besoins, car chaque configuration réseau et chaque application sont à certains égards uniques. Lors de la mesure, vous devez prêter une attention particulière à la consommation totale de bande passante, à la latence et à la congestion TCP pour comprendre les besoins de votre réseau.
Une fois que vous avez une base de référence estimée qui inclut toutes les applications réseau, pilotez Microsoft 365 avec un petit groupe qui comprend les différents profils des personnes de votre organization pour déterminer l’utilisation réelle, et utilisez les deux mesures pour estimer la quantité de bande passante dont vous aurez besoin pour chaque emplacement de bureau. S’il existe des problèmes de latence ou de congestion TCP détectés dans vos tests, vous devrez peut-être rapprocher la sortie des personnes utilisant Microsoft 365 ou supprimer l’analyse réseau intensive telle que le déchiffrement/inspection SSL.
Toutes nos recommandations sur le type de traitement réseau recommandé s’appliquent aux circuits ExpressRoute et Internet. Il en va de même pour le reste des conseils sur notre site d’optimisation des performances.
Créer vos procédures de déploiement et de test
Votre plan d’implémentation doit inclure à la fois la planification de test et de restauration. Si votre implémentation ne fonctionne pas comme prévu, le plan doit être conçu pour affecter le moins de personnes avant que les problèmes ne soient détectés. Voici quelques principes généraux que votre plan doit prendre en compte.
Étape de l’intégration du segment réseau et du service utilisateur pour réduire les interruptions.
Planifiez le test des itinéraires avec traceroute et connexion TCP à partir d’un hôte connecté à Internet distinct.
De préférence, les tests des services entrants et sortants doivent être effectués sur un réseau de test isolé avec un client Microsoft 365 de test.
Vous pouvez également effectuer des tests sur un réseau de production si le client n’utilise pas encore Microsoft 365 ou est en phase pilote.
Vous pouvez également effectuer des tests pendant une panne de production qui est réservée au test et à la surveillance.
Vous pouvez également effectuer des tests en vérifiant les itinéraires de chaque service sur chaque nœud de routeur de couche 3. Cette méthode de secours ne doit être utilisée que si aucun autre test n’est possible, car l’absence de tests physiques présente un risque.
Créer vos procédures de déploiement
Vos procédures de déploiement doivent être déployées sur de petits groupes de personnes en plusieurs étapes pour permettre des tests avant de les déployer sur de plus grands groupes de personnes. Voici plusieurs façons de mettre en scène le déploiement d’ExpressRoute.
Configurez ExpressRoute avec le peering Microsoft et transférez les annonces de routage à un seul hôte uniquement à des fins de test intermédiaire.
Publiez d’abord des itinéraires vers le réseau ExpressRoute sur un seul segment de réseau et développez les annonces de routage par segment réseau ou région.
Si vous déployez Microsoft 365 pour la première fois, utilisez le déploiement réseau ExpressRoute comme pilote pour quelques personnes.
Si vous utilisez des serveurs proxy, vous pouvez également configurer un fichier PAC de test pour diriger quelques personnes vers ExpressRoute avec des tests et des commentaires avant d’en ajouter d’autres.
Votre plan d’implémentation doit répertorier chacune des procédures de déploiement qui doivent être effectuées ou des commandes qui doivent être utilisées pour déployer la configuration réseau. Lorsque le temps de panne du réseau arrive, toutes les modifications apportées doivent provenir du plan de déploiement écrit qui a été écrit à l’avance et examiné par les pairs. Consultez nos conseils sur la configuration technique d’ExpressRoute.
Mise à jour de vos enregistrements TXT SPF si vous avez modifié les adresses IP des serveurs locaux qui continueront à envoyer des e-mails.
Mise à jour des entrées DNS pour les serveurs locaux si vous avez modifié les adresses IP pour prendre en charge une nouvelle configuration NAT.
Vérifiez que vous êtes abonné au flux RSS pour les notifications de point de terminaison Microsoft 365 afin de gérer les configurations de routage ou de proxy.
Une fois votre déploiement ExpressRoute terminé, les procédures du plan de test doivent être exécutées. Les résultats de chaque procédure doivent être consignés. Vous devez inclure des procédures de restauration vers l’environnement de production d’origine si les résultats du plan de test indiquent que l’implémentation n’a pas réussi.
Créer vos procédures de test
Vos procédures de test doivent inclure des tests pour chaque service réseau sortant et entrant pour Microsoft 365 qui utilisera ExpressRoute et ceux qui ne le seront pas. Les procédures doivent inclure des tests à partir de chaque emplacement réseau unique, y compris les utilisateurs qui ne sont pas locaux dans le réseau local de l’entreprise.
Voici quelques exemples d’activités de test.
Effectuez un test ping à partir de votre routeur local vers votre routeur d’opérateur réseau.
Vérifiez que plus de 500 annonces d’adresses IP Microsoft 365 et CRM Online sont reçues par votre routeur local.
Vérifiez que votre NAT entrant et sortant fonctionne entre ExpressRoute et le réseau interne.
Vérifiez que les itinéraires vers votre NAT sont publiés à partir de votre routeur.
Vérifiez qu’ExpressRoute a accepté vos préfixes publiés.
- Utilisez l’applet de commande suivante pour vérifier les publications de peering :
Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeeringVérifiez que votre plage d’adresses IP NAT publiques n’est pas annoncée à Microsoft par le biais d’un autre circuit ExpressRoute ou réseau Internet public, sauf s’il s’agit d’un sous-ensemble spécifique d’une plage plus grande comme dans l’exemple précédent.
Les circuits ExpressRoute sont couplés, vérifiez que les deux sessions BGP sont en cours d’exécution.
Configurez un seul hôte à l’intérieur de votre NAT et utilisez ping, tracert et tcpping pour tester la connectivité entre le nouveau circuit et l’hôte outlook.office365.com. Vous pouvez également utiliser un outil tel que Wireshark ou Microsoft Network Monitor 3.4 sur un port mis en miroir vers le MSEE pour vérifier que vous êtes en mesure de vous connecter à l’adresse IP associée à outlook.office365.com.
Tester la fonctionnalité au niveau de l’application pour Exchange Online.
Test Outlook est en mesure de se connecter à Exchange Online et d’envoyer/recevoir des e-mails.
Test Outlook est en mesure d’utiliser le mode en ligne.
Testez la connectivité du smartphone et la capacité d’envoi/réception.
- Tester les fonctionnalités au niveau de l’application pour SharePoint
Tester OneDrive Entreprise client de synchronisation.
Tester l’accès web SharePoint.
- Tester les fonctionnalités au niveau de l’application pour Skype Entreprise scénarios d’appel :
Participer à une téléconférence en tant qu’utilisateur authentifié [invitation lancée par l’utilisateur final].
Inviter l’utilisateur à une téléconférence [invitation envoyée à partir du MCU].
Participez à une conférence en tant qu’utilisateur anonyme à l’aide de l’application web Skype Entreprise.
Rejoignez l’appel à partir de votre connexion PC câblée, de votre téléphone IP et de votre appareil mobile.
Appel à l’utilisateur fédéré o Appel à la validation RTC : l’appel est terminé, la qualité de l’appel est acceptable, le temps de connexion est acceptable.
Vérifiez que le status de présence pour les contacts est mis à jour pour les membres du locataire et les utilisateurs fédérés.
Problèmes courants
Le routage asymétrique est le problème d’implémentation le plus courant. Voici quelques sources courantes à rechercher :
Utilisation d’une topologie de routage de réseau ouvert ou plat sans NAT source en place.
N’utilisez pas SNAT pour acheminer vers les services entrants par le biais des connexions Internet et ExpressRoute.
Ne pas tester les services entrants sur ExpressRoute sur un réseau de test avant le déploiement à grande échelle.
Déploiement de la connectivité ExpressRoute via votre réseau
Planifiez votre déploiement sur un segment du réseau à la fois, en déployant progressivement la connectivité à différentes parties du réseau avec un plan de restauration pour chaque nouveau segment de réseau. Si votre déploiement est aligné sur un déploiement Microsoft 365, déployez d’abord sur vos utilisateurs pilotes Microsoft 365 et étendez-les à partir de là.
D’abord pour votre test, puis pour la production :
Exécutez les étapes de déploiement pour activer ExpressRoute.
Vérifiez que les itinéraires réseau sont comme prévu.
Effectuez des tests sur chaque service entrant et sortant.
Restaurer si vous rencontrez des problèmes.
Configurer une connexion de test à ExpressRoute avec un segment réseau de test
Maintenant que vous avez le plan complet sur le papier, il est temps de tester à petite échelle. Dans ce test, vous allez établir une connexion ExpressRoute unique avec Microsoft Peering à un sous-réseau de test sur votre réseau local. Vous pouvez configurer un locataire Microsoft 365 d’évaluation avec une connectivité vers et à partir du sous-réseau de test et inclure tous les services sortants et entrants que vous utiliserez en production dans le sous-réseau de test. Configurez DNS pour le segment réseau de test et établissez tous les services entrants et sortants. Exécutez votre plan de test et vérifiez que vous êtes familiarisé avec le routage pour chaque service et la propagation de l’itinéraire.
Exécuter les plans de déploiement et de test
À mesure que vous complétez les éléments décrits ci-dessus, case activée les zones que vous avez terminées et vérifiez que vous et votre équipe les avez examinées avant d’exécuter vos plans de déploiement et de test.
Liste des services sortants et entrants impliqués dans la modification du réseau.
Diagramme de l’architecture réseau globale montrant à la fois les emplacements de sortie Internet et de réunion ExpressRoute.
Diagramme de routage réseau illustrant les différents chemins d’accès réseau utilisés pour chaque service déployé.
Un plan de déploiement avec des étapes pour implémenter les modifications et restaurer si nécessaire.
Un plan de test pour tester chaque service microsoft 365 et réseau.
Validation papier terminée des itinéraires de production pour les services entrants et sortants.
Un test terminé sur un segment de réseau de test, y compris les tests de disponibilité.
Choisissez une fenêtre de panne suffisamment longue pour s’exécuter dans l’ensemble du plan de déploiement et le plan de test, disposez d’un certain temps pour la résolution des problèmes et du temps de restauration si nécessaire.
Attention
En raison de la nature complexe du routage sur Internet et ExpressRoute, il est recommandé d’ajouter du temps de mémoire tampon supplémentaire à cette fenêtre pour gérer la résolution des problèmes de routage complexe.
Configurer QoS pour Skype Entreprise Online
QoS est nécessaire pour obtenir des avantages vocaux et de réunion pour Skype Entreprise Online. Vous pouvez configurer QoS après avoir vérifié que la connexion réseau ExpressRoute ne bloque aucun autre accès au service Microsoft 365. La configuration de QoS est décrite dans l’article ExpressRoute et QoS dans Skype Entreprise Online .
Résolution des problèmes liés à votre implémentation
La première étape à examiner est celle des étapes de ce guide d’implémentation. Y a-t-il eu des échecs dans votre plan d’implémentation ? Retour et exécutez d’autres tests de petit réseau si possible pour répliquer l’erreur et la déboguer.
Identifiez les services entrants ou sortants qui ont échoué pendant le test. Obtenez spécifiquement les adresses IP et les sous-réseaux pour chacun des services qui ont échoué. Parcourez le diagramme de topologie de réseau sur papier et validez le routage. Vérifiez spécifiquement où le routage ExpressRoute est publié, testez ce routage pendant la panne si possible avec des traces.
Exécutez PSPing avec une trace réseau sur chaque point de terminaison client et évaluez les adresses IP source et de destination pour vérifier qu’elles sont comme prévu. Exécutez telnet sur n’importe quel hôte de messagerie que vous exposez sur le port 25 et vérifiez que SNAT masque l’adresse IP source d’origine si cela est prévu.
Gardez à l’esprit que lors du déploiement de Microsoft 365 avec une connexion ExpressRoute, vous devez vous assurer que la configuration réseau pour ExpressRoute est optimale et que vous avez également optimisé les autres composants de votre réseau, tels que les ordinateurs clients. En plus d’utiliser ce guide de planification pour résoudre les problèmes liés aux étapes que vous avez peut-être manquées, nous avons également écrit un plan de résolution des problèmes de performances pour Microsoft 365 .
Voici un lien que vous pouvez utiliser pour revenir : https://aka.ms/implementexpressroute365
Rubriques connexes
Évaluation de la connectivité réseau Microsoft 365
Azure ExpressRoute pour Microsoft 365
Qualité des médias et performances de connectivité réseau dans Skype Entreprise Online
Optimisation de votre réseau pour Skype Entreprise Online
ExpressRoute et QoS dans Skype Entreprise Online
Appel du flux à l’aide d’ExpressRoute
Plan de résolution des problèmes de performances pour Microsoft 365
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour