Jinsi ya kuhudumia seva ya maendeleo ya webpack kwenye anwani ya VPN

Seva ya maendeleo inayojibu kwenye kompyuta mpakato na mahali pengine popote kawaida hufungwa kwenye anwani isiyo sahihi. Seva inayokubali muunganisho lakini inakataa ukurasa kawaida hushindwa ukaguzi wa jina la mwenyeji. Hizi ni hitilafu tofauti na marekebisho tofauti, na kuchagua usanidi sahihi kunategemea nani anapaswa kufikia nafasi ya kazi na jinsi anavyofika.

Maswali matatu huamua jibu: nani anaunganisha, ni anwani gani anaweza kufikia, na kama upakiaji upya moja kwa moja unapaswa kumfaa.

Anza na soketi, si faili ya usanidi

Soma kile mchakato unaoendelea umefungwa nacho kwa kweli ndani ya muktadha huo wa mtandao uliouanzisha, kwa sababu chombo au nafasi ya majina inaweza kumiliki soketi ambayo ganda la mwenyeji haioni. Safu ya kusikiliza hujibu swali la kwanza: njia ya ndani pekee, kiolesura kimoja maalum, au kila kiolesura.

ss -ltn '( sport = :8080 )'
ss -ltnp | grep node

Anwani ya kitanzi cha kurudi ni chaguo salama la msingi na haina maana kwa mteja wa mbali. Ufungaji wa alama ya wildcard ni rahisi na hufichua bandari kwenye kila kiolesura kilicho na njia, jambo ambalo ni pana kuliko wengi wanavyokusudia kwenye mashine inayobeba pia handaki. Anwani mahususi ni chaguo la kati, na hufanya kazi tu ikiwa kiolesura kinamiliki anwani hiyo wakati soketi inaundwa. Tofauti hiyo ni muhimu kwa sababu mbili kati ya zile tatu zinaonekana sawa kwenye kivinjari na hutenda tofauti kabisa mara kiolesura cha pili kinapotokea.

Oanisha na uchunguzi huo kabla ya kugusa njia au kanuni za firewall. Ikiwa mchakato unasikiliza kwenye anwani isiyo sahihi, hakuna uelekezaji wowote wa sera utakao mfikisha mteja huko.

Chagua anwani ya kufunga kulingana na nani anapaswa kuifikia

Ikiwa ni wewe pekee kwenye mashine hii unahitaji ukurasa, baki na ufungaji wa kitanzi cha kurudi na uache. Ikiwa mwenzako mmoja kwenye handaki hilo hilo anauhitaji, funga anwani ya kiolesura cha handaki na uache firewall ikubali chanzo hicho pekee. Kuchapisha seva ya maendeleo zaidi ya watu wanaoiendesha majaribio kwa bidii ni tabia ambayo mwishowe hufichua nafasi ya kazi kwa mtandao.

Ikiwa kivinjari ndani ya chombo kinahitaji kufikia seva, anwani ya kufunga lazima iwe ile ambayo mtandao wa chombo unaweza kuelekeza, na mara nyingi hiyo si anwani ambayo mwenyeji huitatua kwa ajili yake mwenyewe. Amua kesi kabla ya kuhariri usanidi, kwa sababu kesi tatu hutoa thamani tatu tofauti na moja pekee ni sahihi. Kukisia hapa kunapoteza muda zaidi kuliko sehemu nyingine yoyote ya usanidi.

Kisha weka anwani katika umbo ambalo kizinduzi chako husoma kwa kweli. Faili ya usanidi na script inayojenga seva kwa programu hazitumii chaguo zile zile:

devServer: {
  host: "10.77.0.20",
  port: 8080,
  allowedHosts: ["dev.corp.example"],
}

