iOS IKEv2 sang strongSwan: không có đề xuất nào được chọn, sửa danh sách

iPhone dựng đường hầm lên, cổng không trả lời gì, và điện thoại hiển thị một lỗi chung. Nhật ký của strongSwan cụ thể hơn: no proposal chosen. Thông báo đó nghĩa là hai danh sách bộ mã hóa được chấp nhận chưa bao giờ trùng nhau, nên quá trình trao đổi kết thúc trước khi xác thực bắt đầu. Đây là vấn đề khớp nối, và cách sửa là làm cho hai danh sách giao nhau.

Nơi cổng khai báo chính sách của nó

strongSwan ghi chính sách vào cấu hình, và dấu chấm than ở cuối quyết định cách đọc chính sách đó. Có dấu thì danh sách là đầy đủ: chỉ những mục đó được chấp nhận và không gì khác. Không có dấu thì cùng dòng đó là một thứ tự ưu tiên, và daemon có thể chọn thứ bạn không định. Hỏi xem dạng nào đang được triển khai trước khi dịch bất cứ thứ gì, vì hai dạng hành xử khác nhau với cùng một máy khách. Ghi lại dòng chính xác, kể cả dấu, và kiểm tra theo dòng đó.

Máy khách đưa ra danh sách rộng hơn vẫn có thể kết nối với cổng đã ghim, miễn là có một tổ hợp xuất hiện ở cả hai bên. Điều không thể xảy ra là đàm phán ngoài tập đã ghim.

Đó là lý do một hồ sơ sao chép từ ứng dụng VPN khác có thể hoạt động ở nơi hồ sơ của bạn không: ứng dụng kia gửi một danh sách khác.

Tên phải khớp, không phải tốt hơn

Hai bản dịch đánh lừa những người chuyển giá trị từ strongSwan sang iOS. Thuật toán toàn vẹn ghi là SHA1 trong một đề xuất IKE đi ở dạng rút gọn, mà iOS gọi là .SHA96. Nhóm Diffie-Hellman ghi là modp1024 là nhóm 2, mà iOS gọi là .group2. Thay bằng SHA-256 hoặc nhóm 14 sẽ không đàm phán được với cổng chỉ chấp nhận cặp cũ. Máy khách phải mô tả đúng thuật toán đó, không phải một thuật toán mạnh hơn.

Đặt các giá trị đó một cách rõ ràng trong NEVPNProtocolIKEv2. Giá trị mặc định có thể rộng hơn hoặc hẹp hơn hồ sơ bạn đang thay, và sự khác biệt chỉ lộ ra khi bắt tay thất bại.

Đề xuất con thất bại muộn hơn và lặng lẽ hơn

Cấu hình cả hiệp hội bảo mật con, không chỉ của IKE. Khi chỉ các tham số IKE khớp nhau, đường hầm xác thực rồi sau đó không mang lưu lượng, đây là lỗi lặng lẽ hơn nhiều so với một lần từ chối. Đặt mã hóa, toàn vẹn, nhóm và thời gian sống của con trong cùng một bước. Giữ thời gian sống của máy khách bằng hoặc thấp hơn giá trị của cổng, vì khăng khăng dài hơn tạo ra đúng thông báo no proposal chosen từ một nguyên nhân khác. Sự không khớp ở đó trông giống hệt sự không khớp IKE trong nhật ký.

Kiểm tra xem hồ sơ xác thực bằng chứng chỉ hay bằng bí mật chia sẻ khi bạn đang ở trong cấu hình. Việc từ chối đề xuất và việc từ chối xác thực xuất hiện trên các dòng khác nhau, và sửa nhầm cái mất một ngày. Kiểm tra bằng một kết nối mới sau mỗi thay đổi, mỗi lần một biến, vì trạng thái được lưu trong bộ nhớ đệm che mất tham số nào đã dịch chuyển.

Chỉ giữ bộ cũ chừng nào còn cần

Ghim SHA-1 với một nhóm 1024 bit là một cây cầu, không phải đích đến. Cả hai đều đã lỗi thời, và các máy khách mới hơn có thể từ chối thẳng, nghĩa là hồ sơ sẽ hỏng trên thiết bị tiếp theo mà không có thay đổi nào từ phía bạn. Hãy coi việc ghim là tạm thời và ghi như vậy vào biên bản.

Nếu strongSwan là của bạn, hãy thêm một đề xuất hiện đại và để cả hai đầu đàm phán đi lên trong khi mục cũ vẫn ở lại cho thiết bị cũ. Đọc đầu ra trạng thái của daemon để xem mỗi kết nối thực sự dùng bộ nào. Sau đó gỡ bỏ việc ghim ở phía máy khách khi cặp hiện đại đã được xác nhận. Một đường hầm dựng lên chưa đủ bằng chứng, vì nó có thể dựng lên trên đúng bộ bạn đang cố loại bỏ. Tài liệu IKEv2 của strongSwan mô tả cú pháp đề xuất và dấu strict.