SharePoint veze pucaju preko VPN-a zbog objavljenih URL-ova
SharePoint stranica koja se učita preko VPN-a i dalje može vraćati veze na dokumente s imenom koje vaš klijent ne može razriješiti. Provjerite DNS, rutu, TLS i objavljeni URL.
SharePoint stranica se otvara preko VPN-a, a prva veza na dokument ne uspijeva s imenom koje nikada nije bilo u adresnoj traci. Taj jaz je cijeli problem: stranica je došla s jednog URL-a, a servis je sljedeći zahtjev formatirao s drugog. Objavljeni URL je odluka na strani servera, pa je popravljanje na klijentu pogrešan kraj. Provjerite koje ime servis vraća prije nego dirate DNS ili rute.
Prva stranica i sljedeći zahtjev koriste različita imena
Korisnik koji dođe do servera po adresi vidi radnu početnu stranicu. Veze na dokumente na toj stranici generiraju se iz URL-a za koji servis misli da ga objavljuje, a ne iz onoga što je preglednik upisao. Ako se razlikuju, sljedeći klik ide na ime koje klijent nikada nije razriješio.
Unos adrese jednom ne popravlja svaku generiranu vezu, a oznaka do adrese skriva problem dok se dokument ne otvori.
Taj se kvar lako pogrešno pročita kao VPN problem jer se pojavljuje tek nakon što se tunel počne koristiti. U praksi tunel radi svoj posao: nosi zahtjev do imena koje nema radnu putanju ili nema odgovarajući certifikat. Odvojite dva pitanja prije nego promijenite bilo koje. Jedno je kamo paket ide, drugo je koje je ime servis odabrao objaviti.
Četiri kontrole, jedno ime
Svako objavljeno ime mora proći četiri nezavisne kontrole. DNS ga mora razriješiti za stvarnog klijenta, usmjeravanje i politika pristupa moraju dopustiti putanju, TLS mora validirati to ime, a servis mora biti konfiguriran da ga objavi.
Promjena jedne kontrole ne obavlja ostale. Prihvaćanje upozorenja o certifikatu nije popravak razrješavanja imena.
Tabela ispod je redoslijed kontrolne liste. Zaustavite se na prvom redu koji ne prođe, jer kasniji popravak ne može nadoknaditi raniji jaz.
| Control | Question | Where to look |
|---|---|---|
| DNS | Can the client resolve the published name? | Client resolver and split-DNS policy |
| Route and policy | Does the permitted path exist to the service? | VPN routes and firewall rules |
| TLS identity | Does the certificate match the name in use? | Certificate subject names and trust store |
| Publishing config | Which URL does the service return? | Web application settings and site model |
Pročitajte model objavljivanja prije nego ga promijenite
SharePoint Server implementacije se razlikuju. Klasične web aplikacije mogu koristiti alternativna mapiranja pristupa, gdje je interni URL ono što server prima, a javni URL ono što koristi za formatiranje veza. Kolekcije stranica s imenom hosta slijede drugačiji pristup i, prema Microsoftovim smjernicama, ne mogu koristiti AAM.
Microsoftove smjernice za planiranje također označavaju AAM funkcije kao zastarjele i preporučuju kolekcije stranica s imenom hosta za novo planiranje. To model implementacije čini pitanjem za njegovog vlasnika, a ne zadanim izborom koji vi krpate.
Utvrdite koji je model u upotrebi prije nego predložite promjenu mapiranja. Dodavanje AAM unosa u implementaciju s imenom hosta ne čini ništa, a dodavanje jednog u klasičnu implementaciju mijenja svaku vraćenu vezu odjednom. Oba su konfiguracijske promjene širokog utjecaja, pa ih pripremite u fazama i zadržite plan vraćanja. Ovo nije preporuka da u moderno okruženje uvozite naslijeđena mapiranja.
Slijedite neuspjelu radnju, ne početnu stranicu
Zabilježite odredište koje je neuspjeli zahtjev stvarno koristio, klijentsku aplikaciju, vrijeme i grešku. Preglednik i stolna aplikacija mogu ići različitim proxy, VPN ili autentifikacijskim putanjama do istog dokumenta.
Preglednik može uspjeti dok Office klijent ne uspijeva, a ta razlika je trag o tome koji kontekst razrješava ime.
Ako URL i mrežno predavanje rade, a servis još odbija radnju, preostali problem je na razini aplikacije. Dozvole za dokumente i stanje naplate pripadaju vlasniku servisa, a VPN ruta pruža povezanost, a ne dozvolu.
Provjerite predavanje od početka do kraja
Izvršite provjere po redu na klijentu koji ne uspijeva: razriješite objavljeno ime, zatražite stranicu po tom imenu, zatim zatražite URL dokumenta iz izvornog koda stranice. Svaki korak izolira jednu kontrolu.
Tri naredbe pokrivaju razrješavanje, TLS i putanju do dokumenta:
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
Ako razrješavanje ne uspijeva samo kroz tunel, sumnjivac je split-DNS politika. Ako TLS ne uspijeva, uporedite ime certifikata s objavljenim imenom umjesto da kliknete kroz upozorenje. Ako oboje uspije, a dokument još ne uspijeva, greška više nije o URL-u.