SharePoint везе се кидају преко VPN-а због објављених URL-ова
SharePoint страница учитана преко VPN-а и даље може да враћа везе ка документима са именом које ваш клијент не може да разреши. Проверите DNS, руту, TLS и објављени URL.
SharePoint страница се отвара преко VPN-а, а прва веза ка документу не успева са именом које никада није било у адресној траци. Тај јаз је цео проблем: страница је дошла са једног URL-а, а сервис је следећи захтев форматирао са другог. Објављени URL је одлука на страни сервера, па је поправљање на клијенту погрешан крај. Проверите које име сервис враћа пре него што дирате DNS или руте.
Прва страница и следећи захтев користе различита имена
Корисник који стигне до сервера по адреси види радну почетну страницу. Везе ка документима на тој страници генеришу се из URL-а за који сервис мисли да га објављује, а не из онога што је прегледач унео. Ако се разликују, следећи клик иде на име које клијент никада није разрешио.
Унос адресе једном не поправља сваку генерисану везу, а обележивач до адресе крије проблем док се документ не отвори.
Овај неуспех се лако погрешно прочита као проблем са VPN-ом јер се појављује тек након што се тунел почне користити. У пракси тунел ради свој посао: носи захтев до имена које нема радну путању или нема одговарајући сертификат. Одвојите два питања пре него што промените било које. Једно је камо пакет иде, друго је које је име сервис изабрао да објави.
Четири контроле, једно име
Свако објављено име мора да прође четири независне контроле. DNS мора да га разреши за стварног клијента, усмеравање и политика приступа морају да дозволе путању, TLS мора да верификује то име, а сервис мора да буде конфигурисан да га објави.
Промена у једној контроли не обавља остале. Прихватање упозорења о сертификату није поправка разрешавања имена.
Табела испод је редослед контролне листе. Зауставите се на првом реду који не прође, јер каснија поправка не може да надокнади ранији јаз.
| Control | Question | Where to look |
|---|---|---|
| DNS | Can the client resolve the published name? | Client resolver and split-DNS policy |
| Route and policy | Does the permitted path exist to the service? | VPN routes and firewall rules |
| TLS identity | Does the certificate match the name in use? | Certificate subject names and trust store |
| Publishing config | Which URL does the service return? | Web application settings and site model |
Прочитајте модел објављивања пре него што га промените
Распоређивања 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-у.