Lidhjet e SharePoint thyhen përmes VPN për shkak të URL-ve të publikuara

Një faqe SharePoint hapet përmes VPN, dhe lidhja e parë e dokumentit dështon me një emër që nuk ka qenë kurrë në shiritin e adresave. Ky hendek është i gjithë problemi: faqja erdhi nga një URL, dhe shërbimi formatoi kërkesën tjetër nga një tjetër. URL-ja e publikuar është një vendim në anën e serverit, prandaj rregullimi i saj në klient është fundi i gabuar. Kontrolloni cilin emër kthen shërbimi përpara se të prekni DNS ose rrugët.

Faqja e parë dhe kërkesa tjetër përdorin emra të ndryshëm

Një përdorues që arrin serverin përmes adresës sheh një faqe kryesore që funksionon. Lidhjet e dokumenteve në atë faqe gjenerohen nga URL-ja që shërbimi mendon se po publikon, jo nga ajo që shkroi shfletuesi. Nëse ato ndryshojnë, klikimi tjetër shkon drejt një emri që klienti nuk e ka zgjidhur kurrë.

Futja e adresës një herë nuk rregullon çdo lidhje të gjeneruar, dhe një faqeshënues drejt adresës e fsheh problemin derisa të hapet një dokument.

Ky dështim lexohet lehtë gabimisht si problem VPN sepse shfaqet vetëm pasi tuneli është në përdorim. Në praktikë tuneli bën punën e tij: e çon kërkesën drejt një emri që nuk ka rrugë funksionale ose certifikatë përputhëse. Ndani dy pyetjet përpara se të ndryshoni cilën do. Njëra është ku shkon paketa, tjetra është cilin emër zgjodhi shërbimi të publikojë.

Katër kontrolle, një emër

Çdo emër i publikuar duhet të kalojë katër kontrolle të pavarura. DNS duhet ta zgjidhë për klientin real, rrugëtimi dhe politika e aksesit duhet të lejojnë rrugën, TLS duhet të vërtetojë atë emër, dhe shërbimi duhet të jetë konfiguruar për ta publikuar.

Një ndryshim në një kontroll nuk i kryen të tjerët. Pranimi i një paralajmërimi certifikate nuk është rregullim i zgjidhjes së emrit.

Tabela më poshtë është rendi i listës së kontrollit. Ndaloni në rreshtin e parë që dështon, sepse një rregullim i mëvonshëm nuk mund të kompensojë një boshllëk të mëparshëm.

Lexoni modelin e publikimit përpara se ta ndryshoni

Vendosjet e SharePoint Server ndryshojnë. Aplikacionet klasike të uebit mund të përdorin hartëzime alternative të aksesit, ku një URL e brendshme është ajo që merr serveri dhe një URL publike është ajo që përdor për të formatuar lidhjet. Koleksionet e sajteve me emër hosti ndjekin një qasje tjetër dhe, sipas udhëzimeve të Microsoft, nuk mund të përdorin AAM.

Udhëzimet e planifikimit të Microsoft gjithashtu i shënojnë veçoritë AAM si të vjetruara dhe rekomandojnë koleksione sajtesh me emër hosti për planifikim të ri. Kjo e bën modelin e vendosjes një pyetje për pronarin e tij, jo një vlerë të parazgjedhur që ju e rregulloni.

Përcaktoni cili model është në përdorim përpara se të propozoni një ndryshim hartëzimi. Shtimi i një zëri AAM në një vendosje me emër hosti nuk bën asgjë, dhe shtimi i njërit në një vendosje klasike ndryshon çdo lidhje të kthyer përnjëherë. Të dyja janë ndryshime konfigurimi me ndikim të gjerë, prandaj përgatitini në faza dhe mbani një plan kthimi pas. Ky nuk është një rekomandim për të sjellë hartëzime të vjetra në një mjedis modern.

Ndiqni operacionin e dështuar, jo faqen kryesore

Regjistroni destinacionin që kërkesa e dështuar përdori në të vërtetë, aplikacionin klient, kohën dhe gabimin. Një shfletues dhe një aplikacion desktop mund të ndjekin rrugë të ndryshme përmes proxy, VPN ose vërtetimi drejt të njëjtit dokument.

Shfletuesi mund të ketë sukses ndërsa klienti Office dështon, dhe ai ndryshim është një të dhënë se cili kontekst e zgjidh emrin.

Nëse URL-ja dhe dorëzimi i rrjetit funksionojnë të dyja dhe shërbimi vazhdon ta refuzojë operacionin, problemi i mbetur është në nivel aplikacioni. Lejet e dokumenteve dhe statusi i pagesës i përkasin pronarit të shërbimit, dhe një rrugë VPN siguron lidhshmëri, jo leje.

Kontrolloni dorëzimin nga fillimi në fund

Ekzekutoni kontrollet me radhë në klientin që dështon: zgjidhni emrin e publikuar, kërkoni faqen me atë emër, pastaj kërkoni URL-në e dokumentit nga burimi i faqes. Çdo hap izolon një kontroll.

Tre komanda mbulojnë zgjidhjen, TLS dhe rrugën e dokumentit:

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

Nëse zgjidhja dështon vetëm përmes tunelit, politika e split-DNS është e dyshuara. Nëse TLS dështon, krahasoni emrin e certifikatës me emrin e publikuar në vend që të klikoni përtej. Nëse të dyja kanë sukses dhe dokumenti vazhdon të dështojë, gabimi nuk ka më të bëjë me URL-në.