Implementazione di ExpressRoute per Office 365

Importante :  Il presente articolo è stato tradotto automaticamente, vedere la dichiarazione di non responsabilità. Per visualizzare la versione inglese dell'articolo, fare clic qui.

ExpressRoute per Office 365 offre un percorso di routing alternativo a molti servizi di Office 365 su Internet. L'architettura di ExpressRoute per Office 365 si basa sulla promozione dei prefissi IP pubblici dei servizi di Office 365, che sono già accessibili via Internet nei circuiti ExpressRoute di provisioning per la ridistribuzione successiva alla rete aziendale. Con ExpressRoute si attivano in modo efficace più percorsi di routing differenti, via Internet ed ExpressRoute, per molti servizi di Office 365. Questo stato del routing della rete può rappresentare un cambiamento significativo rispetto a come è stata progettata la topologia della rete interna.

Stato: Guida completa v2

È necessario pianificare accuratamente l'implementazione di ExpressRoute per Office 365 in modo da adattarsi alle complessità di rete comportate dalla disponibilità del routing sia attraverso un circuito dedicato con percorsi inseriti nella rete di base sia attraverso Internet. Se il team non esegue la pianificazione e la verifica dettagliate in questa Guida, esiste un forte rischio di riscontrare l'intermittenza o la perdita totale di connettività ai servizi di Office 365 quando il circuito ExpressRoute è abilitato.

Per completare una buona implementazione, è necessario analizzare i requisiti dell'infrastruttura, esaminare nel dettaglio la valutazione e la progettazione della rete, pianificare attentamente l'implementazione in modo controllato e a fasi e creare un piano dettagliato di convalida e test. Per un ambiente distribuito di grandi dimensioni, non è insolito che le implementazioni richiedano diversi mesi. Questa guida è concepita per aiutare l'utente a pianificare l'implementazione in anticipo.

Il buon esito delle grandi distribuzioni può richiedere sei mesi di pianificazione e il team spesso include membri provenienti da svariate aree dell'organizzazione, tra cui gli amministratori di rete, firewall e server proxy, Office 365, sicurezza, supporto per l'utente finale, gestione progetti e supporto della dirigenza. L'investimento operato nel processo di pianificazione ridurrà la probabilità di riscontrare errori di distribuzione che comportano tempi di inattività e complesse e costose attività di risoluzione dei problemi.

Completare i prerequisiti seguenti prima di iniziare questa Guida all'implementazione.

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

  2. È stato selezionato un provider di servizi di rete ExpressRoute. Sono disponibili altre informazioni su partner e località di peering per ExpressRoute.

  3. È già letti e si conoscono documentazione ExpressRoute e la rete interna è in grado di soddisfare prerequisiti ExpressRoute to end.

  4. Il team ha leggere tutte le indicazioni per la pubblica e documentazione https://aka.ms/expressrouteoffice365, https://aka.ms/erte controllate la serie di Azure ExpressRoute per Office 365 formazione su Channel 9 per acquisire familiarità con dettagli tecnici critici inclusi:

    • Le dipendenze Internet dei servizi SaaS.

    • Come evitare percorsi asimmetrici e gestire il routing complesso.

    • Informazioni su come incorporare protezione perimetrale, disponibilità e controllo del livello di applicazione.

Iniziare raccogliendo i requisiti

Prima di tutto determinare quali caratteristiche e servizi si prevede di adottare all'interno dell'organizzazione. È necessario determinare quali caratteristiche dei diversi servizi di Office 365 verranno usate e quali percorsi di rete ospiteranno gli utenti che usano tali caratteristiche. Con il catalogo di scenari, è necessario aggiungere gli attributi di rete che ognuno di questi scenari richiede; ad esempio, flussi di traffico di rete in ingresso e in uscita e se gli endpoint di Office 365 sono disponibili su ExpressRoute o no.

Per raccogliere i requisiti dell'organizzazione:

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

  • Raccogliere la documentazione della topologia di rete esistente con dettagli su dorsale e topologia WAN interne, connettività dei siti satellite, connettività dell'ultimo miglio, routing ai punti di uscita dal perimetro della rete e servizi proxy.

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

    • Identificare tutte le posizioni geografiche per l'utente e la connettività WAN tra posizioni oltre a quali posizioni hanno attualmente un punto di uscita a Internet e per quali posizioni è proposto un punto di uscita a una posizione di peering di ExpressRoute.

    • Identificare tutti i dispositivi periferici, ad esempio proxy, firewall e così via, e catalogare le corrispondenti relazioni ai flussi trasmessi via Internet ed ExpressRoute.

    • Documentare se gli utenti finali accederanno ai servizi di Office 365 via routing diretto oppure un proxy di applicazione indiretto per i flussi Internet ed ExpressRoute.

  • Aggiungere il percorso del tenant e località di peering al diagramma reticolare.

  • Stimare le prestazioni previste e osservate della rete e le caratteristiche di latenza dalle principali località utente a Office 365, tenendo presente che Office 365 è un set di servizi globale e distribuito e che gli utenti si connetteranno a località che potrebbero differire da quella del loro tenant. Per questo motivo, è consigliabile misurare e ottimizzare per la latenza tra l'utente e il dispositivo periferico più vicino della rete globale di Microsoft via connessioni Internet ed ExpressRoute. È possibile usare i risultati della valutazione di rete per semplificare questa attività.

  • Elencare i requisiti in termini di sicurezza ed elevata disponibilità della rete aziendale che occorre soddisfare con la nuova connessione ExpressRoute; ad esempio, il modo in cui gli utenti continuano a ottenere l'accesso a Office 365 in caso di errore del circuito ExpressRoute o del punto di uscita Internet.

  • Documento di rete che Office 365 in ingresso e in uscita scorra verrà utilizzato il percorso di Internet e che verrà utilizzato ExpressRoute. Le specifiche delle aree geografiche degli utenti e i dettagli della topologia di rete locale possono richiedere il piano può essere diverso dalla posizione di un utente a un'altra.

