Liên kết SharePoint hỏng qua VPN vì URL đã công bố

Một trang SharePoint mở qua VPN, và liên kết tài liệu đầu tiên thất bại với một tên chưa bao giờ có trong thanh địa chỉ. Khoảng hở đó chính là toàn bộ vấn đề: trang đến từ một URL, và dịch vụ đã định dạng yêu cầu tiếp theo từ một URL khác. URL đã công bố là quyết định phía máy chủ, nên sửa nó trên máy khách là sai đầu. Hãy kiểm tra dịch vụ trả về tên nào trước khi chạm vào DNS hay tuyến.

Trang đầu và yêu cầu tiếp theo dùng những tên khác nhau

Người dùng truy cập máy chủ bằng địa chỉ sẽ thấy một trang chủ hoạt động. Các liên kết tài liệu trong trang đó được tạo từ URL mà dịch vụ cho là đang công bố, không phải từ URL trình duyệt đã nhập. Nếu hai bên khác nhau, lần nhấp tiếp theo đi đến một tên mà máy khách chưa bao giờ phân giải.

Nhập địa chỉ một lần không sửa mọi liên kết được tạo, và một dấu trang đến địa chỉ che giấu vấn đề cho đến khi mở tài liệu.

Lỗi này dễ bị đọc nhầm thành vấn đề VPN vì nó chỉ xuất hiện sau khi đường hầm được dùng. Trên thực tế đường hầm vẫn làm việc của nó: nó mang yêu cầu đến một tên không có đường hoạt động hoặc không có chứng chỉ khớp. Hãy tách hai câu hỏi trước khi thay đổi bất kỳ bên nào. Một là gói tin đi đâu, hai là dịch vụ đã chọn công bố tên nào.

Bốn kiểm soát, một tên

Mỗi tên đã công bố phải qua bốn kiểm soát độc lập. DNS phải phân giải nó cho máy khách thực tế, định tuyến và chính sách truy cập phải cho phép đường đi, TLS phải xác thực tên đó, và dịch vụ phải được cấu hình để công bố nó.

Thay đổi một kiểm soát không thực hiện các kiểm soát khác. Chấp nhận cảnh báo chứng chỉ không phải là sửa phân giải tên.

Bảng dưới đây là thứ tự của danh sách kiểm tra. Dừng ở hàng đầu tiên thất bại, vì sửa sau không thể bù đắp khoảng hở trước.

Đọc mô hình công bố trước khi thay đổi nó

Các triển khai SharePoint Server khác nhau. Ứng dụng web cổ điển có thể dùng ánh xạ truy cập thay thế, trong đó URL nội bộ là thứ máy chủ nhận và URL công khai là thứ nó dùng để định dạng liên kết. Bộ sưu tập site đặt tên máy chủ theo cách khác và, theo hướng dẫn của Microsoft, không thể dùng AAM.

Hướng dẫn lập kế hoạch của Microsoft cũng đánh dấu các tính năng AAM là lỗi thời và khuyến nghị bộ sưu tập site đặt tên máy chủ cho việc lập kế hoạch mới. Điều đó biến mô hình triển khai thành câu hỏi cho chủ sở hữu của nó, không phải giá trị mặc định mà bạn vá.

Xác định mô hình nào đang được dùng trước khi đề xuất thay đổi ánh xạ. Thêm một mục AAM vào triển khai đặt tên máy chủ không làm gì cả, và thêm một mục vào triển khai cổ điển sẽ thay đổi mọi liên kết được trả về cùng lúc. Cả hai đều là thay đổi cấu hình có ảnh hưởng rộng, nên hãy chuẩn bị theo giai đoạn và giữ kế hoạch khôi phục. Đây không phải khuyến nghị đưa các ánh xạ cũ vào môi trường hiện đại.

Theo dõi thao tác thất bại, không phải trang chủ

Ghi lại đích mà yêu cầu thất bại thực sự dùng, ứng dụng máy khách, thời điểm và lỗi. Trình duyệt và ứng dụng máy tính để bàn có thể đi những đường proxy, VPN hoặc xác thực khác nhau đến cùng một tài liệu.

Trình duyệt có thể thành công trong khi máy khách Office thất bại, và sự khác biệt đó là manh mối về ngữ cảnh nào phân giải tên.

Nếu URL và việc chuyển giao mạng đều hoạt động mà dịch vụ vẫn từ chối thao tác, vấn đề còn lại nằm ở tầng ứng dụng. Quyền tài liệu và trạng thái thanh toán thuộc về chủ sở hữu dịch vụ, và tuyến VPN cung cấp kết nối, không phải quyền.

Kiểm tra việc chuyển giao từ đầu đến cuối

Chạy các kiểm tra theo thứ tự trên máy khách thất bại: phân giải tên đã công bố, yêu cầu trang bằng tên đó, rồi yêu cầu URL tài liệu từ mã nguồn trang. Mỗi bước cô lập một kiểm soát.

Ba lệnh bao gồm phân giải, TLS và đường dẫn tài liệu:

nslookup portal.hq.example
curl -sSI https://portal.hq.example/ | head -5
curl -sS -o /dev/null -w "%{http_code}" https://portal.hq.example/sites/team/Doc.aspx

Nếu phân giải chỉ thất bại qua đường hầm, chính sách split-DNS là đối tượng nghi ngờ. Nếu TLS thất bại, hãy so sánh tên chứng chỉ với tên đã công bố thay vì nhấp qua cảnh báo. Nếu cả hai đều thành công mà tài liệu vẫn thất bại, lỗi không còn là về URL nữa.