NAT ya hairpin: kwa nini kituo cha mwisho cha VPN kinashindwa kutoka ndani

Seva ya VPN inayojibu kutoka mtandao wa simu lakini inashindwa kutoka kwenye kochi kwa kawaida si tatizo la cheti. Mteja aliye ndani ya LAN anaomba kipanga njia kutafsiri pakiti ambayo lengo lake ni anwani ya umma ya kipanga njia yenyewe, kumaanisha pakiti lazima itoke na kurudi ndani mara moja. Ujanja huo unaitwa hairpinning, na vipanga njia vingi ama havitekelezi au hufanya hivyo tu wakati kisanduku cha kuteua kimewashwa. Kufaulu kwa jaribio la nje ndiko kunakochanganya, kwa sababu kunathibitisha kuwa msikilizaji na kanuni ya upelekaji ni sahihi.

Pakiti inatoka na kurudi ndani

Fuatilia pakiti. Mteja hutatua jina la umma, huunganisha na anwani ya umma, na NAT ya lengo la kipanga njia huandika upya lengo kuelekea seva ya ndani. Jibu la seva linaelekezwa kwenye anwani ya LAN ya mteja, kwa hivyo hurudi kupitia kiolesura cha LAN cha kipanga njia bila kamwe kupita kanuni ya NAT ambayo ingetafsiri chanzo kurudi.

Sasa mteja hupokea pakiti kutoka anwani ambayo hakuwahi kutuma chochote, na huitupa. Utengano huo ndio hitilafu yote.

RFC 4787 inaeleza tabia inayotarajiwa kutoka kwa NAT katika hali hii, na toleo fupi ni kwamba kwa vitendo ni hiari hata pale inapobainishwa kinadharia. Vipanga njia vingine huita mpangilio huo NAT loopback, vingine huita hairpin NAT au NAT reflection, na vingine havionyeshi chochote. Kipanga njia kisichokuwa nacho hakijasanidiwa vibaya; kinafanya jambo la kawaida, na suluhisho linahusu mahali pengine. Usihitimishe kutokana na jaribio la ndani lililoshindwa kwamba kanuni ya upelekaji wa umma ni mbaya.

Ukaguzi 1: jaribu njia mbili kwa kutenganisha

Kutoka nje ya LAN, ungana na wasifu uleule ambao mtumiaji halisi angetumia na uthibitishe kuwa kikao kinaundwa. Kutoka ndani, ungana na anwani ya umma kwa wasifu uleule na uandike hitilafu kamili na muda.

Jaribio mahususi la ndani huhifadhi jina la mwenyeji na hubadilisha anwani pekee: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ hutuma ombi kwenye anwani ya umma huku likiwasilisha jina sahihi la seva. Hiyo hutenganisha tatizo la utatuzi wa majina na tatizo la utafsiri, ambayo huchanganywa kwa urahisi wakati jina lilelile linafanya kazi kutoka mgahawa. Kumbuka kama mteja anashindwa kwenye muunganisho wa TCP au baadaye kwenye TLS, kwa sababu la kwanza linaelekeza kwenye utafsiri na la pili kwenye utambulisho.

Ukaguzi 2: soma kile seva inachokiona

Uchunguzi wenye manufaa zaidi ni mtazamo wa seva. Endesha ukamataji kwenye mwenyeji wa VPN uliochujwa kwa anwani ya LAN ya mteja na kwa anwani ya LAN ya kipanga njia, kisha rudia jaribio la ndani. Ikiwa hakuna kinachofika, pakiti haikunusurika utafsiri.

Ikiwa muunganisho unafika kutoka anwani ya LAN ya kipanga njia badala ya ile ya mteja, hairpinning inatokea na chanzo kiliandikwa upya. Hii ni usanidi unaofanya kazi, si hitilafu.

Ukaguzi 3: rekebisha bila kugusa njia ya nje

Kuna aina tatu zinazotumika, kwa mpangilio unaoongezeka wa athari. Nyembamba zaidi ni DNS iliyogawanywa: chapisha rekodi ya ndani ili jina lilelile la seva litatuliwe kwa anwani ya ndani kwa wateja wa LAN, jambo ambalo huepuka kabisa njia ya umma. Inayofuata ni kuwasha chaguo lililoandikwa la loopback au reflection la kipanga njia, ikiwa linapatikana, na kulitumia kwa huduma hii pekee. Pana zaidi ni kanuni ya source-NAT kwenye kipanga njia inayoandika upya trafiki kutoka LAN kuelekea seva ili jibu lirudi kupitia kipanga njia; kwenye kipanga njia cha Linux hiyo ni kanuni MASQUERADE katika POSTROUTING inayolingana na anwani na bandari ya seva. Zote tatu zinaacha njia ya nje ikiwa haijaguswa, na hiyo ndiyo sifa inayopaswa kuhifadhiwa.

Usipanue upelekaji wa bandari usiohusika ili njia ya ndani ifanane na ya nje, na usihamishe huduma kwenda bandari nyingine ili kuepuka tatizo. Mabadiliko yote mawili hubadilisha kile ambacho ulimwengu wa nje unaweza kufikia ili kurekebisha kitu ambacho ulimwengu wa ndani pekee unaona.

DNS iliyogawanywa ina mtego mmoja unaostahili kutajwa. Kubadilisha jina la mwenyeji na IP ya kiholela hubadilisha kile mteja anathibitisha, kwa hivyo rekodi ya ndani lazima bado ilingane na jina kwenye cheti.

Ukaguzi 4: baadaye thibitisha njia zote mbili

Rudia jaribio la nje kutoka nje ya LAN, rudia jaribio la ndani kwa wasifu uleule, na uthibitishe kuwa kumbukumbu ya seva inaonyesha vikao viwili tofauti vilivyofanikiwa na si mafanikio moja na ukimya mmoja. Kisha angalia kuwa wateja wengine bado wanafikia msikilizaji na kwamba njia za rasilimali za kibinafsi hazijabadilika.

Weka kumbukumbu fupi: ni anwani gani kila mteja alitumia, seva iliona nini, na ni rekebisho gani kati ya matatu yaliyotumika. Mahitaji ya hairpinning ya RFC 4787 ni rejeleo la kile kinachotarajiwa kutoka kwa NAT hapa, na yanaeleza kwa nini kipanga njia kisichokuwa na kipengele hiki hufanya kwa kawaida. Kushindwa kwa ndani ambako ulimwengu wa nje hauwezi kuiga ni swali la utafsiri hadi kinyume chake kithibitishwe, kwa hivyo jaribu hivyo.