Посилання SharePoint ламаються через VPN через опубліковані URL

Сторінка SharePoint відкривається через VPN, і перше посилання на документ не працює з іменем, якого ніколи не було в адресному рядку. Ця прогалина і є вся проблема: сторінка прийшла з одного URL, а служба сформувала наступний запит з іншого. Опублікований URL — це рішення на боці сервера, тому виправляти його на клієнті — не той кінець. Перевірте, яке ім'я повертає служба, перш ніж чіпати DNS або маршрути.

Перша сторінка і наступний запит використовують різні імена

Користувач, який потрапляє на сервер за адресою, бачить робочу головну сторінку. Посилання на документи на цій сторінці створюються з URL, який служба вважає опублікованим, а не з того, що ввів браузер. Якщо вони різняться, наступний клік веде на ім'я, яке клієнт ніколи не розв'язував.

Одноразове введення адреси не виправляє кожне створене посилання, а закладка на адресу приховує проблему до відкриття документа.

Цю помилку легко неправильно прочитати як проблему VPN, бо вона з'являється лише після використання тунелю. Насправді тунель робить свою роботу: він несе запит до імені, для якого немає робочого шляху або відповідного сертифіката. Розділіть два питання, перш ніж змінювати будь-яке з них. Одне — куди йде пакет, друге — яке ім'я служба обрала для публікації.

Чотири перевірки, одне ім'я

Кожне опубліковане ім'я має пройти чотири незалежні перевірки. DNS має розв'язати його для фактичного клієнта, маршрутизація й політика доступу мають дозволити шлях, TLS має перевірити те ім'я, а служба має бути налаштована на його публікацію.

Зміна однієї перевірки не виконує інших. Прийняття попередження про сертифікат не є виправленням розв'язання імен.

Таблиця нижче — це порядок контрольного списку. Зупиніться на першому рядку, який не проходить, бо пізніше виправлення не компенсує ранню прогалину.

Прочитайте модель публікації, перш ніж її змінювати

Розгортання SharePoint Server різняться. Класичні вебпрограми можуть використовувати альтернативні зіставлення доступу, де внутрішній URL — це те, що отримує сервер, а публічний URL — те, що він використовує для форматування посилань. Колекції сайтів з іменем хоста дотримуються іншого підходу і, згідно з настановами Microsoft, не можуть використовувати AAM.

Настанови з планування Microsoft також позначають функції AAM як застарілі та радять колекції сайтів з іменем хоста для нового планування. Це робить модель розгортання питанням до її власника, а не типовим значенням, яке ви латаєте.

Встановіть, яка модель використовується, перш ніж пропонувати зміну зіставлення. Додавання запису AAM до розгортання з іменем хоста нічого не робить, а додавання одного до класичного розгортання змінює всі повернені посилання одразу. Обидва — це зміни конфігурації з широким впливом, тож готуйте їх поетапно й тримайте план відкату. Це не рекомендація вносити старі зіставлення в сучасне середовище.

Стежте за невдалою операцією, а не за головною сторінкою

Запишіть призначення, яке фактично використав невдалий запит, клієнтську програму, час і помилку. Браузер і настільна програма можуть проходити різні шляхи через проксі, VPN або автентифікацію до того самого документа.

Браузер може досягти успіху, тоді як клієнт Office зазнає невдачі, і ця різниця підказує, який контекст розв'язує ім'я.

Якщо URL і мережна передача обидва працюють, а служба все ще відхиляє операцію, залишкова проблема на рівні програми. Дозволи на документи й стан оплати належать власникові служби, а маршрут VPN дає зв'язність, а не дозвіл.

Перевірте передачу від початку до кінця

Виконайте перевірки по порядку на клієнті, який зазнає невдачі: розв'яжіть опубліковане ім'я, запитайте сторінку за цим іменем, а потім запитайте URL документа з вихідного коду сторінки. Кожен крок ізолює одну перевірку.

Три команди охоплюють розв'язання, TLS і шлях до документа:

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

Якщо розв'язання не вдається лише через тунель, підозрюваною є політика split-DNS. Якщо TLS не вдається, порівняйте ім'я сертифіката з опублікованим іменем, а не переходьте через попередження. Якщо обидва успішні, а документ усе ще не відкривається, помилка вже не про URL.