Implementazione di ExpressRoute per Microsoft 365

Questo articolo si applica a Microsoft 365 Enterprise.

ExpressRoute per Microsoft 365 offre un percorso di routing alternativo a molti servizi Di Microsoft 365 con connessione Internet. L'architettura di ExpressRoute per Microsoft 365 si basa sulla pubblicità dei prefissi IP pubblici dei servizi di Microsoft 365 già accessibili tramite Internet nei circuiti ExpressRoute di cui è stato effettuato il provisioning per la successiva ridistribuzione di tali prefissi IP nella rete. Con ExpressRoute si abilitano in modo efficace diversi percorsi di routing, tramite Internet e ExpressRoute, per molti servizi di Microsoft 365. Questo stato di routing nella rete potrebbe rappresentare una modifica significativa alla modalità di progettazione della topologia di rete interna.

Nota

Non è consigliabile usare ExpressRoute per Microsoft 365 perché non offre il modello di connettività migliore per il servizio nella maggior parte delle circostanze. Di conseguenza, per usare questo modello di connettività è necessaria l'autorizzazione Microsoft. Esaminiamo ogni richiesta del cliente e autorizziamo ExpressRoute per Microsoft 365 solo nei rari scenari in cui è necessario. Leggere la guida ExpressRoute per Microsoft 365 per altre informazioni e seguire una revisione completa del documento con i team di produttività, rete e sicurezza, collaborare con il team dell'account Microsoft per inviare un'eccezione, se necessario. Le sottoscrizioni non autorizzate che tentano di creare filtri di route per Microsoft 365 riceveranno un messaggio di errore.

È necessario pianificare attentamente l'implementazione di ExpressRoute per Microsoft 365 in modo da soddisfare le complessità di rete di disponibilità del routing tramite un circuito dedicato con route inserite nella rete principale e in Internet. Se l'utente e il team non eseguono la pianificazione dettagliata e i test in questa guida, si verifica un rischio elevato che si verifichi una perdita intermittente o totale di connettività ai servizi di Microsoft 365 quando il circuito ExpressRoute è abilitato.

Per ottenere un'implementazione corretta, è necessario analizzare i requisiti dell'infrastruttura, esaminare la valutazione e la progettazione della rete dettagliate, pianificare attentamente l'implementazione in modo graduale e controllato e creare un piano dettagliato di convalida e test. Per un ambiente distribuito di grandi dimensioni non è raro vedere implementazioni che si estendono per diversi mesi. Questa guida è progettata per aiutarti a pianificare in anticipo.

La pianificazione di distribuzioni di grandi dimensioni con esito positivo potrebbe richiedere sei mesi e spesso includere membri del team provenienti da molte aree dell'organizzazione, tra cui amministratori di rete, firewall e server proxy, amministratori di Microsoft 365, sicurezza, supporto per gli utenti finali, gestione dei progetti e sponsorizzazione dei dirigenti. L'investimento nel processo di pianificazione ridurrà la probabilità che si verifichino errori di distribuzione con conseguente tempo di inattività o risoluzione dei problemi complessa e costosa.

Prima di iniziare questa guida all'implementazione, è previsto il completamento dei prerequisiti seguenti.

1. È stata completata una valutazione di rete per determinare se ExpressRoute è consigliato e approvato.

2. È stato selezionato un provider di servizi di rete ExpressRoute. Informazioni dettagliate sui partner ExpressRoute e sulle località di peering.

3. La documentazione di ExpressRoute è già stata letta e la rete interna è in grado di soddisfare i prerequisiti di ExpressRoute end-to-end.

4. Il team ha letto tutte le linee guida e la documentazione pubblica in https://aka.ms/expressrouteoffice365, https://aka.ms/erte ha guardato la serie di formazione di Azure ExpressRoute per Microsoft 365 su Channel 9 per comprendere i dettagli tecnici critici, tra cui:

   • Dipendenze Internet dei servizi SaaS.

   • Come evitare route asimmetrica e gestire routing complessi.

   • Come incorporare controlli a livello di applicazione, disponibilità e sicurezza perimetrale.

Per iniziare, raccogliere i requisiti

Per iniziare, determinare quali funzionalità e servizi si intende adottare all'interno dell'organizzazione. È necessario determinare quali funzionalità dei diversi servizi di Microsoft 365 verranno usate e quali posizioni nella rete ospiteranno gli utenti che usano tali funzionalità. Con il catalogo degli scenari, è necessario aggiungere gli attributi di rete richiesti da ognuno di questi scenari. ad esempio flussi di traffico di rete in ingresso e in uscita e se gli endpoint di Microsoft 365 sono disponibili su ExpressRoute o meno.

Per raccogliere i requisiti dell'organizzazione:

• Catalogare il traffico di rete in ingresso e in uscita per i servizi di Microsoft 365 usati dall'organizzazione. Consultare la pagina URL e intervalli di indirizzi IP di Microsoft 365 per la descrizione dei flussi richiesti dai diversi scenari di Microsoft 365.

• Raccogliere la documentazione della topologia di rete esistente che mostra i dettagli della topologia e del backbone wan interno, la connettività dei siti satellite, la connettività utente dell'ultimo miglio, il routing ai punti di uscita perimetrali di rete e i servizi proxy.

  • Identificare gli endpoint del servizio in ingresso nei diagrammi di rete a cui si connetteranno Microsoft 365 e altri servizi Microsoft, mostrando sia i percorsi di connessione a Internet che i percorsi di connessione ExpressRoute proposti.

  • Identificare tutte le posizioni degli utenti geografici e la connettività WAN tra le posizioni insieme a quali posizioni hanno attualmente un ingresso a Internet e quali posizioni sono proposte per avere una posizione di peering ExpressRoute in uscita.

  • Identificare tutti i dispositivi perimetrali, ad esempio proxy, firewall e così via, e catalogare la relazione con i flussi che passano su Internet ed ExpressRoute.

  • Documentare se gli utenti finali accederanno ai servizi di Microsoft 365 tramite routing diretto o proxy di applicazione indiretta per i flussi Internet ed ExpressRoute.

• Aggiungere la posizione del tenant e i percorsi di riunione al diagramma di rete.

• Stimare le caratteristiche di latenza e prestazioni di rete previste e osservate dalle posizioni utente principali a Microsoft 365. Tenere presente che Microsoft 365 è un set globale e distribuito di servizi e gli utenti si connetteranno a posizioni che potrebbero essere diverse dalla posizione del tenant. Per questo motivo, è consigliabile misurare e ottimizzare la latenza tra l'utente e il bordo più vicino della rete globale Microsoft tramite ExpressRoute e le connessioni Internet. È possibile usare i risultati della valutazione della rete per facilitare l'esecuzione di questa attività.

• Elencare i requisiti di sicurezza della rete aziendale e disponibilità elevata che devono essere soddisfatti con la nuova connessione ExpressRoute. Ad esempio, in che modo gli utenti continuano a ottenere l'accesso a Microsoft 365 in caso di errore del circuito Di uscita Internet o ExpressRoute.

• Documento in cui i flussi di rete di Microsoft 365 in ingresso e in uscita useranno il percorso Internet e che useranno ExpressRoute. Le specifiche delle posizioni geografiche degli utenti e i dettagli della topologia di rete locale possono richiedere che il piano sia diverso da una posizione utente a un'altra.

Catalogare il traffico di rete in uscita e in ingresso

Per ridurre al minimo il routing e altre complessità di rete, è consigliabile usare ExpressRoute per Microsoft 365 solo per i flussi di traffico di rete necessari per passare attraverso una connessione dedicata a causa di requisiti normativi o come risultato della valutazione della rete. Inoltre, è consigliabile organizzare l'ambito del routing ExpressRoute e approcciare i flussi di traffico di rete in uscita e in ingresso come fasi diverse e distinte del progetto di implementazione. Distribuire ExpressRoute per Microsoft 365 solo per i flussi di traffico di rete in uscita avviati dall'utente e lasciare i flussi di traffico di rete in ingresso attraverso Internet può contribuire a controllare l'aumento della complessità topologica e dei rischi di introduzione di ulteriori possibilità di routing asimmetrico.

Il catalogo del traffico di rete deve contenere elenchi di tutte le connessioni di rete in ingresso e in uscita che si avranno tra la rete locale e Microsoft.

• I flussi di traffico di rete in uscita sono scenari in cui viene avviata una connessione dall'ambiente locale, ad esempio da client o server interni, con una destinazione dei servizi Microsoft. Queste connessioni possono essere dirette a Microsoft 365 o indiretta, ad esempio quando la connessione passa attraverso server proxy, firewall o altri dispositivi di rete nel percorso di Microsoft 365.

