My Awesome Project

Appearance

Connectivity Tests: Simulating Network Paths ​

Tại sao Connectivity Tests Quan Trọng ​

Connectivity Tests là điểm khởi đầu của hầu hết quy trình network troubleshooting trên GCP. Thay vì đặt câu hỏi "tại sao không kết nối được, hãy debug", trước tiên bạn nên tự hỏi: "Cấu hình của chúng ta có phải là nguyên nhân không?"

Connectivity Tests trả lời câu hỏi này trước khi gửi traffic thật. Việc này tiết kiệm hàng giờ vì nó có thể phát hiện lỗi cấu hình, cấu hình sai firewall, hoặc lỗi routing mà không cần chờ traffic thực tế. Nếu Connectivity Tests báo "đường truyền sẽ hoạt động" nhưng traffic khách hàng vẫn lỗi, bạn sẽ biết vấn đề không nằm ở cấu hình hạ tầng — nó nằm ở layer application, DNS, hay service mesh.

Hai Phases của Connectivity Tests ​

Connectivity Tests hoạt động theo hai phase riêng biệt:

Phase 1: Phân tích Cấu hình (Configuration Analysis) ​

Đây là mô phỏng máy status hữu hạn (FSM) của đường đi packet. GCP không gửi traffic thật. Thay vào đó, nó mô phỏng một packet từ source đến destination và kiểm tra xem nó sẽ chịu tác động của hành động nào.

Cách hoạt động:

  1. Bắt đầu từ source — Router hay VM là source của packet.
  2. Trace path — Theo dõi từng bước một:
    • Check firewall rules (ingress)
    • Check routes (destination matching)
    • Check firewall rules (egress)
    • Check next hop (là VM, load balancer, Cloud SQL, hay external internet)
  3. Mô phỏng mỗi hop — Nếu next hop là VM khác trên peered network, nhảy tới VM đó và lặp lại.
  4. Kết quả — "Packet nên đến được đích" hoặc "bị chặn tại bước X".

Ví dụ:

Source: VM A (10.0.1.2)
Destination: VM B (10.1.1.2) trên peered network
Các bước phân tích cấu hình:
  1. VM A ingress firewall: ALLOW all ingress (allow)
  2. VM A egress firewall: ALLOW 10.1.0.0/16 (allow)
  3. VM A route lookup: 10.1.0.0/16 → qua peering (found)
  4. Kiểm tra peering: Active? Yes
  5. VM B ingress firewall: ALLOW từ 10.0.0.0/16? Yes (allow)
  → Kết quả: "Reachable"

Ưu điểm:

  • Rất nhanh (chỉ vài giây).
  • Phát hiện lỗi cấu hình ngay lập tức.
  • Không cần gửi traffic thật.
  • Hỗ trợ rất nhiều service: VPC, load balancers, GKE, Cloud SQL, firewall policies, policy-based routes.

Nhược điểm:

  • Chỉ kiểm tra cấu hình, không kiểm tra thực tế.
  • Không phát hiện lỗi ở application-level.
  • Không đo lường latency.
  • Không phát hiện các lỗi chập chờn (transient issues).

Khả năng hỗ trợ của Configuration Analysis:

GCP hỗ trợ mô phỏng cho:

  • VPC networks (cùng VPC, peered VPC)
  • Cloud VPN tunnels
  • Cloud Interconnect (VLAN attachments)
  • VPC peering
  • Network Connectivity Center (NCC)
  • Load balancers (internal/external, TCP/UDP/HTTP/HTTPS)
  • GKE Pods qua VPC-native networking
  • Cloud SQL qua private service connection
  • Cloud Run qua Serverless VPC Access
  • Firewall rules (cả VPC và Firewall Policies)
  • Policy-based routes

Giới hạn: Không hỗ trợ Compute Engine instances được cấu hình làm router, firewall, hay NAT gateway (các custom data plane appliances).

Phase 2: Phân tích Live Data Plane (Live Data Plane Analysis) ​

Nếu configuration analysis thành công, Connectivity Tests có thể gửi actual probe packets qua network để xác thực kết nối hoạt động trên thực tế.

Cách hoạt động:

