SharePoint-koblinger brytes over VPN på grunn av publiserte URL-er
En SharePoint-side som lastes over VPN, kan fortsatt returnere dokumentkoblinger på et navn klienten din ikke kan slå opp. Kontroller DNS, rute, TLS og den publiserte URL-en.
En SharePoint-side åpnes over VPN, og den første dokumentkoblingen feiler med et navn som aldri var i adressefeltet. Det gapet er hele problemet: siden kom fra én URL, og tjenesten formaterte den neste forespørselen fra en annen. Den publiserte URL-en er en beslutning på serversiden, så å rette den på klienten er feil ende. Kontroller hvilket navn tjenesten returnerer før du rører DNS eller ruter.
Den første siden og den neste forespørselen bruker forskjellige navn
En bruker som når serveren via adressen, ser en fungerende forside. Dokumentkoblingene på den siden genereres fra URL-en tjenesten mener den publiserer, ikke fra det nettleseren skrev. Hvis de er forskjellige, går neste klikk til et navn klienten aldri har slått opp.
Å skrive inn adressen én gang reparerer ikke hver generert kobling, og et bokmerke til adressen skjuler problemet til et dokument åpnes.
Denne feilen leses lett feil som et VPN-problem fordi den bare vises etter at tunnelen er i bruk. I praksis gjør tunnelen jobben sin: den bærer forespørselen til et navn uten fungerende rute eller uten samsvarende sertifikat. Skill de to spørsmålene før du endrer noen av dem. Det ene er hvor pakken går, det andre er hvilket navn tjenesten valgte å publisere.
Fire kontroller, ett navn
Hvert publisert navn må bestå fire uavhengige kontroller. DNS må slå det opp for den faktiske klienten, ruting og tilgangspolicy må tillate ruten, TLS må validere for det navnet, og tjenesten må være konfigurert til å publisere det.
En endring i én kontroll utfører ikke de andre. Å godta en sertifikatadvarsel er ikke en reparasjon av navneoppslag.
Tabellen nedenfor er rekkefølgen i sjekklisten. Stopp ved den første raden som feiler, fordi en senere retting ikke kan veie opp for et tidligere gap.
| 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 |
Les publiseringsmodellen før du endrer den
SharePoint Server-installasjoner er forskjellige. Klassiske webapplikasjoner kan bruke alternative tilgangstilordninger, der en intern URL er det serveren mottar, og en offentlig URL er det den bruker til å formatere koblinger. Vertnavngitte områdesamlinger følger en annen tilnærming og kan ifølge Microsofts veiledning ikke bruke AAM.
Microsofts planleggingsveiledning markerer også AAM-funksjoner som utdaterte og anbefaler vertnavngitte områdesamlinger for ny planlegging. Det gjør installasjonsmodellen til et spørsmål for eieren, ikke en standard du lapper.
Fastslå hvilken modell som er i bruk før du foreslår en tilordningsendring. Å legge til en AAM-oppføring i en vertnavngitt installasjon gjør ingenting, og å legge til en i en klassisk installasjon endrer hver returnerte kobling på én gang. Begge er konfigurasjonsendringer med stort omfang, så forbered dem i trinn og hold en tilbakerullingsplan. Dette er ikke en anbefaling om å innføre gamle tilordninger i et moderne miljø.
Følg den mislykkede operasjonen, ikke forsiden
Registrer målet den mislykkede forespørselen faktisk brukte, klientapplikasjonen, tidspunktet og feilen. En nettleser og en skrivebordsapplikasjon kan ta forskjellige proxy-, VPN- eller godkjenningsveier til samme dokument.
Nettleseren kan lykkes mens Office-klienten feiler, og den forskjellen er et hint om hvilken kontekst som slår opp navnet.
Hvis URL-en og nettverksoverleveringen begge fungerer og tjenesten fortsatt avviser operasjonen, er det gjenværende problemet på applikasjonsnivå. Dokumenttillatelser og innsjekkingsstatus tilhører tjenesteeieren, og en VPN-rute gir tilkobling, ikke tillatelse.
Kontroller overleveringen fra ende til annen
Kjør kontrollene i rekkefølge på klienten som feiler: slå opp det publiserte navnet, be om siden med det navnet, og be deretter om dokumentets URL fra sidens kilde. Hvert trinn isolerer én kontroll.
Tre kommandoer dekker 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.aspxHvis oppslaget bare feiler gjennom tunnelen, er split-DNS-policyen den mistenkte. Hvis TLS feiler, sammenlign sertifikatnavnet med det publiserte navnet i stedet for å klikke gjennom. Hvis begge lykkes og dokumentet fortsatt feiler, handler feilen ikke lenger om URL-en.