Kontena ya Docker haifikiki kupitia VPN? Linganisha subneti

Kontena hujibu kwenye LAN ya ofisi, kisha huacha kujibu wakati VPN ya kampuni inapounganishwa. Hakuna kilichobadilika ndani ya kontena: hakuna kuwasha upya, hakuna kusasisha picha, hakuna kuhariri usanidi. Kilichobadilika ni jedwali la uelekezaji la mwenyeji, ambapo njia iliyoongezwa na handaki sasa inashughulikia anwani ambayo Docker ilitoa. Kabla ya kuhariri subneti au kuomba msamaha wa VPN, weka mipango yote miwili ya anwani kando, kwa sababu ukarabati huhitaji muda tofauti sana.

Soma njia kabla ya kubadilisha usanidi

Anza na mtandao ambao Docker aliunda kwa hakika. Kizuizi cha IPAM ni mpango wa anwani, na subneti ni mstari unaojaliza:

docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]

Compose hugawa /16 kwa kila mradi mpya kwa chaguo-msingi, kwa hivyo huduma mbili zinaweza kukaa ndani ya kiwango cha anwani 65,536. Upana huu ndio sababu mwingiliano ni wa kawaida: /16 iliyochaguliwa kwa bahati nasibu ni kubwa vya kutosha kumeza tovuti unayoifikia kupitia handaki, na hakuna anayegundua hadi handaki linapoinuka.

Kisha linganisha uchaguzi wa njia kwa anwani moja ya kontena, mara moja handaki likiwa limezimwa na mara moja likiwa limewashwa:

ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1

Maumbo mawili ya jibu hupeleka mahali tofauti. Ikiwa matokeo yanataja tun0, wg0 au kifaa kingine cha handaki, kiambishi cha VPN ni mahususi kwa kiwango sawa na njia ya daraja na kifurushi hakifikii kontena kamwe. Ikiwa bado inataja daraja, mwenyeji anaweza kufikia kontena, na hitilafu yako ni uchujaji, DNS au njia ya kurudi inayoshindwa upande mmoja tu.

Kwa nini mgongano wa /16 ni rahisi kupatikana

Docker huchukua mitandao ya daraja kutoka kwa hifadhi za kibinafsi, na hifadhi ya chaguo-msingi inatoka kwenye kizuizi cha 172.16.0.0/12 katika vipande vya /16. Mitandao ya mashirika mara nyingi hutumia nafasi hiyo hiyo ya kibinafsi, na VPN ya ufikiaji wa mbali inasukuma viambishi hivyo kwa kila mteja anayeunganisha. Wakati pande zote mbili zinaamini zinamiliki 172.18.0.0/16, jedwali moja la uelekezaji hushikilia madai mawili yanayopingana.

Urefu wa kiambishi huamua mshindi, sio mpangilio wa njia. Handaki linalosukuma 10.0.0.0/8 haliwezi kushinda njia ya daraja ya 172.18.0.0/16, kwa sababu /8 ni mahususi kidogo. Handaki linalosukuma 172.18.0.0/16, au 172.18.5.0/24 ndani yake, hushinda. Ndio sababu kompyuta mpakato moja hufanya kazi kwenye mtandao wa ofisi na kushindwa kwenye Wi-Fi ya hoteli na VPN hiyo hiyo: mteja hupokea viambishi tofauti.

Jedwali hilo hilo linasimamia upande mwingine. Kontena inayohitaji mwenyeji wa ndani kwenye 10.8.4.20 hutuma kifurushi kwa lango lake la daraja, na mwenyeji kisha huelekeza kwenye handaki. Njia hiyo kwa kawaida hufanya kazi kwa sababu mwenyeji hufanya NAT, lakini hushindwa wakati upande wa shirika unakubali anwani ya VPN ya kompyuta mpakato pekee, au wakati uchujaji wa njia ya kurudi unatupa jibu lisilo lingana.

Linganisha ukarabati tatu

Kuna njia tatu tu za kutoka, na zinatofautiana kwa nani anapaswa kuziidhinisha na kile kinachovunjika unapotumia moja.

Kuorodhesha upya ni ukarabati pekee unaoweza kukamilisha bila tiketi, ndio sababu maandishi mengi huishia hapo. Ni bei ndogo kwenye mradi mchanga na ni ghali mara chombo cha uhamishaji au mfuatano wa muunganisho uliohifadhiwa unapoelekeza kwenye anwani halisi. Hesabu marejeo hayo kabla ya kuhariri YAML, sio baada.

Msamaha kutoka kwa handaki ni jibu safi zaidi wakati mwingiliano uko katika kiwango ambacho kampuni yako inamiliki kwa hakika. Pia ni wa polepole zaidi, na hauna maana kwa mkandarasi asiyeweza kubadilisha wasifu wa mteja. Lango lililochapishwa au proksi ndogo ya kurudi huepuka mzozo: mteja huzungumza na anwani ambayo handaki tayari inaelekeza ipasavyo, na lango hilo pekee linapaswa kufikiwa.

