Linki SharePoint przestają działać przez VPN z powodu opublikowanych adresów URL

Strona SharePoint otwiera się przez VPN, a pierwszy link do dokumentu zawodzi pod nazwą, której nigdy nie było na pasku adresu. Ta luka to cały problem: strona przyszła z jednego adresu URL, a usługa sformatowała kolejne żądanie z innego. Opublikowany adres URL jest decyzją po stronie serwera, więc naprawianie go na kliencie to niewłaściwy koniec. Sprawdź, jaką nazwę zwraca usługa, zanim dotkniesz DNS lub tras.

Pierwsza strona i kolejne żądanie używają różnych nazw

Użytkownik, który dociera do serwera przez adres, widzi działającą stronę główną. Linki do dokumentów na tej stronie są generowane z adresu URL, który usługa uważa za publikowany, a nie z tego, co wpisała przeglądarka. Jeśli się różnią, następne kliknięcie prowadzi do nazwy, której klient nigdy nie rozwiązał.

Jednorazowe wpisanie adresu nie naprawia każdego wygenerowanego linku, a zakładka do adresu ukrywa problem do momentu otwarcia dokumentu.

Ten błąd łatwo odczytać niewłaściwie jako problem z VPN, bo pojawia się dopiero po użyciu tunelu. W praktyce tunel wykonuje swoją pracę: przenosi żądanie do nazwy, która nie ma działającej ścieżki lub pasującego certyfikatu. Oddziel oba pytania, zanim zmienisz którekolwiek. Jedno dotyczy tego, dokąd idzie pakiet, drugie tego, którą nazwę usługa wybrała do publikacji.

Cztery kontrole, jedna nazwa

Każda opublikowana nazwa musi przejść cztery niezależne kontrole. DNS musi ją rozwiązać dla rzeczywistego klienta, routing i polityka dostępu muszą dopuścić ścieżkę, TLS musi zweryfikować tę nazwę, a usługa musi być skonfigurowana do jej publikowania.

Zmiana jednej kontroli nie wykonuje pozostałych. Zaakceptowanie ostrzeżenia o certyfikacie nie jest naprawą rozwiązywania nazw.

Tabela poniżej to kolejność listy kontrolnej. Zatrzymaj się na pierwszym wierszu, który zawodzi, bo późniejsza poprawka nie zrekompensuje wcześniejszej luki.

Przeczytaj model publikacji, zanim go zmienisz

Wdrożenia SharePoint Server różnią się. Klasyczne aplikacje internetowe mogą używać alternatywnych mapowań dostępu, gdzie wewnętrzny adres URL jest tym, co odbiera serwer, a publiczny adres URL tym, czego używa do formatowania linków. Kolekcje witryn z nazwą hosta stosują inne podejście i zgodnie ze wskazówkami Microsoftu nie mogą używać AAM.

Wskazówki dotyczące planowania Microsoftu oznaczają też funkcje AAM jako przestarzałe i zalecają kolekcje witryn z nazwą hosta do nowego planowania. To czyni model wdrożenia pytaniem do jego właściciela, a nie domyślnym ustawieniem, które łatasz.

Ustal, który model jest używany, zanim zaproponujesz zmianę mapowania. Dodanie wpisu AAM do wdrożenia z nazwą hosta nic nie robi, a dodanie jednego do wdrożenia klasycznego zmienia wszystkie zwracane linki naraz. Oba są zmianami konfiguracji o szerokim wpływie, więc przygotuj je etapami i utrzymuj plan wycofania. To nie jest zalecenie wprowadzania starych mapowań do nowoczesnego środowiska.

Śledź nieudaną operację, a nie stronę główną

Zapisz cel, którego faktycznie użyło nieudane żądanie, aplikację klienta, czas i błąd. Przeglądarka i aplikacja desktopowa mogą przejść różne ścieżki przez proxy, VPN lub uwierzytelnianie do tego samego dokumentu.

Przeglądarka może odnieść sukces, podczas gdy klient Office zawodzi, a ta różnica jest wskazówką, który kontekst rozwiązuje nazwę.

Jeśli adres URL i przekazanie sieciowe oba działają, a usługa nadal odrzuca operację, pozostały problem jest na poziomie aplikacji. Uprawnienia do dokumentów i stan wyewidencjonowania należą do właściciela usługi, a trasa VPN zapewnia łączność, nie uprawnienie.

Sprawdź przekazanie od początku do końca

Wykonaj kontrole po kolei na kliencie, który zawodzi: rozwiąż opublikowaną nazwę, zażądaj strony pod tą nazwą, a następnie zażądaj adresu URL dokumentu ze źródła strony. Każdy krok izoluje jedną kontrolę.

Trzy polecenia obejmują rozwiązywanie, TLS i ścieżkę dokumentu:

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

Jeśli rozwiązywanie zawodzi tylko przez tunel, podejrzana jest polityka split-DNS. Jeśli zawodzi TLS, porównaj nazwę certyfikatu z opublikowaną nazwą, zamiast klikać ostrzeżenie. Jeśli oba się udają, a dokument nadal zawodzi, błąd nie dotyczy już adresu URL.