Per ridurre al minimo le complessità di rete di routing e altre, si consiglia di utilizzare solo ExpressRoute per Office 365 per i flussi di traffico di rete necessari per l'invio tramite una connessione dedicata a causa di requisiti normativi o come risultato della valutazione della rete. Inoltre, è consigliabile fase l'ambito della ExpressRoute routing e approccio rete in ingresso e in uscita flussi di traffico come diversi fasi del progetto di implementazione. Distribuire ExpressRoute per Office 365 per flussi di traffico di rete in uscita avviata dall'utente soltanto e lasciare flussi di traffico di rete in ingresso su Internet consente di controllare l'aumento di complessità topologia e i rischi di introdurre altre possibilità di routing asimmetriche.

Nel catalogo il traffico di rete deve contenere elenchi di tutte le connessioni di rete in ingresso e in uscita che è necessario tra la rete locale e Microsoft.

  • Per flusso di traffico di rete in uscita si intende qualsiasi scenario in cui si inizia una connessione dall'ambiente locale, ad esempio dai client o dai server interni, con una destinazione dei servizi Microsoft. Queste connessioni potrebbero essere dirette a Office 365 o indirette, ad esempio quando la connessione attraversa server proxy, firewall o altri dispositivi di rete lungo il percorso verso Office 365.

  • I flussi di traffico di rete in ingresso rappresentano qualsiasi scenario in cui una connessione viene avviata dal cloud Microsoft a un host locale. Queste connessioni in genere devono attraversare un firewall e altre infrastrutture di sicurezza richiesti dai criteri di sicurezza dei clienti per i flussi originati esternamente.

Leggere la sezione su come assicurare la simmetria del percorso dell'articolo Routing con ExpressRoute per Office 365 per determinare quali servizi invieranno il traffico in ingresso e cercare la colonna contrassegnata ExpressRoute per Office 365 nell'articolo di riferimento agli endpoint di Office 365 per determinare le restanti informazioni sulla connettività.

Per ogni servizio che richiede una connessione in uscita, è consigliabile descrivere la connettività pianificata per il servizio, tra cui il routing di rete, la configurazione del proxy, l'ispezione pacchetti e le esigenze in termini di larghezza di banda.

Per ogni servizio che richiede una connessione in ingresso, saranno necessarie alcune informazioni aggiuntive. I server nel cloud Microsoft stabiliranno connessioni alla rete locale. Per assicurarsi che le connessioni siano eseguite correttamente, è consigliabile descrivere tutti gli aspetti della connettività, tra cui le voci di DNS pubbliche per i servizi che accettano queste connessioni in ingresso, gli indirizzi IPv4 formattati con CIDR, quali dispositivi ISP sono implicati e come viene gestito NAT in ingresso o NAT di origine per queste connessioni.

Le connessioni in ingresso devono essere esaminate indipendentemente dal fatto che la connessione avvenga via Internet o ExpressRoute per garantire che non sia stato introdotto un routing asimmetrico. In alcuni casi, l'accesso agli endpoint locali a cui i servizi di Office 365 avviano connessioni in ingresso potrebbe essere necessario anche da parte di altri servizi Microsoft e non Microsoft. È fondamentale che l'abilitazione del routing ExpressRoute a questi servizi per scopi di Office 365 non violino altri scenari. In molti casi, i clienti potrebbe dover implementare modifiche specifiche alla propria rete interna, ad esempio NAT di origine, in modo da assicurare che i flussi in ingresso da Microsoft rimangano simmetrici dopo avere abilitato ExpressRoute.

Ecco un esempio del livello di dettaglio necessario. In questo caso Exchange ibrido eseguirebbe il routing al sistema locale via ExpressRoute.

Proprietà di connessione

Valore

Direzione del traffico di rete

In ingresso

Servizio

Exchange ibrido

Endpoint pubblico di Office 365 (origine)

Exchange Online (indirizzi IP)

Endpoint locali pubblici (destinazione)

5.5.5.5

Voce DNS (Internet) pubblica

Autodiscover.contoso.com

Questo endpoint locale verrà usato da altri servizi Microsoft (non Office 365)?

No

Questo endpoint locale verrà usato da sistemi/utenti su Internet?

Sistemi interni pubblicati attraverso endpoint pubblici

Ruolo di accesso client di Exchange Server (locale) 192.168.101, 192.168.102, 192.168.103

Annuncio IP dell'endpoint pubblico

Su Internet: 5.5.0.0/16

Per ExpressRoute: 5.5.5.0/24

Controlli di sicurezza/perimetrali

Percorso Internet: DeviceID_002

Percorso di ExpressRoute: DeviceID_003

Disponibilità elevata

Attivo/attivo tra 2 circuiti geo-ridondanti

Circuiti ExpressRoute - Chicago e Dallas

Controllo di simmetria percorso

Metodo: NAT di origine

Percorso Internet: connessioni a 192.168.5.5 in ingresso NAT di origine

Percorso di ExpressRoute: connessioni NAT origine 192.168.1.0 (Chicago) e 192.168.2.0 (Roma)

Ecco un esempio di un servizio che è solo in uscita:

Proprietà di connessione

Valore

Direzione del traffico di rete

In uscita

Servizio

SharePoint Online

Endpoint locale (origine)

Workstation utente

Endpoint pubblico di Office 365 (destinazione)

SharePoint Online (indirizzi IP)

Voce DNS (Internet) pubblica

*.sharepoint.com (e FQDN aggiuntivi)

Segnalazioni CDN

cdn.sharepointonline.com (e FQDN aggiuntivi) – Indirizzi IP gestiti dai provider CDN)

