Viungo vya SharePoint hukatika kupitia VPN kwa sababu ya URL zilizochapishwa

Ukurasa wa SharePoint hufunguka kupitia VPN, na kiungo cha kwanza cha hati hushindwa kwa jina ambalo halikuwa kamwe kwenye upau wa anwani. Pengo hilo ndilo tatizo lote: ukurasa ulikuja kutoka URL moja, na huduma ikaunda ombi lifuatalo kutoka nyingine. URL iliyochapishwa ni uamuzi wa upande wa seva, kwa hiyo kuirekebisha kwenye mteja ni mwisho usiofaa. Angalia jina ambalo huduma hurudisha kabla ya kugusa DNS au njia.

Ukurasa wa kwanza na ombi lifuatalo hutumia majina tofauti

Mtumiaji anayefikia seva kwa anwani huona ukurasa wa mwanzo unaofanya kazi. Viungo vya hati kwenye ukurasa huo huzalishwa kutoka URL ambayo huduma inadhani inaichapisha, si kutoka kile kivinjari kilichoandika. Ikiwa ni tofauti, mbofyo unaofuata huenda kwa jina ambalo mteja hakuwahi kulitatuwa.

Kuingiza anwani mara moja hakurekebishi kila kiungo kilichozalishwa, na alamisho la anwani huficha tatizo hadi hati ifunguliwe.

Kushindwa huku husomwa kwa urahisi kimakosa kama tatizo la VPN kwa sababu huonekana tu baada ya handaki kutumika. Kwa hakika handaki hufanya kazi yake: hubeba ombi hadi jina ambalo halina njia inayofanya kazi au cheti kinacholingana. Tenganisha maswali mawili kabla ya kubadilisha lolote. Moja ni pakiti inakwenda wapi, lingine ni jina ambalo huduma ilichagua kuchapisha.

Vidhibiti vinne, jina moja

Kila jina lililochapishwa lazima lipitishe vidhibiti vinne huru. DNS lazima litatue kwa mteja halisi, uelekezaji na sera ya ufikiaji lazima ziruhusu njia, TLS lazima ithibitishe jina hilo, na huduma lazima iwe imesanidiwa kulichapisha.

Mabadiliko katika kidhibiti kimoja hayatekelezi vingine. Kukubali onyo la cheti si ukarabati wa utatuzi wa jina.

Jedwali hapa chini ni mpangilio wa orodha hakiki. Simama kwenye mstari wa kwanza unaoshindwa, kwa sababu marekebisho ya baadaye hayawezi kufidia pengo la awali.

Soma mtindo wa uchapishaji kabla ya kuubadilisha

Usanidi wa SharePoint Server hutofautiana. Programu za wavuti za kawaida zinaweza kutumia ramani mbadala za ufikiaji, ambapo URL ya ndani ni kile seva inapokea na URL ya umma ni kile inachotumia kuunda viungo. Mikusanyiko ya tovuti yenye jina la mwenyeji hufuata mbinu tofauti na, kwa mwongozo wa Microsoft, haziwezi kutumia AAM.

Mwongozo wa upangaji wa Microsoft pia unaonyesha vipengele vya AAM kama vilivyopitwa na wakati na unapendekeza mikusanyiko ya tovuti yenye jina la mwenyeji kwa upangaji mpya. Hiyo hufanya mtindo wa usanidi kuwa swali kwa mmiliki wake, si chaguo-msingi unalolirekebisha.

Bainisha mtindo unaotumika kabla ya kupendekeza mabadiliko ya ramani. Kuongeza ingizo la AAM kwenye usanidi wenye jina la mwenyeji hakufanyi chochote, na kuongeza moja kwenye usanidi wa kawaida hubadilisha kila kiungo kinachorudishwa kwa wakati mmoja. Zote mbili ni mabadiliko ya usanidi yenye athari pana, kwa hiyo ziandae kwa hatua na uwe na mpango wa kurudi nyuma. Hii si pendekezo la kuleta ramani za zamani katika mazingira ya kisasa.

Fuatilia operesheni iliyoshindwa, si ukurasa wa mwanzo

Rekodi lengwa ambalo ombi lililoshindwa lilitumia kwa hakika, programu ya mteja, muda na hitilafu. Kivinjari na programu ya kompyuta ya mezani vinaweza kuchukua njia tofauti za proksi, VPN au uthibitishaji hadi hati moja.

Kivinjari kinaweza kufanikiwa wakati mteja wa Office anashindwa, na tofauti hiyo ni kidokezo cha muktadha upi unatatua jina.

Ikiwa URL na uwasilishaji wa mtandao vyote hufanya kazi na huduma bado inakataa operesheni, tatizo lililobaki ni la kiwango cha programu. Ruhusa za hati na hali ya malipo ni za mmiliki wa huduma, na njia ya VPN hutoa muunganisho, si ruhusa.

Angalia uwasilishaji kutoka mwanzo hadi mwisho

Endesha ukaguzi kwa mpangilio kwenye mteja anayeshindwa: tatua jina lililochapishwa, omba ukurasa kwa jina hilo, kisha omba URL ya hati kutoka chanzo cha ukurasa. Kila hatua hutenga kidhibiti kimoja.

Amri tatu zinashughulikia utatuzi, TLS na njia ya hati:

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

Ikiwa utatuzi unashindwa kupitia handaki pekee, sera ya split-DNS ndiye mtuhumiwa. Ikiwa TLS inashindwa, linganisha jina la cheti na jina lililochapishwa badala ya kubofya kupita. Ikiwa vyote vinafanikiwa na hati bado inashindwa, hitilafu haihusu URL tena.