Chương 63: Phương pháp Troubleshooting Network trên GCP
Tổng quan
Network troubleshooting trên Google Cloud Platform là skill thiết yếu cho bất kỳ production engineer nào. Các vấn đề network có thể xuất phát từ nhiều tầng khác nhau: VPC configuration, firewall rules, routing decisions, DNS resolution, NAT port exhaustion, load balancer health checks, hay service mesh traffic policies. Mỗi layer có các tool riêng, mental model riêng, và cách debug riêng.
Chương này không phải là hướng dẫn dạng tutorial cho beginner. Nó là một troubleshooting methodology cho senior engineers: cách tư duy về network systematically, khi nào dùng tool gì, cách đọc output để hiểu bản chất vấn đề, và cách từ debugging logs suy luận về root cause.
Điều kiện tiên quyết: Bạn cần hiểu:
- VPC model và architecture (Chương 3)
- IAM và resource hierarchy (Chương 1)
- GKE networking nếu debug Kubernetes (Chương 7)
- Cloud DNS (Chương 4)
Tại sao Network Troubleshooting khó
Network issues ở scale production có những đặc điểm làm chúng khó debug:
- Tính chất phân tán (Distributed nature) — vấn đề có thể nằm ở client, network path, hoặc server.
- Lấy mẫu và tổng hợp (Sampling and aggregation) — VPC Flow Logs sample packets, không log 100% traffic.
- Tính chất bất đồng bộ (Async nature) — thay đổi firewall rules, update routes, và health checks chạy trong background.
- Tương tác giữa các layer (Cross-layer interactions) — vấn đề ở layer 3 (routing) có thể trông giống layer 4 (firewall).
- Hành vi nhạy cảm với thời gian (Time-sensitive behavior) — race conditions, timing issues rất khó reproduce.
Troubleshooting Mindset
Trước khi dive vào tool, bạn cần tư duy đúng:
1. Hỏi "Cái gì vỡ ở đâu?"
Không phải "network bị lỗi". Mà cụ thể:
- Traffic từ A có đến được B không? (connectivity)
- Nếu có, latency ra sao? (performance)
- Nếu không, vỡ ở layer nào? (firewall? routing? DNS?)
2. Cô lập Layer bị lỗi (Isolate Problem Layer)
Network có 4 layer cần debug riêng rẽ:
- Layer 1-2 (Link): Physical/Datalink. Thường không phải vấn đề trên GCP managed services.
- Layer 3 (Network): IP routing, ARP. Debug bằng routes, connectivity tests.
- Layer 4 (Transport): TCP/UDP, port mappings. Debug bằng firewall rules, NAT.
- Layer 7 (Application): DNS resolution, HTTP headers, TLS. Debug bằng DNS logs, app logs.
Hầu hết network issues trên GCP nằm ở Layer 3-4.
3. Quy trình Debug hệ thống (Systematic Debugging Process)
Một process systematic luôn tốt hơn việc thay đổi rồi hy vọng:
- Xác thực cấu hình (Validate configuration) — Dùng Connectivity Tests (configuration analysis phase).
- Kiểm tra kết nối (Test connectivity) — gửi actual traffic (gửi probes qua Connectivity Tests live data plane, ping, curl).
- Thu thập traffic (Capture traffic) — VPC Flow Logs, packet captures.
- Phân tích logs (Analyze logs) — trace traffic flow, xác định vị trí packets bị drop hoặc modified.
- Tái hiện nhất quán (Reproduce consistently) — nếu không tái hiện được, rất khó scale solution.
Cấu trúc của Chương
Chương này được tổ chức thành 8 subtopic, mỗi phần cover một khía cạnh của network troubleshooting:
1. Connectivity Tests
Tool native GCP dùng để simulate packet path trước khi gửi traffic thật. Bao gồm configuration analysis (kiểm tra rules, routes, policies) và live data plane analysis (gửi actual probes). Đây là điểm bắt đầu của mọi network troubleshooting.
Cơ chế: Mô phỏng finite state machine, cơ chế probe, và điều kiện hỗ trợ live analysis.
Khi dùng: Mỗi khi có connectivity issue, bắt đầu bằng Connectivity Tests để check cấu hình trước tiên.
2. VPC Flow Logs
Packet-level observability vào network traffic. Capture 5-tuple (source IP, dest IP, source port, dest port, protocol) với fields chi tiết: bytes sent, action (accept/deny), start/end time.
Cơ chế: Two-stage sampling (primary + secondary), aggregation window, firewall rule evaluation timing (egress được sample trước firewall, ingress được sample sau).
Khi dùng: Khi biết traffic vỡ ở Layer 3-4 và cần packet-level details để confirm firewall blocking, routing loop, v.v.
3. Firewall Debugging
VPC firewall rules evaluation order (priority-based), matching logic, cách rules tương tác. Cách dùng VPC Flow Logs để confirm firewall denial.
Cơ chế: Đánh giá theo priority (0-65535), xử lý tiebreaker khi cùng priority (deny wins), matching algorithm, protocol specificity không override priority.
Khi dùng: Khi traffic bị deny, cần check xem firewall rule có phải là culprit hay không.
4. Route Troubleshooting
Packet destination matching, 11-step route selection algorithm, hành động của most-specific-match, ECMP (equal-cost multipath), khi nào route bị replace.
Cơ chế: Destination matching logic, metric-based selection, policy-based routes priority, hành động khi không tìm thấy route.
Khi dùng: Khi traffic đi sai hướng, traffic bị drop không phải do firewall, hoặc latency bất thường.
5. DNS Debugging
Cloud DNS vs. Compute Engine internal DNS, resolution path, TTL issues, query logging, common resolution failures.
Cơ chế: Thứ tự phân giải tên miền (internal > Cloud DNS managed zones > default nameservers), metadata server fallback, cách cache hoạt động, response codes.
Khi dùng: Khi application không resolve được hostnames, connection failures chập chờn, DNS latency issues.
6. NAT Issues
Cloud NAT port allocation, port exhaustion diagnosis, monitoring metrics, tuning strategies.
Cơ chế: Mô hình distributed NAT, port allocation strategy, port reuse, IP address scaling, monitoring fields.
Khi dùng: Khi các kết nối outbound bị fail, cảnh báo port exhaustion, hoặc giảm performance khi gọi external services.
7. Load Balancer Debugging
Health checks (protocols, thresholds, firewall requirements), backend state transitions, traffic distribution, logging.
Cơ chế: Health check probers, threshold mechanics, state machine (healthy ↔ unhealthy), balancing modes, session affinity.
Khi dùng: Khi một số backends unhealthy, traffic không được cân bằng, hoặc connection bị drop.
8. Service Mesh Networking
Envoy sidecar proxy traffic flow, mTLS, traffic policies, debugging Envoy logs, tracing integration.
Cơ chế: Control plane → data plane, sidecar injection, traffic interception, Envoy config, observability qua access logs.
Khi dùng: Khi có vấn đề về service-to-service communication, mTLS handshake failures, hoặc traffic policy không hoạt động.
Quy trình Debug (Tổng quan)
Đây là workflow chung cho hầu hết network issues:
1. Nhận báo cáo: "Connectivity vỡ" / "Traffic bị chặn" / "Latency cao"
↓
2. Hỏi: Các endpoint cụ thể bị ảnh hưởng? Protocol? Pattern?
↓
3. Chạy Connectivity Tests (để phân tích cấu hình)
→ Tìm thấy lỗi cấu hình? Sửa lỗi và hoàn thành.
→ Cấu hình bình thường? Chuyển sang bước 4.
↓
4. Chạy Connectivity Tests (để phân tích live data plane)
→ Probe thành công nhưng traffic của khách hàng vẫn fail? Check app-level.
→ Probe thất bại? Chuyển sang bước 5.
↓
5. Enable VPC Flow Logs, capture traffic
↓
6. Phân tích logs:
- Traffic được accept hay drop? (action=accept/deny)
- Đã đến được đích chưa? (Check routes, hops)
- Source port có sẵn sàng không? (Check NAT exhaustion nếu là outbound)
↓
7. Liên kết kết quả với các layer cụ thể:
- Bị drop ở ingress firewall? → Check firewall rules
- Bị drop ở egress firewall? → Check firewall rules
- Sai đích đến? → Check routes
- Source port không khả dụng? → Check NAT
- Backend không phản hồi? → Check health checks
- Lỗi service-to-service? → Check service mesh policies
↓
8. Sửa lỗi, test lạiĐiểm mấu chốt: Dùng Connectivity Tests trước để tránh lãng phí thời gian. Nó sẽ tiết kiệm hàng giờ troubleshooting.
Các Pattern phổ biến
Khi troubleshooting, tìm các pattern này:
Pattern 1: "Chạy ở local, fail từ bên ngoài"
Root cause thường là: Thiếu firewall ingress rule, hoặc NAT configuration sai. Debug: Check firewall rules cho ingress traffic, check NAT gateway config.
Pattern 2: "Thỉnh thoảng chạy, chập chờn"
Root cause thường là: Health check thresholds, port exhaustion, hoặc race condition. Debug: Check health check logs, NAT metrics, check timestamp pattern.
Pattern 3: "DNS chạy, nhưng kết nối bị timeout"
Root cause thường là: Thiếu firewall rule, routing failure, hoặc backend unhealthy. Debug: DNS log shows resolution, nghĩa là DNS bình thường. Check firewall rules, routes, load balancer backends.
Pattern 4: "Latency cao đến cùng một service"
Root cause thường là: ECMP không cân bằng, session affinity hướng traffic vào backend xấu, hoặc NAT port contention. Debug: Check LB traffic distribution, backend latencies, NAT port allocation.
Bảng tổng hợp Công cụ
| Công cụ | Trường hợp sử dụng | Output | Thời gian có kết quả |
|---|---|---|---|
| Connectivity Tests | Kiểm tra xem path có chạy không | Phân tích cấu hình + kết quả probe | 20s-10m |
| VPC Flow Logs | Debug ở mức độ packet | 5-tuple + metadata | Thời gian thực (có trễ) |
| Firewall Insights | Tìm các rules quá rộng | Gợi ý tối ưu rule | Thời gian thực |
| Cloud Trace | Đo lường latency đầu-cuối | Trace spans | Thời gian thực |
| Cloud Logging | Debug ở mức độ app | Custom logs | Thời gian thực |
| gcloud commands | Kiểm tra nhanh | Dữ liệu rule/route/DNS | Vài giây |
Ghi chú về Production Debugging
Một vài lưu ý khi debug trên môi trường production:
VPC Flow Logs có sampling — Logs có thể bị sót do primary sampling. Việc logs không hiển thị không đồng nghĩa với traffic không tồn tại.
Health checks từ Google ranges — Nếu chặn Google IP ranges, health checks sẽ fail. Firewall rules phải allow từ
35.191.0.0/16và130.211.0.0/22.Cơ chế cache TTL — DNS response có thể được cache ở client. Phân giải mới sẽ không phản ánh ngay lập tức ở client mà phải đợi hết TTL cũ.
Trễ propagate của route — Thay đổi custom route mất tới 5 phút để propagate đến tất cả forwarding engines.
Thứ tự firewall rule — Không có khái niệm "thứ tự". Số priority (0-65535) sẽ định nghĩa quyền ưu tiên.
Độ trễ của Envoy sidecar — Service mesh làm tăng latency (thường 10-50ms mỗi hop) do traffic phải đi qua sidecar proxy.