Azure Virtual Network là gì? Tìm hiểu VNet, Subnet, NSG từ A-Z

Azure Virtual Network (VNet) là nền tảng mạng riêng trong Microsoft Azure, cho phép các tài nguyên như Virtual Machine và nhiều dịch vụ Azure giao tiếp với nhau, với Internet và với hệ thống on-premises. VNet cung cấp không gian địa chỉ IP riêng, khả năng phân đoạn mạng bằng Subnet, kiểm soát traffic bằng Network Security Group (NSG) và kết nối giữa các mạng thông qua những cơ chế như VNet Peering hoặc VPN. Microsoft mô tả Azure Virtual Network là building block nền tảng cho private network trong Azure.

Nếu mới chuyển từ mạng truyền thống sang Cloud, VNet có thể được hình dung gần giống một mạng LAN logic trong Azure, nhưng cách triển khai linh hoạt hơn nhiều. Trong một VNet, doanh nghiệp có thể chia hệ thống thành các subnet dành cho Web, Application, Database; áp dụng NSG để kiểm soát traffic; sử dụng route table để điều hướng traffic; sau đó kết nối VNet với một VNet khác hoặc mạng nội bộ doanh nghiệp.

Hiểu VNet vì vậy không chỉ quan trọng đối với người làm Azure Administrator. Đây còn là kiến thức nền tảng cho Cloud Engineer, DevOps Engineer, Network Engineer và Security Engineer.

Azure Virtual Network là gì?

Azure Virtual Network, thường viết tắt là VNet, là một mạng riêng được định nghĩa bằng phần mềm trong Azure, cung cấp không gian địa chỉ IP và khả năng kết nối cho các tài nguyên Azure.

Mỗi VNet có một hoặc nhiều address space được xác định bằng CIDR, ví dụ:

10.0.0.0/16

Sau đó address space này có thể được chia thành nhiều subnet:

VNet: 10.0.0.0/16

├── Web Subnet
│   └── 10.0.1.0/24
│
├── App Subnet
│   └── 10.0.2.0/24
│
└── Database Subnet
    └── 10.0.3.0/24

Microsoft xác định VNet là một mạng software-defined, isolated và được scope theo Azure region. Các resource nằm trong cùng VNet có thể giao tiếp với nhau thông qua system routes mặc định; các VNet khác nhau không tự động giao tiếp nếu chưa thiết lập cơ chế kết nối phù hợp.

Điểm này rất quan trọng: VNet không phải chỉ là nơi chứa Virtual Machine. Nó là lớp networking nền tảng mà nhiều Azure workload dựa vào để giao tiếp.

Azure cho phép triển khai nhiều loại tài nguyên vào VNet, bao gồm VM, Azure Kubernetes Service, Virtual Machine Scale Sets và nhiều dịch vụ khác tùy khả năng tích hợp mạng của từng dịch vụ.

VNet có vai trò gì trong Azure?

Có thể xem VNet là lớp nền để giải quyết bốn bài toán networking chính:

Kết nối: cho phép các Azure resources giao tiếp với nhau.

Phân đoạn: chia một network lớn thành nhiều subnet theo workload hoặc security boundary.

Kiểm soát truy cập: sử dụng NSG để quyết định traffic nào được phép hoặc bị từ chối.

Kết nối hybrid: kết nối Azure với các VNet khác hoặc infrastructure on-premises thông qua những công nghệ như VNet Peering, VPN Gateway và ExpressRoute.

Nếu không có kiến trúc VNet phù hợp, việc triển khai một hệ thống Azure lớn rất dễ dẫn đến các vấn đề như IP address overlap, security rule phức tạp, routing khó kiểm soát hoặc không thể mở rộng hạ tầng.

Đặc biệt, Microsoft khuyến nghị phải lập kế hoạch address space ngay từ đầu nếu VNet có khả năng kết nối với VNet khác hoặc mạng on-premises. Các address range bị overlap có thể gây khó khăn đáng kể cho việc kết nối sau này.

Kiến trúc Azure VNet gồm những thành phần nào?

Để hiểu Azure Networking, không nên học VNet, Subnet và NSG như ba khái niệm độc lập. Chúng nằm trong cùng một architecture.

