Sådan kører du en webpack-udviklingsserver på en VPN-adresse

Vælg bind-adressen efter hvem der skal kunne nå udviklingsserveren, begræns derefter værtsnavnekontrollen, og bekræft at både siden og live-genindlæsningssocklen opretter forbindelse.

En udviklingsserver, der svarer på bærbaren og ingen andre steder, er normalt bundet til den forkerte adresse. En server, der accepterer forbindelsen, men afviser siden, fejler normalt en værtsnavnekontrol. Det er forskellige fejl med forskellige rettelser, og valget af den rigtige konfiguration afhænger af, hvem der skal nå arbejdsrummet, og hvordan de ankommer.

Tre spørgsmål afgør svaret: hvem opretter forbindelse, hvilken adresse de kan nå, og om live-genindlæsning skal virke for dem.

Begynd med socklen, ikke konfigurationsfilen

Læs, hvad den kørende proces faktisk bandt til, i den samme netværkskontekst, som startede den, fordi en container eller et navnerum kan eje en socket, som værts-shellet ikke kan se. Kolonnen for lyttende svarer på det første spørgsmål: kun lokal sti, en bestemt grænseflade eller alle grænseflader.

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

En loopback-adresse er det sikre standardvalg og ubrugelig for en fjernklient. En wildcard-binding er bekvem og eksponerer porten på enhver grænseflade med en rute, hvilket er bredere, end de fleste forestiller sig på en maskine, der også bærer en tunnel. En bestemt adresse er mellemvejen, og den virker kun, hvis grænsefladen ejer den adresse i det øjeblik, socklen oprettes. Forskellen betyder noget, fordi to af de tre bindinger ser ens ud i browseren og opfører sig helt anderledes, når der findes en anden grænseflade.

Ret dig efter den observation, før du rører ruter eller firewallregler. Hvis processen lytter på den forkerte adresse, får ingen mængde policy-routing klienten derhen.

Vælg bind-adressen efter hvem der skal nå den

Hvis kun du på denne maskine har brug for siden, så behold loopback-bindingen og stop. Hvis en kollega på samme tunnel har brug for den, så bind tunnelgrænsefladens adresse, og lad firewalla tillade kun den kilde. At offentliggøre en udviklingsserver ud over de personer, der aktivt tester den er en vane, der til sidst eksponerer et arbejdsrum for internettet.

Hvis en browser inde i en container skal nå serveren, skal bind-adressen være en, som containerens netværk kan rutte til, og det er ofte ikke den adresse, værten opløser for sig selv. Beslut sagen, før du redigerer konfigurationen, fordi de tre sager giver tre forskellige værdier, og kun én af dem er rigtig. At gætte her spilder mere tid end nogen anden del af opsætningen.

Indstil derefter adressen i den form, din launcher faktisk læser. En konfigurationsfil og et script, der bygger serveren programmatisk, bruger ikke de samme muligheder:

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

Adressen i det uddrag er illustrativ og står for den VPN-adresse, værten ejer. Hvis projektet bygger serveren med new WebpackDevServer(options, compiler), send mulighederne gennem konstruktørens argument i stedet, fordi den separate devServer -egenskab i webpack-konfigurationen ikke læses ad den vej. Den forskel mellem konfigurationsfilen og Node-API'et fanger folk, der kopierer et uddrag ind i et projekt, som aldrig læser det. dev-server-dokumentationen adskiller de to startstile og er referencen, man skal holde op imod den version, der bruges.

Tilpas værtsnavnekontrollen til de navne, du godkender

Værtsnavnekontrollen findes for at forhindre en side, der serveres fra et navn, en angriber kontrollerer, i at tale med din udviklingsserver gennem browseren. At slå den fra med allowedHosts: "all" fjerner den beskyttelse, og bekvemmeligheden er sjældent værd det på en maskine, der kan nå interne tjenester. Kontrollen er billig at opfylde korrekt, når du ved, hvilke navne browseren sender.

List de præcise navne, du vil bruge, inklusive det private navn, der opløses til tunneladressen. Hvis klienten opløser et navn til en anden adresse end den, du bandt til, har du et navneopløsningsproblem snarere end et serverkonfigurationsproblem, og at føje navnet til tilladelseslisten retter det ikke. Bekræft opløsningen fra klienten, ikke fra serveren.

Hold de tre kontroller adskilt i hovedet: bind-adressen afgør, hvilke grænseflader der accepterer forbindelsen, tilladelseslisten afgør, hvilke Host-headere der accepteres, og godkendelse afgør, hvem der lukkes ind. Kun den tredje er adgangskontrol, og en udviklingsserver har normalt ingen. En tunneladresse er heller ikke en godkendelsesmekanisme, da enhver, der kan rutte til den, allerede er inden for den grænse, du stolede på.

Bekræft siden og live-genindlæsningssocklen sammen

Indlæs en frisk anmodning fra den tilsigtede klient med det konfigurerede skema, og læs resultatet i stedet for cachen. For HTTPS skal du beholde det forventede værtsnavn og certifikatvalideringen, fordi en browseradvarsel ikke er en vellykket accepttest. En side, der vises, mens live-genindlæsning tavst fejler, er den mest almindelige delvise succes her, og den er let at overse under et hurtigt tjek.

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

Åbn derefter browserens netværksdiagnostik, og se WebSocket-forbindelsen. En side kan indlæses over ét værtsnavn, port og skema, mens genindlæsningssocklen bruger et andet, og derfor skal de to kontrolleres separat. Konfigurer kun den dokumenterede klient-URL, når den udrullede sti virkelig kræver en anden værdi, og foretræk at rette stien frem for at lære klienten en omvej.

Notér lytteradressen, det accepterede navn, den tilladte kilde og begge resultater i projektnoterne. Den registrering overlever den næste person, der starter arbejdsrummet og undrer sig over, hvorfor siden indlæses, men aldrig genindlæses.

Relaterede artikler