DNS ya mwisho wa AWS Client VPN: kwa nini kubandika IP iliyotatuliwa kunashindikana

Wiki iliyopita dig +short ilikupa anwani moja kwa jina la mwisho katika wasifu wako wa AWS Client VPN, na handaki ikaunganishwa. Wiki hii wasifu huo huo umesimama kwenye 'Connecting' kwenye kompyuta yako ya mkononi wakati nakala ya mwenzako ambayo haijaguswa bado inafanya kazi. Hakuna kilichozuiwa na cheti hakikuisha muda. Mtu alibadilisha jina la mwenyeji wa mwisho na anwani hiyo iliyotatuliwa, na huduma haijibu tena hapo. Jina lililosafirishwa ndilo sehemu iliyojengwa kustahimili mabadiliko hayo.

Jina katika wasifu wako linaweza lisiwe jina linaloulizwa

Wasifu unaosafirishwa kutoka Client VPN kwa kawaida huwa na remote-random-hostname. Wakati chaguo hilo limewashwa, mteja huunda lebo ya mara moja, anaiunganisha na jina la mwisho kwa nukta, na hutatua jina lililounganishwa. Rekodi ya wildcard katika eneo la mwisho hujibu lebo yoyote, ndiyo sababu kiambishi cha kubuni bado kinatatuliwa na ndiyo sababu hila hiyo inabaki isionekana unapojaribu kurudia swali kwa mkono.

Kwa hiyo unapobandika jina la mwisho kwenye terminal na kupata jibu, umetatua jina tofauti na lile ambalo mteja hutumia wakati wa kuunganisha. Tofauti hiyo si kasoro ya kurekebisha katika wasifu. Lebo huundwa upya kwa makusudi: chaguo hilo huzuia akiba kubaki na jibu la zamani, na huwahi kutambua mashine yako au kipindi chako.

Nimekutana na hali ya utangamano ambapo mteja hupuuza chaguo hilo kabisa. AWS huandika suluhisho: baki na jina halisi la mwisho na uongeze mbele mfululizo wa nasibu pamoja na nukta, ukilichukulia kama mfumo wa majina na si thamani ya kubandika. Kulitumia kwa mteja wa zamani ni jambo la maana; kuweka msimbo mgumu wa mfululizo wenye kiambishi kama mwisho si jambo la maana.

Kwa nini jibu lililohifadhiwa haliwezi kubaki sahihi

Anwani za mwisho wa Client VPN zinasimamiwa na AWS na hubadilika kwa muda, jambo ambalo nyaraka za mbinu bora husema waziwazi. Jibu lililonaswa ni picha ya utatuzi mmoja. Wasifu unaoweka msimbo mgumu wa hilo huwa wasifu unaoelekea mwenyeji aliyestaafishwa mara tu huduma inapohama, na kushindikana mara chache huonekana kama DNS: unapata muda wa kuunganisha kuisha au handshake iliyokwama, kwa hiyo watu hufukuza uelekezaji na vyeti.

Jibu hilo hilo katika /etc/hosts hurithi muda huo huo pamoja na tatizo la ziada. Ingizo la hosts hustahimili kuwashwa upya, kusafirishwa upya na marekebisho ya 'sakinisha tena mteja', kwa hiyo kushindikana hurudi kila anwani inapohama. Nimeona moja ikikaa bila madhara kwa wiki, kisha ikaangusha kila mashine iliyoibeba wakati usakinishaji mpya ukiunganishwa kawaida. Mgawanyiko huo, kundi moja likishindwa na lingine likiwa sawa kwenye akaunti moja, ndiyo kidokezo cha bei rahisi zaidi utakachopata.

Punguza wigo wa ubahatishaji ipasavyo. Hufanyika kwa kila jaribio la kuunganisha. Handaki lililoanzishwa halitatui tena mwisho wake, halibadilishi seva katikati ya kipindi, na maombi ya programu binafsi hayachagui kila moja mwenyeji mpya wa VPN. Jaribio linalofuata pekee hutatua tena, kwa hiyo kipindi kinachofanya kazi mchana wote hakisemi chochote kuhusu kesho asubuhi.

Huduma hukagua nini wakati handaki inapanda

Client VPN inahitaji anwani unayounganishwa nayo ilingane na anwani iliyotatuliwa kwa jina la DNS la mwisho. Sharti hilo moja hufafanua kushindikana kadhaa kunakoonekana hakuhusiani: rekodi maalum ya DNS inayoelekea mahali pengine, frontend maalum inayopeleka kwenye anwani halisi ya mwisho, na wasifu ulioandikwa upya kwa anwani ghafi. AWS huandika mpangilio wa rekodi maalum pamoja na upelekaji kama kushindikana na wateja wa hivi karibuni wa AWS. Ukaguzi ni mwembamba; si hukumu kwamba kila jina la bandia limekatazwa.

