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-ஐ வரிசைப்படுத்தப்பட்ட பாதைக்கு உண்மையில் வேறு மதிப்பு தேவைப்படும்போது மட்டும் கட்டமைக்கவும், வாடிக்கையாளருக்கு மாற்று வழியைக் கற்பிப்பதை விட பாதையைச் சரிசெய்வதை விரும்புங்கள்.

கேட்பவரின் முகவரி, ஏற்கப்பட்ட பெயர், அனுமதிக்கப்பட்ட மூலம் மற்றும் இரண்டு முடிவுகளையும் திட்டக் குறிப்புகளில் பதிவு செய்யுங்கள். அந்தப் பதிவு பணியிடத்தைத் தொடங்கி, பக்கம் ஏன் ஏற்றப்படுகிறது ஆனால் ஒருபோதும் புதுப்பிக்கப்படவில்லை என்று யோசிக்கும் அடுத்த நபருக்கு எஞ்சியிருக்கும்.