Odkazy SharePoint sa cez VPN lámu pre publikované URL
Stránka SharePoint načítaná cez VPN môže stále vracať odkazy na dokumenty s názvom, ktorý váš klient nedokáže vyriešiť. Skontrolujte DNS, trasu, TLS a publikovanú URL.
Stránka SharePoint sa otvorí cez VPN a prvý odkaz na dokument zlyhá s názvom, ktorý nikdy nebol v adresnom riadku. Táto medzera je celý problém: stránka prišla z jednej URL a služba naformátovala ďalšiu požiadavku z inej. Publikovaná URL je rozhodnutie na strane servera, takže opravovať ju na klientovi je nesprávny koniec. Skontrolujte, aký názov služba vracia, než sa dotknete DNS alebo trás.
Prvá stránka a ďalšia požiadavka používajú rôzne názvy
Používateľ, ktorý sa na server dostane cez adresu, vidí fungujúcu domovskú stránku. Odkazy na dokumenty na tejto stránke sa generujú z URL, o ktorej si služba myslí, že ju publikuje, nie z toho, čo zadal prehliadač. Ak sa líšia, ďalšie kliknutie ide na názov, ktorý klient nikdy nevyriešil.
Zadanie adresy raz neopraví každý vygenerovaný odkaz a záložka na adresu skrýva problém, kým sa dokument neotvorí.
Toto zlyhanie sa dá ľahko nesprávne prečítať ako problém VPN, pretože sa objaví až po použití tunela. Tunel v skutočnosti robí svoju prácu: nesie požiadavku na názov, ktorý nemá funkčnú cestu alebo nemá zodpovedajúci certifikát. Oddeľte obe otázky, než zmeníte ktorúkoľvek z nich. Jedna je, kam paket ide, druhá je, aký názov služba zvolila publikovať.
Štyri kontroly, jeden názov
Každý publikovaný názov musí prejsť štyrmi nezávislými kontrolami. DNS ho musí vyriešiť pre skutočného klienta, smerovanie a prístupová politika musia cestu povoliť, TLS musí ten názov overiť a služba musí byť nakonfigurovaná na jeho publikovanie.
Zmena jednej kontroly nevykoná ostatné. Prijatie varovania certifikátu nie je oprava prekladu názvu.
Tabuľka nižšie je poradie kontrolného zoznamu. Zastavte sa na prvom riadku, ktorý zlyhá, pretože neskoršia oprava nemôže nahradiť skoršiu medzeru.
| 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 |
Prečítajte si model publikovania, než ho zmeníte
Nasadenia SharePoint Server sa líšia. Klasické webové aplikácie môžu používať alternatívne mapovania prístupu, kde interná URL je to, čo server prijíma, a verejná URL je to, čo používa na formátovanie odkazov. Kolekcie lokalít s názvom hostiteľa volia iný prístup a podľa pokynov Microsoftu nemôžu používať AAM.
Pokyny na plánovanie od Microsoftu tiež označujú funkcie AAM za zastarané a odporúčajú kolekcie lokalít s názvom hostiteľa pre nové plánovanie. To robí z modelu nasadenia otázku pre jeho vlastníka, nie predvolenú hodnotu, ktorú záplatujete.
Než navrhnete zmenu mapovania, zistite, ktorý model sa používa. Pridanie záznamu AAM do nasadenia s názvom hostiteľa nič nerobí a pridanie jedného do klasického nasadenia zmení všetky vracané odkazy naraz. Obe sú konfiguračné zmeny so širokým dopadom, preto ich pripravte po etapách a majte plán návratu. Toto nie je odporúčanie zavádzať staré mapovania do moderného prostredia.
Sledujte neúspešnú operáciu, nie domovskú stránku
Zaznamenajte cieľ, ktorý neúspešná požiadavka skutočne použila, klientsku aplikáciu, čas a chybu. Prehliadač a desktopová aplikácia môžu ísť k rovnakému dokumentu rôznymi cestami cez proxy, VPN alebo overovanie.
Prehliadač môže uspieť, zatiaľ čo klient Office zlyhá, a tento rozdiel je vodítkom, ktorý kontext názov prekladá.
Ak URL aj sieťové odovzdanie fungujú a služba operáciu stále odmieta, zostávajúci problém je na úrovni aplikácie. Oprávnenia k dokumentom a stav uzamknutia patria vlastníkovi služby a trasa VPN poskytuje konektivitu, nie oprávnenie.
Skontrolujte odovzdanie od začiatku do konca
Vykonajte kontroly v poradí na klientovi, ktorý zlyháva: vyriešte publikovaný názov, vyžiadajte stránku pod týmto názvom a potom vyžiadajte URL dokumentu zo zdrojového kódu stránky. Každý krok izoluje jednu kontrolu.
Tri príkazy pokrývajú preklad, TLS a cestu k dokumentu:
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.aspxAk preklad zlyháva len cez tunel, podozrivá je politika split-DNS. Ak zlyháva TLS, porovnajte názov certifikátu s publikovaným názvom, namiesto prekliknutia varovania. Ak obe uspejú a dokument stále zlyháva, chyba už nie je o URL.