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 फक्त तेव्हाच कॉन्फिगर करा जेव्हा तैनात मार्गाला खरोखर वेगळे मूल्य हवे असते, आणि क्लायंटला पर्यायी मार्ग शिकवण्यापेक्षा मार्ग दुरुस्त करण्याला प्राधान्य द्या.

श्रोत्याचा पत्ता, स्वीकारलेले नाव, परवानगी दिलेला स्रोत आणि दोन्ही निकाल प्रकल्पाच्या टिपांमध्ये नोंदवा. ती नोंद पुढच्या व्यक्तीसाठी राहते, जो कार्यक्षेत्र सुरू करून पृष्ठ का लोड होते पण कधीच रिफ्रेश होत नाही याचा विचार करतो.