Cloud VPN đến Cisco ASA: dựng lại sau khi đề xuất không khớp

NEGOTIATION_FAILURE trên một tunnel Cloud VPN có Cisco ASA ở đầu bên kia gần như luôn là do đề xuất hoặc các selector không khớp, và sự thật hữu ích đầu tiên là không bản chỉnh sửa nào sửa được điều đó. Cloud VPN cố định đề xuất IKE ngay khi đối tượng tunnel được tạo. Không có trường nào để đổi thuật toán tại chỗ, nên cách sửa là xóa và tạo lại với một điểm xuất phát đã ghi lại. Hãy coi đó là việc dựng lại và công việc trở thành danh sách kiểm tra thay vì một buổi chiều đoán mò.

Đọc lỗi trước khi xóa bất cứ thứ gì

Lỗi thương lượng là vấn đề về pha, và log của peer thường nêu pha. Pha 1 thất bại nghĩa là hai đầu không thống nhất được đề xuất hoặc không xác thực được nhau. Pha 2 thất bại nghĩa là tunnel đã lên nhưng các selector được bảo vệ không khớp. Đó là những cách sửa khác nhau, và dòng log đáng được trích ra trước khi ai đó chạm vào cấu hình.

Lỗi cũng loại trừ một số thứ. Đây không phải tuyến VPC, không phải quy tắc tường lửa trên giao diện tunnel và không phải lỗi phân giải tên bên trong mạng. Đuổi theo những thứ đó tạo ra các thay đổi đầy tự tin nhưng không thể đổi kết quả, và khiến việc quy kết bản sửa cuối cùng khó hơn.

Ghi lại cả hai cấu hình khi chúng còn tồn tại

Xóa một tunnel mất nửa phút và phá hủy bằng chứng duy nhất bạn có. Trước đó, hãy ghi lại selector cục bộ và từ xa, địa chỉ peer, ai giữ bí mật chia sẻ, và crypto map hoặc profile IKEv2 của ASA. ASA trả lời hai câu hỏi riêng biệt: cái gì đã được cấu hình và cái gì đang hoạt động ngay lúc này:

show running-config crypto ikev2
show crypto ikev2 sa
show crypto ipsec sa | include local ident|remote ident|status

Về phía Google, hãy đọc đối tượng tunnel thay vì bản tóm tắt trên console, vì địa chỉ peer và các trường selector là những giá trị bạn phải tái tạo chính xác:

gcloud compute vpn-tunnels describe tunnel-to-asa --region europe-west1 \
  --format="yaml(peerIp,localTrafficSelector,remoteTrafficSelector,ikeVersion,sharedSecret)"

Đưa những giá trị đó vào ticket trước lần xóa đầu tiên. Việc dựng lại bên dưới chỉ hiệu quả vì bạn có thể tạo lại đúng đối tượng đó với một khác biệt có chủ đích.

Những thuật toán mà một bên từ chối thương lượng

Cloud VPN không chọn từ một dải thuật toán IKEv1 như peer truyền thống. Các thiết lập peer mà nó mong đợi là cố định: aes-cbc-128 cho mã hóa, sha1-96 cho cả tính toàn vẹn và PRF, nhóm Diffie-Hellman 2, 36,600 giây cho pha 1 và 10,800 giây cho pha 2. Chính sách của ASA phải cung cấp đúng bộ đó. Đề xuất thứ hai trên ASA không gây hại miễn là cái khớp cũng có trong danh sách.

IKEv2 cho cả hai bên nhiều chỗ hơn, nhưng các quy tắc giữ nguyên hình dạng: bật PFS, chọn nhóm DH mà tunnel hỗ trợ và giữ danh sách đề xuất đủ ngắn để sự không khớp là hiển nhiên. Một peer ASA trên Cloud VPN cũng có nghĩa là định tuyến tĩnh, nên các prefix được bảo vệ phải được lập kế hoạch và liệt kê thay vì để cho BGP.

Thời gian sống sao chép từ mẫu của nhà cung cấp khác là lối rẽ sai thường gặp ở đây. Google công bố những giá trị này như thiết lập peer bắt buộc, nên hãy đặt chúng; một giá trị ngắn hơn không được thương lượng tăng lên tới mức ASA muốn.

Xóa, tạo lại và dọn trạng thái cũ

Xóa tunnel, không phải gateway, và ghi lại tên mà Cloud VPN đặt cho bản thay thế, vì tên được gán chứ không được dùng lại. Tạo lại nó với các giá trị đã ghi và cùng địa chỉ peer, rồi thêm đề xuất khớp vào danh sách chính sách của ASA.

Dọn các liên kết bảo mật sau khi thay đổi trên ASA và trước khi đọc kết quả. ASA có thể tiếp tục cung cấp chính sách cũ cho đến khi SA hiện tại hết hạn, nên một cấu hình đúng trông như hỏng suốt thời gian sống cũ và người quan sát kết luận việc dựng lại thất bại trong khi nó chưa bắt đầu:

clear crypto ikev2 sa
clear crypto ipsec sa

Xác nhận pha 1 lên trước khi nhìn pha 2. Khi pha 1 còn xuống, đề xuất hoặc khóa chia sẻ trước là sai, và việc làm selector sẽ không thay đổi điều đó.

Các selector soi gương nhau, sau đó các bộ đếm quyết định

Pha 2 chỉ hoạt động khi hai đầu đồng ý về các địa chỉ được bảo vệ, và sự đồng ý là soi gương chứ không chia sẻ. Selector cục bộ của Google phải khớp với selector mà ASA gọi là từ xa, và selector từ xa của Google phải khớp với cái ASA gọi là cục bộ. Một tunnel có 0.0.0.0/0 ở một bên và một subnet duy nhất ở bên kia vượt qua pha 1 rồi thất bại ở pha 2 với cùng lỗi chính. Không bên nào có thể mở rộng danh sách của bên kia.

Với selector dựa trên chính sách, hãy liệt kê từng cặp prefix và giữ danh sách trong ticket. Một subnet thêm sau này tại chỗ cần chỉnh sửa ở cả hai đầu, vì một tuyến mới trên ASA không mở rộng selector, và kết quả là một tunnel đang lên nhưng chỉ cho lưu lượng đi qua với các prefix tồn tại vào ngày đầu tiên.

Kết thúc bằng một luồng từ host đến host và đọc bộ đếm byte ở cả hai phía. Bộ đếm tăng trên ASA trong khi phẳng trên Google thường có nghĩa là phản hồi đi ra qua giao diện khác, hoặc selector không bao phủ prefix quay về. Ghi lại thuật toán, thời gian sống, selector và tên tunnel mới, vì lần thay đổi đề xuất tiếp theo lặp lại việc dựng lại này và những giá trị đó biến nó thành một việc ngắn.