Annuncio IP e NAT in uso

Percorso Internet/NAT di origine: 1.1.1.0/24

Percorso di ExpressRoute/NAT di origine: 1.1.2.0/24 (Chicago) e 1.1.3.0/24 (Roma)

Metodo di connettività

Internet: tramite proxy livello 7 (file con estensione PAC)

ExpressRoute: indirizzare routing (Nessun proxy)

Controlli di sicurezza/perimetrali

Percorso Internet: DeviceID_002

Percorso di ExpressRoute: DeviceID_003

Disponibilità elevata

Percorso Internet: uscita internet ridondanti

Percorso di ExpressRoute: attivo/attivo 'hot la' routing tra 2 circuiti ExpressRoute geografico ridondanti-Chicago e Dallas

Controllo di simmetria percorso

Metodo: NAT per tutte le connessioni di origine

Dopo aver compreso i servizi e i flussi del traffico di rete a essi associati, è possibile creare un diagramma reticolare che incorpori questi nuovi requisiti di connettività e illustri le modifiche apportate per usare ExpressRoute per Office 365. Il diagramma deve includere:

  1. Tutte le località degli utenti da cui si accederà a Office 365 e ad altri servizi.

  2. Tutti i punti di uscita di Internet ed ExpressRoute.

  3. Tutti i dispositivi in ingresso e in uscita gestiscono la connettività in ingresso e in uscita dalla rete, inclusi router, firewall, server proxy delle applicazioni e rilevamento/prevenzione delle intrusioni.

  4. Le destinazioni interne per tutto il traffico in ingresso, ad esempio server ADFS interni che accettano le connessioni dai server proxy delle applicazioni Web ADFS.

  5. Catalogare tutte le subnet IP che verranno annunciate

  6. Identificare ogni località da cui gli utenti accederanno a Office 365 ed elencare le località di peering che verranno usate per ExpressRoute.

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

  8. La topologia della rete deve illustrare l'area geografica di ogni segmento di rete e come si connette alla rete Microsoft via ExpressRoute e/o Internet.

Il diagramma seguente illustra ogni località da cui gli utenti useranno Office 365 insieme agli annunci di routing in ingresso e in uscita a Office 365.

Peering per area geografica di ExpressRoute

Per il traffico in uscita, gli utenti accedono a Office 365 in tre modi:

  1. Attraverso una località di peering nell'America del Nord per gli utenti in California.

  2. Attraverso una località di peering a Hong Kong per gli utenti di Hong Kong.

  3. Attraverso Internet in Bangladesh dove ci sono meno utenti e non è fornito alcun circuito ExpressRoute.

Connessioni in uscita per il diagramma dell'area geografica

Allo stesso modo, il traffico di rete in ingresso da Office 365 viene restituito in uno di tre modi:

  1. Attraverso una località di peering nell'America del Nord per gli utenti in California.

  2. Attraverso una località di peering a Hong Kong per gli utenti di Hong Kong.

  3. Attraverso Internet in Bangladesh dove ci sono meno utenti e non è fornito alcun circuito ExpressRoute.

Connessioni in ingresso per il diagramma dell'area geografica

La selezione delle località di peering, ossia la posizione fisica in cui il circuito ExpressRoute connette la rete dell'utente alla rete Microsoft, è influenzata dalle località da cui gli utenti accederanno a Office 365. Come parte dell'offerta SaaS, Office 365 non opera in base al modello regionale IaaS o PaaS così come fa Azure. Al contrario, Office 365 è un set di servizi di collaborazione distribuito, in cui gli utenti potrebbero doversi connettere agli endpoint attraverso più data center e aree geografiche, che potrebbero non trovarsi necessariamente nella stessa posizione o area geografica in cui è ospitato il tenant dell'utente.

Questo significa che l'aspetto più importante da considerare durante la selezione delle località di peering per ExpressRoute per Office 365 è la posizione da cui si connetteranno gli utenti dell'organizzazione. In generale, per la connettività ottimale di Office 365 è consigliabile implementare il routing, in modo che le richieste inviate dagli utenti ai servizi di Office 365 siano trasferite alla rete Microsoft attraverso il percorso di rete più breve, procedura spesso definita come routing "hot potato". Ad esempio, se la maggior parte degli utenti di Office 365 si trovano in una o due località, la selezione di località di peering che si trovano nelle immediate vicinanze alla località di tali utenti creerà la struttura ottimale. Se la società conta parecchi utenti in molte aree geografiche diverse, può essere preferibile impostare più circuiti e località di peering di ExpressRoute. Per alcune località utente, il percorso più breve/ottimale verso la rete Microsoft e Office 365 potrebbe non passare attraverso la WAN interna e le località di peering di ExpressRoute, ma attraverso Internet.

Spesso, all'interno di un'area geografica è possibile selezionare più località di peering in relativa prossimità agli utenti. Compilare la tabella seguente per un processo decisionale corretto.

Località di peering di ExpressRoute pianificate in California e a New York

Località

Numero di utenti

Latenza prevista verso la rete Microsoft attraverso il punto di uscita Internet

Latenza prevista verso la rete Microsoft attraverso ExpressRoute

Los Angeles

10.000

~15 ms

~10 ms (via Silicon Valley)

Washington

15.000

~20 ms

~10 ms (via New York)

Dallas

5.000

~15 ms

~40 ms (via New York)

Dopo aver sviluppato l'architettura di rete globale che mostra l'area geografica di Office 365, le località di peering del provider di servizi di rete di ExpressRoute e la quantità di utenti per località, è possibile usarla per identificare le eventuali ottimizzazioni potenziali. Può anche mostrare le connessioni di rete di hairpinning globali in cui il traffico viene indirizzato a una posizione distante con lo scopo di ottenere la località di peering. Se viene rilevato un hairpinning nella rete globale, occorre risolverlo prima di continuare. Trovare una località di peering oppure usare i punti di uscita Internet selettivi per evitare l'hairpinning.

