Azure P2S VPN haiwezi kutatua jina la kituo cha mwisho cha faragha

Unaunganisha handaki la point-to-site, unapiga ping kwenye anwani ya faragha, unafungua programu na unapata 403 au hitilafu ya cheti badala yake. Dalili zote mbili zinaelekeza kwa DNS, lakini ni hitilafu tofauti: moja inamaanisha mteja alitatua anwani ya umma, nyingine inamaanisha alitatua anwani ya faragha kisha akatoa jina ambalo cheti hakilifuniki. Fuata ukaguzi hapa chini kwa mpangilio na simama kwenye kushindwa kwa kwanza, kwa sababu ingizo la hosts au jibu lililohifadhiwa kwenye akiba linaweza kufanya kila ukaguzi unaofuata upite kwa sababu isiyo sahihi. Mpangilio huu naweka katika faili ya maandishi kando ya wasifu wangu wa VPN, kwa sababu marekebisho hayabadilishi chochote kwenye handaki na hubadilisha kila kitu katika kile mteja anachojua.

Anza na anwani ambayo mteja anapata kweli

Uliza kitatuzi moja kwa moja badala ya kuamini programu. Kwenye Windows, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net inaonyesha mtazamo ambao mteja alipata. Jibu la umma linamaanisha hakuna kitu chini kitakachofikia kituo cha mwisho; anwani ya faragha ya kituo cha mwisho inamaanisha DNS imekamilika na ukaguzi unaofuata ni muunganisho wenyewe.

Kituo cha mwisho cha faragha hakibadilishi jina la huduma. Akaunti au programu inahifadhi jina lake kamili la kawaida, na kituo cha mwisho kinabadilisha tu anwani ambayo jina hilo linatatuliwa kwa wateja ndani ya mtandao pepe. Ndiyo sababu jina hilo hilo la mwenyeji linatatuliwa kwa faragha kutoka VM kwenye mtandao na kwa umma kutoka kwa kompyuta mpakato ambayo haikupata mtazamo wa faragha kamwe.

Kabla ya handaki, angalia eneo, kiungo chake na rekodi

Masharti matatu lazima yatimizwe pamoja: eneo la faragha lipo, limeunganishwa na mtandao pepe ambao lango la VPN na wateja wanaingia Azure, na lina rekodi ya A ya kituo cha mwisho inayoelekeza kwenye anwani ya faragha. Unganisha eneo na mtandao usiohusiana na lango litaendelea kutatua rekodi ya umma wakati kila kitu kwenye handaki kikionekana kizuri.

Majina ya maeneo ni ya huduma, si ya viungo vya faragha kwa ujumla. App Service kwa kawaida hutumia privatelink.azurewebsites.net, hifadhi na SQL zina nafasi zao za majina, na kuazima eneo la huduma nyingine huzalisha eneo ambalo lipo lakini halijibu kitu chochote cha manufaa.

Mpe mteja kitatuzi anachoweza kufikia kweli

168.63.129.16 hujibu kutoka kwa mashine pepe za Azure na si seva ya DNS kwa kompyuta mpakato upande wa pili wa handaki la point-to-site. Mteja anahitaji kitatuzi kinachofikiwa kupitia handaki: kituo cha mwisho cha kuingia cha Azure DNS Private Resolver, kipitishaji ndani ya mtandao pepe, au maingizo ya seva ya DNS yanayobebwa katika wasifu wa mteja wa VPN ili mteja aulize mtandao pepe moja kwa moja.

Kitatuzi kilichosanidiwa lakini hakiwezi kufikiwa hufanya kama hakuna kitatuzi, na dalili ni muda kuisha si jibu lisilo sahihi, ndiyo sababu husomwa vibaya kama tatizo la firewall. Kijaribu kwa swali ambalo handaki linapaswa kubeba, si kwa jina la umma ambalo lingerafanikiwa kupitia kiungo cha ndani hata hivyo.

Ikiwa unapitisha badala ya kusukuma mipangilio, pitisha nafasi ya majina ambayo eneo la faragha linamiliki, privatelink.azurewebsites.net badala ya azurewebsites.net yote. Kipitishaji chenye masharti kinachomeza kiambishi kamili cha mzazi hutuma kila utafutaji wa huduma kwenda Azure, ikiwa ni pamoja na yale yanayopaswa kubaki ya ndani.

Tumia jina ambalo cheti kilitolewa kwa ajili yake

