RADIUS có thể trả lời bằng một địa chỉ cho một người dùng cụ thể; liệu đường hầm có thực sự nhận được địa chỉ đó hay không phụ thuộc vào cổng kết nối. Chính trong khoảng cách giữa được trả về và được áp dụng mà phần lớn kế hoạch địa chỉ ổn định thất bại. Một thuộc tính trong phản hồi thử nghiệm chứng minh rằng máy chủ có thể gửi nó, chứ không phải rằng dịch vụ truy cập từ xa áp dụng nó. Trình tự dưới đây kiểm tra cả hai nửa trước khi địa chỉ lọt vào các quy tắc tường lửa.

Quyết định lớp nào sở hữu địa chỉ

Các cổng kết nối truy cập từ xa thường có một nhóm địa chỉ cục bộ, và nhiều cổng cũng có thể chấp nhận địa chỉ từ phản hồi xác thực. Bên nào thắng phụ thuộc vào nền tảng, giao thức và cấu hình dịch vụ, vì vậy hãy đọc quy tắc ưu tiên cho đúng bản phát hành đang dùng. Ở nơi nhóm cục bộ được ưu tiên, thuộc tính chỉ là trang trí và máy khách vẫn rơi vào một địa chỉ ngẫu nhiên. Hãy ghi lại quyết định, kể cả việc giá trị được trả về phải nằm trong phạm vi nhóm hay có thể nằm ngoài phạm vi đó.

RFC 2865 định nghĩa Framed-IP-Address là địa chỉ cần được cấu hình cho người dùng, và không nói gì về việc một cổng kết nối cụ thể có sẵn lòng tôn trọng địa chỉ đó hay không. Tài liệu của nhà cung cấp là nguồn có thẩm quyền về thứ tự ưu tiên, không phải định nghĩa của thuộc tính.

Gửi yêu cầu thử nghiệm và đọc phản hồi

Trước tiên hãy kiểm tra máy chủ một cách riêng biệt, để một thuộc tính bị thiếu không bị nhầm với sự cố cổng kết nối. radtest gửi một Access-Request và in ra các thuộc tính được trả về.

radtest alice 'S3cret' 127.0.0.1 0 testing123

Tìm Framed-IP-Address trong Access-Accept và xác nhận rằng giá trị là giá trị dự định chứ không phải địa chỉ nhóm từ một quy tắc dự phòng. Khi thuộc tính vắng mặt, mục người dùng hoặc chính sách ủy quyền không khớp, và việc tinh chỉnh cổng kết nối không thể cung cấp thứ mà máy chủ chưa từng gửi. Lặp lại yêu cầu trong khi máy chủ chạy ở chế độ gỡ lỗi nếu khó truy vết phản hồi về một quy tắc cụ thể. Giữ bí mật chia sẻ ngoài lịch sử shell và các phiếu yêu cầu, vì phần giữ chỗ ở trên không phải là thông tin đăng nhập.

Xác nhận cổng kết nối đã tôn trọng giá trị

Một phản hồi đúng chỉ là một nửa của hợp đồng. Địa chỉ xuất hiện trên giao diện đường hầm mới là quan sát có ý nghĩa, và nó được đọc trên máy khách thay vì suy ra từ cấu hình cổng kết nối.

ip -4 addr show tun0

So sánh địa chỉ đó với thuộc tính từ Access-Accept. Sự không khớp nghĩa là cổng kết nối đã bỏ qua hoặc viết lại giá trị, điều này mở lại câu hỏi ưu tiên từ phần đầu tiên. Hãy kết nối lại một lần nữa, vì một đặt trước chỉ hoạt động ở lần thử đầu thường chỉ ra một phiên cũ hoặc một hợp đồng thuê vẫn do kết nối trước giữ. Ghi lại phiên bản cổng kết nối và giao thức bên cạnh kết quả, để người tiếp theo biết hành vi có phụ thuộc phiên bản hay không.

Lập kế hoạch cho đồng thời và thu hồi

Một tên người dùng trên hai thiết bị không thể ánh xạ tới một địa chỉ trừ khi cổng kết nối phân biệt các phiên bằng thứ gì đó ngoài đăng nhập. Quyết định xem ánh xạ thuộc về một người, một thiết bị đã đăng ký hay một danh tính chứng chỉ, và thể hiện rõ lựa chọn đó trong kho chính sách. Thử một máy khách thứ hai đồng thời và so sánh cả hai địa chỉ được cấp, vì xung đột ở đây sẽ tái xuất hiện sau này như một lỗi định tuyến. Sự cẩn trọng tương tự cũng thuộc về kế hoạch thu hồi, vì một địa chỉ được cấp lại trong khi các quy tắc tường lửa cũ vẫn tham chiếu đến nó sẽ trở thành lỗi ủy quyền.

Địa chỉ ổn định đơn giản hóa các quy tắc và nhật ký, nhưng không bao giờ chứng minh ai đã tạo ra một gói tin. Xác thực và ủy quyền đích vẫn quan trọng khi địa chỉ đó sau này chuyển sang một phiên khác.

Bài viết liên quan