Спасылкі 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.