Il primo diagramma mostra un esempio di un cliente con due località fisiche in America del Nord. Sono visibili le informazioni sulle località degli uffici, le località dei tenant di Office 365 e diverse opzioni di località di peering di ExpressRoute. In questo esempio, il cliente ha selezionato la località di peering in base a due principi, nell'ordine:

  1. Immediata vicinanza agli utenti della propria organizzazione.

  2. Più vicina in prossimità un Data Center Microsoft ospita Office 365.

Peering geografico USA di ExpressRoute

Espandendo ulteriormente il concetto, il secondo diagramma mostra un esempio di cliente multinazionale che ha a che fare con informazioni e processi decisionali simili. Il cliente ha un piccolo ufficio in Bangladesh con un team di sole dieci persone impegnate ad espandere la propria presenza nell'area geografica. È disponibile una località di peering a Chennai, in cui è ospitato anche un data center di Microsoft con Office 365. Dunque, la presenza di una località di peering nella stessa città avrebbe senso; tuttavia, per dieci persone, la spesa di un circuito aggiuntivo è onerosa. Esaminando la rete, sarà necessario determinare se la latenza implicata dall'invio del traffico di rete attraverso la propria rete è più efficace dell'esborso del capitale necessario ad acquisire un altro circuito di ExpressRoute.

In alternativa, le dieci persone in Bangladesh potrebbero riscontrare prestazioni più elevate del traffico di rete inviato attraverso Internet alla rete Microsoft rispetto al routing attraverso la rete interna, come dimostrato nei diagrammi introduttivi riprodotti qui di seguito.

Connessioni in uscita per il diagramma dell'area geografica

Creare un piano di implementazione di ExpressRoute per Office 365

Il piano di implementazione deve includere sia i dettagli tecnici di configurazione di ExpressRoute sia i dettagli di configurazione di tutte le altre infrastrutture in rete, come le seguenti.

  • Pianificare quali servizi saranno suddivisi tra ExpressRoute e Internet.

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

  • Progettare il routing in ingresso e in uscita, incluse le corrette ottimizzazioni del percorso di routing per diverse località

  • Decidere fino a che punto saranno pubblicizzati i percorsi di ExpressRoute in rete e qual è il meccanismo con cui i client selezioneranno il percorso via Internet o ExpressRoute; ad esempio, routing diretto o proxy di applicazione.

  • Pianificare le modifiche ai record DNS, tra cui le voci Sender Policy Framework.

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

  • Per la distribuzione iniziale, tutti i servizi in ingresso, ad esempio posta elettronica in ingresso o connettività ibrida, dovranno usare internet.

  • Pianificare degli utenti finali client routing LAN, ad esempio la configurazione di un file PAC/WPADroute predefinita, nei server proxy e annunci route BGP.

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

Creare un piano per la larghezza di banda necessario per ogni carico di lavoro di Office 365 principale. Stimare separatamente i requisiti in termini di larghezza di banda di Exchange Online, SharePoint Online e Skype for Business Online. Come punto di partenza, è possibile usare gli strumenti di calcolo della stima disponibili per Exchange Online e Skype for Business; è tuttavia necessario effettuare un test del progetto pilota con un campione rappresentativo dei profili e delle località utente per comprendere appieno le esigenze di larghezza di banda dell'organizzazione.

Aggiungere la modalità di gestione della sicurezza in ogni punto di uscita Internet ed ExpressRoute al proprio piano, tenere presente che tutte le connessioni ExpressRoute a Office 365 usano il peering pubblico e devono ancora essere protette in base ai criteri di sicurezza aziendale della connessione a reti esterne.

Aggiungere al piano informazioni dettagliate su quali utenti saranno interessati da quale tipo di interruzione e in che modo potranno eseguire il proprio lavoro a pieno ritmo nel modo più semplice possibile.

Pianificare i requisiti di larghezza di banda tra cui i requisiti di Skype for Business su instabilità, latenza, congestione e capacità

Anche Skype for Business online ha requisiti di rete specifici, descritti nel dettaglio nell'articolo Qualità degli elementi multimediali e prestazioni della connessione di rete in Skype for Business Online.

Leggere la sezione Pianificazione della rete con ExpressRoute per Office 365 in Pianificazione della larghezza di banda per Azure ExpressRoute.

Quando si esegue una valutazione della larghezza di banda con altri utenti del progetto pilota, è possibile usare la Guida Ottimizzazione delle prestazioni di Office 365 con le previsioni e la cronologia delle prestazioni.

Pianificare i requisiti di disponibilità elevata

Creare un piano per la disponibilità elevata che soddisfi le proprie esigenze e incorporarlo nel diagramma di topologia della rete aggiornato. Leggere la sezione Disponibilità elevata e failover con Azure ExpressRoute in Pianificazione della rete con ExpressRoute per Office 365.

Piano per requisiti di sicurezza di rete

Creare un piano che soddisfi i requisiti di sicurezza della rete e incorporarlo nel diagramma di topologia della rete aggiornato. Leggere la sezione Applicazione dei controlli di sicurezza agli scenari con Azure ExpressRoute per Office 365 in Pianificazione della rete con ExpressRoute per Office 365.

ExpressRoute per Office 365 è caratterizzato da requisiti di rete in uscita che potrebbero non essere familiari. In particolare, gli indirizzi IP che rappresentano gli utenti e le reti verso Office 365 e fungono da endpoint di origine per le connessioni di rete in uscita verso Microsoft devono seguire i requisiti specifici indicati di seguito.

  1. Gli endpoint devono essere indirizzi IP pubblici, che vengono registrati alla società o al gestore telefonico che fornisce la connettività di ExpressRoute.

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

  3. Gli endpoint non devono essere annunciati su Internet con la stessa metrica di routing o con una di propria preferenza.

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

