I collegamenti di SharePoint si rompono in VPN a causa degli URL pubblicati

Una pagina di SharePoint si apre tramite la VPN e il primo collegamento a un documento fallisce con un nome che non è mai stato nella barra degli indirizzi. Quel divario è tutto il problema: la pagina è arrivata da un URL e il servizio ha formattato la richiesta successiva da un altro. L'URL pubblicato è una decisione lato server, quindi correggerlo sul client è il capo sbagliato. Verificate quale nome restituisce il servizio prima di toccare DNS o route.

La prima pagina e la richiesta successiva usano nomi diversi

Un utente che raggiunge il server tramite l'indirizzo vede una pagina iniziale funzionante. I collegamenti ai documenti di quella pagina sono generati dall'URL che il servizio ritiene di pubblicare, non da quello digitato nel browser. Se differiscono, il clic successivo va a un nome che il client non ha mai risolto.

Digitare l'indirizzo una volta non ripara ogni collegamento generato, e un segnalibro all'indirizzo nasconde il problema finché non si apre un documento.

Questo errore viene facilmente frainteso come problema VPN perché compare solo dopo l'uso del tunnel. In pratica il tunnel fa il suo lavoro: porta la richiesta a un nome che non ha un percorso funzionante o un certificato corrispondente. Separate le due domande prima di cambiare l'una o l'altra. Una è dove va il pacchetto, l'altra è quale nome il servizio ha scelto di pubblicare.

Quattro controlli, un nome

Ogni nome pubblicato deve superare quattro controlli indipendenti. Il DNS deve risolverlo per il client reale, l'instradamento e la policy di accesso devono consentire il percorso, TLS deve convalidare quel nome e il servizio deve essere configurato per pubblicarlo.

Una modifica a un controllo non esegue gli altri. Accettare un avviso di certificato non è una riparazione della risoluzione dei nomi.

La tabella sotto è l'ordine della lista di controllo. Fermatevi alla prima riga che fallisce, perché una correzione successiva non compensa una lacuna precedente.

Leggete il modello di pubblicazione prima di modificarlo

Le distribuzioni di SharePoint Server differiscono. Le applicazioni Web classiche possono usare mappature di accesso alternative, dove un URL interno è ciò che riceve il server e un URL pubblico è ciò che usa per formattare i collegamenti. Le raccolte siti con nome host seguono un approccio diverso e, secondo le indicazioni di Microsoft, non possono usare AAM.

Le indicazioni di pianificazione di Microsoft segnalano anche le funzionalità AAM come obsolete e consigliano raccolte siti con nome host per le nuove pianificazioni. Ciò rende il modello di distribuzione una domanda per il suo proprietario, non un valore predefinito da correggere.

Stabilite quale modello è in uso prima di proporre una modifica di mappatura. Aggiungere una voce AAM a una distribuzione con nome host non fa nulla, e aggiungerne una a una distribuzione classica cambia tutti i collegamenti restituiti in una volta. Entrambe sono modifiche di configurazione con un impatto ampio, quindi preparatele per fasi e tenete un piano di rollback. Non è una raccomandazione a introdurre mappature legacy in un ambiente moderno.

Seguite l'operazione fallita, non la pagina iniziale

Registrate la destinazione che la richiesta fallita ha effettivamente usato, l'applicazione client, l'ora e l'errore. Un browser e un'applicazione desktop possono seguire percorsi diversi tramite proxy, VPN o autenticazione verso lo stesso documento.

Il browser può riuscire mentre il client Office fallisce, e quella differenza è un indizio su quale contesto risolve il nome.

Se l'URL e la consegna di rete funzionano e il servizio rifiuta ancora l'operazione, il problema rimanente è a livello di applicazione. Le autorizzazioni sui documenti e lo stato di check-out appartengono al proprietario del servizio, e una route VPN fornisce connettività, non autorizzazione.

Verificate la consegna da un capo all'altro

Eseguite i controlli in ordine sul client che fallisce: risolvete il nome pubblicato, richiedete la pagina con quel nome, poi richiedete l'URL del documento dal codice sorgente della pagina. Ogni passo isola un controllo.

Tre comandi coprono risoluzione, TLS e percorso 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

Se la risoluzione fallisce solo attraverso il tunnel, la policy di split-DNS è la sospetta. Se fallisce TLS, confrontate il nome del certificato con il nome pubblicato invece di cliccare per proseguire. Se entrambi riescono e il documento fallisce ancora, l'errore non riguarda più l'URL.