Hogyan szolgáljunk ki egy webpack fejlesztői szervert VPN-címen

Az a fejlesztői szerver, amely a laptopon válaszol és sehol másutt, általában rossz címhez van kötve. Az a szerver, amely elfogadja a kapcsolatot, de elutasítja az oldalt, általában elbukik egy hosztnév-ellenőrzésen. Ezek különböző hibák különböző javításokkal, és a helyes konfiguráció kiválasztása attól függ, kinek kell elérnie a munkaterületet és hogyan érkezik.

Három kérdés dönti el a választ: ki csatlakozik, melyik címet érheti el, és kell-e neki működnie az élő újratöltésnek.

A socketből induljon ki, ne a konfigurációs fájlból

Olvassa el, mihez van valójában kötve a futó folyamat, ugyanabban a hálózati környezetben, amely elindította, mert egy konténer vagy névtér birtokolhat olyan socketet, amelyet a hoszt héja nem lát. A figyelő oszlop az első kérdésre válaszol: csak helyi útvonal, egy adott interfész vagy minden interfész.

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

A loopback-cím a biztonságos alapértelmezés, és hasznavehetetlen távoli kliens számára. A wildcard-kötés kényelmes, és minden útvonallal rendelkező interfészen feltárja a portot, ami szélesebb annál, mint amire a legtöbben számítanak egy olyan gépen, amely alagutat is hordoz. Az adott cím a középső lehetőség, és csak akkor működik, ha az interfész a socket létrehozásának pillanatában birtokolja azt a címet. A megkülönböztetés fontos, mert e három kötés közül kettő ugyanúgy néz ki a böngészőben, és teljesen másképp viselkedik, amint létezik egy második interfész.

Ehhez a megfigyeléshez igazodjon, mielőtt útvonalakhoz vagy tűzfalszabályokhoz nyúl. Ha a folyamat rossz címen figyel, semmilyen házirend-alapú útválasztás nem juttatja el hozzá a klienst.

A kötési címet aszerint válassza ki, kinek kell elérnie

Ha csak önnek kell az oldal ezen a gépen, tartsa meg a loopback-kötést, és álljon meg. Ha egy kollégának ugyanazon az alagúton kell, kösse az alagút interfészének címéhez, és engedje a tűzfalnak csak azt a forrást. Egy fejlesztői szerver közzététele azon túl, akik aktívan tesztelik olyan szokás, amely végül kitárja a munkaterületet az internet felé.

Ha egy konténeren belüli böngészőnek el kell érnie a szervert, a kötési címnek olyannak kell lennie, amelyre a konténer hálózata tud útválasztani, és ez gyakran nem az a cím, amelyet a hoszt magának felold. Döntse el az esetet a konfiguráció szerkesztése előtt, mert a három eset három különböző értéket ad, és csak egy helyes. A találgatás itt több időt pazarol, mint a beállítás bármely más része.

Ezután állítsa be a címet abban a formában, amelyet az indítója valóban olvas. A konfigurációs fájl és a szervert programozottan építő szkript nem ugyanazokat az opciókat fogyasztja:

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

A részletben szereplő cím szemléltető, és a hoszt által birtokolt VPN-címet jelöli. Ha a projekt a szervert a new WebpackDevServer(options, compiler)-kal építi, adja át az opciókat inkább a konstruktor argumentumán keresztül, mert a különálló devServer tulajdonságot a webpack konfigurációjában ezen az úton nem veszik figyelembe. Ez a különbség a konfigurációs fájl és a Node API között azokat kapja el, akik egy részletet olyan projektbe másolnak, amely soha nem olvassa el. A dev-server dokumentációja elválasztja a két indítási stílust, és ez a hivatkozás, amelyhez a használt verziót ellenőrizni kell.

Igazítsa a hosztnév-ellenőrzést az engedélyezett nevekhez

A hosztnév-ellenőrzés azért létezik, hogy megakadályozza egy támadó által irányított névről kiszolgált oldal böngészőn keresztüli beszélgetését a fejlesztői szerverével. Kikapcsolása a allowedHosts: "all" beállítással eltávolítja ezt a védelmet, és a kényelem ritkán éri meg egy olyan gépen, amely belső szolgáltatásokat ér el. Az ellenőrzést olcsó helyesen teljesíteni, ha tudja, milyen neveket küld a böngésző.

Sorolja fel a pontosan használt neveket, beleértve azt a privát nevet, amely az alagút címére oldódik fel. Ha a kliens egy nevet más címre old fel, mint amelyhez kötötte, névfeloldási problémája van, nem szerverkonfigurációs problémája, és a név engedélylistára való felvétele nem javítja meg. A feloldást a kliensről erősítse meg, nem a szerverről.

Tartsa fejben külön a három vezérlőt: a kötési cím dönti el, mely interfészek fogadják a kapcsolatot, az engedélylista dönti el, mely Host fejlécek fogadhatók el, és a hitelesítés dönti el, kit engednek be. Csak a harmadik hozzáférés-vezérlés, és egy fejlesztői szervernek általában nincs egy sem. Az alagút cím sem hitelesítési mechanizmus, mert bárki, aki oda tud útválasztani, már azon a határon belül van, amelyre támaszkodott.

Ellenőrizze az oldalt és az élő újratöltési socketet együtt

Töltsön be egy friss kérést a szándékolt kliensről a beállított sémával, és az eredményt olvassa, ne a gyorsítótárat. HTTPS esetén tartsa meg a várt hosztnevet és a tanúsítvány-ellenőrzést, mert a böngészőfigyelmeztetés nem sikeres átvételi teszt. Az az oldal, amely megjelenik, miközben az élő újratöltés csendben meghiúsul, itt a leggyakoribb részleges siker, és egy gyors ellenőrzés során könnyű kihagyni.

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

Ezután nyissa meg a böngésző hálózati diagnosztikáját, és figyelje a WebSocket-kapcsolatot. Egy oldal betölthető egy hosztnéven, porton és sémán, miközben az újratöltési socket másikat használ, ezért a kettőt külön kell ellenőrizni. A dokumentált kliens URL-t csak akkor állítsa be, ha a telepített útvonal valóban más értéket igényel, és inkább az útvonalat javítsa, mint hogy megkerülő megoldást tanítson a kliensnek.

Jegyezze fel a figyelő címét, az elfogadott nevet, az engedélyezett forrást és mindkét eredményt a projekt megjegyzéseibe. Ez a feljegyzés túléli a következő embert, aki elindítja a munkaterületet, és azon tűnődik, miért töltődik be az oldal, de soha nem frissül.