Chứng chỉ cổng vào vẫn tốt: vì sao đăng nhập IKEv2 PEAP vẫn thất bại

Chứng chỉ cổng VPN của bạn còn hiệu lực, chuỗi được xác thực, và máy khách IKEv2 vẫn từ chối đăng nhập với thông báo về khoảng hiệu lực của chứng chỉ. Phản xạ đầu tiên là cấp lại chứng chỉ cổng hoặc đổi phương thức EAP, và cả hai thường đều sai. Lần đăng nhập mang hai danh tính máy chủ riêng biệt: chứng chỉ cổng mà IKE dùng, và chứng chỉ do thứ kết thúc PEAP trình bày. Một trong hai vẫn tốt, và cái còn lại là lý do máy khách dừng lại.

Hai danh tính, một lần đăng nhập

Chứng chỉ trong hồ sơ VPN thuộc về trao đổi IKE: nó chứng minh cổng là đối tác mà hồ sơ nêu tên, theo chính sách IKE đã cấu hình. Chứng chỉ thất bại ở đây thuộc về một cuộc trò chuyện khác, phiên TLS mà PEAP mở với bên xác thực người dùng, thường là máy chủ RADIUS như NPS chứ không phải chính cổng. Kiểm tra thứ ba, thông tin đăng nhập của người dùng, diễn ra bên trong phiên đó. Mật khẩu hợp lệ không thể sửa chứng chỉ máy chủ đã hết hạn, và chứng chỉ cổng hợp lệ không thể bảo đảm cho điểm cuối PEAP.

Cách phân lớp này giải thích vì sao lỗi chứng chỉ xuất hiện ở nơi mà chứng chỉ duy nhất ai đó cấu hình là của cổng. Nó cũng giải thích vì sao cấp lại chứng chỉ đó không thay đổi gì.

Đọc dòng nhật ký theo giai đoạn

Tìm thông báo nêu lý do và ngày tháng. Khiếu nại về khoảng hiệu lực bên cạnh lỗi chủ thể nghĩa là máy chủ đã từ chối chứng chỉ được đưa cho nó, không phải người dùng từ chối đăng nhập. Sau đó tìm giai đoạn: nhật ký charon của strongSwan hiển thị IKE_SA .* established trước khi trao đổi EAP bắt đầu, nên lỗi chứng chỉ sau dòng đó thuộc về danh tính EAP, còn lỗi trước đó chỉ vào cổng. Văn bản giai đoạn trong bảng kết nối của máy khách Windows cũng nói điều tương tự.

Kiểm tra đồng hồ của máy khách trước khi chạm vào bất kỳ chứng chỉ nào. Thiết bị lệch vài giờ tạo ra đúng lỗi hiệu lực như chứng chỉ thực sự hết hạn. Chỉnh đồng hồ là bản sửa năm giây, còn thay một chứng chỉ chưa bao giờ là vấn đề là một lần gián đoạn dịch vụ.

Xác định điểm cuối nào kết thúc PEAP

Trong thiết kế cổng cộng RADIUS, cổng chuyển tiếp EAP và không kết thúc nó. Plugin eap-radius của strongSwan giao trao đổi cho máy chủ RADIUS, bên sở hữu phiên TLS của PEAP và chứng chỉ của nó. Đối chiếu một lần thử thất bại trên cả hai nhật ký và xác nhận tiến trình nào thực sự đã chọn chứng chỉ cho phiên đó.

Với NPS, chứng chỉ phải nằm trong kho của máy tính cục bộ, mang mục đích xác thực máy chủ, khớp với tên mà máy khách mong đợi, và tài khoản dịch vụ phải đọc được. Yêu cầu chứng chỉ của Microsoft cho NPS liệt kê những điều kiện đó. Các máy chủ EAP khác có quy tắc chọn riêng, nên đừng sao chép đặc thù của NPS vào bản triển khai FreeRADIUS hoặc ngược lại. Quy tắc đúng trong cả hai trường hợp là điểm cuối kết thúc PEAP sở hữu chứng chỉ mà bạn sắp thay.

Thay chứng chỉ tại nơi EAP kết thúc

Gia hạn hoặc thay chứng chỉ trên điểm cuối kết thúc PEAP, theo quy trình được hỗ trợ, giữ nguyên mục đích xác thực máy chủ và tên mong đợi. Cài đặt chuỗi đầy đủ ở nơi dịch vụ tìm kiếm và cấp cho dịch vụ quyền truy cập khóa riêng. Khởi động lại hoặc liên kết lại dịch vụ, vì nhiều dịch vụ giữ chứng chỉ cũ trong bộ nhớ và tiếp tục trình bày nó. Một tệp được sao chép vào máy không chứng minh được gì về chứng chỉ mà dịch vụ thực sự trình bày.

Xác nhận thay đổi bằng cách đối chiếu lần thử tiếp theo với nhật ký của chính dịch vụ, hoặc kiểm tra chứng chỉ mà phiên đã trình bày. Nếu nhật ký đó vẫn hiển thị dấu vân tay cũ, lần khởi động lại không có tác dụng.

Đừng cho rằng tệp mới nhất trong thư mục là tệp đang được dùng. Một bản sao có đúng tên nhưng sai quyền không thay đổi gì. Đánh giá thay đổi bằng danh tính được trình bày, không bằng dấu thời gian của tệp.

Điều không nên làm

Đừng tắt xác thực PEAP và đừng ép một phương thức bên trong yếu hơn để vượt qua lỗi. Điều đó thay đổi chính sách và loại bỏ thuộc tính xác thực máy chủ vốn đã bắt được chứng chỉ hết hạn ngay từ đầu. Bạn sẽ đổi một kiểm tra đang hoạt động lấy một kết nối đang hoạt động, và chứng chỉ hết hạn tiếp theo sẽ đến mà không có gì báo trước.

Đừng coi một kết nối thành công từ hệ điều hành khác là bằng chứng rằng chứng chỉ chấp nhận được. Máy khách đó có thể dùng phương thức EAP khác, kho tin cậy khác hoặc không xác thực máy chủ, nên thành công của nó không nói gì về kiểm tra đã thất bại ở đây. Hãy giữ một phép thử phủ định có chủ đích, chẳng hạn chứng chỉ sai tên hoặc chuỗi không đáng tin cậy, thất bại đúng như mong đợi. Nếu phép thử đó giờ đã qua, bạn đã bỏ một kiểm tra chứ không phải sửa một chứng chỉ. Ghi lại danh tính nào đã thất bại, để người tiếp theo không bắt đầu lại từ chứng chỉ cổng.