Tuần trước, một người dùng có thể đăng nhập VPN và vẫn rơi vào một mạng nơi không có gì được phân giải. Máy khách báo đã kết nối, nhật ký cổng báo Access-Accept, và nhóm danh tính nói tài khoản vẫn ổn. Việc đăng nhập đã hoạt động; việc cấp quyền phía sau thì không. Khi một lần đăng nhập VPN thất bại, tôi đi theo con đường mà yêu cầu thực sự đi — máy khách, cổng, máy chủ RADIUS, nhà cung cấp danh tính — và dừng ở chặng đầu tiên có câu trả lời không khớp với chặng tiếp theo.

Máy khách không bao giờ nói RADIUS

Dù ứng dụng trên laptop hiển thị gì, chặng đầu tiên của nó là giao thức VPN: IKEv2, OpenVPN, WireGuard hoặc một máy khách dựa trên TLS. RADIUS không xuất hiện trong trao đổi đó. Máy khách xác thực với cổng bằng chứng chỉ, tên người dùng và mật khẩu, hoặc một phương thức EAP được mang trong thiết lập đường hầm.

Điều đó quan trọng khi đọc nhật ký, vì lỗi xác thực chung mà người dùng thấy do cổng tạo ra sau khi nó đã nói chuyện với thứ khác. Nếu máy khách không bao giờ đến được cổng, không có yêu cầu RADIUS nào để gỡ lỗi, và một giờ trên máy chủ RADIUS là lãng phí. Xác nhận đường hầm có dựng lên hay không trước khi chạm vào phần phía sau.

Cổng chính là máy khách RADIUS

Ngay khi thiết lập đường hầm đến điểm phải kiểm tra thông tin đăng nhập, cổng trở thành một máy chủ truy cập mạng. Nó dựng một Access-Request: User-Name, mật khẩu hoặc tải trọng EAP, NAS-IP-Address hoặc NAS-Identifier, và Message-Authenticator khi phương thức yêu cầu. Yêu cầu đi đến UDP 1812 theo mặc định, và kế toán đến 1813. Các triển khai cũ vẫn dùng 1645 và 1646, nên một quy tắc tường lửa viết cho một cặp giải thích nhiều lỗi im lặng.

Hai bên chia sẻ một bí mật, và đó không phải thông tin đăng nhập của người dùng. Nó ký trao đổi, và mọi câu trả lời được xác minh dựa trên nó. Cấu hình bí mật khác nhau ở hai bên và máy chủ không trả lời là bí mật sai — nó bỏ yêu cầu hoặc câu trả lời không qua xác minh, nên cổng báo hết thời gian. Một bí mật sai và một máy chủ chết trông giống nhau từ cổng, vì vậy tôi kiểm tra chặng đó bằng công cụ máy khách trước khi đổ lỗi cho thư mục.

Giao thức nhỏ và cũ — RFC 2865 định nghĩa trao đổi xác thực — nhưng các thuộc tính nó mang là nền tảng mà phần lớn chính sách VPN được xây dựng trên đó.

# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123

# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'

Máy chủ RADIUS có thể chỉ là mặt trước của nhà cung cấp danh tính

Người ta nói về RADIUS và nhà cung cấp danh tính như thể chúng là cùng một chiếc hộp. Thường không phải. Máy chủ RADIUS nhận Access-Request rồi hỏi thứ khác — Active Directory qua LDAP hoặc Kerberos, tệp người dùng cục bộ hoặc dịch vụ bên ngoài — trước khi trả lời. FreeRADIUS với mô-đun LDAP hoặc krb5, Windows NPS và Cisco ISE đều đứng ở vị trí này.

