Odkazy na SharePoint se přes VPN rozbíjejí kvůli publikovaným URL

Stránka SharePoint se otevře přes VPN a první odkaz na dokument selže s názvem, který nikdy nebyl v adresním řádku. Tato mezera je celý problém: stránka přišla z jedné URL a služba naformátovala další požadavek z jiné. Publikovaná URL je rozhodnutí na straně serveru, takže opravovat ji na klientovi je špatný konec. Zkontrolujte, jaký název služba vrací, než se dotknete DNS nebo tras.

První stránka a další požadavek používají různé názvy

Uživatel, který se na server dostane přes adresu, vidí fungující domovskou stránku. Odkazy na dokumenty na této stránce se generují z URL, o které si služba myslí, že ji publikuje, nikoli z toho, co zadal prohlížeč. Pokud se liší, další kliknutí jde na název, který klient nikdy nepřeložil.

Zadání adresy jednou neopraví každý vygenerovaný odkaz a záložka na adresu skrývá problém, dokud se dokument neotevře.

Toto selhání lze snadno chybně přečíst jako problém VPN, protože se objeví až po použití tunelu. Tunel ve skutečnosti dělá svou práci: nese požadavek na název, který nemá funkční cestu nebo nemá odpovídající certifikát. Oddělte obě otázky, než změníte kteroukoli z nich. Jedna je, kam paket jde, druhá je, jaký název služba zvolila publikovat.

Čtyři kontroly, jeden název

Každý publikovaný název musí projít čtyřmi nezávislými kontrolami. DNS jej musí přeložit pro skutečného klienta, směrování a přístupová politika musí cestu povolit, TLS musí ten název ověřit a služba musí být nakonfigurována k jeho publikování.

Změna jedné kontroly neprovede ostatní. Přijetí varování certifikátu není oprava překladu názvu.

Tabulka níže je pořadí kontrolního seznamu. Zastavte se u prvního řádku, který selže, protože pozdější oprava nemůže nahradit dřívější mezeru.

Přečtěte si model publikování, než jej změníte

Nasazení SharePoint Server se liší. Klasické webové aplikace mohou používat alternativní mapování přístupu, kde interní URL je to, co server přijímá, a veřejná URL je to, co používá k formátování odkazů. Kolekce webů s názvem hostitele volí jiný přístup a podle pokynů Microsoftu nemohou používat AAM.

Pokyny pro plánování od Microsoftu také označují funkce AAM za zastaralé a doporučují kolekce webů s názvem hostitele pro nové plánování. To činí z modelu nasazení otázku pro jeho vlastníka, ne výchozí hodnotu, kterou záplatujete.

Než navrhnete změnu mapování, zjistěte, který model se používá. Přidání záznamu AAM do nasazení s názvem hostitele nic nedělá a přidání jednoho do klasického nasazení změní všechny vracené odkazy najednou. Obojí jsou konfigurační změny s širokým dopadem, proto je připravujte po etapách a mějte plán návratu. Toto není doporučení zavádět stará mapování do moderního prostředí.

Sledujte neúspěšnou operaci, ne domovskou stránku

Zaznamenejte cíl, který neúspěšný požadavek skutečně použil, klientskou aplikaci, čas a chybu. Prohlížeč a desktopová aplikace mohou jít k témuž dokumentu různými cestami přes proxy, VPN nebo ověřování.

Prohlížeč může uspět, zatímco klient Office selže, a tento rozdíl je vodítkem, který kontext název překládá.

Pokud URL i síťové předání fungují a služba operaci stále odmítá, zbývající problém je na úrovni aplikace. Oprávnění k dokumentům a stav uzamčení patří vlastníkovi služby a trasa VPN poskytuje konektivitu, nikoli oprávnění.

Zkontrolujte předání od začátku do konce

Proveďte kontroly v pořadí na klientovi, který selhává: přeložte publikovaný název, vyžádejte stránku pod tímto názvem a poté vyžádejte URL dokumentu ze zdrojového kódu stránky. Každý krok izoluje jednu kontrolu.

Tři příkazy pokrývají překlad, 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.aspx

Pokud překlad selhává jen přes tunel, podezřelá je politika split-DNS. Pokud selhává TLS, porovnejte název certifikátu s publikovaným názvem, místo abyste proklikali varování. Pokud obojí uspěje a dokument stále selhává, chyba už není o URL.