Microsoft AZ-700: 混合式網路 — 學習指南

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

屬於 Microsoft Azure Network Engineer AZ-700 — 學習指南. 使用經過驗證的解答練習： Microsoft 考試中心, 或參加限時模擬考試： ExamRoll.io.

混合式連線基礎與位址限制

混合式連線旨在於地端和 Azure 虛擬網路之間，建立可靠、可路由且安全的 IP 連通性。在規劃虛擬網路位址時，請記住，子網路內某些由 Azure 管理的資源需要連續、不衝突的位址配置，有時還需要特定的保留位址：Azure 負載平衡器和閘道子網路必須特意規劃出來 (GatewaySubnet 必須使用這個確切的名稱，且大小需能容納閘道 SKU 的擴展需求)，而私人端點和 Azure 管理的服務端點則需要從託管的 VNet 中取得位址。地端與 Azure 的前置碼重疊是最常見的陷阱：重疊的範圍會破壞路由和 BGP 路由選擇、造成非對稱路由，並使防火牆策略變得複雜。對於託管具狀態防火牆、負載平衡器或大量私人端點的子網路，請至少使用 /27–/24 的區段；並保留一個專用的 GatewaySubnet (/27 或更大，視 SKU 而定)。DNS 同樣至關重要：私人端點使用平台私有 DNS 區域 (例如 privatelink.database.windows.net)，因此地端需要條件式轉寄站或 Azure DNS Private Resolver 才能解析 Azure 的私有名稱。設計上的權衡取捨，主要在於 IP 使用率與彈性之間的平衡：較密集的 IPv4 配置方案能節省位址空間，但會增加衝突和遷移的風險；而較大、效率較低的前置碼則簡化了未來的擴展和 BGP 路由宣告策略。

VPN 閘道 SKU、BGP 基礎與區域網路閘道

選擇正確的 VPN 閘道 SKU (VpnGw1–VpnGw5，舊版為 Basic) 會直接影響吞吐量、並行的 S2S/P2S 工作階段數量，以及可用功能 (如主動-主動模式或路由限制)。對於現代混合式設計，應使用路由式閘道；策略式閘道是舊版技術且會限制 BGP 的使用。BGP 提供動態交換前置碼的功能，並支援路徑彈性、自動容錯移轉和前置碼優先級設定 — 請設定 Azure VPN 閘道的 ASN (預設為 65515)，並在 Local Network Gateway 物件中與地端的 ASN 進行對接或匹配。Local Network Gateway 儲存了地端的公用 IP、位址空間，以及選用的 BGP 對等體 IP 和 ASN；忘記填寫 BGP 對等體 IP 或 ASN 不匹配，會阻止路由傳播，並導致需要使用靜態路由作為權宜之計。針對多站點的擴展和內建的轉送路由，可考慮使用 Azure Virtual WAN 中樞；VWAN 中樞支援大規模的 S2S 和 P2S，並能與 Azure Firewall 和 ExpressRoute 整合。請注意路由表的傳播：預設情況下，某些中樞-輪輻或虛擬設備的拓撲會抑制自動傳播；此時可能需要明確的 UDR 或 BGP 路由宣告。權衡取捨：較高的 SKU 和 VWAN 會增加成本，但能減少管理負擔並提升吞吐量和路由規模。

點對站設計選擇、用戶端支援與 DNS 整合

點對站 (P2S) 的設計選擇決定了用戶端的相容性、驗證方式和規模。OpenVPN (SSL) 跨平台支援度最高，推薦用於 macOS、Linux 和行動裝置用戶端；IKEv2 較為輕量，且與 macOS 的原生用戶端能良好配合；SSTP 則仍是僅限舊版 Windows 情境的一個選項。驗證模式包括 Azure Active Directory (推薦用於身分識別整合和條件式存取)、憑證式驗證，以及用於地端 MFA 或 RADIUS 解決方案的 RADIUS 驗證。VPN 閘道的 SKU 決定了 P2S 通道數量和吞吐量；為中到大型使用者群選擇 VpnGw2/3，對於大規模或對吞吐量敏感的用途則選擇 VpnGw4/5。私人端點和 P2S 透過 DNS 互動：為了讓 P2S 用戶端能夠解析私人端點的名稱 (privatelink 區域)，可以將私人 DNS 區域連結到 VNet，或使用 Azure DNS Private Resolver 以及來自地端或用戶端 DNS 的條件式轉寄站。一個常見的陷阱是忘記 P2S 用戶端通常只有在用戶端推送路由和 DNS 設定時，才會使用閘道提供的 Azure DNS；明確設定 DNS 尾碼和轉寄站可以避免「無法解析私人端點」的問題。在擴展性與成本之間取得平衡：憑證驗證成本低廉但較難撤銷；Azure AD 提供現代化的安全控制，但增加了授權和複雜性。