Một mô hình đơn giản:

                    Azure Virtual Network
                         10.0.0.0/16
                              |
              +---------------+---------------+
              |                               |
        Web Subnet                         App Subnet
        10.0.1.0/24                       10.0.2.0/24
              |                               |
           Web VM                           App VM
              |                               |
             NIC                             NIC
              |                               |
           NSG-Web                        NSG-App

Ở đây:

• VNet cung cấp network boundary.
• Subnet chia VNet thành các network segment.
• NIC kết nối VM vào subnet.
• Private IP cung cấp địa chỉ giao tiếp nội bộ.
• NSG kiểm soát traffic.
• Route table có thể điều chỉnh đường đi của traffic.
• Public IP có thể được sử dụng khi resource cần kết nối Internet theo mô hình phù hợp.

VNet

VNet là network container ở cấp logic. Nó sở hữu address space và chứa các subnet.

Address Space và CIDR

Khi tạo VNet, cần khai báo address space, ví dụ:

10.0.0.0/16

Từ đó có thể chia thành nhiều subnet.

Việc lựa chọn address space không nên chỉ dựa vào số lượng VM hiện tại. Cần tính đến khả năng mở rộng và khả năng kết nối với các network khác.

Ví dụ:

10.0.0.0/16

có thể được chia thành:

10.0.1.0/24
10.0.2.0/24
10.0.3.0/24
10.0.4.0/24

Azure sử dụng CIDR để xác định address ranges của VNet và subnet.

Subnet

Subnet là một phần address space của VNet.

Ví dụ:

VNet = 10.0.0.0/16

Subnet Web = 10.0.1.0/24
Subnet App = 10.0.2.0/24
Subnet DB  = 10.0.3.0/24

Subnet thường được thiết kế dựa trên workload, role hoặc security boundary.

Network Interface

Azure VM giao tiếp với network thông qua Network Interface Card (NIC).

Có thể hình dung:

VM
 ↓
NIC
 ↓
Subnet
 ↓
VNet

Mỗi NIC của VM được kết nối vào một subnet trong một VNet.

Private IP và Public IP

Private IP được sử dụng để giao tiếp trong VNet hoặc các network được kết nối với VNet.

Public IP phục vụ các trường hợp resource cần khả năng giao tiếp với Internet theo kiến trúc được thiết kế.

Đây là một điểm quan trọng về bảo mật: không phải VM nào cũng cần Public IP.

Một kiến trúc an toàn hơn có thể đặt:

Internet
   ↓
Application Gateway / Load Balancer
   ↓
Web Tier
   ↓
Application Tier
   ↓
Database Tier

thay vì đưa Public IP trực tiếp cho mọi VM.

Azure Subnet là gì?

Subnet trong Azure là một dải địa chỉ IP được phân chia từ address space của VNet, dùng để tổ chức tài nguyên thành các network segment khác nhau.

Ví dụ:

VNet
10.0.0.0/16
│
├── Web
│   10.0.1.0/24
│
├── Application
│   10.0.2.0/24
│
└── Database
    10.0.3.0/24

Subnet không chỉ giúp “chia nhỏ IP”.

Đây còn là một điểm gắn chính sách networking. Microsoft xác định subnet là scope để gắn Network Security Group và route table.

Một thiết kế subnet hợp lý thường dựa trên câu hỏi:

Những resource nào có cùng chức năng và cùng yêu cầu security?

Ví dụ:

Web servers
      ↓
Web Subnet

Application servers
      ↓
App Subnet

Database servers
      ↓
Database Subnet

Cách phân đoạn này giúp administrator xây dựng security policy khác nhau cho từng tầng.

VNet và Subnet khác nhau như thế nào?

Có thể hiểu rất đơn giản:

VNet là mạng lớn; Subnet là các phân đoạn bên trong mạng đó.

Ví dụ:

VNet: 10.0.0.0/16
│
├── Subnet A: 10.0.1.0/24
├── Subnet B: 10.0.2.0/24
└── Subnet C: 10.0.3.0/24

Một sai lầm phổ biến là nghĩ rằng:

“Tách subnet = tự động cô lập network.”

Không hoàn toàn như vậy.

Microsoft lưu ý rằng các subnet trong cùng VNet có thể giao tiếp với nhau theo mặc định thông qua system routes; bản thân việc tạo subnet không tạo ra security boundary hoàn chỉnh. Nếu cần kiểm soát traffic giữa các subnet, cần sử dụng NSG hoặc các cơ chế kiểm soát mạng phù hợp.

Đây là khác biệt rất quan trọng giữa network segmentation và security segmentation.