Connectivity Tests gửi ICMP Echo (ping) packets từ source tới destination qua mạng thực tế (actual network data plane), sau đó đo:

  • Latency (round-trip time)
  • Packet loss
  • Biến động thời gian phản hồi (response time variance)

Ví dụ output:

Probe results: 
- Round-trip time: 2.5ms (min: 2.1ms, max: 3.2ms)
- Packet loss: 0%
- Status: SUCCESS

Khi nào Live Analysis được hỗ trợ:

Live data plane analysis không hỗ trợ mọi kịch bản như configuration analysis. GCP chỉ hỗ trợ cho:

  • VM-to-VM (cùng/peered VPC, cross-region)
  • VM đến Cloud SQL
  • VM đến GKE control plane
  • Serverless với Serverless VPC Access
  • On-premises đến GCP (qua Cloud Interconnect hoặc Cloud VPN)

Không hỗ trợ: VM-to-load-balancer, VM-to-Cloud Run (không qua VPC Access), hay traffic đi qua NAT.

Cơ chế hoạt động của Probe:

  1. Khởi tạo Probe — GCP tạo một temporary probe prober instance gần source.
  2. Xây dựng Packet — Tạo ICMP Echo packet qua actual VPC path.
  3. Gửi — Gửi qua mạng thực tế.
  4. Nhận — Chờ phản hồi ICMP Echo Reply từ destination.
  5. Đo lường — Tính toán RTT, packet loss.
  6. Dọn dẹp — Xóa temporary prober.

Quy trình này mất khoảng 20-120 giây tùy thuộc vào độ phức tạp của cấu hình.

Ưu điểm:

  • Kiểm tra thực tế, không phải mô phỏng.
  • Đo lường latency và packet loss.
  • Phát hiện các lỗi chập chờn (trong thời gian chạy probe).

Nhược điểm:

  • Chậm hơn configuration analysis (mất 20-120 giây).
  • Giới hạn kịch bản hỗ trợ.
  • Không test ứng dụng (chỉ test ICMP).
  • Có thể bị firewall rules chặn nếu firewall ứng dụng không cho phép ICMP.

Độ trễ Cập nhật Cấu hình (Configuration Propagation Delay) ​

Quan trọng: Connectivity Tests đọc cấu hình từ snapshot control plane tại thời điểm chạy test. Nếu bạn vừa thay đổi firewall rule hoặc route, sẽ có một khoảng trễ trước khi Connectivity Tests nhận dạng được thay đổi đó.

Tài liệu GCP ghi rõ: "Mất từ 20 đến 120 giây để Connectivity Tests nhận bản cập nhật cấu hình."

Ý nghĩa thực tiễn:

  • Nếu thay đổi firewall rule rồi chạy Connectivity Tests ngay, nó có thể vẫn hiển thị cấu hình cũ.
  • Nên chờ 2-3 phút sau khi đổi cấu hình trước khi tin tưởng kết quả Connectivity Tests.
  • Đối với các bản sửa lỗi production, hãy xác thực thay đổi cấu hình đã áp dụng (chạy gcloud compute firewall-rules describe v.v.) trước khi dựa vào kết quả Connectivity Tests.

Quy trình Sử dụng Connectivity Tests ​

Bước 1: Chạy Configuration Analysis ​

bash
# Qua gcloud CLI
gcloud compute network-management connectivity-tests create test-vm-to-vm \
  --source-instance=projects/my-project/zones/us-central1-a/instances/vm-a \
  --destination-instance=projects/my-project/zones/us-central1-b/instances/vm-b \
  --protocol=TCP \
  --source-port=1024 \
  --destination-port=443

# Ngoài ra: Source/destination có thể là public IP, GKE Pod IP, Cloud SQL IP, v.v.

Đọc hiểu output:

Connectivity Test Results:
CONNECTIVITY_TEST_RESULTS {
  result: FULLY_REACHABLE  # Hoặc UNREACHABLE, UNKNOWN, v.v.
  trace: [
    STEP_1: Source_VM → Ingress_Firewall [ALLOW]
    STEP_2: Source_VM → Route_Lookup [FOUND: 10.1.0.0/16 via peering]
    STEP_3: Source_VM → Egress_Firewall [ALLOW]
    STEP_4: Peering → Reachable [YES]
    STEP_5: Destination_VM → Ingress_Firewall [ALLOW]
  ]
}