Bainisha kiwango kwa makusudi

Kwa mradi mmoja, tangaza subneti kwenye faili ya compose ili mradi uache kuchukua kutoka hifadhi inayoshirikiwa:

networks:
  default:
    ipam:
      config:
        - subnet: 10.201.7.0/24

Chukua kiwango hicho kutoka kwa rejista ambayo timu yako inaitunza, sio kutoka kwa mfano ulioupata wakati wa kutafuta. Iangalie dhidi ya viambishi ambavyo VPN inasukuma, LAN za nyumbani ambako watu hufanya kazi, na mitandao mingine ya kontena kwenye mwenyeji huyo huyo. Kisha panga uundaji upya, kwa sababu mtandao uliopo unabakiza subneti yake ya zamani: docker compose down, kisha up -d. docker network rm hukataa wakati vituo vya mwisho vimeunganishwa, na kila ingizo la ipv4_address kwenye faili lazima liwe ndani ya kiwango kipya.

Kwa mitandao ambayo Docker huunda yenyewe, weka hifadhi ya daemon katika /etc/docker/daemon.json:

{
  "default-address-pools": [
    { "base": "10.201.0.0/16", "size": 24 },
    { "base": "10.202.0.0/16", "size": 24 }
  ]
}

Hifadhi hiyo inatumika kwa mitandao iliyoundwa baada ya daemon kuwashwa upya, na madaraja yaliyopo tayari hubakiza anwani zake. Hiyo ni rahisi na ni rahisi kusahau, kwa hivyo chukulia mradi wa zamani kama bado unagongana hadi mtu auunde upya mtandao wake. nyaraka za mtandao za injini za Docker zinaeleza kanuni za ugawaji ikiwa unahitaji kutetea hifadhi kwenye ukaguzi.

Daraja la Linux na Docker Desktop hushindwa tofauti

Kwenye mwenyeji wa Linux, kontena hukaa juu ya madaraja katika nafasi ya majina ya mwenyeji. Jedwali moja huamua kila kitu, kwa hivyo ulinganisho wa juu ni hadithi yote: soma njia ya daraja, soma njia ya handaki, na uone ipi inashinda kwa anwani halisi ya kontena.

Docker Desktop huweka kontena nyuma ya VM yenye NAT yake. Mwenyeji hana njia yoyote ya kufikia anwani ya kontena; hufikia huduma kupitia lango lililochapishwa, kwa kawaida limefungwa kwa 127.0.0.1. Kwa hivyo mteja wa VPN anaweza kuvunja huduma bila mwingiliano wowote wa subneti: ama kwa kusakinisha njia kwa kiwango cha ndani cha VM au kwa kuzuia trafiki ya loopback wakati handaki limeunganishwa. Ikiwa ip route get kwenye mwenyeji inaripoti hakuna njia kwa anwani ya kontena, hiyo inatarajiwa na sio hitilafu.

Matokeo ya kiutendaji ni mahali unapoangalia kwanza. Kwenye Linux, anza na jedwali la uelekezaji. Kwenye Desktop, anza na lango lililochapishwa na kanuni za firewall za mteja wa VPN, kisha angalia kama subneti ya ndani ya VM inagongana na kitu ambacho handaki inasukuma.

Thibitisha handaki likiwa limewashwa

Unganisha upya VPN mara mbili kabla ya kusema imerekebishwa, kwa sababu wasifu unaosukuma njia wakati wa kuunganisha na kuziondoa wakati wa kukataa unaweza kuonekana sawa baada ya jaribio la kwanza. Kisha endesha ukaguzi ambao mteja hufanya kwa hakika:

1. ip route get kutoka kwa mwenyeji, ukitumia anwani halisi ya kontena.
2. Ombi kutoka kwa kontena lingine, kuthibitisha kuwa huduma yenyewe ni nzuri.
3. curl -sv http://127.0.0.1:8080/ kutoka kwa mteja handaki likiwa limewashwa, kisha traceroute -n kwa anwani ya kontena kutoka kwa mashine iliyo kwenye LAN.
4. sysctl net.ipv4.conf.all.rp_filter ikiwa ombi linafika kwa mwenyeji lakini jibu linapotea.

Mwisho, andika kiwango kilichochaguliwa kwenye rejista hiyo hiyo uliyotumia kukichagua, pamoja na tarehe na mradi unaokimiliki. Mwingiliano unaofuata utatoka kwa mradi ambao hakuna aliyekuandika, na ulinzi pekee ni kwamba kiwango kilihifadhiwa kwa makusudi badala ya kuchukuliwa kwa bahati nasibu.