Slik betjener du en webpack-utviklingsserver på en VPN-adresse

Velg bindingsadressen etter hvem som må nå utviklingsserveren, begrens deretter vertsnavnkontrollen og bekreft at både siden og live-omlastingssockelen kobler til.

En utviklingsserver som svarer på laptopen og ingen andre steder, er vanligvis bundet til feil adresse. En server som godtar tilkoblingen men avviser siden, feiler vanligvis en vertsnavnkontroll. Det er forskjellige feil med forskjellige rettelser, og valget av riktig konfigurasjon avhenger av hvem som må nå arbeidsområdet og hvordan de ankommer.

Tre spørsmål avgjør svaret: hvem kobler til, hvilken adresse de kan nå, og om live-omlasting må fungere for dem.

Start med sockelen, ikke konfigurasjonsfilen

Les hva den kjørende prosessen faktisk er bundet til, i samme nettverkskontekst som startet den, fordi en container eller et navnerom kan eie en sockel som vertsskallet ikke ser. Lyttkolonnen svarer på det første spørsmålet: bare lokal bane, ett bestemt grensesnitt eller alle grensesnitt.

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

En loopback-adresse er den trygge standarden og ubrukelig for en ekstern klient. En jokertegnbinding er praktisk og eksponerer porten på hvert grensesnitt som har en rute, noe som er bredere enn de fleste mener på en maskin som også bærer en tunnel. En bestemt adresse er mellomvalget, og den virker bare hvis grensesnittet eier den adressen i det øyeblikket sockelen opprettes. Forskjellen betyr noe fordi to av disse tre bindingene ser like ut i nettleseren og oppfører seg helt annerledes når et andre grensesnitt finnes.

Rett deg etter den observasjonen før du rører ruter eller brannmurregler. Hvis prosessen lytter på feil adresse, får ingen mengde policy-ruting klienten dit.

Velg bindingsadressen etter hvem som må nå den

Hvis bare du på denne maskinen trenger siden, behold loopback-bindingen og stopp. Hvis en kollega på samme tunnel trenger den, bind tunnelgrensesnittets adresse og la brannmuren bare tillate den kilden. Å publisere en utviklingsserver utover dem som aktivt tester den er en vane som til slutt eksponerer et arbeidsområde for internett.

Hvis en nettleser inne i en container må nå serveren, må bindingsadressen være en containerens nettverk kan rute til, og det er ofte ikke adressen verten løser for seg selv. Bestem saken før du redigerer konfigurasjonen, fordi de tre sakene gir tre forskjellige verdier og bare én er riktig. Gjetting her koster mer tid enn noen annen del av oppsettet.

Sett deretter adressen i den formen starteren din faktisk leser. En konfigurasjonsfil og et skript som bygger serveren programmatisk bruker ikke de samme alternativene:

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

Adressen i det utdraget er illustrativ og står for VPN-adressen verten eier. Hvis prosjektet bygger serveren med new WebpackDevServer(options, compiler) send alternativene gjennom konstruktørargumentet i stedet, fordi den separate devServer -egenskapen i webpack-konfigurasjonen ikke konsulteres på den veien. Den forskjellen mellom konfigurasjonsfilen og Node-API-et fanger folk som kopierer et utdrag inn i et prosjekt som aldri leser det. dev-server-dokumentasjonen skiller de to startstilene og er referansen man skal sjekke mot versjonen som brukes.

Tilpass vertsnavnkontrollen til navnene du godkjenner

Vertsnavnkontrollen finnes for å hindre en side som serveres fra et navn en angriper kontrollerer, i å snakke med utviklingsserveren din gjennom nettleseren. Å slå den av med allowedHosts: "all" fjerner den beskyttelsen, og bekvemmeligheten er sjelden verdt det på en maskin som kan nå interne tjenester. Kontrollen er billig å oppfylle riktig når du vet hvilke navn nettleseren sender.

List de nøyaktige navnene du vil bruke, inkludert det private navnet som løses til tunneladressen. Hvis klienten løser et navn til en annen adresse enn den du bandt til, har du et navneoppløsningsproblem snarere enn et serverkonfigurasjonsproblem, og å legge navnet til tillatelseslisten retter det ikke. Bekreft oppløsningen fra klienten, ikke fra serveren.

Hold de tre kontrollene atskilt i hodet: bindingsadressen avgjør hvilke grensesnitt som godtar tilkoblingen, tillatelseslisten avgjør hvilke Host-hoder som godtas, og autentisering avgjør hvem som slippes inn. Bare den tredje er tilgangskontroll, og en utviklingsserver har vanligvis ingen. En tunneladresse er heller ikke en autentiseringsmekanisme, siden enhver som kan rute dit allerede er innenfor grensen du stolte på.

Bekreft siden og live-omlastingssockelen sammen

Last en fersk forespørsel fra den tiltenkte klienten med det konfigurerte skjemaet, og les resultatet i stedet for cachen. For HTTPS beholder du forventet vertsnavn og sertifikatvalidering, fordi en nettleseradvarsel ikke er en vellykket aksepttest. En side som vises mens live-omlasting stille feiler, er den vanligste delvise suksessen her, og den er lett å overse under en rask sjekk.

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

Åpne deretter nettleserens nettverksdiagnostikk og se på WebSocket-tilkoblingen. En side kan lastes over ett vertsnavn, port og skjema mens omlastingssockelen bruker et annet, og derfor må de to sjekkes separat. Konfigurer den dokumenterte klient-URL-en bare når den utrullede banen virkelig trenger en annen verdi, og foretrekk å rette banen fremfor å lære klienten en omvei.

Noter lytteradressen, det godtatte navnet, den tillatte kilden og begge resultatene i prosjektnotatene. Den registreringen overlever neste person som starter arbeidsområdet og lurer på hvorfor siden lastes men aldri oppdateres.

Relaterte artikler