Så här serverar du en webpack-utvecklingsserver på en VPN-adress

Välj bindningsadress utifrån vem som måste nå utvecklingsservern, begränsa sedan värdnamnskontrollen och bekräfta att både sidan och live-omladdningssockeln ansluter.

En utvecklingsserver som svarar på laptopen och ingen annanstans är vanligtvis bunden till fel adress. En server som accepterar anslutningen men nekar sidan misslyckas vanligtvis med en värdnamnskontroll. Det är olika fel med olika åtgärder, och valet av rätt konfiguration beror på vem som måste nå arbetsytan och hur de kommer dit.

Tre frågor avgör svaret: vem som ansluter, vilken adress den personen kan nå, och om live-omladdning måste fungera för dem.

Börja med sockeln, inte konfigurationsfilen

Läs vad den körande processen faktiskt är bunden till, i samma nätverkskontext som startade den, eftersom en container eller ett namnutrymme kan äga en sockel som värdshellet inte ser. Lyssningskolumnen svarar på den första frågan: bara lokal sökväg, ett visst gränssnitt eller alla gränssnitt.

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

En loopback-adress är den säkra standarden och oanvändbar för en fjärrklient. En jokerteckenbindning är praktisk och exponerar porten på varje gränssnitt som har en rutt, vilket är bredare än de flesta avser på en maskin som också bär en tunnel. En specifik adress är mellanalternativet, och den fungerar bara om gränssnittet äger den adressen i det ögonblick sockeln skapas. Skillnaden spelar roll eftersom två av dessa tre bindningar ser identiska ut i webbläsaren och beter sig helt annorlunda när ett andra gränssnitt finns.

Anpassa dig efter den observationen innan du rör rutter eller brandväggsregler. Om processen lyssnar på fel adress får ingen mängd policy-routing klienten dit.

Välj bindningsadress utifrån vem som måste nå den

Om bara du på den här maskinen behöver sidan, behåll loopback-bindningen och sluta. Om en kollega på samma tunnel behöver den, bind tunnelgränssnittets adress och låt brandväggen bara tillåta den källan. Att publicera en utvecklingsserver bortom de personer som aktivt testar den är en vana som till slut exponerar en arbetsyta för internet.

Om en webbläsare inuti en container måste nå servern måste bindningsadressen vara en som containerns nätverk kan routa till, och det är ofta inte den adress som värden löser för sig själv. Bestäm fallet innan du redigerar konfigurationen, eftersom de tre fallen ger tre olika värden och bara ett är rätt. Gissningar här slösar mer tid än någon annan del av installationen.

Ställ sedan in adressen i den form som din startare faktiskt läser. En konfigurationsfil och ett skript som bygger servern programmatiskt använder inte samma alternativ:

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

Adressen i det utdraget är illustrativ och står för den VPN-adress som värden äger. Om projektet bygger servern med new WebpackDevServer(options, compiler) skicka alternativen genom konstruktorargumentet i stället, eftersom den separata devServer -egenskapen i webpack-konfigurationen inte läses den vägen. Den skillnaden mellan konfigurationsfilen och Node-API:t fångar folk som kopierar ett utdrag till ett projekt som aldrig läser det. dev-server-dokumentationen skiljer de två startstilarna och är referensen man ska jämföra den använda versionen mot.

Anpassa värdnamnskontrollen till de namn du godkänner

Värdnamnskontrollen finns för att hindra en sida som serveras från ett namn som en angripare kontrollerar att prata med din utvecklingsserver via webbläsaren. Att stänga av den med allowedHosts: "all" tar bort det skyddet, och bekvämligheten är sällan värd det på en maskin som kan nå interna tjänster. Kontrollen är billig att uppfylla korrekt när du vet vilka namn webbläsaren skickar.

Lista de exakta namnen du ska använda, inklusive det privata namnet som löses till tunneladressen. Om klienten löser ett namn till en annan adress än den du band till har du ett namnmatchproblem och inte ett serverkonfigurationsproblem, och att lägga till namnet i tillåtelselistan åtgärdar det inte. Bekräfta upplösningen från klienten, inte från servern.

Håll de tre kontrollerna åtskilda i huvudet: bindningsadressen avgör vilka gränssnitt som accepterar anslutningen, tillåtelselistan avgör vilka Host-huvuden som accepteras, och autentisering avgör vem som släpps in. Bara den tredje är åtkomstkontroll, och en utvecklingsserver har vanligtvis ingen. En tunneladress är inte heller en autentiseringsmekanism, eftersom den som kan routa dit redan är innanför gränsen du förlitade dig på.

Verifiera sidan och live-omladdningssockeln tillsammans

Ladda en färsk begäran från den avsedda klienten med det konfigurerade schemat, och läs resultatet i stället för cachen. För HTTPS behåller du det förväntade värdnamnet och certifikatvalideringen, eftersom en webbläsarvarning inte är ett lyckat acceptanstest. En sida som visas medan live-omladdning tyst misslyckas är den vanligaste delvisa framgången här, och det är lätt att missa vid en snabb kontroll.

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

Öppna sedan webbläsarens nätverksdiagnostik och titta på WebSocket-anslutningen. En sida kan laddas över ett värdnamn, port och schema medan omladdningssockeln använder ett annat, vilket är därför de två måste kontrolleras separat. Konfigurera den dokumenterade klient-URL:en bara när den utrullade sökvägen verkligen behöver ett annat värde, och föredra att fixa sökvägen framför att lära klienten en kringgång.

Anteckna lyssnaradressen, det accepterade namnet, den tillåtna källan och båda resultaten i projektanteckningarna. Den anteckningen överlever nästa person som startar arbetsytan och undrar varför sidan laddas men aldrig uppdateras.

Relaterade artiklar