Xác thực lai của IKEv1 chuyển sang xác thực người dùng của IKEv2 như thế nào
Chế độ lai tách bằng chứng của cổng khỏi bằng chứng của người dùng. Việc chuyển sang IKEv2 giữ nguyên sự tách biệt đó nhưng thay đổi trao đổi, phương thức EAP và các kiểm tra chứng chỉ.
Mỗi hồ sơ VPN cũ yêu cầu trước hết chứng chỉ máy chủ rồi đến tên người dùng mang hai sự kiện xác thực trong một lần trao đổi, và hình dạng đó sống lâu hơn giao thức đã mang nó vào. Chế độ lai của IKEv1 được xây dựng chính vì việc này: cổng tự chứng minh bằng khóa công khai còn người dùng chứng minh sau đó qua XAuth. IKEv2 diễn đạt cùng ý tưởng hai bước bằng cơ chế khác, và chính trong những khác biệt đó các cuộc di trú thất bại. Không số phiên bản nào chuyển cái này thành cái kia, và việc sao chép các tên tùy chọn cũ vào hồ sơ mới cho ra một máy khách đàm phán rồi không xác thực gì cả.
Chế độ lai đã làm gì bên trong IKEv1
Trong hồ sơ lai, bên trả lời ký lần trao đổi giai đoạn một bằng chứng chỉ của mình trong khi bên khởi tạo cố ý không trình chứng chỉ nào. Bằng chứng danh tính vì thế là bất đối xứng, và chính điều đó cho phép cổng giữ PKI hiện có trong khi người dùng giữ mật khẩu thư mục của họ. Khi giai đoạn một kết thúc, XAuth chạy như một yêu cầu và trả lời mang các thuộc tính tên người dùng và mật khẩu bên trong kênh ISAKMP đã mã hóa.
Hãy để ý niềm tin đáp xuống đâu. Chứng chỉ trả lời máy khách đã đến cổng nào; XAuth trả lời người dùng nào muốn truy cập. Không cái nào thay thế cái kia, và một máy khách được đặt để chấp nhận mọi chứng chỉ máy chủ đã âm thầm vứt bỏ câu trả lời đầu tiên. Nhãn lai cũng được dùng cho chế độ tấn công với khóa chia sẻ trước cùng XAuth, một cách bố trí khác có cùng trải nghiệm người dùng, nên hãy đọc hồ sơ chứ không phải tên. Cả hai biến thể đến từ các bản nháp chưa bao giờ thành tiêu chuẩn, và vì thế hai nhà sản xuất có thể triển khai chế độ lai mà không tương tác với bên nào.
IKEv2 đạt tới cùng hai bằng chứng như thế nào
IKEv2 chia việc giữa IKE_SA_INIT và IKE_AUTH. Lần trao đổi đầu thỏa thuận đề xuất và khóa mà không có danh tính nào; lần thứ hai mang IDi, IDr và các tải trọng AUTH. Dưới EAP, tải trọng AUTH đầu tiên của bên khởi tạo đi ra rỗng, bên trả lời xác thực trước bằng chứng chỉ và chữ ký của mình, rồi cuộc trò chuyện EAP chạy bên trong các thông điệp IKE_AUTH.
Cơ chế khiến việc này an toàn là vật liệu khóa. Một phương thức EAP thành công xuất ra khóa phiên, và tải trọng AUTH cuối cùng của bên khởi tạo được tính từ đó, nên bằng chứng của người dùng và các khóa của đường hầm gắn với nhau. XAuth không có tương đương: các thuộc tính của nó đến sau giai đoạn một và không đóng góp gì cho khóa. Chính khoảng trống đó là thứ khung IKEv2 được thiết kế để lấp, và vì vậy một lần đăng nhập IKEv2 hoạt động sẽ kiểm tra chứng chỉ máy chủ trước khi hỏi bất cứ điều gì.
Thứ tự này cũng là một chẩn đoán hữu ích. Khi một máy khách phàn nàn về thông tin đăng nhập trước khi cho bạn thấy chứng chỉ, nó hoàn toàn không thực hiện trao đổi EAP của IKEv2.
Giữ ba danh tính tách rời
Một cuộc di trú hỏng khi ba danh tính sụp vào một trường. Có danh tính cổng mà máy khách kiểm tra, thường là tên DNS trong subject hoặc SAN của chứng chỉ. Có danh tính người dùng được trình bày trong EAP, có thể là đăng nhập miền, một địa chỉ hoặc một chuỗi danh tính EAP rõ ràng. Và có nguồn ủy quyền ánh xạ người dùng đó lên mạng và tuyến.
Cú pháp swanctl của strongSwan làm sự tách biệt hiện rõ: kết nối đặt remote { auth = pubkey } cho cổng và local { auth = eap-mschapv2 } cho người dùng, với danh tính EAP được mang riêng.
Khi danh tính người dùng trong hồ sơ mới khác các thuộc tính XAuth cũ, ví dụ UPN thay cho tên ngắn, máy chủ xác thực thấy một người dùng lạ và sự cố trông như mật khẩu sai. Hãy kiểm tra chuỗi danh tính trước khi kiểm tra thông tin đăng nhập.
Ánh xạ các tùy chọn rồi chờ các bẫy
Ánh xạ ngắn và mỗi hàng có một bẫy chỉ xuất hiện vào lúc xác thực.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
Không hàng nào trong số đó là đổi tên đơn thuần. Tải trọng cấu hình giao địa chỉ và bộ phân giải qua danh sách thuộc tính có kiểu, trong khi không gian thuộc tính của XAuth là phát minh riêng của nó; coi chúng là thay thế được cho nhau chính là cách một hồ sơ đi đến chỗ đòi một thiết lập mà cổng sẽ không bao giờ gửi.
Bộ chọn lưu lượng đáng có cảnh báo riêng. IKEv1 diễn đạt lưu lượng quan tâm qua các ID proxy gắn với trao đổi quick mode, trong khi IKEv2 đàm phán các bộ chọn trong IKE_AUTH và bên trả lời có thể thu hẹp chúng. Sự không khớp tạo ra một IKE SA đã thiết lập mà không có child SA, thứ mà một số máy khách vui vẻ hiển thị là đã kết nối.
Coi kết nối cũ là một ranh giới
RFC 9395 tuyên bố IKEv1 lỗi thời, nên một kết nối lai cũ là ranh giới tương thích có ngày tháng, không phải nền móng. Hãy chạy cả hai hồ sơ song song trong lúc chuyển đổi, vì bài kiểm tra quan trọng không phải là hồ sơ mới có lên hay không mà là cùng người dùng trên cùng thiết bị có đến được cùng tài nguyên hay không.
Giữ việc kiểm tra chứng chỉ nghiêm ngặt suốt quá trình. Khi máy khách ngừng trình chứng chỉ của mình, cám dỗ là nới lỏng kiểm tra máy chủ cho đến khi bắt tay xong, và điều đó đổi bằng chứng duy nhất còn lại lấy một biểu tượng xanh.
Ghi ra bốn điều trước khi cho hồ sơ cũ nghỉ hưu: phương thức EAP, chuỗi danh tính, nguồn ủy quyền và ngày hỗ trợ kết thúc.