IP VPN cố định: Framed-IP-Address trong RADIUS hay một đặt trước trong pool
Cấp cho một máy khách VPN địa chỉ nội bộ cố định: Framed-IP-Address trong RADIUS so với ánh xạ pool trên cổng, và cách kiểm tra bên nào thực sự sở hữu đặt trước.
Ba nơi có thể giữ địa chỉ nội bộ cố định cho một máy khách VPN, và chỉ một trong số đó nên sở hữu nó. RADIUS có thể trả địa chỉ trong Access-Accept, cổng có thể giữ ánh xạ tĩnh cho tài khoản, và bộ điều hợp của máy khách có thể đặt thủ công. Hai nơi đầu là chính sách và nơi thứ ba là phỏng đoán cục bộ mà cổng được tự do bỏ qua hoặc ghi đè. Chọn giữa hai nơi đầu là quyết định thật sự, và nó phụ thuộc vào việc máy chủ truy cập mạng thực sự triển khai gì.
Ba nơi một địa chỉ cố định có thể sống
RADIUS sở hữu địa chỉ khi phản hồi mang Framed-IP-Address và cổng áp dụng giá trị đó cho phiên. Cổng sở hữu nó khi quản trị viên ánh xạ tài khoản tới một địa chỉ tĩnh trong pool. Máy khách không sở hữu gì, ngay cả khi bộ điều hợp hiển thị địa chỉ đặt thủ công, vì máy chủ gán địa chỉ nội bộ trong quá trình thương lượng và thiết lập cục bộ chỉ có ý nghĩa khi máy chủ không gửi gì. Cả ba trông giống nhau trên một kết nối đang hoạt động, đó là lý do các xung đột lộ ra muộn. Khác biệt hiện ra khi kết nối lại, trên thiết bị thứ hai và sau khi thay đổi chính sách.
Hai chủ sở hữu là cấu hình bị hỏng. Một phản hồi RADIUS gán 172.28.4.77 trong khi cổng giữ ánh xạ tĩnh cho 172.28.4.90 sẽ cho giá trị mà mã của nhà cung cấp kiểm tra trước, và bên thua bị loại bỏ mà không có một dòng nhật ký. Cùng tài khoản đó trên thiết bị thứ hai nhận địa chỉ trùng lặp, và triệu chứng được đọc như lỗi định tuyến chứ không phải xung đột gán. Hãy quyết định chủ sở hữu trước khi thêm cơ chế thứ hai.
Tùy chọn phía máy khách chỉ đáng nêu ra để có thể loại trừ. Địa chỉ bộ điều hợp đặt thủ công là một tùy chọn hệ điều hành có thể trình bày, không phải một đặt trước, và nó không thể ngăn một phiên khác nhận cùng địa chỉ.
Phản hồi RADIUS có thể và không thể hứa gì
RFC 2865định nghĩa Framed-IP-Address là địa chỉ IPv4 cần cấu hình cho người dùng, và nó thuộc Access-Accept. Cùng thuộc tính đó trong Access-Request chỉ là một gợi ý mà máy chủ có thể bỏ qua, điều này quan trọng khi máy khách hoặc cổng đề nghị một địa chỉ ưu tiên. Không có gì trong giao thức buộc cổng phải tôn trọng phản hồi, vì máy chủ truy cập mạng là thành phần áp dụng nó cho phiên.
Hỗ trợ là câu hỏi về sản phẩm chứ không phải giao thức. Một số cổng áp dụng địa chỉ có khung theo mặc định, số khác cần bật công tắc cấp nhóm trước khi làm vậy, và số khác chấp nhận thuộc tính nhưng không bao giờ dùng nó cho các phiên truy cập từ xa. Trường hợp cuối là nguy hiểm, vì bản ghi kế toán có thể hiển thị phản hồi trong khi máy khách nhận địa chỉ từ pool. Hãy xác nhận hành vi trên đúng kiểu cổng và phần sụn bạn vận hành, không phải trên tài liệu của một sản phẩm anh em.
Một phản hồi mà cổng bỏ qua trông giống hệt một phản hồi chưa bao giờ được gửi. Đọc Access-Accept và địa chỉ phiên cạnh nhau là cách duy nhất để tách hai trường hợp.
Đặt trước địa chỉ bên trong pool bạn đã định tuyến
Chọn địa chỉ cố định từ subnet của pool mà cổng đã định tuyến và tường lửa đã tin cậy. Một địa chỉ ngoài dải đó biến thay đổi chính sách thành một dự án định tuyến, và VPN sẽ lên trong khi không gì phía sau trả lời được. Nếu có quy tắc truy cập theo địa chỉ, hãy thêm địa chỉ cố định vào chúng trong cùng thay đổi.
Quyết định phiên đồng thời thứ hai nên làm gì. Gán một địa chỉ hai lần không phải quản lý thiết bị, và xung đột phát sinh hiện ra như kết nối chập chờn cho cả hai phiên. Hoặc phát hành danh tính riêng cho từng thiết bị, hoặc gán riêng, hoặc buộc đồng thời bằng một kiểm tra được hỗ trợ, chẳng hạn Simultaneous-Use, thay vì hy vọng máy khách không bao giờ kết nối lại trước khi phiên cũ hết hạn.
Các tuyến trả về xứng đáng được chú ý như việc gán. Cổng cần một tuyến tới pool, các bộ định tuyến nội bộ cần tuyến trở lại cổng, và địa chỉ cố định thừa hưởng cả hai. Một máy khách hoạt động trong khi mọi máy khác thất bại thường có nghĩa tuyến của pool tồn tại nhưng tuyến máy chủ cho địa chỉ đặt trước thì không.
Kiểm tra phản hồi trước khi tin vào đặt trước
Kiểm tra phía AAA và phía phiên riêng rẽ, vì chúng thất bại vì lý do khác nhau. Một radtest cục bộ cho thấy máy chủ trả gì cho tài khoản mà không liên quan tới cổng, và mục trong tệp người dùng cho thấy máy chủ phải khớp với gì. Sau đó kết nối lại máy khách và so sánh địa chỉ nhận được với thuộc tính trong phản hồi.
Authenticated member: survey-tablet-17
Reply attribute: Framed-IP-Address = 172.28.4.77
survey-tablet-17 Cleartext-Password := "REPLACE_ME"
Framed-IP-Address = 172.28.4.77
radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123
Access-Accept không có thuộc tính nghĩa là máy chủ không khớp mục hoặc thuộc tính không được áp dụng cho người dùng đó. Access-Accept có thuộc tính và một máy khách vẫn nhận địa chỉ từ pool nghĩa là cổng đã bỏ qua nó. Access-Reject đưa bạn trở lại thông tin đăng nhập hoặc chính sách nhóm, và không kết quả nào trong số này nên được gỡ lỗi bằng cách sửa bộ điều hợp của máy khách.
Lặp lại kiểm tra sau khi kết nối lại và sau lần đăng nhập thứ hai từ thiết bị khác. Một đặt trước chỉ giữ cho phiên đầu là xung đột pool đang chờ xảy ra, và tìm ra nó bây giờ rẻ hơn là trong một cuộc kiểm toán.
Chọn một chủ sở hữu và ghi nó ra
Nếu cổng áp dụng địa chỉ có khung một cách đáng tin cậy, hãy để RADIUS sở hữu việc gán và xóa mọi ánh xạ tĩnh cho cùng tài khoản. Nếu không, hãy để cổng sở hữu nó và xóa thuộc tính khỏi phản hồi, để hai nguồn không thể bất đồng. Giữ cả hai vì mỗi cái gần như hoạt động sẽ bảo đảm một phiên tương lai với địa chỉ sai và không có nguyên nhân rõ ràng.
Ghi chủ sở hữu đã chọn, địa chỉ đặt trước và pool mà nó đến từ đó vào hồ sơ tài khoản. Người tiếp theo thêm thiết bị sẽ thấy địa chỉ là chính sách AAA hay ánh xạ của cổng trước khi thay đổi một trong hai.