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 तभी कॉन्फ़िगर करें जब तैनात पथ को वाकई अलग मान चाहिए, और क्लाइंट को वर्कअराउंड सिखाने के बजाय पथ सुधारना पसंद करें।

सुनने वाले का पता, स्वीकृत नाम, अनुमत स्रोत और दोनों परिणाम प्रोजेक्ट नोट्स में दर्ज करें। यह रिकॉर्ड अगले उस व्यक्ति के लिए बचा रहता है जो वर्कस्पेस शुरू करता है और सोचता है कि पेज क्यों लोड होता है पर कभी रीफ़्रेश नहीं होता।