A SharePoint hivatkozások VPN-en át eltörnek a közzétett URL-ek miatt

Egy SharePoint-oldal VPN-en át nyílik meg, és az első dokumentumhivatkozás olyan névvel hiúsul meg, amely soha nem volt a címsorban. Ez a rés az egész probléma: az oldal egy URL-ről jött, a szolgáltatás pedig a következő kérést egy másikról formázta. A közzétett URL kiszolgálóoldali döntés, ezért az ügyfélen javítani a rossz vég. Ellenőrizze, milyen nevet ad vissza a szolgáltatás, mielőtt a DNS-hez vagy az útvonalakhoz nyúl.

Az első oldal és a következő kérés különböző neveket használ

Az a felhasználó, aki a cím alapján éri el a kiszolgálót, működő kezdőlapot lát. Az oldal dokumentumhivatkozásai abból az URL-ből generálódnak, amelyet a szolgáltatás közzétettnek hisz, nem abból, amit a böngésző beírt. Ha ezek eltérnek, a következő kattintás olyan névre megy, amelyet az ügyfél soha nem oldott fel.

A cím egyszeri beírása nem javítja meg az összes generált hivatkozást, a címre tett könyvjelző pedig elrejti a problémát a dokumentum megnyitásáig.

Ez a hiba könnyen VPN-problémának olvasható, mert csak az alagút használata után jelenik meg. Valójában az alagút a dolgát teszi: a kérést olyan névhez viszi, amelynek nincs működő útvonala vagy nincs megfelelő tanúsítványa. Válassza szét a két kérdést, mielőtt bármelyiket módosítja. Az egyik az, hová megy a csomag, a másik az, melyik nevet választotta közzétételre a szolgáltatás.

Négy ellenőrzés, egy név

Minden közzétett névnek négy független ellenőrzésen kell átmennie. A DNS-nek fel kell oldania a tényleges ügyfél számára, az útválasztásnak és a hozzáférési szabályzatnak engedélyeznie kell az útvonalat, a TLS-nek érvényesítenie kell ezt a nevet, és a szolgáltatást úgy kell beállítani, hogy közzétegye.

Egy ellenőrzés módosítása nem végzi el a többit. A tanúsítványfigyelmeztetés elfogadása nem a névfeloldás javítása.

Az alábbi táblázat az ellenőrzőlista sorrendje. Álljon meg az első sorban, amelyik megbukik, mert egy későbbi javítás nem pótolhat egy korábbi hiányt.

Olvassa el a közzétételi modellt, mielőtt módosítja

A SharePoint Server-telepítések különböznek. A klasszikus webalkalmazások alternatív hozzáférési leképezéseket használhatnak, ahol a belső URL az, amit a kiszolgáló fogad, a nyilvános URL pedig az, amit a hivatkozások formázásához használ. A gazdagépneves webhelygyűjtemények más megközelítést követnek, és a Microsoft útmutatása szerint nem használhatnak AAM-t.

A Microsoft tervezési útmutatója az AAM-funkciókat is elavultnak jelöli, és az új tervezéshez gazdagépneves webhelygyűjteményeket javasol. Ez a telepítési modellt a tulajdonosának kérdésévé teszi, nem pedig Ön által foltozott alapértékké.

Állapítsa meg, melyik modell van használatban, mielőtt leképezésmódosítást javasol. AAM-bejegyzés hozzáadása egy gazdagépneves telepítéshez semmit nem tesz, egy klasszikus telepítéshez hozzáadva pedig minden visszaadott hivatkozást egyszerre megváltoztat. Mindkettő széles hatókörű konfigurációs változtatás, ezért fokozatosan készítse elő őket, és tartson fenn visszaállítási tervet. Ez nem javaslat arra, hogy régi leképezéseket vigyen be egy modern környezetbe.

A sikertelen műveletet kövesse, ne a kezdőlapot

Jegyezze fel a célt, amelyet a sikertelen kérés ténylegesen használt, az ügyfélalkalmazást, az időt és a hibát. A böngésző és az asztali alkalmazás különböző proxy-, VPN- vagy hitelesítési útvonalakon juthat el ugyanahhoz a dokumentumhoz.

A böngésző sikerülhet, miközben az Office-ügyfél meghiúsul, és ez a különbség arra utal, melyik környezet oldja fel a nevet.

Ha az URL és a hálózati átadás is működik, és a szolgáltatás továbbra is elutasítja a műveletet, a fennmaradó probléma alkalmazásszintű. A dokumentumengedélyek és a kijelentkezési állapot a szolgáltatás tulajdonosáé, a VPN-útvonal pedig kapcsolatot ad, nem engedélyt.

Ellenőrizze az átadást elejétől a végéig

Futtassa az ellenőrzéseket sorrendben a meghiúsuló ügyfélen: oldja fel a közzétett nevet, kérje le az oldalt azon a néven, majd kérje le a dokumentum URL-jét az oldal forrásából. Minden lépés egy ellenőrzést izolál.

Három parancs lefedi a feloldást, a TLS-t és a dokumentum útvonalát:

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

Ha a feloldás csak az alagúton keresztül hiúsul meg, a gyanúsított a split-DNS-szabályzat. Ha a TLS hiúsul meg, hasonlítsa össze a tanúsítvány nevét a közzétett névvel, ahelyett hogy átkattintana a figyelmeztetésen. Ha mindkettő sikerül, és a dokumentum továbbra is meghiúsul, a hiba már nem az URL-ről szól.