Kaip aptarnauti webpack kūrimo serverį VPN adresu

Kūrimo serveris, kuris atsako nešiojamajame kompiuteryje ir niekur kitur, paprastai būna pririštas prie neteisingo adreso. Serveris, kuris priima ryšį, bet atmeta puslapį, paprastai nepraeina pagrindinio kompiuterio vardo patikros. Tai skirtingi gedimai su skirtingais pataisymais, o tinkamos konfigūracijos pasirinkimas priklauso nuo to, kas turi pasiekti darbo sritį ir kaip jis atvyksta.

Atsakymą lemia trys klausimai: kas jungiasi, kokį adresą jis gali pasiekti ir ar jam turi veikti tiesioginis perkrovimas.

Pradėkite nuo lizdo, o ne nuo konfigūracijos failo

Perskaitykite, prie ko iš tikrųjų pririštas veikiantis procesas tame pačiame tinklo kontekste, kuris jį paleido, nes konteineris ar vardų erdvė gali turėti lizdą, kurio pagrindinio kompiuterio apvalkalas nemato. Klausymosi stulpelis atsako į pirmąjį klausimą: tik vietinis kelias, viena konkreti sąsaja ar visos sąsajos.

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

Grąžinimo adresas yra saugus numatytasis ir nenaudingas nuotoliniam klientui. Pakaitos simbolio prisirišimas yra patogus ir atveria prievadą kiekvienoje sąsajoje, turinčioje maršrutą, o tai platesnė apimtis, nei dauguma numato mašinoje, kuri taip pat turi tunelį. Konkretus adresas yra vidurinis variantas, ir jis veikia tik tada, kai sąsaja turi tą adresą lizdo sukūrimo momentu. Skirtumas svarbus, nes du iš šių trijų prisirišimų naršyklėje atrodo vienodai ir elgiasi visiškai kitaip, kai atsiranda antroji sąsaja.

Atsižvelkite į šį pastebėjimą prieš liesdami maršrutus ar užkardos taisykles. Jei procesas klausosi neteisingo adreso, jokia politika pagrįsta maršrutizacija kliento ten neprives.

Pasirinkite prisirišimo adresą pagal tai, kas jį turi pasiekti

Jei tik jums šioje mašinoje reikia puslapio, palikite grąžinimo prisirišimą ir sustokite. Jei jo reikia vienam kolegai tame pačiame tunelyje, pririškite tunelio sąsajos adresą ir leiskite užkardai leisti tik tą šaltinį. Kūrimo serverio paskelbimas už tų žmonių, kurie jį aktyviai testuoja yra įprotis, kuris galiausiai atskleidžia darbo sritį internetui.

Jei naršyklė konteinerio viduje turi pasiekti serverį, prisirišimo adresas turi būti toks, į kurį konteinerio tinklas gali maršrutizuoti, ir tai dažnai nėra adresas, kurį pagrindinis kompiuteris išsprendžia sau. Nuspręskite atvejį prieš redaguodami konfigūraciją, nes trys atvejai duoda tris skirtingas reikšmes ir tik viena teisinga. Spėliojimas čia praranda daugiau laiko nei bet kuri kita sąrankos dalis.

Tada nustatykite adresą tokia forma, kurią jūsų paleidiklis iš tikrųjų skaito. Konfigūracijos failas ir scenarijus, kuris programiškai sukuria serverį, naudoja ne tas pačias parinktis:

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

To fragmento adresas yra iliustracinis ir reiškia VPN adresą, kurį turi pagrindinis kompiuteris. Jei projektas kuria serverį naudodamas new WebpackDevServer(options, compiler) perduokite parinktis per konstruktoriaus argumentą, nes atskira devServer savybė webpack konfigūracijoje tuo keliu nėra tikrinama. Šis skirtumas tarp konfigūracijos failo ir Node API pagauna tuos, kurie nukopijuoja fragmentą į projektą, kuris jo niekada neskaito. dev-server dokumentacija atskiria du paleidimo stilius ir yra nuoroda, su kuria reikia lyginti naudojamą versiją.

Suderinkite pagrindinio kompiuterio vardo patikrą su vardais, kuriuos patvirtinate

Pagrindinio kompiuterio vardo patikra egzistuoja tam, kad puslapis, patiektas iš užpuoliko kontroliuojamo vardo, negalėtų per naršyklę kalbėtis su jūsų kūrimo serveriu. Išjungimas su allowedHosts: "all" pašalina tą apsaugą, o patogumas retai vertas to mašinoje, kuri pasiekia vidines paslaugas. Patikrą pigu teisingai patenkinti, kai žinote, kokius vardus naršyklė siųs.

Išvardykite tikslius vardus, kuriuos naudosite, įskaitant privatų vardą, kuris išsprendžiamas į tunelio adresą. Jei klientas išsprendžia vardą į kitą adresą nei tas, prie kurio prisirišote, turite vardų sprendimo problemą, o ne serverio konfigūracijos problemą, ir vardo pridėjimas į leidžiamų sąrašą to neištaisys. Patvirtinkite sprendimą iš kliento, o ne iš serverio.

Trys valdikliai laikykite atskirai galvoje: prisirišimo adresas nusprendžia, kurios sąsajos priima ryšį, leidžiamų sąrašas nusprendžia, kurios Host antraštės priimamos, o autentifikavimas nusprendžia, kas įleidžiamas. Tik trečiasis yra prieigos kontrolė, ir kūrimo serveris paprastai jos neturi. Tunelio adresas taip pat nėra autentifikavimo mechanizmas, nes kiekvienas, kuris gali ten maršrutizuoti, jau yra tos ribos, kuria rėmėtės, viduje.

Patikrinkite puslapį ir tiesioginio perkrovimo lizdą kartu

Įkelkite naują užklausą iš numatyto kliento su sukonfigūruota schema ir skaitykite rezultatą, o ne talpyklą. HTTPS atveju palikite laukiamą pagrindinio kompiuterio vardą ir sertifikato tikrinimą, nes naršyklės įspėjimas nėra sėkmingas priėmimo testas. Puslapis, kuris atvaizduojamas, kai tiesioginis perkrovimas tyliai nepavyksta, čia yra dažniausia dalinė sėkmė, ir ją lengva praleisti atliekant greitą patikrą.

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

Tada atidarykite naršyklės tinklo diagnostiką ir stebėkite WebSocket ryšį. Puslapis gali įsikelti per vieną pagrindinio kompiuterio vardą, prievadą ir schemą, o perkrovimo lizdas naudoja kitą, todėl abu reikia tikrinti atskirai. Konfigūruokite dokumentuotą kliento URL tik tada, kai įdiegtas kelias tikrai reikalauja kitos reikšmės, ir pirmenybę teikite kelio taisymui, o ne apėjimo mokymui klientui.

Užrašykite klausytojo adresą, priimtą vardą, leidžiamą šaltinį ir abu rezultatus projekto pastabose. Tas įrašas išlieka kitam žmogui, kuris paleis darbo sritį ir stebėsis, kodėl puslapis įkeliamas, bet niekada neatnaujinamas.