Kwa nini kontena la macvlan haliwezi kumjibu mteja wa VPN

Fikiria mwenyeji wa Linux anayemaliza VPN na wakati huo huo anaendesha kontena kwenye mtandao wa macvlan. LAN ni 192.168.60.0/24, kontena lina 192.168.60.210, na wateja wa VPN wanakuja kutoka 10.95.0.0/24. Mteja anafika kwenye huduma, jibu halirudi kamwe, na kila kanuni ya firewall kwenye mwenyeji inaonekana sahihi. Vikwazo viwili tofauti hutengeneza dalili hiyo, na kurekebisha kimoja huacha kingine mahali pake.

Vikwazo viwili, dalili moja

Kikwazo cha kwanza ni utengano: dereva wa macvlan wa Docker hairuhusu kontena kuzungumza na mwenyeji wake mwenyewe kupitia kiolesura cha mzazi. Trafiki kati ya stack ya mwenyeji na kontena haina njia, bila kujali jinsi njia za mwenyeji zilivyoandikwa.

Kikwazo cha pili ni njia ya kurudi. Lango la msingi la kontena kwa kawaida ni router ya LAN, kwa hiyo jibu lililoelekezwa kwa mteja wa VPN linatoka kupitia router hiyo. Ikiwa router haina njia ya kurudi kwenye bwawa la VPN, jibu linatupwa mahali fulani katikati.

Hitilafu hizo mbili zinaonekana sawa kutoka kwa mteja: ombi linalofika na jibu lisilofika kamwe. Zinahitaji matengenezo tofauti, na kanuni pana ya masquerade inaweza kuficha ni ipi ambayo bado imeharibika. Ndiyo sababu jaribio la kwanza ni kunasa upande wa kontena badala ya mabadiliko mengine ya firewall. Ikiwa ombi halionekani huko kamwe, kikwazo cha utengano ndicho kinachofanya kazi.

Jenga shim upande wa mwenyeji, kwa ufinyu

Kiolesura cha pili cha macvlan kwenye mwenyeji, kilichounganishwa na mzazi yule yule katika hali ya daraja, kinampa stack ya mwenyeji utambulisho wake katika sehemu hiyo ya LAN. Hifadhi anwani nje ya bwawa la DHCP na nje ya safu ya kontena kwa ajili yake, na pitisha kontena pekee kupitia hiyo.

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

Amri ya kwanza inaunda kiolesura katika hali ya daraja, ambayo ni chaguo-msingi lililoandikwa kwa dereva huyu na hali unayotaka kwa trafiki kati ya mwenyeji na kontena. Ya pili inagawa /32 ili anwani isigongane na kiambishi cha LAN, na ya nne inatuma anwani ya kontena pekee kupitia shim.

Usielekeze LAN yote kupitia kiolesura kipya. Njia ya kawaida iliyounganishwa inabaki kama ilivyo, na njia ya mwenyeji kwa makusudi ni nyembamba ili kontena moja lipate njia bila sehemu nyingine ya kanda kubadilisha tabia yake. Njia ya msingi inayoelekea shim ingekuwa muundo mwingine wenye matokeo mengine. Iweke mahususi na eneo la uharibifu linabaki dogo.

Amri hizi zinabadilisha mipangilio ya mtandao kwenye mwenyeji unaoendesha. Kwenye kifaa au jukwaa linalosimamiwa, tumia utaratibu wa usanidi unaoungwa mkono na jukwaa hilo, kwa sababu mabadiliko ya mwingiliano katika root-shell yanaweza yasiendelee baada ya uboreshaji.

Amua jinsi chanzo kinahifadhiwa

Shim ikiwa mahali pake, kontena linaweza kufikia mwenyeji, na swali linakuwa ni anwani gani ya chanzo jibu linabeba. Kuhifadhi chanzo asili cha VPN ni modeli safi zaidi: kontena linaona anwani halisi ya mteja, na kumbukumbu na kanuni za ufikiaji za huduma zinaweza kuitumia.

Ili hiyo ifanye kazi, usanidi wa mtandao wa kontena lazima utume trafiki ya 10.95.0.0/24 kwenda 192.168.60.250 kama lango lake kwa njia hii. Hiyo ni mpangilio wa njia au lango unaoungwa mkono ndani ya usanidi wa kontena lenyewe, si hila upande wa mwenyeji. Thibitisha kutoka ndani ya kontena badala ya kudhani kuwa mpangilio umeanza kutumika. Lango la msingi ambalo bado linaelekea router ya LAN litaendelea kutuma majibu kwenye shimo lile lile.

Ikiwa muundo ulioidhinishwa unaficha vyanzo vya VPN badala yake, punguza tafsiri kwa ufinyu: bwawa halisi la VPN, shim kama kiolesura cha kutoka, na kontena na huduma mahususi.

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

Oanisha shim kama kiolesura cha kutoka, si handaki. Kanuni inayotaja handaki kama kiolesura cha kutoka haitalingana na pakiti inayoelekea kontena, na hilo ndilo kosa ambalo mpangilio wa aina hii kwa kawaida huwa nalo. Weka kanuni nyembamba kama sentensi iliyo juu na ikague tena bwawa linapobadilika.

Thibitisha kutoka kwa mteja, si kwa mwenyeji

Ombi kutoka kwa mwenyeji mwenyewe, lililofungwa kwa anwani ya shim, linathibitisha kwamba shim inaweza kufikia kontena. Halithibitishi kwamba kontena linaweza kurudisha trafiki kwenye chanzo kilichohifadhiwa 10.95.0.x, kwa sababu anwani ya chanzo katika jaribio hilo ni ya shim yenyewe.

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

Amri ya kwanza inajaribu sehemu ya mwenyeji hadi kontena, na ya pili inaonyesha kile kinachopita kwenye shim kweli wakati mteja halisi wa VPN anafanya ombi. Angalia anwani ya chanzo kwenye njia ya kuingia na kama jibu linaonekana na mtiririko huo huo.

Usambazaji lazima uwe umewezeshwa kwenye mwenyeji, na njia ya usambazaji inahitaji ruhusa kwa bwawa la VPN kuelekea shim kwenye bandari ya huduma pamoja na majibu yaliyoimarishwa. Kanuni ya INPUT kwenye mwenyeji hairuhusu trafiki inayosambazwa, na hiyo ni sababu ya kawaida ya pakiti kutupwa baada ya uelekezaji kuonekana sahihi.

Endesha programu halisi na vitambulisho halisi, kisha angalia kwamba huduma ya pili, isiyohusiana, kwenye kontena lile lile bado inakukataa. Ikiwa njia pekee ya kuifanya ifanye kazi ilikuwa kufungua kila kanuni ya usambazaji, muundo haujakamilika. Kumbuka pia ni anwani gani ya chanzo ambayo huduma ilirekodi, kwa sababu hiyo ndiyo kanuni zake za ufikiaji zitatakazotumia kuanzia sasa.