傳輸路由、強制通道、檢測與安全設備放置

在設計多個 VNet、地端環境與檢測設備之間的傳輸時，需要明確地強制執行路由與 NAT 邊界。若要強制流量通過 Azure Firewall 或虛擬設備，需要使用指向防火牆私有 IP 的使用者定義路由 (UDRs)，或利用 Virtual WAN 中樞路由來集中化檢測。如果您需要完整的透明代理 (transparent proxying) 或 TLS 檢測，請將設備放置在專用的檢測子網路中，並確保閘道子網路和防火牆的 SKU 支援預期吞吐量的傳輸。請注意 SNAT 的行為和公有 IP SKU 的選擇：建議使用 Standard Public IPs 和 NAT Gateway 以獲得可預測的對外 SNAT 和安全規則；將 NAT Gateway 與一組 Standard public IPs 搭配使用，可以分擔 SNAT 的負載，並避免每個 VM 都配置公有 IP 的雜亂情況。一個常見的陷阱是非對稱路由 (asymmetric routing)，當地端的路由和 Azure UDRs 導致回程流量繞過預期的設備時就會發生；請確保所有分支 (spokes) 都透過 BGP 通告必要的首碼，或設定 UDRs 將流量導向檢測點。效能與成本的權衡：採用 hub-and-spoke 架構，搭配 Azure Firewall Premium 或第三方高吞吐量設備，可以增強保護和集中管理，但也會增加成本和單一中樞的故障風險，除非您部署 active-active 的備援中樞，並跨區域配對閘道。

實務問題：使用案例情境

情境：Contoso Ltd 有兩個地端資料中心（西雅圖和阿姆斯特丹），以及一個現有的 Azure 環境，其中包含三個 VNet（VNet-Prod、VNet-Shared、VNet-Dev）位於一個單一的中樞 VNet (VNet-Hub) 中。他們目前為西雅圖使用一個 VpnGw1 VPN Gateway，並為阿姆斯特丹使用一個站對站 (site-to-site) 連線到 Azure Virtual WAN 中樞。在 VNet-Shared 中，他們使用私有端點 (Private endpoints) 來存取 Azure SQL。

挑戰：Contoso 需要在地端資料中心和 Azure 之間建立具有動態路由 (BGP) 的彈性、可擴展的混合式連線，為 macOS 使用者提供可靠的 P2S 支援，從地端解析私有端點的 DNS，並透過 Azure Firewall 集中檢測來自各分支 (spokes) 的對外流量。

建議方法：

在 VNet-Hub 中部署一個新的 VpnGw3 route-based VPN Gateway，設定為 active-active 模式並啟用 BGP（明確設定閘道 ASN），並更新 Local Network Gateway 物件，填入地端的 BGP 對等 IP 和 ASN；將西雅圖的 S2S 遷移到新的閘道，以支援更高的吞吐量和路由限制。
透過建立 ExpressRoute 或將 VWAN 中樞遷移為與 VNet-Hub 進行中樞對等互連 (hub peering)，來將阿姆斯特丹的連線整合到中樞；確保兩個資料中心之間進行 BGP 路由交換，以避免使用靜態路由並啟用自動容錯轉移。
在 VpnGw3 上使用 OpenVPN 協定與 Azure AD 驗證來設定 P2S，以支援 macOS 用戶端（使用 IKEv2 作為備援），並根據 VpnGw3 的限制來規劃用戶端集區的大小；在地端 DNS 上發佈一個條件式轉寄站 (conditional forwarder)，將 privatelink.* 區域的查詢轉寄到部署在 VNet-Shared 中的 Azure DNS Private Resolver，該解析器已連結到私有端點的私有 DNS 區域。
在 VNet-Hub 中以 active-active 組態部署 Azure Firewall（如果需要 TLS 檢測，則使用 Premium 版），並為分支子網路建立 UDRs，將 0.0.0.0/0 的流量導向防火牆的私有 IP；將帶有 Standard public IPs 的 NAT Gateway 附加到防火牆，或使用防火牆的公有 IP 進行明確的 SNAT，並將日誌記錄到中央的 Log Analytics。

基本原理：使用帶有 BGP 的 VpnGw3 可為多站點的彈性提供動態路由傳播和吞吐量；OpenVPN+Azure AD 能安全地支援 macOS 使用者；將 DNS 轉寄到 Azure DNS Private Resolver 可確保從地端解析私有端點的名稱；在 Azure Firewall 中樞使用 UDRs 集中檢測可避免非對稱路由並簡化策略管理，同時以成本換取集中的安全性與可觀測性。

← Azure Virtual Network 設計 · 所有領域 · Azure DNS 與名稱解析 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →