SharePoint-lenkjer bryt saman over VPN på grunn av publiserte URL-ar

Ei SharePoint-side opnar over VPN, og den første dokumentlenkja feilar med eit namn som aldri var i adressefeltet. Det gapet er heile problemet: sida kom frå éin URL, og tenesta formaterte den neste førespurnaden frå ein annan. Den publiserte URL-en er ei avgjerd på serversida, så å rette han på klienten er feil ende. Kontroller kva namn tenesta returnerer før du rører DNS eller ruter.

Den første sida og den neste førespurnaden brukar ulike namn

Ein brukar som når serveren via adressa, ser ei fungerande framside. Dokumentlenkjene på den sida blir genererte frå URL-en tenesta meiner ho publiserer, ikkje frå det nettlesaren skreiv. Viss dei er ulike, går neste klikk til eit namn klienten aldri har slått opp.

Å skrive inn adressa éin gong reparerer ikkje kvar generert lenkje, og eit bokmerke til adressa løyner problemet til eit dokument blir opna.

Denne feilen blir lett lesen feil som eit VPN-problem fordi han berre viser seg etter at tunnelen er i bruk. I praksis gjer tunnelen jobben sin: han ber førespurnaden til eit namn utan fungerande rute eller utan samsvarande sertifikat. Skil dei to spørsmåla før du endrar nokon av dei. Det eine er kvar pakken går, det andre er kva namn tenesta valde å publisere.

Fire kontrollar, eitt namn

Kvart publisert namn må bestå fire uavhengige kontrollar. DNS må slå det opp for den faktiske klienten, ruting og tilgangspolicy må tillate ruta, TLS må validere for det namnet, og tenesta må vere konfigurert til å publisere det.

Ei endring i éin kontroll utfører ikkje dei andre. Å godta ei sertifikatåtvaring er ikkje ein reparasjon av namneoppslag.

Tabellen nedanfor er rekkjefølgja i sjekklista. Stopp ved den første rada som feilar, fordi ei seinare retting ikkje kan vege opp for eit tidlegare gap.

Les publiseringsmodellen før du endrar han

SharePoint Server-installasjonar er ulike. Klassiske webapplikasjonar kan bruke alternative tilgangstildelingar, der ein intern URL er det serveren mottek, og ein offentleg URL er det han brukar til å formatere lenkjer. Vertnamngitte områdesamlingar følgjer ein annan tilnærming og kan ifølgje rettleiinga frå Microsoft ikkje bruke AAM.

Rettleiinga til Microsoft for planlegging markerer òg AAM-funksjonar som utdaterte og tilrår vertnamngitte områdesamlingar for ny planlegging. Det gjer installasjonsmodellen til eit spørsmål for eigaren, ikkje ein standard du lappar.

Fastslå kva modell som er i bruk før du føreslår ei tildelingsendring. Å leggje til ein AAM-oppføring i ein vertnamngitt installasjon gjer ingenting, og å leggje til ein i ein klassisk installasjon endrar kvar returnerte lenkje på éin gong. Begge er konfigurasjonsendringar med stort omfang, så førebu dei i trinn og hald ein tilbakerullingsplan. Dette er ikkje ei tilråding om å innføre gamle tildelingar i eit moderne miljø.

Følg den mislukka operasjonen, ikkje framsida

Registrer målet den mislukka førespurnaden faktisk brukte, klientapplikasjonen, tidspunktet og feilen. Ein nettlesar og ein skrivebordsapplikasjon kan ta ulike proxy-, VPN- eller godkjenningsvegar til same dokument.

Nettlesaren kan lukkast medan Office-klienten feilar, og den skilnaden er eit hint om kva kontekst som slår opp namnet.

Viss URL-en og nettverksoverleveringa båe fungerer og tenesta framleis avviser operasjonen, er det gjenverande problemet på applikasjonsnivå. Dokumentløyve og innsjekkingsstatus høyrer til tenesteeigaren, og ei VPN-rute gir tilkopling, ikkje løyve.

Kontroller overleveringa frå ende til annan

Køyr kontrollane i rekkjefølgje på klienten som feilar: slå opp det publiserte namnet, be om sida med det namnet, og be deretter om dokumentet sin URL frå kjelda til sida. Kvart trinn isolerer éin kontroll.

Tre kommandoar dekkjer oppslag, TLS og dokumentstien:

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

Viss oppslaget berre feilar gjennom tunnelen, er split-DNS-policyen den mistenkte. Viss TLS feilar, samanlikn sertifikatnamnet med det publiserte namnet i staden for å klikke gjennom. Viss båe lukkast og dokumentet framleis feilar, handlar feilen ikkje lenger om URL-en.