跳转到内容

Microsoft Azure 虚拟网络服务

添加链接
本页使用了标题或全文手工转换
维基百科，自由的百科全书

Microsoft Azure 虚拟网络服务 是 Microsoft Azure 所提供的网络通讯服务，并运行于 Azure 数据中心内，供应运算资源所需要的网络通讯能力以及必需的资源，例如 IP 地址。

虚拟网络服务是一种软件定义网络的实现，它完全使用软件设置自动建置，无须人力介入。

Azure 平台内可使用虚拟网络的服务有：虚拟机、云端服务 与 应用服务内的 Web App。

网络配置

[编辑]

Azure 虚拟网络利用软件的方式操作 Azure 数据中心内的网络建设，它本身就是一个大型的软件定义网络解决方案，网络管理人员可在 Azure 虚拟网络内自由划分需要的子网与IP地址空间。Azure 虚拟网络提供了三种基本地址空间供选择 (都是 IP 地址中已定义的私人网络范围)：

  • 10.0.0.0
  • 172.16.0.0
  • 192.168.0.0

网络管理人员可利用 CIDR 的网络划分法来定义主地址空间 (例如 10.0.0.0/8 或 10.0.0.0/16)，并在地址空间内划分出子网 (例如 10.0.1.0/24, 10.0.2.0/24) 供虚拟机配给 IP 之用，每个子网都有自己的 DHCP 伺服器，当虚拟机加入到子网时，就会自动分派 IP 地址给它，一个子网可用的地址为该子网划分出的地址数量-3，Azure会保留每个子网的前三个 IP (.1~.3) 供 Azure 服务使用 [1]，因此可用地址均是由 .4 开始。

虽然子网可以动态分配 IP 地址给虚拟机，不过网络管理人员或服务也可以自定义要使用的 IP 地址。

IP 地址

[编辑]

虚拟网络中的 IP 地址，视可联外与否而区分，但是在新的资源管理模式 (Resource Management) 问世后，IP 地址被简化成内部 IP 与公用 IP 两种 [2]。

公用 IP

[编辑]

公用 IP (Public IP) 负责对 Internet 的连线，虚拟网络内的资源若要能连到 Internet，就必须设置一个或多个公用 IP，公用 IP 的配给方式由 Azure 管理，网络管理人员可利用 Portal 或是 PowerShell 指令等方式向 Azure 索取 IP 地址，不过 IP 地址会视可重复使用的类型分成动态 (dynamic) 与静态 (static)，动态系指当运算资源上线时才会分派 IP 地址，适合用在一般性的对外运算资源，但由于 IP 不固定，无法适用于常态性的 Internet 服务 (如 DNS 或 SSL)，若需要 IP 固定，则要使用静态公用 IP，它自配发开始就固定 (视为永久上线状态)，直到它被删除为止。

公用 IP 地址在旧的服务管理模式下，和服务有紧密的结合，因此会有下列几种类型：

  • 执行个体层级公用 IP (Instance-Level Public IP, ILPIP)，绑定在虚拟机的公用 IP，为动态的公用 IP，。
  • 保留 IP (Reserved IP, VIP)，绑定在云端服务上的 IP，为静态的公用 IP，但不能绑定在虚拟机，虚拟机要使用通讯端口对应才能使用保留 IP 连线 [3]。

在资源管理模式下属于独立资源，它可以与网卡、负载平衡器、网络网关 (Network Gateway) 与应用程式网关 (Application Gateway) 四种资源绑定 (Binding)，当 IP 不需绑定时可单独存在，动态模式的公用 IP 在未绑定时不会配发 IP，静态 IP 则有绑定的资源限制 (它不可以和网络网关或应用程式网关绑定)。

内部 IP

[编辑]

内部 IP (Private IP) 则是虚拟网络内运算资源之间通讯的基础，每个配置到虚拟网络内的运算资源都会配给内部 IP，通常是由 DHCP 依子网的地址空间进行配发，但网络管理人员也可以使用静态的内部 IP (Static VNet IP)，当运算资源注册了静态内部 IP 时，除非运算资源被删除或是解除静态内部 IP 的绑定，否则不论运算资源启动与否，该静态内部 IP 都会存在且固定。静态内部 IP 可配置在网卡、负载平衡器与应用程式网关 (Application Gateway)。然而静态内部 IP 与公用 IP 不同，它不会独立存在，而是依附于子网的设置内，因此各网络资源都要使用静态内部 IP 要个别设置无法共享。

