Cloud VPN — Cơ Chế Tunnel, IKE/ESP và HA Model

Tại sao quan trọng trong production

Cloud VPN là lựa chọn phổ biến nhất cho hybrid connectivity vì không đòi hỏi hạ tầng vật lý ở colocation facility. Tuy nhiên, "phổ biến" không có nghĩa là "đơn giản để vận hành đúng". Ba vấn đề thường gặp nhất trong production:

1. SLA bị hiểu sai: tưởng rằng chỉ cần tạo hai tunnel là đủ cho 99.99%, nhưng thực tế topology quyết định SLA tier.
2. Throughput ceiling bất ngờ: mỗi tunnel chỉ đạt 1–3 Gbps tùy packet size, và nhiều team không biết cách tính capacity khi aggregate.
3. MTU mismatch im lặng: gói tin lớn bị drop sau khi vào tunnel, nhưng không có error log rõ ràng ở tầng application — chỉ thấy TCP retransmit.

Hiểu cơ chế bên trong của Cloud VPN giải quyết cả ba vấn đề này.

---

Internal Model — Cơ Chế Hoạt Động Bên Trong

Mô hình kiến trúc tổng thể

Cloud VPN là một regional managed service — Google vận hành toàn bộ infrastructure bên dưới, bạn chỉ cấu hình logical resources: VPN gateway, tunnel, và BGP session trên Cloud Router. Không có VM nào chạy VPN software mà bạn phải quản lý.

Cấu trúc logical gồm ba lớp:

[On-premises router]
        |
   (IPsec tunnel qua public internet)
        |
[Cloud VPN Gateway] ── [Cloud Router] ── [VPC routes]

VPN Gateway là điểm chấm dứt IPsec tunnel. Cloud Router là BGP peer, chịu trách nhiệm học và quảng bá routes. Hai component này tách biệt về chức năng: VPN Gateway xử lý data plane (mã hóa/giải mã packet), Cloud Router xử lý control plane (BGP, route propagation vào VPC).

Classic VPN — Mô hình cũ và giới hạn

Classic VPN sử dụng một external IP duy nhất per gateway, với hai loại routing:

• Policy-based routing: Tunnel chỉ forward traffic match với selector (local subnet và remote subnet được khai báo cứng). Đây là static, không flexible, và cần recreate tunnel khi thêm subnet mới.
• Route-based routing: Dùng tunnel interface như một next-hop, traffic match theo route table. Vẫn không hỗ trợ BGP dynamic routing.

Classic VPN đạt 99.9% SLA (monthly uptime). Nguồn downtime: planned maintenance trên gateway, và không có redundancy path vì chỉ có một external IP. Khi Google thực hiện maintenance, tunnel xuống trong thời gian ngắn.

Classic VPN không hỗ trợ IPv6, không hỗ trợ active-active configuration, và đang dần bị deprecated. Production systems mới không nên dùng Classic VPN.

HA VPN — Mô hình hiện đại

HA VPN (High Availability VPN) giải quyết vấn đề single point of failure của Classic VPN bằng cách:

1. Hai interface, hai external IP: Mỗi HA VPN gateway có hai network interface, mỗi interface có external IP riêng từ hai address pool độc lập.
2. Hai tunnel, hai BGP session: Mỗi interface phải có ít nhất một tunnel, và mỗi tunnel có BGP session riêng trên Cloud Router.
3. Active-active hay active-passive: Cả hai tunnel đều up và forward traffic (active-active), hoặc một tunnel chính và một tunnel standby (active-passive, thực hiện qua BGP MED/priority).

Điều kiện để đạt 99.99% SLA: bạn phải tạo tunnel trên cả hai interface của HA VPN gateway. Một gateway với chỉ một tunnel trên một interface không đủ điều kiện cho SLA tier này.

