SharePoint-links går i stykker over VPN på grund af offentliggjorte URL'er
En SharePoint-side, der indlæses over VPN, kan stadig returnere dokumentlinks på et navn, din klient ikke kan slå op. Kontroller DNS, rute, TLS og den offentliggjorte URL.
En SharePoint-side åbnes gennem VPN, og det første dokumentlink fejler med et navn, der aldrig var i adressefeltet. Det gab er hele problemet: siden kom fra én URL, og tjenesten formaterede den næste anmodning ud fra en anden. Den offentliggjorte URL er en beslutning på serversiden, så at rette den på klienten er den forkerte ende. Kontroller, hvilket navn tjenesten returnerer, før du rører DNS eller ruter.
Den første side og den næste anmodning bruger forskellige navne
En bruger, der når serveren via adressen, ser en fungerende forside. Dokumentlinkene på den side genereres ud fra den URL, som tjenesten mener, den offentliggør, ikke ud fra det, browseren skrev. Hvis de er forskellige, går det næste klik til et navn, klienten aldrig har slået op.
At indtaste adressen én gang reparerer ikke alle genererede links, og et bogmærke til adressen skjuler problemet, indtil et dokument åbnes.
Fejlen læses let forkert som et VPN-problem, fordi den først vises, når tunnelen er i brug. I praksis gør tunnelen sit arbejde: den bærer anmodningen til et navn uden fungerende rute eller passende certifikat. Adskil de to spørgsmål, før du ændrer noget af det. Det ene er, hvor pakken går hen, det andet er, hvilket navn tjenesten valgte at offentliggøre.
Fire kontroller, ét navn
Hvert offentliggjort navn skal bestå fire uafhængige kontroller. DNS skal slå det op for den faktiske klient, routing og adgangspolitik skal tillade ruten, TLS skal validere for det navn, og tjenesten skal være konfigureret til at offentliggøre det.
En ændring i én kontrol udfører ikke de andre. At acceptere en certifikatadvarsel er ikke en reparation af navneopslag.
Tabellen nedenfor er tjeklistens rækkefølge. Stop ved den første række, der fejler, fordi en senere rettelse ikke kan opveje et tidligere gab.
| 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 |
Læs publiceringsmodellen, før du ændrer den
SharePoint Server-installationer er forskellige. Klassiske webapplikationer kan bruge alternative adgangstilknytninger, hvor en intern URL er det, serveren modtager, og en offentlig URL er det, den bruger til at formatere links. Værtsnavngivne webstedssamlinger følger en anden tilgang og kan ifølge Microsofts vejledning ikke bruge AAM.
Microsofts planlægningsvejledning markerer også AAM-funktioner som forældede og anbefaler værtsnavngivne webstedssamlinger til ny planlægning. Det gør installationsmodellen til et spørgsmål for dens ejer, ikke en standard, du lapper.
Fastslå, hvilken model der er i brug, før du foreslår en tilknytningsændring. At tilføje en AAM-post til en værtsnavngivet installation gør ingenting, og at tilføje en til en klassisk installation ændrer hvert returneret link på én gang. Begge er konfigurationsændringer med stor rækkevidde, så forbered dem i faser, og hold en tilbagerulning. Dette er ikke en anbefaling om at indføre ældre tilknytninger i et moderne miljø.
Følg den mislykkede handling, ikke forsiden
Registrer det mål, den mislykkede anmodning faktisk brugte, klientprogrammet, tidspunktet og fejlen. En browser og et skrivebordsprogram kan tage forskellige proxy-, VPN- eller godkendelsesveje til det samme dokument.
Browseren kan lykkes, mens Office-klienten fejler, og den forskel er et fingerpeg om, hvilken kontekst der slår navnet op.
Hvis URL'en og netværksoverdragelsen begge virker, og tjenesten stadig afviser handlingen, er det resterende problem på applikationsniveau. Dokumenttilladelser og check-out-status tilhører tjenesteejeren, og en VPN-rute giver forbindelse, ikke tilladelse.
Kontroller overdragelsen fra ende til anden
Kør kontrollerne i rækkefølge på den klient, der fejler: slå det offentliggjorte navn op, anmod om siden med det navn, og anmod derefter om dokumentets URL fra sidens kilde. Hvert trin isolerer én kontrol.
Tre kommandoer dækker opslag, 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.aspxHvis opslaget kun fejler gennem tunnelen, er split-DNS-politikken den mistænkte. Hvis TLS fejler, sammenlign certifikatnavnet med det offentliggjorte navn i stedet for at klikke igennem. Hvis begge lykkes, og dokumentet stadig fejler, handler fejlen ikke længere om URL'en.