DNS

[编辑]

Azure 虚拟网络内默认使用由 Azure 提供的名称解析服务 (Name Resolution Services)，当虚拟机配置到虚拟网络内时，其 DNS 设置会指向 Azure 的名称解析服务，负责 Azure 本身相关服务的名称对应，在早期以云端服务为主的运算服务，若没有它，则无法解析如 cloudapp.net 的名称对应，不过在资源管理员模式导入后，它不再是必备的条件，只是若公用的 IP 地址设置了 DNS 名称时，仍然会以 Azure 的 DNS 来处理名称解析 [4]。

网络管理人员若需要自己的名称解析方案 (如在虚拟网络内布建 Active Directory 网域控制站) 时，仍然可以在虚拟网络内架设 DNS 伺服器，以供应自定义的名称解析解决方案。

2015 年时，Azure 推出了自己的域名托管服务 (DNS Hosting Service)，对外使用 Azure DNS 的名称，但为避免与原有的 Azure 名称解析服务 (其原本在文件内的名称也是 Azure DNS)，目前在 Azure 官方技术文件上看到的 Azure DNS 都是指域名托管服务，而原本的 Azure DNS 则改为名称解析服务 (Azure-provided name resolution)。

负载平衡器

[编辑]

Azure 的网络服务中提供了两种类型的负载平衡器，以处理面对大量运算时的工作负载分流机制，一种是 Azure 管理的负载平衡器 (Azure Load Balancer)，这也是早期以云端服务为主的负载平衡器，由 Azure 管理，对外只能使用连接端口区分并用存取控制表来控制存取权限；另一种是内部负载平衡器 (Internal Load Balancer)，由网络管理人员自行管理，供虚拟网络内的负载分流工作。在资源管理员模式内，不论是何种负载平衡器，都视为一个独立组件，只差在负载平衡器对外的 IP 地址的设置类型不同而已。

类型

[编辑]

面对 Internet 的负载平衡器 (Internet-facing Load Balancer) 在早期以云端服务为主的管理模式下，它统一分派 *.cloudapp.net 的网址，负责 Internet 连入 Azure 服务的流量调节，但它并不决定开放的通讯端口、通讯端口对应 (Port Mapping) 与存取控制，这些设置是由挂到同一个云端服务下的运算资源来决定 (如虚拟机)，运算资源都有两种通讯设置，一种是给运算资源本身的，另一种是给负载平衡器的，这导致网络管理员在设置通讯端口上的困难与不便 (等于同一个 Policy 要设两边，而且每一个运算资源都要设)。在资源管理员模式下，负载平衡器上的通讯端口对应被改称为连入网络地址转换 (Inbound NAT)，网络管理人员可以决定负载平衡器的地址连入到哪一个运算资源，同样的，内部到外部也有一个来源网络地址转换 (Source NAT)，由负载平衡器自动管理，以加速资料经负载平衡器回传的速度。此类负载平衡器的来源是公用 IP，且不论是动态或静态皆可。

内部负载平衡器则是配置在虚拟网络内，其来源由虚拟网络内的子网决定 (也可设置固定的静态内部 IP)，其通讯端口对应机制与面对 Internet 的负载平衡器相同，但它的运用更多元，除了可辅助面对 Internet 的负载平衡器实现出多层次的应用负载平衡 (如对外是 Web Application 的负载平衡，对内则是 Database 的负载平衡)，也可以让企业的地端网络透过 VPN 直接存取内部负载平衡器以分散内部的流量。

分流算法

[编辑]

Azure 的负载平衡器采用分布式散列表处理来源连入的分流工作，依照负载平衡器对来源与(或)目标的参数进行散列演算，产生要分派的目标伺服器资讯。

负载平衡器早期只支持 5-tuple 的算法，分配连入的来源到不同的资源，在 2014 年时，微软宣布加入新的算法[5]，以支持如远程桌面服务 (Remote Desktop Service) 这类需要持久且固定的客户端-服务端机器的对应，因此目前负载平衡器支持三种分流算法 (Distribution Modes)：

  • 2-tuple 算法 (Source IP Affinity 算法)：使用来源IP与目标IP为参考资料。
  • 3-tuple 算法 (Source IP Affinity 算法)：使用来源IP、目标IP与通讯协议为参考资料。
  • 5-tuple 算法 (默认的算法): 使用来源IP、来源通讯端口、目标IP、目标通讯端口与通讯协议为参考资料。

存取控制

[编辑]

