SharePoint stranica otvara se preko VPN-a, a prva veza na dokument ne uspijeva s imenom koje nikada nije bilo u adresnoj traci. Taj je jaz cijeli problem: stranica je došla s jednog URL-a, a servis je sljedeći zahtjev formatirao s drugog. Objavljeni URL odluka je na strani poslužitelja, pa je popravljanje na klijentu pogrešan kraj. Provjerite koje ime servis vraća prije nego dirnete DNS ili rute.

Prva stranica i sljedeći zahtjev koriste različita imena

Korisnik koji dođe do poslužitelja 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ću potvrdu. 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 neovisne kontrole. DNS ga mora razriješiti za stvarnog klijenta, usmjeravanje i pravila pristupa moraju dopustiti putanju, TLS mora potvrditi to ime, a servis mora biti konfiguriran da ga objavi.

Promjena jedne kontrole ne obavlja ostale. Prihvaćanje upozorenja o potvrdi nije popravak razrješavanja imena.

Tablica ispod redoslijed je kontrolnog popisa. Zaustavite se na prvom retku koji ne prođe, jer kasniji popravak ne može nadoknaditi raniji jaz.

ControlQuestionWhere to look
DNSCan the client resolve the published name?Client resolver and split-DNS policy
Route and policyDoes the permitted path exist to the service?VPN routes and firewall rules
TLS identityDoes the certificate match the name in use?Certificate subject names and trust store
Publishing configWhich URL does the service return?Web application settings and site model

Pročitajte model objavljivanja prije nego ga promijenite

Implementacije SharePoint Servera razlikuju se. Klasične web-aplikacije mogu koristiti alternativna preslikavanja pristupa, gdje je interni URL ono što poslužitelj prima, a javni URL ono što koristi za oblikovanje veza. Kolekcije web-mjesta s imenom hosta slijede drukčiji pristup i, prema Microsoftovim smjernicama, ne mogu koristiti AAM.

Microsoftove smjernice za planiranje također označavaju AAM značajke zastarjelima i preporučuju kolekcije web-mjesta s imenom hosta za novo planiranje. To model implementacije čini pitanjem za njegova vlasnika, a ne zadanim izborom koji vi krpate.

Utvrdite koji je model u upotrebi prije nego predložite promjenu preslikavanja. 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 preslikavanja.

Slijedite neuspjelu radnju, ne početnu stranicu

Zabilježite odredište koje je neuspjeli zahtjev stvarno koristio, klijentsku aplikaciju, vrijeme i pogreš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 je razlika trag o tome koji kontekst razrješava ime.

Ako URL i mrežno predavanje rade, a servis još odbija radnju, preostali je problem na razini aplikacije. Dopuštenja za dokumente i stanje naplate pripadaju vlasniku servisa, a VPN ruta pruža povezanost, a ne dopuštenje.

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 pravilo. Ako TLS ne uspijeva, usporedite ime potvrde s objavljenim imenom umjesto da kliknete kroz upozorenje. Ako oboje uspije, a dokument još ne uspijeva, pogreška više nije o URL-u.

Povezani članci