Paano maghain ng webpack dev server sa isang VPN address

Ang dev server na sumasagot sa laptop at wala nang iba ay karaniwang nakatali sa maling address. Ang server na tumatanggap ng koneksyon pero tumatanggi sa pahina ay karaniwang bumabagsak sa pagsusuri ng hostname. Magkaibang depekto ang mga ito na may magkaibang pagwawasto, at ang pagpili ng tamang configuration ay depende sa kung sino ang kailangang makarating sa workspace at paano siya dumating.

Tatlong tanong ang nagpapasya sa sagot: sino ang kumokonekta, aling address ang maaari niyang maabot, at kung dapat gumana ang live reload para sa kanya.

Magsimula sa socket, hindi sa configuration file

Basahin kung ano talaga ang nakatali sa tumatakbong proseso sa parehong network context na nagpatakbo nito, dahil may container o namespace na maaaring nagmamay-ari ng socket na hindi nakikita ng host shell. Ang listen column ang sumasagot sa unang tanong: local path lang, isang partikular na interface, o lahat ng interface.

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

Ang loopback address ay ang ligtas na default at walang silbi sa malayong client. Ang wildcard bind ay maginhawa at inilalantad ang port sa bawat interface na may ruta, na mas malawak kaysa sa inaasahan ng karamihan sa isang makina na may dala ring tunnel. Ang partikular na address ang gitnang opsyon, at gumagana lang ito kung pagmamay-ari ng interface ang address na iyon sa sandaling ginawa ang socket. Mahalaga ang pagkakaiba dahil ang dalawa sa tatlong binding na ito ay magkamukha sa browser at lubos na magkaiba ang kilos kapag may pangalawang interface.

Umayon sa obserbasyong iyon bago hawakan ang mga ruta o patakaran ng firewall. Kung nakikinig ang proseso sa maling address, walang policy routing ang makapaghahatid sa client doon.

Piliin ang bind address ayon sa kailangang makarating dito

Kung ikaw lang sa makinang ito ang nangangailangan ng pahina, panatilihin ang loopback bind at huminto. Kung kailangan ito ng isang kasamahan sa parehong tunnel, i-bind ang address ng tunnel interface at hayaang payagan ng firewall ang source na iyon lang. Ang paglalathala ng dev server lampas sa mga taong aktibong sumusubok dito ay isang ugali na sa huli ay naglalantad ng workspace sa internet.

Kung kailangang maabot ng browser sa loob ng container ang server, ang bind address ay dapat isa na kayang i-route ng network ng container, at kadalasan hindi ito ang address na nire-resolve ng host para sa sarili nito. Pagpasyahan ang kaso bago i-edit ang configuration, dahil tatlong magkaibang halaga ang ibinibigay ng tatlong kaso at isa lang ang tama. Ang paghula rito ay mas malaking pag-aaksaya ng oras kaysa sa alinmang bahagi ng setup.

Pagkatapos itakda ang address sa form na talagang binabasa ng launcher mo. Ang configuration file at ang script na gumagawa ng server sa paraang programmatic ay hindi gumagamit ng parehong opsyon:

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

Ang address sa snippet na iyon ay halimbawa at kumakatawan sa VPN address na pagmamay-ari ng host. Kung ginagawa ng proyekto ang server gamit ang new WebpackDevServer(options, compiler) ipasa ang mga opsyon sa constructor argument sa halip, dahil ang hiwalay na devServer property sa webpack configuration ay hindi isinasaalang-alang sa rutang iyon. Ang pagkakaibang iyon sa pagitan ng configuration file at ng Node API ang humuhuli sa mga kumokopya ng snippet sa proyektong hindi ito binabasa. Ang dokumentasyon ng dev-server ay naghihiwalay sa dalawang estilo ng paglunsad at ito ang sangguniang dapat ihambing sa bersyong ginagamit.

Itugma ang pagsusuri ng hostname sa mga pangalang inaprubahan mo

Ang pagsusuri ng hostname ay naroon para pigilan ang pahinang inihain mula sa pangalang kontrolado ng attacker na makipag-usap sa dev server mo sa pamamagitan ng browser. Ang pag-disable nito gamit ang allowedHosts: "all" ay nag-aalis ng proteksyong iyon, at bihirang sulit ang kaginhawahan sa isang makinang kayang maabot ang mga panloob na serbisyo. Murang matugunan nang tama ang pagsusuri kapag alam mo kung aling mga pangalan ang ipapadala ng browser.

Ilista ang eksaktong mga pangalang gagamitin mo, kasama ang pribadong pangalang nire-resolve sa address ng tunnel. Kung nire-resolve ng client ang isang pangalan sa ibang address kaysa sa na-bind mo, may problema ka sa pag-resolve ng pangalan at hindi sa configuration ng server, at hindi ito aayusin ng pagdaragdag ng pangalan sa allowlist. Kumpirmahin ang resolution mula sa client, hindi mula sa server.

Panatilihing hiwalay sa isipan ang tatlong kontrol: ang bind address ang nagpapasya kung aling interface ang tumatanggap ng koneksyon, ang allowlist ang nagpapasya kung aling Host header ang tinatanggap, at ang authentication ang nagpapasya kung sino ang pinapapasok. Ang pangatlo lang ang access control, at karaniwang wala nito ang dev server. Hindi rin mekanismo ng authentication ang address ng tunnel, dahil nasa loob na ng hangganang pinagkatiwalaan mo ang sinumang kayang mag-route doon.

I-verify nang sabay ang pahina at ang live-reload socket

Mag-load ng bagong request mula sa intended client gamit ang naka-configure na scheme, at basahin ang resulta sa halip na ang cache. Para sa HTTPS, panatilihin ang inaasahang hostname at validation ng certificate, dahil ang babala ng browser ay hindi matagumpay na acceptance test. Ang pahinang nagre-render habang tahimik na bumabagsak ang live reload ang pinakakaraniwang partial success dito, at madaling makaligtaan sa mabilisang pagsusuri.

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

Pagkatapos buksan ang network diagnostics ng browser at obserbahan ang WebSocket connection. Maaaring mag-load ang pahina sa isang hostname, port at scheme habang iba ang ginagamit ng reload socket, kaya kailangang suriin nang hiwalay ang dalawa. I-configure ang dokumentadong client URL lamang kapag talagang kailangan ng naka-deploy na path ang ibang halaga, at unahin ang pag-aayos ng path kaysa turuan ang client ng workaround.

Itala ang listener address, ang tinanggap na pangalan, ang pinapayagang source at parehong resulta sa mga tala ng proyekto. Ang talaang iyon ay mananatili para sa susunod na taong magpapatakbo ng workspace at magtatanong kung bakit naglo-load ang pahina pero hindi kailanman nagre-refresh.