Cloud Run đến VPN nội bộ: thiết lập Direct VPC egress

Đường hầm đang hoạt động, một VM đến được máy chủ nội bộ, nhưng dịch vụ Cloud Run lại hết thời gian chờ trên cùng máy chủ đó. Đây là điểm khởi đầu bình thường cho tác vụ này, và đường hầm hiếm khi là thứ sai. Một bản sửa đổi Cloud Run không nằm trong VPC của bạn theo mặc định, và khi nó nằm trong đó, nó dùng địa chỉ nguồn riêng thay vì subnet VM mà bạn đã định tuyến. Runbook dưới đây gắn dịch vụ, định tuyến dải nguồn thực tế của nó, rồi chứng minh đường đi từ bản sửa đổi đã phục vụ yêu cầu. Hãy chạy theo đúng thứ tự đó, vì bỏ qua bước đầu tiên là lý do nhiều trường hợp như thế này kết thúc bằng một thay đổi VPN không sửa được gì.

Gắn bản sửa đổi trước khi gỡ lỗi đường hầm

Cloud Run hỗ trợ Direct VPC egress, đưa lưu lượng của dịch vụ lên một subnet trong VPC của bạn mà không cần trình kết nối Serverless VPC Access. Với dịch vụ hiện có, bản cập nhật trông như sau:

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

Thay các placeholder, xem xét việc triển khai ảnh hưởng gì đến lưu lượng trực tiếp, và chọn một subnet trong khu vực của dịch vụ có đủ dung lượng địa chỉ và quyền mạng phù hợp.

Chọn chế độ ra phù hợp với đích

private-ranges-only gửi các đích mà nó phân loại là riêng tư qua VPC. Điều đó không có nghĩa là «mọi thứ có thể đến được qua VPN», và khoảng trống đó xuất hiện khi dịch vụ nội bộ nằm trong một dải mà thiết lập không phân loại như vậy. Nếu đích không được bao phủ, all-traffic là chế độ khác đã được ghi nhận, và nó gửi mọi thứ qua VPC, kể cả các phụ thuộc công khai của dịch vụ. Hãy chọn có ý thức và ghi hệ quả vào bản ghi thay đổi.

Dịch vụ đã dùng trình kết nối cần di chuyển chứ không phải bật tắt, nên hãy lập kế hoạch thay vì cấu hình cả hai.

Định tuyến nguồn Cloud Run, không phải nguồn VM

Direct VPC egress cấp địa chỉ tạm thời từ subnet đã chọn, và phía nội bộ phải trả lưu lượng về dải đó. Một tuyến trả về hoặc quyền tường lửa viết cho subnet VM khác sẽ trông đúng trên sơ đồ và thất bại trong thực tế. Lấy CIDR của subnet từ VPC chứ không từ trí nhớ, rồi xác nhận rằng ACL mật mã hoặc bảng tuyến của thiết bị từ xa có bao gồm nó.

Với định tuyến động, hãy xác minh Cloud Router thực sự quảng bá gì và VPC nhập gì, kể cả mọi chính sách quảng bá tùy chỉnh. Một tuyến tồn tại trong bảng điều khiển nhưng không được chọn cho đích này cũng như không có tuyến.

Ba điều kiện phải cùng thỏa mãn

Một đường đi hoạt động cần tất cả những điều sau, và mỗi điều kiện hỏng theo cách riêng của nó:

• Một tuyến trong VPC hướng tới tiền tố nội bộ qua kết nối Cloud VPN dự kiến.
• Một tuyến ngược phía nội bộ cho subnet Cloud Run.
• Phạm vi bảo vệ của tường lửa và IPsec cho phép nguồn, đích và cổng.

Một tuyến thiếu thường trông như hết thời gian chờ mà không có bằng chứng phía xa. Sự cố tuyến ngược trông như yêu cầu đến và phản hồi biến mất. Sự cố tường lửa hoặc bộ chọn có thể trông như bị từ chối hoặc bị thả im lặng, tùy thiết bị. Xác định bạn đang gặp điều nào trong ba điều đó giúp thu hẹp lệnh tiếp theo rất nhiều.

Đừng đưa một địa chỉ Cloud Run tạm thời vào danh sách cho phép. Hãy dùng dải của subnet và thiết kế ủy quyền phù hợp với ứng dụng.

Kiểm tra bản sửa đổi đã phục vụ yêu cầu

Kiểm tra cài đặt mạng đã triển khai và phân bổ lưu lượng trước khi thử, vì bản cập nhật có thể tạo bản sửa đổi mới trong khi yêu cầu vẫn đến bản cũ hơn. Sau đó thực hiện đúng thao tác mà yêu cầu của người dùng thực hiện, từ bản sửa đổi đó. Nếu đích là tên máy chủ riêng, hãy kiểm tra phân giải của nó trong môi trường đó và địa chỉ nó tạo ra, vì câu trả lời DNS doanh nghiệp từ máy tính xách tay của bạn không chứng minh gì về không gian tên của dịch vụ. Giữ nguyên việc xác minh tên máy chủ TLS và xác thực riêng của ứng dụng từ xa.

Hãy chờ các độ trễ kết nối khởi động của Direct VPC đã được ghi nhận, và trao cho ứng dụng khách chiến lược sẵn sàng hoặc thử lại thay vì chẩn đoán mọi lần khởi động nguội là đường hầm hỏng.

Hoàn tác và những gì điều này không làm

Để hoàn tác, đặt cài đặt mạng và lối ra của dịch vụ trở lại giá trị trước đó và xác nhận bản sửa đổi trước vẫn phục vụ lưu lượng. Giữ lệnh gcloud trong bản ghi thay đổi, vì việc đảo ngược một thay đổi cục bộ không rõ ràng sau sáu tuần. Gỡ gắn kết VPC đưa dịch vụ trở lại đường ra trước đó, có thể đúng là điều bạn muốn trong một sự cố.

Thiết kế này bao gồm các kết nối do Cloud Run khởi tạo và phản hồi của chúng. Nó không cấp cho mạng nội bộ một socket có thể định địa chỉ bên trong dịch vụ, vì việc phơi ra bên trong là quyết định ingress.