DNS ya Azure P2S inashindwa wakati resolver iko katika VNet iliyooanishwa

Mteja anaweza kufikia mtandao wake pepe na bado ashindwe kutafsiri majina katika mtandao uliooanishwa. Peering si usafirishaji wa gateway hadi pande zote mbili zikubali.

Pinga VM na inajibu; uliza jina lake na mteja anasema mwenyeji hajulikani. Wakati resolver iko katika mtandao pepe uliooanishwa badala ya ule ulio na gateway ya VPN, jozi hiyo ya matokeo inatarajiwa, na hakuna kiasi cha utatuzi wa resolver kinachobadilisha hilo. Kinachokosekana ni mkataba wa uelekezaji ambao peering huuzuia kwa chaguo-msingi. Topolojia mbili zinaonekana karibu sawa kwenye karatasi, na pengo kati ya inayofanya kazi na iliyovunjika ni jozi ya swichi za peering zilizowekwa upande sahihi.

Fikiria kompyuta mpaku inayotengeneza handaki kwenye gateway katika VNet2, wakati kidhibiti cha kikoa kinachohudumia DNS kiko VNet1.

Topolojia mbili, tofauti moja

Weka resolver ndani ya mtandao pepe wa gateway yenyewe na jina litatatuliwa wakati handaki linapoinuka. Hakuna mpangilio wa peering unaoshiriki katika utafutaji huo.

Hamisha resolver hiyo hiyo ng'ambo ya peering na mteja bado anapata jibu kutoka VM wakati jina linabaki halijulikani. Cheti, handaki na mteja havijabadilika. Kitu pekee kilichohama ni mahali resolver inapoishi. Peering ilimpa njia kuelekea anwani hiyo, si mamlaka kwa gateway kubeba trafiki huko.

Upande A: ruhusu usafirishaji wa gateway kwa mmiliki wa gateway

Peering huunganisha mitandao miwili pepe, lakini muunganisho huo si wa kupitisha kwa trafiki inayofika kupitia gateway, na ombi la point-to-site hufika hivyo kabisa. Kwa hiyo gateway katika VNet2 haina msingi wa kukabidhi utafutaji kwa VNet1 hadi muundo uruhusu. Ruhusa ni swichi kwenye peering inayomilikiwa na mtandao ulio na gateway.

Weka Allow gateway transit kwenye peering ya VNet2 kuelekea VNet1. Sifa hiyo ni ya kitu cha peering, si ya rasilimali ya gateway, kwa hiyo unaisoma na kuibadilisha kwenye blade ya peering. Huo ni upande A wote.

Upande B: tumia gateway za mbali kwa mwenzake

Nusu nyingine ni picha ya kioo: kwenye peering ya VNet1 kurudi VNet2 washa Use remote gateways. Kuwasha bendera hiyo hiyo kwenye ncha zote mbili, au moja tu, huacha njia iliyojengwa nusu na dalili ya awali haijaguswa. Mtandao wenye gateway ya VPN pekee ndio unaruhusu usafirishaji, na mwenza ni upande unaoitumia.

Soma sifa zote mbili kwenye mitandao yote mbadala ya kuamini blade ya lango uliyofungua mwisho.

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

Kuona jozi hiyo bega kwa bega ndiyo njia ya haraka zaidi ya kunasa mpangilio uliopinduliwa. Peering inayoripoti AllowGatewayTransit false upande wa gateway inaeleza kushindwa kote bila kunasa pakiti.

Mteja bado anapaswa kupokea nini

Uelekezaji ni lazima na hautoshi, kwa sababu wasifu wa point-to-site lazima pia umpe mteja anwani ya DNS inayojibu mara usafirishaji unapofanya kazi. Resolver ya jukwaa si anwani hiyo: inajibu kanda za Azure Private DNS zilizounganishwa na mtandao pepe, lakini hakuna kitu kwa ukanda uliopangishwa kwenye seva zako za saraka, na ndivyo uenezaji huu unatumia. Elekeza mteja hapo na majina ya umma yatatatuliwa kwa furaha wakati mwenyeji wa ndani anabaki haijulikani.

Uliza resolver kutoka kompyuta mpaku iliyounganishwa kabla ya kubadilisha kitu kingine chochote.

nslookup dc01.corp.example 10.1.0.4

Muda kupita unasema njia bado haipo. Jibu la mamlaka linasukuma tatizo kurudi kwa mteja, kwa kawaida kiambishi ambacho hakiongezwi kamwe, kwa hiyo majina mafupi husafiri hadi resolver ya umma inayowashindisha kwa furaha.

Linganisha mkataba huo huo upande wa tovuti-kwa-tovuti

Hakuna kitu katika haya ni cha kompyuta mpaku hasa. Badilisha mteja na tawi la tovuti-kwa-tovuti na sharti la pande mbili linarejea: tawi hufika moja kwa moja kwenye mtandao wa gateway, na huduma iliyo umbali wa mitandao miwili bado iko nyuma ya peering.

Usafirishaji lazima utolewe kwenye peering zote mbili, na swichi inayoutoa iko kwenye peering si kwa aina ya mteja.

Kabla ya kulaumu gateway

Windows huweka orodha ya resolver kwa kila adapta, kwa hiyo thibitisha kile kiolesura cha handaki kilipokea kweli kabla ya kulaumu gateway.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

Jibu hasi huishi kwenye akiba muda mrefu kuliko marekebisho ya uelekezaji, na orodha ya kiambishi iliyopitwa na wakati inaendelea kutuma maswali mahali ambapo ukanda haukupangishwa kamwe. Safisha, uliza tena, na uandike ni seva gani inayojibu.

Masharti mawili madogo huamua kama njia itadumu: nafasi za anwani hazipaswi kuingiliana, na kikundi cha usalama wa mtandao kwenye subnet ya resolver lazima kikubali bwawa la wateja, ambalo ni safu nyingine ya chanzo. Thibitisha kwa ukaguzi wa njia bora kutoka upande wa VM pamoja na swali moja la moja kwa moja kutoka kwa mteja, ili tatizo la ukanda, tatizo la kiambishi au kichujio kamwe lisidanganywe kuwa usafirishaji unaokosekana.

Makala zinazohusiana