Cloud VPN đến VM trên GCP: dùng IP nội bộ, không phải IP NAT

Khi một mạng tại chỗ đến được VPC qua Cloud VPN, đích đến cho một dịch vụ Compute Engine thường là địa chỉ nội bộ của VM. Địa chỉ IPv4 bên ngoài không phải là địa chỉ thứ hai mà bạn có thể thay vào cùng tuyến riêng đó. Phần lớn sự nhầm lẫn trong lĩnh vực này đến từ việc coi ba địa chỉ với ba nhiệm vụ là có thể hoán đổi cho nhau, vì vậy hãy bắt đầu bằng việc gọi tên địa chỉ mà một gói cụ thể đang dùng.

Ba địa chỉ, ba nhiệm vụ

Hãy gọi tên cả ba trước khi gỡ lỗi bất kỳ địa chỉ nào, vì câu trả lời sẽ thay đổi đối tượng bạn kiểm tra tiếp theo.

Địa chỉ thứ nhất thuộc về đường hầm. Địa chỉ thứ hai thuộc về thiết kế tuyến và tường lửa của bạn. Địa chỉ thứ ba thuộc về truy cập internet đi vào và nó được ánh xạ, không được gắn. Một thiết kế chạy được cho một trong số chúng không nói gì về hai địa chỉ còn lại.

Vì sao địa chỉ bên ngoài không phải giao diện thứ hai

Hướng dẫn đánh địa chỉ là nguồn có thẩm quyền về cách khả năng tiếp cận bên trong và bên ngoài khác nhau trên Compute Engine. IPv4 bên ngoài của Compute Engine là ánh xạ một-một lên NIC nội bộ duy nhất của phiên bản, nên khách không bao giờ thấy giao diện thứ hai hay địa chỉ thứ hai trên NIC đó. Những gì VM báo cáo từ bên trong vẫn là một địa chỉ nội bộ chính.

Đó là lý do vì sao một khách riêng định tuyến qua đường hầm tới 10.24.1.7 và một khách nhắm vào địa chỉ bên ngoài của VM nằm trên các đường khác nhau. Mở một quy tắc tường lửa cho địa chỉ công cộng không thay đổi gì trên tuyến VPC phải chuyên chở lưu lượng của đường hầm, và sửa một tuyến trên khách không dịch chuyển ánh xạ của nền tảng. Hãy chọn địa chỉ mà tuyến của bạn gọi tên, rồi chỉ kiểm tra những đối tượng chi phối địa chỉ đó. Kỷ luật này loại bỏ phần lớn phỏng đoán khỏi lối gỡ lỗi này.

Đi theo tuyến bằng gcloud

Bắt đầu từ phiên bản và đọc cả hai địa chỉ từ cùng một đối tượng, để bạn biết tài liệu của mình đang nói về địa chỉ nào:

gcloud compute instances describe app-1 --zone=europe-west1-b \
  --format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"

Sau đó xác nhận định tuyến và quyền mà tuyến thực sự phụ thuộc:

gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1

Đọc các dải được quảng bá và học được của đường hầm, tuyến VPC cho mạng con của khối công việc, và quy tắc tường lửa cho phép nguồn tại chỗ. Ba điều này phải khớp trước khi một trình nghe trên khách trở nên liên quan.

Sau đó kiểm tra khách: dịch vụ có đang lắng nghe trên địa chỉ nội bộ không, và đường quay về của nó có đi lại qua VPC không? Một trình nghe chỉ gắn với địa chỉ công cộng sẽ thất bại bài kiểm tra này ngay cả khi mọi đối tượng phía đám mây đều đúng.

Một tiền tố công cộng là câu hỏi khác

Không điều nào ở trên có nghĩa rằng mọi địa chỉ được chuyên chở trong VPN phải là RFC1918. Một mạng từ xa có thể được đánh số hợp pháp từ không gian công cộng, miễn là nền tảng hỗ trợ định tuyến và người vận hành có thẩm quyền về địa chỉ. Đó là một lựa chọn thiết kế bình thường.

Điều này không giống với việc coi một địa chỉ NAT bên ngoài thông thường như thể nó là một địa chỉ mạng con nội bộ khác. Một bên là tiền tố bạn định tuyến; bên kia là ánh xạ mà nền tảng áp dụng cho truy cập đi vào.

IPv6 bên ngoài và các cách bố trí địa chỉ được thiết kế đặc biệt có ngữ nghĩa riêng. Nếu kế hoạch của bạn phụ thuộc vào một trong số đó, hãy đọc tài liệu nền tảng cho tính năng đó thay vì khái quát hóa từ trường hợp IPv4. Ánh xạ IPv4 là trường hợp phổ biến, không phải duy nhất, và mỗi ngoại lệ có quy tắc riêng.

Các dải chồng lấn là vấn đề khác

Các dải riêng chồng lấn là lý do thực sự khiến người ta với tới địa chỉ công cộng, và đó là cần gạt sai. Đổi đích sang địa chỉ NAT của VM không giải quyết chồng lấn; nó đổi việc gói tuyên bố là dành cho địa chỉ nào, mà không định nghĩa đường quay về hoạt động ra sao.

Hãy giải quyết chồng lấn một cách có chủ đích: đánh số lại, dùng một thiết kế dịch được hỗ trợ, hoặc định tuyến qua một mạng nơi các tiền tố không xung đột. Mỗi cách trong số đó là một thiết kế có người chịu trách nhiệm. Địa chỉ NAT không phải là thiết kế.

Ghi tài liệu hai trường riêng biệt

Ghi đối tác đường hầm và đích của khối công việc thành hai trường runbook riêng biệt, mỗi trường kèm tuyến và quy tắc tường lửa hỗ trợ nó. Một đường hầm IPsec dựng lên chỉ cho bạn biết hai bên đồng ý; nó không nói gì về việc khối công việc tiếp cận được ở địa chỉ nào, cũng không nói tuyến riêng của nó đã đầy đủ chưa.

Kiểm chứng bằng một khách thật ở phía bên kia: phân giải tên, xác nhận nó trả về địa chỉ nội bộ, kết nối và kiểm tra lưu lượng quay về. tài liệu về địa chỉ IP của Compute Engine là tham chiếu cho sự phân biệt trong và ngoài được dùng ở trên.