Uchapishaji wa bandari za Docker na vyanzo vya VPN: mianya miwili unayoikosa

Kanuni inasema ruhusu anwani ya seva ya VPN kwenye huduma iliyochapishwa, na bado muunganisho unakatika. Matokeo hayo ni ya kawaida, na si hitilafu ya Docker. Mianya miwili tofauti si sahihi: chanzo ulichoandika huenda si chanzo ambacho mwenyeji hupokea, na bandari uliyoandika huenda si bandari ambayo kichujio huona. Kurekebisha yote mawili kunahitaji kuangalia njia ya pakiti badala ya mchoro wa huduma.

Hadithi: ruhusu seva ya VPN na umemaliza

VPN iliyoelekezwa inaweza kuhifadhi anwani ya handaki ya mteja hadi mwenyeji wa Docker. Lango linalofanya tafsiri ya chanzo linaweza kubadilisha anwani hiyo na yake. Miundo yote miwili ni halali, na hutoa vyanzo tofauti kwa kitendo kimoja cha mtumiaji.

Kwa hiyo kifungu IP ya seva ya VPN kinaeleza dhana, si uchunguzi. Hadi ujue ni muundo upi kati ya huo miwili ulio mbele yako, kanuni ni dhahania.

Chanzo: dimbwi la wateja au lango lililotafsiriwa

Angalia mambo manne kwa mpangilio. Kwanza, dimbwi la anwani za wateja, kwa mfano 10.90.0.0/24. Pili, kama lango hutafsiri dimbwi hilo kabla ya kufika kwa mwenyeji. Tatu, chanzo ambacho mwenyeji huona kwa kweli kwa muunganisho mmoja mpya. Nne, kama uthibitishaji wa programu hutofautisha watumiaji binafsi, kwa sababu anwani ya tafsiri inayoshirikiwa haiwezi.

Ikiwa dimbwi litahifadhiwa, kanuni inayolingana na anwani ya umma ya lango pekee itakosa kila mteja. Ikiwa lango hutafsiri kwa kusudi, kuruhusu anwani iliyotafsiriwa kunamwingiza kila mtumiaji aliye nyuma yake, jambo ambalo linaweza kukubalika kwa huduma yenye kuingia yake yenyewe na halikubaliki kwa kitu kingine chochote.

Bandari: DNAT hubadilisha namba unayolinganisha

Katika uchapishaji wa kawaida wa daraja la Linux pamoja na iptables ya Docker, ramani ya mwenyeji kutoka 8443 hadi bandari ya kontena 443 hutafsiriwa kabla kichujio cha upelekaji hakijaanza. Pakiti hufika kwa kichujio ikiwa na bandari ya lengo 443. Kanuni inayolingana na 8443 wakati huo haiwashi kamwe, ingawa 8443 ndiyo mteja aliyoandika.

Bandari iliyochapishwa bado ipo katika ufuatiliaji wa miunganisho, ndiyo sababu lengo la awali linaweza kulinganishwa hapo unapohitaji kwa dhati.

Amua ni namba ipi inayoeleza kusudi. Linganisha bandari ya kontena baada ya DNAT wakati kanuni inalinda huduma ndani ya kontena. Linganisha lengo la awali kwa chaguo la conntrack wakati kanuni inapaswa kueleza kile mteja alichoomba, na kubali gharama ya ziada ya kulinganisha na uangalifu wa mpangilio wa kanuni unaokuja na hilo.

Mnyororo: DOCKER-USER, si INPUT

Mwongozo wa iptables wa Docker unaweka sera ya upelekaji ya mtumiaji katika mnyororo wa DOCKER-USER, ambao hutathminiwa kabla ya kanuni za upelekaji za Docker yenyewe. Kanuni iliyonakiliwa kutoka huduma ya mwenyeji hadi mnyororo wa INPUT huchuja trafiki inayoelekezwa kwa mwenyeji, si trafiki inayopelekwa kwenye kontena. Hitilafu hiyo hutoa kanuni inayoonekana sahihi na isiyo na athari yoyote kwenye njia ya kontena.

Weka pamoja katika kanuni moja masafa ya chanzo, bandari ya lengo inayofanya kazi, itifaki na kiolesura cha kuingia. Ruhusa ya chanzo pekee kwa kila lengo linalopelekwa ni pana kuliko kuruhusu huduma moja iliyochapishwa.

Thibitisha kwa miunganisho mipya

Jaribu pande zote mbili kwa miunganisho mipya: mteja mmoja wa VPN aliyeruhusiwa na chanzo kimoja kinachopaswa kubaki kimekataliwa. Hali ya muunganisho iliyopo inaweza kuendeleza kipindi kuwa hai baada ya sera kubadilika, kwa hiyo muunganisho wa zamani hauthibitishi chochote kuhusu kanuni mpya. Kisha angalia njia ya jibu, kwa sababu kontena bado linapaswa kuelekeza njia kurudi kwenye chanzo kinacholiona.

Mpangilio wa mnyororo na tabia ya tafsiri ya bandari nyuma ya ukaguzi huu imeandikwa katika mwongozo wa iptables wa Docker. Isome kabla ya kunakili mapishi, na thibitisha backend ipi Docker iliyosakinishwa inatumia, kwa sababu backend ya nftables huunganisha sera kwa namna tofauti.