• I flussi di traffico di rete in ingresso sono scenari in cui viene avviata una connessione dal cloud Microsoft a un host locale. Queste connessioni devono in genere passare attraverso il firewall e altre infrastrutture di sicurezza necessarie per i criteri di sicurezza dei clienti per i flussi originati esternamente.

Leggere la sezione Verifica della simmetria di route per determinare quali servizi invieranno traffico in ingresso e cercare la colonna contrassegnata come ExpressRoute per Microsoft 365 nell'articolo di riferimento sugli endpoint di Microsoft 365 per determinare il resto delle informazioni di connettività.

Per ogni servizio che richiede una connessione in uscita, è necessario descrivere la connettività pianificata per il servizio, inclusi routing di rete, configurazione proxy, ispezione dei pacchetti e esigenze di larghezza di banda.

Per ogni servizio che richiede una connessione in ingresso, sono necessarie alcune informazioni aggiuntive. I server nel cloud Microsoft stabiliranno connessioni alla rete locale. Per assicurarsi che le connessioni siano eseguite correttamente, è necessario descrivere tutti gli aspetti di questa connettività, tra cui; le voci DNS pubbliche per i servizi che accetteranno queste connessioni in ingresso, gli indirizzi IP IPv4 formattati CIDR, le apparecchiature ISP coinvolte e la modalità di gestione di NAT o NAT di origine in ingresso per queste connessioni.

Le connessioni in ingresso devono essere esaminate indipendentemente dal fatto che si connettono tramite Internet o ExpressRoute per garantire che non sia stato introdotto il routing asimmetrico. In alcuni casi, gli endpoint locali a cui i servizi di Microsoft 365 avviano connessioni in ingresso potrebbero dover essere accessibili anche da altri servizi Microsoft e non Microsoft. È fondamentale che l'abilitazione del routing ExpressRoute a questi servizi per scopi di Microsoft 365 non interrompa altri scenari. In molti casi, i clienti potrebbero dover implementare modifiche specifiche alla rete interna, ad esempio NAT basato sull'origine, per garantire che i flussi in ingresso da Microsoft rimangano simmetrici dopo l'abilitazione di ExpressRoute.

Ecco un esempio del livello di dettaglio richiesto. In questo caso, Exchange Hybrid instrada il sistema locale tramite ExpressRoute.

Proprietà connection	Valore
Direzione del traffico di rete	Inbound
Servizio	Ambiente Exchange ibrido
Endpoint microsoft 365 pubblico (origine)	Exchange Online (indirizzi IP)
Endpoint locale pubblico (destinazione)	5.5.5.5
Voce DNS pubblica (Internet)	Autodiscover.contoso.com
Questo endpoint locale verrà usato per altri servizi Microsoft (non Microsoft 365)	No
L'endpoint locale verrà usato da utenti/sistemi su Internet	Sì
Sistemi interni pubblicati tramite endpoint pubblici	Exchange Server ruolo di accesso client (locale) 192.168.101, 192.168.102, 192.168.103
Annuncio IP dell'endpoint pubblico	Verso Internet: da 5.5.0.0/16 a ExpressRoute: 5.5.5.0/24
Controlli di sicurezza/perimetro	Percorso Internet: DeviceID_002 percorso ExpressRoute: DeviceID_003
Disponibilità elevata	Attivo/Attivo su 2 circuiti con ridondanza geografica/ExpressRoute - Chicago e Dallas
Controllo di simmetria del percorso	Metodo: Percorso Internet NAT di origine: Connessioni in ingresso NAT di origine al percorso ExpressRoute 192.168.5.5: Connessioni NAT di origine a 192.168.1.0 (Chicago) e 192.168.2.0 (Dallas)

Ecco un esempio di servizio che è solo in uscita:

Proprietà connection	Valore
Direzione del traffico di rete	In uscita
Servizio	SharePoint
Endpoint locale (origine)	Workstation utente
Endpoint microsoft 365 pubblico (destinazione)	SharePoint (indirizzi IP)
Voce DNS pubblica (Internet)	*.sharepoint.com (e altri FQDN)
Segnalazioni della rete CDN	cdn.sharepointonline.com (e più FQDN) - Indirizzi IP gestiti dai provider di reti CDN)
Annuncio IP e NAT in uso	Percorso Internet/NAT di origine: 1.1.1.0/24 Percorso ExpressRoute/NAT di origine: 1.1.2.0/24 (Chicago) e 1.1.3.0/24 (Dallas)
Metodo di connettività	Internet: tramite proxy di livello 7 (file pac) ExpressRoute: routing diretto (nessun proxy)
Controlli di sicurezza/perimetro	Percorso Internet: DeviceID_002 Percorso ExpressRoute: DeviceID_003
Disponibilità elevata	Percorso Internet: uscita Internet ridondante Percorso ExpressRoute: routing "hot potato" attivo/attivo in 2 circuiti ExpressRoute con ridondanza geografica - Chicago e Dallas
Controllo di simmetria del percorso	Metodo: NAT di origine per tutte le connessioni

Progettazione della topologia di rete con connettività a livello di area

Dopo aver compreso i servizi e i relativi flussi di traffico di rete associati, è possibile creare un diagramma di rete che incorpora questi nuovi requisiti di connettività e illustra le modifiche apportate all'uso di ExpressRoute per Microsoft 365. Il diagramma deve includere:

1. Tutte le posizioni utente da cui sarà possibile accedere a Microsoft 365 e ad altri servizi.

2. Tutti i punti di uscita internet ed ExpressRoute.

3. Tutti i dispositivi in uscita e in ingresso che gestiscono la connettività all'interno e all'esterno della rete, inclusi router, firewall, server proxy dell'applicazione e rilevamento/prevenzione delle intrusioni.

4. Destinazioni interne per tutto il traffico in ingresso, ad esempio i server ADFS interni che accettano connessioni dai server proxy dell'applicazione Web ADFS.

5. Catalogo di tutte le subnet IP che verranno annunciate

6. Identificare ogni posizione in cui gli utenti accederanno a Microsoft 365 da ed elencare le località meet-me che verranno usate per ExpressRoute.

7. Posizioni e parti della topologia di rete interna, in cui i prefissi IP Microsoft appresi da ExpressRoute verranno accettati, filtrati e propagati in.

8. La topologia di rete deve illustrare la posizione geografica di ogni segmento di rete e il modo in cui si connette alla rete Microsoft tramite ExpressRoute e/o Internet.

Il diagramma seguente mostra ogni posizione in cui gli utenti useranno Microsoft 365, oltre agli annunci di routing in ingresso e in uscita a Microsoft 365.

Per il traffico in uscita, gli utenti accedono a Microsoft 365 in uno dei tre modi seguenti:

1. Attraverso una posizione meet-me in America del Nord per la gente in California.

2. Attraverso una posizione meet-me nella regione amministrativa speciale di Hong Kong per le persone a Hong Kong SAR.

3. Attraverso Internet in Bangladesh, dove ci sono meno persone e nessun circuito ExpressRoute di cui è stato effettuato il provisioning.

Analogamente, il traffico di rete in ingresso da Microsoft 365 restituisce uno dei tre modi seguenti:

1. Attraverso una posizione meet-me in America del Nord per la gente in California.

2. Attraverso una posizione meet-me nella regione amministrativa speciale di Hong Kong per le persone a Hong Kong SAR.

3. Attraverso Internet in Bangladesh, dove ci sono meno persone e nessun circuito ExpressRoute di cui è stato effettuato il provisioning.

Determinare la posizione di meet-me appropriata

La selezione delle posizioni meet-me, ovvero la posizione fisica in cui il circuito ExpressRoute connette la rete alla rete Microsoft, è influenzata dalle posizioni in cui gli utenti accederanno a Microsoft 365. Come offerta SaaS, Microsoft 365 non funziona con il modello di area IaaS o PaaS nello stesso modo di Azure. Microsoft 365 è invece un set distribuito di servizi di collaborazione, in cui gli utenti potrebbero dover connettersi agli endpoint in più data center e aree geografiche, che potrebbero non trovarsi necessariamente nella stessa posizione o area geografica in cui è ospitato il tenant dell'utente.