Se la struttura della rete non soddisfa questi requisiti, esiste un alto rischio che gli utenti riscontrino problemi di connettività a Office 365 e ad altri servizi Microsoft a causa dei "black hole" del percorso o di un routing asimmetrico. Questo problema si verifica quando le richieste ai servizi Microsoft vengono instradate attraverso ExpressRoute, ma le risposte vengono indirizzate nuovamente su Internet o viceversa e le risposte vengono eliminate da dispositivi di rete con stato, ad esempio i firewall.

Il metodo più comune che è possibile usare per soddisfare i requisiti precedenti consiste nell'usare il NAT di origine, implementato come parte della rete aziendale o fornito dal gestore di ExpressRoute. Il NAT di origine consente di estrarre i dettagli e gli indirizzi IP privati della rete Internet da ExpressRoute e, unitamente agli annunci di percorsi IP corretti, fornire un meccanismo semplice per garantire la simmetria del percorso. Se si usano dispositivi di rete con stato che sono specifici delle località di peering di ExpressRoute, è necessario implementare pool di NAT separati per ogni peering di ExpressRoute per garantire la simmetria del percorso.

Altre informazioni sui requisiti NAT di ExpressRoute.

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

La maggior parte delle distribuzioni di Office 365 aziendali presuppone una sorta di connettività in ingresso da Office 365 ai servizi locali, ad esempio per scenari ibridi di Exchange, SharePoint e Skype for Business, migrazione di cassette postali e autenticazione con l'infrastruttura ADFS. Quando ExpressRoute abilita un percorso di routing aggiuntivo tra la rete locale e Microsoft per la connettività in uscita, queste connessioni in ingresso potrebbero inavvertitamente essere interessate da routing asimmetrici, anche se si intende che tali flussi continuino a usare Internet. È consigliabile adottare alcune delle precauzioni descritte di seguito per assicurarsi che non via sia alcun impatto sui flussi in ingresso basati su Internet da Office 365 ai sistemi locali.

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

Può risultare utile uno dei modelli di implementazione seguenti per soddisfare questo requisito:

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

  2. Assicurarsi che i percorsi di ExpressRoute non vengano propagati ai segmenti di rete in cui risiedono i servizi in ingresso, come i server front-end o i sistemi di proxy inverso, che gestiscono le connessioni.

Tenere esplicitamente conto di questi scenari nella propria rete e mantenere tutti i flussi di traffico di rete in ingresso via Internet aiuta a ridurre al minimo la distribuzione e il rischio operativo del routing asimmetrico.

In alcuni casi potrebbe essere possibile scegliere di indirizzare alcuni flussi in ingresso attraverso le connessioni ExpressRoute. Per questi scenari, tenere presenti le seguenti considerazioni aggiuntive.

  1. Office 365 può considerare come destinazione solo gli endpoint locali che usano IP pubblici. Questo significa che anche se l'endpoint in ingresso locale viene esposto solo a Office 365 via ExpressRoute, è comunque necessario che ad esso sia associato un IP pubblico.

  2. Tutte le operazioni di risoluzione dei nomi DNS eseguite dai servizi di Office 365 per risolvere gli endpoint locali usano DNS pubblici. Questo significa che è necessario registrare l'FQDN degli endpoint del servizio in ingresso nei mapping IP su Internet.

  3. Per ricevere le connessioni di rete in ingresso via ExpressRoute, è necessario che le subnet pubbliche per questi endpoint siano annunciate su Microsoft via ExpressRoute.

  4. Valutare con attenzione questi flussi del traffico di rete in ingresso per garantire che un'adeguata protezione e controlli di rete vengano applicati in conformità con i criteri di rete e sicurezza della società.

  5. Dopo aver annunciato gli endpoint in ingresso locali su Microsoft via ExpressRoute, ExpressRoute diverrà effettivamente il percorso di routing preferito a tali endpoint per tutti i servizi Microsoft, tra cui Office 365. Questo significa che le subnet degli endpoint devono essere usate solo per le comunicazioni con i servizi di Office 365 e nessun altro servizio della rete Microsoft. In caso contrario, la progettazione causerà il routing asimmetrico in cui le connessioni in ingresso da altri servizi Microsoft preferiscono l'instradamento in ingresso via ExpressRoute, mentre il percorso di ritorno userà Internet.

  6. Nel caso in cui un circuito di ExpressRoute o una località di peering non fossero attivi, assicurarsi che gli endpoint in ingresso locali accettino ancora le richieste attraverso un percorso di rete separato. Ciò può comportare l'annuncio delle subnet per tali endpoint attraverso più circuiti ExpressRoute.

  7. È consigliabile applicare il NAT di origine per tutti i flussi di traffico di rete in ingresso che accedono alla rete attraverso ExpressRoute, soprattutto quando questi flussi attraversano più dispositivi di rete con stato, ad esempio i firewall.

  8. Alcuni servizi locali, come il proxy ADFS o l'individuazione automatica di Exchange, potrebbero ricevere richieste in ingresso dai servizi di Office 365 e dagli utenti da Internet. Per queste richieste, la destinazione di Office 365 sarò lo stesso FQDN delle richieste degli utenti via Internet. Consentire le connessioni utente in ingresso da Internet a tali endpoint locali, imponendo allo stesso tempo l'uso di ExpressRoute in Office 365, rappresenta una significativa complessità del routing. Per la maggior parte dei clienti, l'implementazione di tali scenari complessi via ExpressRoute non è consigliabile per motivi operativi. Questo sovraccarico aggiuntivo include la gestione dei rischi di routing asimmetrico e richiederà l'attenta gestione degli annunci e dei criteri di routing in più dimensioni.

