Kako streči razvojnemu strežniku webpack na naslovu VPN

Razvojni strežnik, ki odgovarja na prenosniku in nikjer drugje, je običajno vezan na napačen naslov. Strežnik, ki povezavo sprejme, a stran zavrne, običajno ne opravi preverjanja imena gostitelja. To so različne napake z različnimi popravki, izbira pravilne konfiguracije pa je odvisna od tega, kdo mora doseči delovni prostor in kako tja pride.

Odgovor določajo tri vprašanja: kdo se poveže, kateri naslov lahko doseže in ali mora za njega delovati sprotno ponovno nalaganje.

Začnite z vtičnico, ne s konfiguracijsko datoteko

Preberite, na kaj je tekoči proces dejansko vezan, v istem omrežnem kontekstu, ki ga je zagnal, ker je lahko vsebnik ali imenski prostor lastnik vtičnice, ki je lupina gostitelja ne vidi. Stolpec poslušanja odgovori na prvo vprašanje: samo lokalna pot, en določen vmesnik ali vsi vmesniki.

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

Naslov povratne zanke je varna privzeta vrednost in neuporaben za oddaljenega odjemalca. Vezava z nadomestnim znakom je priročna in izpostavi vrata na vsakem vmesniku s potjo, kar je širše, kot namerava večina ljudi na stroju, ki nosi tudi tunel. Določen naslov je srednja možnost in deluje le, če ima vmesnik ta naslov v trenutku ustvarjanja vtičnice. Razlika je pomembna, ker sta dve od teh treh vezav v brskalniku videti enako in se obnašata povsem drugače, ko obstaja drugi vmesnik.

Temu opažanju se prilagodite, preden se dotaknete poti ali pravil požarnega zidu. Če proces posluša na napačnem naslovu, nobeno usmerjanje po pravilniku ne bo pripeljalo odjemalca tja.

Izberite naslov vezave glede na to, kdo ga mora doseči

Če stran potrebujete samo vi na tem stroju, ohranite vezavo povratne zanke in se ustavite. Če jo potrebuje en sodelavec v istem tunelu, vežite naslov vmesnika tunela in pustite požarnemu zidu, da dovoli samo ta vir. Objavljanje razvojnega strežnika zunaj kroga ljudi, ki ga aktivno preizkušajo je navada, ki na koncu izpostavi delovni prostor internetu.

Če mora brskalnik v vsebniku doseči strežnik, mora biti naslov vezave tak, da lahko omrežje vsebnika usmerja nanj, in to pogosto ni naslov, ki ga gostitelj razreši zase. Odločite se o primeru pred urejanjem konfiguracije, ker trije primeri dajo tri različne vrednosti in samo ena je pravilna. Ugibanje tukaj izgubi več časa kot kateri koli drug del nastavitve.

Nato nastavite naslov v obliki, ki jo vaš zaganjalnik resnično bere. Konfiguracijska datoteka in skripta, ki strežnik sestavi programsko, ne porabita istih možnosti:

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

Naslov v tem izseku je ponazoritven in predstavlja naslov VPN, ki ga ima gostitelj. Če projekt sestavi strežnik s new WebpackDevServer(options, compiler) možnosti posredujte skozi argument konstruktorja, ker se ločena lastnost devServer v konfiguraciji webpacka na tej poti ne upošteva. Ta razlika med konfiguracijsko datoteko in Node API ujame ljudi, ki izsek kopirajo v projekt, ki ga nikoli ne prebere. Dokumentacija dev-serverja ločuje dva načina zagona in je referenca, s katero je treba primerjati uporabljeno različico.

Preverjanje imena gostitelja uskladite z imeni, ki jih odobrite

Preverjanje imena gostitelja obstaja zato, da prepreči strani, postreženi z imena pod nadzorom napadalca, da bi prek brskalnika govorila z vašim razvojnim strežnikom. Izklop z allowedHosts: "all" to zaščito odstrani, priročnost pa se na stroju, ki doseže notranje storitve, redko izplača. Preverjanje je poceni pravilno izpolniti, ko veste, katera imena bo poslal brskalnik.

Naštejte natančna imena, ki jih boste uporabili, vključno z zasebnim imenom, ki se razreši na naslov tunela. Če odjemalec razreši ime na drug naslov kot tistega, na katerega ste vezali, imate težavo z razreševanjem imen in ne s konfiguracijo strežnika, in dodajanje imena na seznam dovoljenih tega ne popravi. Razrešitev potrdite pri odjemalcu, ne pri strežniku.

V glavi imejte tri nadzore ločeno: naslov vezave odloča, kateri vmesniki sprejmejo povezavo, seznam dovoljenih odloča, katere glave Host so sprejete, preverjanje pristnosti pa odloča, kdo sme noter. Samo tretji je nadzor dostopa in razvojni strežnik običajno nima nobenega. Tudi naslov tunela ni mehanizem preverjanja pristnosti, saj je vsakdo, ki lahko usmerja nanj, že znotraj meje, na katero ste se zanašali.

Preverite stran in vtičnico za sprotno ponovno nalaganje skupaj

Naložite svežo zahtevo od predvidenega odjemalca z nastavljeno shemo in berite rezultat, ne predpomnilnika. Pri HTTPS ohranite pričakovano ime gostitelja in preverjanje potrdila, ker opozorilo brskalnika ni uspešen sprejemni test. Stran, ki se izriše, medtem ko sprotno ponovno nalaganje tiho ne uspe, je tukaj najpogostejši delni uspeh in ga je pri hitrem pregledu lahko spregledati.

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

Nato odprite omrežno diagnostiko brskalnika in opazujte povezavo WebSocket. Stran se lahko naloži prek enega imena gostitelja, vrat in sheme, medtem ko vtičnica za ponovno nalaganje uporablja drugega, zato je treba oba preveriti ločeno. Dokumentirani URL odjemalca nastavite le, ko nameščena pot resnično potrebuje drugo vrednost, in raje popravite pot, kot da odjemalca učite obhoda.

Zapišite naslov poslušalca, sprejeto ime, dovoljeni vir in oba rezultata v projektne opombe. Ta zapis preživi naslednjo osebo, ki zažene delovni prostor in se sprašuje, zakaj se stran naloži, a se nikoli ne osveži.