Anwani inapokuwa sahihi, hitilafu ya pili inaonekana. Hifadhi na App Service huchapisha jina bandia privatelink, na jina hilo bandia si lazima liwe jina lililo kwenye cheti. Upakiaji wa AzCopy ulioelekezwa privatelink.blob.core.windows.net haukufaulu uthibitishaji; upakiaji huo huo kwenda <account>.blob.core.windows.net/<container> ulitatuliwa kwenye anwani ya faragha na ukapita, kwa hiyo ulibaki kwenye njia ya faragha bila upitishaji wowote.

Kanuni hii inatumika kwenye kivinjari na pia kwa App Service: unganisha na jina la mwenyeji ambalo cheti kinakifunika na uache DNS itoe anwani ya faragha. Usikimbilie kupitisha uthibitishaji, kwa sababu hubadilisha hitilafu ya majina kuwa kurudi nyuma kwa usalama. Ping iliyofaulu inathibitisha njia na haisemi chochote kuhusu jina ndani ya kupeana mkono, ndiyo sababu hizi zinabaki kuwa ukaguzi tofauti.

Mpangilio wa hatua nne unaotenganisha kila tabaka

1. Hakikisha mteja wa VPN ana anwani kutoka bwawa la point-to-site na njia kuelekea anwani ya faragha ya kituo cha mwisho.
2. Tatua jina kamili ambalo programu inatumia na linganisha jibu na anwani ya kituo cha mwisho.
3. Fungua muunganisho wa TCP kwa kituo cha mwisho kwenye bandari ya huduma, kisha soma jina la cheti linalowasilishwa kwenye muunganisho huo.
4. Ndipo tu jaribu idhini, kwa sababu njia inayofanya kazi na cheti halali bado haitoi ufikiaji wa rasilimali.

Muunganisho uliokataliwa wakati anwani ni sahihi unaelekeza kwenye kikundi cha usalama cha mtandao au hali ya muunganisho wa kituo cha mwisho cha faragha, si DNS, kwa hiyo angalia hizo kabla ya kuhariri mipangilio ya kitatuzi tena. Kutolingana kwa jina la TLS hukurejesha kwenye jina la mwenyeji kwenye URL na subject ya cheti. Hifadhi pamoja matokeo ya utatuzi, jina la cheti na URL kamili; thamani hizo tatu zinaeleza mengi ya matukio haya bila kugusa lango.

Tumia VM ndani ya mtandao pepe kama udhibiti. Ikiwa jina linatatuliwa kwa faragha huko na kwa umma kutoka handaki, eneo na rekodi ni sahihi na tofauti pekee ni njia ya kitatuzi cha mteja, ambayo huthibitishwa haraka kuliko mzunguko mwingine wa usanidi wa kituo cha mwisho.

Wateja pia huhifadhi kwenye akiba. Rekodi iliyojibu kwa umma dakika kumi zilizopita inaendelea kujibu baada ya kurekebisha eneo, kwa hiyo futa akiba kabla ya kujaribu tena. Kwenye Windows, ipconfig /flushdns husafisha akiba ya mteja; kanuni za sera ya utatuzi wa majina zinabaki, huamua kiambishi kipi kinaenda kwa seva ipi, na zinaweza kuendelea kutuma nafasi ya majina kwa kitatuzi ulichokibadilisha hivi punde.

Ingizo la hosts linafaa wapi

Kuongeza anwani ya kituo cha mwisho kwenye faili la hosts ni utambuzi mzuri na muundo mbaya. Inathibitisha kwamba ramani ya jina-kwa-anwani ndiyo kipande kinachokosekana na inakuwezesha kujaribu kila kitu baada ya hatua hiyo, lakini haionekani kwa watumiaji wako, huvunjika anwani ya kituo cha mwisho inapobadilika, na huficha eneo ambalo linapaswa kujibu.

Ingizo la jaribio lililobaki ni baya kuliko akiba iliyopitwa na wakati, kwa sababu inaweza kufanya njia iliyorekebishwa ionekane imevunjika au njia iliyovunjika ionekane imerekebishwa kulingana na mwelekeo wa hitilafu. Liondoe kabla ya mzunguko wa mwisho na utatue kwa kitatuzi cha uzalishaji pekee.

Majina mafupi yanahitaji kiambishi cha utafutaji na majina kamili hayahitaji, kwa hiyo jaribu kwanza jina kamili, kisha amua kama mtiririko wa kazi unahitaji kiambishi kinachosukumwa kupitia wasifu wa mteja. Microsoft huandika majina ya maeneo na maumbo ya rekodi kwa kila huduma katika mwongozo wake wa DNS wa vituo vya mwisho vya faragha; soma ingizo la huduma yako badala ya kunakili eneo kutoka kwa nyingine.