SharePoint-länkar bryts över VPN på grund av publicerade URL:er
En SharePoint-sida som läses in över VPN kan fortfarande returnera dokumentlänkar med ett namn som din klient inte kan slå upp. Kontrollera DNS, rutt, TLS och den publicerade URL:en.
En SharePoint-sida öppnas via VPN, och den första dokumentlänken misslyckas med ett namn som aldrig fanns i adressfältet. Den luckan är hela problemet: sidan kom från en URL, och tjänsten formaterade nästa begäran från en annan. Den publicerade URL:en är ett beslut på serversidan, så att rätta den på klienten är fel ände. Kontrollera vilket namn tjänsten returnerar innan du rör DNS eller rutter.
Den första sidan och nästa begäran använder olika namn
En användare som når servern via adressen ser en fungerande startsida. Dokumentlänkarna på den sidan genereras från den URL som tjänsten tror att den publicerar, inte från det webbläsaren skrev. Om de skiljer sig går nästa klick till ett namn som klienten aldrig har slagit upp.
Att ange adressen en gång reparerar inte varje genererad länk, och ett bokmärke till adressen döljer problemet tills ett dokument öppnas.
Det här felet läses lätt fel som ett VPN-problem eftersom det bara visas när tunneln används. I praktiken gör tunneln sitt jobb: den bär begäran till ett namn som saknar fungerande väg eller saknar matchande certifikat. Separera de två frågorna innan du ändrar någon av dem. Den ena är vart paketet tar vägen, den andra är vilket namn tjänsten valde att publicera.
Fyra kontroller, ett namn
Varje publicerat namn måste klara fyra oberoende kontroller. DNS måste slå upp det för den faktiska klienten, routning och åtkomstpolicy måste tillåta vägen, TLS måste validera för det namnet, och tjänsten måste vara konfigurerad att publicera det.
En ändring i en kontroll utför inte de andra. Att acceptera en certifikatvarning är inte en reparation av namnmatchningen.
Tabellen nedan är checklistans ordning. Stanna vid den första raden som misslyckas, eftersom en senare rättelse inte kan kompensera en tidigare lucka.
| 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 innan du ändrar den
SharePoint Server-installationer skiljer sig åt. Klassiska webbapplikationer kan använda alternativa åtkomstmappningar, där en intern URL är det servern tar emot och en offentlig URL är det den använder för att formatera länkar. Värdsnamnade webbplatssamlingar följer en annan metod och kan enligt Microsofts vägledning inte använda AAM.
Microsofts planeringsvägledning markerar också AAM-funktioner som föråldrade och rekommenderar värdsnamnade webbplatssamlingar för ny planering. Det gör distributionsmodellen till en fråga för ägaren, inte en standard som du lappar.
Fastställ vilken modell som används innan du föreslår en mappningsändring. Att lägga till en AAM-post i en värdsnamnad distribution gör ingenting, och att lägga till en i en klassisk distribution ändrar varje returnerad länk på en gång. Båda är konfigurationsändringar med stor påverkan, så förbered dem i steg och behåll en återställningsplan. Det här är ingen rekommendation att införa gamla mappningar i en modern miljö.
Följ den misslyckade åtgärden, inte startsidan
Anteckna målet som den misslyckade begäran faktiskt använde, klientapplikationen, tiden och felet. En webbläsare och en skrivbordsapplikation kan ta olika proxy-, VPN- eller autentiseringsvägar till samma dokument.
Webbläsaren kan lyckas medan Office-klienten misslyckas, och den skillnaden är en ledtråd till vilken kontext som slår upp namnet.
Om URL:en och nätverksöverlämningen båda fungerar och tjänsten ändå avvisar åtgärden, ligger det kvarvarande problemet på applikationsnivå. Dokumentbehörigheter och incheckningsstatus tillhör tjänstens ägare, och en VPN-rutt ger anslutning, inte behörighet.
Kontrollera överlämningen från början till slut
Kör kontrollerna i ordning på klienten som misslyckas: slå upp det publicerade namnet, begär sidan med det namnet och begär sedan dokumentets URL från sidans källa. Varje steg isolerar en kontroll.
Tre kommandon täcker uppslagning, TLS och dokumentvägen:
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.aspxOm uppslagningen bara misslyckas genom tunneln är split-DNS-policyn den misstänkta. Om TLS misslyckas, jämför certifikatets namn med det publicerade namnet i stället för att klicka igenom. Om båda lyckas och dokumentet fortfarande misslyckas, handlar felet inte längre om URL:en.