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 ഡിപ്ലോയ് ചെയ്ത പാത്തിന് യഥാർത്ഥത്തിൽ വ്യത്യസ്ത മൂല്യം ആവശ്യമുള്ളപ്പോൾ മാത്രം കോൺഫിഗർ ചെയ്യുക, ക്ലയന്റിന് ഒരു ബദൽ വഴി പഠിപ്പിക്കുന്നതിനേക്കാൾ പാത്ത് ശരിയാക്കുന്നതിന് മുൻഗണന നൽകുക.

ശ്രോതാവിന്റെ വിലാസം, സ്വീകരിച്ച പേര്, അനുവദിച്ച ഉറവിടം, രണ്ട് ഫലങ്ങളും പ്രോജക്ട് കുറിപ്പുകളിൽ രേഖപ്പെടുത്തുക. ആ രേഖ അടുത്ത വ്യക്തിക്ക് അവശേഷിക്കുന്നു, അവർ വർക്ക്സ്പേസ് ആരംഭിച്ച് പേജ് എന്തുകൊണ്ട് ലോഡ് ചെയ്യുന്നു പക്ഷേ ഒരിക്കലും റിഫ്രെഷ് ചെയ്യുന്നില്ല എന്ന് ചിന്തിക്കുമ്പോൾ.