Network Security Group (NSG) là gì?

Network Security Group (NSG) là tập hợp các rule dùng để cho phép hoặc từ chối network traffic đến và đi từ Azure resources.

NSG có thể được associate với:

• Subnet.
• Network Interface của VM.

Một NSG chứa các rule inbound và outbound. Mỗi rule xác định các thuộc tính như:

• Source.
• Source port.
• Destination.
• Destination port.
• Protocol.
• Direction.
• Priority.
• Allow/Deny.

Microsoft mô tả NSG như một cơ chế stateful packet filtering dựa trên IP address và TCP/UDP protocols.

Ví dụ:

Source: Internet
Destination: Web Subnet
Protocol: TCP
Port: 443
Action: Allow

Rule này cho phép HTTPS traffic đi vào workload theo phạm vi được xác định.

Trong khi:

Source: Internet
Destination: Database Subnet
Protocol: TCP
Port: 1433
Action: Deny

có thể được sử dụng để ngăn truy cập trực tiếp từ Internet đến SQL Server workload.

NSG hoạt động như thế nào?

NSG sử dụng hệ thống priority để đánh giá các security rules.

Một rule có priority nhỏ hơn sẽ được xử lý trước rule có priority lớn hơn.

Ví dụ:

Priority 100
Allow TCP 443

Priority 200
Deny Internet

HTTPS traffic có thể được allow bởi rule 100 trước khi rule 200 được xét.

Vì vậy, thiết kế NSG không chỉ là viết nhiều rule. Quan trọng hơn là thiết kế thứ tự và phạm vi rule đúng.

NSG có các default security rules được Azure tạo sẵn và các custom rules do administrator cấu hình. Default rules có priority thấp hơn custom rules nên không thể bị ghi đè bằng một rule có priority cao hơn theo cách hiểu thông thường của precedence.

Inbound và Outbound

NSG xử lý hai chiều traffic:

Internet
   ↓
Inbound
   ↓
VM
   ↓
Outbound
   ↓
Internet / Other Network

Với inbound traffic, nếu cả subnet và NIC đều có NSG, Azure đánh giá NSG ở subnet trước rồi đến NSG ở NIC.

Với outbound traffic, thứ tự ngược lại: NIC-level NSG trước rồi subnet-level NSG.

Điều này rất quan trọng khi troubleshooting.

Một administrator có thể nhìn vào NSG của subnet và thấy rule Allow, nhưng traffic vẫn bị chặn vì một NSG gắn ở NIC có rule Deny.

NSG nên gắn vào Subnet hay NIC?

Câu trả lời phụ thuộc vào mục đích.

Gắn NSG vào Subnet phù hợp khi muốn áp dụng chính sách chung cho toàn bộ workload trong subnet.

Ví dụ:

Web Subnet
     ↓
NSG-Web
     ↓
Tất cả Web VM

Gắn NSG vào NIC phù hợp khi cần chính sách riêng cho một network interface cụ thể.

Microsoft cho phép associate NSG với cả subnet và NIC. Khi cả hai cùng tồn tại, các rule của chúng đều tham gia vào quá trình đánh giá traffic.

Trong môi trường production, nên tránh tạo một hệ thống NSG quá phức tạp đến mức administrator không thể trả lời nhanh:

Traffic này đang bị chặn ở đâu?

Thiết kế càng rõ ràng, troubleshooting càng dễ.

VNet, Subnet và NSG phối hợp với nhau như thế nào?

Có thể hình dung toàn bộ architecture như sau:

                    Azure
                      │
             Virtual Network
               10.0.0.0/16
                      │
        ┌─────────────┼─────────────┐
        │             │             │
      Web           App             DB
    Subnet          Subnet         Subnet
        │             │             │
     NSG-Web       NSG-App       NSG-DB
        │             │             │
      Web VM       App VM        DB VM

Traffic:

Internet
   ↓
Web VM : 443
   ↓
App VM : 8080
   ↓
DB VM : 1433

Security policy có thể được thiết kế:

Internet → Web : HTTPS       ALLOW
Internet → App : Any         DENY
Internet → DB  : Any         DENY

Web → App : Application Port  ALLOW
Web → DB  : Any               DENY

App → DB : Database Port      ALLOW

Đây là cách tư duy tốt hơn so với việc chỉ hỏi:

“NSG nên mở port nào?”

