Si të shërbehet një server zhvillimi webpack në një adresë VPN

Një server zhvillimi që përgjigjet në laptop dhe askund tjetër zakonisht është i lidhur me adresën e gabuar. Një server që e pranon lidhjen por e refuzon faqen zakonisht dështon në një kontroll të emrit të hostit. Këto janë defekte të ndryshme me rregullime të ndryshme, dhe zgjedhja e konfigurimit të saktë varet nga kush duhet të arrijë hapësirën e punës dhe si arrin atje.

Tre pyetje vendosin përgjigjen: kush lidhet, cilën adresë mund të arrijë dhe nëse ringarkimi i drejtpërdrejtë duhet të funksionojë për të.

Filloni me soketin, jo me skedarin e konfigurimit

Lexoni se çfarë është lidhur në të vërtetë procesi që po ekzekutohet, në të njëjtin kontekst rrjeti që e nisi atë, sepse një kontejner ose një hapësirë emrash mund të zotërojë një soket që guaska e hostit nuk e sheh. Kolona e dëgjimit i përgjigjet pyetjes së parë: vetëm rruga lokale, një ndërfaqe e caktuar ose çdo ndërfaqe.

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

Një adresë loopback është vlera e parazgjedhur e sigurt dhe e padobishme për një klient në distancë. Lidhja me karakter gjenerik është e përshtatshme dhe e ekspozon portin në çdo ndërfaqe që ka një rrugë, që është më e gjerë se sa shumica synon në një makinë që mban edhe një tunel. Një adresë e caktuar është opsioni i mesëm, dhe funksionon vetëm nëse ndërfaqja e zotëron atë adresë në momentin që krijohet soketi. Diferenca ka rëndësi sepse dy nga këto tre lidhje duken identike në shfletues dhe sillen krejt ndryshe sapo të ekzistojë një ndërfaqe e dytë.

Përshtatuni me atë vëzhgim përpara se të prekni rrugët ose rregullat e murit të zjarrit. Nëse procesi dëgjon në adresën e gabuar, asnjë ushtrim i politikave nuk do ta bëjë klientin ta arrijë atë.

Zgjidhni adresën e lidhjes sipas kujt duhet ta arrijë

Nëse vetëm ju në këtë makinë ju nevojitet faqja, mbajeni lidhjen loopback dhe ndaloni. Nëse një koleg në të njëjtin tunel ka nevojë për të, lidhni adresën e ndërfaqes së tunelit dhe lërini murit të zjarrit të lejojë vetëm atë burim. Publikimi i një serveri zhvillimi përtej njerëzve që po e testojnë aktivisht atë është një zakon që përfundimisht e ekspozon hapësirën e punës ndaj internetit.

Nëse një shfletues brenda një kontejneri duhet të arrijë serverin, adresa e lidhjes duhet të jetë një të cilën rrjeti i kontejnerit mund ta drejtojë, dhe kjo shpesh nuk është adresa që hosti e zgjidh për vete. Vendosni për rastin përpara se të modifikoni konfigurimin, sepse tre rastet prodhojnë tre vlera të ndryshme dhe vetëm njëra është e saktë. Hamendja këtu humb më shumë kohë se çdo pjesë tjetër e konfigurimit.

Pastaj vendosni adresën në formën që nisësi juaj lexon vërtet. Një skedar konfigurimi dhe një skript që e ndërton serverin në mënyrë programore nuk konsumojnë të njëjtat opsione:

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

Adresa në atë fragment është ilustruese dhe përfaqëson adresën VPN që zotëron hosti. Nëse projekti e ndërton serverin me new WebpackDevServer(options, compiler) kaloni opsionet përmes argumentit të konstruktorit në vend të kësaj, sepse vetia e veçantë devServer në konfigurimin e webpack nuk konsultohet në atë rrugë. Kjo diferencë midis skedarit të konfigurimit dhe Node API kap njerëzit që kopjojnë një fragment në një projekt që nuk e lexon kurrë. Dokumentacioni i dev-server i ndan dy stilet e nisjes dhe është referenca me të cilën duhet krahasuar versioni i përdorur.

Përputhni kontrollin e emrit të hostit me emrat që miratoni

Kontrolli i emrit të hostit ekziston për të parandaluar një faqe të shërbyer nga një emër i kontrolluar nga një sulmues të flasë me serverin tuaj të zhvillimit përmes shfletuesit. Çaktivizimi i tij me allowedHosts: "all" e heq atë mbrojtje, dhe lehtësia rrallë ia vlen në një makinë që mund të arrijë shërbime të brendshme. Kontrolli është i lirë të plotësohet saktë sapo të dini cilat emra do të dërgojë shfletuesi.

Rendisni emrat e saktë që do të përdorni, duke përfshirë emrin privat që zgjidhet në adresën e tunelit. Nëse klienti zgjidh një emër në një adresë të ndryshme nga ajo me të cilën u lidhët, keni një problem të zgjidhjes së emrave dhe jo një problem konfigurimi të serverit, dhe shtimi i emrit në listën e lejuar nuk do ta rregullojë. Konfirmoni zgjidhjen nga klienti, jo nga serveri.

Mbajini tre kontrollet të ndara në mendjen tuaj: adresa e lidhjes vendos cilat ndërfaqe e pranojnë lidhjen, lista e lejuar vendos cilat tituj Host pranohen, dhe vërtetimi vendos kush lejohet të hyjë. Vetëm i treti është kontroll aksesi, dhe një server zhvillimi zakonisht nuk ka asnjë. As adresa e tunelit nuk është mekanizëm vërtetimi, pasi kushdo që mund të drejtojë drejt saj është tashmë brenda kufirit ku po mbështeteshit.

Verifikoni faqen dhe soketin e ringarkimit të drejtpërdrejtë së bashku

Ngarkoni një kërkesë të re nga klienti i synuar me skemën e konfiguruar, dhe lexoni rezultatin në vend të cache. Për HTTPS mbani emrin e hostit të pritur dhe vërtetimin e certifikatës, sepse një paralajmërim i shfletuesit nuk është një test pranimi i suksesshëm. Një faqe që paraqitet ndërsa ringarkimi i drejtpërdrejtë dështon në heshtje është suksesi i pjesshëm më i zakonshëm këtu, dhe është e lehtë ta humbësh gjatë një kontrolli të shpejtë.

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

Pastaj hapni diagnostikimin e rrjetit të shfletuesit dhe vëzhgoni lidhjen WebSocket. Një faqe mund të ngarkohet përmes një emri hosti, porti dhe skeme ndërsa soketi i ringarkimit përdor një tjetër, prandaj të dyja duhet të kontrollohen veçmas. Konfiguroni URL-në e dokumentuar të klientit vetëm kur rruga e vendosur me të vërtetë kërkon një vlerë të ndryshme, dhe preferoni rregullimin e rrugës para mësimit të klientit për një zgjidhje anashkaluese.

Regjistroni adresën e dëgjuesit, emrin e pranuar, burimin e lejuar dhe të dyja rezultatet në shënimet e projektit. Ai regjistrim i mbijeton personit të ardhshëm që nis hapësirën e punës dhe pyet veten pse faqja ngarkohet por nuk rifreskohet kurrë.