Ciò significa che la considerazione più importante da prendere quando si selezionano le località meet-me per ExpressRoute per Microsoft 365 è la posizione da cui si connetteranno gli utenti dell'organizzazione. La raccomandazione generale per una connettività ottimale di Microsoft 365 consiste nell'implementare il routing, in modo che le richieste degli utenti ai servizi di Microsoft 365 vengano inviate alla rete Microsoft attraverso il percorso di rete più breve, spesso definito anche routing "hot potato". Ad esempio, se la maggior parte degli utenti di Microsoft 365 si trova in una o due posizioni, selezionando le posizioni meet-me più vicine alla posizione di tali utenti verrà creata la progettazione ottimale. Se l'azienda ha un numero elevato di utenti in molte aree diverse, è consigliabile prendere in considerazione la possibilità di avere più circuiti ExpressRoute e posizioni di incontro. Per alcune delle posizioni degli utenti, il percorso più breve/ottimale nella rete Microsoft e in Microsoft 365 potrebbe non essere tramite la rete WAN interna e i punti di incontro ExpressRoute, ma tramite Internet.

Spesso sono presenti più località meet-me che possono essere selezionate all'interno di un'area con prossimità relativa agli utenti. Compilare la tabella seguente per guidare le decisioni.

Sedi di incontro expressroute pianificate in California e New York

Posizione	Numero di persone	Latenza prevista per la rete Microsoft su Internet in uscita	Latenza prevista per la rete Microsoft tramite ExpressRoute
Roma	10,000	~15ms	~10ms (tramite Silicon Valley)
Washington DC	15.000	~20ms	~10ms (via New York)
Dallas	5,000	~15ms	~40ms (via New York)

Una volta sviluppata l'architettura di rete globale che mostra l'area di Microsoft 365, le località di incontro del provider di servizi di rete ExpressRoute e la quantità di persone per località, è possibile usarla per identificare se è possibile eseguire ottimizzazioni. Può anche mostrare connessioni di rete globali dove il traffico si instrada a una posizione distante per ottenere la posizione meet-me. Se viene individuata una puntina sulla rete globale, è necessario correggerla prima di continuare. Trovare un'altra posizione meet-me o usare punti di uscita internet selettivi per evitare la puntina.

Il primo diagramma mostra un esempio di cliente con due posizioni fisiche in America del Nord. È possibile visualizzare le informazioni sulle posizioni di office, le posizioni dei tenant di Microsoft 365 e diverse opzioni per le posizioni di riunione di ExpressRoute. In questo esempio, il cliente ha selezionato la località meet-me in base a due principi, nell'ordine:

1. Prossimità più vicina alle persone dell'organizzazione.

2. Più vicino a un data center Microsoft in cui è ospitato Microsoft 365.

Espandendo leggermente questo concetto, il secondo diagramma mostra un esempio di cliente multi-nazionale di fronte a informazioni e processi decisionali simili. Questo cliente ha un piccolo ufficio in Bangladesh con solo un piccolo team di 10 persone concentrato sulla crescita della loro impronta nella regione. C'è una posizione meet-me a Chennai e un data center Microsoft con Microsoft 365 ospitato a Chennai, quindi una posizione meet-me avrebbe senso; tuttavia, per 10 persone, la spesa del circuito aggiuntivo è onerosa. Quando si esamina la rete, è necessario determinare se la latenza necessaria per inviare il traffico di rete attraverso la rete è più efficace rispetto alla spesa del capitale per acquisire un altro circuito ExpressRoute.

In alternativa, le 10 persone in Bangladesh potrebbero riscontrare prestazioni migliori con il traffico di rete inviato via Internet alla rete Microsoft rispetto al routing sulla rete interna, come illustrato nei diagrammi introduttivi e riprodotto di seguito.

Create piano di implementazione di ExpressRoute per Microsoft 365

Il piano di implementazione deve includere sia i dettagli tecnici della configurazione di ExpressRoute che i dettagli relativi alla configurazione di tutte le altre infrastrutture nella rete, ad esempio i seguenti.

• Pianificare i servizi suddivisi tra ExpressRoute e Internet.

• Pianificare larghezza di banda, sicurezza, disponibilità elevata e failover.

• Progettare il routing in ingresso e in uscita, incluse le ottimizzazioni dei percorsi di routing appropriate per posizioni diverse

• Decidere fino a che punto verranno annunciate le route ExpressRoute nella rete e qual è il meccanismo per consentire ai client di selezionare il percorso Internet o ExpressRoute; ad esempio il routing diretto o il proxy dell'applicazione.

• Pianificare le modifiche ai record DNS, incluse le voci di Sender Policy Framework .

• Pianificare la strategia NAT, inclusi NAT in uscita e di origine in ingresso.

Pianificare il routing con percorsi di rete Sia Internet che ExpressRoute

• Per la distribuzione iniziale, è consigliabile usare Internet per tutti i servizi in ingresso, ad esempio la posta elettronica in ingresso o la connettività ibrida.

• Pianificare il routing LAN del client dell'utente finale, ad esempio la configurazione di un file PAC/WPAD, la route predefinita, i server proxy e gli annunci di route BGP.

• Pianificare il routing perimetrale, inclusi server proxy, firewall e proxy cloud.

Pianificare larghezza di banda, sicurezza, disponibilità elevata e failover

Create un piano per la larghezza di banda necessaria per ogni carico di lavoro principale di Microsoft 365. Stimare separatamente i requisiti di larghezza di banda Exchange Online, SharePoint e Skype for Business Online. È possibile usare i calcolatori di stima forniti per Exchange Online e Skype for Business come punto di partenza. Tuttavia, è necessario un test pilota con un campione rappresentativo dei profili utente e delle posizioni per comprendere appieno le esigenze di larghezza di banda dell'organizzazione.

Aggiungere il modo in cui la sicurezza viene gestita in ogni posizione in uscita di Internet ed ExpressRoute al piano, ricordare che tutte le connessioni ExpressRoute a Microsoft 365 usano il peering pubblico e devono comunque essere protette in base ai criteri di sicurezza aziendali per la connessione a reti esterne.

Aggiungere i dettagli al piano su quali persone saranno interessate dal tipo di interruzione e dal modo in cui tali persone saranno in grado di svolgere il proprio lavoro a piena capacità nel modo più semplice.

Pianificare i requisiti di larghezza di banda, inclusi i requisiti di Skype for Business in jitter, latenza, congestione e headroom

Skype for Business Online ha anche requisiti di rete aggiuntivi specifici, descritti in dettaglio nell'articolo Media Quality and Network Connectivity Performance in Skype for Business Online.

Leggere la sezione Pianificazione della larghezza di banda per Azure ExpressRoute. Quando si esegue una valutazione della larghezza di banda con gli utenti pilota, è possibile usare la guida Ottimizzazione delle prestazioni di Microsoft 365 usando le baseline e la cronologia delle prestazioni.

Pianificare i requisiti di disponibilità elevata

Create un piano per la disponibilità elevata per soddisfare le esigenze e incorporarlo nel diagramma della topologia di rete aggiornato. Leggere la sezione Disponibilità elevata e failover con Azure ExpressRoute.

Pianificare i requisiti di sicurezza di rete

Create un piano per soddisfare i requisiti di sicurezza di rete e incorporarlo nel diagramma della topologia di rete aggiornato. Leggere la sezione Applicazione di controlli di sicurezza ad Azure ExpressRoute per scenari di Microsoft 365.

Progettare la connettività del servizio in uscita

ExpressRoute per Microsoft 365 ha requisiti di rete in uscita che potrebbero non essere noti. In particolare, gli indirizzi IP che rappresentano gli utenti e le reti a Microsoft 365 e fungono da endpoint di origine per le connessioni di rete in uscita a Microsoft devono seguire requisiti specifici descritti di seguito.

1. Gli endpoint devono essere indirizzi IP pubblici registrati nell'azienda o nel gestore che fornisce la connettività ExpressRoute.

2. Gli endpoint devono essere annunciati a Microsoft e convalidati/accettati da ExpressRoute.

3. Gli endpoint non devono essere annunciati su Internet con la stessa metrica di routing o più preferita.

4. Gli endpoint non devono essere usati per la connettività ai servizi Microsoft non configurati su ExpressRoute.

Se la progettazione di rete non soddisfa questi requisiti, esiste un rischio elevato che gli utenti riscontreranno errori di connettività a Microsoft 365 e ad altri servizi Microsoft a causa di instradamento nero o routing asimmetrico. Ciò si verifica quando le richieste ai servizi Microsoft vengono instradate tramite ExpressRoute, ma le risposte vengono instradate attraverso Internet o viceversa e le risposte vengono eliminate dai dispositivi di rete con stato, ad esempio i firewall.

