Stran SharePoint se odpre prek VPN, in prva povezava do dokumenta ne uspe z imenom, ki ga nikoli ni bilo v naslovni vrstici. Ta vrzel je vsa težava: stran je prišla z enega URL-ja, storitev pa je naslednjo zahtevo oblikovala z drugega. Objavljeni URL je odločitev na strani strežnika, zato je popravljanje na odjemalcu napačni konec. Preverite, katero ime vrne storitev, preden se dotaknete DNS ali poti.

Prva stran in naslednja zahteva uporabljata različna imena

Uporabnik, ki doseže strežnik po naslovu, vidi delujočo domačo stran. Povezave do dokumentov na tej strani se ustvarjajo iz URL-ja, za katerega storitev meni, da ga objavlja, ne iz tega, kar je vnesel brskalnik. Če se razlikujeta, naslednji klik vodi na ime, ki ga odjemalec ni nikoli razrešil.

Enkratni vnos naslova ne popravi vsake ustvarjene povezave, zaznamek na naslov pa skrije težavo, dokler se dokument ne odpre.

To napako je lahko napačno brati kot težavo VPN, ker se pojavi šele po uporabi tunela. V praksi tunel opravlja svoje delo: zahtevo nosi do imena, ki nima delujoče poti ali ustreznega potrdila. Ločite obe vprašanji, preden spremenite katero koli. Eno je, kam gre paket, drugo je, katero ime je storitev izbrala za objavo.

Štiri kontrole, eno ime

Vsako objavljeno ime mora prestati štiri neodvisne kontrole. DNS ga mora razrešiti za dejanskega odjemalca, usmerjanje in politika dostopa morata dovoliti pot, TLS mora potrditi to ime, storitev pa mora biti konfigurirana za njegovo objavo.

Sprememba ene kontrole ne izvede drugih. Sprejetje opozorila o potrdilu ni popravilo razreševanja imen.

Tabela spodaj je vrstni red kontrolnega seznama. Ustavite se pri prvi vrstici, ki ne uspe, ker poznejši popravek ne more nadomestiti prejšnje vrzeli.

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

Preberite model objavljanja, preden ga spremenite

Namestitve SharePoint Server se razlikujejo. Klasične spletne aplikacije lahko uporabljajo nadomestna preslikavanja dostopa, kjer je notranji URL tisto, kar prejme strežnik, javni URL pa tisto, kar uporablja za oblikovanje povezav. Zbirke mest z imenom gostitelja sledijo drugačnemu pristopu in po Microsoftovih smernicah ne morejo uporabljati AAM.

Microsoftove smernice za načrtovanje prav tako označujejo funkcije AAM kot zastarele in priporočajo zbirke mest z imenom gostitelja za novo načrtovanje. To naredi model namestitve vprašanje za njegovega lastnika, ne privzeto vrednost, ki jo krpate.

Ugotovite, kateri model se uporablja, preden predlagate spremembo preslikave. Dodajanje vnosa AAM v namestitev z imenom gostitelja ne naredi ničesar, dodajanje enega v klasično namestitev pa spremeni vse vrnjene povezave hkrati. Obe sta konfiguracijski spremembi s širokim vplivom, zato ju pripravite po stopnjah in ohranite načrt za razveljavitev. To ni priporočilo za uvajanje starih preslikav v sodobno okolje.

Sledite neuspešni operaciji, ne domači strani

Zabeležite cilj, ki ga je neuspešna zahteva dejansko uporabila, odjemalsko aplikacijo, čas in napako. Brskalnik in namizna aplikacija lahko ubirata različne poti prek proxyja, VPN ali preverjanja pristnosti do istega dokumenta.

Brskalnik lahko uspe, medtem ko odjemalec Office ne uspe, in ta razlika je namig, kateri kontekst razreši ime.

Če URL in omrežna predaja oba delujeta in storitev operacijo še vedno zavrača, je preostala težava na ravni aplikacije. Dovoljenja za dokumente in stanje zaklepa pripadajo lastniku storitve, pot VPN pa zagotavlja povezljivost, ne dovoljenja.

Preverite predajo od začetka do konca

Izvedite preverjanja po vrsti na odjemalcu, ki ne uspe: razrešite objavljeno ime, zahtevajte stran pod tem imenom, nato zahtevajte URL dokumenta iz izvorne kode strani. Vsak korak izolira eno kontrolo.

Trije ukazi pokrivajo razreševanje, TLS in pot 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

Če razreševanje ne uspe samo skozi tunel, je sumljiva politika split-DNS. Če TLS ne uspe, primerjajte ime potrdila z objavljenim imenom, namesto da kliknete skozi opozorilo. Če oba uspeta in dokument še vedno ne uspe, napaka ni več povezana z URL-jem.

Sorodni članki