共用方式為


規劃IP尋址

組織在 Azure 中規劃 IP 尋址很重要。 規劃可確保IP位址空間不會在內部部署位置和Azure區域之間重疊。

設計考量:

  • 跨內部部署和 Azure 區域重疊的 IP 位址空間會產生重大爭用挑戰。

  • Azure VPN 閘道 可以透過網路位址轉換(NAT) 功能,連接重疊的內部部署網站與重疊 IP 位址空間。 此功能已在 Azure 虛擬 WAN 和獨立 Azure VPN 閘道 中正式推出

    {顯示 NAT 如何與 VPN 閘道 搭配運作的圖表。}

  • 建立虛擬網路之後,您可以新增位址空間。 如果虛擬網路已透過虛擬網路對等互連連線到另一個虛擬網路,則此程式不需要中斷。 相反地,每個遠端對等互連都需要 在網路空間變更之後完成重新同步作業

  • Azure 會在每個子網內保留五個IP位址 。 當您調整虛擬網路大小並包含子網時,請納入這些位址。

  • 某些 Azure 服務需要 專用子網。 這些服務包括 Azure 防火牆和 Azure VPN 閘道。

  • 您可以將子網委派給特定服務,以在子網內建立服務的實例。

設計建議:

  • 事先規劃跨 Azure 區域和內部部署位置的非重疊 IP 位址空間。

  • 針對私人因特網使用位址配置中的IP位址,稱為 RFC 1918 位址。

  • 請勿使用下列位址範圍:

    • 224.0.0.0/4 (多播)
    • 255.255.255.255/32 (廣播)
    • 127.0.0.0/8 (回送)
    • 169.254.0.0/16 (link-local)
    • 168.63.129.16/32 (內部 DNS)
  • 對於私人IP位址可用性有限的環境,請考慮使用IPv6。 虛擬網路可以是僅限 IPv4 或雙堆疊 IPv4+IPv6

    顯示IPv4和IPv6雙重堆疊的圖表。

  • 請勿建立大型虛擬網路,例如 /16。 它可確保不會浪費IP位址空間。 支援的最小 IPv4 子網是 /29,而最大的是 /2 使用無類別網路變數間路由 (CIDR) 子網定義時。 IPv6 子網的大小必須剛好 /64

  • 請勿事先規劃所需的位址空間,即可建立虛擬網路。

  • 請勿對虛擬網路使用公用IP位址,特別是公用IP位址不屬於您的組織時。

  • 將要使用的服務納入考慮,有一些服務具有保留IP(IP位址),例如 具有 CNI 網路的 AKS

  • 使用 不可路由登陸區域輪輻虛擬網路Azure Private Link 服務 來防止 IPv4 耗盡。

IPv6 考慮

越來越多的組織在其環境中採用IPv6。 這種採用是由公用 IPv4 空間耗盡、私人 IPv4 稀缺性,特別是在大規模網路內,以及提供 IPv6 專用用戶端連線的需求所推動。 沒有採用 IPv6 的通用方法。 不過,規劃 IPv6 並在現有的 Azure 網路中實作時,您可以遵循的最佳做法。

適用於 Azure 的 Microsoft 雲端採用架構 可協助您了解在雲端中建立系統時要考慮的考慮。 若要瞭解設計可持續系統的架構最佳做法,請參閱 Azure 登陸區域設計原則。 如需雲端架構的深入建議和最佳做法,包括參考架構部署、圖表和指南,請參閱 IPv6 的架構中心指南。

