VPN vào VPC hoạt động, nhưng dịch vụ được quản lý hết thời gian chờ
Đường hầm kết thúc ở biên của bạn, không phải ở cửa trước của nhà cung cấp. Hãy phân loại mục tiêu là lưu trữ trên VM, gắn với VPC hay chỉ công khai trước khi thay đổi tuyến.
Truy cập cơ sở dữ liệu được quản lý qua VPN thường thất bại vì một lý do mà không ai ghi vào runbook: đường hầm kết thúc ở biên mạng của bạn, trong khi dịch vụ chưa bao giờ nằm ở phía bạn của biên đó. Bảng tuyến trông đúng, đường hầm báo hoạt động, và kết nối vẫn hết thời gian chờ. Hãy thực hiện bốn kiểm tra dưới đây theo thứ tự và dừng ở kiểm tra đầu tiên có điều kiện đạt không thỏa mãn, vì mọi kiểm tra sau đó đều giả định các kiểm tra trước đã đạt.
Kiểm tra một: điểm cuối thực sự nằm ở đâu?
Một cổng VPN nối hai mạng mà bạn kiểm soát địa chỉ. Dịch vụ được quản lý vận hành phía sau cửa trước của chính nhà cung cấp, và cửa đó có một trong ba dạng tùy theo sản phẩm. Nếu bạn không biết mình đang xử lý dạng nào, mọi công việc về tuyến sẽ không giúp gì, vì lỗi có thể không phải là lỗi tuyến.
| Shape | What it means | Pass condition |
|---|---|---|
| Software on your VM | Ordinary subnet addressing | Route and security group permit the client |
| Attached to your VPC | Private, but only inside that VPC | Endpoint associated, source allowed, route present |
| Provider-hosted, public endpoint | Optional private link, not private by default | A private endpoint exists and DNS points at it |
Phần lớn những buổi chiều bị mất đến từ việc bỏ qua phân loại này và đi thẳng vào bảng tuyến. Một dịch vụ lưu trữ tại nhà cung cấp có điểm cuối công khai không nằm sau đường hầm của bạn bất kể sơ đồ nói gì, và dịch vụ gắn với VPC sẽ không bao giờ xuất hiện trong câu trả lời DNS công khai.
Kiểm tra hai: dịch vụ gắn với VPC như ElastiCache
Bộ nhớ đệm loại đó được đánh địa chỉ bên trong VPC của chính bạn và không có trình lắng nghe nào hướng ra internet. Một VPN máy khách kết thúc trong cùng VPC đó có thể tiếp cận chúng, nhưng chỉ khi ba điều kiện cùng thỏa mãn. Điểm cuối của bộ nhớ đệm phải được liên kết với các mạng con mà đường hầm của bạn nhìn thấy, nhóm bảo mật của nó phải cho phép địa chỉ mà máy khách của bạn đến từ đó, và phía máy khách cần một tuyến bao phủ các mạng con của bộ nhớ đệm.
Lỗi thường gặp là giả định rằng một kết nối ở đâu đó gần đó cũng được tính. Việc gắn VPN vào một VPC khác, hoặc chỉ dựa vào peering, không mở rộng nhóm bảo mật của bộ nhớ đệm hay bảng tuyến của mạng con đó tới máy khách của bạn. Khi đường hầm hiện có kết thúc ở nơi khác, một máy chủ nhảy hoặc máy chủ VPN đặt bên trong VPC đó là phương án dự phòng thường lệ. Phương án đó là một lối vòng và không phải thiết kế, và nên được ghi nhãn như vậy trong runbook.
Kiểm tra ba: điểm cuối PaaS có tên công khai
Azure Database for PostgreSQL trình bày một tên máy chủ công khai. Nó không cấp cho bạn một địa chỉ riêng để bạn ghim vào tệp hosts và định tuyến qua cổng. Các điểm cuối dịch vụ của mạng ảo giới hạn mạng con nào có thể tiếp cận tài nguyên; chúng không cấp quyền cho máy khách tại chỗ đi đến qua VPN.
Để có quyền truy cập riêng, cần đưa vào một điểm cuối riêng hoặc thiết kế liên kết riêng, rồi thêm vùng DNS riêng để tên công khai trả lời bằng điểm cuối đó thay vì internet. VPN kết hợp với quy tắc điểm cuối dịch vụ là một kiến trúc khác chỉ trông giống trên sơ đồ. App Service tuân theo cùng logic từ hướng ngược lại: tích hợp VNet cho phép ứng dụng thực hiện các cuộc gọi đi vào VNet và không tạo ra đường riêng đi vào từ đường hầm của bạn. Vì vậy quyền truy cập riêng đi vào cần một điểm cuối riêng, một môi trường App Service hoặc một cổng phía trước ứng dụng, và bạn dùng được cái nào tùy thuộc vào gói.
Kiểm tra bốn: sản phẩm có cửa trước riêng
Firebase Hosting không thể gắn với Cloud VPN, vì lớp lưu trữ là một giao diện toàn cầu chứ không phải thứ gì đó bên trong VPC của dự án. Phương án thay thế được ghi lại là tự xây điểm vào được kiểm soát, bằng một phiên bản proxy hoặc bộ cân bằng tải dựa trên một xô lưu trữ. Dù thế nào thì trang cũng không còn là sản phẩm lưu trữ thuần túy và trở thành hạ tầng mà bạn vận hành. Sự đánh đổi đó đáng được nêu tên trước khi ai đó hứa rằng đường hầm sẽ bao phủ nó.
Private API Gateway nằm gần phía dịch vụ VPC hơn: một điểm cuối VPC kiểu interface công bố tên máy chủ mà câu trả lời là địa chỉ riêng, và lưu lượng từ cơ sở của bạn đến qua đường hầm hoặc một kết nối riêng. Điểm cuối phải được liên kết với API, và chứng chỉ cùng tên máy chủ phải khớp với tên miền tùy chỉnh mà người gọi sử dụng.
Các đường hầm Google Cloud VPN gắn với địa chỉ IP của đối tác, không gắn với tên. Việc chuyển tiếp DNS được cấu hình riêng, đó là lý do một đường hầm có thể hoàn toàn khỏe mạnh trong khi các tra cứu trong vùng riêng từ xa vẫn thất bại.
Sau đó xác định ranh giới
Chạy cùng kết nối đó từ một VM bên trong VPC. Khi nó thành công ở đó và thất bại từ máy khách VPN, khoảng trống nằm giữa đường của máy khách và điểm cuối của dịch vụ: một tuyến, một nhóm bảo mật, một chính sách điểm cuối hoặc một tên. Khi cả hai lần thử đều thất bại, không gì trong mạng đó tiếp cận được dịch vụ, và VPN chưa bao giờ là trở ngại.
getent hosts db.internal.example
nc -vz db.internal.example 5432Hãy tra cứu tên và kiểm tra cổng riêng rẽ, vì chúng thất bại vì những lý do khác nhau và cặp đó cho bạn biết nửa nào của đường bị hỏng. Một tên phân giải thành địa chỉ công khai đang nói với bạn rằng vùng DNS riêng không có tác dụng.