Miten webpack-kehityspalvelin tarjoillaan VPN-osoitteessa

Kehityspalvelin, joka vastaa kannettavassa ja ei missään muualla, on yleensä sidottu väärään osoitteeseen. Palvelin, joka hyväksyy yhteyden mutta hylkää sivun, epäonnistuu yleensä isäntänimen tarkistuksessa. Ne ovat eri vikoja eri korjauksilla, ja oikean kokoonpanon valinta riippuu siitä, kenen on päästävä työtilaan ja miten he saapuvat.

Kolme kysymystä ratkaisevat vastauksen: kuka yhdistää, mihin osoitteeseen hän pääsee ja täytyykö live-uudelleenlatauksen toimia hänelle.

Aloita socketista, älä kokoonpanotiedostosta

Lue, mihin käynnissä oleva prosessi todella sitoutui samassa verkkoympäristössä, joka sen käynnisti, koska kontti tai nimiavaruus voi omistaa socketin, jota isännän kuori ei näe. Kuuntelusarake vastaa ensimmäiseen kysymykseen: vain paikallinen polku, yksi tietty liitäntä vai kaikki liitännät.

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

Loopback-osoite on turvallinen oletus ja hyödytön etäasiakkaalle. Jokerimerkkisidonta on kätevää ja paljastaa portin jokaisessa liitännässä, jolla on reitti, mikä on laajempaa kuin useimmat tarkoittavat koneessa, joka kantaa myös tunnelia. Tietty osoite on keskimmäinen vaihtoehto, ja se toimii vain, jos liitäntä omistaa kyseisen osoitteen socketin luontihetkellä. Ero on tärkeä, koska kaksi näistä kolmesta sidonnasta näyttävät selaimessa samoilta ja käyttäytyvät täysin eri tavoin, kun toinen liitäntä on olemassa.

Mukauta havaintoon ennen kuin kosket reitteihin tai palomuurisääntöihin. Jos prosessi kuuntelee väärässä osoitteessa, mikään käytäntöpohjainen reititys ei saa asiakasta sinne.

Valitse sidontaosoite sen mukaan, kenen on päästävä sinne

Jos vain sinä tässä koneessa tarvitset sivun, pidä loopback-sidonta ja lopeta. Jos yksi kollega samassa tunnelissa tarvitsee sitä, sido tunnelin liitännän osoite ja anna palomuurin sallia vain se lähde. Kehityspalvelimen julkaiseminen aktiivisesti testaavien ihmisten ulkopuolelle on tapa, joka lopulta altistaa työtilan internetille.

Jos kontin sisäinen selain tarvitsee päästä palvelimeen, sidontaosoitteen on oltava sellainen, johon kontin verkko osaa reitittää, ja se ei usein ole osoite, jonka isäntä ratkaisee itselleen. Päätä tapaus ennen kokoonpanon muokkaamista, koska kolme tapausta tuottavat kolme eri arvoa ja vain yksi on oikein. Arvaaminen täällä tuhlaa enemmän aikaa kuin mikään muu asennuksen osa.

Aseta sitten osoite muotoon, jonka käynnistimesi todella lukee. Kokoonpanotiedosto ja skripti, joka rakentaa palvelimen ohjelmallisesti, eivät käytä samoja vaihtoehtoja:

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

Kyseisen katkelman osoite on havainnollinen ja tarkoittaa VPN-osoitetta, jonka isäntä omistaa. Jos projekti rakentaa palvelimen new WebpackDevServer(options, compiler)-komennolla, välitä vaihtoehdot sen sijaan konstruktorin argumentin kautta, koska erillistä devServer -ominaisuutta webpackin kokoonpanossa ei tarkisteta tällä polulla. Tämä ero kokoonpanotiedoston ja Node API:n välillä nappaa ihmiset, jotka kopioivat katkelman projektiin, joka ei koskaan lue sitä. dev-serverin dokumentaatio erottaa kaksi käynnistystyyliä ja on viite, jota vasten käytössä oleva versio on tarkistettava.

Sovita isäntänimen tarkistus nimiin, jotka hyväksyt

Isäntänimen tarkistus on olemassa estääkseen hyökkääjän hallitsemasta nimestä tarjoiltua sivua puhumasta kehityspalvelimesi kanssa selaimen kautta. Sen poistaminen käytöstä allowedHosts: "all" -asetuksella poistaa tämän suojan, ja mukavuus on harvoin sen arvoista koneessa, joka pääsee sisäisiin palveluihin. Tarkistus on halpa täyttää oikein, kun tiedät, mitkä nimet selain lähettää.

Listaa tarkat nimet, joita käytät, mukaan lukien yksityinen nimi, joka ratkeaa tunnelin osoitteeseen. Jos asiakas ratkaisee nimen eri osoitteeseen kuin mihin sidoit, sinulla on nimien ratkaisun ongelma eikä palvelimen kokoonpanon ongelma, eikä nimen lisääminen sallittujen luetteloon korjaa sitä. Vahvista ratkaisu asiakkaalta, älä palvelimelta.

Pidä kolme ohjainta erillään päässäsi: sidontaosoite päättää, mitkä liitännät hyväksyvät yhteyden, sallittujen luettelo päättää, mitkä Host-otsikot hyväksytään, ja todennus päättää, kuka päästetään sisään. Vain kolmas on käyttöoikeuden valvonta, eikä kehityspalvelimella yleensä ole yhtään. Tunnelin osoite ei ole todennusmekanismikaan, koska jokainen, joka osaa reitittää sinne, on jo sen rajan sisällä, johon luotit.

Tarkista sivu ja live-uudelleenlatauksen socket yhdessä

Lataa tuore pyyntö aiommalta asiakkaalta määritetyllä skeemalla ja lue tulos, älä välimuistia. HTTPS:lle säilytä odotettu isäntänimi ja varmenteen vahvistus, koska selaimen varoitus ei ole onnistunut hyväksymistesti. Sivu, joka renderöityy, kun live-uudelleenlataus epäonnistuu hiljaa, on täällä yleisin osittainen onnistuminen, ja se on helppo jättää huomaamatta nopeassa tarkistuksessa.

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

Avaa sitten selaimen verkkodiagnostiikka ja seuraa WebSocket-yhteyttä. Sivu voi latautua yhden isäntänimen, portin ja skeeman kautta, kun uudelleenlatauksen socket käyttää toista, minkä vuoksi ne on tarkistettava erikseen. Määritä dokumentoitu asiakas-URL vain, kun käyttöön otettu polku todella tarvitsee eri arvon, ja korjaa mieluummin polku kuin opeta asiakkaalle kiertotie.

Kirjaa kuuntelijan osoite, hyväksytty nimi, sallittu lähde ja molemmat tulokset projektin muistiinpanoihin. Se merkintä selviää seuraavalle ihmiselle, joka käynnistää työtilan ja ihmettelee, miksi sivu latautuu mutta ei koskaan päivity.