webpack ડેવ સર્વરને VPN સરનામા પર કેવી રીતે સર્વ કરવો

લેપટોપ પર જવાબ આપતું અને બીજે ક્યાંય નહીં જવાબ આપતું ડેવલપમેન્ટ સર્વર સામાન્ય રીતે ખોટા સરનામા પર બંધાયેલું હોય છે. કનેક્શન સ્વીકારતું પણ પૃષ્ઠ નકારતું સર્વર સામાન્ય રીતે હોસ્ટનામ તપાસમાં નિષ્ફળ જાય છે. આ અલગ ખામીઓ અને અલગ સુધારા છે, અને યોગ્ય રૂપરેખાંકન પસંદ કરવું એના પર આધાર રાખે છે કે કોને વર્કસ્પેસ સુધી પહોંચવું છે અને તેઓ કેવી રીતે પહોંચે છે.

ત્રણ પ્રશ્નો જવાબ નક્કી કરે છે: કોણ જોડાય છે, કયા સરનામા સુધી તેઓ પહોંચી શકે છે, અને તેમના માટે લાઇવ રીલોડ કાર્ય કરવું જોઈએ કે નહીં.

રૂપરેખાંકન ફાઇલથી નહીં, સોકેટથી શરૂ કરો

ચાલી રહેલી પ્રક્રિયા ખરેખર શેમાં બંધાઈ છે તે તેને શરૂ કરનારા સમાન નેટવર્ક સંદર્ભમાં વાંચો, કારણ કે કન્ટેનર અથવા નામસ્થાન એવું સોકેટ ધરાવી શકે છે જે હોસ્ટ શેલ જોઈ શકતું નથી. સાંભળવાની કોલમ પ્રથમ પ્રશ્નનો જવાબ આપે છે: ફક્ત સ્થાનિક પાથ, એક ચોક્કસ ઇન્ટરફેસ, અથવા દરેક ઇન્ટરફેસ.

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

લૂપબેક સરનામું સુરક્ષિત ડિફોલ્ટ છે અને દૂરના ક્લાયન્ટ માટે નકામું છે. વાઇલ્ડકાર્ડ બાઈન્ડ અનુકૂળ છે અને જે પણ ઇન્ટરફેસનો રૂટ હોય તેના પર પોર્ટ ખુલ્લો મૂકે છે, જે ટનલ પણ ધરાવતી મશીન પર મોટાભાગના લોકો ધારે તેના કરતાં વધુ વિશાળ છે. ચોક્કસ સરનામું મધ્યમ વિકલ્પ છે, અને તે ફક્ત ત્યારે જ કાર્ય કરે છે જ્યારે સોકેટ બનાવવાની ક્ષણે ઇન્ટરફેસ પાસે તે સરનામું હોય. તફાવત મહત્ત્વનો છે કારણ કે આ ત્રણમાંથી બે બાઈન્ડિંગ બ્રાઉઝરમાં સરખા દેખાય છે અને બીજું ઇન્ટરફેસ અસ્તિત્વમાં આવતાં તદ્દન અલગ રીતે વર્તે છે.

રૂટ અથવા ફાયરવોલ નિયમોને સ્પર્શતા પહેલાં તે અવલોકન સાથે મેળ બેસાડો. જો પ્રક્રિયા ખોટા સરનામા પર સાંભળી રહી હોય, તો કોઈ પણ પોલિસી રાઉટિંગ ક્લાયન્ટને ત્યાં પહોંચાડી શકશે નહીં.

કોણ પહોંચવું છે તેના આધારે બાઈન્ડ સરનામું પસંદ કરો

જો આ મશીન પર ફક્ત તમને જ પૃષ્ઠની જરૂર હોય, તો લૂપબેક બાઈન્ડ રાખો અને થોભો. જો તે જ ટનલ પરના એક સહકર્મીને તેની જરૂર હોય, તો ટનલ ઇન્ટરફેસનું સરનામું બાઈન્ડ કરો અને ફાયરવોલને ફક્ત તે જ સ્રોતને મંજૂરી આપવા દો. ડેવલપમેન્ટ સર્વરને તેનું સક્રિય પરીક્ષણ કરતા લોકોની બહાર પ્રકાશિત કરવું એવી આદત છે જે છેવટે વર્કસ્પેસને ઇન્ટરનેટ સામે ખુલ્લું મૂકે છે.

જો કન્ટેનરની અંદરનું બ્રાઉઝર સર્વર સુધી પહોંચવાનું હોય, તો બાઈન્ડ સરનામું એવું હોવું જોઈએ કે જ્યાં કન્ટેનરનું નેટવર્ક રૂટ કરી શકે, અને તે ઘણી વાર એ સરનામું હોતું નથી જે હોસ્ટ પોતાના માટે ઉકેલે છે. રૂપરેખાંકન સંપાદિત કરતા પહેલાં કેસ નક્કી કરો, કારણ કે ત્રણ કેસ ત્રણ અલગ મૂલ્યો આપે છે અને ફક્ત એક જ સાચું છે. અહીં અનુમાન કરવું સેટઅપના કોઈ પણ બીજા ભાગ કરતાં વધુ સમય બગાડે છે.

પછી સરનામું તે સ્વરૂપમાં સેટ કરો જે તમારો લોન્ચર ખરેખર વાંચે છે. રૂપરેખાંકન ફાઇલ અને સર્વરને પ્રોગ્રામેટિક રીતે બનાવતી સ્ક્રિપ્ટ સમાન વિકલ્પો વાપરતાં નથી:

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

