Giới hạn của Cloud VPN không thể tinh chỉnh: thời hạn IKE và NAT phía peer

Gán cho thiết bị đầu xa thời hạn pha 1 là 24 giờ và đường hầm Cloud VPN sẽ vẫn nằm xuống, dù mọi thứ phía Google đã được cấu hình đúng. Peer đang đề xuất một giá trị mà bên phản hồi sẽ không chấp nhận, nên quá trình thương lượng hoặc thất bại hoàn toàn hoặc khởi động lại vô hạn. Cloud VPN giới hạn pha 1 ở 36,000 giây, tức mười giờ, và mức trần đó không phải là cài đặt bạn có thể nâng lên. Thay đổi phải nằm ở thiết bị đầu xa.

Peer hỏi, bên phản hồi quyết định

IKE là bài tập khớp nối giữa hai bộ đề xuất. Đường hầm chỉ hình thành ở nơi hai bộ chồng lấn trong giới hạn mà bên phản hồi chấp nhận, vì thế một thời hạn ngoài khoảng sẽ không tạo ra đường hầm một phần nào cả. Sai lầm thường gặp là coi cấu hình của peer như danh sách mong muốn thay vì một đề xuất. Giao rỗng khiến đường hầm vẫn nằm xuống, dù định tuyến và các bộ chọn có đúng đến đâu.

Hãy đọc trạng thái của chính đường hầm trước khi mở phiếu, vì trạng thái chi tiết thường nêu tên pha đã thất bại:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

So sánh những gì trả về với bộ được hỗ trợ cho loại cổng và phiên bản IKE của bạn, và ghi lại cả hai bộ chọn lưu lượng khi bạn ở đó. Việc lệch bộ chọn cho cùng triệu chứng đường hầm nằm xuống như lệch thuật toán, và khác với thuật toán, phần này bạn phải tự sửa.

36,000 giây là mức trần

Pha 1 dừng ở 36,000 giây. Một thiết bị đặt 86,400 đang yêu cầu điều mà bên phản hồi sẽ không bao giờ đồng ý, và thử lại không làm thay đổi ý định đó. Kéo đề xuất đầu xa trở lại trong khoảng và cấu hình đó sẽ được thiết lập; sự bất đối xứng chính là toàn bộ bài học, vì bạn có thể hạ giá trị của mình nhưng không thể nâng giá trị của Google.

Hãy ghi giá trị đã chọn vào ghi chú thiết kế. Nếu không, kỹ sư tiếp theo sẽ lặp lại thí nghiệm 24 giờ và đụng đúng bức tường đó.

Bộ được hỗ trợ được công bố theo loại cổng và phiên bản IKE trong tổng quan Cloud VPN, nên hãy đọc phần dành cho sơ đồ mạng của bạn thay vì một hướng dẫn IKE chung.

Một đường hầm rơi theo lịch

Pha 2 hành xử khác: khi hai đầu không đồng ý, việc làm mới khóa theo khoảng ngắn hơn. Peer coi sự lệch là nghiêm trọng sẽ cho đường hầm rơi xuống thay vào đó, nên một sự lệch có thể trông như hai lỗi không liên quan. Hãy nhìn nhịp làm mới khóa, không chỉ lần kết nối đầu tiên. Một đường hầm lên rồi rơi đều đặn thường là lệch thời hạn hơn là lỗi định tuyến.

Hãy đối chiếu các mốc thời gian rơi đó với nhật ký của chính peer trước khi sửa bất cứ thứ gì, vì thay đổi bộ chọn hoặc tuyến có thể bắt chước cùng nhịp. Nếu nhịp khớp với bộ đếm thời gian pha 2 thì nguyên nhân đã được tìm ra mà không cần chạm vào đề xuất.

Các bộ đến từ loại cổng

Bộ mã hóa và toàn vẹn không phải hồ sơ cho từng đường hầm mà bạn chỉnh như strongSwan cho phép. Bạn chọn chúng theo loại cổng và phiên bản IKE, và việc đi tìm một hồ sơ không tồn tại chỉ làm mất một buổi chiều.

Một thiết bị cũ không cung cấp gì trong bộ được hỗ trợ để lại hai con đường trung thực: thay thiết bị, hoặc kết thúc trên một cổng phần mềm do bạn kiểm soát và định tuyến vào VPC từ đó. Mọi thứ khác là giải pháp lách sẽ trượt ở lần đánh giá tiếp theo.

Một địa chỉ bên ngoài cho mỗi thiết bị

Địa chỉ bên ngoài của peer phải ánh xạ một-một với địa chỉ bên trong của nó. Một bể PAT quá tải không thể hoạt động, vì nhiều máy chủ sau một địa chỉ công cộng không cho bên phản hồi cách nào để tách chúng ra. Ở nơi nhiều máy chủ phải chia sẻ một địa chỉ, đường hầm phải kết thúc ở nơi có thể phân biệt chúng.

Hãy giữ địa chỉ bên ngoài đó ổn định. Dời thiết bị ra sau một NAT khác và liên kết sẽ đứt dù mọi đề xuất vẫn khớp. Đáng để ghi lại giá trị nào của Google và giá trị nào của bạn: thời hạn, các bộ và NAT một-một là cố định ở phía họ, còn đề xuất, bộ chọn, định tuyến và ưu tiên BGP là của bạn.