Kuidas käivitada webpacki arendusserverit VPN-aadressil

Valige sidumisaadress selle järgi, kes peab arendusserverini jõudma, seejärel piirake hostinime kontrolli ja kinnitage, et nii leht kui ka reaalajas uuestilaadimise socket ühenduvad.

Arendusserver, mis vastab sülearvutis ja mitte mujal, on tavaliselt seotud vale aadressiga. Server, mis võtab ühenduse vastu, kuid keeldub lehest, ebaõnnestub tavaliselt hostinime kontrollis. Need on erinevad vead erinevate parandustega ning õige konfiguratsiooni valik sõltub sellest, kes peab tööruumi jõudma ja kuidas ta sinna jõuab.

Vastuse otsustavad kolm küsimust: kes ühendub, millisele aadressile ta pääseb ja kas reaalajas uuestilaadimine peab tema jaoks töötama.

Alustage socketist, mitte konfiguratsioonifailist

Lugege, millega jooksev protsess tegelikult seotud on, samas võrgukontekstis, mis selle käivitas, sest konteiner või nimeruum võib omada socketit, mida hosti kest ei näe. Kuulamisveerg vastab esimesele küsimusele: ainult kohalik tee, üks kindel liides või kõik liidesed.

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

Loopback-aadress on turvaline vaikeväärtus ja kaugkliendi jaoks kasutu. Wildcard-sidumine on mugav ja paljastab pordi igal liidesel, millel on marsruut, mis on laiem, kui enamik kavatseb masinas, mis kannab ka tunnelit. Kindel aadress on keskmine valik ja see töötab ainult siis, kui liides omab seda aadressi socketi loomise hetkel. Erinevus on oluline, sest kaks neist kolmest sidumisest näevad brauseris identsed välja ja käituvad täiesti erinevalt, kui tekib teine liides.

Arvestage selle tähelepanekuga enne marsruutide või tulemüürireeglite puudutamist. Kui protsess kuulab vale aadressi peal, ei vii ükski poliitikapõhine marsruutimine klienti sinna.

Valige sidumisaadress selle järgi, kes peab sinna jõudma

Kui lehte vajate ainult teie selles masinas, jätke loopback-sidumine alles ja lõpetage. Kui seda vajab üks kolleeg samas tunnelis, siduge tunneli liidese aadress ja laske tulemüüril lubada ainult seda allikat. Arendusserveri avaldamine kaugemale inimestest, kes seda aktiivselt testivad on harjumus, mis lõpuks paljastab tööruumi internetile.

Kui konteineri sees olev brauser peab serverini jõudma, peab sidumisaadress olema selline, kuhu konteineri võrk oskab marsruutida, ja see pole sageli aadress, mille host iseendale lahendab. Otsustage juhtum enne konfiguratsiooni muutmist, sest kolm juhtumit annavad kolm erinevat väärtust ja ainult üks on õige. Siin oletamine raiskab rohkem aega kui ükski teine seadistamise osa.

Seejärel määrake aadress kujul, mida teie käivitaja tegelikult loeb. Konfiguratsioonifail ja skript, mis ehitab serveri programmiliselt, ei tarbi samu valikuid:

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

Selle fragmendi aadress on illustratiivne ja tähistab VPN-aadressi, mida host omab. Kui projekt ehitab serveri new WebpackDevServer(options, compiler)-ga, edastage valikud selle asemel konstruktori argumendi kaudu, sest eraldi devServer omadust webpacki konfiguratsioonis sellel teel ei vaadata. See erinevus konfiguratsioonifaili ja Node API vahel püüab inimesi, kes kopeerivad katkendi projekti, mis seda kunagi ei loe. dev-serveri dokumentatsioon eristab kahte käivitusstiili ja on viide, millega kasutatavat versiooni kontrollida.

Sobitage hostinime kontroll heakskiidetud nimedega

Hostinime kontroll on selleks, et takistada ründaja kontrollitud nimelt serveeritaval lehel brauseri kaudu teie arendusserveriga rääkida. Selle keelamine allowedHosts: "all" -ga eemaldab selle kaitse ja mugavus on masinas, mis pääseb sisemistele teenustele ligi, harva seda väärt. Kontrolli on odav õigesti täita, kui teate, milliseid nimesid brauser saadab.

Loetlege täpsed nimed, mida kasutate, sealhulgas privaatne nimi, mis lahendub tunneli aadressiks. Kui klient lahendab nime teisele aadressile kui see, millele sidusite, on teil nimelahenduse probleem, mitte serveri konfiguratsiooni probleem, ja nime lubatud loendisse lisamine ei paranda seda. Kinnitage lahendus kliendist, mitte serverist.

Hoidke kolm juhtimisvahendit peas eraldi: sidumisaadress otsustab, millised liidesed ühenduse vastu võtavad, lubatud loend otsustab, millised Host-päised vastu võetakse, ja autentimine otsustab, kes sisse lastakse. Ainult kolmas on juurdepääsukontroll ja arendusserveril pole tavaliselt ühtegi. Ka tunneli aadress ei ole autentimismehhanism, sest igaüks, kes oskab sinna marsruutida, on juba seespool piiri, millele te lootsite.

Kontrollige lehte ja reaalajas uuestilaadimise socketit koos

Laadige värske päring kavandatud kliendist konfigureeritud skeemiga ja lugege tulemust, mitte vahemälu. HTTPS-i puhul hoidke eeldatav hostinimi ja sertifikaadi valideerimine, sest brauseri hoiatus ei ole õnnestunud vastuvõtutest. Leht, mis kuvatakse, samal ajal kui reaalajas uuestilaadimine vaikselt ebaõnnestub, on siin kõige tavalisem osaline edu ja seda on kiire kontrolli käigus lihtne märkamata jätta.

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

Seejärel avage brauseri võrgudiagnostika ja jälgige WebSocket-ühendust. Leht võib laadida ühe hostinime, pordi ja skeemiga, samal ajal kui uuestilaadimise socket kasutab teist, mistõttu tuleb neid kahte eraldi kontrollida. Konfigureerige dokumenteeritud kliendi URL ainult siis, kui juurutatud tee vajab tõesti teist väärtust, ja eelistage tee parandamist kliendile möödasõidu õpetamisele.

Kirjutage kuulaja aadress, vastuvõetud nimi, lubatud allikas ja mõlemad tulemused projektimärkmetesse. See kirje elab üle järgmise inimese, kes tööruumi käivitab ja imestab, miks leht laaditakse, aga kunagi ei värskendata.

Seotud artiklid