實作適用於 Microsoft 365 的 ExpressRoute
本文適用於 Microsoft 365 企業版。
ExpressRoute for Microsoft 365 提供許多因特網對向 Microsoft 365 服務的替代路由路徑。 適用於 Microsoft 365 的 ExpressRoute 架構是以 Microsoft 365 服務的公用 IP 前綴為基礎，這些服務已可透過因特網存取到您布建的 ExpressRoute 線路，以便後續將這些 IP 前綴轉散發到您的網路。 透過 ExpressRoute，您可以透過因特網和 ExpressRoute，有效地為許多 Microsoft 365 服務啟用數個不同的路由路徑。 網路上的這種路由狀態可能代表內部網路拓撲設計方式的重大變更。
注意事項
我們不建議使用適用於 Microsoft 365 的 ExpressRoute，因為它在大部分情況下不會為服務提供最佳的連線模型。 因此，需要 Microsoft 授權才能使用此連線模型。 我們只會在需要的罕見案例中檢閱每個客戶要求並授權適用於 Microsoft 365 的 ExpressRoute。 如需詳細資訊，請參閱 ExpressRoute for Microsoft 365 指南 ，並遵循與您的生產力、網路和安全性小組一起完整檢閱檔，並視需要與您的 Microsoft 帳戶小組合作提交例外狀況。 嘗試建立 Microsoft 365 路由篩選器的未經授權訂閱將會收到 錯誤訊息。
您必須仔細規劃 ExpressRoute for Microsoft 365 實作，以因應透過專用線路提供路由的網路複雜性，以及將路由插入核心網路和因特網的路由。 如果您和您的小組未執行本指南中的詳細規劃和測試，當 ExpressRoute 線路啟用時，您會遇到間歇性或完全中斷與 Microsoft 365 服務連線的高風險。
若要成功實作，您必須分析基礎結構需求、進行詳細的網路評估和設計、以分段和受控制的方式仔細規劃推出，以及建立詳細的驗證和測試計劃。 對於大型分散式環境，不常看到跨幾個月的實作。 本指南旨在協助您事先規劃。
大型成功部署可能需要六個月的規劃時間，而且通常包括組織中許多領域的小組成員，包括網路、防火牆和 Proxy 伺服器管理員、Microsoft 365 系統管理員、安全性、用戶支援、專案管理和主管贊助。 您對規劃程序的投資，可降低部署失敗導致停機或複雜且昂貴的疑難解答的可能性。
我們預期在開始本實作指南之前，必須先完成下列必要條件。
您已完成網路評估，以判斷是否建議並核准 ExpressRoute。
您已選取 ExpressRoute 網路服務提供者。 尋找 ExpressRoute 合作夥伴和對等互連位置的詳細數據。
您已經閱讀並瞭解 ExpressRoute 檔 ，而且您的內部網路能夠端對端符合 ExpressRoute 必要條件。
您的小組已閱讀 、 的所有公開指引和檔https://aka.ms/expressrouteoffice365https://aka.ms/ert，並觀看 Channel 9 上的 Azure ExpressRoute for Microsoft 365 訓練系列，以瞭解重要的技術詳細數據，包括：
SaaS 服務的因特網相依性。
如何避免非對稱路由和處理複雜的路由。
如何納入周邊安全性、可用性和應用層級控件。
從收集需求開始
首先，判斷您打算在組織內採用哪些功能和服務。 您必須判斷將使用不同 Microsoft 365 服務的哪些功能，以及您網路上的哪些位置會裝載使用這些功能的人員。 使用案例目錄時，您必須新增每個案例所需的網路屬性;例如輸入和輸出網路流量，以及 Microsoft 365 端點是否可透過 ExpressRoute 使用。
若要收集貴組織的需求：
為貴組織所使用的 Microsoft 365 服務編目輸入和輸出網路流量。 如需不同 Microsoft 365 案例所需的流程描述，請參閱 Microsoft 365 URL 和 IP 位址範圍頁面。
收集現有網路拓撲的檔，其中顯示內部 WAN 骨幹和拓撲的詳細數據、衛星月臺的連線能力、最後一公里用戶連線能力、路由傳送至網路周邊輸出點，以及 Proxy 服務。
在 Microsoft 365 和其他 Microsoft 服務將連線的網路圖上識別輸入服務端點，其中顯示因特網和建議的 ExpressRoute 連線路徑。
識別位置之間的所有地理使用者位置和 WAN 連線能力，以及哪些位置目前具有因特網的輸出，以及建議要輸出至 ExpressRoute 對等互連位置的位置。
識別所有邊緣裝置，例如 Proxy、防火牆等，並將其與流經因特網和 ExpressRoute 的流程關聯性編目。
記載終端使用者是否會透過直接路由或因特網和 ExpressRoute 流程的間接應用程式 Proxy 存取 Microsoft 365 服務。
將租使用者的位置和 meet-me 位置新增至您的網路圖。
估計從主要使用者位置到 Microsoft 365 的預期和觀察到的網路效能和延遲特性。 請記住，Microsoft 365 是一組全域且分散式的服務，使用者將會連線到與其租使用者位置不同的位置。 基於這個理由，建議您透過 ExpressRoute 和因特網連線，測量並優化使用者與 Microsoft 全球網路最接近邊緣之間的延遲。 您可以使用網路評量的結果來協助這項工作。
列出必須符合新 ExpressRoute 連線的公司網路安全性和高可用性需求。 例如，當因特網輸出或 ExpressRoute 線路失敗時，使用者如何繼續取得 Microsoft 365 的存取權。
記錄哪些輸入和輸出 Microsoft 365 網路流程將使用因特網路徑，以及哪些路徑將使用 ExpressRoute。 使用者的地理位置細節和內部部署網路拓撲的詳細數據，可能需要將方案與另一個使用者位置不同。
編目您的輸出和輸入網路流量
若要將路由和其他網路複雜性降至最低，建議您只針對因法規需求或網路評量而需要通過專用連線的網路流量，使用 ExpressRoute for Microsoft 365。 此外，我們建議您暫存 ExpressRoute 路由的範圍，並將輸出和輸入網路流量作為實作專案的不同階段來處理。 僅針對使用者起始的輸出網路流量流程部署 ExpressRoute for Microsoft 365，並讓輸入網路流量流經因特網，有助於控制拓撲複雜度增加，以及引進其他非對稱式路由可能性的風險。
您的網路流量目錄應該包含內部部署網路與 Microsoft 之間所有輸入和輸出網路連線的清單。
輸出網路流量是從內部部署環境起始連線的任何案例，例如從內部用戶端或伺服器起始連線，並具有 Microsoft 服務的目的地。 這些連線可能會直接連線到 Microsoft 365 或間接連線，例如當連線通過 Microsoft 365 路徑上的 Proxy 伺服器、防火牆或其他網路裝置時。
輸入網路流量是從 Microsoft 雲端到內部部署主機起始連線的任何案例。 這些連線通常需要通過防火牆，以及客戶安全策略針對外部來源流程所需的其他安全性基礎結構。
請閱讀確保路由對稱一節，以判斷哪些服務會傳送輸入流量，並在 Microsoft 365 端點參考文章中尋找標示為 ExpressRoute for Microsoft 365 的數據行，以判斷其餘的聯機資訊。
針對每個需要輸出連線的服務，您會想要描述服務的計劃性連線，包括網路路由、Proxy 設定、封包檢查和頻寬需求。
對於需要輸入連線的每個服務，您將需要一些額外的資訊。 Microsoft 雲端中的伺服器會建立與內部部署網路的連線。 若要確保連線正確，您會想要描述此聯機的所有層面，包括;將接受這些輸入連線之服務的公用 DNS 專案、CIDR 格式化的 IPv4 IP 位址、涉及的 ISP 設備，以及如何處理這些連線的輸入 NAT 或來源 NAT。
不論輸入連線是透過因特網還是 ExpressRoute 連線，都應該檢閱輸入連線，以確保未引入非對稱式路由。 在某些情況下，Microsoft 365 服務起始輸入連線的內部部署端點可能也需要由其他 Microsoft 和非 Microsoft 服務存取。 為 Microsoft 365 目的啟用這些服務的 ExpressRoute 路由，並不會中斷其他案例，這是最重要的。 在許多情況下，客戶可能需要實作其內部網路的特定變更，例如來源型 NAT，以確保在啟用 ExpressRoute 之後，來自 Microsoft 的輸入流程保持對稱。
以下是所需詳細數據層級的範例。 在此情況下，Exchange Hybrid 會透過 ExpressRoute 路由傳送至內部部署系統。
| Connection 屬性 | 值 |
|---|---|
| 網路流量方向 |
入境 |
| 服務 |
Exchange 混合式 |
| 公用 Microsoft 365 端點 (來源) |
Exchange Online (IP位址) |
| 公用內部部署端點 (目的地) |
5.5.5.5 |
| 公用 (因特網) DNS 專案 |
Autodiscover.contoso.com |
| 此內部部署端點是否會由其他非 Microsoft 365) Microsoft 服務 (使用 |
否 |
| 此內部部署端點是否會由因特網上的使用者/系統使用 |
是 |
| 透過公用端點發佈的內部系統 |
Exchange Server 內部部署) 192.168.101、192.168.102、192.168.103 (用戶端存取角色 |
| 公用端點的IP公告 |
至因特網：5.5.0.0/16 至 ExpressRoute：5.5.5.0/24 |
| 安全性/周邊控件 |
因特網路徑:D eviceID_002 ExpressRoute 路徑:D eviceID_003 |
| 高可用性 |
跨 2 個異地備援/ExpressRoute 線路的作用中/作用中 - 芝加哥和達拉斯 |
| 路徑對稱控件 |
方法：來源 NAT 因特網路徑：192.168.5.5 ExpressRoute 路徑的來源 NAT 輸入連線：192.168.1.0 (芝加哥) 和 192.168.2.0 (達拉斯) |
以下是僅輸出的服務範例：
| Connection 屬性 | 值 |
|---|---|
| 網路流量方向 |
出埠 |
| 服務 |
SharePoint |
| 內部部署端點 (來源) |
使用者工作站 |
| 公用 Microsoft 365 端點 (目的地) |
SharePoint (IP 位址) |
| 公用 (因特網) DNS 專案 |
*.sharepoint.com (和更多 FQDN) |
| CDN 轉介 |
cdn.sharepointonline.com (和更多 FQDN) - CDN 提供者所維護的 IP 位址) |
| 使用中的IP公告和NAT |
因特網路徑/來源 NAT：1.1.1.0/24 ExpressRoute 路徑/來源 NAT：1.1.2.0/24 (芝加哥) 和 1.1.3.0/24 (達拉斯) |
| 線上方法 |
因特網：透過第 7 層 proxy (.pac 檔案) ExpressRoute：直接路由 (沒有 Proxy) |
| 安全性/周邊控件 |
因特網路徑:D eviceID_002 ExpressRoute 路徑:D eviceID_003 |
| 高可用性 |
因特網路徑：備援因特網輸出 ExpressRoute 路徑：跨 2 個異地備援 ExpressRoute 線路的主動/作用中「熱馬達」路由 - 芝加哥和達拉斯 |
| 路徑對稱控件 |
方法：所有連線的來源 NAT |
具有區域連線能力的網路拓撲設計
一旦您了解服務及其相關聯的網路流量，您可以建立包含這些新連線需求的網路圖，並說明您將針對 Microsoft 365 使用 ExpressRoute 所做的變更。 您的圖表應該包括：
將存取 Microsoft 365 和其他服務的所有使用者位置。
所有因特網和 ExpressRoute 輸出點。
所有可管理網路進出連線能力的輸出和輸入裝置，包括路由器、防火牆、應用程式 Proxy 伺服器，以及入侵偵測/預防。
所有輸入流量的內部目的地，例如接受來自ADFS Web應用程式 Proxy 伺服器連線的內部ADFS伺服器。
將公告的所有IP子網目錄
識別人員從中存取 Microsoft 365 的每個位置，並列出將用於 ExpressRoute 的 Meet-me 位置。
內部網路拓撲的位置和部分，將會接受、篩選及傳播從 ExpressRoute 學習的 Microsoft IP 前置詞。
網路拓撲應該說明每個網路區段的地理位置，以及它如何透過ExpressRoute和/或因特網連線到 Microsoft 網路。
下圖顯示使用者將使用 Microsoft 365 的每個位置，以及 Microsoft 365 的輸入和輸出路由通告。
針對輸出流量，人員會透過下列三種方式之一來存取 Microsoft 365：
透過加州 北美洲 中的 [與我開會] 位置。
透過香港特別行政區人員在香港特別行政區的開會地點。
透過孟加拉國的因特網，這裡的人數較少，而且沒有布建 ExpressRoute 線路。
同樣地，來自 Microsoft 365 的輸入網路流量會以三種方式之一傳回：
透過加州 北美洲 中的 [與我開會] 位置。
透過香港特別行政區人員在香港特別行政區的開會地點。
透過孟加拉國的因特網，這裡的人數較少，而且沒有布建 ExpressRoute 線路。
判斷適當的與我相符的位置
選取的 meet-me 位置是 ExpressRoute 線路將您的網路連線到 Microsoft 網路的實體位置，會受到人員從中存取 Microsoft 365 的位置影響。 作為 SaaS 供應專案，Microsoft 365 不會以 Azure 的相同方式在 IaaS 或 PaaS 區域模型下運作。 相反地，Microsoft 365 是一組分散式的共同作業服務，使用者可能需要連線到跨多個數據中心和區域的端點，這些端點不一定位於裝載使用者租使用者的相同位置或區域。
這表示在選取 ExpressRoute for Microsoft 365 的 Meet-me 位置時，您需要做的最重要考慮，就是組織中的人員將從中連線的位置。 最佳 Microsoft 365 連線能力的一般建議是實作路由，讓使用者對 Microsoft 365 服務的要求透過最短的網路路徑傳遞至 Microsoft 網路，這通常也稱為「熱馬達」路由。 例如，如果大部分的 Microsoft 365 用戶位於一或兩個位置，則選取最接近這些使用者位置的 meet-me 位置，將會建立最佳的設計。 如果您的公司在許多不同的區域中有大量的使用者，您可能會想要考慮擁有多個 ExpressRoute 線路和 meet-me 位置。 針對某些使用者位置，進入 Microsoft 網路和 Microsoft 365 的最短/最理想路徑可能不是透過內部 WAN 和 ExpressRoute meet-me 點，而是透過因特網。
通常，在用戶相對鄰近的區域內，可以選取多個 meet-me 位置。 填寫下表以引導您的決策。
加州和紐約規劃的 ExpressRoute Meet-me 位置
| 位置 |
人數 |
透過因特網輸出對 Microsoft 網路的預期延遲 |
透過 ExpressRoute 對 Microsoft 網路的預期延遲 |
|---|---|---|---|
| Los Angeles |
10,000 |
~15ms |
~10ms (透過矽谷) |
| 華盛頓 |
15,000 |
~20ms |
~10ms (透過紐約) |
| 達拉斯 |
5,000 |
~15ms |
~40ms (透過紐約) |
一旦顯示 Microsoft 365 區域、ExpressRoute 網路服務提供者符合我位置的全域網路架構，以及依位置開發的人員數量，就可以用來識別是否可以進行任何優化。 它也可能顯示全域固定網路連線，其中流量會路由傳送至遠距位置，以取得meet-me位置。 如果探索到全域網路上的圖釘，則應該先進行補救再繼續。 請尋找另一個符合我的位置，或使用選擇性的因特網分隔輸出點來避免髮夾。
第一個圖表顯示客戶在 北美洲 中具有兩個實體位置的範例。 您可以查看辦公室位置、Microsoft 365 租使用者位置的相關信息，以及 ExpressRoute Meet-me 位置的數個選擇。 在此範例中，客戶已根據下列兩個原則選取meet-me位置：
最接近組織中的人員。
最接近裝載 Microsoft 365 的 Microsoft 數據中心。
稍微進一步擴展此概念，第二個圖表顯示面臨類似資訊和決策的多國客戶範例。 此客戶在孟加拉國有一個小型辦公室，只有一小組 10 人專注於拓展其在該區域中的使用量。 在Chennai 中有一個與我開會的位置，以及在Chennai 中裝載 Microsoft 365 的 Microsoft 數據中心，因此與我開會的位置是合理的;不過，對於 10 個人而言，額外線路的費用是很麻煩的。 當您查看網路時，您必須判斷透過網路傳送網路流量所涉及的延遲是否比花費資本來取得另一個 ExpressRoute 線路更有效率。
或者，孟加拉國的 10 個人透過因特網傳送至 Microsoft 網路的網路流量，可能會比在內部網路上路由傳送的網路流量效能更好，如我們在簡介圖表中所示，如下所示。
Create 適用於 Microsoft 365 的 ExpressRoute 實作計畫
您的實作計劃應該包含設定 ExpressRoute 的技術詳細數據，以及在網路上設定所有其他基礎結構的詳細數據，如下所示。
規劃在 ExpressRoute 和因特網之間分割哪些服務。
規劃頻寬、安全性、高可用性和故障轉移。
設計輸入和輸出路由，包括針對不同位置的適當路由路徑優化
決定將 ExpressRoute 路由通告至您網路的程度，以及客戶端選取因特網或 ExpressRoute 路徑的機制為何;例如，直接路由或應用程式 Proxy。
規劃 DNS 記錄變更，包括 寄件者原則架構 專案。
規劃 NAT 策略，包括輸出和輸入來源 NAT。
使用因特網和 ExpressRoute 網路路徑規劃路由
針對初始部署，建議使用因特網的所有輸入服務，例如輸入電子郵件或混合式連線。
規劃使用者用戶端 LAN 路由，例如 設定 PAC/WPAD 檔案、預設路由、Proxy 伺服器和 BGP 路由通告。
規劃周邊路由，包括 Proxy 伺服器、防火牆和雲端 Proxy。
規劃頻寬、安全性、高可用性和故障轉移
Create 每個主要 Microsoft 365 工作負載所需的頻寬計劃。 個別估計 Exchange Online、SharePoint 和 商務用 Skype Online 頻寬需求。 您可以使用我們為 Exchange Online 和 商務用 Skype 提供的估計計算機作為起點;不過，需要有具代表性的使用者配置檔和位置範例的試驗測試，才能完全了解組織的頻寬需求。
將每個因特網和 ExpressRoute 輸出位置的安全性處理方式新增至您的計劃、記住所有與 Microsoft 365 的 ExpressRoute 連線都使用公用對等互連，而且仍然必須根據公司連線到外部網路的安全策略來保護。
將詳細數據新增至您的計劃，以瞭解哪些人會受到何種類型的中斷影響，以及這些人員如何以最簡單的方式以完整容量執行工作。
規劃頻寬需求，包括對 Jitter、延遲、壅塞和空房的 商務用 Skype 需求
商務用 Skype Online 也有特定的額外網路需求，如 商務用 Skype Online 中的媒體品質和網路連線效能一文所詳述。
閱讀 Azure ExpressRoute 的頻寬規劃一節。 與試驗使用者一起執行頻寬評估時，您可以使用我們的指南 Microsoft 365 效能微調，使用基準和效能歷程記錄。
規劃高可用性需求
Create 高可用性方案以符合您的需求，並將此方案納入更新的網路拓撲圖表中。 閱讀使用 Azure ExpressRoute 的高可用性和故障轉移一節。
規劃網路安全性需求
Create 符合網路安全性需求的計劃，並將其納入更新的網路拓撲圖表中。 請閱讀將 安全性控件套用至適用於 Microsoft 365 案例的 Azure ExpressRoute 一節。
設計輸出服務連線能力
ExpressRoute for Microsoft 365 具有可能不熟悉的 輸出 網路需求。 具體而言，代表您使用者和 Microsoft 365 網路並作為 Microsoft 輸出網路連線來源端點的 IP 位址，必須遵循以下所述的特定需求。
端點必須是向貴公司或提供 ExpressRoute 連線能力的電信業者註冊的公用 IP 位址。
端點必須公告給 Microsoft，並由 ExpressRoute 驗證/接受。
端點不得通告至具有相同或更慣用路由計量的因特網。
端點不能用於連線到未透過 ExpressRoute 設定的 Microsoft 服務。
如果您的網路設計不符合這些需求，您的用戶會因為路由黑色全像或非對稱式路由而發生連線失敗至 Microsoft 365 和其他 Microsoft 服務的高風險。 當 Microsoft 服務的要求是透過 ExpressRoute 路由傳送，但回應會透過因特網路由傳回，反之亦然，而且回應是由防火牆等具狀態網路裝置捨棄時發生。
您可以用來符合上述需求的最常見方法是使用來源 NAT，這會實作為網路的一部分，或由 ExpressRoute 貨運公司提供。 來源 NAT 可讓您從 ExpressRoute 和 擷取因特網網路的詳細數據和私人 IP 位址;結合適當的IP路由通告，提供簡單的機制來確保路徑對稱。 如果您使用 ExpressRoute 對等互連位置專屬的具狀態網路裝置，您必須為每個 ExpressRoute 對等互連實作個別的 NAT 集區，以確保路徑對稱。
深入瞭解 ExpressRoute NAT 需求。
將輸出連線的變更新增至網路拓撲圖表。
設計輸入服務連線能力
大部分的企業 Microsoft 365 部署都假設某種形式的輸入連線從 Microsoft 365 連線到內部部署服務，例如 Exchange、SharePoint，以及使用 ADFS 基礎結構 商務用 Skype 混合式案例、信箱移轉和驗證。 當 ExpressRoute 您針對輸出連線啟用內部部署網路與 Microsoft 之間的額外路由路徑時，即使您想要讓這些流程繼續使用因特網，這些輸入連線也可能不小心受到非對稱式路由的影響。 建議您採取以下幾個預防措施，以確保不會影響從 Microsoft 365 到內部部署系統的因特網型輸入流程。
若要將輸入網路流量的非對稱式路由風險降到最低，所有輸入連線都應該先使用來源 NAT，再路由傳送至您網路的區段，而這些區段具有 ExpressRoute 的路由可見度。 如果允許連入連線進入具有 ExpressRoute 路由可見度且不含來源 NAT 的網路區段，則源自 Microsoft 365 的要求會從因特網輸入，但回到 Microsoft 365 的回應會偏好將 ExpressRoute 網路路徑送回 Microsoft 網路，因而導致非對稱式路由。
您可以考慮下列其中一個實作模式來滿足此需求：
在要求從因特網到內部部署系統的路徑上使用防火牆或負載平衡器等網路設備路由傳送至內部網路之前，請先執行來源 NAT。
請確定 ExpressRoute 路由不會傳播至輸入服務所在的網路區段，例如前端伺服器或反向 Proxy 系統，處理因特網連線。
明確考慮您網路中的這些案例，並讓所有輸入網路流量透過因特網保持流動，有助於將非對稱式路由的部署和作業風險降至最低。
在某些情況下，您可能會選擇透過 ExpressRoute 連線來導向一些輸入流程。 針對這些案例，請考慮下列額外考慮。
Microsoft 365 只能以使用公用IP的內部部署端點為目標。 這表示即使內部部署輸入端點只透過 ExpressRoute 公開給 Microsoft 365，仍然需要有與其相關聯的公用 IP。
Microsoft 365 服務執行以解析內部部署端點的所有 DNS 名稱解析都會使用公用 DNS 來進行。 這表示您必須向因特網上的IP對應註冊輸入服務端點的 FQDN。
若要透過 ExpressRoute 接收輸入網路連線，必須透過 ExpressRoute 向 Microsoft 公告這些端點的公用 IP 子網。
仔細評估這些輸入網路流量，以確保根據公司的安全性和網路原則，將適當的安全性和網路控制套用至這些流量。
透過 ExpressRoute 向 Microsoft 公告內部部署輸入端點之後，ExpressRoute 將會有效地成為所有 Microsoft 服務的慣用路由路徑，包括 Microsoft 365。 這表示這些端點子網只能用於與 Microsoft 365 服務的通訊，且 Microsoft 網路上沒有其他服務。 否則，您的設計會導致非對稱式路由，其中來自其他 Microsoft 服務的輸入連線偏好透過 ExpressRoute 路由傳入，而傳回路徑會使用因特網。
如果 ExpressRoute 線路或 meet-me 位置關閉，您必須確保內部部署輸入端點仍可透過個別網路路徑接受要求。 這可能表示透過多個 ExpressRoute 線路為這些端點公告子網。
建議您針對透過 ExpressRoute 進入網路的所有輸入網路流量套用來源 NAT，特別是當這些流量跨越防火牆等具狀態網路裝置時。
某些內部部署服務，例如 ADFS Proxy 或 Exchange 自動探索，可能會收到來自 Microsoft 365 服務和因特網用戶的輸入要求。 針對這些要求，Microsoft 365 會以與透過因特網的使用者要求相同的 FQDN 為目標。 允許從因特網到這些內部部署端點的輸入用戶連線，同時強制 Microsoft 365 連線使用 ExpressRoute，代表明顯的路由複雜度。 針對大部分透過 ExpressRoute 實作這類複雜案例的客戶，由於作業考慮，不建議使用。 這個額外的額外負荷包括管理非對稱式路由的風險，而且需要您仔細管理跨多個維度的路由通告和原則。
更新您的網路拓撲計劃，以顯示如何避免非對稱式路由
您想要避免非對稱式路由，以確保組織中的人員可以順暢地使用 Microsoft 365 以及因特網上的其他重要服務。 客戶有兩個常見的組態會造成非對稱式路由。 現在是檢閱您打算使用的網路組態的好時機，並檢查這些非對稱式路由案例是否存在。
首先，我們將檢查一些與下列網路圖相關聯的不同情況。 在此圖表中，所有接收輸入要求的伺服器，例如 ADFS 或內部部署混合式伺服器，都會位於 New 階數據中心，並通告至因特網。
雖然周邊網路是安全的，但傳入要求沒有可用的來源 NAT。
新澤西島數據中心的伺服器可以同時查看因特網和 ExpressRoute 路由。
我們也有如何修正它們的建議。
問題 1：透過因特網的雲端到內部部署連線
下圖說明當您的網路設定未透過因特網為來自 Microsoft 雲端的輸入要求提供 NAT 時所採取的非對稱網路路徑。
來自 Microsoft 365 的輸入要求會從公用 DNS 擷取內部部署端點的IP位址，並將要求傳送至周邊網路。
在此錯誤的設定中，傳送流量的周邊網路上沒有設定或可用的來源 NAT，因此實際的來源 IP 位址會作為傳回目的地。
您網路上的伺服器會透過任何可用的 ExpressRoute 網路連線，將傳回流量路由傳送至 Microsoft 365。
結果是該流向 Microsoft 365 的非對稱路徑，導致連線中斷。
解決方案 1a：來源 NAT
只要將來源 NAT 新增至輸入要求，就能解決這個設定錯誤的網路。 在此圖表中：
傳入要求會繼續透過新加西島資料中心的周邊網路輸入。 這次可以使用來源 NAT。
來自伺服器的回應會路由傳回與來源 NAT 相關聯的 IP，而不是原始 IP 位址，導致回應沿著相同的網路路徑傳回。
解決方案1b：路由範圍界定
或者，您可以選擇不允許公告 ExpressRoute BGP 前置詞，並移除這些計算機的替代網路路徑。 在此圖表中：
傳入要求會繼續透過新加西島資料中心的周邊網路輸入。 這一次，從 Microsoft 透過 ExpressRoute 線路公告的前置詞無法提供給 New 階加索引資料中心使用。
伺服器的回應會透過唯一可用的路由傳回與原始IP位址相關聯的IP，導致回應沿著相同的網路路徑傳回。
問題 2：透過 ExpressRoute 的雲端到內部部署連線
下圖說明當您的網路設定未透過 ExpressRoute 為來自 Microsoft 雲端的輸入要求提供 NAT 時所採取的非對稱網路路徑。
來自 Microsoft 365 的輸入要求會從 DNS 擷取 IP 位址，並將要求傳送至周邊網路。
在此錯誤的設定中，傳送流量的周邊網路上沒有設定或可用的來源 NAT，因此實際的來源 IP 位址會作為傳回目的地。
您網路上的計算機會透過任何可用的 ExpressRoute 網路連線，將傳回流量路由傳送至 Microsoft 365。
結果是與 Microsoft 365 的非對稱連線。
解決方案 2：來源 NAT
只要將來源 NAT 新增至輸入要求，就能解決這個設定錯誤的網路。 在此圖表中：
傳入要求會繼續透過紐約資料中心的周邊網路輸入。 這次可以使用來源 NAT。
來自伺服器的回應會路由傳回與來源 NAT 相關聯的 IP，而不是原始 IP 位址，導致回應沿著相同的網路路徑傳回。
紙張確認網路設計具有路徑對稱
此時，您需要在文件上確認您的實作計劃針對您將使用 Microsoft 365 的不同案例提供路由對稱。 您將識別當人員使用服務的不同功能時，預期會採用的特定網路路由。 從內部部署網路和WAN路由，到周邊裝置，到連線路徑;ExpressRoute 或因特網，以及連線到在線端點。
您必須針對先前識別為貴組織將採用之服務的所有 Microsoft 365 網路服務執行此動作。
這有助於逐步解說與第二人稱的路線。 向他們說明每個網路躍點應該從何處取得其下一個路由，並確保您熟悉路由路徑。 請記住，ExpressRoute 一律會提供更限定範圍的路由給 Microsoft 伺服器 IP 位址，使其比因特網預設路由更低的路由成本。
設計用戶端聯機組態
如果您針對因特網系結的流量使用 Proxy 伺服器，則必須調整任何 PAC 或用戶端組態檔，以確保網路上的用戶端計算機已正確設定為將您想要的 ExpressRoute 流量傳送至 Microsoft 365，而不需要傳輸您的 Proxy 伺服器，而剩餘的流量，包括某些 Microsoft 365 流量，會傳送至相關的 Proxy。 閱讀管理 Microsoft 365 端點的指南，例如 PAC 檔案。
注意事項
端點會經常變更，頻率與每周一樣。 您應該只根據貴組織所採用的服務和功能進行變更，以減少您需要進行變更以維持最新狀態的數目。 請密切注意 RSS 摘要中的 生效日期 ，其中會公告變更，並保留所有過去變更的記錄、公告的 IP 位址，或從公告中移除，直到達到生效日期為止。
確保路由對稱
Microsoft 365 前端伺服器可在因特網和 ExpressRoute 上存取。 當兩者都可用時，這些伺服器會偏好透過 ExpressRoute 線路路由回到內部部署。 因此，如果來自網路的流量偏好透過因特網線路路由傳送，可能會有路由非對稱。 非對稱式路由是一個問題，因為執行具狀態封包檢查的裝置可以封鎖與所遵循輸出封包不同路徑之後的傳回流量。
不論您是透過因特網還是 ExpressRoute 起始與 Microsoft 365 的連線，來源都必須是可公開路由傳送的位址。 由於有許多客戶直接與 Microsoft 對等互連，因此在客戶之間有可能會重複的私人位址是不可行的。
以下是將起始從 Microsoft 365 到內部部署網路的通訊案例。 為了簡化您的網路設計，建議您透過因特網路徑路由傳送下列專案。
SMTP 服務，例如從 Exchange Online 租用戶傳送至內部部署主機的郵件，或從 SharePoint 傳送至內部部署主機的 SharePoint Mail。 SMTP 通訊協定在 Microsoft 網路中的使用範圍比透過 ExpressRoute 線路共用的路由前綴更廣泛，而透過 ExpressRoute 公告內部部署 SMTP 伺服器會導致這些其他服務失敗。
用於登入的密碼驗證期間的ADFS。
若要讓 Microsoft 針對這些雙向流量路由回到您的網路，必須與 Microsoft 共用內部部署裝置的 BGP 路由。 當您透過 ExpressRoute 向 Microsoft 公告路由前綴時，您應該遵循下列最佳做法：
請勿將相同的公用IP位址路由前綴通告至公用因特網和ExpressRoute。 建議透過 ExpressRoute 將 IP BGP 路由前綴通告發佈至 Microsoft，範圍完全不會通告至因特網。 如果因為可用的IP位址空間而無法達成此目的，請務必確保您透過ExpressRoute通告比任何因特網線路更特定的範圍。
針對每個 ExpressRoute 線路使用個別的 NAT IP 集區，並個別使用因特網線路的 NAT IP 集區。
任何通告給 Microsoft 的路由都會吸引來自 Microsoft 網路中任何伺服器的網路流量，而不只是透過 ExpressRoute 向您的網路公告路由的網路流量。 只公告路由傳送至您的小組已定義並充分瞭解路由案例的伺服器。 在網路的多個 ExpressRoute 線路中，公告個別的 IP 位址路由前綴。
使用 Azure ExpressRoute 的高可用性和故障轉移
建議您使用 ExpressRoute 將每個輸出至少布建兩個使用中線路給 ExpressRoute 提供者。 這是我們看到客戶失敗的最常見位置，您可以布建一對作用中/使用中的 ExpressRoute 線路，輕鬆避免發生此問題。 我們也建議至少使用兩個作用中/作用中的因特網線路，因為許多 Microsoft 365 服務只能透過因特網使用。
在網路的輸出點內，還有許多其他裝置和線路，這些裝置和線路在人們感知可用性方面扮演著重要的角色。 ExpressRoute 或 Microsoft 365 SLA 並未涵蓋這些部分的連線案例，但它們在組織中人員所察覺的端對端服務可用性中扮演重要角色。
將焦點放在使用和操作 Microsoft 365 的人員，如果任何一個元件的失敗都會影響使用服務的年長體驗，請尋找方法來限制受影響的人員總數百分比。 如果故障轉移模式在操作上很複雜，請考慮長期復原的年長經驗，並尋找操作上簡單且自動化的故障轉移模式。
在您的網路外部，Microsoft 365、ExpressRoute 和 ExpressRoute 提供者都有不同層級的可用性。
服務可用性
Microsoft 365 服務涵蓋在妥善定義 的服務等級協定中，其中包括個別服務的運行時間和可用性計量。 Microsoft 365 能夠維持如此高的服務可用性層級，其中一個原因是個別元件能夠使用全域 Microsoft 網路，在許多 Microsoft 數據中心之間順暢地進行故障轉移。 此故障轉移會從數據中心和網路延伸到多個因特網輸出點，並從使用服務的人員的觀點順暢地啟用故障轉移。
ExpressRoute 在 Microsoft Network Edge 與 ExpressRoute 提供者或合作夥伴基礎結構之間的個別專用線路上 提供 99.9% 的可用性 SLA 。 這些服務等級會套用在 ExpressRoute 線路層級，其中包含備援 Microsoft 設備與每個對等互連位置中網路提供者設備之間的 兩個獨立互連 。
提供者可用性
- Microsoft 的服務等級安排會在您的 ExpressRoute 提供者或合作夥伴停止。 這也是您可以做出會影響可用性層級之選擇的第一個位置。 您應該仔細評估 ExpressRoute 提供者在網路周邊與每個 Microsoft 對等互連位置的提供者連線之間所提供的架構、可用性和復原特性。 請密切注意備援的邏輯和實體層面、對等互連設備、貨運公司提供的WAN線路，以及任何額外的價值新增服務，例如NAT服務或受控防火牆。
設計可用性方案
強烈建議您針對 Microsoft 365 的端對端連線案例規劃及設計高可用性和復原能力。 設計應包含;
沒有單一失敗點，包括因特網和 ExpressRoute 線路。
將受影響人數和影響最預期失敗模式的持續時間降至最低。
從大部分預期的失敗模式優化簡單、可重複和自動復原程式。
透過備援路徑支持網路流量和功能的完整需求，而不會大幅降低。
您的連線案例應該包含針對 Microsoft 365 的多個獨立和作用中網路路徑優化的網路拓撲。 這會產生比僅針對個別裝置或設備層級備援優化的拓撲更好的端對端可用性。
提示
如果您的使用者分散於多個大陸或地理區域，而且每個位置都會透過備援 WAN 線路連線到單一 ExpressRoute 線路所在的單一內部部署位置，則您的使用者會遇到比網路拓撲設計更少的端對端服務可用性，該設計包含將不同區域連線到最接近對等互連位置的獨立 ExpressRoute 線路。
我們建議您布建至少兩個 ExpressRoute 線路，每個線路都會以不同的地理對等互連位置連線到。 您應該為使用者將針對 Microsoft 365 服務使用 ExpressRoute 連線的每個區域布建這組主動-主動線路。 這可讓每個區域在影響主要位置的災害期間保持連線，例如數據中心或對等互連位置。 將它們設定為作用中/作用中，可讓終端使用者流量分散到多個網路路徑。 這可減少裝置或網路設備中斷期間受影響的人員範圍。
我們不建議使用單一 ExpressRoute 線路搭配因特網作為備份。
範例：故障轉移和高可用性
Contoso 的多地理設計已經過路由、帶寬、安全性的檢閱，現在必須經過高可用性檢閱。 Contoso 將高可用性視為涵蓋三個類別;復原、可靠性和備援。
復原可讓 Contoso 快速從失敗中復原。 可靠性可讓 Contoso 在系統內提供一致的結果。 備援可讓 Contoso 在基礎結構的一或多個鏡像實例之間移動。
在每個邊緣設定中，Contoso 都有備援防火牆、Proxy 和 IDS。 針對 北美洲，Contoso 在其達拉斯數據中心有一個邊緣組態，在其維吉尼亞州數據中心有另一個邊緣設定。 每個位置的備援設備都提供該位置的復原能力。
Contoso 的網路設定是根據幾個主要原則所建置：
在每個地理區域內，都有多個 Azure ExpressRoute 線路。
區域內的每個線路都可以支援該區域內的所有網路流量。
視可用性、位置等而定，路由會明顯偏好一個或另一個路徑。
Azure ExpressRoute 線路之間的故障轉移會自動進行，而不需要 Contoso 需要額外的設定或動作。
因特網線路之間的故障轉移會自動發生，而不需要 Contoso 進行額外的設定或動作。
在此設定中，使用實體和虛擬層級的備援，Contoso 能夠以可靠的方式提供本機復原、區域復原和全域復原。 Contoso 在評估每個區域的單一 Azure ExpressRoute 線路，以及故障轉移至因特網的可能性之後，選擇了此設定。
如果 Contoso 無法讓每個區域有多個 Azure ExpressRoute 線路，則將源自 北美洲 的流量路由傳送至亞太地區的 Azure ExpressRoute 線路會增加無法接受的延遲層級，而所需的 DNS 轉寄站設定會增加複雜度。
不建議使用因特網作為備份組態。 這會中斷 Contoso 的可靠性原則，導致使用連線的體驗不一致。 此外，考慮已設定的 BGP 公告、NAT 設定、DNS 組態和 Proxy 設定，需要手動設定才能進行故障轉移。 這會增加故障轉移複雜度，以增加復原時間，並降低診斷和疑難解答相關步驟的能力。
仍然有關於如何規劃和實作流量管理或 Azure ExpressRoute 的問題嗎？ 閱讀網路 和效能指引 的其餘部分或 Azure ExpressRoute 常見問題。
將安全性控件套用至適用於 Microsoft 365 案例的 Azure ExpressRoute
保護 Azure ExpressRoute 連線從保護因特網連線的相同原則開始。 許多客戶選擇沿著將內部部署網路連線到 Microsoft 365 和其他 Microsoft 雲端的 ExpressRoute 路徑部署網路和周邊控件。 這些控制項可能包括防火牆、應用程式 Proxy、數據外洩防護、入侵檢測、入侵防護系統等等。 在許多情況下，客戶會將不同層級的控件套用至從內部部署移至 Microsoft 的流量，而從 Microsoft 起始的流量則會流向客戶內部部署網路，而非從內部部署到一般因特網目的地的流量。
以下是將安全性與您選擇部署的 ExpressRoute 連線模型 整合的一些範例。
| ExpressRoute 整合選項 | 網路安全性周邊模型 |
|---|---|
| 共置於雲端交換 |
在建立 ExpressRoute 連線的共置設施中安裝新的或使用現有的安全性/周邊基礎結構。 僅針對路由/互連用途使用共置設施，並將共置設施的傳送聯機傳回內部部署安全性/周邊基礎結構。 |
| 點對點乙太網路 |
終止現有內部部署安全性/周邊基礎結構位置中的點對點 ExpressRoute 連線。 安裝 ExpressRoute 路徑專屬的新安全性/周邊基礎結構，並在該處終止點對點連線。 |
| 任意對任意 IPVPN |
在輸出至用於 ExpressRoute for Microsoft 365 連線之 IPVPN 的所有位置使用現有的內部部署安全性/周邊基礎結構。 將用於 ExpressRoute for Microsoft 365 的 IPVPN 固定到指定做為安全性/周邊的特定內部部署位置。 |
某些服務提供者也提供受控安全性/周邊功能，作為其與 Azure ExpressRoute 整合解決方案的一部分。
在考慮用於 Microsoft 365 連線之 ExpressRoute 的網路/安全性周邊選項拓撲位置時，以下是額外的考慮
深度和類型網路/安全性控制可能會影響 Microsoft 365 用戶體驗的效能和延展性。
輸出 (內部部署 Microsoft>) 和輸入 (Microsoft 內部>部署) [如果啟用] 流程可能有不同的需求。 這些可能不同於輸出到一般因特網目的地。
無論流量是透過 ExpressRoute for Microsoft 365 或透過因特網路由傳送，埠/通訊協定和必要 IP 子網的 Microsoft 365 需求都相同。
客戶網路/安全性控件的拓撲放置決定使用者與 Microsoft 365 服務之間的最終端對端網路，而且可能會對網路等待時間和壅塞造成重大影響。
建議客戶根據備援、高可用性和災害復原的最佳做法，設計其安全性/周邊拓撲以搭配適用於 Microsoft 365 的 ExpressRoute 使用。
以下是 Contoso 的範例，可比較不同的 Azure ExpressRoute 連線選項與上面所述的周邊安全性模型。
範例：保護 Azure ExpressRoute
Contoso 正考慮實作 Azure ExpressRoute，並在規劃適用於 Microsoft 365 的 ExpressRoute 最佳架構之後，並在使用上述指引來了解頻寬需求之後，決定保護其周邊的最佳方法。
針對 Contoso，一個位於多個大陸的多國家/地區組織，安全性必須跨越所有周邊。 Contoso 的最佳連線選項是多點連線，其在全球各地有多個對等互連位置，可滿足其在每個大陸中的員工需求。 每個大陸都包含大陸內的備援 Azure ExpressRoute 線路，而安全性必須跨越所有這些。
Contoso 現有的基礎結構是可靠的，而且可以處理額外的工作，因此 Contoso 能夠針對其 Azure ExpressRoute 和因特網周邊安全性使用基礎結構。 如果不是這種情況，Contoso 可以選擇購買更多設備來補充其現有的設備，或處理不同類型的連線。
Azure ExpressRoute 的頻寬規劃
每個 Microsoft 365 客戶都有唯一的頻寬需求，視每個位置的人員數目、每個 Microsoft 365 應用程式的作用中程度，以及其他因素而定，例如使用內部部署或混合式設備和網路安全性設定。
帶寬太少會導致壅塞、數據重新傳輸，以及無法預期的延遲。 帶寬過多會導致不必要的成本。 在現有的網路上，頻寬通常會以百分比表示線路上可用的空餘空間數量。 擁有 10% 的頭房可能會導致壅塞，而擁有 80% 的頭空間通常表示不必要的成本。 一般空間目標配置是 20% 到 50%。
若要尋找正確的頻寬層級，最佳機制是測試您現有的網路耗用量。 這是取得實際使用量和需求的唯一方法，因為每個網路組態和應用程式在某些方面都是唯一的。 測量時，您會想要密切注意總頻寬耗用量、延遲和 TCP 壅塞，以瞭解您的網路需求。
一旦您有包含所有網路應用程式的預估基準，請試驗 Microsoft 365 與包含組織中不同人員配置檔的小型群組，以判斷實際使用量，並使用兩個度量來估計每個辦公室位置所需的頻寬量。 如果您的測試中發現任何延遲或 TCP 壅塞問題，您可能需要使用 Microsoft 365 將輸出移至更接近人員的地方，或移除密集的網路掃描，例如 SSL 解密/檢查。
我們對於建議的網路處理類型的所有建議都適用於 ExpressRoute 和因特網線路。 我們 效能微調網站上的其餘指引也是如此。
建置您的部署和測試程式
您的實作計劃應該包含測試和復原規劃。 如果您的實作未如預期般運作，則應設計計劃以在發現問題之前影響最少的人員數目。 以下是您的計劃應該考慮的一些高階原則。
暫存網路區段和使用者服務上線，以將中斷情況降到最低。
規劃使用追蹤路由和 TCP 連線，從個別的因特網連線主機測試路由。
最好是在具有測試 Microsoft 365 租使用者的隔離測試網路上測試輸入和輸出服務。
或者，如果客戶尚未使用 Microsoft 365 或正在試驗中，則可以在生產網路上執行測試。
或者，測試可以在生產中斷期間執行，而此中斷僅供測試和監視之用。
或者，測試可以藉由檢查每個第 3 層路由器節點上每個服務的路由來完成。 只有在沒有其他測試時才應該使用此後援，因為缺少實體測試會帶來風險。
建置您的部署程式
您的部署程式應該分階段推出給一小群人員，以便在部署到較大的人員群組之前進行測試。 以下是預備 ExpressRoute 部署的幾種方式。
使用 Microsoft 對等互連設定 ExpressRoute，並將路由公告轉送到單一主機，僅供分段測試之用。
一開始將 ExpressRoute 網路的路由公告至單一網路區段，並依網路區段或區域展開路由通告。
如果是第一次部署 Microsoft 365，請使用 ExpressRoute 網路部署作為少數人的試驗。
如果使用 Proxy 伺服器，您也可以設定測試 PAC 檔案，在新增更多專案之前，先使用測試和意見反應將一些人員導向 ExpressRoute。
您的實作計劃應該列出每個必須採取的部署程式，或需要用來部署網路組態的命令。 當網路中斷時間到達時，進行的所有變更都應該來自事先撰寫的書面部署計劃和對等檢閱。 請參閱 ExpressRoute 技術設定的指引。
如果您已變更任何將繼續傳送電子郵件之內部部署伺服器的IP位址，請更新SPF TXT記錄。
如果您已變更 IP 位址以容納新的 NAT 設定，請更新內部部署伺服器的任何 DNS 專案。
請確定您已訂閱 Microsoft 365 端點通知的 RSS 摘要，以維護任何路由或 Proxy 設定。
ExpressRoute 部署完成之後，應該執行測試計劃中的程式。 應該記錄每個程序的結果。 如果測試計劃結果指出實作不成功，您必須包含復原到原始生產環境的程式。
建置測試程式
您的測試程式應該包含每個將使用 ExpressRoute 的 Microsoft 365 輸出和輸入網路服務，以及不會使用的測試。 這些程式應該包含來自每個唯一網路位置的測試，包括不是公司 LAN 內部部署的使用者。
測試活動的一些範例包括下列各項。
從內部部署路由器 Ping 至網路操作員路由器。
驗證內部部署路由器會收到 500 個以上的 Microsoft 365 和 CRM Online IP 位址通告。
驗證您的輸入和輸出 NAT 在 ExpressRoute 與內部網路之間運作。
驗證路由傳送至 NAT 的路由正在從路由器公告。
驗證 ExpressRoute 是否已接受通告的前置詞。
- 使用下列 Cmdlet 來驗證對等互連通告：
Get-AzureRmExpressRouteCircuitRouteTable -DevicePath Primary -ExpressRouteCircuitName TestER -ResourceGroupName RG -PeeringType MicrosoftPeering驗證您的公用NAT IP 範圍不會透過任何其他 ExpressRoute 或公用因特網網路線路向 Microsoft 公告，除非它是如先前範例所示較大範圍的特定子集。
ExpressRoute 線路會配對，並驗證這兩個 BGP 工作階段正在執行。
在 NAT 內部設定單一主機，並使用 ping、tracert 和 tcpping 來測試新線路與主機 outlook.office365.com 的連線能力。 或者，您可以在 MSEE 的鏡像埠上使用 Wireshark 或 Microsoft 網路監視器 3.4 等工具來驗證您是否能夠連線到與 outlook.office365.com 相關聯的 IP 位址。
測試 Exchange Online的應用層級功能。
測試 Outlook 能夠連線到 Exchange Online 並傳送/接收電子郵件。
測試 Outlook 能夠使用在線模式。
測試智慧型手機連線能力和傳送/接收功能。
- 測試 SharePoint 的應用層級功能
測試 商務用 OneDrive 同步處理用戶端。
測試 SharePoint Web 存取。
- 測試 商務用 Skype呼叫案例的應用層級功能：
以已驗證的使用者身分加入電話會議 [由使用者起始的邀請]。
邀請用戶參加電話會議 [從 MCU 傳送的邀請]。
使用 商務用 Skype Web 應用程式以匿名使用者身分加入會議。
從有線計算機連線、IP 電話和行動裝置加入通話。
呼叫同盟使用者 o 呼叫 PSTN 驗證：通話已完成、通話品質可接受、可接受連線時間。
確認已針對租使用者和同盟用戶的成員更新聯繫人的目前狀態。
常見問題
非對稱式路由是最常見的實作問題。 以下是一些要尋找的常見來源：
使用未備妥來源 NAT 的開放或一般網路路由拓撲。
不使用 SNAT 透過因特網和 ExpressRoute 連線路由傳送至輸入服務。
在廣泛部署之前，請不要在測試網路上測試 ExpressRoute 上的輸入服務。
透過網路部署 ExpressRoute 連線能力
一次將您的部署暫存至網路的一個區段，並逐步推出與網路不同部分的連線，並規劃針對每個新的網路區段復原。 如果您的部署與 Microsoft 365 部署一致，請先部署到您的 Microsoft 365 試驗使用者，然後從該處擴充。
首先針對您的測試，然後針對生產環境：
執行部署步驟以啟用 ExpressRoute。
測試您是否如預期般看到網路路由。
在每個輸入和輸出服務上執行測試。
如果您發現任何問題，請回復。
使用測試網路區段設定 ExpressRoute 的測試連線
既然您已在紙張上完成計劃，現在可以進行小規模的測試。 在此測試中，您將建立與 Microsoft 對等互連的單一 ExpressRoute 連線，以連線到內部部署網路上的測試子網。 您可以設定 試用版 Microsoft 365 租 使用者與測試子網之間的連線能力，並包含您將在測試子網的生產環境中使用的所有輸出和輸入服務。 設定測試網路區段的 DNS，並建立所有輸入和輸出服務。 執行測試計劃，並確定您已熟悉每個服務的路由和路由傳播。
執行部署和測試計劃
當您完成上述專案時，請檢查您已完成的區域，並確定您和您的小組在執行部署和測試計劃之前已檢閱過這些區域。
涉及網路變更的輸出和輸入服務清單。
顯示因特網輸出和 ExpressRoute meet-me 位置的全域網路架構圖表。
網路路由圖示範用於每個已部署服務的不同網路路徑。
部署計劃，其中包含必要時實作變更和復原的步驟。
測試每個 Microsoft 365 和網路服務的測試計劃。
已完成輸入和輸出服務生產路由的紙張驗證。
測試網路區段中已完成的測試，包括可用性測試。
選擇足以在整個部署計劃和測試計劃中執行的中斷時間範圍，有一些時間可用來進行疑難解答，以及視需要復原的時間。
注意
由於透過因特網和 ExpressRoute 路由的複雜本質，建議在此視窗中新增額外的緩衝時間，以處理複雜路由的疑難解答。
設定 商務用 Skype Online 的 QoS
QoS 是取得 商務用 Skype Online 語音和會議權益的必要專案。 您可以在確定 ExpressRoute 網路連線不會封鎖任何其他 Microsoft 365 服務存取之後，設定 QoS。 商務用 Skype Online 中的 ExpressRoute 和 QoS 一文說明 QoS 的設定。
針對您的實作進行疑難解答
第一個要查看的是本實作指南中的步驟，您的實作計劃中是否遺漏了任何專案？ 返回 並盡可能執行進一步的小型網路測試，以復寫錯誤並在該處進行偵錯。
識別哪些輸入或輸出服務在測試期間失敗。 特別取得每個失敗服務的IP位址和子網。 繼續進行並逐步解說紙張上的網路拓撲圖表，並驗證路由。 特別驗證 ExpressRoute 路由通告至的位置，請盡可能使用追蹤測試中斷期間的路由。
對每個用戶端點執行具有網路追蹤的 PSPing，並評估來源和目的地 IP 位址，以驗證它們是否如預期般。 對您在埠 25 上公開的任何郵件主機執行 telnet，並確認如果預期，SNAT 會隱藏原始來源 IP 位址。
請記住，使用 ExpressRoute 連線部署 Microsoft 365 時，您必須確保 ExpressRoute 的網路組態設計最佳，而且您也已優化網路上的其他元件，例如用戶端電腦。 除了使用此規劃指南來針對您可能錯過的步驟進行疑難解答之外，我們也撰寫了 Microsoft 365 的效能疑難解答計劃 。
您可以使用下列短連結返回這裡：https://aka.ms/implementexpressroute365
相關主題
適用於 Microsoft 365 的 Azure ExpressRoute
商務用 Skype Online 中的媒體品質和網路連線效能
商務用 Skype Online 中的 ExpressRoute 與 QoS