In genere si tende a evitare il routing asimmetrico per garantire che gli utenti nell'organizzazione possano usare facilmente Office 365 nonché altri importanti servizi su Internet. Sono due le configurazioni comuni adottate dai clienti che causano il routing asimmetrico. È il momento giusto per esaminare la configurazione di rete che si intende usare e verificare se potrebbe verificarsi uno dei seguenti scenari di routing asimmetrico.

Per iniziare, verranno prese in esame alcune situazioni diverse associate al diagramma reticolare seguente. In questo diagramma, tutti i server che ricevono le richieste in ingresso, ad esempio nel caso in cui server ibridi ADFS o locali si trovano nel data center nel New Jersey e vengono annunciati su Internet.

  1. Mentre la rete perimetrale è protetta, non è disponibile alcun NAT di origine per le richieste in arrivo.

  2. I server nel data center nel New Jersey possono visualizzare i percorsi sia Internet sia ExpressRoute.

Panoramica sulla connettività di ExpressRoute

Sono disponibili altri suggerimenti su come risolverli.

Problema 1: Connessione da cloud a locale via Internet

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

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

  2. In questa configurazione difettosa, non è né disponibile né è stato configurato un NAT di origine nella rete perimetrale a cui viene inviato il traffico, e ciò comporta l'uso dell'effettivo indirizzo IP di origine come destinazione di ritorno.

    • Il server della rete indirizza il traffico di ritorno a Office 365 attraverso qualsiasi connessione di rete ExpressRoute disponibile.

    • Il risultato è un percorso asimmetrico per tale flusso a Office 365, risultante in una connessione interrotta.

Problema di routing asimmetrico ExpressRoute 1

Soluzione 1a: NAT di origine

La semplice aggiunta di un NAT di origine alla richiesta in ingresso risolve questo errore di configurazione della rete. In questo diagramma:

  1. La richiesta in ingresso continua ad accedere attraverso la rete perimetrale del data center nel New Jersey. Stavolta, il NAT di origine è disponibile.

  2. La risposta dal server torna all'IP associato al NAT di origine invece che all'indirizzo IP originale, comportando la restituzione della risposta lungo lo stesso percorso di rete.

Soluzione per routing asimmetrico ExpressRoute 1

Soluzione 1b: Definizione dell'ambito del percorso

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 ad accedere attraverso la rete perimetrale del data center nel New Jersey. Stavolta i prefissi annunciati da Microsoft attraverso il circuito di ExpressRoute non sono disponibili al data center del New Jersey.

  2. La risposta dal server torna all'IP associato all'indirizzo IP originale attraverso l'unico percorso disponibile, comportando la restituzione della risposta lungo lo stesso percorso di rete.

Soluzione per routing asimmetrico ExpressRoute 2

Problema 2: Connessione da cloud a locale via ExpressRoute

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

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

  2. In questa configurazione difettosa, non è né disponibile né è stato configurato un NAT di origine nella rete perimetrale a cui viene inviato il traffico, e ciò comporta l'uso dell'effettivo indirizzo IP di origine come destinazione di ritorno.

    • Il computer nella rete indirizza il traffico di ritorno a Office 365 attraverso qualsiasi connessione di rete ExpressRoute disponibile.

    • Il risultato è una connessione asimmetrica a Office 365.

Problema di routing asimmetrico ExpressRoute 2

Soluzione 2: NAT di origine

La semplice aggiunta di un NAT di origine alla richiesta in ingresso risolve questo errore di configurazione della rete. In questo diagramma:

  1. La richiesta in ingresso continua ad accedere attraverso la rete perimetrale del data center di New York. Stavolta, il NAT di origine è disponibile.

  2. La risposta dal server torna all'IP associato al NAT di origine invece che all'indirizzo IP originale, comportando la restituzione della risposta lungo lo stesso percorso di rete.

Soluzione per routing asimmetrico ExpressRoute 3

Verificare su carta che la progettazione della rete offra la simmetria dei percorsi

A questo punto occorre verificare su carta che il piano di implementazione offra la simmetria dei percorsi per i diversi scenari in cui si inizierà a usare Office 365. Sarà identificato il percorso di rete specifico che si prevede verrà scelto quando un utente usa diverse caratteristiche del servizio. Dalla rete locale e il routing WAN ai dispositivi perimetrali al percorso di connettività ExpressRoute o Internet, fino alla connessione all'endpoint online.

Questa operazione è necessaria per tutti i servizi di rete di Office 365 che sono stati precedentemente identificati come servizi che verranno adottati dalla propria organizzazione.

È utile affrontare questo procedimento su carta con l'aiuto di un'altra persona. Illustrare i punti da cui ogni passaggio di rete dovrebbe ricavare il percorso successivo e garantire la propria familiarità con i percorsi di routing. Tenere presente che ExpressRoute fornirà sempre un percorso con un maggiore ambito agli indirizzi IP del server Microsoft assegnandovi un costo inferiore rispetto a un percorso predefinito di Internet.

Progettare la configurazione della connettività dei client

Uso di file PAC con ExpressRoute

Se si usa un server proxy per internet associato il traffico, sarà necessario modificare qualsiasi PAC o file di configurazione di client per assicurarsi che il computer client nella rete sta configurato correttamente per inviare il traffico ExpressRoute desiderato in Office 365 senza in transito server proxy e del traffico, tra cui una parte del traffico Office 365, vengono inviate al proxy di pertinenti. Leggere la Guida sulla gestione di Office 365 endpoint ad esempio file PAC.

Nota : Gli endpoint cambiano di frequente, molto spesso ogni settimana. È necessario apportare modifiche solo in base ai servizi e alle caratteristiche che l'organizzazione ha adottato per ridurre il numero di modifiche necessario a dimostrare di essere sempre aggiornati. Prestare particolare attenzione alla Data di validità nel feed RSS in cui le modifiche vengono annunciate e che sia mantenuto un record di tutte le modifiche precedenti, tra cui indirizzi IP annunciati che potrebbero non essere pubblicizzati o rimossi dall'annuncio, fino al raggiungimento della data di validità.

