Hoe om 'n webpack-ontwikkelingsbediener op 'n VPN-adres te laat werk

'n Ontwikkelingsbediener wat op die skootrekenaar antwoord en nêrens anders nie, is gewoonlik aan die verkeerde adres gebind. 'n Bediener wat die verbinding aanvaar maar die bladsy weier, faal gewoonlik 'n gasheernaamkontrole. Dit is verskillende foute met verskillende regstellings, en die keuse van die regte konfigurasie hang daarvan af wie die werkruimte moet bereik en hoe hulle daar aankom.

Drie vrae bepaal die antwoord: wie verbind, watter adres hulle kan bereik, en of live herlaai vir hulle moet werk.

Begin met die sok, nie die konfigurasielêer nie

Lees waaraan die lopende proses werklik gebind het binne dieselfde netwerkkonteks wat dit begin het, want 'n houer of 'n naamruimte kan 'n sok besit wat die gasheer-shell nie kan sien nie. Die luisterkolom beantwoord die eerste vraag: slegs die plaaslike pad, een spesifieke koppelvlak, of elke koppelvlak.

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

'n Loopback-adres is die veilige verstek en nutteloos vir 'n afstandkliënt. 'n Wilderkaart-binding is gerieflik en stel die poort bloot op elke koppelvlak wat 'n roete het, wat wyer is as wat meeste mense bedoel op 'n masjien wat ook 'n tonnel dra. 'n Spesifieke adres is die middelste opsie, en dit werk net as die koppelvlak daardie adres besit op die oomblik dat die sok geskep word. Die onderskeid is belangrik omdat twee van daardie drie bindings in die blaaier identies lyk en heeltemal anders optree sodra 'n tweede koppelvlak bestaan.

Pas daardie waarneming toe voordat jy aan roetes of firewall-reëls raak. As die proses na die verkeerde adres luister, sal geen hoeveelheid beleidsroetering die kliënt daar laat uitkom nie.

Kies die bindadres volgens wie dit moet bereik

As net jy op hierdie masjien die bladsy nodig het, hou die loopback-binding en stop. As een kollega op dieselfde tonnel dit nodig het, bind die tonnelkoppelvlakadres en laat die firewall net daardie bron toe. Om 'n ontwikkelingsbediener buite die mense wat dit aktief toets te publiseer is 'n gewoonte wat uiteindelik 'n werkruimte aan die internet blootstel.

As 'n blaaier binne 'n houer die bediener moet bereik, moet die bindadres een wees waarna die houer se netwerk kan roeteer, en dit is dikwels nie die adres wat die gasheer vir homself oplos nie. Besluit die geval voordat jy die konfigurasie wysig, want die drie gevalle lewer drie verskillende waardes en net een daarvan is reg. Om hier te raai mors meer tyd as enige ander deel van die opstelling.

Stel dan die adres in die vorm wat jou lanseerder werklik lees. 'n Konfigurasielêer en 'n script wat die bediener programmaties bou, verbruik nie dieselfde opsies nie:

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

Die adres in daardie fragment is illustratief en staan vir die VPN-adres wat die gasheer besit. As die projek die bediener bou met new WebpackDevServer(options, compiler), gee die opsies eerder deur die konstruktor-argument deur, want die aparte devServer -eienskap in die webpack-konfigurasie word nie op daardie pad geraadpleeg nie. Daardie verskil tussen die konfigurasielêer en die Node-API vang mense wat 'n snippet in 'n projek kopieer wat dit nooit lees nie. Die dev-server-dokumentasie skei die twee lanseerstyl en is die verwysing om teen die weergawe in gebruik te kontroleer.

Pas die gasheernaamkontrole aan by die name wat jy goedkeur

Die gasheernaamkontrole bestaan om te verhoed dat 'n bladsy wat vanaf 'n aanvallerbeheerde naam bedien word, deur die blaaier met jou ontwikkelingsbediener praat. Om dit met allowedHosts: "all" te deaktiveer, verwyder daardie beskerming, en die gerief is selde die moeite werd op 'n masjien wat interne dienste kan bereik. Die kontrole is goedkoop om korrek te bevredig sodra jy weet watter name die blaaier sal stuur.

Lys die presiese name wat jy sal gebruik, insluitend die private naam wat na die tonneladres oplos. As die kliënt 'n naam na 'n ander adres oplos as die een waaraan jy gebind het, het jy 'n naamoplossingsprobleem eerder as 'n bedienerkonfigurasieprobleem, en om die naam by die toelaatlys te voeg sal dit nie regstel nie. Bevestig die oplossing vanaf die kliënt, nie vanaf die bediener nie.

Hou die drie kontroles apart in jou kop: die bindadres besluit watter koppelvlakke die verbinding aanvaar, die toelaatlys besluit watter Host-opskrifte aanvaar word, en verifikasie besluit wie ingelaat word. Net die derde een is 'n toegangsbeheer, en 'n ontwikkelingsbediener het gewoonlik geen. 'n Tonneladres is ook nie 'n verifikasiemeganisme nie, want enigiemand wat daarheen kan roeteer, is reeds binne die grens waarop jy gesteun het.

Verifieer die bladsy en die live-herlaai-sok saam

Laai 'n vars versoek van die beoogde kliënt met die gekonfigureerde skema, en lees die resultaat eerder as die kas. Vir HTTPS, hou die verwagte gasheernaam en sertifikaatvalidering, want 'n blaaierwaarskuwing is nie 'n suksesvolle aanvaardingstoets nie. 'n Bladsy wat rendert terwyl live herlaai stilweg misluk, is die mees algemene gedeeltelike sukses hier, en dit is maklik om tydens 'n vinnige kontrole te mis.

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

Maak dan die blaaier se netwerkdiagnostiek oop en kyk na die WebSocket-verbinding. 'n Bladsy kan oor een gasheernaam, poort en skema laai terwyl die herlaaisok 'n ander een gebruik, en daarom moet die twee afsonderlik gekontroleer word. Konfigureer die gedokumenteerde kliënt-URL net wanneer die ontplooide pad werklik 'n ander waarde nodig het, en verkies om die pad reg te maak bo om die kliënt van 'n workaround te leer.

Teken die luisteraaradres, die aanvaarde naam, die toegelate bron en beide resultate in die projeknotas aan. Daardie rekord oorleef die volgende persoon wat die werkruimte begin en wonder waarom die bladsy laai maar nooit herlaai nie.