設計考量:

  • 階段您的 IPv6 採用。 根據您的業務需求,視需要實作IPv6。 請記住,只要必要,IPv4 和 IPv6 就可以共存。

  • 在應用程式依賴基礎結構即服務 (IaaS) 服務的情況下,可以支援完整的 IPv6,例如虛擬機(VM)、IPv4 和 IPv6 的原生端對端使用。 此組態可避免轉譯複雜問題,並將大部分資訊提供給伺服器和應用程式。

    您可以使用 IPv6 位址部署基本 SKU 因特網對向 Azure 負載平衡器。 此組態可透過負載平衡器啟用公用因特網與 Azure VM 之間的原生端對端 IPv6 連線。 此方法也可協助公用因特網上 VM 與啟用 IPv6 的客戶端之間的原生端對端輸出連線。 請注意,這種方法需要路徑中的每個裝置來處理IPv6流量。

    原生端對端方法最適合直接伺服器對伺服器或客戶端對伺服器通訊。 它不適用於大部分 Web 服務和應用程式,這些服務通常會受到防火牆、Web 應用程式防火牆或反向 Proxy 的保護。

  • 某些複雜的部署和應用程式會使用第三方服務、平臺即服務 (PaaS) 服務和後端解決方案的組合,可能不支援原生 IPv6。 在這些情況下,您必須使用 NAT/NAT64 或 IPv6 Proxy 解決方案來啟用 IPv6 與 IPv4 之間的通訊。

  • 當應用程式架構的複雜度或訓練成本等因素被視為相當重要時,您可能會想要在後端繼續使用僅限IPv4的基礎結構,並部署第三方網路虛擬設備 (NVA) 雙堆棧 IPv4/IPv6 閘道以進行服務傳遞。

    使用 NVA 的一般部署看起來可能如下所示:

    此圖顯示雙堆棧 IPv4/IPv6 閘道,可提供 IPv4 專用後端的存取權。

設計建議:

以下是一般架構外觀的更仔細探討:

此圖顯示 IPv4/IPv6 負載平衡器,可存取僅限 IPv4 的後端。

  • 使用彈性協調流程 (VMSS Flex) 在 虛擬機器擴展集 中部署 NVA,以透過具有公用 IP 位址前端的 Azure Load-Balancer 將其公開至因特網

    NVA 接受 IPv4 和 IPv6 流量,並將其轉譯為僅限 IPv4 的流量,以存取應用程式子網中的應用程式。 此方法可降低應用程式小組的複雜度,並減少受攻擊面。

  • 部署 Azure Front Door 以提供 Web 流量的全域路由。

    Azure Front Door 功能包括 Proxy 處理 IPv6 用戶端要求和僅限 IPv4 後端的流量,如下所示:

    此圖顯示 Azure Front Door 提供 IPv4 專用後端存取權。

這些是 NVA 方法與 Azure Front Door 方法之間的主要差異:

  • NVA 是客戶管理的、在 OSI 模型的第 4 層工作,而且可以使用私人和公用介面,部署在與應用程式相同的 Azure 虛擬網路中。
  • Azure Front Door 是全域 Azure PaaS 服務,可在第 7 層 (HTTP/HTTPS) 運作。 應用程式後端是因特網面向的服務,可以鎖定以只接受來自 Azure Front Door 的流量。

在複雜的環境中,您可以使用兩者的組合。 NVA 會在區域部署內使用。 Azure Front Door 可用來將流量路由傳送至不同 Azure 區域或其他因特網對應位置中的一或多個區域部署。 若要判斷最佳解決方案,建議您檢閱 Azure Front Door 的功能和產品檔。

