Kwa nini jibu la DNS linashindikana kwenye kinga ya ukingo ya VPN isiyo na hali

Handaki liko hai, wateja wanaweza kufikia mwenyeji wa VPN, lakini mwenyeji hawezi kutatua chochote. Maswali yake ya kutoka yanaondoka kwenye kiunganishi kwa usafi, kwa hiyo hitilafu iko kwenye njia ya kurudi: kwenye ukingo wa juu unaochuja trafiki inayoingia bila kukumbuka kile mwenyeji alichotuma hivi punde. Kuruhusu mlango wa handaki hakuelezei kabisa mabadilishano hayo. Jibu la swali la DNS ni mtiririko tofauti, na ikiwa ukingo hauna hali, hakuna kilicholiruhusu kurudi.

Mabadilishano mawili hayo si mabadilishano yale yale

Andika tuples na kosa linaonekana wazi. Mlango wa lengo wa ombi unakuwa mlango wa chanzo wa jibu, ambayo ni kinyume cha kile watu wengi wanachofikiria wanapoongeza kanuni inayoingia kwa mlango 53:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

Kanuni inayoingia inayohitaji mlango wa lengo 53 inaelezea trafiki inayoelekezwa kwa msikilizaji wa DNS anayeendesha kwenye mwenyeji, na hiyo ni huduma tofauti kabisa. Anwani hizo ni mifano ya nyaraka, na mlango wa chanzo huchaguliwa na mteja kwa kila swali, kwa hiyo si thamani ambayo unaweza kunakili kwenye kanuni na kutarajia iendelee kufanya kazi.

Ukingo usio na hali dhidi ya kinga ya mwenyeji yenye hali

Kichujio cha ukingo kisicho na hali hutathmini kila pakiti inayoingia dhidi ya orodha yake ya kanuni bila jedwali la miunganisho nyuma yake. Swali la kutoka lililofanikiwa kutoka halitengenezi idhini yoyote kwa jibu lake linaloingia, kwa sababu kifaa hakina rekodi kwamba swali limewahi kutokea. Kinga ya mwenyeji yenye hali ni kinyume: ufuatiliaji wake wa miunganisho hutambua trafiki ya kurudi ya mabadilishano yaliyoruhusiwa na kuipitisha bila kanuni ya jibu. Mipaka yote miwili ipo kwenye njia ya kawaida, na zote mbili lazima ziruhusu pakiti inayokusudiwa.

Ulinganisho ni muhimu kwa sababu vifaa viwili vinashindikana kwa namna tofauti. Kinga yenye hali inayokataa jibu hurekodi kutupwa; ukingo usio na hali hukataa kimya, ndiyo sababu mwenyeji hufikia muda wa mwisho.

Jenga idhini kuzunguka itifaki, si namba ya mlango

Weka kikomo cha kanuni kwa anwani halisi za kisuluhishi, mwenyeji wa lengo na sera ya mlango wa kupokea inayoungwa mkono na bidhaa. Kumbuka pia njia ya TCP ya DNS, kwa sababu jibu kubwa au kurudi nyuma kwa sababu ya kukatwa huhamisha mabadilishano kwenda TCP na kanuni ya UDP pekee haitayafunika. Ikiwa ukingo unatumia ukaguzi wenye hali kwa mtiririko ulioainishwa, upendelee badala ya kanuni ya jibu iliyoandikwa kwa mkono, kwa sababu njia yenye hali hufuata milango iliyochaguliwa na mteja kiotomatiki.

Kisha thibitisha ni bidhaa gani kwenye njia inayochuja trafiki kwa kweli. Wigo wa ukingo wa IPv4 ulioandikwa hautengenezi sera ya IPv6, na trafiki ya ndani ya mtoa huduma huenda isipite kamwe kwenye kichujio kimoja.

Kwa nini kuruhusu mlango wowote wa chanzo 53 si suluhisho

Kanuni inayokubali chochote kinachodai mlango wa chanzo 53 ni kanuni inayokubali kile mtumaji anaandika kwenye sehemu ya kichwa. Namba ya mlango haithibitishi mtumaji na haithibitishi kwamba mzigo ni jibu halali, kwa hiyo kanuni hupanua mfiduo wa mwenyeji bila kufanya utatuzi kuwa wa kuaminika zaidi. Weka vizuizi vya chanzo na weka ukaguzi wa jibu wa mteja mwenyewe, ikiwa ni pamoja na ubadilikaji wa mlango wa chanzo, badala ya kuzima ili kurahisisha orodha ya ufikiaji.

Ikiwa kisuluhishi ni huduma unayodhibiti, kuweka kikomo kwa anwani zake kunatosha. Ikiwa ni kisuluhishi cha umma, weka kikomo kwa anwani ulizozidhinisha na uzitaje kwenye maoni ya kanuni.

Thibitisha kwenye mpaka sahihi, kwa mwelekeo sahihi

Nasa kwenye mwenyeji na kwenye ukingo kwa swali lile lile, na linganisha tuples badala ya hesabu za pakiti. Swali linaloonekana pande zote mbili bila jibu linaloonekana upande wa mwenyeji linaelekeza kwenye kichujio kinachoingia; swali linaloonekana upande wa mwenyeji pekee linaelekeza kwenye uelekezaji au kisuluhishi chenyewe. Rudia kwa swali la TCP ikiwa una idhini ya UDP pekee, kwa sababu hiyo ndiyo pengo ambalo jaribio la kwanza haliwezi kuliona.

Kurekebisha hili hukamilisha mabadilishano ya DNS ambayo mwenyeji anayahitaji kwa kweli. Haimfanyi mwenyeji kuwa kisuluhishi cha umma, hairuhusu mitiririko ya VPN iliyopelekwa mbele, na haithibitishi kwamba DNS ndiyo ilikuwa sababu ya tatizo la handaki lisilohusiana.