Creare le procedure di distribuzione e test

Il piano di implementazione deve includere la pianificazione del test e del rollback. Se l'implementazione non funziona come previsto, il piano dovrà essere progettato in modo da influire sul minor numero di utenti prima che vengano rilevati dei problemi. Di seguito sono riportati alcuni principi di alto livello che è opportuno prendere in considerazione nel piano.

  1. Organizzare per fasi il segmento di rete e l'onboarding del servizio per ridurre al minimo i disagi.

  2. Pianificare percorsi di test con un traceroute e connessione TCP da un host separato e connesso a Internet.

  3. Preferenza, verifica dei servizi in ingresso e in uscita deve essere eseguita in una rete isolata test con un tenant di prova Office 365.

    • In alternativa, il test può essere eseguito in una rete di produzione se il cliente non usa ancora Office 365 o partecipa al progetto pilota.

    • In alternativa, il test può essere eseguito durante un'interruzione della produzione che è riservata solo per test e monitoraggio.

    • In alternativa, il test può essere eseguito verificando i percorsi per ogni servizio in ciascun nodo di router di livello 3. Quest'alternativa dovrà essere usata solo qualora non fosse possibile alcun altro approccio, perché un'assenza di test fisici introduce il rischio.

Le procedure di distribuzione dovrebbero essere implementate in piccoli gruppi di persone in più passaggi, per poter eseguire dei test prima della distribuzione a gruppi di utenti più grandi. Di seguito sono illustrati diversi modi per eseguire la distribuzione di ExpressRoute.

  1. Configurare ExpressRoute con il peering Microsoft in modo da inoltrare gli annunci del percorso a un singolo host solo a scopo di verifica temporanea.

  2. Annunciare i percorsi nella rete ExpressRoute prima in un singolo segmento di rete, quindi espandere gli annunci del percorso per segmento di rete o per area geografica.

  3. Se la distribuzione di Office 365 avviene per la prima volta, usare la distribuzione di rete ExpressRoute come progetto pilota per un numero limitato di persone.

  4. Se si usano server proxy, è possibile configurare alternativamente un file PAC di test per indirizzare un numero limitato di persone a ExpressRoute con test e feedback prima di aggiungerne altre.

Il piano di implementazione dovrebbe elencare ognuna delle procedure di distribuzione che devono essere intraprese o i comandi che devono essere usati per distribuire la configurazione di rete. Quando arriva l'ora dell'interruzione di rete tutte le modifiche apportate dovrebbero provenire dal piano di distribuzione scritto in anticipo ed esaminato da un collega. Vedere la Guida alla configurazione tecnica di ExpressRoute.

  • Aggiornamento dei record TXT SPF se sono stati modificati gli indirizzi IP per qualsiasi server locale che continuerà a inviare posta elettronica.

  • Aggiornamento delle voci DNS per i server locali se sono stati modificati gli indirizzi IP per creare spazio sufficiente per una nuova configurazione NAT.

  • Assicurarsi di aver sottoscritto il feed RSS per le notifiche degli endpoint di Office 365 per mantenere tutte le configurazioni di routing o proxy.

Al termine della distribuzione ExpressRoute le procedure nel piano di test devono essere eseguite. I risultati per ogni procedura devono essere registrati. È necessario includere le procedure per ripristinare l'ambiente di produzione originale nel caso in cui i risultati del piano di test indicano che l'implementazione non ha esito negativo.