Lý do hai interface quan trọng về mặt kỹ thuật: Google triển khai các interface này trên hai independent failure domain. Khi một failure domain gặp sự cố (planned maintenance, hardware failure, power issue), interface kia vẫn hoạt động. Tunnel trên interface bị ảnh hưởng sẽ down, nhưng tunnel trên interface còn lại sẽ tiếp tục forward traffic — đây là cơ chế đạt 99.99%.

Quan trọng: SLA tính theo topology, không phải số lượng tunnel. Hai tunnel trên cùng một interface không đạt 99.99%.

---

IPsec Tunnel Mechanics — IKE và ESP

Cloud VPN sử dụng IPsec trong tunnel mode (không phải transport mode). Hiểu sự khác biệt này quan trọng:

• Transport mode: Chỉ encrypt payload, giữ nguyên IP header gốc. Phù hợp cho host-to-host.
• Tunnel mode: Encrypt toàn bộ gói tin gốc (header + payload), thêm outer IP header mới. Phù hợp cho gateway-to-gateway, vì on-premises và GCP VPC dùng private IP không routable trên internet.

Khi packet rời on-premises router đến Cloud VPN:

[Gói tin gốc]
Inner IP: 10.0.1.5 → 172.16.2.10 (VPC VM)
Payload: TCP data

↓ IPsec Tunnel Mode processing

[Gói tin sau khi vào tunnel]
Outer IP: <on-prem public IP> → <Cloud VPN external IP>
ESP header: SPI, Sequence Number
Encrypted payload: {Inner IP + TCP data}
ESP Trailer + ICV (Integrity Check Value)

Outer IP header là public IP, được route trên internet. Khi đến Cloud VPN Gateway, lớp outer IP và ESP header được bóc ra, inner packet được giải mã và forward vào VPC.

IKE — Internet Key Exchange

Trước khi có thể forward traffic, hai bên phải thiết lập Security Association (SA) qua giao thức IKE. SA là thỏa thuận về: thuật toán mã hóa, key, và lifetime của key.

IKE Phase 1 (IKE SA hoặc ISAKMP SA):

• Hai bên xác thực lẫn nhau (Cloud VPN dùng pre-shared key hoặc PKI, thực tế phổ biến là pre-shared key).
• Thương lượng cipher suite cho chính kênh IKE (không phải cho traffic).
• Thiết lập một kênh secure (encrypted, authenticated) để tiến hành Phase 2.

IKE Phase 2 (IPsec SA hoặc Child SA):

• Thương lượng cipher suite cho IPsec data traffic.
• Derive các session key từ key material đã trao đổi ở Phase 1.
• Kết quả là hai IPsec SA — một chiều inbound, một chiều outbound.

Cloud VPN hỗ trợ cả IKEv1 và IKEv2. IKEv2 được khuyến nghị vì:

• Nhanh hơn: ít round-trip hơn trong negotiation (2 round-trips thay vì 6).
• Mandatory cho IPv6 support.
• Hỗ trợ EAP authentication (không phổ biến trong VPN site-to-site nhưng có).
• MOBIKE extension cho mobility (không áp dụng với gateway-to-gateway nhưng protocol robust hơn).

Khi IKE negotiation thất bại, debug points cần kiểm tra:

• Cipher suite mismatch: Cloud VPN có danh sách supported IKE ciphers, peer phải support ít nhất một cipher chung.
• Pre-shared key không khớp: Lỗi này thường hiển thị ở peer log, không phải Cloud VPN log.
• Firewall: UDP 500 (IKE) và UDP 4500 (NAT-T) phải được mở cho traffic từ peer IP đến Cloud VPN external IP.

Dead Peer Detection (DPD): Cloud VPN implement DPD theo RFC 3706 để phát hiện khi peer không còn respond. Khi DPD confirm peer down, tunnel được tear down và IKE re-negotiation bắt đầu. Interval của DPD không cấu hình được trên Cloud VPN side. Đây là một lý do tại sao BFD (Bidirectional Forwarding Detection) quan trọng hơn — BFD phát hiện failure nhanh hơn nhiều (sub-second) so với DPD.

ESP — Encapsulating Security Payload

