虛擬網路的配置是所有公有云中非常重要的環節。把虛擬網路配置好，對整個系統的管理、維護，以及安全性都非常重要。
本文將介紹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有不同的策略和實現方式。