Hoe't jo in webpack-ûntwikkelingsserver op in VPN-adres betsjinje

In ûntwikkelingsserver dy't op de laptop antwurdet en nearne oars, is meastentiids bûn oan it ferkearde adres. In server dy't de ferbining akseptearret mar de side wegeret, mislearret meastentiids in hostnamerkontrôle. Dat binne ferskillende flaters mei ferskillende oplossings, en de kar fan de juste konfiguraasje hinget ôf fan wa't de wurkromte berikke moat en hoe't se dêr komme.

Trije fragen beslisse it antwurd: wa't ferbynt, hokker adres se berikke kinne, en oft live-herladen foar har wurkje moat.

Begjin mei de socket, net mei it konfiguraasjebestân

Lês wêr't it rinnende proses echt oan bûn is, yn deselde netwurkbakte dy't it starte, want in kontener of in nammeromte kin in socket besitte dy't de shell fan de host net sjen kin. De harkkolom beantwurdet de earste fraach: allinnich lokaal paad, ien spesifike ynterface of alle ynterfaces.

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

In loopback-adres is de feilige standert en nutteloas foar in klant op ôfstân. In wildcard-bining is handich en stelt de poarte bleat op elk ynterface mei in rûte, wat breder is as de measte minsken bedoele op in masine dy't ek in tunnel hat. In spesifyk adres is de middenopsje, en it wurket allinnich as it ynterface dat adres besit op it momint dat de socket makke wurdt. It ferskil is wichtich, want twa fan dy trije binings lykje itselde yn de browser en hâlde har folslein oars as der in twadde ynterface bestiet.

Rjochtsje jo op dy observaasje foardat jo rûtes of firewallregels oanreitsje. As it proses op it ferkearde adres harket, sil gjin inkele policy-routing de klant dêrhinne krije.

Kies it bindadres op basis fan wa't it berikke moat

As allinnich jo op dizze masine de side nedich hawwe, hâld de loopback-bining en stop. As ien kollega op deselde tunnel it nedich hat, byn dan it adres fan it tunnel-ynterface en lit de firewall allinnich dy boarne talitte. In ûntwikkelingsserver publisearje bûten de minsken dy't him aktyf testen is in gewoante dy't úteinlik in wurkromte oan it ynternet bleatstelt.

As in browser yn in kontener de server berikke moat, moat it bindadres ien wêze dêr't it netwurk fan de kontener nei rûte kin, en dat is faak net it adres dat de host foar himsels oplost. Beskied it gefal foardat jo de konfiguraasje bewurkje, want de trije gefallen jouwe trije ferskillende wearden en mar ien is goed. Rieden hjir fergriemt mear tiid as hokker oar part fan 'e opset ek.

Stel dan it adres yn yn de foarm dy't jo lansearder echt lêst. In konfiguraasjebestân en in skript dat de server programmatysk bout, brûke net deselde opsjes:

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

It adres yn dat fragmint is yllustratyf en stiet foar it VPN-adres dat de host besit. As it projekt de server bout mei new WebpackDevServer(options, compiler) jou dan de opsjes troch fia it konstruktor-argumint, want de aparte devServer -eigenskip yn 'e webpack-konfiguraasje wurdt op dy wize net rieplachte. Dat ferskil tusken it konfiguraasjebestân en de Node-API fangt minsken dy't in fragmint kopiearje yn in projekt dat it nea lêst. De dev-server-dokumintaasje skiedt de twa lansearstilen en is de referinsje dêr't jo de brûkte ferzje mei fergelykje moatte.

Pas de hostnamerkontrôle oan op de nammen dy't jo goedkarre

De hostnamerkontrôle bestiet om te foarkommen dat in side dy't tsjinne wurdt fan in namme ûnder kontrôle fan in oanfaller, fia de browser mei jo ûntwikkelingsserver praat. It útsette mei allowedHosts: "all" hellet dy beskerming fuort, en it gemak is selden de muoite wurdich op in masine dy't ynterne tsjinsten berikke kin. De kontrôle is goedkeap om goed te foldwaan as jo ienris witte hokker nammen de browser stjoert.

List de krekte nammen op dy't jo brûke sille, ynklusyf de priveenamme dy't nei it tunneladres oplost. As de klant in namme nei in oar adres oplost as dat jo bûn hawwe, hawwe jo in namme-oplossingsprobleem en gjin serverkonfiguraasjeprobleem, en it tafoegjen fan de namme oan 'e tastienlist sil it net reparearje. Befêstigje de oplossing fan de klant, net fan de server.

Hâld de trije kontrôles apart yn jo holle: it bindadres beslút hokker ynterfaces de ferbining akseptearje, de tastienlist beslút hokker Host-koppen akseptearre wurde, en autentikaasje beslút wa't binnenmei. Allinnich de tredde is tagongskontrôle, en in ûntwikkelingsserver hat meastentiids gjinien. In tunneladres is ek gjin autentikaasjemeganisme, want wa't derhinne rûte kin, is al binnen de grins dêr't jo op fertrouden.

Kontrolearje de side en de live-herladingssocket tagelyk

Laad in farsk fersyk fan de bedoelde klant mei it konfigurearre skema, en lês it resultaat ynstee fan 'e cache. Foar HTTPS hâld it ferwachte hostnamme en sertifikaatfalidaasje, want in browserwarskôging is gjin slagge akseptaasjetest. In side dy't rendert wylst live-herladen stil mislearret, is hjir it meast foarkommende partielle sukses, en it is maklik te missen by in snelle kontrôle.

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

Iepenje dan de netwurkdiagnostyk fan de browser en besjoch de WebSocket-ferbining. In side kin oer ien hostnamme, poarte en skema lade wylst de herladingssocket in oare brûkt, en dêrom moatte de beide apart kontrolearre wurde. Konfigurearje de dokumintearre klant-URL allinnich as it útrôle paad echt in oare wearde nedich hat, en reparearje leaver it paad as om de klant in omwei te learen.

Skriuw it harkeradres, de akseptearre namme, de tastiene boarne en beide resultaten op yn 'e projektnotysjes. Dy optekening oerlibbet de folgjende persoan dy't de wurkromte start en har ôffreget wêrom't de side laadt mar nea ferfrist.