ESP là protocol mã hóa actual traffic. Sau khi IKE thiết lập SA, mỗi packet đi qua tunnel được xử lý bởi ESP:

1. Packet gốc được padding để align với block size của cipher.
2. Payload được encrypt bằng cipher đã thỏa thuận (ví dụ: AES-256-GCM).
3. ESP header được thêm vào (SPI để identify SA, sequence number để chống replay).
4. Integrity Check Value (ICV) được tính và append.
5. Outer IP header được thêm vào.

Cloud VPN bắt buộc dùng ESP trong tunnel mode, không support AH (Authentication Header) vì AH không mã hóa payload.

Replay protection: Cloud VPN implement replay protection với window size 4096 packets và không cho phép disable. Điều này có nghĩa là nếu out-of-order packets vượt quá window (trong môi trường high-latency hoặc khi có reorder), packets sẽ bị drop. Đây là một trade-off security vs reliability cần biết.

---

Dynamic Routing qua Cloud Router

HA VPN bắt buộc dùng dynamic BGP routing. Không có static routing option. Điều này là intentional design decision: BGP là cơ chế duy nhất cho phép tunnel failover tự động.

Workflow:

1. Khi tunnel lên (IPsec SA established), Cloud Router thiết lập BGP session với peer router on-premises qua link-local address 169.254.x.x.
2. Cloud Router học routes từ peer qua BGP UPDATE messages.
3. Cloud Router install routes này vào VPC routing table với next-hop là tunnel.
4. Cloud Router quảng bá VPC subnet routes cho peer.

Điểm quan trọng về BGP over VPN: BGP session chạy bên trong IPsec tunnel, không phải trên public internet. BGP packets được mã hóa như bất kỳ traffic nào khác. Địa chỉ BGP peer là 169.254.x.x (link-local, không routable ngoài tunnel) — đây là thiết kế có chủ đích để ensure BGP chỉ hoạt động khi tunnel up.

Khi tunnel down, BGP session mất, routes bị withdraw, traffic chuyển sang tunnel còn lại (trong active-active) hoặc chờ tunnel khôi phục (active-passive).

Thời gian failover phụ thuộc vào:

• BGP hold timer (mặc định 60 giây) — thời gian để BGP detect peer down nếu không có DPD/BFD
• BFD: nếu được bật, failover sub-second
• Route convergence sau khi BGP routes được update

Trong HA VPN với BFD bật, failover thường xảy ra trong 1–2 giây. Không có BFD, failover có thể mất 60–90 giây (hold timer expiry).

---

MTU và TCP MSS Clamping

Đây là một trong những vấn đề subtlest của Cloud VPN mà nhiều team gặp nhưng khó diagnose.

Tại sao MTU giảm trong VPN tunnel

Khi một packet đi qua IPsec tunnel, overhead được thêm vào:

• ESP header: 8 bytes
• IV (Initialization Vector): 8–16 bytes tùy cipher
• ESP trailer + padding: biến động
• ICV: 16 bytes (với GCM-256)
• Outer IP header: 20 bytes (IPv4) hoặc 40 bytes (IPv6)
• Nếu qua NAT: UDP 4500 header thêm 8 bytes

Tổng overhead tùy cipher, nhưng khoảng 54–100+ bytes so với payload gốc. Nếu payload gốc đã gần 1500 bytes (standard ethernet MTU), sau khi encapsulate, outer packet vượt quá 1500 bytes và cần fragmentation.

Cloud VPN xử lý vấn đề này theo cách sau: fragmentation xảy ra trước khi encrypt. Nhưng fragmenting IP packets ở gateway có nhiều vấn đề:

• Tất cả fragments phải đến đúng bên kia để reassemble.
• Reassembly overhead tốn tài nguyên.
• Nếu peer có DF (Don't Fragment) bit set, gói tin không thể fragment và phải bị drop.

Do đó, Cloud VPN set payload MTU (MTU của inner packet sau khi trừ overhead) như sau (theo docs chính thức):

Loại cipher	IPv4 payload MTU	IPv6 payload MTU
AEAD (AES-GCM)	1406 bytes	1386 bytes
Non-AEAD (set 1)	1374 bytes	1354 bytes
Non-AEAD (set 2)	1390 bytes	1370 bytes
HA VPN over Interconnect (AEAD, IPv4)	1386 bytes	—

Gateway MTU của Cloud VPN là 1460 bytes (standard VPN, không phải HA over Interconnect).

TCP MSS Clamping — Giải pháp cho TCP

Với TCP connections, Cloud VPN sử dụng MSS (Maximum Segment Size) clamping: khi bắt thấy TCP SYN packet đi vào tunnel, Cloud VPN modify trường MSS trong TCP header để advertise giá trị phù hợp với payload MTU. Peer TCP stack sẽ gửi segment không vượt quá MSS này.

Ví dụ: Nếu payload MTU là 1406, MSS sẽ được clamp xuống khoảng 1366 (1406 - 20 bytes IP header - 20 bytes TCP header = 1366 bytes TCP payload).

MSS clamping chỉ áp dụng cho TCP. Các giao thức khác (UDP, ICMP, GRE) không có MSS mechanism. Đây là lý do:

• UDP fragmentation phải được xử lý bởi application (ví dụ QUIC, DTLS).
• ICMP Fragmentation Needed: Khi Cloud VPN nhận UDP/ICMP packet với DF bit set mà quá lớn, nó gửi ICMP type 3 code 4 (Fragmentation Needed) về source với "next-hop MTU" = payload MTU. Source sẽ giảm packet size. Nhưng nếu firewall on-premises block ICMP, source không nhận được tín hiệu này — kết quả là PMTUD (Path MTU Discovery) blackhole.

Debug MTU issues

Triệu chứng điển hình của MTU/MSS vấn đề:

• HTTP/HTTPS requests nhỏ hoạt động bình thường, nhưng transfers lớn (file download, database bulk query) fail hoặc rất chậm.
• TCP SYN/SYN-ACK thành công nhưng data transfer stall.
• ping -s 1400 <vm-ip> từ on-premises fail, nhưng ping -s 500 thành công.

Kiểm tra: tcpdump -i <interface> tcp and 'tcp[13] & 2 == 2' để capture SYN packets và kiểm tra MSS option trong TCP header.

---

Constraints & Trade-offs

Bandwidth ceiling

Mỗi HA VPN tunnel đạt tối đa 3 Gbps (thực tế 1–3 Gbps tùy packet size). Với packet nhỏ (64 bytes), throughput thực tế gần 1 Gbps vì overhead per-packet cao. Với packet lớn (gần MTU), throughput gần 3 Gbps.

Limit này không thể tăng vì nó là per-tunnel hardware limit của Google's VPN infrastructure. Để scale bandwidth, cần nhiều tunnel và aggregate:

HA VPN Gateway Interface 0 -- Tunnel A (max 3 Gbps)
                           -- Tunnel B (max 3 Gbps)
HA VPN Gateway Interface 1 -- Tunnel C (max 3 Gbps)
                           -- Tunnel D (max 3 Gbps)

Cloud Router có thể ECMP across multiple tunnels, cho phép aggregate bandwidth. Tuy nhiên ECMP per-flow (không phải per-packet), nên một flow đơn không vượt quá 3 Gbps.

Khi nào Cloud VPN không đủ: Nếu bạn cần >3 Gbps per-flow (ví dụ: replication của một database lớn, bulk data migration), Cloud Interconnect là lựa chọn đúng.

Site-to-site only

Cloud VPN chỉ hỗ trợ gateway-to-gateway (site-to-site). Không hỗ trợ client VPN (remote access VPN cho laptop/mobile). Nếu cần remote access, phải dùng third-party solutions hoặc Google Chrome Enterprise Remote Desktop, IAP Tunneling.

Peer gateway requirements

Peer gateway phải có static external (internet-routable) IPv4 address. Dynamic IP không hỗ trợ. Nếu peer nằm sau NAT, cần dùng NAT-T (NAT Traversal) — Cloud VPN hỗ trợ NAT-T qua UDP 4500.

Regional resource

VPN gateway là regional resource. Nếu cần kết nối đến nhiều region, cần nhiều gateway. Không thể dùng một gateway ở us-central1 để kết nối với workload ở asia-east1 (traffic sẽ phải traverse qua GCP backbone, không phải vấn đề kỹ thuật nhưng là latency concern).

---

Anti-pattern: Classic VPN với static routing trong production

Vẫn còn nhiều hệ thống dùng Classic VPN với static routing vì lý do lịch sử. Vấn đề:

1. Fragility: Khi thêm subnet mới on-premises hoặc trong VPC, phải manually update tunnel selectors hoặc static routes. Dễ quên, dẫn đến routing black hole.
2. No failover: Không có automatic failover khi tunnel down. Manual intervention cần thiết.
3. No visibility: BGP cho visibility về route state. Static routing không có mechanism để biết next-hop thực sự reachable hay không.

Hiểu sai về bản chất: nhiều người tưởng Classic VPN "đơn giản hơn và ít overhead hơn". Thực tế: IKE negotiation và IPsec processing overhead gần như giống nhau. Sự đơn giản là giả — bạn đang trả giá bằng fragility và operational toil.

---

GCP-native Implementation Guidance

Tạo HA VPN gateway với Cloud Router và dynamic BGP routing:

# Tạo HA VPN Gateway (tự động cấp 2 external IP)
gcloud compute vpn-gateways create ha-vpn-gw-1 \
  --network=my-vpc \
  --region=us-central1

# Tạo Cloud Router cho dynamic routing
gcloud compute routers create vpn-router \
  --network=my-vpc \
  --region=us-central1 \
  --asn=65001

# Tạo peer VPN gateway (external gateway on-premises)
gcloud compute external-vpn-gateways create on-prem-gw \
  --interfaces=0=<ON_PREM_IP_0>,1=<ON_PREM_IP_1>

# Tạo tunnel trên Interface 0
gcloud compute vpn-tunnels create tunnel-0 \
  --peer-external-gateway=on-prem-gw \
  --peer-external-gateway-interface=0 \
  --region=us-central1 \
  --ike-version=2 \
  --shared-secret=<PSK> \
  --router=vpn-router \
  --vpn-gateway=ha-vpn-gw-1 \
  --vpn-gateway-interface=0

# Tạo tunnel trên Interface 1
gcloud compute vpn-tunnels create tunnel-1 \
  --peer-external-gateway=on-prem-gw \
  --peer-external-gateway-interface=1 \
  --region=us-central1 \
  --ike-version=2 \
  --shared-secret=<PSK> \
  --router=vpn-router \
  --vpn-gateway=ha-vpn-gw-1 \
  --vpn-gateway-interface=1

# Add BGP interface cho mỗi tunnel
gcloud compute routers add-interface vpn-router \
  --interface-name=tunnel-0-if \
  --vpn-tunnel=tunnel-0 \
  --ip-address=169.254.0.1 \
  --mask-length=30 \
  --region=us-central1

gcloud compute routers add-bgp-peer vpn-router \
  --peer-name=tunnel-0-peer \
  --interface=tunnel-0-if \
  --peer-ip-address=169.254.0.2 \
  --peer-asn=65002 \
  --region=us-central1

Xác nhận trạng thái BGP:

gcloud compute routers get-status vpn-router \
  --region=us-central1 \
  --format='json(result.bgpPeerStatus)'

Trường status: UP và numLearnedRoutes > 0 xác nhận BGP hoạt động và routes đã được học.

---

References

• Cloud VPN Overview
• HA VPN Topologies
• Cloud VPN MTU Considerations
• Supported IKE Ciphers
• Cloud VPN SLA
• Create HA VPN to Peer Gateway