Câu hỏi đúng phải là:

Ai cần giao tiếp với ai, bằng protocol/port nào và vì mục đích gì?

Ví dụ thiết kế Azure VNet cho ứng dụng 3 tầng

Một ứng dụng web điển hình có thể được thiết kế:

                       Internet
                           │
                     HTTPS : 443
                           │
                Application Gateway
                           │
                    Web Subnet
                    10.0.1.0/24
                           │
                     App Subnet
                    10.0.2.0/24
                           │
                      DB Subnet
                    10.0.3.0/24

Mỗi tầng có một security requirement khác nhau.

Web Subnet

Có thể nhận HTTPS từ Internet.

Internet → Web
TCP 443 → ALLOW

App Subnet

Không cần nhận traffic trực tiếp từ Internet.

Internet → App
DENY

Chỉ cho phép Web Tier gọi Application Tier theo port ứng dụng cần thiết.

Database Subnet

Database càng cần được hạn chế phạm vi truy cập.

Internet → Database
DENY

Web → Database
DENY

Application → Database
TCP 1433 → ALLOW

Microsoft cũng sử dụng mô hình nhiều subnet cho các workload nhiều tầng và khuyến nghị phân tách resource theo workload/security boundary.

Điểm quan trọng ở đây là Subnet tạo cấu trúc, NSG thực thi chính sách truy cập.

Azure VNet Peering là gì?

Khi một hệ thống có nhiều VNet, chúng có thể cần giao tiếp với nhau.

VNet Peering cho phép kết nối hai VNet thông qua mạng backbone của Microsoft với độ trễ thấp, kể cả khi hai VNet nằm ở các region khác nhau.

Ví dụ:

VNet-Production
10.0.0.0/16
       │
       │ VNet Peering
       │
VNet-Shared-Services
10.1.0.0/16

Một lỗi thiết kế rất quan trọng cần tránh là overlapping address space.

Ví dụ:

VNet A: 10.0.0.0/16
VNet B: 10.0.0.0/16

Khi cần kết nối hai network này, việc overlap IP có thể gây ra vấn đề định tuyến.

Vì vậy, address planning phải được thực hiện trước khi hạ tầng phát triển lớn, không nên đợi đến lúc cần peering mới bắt đầu nghĩ về IP architecture.

Ngoài ra, VNet Peering không phải kết nối transitive. Nếu A peer với B và B peer với C, điều đó không tự động tạo kết nối A → C. Microsoft xác định peering là kết nối trực tiếp giữa các VNet.

Routing trong Azure VNet

Nếu NSG trả lời câu hỏi:

Traffic có được phép đi hay không?

thì routing trả lời:

Traffic sẽ đi theo đường nào?

Azure cung cấp system routes mặc định. Trong những kiến trúc phức tạp hơn, administrator có thể sử dụng Route Table/User Defined Routes – UDR để kiểm soát đường đi của traffic.

Ví dụ:

Application Subnet
        │
        ↓
Azure Firewall
        │
        ↓
Internet

Thay vì cho application workload đi thẳng ra Internet, tổ chức có thể buộc traffic đi qua firewall để inspection.

Microsoft xác định route table/UDR là cơ chế dùng để override system routes và điều khiển traffic, chẳng hạn buộc traffic đi qua firewall hoặc Network Virtual Appliance.

Đây là lúc kiến thức Azure Networking bắt đầu chuyển từ mức “học từng dịch vụ” sang thiết kế network architecture.

Những sai lầm thường gặp khi thiết kế Azure VNet

Chọn IP address space quá nhỏ

Một VNet ban đầu chỉ có vài VM nhưng sau đó phát triển thành hàng chục workload. Nếu address space được thiết kế quá nhỏ, việc mở rộng có thể trở nên khó khăn.

Microsoft khuyến nghị tránh các VNet/subnet quá nhỏ để giữ không gian cho tăng trưởng trong tương lai.

Nghĩ rằng Subnet tự động tạo security boundary

Subnet giúp segmentation nhưng không đồng nghĩa với việc mọi traffic giữa các subnet tự động bị chặn.

Các subnet trong cùng VNet có thể giao tiếp theo system routes; muốn kiểm soát traffic cần có NSG hoặc cơ chế security phù hợp.

Mở 0.0.0.0/0 quá rộng

Một rule kiểu:

Source: Any
Destination: Any
Port: Any
Action: Allow

