8. Security Group, Floating IP/SNAT & BGPaaS
Mục lục
- Section 14 — Security Groups và Network Policy
- Section 15 — Floating IP và SNAT
- Section 16 — BGP as a Service (BGPaaS)
Section 14 — Security Groups và Network Policy
Mental Model
Hãy nghĩ về hai lớp bảo vệ trong một tòa nhà văn phòng:
Network Policy = Nội quy tòa nhà giữa các tầng: "Tầng A được phép lên tầng B, không được vào tầng C". Quy tắc này áp dụng cho toàn bộ tầng — mọi người ở tầng đó đều bị ràng buộc.
Security Group = Thẻ nhân viên của từng cá nhân: "Nhân viên John có badge cho phép vào phòng server, không vào phòng VIP". Quy tắc này gắn với từng người — dù John đứng ở tầng nào cũng vẫn có quy tắc đó.
Phân biệt Network Policy vs Security Group
| Tiêu chí | Network Policy | Security Group |
|---|---|---|
| Phạm vi | Toàn bộ Virtual Network | Từng port của VM |
| Gắn với | VN pair (VN A → VN B) | VM port (VMI) |
| Mục đích | Kết nối/cô lập giữa VN | Stateful firewall per VM |
| Stateful | Không (stateless ACL) | ✓ (track connection state) |
| Hướng | Bidirectional | Ingress + Egress riêng biệt |
| Cấu hình | Global → attach to VN | Per-VM, per-port |
📝 Suy luận: Thứ tự check Network Policy trước rồi mới Security Group trong diagram trên là suy luận logic từ kiến trúc phân lớp (chi tiết ở mục 14.2) — Juniper docs không mô tả rõ evaluation order này, thực tế có thể evaluate song song.
14.1 Security Group — Stateful Firewall per Port
Security Group Rule format:
direction: ingress | egress
ether_type: IPv4 | IPv6
protocol: TCP | UDP | ICMP | any
src/dst: CIDR | Security Group ID
port_range: min–max
Ví dụ SG "web-server-sg":
ingress: allow TCP 0.0.0.0/0 → port 80, 443
ingress: allow TCP 10.0.0.0/8 → port 22 (SSH từ management)
ingress: deny any 0.0.0.0/0 → any (default deny)
egress: allow any 0.0.0.0/0 → any (allow all outbound)
Cách implement trong vRouter:
VM gửi/nhận packet → vRouter flow table lookup
├── First packet → PUNT lên agent
├── Agent kiểm tra SG rules của VMI
│ ├── Stateful: nếu egress allow → automatically allow ingress reply
│ └── Track connection state (TCP flags, UDP timeout)
├── Agent cài flow entry với action (forward / drop)
└── Subsequent packets → kernel fast path theo flow entry
Stateful tracking: Connection state được lưu trong flow entry. Nếu TCP outbound allowed → reply packets automatically allowed. Không cần rule ingress riêng cho reply.
📝 Suy luận: Cơ chế stateful tracking qua flow entry là suy luận từ kiến trúc vRouter Agent (first-packet punt + flow table). Juniper docs xác nhận SG là stateful nhưng không mô tả chi tiết internal flow path như trên.
14.2 Network Policy — VN-to-VN Connectivity
Network Policy kiểm soát kết nối giữa các Virtual Network và có thể kết hợp với service chaining.
Cú pháp đơn giản:
pass protocol <proto> src-vn <vn-a> src-port <port> dst-vn <vn-b> dst-port <port>
deny protocol any src-vn <vn-a> dst-vn <vn-c>
Với service chain:
pass any src-vn web-tier dst-vn app-tier services [firewall, ids]
Network Policy vs Security Group interaction:
Packet phải pass CẢ HAI lớp:
1. Network Policy (VN level): VN-A có được kết nối VN-B không?
2. Security Group (port level): Port cụ thể của VM có được nhận packet này không?
Nếu Network Policy deny → không cần check SG (đã drop trước)
Nếu Network Policy allow nhưng SG deny → vẫn bị drop tại SG
📝 Suy luận: Thứ tự check Network Policy trước rồi mới SG là suy luận logic từ kiến trúc phân lớp. Không có nguồn Juniper docs nào mô tả rõ evaluation order này. Thực tế có thể evaluate song song trong flow pipeline.
14.3 Tag-Based Firewall Policy (Contrail 4.1+)
Contrail 4.1 giới thiệu tag-based policy — linh hoạt hơn nhiều so với model cũ.
Tags có thể gắn vào: Project, Virtual Network, VM, VMI
Examples:
application=web-app
tier=frontend
deployment=production
site=hanoi
Firewall Policy Rule:
from: application=web-app AND tier=frontend
to: application=web-app AND tier=backend
action: pass, protocol=TCP, port=8080
Tag inheritance: VMI → VM → VN → Project (từ dưới lên trên)
Ưu điểm so với policy cũ:
- Decoupled from routing: Policy không phụ thuộc vào VN topology
- Portable: Cùng policy áp dụng được trên môi trường khác nhau
- Multi-dimension: Segment theo application, tier, site đồng thời
Section 15 — Floating IP và SNAT
Mental Model
Hãy nghĩ về điện thoại nội bộ của công ty.
VM có private IP (như máy nhánh nội bộ: 1234). Từ ngoài Internet, không ai biết số 1234.
Floating IP = Số máy chính công khai (0123-456789). Khi khách gọi vào số chính → tổng đài (vRouter) chuyển sang nhánh 1234. Khi nhánh 1234 gọi ra ngoài → caller ID hiển thị số chính.
SNAT = Nhiều máy nhánh dùng chung một số gọi ra, nhưng phân biệt bằng extension (port).
15.1 Floating IP — One-to-One NAT
Cấu trúc:
FIP Pool → tạo từ FIP-VN (Floating IP Virtual Network, public range)
FIP-VN → có route target match với gateway router's VRF
Floating IP → được allocate từ FIP Pool, map với VM port
Ví dụ:
Private VM: 10.1.1.5 (trong VN "web-tier")
Floating IP: 203.0.113.10 (trong FIP-VN "public-net")
NAT tại vRouter (per-packet): (cơ chế DNAT/SNAT được xác nhận từ Juniper docs — Contrail vRouter CLI Guide; packet format example là minh họa)
INBOUND (ngoài → VM):
src: 203.0.113.1:54321 dst: 203.0.113.10:80
│ DNAT
src: 203.0.113.1:54321 dst: 10.1.1.5:80
│
Deliver to VM
OUTBOUND (VM → ngoài):
src: 10.1.1.5:45678 dst: 8.8.8.8:53
│ SNAT
src: 203.0.113.10:45678 dst: 8.8.8.8:53
│
Send to gateway
Routing flow với FIP:
1. Gateway router nhận route 203.0.113.0/24 (FIP-VN)
qua BGP từ Control Node (import RT của FIP-VN)
2. External traffic → gateway → BGP next-hop = compute node (có VM)
(Control Node advertise FIP→compute mapping qua BGP)
3. Compute node (vRouter) thực hiện DNAT
→ deliver đến VM private IP
4. Ngược lại: VM gửi ra ngoài → SNAT tại vRouter
→ IP nguồn = Floating IP → exit qua gateway
15.2 Distributed SNAT
Floating IP là 1-to-1 mapping. Distributed SNAT cho phép nhiều VM share một IP nguồn (compute node IP) qua Port Address Translation.
Use case: VM cần gọi ra Internet nhưng không có Floating IP riêng
Cơ chế:
VM (10.1.1.5:xxxxx) → SNAT tại vRouter
→ src = Compute Node's IP:unique-port
→ Bảng PAT lưu: (original-src-ip:port) ↔ (compute-ip:mapped-port)
Ưu điểm: Tiết kiệm public IP (nhiều VM share 1 IP)
Hạn chế: Không thể nhận kết nối từ ngoài vào (NAT inbound không có)
Section 16 — BGP as a Service (BGPaaS)
Mental Model
Hãy nghĩ về việc một công ty nhỏ thuê văn phòng trong tòa nhà lớn.
Bình thường, giao thức định tuyến (BGP) chỉ chạy giữa các router vật lý. Contrail quản lý routing thay VM.
Nhưng một số VM là VNF (Virtual Network Function) — chúng là router thật chạy phần mềm (như SD-WAN CPE), và chúng cần tự làm BGP. BGPaaS giống như tòa nhà cấp cho công ty nhỏ đó một đường dây điện thoại trực tiếp đến tổng đài thành phố — không cần qua trung gian.
Simple Explanation
BGPaaS cho phép tenant VM thiết lập BGP session trực tiếp với Contrail Control Node.
Use cases chính:
- Brownfield VNF migration: VNF (firewall, SD-WAN, load balancer) đang chạy BGP → migrate vào Contrail mà không cần sửa ứng dụng
- Custom route injection: VM muốn tự inject routes vào VN (ví dụ: SD-WAN overlay routes)
- Tunnel endpoint BGP: VM announce tunnel endpoints qua BGP
Cơ chế hoạt động
┌─────────────────────────────────────────────────────┐
│ vRouter Agent │
│ │
│ VM (10.1.1.5) │
│ │ BGP TCP port 179 │
│ ▼ │
│ vRouter Agent intercept → NAT/Proxy │
│ │ │
│ │ BGP TCP (proxied) │
│ ▼ │
│ Control Node:179 │
│ (BGP session established between VM and CN) │
└─────────────────────────────────────────────────────┘
Quan trọng: VM không biết mình đang BGP với Control Node — từ phía VM, đây là session với gateway IP của subnet. (xác nhận từ Juniper BGPaaS docs: "vRouter-agent proxies the TCP connection to the control node on behalf of the tenant VM")
vRouter Agent proxy (NAT) TCP session port 179:
- VM mở TCP:179 đến default gateway (169.254.1.1 hoặc subnet GW)
- vRouter Agent intercept, translate, forward đến Control Node
- Control Node nhận như eBGP session bình thường
📝 Suy luận: Chi tiết "VM mở TCP đến 169.254.1.1" là suy luận từ cơ chế ARP proxy (Section 4). Juniper docs chỉ nói "proxy TCP connection" mà không mô tả target IP cụ thể từ góc nhìn VM.
Cấu hình
BGPaaS object gắn với VMI (VM Interface), không phải VM:
→ Một VM có thể có BGPaaS trên nhiều VN khác nhau
Session parameters:
AS number của VM (peer AS)
Địa chỉ BGP peer phía VM
Route limits (tránh VM inject quá nhiều routes)
Route handling:
Routes VM advertise → import vào routing instance của VN đó
Routes từ VN → advertise xuống VM với next-hop = default gateway
(đơn giản hóa: VM không cần resolve recursive next-hop)
HA cho BGPaaS
Control Node Zone: nhóm các control nodes theo zone
BGPaaS có thể chọn zone cụ thể để session luôn terminate
trên cùng một nhóm node → predictable behavior
Khi Control Node fail:
vRouter Agent proxy session đến Control Node khác trong zone
BGP session restart (graceful restart nếu VM hỗ trợ)
Đã đi qua toàn bộ data plane, control plane và các tính năng network service chính. Phần cuối cùng của series chuyển sang mảng hiệu năng (DPDK vRouter), hướng phát triển của Contrail (Tungsten Fabric, CN2) và các công cụ vận hành/troubleshooting hàng ngày.
Nguồn tham khảo
Các điểm dưới đây được đính chính/bổ sung so với nhận định ban đầu trong whitepaper 2015/docs cũ:
- Contrail 4.1 tag-based policy — xác nhận đúng version, khớp firewall-policy object và up to 32 tag types — Juniper Contrail 4.1 docs, truy cập 07/2026