System-Generated Routes — Các Routes Ngầm Định Của GCP Và Những Gì Chúng Ẩn Giấu

Tại Sao Cần Hiểu System-Generated Routes

System-generated routes là routes mà GCP tự động tạo — bạn không tạo chúng, và trong một số trường hợp, bạn không thể xóa chúng. Không hiểu về chúng dẫn đến hai vấn đề: (1) traffic đi qua đường bạn không ngờ đến, và (2) bạn nghĩ đã block traffic nhưng traffic vẫn đi được vì có special routing path không visible.

Loại 1: Subnet Routes (Tự Động, Có Thể Xem)

Khi bạn tạo subnet, GCP tự động thêm route vào route table:

Hành động: Create subnet prod-us-west1 với CIDR 10.0.0.0/20

Route được tạo tự động:
  Destination: 10.0.0.0/20
  Next hop: local
  Priority: 0 (giá trị đặc biệt — không thể override bằng custom route có cùng destination)

Tương tự với secondary ranges:

Subnet prod-us-west1 thêm secondary range gke-pods=10.1.0.0/16:

Route được tạo:
  Destination: 10.1.0.0/16
  Next hop: local
  Priority: 0

Đặc điểm của subnet routes:

• Tự động visible trong Cloud Console và gcloud routes list
• Không thể xóa (tồn tại chừng nào subnet còn)
• Priority 0 (thực chất là không có priority number, luôn được evaluate sau special paths nhưng trước custom routes có cùng destination trong VPC-local context)
• Traffic match subnet route → được forward locally trong VPC

Subnet Routes Cho Peering

Khi thiết lập VPC Peering, subnet routes của VPC đối tác được import:

VPC A peered với VPC B (10.50.0.0/16):

Routes trong VPC A sau khi peering:
  10.0.0.0/20 → local     (VPC A subnet routes, existing)
  10.50.0.0/16 → peering  (VPC B subnet routes, imported)

Peering subnet routes có priority thấp hơn local subnet routes và local custom routes. Nếu VPC A có custom route đến 10.50.0.0/24, nó override peering route đến subnet 10.50.0.0/24.

Loại 2: Default Internet Gateway Route

Destination: 0.0.0.0/0
Next hop: default-internet-gateway
Priority: 1000

Route này được GCP tạo tự động cho mỗi VPC. Bạn có thể xóa nó — và đôi khi nên xóa trong môi trường high-security.

Khi Xóa Default Route

# Tìm default route
gcloud compute routes list \
  --filter="nextHopGateway:default-internet-gateway"

# Xóa
gcloud compute routes delete default-route-xyz

Sau khi xóa, VM không có external IP không thể gửi traffic ra internet. Nhưng có subtlety: VM có external IP vẫn có thể nhận kết nối vào (return traffic từ external connections đã establish trước đó), nhưng không thể initiate kết nối mới ra ngoài.

Use case: "Private VPC" — VPC hoàn toàn isolated từ internet, kết nối Google APIs thông qua Private Google Access và kết nối on-premises thông qua Interconnect.

Thay Thế Default Route Bằng Egress NVA

Pattern phổ biến trong enterprise: route tất cả internet egress qua Network Virtual Appliance:

Xóa default route → default-internet-gateway

Thêm custom route:
  Destination: 0.0.0.0/0
  Next hop: nva-ilb (Internal Load Balancer phía trước NGFW cluster)
  Priority: 1000

Thêm route cho Google APIs:
  Destination: 199.36.153.4/30 (restricted.googleapis.com)
  Next hop: default-internet-gateway
  Priority: 900  (higher priority than NVA route)

→ Traffic đến Google APIs đi trực tiếp
→ Tất cả internet traffic khác đi qua NGFW

Loại 3: Special Routing Paths (Không Visible, Không Thể Xóa)

Đây là loại routes nguy hiểm nhất nếu không biết về chúng — chúng không xuất hiện trong route table nhưng luôn được evaluate TRƯỚC tất cả routes khác.

Tài liệu GCP gọi chúng là "special routing paths": "These paths don't appear in your VPC network route table."

Paths Đặc Biệt

Identity-Aware Proxy (IAP):

35.235.240.0/20 → IAP forwarding plane

Traffic đến range này được IAP intercept để authenticate. Ngay cả khi bạn xóa tất cả routes và firewall rules, IAP vẫn có thể nhận traffic đến range này — vì đây là special path, không phải route thông thường.

Cloud DNS và Service Directory:

35.199.192.0/19 → Cloud DNS / Service Directory

DNS queries từ VMs đến Cloud DNS private zones đi qua path này. Nếu bạn cố gắng intercept DNS traffic bằng policy-based route trước khi nó đến 35.199.192.0/19, bạn sẽ break DNS cho tất cả VMs trong VPC.

Serverless VPC Access:

35.199.224.0/19 → Serverless VPC Access

Traffic từ Cloud Functions, Cloud Run đến VPC đi qua range này. Nếu bạn có firewall rules block egress đến 35.199.224.0/19, serverless functions của bạn không thể kết nối VMs trong VPC.

Google Front End (GFE) Health Checks:

35.191.0.0/16   → Health check probes
130.211.0.0/22  → Health check probes

Load balancer health checks đến từ những ranges này. Phải có firewall rule ALLOW ingress từ những ranges này đến backend VMs — ngay cả trong "private" environments.

Hệ Quả Bảo Mật: Bạn Không Thể Block Chúng Bằng Routes

Vì special routing paths được evaluate trước tất cả routes, việc xóa routes không ngăn traffic đến chúng:

Tình huống: Admin muốn block tất cả traffic vào VM
  Xóa tất cả custom routes ✓
  Xóa default route ✓
  
