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