RRAS DHCP: địa chỉ mới hay chỉ là các tùy chọn cấu hình?
ACK trong một vết VPN chứng minh có câu trả lời, không phải có cấp phát. RRAS có thể sở hữu địa chỉ trong khi DHCP chỉ chuyển tùy chọn tới máy khách đã kết nối.
Đọc một DHCPACK trong bản ghi như bằng chứng rằng máy khách VPN nhận địa chỉ từ DHCP là sai lầm. Thông thường nó chỉ chứng minh rằng một thông điệp DHCP nào đó đã được trả lời. Windows RRAS có thể cấp địa chỉ phiên từ nhóm tĩnh của riêng nó trong khi DHCP vẫn cung cấp tùy chọn cho máy khách đã kết nối. Loại yêu cầu cho biết công việc nào trong hai công việc đang diễn ra.
Hai công việc dùng chung một loại thông điệp
DHCP làm hai việc riêng biệt và chúng dùng chung các loại thông điệp. Một là cấp địa chỉ và thời hạn thuê. Việc kia là gửi cấu hình tới một máy chủ đã có địa chỉ, mà RFC 2131 gọi là DHCPINFORM. Câu trả lời trong trường hợp thứ hai mang tùy chọn và không mang thời gian thuê nào.
Vậy ACK là bằng chứng của một câu trả lời, không phải bằng chứng của một lần cấp phát. Thông điệp đứng trước nó quyết định câu hỏi nào đã được đặt ra. Hãy đọc dòng yêu cầu trước, phần còn lại của vết thường tự giải thích.
RRAS lấy địa chỉ từ đâu
RRAS nắm quyết định về địa chỉ VPN thông qua phương thức cấp phát IPv4 đã cấu hình: hoặc máy chủ DHCP, hoặc một nhóm địa chỉ tĩnh. Khi nhóm là tĩnh thì nhóm chính là bên cấp phát, và một đặt trước trên máy chủ DHCP riêng không có tiếng nói trong phiên đó. Hai cơ chế có thể cùng tồn tại trên một mạng mà không bên nào điều khiển bên kia.
Get-Command -Module RemoteAccess *IPAddress*Xác định phương thức cấp phát đang áp dụng trước khi truy tìm địa chỉ. Nếu là nhóm tĩnh thì phạm vi DHCP là nơi không đúng để tìm. Lệnh ở trên liệt kê các cmdlet có trong phiên bản bạn đang chạy, và thế là đủ để tìm ra thiết lập.
Lớp người dùng có thể chứng minh gì và không thể chứng minh gì
Lớp người dùng DHCP là một chuỗi do máy khách gửi, không phải tư cách thành viên nhóm đã xác thực. Ngay cả khi máy khách gửi một chuỗi và máy chủ khớp một chính sách với nó, nhãn đó chỉ chứng minh rằng chuỗi đã đến. RFC 3004 nói rõ rằng tùy chọn này không xác thực quyền đối với lớp.
Đừng mong tên người dùng VPN, mã định danh nhóm bảo mật hay địa chỉ Ethernet của máy tính xách tay xuất hiện trong yêu cầu đó ở dạng dùng được. Đó là các dữ kiện về xác thực và thư mục, và yêu cầu DHCP không mang cả hai. Nếu yêu cầu là phân biệt người được cấp quyền, hãy thực thi điều đó trong chính sách VPN, nơi danh tính thực sự tồn tại. Chính sự tách biệt đó giữ hai hệ thống độc lập.
So sánh bằng chứng, không phải ACK
Dựng chuỗi bằng chứng thay vì đọc một gói tin. Ghi lại địa chỉ mà phiên nhận được, loại và các trường của yêu cầu, các tùy chọn máy chủ trả về, và sau đó là cấu hình thực tế của máy khách. Mỗi mắt xích trả lời một câu hỏi khác nhau, và mắt xích thiếu chính là nơi lỗi thật thường nằm.
Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0Nếu địa chỉ đến từ nhóm RRAS thì một đặt trước DHCP không giải thích được gì. Nếu tùy chọn đến nhưng máy khách bỏ qua chúng thì máy chủ đã làm xong việc của mình và trạm tiếp theo là cấu hình máy khách. So sánh hai kết cục đó một cách rõ ràng thì ACK không còn mơ hồ nữa. Hai vết, mỗi phương thức cấp phát một vết, kết thúc tranh luận nhanh hơn bất kỳ tài liệu nào.