Kết quả trace hiển thị chính xác đường đi của packet và vị trí bị chặn (nếu có).

Bước 2: Chạy Live Data Plane Analysis ​

Nếu configuration analysis báo reachable, chọn "Run live data plane analysis":

Live Data Plane Analysis Results:
Probing with ICMP Echo...
Round-trip time: 3.2ms (min: 2.8ms, max: 3.8ms)
Packet loss: 0%
Status: SUCCESS

Khi nào nên sử dụng từng Phase ​

Configuration Analysis:

  • Bước đầu tiên cho bất kỳ vấn đề kết nối nào.
  • Phản hồi nhanh chóng.
  • Phù hợp để xác thực cấu hình.

Live Data Plane Analysis:

  • Khi config analysis thành công nhưng người dùng vẫn báo lỗi kết nối.
  • Cần xác nhận mạng thực tế có chuyển packet đi hay không.
  • Khắc phục các sự cố chập chờn.
  • Đo lường latency cơ sở.

Các lỗi Configuration Analysis thường gặp ​

Dưới đây là các mẫu lỗi phổ biến từ Connectivity Tests:

Trường hợp 1: Firewall Rules chặn traffic ​

Status: UNREACHABLE
Failure: Destination unreachable due to firewall rule
Blocking_rule: Default_Deny_Ingress (priority: 65534)

Root cause: VM đích có rule deny, hoặc không có rule allow phù hợp.

Sửa lỗi:

bash
gcloud compute firewall-rules create allow-from-source \
  --allow=tcp:443 \
  --source-tags=source-tag \
  --target-tags=dest-tag

Trường hợp 2: Thiếu Route ​

Status: UNREACHABLE
Failure: No route found for destination
Destination: 10.1.0.0/16
Route_check: No matching route

Root cause: Subnet đích không thể tiếp cận (peering chưa active, route chưa được tạo, v.v.).

Sửa lỗi: Tạo route hoặc kích hoạt VPC peering:

bash
gcloud compute networks peerings create peer-to-other-vpc \
  --network=my-network \
  --auto-create-routes \
  --peer-project=other-project \
  --peer-network=other-network

Trường hợp 3: Không tìm thấy Backend Load Balancer ​

Status: UNREACHABLE
Failure: Load balancer backend not healthy or not found
LB_config: Internal LB at 10.2.0.10
Backend_status: No healthy backends

Root cause: VM backend không ở status healthy (health check bị fail).

Debug:

bash
gcloud compute backend-services get-health my-backend-service \
  --region=us-central1
# Kiểm tra status health của từng backend

Trường hợp 4: Peering chưa hoạt động ​

Status: UNREACHABLE
Failure: VPC peering not active
Peering_state: INACTIVE

Root cause: Peering đã tạo nhưng hai phía chưa chấp nhận, hoặc đã bị xóa.

Sửa lỗi: Kiểm tra status peering và chấp nhận nếu cần:

bash
gcloud compute networks peerings list --network=my-network
gcloud compute networks peerings update peer-name \
  --auto-create-routes

Giải thích Kết quả Live Data Plane Probe ​

Khi chạy phân tích live, cần chú ý đến:

Packet Loss > 0% ​

Packet loss: 5%
Status: PARTIALLY_REACHABLE

Điều này chỉ ra:

  • Nghẽn mạng (network congestion).
  • Đường truyền bị nghẽn ở hàng đợi (path queueing).
  • Sự cố kết nối chập chờn.
  • Firewall nguồn/đích chặn ICMP (nếu mất 100% packet).

Khi packet loss 100% nhưng config analysis báo reachable:

  • Firewall ứng dụng hoặc IDS/IPS chặn ICMP.
  • Hệ điều hành đích cấu hình net.ipv4.icmp_echo_ignore_all=1.
  • Firewall rule chặn ICMP nhưng cho phép TCP/UDP.

Latency cao hoặc biến động lớn ​

RTT: 45.2ms (min: 2.1ms, max: 120.5ms)
Variance: Very high

Chỉ ra:

  • Đường truyền qua nhiều hop (cross-region).
  • Nghẽn mạng.
  • Xếp hàng ở mức độ switch.
  • Sai tuyến (routing loop, packet bouncing).

