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) | 不支援 | 不支援 | 不支援 | 不支援 |
参考[编辑]
- ^ Virtual Network FAQ. [2016-03-19]. （原始内容存档于2016-08-22）.
- ^ IP Addresses in Azure. [2016-03-19]. （原始内容存档于2019-10-18）.
- ^ 保留的 IP 概觀. [2016-03-19]. （原始内容存档于2019-10-18）.
- ^ Name Resolution for VMs and Role Instances. [2016-03-19]. （原始内容存档于2015-09-05）.
- ^ Azure Load Balancer new distribution mode. [2016-03-19]. （原始内容存档于2019-08-04）.
- ^ What is a Network Security Group (NSG). [2016-03-19]. （原始内容存档于2016-10-30）.
- ^ About VPN gateways. [2016-03-19]. （原始内容存档于2016-10-24）.
| ||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