có thể tạo ra attack surface rất lớn.

Microsoft khuyến nghị tránh những allow rule quá rộng và áp dụng nguyên tắc deny-by-default, permit-by-exception khi thiết kế network security.

Chỉ quan tâm inbound mà quên outbound

Một workload có thể không nhận traffic từ Internet nhưng vẫn tạo kết nối outbound. Vì vậy security policy cần xem xét cả hai chiều.

Gắn quá nhiều NSG rule

NSG càng nhiều rule không đồng nghĩa với càng an toàn. Rule cần có mục đích rõ ràng, phạm vi hợp lý và có khả năng audit.

Không tính đến hybrid connectivity

Nếu hệ thống có khả năng kết nối với data center hoặc hệ thống khác trong tương lai, cần tính đến IP overlap ngay từ giai đoạn thiết kế.

Azure VNet và bảo mật theo Zero Trust

Trong kiến trúc hiện đại, VNet không nên được xem là một “vùng tin cậy tuyệt đối”.

Microsoft khuyến nghị tiếp cận network security theo các nguyên tắc Zero Trust như:

• Verify explicitly.
• Use least privilege access.
• Assume breach.

Đối với VNet, điều này thể hiện ở việc phân đoạn workload, hạn chế traffic giữa các tầng, chỉ cho phép connection thực sự cần thiết và giảm lateral movement khi một workload bị compromise.

Ví dụ thay vì:

Internet
   ↓
All VMs

có thể thiết kế:

Internet
   ↓
Public Entry Point
   ↓
Web Tier
   ↓
Application Tier
   ↓
Database Tier

và mỗi tầng có security policy riêng.

Khi đó, nếu Web Tier bị compromise, attacker không mặc nhiên có quyền truy cập trực tiếp đến Database Tier.

Đây chính là giá trị lớn của việc kết hợp VNet + Subnet + NSG: không chỉ tổ chức network mà còn tạo các lớp kiểm soát để hạn chế phạm vi ảnh hưởng của một sự cố.

Người học Azure cần biết gì về VNet?

Nếu mục tiêu chỉ là tạo một Azure VM để thử nghiệm, người học có thể nhanh chóng tạo VNet, subnet và NSG thông qua Azure Portal.

Nhưng với mục tiêu trở thành Azure Administrator hoặc Cloud Engineer, cần hiểu sâu hơn:

IP Address
    ↓
CIDR
    ↓
VNet
    ↓
Subnet
    ↓
NIC
    ↓
NSG
    ↓
Routing
    ↓
VNet Peering
    ↓
VPN / ExpressRoute
    ↓
Firewall
    ↓
Hybrid / Multi-cloud Architecture

Đặc biệt, cần phân biệt rõ ba câu hỏi:

VNet: Resource này thuộc network nào?

Subnet: Resource này nằm trong network segment nào?

NSG: Resource này được phép giao tiếp với ai và qua port/protocol nào?

Sau đó mới đến câu hỏi thứ tư:

Routing: Traffic sẽ đi qua đâu?

Đây là cách tư duy giúp người học không chỉ nhớ khái niệm để làm bài thi mà có thể đọc và phân tích một Azure network architecture thực tế.

Kết luận

Azure Virtual Network là nền tảng của Azure Networking. VNet cung cấp network boundary và address space; Subnet giúp phân đoạn workload; NIC kết nối resource vào network; NSG kiểm soát traffic; còn routing quyết định đường đi của traffic. Các thành phần này không nên được học riêng lẻ mà cần được nhìn như một architecture thống nhất.

Một thiết kế Azure VNet tốt không đơn giản là tạo một VNet rồi chia thành vài subnet. Nó bắt đầu từ IP address planning, xác định workload, phân chia security boundary, thiết kế NSG, kiểm soát routing và tính đến khả năng mở rộng cũng như hybrid connectivity.

Đối với người mới, có thể bắt đầu bằng mô hình:

VNet
 ↓
Subnet
 ↓
VM + NIC
 ↓
NSG
 ↓
Routing

Sau khi nắm chắc nền tảng này, có thể mở rộng sang VNet Peering, Azure Firewall, Application Gateway, VPN Gateway, ExpressRoute, Private Endpoint, Azure Bastion và hub-and-spoke architecture. Đây cũng là nền tảng kiến thức quan trọng khi đi sâu vào quản trị Azure, Cloud Infrastructure và DevOps.