Nasira ang mga link ng SharePoint sa VPN dahil sa mga nailathalang URL

Bumubukas ang pahinang SharePoint sa VPN, at nabigo ang unang link ng dokumento sa isang pangalang hindi kailanman nasa address bar. Ang agwat na iyon ang buong problema: ang pahina ay galing sa isang URL, at ang serbisyo ay nag-format ng susunod na kahilingan mula sa iba. Ang nailathalang URL ay desisyon sa panig ng server, kaya ang pag-aayos nito sa kliyente ay maling dulo. Suriin kung anong pangalan ang ibinabalik ng serbisyo bago hawakan ang DNS o mga ruta.

Ang unang pahina at ang susunod na kahilingan ay gumagamit ng magkaibang pangalan

Ang gumagamit na nakakarating sa server sa pamamagitan ng address ay nakakakita ng gumaganang home page. Ang mga link ng dokumento sa pahinang iyon ay nabuo mula sa URL na inaakala ng serbisyong inilalathala nito, hindi mula sa itina-type ng browser. Kung magkaiba ang mga ito, ang susunod na click ay pupunta sa pangalang hindi kailanman nalutas ng kliyente.

Ang pagpasok ng address nang isang beses ay hindi nag-aayos ng bawat nabuong link, at ang bookmark sa address ay nagtatago ng problema hanggang may mabuksang dokumento.

Ang kabiguan na ito ay madaling mabasa nang mali bilang problema sa VPN dahil lumilitaw lamang ito pagkatapos gamitin ang tunnel. Sa pagsasagawa, ginagawa ng tunnel ang trabaho nito: dinadala nito ang kahilingan sa isang pangalang walang gumaganang landas o walang tugmang sertipiko. Paghiwalayin ang dalawang tanong bago baguhin ang alinman. Ang isa ay kung saan pupunta ang packet, ang isa ay kung anong pangalan ang piniling ilathala ng serbisyo.

Apat na kontrol, isang pangalan

Bawat nailathalang pangalan ay dapat pumasa sa apat na independiyenteng kontrol. Dapat itong lutasin ng DNS para sa aktuwal na kliyente, dapat pahintulutan ng routing at patakaran ng access ang landas, dapat patunayan ng TLS ang pangalang iyon, at dapat na naka-configure ang serbisyo upang ilathala ito.

Ang pagbabago sa isang kontrol ay hindi nagsasagawa ng iba. Ang pagtanggap ng babala sa sertipiko ay hindi pag-aayos ng paglutas ng pangalan.

Ang talahanayan sa ibaba ay ang pagkakasunod-sunod ng checklist. Huminto sa unang hilera na nabigo, dahil ang huling pagwawasto ay hindi makababayad sa naunang puwang.

Basahin ang modelo ng paglalathala bago ito baguhin

Nagkakaiba ang mga deployment ng SharePoint Server. Ang mga klasikong web application ay maaaring gumamit ng alternatibong access mapping, kung saan ang internal na URL ay ang natatanggap ng server at ang pampublikong URL ay ang ginagamit nito upang i-format ang mga link. Ang mga host-named site collection ay sumusunod sa ibang pamamaraan at, ayon sa gabay ng Microsoft, hindi makakagamit ng AAM.

Ang gabay sa pagpaplano ng Microsoft ay nagmamarka rin ng mga feature ng AAM bilang lipas na at inirerekomenda ang mga host-named site collection para sa bagong pagpaplano. Ginagawa nitong tanong para sa may-ari ang modelo ng deployment, hindi default na iyong tinatapalan.

Alamin kung aling modelo ang ginagamit bago magmungkahi ng pagbabago sa mapping. Ang pagdaragdag ng AAM entry sa host-named deployment ay walang ginagawa, at ang pagdaragdag ng isa sa klasikong deployment ay nagbabago sa bawat ibinalik na link nang sabay. Pareho silang pagbabago sa configuration na may malawak na epekto, kaya ihanda ang mga ito nang yugto-yugto at panatilihin ang plano sa pag-rollback. Hindi ito rekomendasyon na magdala ng lumang mapping sa modernong kapaligiran.

Sundan ang nabigong operasyon, hindi ang home page

Itala ang destinasyon na aktuwal na ginamit ng nabigong kahilingan, ang kliyenteng application, ang oras at ang error. Ang browser at desktop application ay maaaring dumaan sa magkaibang proxy, VPN o authentication na landas patungo sa parehong dokumento.

Maaaring magtagumpay ang browser habang nabigo ang Office client, at ang pagkakaibang iyon ay palatandaan kung aling konteksto ang lumulutas ng pangalan.

Kung gumagana ang URL at ang paghahatid ng network at tinatanggihan pa rin ng serbisyo ang operasyon, ang natitirang problema ay nasa antas ng application. Ang mga pahintulot sa dokumento at katayuan ng pagbabayad ay pag-aari ng may-ari ng serbisyo, at ang ruta ng VPN ay nagbibigay ng koneksyon, hindi pahintulot.

Suriin ang paghahatid mula umpisa hanggang dulo

Patakbuhin ang mga pagsusuri nang sunud-sunod sa kliyenteng nabibigo: lutasin ang nailathalang pangalan, hilingin ang pahina sa pangalang iyon, pagkatapos hilingin ang URL ng dokumento mula sa source ng pahina. Ang bawat hakbang ay naghihiwalay ng isang kontrol.

Tatlong command ang sumasaklaw sa paglutas, TLS at landas ng dokumento:

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

Kung nabibigo ang paglutas sa tunnel lamang, ang patakaran ng split-DNS ang pinaghihinalaan. Kung nabibigo ang TLS, ihambing ang pangalan ng sertipiko sa nailathalang pangalan sa halip na i-click ito. Kung pareho silang nagtagumpay at nabibigo pa rin ang dokumento, ang error ay hindi na tungkol sa URL.