Jak provozovat webpack vývojový server na adrese VPN

Zvolte adresu pro naslouchání podle toho, kdo se k vývojovému serveru musí dostat, potom omezte kontrolu názvu hostitele a ověřte, že se stránka i socket živého načítání skutečně připojí.

Vývojový server, který odpovídá na notebooku a nikde jinde, bývá obvykle navázán na špatnou adresu. Server, který připojení přijme, ale stránku odmítne, obvykle neprojde kontrolou názvu hostitele. To jsou různé závady s různými opravami a volba správné konfigurace závisí na tom, kdo se musí do pracovního prostoru dostat a jak se tam dostává.

Odpověď určují tři otázky: kdo se připojuje, kterou adresu může dosáhnout a zda mu musí fungovat živé načítání.

Začněte socketem, ne konfiguračním souborem

Přečtěte si, k čemu se běžící proces skutečně navázal, ve stejném síťovém kontextu, který ho spustil, protože kontejner nebo jmenný prostor může vlastnit socket, který shell hostitele nevidí. Sloupec naslouchání odpovídá na první otázku: jen lokální cesta, jedno konkrétní rozhraní, nebo všechna rozhraní.

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

Adresa zpětné smyčky je bezpečná volba a pro vzdáleného klienta nepoužitelná. Navázání na zástupný znak je pohodlné a vystavuje port na každém rozhraní, které má trasu, což je širší, než většina lidí zamýšlí na stroji, který zároveň nese tunel. Konkrétní adresa je prostřední možnost a funguje jen tehdy, když rozhraní tuto adresu vlastní v okamžiku vytvoření socketu. Rozdíl je důležitý, protože dvě z těchto tří navázání vypadají v prohlížeči stejně a chovají se úplně jinak, jakmile existuje druhé rozhraní.

Tomuto pozorování se přizpůsobte dřív, než sáhnete na trasy nebo pravidla firewallu. Pokud proces naslouchá na špatné adrese, žádné směrování podle zásad klienta k němu nedostane.

Zvolte adresu navázání podle toho, kdo se k ní musí dostat

Pokud stránku potřebujete jen vy na tomto stroji, ponechte navázání na zpětnou smyčku a skončete. Pokud ji potřebuje jeden kolega ve stejném tunelu, navažte adresu rozhraní tunelu a nechte firewall povolit jen tento zdroj. Zveřejňování vývojového serveru mimo okruh lidí, kteří ho aktivně testují je návyk, který nakonec vystaví pracovní prostor internetu.

Pokud se prohlížeč uvnitř kontejneru musí dostat na server, musí být adresa navázání taková, aby na ni síť kontejneru uměla směrovat, a to často není adresa, kterou si hostitel přeloží sám pro sebe. Rozhodněte případ před úpravou konfigurace, protože tři případy dávají tři různé hodnoty a správná je jen jedna. Hádání zde ztrácí více času než kterákoli jiná část nastavení.

Potom adresu nastavte ve formě, kterou váš spouštěč skutečně čte. Konfigurační soubor a skript, který server sestavuje programově, nespotřebovávají stejné volby:

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

Adresa v tomto fragmentu je ilustrativní a zastupuje adresu VPN, kterou hostitel vlastní. Pokud projekt sestavuje server pomocí new WebpackDevServer(options, compiler), předejte volby místo toho argumentem konstruktoru, protože samostatná vlastnost devServer v konfiguraci webpacku se touto cestou nečte. Tento rozdíl mezi konfiguračním souborem a Node API chytá lidi, kteří zkopírují úryvek do projektu, který ho nikdy nepřečte. Dokumentace dev-serveru odděluje dva styly spouštění a je referencí, se kterou je třeba porovnat používanou verzi.

Přizpůsobte kontrolu názvu hostitele názvům, které schvalujete

Kontrola názvu hostitele existuje proto, aby zabránila stránce poskytnuté z názvu ovládaného útočníkem mluvit s vaším vývojovým serverem přes prohlížeč. Vypnutí pomocí allowedHosts: "all" tuto ochranu odstraňuje a pohodlí se na stroji, který dosáhne na interní služby, málokdy vyplatí. Kontrolu je levné správně splnit, jakmile víte, které názvy prohlížeč pošle.

Vyjmenujte přesné názvy, které budete používat, včetně soukromého názvu, který se překládá na adresu tunelu. Pokud klient přeloží název na jinou adresu, než na kterou jste navázali, máte problém s překladem názvů, ne s konfigurací serveru, a přidání názvu do seznamu povolených to nespraví. Ověřte překlad z klienta, ne ze serveru.

Mějte tři ovládací prvky odděleně v hlavě: adresa navázání rozhoduje, která rozhraní přijímají spojení, seznam povolených rozhoduje, které hlavičky Host se přijímají, a ověřování rozhoduje, kdo smí dovnitř. Jen třetí je řízení přístupu a vývojový server obvykle nemá žádné. Ani adresa tunelu není autentizační mechanismus, protože každý, kdo na ni umí směrovat, je už uvnitř hranice, na kterou jste se spoléhali.

Ověřte stránku i socket živého načítání společně

Načtěte nový požadavek od zamýšleného klienta s nakonfigurovaným schématem a čtěte výsledek, ne mezipaměť. U HTTPS zachovejte očekávaný název hostitele a ověření certifikátu, protože varování prohlížeče není úspěšný akceptační test. Stránka, která se vykreslí, zatímco živé načítání tiše selhává, je zde nejčastější částečný úspěch a při rychlé kontrole snadno unikne.

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 otevřete síťovou diagnostiku prohlížeče a sledujte spojení WebSocket. Stránka se může načíst přes jeden název hostitele, port a schéma, zatímco socket pro načítání používá jiné, proto je třeba obojí zkontrolovat zvlášť. Dokumentovanou URL klienta nastavte jen tehdy, když nasazená cesta skutečně potřebuje jinou hodnotu, a dejte přednost opravě cesty před učením klienta obchvatnému řešení.

Zapište adresu naslouchajícího, přijatý název, povolený zdroj a oba výsledky do poznámek projektu. Tento záznam přežije dalšího člověka, který pracovní prostor spustí a bude se divit, proč se stránka načte, ale nikdy neobnoví.

Související články