Ako prevádzkovať webpack vývojový server na adrese VPN

Vyberte adresu naviazania podľa toho, kto sa musí dostať k vývojovému serveru, potom obmedzte kontrolu názvu hostiteľa a overte, že sa pripojí stránka aj socket živého načítania.

Vývojový server, ktorý odpovedá na notebooku a nikde inde, býva zvyčajne naviazaný na nesprávnu adresu. Server, ktorý prijme pripojenie, ale stránku odmietne, zvyčajne neprejde kontrolou názvu hostiteľa. Sú to rôzne poruchy s rôznymi opravami a výber správnej konfigurácie závisí od toho, kto sa musí dostať do pracovného priestoru a ako sa tam dostane.

Odpoveď určujú tri otázky: kto sa pripája, ktorú adresu môže dosiahnuť a či mu musí fungovať živé načítanie.

Začnite socketom, nie konfiguračným súborom

Prečítajte si, k čomu sa bežiaci proces skutočne naviazal, v tom istom sieťovom kontexte, ktorý ho spustil, pretože kontajner alebo menný priestor môže vlastniť socket, ktorý shell hostiteľa nevidí. Stĺpec počúvania odpovedá na prvú otázku: len lokálna cesta, jedno konkrétne rozhranie alebo všetky rozhrania.

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

Adresa spätnej slučky je bezpečná predvoľba a pre vzdialeného klienta nepoužiteľná. Naviazanie na zástupný znak je pohodlné a vystavuje port na každom rozhraní, ktoré má trasu, čo je širšie, než väčšina ľudí zamýšľa na stroji, ktorý nesie aj tunel. Konkrétna adresa je stredná možnosť a funguje len vtedy, keď rozhranie túto adresu vlastní v okamihu vytvorenia socketu. Rozdiel je dôležitý, pretože dve z týchto troch naviazaní vyzerajú v prehliadači rovnako a správajú sa úplne inak, keď existuje druhé rozhranie.

Prispôsobte sa tomuto pozorovaniu skôr, než sa dotknete trás alebo pravidiel firewallu. Ak proces počúva na nesprávnej adrese, žiadne smerovanie podľa pravidiel klienta k nej nedostane.

Vyberte adresu naviazania podľa toho, kto sa k nej musí dostať

Ak stránku potrebujete len vy na tomto stroji, ponechajte naviazanie na spätnú slučku a skončite. Ak ju potrebuje jeden kolega v tom istom tuneli, naviažte adresu rozhrania tunela a nechajte firewall povoliť len tento zdroj. Zverejňovanie vývojového servera mimo okruhu ľudí, ktorí ho aktívne testujú je návyk, ktorý napokon vystaví pracovný priestor internetu.

Ak sa prehliadač v kontajneri musí dostať na server, adresa naviazania musí byť taká, aby na ňu sieť kontajnera vedela smerovať, a to často nie je adresa, ktorú si hostiteľ preloží sám pre seba. Rozhodnite prípad pred úpravou konfigurácie, pretože tri prípady dávajú tri rôzne hodnoty a správna je len jedna. Hádanie tu stráca viac času než ktorákoľvek iná časť nastavenia.

Potom nastavte adresu v podobe, ktorú váš spúšťač skutočne číta. Konfiguračný súbor a skript, ktorý server zostavuje programovo, nespotrebúvajú rovnaké voľby:

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

Adresa v tomto fragmente je ilustratívna a zastupuje adresu VPN, ktorú hostiteľ vlastní. Ak projekt zostavuje server pomocou new WebpackDevServer(options, compiler) odovzdajte voľby namiesto toho argumentom konštruktora, pretože samostatná vlastnosť devServer v konfigurácii webpacku sa touto cestou nečíta. Tento rozdiel medzi konfiguračným súborom a Node API chytá ľudí, ktorí skopírujú úryvok do projektu, ktorý ho nikdy neprečíta. Dokumentácia dev-servera oddeľuje dva štýly spúšťania a je referenciou, s ktorou treba porovnať používanú verziu.

Prispôsobte kontrolu názvu hostiteľa názvom, ktoré schvaľujete

Kontrola názvu hostiteľa existuje preto, aby zabránila stránke poskytnutej z názvu ovládaného útočníkom hovoriť s vaším vývojovým serverom cez prehliadač. Vypnutie pomocou allowedHosts: "all" túto ochranu odstraňuje a pohodlie sa na stroji, ktorý dosiahne na interné služby, málokedy vyplatí. Kontrolu je lacné správne splniť, keď viete, ktoré názvy prehliadač pošle.

Vymenujte presné názvy, ktoré budete používať, vrátane súkromného názvu, ktorý sa prekladá na adresu tunela. Ak klient preloží názov na inú adresu, než na ktorú ste naviazali, máte problém s prekladom názvov, nie s konfiguráciou servera, a pridanie názvu do zoznamu povolených to nespraví. Overte preklad z klienta, nie zo servera.

Majte tri ovládacie prvky oddelene v hlave: adresa naviazania rozhoduje, ktoré rozhrania prijímajú spojenie, zoznam povolených rozhoduje, ktoré hlavičky Host sa prijímajú, a overovanie rozhoduje, kto smie dnu. Len tretí je riadenie prístupu a vývojový server zvyčajne nemá žiadne. Ani adresa tunela nie je autentizačný mechanizmus, pretože každý, kto na ňu vie smerovať, je už vnútri hranice, na ktorú ste sa spoliehali.

Overte stránku aj socket živého načítania spoločne

Načítajte novú požiadavku od zamýšľaného klienta s nakonfigurovanou schémou a čítajte výsledok, nie vyrovnávaciu pamäť. Pri HTTPS zachovajte očakávaný názov hostiteľa a overenie certifikátu, pretože varovanie prehliadača nie je úspešný akceptačný test. Stránka, ktorá sa vykreslí, zatiaľ čo živé načítanie ticho zlyháva, je tu najčastejší čiastočný úspech a pri rýchlej kontrole sa ľahko prehliadne.

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

Potom otvorte sieťovú diagnostiku prehliadača a sledujte spojenie WebSocket. Stránka sa môže načítať cez jeden názov hostiteľa, port a schému, zatiaľ čo socket načítania používa iné, preto treba obe skontrolovať zvlášť. Dokumentovanú URL klienta nastavte len vtedy, keď nasadená cesta skutočne potrebuje inú hodnotu, a uprednostnite opravu cesty pred učením klienta obchádzke.

Zapíšte adresu počúvajúceho, prijatý názov, povolený zdroj a oba výsledky do poznámok projektu. Tento záznam prežije ďalšieho človeka, ktorý pracovný priestor spustí a bude sa čudovať, prečo sa stránka načíta, ale nikdy neobnoví.

Súvisiace články