Le procedure di test devono includere i test per ogni servizio di rete in ingresso e in uscita per Office 365 che userà ExpressRoute e per quelli che non l'useranno. Le procedure devono includere test da ogni percorso di rete univoco tra cui gli utenti che non sono in locale nella rete locale aziendale.

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

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

  2. Verificare che gli oltre 500 annunci di indirizzi IP di Office 365 e CRM Online al router siano ricevuti dal router locale.

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

  4. Convalidare che indirizza al NAT è viene annunciato da router.

  5. Verificare che ExpressRoute abbia accettato i prefissi annunciati.

    • Per verificare gli annunci peering, utilizzare il cmdlet seguente:

    • Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeering
  6. Verificare che l'intervallo IP NAT pubblico non sia annunciato su Microsoft attraverso nessun altro circuito di rete ExpressRoute o Internet pubblico, a meno che non si tratti di uno specifico sottoinsieme di un intervallo più esteso, come nell'esempio precedente.

  7. I circuiti ExpressRoute vengono accoppiati; verificare che entrambe le sessioni BGP siano in esecuzione.

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

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

    • Testare la capacità di Outlook di connettersi a Exchange Online e inviare/ricevere posta elettronica.

    • Testare la capacità di Outlook di usare la modalità online.

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

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

    • Testare il client di sincronizzazione di OneDrive for Business.

    • Testare l'accesso Web di SharePoint Online.

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

    • Partecipare a una conferenza telefonica come utente autenticato [invito inviato dall'utente finale].

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

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

    • Partecipare alla chiamata dalla connessione cablata del PC, da telefono IP e da dispositivo mobile.

    • Chiamata per utente federato o chiamata al PSTN convalida: completamento della chiamata, qualità delle chiamate è accettabile, momento della connessione è accettabile.

    • Verificare che lo stato presenza per i contatti venga aggiornato in entrambi i membri del tenant e degli utenti federati.

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

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

  • Mancato uso di SNAT per instradare ai servizi in ingresso attraverso le connessioni Internet ed ExpressRoute.

  • Test non servizi in entrata sul ExpressRoute su una rete prima di distribuire ampiamente.

Distribuzione della connettività di ExpressRoute attraverso la rete

Organizzare la distribuzione in un segmento di rete per volta, implementando progressivamente la connettività a diverse parti della rete con un piano di eseguire il rollback per ogni nuovo segmento di rete. Se la distribuzione è allineata con una distribuzione di Office 365, distribuire prima agli utenti del progetto pilota di Office 365 ed estendere da quel punto.

Prima per il test e poi per la produzione:

  • Eseguire i passaggi di distribuzione per abilitare ExpressRoute.

  • Verificare che i percorsi di rete siano visualizzati come previsto.

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

  • Eseguire il rollback qualora si riscontrino dei problemi.

Dopo aver ottenuto il piano completo su carta, è giunto il momento di testarlo su piccola scala. In questo test si stabilirà una connessione ExpressRoute singola con Microsoft Peering alla subnet di prova nella rete locale. È possibile configurare un tenant di Office 365 di valutazione con connettività da e verso la subnet di prova e includere tutti i servizi in ingresso e in uscita da usare nella produzione nella subnet di prova. Configurare il DNS per il segmento di rete di test e stabilire tutti i servizi in ingresso e in uscita. Eseguire il piano di test e verificare che si abbia familiarità con il routing per ogni servizio e con la propagazione del percorso.

Dopo avere completato gli elementi descritti in precedenza, spuntare le aree completate e assicurarsi assieme al proprio team che siano state prese in esame prima di eseguire i piani di distribuzione e test.

  • Elenco dei servizi in ingresso e in uscita implicati nella modifica di rete.

  • Diagramma di architettura di rete globale con punto di uscita Internet e località di peering di ExpressRoute.

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

  • Piano di distribuzione con i passaggi per implementare le modifiche e il rollback, se necessario.

  • Piano di test per verificare ogni servizio Office 365 e di rete.

  • Convalida cartacea completata dei percorsi di produzione per i servizi in ingresso e in uscita.

  • Test completato attraverso un segmento di rete di prova inclusa la verifica della disponibilità.

Scegliere una finestra di interruzione che sia abbastanza lunga da essere eseguire attraverso l'intero piano di distribuzione intera e piano di test, con tempo disponibile per la risoluzione dei problemi e per l'eventuale rollback.

Avviso : A causa della natura complessa del routing via Internet ed ExpressRoute, è consigliabile aggiungere un ulteriore tempo di buffer a questa finestra per gestire la risoluzione dei problemi di routing complesso.

QoS è necessario per ottenere vantaggi in termini di voce e riunioni per Skype for Business online. È possibile configurare QoS dopo aver verificato che la connessione di rete di ExpressRoute non impedirà l'accesso a nessun altro servizio di Office 365. La configurazione per QoS è descritta nell'articolo ExpressRoute e QoS in Skype for Business Online.

Risoluzione dei problemi di implementazione

Il primo posto in cui guardare è la procedura in questa Guida all'implementazione. Sono stati ignorati eventuali passaggi del piano di implementazione? Tornare indietro e, se possibile, eseguire ulteriori test di rete per replicare l'errore ed eseguire il debug.

Identificare quali servizi in ingresso o in uscita hanno prodotto un errore durante il test. Ottenere specificamente gli indirizzi IP e le subnet per ognuno dei servizi non riusciti. Continuare a seguire il diagramma della topologia di rete su carta e convalidare il routing. Verificare in particolare dove viene annunciato il routing di ExpressRoute e testare il routing durante il periodo di inattività, se possibile con tracce.

Eseguire PSPing con una traccia di rete per ogni endpoint dei clienti e valutare gli indirizzi IP di origine e destinazione per convalidare la come previsto. Eseguire telnet a qualsiasi host di posta elettronica che espongono sulla porta 25 e verificare che SNAT è nascondere l'indirizzo IP di origine originale, se è previsto.

Tenere presente che, durante la distribuzione di Office 365 con una connessione ExpressRoute, è necessario assicurarsi che la configurazione di rete per ExpressRoute sia stata progettato in modo ottimale e di aver ottimizzato anche gli altri componenti della rete, ad esempio i computer client. Oltre a questa Guida alla pianificazione per la risoluzione dei passaggi ignorati, è disponibile anche un Piano di risoluzione dei problemi di prestazioni per Office 365.

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

Argomenti correlati

Connettività a Office 365 di rete
Azure ExpressRoute per Office 365
Gestione ExpressRoute per Office 365 connettività
Routing con ExpressRoute per Office 365
pianificazione della rete con ExpressRoute per Office 365
Comunità utilizzando BGP ExpressRoute per gli scenari di Office 365 (preview)
qualità Media e le prestazioni di connettività di rete in Skype for Business Online
ottimizzare la rete per Skype for Business Online
ExpressRoute e QoS in Skype for Business Online
chiamata flusso usando ExpressRoute
ottimizzazione delle prestazioni di Office 365 con le previsioni e la cronologia delle prestazioni
prestazioni risoluzione dei problemi per Office 365 piano
URL di Office 365 e intervalli di indirizzi IP
Office 365 rete e ottimizzazione delle prestazioni

Nota : Dichiarazione di non responsabilità per la traduzione automatica: Il presente articolo è stato tradotto tramite un software di traduzione automatica e non da una persona. Microsoft offre le traduzioni automatiche per consentire a coloro che non conoscono la lingua inglese di leggere gli articoli sui prodotti, sui servizi e sulle tecnologie Microsoft. Dal momento che l'articolo è stato tradotto automaticamente, potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli.

Amplia le tue competenze
Esplora i corsi di formazione
Ottieni in anticipo le nuove caratteristiche
Partecipa al programma Office Insider

Queste informazioni sono risultate utili?

Grazie per i tuoi commenti e suggerimenti

Grazie per il tuo feedback! Potrebbe essere utile metterti in contatto con uno dei nostri operatori del supporto di Office.

×