Kako poslužiti webpack razvojni poslužitelj na VPN adresi

Odaberite adresu vezivanja prema tome kome treba biti dostupan razvojni poslužitelj, zatim ograničite provjeru naziva hosta i potvrdite da se stranica i socket za uživo ponovno učitavanje oboje povezuju.

Razvojni poslužitelj koji odgovara na prijenosnom računalu i nigdje drugdje obično je vezan na pogrešnu adresu. Poslužitelj koji prihvaća vezu ali odbija stranicu obično ne prolazi provjeru naziva hosta. To su različite greške s različitim ispravcima, a odabir ispravne konfiguracije ovisi o tome kdo mora doći do radnog prostora i kako dolazi.

Tri pitanja određuju odgovor: tko se povezuje, koju adresu može dosegnuti i mora li im uživo ponovno učitavanje raditi.

Počnite sa socketom, a ne s konfiguracijskom datotekom

Pročitajte na što se pokrenuti proces stvarno vezao unutar istog mrežnog konteksta koji ga je pokrenuo, jer kontejner ili imenski prostor može posjedovati socket koji ljuska hosta ne može vidjeti. Stupac slušanja odgovara na prvo pitanje: samo lokalna putanja, jedno određeno sučelje ili svako sučelje.

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

Povratna adresa siguran je zadani izbor i beskorisna za udaljenog klijenta. Vezivanje na zamjenski znak prikladno je i izlaže port na svakom sučelju koje ima rutu, što je šire nego što većina ljudi namjerava na stroju koji nosi i tunel. Određena adresa je srednja opcija i radi samo ako sučelje posjeduje tu adresu u trenutku stvaranja socketa. Razlika je važna jer dva od ta tri vezivanja izgledaju jednako u pregledniku i ponašaju se posve drukčije kad se pojavi drugo sučelje.

Uskladite to zapažanje prije nego dirnete rute ili pravila vatrozida. Ako proces sluša na pogrešnoj adresi, nikakvo usmjeravanje po pravilima neće dovesti klijenta do nje.

Odaberite adresu vezivanja prema tome kdo do nje mora doći

Ako samo vama na ovom stroju treba stranica, zadržite vezivanje na povratnu adresu i stanite. Ako treba jednom kolegi na istom tunelu, vežite adresu sučelja tunela i pustite vatrozid da dopusti samo taj izvor. Objavljivanje razvojnog poslužitelja izvan kruga ljudi koji ga aktivno testiraju navika je koja na kraju izloži radni prostor internetu.

Ako preglednik unutar kontejnera mora doći do poslužitelja, adresa vezivanja mora biti ona do koje mreža kontejnera može usmjeravati, a to često nije adresa koju host razrješava za sebe. Odlučite o slučaju prije uređivanja konfiguracije, jer tri slučaja daju tri različite vrijednosti i samo je jedna ispravna. Nagađanje ovdje troši više vremena od bilo kojeg drugog dijela postavljanja.

Zatim postavite adresu u obliku koji vaš pokretač stvarno čita. Konfiguracijska datoteka i skripta koja programski gradi poslužitelj ne troše iste opcije:

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

Adresa u tom ulomku ilustrativna je i označava VPN adresu koju host posjeduje. Ako projekt gradi poslužitelj s new WebpackDevServer(options, compiler), proslijedite opcije kroz argument konstruktora umjesto toga, jer se zasebno svojstvo devServer u konfiguraciji webpacka ne provjerava na tom putu. Ta razlika između konfiguracijske datoteke i Node API-ja hvata ljude koji kopiraju isječak u projekt koji ga nikad ne čita. Dokumentacija dev-servera razdvaja dva stila pokretanja i referenca je s kojom treba usporediti verziju koja se koristi.

Uskladite provjeru naziva hosta s imenima koja odobravate

Provjera naziva hosta postoji da spriječi da stranica poslužena s napadačevog naziva razgovara s vašim razvojnim poslužiteljem preko preglednika. Isključivanje s allowedHosts: "all" uklanja tu zaštitu, a pogodnost se rijetko isplati na stroju koji može dosegnuti interne servise. Provjeru je jeftino ispravno zadovoljiti kad znate koja će imena preglednik poslati.

Navedite točna imena koja ćete koristiti, uključujući privatno ime koje se razrješava u adresu tunela. Ako klijent razrješava ime u drugu adresu od one na koju ste vezali, imate problem razrješavanja imena, a ne konfiguracije poslužitelja, i dodavanje imena na popis dopuštenih to neće popraviti. Potvrdite razrješavanje s klijenta, ne s poslužitelja.

Držite tri kontrole odvojeno u glavi: adresa vezivanja odlučuje koja sučelja prihvaćaju vezu, popis dopuštenih odlučuje koji se Host zaglavlja prihvaćaju, a autentifikacija odlučuje kome je dopušten ulazak. Samo je treća kontrola pristupa, a razvojni poslužitelj obično nema nijednu. Ni adresa tunela nije mehanizam autentifikacije, jer je svatko tko može usmjeravati do nje već unutar granice na koju ste se oslanjali.

Provjerite stranicu i socket za uživo ponovno učitavanje zajedno

Učitajte svjež zahtjev s predviđenog klijenta s konfiguriranom shemom i čitajte rezultat, a ne predmemoriju. Za HTTPS zadržite očekivani naziv hosta i provjeru certifikata, jer upozorenje preglednika nije uspješan test prihvaćanja. Stranica koja se prikaže dok uživo ponovno učitavanje tiho ne uspijeva najčešći je djelomični uspjeh ovdje i lako se propušta tijekom brze provjere.

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

Zatim otvorite mrežnu dijagnostiku preglednika i promatrajte WebSocket vezu. Stranica se može učitati preko jednog naziva hosta, porta i sheme dok socket za ponovno učitavanje koristi druge, zato se to dvoje mora provjeriti odvojeno. Konfigurirajte dokumentirani URL klijenta samo kad razmještena putanja doista treba drugu vrijednost i radije popravite putanju nego da klijenta učite zaobilaznom rješenju.

Zabilježite adresu slušatelja, prihvaćeni naziv, dopušteni izvor i oba rezultata u bilješke projekta. Taj zapis nadživi sljedeću osobu koja pokrene radni prostor i pita se zašto se stranica učitava ali nikad ne osvježava.

Povezani članci