Kết quả mong đợi: VM hoàn toàn isolated
Thực tế: IAP vẫn có thể kết nối đến VM (qua 35.235.240.0/20)
         Health checks vẫn reach VM (qua 35.191.0.0/16)

Bảo mật thật sự phải dùng firewall rules, không phải routing. Routes kiểm soát WHERE traffic đi, firewall rules kiểm soát WHETHER traffic được phép.

Cách Kiểm Soát Access Đến Google Services (Đúng Cách)

Để restrict IAP access hoặc health checks, phải dùng firewall:

# Block IAP access (không nên làm trong production, nhưng có thể)
gcloud compute firewall-rules create block-iap \
  --direction=INGRESS \
  --priority=500 \
  --action=DENY \
  --source-ranges=35.235.240.0/20 \
  --rules=tcp:22,tcp:3389

# Chỉ allow health checks từ specific ranges
gcloud compute firewall-rules create allow-health-checks \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --source-ranges=35.191.0.0/16,130.211.0.0/22 \
  --target-tags=backend-vm \
  --rules=tcp:80,tcp:443,tcp:8080

Loại 4: Routes Cho Private Google Access

Khi bật Private Google Access trên subnet, GCP không tự động thêm routes. Bạn phải tự tạo routes cho các VIP ranges:

# Phải tạo thủ công (không phải system-generated!)
gcloud compute routes create private-googleapis-route \
  --destination-range=199.36.153.8/30 \
  --next-hop-gateway=default-internet-gateway \
  --network=prod-vpc

gcloud compute routes create restricted-googleapis-route \
  --destination-range=199.36.153.4/30 \
  --next-hop-gateway=default-internet-gateway \
  --network=prod-vpc

Tại sao next-hop là default-internet-gateway dù traffic không ra internet?

Đây là một trong những điều counterintuitive nhất trong GCP networking. Theo tài liệu chính thức: "Packets from VMs remain within Google's network." Mặc dù next-hop là internet gateway, traffic thực sự đến Google VIP ranges này không bao giờ rời khỏi Google's private network — GCP intercept traffic này tại edge và forward đến internal APIs.

Nghĩa là: default-internet-gateway trong GCP không phải là "ra internet" theo nghĩa đen — nó là "gửi đến Google edge", và Google edge quyết định traffic đến đâu (internet hay internal APIs).

Loại 5: Health Check Routes (Special Path, Không Configurable)

Load balancer health checks được GCP xử lý ở một tầng đặc biệt. Kể cả khi bạn không có route nào cho 35.191.0.0/16, health checks vẫn có thể reach backends — vì đây là special path.

Tuy nhiên, firewall rules vẫn áp dụng cho health checks. Nếu không có firewall rule allow ingress từ health check ranges, health checks sẽ thất bại dù special routing path tồn tại.

Health check logic:
  1. Special routing path: ✓ (bypass route table)
  2. Firewall check: 
     - Nếu có firewall allow → Health check reach backend
     - Nếu không có firewall allow → Health check bị drop
     → Backend bị đánh dấu UNHEALTHY
     → Load balancer ngừng gửi traffic đến backend
     → Production outage

Đây là nguyên nhân phổ biến của "load balancer tạo ra nhưng backends đều unhealthy" — quên thêm firewall rule cho health check ranges.

Tương Tác Giữa Các Loại Routes

Khi có nhiều routes có thể match một packet, GCP evaluate theo thứ tự:

1. Special routing paths (IAP, Cloud DNS, Serverless, Health checks)
   → Nếu match: apply special handling, stop evaluation

2. Policy-based routes (nếu có)
   → Nếu match và action không phải skip: apply và stop

3. Subnet routes (local routes)
   → Nếu destination trong subnet CIDR: forward locally

4. Custom static routes
   → Theo longest prefix match và priority

5. Dynamic routes từ Cloud Router
   → Routes học từ BGP peers

6. Peering routes
   → Routes từ peered VPCs

7. Default route (0.0.0.0/0 → internet gateway)
   → Nếu không có route nào match

Ví dụ thực tế:

Packet: 10.0.0.5 → 35.199.192.5 (Cloud DNS)

Step 1: Kiểm tra special paths
  35.199.192.5 ∈ 35.199.192.0/19? → YEP
  → Apply Cloud DNS special path
  → Đến Cloud DNS resolver, không cần route table lookup
  → Done, không check routes tiếp

Packet: 10.0.0.5 → 8.8.8.8 (external)

Step 1: Special paths → không match (8.8.8.8 không trong special ranges)
Step 2: Policy-based → không có PBR match
Step 3: Subnet routes → không match (8.8.8.8 không trong 10.x.x.x)
Step 4: Custom static → không có route cho 8.8.8.8
Step 5: Dynamic routes → không có BGP route cho 8.8.8.8
Step 6: Default route → 0.0.0.0/0 → internet-gateway
→ Traffic đi ra internet

Debug: "Tại Sao Traffic Đi Theo Đường Này?"

Khi cần debug routing behavior:

# Network Connectivity Center Connectivity Test
gcloud network-management connectivity-tests create debug-test \
  --source-instance=projects/proj/zones/us-west1-a/instances/vm1 \
  --destination-ip=35.199.192.5 \
  --protocol=UDP \
  --destination-port=53

gcloud network-management connectivity-tests describe debug-test \
  --format="json" | jq '.reachabilityDetails'

Connectivity Test show từng hop và lý do tại sao packet đi theo path đó — bao gồm cả special routing paths.

References

• GCP Routes Documentation — Tài liệu đầy đủ về routes, bao gồm special paths
• Private Google Access Configuration — Routes cần thiết cho Private Google Access
• Network Intelligence Center - Connectivity Test — Debug routing
• Health Check Firewall Rules — Các ranges cần allow cho LB health checks