Връзките на 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.