Korleis tena ein webpack-utviklingsserver på ei VPN-adresse

Ein utviklingsserver som svarar på laptopen og ingen andre stader, er vanlegvis bunden til feil adresse. Ein server som tek imot tilkoplinga men avviser sida, feilar vanlegvis ein vertsnamnkontroll. Det er ulike feil med ulike rettingar, og valet av rett konfigurasjon avheng av kven som må nå arbeidsområdet og korleis dei kjem.

Tre spørsmål avgjer svaret: kven koplar til, kva adresse dei kan nå, og om live-omlasting må verke for dei.

Start med sokkelen, ikkje konfigurasjonsfila

Les kva den køyrande prosessen faktisk er bunden til, i same nettverkskonteksten som starta han, fordi ein container eller eit namnerom kan eiga ein sokkel som vertsskalet ikkje ser. Lyttkolonnen svarar på det første spørsmålet: berre lokal bane, eitt bestemt grensesnitt eller alle grensesnitt.

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

Ei loopback-adresse er den trygge standarden og ubrukeleg for ein ekstern klient. Ei jokerteiknbinding er praktisk og eksponerer porten på kvart grensesnitt som har ei rute, noko som er breiare enn dei fleste meiner på ein maskin som òg ber ein tunnel. Ei bestemt adresse er mellomvalet, og ho verkar berre om grensesnittet eig den adressa i augneblinken sokkelen blir laga. Skilnaden har noko å seie fordi to av desse tre bindingane ser like ut i nettlesaren og oppfører seg heilt annleis når eit andre grensesnitt finst.

Rett deg etter den observasjonen før du rører ruter eller brannmurreglar. Om prosessen lyttar på feil adresse, får inga mengd policy-ruting klienten dit.

Vel bindingsadressa etter kven som må nå henne

Om berre du på denne maskinen treng sida, hald på loopback-bindinga og stopp. Om ein kollega på same tunnel treng henne, bind adressa til tunnelgrensesnittet og lat brannmuren berre tillate den kjelda. Å publisere ein utviklingsserver utover dei som aktivt testar han er ein vane som til slutt eksponerer eit arbeidsområde for internett.

Om ein nettlesar inne i ein container må nå serveren, må bindingsadressa vere ei som nettverket til containeren kan rute til, og det er ofte ikkje adressa verten løyser for seg sjølv. Avgjer saka før du redigerer konfigurasjonen, fordi dei tre sakene gir tre ulike verdiar og berre éin er rett. Gissing her kostar meir tid enn nokon annan del av oppsettet.

Set deretter adressa i den forma startaren din faktisk les. Ei konfigurasjonsfil og eit skript som byggjer serveren programmatisk brukar ikkje dei same alternativa:

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

Adressa i det utdraget er illustrativ og står for VPN-adressa verten eig. Om prosjektet byggjer serveren med new WebpackDevServer(options, compiler) send alternativa gjennom konstruktørargumentet i staden, fordi den separate devServer -eigenskapen i webpack-konfigurasjonen ikkje blir konsultert på den vegen. Den skilnaden mellom konfigurasjonsfila og Node-API-et fangar folk som kopierer eit utdrag inn i eit prosjekt som aldri les det. dev-server-dokumentasjonen skil dei to startstilane og er referansen ein skal sjekke mot versjonen som blir brukt.

Tilpass vertsnamnkontrollen til namna du godkjenner

Vertsnamnkontrollen finst for å hindre at ei side som blir tente frå eit namn ein åtakar kontrollerer, snakkar med utviklingsserveren din gjennom nettlesaren. Å slå han av med allowedHosts: "all" fjernar den vernet, og komforten er sjeldan verdt det på ein maskin som kan nå interne tenester. Kontrollen er billeg å oppfylle rett når du veit kva namn nettlesaren sender.

List dei nøyaktige namna du vil bruke, inkludert det private namnet som blir løyst til tunneladressa. Om klienten løyser eit namn til ei anna adresse enn den du batt til, har du eit namneløysingsproblem snarare enn eit serverkonfigurasjonsproblem, og å leggje namnet til tillatingslista rettar det ikkje. Stadfest løysinga frå klienten, ikkje frå serveren.

Hald dei tre kontrollane skilde i hovudet: bindingsadressa avgjer kva grensesnitt som tek imot tilkoplinga, tillatingslista avgjer kva Host-hovud som blir godtekne, og autentisering avgjer kven som slepp inn. Berre den tredje er tilgangskontroll, og ein utviklingsserver har vanlegvis ingen. Ei tunneladresse er heller ikkje ein autentiseringsmekanisme, sidan kven som helst som kan rute dit alt er innanfor grensa du stolte på.

Stadfest sida og live-omlastingssokkelen saman

Last ein fersk førespurnad frå den tiltenkte klienten med det konfigurerte skjemaet, og les resultatet i staden for cachen. For HTTPS held du på forventa vertsnamn og sertifikatvalidering, fordi ei nettlesaråtvaring ikkje er ein vellukka aksepttest. Ei side som blir rendra medan live-omlasting stille feilar, er den vanlegaste delvise suksessen her, og han er lett å oversjå under ein 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

Opne deretter nettverksdiagnostikken til nettlesaren og sjå på WebSocket-tilkoplinga. Ei side kan lastast over eitt vertsnamn, port og skjema medan omlastingssokkelen brukar eit anna, og difor må dei to sjekkast kvar for seg. Konfigurer den dokumenterte klient-URL-en berre når den utrulla banen verkeleg treng ein annan verdi, og føretrekk å rette banen framfor å lære klienten ein omveg.

Noter lyttaradressa, det godtekne namnet, den tillatne kjelda og begge resultata i prosjektnotata. Den registreringa overlever neste person som startar arbeidsområdet og lurer på kvifor sida blir lasta men aldri oppdatert.