IPv6 虛擬網路 CIDR 區塊:

  • 當您在訂用帳戶中的現有 Azure 部署中建立新的虛擬網路時,您可以建立單一 IPv6 無類別網路域間路由 (CIDR) 區塊。 IPv6 的子網大小必須是 /64。 如果您決定啟用子網路由至內部部署網路,則使用此大小可確保未來的相容性。 某些路由器只能接受 /64 IPv6 路由。
  • 如果您有只支援 IPv4 的現有虛擬網路,且子網中的資源設定為只使用 IPv4,您可以啟用虛擬網路和資源的 IPv6 支援。 您的虛擬網路可以在雙堆棧模式中運作,讓您的資源能夠透過IPv4、IPv6 或兩者進行通訊。 IPv4 和 IPv6 通訊彼此獨立。
  • 您無法停用虛擬網路和子網的 IPv4 支援。 IPv4 是 Azure 虛擬網路的預設 IP 尋址系統。
  • 將IPv6 CIDR 區塊與您的虛擬網路和子網或 BYOIP IPv6 產生關聯。 CIDR 表示法是表示IP位址及其網路遮罩的方法。 這些位址格式如下:
    • 個別的 IPv4 位址是 32 位,四個群組的十進位數多達三個。 例如: 10.0.1.0
    • IPv4 CIDR 區塊有四組多達三個十進位數,從 0 到 255,以句點分隔,後面接著斜線和 0 到 32 的數位。 例如: 10.0.0.0/16
    • 個別的 IPv6 位址是 128 位。 它有八組四個十六進位數位。 例如: 2001:0db8:85a3:0000:0000:8a2e:0370:7334
    • IPv6 CIDR 區塊有四組多達四個十六進位數位,以冒號分隔,後面接著雙冒號,然後接著斜線和 1 到 128 的數位。 例如: 2001:db8:1234:1a00::/64
  • 更新路由表以路由IPv6流量。 針對公用流量,建立路由,將所有 IPv6 流量從子網路由傳送至 VPN 閘道 或 Azure ExpressRoute 閘道。
  • 更新安全組規則,以包含IPv6位址的規則。 這麼做可讓 IPv6 流量流向您的實例。 如果您有網路安全組規則來控制來自子網的流量流程,則必須包含IPv6流量的規則。
  • 如果您的實例類型不支援 IPv6,請使用雙堆疊或部署 NVA,如先前所述,從 IPv4 轉譯為 IPv6。

IP 位址管理 (IPAM) 工具

使用IPAM工具可協助您在 Azure 中規劃IP位址,因為它提供集中式管理和可見度,防止IP位址空間中的重疊和衝突。 本節會引導您完成採用IPAM工具時的基本考慮和建議。

設計考量:

視您的需求和組織大小而定,有許多IPAM工具可供您考慮。 這些選項範圍從具有基本的 Excel 型清查到開放原始碼社群驅動解決方案,或具有進階功能和支援的完整企業產品。

  • 評估要實作的IPAM工具時,請考慮這些因素:

    • 組織所需的最低功能
    • 總擁有成本 (TCO),包括授權和持續維護
    • 稽核線索、記錄和角色型訪問控制
    • 透過 Microsoft Entra 識別碼進行驗證和授權
    • 可透過 API 存取
    • 與其他網路管理工具和系統的整合
    • 主動社群支援或軟體提供者的支持層級
  • 請考慮評估開放原始碼IPAM工具,例如 Azure IPAM。 Azure IPAM 是建置在 Azure 平臺上的輕量型解決方案。 它會自動探索 Azure 租使用者內的 IP 位址使用率,並可讓您從集中式 UI 或透過 RESTful API 管理它。

  • 請考慮您的組織作業模型和IPAM工具的擁有權。 實作IPAM工具的目標是簡化要求應用程式小組的新IP位址空間的程式,而不需要相依性和瓶頸。

  • IPAM 工具功能的重要部分是清查IP位址空間使用量,並以邏輯方式加以組織。

設計建議:

  • 保留非重疊IP位址空間的程式應該支援根據個別應用程式登陸區域的需求要求不同的大小。

    • 例如,您可以採用 T 恤重設大小,讓應用程式小組輕鬆地描述其需求:
      • 小型 - /24 - 256 個 IP 位址
      • 中 - - /22 1,024 個 IP 位址
      • 大型 - - /20 4,096 個 IP 位址
  • 您的IPAM工具應該有 API 來保留非重疊的IP位址空間,以支援基礎結構即程式代碼 (IaC) 方法。 這項功能對於將IPAM與 訂閱自動販賣 程式緊密整合也非常重要,因此可降低錯誤的風險和手動介入的需求。

    • IaC 方法的範例是 Bicep 及其部署腳本功能或 Terraform 數據源,以動態方式從 IPAM API 擷取數據。
  • 根據 Azure 區域和工作負載原型來建立 IP 位址空間的系統式安排,以確保網路清查乾淨且可追蹤。

  • 工作負載的解除委任程式應包括移除不再使用的IP位址空間,而該空間稍後可針對即將推出的新工作負載進行重新用途,以促進有效率的資源使用率。