Il metodo più comune che è possibile usare per soddisfare i requisiti precedenti consiste nell'usare NAT di origine, implementato come parte della rete o fornito dal gestore ExpressRoute. Nat di origine consente di astrarre i dettagli e gli indirizzi IP privati della rete Internet da ExpressRoute e; abbinati ad annunci di route IP appropriati, forniscono un meccanismo semplice per garantire la simmetria del percorso. Se si usano dispositivi di rete con stato specifici per le posizioni di peering ExpressRoute, è necessario implementare pool NAT separati per ogni peering ExpressRoute per garantire la simmetria del percorso.

Altre informazioni sui requisiti NAT di ExpressRoute.

Aggiungere le modifiche per la connettività in uscita al diagramma della topologia di rete.

Progettare la connettività del servizio in ingresso

La maggior parte delle distribuzioni aziendali di Microsoft 365 presuppone una qualche forma di connettività in ingresso da Microsoft 365 ai servizi locali, ad esempio per Exchange, SharePoint e Skype for Business scenari ibridi, migrazioni delle cassette postali e autenticazione tramite l'infrastruttura ADFS. Quando si abilita ExpressRoute un percorso di routing aggiuntivo tra la rete locale e Microsoft per la connettività in uscita, queste connessioni in ingresso potrebbero essere inavvertitamente interessate dal routing asimmetrico, anche se si prevede che tali flussi continuino a usare Internet. Alcune precauzioni descritte di seguito sono consigliate per garantire che non vi sia alcun impatto sui flussi in ingresso basati su Internet da Microsoft 365 a sistemi locali.

Per ridurre al minimo i rischi di routing asimmetrico per i flussi di traffico di rete in ingresso, tutte le connessioni in ingresso devono usare NAT di origine prima di essere instradate in segmenti della rete, che hanno visibilità sul routing in ExpressRoute. Se le connessioni in ingresso sono consentite in un segmento di rete con visibilità di routing in ExpressRoute senza NAT di origine, le richieste provenienti da Microsoft 365 verranno immesse da Internet, ma la risposta che torna a Microsoft 365 preferirà il percorso di rete ExpressRoute alla rete Microsoft, causando il routing asimmetrico.

Per soddisfare questo requisito, è possibile considerare uno dei modelli di implementazione seguenti:

1. Eseguire NAT di origine prima che le richieste vengano instradate nella rete interna usando apparecchiature di rete come firewall o servizi di bilanciamento del carico nel percorso da Internet ai sistemi locali.

2. Assicurarsi che le route ExpressRoute non vengano propagate ai segmenti di rete in cui risiedono i servizi in ingresso, ad esempio server front-end o sistemi proxy inversi, che gestiscono le connessioni Internet.

Tenere conto in modo esplicito di questi scenari nella rete e mantenere tutti i flussi di traffico di rete in ingresso su Internet consente di ridurre al minimo il rischio operativo e di distribuzione del routing asimmetrico.

In alcuni casi è possibile scegliere di indirizzare alcuni flussi in ingresso sulle connessioni ExpressRoute. Per questi scenari, prendere in considerazione le considerazioni aggiuntive seguenti.

1. Microsoft 365 può essere destinato solo agli endpoint locali che usano indirizzi IP pubblici. Ciò significa che anche se l'endpoint in ingresso locale è esposto solo a Microsoft 365 tramite ExpressRoute, deve comunque avere un INDIRIZZO IP pubblico associato.

2. Tutta la risoluzione dei nomi DNS eseguita dai servizi Microsoft 365 per risolvere gli endpoint locali avviene tramite DNS pubblico. Ciò significa che è necessario registrare l'FQDN degli endpoint di servizio in ingresso nei mapping IP su Internet.

3. Per ricevere connessioni di rete in ingresso tramite ExpressRoute, le subnet IP pubbliche per questi endpoint devono essere annunciate a Microsoft tramite ExpressRoute.

4. Valutare attentamente questi flussi di traffico di rete in ingresso per assicurarsi che vengano applicati controlli di rete e di sicurezza appropriati in base ai criteri di sicurezza e di rete aziendali.

5. Dopo che gli endpoint in ingresso locali vengono annunciati a Microsoft tramite ExpressRoute, ExpressRoute diventerà effettivamente il percorso di routing preferito per tali endpoint per tutti i servizi Microsoft, incluso Microsoft 365. Ciò significa che tali subnet endpoint devono essere usate solo per le comunicazioni con i servizi di Microsoft 365 e nessun altro servizio nella rete Microsoft. In caso contrario, la progettazione causerà il routing asimmetrico in cui le connessioni in ingresso da altri servizi Microsoft preferiscono instradare l'ingresso su ExpressRoute, mentre il percorso restituito userà Internet.

6. Nel caso in cui un circuito ExpressRoute o un percorso meet-me non sia attivo, è necessario assicurarsi che gli endpoint in ingresso locali siano ancora disponibili per accettare le richieste su un percorso di rete separato. Ciò può significare la pubblicità di subnet per tali endpoint tramite più circuiti ExpressRoute.

7. È consigliabile applicare NAT di origine per tutti i flussi di traffico di rete in ingresso che entrano nella rete tramite ExpressRoute, soprattutto quando questi flussi attraversano dispositivi di rete con stato, ad esempio firewall.

8. Alcuni servizi locali, ad esempio il proxy ADFS o l'individuazione automatica di Exchange, possono ricevere richieste in ingresso sia dai servizi di Microsoft 365 che dagli utenti da Internet. Per queste richieste, Microsoft 365 avrà lo stesso nome di dominio completo delle richieste utente su Internet. Consentire le connessioni utente in ingresso da Internet a tali endpoint locali, forzando al tempo stesso le connessioni di Microsoft 365 a usare ExpressRoute, rappresenta una complessità di routing significativa. Per la maggior parte dei clienti che implementano scenari così complessi su ExpressRoute non è consigliabile a causa di considerazioni operative. Questo sovraccarico aggiuntivo include la gestione dei rischi di routing asimmetrico e richiederà di gestire con attenzione gli annunci e i criteri di routing in più dimensioni.

Aggiornare il piano di topologia di rete per mostrare come evitare route asimmetrica

Si vuole evitare il routing asimmetrico per garantire che gli utenti dell'organizzazione possano usare facilmente Microsoft 365 e altri importanti servizi su Internet. Esistono due configurazioni comuni che i clienti hanno che causano il routing asimmetrico. È ora possibile esaminare la configurazione di rete che si prevede di usare e verificare se potrebbe esistere uno di questi scenari di routing asimmetrico.

Per iniziare, verranno esaminate alcune situazioni diverse associate al diagramma di rete seguente. In questo diagramma tutti i server che ricevono richieste in ingresso, ad esempio ADFS o server ibridi locali, si trovano nel data center del New Jersey e vengono annunciati a Internet.

1. Anche se la rete perimetrale è sicura, non è disponibile alcun NAT di origine per le richieste in ingresso.

2. I server nel data center del New Jersey sono in grado di visualizzare le route Sia Internet che ExpressRoute.

Sono disponibili anche suggerimenti su come risolverli.

Problema 1: Connessione da cloud a locale tramite Internet

Il diagramma seguente illustra il percorso di rete asimmetrico eseguito quando la configurazione di rete non fornisce NAT per le richieste in ingresso dal cloud Microsoft tramite Internet.

1. La richiesta in ingresso da Microsoft 365 recupera l'indirizzo IP dell'endpoint locale dal DNS pubblico e invia la richiesta alla rete perimetrale.

2. In questa configurazione difettosa non è disponibile alcun NAT di origine configurato o disponibile nella rete perimetrale in cui viene inviato il traffico, con conseguente uso dell'indirizzo IP di origine effettivo come destinazione restituita.

• Il server nella rete instrada il traffico restituito a Microsoft 365 tramite qualsiasi connessione di rete ExpressRoute disponibile.

• Il risultato è un percorso asimmetrico per il flusso a Microsoft 365, con conseguente interruzione della connessione.

Soluzione 1a: NAT di origine

La semplice aggiunta di un NAT di origine alla richiesta in ingresso risolve questa rete non configurata correttamente. In questo diagramma:

1. La richiesta in ingresso continua a essere immessa attraverso la rete perimetrale del data center del New Jersey. Questa volta l'origine NAT è disponibile.

2. La risposta del server esegue il routing verso l'IP associato al NAT di origine anziché all'indirizzo IP originale, con conseguente restituzione della risposta lungo lo stesso percorso di rete.

Soluzione 1b: Ambito route

