Les liens SharePoint se cassent via le VPN à cause des URL publiées

Une page SharePoint s'ouvre via le VPN, et le premier lien de document échoue avec un nom qui n'a jamais été dans la barre d'adresse. Cet écart est tout le problème : la page venait d'une URL, et le service a formaté la requête suivante à partir d'une autre. L'URL publiée est une décision côté serveur, donc la corriger sur le client est le mauvais bout. Vérifiez quel nom le service renvoie avant de toucher au DNS ou aux routes.

La première page et la requête suivante utilisent des noms différents

Un utilisateur qui atteint le serveur par l'adresse voit une page d'accueil fonctionnelle. Les liens de documents de cette page sont générés à partir de l'URL que le service croit publier, et non de ce que le navigateur a saisi. S'ils diffèrent, le clic suivant va vers un nom que le client n'a jamais résolu.

Saisir l'adresse une fois ne répare pas chaque lien généré, et un favori vers l'adresse masque le problème jusqu'à l'ouverture d'un document.

Cet échec se lit facilement à tort comme un problème de VPN parce qu'il n'apparaît qu'une fois le tunnel utilisé. En pratique, le tunnel fait son travail : il transporte la requête vers un nom qui n'a pas de chemin fonctionnel ou pas de certificat correspondant. Séparez les deux questions avant de changer l'une ou l'autre. L'une est où va le paquet, l'autre est quel nom le service a choisi de publier.

Quatre contrôles, un nom

Chaque nom publié doit passer quatre contrôles indépendants. Le DNS doit le résoudre pour le client réel, le routage et la politique d'accès doivent autoriser le chemin, le TLS doit valider ce nom, et le service doit être configuré pour le publier.

Une modification d'un contrôle n'exécute pas les autres. Accepter un avertissement de certificat n'est pas une réparation de la résolution de nom.

Le tableau ci-dessous donne l'ordre de la liste de vérification. Arrêtez-vous à la première ligne qui échoue, car une correction ultérieure ne compense pas un manque antérieur.

Lisez le modèle de publication avant de le modifier

Les déploiements SharePoint Server diffèrent. Les applications web classiques peuvent utiliser des mappages d'accès alternatifs, où une URL interne est ce que le serveur reçoit et une URL publique ce qu'il utilise pour formater les liens. Les collections de sites nommées par hôte suivent une autre approche et, selon les recommandations de Microsoft, ne peuvent pas utiliser AAM.

Les recommandations de planification de Microsoft marquent aussi les fonctionnalités AAM comme obsolètes et préconisent les collections de sites nommées par hôte pour les nouvelles planifications. Cela fait du modèle de déploiement une question pour son propriétaire, pas un réglage par défaut que vous corrigez.

Établissez quel modèle est utilisé avant de proposer un changement de mappage. Ajouter une entrée AAM à un déploiement nommé par hôte ne fait rien, et en ajouter une à un déploiement classique change tous les liens renvoyés d'un coup. Les deux sont des changements de configuration à fort impact, préparez-les par étapes et gardez un plan de retour arrière. Ce n'est pas une recommandation d'introduire des mappages hérités dans un environnement moderne.

Suivez l'opération en échec, pas la page d'accueil

Notez la destination que la requête en échec a réellement utilisée, l'application cliente, l'heure et l'erreur. Un navigateur et une application de bureau peuvent emprunter des chemins différents via proxy, VPN ou authentification vers le même document.

Le navigateur peut réussir alors que le client Office échoue, et cette différence indique quel contexte résout le nom.

Si l'URL et la remise réseau fonctionnent et que le service rejette encore l'opération, le problème restant se situe au niveau de l'application. Les autorisations de document et l'état de réservation appartiennent au propriétaire du service, et une route VPN fournit la connectivité, pas l'autorisation.

Vérifiez la remise de bout en bout

Exécutez les vérifications dans l'ordre sur le client qui échoue : résolvez le nom publié, demandez la page sous ce nom, puis demandez l'URL du document depuis la source de la page. Chaque étape isole un contrôle.

Trois commandes couvrent la résolution, le TLS et le chemin du 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 résolution échoue uniquement par le tunnel, la politique de split-DNS est la suspecte. Si le TLS échoue, comparez le nom du certificat avec le nom publié au lieu de cliquer pour continuer. Si les deux réussissent et que le document échoue encore, l'erreur ne concerne plus l'URL.