Một máy khách Windows IKEv2 kết nối, và yêu cầu RADIUS đến với một địa chỉ ở nơi lẽ ra phải là tên tài khoản. Chưa có gì thất bại, và đó chính là chỗ gây bối rối: cổng báo cáo danh tính mà máy khách trình bày ở lớp IKE. Tên người dùng mà phần phụ trợ của bạn muốn có thể đến từ một trao đổi EAP riêng chưa xảy ra. Hãy quyết định ai yêu cầu nó trước khi thay đổi tài khoản.

Hai danh tính cùng đi trong một kết nối

Hai cái tên có thể xuất hiện trong một kết nối. Danh tính IKE nhận diện đối tác trong lúc thiết lập đường hầm, và plugin eap-radius ban đầu sao chép nó vào RADIUS User-Name. Danh tính EAP là một giá trị khác, được dùng để xác thực người dùng, và có thể không bao giờ được gửi nếu không ai yêu cầu.

Vì thế nhật ký RADIUS có thể hiển thị một địa chỉ trong khi tài khoản tồn tại và mật khẩu đúng. Phần phụ trợ đang bị hỏi về sai lớp. Thuộc tính RADIUS chỉ là phương tiện vận chuyển cho cái tên đã được chọn.

Yêu cầu cổng yêu cầu một danh tính EAP

Một cách bố trí được hỗ trợ khiến cổng yêu cầu danh tính EAP trước khi giao xác thực cho RADIUS. Trong phần xác thực từ xa của kết nối, đặt phương thức thành eap-radius và yêu cầu danh tính EAP một cách rõ ràng. Đoạn dưới đây thuộc vào bên trong một khối kết nối sẵn có, không phải một tệp riêng. Hãy xác nhận kết nối và phần phụ trợ cấu hình trước khi sao chép cú pháp từ một triển khai khác.

remote {
    auth = eap-radius
    eap_id = %any
}

Với điều đó, phần phụ trợ nhận được danh tính mà máy khách cung cấp trong trao đổi EAP thay vì địa chỉ IKE. Không có gì khác về kết nối thay đổi.

Hoặc để RADIUS bắt đầu trao đổi EAP

Cách bố trí còn lại đặt nước đi đầu tiên về phía RADIUS. Plugin có thể gửi một chỉ báo EAP-Start thay vì chờ phản hồi danh tính ban đầu, điều này cho phép máy chủ dẫn dắt trao đổi. Đây là cấu hình ở cấp plugin, nên nó ảnh hưởng đến mọi kết nối dùng plugin.

charon {
    plugins {
        eap-radius {
            eap_start = yes
        }
    }
}

Hãy chọn một cách bố trí với người vận hành RADIUS thay vì bật cả hai rồi hy vọng. Chúng mô tả những luồng công việc khác nhau, và một máy chủ mong đợi khởi đầu sẽ không nhất thiết xử lý được cổng khởi đầu cuộc trò chuyện. Tài liệu plugin mô tả cả hai, bao gồm danh tính mà mỗi bước mang theo.

Theo dõi một lần thử trong cả hai nhật ký

Đối chiếu một lần thử duy nhất trong cả hai nhật ký. Xem danh tính IKE, rồi xem có trao đổi EAP-Identity hay không, rồi xem bước xác thực nhận được tên nào. Một phần phụ trợ từ chối địa chỉ trước trao đổi EAP có thể dừng tiến trình trước khi danh tính bạn định có bao giờ được thấy.

journalctl -u strongswan -f

Giữ nguyên định dạng tên người dùng chính xác mà hệ thống danh tính mong đợi, kể cả tiền tố miền. Đừng bao giờ bịa ra tài khoản từ một giá trị có dạng địa chỉ và đừng bao giờ tắt xác thực để thỏa một quy tắc chính sách. Danh tính EAP là một cái tên được khẳng định, và phương thức vẫn phải chứng minh nó. Ghi tên thu được vào hồ sơ kiểm thử để lần thử tiếp theo bắt đầu từ trạng thái đã biết.

Nếu luồng đã sửa đến đúng tài khoản mà vẫn bị từ chối, bằng chứng tiếp theo là phương thức EAP và chính sách của phần phụ trợ, không phải danh tính. Lặp lại việc đặt lại mật khẩu không thể sửa một giá trị đã được chọn ở lớp giao thức trước đó.

Bài viết liên quan