In alternativa, è possibile scegliere di non consentire l'annuncio dei prefissi BGP di ExpressRoute, rimuovendo il percorso di rete alternativo per tali computer. In questo diagramma:

1. La richiesta in ingresso continua a essere immessa attraverso la rete perimetrale del data center del New Jersey. Questa volta i prefissi annunciati da Microsoft sul circuito ExpressRoute non sono disponibili per il data center del New Jersey.

2. La risposta del server esegue il routing verso l'INDIRIZZO IP associato all'indirizzo IP originale sull'unica route disponibile, con conseguente restituzione della risposta lungo lo stesso percorso di rete.

Problema 2: Connessione da cloud a locale tramite ExpressRoute

Il diagramma seguente illustra il percorso di rete asimmetrico eseguito quando la configurazione di rete non fornisce NAT per le richieste in ingresso dal cloud Microsoft tramite ExpressRoute.

1. La richiesta in ingresso da Microsoft 365 recupera l'indirizzo IP da DNS e invia la richiesta alla rete perimetrale.

2. In questa configurazione difettosa non è disponibile alcun NAT di origine configurato o disponibile nella rete perimetrale in cui viene inviato il traffico, con conseguente uso dell'indirizzo IP di origine effettivo come destinazione restituita.

• Il computer sulla rete instrada il traffico restituito a Microsoft 365 tramite qualsiasi connessione di rete ExpressRoute disponibile.

• Il risultato è una connessione asimmetrica a Microsoft 365.

Soluzione 2: NAT di origine

La semplice aggiunta di un NAT di origine alla richiesta in ingresso risolve questa rete non configurata correttamente. In questo diagramma:

1. La richiesta in ingresso continua a essere immessa attraverso la rete perimetrale del data center di New York. Questa volta l'origine NAT è disponibile.

2. La risposta del server esegue il routing verso l'IP associato al NAT di origine anziché all'indirizzo IP originale, con conseguente restituzione della risposta lungo lo stesso percorso di rete.

Verificare che la progettazione di rete abbia la simmetria del percorso

A questo punto, è necessario verificare su carta che il piano di implementazione offra la simmetria di route per i diversi scenari in cui si userà Microsoft 365. Si identificherà la route di rete specifica che dovrebbe essere eseguita quando una persona usa funzionalità diverse del servizio. Dalla rete locale e il routing WAN, ai dispositivi perimetrali, al percorso di connettività; ExpressRoute o Internet e alla connessione all'endpoint online.

È necessario eseguire questa operazione per tutti i servizi di rete microsoft 365 identificati in precedenza come servizi che l'organizzazione adotterà.

Aiuta a fare questo documento walk-through di percorsi con una seconda persona. Spiegare loro da dove ogni hop di rete dovrebbe ottenere la route successiva e assicurarsi di avere familiarità con i percorsi di routing. Tenere presente che ExpressRoute fornirà sempre una route più con ambito agli indirizzi IP del server Microsoft, offrendo un costo di route inferiore rispetto a una route predefinita internet.

Progettare la configurazione della connettività client

Se si usa un server proxy per il traffico associato a Internet, è necessario modificare tutti i file di configurazione pac o client per assicurarsi che i computer client nella rete siano configurati correttamente per inviare il traffico ExpressRoute desiderato a Microsoft 365 senza transitare nel server proxy e il traffico rimanente, incluso il traffico di Microsoft 365, viene inviato al proxy pertinente. Leggere la guida sulla gestione degli endpoint di Microsoft 365, ad esempio i file PAC.

Nota

Gli endpoint cambiano spesso, con una frequenza settimanale. È consigliabile apportare modifiche solo in base ai servizi e alle funzionalità adottate dall'organizzazione per ridurre il numero di modifiche che è necessario apportare per rimanere aggiornati. Prestare particolare attenzione alla data di validità nel feed RSS in cui vengono annunciate le modifiche e viene mantenuto un record di tutte le modifiche precedenti, gli indirizzi IP annunciati non possono essere annunciati o rimossi dall'annuncio pubblicitario fino al raggiungimento della data di validità.

Garantire la simmetria della route

I server front-end di Microsoft 365 sono accessibili sia su Internet che su ExpressRoute. Questi server preferiranno eseguire il routing all'ambiente locale tramite circuiti ExpressRoute quando sono disponibili entrambi. Per questo motivo, esiste la possibilità di asimmetria di route se il traffico dalla rete preferisce essere instradato sui circuiti Internet. Le route asimmetriche rappresentano un problema perché i dispositivi che eseguono l'ispezione dei pacchetti con stato possono bloccare il traffico restituito che segue un percorso diverso rispetto ai pacchetti in uscita seguiti.

Indipendentemente dal fatto che si avvii una connessione a Microsoft 365 tramite Internet o ExpressRoute, l'origine deve essere un indirizzo instradabile pubblicamente. Con molti clienti che esecedono direttamente il peering con Microsoft, non è possibile avere indirizzi privati in cui è possibile la duplicazione tra i clienti.

Di seguito sono riportati gli scenari in cui verranno avviate le comunicazioni da Microsoft 365 alla rete locale. Per semplificare la progettazione della rete, è consigliabile instradare quanto segue sul percorso Internet.

• Servizi SMTP, ad esempio la posta da un tenant Exchange Online a un host locale o SharePoint Mail inviato da SharePoint a un host locale. Il protocollo SMTP viene usato in modo più ampio all'interno della rete Microsoft rispetto ai prefissi di route condivisi sui circuiti ExpressRoute e la pubblicità dei server SMTP locali su ExpressRoute causerà errori con questi altri servizi.

• ADFS durante la convalida della password per l'accesso.

• Exchange Server distribuzioni ibride.

• Ricerca ibrida federata di SharePoint.

• Bcs ibrido di SharePoint.

• Skype for Business federazione ibrida e/o Skype for Business.

• Skype for Business Cloud Connector.

Per consentire a Microsoft di tornare alla rete per questi flussi di traffico bidirezionali, le route BGP verso i dispositivi locali devono essere condivise con Microsoft. Quando si annunciano prefissi di route a Microsoft tramite ExpressRoute, è consigliabile seguire queste procedure consigliate:

1. Non annunciare lo stesso prefisso di route dell'indirizzo IP pubblico a Internet pubblico e tramite ExpressRoute. È consigliabile che gli annunci del prefisso di route BGP IP a Microsoft su ExpressRoute provenivano da un intervallo che non è affatto annunciato su Internet. Se non è possibile ottenere questo risultato a causa dello spazio di indirizzi IP disponibile, è essenziale assicurarsi di annunciare un intervallo più specifico su ExpressRoute rispetto a qualsiasi circuito Internet.

2. Usare pool IP NAT separati per ogni circuito ExpressRoute e separati da quelli dei circuiti Internet.

3. Qualsiasi route annunciata a Microsoft attirerà il traffico di rete da qualsiasi server nella rete Microsoft, non solo quelli per cui le route vengono annunciate alla rete tramite ExpressRoute. Annunciare solo le route ai server in cui gli scenari di routing sono definiti e ben compresi dal team. Annunciare prefissi di route di indirizzi IP separati in ognuno di più circuiti ExpressRoute dalla rete.

Disponibilità elevata e failover con Azure ExpressRoute

È consigliabile effettuare il provisioning di almeno due circuiti attivi da ogni uscita con ExpressRoute al provider ExpressRoute. Questa è la posizione più comune in cui vengono visualizzati errori per i clienti ed è possibile evitarlo facilmente eseguendo il provisioning di una coppia di circuiti ExpressRoute attivi/attivi. È anche consigliabile usare almeno due circuiti Internet attivi/attivi perché molti servizi di Microsoft 365 sono disponibili solo su Internet.

All'interno del punto di uscita della rete ci sono molti altri dispositivi e circuiti che svolgono un ruolo fondamentale nel modo in cui le persone percepiscono la disponibilità. Queste parti degli scenari di connettività non sono coperte da ExpressRoute o dai contratti di servizio di Microsoft 365, ma svolgono un ruolo fondamentale nella disponibilità dei servizi end-to-end percepita dagli utenti dell'organizzazione.

Concentrarsi sulle persone che usano e gestiscono Microsoft 365, se un errore di un componente influirà sull'esperienza delle persone che usano il servizio, cercare modi per limitare la percentuale totale di persone interessate. Se una modalità di failover è operativamente complessa, considerare l'esperienza delle persone di lungo tempo per il ripristino e cercare le modalità di failover operativamente semplici e automatizzate.

All'esterno della rete, Microsoft 365, ExpressRoute e il provider ExpressRoute hanno tutti livelli di disponibilità diversi.

