Linkurile SharePoint se rup prin VPN din cauza URL-urilor publicate

O pagină SharePoint se deschide prin VPN, iar primul link către un document eșuează cu un nume care nu a fost niciodată în bara de adrese. Acest gol este întreaga problemă: pagina a venit de la un URL, iar serviciul a format următoarea cerere de la altul. URL-ul publicat este o decizie pe partea serverului, așa că repararea lui pe client este capătul greșit. Verifică ce nume returnează serviciul înainte de a atinge DNS sau rutele.

Prima pagină și cererea următoare folosesc nume diferite

Un utilizator care ajunge la server prin adresă vede o pagină principală funcțională. Linkurile către documente din acea pagină sunt generate din URL-ul pe care serviciul crede că îl publică, nu din ce a tastat browserul. Dacă acestea diferă, următorul clic merge către un nume pe care clientul nu l-a rezolvat niciodată.

Introducerea adresei o singură dată nu repară fiecare link generat, iar un semn de carte către adresă ascunde problema până când se deschide un document.

Această eșuare este ușor de citit greșit ca problemă de VPN pentru că apare doar după ce tunelul este folosit. În practică tunelul își face treaba: duce cererea către un nume care nu are cale funcțională sau certificat potrivit. Separă cele două întrebări înainte de a schimba oricare dintre ele. Una este unde merge pachetul, cealaltă este ce nume a ales serviciul să publice.

Patru controale, un nume

Fiecare nume publicat trebuie să treacă de patru controale independente. DNS trebuie să îl rezolve pentru clientul real, rutarea și politica de acces trebuie să permită calea, TLS trebuie să valideze acel nume, iar serviciul trebuie să fie configurat să îl publice.

O modificare la un control nu le execută pe celelalte. Acceptarea unui avertisment de certificat nu este o reparare a rezolvării numelui.

Tabelul de mai jos este ordinea listei de verificare. Oprește-te la primul rând care eșuează, pentru că o corecție ulterioară nu poate compensa o lipsă anterioară.

Citește modelul de publicare înainte de a-l schimba

Implementările SharePoint Server diferă. Aplicațiile web clasice pot folosi mapări de acces alternative, în care un URL intern este ceea ce primește serverul, iar un URL public este ceea ce folosește pentru a formata linkurile. Colecțiile de site-uri cu nume de gazdă urmează o altă abordare și, conform îndrumărilor Microsoft, nu pot folosi AAM.

Îndrumările de planificare ale Microsoft marchează de asemenea funcțiile AAM ca învechite și recomandă colecții de site-uri cu nume de gazdă pentru planificare nouă. Asta face modelul de implementare o întrebare pentru proprietarul său, nu o valoare implicită pe care o petici.

Stabilește ce model este folosit înainte de a propune o modificare de mapare. Adăugarea unei intrări AAM la o implementare cu nume de gazdă nu face nimic, iar adăugarea uneia la o implementare clasică schimbă toate linkurile returnate deodată. Ambele sunt modificări de configurare cu impact larg, așa că pregătește-le în etape și păstrează un plan de revenire. Aceasta nu este o recomandare de a introduce mapări vechi într-un mediu modern.

Urmărește operațiunea eșuată, nu pagina principală

Notează destinația pe care cererea eșuată a folosit-o efectiv, aplicația client, ora și eroarea. Un browser și o aplicație desktop pot urma căi diferite prin proxy, VPN sau autentificare către același document.

Browserul poate reuși în timp ce clientul Office eșuează, iar această diferență este un indiciu despre ce context rezolvă numele.

Dacă URL-ul și predarea de rețea funcționează ambele și serviciul încă respinge operațiunea, problema rămasă este la nivel de aplicație. Permisiunile documentelor și starea de check-out aparțin proprietarului serviciului, iar o rută VPN oferă conectivitate, nu permisiune.

Verifică predarea de la un capăt la altul

Rulează verificările în ordine pe clientul care eșuează: rezolvă numele publicat, cere pagina cu acel nume, apoi cere URL-ul documentului din sursa paginii. Fiecare pas izolează un control.

Trei comenzi acoperă rezolvarea, TLS și calea documentului:

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

Dacă rezolvarea eșuează doar prin tunel, politica de split-DNS este suspecta. Dacă TLS eșuează, compară numele certificatului cu numele publicat în loc să dai clic mai departe. Dacă ambele reușesc și documentul tot eșuează, eroarea nu mai este despre URL.