Google API qua VPN: định tuyến tới VIP, không chỉ tới subnet
Tuyến đường tới subnet trong VPC không chọn các địa chỉ VIP của API. Phân giải đúng tên, quảng bá tiền tố VIP, giữ đường quay về trong VPC, rồi kiểm tra HTTPS.
Đăng nhập vào máy chủ tại chỗ bằng SSH, bật tunnel lên và VM riêng trả lời; sau đó lệnh gọi Google API đầu tiên thất bại vì không có tuyến. Subnet của VM và các địa chỉ VIP của API là những đích khác nhau, nên tuyến cho cái này không chọn cái kia. Ba điều kiện phải đúng trước khi một lệnh gọi API riêng hoạt động. Tên API phải phân giải thành một VIP, tiền tố VIP phải được quảng bá qua tunnel, và VPC phải biết cách gửi trả lời về. Ping không cho bạn biết gì về những điều đó, và một phiên SSH hoạt động tới máy trong subnet cũng vậy.
Các địa chỉ VIP của API là những đích riêng
Google công bố các VIP chuyên dụng cho truy cập API từ mạng tại chỗ, và đó là những địa chỉ mà DNS của bạn phải trả về cho tên API. Cả hai đều là tiền tố nhỏ và không cái nào thuộc không gian RFC 1918:
| Record | Resolves to | What it does not give you |
|---|---|---|
| private.googleapis.com | 199.36.153.8/30, the general front door for Google APIs | not a bypass around a service perimeter |
| restricted.googleapis.com | 199.36.153.4/30, reachable only for services a perimeter allows | not the whole API surface, so some names stay out of reach |
Địa chỉ trông như công khai không có nghĩa là tuyến phải rời khỏi tunnel cho internet thông thường. Các tiền tố tồn tại để một máy khách tại chỗ tới được phần giao diện của Google qua một đường được hỗ trợ thay vì một điểm ra tùy ý. Hãy coi chúng là những đích thuộc về tunnel, không phải máy chủ để dò. Một quy tắc tường lửa viết cho lối ra internet thường loại bỏ chúng, và đó là lý do phổ biến khiến một lệnh gọi thất bại trước khi bắt đầu.
DNS quyết định bạn tới điểm cuối nào
Trỏ trình phân giải tại chỗ tới các bản ghi mà Google ghi tài liệu cho điểm cuối đã chọn, để những tên ứng dụng cần được trả lời bằng VIP đó. Chỉ googleapis.com không phải là một bản kiểm kê: registry gói, registry container và trình kết nối di chuyển có tên được ghi tài liệu riêng. VIP hạn chế cũng không mang mọi dịch vụ, nên một tên phân giải được vẫn có thể chưa được hỗ trợ. Ghi lại các miền mà ứng dụng thực sự liên hệ trước khi chạm vào trình phân giải.
Đoán một địa chỉ VM trong VPC thay cho tên dịch vụ không phải là cách sửa, và nó thường che lấp lỗ hổng DNS cho tới khi một máy khách khác thất bại.
Quảng bá tiền tố VIP, giữ phần còn lại
Với kết nối dựa trên BGP, Cloud Router phải quảng bá tiền tố VIP đã chọn để bộ định tuyến tại chỗ học được dải đó qua phiên đã định. Chỉ quảng bá các subnet của VPC không thêm dải đó, và bộ định tuyến tại chỗ tiếp tục dùng tuyến mặc định của nó cho những địa chỉ ấy. Tiền tố trong bảng định tuyến là bằng chứng duy nhất rằng quảng bá đã đi qua phiên.
Giữ các quảng bá hiện có trong khi thêm cái mới, vì tùy chọn ở mức bộ định tuyến và ở mức peer có phạm vi khác nhau, và thay bộ giá trị có thể rút lại những mạng đã hoạt động. Sau đó kiểm tra quảng bá hiệu lực trên từng phiên chứ không trên toàn bộ định tuyến. Tiền tố thiếu và tiền tố bị rút trông giống nhau từ phía tại chỗ, nên chính góc nhìn phiên phân biệt thiếu sót với suy giảm.
Phía VPC cần tuyến và đường quay về của riêng nó
Bên trong VPC, đường tới VIP phải dùng cổng internet mặc định làm bước nhảy tiếp theo, và bất kể tên gọi, lưu lượng đó vẫn ở trong mạng của Google. VPC cũng cần tuyến quay về nguồn tại chỗ qua VPN, và đó là một đối tượng riêng so với tiền tố được quảng bá. Hãy tính đến các yêu cầu định tuyến theo khu vực đã được ghi tài liệu khi tunnel và máy khách không ở cùng khu vực.
Kiểm tra đường quay về một cách độc lập, vì chiều yêu cầu hoạt động có thể che giấu chiều trả lời bị hỏng. Hai chiều, hai tuyến, và mỗi chiều hỏng với triệu chứng riêng.
Thử yêu cầu, rồi đọc lời từ chối
ICMP echo không nhận được trả lời từ các VIP này, nên ping thất bại không chứng minh gì và ping thành công chứng minh rất ít. Từ máy khách thật, hãy xem trả lời của tên và tuyến đã chọn, rồi gửi một yêu cầu HTTPS được cấp quyền tới dịch vụ bạn quan tâm. Nếu yêu cầu tới được dịch vụ và bị từ chối, hãy xem thông tin xác thực, IAM và bất kỳ chính sách vành đai dịch vụ nào áp dụng.
Định tuyến riêng không cấp quyền API và không thay đổi điều mà danh tính được phép làm. Thành công của vận chuyển và một trả lời được cấp quyền là hai kết quả riêng, và bạn cần cả hai. Giữ đường IPv6 cũng rõ ràng, vì việc cấu hình các tiền tố IPv4 không nói gì về một máy khách ưa IPv6.
Hướng dẫn của Google về Private Google Access từ mạng tại chỗ bao gồm cả bản ghi DNS và các yêu cầu định tuyến, nên hãy so cấu hình trình phân giải và quảng bá của bạn với nó chứ không phải với một bài đăng diễn đàn. Sau đó chạy lại đúng yêu cầu đó và ghi lại trả lời cùng tuyến trong cùng một phiếu.