Action: Kiểm tra route, xác minh đường truyền ngắn nhất, cân nhắc sử dụng Cloud Interconnect nếu latency cao liên tục.

Giới hạn của Connectivity Tests ​

Một số giới hạn quan trọng cần nắm rõ:

  1. Application layer là hộp đen (black box) — Test chỉ kiểm tra layer 3-4. Không kiểm tra logic ứng dụng, API version, hay cơ chế xác thực.
  2. ICMP có thể không tương đồng với app protocol — App dùng TCP 443, probe dùng ICMP. Nếu firewall chặn TCP nhưng cho phép ICMP, probe sẽ thành công nhưng app vẫn lỗi.
  3. Không hỗ trợ custom data plane appliances — Nếu dùng VM firewall custom hoặc NAT appliance, Connectivity Tests không thể mô phỏng.
  4. Không test đường truyền egress internet — Connectivity Tests không kiểm tra đường truyền ra internet. Nó chỉ kiểm tra đến các tài nguyên GCP, on-premises qua VPN/Interconnect, hoặc IP public (hỗ trợ một phần).
  5. Không mô phỏng hoàn toàn session/stateful rules — Firewall rules có thể phức tạp. Connectivity Tests mô phỏng tốt các rule cơ bản nhưng các trường hợp đặc biệt có thể cho kết quả sai lệch.
  6. Không kiểm tra Service Mesh policies — Nếu dùng Anthos Service Mesh hay Istio, Connectivity Tests không kiểm tra mTLS policies hay traffic policies. Nó chỉ kiểm tra hạ tầng mạng bên dưới.

Khi nghi ngờ các giới hạn bị ảnh hưởng:

  • Bật VPC Flow Logs để theo dõi traffic thực tế.
  • Kiểm tra logs ứng dụng trên destination.
  • Theo dõi request đầu-cuối bằng Cloud Trace.

Best Practices ​

1. Luôn chạy Connectivity Tests trước tiên ​

Chạy thử trước. Nó nhanh, giải quyết được 90% trường hợp, và tiết kiệm thời gian debug.

2. Sử dụng Configuration Analysis để xác thực định kỳ ​

Tích hợp Connectivity Tests vào CI/CD pipeline để xác thực cấu hình mạng trước khi deploy lên production:

bash
# Ví dụ: xác thực peering hoạt động trước khi deploy
gcloud compute network-management connectivity-tests create pre-deploy-validation \
  --source-instance=projects/project/zones/zone/instances/test-source \
  --destination-instance=projects/other-project/zones/zone/instances/test-dest \
  --async

# Nếu kết quả là UNREACHABLE, dừng deploy

3. Kiểm tra cả hai chiều (Bidirectional) ​

Nếu debug chiều A → B, hãy kiểm tra cả chiều B → A. Firewall rules có thể bất đối xứng:

  • A có thể tiếp cận B (A cho phép egress + B cho phép ingress).
  • B không thể tiếp cận A (B chặn egress).

4. Kiểm tra nhiều Protocol/Port khác nhau ​

Connectivity Tests hỗ trợ chỉ định protocol (TCP, UDP, ICMP) và port. Hãy test đúng port mà ứng dụng thực tế sử dụng:

bash
# Kiểm tra riêng TCP 443
gcloud compute network-management connectivity-tests create test-https \
  --source-instance=... \
  --destination-instance=... \
  --protocol=TCP \
  --destination-port=443

5. Lưu lại Kết quả Baseline ​

Khi thiết lập hạ tầng thành công, hãy lưu kết quả Connectivity Tests làm baseline. Khi có lỗi xảy ra, chạy lại và so sánh:

bash
# Export baseline
gcloud compute network-management connectivity-tests describe test-vm-to-vm \
  --format=json > baseline-connectivity.json

# Chạy lại và so sánh sau đó

6. Kết hợp với VPC Flow Logs ​

Nếu Connectivity Tests báo reachable nhưng kết nối vẫn lỗi, hãy bật VPC Flow Logs ngay lập tức. Flow logs cung cấp dữ liệu packet thực tế mà Connectivity Tests không thể cung cấp.

References ​