Los enlaces de SharePoint fallan por VPN debido a las URL publicadas

Una página de SharePoint se abre por la VPN y el primer enlace de documento falla con un nombre que nunca estuvo en la barra de direcciones. Ese hueco es todo el problema: la página vino de una URL y el servicio formateó la siguiente solicitud desde otra. La URL publicada es una decisión del lado del servidor, así que arreglarla en el cliente es el extremo equivocado. Compruebe qué nombre devuelve el servicio antes de tocar DNS o rutas.

La primera página y la siguiente solicitud usan nombres distintos

Un usuario que llega al servidor por la dirección ve una página de inicio que funciona. Los enlaces de documentos de esa página se generan a partir de la URL que el servicio cree que publica, no de lo que escribió el navegador. Si difieren, el siguiente clic va a un nombre que el cliente nunca ha resuelto.

Escribir la dirección una vez no repara todos los enlaces generados, y un marcador a la dirección oculta el problema hasta que se abre un documento.

Este fallo se malinterpreta fácilmente como un problema de VPN porque solo aparece cuando el túnel está en uso. En la práctica el túnel hace su trabajo: lleva la solicitud a un nombre que no tiene ruta operativa ni certificado coincidente. Separe las dos preguntas antes de cambiar cualquiera de ellas. Una es adónde va el paquete, la otra es qué nombre eligió publicar el servicio.

Cuatro controles, un nombre

Cada nombre publicado debe pasar cuatro controles independientes. DNS debe resolverlo para el cliente real, el enrutamiento y la política de acceso deben permitir la ruta, TLS debe validar ese nombre, y el servicio debe estar configurado para publicarlo.

Un cambio en un control no realiza los demás. Aceptar una advertencia de certificado no es una reparación de la resolución de nombres.

La tabla siguiente es el orden de la lista de comprobación. Deténgase en la primera fila que falle, porque una corrección posterior no puede compensar un hueco anterior.

Lea el modelo de publicación antes de cambiarlo

Las implementaciones de SharePoint Server difieren. Las aplicaciones web clásicas pueden usar asignaciones de acceso alternativas, donde una URL interna es lo que recibe el servidor y una URL pública es lo que usa para dar formato a los enlaces. Las colecciones de sitios con nombre de host siguen otro enfoque y, según las directrices de Microsoft, no pueden usar AAM.

Las directrices de planificación de Microsoft también marcan las funciones de AAM como obsoletas y recomiendan colecciones de sitios con nombre de host para la planificación nueva. Eso convierte el modelo de implementación en una pregunta para su propietario, no en un valor predeterminado que usted parchee.

Establezca qué modelo se usa antes de proponer un cambio de asignación. Añadir una entrada de AAM a una implementación con nombre de host no hace nada, y añadir una a una implementación clásica cambia todos los enlaces devueltos a la vez. Ambos son cambios de configuración con un impacto amplio, así que prepárelos por etapas y mantenga un plan de reversión. Esta no es una recomendación de introducir asignaciones antiguas en un entorno moderno.

Siga la operación fallida, no la página de inicio

Registre el destino que realmente usó la solicitud fallida, la aplicación cliente, la hora y el error. Un navegador y una aplicación de escritorio pueden tomar rutas distintas de proxy, VPN o autenticación hacia el mismo documento.

El navegador puede tener éxito mientras el cliente de Office falla, y esa diferencia es una pista sobre qué contexto resuelve el nombre.

Si la URL y el traspaso de red funcionan y el servicio sigue rechazando la operación, el problema restante es de nivel de aplicación. Los permisos de documentos y el estado de pago pertenecen al propietario del servicio, y una ruta VPN proporciona conectividad, no permiso.

Compruebe el traspaso de extremo a extremo

Ejecute las comprobaciones en orden en el cliente que falla: resuelva el nombre publicado, solicite la página con ese nombre y luego solicite la URL del documento desde el código fuente de la página. Cada paso aísla un control.

Tres comandos cubren la resolución, TLS y la ruta del 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

Si la resolución falla solo a través del túnel, la política de split-DNS es la sospechosa. Si falla TLS, compare el nombre del certificado con el nombre publicado en lugar de hacer clic para continuar. Si ambos tienen éxito y el documento sigue fallando, el error ya no se trata de la URL.