Els enllaços de SharePoint es trenquen per VPN a causa de les URL publicades

Una pàgina de SharePoint s'obre per la VPN, i el primer enllaç de document falla amb un nom que mai no havia estat a la barra d'adreces. Aquest buit és tot el problema: la pàgina va venir d'una URL, i el servei va formatar la petició següent des d'una altra. L'URL publicada és una decisió del costat del servidor, així que arreglar-la al client és el costat equivocat. Comproveu quin nom retorna el servei abans de tocar el DNS o les rutes.

La primera pàgina i la petició següent fan servir noms diferents

Un usuari que arriba al servidor per adreça veu una pàgina d'inici que funciona. Els enllaços de documents d'aquella pàgina es generen a partir de l'URL que el servei creu que publica, no del que va escriure el navegador. Si difereixen, el clic següent va a un nom que el client mai no ha resolt.

Introduir l'adreça una vegada no arregla tots els enllaços generats, i una marca a l'adreça amaga el problema fins que s'obre un document.

Aquesta fallada es pot llegir malament com un problema de VPN perquè només apareix quan el túnel ja s'usa. En la pràctica el túnel fa la seva feina: porta la petició a un nom que no té cap camí operatiu o cap certificat coincident. Separeu les dues preguntes abans de canviar-ne cap. Una és on va el paquet, l'altra és quin nom el servei va triar publicar.

Quatre controls, un nom

Cada nom publicat ha de passar quatre controls independents. El DNS l'ha de resoldre per al client real, l'encaminament i la política d'accés han de permetre el camí, el TLS ha de validar aquell nom, i el servei ha d'estar configurat per publicar-lo.

Un canvi en un control no realitza els altres. Acceptar un avís de certificat no és una reparació de resolució de noms.

La taula de sota és l'ordre de la llista de verificació. Atureu-vos a la primera fila que falla, perquè una correcció posterior no pot compensar un buit anterior.

Llegiu el model de publicació abans de canviar-lo

Les implantacions de SharePoint Server difereixen. Les aplicacions web clàssiques poden fer servir mapes d'accés alternatius, on l'URL intern és el que rep el servidor i l'URL públic és el que fa servir per formatar els enllaços. Les col·leccions de llocs amb nom d'amfitrió segueixen un enfocament diferent i, segons les directrius de Microsoft, no poden fer servir AAM.

Les directrius de planificació de Microsoft també marquen les funcions AAM com a obsoletes i recomanen col·leccions de llocs amb nom d'amfitrió per a la planificació nova. Això converteix el model d'implantació en una pregunta per al seu propietari, no en un valor per defecte que vosaltres pedaceu.

Establiu quin model s'usa abans de proposar un canvi de mapatge. Afegir una entrada AAM a una implantació amb nom d'amfitrió no fa res, i afegir-ne una a una implantació clàssica canvia tots els enllaços retornats alhora. Tots dos són canvis de configuració amb un impacte ampli, així que prepareu-los per etapes i manteniu un pla de reversió. Aquesta no és una recomanació d'introduir mapatges antics en un entorn modern.

Seguiu l'operació fallida, no la pàgina d'inici

Registreu la destinació que la petició fallida va fer servir realment, l'aplicació client, l'hora i l'error. Un navegador i una aplicació d'escriptori poden seguir camins diferents de proxy, VPN o autenticació cap al mateix document.

El navegador pot tenir èxit mentre el client d'Office falla, i aquesta diferència és una pista sobre quin context resol el nom.

Si l'URL i el lliurament de xarxa funcionen i el servei encara rebutja l'operació, el problema restant és a nivell d'aplicació. Els permisos de documents i l'estat de pagament pertanyen al propietari del servei, i una ruta VPN proporciona connectivitat, no permís.

Comproveu el lliurament d'extrem a extrem

Executeu les comprovacions en ordre al client que falla: resoleu el nom publicat, sol·liciteu la pàgina amb aquell nom, i després sol·liciteu l'URL del document des del codi font de la pàgina. Cada pas aïlla un control.

Tres ordres cobreixen la resolució, el TLS i el camí del document:

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

Si la resolució falla només a través del túnel, la sospitosa és la política de split-DNS. Si falla el TLS, compareu el nom del certificat amb el nom publicat en lloc de clicar per continuar. Si tots dos tenen èxit i el document encara falla, l'error ja no és sobre l'URL.