Anwani katika kipande hicho ni kielelezo na inawakilisha anwani ya VPN ambayo mwenyeji anamiliki. Ikiwa mradi unajenga seva kwa new WebpackDevServer(options, compiler) pitisha chaguo kupitia hoja ya kijenzi badala yake, kwa sababu sifa tofauti devServer katika usanidi wa webpack haizingatiwi kwenye njia hiyo. Tofauti hiyo kati ya faili ya usanidi na Node API huwakamata wale wanaonakili kipande kwenye mradi ambao hauusomi kamwe. Nyaraka za dev-server hutenganisha mitindo miwili ya kuzindua na ni rejeleo la kulinganisha toleo linalotumika.

Oanisha ukaguzi wa jina la mwenyeji na majina unayoidhinisha

Ukaguzi wa jina la mwenyeji upo ili kuzuia ukurasa unaotolewa kutoka jina linalodhibitiwa na mshambuliaji kuzungumza na seva yako ya maendeleo kupitia kivinjari. Kuuzima kwa allowedHosts: "all" kunaondoa ulinzi huo, na urahisi huo mara chache una faida kwenye mashine inayoweza kufikia huduma za ndani. Ukaguzi ni wa bei nafuu kutimiza kwa usahihi mara unapojua majina ambayo kivinjari kitatuma.

Orodhesha majina kamili utakayotumia, ikiwa ni pamoja na jina la faragha linalotatuliwa hadi anwani ya handaki. Ikiwa mteja anatafsiri jina hadi anwani tofauti na ile uliyofunga, una tatizo la utatuzi wa majina na si tatizo la usanidi wa seva, na kuongeza jina kwenye orodha inayoruhusiwa hakutarekebisha. Thibitisha utatuzi kutoka kwa mteja, si kwa seva.

Weka vidhibiti vitatu kando akilini mwako: anwani ya kufunga huamua ni violezo vipi vinavyokubali muunganisho, orodha inayoruhusiwa huamua ni vichwa vipi vya Host vinavyokubaliwa, na uthibitishaji huamua nani anaruhusiwa kuingia. Cha tatu pekee ndicho kidhibiti cha ufikiaji, na seva ya maendeleo kwa kawaida haina hata kimoja. Anwani ya handaki pia si utaratibu wa uthibitishaji, kwa kuwa yeyote anayeweza kuelekeza huko tayari yuko ndani ya mpaka uliokuwa ukitegemea.

Thibitisha ukurasa na soketi ya upakiaji upya moja kwa moja pamoja

Pakia ombi jipya kutoka kwa mteja aliyekusudiwa ukiwa na mpango uliosanidiwa, na soma matokeo badala ya akiba. Kwa HTTPS weka jina la mwenyeji linalotarajiwa na uthibitishaji wa cheti, kwa sababu onyo la kivinjari si jaribio la ukubalifu lililofanikiwa. Ukurasa unaoonyeshwa wakati upakiaji upya moja kwa moja unashindwa kimya ndiyo mafanikio ya sehemu yanayojulikana zaidi hapa, na ni rahisi kuikosa wakati wa ukaguzi wa haraka.

curl -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" http://dev.corp.example:8080/
curl -sS -i http://10.77.0.20:8080/ | head -n 5

Kisha fungua uchunguzi wa mtandao wa kivinjari na uangalie muunganisho wa WebSocket. Ukurasa unaweza kupakiwa kupitia jina moja la mwenyeji, bandari na mpango wakati soketi ya upakiaji upya inatumia lingine, ndiyo sababu vyote viwili vinapaswa kukaguliwa kivyake. Sanidi URL ya mteja iliyoandikwa tu wakati njia iliyotumwa inahitaji thamani tofauti kwa kweli, na upendelee kurekebisha njia badala ya kumfundisha mteja njia ya kukwepa.

Rekodi anwani ya msikilizaji, jina lililokubaliwa, chanzo kilichoruhusiwa na matokeo yote mawili katika maelezo ya mradi. Rekodi hiyo hubaki kwa mtu anayefuata atakayeanzisha nafasi ya kazi na kujiuliza kwa nini ukurasa unapakiwa lakini hauonyeshwi upya kamwe.