VNet Peering 的連接模型
建立 Peering 後,兩個 VNet 可透過 Azure 骨幹交換符合路由的私有流量。常見設計包括同一訂閱內的環境互連、跨訂閱的共用服務,以及跨區域的災難復原連接。兩端 Peering 狀態及配置需同時檢查;單邊建立或設定不一致會令連線不完整。
Peering 並不等同於把所有 VNet 自動變成一個無邊界的網絡。地址必須不重疊,路由前綴必須可達,且 NSG、防火牆、作業系統及服務層的控制仍會影響最終結果。
建立 Peering 後,兩個 VNet 可透過 Azure 骨幹交換符合路由的私有流量。常見設計包括同一訂閱內的環境互連、跨訂閱的共用服務,以及跨區域的災難復原連接。兩端 Peering 狀態及配置需同時檢查;單邊建立或設定不一致會令連線不完整。
Peering 並不等同於把所有 VNet 自動變成一個無邊界的網絡。地址必須不重疊,路由前綴必須可達,且 NSG、防火牆、作業系統及服務層的控制仍會影響最終結果。
| 路由來源 | 用途 | 排錯重點 |
|---|---|---|
| 系統路由 | 平台按 VNet、子網及互連產生的基本可達性 | 確認目的地前綴、下一跳及是否存在更精確路由 |
| 使用者定義路由(UDR) | 把流量導向網絡虛擬設備、VPN 或指定下一跳 | 檢查路由表是否已關聯正確子網及下一跳是否可達 |
| 外部路由交換 | VPN、ExpressRoute 或網絡虛擬設備宣告的企業網段 | 檢查前綴宣告、學習狀態、摘要及回程路由 |
| 安全規則 | NSG 及設備策略決定流量是否獲准 | 分開判斷「沒有路由」與「有路由但被拒絕」 |
企業常把共用防火牆、DNS、跳板機或 VPN 閘道集中在 Hub,工作負載 VNet 作為 Spoke。這種設計必須明確定義哪些流量可以經 Hub 轉送、哪些前綴由哪一個下一跳承載,以及回程路由如何返回。只建立 Hub 與 Spoke 的 Peering,不代表 Spoke 會自動經另一個 Spoke 轉送。
按來源、目的地、協定及業務用途畫出流量矩陣,避免只用「互通」描述需求。
每條允許流量都要有正向及回程路由,並檢查更長前綴是否覆蓋預期下一跳。
路由決定如何到達,NSG 及防火牆決定是否允許;兩者要分開驗證。
跨區域或經設備轉送的流量應按容量、延遲、可用性及成本評估。
RFC 1812 對 IPv4 路由器的要求提供了理解下一跳、轉送及路由一致性的基礎;在 Azure 中,實際可用功能仍以 Azure Virtual Network 文件及已部署配置為準。工程驗收不應只測試單一方向的 TCP 連線,還要記錄前綴、有效路由、NSG、設備日誌及故障時的替代路徑。
不確定如何應用於實際環境?我們的工程師可按現場情況提供建議,免費解答及報價。
WhatsApp 即時查詢若閣下正計劃相關工程或需要選購設備,歡迎瀏覽網絡工程服務了解方案詳情,或透過網上快速報價與我們的工程師聯絡。
產品規格以原廠最新文件為準;有需要請聯絡我們工程師。