Disponibilità del servizio

• I servizi di Microsoft 365 sono coperti da contratti di servizio ben definiti, che includono metriche di tempo di attività e disponibilità per i singoli servizi. Uno dei motivi per cui Microsoft 365 può mantenere livelli di disponibilità del servizio così elevati è la possibilità per i singoli componenti di eseguire facilmente il failover tra i numerosi data center Microsoft, usando la rete Microsoft globale. Questo failover si estende dal data center e dalla rete ai più punti di uscita Internet e consente il failover senza problemi dal punto di vista degli utenti che usano il servizio.

• ExpressRoute offre un contratto di servizio di disponibilità del 99,9% per i singoli circuiti dedicati tra Microsoft Network Edge e il provider o l'infrastruttura partner ExpressRoute. Questi livelli di servizio vengono applicati a livello di circuito ExpressRoute, costituito da due interconnessioni indipendenti tra le apparecchiature Microsoft ridondanti e le apparecchiature del provider di rete in ogni posizione di peering.

Disponibilità del provider

• Le disposizioni del livello di servizio microsoft si fermano al provider o al partner ExpressRoute. Questo è anche il primo posto in cui è possibile effettuare scelte che influiranno sul livello di disponibilità. È consigliabile valutare attentamente le caratteristiche di architettura, disponibilità e resilienza offerte dal provider ExpressRoute tra il perimetro di rete e la connessione dei provider in ogni posizione di peering Microsoft. Prestare particolare attenzione sia agli aspetti logici che fisici della ridondanza, alle apparecchiature di peering, ai circuiti WAN forniti dal vettore e a qualsiasi altro valore aggiuntivo, ad esempio servizi NAT o firewall gestiti.

Progettazione del piano di disponibilità

È consigliabile pianificare e progettare disponibilità elevata e resilienza negli scenari di connettività end-to-end per Microsoft 365. Una progettazione deve includere;

• Nessun singolo punto di errore, inclusi i circuiti Internet ed ExpressRoute.

• Riduzione al minimo del numero di persone interessate e della durata dell'impatto per le modalità di errore più previste.

• Ottimizzazione per un processo di ripristino semplice, ripetibile e automatico dalle modalità di errore più previste.

• Supporto delle richieste complete del traffico di rete e delle funzionalità tramite percorsi ridondanti, senza riduzione sostanziale.

Gli scenari di connettività devono includere una topologia di rete ottimizzata per più percorsi di rete indipendenti e attivi per Microsoft 365. In questo modo si otterrà una disponibilità end-to-end migliore rispetto a una topologia ottimizzata solo per la ridondanza a livello di singolo dispositivo o attrezzatura.

Consiglio

Se gli utenti sono distribuiti in più continenti o aree geografiche e ognuna di queste posizioni si connette tramite circuiti WAN ridondanti a una singola posizione locale in cui si trova un singolo circuito ExpressRoute, gli utenti avranno meno disponibilità del servizio end-to-end rispetto a una progettazione di topologia di rete che include circuiti ExpressRoute indipendenti che connettono le diverse aree alla posizione di peering più vicina.

È consigliabile effettuare il provisioning di almeno due circuiti ExpressRoute con ogni circuito a cui ci si connette con una posizione di peering geografica diversa. È consigliabile effettuare il provisioning di questa coppia attiva-attiva di circuiti per ogni area in cui gli utenti useranno la connettività ExpressRoute per i servizi Microsoft 365. Ciò consente a ogni area di rimanere connessa durante un'emergenza che interessa una posizione principale, ad esempio un data center o una posizione di peering. La configurazione in come attivo/attivo consente di distribuire il traffico dell'utente finale tra più percorsi di rete. In questo modo si riduce l'ambito delle persone interessate durante le interruzioni del dispositivo o delle apparecchiature di rete.

Non è consigliabile usare un singolo circuito ExpressRoute con Internet come backup.

Esempio: Failover e disponibilità elevata

La progettazione multi-geografica di Contoso ha subito una revisione del routing, della larghezza di banda, della sicurezza e ora deve essere sottoposta a una verifica di disponibilità elevata. Contoso considera la disponibilità elevata come una copertura di tre categorie; resilienza, affidabilità e ridondanza.

La resilienza consente a Contoso di eseguire rapidamente il ripristino dagli errori. L'affidabilità consente a Contoso di offrire un risultato coerente all'interno del sistema. La ridondanza consente a Contoso di spostarsi tra una o più istanze di infrastruttura con mirroring.

All'interno di ogni configurazione perimetrale, Contoso dispone di firewall, proxy e IDS ridondanti. Per America del Nord, Contoso ha una configurazione perimetrale nel data center di Dallas e un'altra configurazione perimetrale nel data center virginiano. L'attrezzatura ridondante in ogni posizione offre resilienza a tale posizione.

La configurazione di rete in Contoso si basa su alcuni principi chiave:

• All'interno di ogni area geografica sono presenti più circuiti Azure ExpressRoute.

• Ogni circuito all'interno di un'area può supportare tutto il traffico di rete all'interno di tale area.

• Il routing preferirà chiaramente uno o l'altro percorso a seconda della disponibilità, della posizione e così via.

• Il failover tra circuiti Azure ExpressRoute viene eseguito automaticamente senza ulteriore configurazione o azione richiesta da Contoso.

• Il failover tra circuiti Internet viene eseguito automaticamente senza la configurazione o l'azione aggiuntiva richiesta da Contoso.

In questa configurazione, con ridondanza a livello fisico e virtuale, Contoso è in grado di offrire resilienza locale, resilienza a livello di area e resilienza globale in modo affidabile. Contoso ha scelto questa configurazione dopo aver valutato un singolo circuito Azure ExpressRoute per area, nonché la possibilità di eseguire il failover su Internet.

Se Contoso non è in grado di avere più circuiti Azure ExpressRoute per area, il routing del traffico proveniente da America del Nord al circuito Azure ExpressRoute in Asia Pacifico aggiungerebbe un livello di latenza non accettabile e la configurazione del server d'inoltro DNS necessaria aggiunge complessità.

L'uso di Internet come configurazione di backup non è consigliato. Ciò interrompe il principio di affidabilità di Contoso, con conseguente esperienza incoerente nell'uso della connessione. Inoltre, è necessario eseguire il failover della configurazione manuale considerando gli annunci BGP configurati, la configurazione NAT, la configurazione DNS e la configurazione del proxy. Questa maggiore complessità del failover aumenta il tempo necessario per il ripristino e riduce la capacità di diagnosticare e risolvere i problemi relativi ai passaggi coinvolti.

Sono ancora presenti domande su come pianificare e implementare la gestione del traffico o Azure ExpressRoute? Leggere il resto delle linee guida sulla rete e sulle prestazioni o le domande frequenti su Azure ExpressRoute.

Applicazione di controlli di sicurezza ad Azure ExpressRoute per scenari di Microsoft 365

La protezione della connettività di Azure ExpressRoute inizia con gli stessi principi della protezione della connettività Internet. Molti clienti scelgono di distribuire controlli di rete e perimetrali lungo il percorso ExpressRoute che connette la rete locale a Microsoft 365 e ad altri cloud Microsoft. Questi controlli possono includere firewall, proxy dell'applicazione, prevenzione della perdita di dati, rilevamento delle intrusioni, sistemi di prevenzione delle intrusioni e così via. In molti casi i clienti applicano diversi livelli di controlli al traffico avviato dall'ambiente locale verso Microsoft, rispetto al traffico avviato da Microsoft verso la rete locale del cliente, rispetto al traffico avviato dall'ambiente locale verso una destinazione Internet generale.

Ecco alcuni esempi di integrazione della sicurezza con il modello di connettività ExpressRoute che si sceglie di distribuire.

Opzione di integrazione expressroute	Modello perimetrale di sicurezza di rete
Colocato in uno scambio cloud	Installare un'infrastruttura di sicurezza o perimetrale esistente nella struttura di colocation in cui è stabilita la connessione ExpressRoute. Usare la struttura di colocation esclusivamente per scopi di routing/interconnessione e backtrasporto delle connessioni dalla struttura di colocation all'infrastruttura di sicurezza/perimetro locale.
Ethernet da punto a punto	Terminare la connessione ExpressRoute da punto a punto nella posizione dell'infrastruttura perimetrale/di sicurezza locale esistente. Installare la nuova infrastruttura di sicurezza/perimetrale specifica per il percorso ExpressRoute e terminare la connessione da punto a punto.
Any-to-Any IPVPN	Usare un'infrastruttura di sicurezza/perimetro locale esistente in tutte le posizioni in uscita nell'IPVPN usato per la connettività ExpressRoute per Microsoft 365. Aggiungere l'IPVPN usato per ExpressRoute per Microsoft 365 a posizioni locali specifiche designate come sicurezza/perimetro.

