IIS Manager từ xa: kiểm tra địa chỉ riêng của WMSVC trước

Trang của bạn trả lời trên 443 qua đường hầm, và IIS Manager vẫn không thể kết nối tới máy chủ. Cặp kết quả này không mâu thuẫn, vì trang web và điểm cuối quản trị từ xa là hai trình lắng nghe với hai cấu hình và hai bộ quy tắc truy cập. Bên quản trị thuộc Web Management Service, WMSVC, và có địa chỉ, cổng, chứng chỉ cùng các giới hạn IPv4 riêng. Hãy kiểm tra điểm cuối đó trước khi chạm vào dù chỉ một tuyến.

Hai trình lắng nghe, hai vấn đề khác nhau

Yêu cầu tới trang đi đến liên kết HTTP.sys của trang đó, được định nghĩa theo từng trang và từng giao thức trong cấu hình applicationHost. Yêu cầu từ IIS Manager đi đến WMSVC, dịch vụ này mặc định trả lời HTTPS trên TCP 8172 và được cấu hình ở cấp máy chủ. Không có gì trong liên kết của trang thay đổi nơi WMSVC lắng nghe, và không có gì trong WMSVC thay đổi địa chỉ mà trang trả lời. Chúng chia sẻ một máy và một kho chứng chỉ, và sự giống nhau kết thúc ở đó.

Vì vậy một Test-NetConnection thành công tới cổng 443 chỉ cho biết trình lắng nghe của trang có thể truy cập, và không nói gì về quản trị.

Tìm địa chỉ mà WMSVC thực sự được liên kết

Hỏi máy chủ xem hiện nó đang lắng nghe gì, chứ không phải điều đã được cấu hình nhiều năm trước. Get-NetTCPConnection -LocalPort 8172 -State Listen in địa chỉ cục bộ, và giá trị 0.0.0.0 hoặc :: nghĩa là mọi địa chỉ, trong khi một địa chỉ cụ thể chỉ nghĩa là địa chỉ đó. Nếu địa chỉ của máy chủ đã thay đổi, một trình lắng nghe vẫn gắn vào địa chỉ đã nghỉ hưu chính là lỗi mà bước kiểm tra này bắt được.

Giá trị được cấu hình nằm trên trang Management Service của IIS Manager ở nút máy chủ, và phía sau nó trong administration.config trong thư mục cấu hình inetsrv. Hãy so sánh cả hai: tệp nói gì, và ổ cắm thực sự được liên kết với gì.

Sau đó chạy Test-NetConnection -ComputerName iis-admin.example.com -Port 8172 -InformationLevel Detailed từ máy khách VPN bị ảnh hưởng và đọc địa chỉ đã phân giải cùng địa chỉ nguồn được chọn. Câu trả lời DNS khác trên VPN đủ phổ biến để đáng loại trừ sớm. Giữ nguyên tên máy chủ và cổng chính xác đó trong phiếu, vì việc so sánh sau này với một tên khác không chứng minh được gì về thay đổi bạn đã làm.

Đọc địa chỉ nguồn mà máy chủ nhìn thấy

Các giới hạn IPv4 của WMSVC được đánh giá theo địa chỉ đến máy chủ, mà không phải lúc nào cũng là địa chỉ mà máy tính xách tay của bạn nghĩ rằng nó có. Nếu nhóm VPN được dịch ở đâu đó trên đường đi, máy chủ thấy địa chỉ đã dịch và danh sách cho phép xây từ địa chỉ bên trong của máy khách sẽ từ chối nó. Sự từ chối đó trông giống như lỗi kết nối từ phía máy khách, vì vậy nó thường bị chẩn đoán nhầm là vấn đề định tuyến.

Dùng đầu ra chi tiết của bài kiểm tra TCP, cùng với bảng kết nối của chính máy chủ, để xem địa chỉ nguồn nào thực sự đến trước khi bạn sửa danh sách giới hạn.

Thay đổi liên kết như một thay đổi dịch vụ

WMSVC phải được dừng trước khi sửa cấu hình, vì vậy hãy lên kế hoạch như một thay đổi có sẵn một đường quản trị khác, chẳng hạn truy cập bảng điều khiển hoặc phiên từ xa không phụ thuộc vào IIS Manager. Dừng dịch vụ, áp dụng thay đổi địa chỉ, cổng hoặc chứng chỉ, rồi khởi động lại và xác nhận trình lắng nghe đã chuyển. Bất kỳ ai khác đang dùng quản trị IIS từ xa sẽ mất phiên trong khoảng thời gian đó. Hãy báo cho các quản trị viên khác trước khi cửa sổ mở ra; phát hiện điều đó giữa lúc thay đổi là cách hai người cùng sửa một trình lắng nghe.

Chọn mọi địa chỉ là một lựa chọn hợp lệ, nhưng hãy coi đó là quyết định truy cập chứ không phải lối tắt. Mở rộng trình lắng nghe trong khi danh sách giới hạn vẫn mở là cách một điểm cuối quản trị bị phơi ra trên mạng mà không ai định trước. Nếu máy chủ có nhiều NIC, hãy giới hạn trình lắng nghe ở giao diện quản trị, để yên đường dữ liệu và xác nhận trang vẫn trả lời trên địa chỉ riêng của nó.

Chứng chỉ mà WMSVC trình bày được chọn riêng khỏi chứng chỉ của trang. Nếu bạn đổi địa chỉ, hãy xác nhận chứng chỉ vẫn khớp với tên máy chủ mà máy khách dùng, nếu không kết nối sẽ thất bại sau đó ở bước TLS với một phàn nàn không liên quan gì đến định tuyến.

Tách khả năng tiếp cận khỏi tin cậy và quyền

Khi TCP thành công, các lỗi còn lại có thứ tự: tin cậy TLS cho chứng chỉ quản trị, rồi xác thực Windows, rồi quyền IIS Manager được cấp cho tài khoản đó. Mỗi lỗi tạo ra một lỗi khác nhau, và không lỗi nào được sửa bằng tuyến hay quy tắc tường lửa. Hãy đọc văn bản lỗi theo đúng nghĩa thay vì khởi động lại dịch vụ.

Thực hiện bốn bước kiểm tra theo thứ tự đó, điểm cuối, trình lắng nghe, địa chỉ nguồn, tin cậy, và bạn thường sẽ tìm thấy liên kết cũ trước khi tìm thấy sự cố mạng.