Kontena haifikii API inayopatikana kwa VPN pekee? Ipe proksi kwenye mwenyeji

Huduma yako ya Compose inaisha muda dhidi ya API ambayo kivinjari kwenye mashine hiyo hiyo huifungua bila malalamiko yoyote. Tofauti hiyo ndiyo kidokezo: ombi linalofanya kazi linatoka kwa mwenyeji mwenye handaki la VPN, na ombi linaloning'inia linatoka kwa kontena lenye mrundikano wake wa mtandao. Hakuna kitu ndani ya kontena kinachojua njia za handaki, kwa hivyo lengo la kibinafsi linabaki lisilofikika jinsi yoyote jina linavyoandikwa. Suluhisho ni kuruka kwa makusudi kupitia mwenyeji, si jedwali la njia lenye werevu zaidi.

Anza na kwa nini njia mbili zinatofautiana, kisha amua handaki linapaswa kuishi wapi.

Kwa nini mwenyeji anafanya kazi na kontena haifanyi

Kuinua handaki kunampa mwenyeji kiolesura, seti ya njia na, kwa kawaida, ingizo la kitatuzi linalotolewa na VPN. Kontena hurithi hakuna chochote cha hayo: huanza na kiolesura kimoja kwenye daraja la injini na njia chaguo-msingi inayoelekea daraja hilo. Njia zilizosakinishwa kwenye mwenyeji hazionekani kwa chochote kinachofanya kazi ndani ya nafasi hiyo ya majina.

Ndiyo sababu dalili zinaonekana zisizolingana badala ya kuvunjika tu. Mwenyeji hutatua jina la kibinafsi na kuunganisha, kwa sababu jina na njia zote zipo hapo. Kontena hutuma pakiti yake kwa anwani ya kibinafsi ambayo hakuna kitu kwenye njia ya daraja linaweza kufikia, na ombi linaisha muda. Kuongeza jina kwenye faili ya hosts ya kontena hakubadilishi chochote, kwa sababu anwani yenyewe haifikiki kutoka mahali kontena ilipo.

Fikia mwenyeji kutoka ndani ya kontena

Mchakato ndani ya kontena unaopiga localhost unapiga kontena. Docker Desktop huchapisha host.docker.internal kama jina linaloelekea nyuma kwenye mashine inayoendesha injini; injini za Linux huiacha isijulikane isipokuwa huduma iombe, na ndivyo ramani iliyo hapa chini inavyofanya. Kwa hilo, programu inalenga jina na bandari badala ya anwani ya kibinafsi.

services:
  app:
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      INTERNAL_API_HOST: "host.docker.internal:8666"

Handaki linabaki upande wa mwenyeji wa kuruka huku, na bandari katika kigezo hicho ni ile ambayo proksi itasikiliza. Kontena linalopoteza handaki sasa linashindwa kwenye kuruka kumoja kunayojulikana badala ya kujaribu njia ambayo halikuwa nayo kamwe.

Chagua handaki linaishi wapi

Maumbo matatu yanawezekana kwa huduma ya Compose inayohitaji API ya kibinafsi, na yanatofautiana kwa mchakato upi unamiliki handaki. Mteja wa VPN anaweza kufanya kazi ndani ya picha ya kontena, jambo linalohitaji kufichua kifaa cha handaki na kutoa uwezo wa usimamizi wa mtandao unaoambatana na hilo. Programu inaweza kushiriki nafasi ya majina ya mtandao ya kontena lingine la handaki, kwa hivyo michakato yote miwili inaona mrundikano mmoja na jedwali moja la njia. Au handaki linaweza kubaki kwenye mwenyeji, likiwa na kipitishaji nyembamba kutoka kwa mwenyeji kwenda ndani ya kontena.

Mbili za kwanza huvuta faili za wasifu, tabia ya kuunganisha upya na sera ya kitatuzi ndani ya mradi, na hufanya kila huduma kwenye faili itegemee afya ya handaki. Hiyo ni muunganisho mwingi kwa mwito mmoja wa API. Kwa mrundikano wa maendeleo unaosoma nukta moja ya mwisho ya ndani, kipitishaji cha upande wa mwenyeji ni badiliko dogo zaidi ambalo bado huhifadhi vitambulisho mahali timu ya jukwaa inavyovisimamia.

Chapisha njia moja nyembamba kwenye mwenyeji

Anza na kile kipitishaji kinachorithi: kiendeshe chini ya akaunti inayomiliki handaki, na soketi zake za kutoka zitachukua njia za mwenyeji na kitatuzi cha mwenyeji. Sehemu moja ya location ya nginx inashughulikia njia moja.

server {
    listen 8666;
    location /search/ {
        proxy_pass http://10.20.30.40:8090/;
        proxy_set_header Host internal-api.example;
        proxy_read_timeout 60s;
    }
}

Chukulia anwani na bandari kama vibadala na uweke jozi ambayo API inasikiliza kweli. Kila upstream ya ziada inastahili sehemu yake ya location, na kila sehemu inapaswa kuruhusu njia tu ambazo huduma hii inaziita, ili proksi isiwe mlango wa jumla kwenye mtandao wa kibinafsi. Funga msikilizaji kwenye anwani ya daraja kwa wateja wanaokuja kupitia host-gateway, kwenye loopback tu wakati mteja anashiriki nafasi ya majina ya mtandao ya mwenyeji, na kamwe kwenye 0.0.0.0. Pia chagua bandari ambayo bado iko huru: nambari iliyochukuliwa tayari huiacha proksi bila kusikiliza wakati kontena linaendelea kuisha muda, jambo ambalo haliwezi kutofautishwa na hitilafu ya mtandao uliyoanza nayo.

Bandari, majina na uamuzi wa TLS

Utatuzi wa majina hugawanyika kama uelekezaji. Utafutaji wa umma wa kontena hupitia kitatuzi cha injini, kwa hivyo jina la kibinafsi linalotatuliwa kwenye mwenyeji halitatatuliwa ndani ya kontena. Proksi ni sehemu inayotatua jina la kibinafsi, kwa sababu hurithi kitatuzi cha mwenyeji.

TLS ni uamuzi unaoahirishwa na kisha kueleza hitilafu inayofuata. Ikiwa proksi inapitisha baiti bila kuzigusa, kontena linaona cheti cha API yenyewe na linahitaji CA ya ndani kwenye hifadhi yake ya uaminifu. Ikiwa proksi inamaliza TLS, uaminifu huo unahamia kwa mwenyeji na programu huanza kujenga viungo kutoka kwa kichwa cha host inachopokea. Chagua mpangilio mmoja na uutekeleze kwa kila rasilimali, kwa sababu uelekezaji upya unaotolewa na ule mwingine unaelekea jina la mwenyeji ambalo kontena haliwezi kulitulia.

Thibitisha kutoka ndani ya huduma

Tuma ombi kutoka kwa kontena, si kwa mwenyeji: curl ya kawaida kwenye njia ya proksi, kisha ukaguzi wa afya wa programu yenyewe. Wakati proksi inajibu lakini programu bado inashindwa, linganisha mambo matatu: URL ya msingi inayoijenga, kigezo chochote cha proksi katika mazingira yake, na CA inayoiamini. Yote yako katika mazingira na kumbukumbu za kontena, na kurekebisha yoyote kati yao kunaiacha VPN kwa utulivu.

Andika mpangilio uliochaguliwa kwenye README ya mradi wakati bado ni mbichi. Vinginevyo mtu anayefuata kukutana na muda huu wa kuisha atatumia mchana huo huo kugundua upya kwamba handaki linaishi kwenye mwenyeji.