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 तैनाथ मार्गलाई साँच्चै फरक मान चाहिएको अवस्थामा मात्र कन्फिगर गर्नुहोस्, र क्लाइन्टलाई वैकल्पिक उपाय सिकाउनुभन्दा मार्ग सुधार्न प्राथमिकता दिनुहोस्।

श्रोताको ठेगाना, स्वीकृत नाम, अनुमत स्रोत र दुवै नतिजा परियोजना टिप्पणीमा लेख्नुहोस्। त्यो अभिलेख अर्को व्यक्तिका लागि रहन्छ, जसले कार्यक्षेत्र सुरु गरेर पृष्ठ किन लोड हुन्छ तर कहिल्यै रिफ्रेस हुँदैन भनी सोच्छ।