As ligazóns de SharePoint rompen pola VPN debido ás URL publicadas

Unha páxina de SharePoint ábrese pola VPN, e a primeira ligazón de documento falla cun nome que nunca estivo na barra de enderezos. Esa fenda é todo o problema: a páxina veu dunha URL, e o servizo formatou a seguinte solicitude desde outra. A URL publicada é unha decisión do lado do servidor, así que arranxala no cliente é o extremo equivocado. Comprobe que nome devolve o servizo antes de tocar o DNS ou as rutas.

A primeira páxina e a seguinte solicitude usan nomes distintos

Un usuario que chega ao servidor polo enderezo ve unha páxina de inicio que funciona. As ligazóns de documentos desa páxina xéranse a partir da URL que o servizo cre que publica, non do que escribiu o navegador. Se difiren, o seguinte clic vai a un nome que o cliente nunca resolveu.

Escribir o enderezo unha vez non arranxa todas as ligazóns xeradas, e un marcador ao enderezo agocha o problema ata que se abre un documento.

Este fallo malinterprétase doadamente como un problema de VPN porque só aparece cando o túnel está en uso. Na práctica o túnel fai o seu traballo: leva a solicitude a un nome que non ten ruta operativa nin certificado coincidente. Separe as dúas preguntas antes de cambiar calquera delas. Unha é a onde vai o paquete, a outra é que nome escolleu publicar o servizo.

Catro controis, un nome

Cada nome publicado debe pasar catro controis independentes. O DNS debe resolvelo para o cliente real, o encamiñamento e a política de acceso deben permitir a ruta, o TLS debe validar ese nome, e o servizo debe estar configurado para publicalo.

Un cambio nun control non realiza os demais. Aceptar un aviso de certificado non é unha reparación da resolución de nomes.

A táboa de abaixo é a orde da lista de comprobación. Detéñase na primeira fila que falla, porque unha corrección posterior non pode compensar unha fenda anterior.

Lea o modelo de publicación antes de cambialo

Os despregamentos de SharePoint Server difiren. As aplicacións web clásicas poden usar asignacións de acceso alternativas, onde unha URL interna é o que recibe o servidor e unha URL pública é o que usa para formatar as ligazóns. As coleccións de sitios con nome de host seguen outro enfoque e, segundo as directrices de Microsoft, non poden usar AAM.

As directrices de planificación de Microsoft tamén marcan as funcións de AAM como obsoletas e recomendan coleccións de sitios con nome de host para a planificación nova. Iso converte o modelo de despregamento nunha pregunta para o seu propietario, non nun valor predeterminado que vostede parchee.

Estableza que modelo se usa antes de propoñer un cambio de asignación. Engadir unha entrada AAM a un despregamento con nome de host non fai nada, e engadir unha a un despregamento clásico cambia todas as ligazóns devoltas á vez. Ambos son cambios de configuración cun impacto amplo, así que prepáreos por etapas e manteña un plan de reversión. Esta non é unha recomendación de introducir asignacións antigas nunha contorna moderna.

Siga a operación fallida, non a páxina de inicio

Rexiste o destino que a solicitude fallida usou realmente, a aplicación cliente, a hora e o erro. Un navegador e unha aplicación de escritorio poden tomar camiños distintos de proxy, VPN ou autenticación cara ao mesmo documento.

O navegador pode ter éxito mentres o cliente de Office falla, e esa diferenza é unha pista sobre que contexto resolve o nome.

Se a URL e a entrega de rede funcionan e o servizo segue rexeitando a operación, o problema restante é de nivel de aplicación. Os permisos de documentos e o estado de pagamento pertencen ao propietario do servizo, e unha ruta VPN fornece conectividade, non permiso.

Comprobe a entrega de extremo a extremo

Executen as comprobacións por orde no cliente que falla: resolva o nome publicado, solicite a páxina con ese nome, e despois solicite a URL do documento desde o código fonte da páxina. Cada paso illa un control.

Tres comandos cobren a resolución, o TLS e a ruta do documento:

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

Se a resolución falla só a través do túnel, a política de split-DNS é a sospeitosa. Se falla o TLS, compare o nome do certificado co nome publicado en lugar de facer clic para continuar. Se ambos teñen éxito e o documento segue fallando, o erro xa non se trata da URL.