IKEv2 NO_PROPOSAL_CHOSEN: giai đoạn nào đã từ chối bộ này?

NO_PROPOSAL_CHOSEN trong nhật ký khiến mọi người chuyển sang khóa chia sẻ trước, và lỗi vẫn tồn tại sau khi thay đổi. Đây chưa bao giờ là vấn đề thông tin xác thực: đối tác đã từ chối mọi đề xuất được đưa ra cho trao đổi đó, đó là phát biểu về thuật toán chứ không phải danh tính. Câu hỏi hữu ích đầu tiên không phải là sửa thuật toán nào mà là trao đổi nào bị từ chối. Hãy trả lời điều đó trước khi so sánh bất cứ điều gì. Sau đó so sánh toàn bộ bộ được đề nghị với toàn bộ bộ mà đối tác cho phép.

Đầu tiên: trao đổi nào bị từ chối

IKEv2 thương lượng hai loại liên kết. IKE SA bảo vệ chính quá trình thương lượng, và CHILD SA bảo vệ lưu lượng. Mỗi loại có bộ đề xuất riêng, và mỗi loại có thể thất bại với cùng một thông báo. Việc từ chối trong thương lượng IKE ban đầu và từ chối trong thương lượng CHILD cần các sửa chữa khác nhau, và nhật ký thường nêu tên trao đổi một hoặc hai dòng phía trên thông báo. Hãy đọc hai dòng đó cùng nhau, nếu không bạn sẽ sửa danh sách đề xuất sai.

Chỉ thông báo không nhận diện được trao đổi. Dòng phía trên nêu tên SA đang được thương lượng, và tên đó trỏ đến danh sách đề xuất cần kiểm tra.

So sánh toàn bộ bộ, không phải từ khóa riêng lẻ

Một đề xuất là sự kết hợp: thuật toán mã hóa, tính toàn vẹn hoặc AEAD, nhóm trao đổi khóa và bất kỳ hàm giả ngẫu nhiên nào. Chỉ so sánh tên mã hóa là lỗi thường gặp, vì hai đối tác có thể đồng ý về AES-256 mà vẫn bất đồng về SHA-1 so với SHA-256. Hãy viết các bộ được đề nghị và được phép cạnh nhau ở giai đoạn thất bại, sau đó tìm phần giao rỗng.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

Cũng kiểm tra rằng cả hai triển khai đều hỗ trợ những gì bạn đã cấu hình. Tên sao chép từ nền tảng khác có thể trông quen thuộc về cú pháp trong khi plugin hoặc triển khai hoàn toàn không có.

Bộ IKE và bộ ESP là các đối tượng khác nhau

Sửa đề xuất IKE sẽ không sửa được đề xuất CHILD bị từ chối, và ngược lại cũng đúng. Trong strongSwan đây là các cài đặt riêng, khoảng proposals = aes256-sha256-modp2048 cho IKE SA và một danh sách ESP riêng cho CHILD SA. Hãy thay đổi danh sách khớp với trao đổi thất bại, sau đó đọc lại nhật ký thay vì cho rằng sửa chữa đã hiệu quả.

Đối với CHILD SA, cài đặt liên quan là danh sách đề xuất ESP, không phải danh sách IKE. Sao chép dòng IKE vào đó tạo ra cấu hình được phân tích nhưng thương lượng sai đối tượng.

Một đường hầm đang hoạt động nhưng thất bại khi gia hạn khóa

Nếu đường hầm chạy một giờ rồi thất bại, thương lượng ban đầu không phải là vấn đề. Gia hạn khóa có thể kiểm tra các điều kiện khác: nhóm trao đổi khóa khác sau lần trao đổi đầu tiên, sự không khớp thời gian sống giữa các đối tác hoặc chính sách của bên trả lời bị thay đổi. Hãy giữ dấu thời gian gia hạn và các định danh liên kết từ cả hai phía. Mẫu đó cần so sánh đề xuất khi gia hạn, không phải thời gian chờ dài hơn. Thay đổi thời gian chờ che giấu triệu chứng và để sự không khớp tại chỗ.

ipsec statusall hiển thị từng liên kết và các thuật toán thực sự được thương lượng. Đầu ra đó là cách nhanh nhất để xác nhận danh sách nào đã được dùng, và nó tách lỗi cấu hình khỏi một đường hầm cũ chưa bao giờ được thương lượng lại.

ipsec statusall | grep -E "IKE:|ESP:"

Chọn một phần giao, sau đó xác nhận cả hai giai đoạn

Yêu cầu quản trị viên chọn một phần giao hiện đại có tài liệu mà cả hai đối tác hỗ trợ, và ghi lại. Đừng giải quyết lỗi bằng cách bật mọi thuật toán cũ hoặc tắt xác minh danh tính, vì cả hai đều không suy ra từ việc từ chối. Sau khi thay đổi, thiết lập kết nối mới rồi buộc gia hạn khóa. Chỉ kết nối đầu tiên không chứng minh đường gia hạn hoạt động.

Giữ tổ hợp được chấp nhận cùng với các phiên bản firmware. Nếu lỗi tiếp theo liên quan đến bộ chọn lưu lượng, hãy xử lý riêng, vì thỏa thuận về mật mã không nói gì về việc đường hầm bảo vệ những mạng con nào. tài liệu đề xuất của strongSwan bao gồm cú pháp cho cả hai danh sách.