Sự khác biệt quyết định nơi bạn nhìn. Mật khẩu bị từ chối là câu trả lời của nhà cung cấp danh tính do RADIUS chuyển tiếp. Hết thời gian thường là đoạn RADIUS đến thư mục: tài khoản bind hết hạn, thư mục không thể truy cập, hoặc yêu cầu bị định tuyến đến phần phía sau sai. Nếu tên người dùng có hậu tố miền, máy chủ có thể định tuyến theo đó, và cùng một tài khoản gửi dưới dạng CORP\alice và [email protected] có thể rơi vào những nơi khác nhau. Trong Windows NPS, nhật ký Security ghi 6272 khi cấp và 6273 khi từ chối, cho biết quyết định có đến từ NPS hay không.

Đọc lỗi ở chặng đã tạo ra nó

Một thông báo không thể kết nối bao trùm bốn lỗi khác nhau. Trước khi thay đổi bất cứ điều gì, hãy khớp triệu chứng với chặng đã tạo ra nó.

What you seeWhere it comes fromFirst check
Gateway timeout, no replyShared secret mismatch, UDP 1812 blocked, unknown NAS, wrong server addresstcpdump at the gateway; radtest from the gateway host
Immediate rejectCredentials, account state, domain suffix, RADIUS policyNPS 6273 or the FreeRADIUS auth log; test the account directly
Repeated challenge or MFA loopAccess-Challenge state not returned, or a token that expired mid-flowClient prompt timing and the State attribute in debug output
Accept, then no accessAuthorization attributes unmapped, wrong pool, route or ACL policyGateway policy and the attributes in the Access-Accept

Hàng cuối cùng là hàng đưa người ta đến nhóm sai. Access-Accept nghĩa là thông tin đăng nhập đã được chấp nhận; không có nghĩa là cổng đã đặt người dùng vào đúng nhóm hoặc đẩy tuyến đường. Thuộc tính nhóm chỉ quan trọng nếu chính sách của cổng đọc chúng. Tôi đã thấy một lần đăng nhập đúng rơi vào nhóm khách vì ánh xạ nhóm được cấu hình ở phía RADIUS cho một thuộc tính khác với thuộc tính mà cổng kiểm tra.

Theo dõi một lần đăng nhập từ đầu đến cuối

Chọn một tài khoản thử nghiệm và một cổng, rồi quan sát cùng một lần thử ở cả bốn điểm. Bắt đầu một lần chạy gỡ lỗi ở phía RADIUS — freeradius -X in yêu cầu và mọi mô-đun nó chạm vào — theo dõi nhật ký xác thực của cổng, và chạy tcpdump cho trao đổi UDP. Kết nối một lần và đọc bốn dấu vết theo thứ tự.

Điều bạn muốn thấy là sự đồng thuận: cổng hỏi về người dùng bạn mong đợi, máy chủ RADIUS chọn phần phía sau bạn mong đợi, phần phía sau đó trả về một quyết định, và các thuộc tính trong câu trả lời khớp với chính sách mà cổng áp dụng. Nơi đầu tiên các dấu vết không khớp là ranh giới lỗi của bạn. Nếu câu trả lời không mang thuộc tính nhóm, vấn đề ở phía RADIUS, không phải trong hồ sơ VPN; nếu thuộc tính có đó và cổng bỏ qua nó, chính sách của cổng là vấn đề.

Một lưu ý bảo mật khi bạn ở đó. Bí mật chia sẻ bảo vệ trao đổi, nhưng nó không mã hóa phần lớn thuộc tính. Nếu cổng và máy chủ RADIUS ở các phân đoạn khác nhau, hãy đặt chặng đó trên RADIUS qua TLS hoặc một đường riêng. Một đường hầm người dùng được mã hóa không nói gì về liên kết phía sau.

Trước khi đóng phiếu, xác nhận bốn điều. Cổng đến được máy chủ RADIUS trên cổng mà nó thực sự được cấu hình. Bí mật chia sẻ khớp ở cả hai bên. Máy chủ RADIUS phân giải đúng dạng tên người dùng mà cổng gửi. Việc chấp nhận mang các thuộc tính mà chính sách của cổng cần. Khi cả bốn đúng, một lần đăng nhập vẫn thất bại là vấn đề chính sách của cổng, không phải xác thực.

Bài viết liên quan