SharePoint-skakels breek oor VPN weens gepubliseerde URL's
'n SharePoint-bladsy wat oor VPN laai, kan steeds dokument-skakels teruggee op 'n naam wat jou kliënt nie kan oplos nie. Kontroleer DNS, roete, TLS en die gepubliseerde URL.
'n SharePoint-bladsy open deur die VPN, en die eerste dokument-skakel misluk met 'n naam wat nooit in die adresbalk was nie. Dié gaping is die hele probleem: die bladsy het van een URL gekom, en die diens het die volgende versoek van 'n ander een geformateer. Die gepubliseerde URL is 'n besluit aan die bedienerkant, so om dit op die kliënt reg te maak is die verkeerde kant. Kyk watter naam die diens teruggee voordat jy aan DNS of roetes raak.
Die eerste bladsy en die volgende versoek gebruik verskillende name
'n Gebruiker wat die bediener per adres bereik, sien 'n werkende tuisblad. Die dokument-skakels op daardie bladsy word gegenereer uit die URL wat die diens dink hy publiseer, nie uit wat die blaaier ingetik het nie. As dié verskil, gaan die volgende klik na 'n naam wat die kliënt nog nooit opgelos het nie.
Om die adres een keer in te tik herstel nie elke gegenereerde skakel nie, en 'n boekmerk na die adres verberg die probleem totdat 'n dokument oopgemaak word.
Die fout word maklik verkeerd gelees as 'n VPN-probleem, want dit verskyn eers nadat die tonnel in gebruik is. In die praktyk doen die tonnel sy werk: dit dra die versoek na 'n naam met geen werkende pad of geen passende sertifikaat nie. Skei die twee vrae voordat jy enigeen verander. Een is waar die pakkie heen gaan, die ander is watter naam die diens gekies het om te publiseer.
Vier kontroles, een naam
Elke gepubliseerde naam moet vier onafhanklike kontroles deurkom. DNS moet dit vir die werklike kliënt oplos, roetering en toegangsbeleid moet die pad toelaat, TLS moet vir daardie naam valideer, en die diens moet gekonfigureer wees om dit te publiseer.
'n Verandering aan een kontrole verrig nie die ander nie. Om 'n sertifikaatwaarskuwing te aanvaar is nie 'n herstel van naamoplossing nie.
Die tabel hieronder is die kontrolelysorde. Stop by die eerste ry wat misluk, want 'n latere regstelling kan nie 'n vroeëre gaping vergoed nie.
| 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 |
Lees die publikasiemodel voordat jy dit verander
SharePoint Server-ontplooiings verskil. Klassieke webtoepassings kan alternatiewe toegangskarterings gebruik, waar 'n interne URL is wat die bediener ontvang en 'n publieke URL is wat hy gebruik om skakels te formateer. Gasheernaam-genoemde werfversamelings volg 'n ander benadering en kan volgens Microsoft se leiding nie AAM gebruik nie.
Microsoft se beplanningsleiding merk ook AAM-kenmerke as afgeskaf en beveel gasheernaam-genoemde werfversamelings vir nuwe beplanning aan. Dit maak die ontplooiingsmodel 'n vraag vir sy eienaar, nie 'n verstekwaarde wat jy self aanpas nie.
Stel vas watter model in gebruik is voordat jy 'n karteringsverandering voorstel. Om 'n AAM-inskrywing by 'n gasheernaam-ontplooiing te voeg, doen niks, en om een by 'n klassieke ontplooiing te voeg, verander elke teruggekeerde skakel gelyktydig. Albei is konfigurasieveranderinge met 'n groot impak, so berei hulle in fases voor en hou 'n terugrol. Dit is nie 'n aanbeveling om ou karterings in 'n moderne omgewing in te bring nie.
Volg die mislukte bewerking, nie die tuisblad nie
Teken die bestemming aan wat die mislukte versoek werklik gebruik het, die kliënttoepassing, die tyd en die fout. 'n Blaaier en 'n lessenaartoepassing kan verskillende gevolmagtigde, VPN- of verifikasiepades na dieselfde dokument volg.
Die blaaier kan slaag terwyl die Office-kliënt misluk, en daardie verskil is 'n leidraad oor watter konteks die naam oplos.
As die URL en die netwerkoordrag albei werk en die diens verwerp steeds die bewerking, is die oorblywende probleem op toepassingsvlak. Dokumenttoestemmings en die uitgebetaalstatus behoort aan die dienseienaar, en 'n VPN-roete verskaf verbinding eerder as toestemming.
Kontroleer die oordrag van begin tot end
Voer die kontroles in volgorde uit op die kliënt wat misluk: los die gepubliseerde naam op, versoek die bladsy met daardie naam, versoek dan die dokument-URL uit die bladsybron. Elke stap isoleer een kontrole.
Drie opdragte dek oplossing, TLS en die dokumentpad:
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.aspxAs oplossing net deur die tonnel misluk, is die split-DNS-beleid die verdagte. As TLS misluk, vergelyk die sertifikaatnaam met die gepubliseerde naam eerder as om deur te klik. As albei slaag en die dokument misluk steeds, gaan die fout nie meer oor die URL nie.