Alcuni provider di servizi offrono anche funzionalità di sicurezza/perimetro gestite come parte delle soluzioni di integrazione con Azure ExpressRoute.

Quando si considera il posizionamento della topologia delle opzioni perimetrali di rete/sicurezza usate per Le connessioni ExpressRoute per Microsoft 365, di seguito sono riportate considerazioni aggiuntive

• I controlli di rete/sicurezza di profondità e tipo possono avere un impatto sulle prestazioni e sulla scalabilità dell'esperienza utente di Microsoft 365.

• I flussi in uscita (on-premises-Microsoft>) e in ingresso (Microsoft-on-premises>) [se abilitati] potrebbero avere requisiti diversi. Queste sono probabilmente diverse da Quelle in uscita per le destinazioni Internet generali.

• I requisiti di Microsoft 365 per porte/protocolli e subnet IP necessarie sono gli stessi, indipendentemente dal fatto che il traffico venga instradato tramite ExpressRoute per Microsoft 365 o tramite Internet.

• Il posizionamento topologico dei controlli di rete/sicurezza dei clienti determina la rete end-to-end finale tra l'utente e il servizio Microsoft 365 e può avere un impatto significativo sulla latenza e la congestione della rete.

• I clienti sono invitati a progettare la topologia di sicurezza/perimetro da usare con ExpressRoute per Microsoft 365 in base alle procedure consigliate per la ridondanza, la disponibilità elevata e il ripristino di emergenza.

Ecco un esempio di Contoso che confronta le diverse opzioni di connettività di Azure ExpressRoute con i modelli di sicurezza perimetrali descritti in precedenza.

Esempio: Protezione di Azure ExpressRoute

Contoso sta valutando l'implementazione di Azure ExpressRoute e dopo aver pianificato l'architettura ottimale per ExpressRoute per Microsoft 365 e dopo aver usato le indicazioni precedenti per comprendere i requisiti di larghezza di banda, sta determinando il metodo migliore per proteggere il proprio perimetro.

Per Contoso, un'organizzazione multi-nazionale con posizioni in più continenti, la sicurezza deve estendersi su tutti i perimetri. L'opzione di connettività ottimale per Contoso è una connessione multipunto con più località di peering in tutto il mondo per soddisfare le esigenze dei dipendenti in ogni continente. Ogni continente include circuiti Azure ExpressRoute ridondanti all'interno del continente e la sicurezza deve estendersi su tutti questi elementi.

L'infrastruttura esistente di Contoso è affidabile e può gestire il lavoro aggiuntivo, pertanto Contoso è in grado di usare l'infrastruttura per la sicurezza perimetrale di Azure ExpressRoute e Internet. In caso contrario, Contoso potrebbe scegliere di acquistare più apparecchiature per integrare le apparecchiature esistenti o per gestire un diverso tipo di connessione.

Pianificazione della larghezza di banda per Azure ExpressRoute

Ogni cliente di Microsoft 365 ha esigenze di larghezza di banda univoche a seconda del numero di persone in ogni posizione, della loro attività con ogni applicazione Microsoft 365 e di altri fattori, ad esempio l'uso di apparecchiature locali o ibride e configurazioni di sicurezza di rete.

Se la larghezza di banda è insufficiente, si verificheranno congestioni, ritrasmissioni di dati e ritardi imprevedibili. La presenza di una larghezza di banda eccessiva comporta costi non necessari. In una rete esistente, la larghezza di banda viene spesso definita percentuale in termini di quantità di spazio head disponibile nel circuito. Avere il 10% di spazio per la testa probabilmente comporterà congestione e avere l'80% di spazio per la testa in genere significa costi non necessari. Le allocazioni di destinazione di headroom tipiche sono dal 20% al 50%.

Per trovare il livello di larghezza di banda corretto, il meccanismo migliore consiste nel testare il consumo di rete esistente. Questo è l'unico modo per ottenere una reale misura dell'utilizzo e delle esigenze, perché ogni configurazione di rete e ogni applicazione sono in qualche modo univoche. Durante la misurazione, è necessario prestare particolare attenzione al consumo totale di larghezza di banda, alla latenza e alla congestione TCP per comprendere le esigenze di rete.

Dopo aver creato una baseline stimata che includa tutte le applicazioni di rete, pilotare Microsoft 365 con un piccolo gruppo che comprende i diversi profili di persone nell'organizzazione per determinare l'utilizzo effettivo e usare le due misurazioni per stimare la quantità di larghezza di banda necessaria per ogni sede dell'ufficio. In caso di problemi di latenza o congestione TCP rilevati nei test, potrebbe essere necessario spostare l'uscita più vicino agli utenti che usano Microsoft 365 o rimuovere l'analisi di rete intensiva, ad esempio decrittografia/ispezione SSL.

Tutte le raccomandazioni sul tipo di elaborazione di rete consigliato si applicano sia ai circuiti ExpressRoute che a Internet. Lo stesso vale per il resto delle linee guida sul sito di ottimizzazione delle prestazioni.

Compilare le procedure di distribuzione e test

Il piano di implementazione deve includere sia la pianificazione di test che di rollback. Se l'implementazione non funziona come previsto, il piano deve essere progettato in modo da influire sul minor numero di persone prima di individuare i problemi. Di seguito sono riportati alcuni principi generali che il piano deve prendere in considerazione.

1. Eseguire l'onboarding del segmento di rete e del servizio utente per ridurre al minimo le interruzioni.

2. Pianificare il test delle route con traceroute e TCP connect da un host connesso a Internet separato.

3. Preferibilmente, il test dei servizi in ingresso e in uscita deve essere eseguito in una rete di test isolata con un tenant di Microsoft 365 di test.

   • In alternativa, i test possono essere eseguiti in una rete di produzione se il cliente non usa ancora Microsoft 365 o è in fase pilota.

   • In alternativa, i test possono essere eseguiti durante un'interruzione di produzione che viene messa da parte solo per il test e il monitoraggio.

   • In alternativa, è possibile eseguire il test controllando le route per ogni servizio in ogni nodo del router di livello 3. Questo ripiego deve essere usato solo se non è possibile eseguire altri test perché la mancanza di test fisici comporta un rischio.

Compilare le procedure di distribuzione

Le procedure di distribuzione devono essere distribuite a piccoli gruppi di persone in fasi per consentire il test prima della distribuzione a gruppi più grandi di persone. Di seguito sono riportati diversi modi per organizzare la distribuzione di ExpressRoute.

1. Configurare ExpressRoute con il peering Microsoft e inoltrare gli annunci di route a un singolo host solo a scopo di test a fasi.

2. Annunciare le route alla rete ExpressRoute a un singolo segmento di rete in un primo momento ed espandere gli annunci di route in base al segmento di rete o all'area.

3. Se si distribuisce Microsoft 365 per la prima volta, usare la distribuzione di rete ExpressRoute come progetto pilota per alcune persone.

4. Se si usano server proxy, è possibile configurare in alternativa un file PAC di test per indirizzare alcune persone a ExpressRoute con test e commenti e suggerimenti prima di aggiungerne altri.

Il piano di implementazione deve elencare ognuna delle procedure di distribuzione che devono essere eseguite o i comandi che devono essere usati per distribuire la configurazione di rete. Quando arriva il tempo di interruzione della rete, tutte le modifiche apportate devono provenire dal piano di distribuzione scritto scritto in anticipo e sottoposto a peer reviewed. Vedere le linee guida sulla configurazione tecnica di ExpressRoute.

• Aggiornamento dei record TXT SPF se sono stati modificati gli indirizzi IP per tutti i server locali che continueranno a inviare messaggi di posta elettronica.

• Aggiornamento di eventuali voci DNS per i server locali se sono stati modificati gli indirizzi IP per supportare una nuova configurazione NAT.

• Assicurarsi di aver sottoscritto il feed RSS per le notifiche degli endpoint di Microsoft 365 per gestire eventuali configurazioni di routing o proxy.

Al termine della distribuzione di ExpressRoute, è necessario eseguire le procedure nel piano di test. I risultati per ogni procedura devono essere registrati. È necessario includere procedure per il rollback all'ambiente di produzione originale nel caso in cui i risultati del piano di test indichino che l'implementazione non è riuscita.

Compilare le procedure di test

