Tweet
Khi học Azure AZ-104, Azure Virtual Network (VNet) là một trong những kiến thức nền tảng mà Azure Administrator cần nắm chắc. Tuy nhiên, thay vì chỉ học cách tạo VNet trên Azure Portal, chúng ta nên thực hành theo một scenario gần với môi trường doanh nghiệp: workload được phân chia thành nhiều subnet và sử dụng Network Security Group (NSG) để kiểm soát traffic.
Trong bài lab này, chúng ta sẽ triển khai 1 VNet, 2 Subnet và 2 Windows Server VM, sau đó cấu hình NSG để tạo ra tình huống traffic được Allow/Deny và sử dụng Network Watcher để troubleshooting.
Giả sử doanh nghiệp có hai workload:
Yêu cầu:
IP Plan:
VNET-AZ104 10.10.0.0/16
Web-Subnet 10.10.1.0/24
App-Subnet 10.10.2.0/24 2. TẠO VNET VÀ SUBNET
Trên Azure Portal chọn:
Virtual Networks → Create
Tạo Resource Group:
RG-AZ104-Network
VNet:
Name: VNET-AZ104
Address Space: 10.10.0.0/16
Tạo hai subnet:
Web-Subnet
10.10.1.0/24
App-Subnet
10.10.2.0/24
Sau khi Create, kiểm tra lại Address Space và subnet. Việc thiết kế IP ngay từ đầu rất quan trọng vì nó ảnh hưởng trực tiếp đến routing, peering và khả năng mở rộng network về sau. 3. DEPLOY 2 AZURE VM
Tạo VM đầu tiên:
Virtual Machines → Create → Azure virtual machine
Cấu hình:
Name: Web-VM
VNet: VNET-AZ104
Subnet: Web-Subnet
Public IP: Yes
Tạo VM thứ hai:
Name: App-VM
VNet: VNET-AZ104
Subnet: App-Subnet
Public IP: None
Sau khi triển khai xong, vào:
VM → Networking → Network settings
Ghi lại private IP của từng VM.
Ví dụ:
Web-VM = 10.10.1.4
App-VM = 10.10.2.4
Không nên giả định IP luôn giống ví dụ trên; hãy sử dụng IP thực tế Azure cấp cho VM. 4. TẠO VÀ GÁN NSG
Tạo hai Network Security Group:
NSG-Web
NSG-App
Sau đó associate:
NSG-Web → Web-Subnet
NSG-App → App-Subnet
Trong lab này, NSG được gắn ở subnet để minh họa việc áp dụng policy cho cả network segment. NSG-Web
Tạo Inbound Rule cho HTTP:
Source: Any
Destination: Any
Protocol: TCP
Destination Port: 80
Action: Allow
Priority: 100
Name: Allow-HTTP
Nếu cần HTTPS, tạo thêm rule cho TCP/443.
Không nên sử dụng kiểu Any → Any → Allow chỉ để đảm bảo kết nối. Trong môi trường thực tế, nên áp dụng nguyên tắc Least Privilege. NSG-App
Tạo rule cho phép Web-Subnet truy cập App-VM qua TCP/80:
Source: 10.10.1.0/24
Destination: 10.10.2.0/24
Protocol: TCP
Destination Port: 80
Action: Allow
Priority: 100
Name: Allow-Web-to-App-HTTP
Không tạo rule Allow RDP từ Internet cho App-VM. 5. TEST TRAFFIC ALLOW/DENY
Đăng nhập Web-VM và mở PowerShell.
Kiểm tra kết nối đến App-VM:
Test-NetConnection 10.10.2.4 -Port 80
Nếu App-VM đang chạy Web Service trên port 80 và NSG được cấu hình đúng:
TcpTestSucceeded : True
Tiếp tục kiểm tra port 3389:
Test-NetConnection 10.10.2.4 -Port 3389
Nếu không có rule cho phép RDP:
TcpTestSucceeded : False
Đây là điểm quan trọng của bài lab: cùng source và destination nhưng khác destination port có thể cho kết quả Allow/Deny khác nhau.
Qua đó có thể phân biệt rõ:
Network Connectivity ≠ Network Security
Hai VM có thể kết nối ở mức network nhưng từng loại traffic vẫn có thể bị NSG kiểm soát. 6. TROUBLESHOOT BẰNG NETWORK WATCHER
Khi kết nối thất bại, không nên sửa NSG một cách ngẫu nhiên.
Truy cập:
Network Watcher → IP flow verify
Kiểm tra flow:
Source IP: 10.10.1.4
Destination IP: 10.10.2.4
Protocol: TCP
Destination: Port 80
Azure sẽ trả về:
Access: Allow
hoặc:
Access: Deny
Quan trọng hơn, kết quả có thể cho biết security rule nào đang quyết định flow.
Nếu IP flow verify cho phép nhưng ứng dụng vẫn không kết nối được, tiếp tục kiểm tra:
Đây là tư duy troubleshooting quan trọng đối với Azure Administrator. 7. MỞ RỘNG LAB
Sau khi hoàn thành bài lab cơ bản, có thể mở rộng theo hướng enterprise:
Khi đó, người học có thể tiếp tục phân tích: traffic đi đâu, route nào được sử dụng, NSG nào tác động và firewall có chặn traffic hay không. KẾT LUẬN
Điểm quan trọng nhất của bài lab không phải là tạo được một VNet, mà là hiểu được toàn bộ flow:
Source → Destination → Route → NSG → Application
Khi troubleshooting một kết nối Azure, hãy tập thói quen kiểm tra theo thứ tự:
Private IP → Port → NSG → Route → Firewall → Application Service.
Đây chính là tư duy cần có của một Azure Administrator: không chỉ biết triển khai resource mà còn phải đọc được network flow, kiểm tra security rule và xác định nguyên nhân khi connectivity xảy ra sự cố.
Đây cũng là nền tảng để tiếp tục thực hành các nội dung AZ-104 nâng cao như VNet Peering, Load Balancer, Azure Bastion, Route Table và Azure Firewall.
Trong bài lab này, chúng ta sẽ triển khai 1 VNet, 2 Subnet và 2 Windows Server VM, sau đó cấu hình NSG để tạo ra tình huống traffic được Allow/Deny và sử dụng Network Watcher để troubleshooting.
Mô hình lab: Hình ảnh minh họa kèm theo bài viết mô phỏng VNet, Web-Subnet, App-Subnet, hai VM, NSG và luồng traffic giữa các thành phần.
1. SCENARIO VÀ IP PLANGiả sử doanh nghiệp có hai workload:
- Web-VM: máy chủ Web, đặt trong Web-Subnet.
- App-VM: máy chủ Application, đặt trong App-Subnet.
Yêu cầu:
- Web-VM được phép nhận HTTP/HTTPS.
- Web-VM được phép truy cập App-VM qua TCP/80.
- App-VM không được phép nhận RDP trực tiếp từ Internet.
- Các traffic không cần thiết phải bị chặn.
IP Plan:
VNET-AZ104 10.10.0.0/16
Web-Subnet 10.10.1.0/24
App-Subnet 10.10.2.0/24 2. TẠO VNET VÀ SUBNET
Trên Azure Portal chọn:
Virtual Networks → Create
Tạo Resource Group:
RG-AZ104-Network
VNet:
Name: VNET-AZ104
Address Space: 10.10.0.0/16
Tạo hai subnet:
Web-Subnet
10.10.1.0/24
App-Subnet
10.10.2.0/24
Sau khi Create, kiểm tra lại Address Space và subnet. Việc thiết kế IP ngay từ đầu rất quan trọng vì nó ảnh hưởng trực tiếp đến routing, peering và khả năng mở rộng network về sau. 3. DEPLOY 2 AZURE VM
Tạo VM đầu tiên:
Virtual Machines → Create → Azure virtual machine
Cấu hình:
Name: Web-VM
VNet: VNET-AZ104
Subnet: Web-Subnet
Public IP: Yes
Tạo VM thứ hai:
Name: App-VM
VNet: VNET-AZ104
Subnet: App-Subnet
Public IP: None
Sau khi triển khai xong, vào:
VM → Networking → Network settings
Ghi lại private IP của từng VM.
Ví dụ:
Web-VM = 10.10.1.4
App-VM = 10.10.2.4
Không nên giả định IP luôn giống ví dụ trên; hãy sử dụng IP thực tế Azure cấp cho VM. 4. TẠO VÀ GÁN NSG
Tạo hai Network Security Group:
NSG-Web
NSG-App
Sau đó associate:
NSG-Web → Web-Subnet
NSG-App → App-Subnet
Trong lab này, NSG được gắn ở subnet để minh họa việc áp dụng policy cho cả network segment. NSG-Web
Tạo Inbound Rule cho HTTP:
Source: Any
Destination: Any
Protocol: TCP
Destination Port: 80
Action: Allow
Priority: 100
Name: Allow-HTTP
Nếu cần HTTPS, tạo thêm rule cho TCP/443.
Không nên sử dụng kiểu Any → Any → Allow chỉ để đảm bảo kết nối. Trong môi trường thực tế, nên áp dụng nguyên tắc Least Privilege. NSG-App
Tạo rule cho phép Web-Subnet truy cập App-VM qua TCP/80:
Source: 10.10.1.0/24
Destination: 10.10.2.0/24
Protocol: TCP
Destination Port: 80
Action: Allow
Priority: 100
Name: Allow-Web-to-App-HTTP
Không tạo rule Allow RDP từ Internet cho App-VM. 5. TEST TRAFFIC ALLOW/DENY
Đăng nhập Web-VM và mở PowerShell.
Kiểm tra kết nối đến App-VM:
Test-NetConnection 10.10.2.4 -Port 80
Nếu App-VM đang chạy Web Service trên port 80 và NSG được cấu hình đúng:
TcpTestSucceeded : True
Tiếp tục kiểm tra port 3389:
Test-NetConnection 10.10.2.4 -Port 3389
Nếu không có rule cho phép RDP:
TcpTestSucceeded : False
Đây là điểm quan trọng của bài lab: cùng source và destination nhưng khác destination port có thể cho kết quả Allow/Deny khác nhau.
Qua đó có thể phân biệt rõ:
Network Connectivity ≠ Network Security
Hai VM có thể kết nối ở mức network nhưng từng loại traffic vẫn có thể bị NSG kiểm soát. 6. TROUBLESHOOT BẰNG NETWORK WATCHER
Khi kết nối thất bại, không nên sửa NSG một cách ngẫu nhiên.
Truy cập:
Network Watcher → IP flow verify
Kiểm tra flow:
Source IP: 10.10.1.4
Destination IP: 10.10.2.4
Protocol: TCP
Destination: Port 80
Azure sẽ trả về:
Access: Allow
hoặc:
Access: Deny
Quan trọng hơn, kết quả có thể cho biết security rule nào đang quyết định flow.
Nếu IP flow verify cho phép nhưng ứng dụng vẫn không kết nối được, tiếp tục kiểm tra:
- Windows Firewall trên VM.
- Web Service có thực sự chạy hay không.
- Private IP/NIC.
- Route đến destination.
- Application đang listen trên port nào.
Đây là tư duy troubleshooting quan trọng đối với Azure Administrator. 7. MỞ RỘNG LAB
Sau khi hoàn thành bài lab cơ bản, có thể mở rộng theo hướng enterprise:
- Thêm Route Table và User Defined Route (UDR).
- Kết nối VNet bằng VNet Peering.
- Thay Public IP bằng Azure Bastion.
- Thêm Azure Load Balancer.
- Xây dựng Database Subnet riêng.
- Sử dụng Azure Firewall để kiểm soát traffic tập trung.
Khi đó, người học có thể tiếp tục phân tích: traffic đi đâu, route nào được sử dụng, NSG nào tác động và firewall có chặn traffic hay không. KẾT LUẬN
Điểm quan trọng nhất của bài lab không phải là tạo được một VNet, mà là hiểu được toàn bộ flow:
Source → Destination → Route → NSG → Application
Khi troubleshooting một kết nối Azure, hãy tập thói quen kiểm tra theo thứ tự:
Private IP → Port → NSG → Route → Firewall → Application Service.
Đây chính là tư duy cần có của một Azure Administrator: không chỉ biết triển khai resource mà còn phải đọc được network flow, kiểm tra security rule và xác định nguyên nhân khi connectivity xảy ra sự cố.
Đây cũng là nền tảng để tiếp tục thực hành các nội dung AZ-104 nâng cao như VNet Peering, Load Balancer, Azure Bastion, Route Table và Azure Firewall.
Attached Files