Pia si kanuni ya jumla kuhusu itifaki za VPN. remote ya nambari ni halali kabisa katika usambazaji wa kawaida wa OpenVPN, na nyingi hufanya kazi hivyo. Kizuizi kinatokana na mpangilio unaosimamiwa, si na itifaki iliyo chini yake.

Jambo ambalo hufanya kulegeza uthibitishaji wa cheti kuwa mwitikio usiofaa. Ikiwa wasifu unashindwa baada ya kubadilishwa anwani, kuzima uthibitishaji wa seva huhamisha hitilafu badala ya kurekebisha utatuzi au sharti la kulingana na anwani, na huacha mteja atakayeamini kitu chochote. Weka CA iliyosafirishwa, uthibitishaji wa seva na mipangilio ya uthibitishaji wa pande zote kama ilivyokuja.

Orodha za ruhusa, utokaji na DNS ya faragha ni matatizo matatu tofauti

Kanuni ya firewall ambayo lazima iruhusu lengo kabla ya kompyuta ya mkononi kuunganisha inahusu msikilizaji wa nje. Mpe mmiliki wa mtandao jina la mwisho, usafiri na bandari iliyowekwa, kisha muulize kama udhibiti wao unaweza kufuata tabia ya DNS ya huduma. Kanuni inayoshikilia anwani moja iliyonaswa ni picha yenye muda wa mwisho usioandikwa. Ikiwa udhibiti unakubali tu malengo yasiyobadilika, tatua pengo hilo kabla ya uzinduzi badala ya kuweka msimbo mgumu wa jibu kimya kimya.

Mshirika anayehitaji anwani thabiti ya chanzo kwa maombi yanayofanywa baada ya handaki kupanda ana sharti lingine: utokaji. Kile ambacho tovuti huona hutegemea njia ya programu na sera ya handaki iliyogawanywa, si anwani ambayo mteja aliunganisha nayo. Trafiki ya handaki iliyogawanywa huenda isiguse AWS kabisa.

DNS ya faragha ndani ya handaki ni tabaka la tatu. Kitatuzi kinachopewa wateja hujibu majina ya ndani baada ya kuunganisha; hakiwezi kutatuwa mwisho wa umma kabla ya handaki kuwepo. Kushindikana kwa utatuzi wa mwisho na kushindikana kwa utatuzi wa programu ya ndani hutokea katika hatua tofauti, na kuzichanganya hukupeleka kwenye kumbukumbu isiyofaa.

Familia ya anwani ni sehemu ya orodha hiyo hiyo. Jibu la IPv4 halisemi chochote kuhusu njia inayoruhusiwa ya mwisho wa IPv6 au wa tabaka mbili, kwa hiyo picha iliyopigwa katika familia moja si ushahidi kwa nyingine.

Kagua muunganisho bila kubandika chochote

Anza na wasifu kama ulivyosafirishwa na usome unachoomba kwa hakika:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

Kisha linganisha mambo matatu: jina la mwisho lililo kwenye wasifu, anwani ambayo mteja huripoti kwa jaribio jipya, na kile ambacho jina linatatuliwa sasa. Jina linalotatuliwa linathibitisha tu kwamba rekodi inajibu; usafiri na uthibitishaji ni tofauti, na mwisho hauhitaji kujibu ping. Kumbukumbu ya mteja mwenyewe ndiyo chanzo pekee cha kipengele cha kati, kwa hiyo inase wakati wa jaribio na si baada yake.

Anwani inayojibu leo ni ushahidi kuhusu leo; jina ndilo ambalo huduma huliweka halali. Andika uchunguzi, tuma kwa anayemiliki mwisho, na uache wasifu ukielekea jina.

Tabia mbili za kuacha: kuzima ukaguzi wa vyeti ili kupita handshake iliyokwama, na kurundika lebo mbele ya jina la mwisho kwa matumaini kwamba moja itashikamana. Lebo hutatuliwa kupitia rekodi ya wildcard au tatizo liko mahali pengine. Ikiwa wasifu uliowekwa vizuri bado unashindwa, tuma swali kamili na tukio la muunganisho, si jina refu la mwenyeji.

Kabla ya kuifunga: wasifu bado umeibeba jina la mwisho lililosafirishwa, hakuna faili la hosts linalobandika anwani, remote kwenye kumbukumbu ya mteja inalingana na utatuzi wa sasa, na kanuni ya firewall inataja mwisho badala ya anwani. Hiyo pia ni hali ya kumkabidhi mtu anayefuata.