Ссылки 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.