Os links do SharePoint quebram na VPN por causa dos URL publicados

Uma página do SharePoint abre pela VPN, e o primeiro link de documento falha com um nome que nunca esteve na barra de endereços. Essa lacuna é todo o problema: a página veio de um URL, e o serviço formatou o pedido seguinte a partir de outro. O URL publicado é uma decisão do lado do servidor, portanto corrigi-lo no cliente é o lado errado. Verifique que nome o serviço devolve antes de tocar no DNS ou nas rotas.

A primeira página e o pedido seguinte usam nomes diferentes

Um utilizador que chega ao servidor pelo endereço vê uma página inicial a funcionar. Os links de documentos dessa página são gerados a partir do URL que o serviço julga estar a publicar, não do que o navegador escreveu. Se forem diferentes, o clique seguinte vai para um nome que o cliente nunca resolveu.

Introduzir o endereço uma vez não corrige todos os links gerados, e um marcador para o endereço esconde o problema até um documento ser aberto.

Esta falha é facilmente mal interpretada como um problema de VPN porque só aparece depois de o túnel estar em uso. Na prática o túnel faz o seu trabalho: leva o pedido a um nome que não tem caminho funcional nem certificado correspondente. Separe as duas perguntas antes de mudar qualquer uma. Uma é para onde vai o pacote, a outra é que nome o serviço escolheu publicar.

Quatro controlos, um nome

Cada nome publicado tem de passar quatro controlos independentes. O DNS tem de o resolver para o cliente real, o encaminhamento e a política de acesso têm de permitir o caminho, o TLS tem de validar esse nome, e o serviço tem de estar configurado para o publicar.

Uma alteração num controlo não executa os outros. Aceitar um aviso de certificado não é uma reparação da resolução de nomes.

A tabela abaixo é a ordem da lista de verificação. Pare na primeira linha que falhar, porque uma correção posterior não compensa uma lacuna anterior.

Leia o modelo de publicação antes de o alterar

As implementações do SharePoint Server diferem. As aplicações Web clássicas podem usar mapeamentos de acesso alternativos, em que um URL interno é o que o servidor recebe e um URL público é o que usa para formatar os links. As coleções de sites com nome de anfitrião seguem outra abordagem e, segundo as orientações da Microsoft, não podem usar AAM.

As orientações de planeamento da Microsoft também marcam as funcionalidades AAM como obsoletas e recomendam coleções de sites com nome de anfitrião para novo planeamento. Isso torna o modelo de implementação uma pergunta para o seu proprietário, não um valor predefinido que você remenda.

Estabeleça que modelo está em uso antes de propor uma alteração de mapeamento. Acrescentar uma entrada AAM a uma implementação com nome de anfitrião não faz nada, e acrescentar uma a uma implementação clássica altera todos os links devolvidos de uma vez. Ambos são alterações de configuração com grande impacto, por isso prepare-as por fases e mantenha um plano de reversão. Isto não é uma recomendação para introduzir mapeamentos antigos num ambiente moderno.

Siga a operação falhada, não a página inicial

Registe o destino que o pedido falhado realmente usou, a aplicação cliente, a hora e o erro. Um navegador e uma aplicação de ambiente de trabalho podem seguir caminhos diferentes de proxy, VPN ou autenticação até ao mesmo documento.

O navegador pode ter sucesso enquanto o cliente do Office falha, e essa diferença é uma pista sobre que contexto resolve o nome.

Se o URL e a entrega de rede funcionam e o serviço continua a rejeitar a operação, o problema restante é ao nível da aplicação. As permissões de documentos e o estado de pagamento pertencem ao proprietário do serviço, e uma rota VPN fornece conectividade, não permissão.

Verifique a entrega de ponta a ponta

Execute as verificações por ordem no cliente que falha: resolva o nome publicado, peça a página com esse nome e depois peça o URL do documento a partir do código-fonte da página. Cada passo isola um controlo.

Três comandos cobrem a resolução, o TLS e o caminho 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 resolução falhar apenas através do túnel, a política de split-DNS é a suspeita. Se o TLS falhar, compare o nome do certificado com o nome publicado em vez de clicar para continuar. Se ambos tiverem sucesso e o documento continuar a falhar, o erro já não é sobre o URL.