Nola zerbitzatu webpack garapen-zerbitzari bat VPN helbide batean

Eramangarrian erantzuten duen eta inon gehiago ez duen garapen-zerbitzari bat ohi helbide okerrean lotuta egoten da. Konexioa onartzen baina orria ukatzen duen zerbitzari batek ostalari-izenaren egiaztapen batean huts egiten du normalean. Akats ezberdinak dira, konponbide ezberdinekin, eta konfigurazio egokia aukeratzea lan-eremura nor iritsi behar den eta nola iristen den araberakoa da.

Hiru galderak erabakitzen dute erantzuna: nork konektatzen duen, zein helbide lor dezakeen eta zuzeneko birkarga haientzat funtzionatu behar duen.

Hasi socket-arekin, ez konfigurazio-fitxategiarekin

Irakurri exekutatzen ari den prozesuak zeri lotu dion benetan, abiarazi zuen sare-testuinguru berean, zeren edukiontzi batek edo izen-espazio batek ostalariaren shell-ak ikusten ez duen socket bat eduki baitezake. Entzute-zutabeak lehen galderari erantzuten dio: bide lokal soilik, interfaze zehatz bat edo interfaze guztiak.

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

Loopback helbide bat lehenespen segurua da eta urrutiko bezeroarentzat alferrikakoa. Komodin lotze bat erraza da eta bidea duen interfaze guztietan jartzen du portua agerian, hau da, tunel bat ere daraman makinan gehienek nahi dutena baino zabalagoa. Helbide zehatz bat erdiko aukera da, eta socket-a sortzen den unean interfazeak helbide hori badu soilik funtzionatzen du. Bereizketa garrantzitsua da, hiru lotze horietatik bik berdinak diruditelako nabigatzailean eta erabat ezberdin jokatzen dutelako bigarren interfaze bat dagoenean.

Egokitu behaketa horri bideak edo suebaki-arauak ukitu aurretik. Prozesua helbide okerrean entzuten ari bada, ez du policy routing-ik bezeroa hara iritsaraziko.

Aukeratu lotze-helbidea hara nor iritsi behar den arabera

Makina honetan zuri bakarrik behar baduzu orria, mantendu loopback lotzea eta gelditu. Tunel berean dagoen lankide bati behar badio, lotu tunelaren interfazearen helbidea eta utzi suebakiari iturri hori soilik baimentzen. Garapen-zerbitzari bat aktiboki probatzen ari diren pertsonetatik harago argitaratzea lan-eremua interneten azkenean agerian uzten duen ohitura da.

Edukiontzi baten barruko nabigatzaile batek zerbitzarira iritsi behar badu, lotze-helbidea edukiontziaren sareak bideratu dezakeen bat izan behar da, eta hori sarritan ez da ostalariak beretzat ebazten duen helbidea. Erabaki kasua konfigurazioa editatu aurretik, hiru kasuek hiru balio ezberdin ematen baitituzte eta bakarra delako zuzena. Hemen asmatzeak konfigurazioaren beste edozein atalek baino denbora gehiago galtzen du.

Gero ezarri helbidea zure abiarazleak benetan irakurtzen duen forman. Konfigurazio-fitxategi batek eta zerbitzaria programatikoki eraikitzen duen script batek ez dituzte aukera berak kontsumitzen:

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

Zati horretako helbidea ilustratiboa da eta ostalariak duen VPN helbidea adierazten du. Proiektuak zerbitzaria honekin eraikitzen badu new WebpackDevServer(options, compiler), pasa aukerak konstruktore-argumentuaren bidez horren ordez, zeren propietate bereizia devServer webpack konfigurazioan ez da bide horretan kontsultatzen. Konfigurazio-fitxategiaren eta Node API-ren arteko aldea horrek sekula irakurtzen ez duen proiektu batera zati bat kopiatzen dutenak harrapatzen ditu. dev-server dokumentazioak bi abiarazte-estiloak bereizten ditu eta erabiltzen ari den bertsioarekin alderatzeko erreferentzia da.

Egokitu ostalari-izenaren egiaztapena onartzen dituzun izenetara

Ostalari-izenaren egiaztapena erasotzaileak kontrolatutako izen batetik zerbitzatutako orri bat nabigatzailearen bidez zure garapen-zerbitzariarekin hitz egitea eragozteko dago. Honekin desgaitzeak: allowedHosts: "all" babes hori kentzen du, eta erosotasunak gutxitan merezi du zerbitzu barnekoetara iristen den makinan. Egiaztapena merkea da behar bezala betetzea, nabigatzaileak zein izen bidaliko dituen jakinda.

Zerrendatu erabiliko dituzun izen zehatzak, tunelaren helbidera ebazten den izen pribatua barne. Bezeroak izen bat lotu duzun helbideaz bestelako helbide batera ebazten badu, izen-ebazpen arazoa duzu, ez zerbitzariaren konfigurazio arazoa, eta izena baimenduen zerrendara gehitzeak ez du konponduko. Berretsi ebazpena bezerotik, ez zerbitzaritik.

Eduki hiru kontrolak bereizita buruan: lotze-helbideak zein interfazek onartzen duten konexioa erabakitzen du, baimenduen zerrendak zein Host goiburu onartzen diren erabakitzen du eta autentifikazioak nor sar daitekeen erabakitzen du. Hirugarrena soilik da sarbide-kontrola, eta garapen-zerbitzari batek normalean ez du bat ere. Tunel helbide bat ere ez da autentifikazio-mekanismoa, hara bideratu dezakeen edonor jada fidatu zinen mugaren barruan baitago.

Egiaztatu orria eta zuzeneko birkargatzeko socket-a elkarrekin

Kargatu eskaera berri bat aurreikusitako bezerotik konfiguratutako eskema erabiliz, eta irakurri emaitza, cachea ez ezik. HTTPSrako, mantendu espero den ostalari-izena eta ziurtagiriaren baliozkotzea, nabigatzailearen abisu bat ez baita onarpen-proba arrakastatsua. Zuzeneko birkargak isilka huts egiten duen bitartean errendatzen den orria da hemen arrakasta partzial ohikoena, eta erraza da azkarreko egiaztapen batean nabaritzea.

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

Gero ireki nabigatzailearen sare-diagnostikoak eta begiratu WebSocket konexioa. Orri bat ostalari-izen, portu eta eskema baten bidez karga daiteke birkargatzeko socket-ak beste bat erabiltzen duen bitartean, eta horregatik biak bereizita egiaztatu behar dira. Konfiguratu dokumentatutako bezero URL-a soilik inplementatutako bideak benetan beste balio bat behar duenean, eta hobetsi bidea konpontzea bezeroari lanbide-ingurubide bat irakastea baino.

Erregistratu entzulearen helbidea, onartutako izena, baimendutako iturria eta bi emaitzak proiektuko oharretan. Erregistro horrek lan-eremua abiarazten duen hurrengo pertsonak biziraungo du, orria zergatik kargatzen den baina inoiz berritzen ez den galdetzean.