તે ટુકડામાંનું સરનામું ઉદાહરણરૂપ છે અને હોસ્ટ પાસેના VPN સરનામાનું પ્રતિનિધિત્વ કરે છે. જો પ્રોજેક્ટ સર્વરને new WebpackDevServer(options, compiler) વડે બનાવે છે, તો તેના બદલે વિકલ્પો કન્સ્ટ્રક્ટર આર્ગ્યુમેન્ટ દ્વારા પસાર કરો, કારણ કે webpack રૂપરેખાંકનમાંનો અલગ devServer ગુણધર્મ તે માર્ગ પર ધ્યાનમાં લેવાતો નથી. રૂપરેખાંકન ફાઇલ અને Node API વચ્ચેનો તે તફાવત એવા લોકોને પકડે છે જે ટુકડો એવા પ્રોજેક્ટમાં કૉપિ કરે છે જે તેને કદી વાંચતો નથી. dev-server દસ્તાવેજીકરણ બે લોન્ચ શૈલીઓને અલગ પાડે છે અને વપરાતી આવૃત્તિ સામે ચકાસવાનો સંદર્ભ છે.

તમે મંજૂરી આપેલા નામો સાથે હોસ્ટનામ તપાસ મેળવો

હોસ્ટનામ તપાસ એટલા માટે છે કે હુમલાખોરના નિયંત્રણ હેઠળના નામથી સર્વ કરાયેલું પૃષ્ઠ બ્રાઉઝર દ્વારા તમારા ડેવલપમેન્ટ સર્વર સાથે વાત ન કરે. તેને allowedHosts: "all" વડે નિષ્ક્રિય કરવાથી તે રક્ષણ દૂર થાય છે, અને આંતરિક સેવાઓ સુધી પહોંચી શકતી મશીન પર આ સુવિધા ભાગ્યે જ પાત્ર હોય છે. બ્રાઉઝર કયા નામો મોકલશે તે જાણ્યા પછી તપાસ યોગ્ય રીતે પૂરી કરવી સસ્તી છે.

તમે વાપરવાના ચોક્કસ નામોની યાદી બનાવો, જેમાં ટનલ સરનામા પર ઉકેલાતું ખાનગી નામ પણ સામેલ છે. જો ક્લાયન્ટ નામને તમે બાઈન્ડ કરેલા સરનામા કરતાં અલગ સરનામા પર ઉકેલે છે, તો તમારી પાસે નામ-ઉકેલ સમસ્યા છે, સર્વર રૂપરેખાંકન સમસ્યા નહીં, અને મંજૂર યાદીમાં નામ ઉમેરવાથી તે ઠીક થશે નહીં. ઉકેલ સર્વરથી નહીં, ક્લાયન્ટથી ખાતરી કરો.

ત્રણ નિયંત્રણોને તમારા મનમાં અલગ રાખો: બાઈન્ડ સરનામું નક્કી કરે છે કયા ઇન્ટરફેસ કનેક્શન સ્વીકારે છે, મંજૂર યાદી નક્કી કરે છે કયા Host હેડર સ્વીકારવામાં આવે છે, અને પ્રમાણીકરણ નક્કી કરે છે કોને અંદર આવવાની મંજૂરી છે. ફક્ત ત્રીજું જ ઍક્સેસ નિયંત્રણ છે, અને ડેવલપમેન્ટ સર્વરમાં સામાન્ય રીતે એક પણ હોતું નથી. ટનલ સરનામું પણ પ્રમાણીકરણ પદ્ધતિ નથી, કારણ કે જે કોઈ ત્યાં રૂટ કરી શકે છે તે પહેલેથી જ તમે જે સીમા પર આધાર રાખતા હતા તેની અંદર છે.

પૃષ્ઠ અને લાઇવ-રીલોડ સોકેટને એકસાથે ચકાસો

ઇચ્છિત ક્લાયન્ટથી રૂપરેખાંકિત સ્કીમ સાથે નવી વિનંતી લોડ કરો અને કૅશને બદલે પરિણામ વાંચો. HTTPS માટે, અપેક્ષિત હોસ્ટનામ અને પ્રમાણપત્ર માન્યતા રાખો, કારણ કે બ્રાઉઝર ચેતવણી સફળ સ્વીકૃતિ પરીક્ષણ નથી. જે પૃષ્ઠ રેન્ડર થાય છે જ્યારે લાઇવ રીલોડ શાંતિથી નિષ્ફળ જાય છે તે અહીં સૌથી સામાન્ય આંશિક સફળતા છે, અને ઝડપી તપાસ દરમિયાન તે ચૂકી જવું સરળ છે.

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

પછી બ્રાઉઝરનું નેટવર્ક ડાયગ્નોસ્ટિક્સ ખોલો અને WebSocket કનેક્શન જુઓ. પૃષ્ઠ એક હોસ્ટનામ, પોર્ટ અને સ્કીમ પર લોડ થઈ શકે છે જ્યારે રીલોડ સોકેટ બીજું વાપરે છે, તેથી બંનેને અલગ તપાસવા પડે છે. દસ્તાવેજીકૃત ક્લાયન્ટ URL ફક્ત ત્યારે ગોઠવો જ્યારે તૈનાત પાથને ખરેખર અલગ મૂલ્યની જરૂર હોય, અને ક્લાયન્ટને વર્કઅરાઉન્ડ શીખવવાને બદલે પાથ સુધારવાને પ્રાધાન્ય આપો.

શ્રોતાનું સરનામું, સ્વીકૃત નામ, મંજૂર સ્રોત અને બંને પરિણામો પ્રોજેક્ટ નોંધમાં નોંધો. તે નોંધ આગલી વ્યક્તિ માટે ટકી રહે છે જે વર્કસ્પેસ શરૂ કરે છે અને વિચારે છે કે પૃષ્ઠ કેમ લોડ થાય છે પણ કદી રિફ્રેશ થતું નથી.