Chương 19: VPC Routing & Connectivity — Deep Dive
Chương này khác gì so với Chương 3?
Chương 3 (VPC Model) trả lời câu hỏi "VPC là gì và cấu hình nó thế nào": auto/custom mode, subnet design, alias IP, các loại route, firewall fundamentals, peering, Shared VPC, Private Google Access, Flow Logs. Đó là tầng kiến thức nền tảng — đủ để bạn dựng một VPC chạy được và đọc hiểu một network diagram.
Chương này đi xuống một tầng sâu hơn: routing và connectivity control plane thực sự vận hành thế nào dưới lớp abstraction. Mục tiêu không phải dạy bạn gcloud compute routes create (Chương 3 đã làm), mà dạy bạn trả lời được những câu hỏi mà chỉ người hiểu cơ chế mới trả lời đúng:
- Khi một VM có 4 route cùng khớp một destination, route nào thắng, và tại sao? Thuật toán tie-break đầy đủ là gì?
- Cloud Router có nằm trên đường đi của packet không? Nếu Cloud Router crash, traffic đang chạy có rớt không?
- Tại sao một route học qua BGP ở
us-central1lại "biến mất" ởeurope-west1— và đổi một flag duy nhất lại làm nó xuất hiện? - Khi hai firewall policy ở hai tầng khác nhau cùng khớp một packet với cùng priority, cái nào quyết định?
- VPC Service Controls chặn data exfiltration ở đâu trong stack — nó có phải là firewall không?
Đây là chương "hiểu để debug và thiết kế", không phải "hiểu để cấu hình". Nếu Chương 3 cho bạn bản đồ, chương này cho bạn hiểu động cơ sinh ra bản đồ đó.
Tại sao tầng kiến thức này quan trọng ở production
Phần lớn sự cố mạng nghiêm trọng trên GCP không đến từ "cấu hình sai một dòng" mà đến từ hiểu sai mô hình. Một kỹ sư tin rằng VPC peering là transitive sẽ thiết kế một hub-and-spoke topology mà spoke-to-spoke không bao giờ thông — và mất nhiều giờ debug firewall trong khi vấn đề nằm ở routing. Một kỹ sư tin rằng Cloud Router "định tuyến packet" sẽ panic khi thấy Cloud Router restart, trong khi datapath chưa từng bị ảnh hưởng. Một kỹ sư không hiểu preference category sẽ không hiểu vì sao route static next-hop-VM của họ luôn thắng route dynamic dù prefix kém cụ thể hơn.
Những hiểu lầm này không thể fix bằng cách đọc thêm gcloud flags. Chúng chỉ tan biến khi bạn có mental model chính xác về control plane: nơi state được lưu, ai chương trình hóa (program) forwarding table, route được resolve theo thứ tự nào, và biên giới giữa "routing", "firewall" và "API-layer security" nằm ở đâu.
Mental model trung tâm: tách bạch Control Plane và Data Plane
Toàn bộ chương này xoay quanh một sự phân tách duy nhất mà nếu nắm chắc, mọi thứ khác sẽ tự rơi vào đúng chỗ:
CONTROL PLANE DATA PLANE
(quyết định "đi đâu") (thực thi forwarding)
┌─────────────────────────────┐ ┌──────────────────────────┐
│ Cloud Router (BGP speaker) │ │ Andromeda (host vSwitch)│
│ Route table của VPC │ ───► │ Forwarding state tại │
│ Firewall policy objects │ program│ từng VM / từng host │
│ VPC-SC perimeter config │ │ Stateful conn tracking │
└─────────────────────────────┘ └──────────────────────────┘
State sống ở đây Packet thực sự đi qua đây
Thay đổi = eventual Tốc độ = wire speedBa hệ quả lớn của mô hình này, sẽ lặp lại xuyên suốt chương:
Route table của VPC là một control-plane object, không phải một bảng vật lý nằm trong một con router. Nó được "biên dịch" thành forwarding state và đẩy xuống Andromeda tại từng host. Không có "con router trung tâm" nào để traffic phải đi qua. Đây là lý do VPC có thể là global mà vẫn không có single point of failure.
Cloud Router chỉ là control plane. Theo tài liệu Cloud Router, "Cloud Router không cung cấp khả năng routing hay forwarding packet; Andromeda xử lý toàn bộ việc đó, còn Cloud Router quản lý các BGP session tương ứng". Cloud Router học route qua BGP rồi program chúng vào VPC. Nó không nằm trên datapath.
Firewall và VPC-SC là các control-plane khác nhau, enforce ở các tầng khác nhau. Firewall rule được biên dịch thành stateful filter tại Andromeda (datapath, theo từng packet/connection). VPC-SC enforce ở API layer của managed services (Cloud Storage, BigQuery...) — hoàn toàn ngoài datapath của VPC. Nhầm lẫn hai biên giới này là nguồn gốc của vô số lỗi thiết kế bảo mật.
Giữ ba điểm này trong đầu khi đọc từng file.
Cấu trúc chương
Chương đi từ trong ra ngoài: bắt đầu từ cơ chế routing nội tại của một VPC, mở rộng ra control plane động (Cloud Router/BGP), rồi tới connectivity liên-mạng (hybrid, transitive), và cuối cùng là hai lớp kiểm soát chồng lên routing (firewall engine, VPC-SC).
| File | Chủ đề | Câu hỏi cốt lõi nó trả lời |
|---|---|---|
| 01. Routing Control Plane Model | VPC route table như control-plane object, program vào Andromeda, scope global vs regional của route | State routing sống ở đâu? Vì sao VPC global mà không có router trung tâm? |
| 02. Route Resolution & Priority | Thuật toán chọn route đầy đủ: thứ tự loại route, longest-prefix, priority, preference category, ECMP | Khi nhiều route cùng khớp, route nào thắng và theo logic nào? |
| 03. Cloud Router Architecture | Control-plane-only, regional resource, HA nội tại, cơ chế program route vào VPC | Cloud Router crash thì traffic có rớt không? Nó scale thế nào? |
| 04. BGP trên GCP | ASN, link-local interface, BGP FSM, keepalive/hold timers, BFD, MD5, graceful restart, multipath | BGP session thực sự được thiết lập và duy trì thế nào? Failover nhanh tới đâu? |
| 05. Route Advertisement & Propagation | Advertisement mode, dynamic routing mode (regional vs global), MED, custom route policies, filtering | Vì sao route biến mất giữa các region? Điều khiển propagation thế nào? |
| 06. Hybrid Connectivity Routing | HA VPN, Interconnect VLAN attachment, redundancy, SLA topologies, failover qua MED/AS-PATH | Thiết kế kết nối on-prem đạt 99.99% và failover tự động ra sao? |
| 07. Transitive Routing & NCC | Phi-transitivity của peering ở tầng routing; Network Connectivity Center hub/spoke; route exchange | Vì sao spoke-to-spoke không thông qua peering? NCC giải quyết thế nào? |
| 08. Firewall Policy Evaluation Engine | Thứ tự evaluate xuyên hierarchical/global/regional/VPC; goto_next; secure tag vs SA; stateful tracking | Khi nhiều tầng firewall cùng khớp, cái nào quyết định? |
| 09. VPC Service Controls Perimeter | Perimeter như control plane riêng, enforce ở API layer; restricted VIP; ingress/egress; dry-run | VPC-SC chặn exfiltration ở đâu? Khác firewall và IAM thế nào? |
Lộ trình đọc đề xuất
Nếu bạn đang debug một routing issue (route không khớp như kỳ vọng): 01 → 02 → 05. Hiểu nơi state sống, thuật toán resolve, và cơ chế propagation là đủ để truy nguyên 90% sự cố routing.
Nếu bạn đang thiết kế hybrid connectivity (on-prem ↔ GCP): 03 → 04 → 05 → 06. Đây là chuỗi Cloud Router → BGP → propagation → topology vật lý, theo đúng thứ tự bạn cần để thiết kế một kết nối production-grade có HA.
Nếu bạn đang thiết kế multi-VPC / multi-project topology: 01 → 07 → 08 → 09. Routing scope, transitivity, firewall layering, và perimeter là bốn trục quyết định một enterprise network landing zone.
Nguyên tắc xuyên suốt chương
Control plane ≠ data plane. Mọi thay đổi route/firewall/perimeter là thay đổi control-plane object; nó cần thời gian để được program xuống datapath (eventual consistency). Đừng kỳ vọng failover tức thời chỉ vì BGP session đã down.
Route resolution là thuật toán xác định, không phải "best effort". Longest-prefix → priority → preference category → ECMP. Học thuộc thứ tự này; nó giải thích mọi hành vi routing "kỳ lạ".
VPC peering không transitive, và đó là quyết định thiết kế có chủ đích. Đừng cố "lách" bằng route tĩnh; dùng đúng công cụ (NCC, Cloud Router) cho transitive routing.
Firewall enforce theo packet ở datapath; VPC-SC enforce theo API call ở control plane của service. Chúng bổ sung cho nhau, không thay thế nhau. Một perimeter VPC-SC không chặn
ping; một firewall rule không chặngcloud storage cpra ngoài perimeter.