Azure 虚拟网络早期并没有存取控制机制，全部依赖云端服务内的虚拟机的存取控制表 (ACL)，但设置上相当不便 (有几台机器就要设几次)，因此在资源管理模式下，Azure 提供了网络安全组群 (Network Security Group) 供网络管理人员配置网络存取控制之用，网络安全组群也是一个独立组件。

网络安全组群支持流入 (inbound) 与流出 (outbound) 的 ACL 机制 (称为 ACL 规则)，ACL 使用五种资料进行散列 [6]，分别是通讯协议、来源 IP 地址范围、来源连接端口范围、目的地 IP 地址范围和目的连接端口范围，并且在散列对应成功时以其设置的优先权 (Priority) 排序 (数字愈小优先权愈高)，最后再评估其存取权限 (Allow/Deny) 决定是否允许存取。网络管理员可以针对自己的网络安全需求配置许多个 ACL 规则并组合应用。

ACL 可以套用到特定的地址范围 (例如一个 IP 或一组 IP)，或是由 Azure 定义的地址类型：

  • Internet: 来自 Internet 的 IP。
  • Azure Load Balancer: 来自于 Azure 基础建设的负载平衡器，它会以 Azure Datacenter 的 IP 范围为主，亦即套用于所有的 Azure 服务的 IP。
  • Virtual Network: 来自于虚拟网络的 IP。

网络安全组群可套用于网卡 (只有资源管理模式支持)、虚拟机 (只有传统模式支持，且只能使用指令) 以及子网配置，负载平衡器则是透过网卡来支持网络安全组群的设置。

VPN

[编辑]

Azure 虚拟网络为了与外界互连，因此提供了VPN的连线能力，早期虚拟网络只支持站对站(Site-to-Site VPN, S2S VPN)，且要求使用 IKEv1 的原则模式 (Policy-based Mode)，但 2014 年起导入了 IKEv2 的路由模式 (Route-based Mode) 后，VPN的应用范围大幅提升，目前可支持站对站、点对站 (Point-To-Site, P2S VPN)、虚拟网络间对接 (VNet-to-VNet VPN)、多站式对接 (Multi-site VPN) 以及与 Microsoft Azure ExpressRoute 对接的 VPN。

VPN 需要使用网络网关 (Network Gateway)[7]，这会决定 VPN 使用的模式是 Policy-based 或是 Route-based，并且依流量不同分成 Basic、Standard 与 Premium 三种计费模式。网关要求虚拟网络内必须配置一个子网，名称固定为 "GatewaySubnet"，地址空间限制在 /26~/29 之间，要用多大则视要对接的网关数有多少决定，因为大型虚拟网络可能要和不同的网络对接，而每一个网络使用的可能不是同一个网关。

各类 VPN 的支持如下表。

Policy-based Basic Route-based Basic Route-based Standard Route-based Premium
站对站 VPN Policy-based VPN 配置 Route-based VPN 配置 Route-based VPN 配置 Route-based VPN 配置
点对站 VPN 不支持 支持，且可与站对站VPN共存 支持，且可与站对站VPN共存 支持，且可与站对站VPN共存
验证方法 预先共享密钥 S2S: 预先共享密钥
P2S: 以证书为主		 S2S: 预先共享密钥
P2S: 以证书为主		 S2S: 预先共享密钥
P2S: 以证书为主
最大站对站连接数 1 10 10 30
最大点对站连接数 不支持 128 128 128
主动式路由支持 (BGP) 不支持 不支持 不支持 不支持

参考

[编辑]
  1. ^ Virtual Network FAQ. [2016-03-19]. （原始内容存档于2016-08-22）. 
  2. ^ IP Addresses in Azure. [2016-03-19]. （原始内容存档于2019-10-18）. 
  3. ^ 保留的 IP 概觀. [2016-03-19]. （原始内容存档于2019-10-18）. 
  4. ^ Name Resolution for VMs and Role Instances. [2016-03-19]. （原始内容存档于2015-09-05）. 
  5. ^ Azure Load Balancer new distribution mode. [2016-03-19]. （原始内容存档于2019-08-04）. 
  6. ^ What is a Network Security Group (NSG). [2016-03-19]. （原始内容存档于2016-10-30）. 
  7. ^ About VPN gateways. [2016-03-19]. （原始内容存档于2016-10-24）. 
检索自“https://zh.wikipedia.org/w/index.php?title=Microsoft_Azure_虛擬網路服務&oldid=68536959”