DNS ya kibinafsi inafanya kazi ndani ya VPC lakini si kupitia VPN

Jina la kibinafsi linatatuliwa kutoka kwa instansi ya EC2 lakini si kutoka kwa kompyuta ya mkononi iliyounganishwa kupitia VPN, na eneo linaonekana sahihi kwenye konsoli. Msukumo wa kwanza ni kuhariri rekodi, jambo ambalo karibu kamwe si tatizo. Rekodi inajibu mtu fulani; haijibu tu kompyuta yako ya mkononi. Kinachotofautiana kati ya wapigaji simu wawili ni resolver gani wanaiuliza na kama resolver hiyo ina njia inayotumika kuingia kwenye mwonekano wa DNS wa VPC.

Ninaanza kwa kuthibitisha kuwa rekodi ipo, kisha ninatumia muda uliobaki kwenye njia ya swali. Hizi ni mifumo tofauti na zinashindwa kwa namna tofauti.

Soma umbo la kushindwa kabla ya kubadilisha kitu chochote

Matokeo matatu yanamaanisha mambo matatu tofauti, na swali moja linawatenganisha: endesha dig kwa jina hilo dhidi ya resolver ambayo mteja anaitumia kweli.

Muda kuisha ni tamko kuhusu mtandao. NXDOMAIN ni tamko kuhusu mwonekano wa DNS. Jibu la umma ni tamko kuhusu sera. Kuhariri rekodi ya eneo wakati muda umeisha ni kutupa ushahidi mmoja wenye manufaa katika kesi hii.

Kwa nini anwani ya pamoja-na-mbili ya VPC si resolver ya mbali

Anwani ya CIDR pamoja-na-mbili ni huduma ya ndani kwa rasilimali zilizo ndani ya VPC. AWS inaeleza kwamba kupeleka hoja kutoka mitandao ya ndani, au kutoka kwa seva za DNS za VPC nyingine, moja kwa moja hadi anwani hiyo hakuungwi mkono na kunaweza kutoa matokeo yasiyotulia.

Hilo halimaanishi kwamba jaribio halionekani kamwe kufanya kazi. Linamaanisha tabia si mkataba unaoweza kuwekwa kwenye script ya msaada. Mwelekeo unaoungwa mkono ni Resolver endpoint inayoingia: jozi la anwani ndani ya VPC yako, linalofikika kutoka mtandao unaoudhibiti, linalokubali hoja zinazokuja kutoka nje ya AWS.

Jenga njia kwa mpangilio ambao inashindwa kwa usafi

Lazima kuwe na hatua tatu, na kila moja ina namna yake ya kushindwa.

VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addresses

Kipitishaji kinahitaji njia hadi anwani za endpoint kupitia VPN, na njia ya kurudi lazima pia ifanye kazi. Kwa DNS ya kawaida kwenye bandari 53 endpoint inajibu kupitia UDP na TCP, kwa hivyo itifaki zote mbili lazima zikubaliwe na zote mbili lazima zipite ukaguzi wowote wa hali katikati.

Kisha angalia mwonekano wa DNS kwa tofauti. Eneo la mwenyeji la kibinafsi linaonekana tu kwa VPC ambazo limeunganishwa nazo, au kupitia mpango wa kushiriki uliokusudiwa. Endpoint inayofikika yenyewe haifanyi kila eneo la kibinafsi litatuliwe katika muktadha wake wa utatuzi.

Endpoint inayotoka inahudumia mwelekeo kinyume na haitajibu swali linaloingia kutoka kompyuta yako ya mkononi.

Thibitisha kutoka pande zote mbili

Uliza kutoka kwa mteja kuelekea kipitishaji, kisha kutoka kwa kipitishaji kuelekea endpoint. Ikiwa mteja anashindwa wakati kipitishaji kinafanikiwa, pengo liko kati ya hao wawili.

Ikiwa wote wawili wanashindwa, angalia sera ya usalama kwenye endpoint na anwani ya chanzo inayoiona kweli. Kipitishaji kilicho nyuma ya NAT kinaonyesha anwani ya NAT badala ya anwani ya VPN ya kompyuta ya mkononi, na tofauti hiyo pekee inatosha kuangusha swali. Ikiwa wote wawili wanafanikiwa lakini programu bado inashindwa, programu inaweza kuwa inatumia resolver tofauti na ile uliyojaribu.

Tenganisha nafasi za majina za umma na za kibinafsi kwa makusudi. Split DNS ni sera unayoisanidi, si athari ya pembeni ya utafutaji mmoja unaotokea kurudisha data.

Ninachokataa kufanya

Sitaongeza kanuni ya NAT iliyofanya utafutaji mmoja ufanye kazi na kuiita muundo.

Sitaelekeza kila mteja wa mbali kwenye anwani ya pamoja-na-mbili kwa sababu jaribio moja liliwahi kurudisha rekodi. Na sitapanua sera ya usalama ya endpoint hadi bwawa lote la VPN wakati kipitishaji kimoja kinahitaji ufikiaji. Ikiwa shirika tayari linaendesha kipitishaji kilichoidhinishwa ndani ya VPC, soma muundo huo kwanza, kwa sababu endpoint ya pili unayoongeza ndiyo ambayo hakuna anayeidokumenti.