Truy cập từ xa của nhà phát triển vào Google Cloud VPC: chọn đường đi

Một nhà phát triển cần một phiên SSH, một cổng cơ sở dữ liệu hoặc quyền truy cập rộng vào hàng chục dịch vụ riêng tư, và mỗi yêu cầu đó trông giống như cùng một câu hỏi. Không phải vậy. Các đích đến, giao thức và danh tính liên quan quyết định đường truy cập Google Cloud nào phù hợp, và việc chọn đường rộng nhất theo mặc định tạo ra công việc mà bạn không cần phải sở hữu.

Ghi ra các đích đến và giao thức

Liệt kê các địa chỉ riêng, cổng và giao thức mà công việc thực sự cần, sau đó đánh dấu những danh tính phải được xác thực riêng. Một cổng cơ sở dữ liệu và một vùng DNS riêng là những yêu cầu khác nhau, và một dịch vụ UDP loại bỏ hoàn toàn một trong các lựa chọn bên dưới. Một danh sách bằng văn bản cũng cho thấy điều bạn không cấp. Đó là phần mà người đánh giá hỏi đến.

Hãy làm điều này trước khi mở trình lắng nghe. Danh sách sau này trở thành bài kiểm tra chấp nhận, và đó là cách duy nhất đáng tin cậy để phân biệt một đường hầm hẹp với một đường hầm rộng tình cờ hoạt động.

IAP cho một vài dịch vụ TCP

Chuyển tiếp TCP trong Identity-Aware Proxy cung cấp một đường hầm đã xác thực đến các tài nguyên VM đủ điều kiện mà không đưa dịch vụ ra internet. Hình thức hàng ngày là gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, và một cổng duy nhất có thể được chuyển tiếp cục bộ với gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Ba điều phải khớp: bên gọi cần vai trò truy cập đường hầm IAP, tường lửa phải chấp nhận dải nguồn IAP, và đích đến phải có thể truy cập trên phiên bản. Quyền tạo đường hầm không phải là thông tin xác thực cơ sở dữ liệu, đăng nhập SSH hay phiên RDP, vì vậy hãy giữ xác thực ứng dụng ở nơi nó thuộc về.

Chuyển tiếp TCP trong IAP không phải là VPN lớp ba. Nó mang TCP đến một đích đã chọn, không phải lưu lượng IP tùy tiện hay UDP, và nó không phù hợp khi một ứng dụng cần DNS riêng trên nhiều dịch vụ.

VPN truy cập từ xa để có phạm vi tiếp cận rộng hơn

Khi cần nhiều đích đến, giao thức hoặc vùng DNS riêng, hình thức tốt hơn là một VPN truy cập từ xa được quản lý rõ ràng trên VM hoặc thiết bị được hỗ trợ. Việc triển khai đó tách biệt với Cloud VPN do Google quản lý: bạn sở hữu việc đăng ký danh tính máy khách, cập nhật phần mềm, tuyến máy khách và tuyến quay lại trong VPC.

Lập kế hoạch cho toàn bộ danh sách, không chỉ trình lắng nghe công khai. Bao gồm nhóm đường hầm, tuyến VPC quay lại đó, kiểm soát chuyển tiếp, phân giải DNS và chính sách truy cập theo từng dịch vụ. Một VPN kết nối được nhưng không phân giải được tên nội bộ sẽ làm hỏng quy trình của nhà phát triển hoàn toàn như một VPN không bao giờ kết nối.

Cloud VPN là cổng của site, không phải hồ sơ máy tính xách tay

Google Cloud VPN kết nối các cổng ngang hàng qua IPsec, và câu hỏi thường gặp của nó tách vai trò site-tới-site đó khỏi quyền truy cập máy khách-tới-cổng. Việc tạo đường hầm không tạo ra hồ sơ mà nhân viên nhập vào máy tính xách tay. Sự khác biệt này quan trọng khi ai đó yêu cầu hồ sơ Cloud VPN. Câu trả lời là một sản phẩm khác.

Điều một cổng làm tốt là cho các máy sau một mạng văn phòng một tuyến vào VPC. Nó không xác thực từng nhân viên và không cấp quyền ứng dụng, vì vậy các chính sách đó vẫn ở lớp mạng và lớp ứng dụng, nơi chúng có thể được thực thi theo danh tính.

Xác minh và ghi lại

Trước tiên hãy kiểm tra đích hẹp nhất, sau đó là đích cần DNS, rồi một đích phải tiếp tục bị từ chối. Chạy mỗi bài kiểm tra từ cùng máy khách sẽ dùng đường đi trong môi trường sản xuất, vì một bài kiểm tra thành công từ máy trạm của quản trị viên chứng minh rất ít về máy tính xách tay của nhà phát triển với mạng khác.

Ghi lại mô hình đã chọn, các đích nó bao phủ, các danh tính nó xác thực và hành vi khi thất bại khi đường đi không khả dụng. Bản ghi đó chính là thứ ngăn yêu cầu tiếp theo âm thầm mở rộng đường hầm thay vì thêm một đích vào một thiết kế đã được ghi lại.