Kiel servi webpack-an evoluigservilon je VPN-adreso

Elektu la bind-adreson laŭ kiu devas atingi la evoluigservilon, poste limigu la gastnom-kontrolon kaj konfirmu, ke kaj la paĝo kaj la vivreŝarga ingo konektiĝas.

Evoluigservilo, kiu respondas sur la tekkomputilo kaj nenie alie, estas kutime ligita al la malĝusta adreso. Servilo, kiu akceptas la konekton sed rifuzas la paĝon, kutime malsukcesas gastnom-kontrolon. Tiuj estas malsamaj difektoj kun malsamaj riparoj, kaj la elekto de la ĝusta agordo dependas de tio, kiu devas atingi la laborspacon kaj kiel ili alvenas.

Tri demandoj decidas la respondon: kiu konektiĝas, kiun adreson ili povas atingi, kaj ĉu viva reŝargo devas funkcii por ili.

Komencu per la ingo, ne per la agorda dosiero

Legu, al kio la funkcianta procezo efektive ligiĝis ene de la sama reta kunteksto, kiu ĝin lanĉis, ĉar ujo aŭ nomspaco povas posedi ingon, kiun la gastiga ŝelo ne povas vidi. La aŭskulta kolumno respondas la unuan demandon: nur loka vojo, unu specifa interfaco aŭ ĉiu interfaco.

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

Loopback-adreso estas la sekura defaŭlto kaj senutila por fora kliento. Ĵokera bind estas oportuna kaj elmetas la pordon sur ĉiu interfaco kun vojo, kio estas pli vasta ol plej multaj intencas sur maŝino, kiu ankaŭ portas tunelon. Specifa adreso estas la meza opcio, kaj ĝi funkcias nur se la interfaco posedas tiun adreson en la momento de kreado de la ingo. La distingo gravas, ĉar du el tiuj tri bindoj aspektas identaj en la retumilo kaj kondutas tute alimaniere, kiam ekzistas dua interfaco.

Adaptu vin al tiu observo antaŭ ol tuŝi vojojn aŭ fajroŝirmilajn regulojn. Se la procezo aŭskultas je la malĝusta adreso, nenia politika enkursigado igos la klienton atingi ĝin.

Elektu la bind-adreson laŭ kiu devas atingi ĝin

Se nur vi sur ĉi tiu maŝino bezonas la paĝon, konservu la loopback-bindon kaj haltu. Se unu kolego sur la sama tunelo bezonas ĝin, ligu la adreson de la tunela interfaco kaj lasu la fajroŝirmilon permesi nur tiun fonton. Publikigi evoluigservilon preter la homoj, kiuj aktive testas ĝin estas kutimo, kiu finfine elmetas laborspacon al la interreto.

Se retumilo ene de ujo devas atingi la servilon, la bind-adreso devas esti tiu, al kiu la reto de la ujo povas enkursigi, kaj tio ofte ne estas la adreso, kiun la gastigo solvas por si mem. Decidu la kazon antaŭ ol redakti la agordon, ĉar la tri kazoj produktas tri malsamajn valorojn kaj nur unu estas ĝusta. Diveni ĉi tie malŝparas pli da tempo ol iu ajn alia parto de la agordado.

Poste agordu la adreson en la formo, kiun via lanĉilo efektive legas. Agorda dosiero kaj skripto, kiu konstruas la servilon programe, ne konsumas la samajn opciojn:

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

La adreso en tiu fragmento estas ilustra kaj staras por la VPN-adreso, kiun posedas la gastigo. Se la projekto konstruas la servilon per new WebpackDevServer(options, compiler), transdonu la opciojn per la konstruila argumento anstataŭe, ĉar la aparta devServer -propraĵo en la webpack-agordo ne estas konsultata sur tiu vojo. Tiu diferenco inter la agorda dosiero kaj la Node-API kaptas homojn, kiuj kopias fragmenton en projekton, kiu neniam legas ĝin. La dokumentaro de dev-server apartigas la du lanĉostilojn kaj estas la referenco, kontraŭ kiu kontroli la uzatan version.

Agordigu la gastnom-kontrolon al la nomoj, kiujn vi aprobas

La gastnom-kontrolo ekzistas por malhelpi paĝon servitan de atakanto-kontrolita nomo paroli kun via evoluigservilo tra la retumilo. Malŝalti ĝin per allowedHosts: "all" forigas tiun protekton, kaj la oportuno malofte valoras tion sur maŝino, kiu povas atingi internajn servojn. La kontrolo estas malmultekosta plenumiĝi ĝuste, kiam vi scias, kiujn nomojn la retumilo sendos.

Listigu la precizajn nomojn, kiujn vi uzos, inkluzive de la privata nomo, kiu solviĝas al la tunela adreso. Se la kliento solvas nomon al adreso malsama ol tiu, kiun vi ligis, vi havas nom-solvan problemon kaj ne servilan agordan problemon, kaj aldoni la nomon al la permeslisto ne riparos ĝin. Konfirmu la solvon de la kliento, ne de la servilo.

Tenu la tri regilojn apartaj en la kapo: la bind-adreso decidas, kiuj interfacoj akceptas la konekton, la permeslisto decidas, kiuj Host-kapoj estas akceptataj, kaj aŭtentikigo decidas, kiu rajtas eniri. Nur la tria estas alirkontrolo, kaj evoluigservilo kutime havas neniun. Ankaŭ tunela adreso ne estas aŭtentikiga mekanismo, ĉar ĉiuj, kiuj povas enkursigi al ĝi, jam estas ene de la limo, sur kiu vi fidis.

Kontrolu la paĝon kaj la vivreŝargan ingon kune

Ŝargu freŝan peton de la celita kliento kun la agordita skemo, kaj legu la rezulton anstataŭ la kaŝmemoron. Por HTTPS konservu la atendatan gastnomon kaj la atestilan validigon, ĉar retumila averto ne estas sukcesa akcepta testo. Paĝo, kiu bildiĝas dum viva reŝargo silente malsukcesas, estas la plej ofta parta sukceso ĉi tie, kaj facile preteratenteblas dum rapida kontrolo.

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

Poste malfermu la retajn diagnozojn de la retumilo kaj observu la WebSocket-konekton. Paĝo povas ŝargiĝi per unu gastnomo, pordo kaj skemo dum la reŝarga ingo uzas alian, kaj tial la du devas esti kontrolataj aparte. Agordu la dokumentitan klientan URL nur kiam la deplojita vojo vere bezonas alian valoron, kaj preferu ripari la vojon anstataŭ lernigi al la kliento ĉirkaŭvojon.

Notu la aŭskultan adreson, la akceptitan nomon, la permesitan fonton kaj ambaŭ rezultojn en la projektaj notoj. Tiu noto postvivos la sekvan personon, kiu lanĉos la laborspacon kaj demandos sin, kial la paĝo ŝargiĝas sed neniam refreŝiĝas.

Rilataj artikoloj