SharePoint-links breken via VPN door gepubliceerde URL's

Een SharePoint-pagina opent via de VPN, en de eerste documentlink mislukt met een naam die nooit in de adresbalk stond. Dat gat is het hele probleem: de pagina kwam van de ene URL, en de dienst formatteerde het volgende verzoek vanuit een andere. De gepubliceerde URL is een beslissing aan de serverkant, dus het op de client repareren is het verkeerde uiteinde. Controleer welke naam de dienst teruggeeft voordat u DNS of routes aanraakt.

De eerste pagina en het volgende verzoek gebruiken verschillende namen

Een gebruiker die de server via het adres bereikt, ziet een werkende startpagina. De documentlinks op die pagina worden gegenereerd uit de URL die de dienst denkt te publiceren, niet uit wat de browser heeft getypt. Als die verschillen, gaat de volgende klik naar een naam die de client nooit heeft geresolved.

Het adres één keer invoeren repareert niet elke gegenereerde link, en een bladwijzer naar het adres verbergt het probleem tot een document wordt geopend.

Deze fout wordt gemakkelijk verkeerd gelezen als een VPN-probleem omdat hij pas verschijnt als de tunnel in gebruik is. In de praktijk doet de tunnel zijn werk: hij draagt het verzoek naar een naam zonder werkend pad of zonder passend certificaat. Scheid de twee vragen voordat u een van beide wijzigt. De ene is waar het pakket heen gaat, de andere is welke naam de dienst heeft gekozen te publiceren.

Vier controles, één naam

Elke gepubliceerde naam moet vier onafhankelijke controles doorstaan. DNS moet hem voor de werkelijke client resolven, routing en toegangsbeleid moeten het pad toestaan, TLS moet voor die naam valideren, en de dienst moet geconfigureerd zijn om hem te publiceren.

Een wijziging aan één controle voert de andere niet uit. Een certificaatwaarschuwing accepteren is geen reparatie van naamresolutie.

De tabel hieronder is de volgorde van de checklist. Stop bij de eerste rij die faalt, want een latere correctie kan een eerder gat niet compenseren.

Lees het publicatiemodel voordat u het wijzigt

SharePoint Server-implementaties verschillen. Klassieke webtoepassingen kunnen alternatieve toegangstoewijzingen gebruiken, waarbij een interne URL is wat de server ontvangt en een openbare URL is wat hij gebruikt om links te formatteren. Hostnaam-sitepassingsverzamelingen volgen een andere aanpak en kunnen volgens de richtlijnen van Microsoft geen AAM gebruiken.

De planningsrichtlijnen van Microsoft markeren AAM-functies ook als verouderd en raden hostnaam-sitepassingsverzamelingen aan voor nieuwe planning. Dat maakt het implementatiemodel een vraag voor de eigenaar, niet een standaard die u zelf aanscherpt.

Stel vast welk model in gebruik is voordat u een toewijzingswijziging voorstelt. Een AAM-vermelding toevoegen aan een hostnaam-implementatie doet niets, en er één toevoegen aan een klassieke implementatie verandert elke teruggegeven link tegelijk. Beide zijn configuratiewijzigingen met een brede impact, dus bereid ze in fasen voor en houd een terugdraaiplan aan. Dit is geen aanbeveling om oude toewijzingen in een moderne omgeving in te voeren.

Volg de mislukte bewerking, niet de startpagina

Noteer het doel dat het mislukte verzoek daadwerkelijk gebruikte, de clienttoepassing, de tijd en de fout. Een browser en een desktoptoepassing kunnen verschillende proxy-, VPN- of authenticatieroutes naar hetzelfde document nemen.

De browser kan slagen terwijl de Office-client faalt, en dat verschil is een aanwijzing welke context de naam resolvet.

Als de URL en de netwerkoverdracht beide werken en de dienst de bewerking nog steeds weigert, is het resterende probleem op applicatieniveau. Documentmachtigingen en de uitcheckstatus horen bij de diensteigenaar, en een VPN-route levert connectiviteit, geen toestemming.

Controleer de overdracht van begin tot eind

Voer de controles in volgorde uit op de client die faalt: resolve de gepubliceerde naam, vraag de pagina met die naam aan, en vraag daarna de document-URL uit de paginabron aan. Elke stap isoleert één controle.

Drie opdrachten dekken resolutie, TLS en het documentpad:

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

Als de resolutie alleen via de tunnel faalt, is het split-DNS-beleid de verdachte. Als TLS faalt, vergelijk dan de certificaatnaam met de gepubliceerde naam in plaats van erdoorheen te klikken. Als beide slagen en het document faalt nog steeds, gaat de fout niet meer over de URL.