虚拟网络的配置是所有公有云中非常重要的环节。把虚拟网络配置好，对整个系统的管理、维护，以及安全性都非常重要。
本文将介绍Azure在ARM模式下VNet配置中需要特别注意的几点。
一 Azure的VNet架构
Azure的虚拟网络叫做VNet，VNet内部有多个Subnet和一个Gateway Subnet。
Subnet是VM所在的子网，类似于企业网络中的VLAN；Gateway Subnet是VPN网关和ER网关所在的网段。
1. 只有Internet接入时VNet的架构
对于一般的企业应用，如下的架构就可以满足需求：
在这种拓扑结构中，有多个生产网段：Web、APP和DB，以及一个管理网段Mgmt。这四个网段都可以通过Internet Gateway连接到Internet。
2. 有IPSec VPN接入的架构
在这种架构中，有4个Subnet外，还有一个Gateway Subnet。在这个Subnet中，有两台VPN Gateway（Azure的Gateway总是成对出现的）。这个VPN GW负责和企业内部的VPN GW打通IPSec VPN。此时，企业的内部网络和Azure的VNet就打通了。两边可以通过内部网络互相访问。但由于IPSec VPN是通过Internet连接的。企业重要的应用，IPSec VPN在可靠性和安全性上都满足不了企业的需求。
3. 有ER接入的架构
这种架构有些类似于上种架构，只是连接企业的方式改成了MSTP的Express Route模式。由于MSTP是基于SDH的网络，可靠性和安全性都有了大大的提升。
4. IPSec VPN作为ER的备份
Azure的Express Route是两根链路接入到Azure的，所以ER是有99.9%的SLA的。但有些客户还是希望有IPSec VPN作为ER的备份。如上的拓扑结构就是IPSec VPN作为Express Route的备份的架构。这种架构下，VNet的Subnet Gateway中有两组Gateway，一组是VPN GW，另外一组是ER Gateway。此时需要VPN GW和ER GW都是Standard以上类型，且VPN GW要求支持BGP。也就是说，VNet和企业间的路由是通过BGP打通的。但这种情况下，目前IPSec VPN只能作为Express Route的备份。Express Route出现故障时，只能手动把流量导到IPSec VPN，还不能实现自动的IPSec VPN自动切换。
二 VNet中的地址问题
在如上的架构中有一个需要解决的问题，就是企业一般会要求APP、DB等内部网络不能连接Internet。而对生产网段，即Web、APP和DB网段的SSH、RDP等管理协议的端口都不能对外网开放，而应该通过管理网段中的堡垒机或跳板机接入这些网段中的VM。
为满足这些需求，我们先来讨论一下Azure VM的地址，比如对Web Subnet中的两台VM：
每台VM都有三种地址：
- 在VM内部能够看到的DIP地址
- 每个VM对应的PIP地址（这个地址就是ASM模式中的Public IP地址）
- 每个VM对应负载均衡（SLB）的地址VIP（这个地址在ASM模式中是cloud service的地址）
DIP地址是VM在NAT之前的地址，PIP和VIP都是VM在NAT之后的地址。但这两个地址有如下一些不同：
- PIP地址只能给一台机器使用；而VIP地址可以给一台，也可以给多台使用，实现负载均衡
- PIP地址不需要做NAT的规则，PIP地址和DIP地址之间NAT是全开的，从外网可以通过PIP地址对VM进行扫描；VIP地址需要做NAT规则，需要开放的端口才做NAT规则，不需要开放的端口不开放，从外网扫描不到。比如，VM1开放了SSH的TCP 22端口和WEB的TCP 80两个端口，如果VM1配置了PIP地址和VIP地址，同时VIP地址开放了HTTP的负载均衡。此时，通过PIP地址可以看到VM1开放的TCP 22和80端口，而通过VIP地址只能看到VM1开放的TCP 80端口
- PIP地址在做了与DIP地址1：1的NAT外，还开放了ICMP协议，所以，如果VM配置了PIP地址，这台VM是可以ping的；而VIP地址没有开放ICMP协议，是不能ping的。
VIP地址除了做负载均衡，还有一个非常重要的属性，可以做Inbound NAT Rule，就是做Port Mapping端口翻译。如下图：
相同的TCP 22端口通过VIP的翻译成22122和22222。通过这个功能，可以把一些Well Known的端口保护起来，特别是管理端口。
具体的配置项在Azure的新Portal的：
根据上面的介绍，不同的网段应该采用不同的策略来配置DIP、VIP和PIP。
1. WEB网段
这个网段的VM需要对外部提供网络服务。这个网段一般开启VIP地址，实现负载均衡：
这个网段的VM一般不需要开启PIP地址。
2. APP、DB网段
这个网段，一般不需要和外部网络通讯，只需要和本VNet内的虚拟机通讯，所以这种网段的VM只要配置DIP地址就OK：
这种配置下，只有通过内部网段地址才能访问这些虚拟机。
3. Mgmt网段
这个网段，需要接受外部网段来访问VM的管理的端口，比如SSH或RDP。这种网段建议采用VIP的Inbound Nat Rule做Port Mapping来实现隐藏管理端口实现对外部提供服务的功能。
当然也可以采用PIP地址来实现对外提供管理功能的端口，但这样的安全隐患比较大，不建议使用。
4. 其他网段
对于一些特殊网段，这些网段内的VM有一些特殊需求，比如：
- 要求开ICMP进行特殊工作
- 要求打开大量端口
- 突破SNAT（Source NAT）对Session数（每秒钟160个）的限制
这时开PIP是非常有效的。另外，对一些测试机器，对安全性等没有太多需求，开PIP是比较方便的。
三 VNet中的安全功能-NSG
NSG是Network Security Group的缩写，相当于网络的ACL。它支持：
- 支持入向、出向的安全控制
- 支持应用到网段、VM上
针对我们前面提到的4种网段，NSG的设置如下：
1. WEB网段
允许80端口和VNet内部的22端口访问
2. APP、DB网段
这两个网段除允许VNet内部的互相访问外，对外的访问都要屏蔽
大家注意最后一条，虽然是Deny any，但前面允许的Inbound Rule的流量是可以出去的。所以NSG的工作类似于防火墙的基于状态的过滤。
3. Mgmt网段
这个网段需要允许外部访问管理端口，比如TCP 22，其他的不允许进入。出方向可以访问any。
4. 其他网段
由于开启了PIP，相当于VM暴露在公网上，所以，对安全性要求非常高。此时的NSG要精细设置，防止出现安全隐患。
四 VNet中的VM访问PaaS的问题
目前Azure的PaaS服务大部分都还是基于公网地址的。只有部分PaaS服务是可以运行在VNet内的。比如：Redis、Web APP和HDInsight。其他的服务目前还都需要通过域名的方式访问。
当然还有其他一些应用，比如yum、apt-get、windows update等等各种更新服务，都需要访问外部网络。这时需要对VNet中的Subnet进行特殊的安全设置。目前有两种方式：
1．采用NSG的方式
方法和前文相同，这里就不再详细展开了。只是对Outbound进行精细的控制。明确指明哪些是可以访问的，哪些是不能访问的。
2. 采用UDR（User Define Route）的方式
这种方式是定义路由表的方式，前文中描述的，一些地址是要求能够访问的，其他地址不能访问，可以通过路由的方式实现。以APP层需要访问Azure的MySQL PaaS为例：
APP层的VM需要访问Azure China East的地址，除此之外的公网地址都不能访问。
增加Route Table的配置，Azure China East的所有地址都加入Internet路由表，默认路由指向None。
具体Route Table的配置如下：
将此Route Table关联到APP的Subnet就OK了。
图中还画了一个虚线的VIP负载均衡地址。这个地址的主要功能是给Azure的PaaS添加白名单使用。通过这个VIP固定公网IP地址，使得Azure PaaS的白名单容易部署。
两种方式都可以实现对外访问的精细控制。但在一种情况下，Route Table的模式比NSG的模式好：当VM开启了PIP地址，由于NSG不能对ICMP进行控制，这时的表现是：可以Ping通外部网络，但不能访问。而用Route Table进行控制就可以阻止Ping通外网。
总结：在Azure的VNet中，每个VM都有DIP、PIP、VIP三种地址。另外对各个Subnet的安全控制，需要通过NSG、Route Table等功能实现。不同的Subnet有不同的策略和实现方式。