HAProxy 302 kwa programu ya kibinafsi: nani anafungua hatua ya pili?

Mtu anaelekeza mwenyeji wa umma wa HAProxy kwenye programu ya ndani na kuuliza kwa nini kivinjari hakiwezi kufuata. Proksi hufikia programu kupitia VPN yake, uelekezaji upya hurudisha kichwa cha Location, na kivinjari hukijaribu anwani ambayo ipo ndani ya handaki tu. Kutoka nje, ukurasa hukwama tu. Uamuzi unahusu upande gani unafungua muunganisho wa pili, na hilo ndilo linalotenganisha uelekezaji upya na backend.

Njia mbili zinazofanana kwenye usanidi

Uelekezaji upya humaliza mabadilishano kwa jibu. Mteja husoma Location na kuanzisha ombi jipya kutoka mahali alipo, yaani mtandao ambao hukuwahi kuudhibiti. Proksi haihusiki tena. Kila kinachofuata hutegemea DNS, njia na uaminifu wa mteja mwenyewe, kwa hiyo matokeo hutofautiana kulingana na mahali mtumiaji alifungua kivinjari:

GET /app        client -> proxy
302 Location    proxy  -> client   (http://10.40.0.20:8080/)
GET /app        client -> 10.40.0.20:8080   client network, no route

Backend ya proksi huweka hatua ya pili upande wa seva. Proksi huifungua kwa njia ambayo tayari inayo, na mteja huendelea kuzungumza na jina moja la umma. Ikiwa handaki litakatika, mteja hupokea hitilafu badala ya URL ambayo hawezi kuifuata. Tofauti hiyo pia ndiyo inayofanya hitilafu iweze kutambulika, kwa sababu hitilafu huonekana mahali kumbukumbu zilipo:

GET /app        client -> proxy
GET /app        proxy  -> 10.40.0.20:8080   over the VPN
response        proxy  -> client

Nyaraka za uelekezaji upya za HAProxy huchora mstari huu hasa: kumjibu mteja kwa uelekezaji upya ni kitendo tofauti na kupeleka ombi kwa backend. Maagizo mawili yako mistari michache mbali kwenye faili ya usanidi na hayafanyi kazi sawa hata kidogo. Moja humaliza ombi, lingine huanzisha ombi la pili ambalo proksi inamiliki.

Kile kivinjari kinachohitaji ambacho VPN ya seva haitoi

Ombi la kivinjari lenyewe linahitaji vitu vinne ambavyo huenda havina: jibu la DNS kwa jina la kibinafsi, njia ya kufikia anwani hiyo, ruhusa ya kufikia huduma inayosikiliza, na uaminifu kwa cheti chochote ambacho huduma hiyo inawasilisha. Mwenyeji wa proksi anavyo vyote vinne kupitia handaki yake. Hakuna kimoja kinachohamishwa kwa mteja ambaye hakuwahi kuwa kwenye handaki hilo, kwa sababu handaki ni sifa ya mwenyeji, si ya URL.

Pengo hilo linaeleza dalili ya «karibu ifanye kazi». Ombi la kwanza linafanikiwa, upau wa anwani hubadilika, na muunganisho hukwama au kushindwa wakati proksi iko sawa muda wote. Hakuna kilichovunjika kwenye usanidi wa proksi, na kuurekebisha hakuwezi kusaidia mteja asiye na njia ya kufikia 10.40.0.20. Ama mteja apate njia, au proksi ifanye muunganisho kwa niaba yake.

Wakati proksi pekee inaweza kufikia programu

Ondoa kitendo cha uelekezaji upya na tuma maombi hayo kwa backend inayoelekeza anwani ya kibinafsi. Frontend huhifadhi jina lake la umma wakati backend inaamua ombi linaenda wapi hasa. Hakuna kinachobadilika kwenye njia ya mteja, kwa sababu proksi huacha kuelezea mwisho na yenyewe inakuwa mwisho. Kwa programu inayosikiliza kwa makusudi bandari ya ndani 8080, kizuizi cha seva ni kifupi:

backend private_app
    mode http
    option httpchk GET /health
    server app1 10.40.0.20:8080 check

Soma kizuizi hicho kama taarifa kuhusu jedwali la njia la proksi: 10.40.0.20 lazima ifikiwe kutoka kwa mwenyeji wa proksi mwenyewe, ambayo hapa inamaanisha kupitia kiolesura cha VPN na si kupitia njia ya kawaida. Neno kuu check hutaarifu tu kile njia hiyo inafanya, na njia ya ukaguzi wa afya lazima iwepo kwenye programu, vinginevyo uchunguzi wowote huweka seva kama imeanguka. Ukaguzi unaopita hauthibitishi chochote kuhusu mteja na hauchukui nafasi ya sera inayoamua nani anaweza kutumia backend.

Kipande hiki si frontend kamili. Hifadhi kiskilizaji, uthibitishaji, uchaguzi wa mwenyeji na njia unaoruhusiwa, na kanuni inayoamua nani anaweza kufikia programu kabisa. Linganisha pia itifaki ya backend, kwa sababu backend ya HTTPS inahitaji uthibitishaji wa cheti na usanidi wa utambulisho wa seva, na kuruka ukaguzi huo hubadilisha muunganisho wa kibinafsi kuwa usiothibitishwa.

Thibitisha njia ya kurudi pande zote mbili kabla ya kutangaza ushindi. Programu sasa inaona muunganisho kutoka kwa proksi, kwa hiyo kumbukumbu zake na metadata yoyote ya anwani ya mteja inaelezea proksi isipokuwa uandae vinginevyo. Amua jinsi utambulisho na anwani zilizopelekwa zinashughulikiwa, na jaribu uamuzi huo badala ya kuudhania.

Uelekezaji upya wa programu yenyewe bado unaelekeza ndani

Kupeleka ombi la kwanza ni nusu ya muunganisho tu. Programu inaweza kutoa uelekezaji upya kamili, URL za rasilimali zilizoandikwa moja kwa moja, au vidakuzi vilivyowekewa kikomo kwa jina inalojua ndani, na kila kimoja humrudisha kivinjari kwenye anwani ambayo hakiwezi kufikia. Kichwa cha Location kinachoelekeza jina la ndani kinaonekana sawa kabisa na tatizo la awali, ndiyo sababu hugunduliwa vibaya kama hitilafu ya proksi.

Weka URL ya nje iliyoandikwa ya programu na chaguo zake za proksi, kisha ulinganishe kichwa cha Host na mwenyeji pepe na matarajio ya cheti. Kidakuzi kilichowekewa kikomo kwa jina la ndani hakitakuja kupitia jina la umma, na mzunguko wa kuingia unaofuata husomwa kama hitilafu ya uthibitishaji. Badilisha kwanza URL ya nje, jaribu tena kutoka wasifu safi wa kivinjari, na tarajia mipangilio iliyohamishwa nusu kutoa kuingia kunakofanikiwa na kipindi kinachokufa mara moja.

Amini metadata iliyopelekwa tu kutoka kwa proksi iliyotengwa. Kichwa ambacho mteja yeyote anaweza kuweka hakiwezi kamwe kuwa thamani ya uidhinishaji, vinginevyo proksi inakuwa njia ya mpigaji simu kudai utambulisho wa mtu mwingine. Kanuni hiyo haitegemei swali la uelekezaji upya na hudumu katika kila muundo mpya wa baadaye.

Amua ni muundo upi ulio nao kweli

Ikiwa watumiaji wote tayari wana ufikiaji wa VPN ulioidhinishwa, uelekezaji upya kwenye URL ya kibinafsi unaweza kuwa muundo wa makusudi. Thibitisha hitaji hilo kwa uwazi badala ya kulidhania, kwa sababu miundo miwili huhudumia makundi tofauti kabisa. Mmoja haufanyi kazi kabisa kutoka mtandao wa hoteli, na ule mwingine huweka programu wazi kwa yeyote anayeweza kupakia URL ya umma. Tofauti hiyo inapaswa kuwa kwenye dokezo la muundo.

Endesha ukaguzi kutoka kwa mashine iliyo kwenye mtandao wa watumiaji na fuata kila hatua ambayo kivinjari hufanya, si jibu la kwanza tu. Angalia upau wa anwani na kila ombi linalofuata, kwa sababu URL moja kamili kwenye lebo ya rasilimali inatosha kuvunja mtiririko ambao hatua ya kwanza ilipita. Kuingia lazima kufanye kazi kupitia jina la umma, na rasilimali zinazopaswa kukataliwa lazima zibaki zimekataliwa.

Kuchapisha proksi ya nyuma ni uamuzi tofauti wa ufikiaji, si upanuzi wa wazi wa VPN ya proksi yenyewe kwa yeyote anayeweza kupakia URL yake ya umma. Wawili hao hufanana kwenye mchoro, na hutofautiana kwa nani anaruhusiwa kuingia. Kuamua swali hilo baada ya kupelekwa ni jinsi programu ya ndani inavyokuwa ya umma kwa bahati mbaya.

Andika ni upi uliojenga na kwa nini. Mtu anayefuata kugusa usanidi atadhania ule mwingine. Uelekezaji upya mmoja ulioongezwa kwa urahisi unatosha kuunda upya hitilafu ya awali, na dalili itaonekana sawa kabisa na ile uliyoirekebisha sasa hivi.