Le procedure di test devono includere test per ogni servizio di rete in uscita e in ingresso per Microsoft 365 che userà ExpressRoute e quelli che non lo faranno. Le procedure devono includere test da ogni posizione di rete univoca, inclusi gli utenti che non sono locali nella LAN aziendale.

Di seguito sono riportati alcuni esempi di attività di test.

1. Effettuare il ping dal router locale al router dell'operatore di rete.

2. Verificare che gli annunci degli indirizzi IP di Microsoft 365 e CRM Online più di 500 vengano ricevuti dal router locale.

3. Verificare che nat in ingresso e in uscita funzioni tra ExpressRoute e la rete interna.

4. Verificare che le route verso NAT vengano annunciate dal router.

5. Verificare che ExpressRoute abbia accettato i prefissi annunciati.

   • Usare il cmdlet seguente per verificare gli annunci di peering:

   Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeering
   

6. Verificare che l'intervallo IP NAT pubblico non sia annunciato a Microsoft tramite altri circuiti ExpressRoute o Internet pubblici, a meno che non si tratti di un subset specifico di un intervallo più ampio, come nell'esempio precedente.

7. I circuiti ExpressRoute sono associati, verificare che entrambe le sessioni BGP siano in esecuzione.

8. Configurare un singolo host all'interno di NAT e usare ping, tracert e tcpping per testare la connettività tra il nuovo circuito e l'host outlook.office365.com. In alternativa, è possibile usare uno strumento come Wireshark o Microsoft Network Monitor 3.4 su una porta con mirroring per MSEE per verificare di essere in grado di connettersi all'indirizzo IP associato a outlook.office365.com.

9. Testare la funzionalità a livello di applicazione per Exchange Online.

• Test Outlook è in grado di connettersi a Exchange Online e inviare/ricevere messaggi di posta elettronica.

• Test Outlook è in grado di usare la modalità online.

• Testare la connettività dello smartphone e la funzionalità di invio/ricezione.

10. Testare la funzionalità a livello di applicazione per SharePoint

• Testare OneDrive for Business client di sincronizzazione.

• Testare l'accesso Web di SharePoint.

11. Testare la funzionalità a livello di applicazione per scenari di chiamata Skype for Business:

• Partecipare alla conferenza telefonica come utente autenticato [invito avviato dall'utente finale].

• Invitare l'utente a una conferenza telefonica [invito inviato da MCU].

• Partecipare alla conferenza come utente anonimo usando l'applicazione Web Skype for Business.

• Partecipare alla chiamata dalla connessione pc cablata, dal telefono IP e dal dispositivo mobile.

• Chiamare l'utente federato o Convalida della chiamata a PSTN: la chiamata è stata completata, la qualità della chiamata è accettabile, il tempo di connessione è accettabile.

• Verificare che lo stato della presenza per i contatti sia per i membri del tenant che per gli utenti federati.

Problemi comuni

Il routing asimmetrico è il problema di implementazione più comune. Ecco alcune origini comuni da cercare:

• Uso di una topologia di routing di rete aperta o flat senza NAT di origine.

• Non si usa SNAT per instradare i servizi in ingresso tramite connessioni Internet ed ExpressRoute.

• Non si testano i servizi in ingresso in ExpressRoute in una rete di test prima della distribuzione su larga scala.

Distribuzione della connettività ExpressRoute tramite la rete

Organizzare la distribuzione in un segmento della rete alla volta, implementando progressivamente la connettività a diverse parti della rete con un piano per eseguire il rollback per ogni nuovo segmento di rete. Se la distribuzione è allineata a una distribuzione di Microsoft 365, distribuirla prima agli utenti pilota di Microsoft 365 ed estenderla da qui.

Prima per il test e quindi per la produzione:

• Eseguire i passaggi di distribuzione per abilitare ExpressRoute.

• Testare la visualizzazione delle route di rete come previsto.

• Eseguire test in ogni servizio in ingresso e in uscita.

• Rollback in caso di problemi.

Configurare una connessione di test a ExpressRoute con un segmento di rete di test

Ora che si ha il piano completato su carta, è il momento di eseguire il test su piccola scala. In questo test si stabilirà una singola connessione ExpressRoute con il peering Microsoft a una subnet di test nella rete locale. È possibile configurare un tenant di valutazione di Microsoft 365 con connettività da e verso la subnet di test e includere tutti i servizi in uscita e in ingresso che verranno usati nell'ambiente di produzione nella subnet di test. Configurare DNS per il segmento di rete di test e stabilire tutti i servizi in ingresso e in uscita. Eseguire il piano di test e assicurarsi di avere familiarità con il routing per ogni servizio e la propagazione della route.

Eseguire i piani di distribuzione e test

Quando si completano gli elementi descritti in precedenza, controllare le aree completate e assicurarsi che l'utente e il team li abbiano esaminati prima di eseguire i piani di distribuzione e test.

• Elenco dei servizi in uscita e in ingresso coinvolti nella modifica della rete.

• Diagramma dell'architettura di rete globale che mostra sia le posizioni di uscita Internet che le posizioni di incontro di ExpressRoute.

• Diagramma di routing di rete che illustra i diversi percorsi di rete usati per ogni servizio distribuito.

• Un piano di distribuzione con la procedura per implementare le modifiche e il rollback, se necessario.

• Un piano di test per il test di ogni servizio microsoft 365 e di rete.

• Convalida cartacea completata delle route di produzione per i servizi in ingresso e in uscita.

• Test completato in un segmento di rete di test, incluso il test di disponibilità.

Scegliere una finestra di interruzione sufficiente per l'esecuzione dell'intero piano di distribuzione e del piano di test, con un tempo disponibile per la risoluzione dei problemi e il tempo necessario per il rollback, se necessario.

Attenzione

A causa della natura complessa del routing sia su Internet che su ExpressRoute, è consigliabile aggiungere ulteriore tempo del buffer a questa finestra per gestire la risoluzione dei problemi di routing complesso.

Configurare QoS per Skype for Business Online

QoS è necessario per ottenere i vantaggi di voce e riunione per Skype for Business Online. È possibile configurare QoS dopo aver verificato che la connessione di rete ExpressRoute non blocchi alcun altro accesso al servizio Microsoft 365. La configurazione per QoS è descritta nell'articolo ExpressRoute e QoS in Skype for Business Online .

Risoluzione dei problemi di implementazione

Il primo aspetto da esaminare è la procedura descritta in questa guida all'implementazione, in cui sono mancati i passaggi nel piano di implementazione? Indietro ed eseguire ulteriori piccoli test di rete, se possibile, per replicare l'errore ed eseguirne il debug.

Identificare i servizi in ingresso o in uscita non riusciti durante il test. Ottenere in modo specifico gli indirizzi IP e le subnet per ognuno dei servizi non riusciti. Procedere e seguire il diagramma della topologia di rete su carta e convalidare il routing. Convalidare in modo specifico la posizione in cui viene annunciato il routing di ExpressRoute, testare il routing durante l'interruzione, se possibile con le tracce.

Eseguire PSPing con una traccia di rete per ogni endpoint del cliente e valutare gli indirizzi IP di origine e di destinazione per verificare che siano come previsto. Eseguire telnet in qualsiasi host di posta elettronica esposto sulla porta 25 e verificare che SNAT stia nascondendo l'indirizzo IP di origine originale, se previsto.

Tenere presente che durante la distribuzione di Microsoft 365 con una connessione ExpressRoute è necessario assicurarsi che sia la configurazione di rete per ExpressRoute sia progettata in modo ottimale e che siano stati ottimizzati anche gli altri componenti della rete, ad esempio i computer client. Oltre a usare questa guida alla pianificazione per risolvere i passaggi che potrebbero non essere stati eseguiti, è stato scritto anche un piano di risoluzione dei problemi di prestazioni per Microsoft 365 .

Ecco un collegamento breve per tornare alla pagina: https://aka.ms/implementexpressroute365

Argomenti correlati

Valutazione della connettività di rete di Microsoft 365

Azure ExpressRoute per Microsoft 365

Qualità multimediale e prestazioni della connettività di rete in Skype for Business Online

Ottimizzazione della rete per Skype for Business Online

ExpressRoute e QoS in Skype for Business Online

Flusso di chiamata con ExpressRoute

Ottimizzazione delle prestazioni di Microsoft 365 con baseline e cronologia delle prestazioni

Piano di risoluzione dei problemi di prestazioni per Microsoft 365

URL e intervalli di indirizzi IP per Microsoft 365

Ottimizzazione della rete e delle prestazioni di Microsoft 365