VPN चालू और localhost काम करना बंद: नाम, प्रॉक्सी या बाइंड?

आपके डेवलपमेंट सर्वर ने एक मिनट पहले जवाब दिया था, और अब टनल चालू होने पर अनुरोध ऐसे होस्ट नाम के साथ समय-सीमा पार कर जाता है जो आपने कभी टाइप नहीं किया। लगभग हर मामले को दो तंत्र समझाते हैं, और बाहर से वे एक जैसे दिखते हैं। सर्च सफ़िक्स छोटे नाम को कॉर्पोरेट नाम बना देता है, जबकि प्रॉक्सी लूपबैक ट्रैफ़िक को ऐसे होस्ट पर भेजता है जो उस तक नहीं पहुँच सकता। इन दोनों को अलग करने में एक क्वेरी लगती है और वह फ़ायरवॉल नियम बचता है जिसे आप लिखने वाले थे।

जब localhost कॉर्पोरेट ज़ोन में हल होता है

टनल चालू रहते समय जाँचें कि नाम किसमें हल होता है, फिर टनल बंद करके वही क्वेरी चलाएँ और दोनों जवाबों की तुलना करें। संकेत वह है कि जहाँ आपने 127.0.0.1 की अपेक्षा की थी वहाँ कॉर्पोरेट रेंज का पता मिले। localhost.mycompany.corp जैसा रिकॉर्ड क्लाइंट द्वारा वह सफ़िक्स सर्च सूची में जोड़ते ही लूपबैक प्रविष्टि पर भारी पड़ता है, और अनुरोध उस निजी होस्ट तक जाता है जहाँ उस पोर्ट पर कुछ भी नहीं सुन रहा होता। सर्च सूची अनुमान लगाने के बजाय पढ़ें, क्योंकि क्लाइंट एक से अधिक डोमेन जोड़ सकता है और क्रम तय करता है कि कौन-सा उम्मीदवार पहले आज़माया जाएगा:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

एप्लिकेशन, डेटाबेस क्लाइंट या नोटबुक URL में होस्ट नाम की जगह शाब्दिक पता डालें, फिर अनुरोध दोहराएँ। अगर विफलता गायब हो जाए तो आपकी समस्या नामकरण की थी और टनल केवल ट्रिगर था। अगर वह बनी रहे तो श्रोता या रूट अगला संदिग्ध है और नाम केवल गुमराह करने वाला सुराग था।

लूपबैक पकड़ने वाली प्रॉक्सी सेटिंग्स

टनल उठते समय लागू होने वाला सिस्टम प्रॉक्सी 127.0.0.1 के लिए अनुरोध स्वीकार करेगा और उसे ऐसे दूरस्थ प्रॉक्सी पर भेज देगा जिसे पता ही नहीं कि आपका मतलब क्या था। खाली बायपास सूची स्थानीय अनुरोध को दूरस्थ बना देती है, और त्रुटि संदेश ऐसा शायद ही कहता है। लूपबैक पतों को एक आदेश के बजाय पूरे सत्र के लिए बायपास सूची में जोड़ें, फिर नेटवर्क के बारे में कोई निष्कर्ष निकालने से पहले पुष्टि करें कि टूल इसका पालन करता है।

एप्लिकेशन फ़्रेमवर्क अपने ही एनवायरनमेंट वेरिएबल और कभी-कभी अपनी ही कॉन्फ़िगरेशन फ़ाइल पढ़ते हैं, इसलिए एक टूल के लिए काम करने वाला बायपास अगले के लिए कुछ साबित नहीं करता। ब्राउज़र एक बारीकी जोड़ते हैं: Chromium आधारित ब्राउज़र लूपबैक के लिए प्रॉक्सी को अंतर्निहित रूप से बायपास करते हैं, और बायपास टोकन उस व्यवहार को हटा सकता है। ऑपरेटिंग सिस्टम की सेटिंग को पूरी कहानी मानने के बजाय वास्तविक प्रॉक्सी निर्णय जाँचें। शेल से शुरू होने वाली किसी भी चीज़ के लिए दो आदेश इसे तय करते हैं:

curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool

बाइंड पता तय करता है कौन जुड़ सकता है

127.0.0.1 पर शुरू होने वाला सर्वर केवल उसी मशीन से कनेक्शन स्वीकार करता है, जो विकास के लिए आम तौर पर सही डिफ़ॉल्ट है। 0.0.0.0 पर सर्वर हर इंटरफ़ेस पर जवाब देता है, VPN एडाप्टर सहित, जो ज़्यादातर लोगों के इरादे से अधिक एक्सपोज़र है। जब शाब्दिक लूपबैक पता विफल हो, तो सबसे पहले बाइंड जाँचें।

सुनने वाले सॉकेट को देखें और जिस पते से वह बंधा है उसे लिखें, केवल पोर्ट नहीं। अगर किसी दूसरे उपकरण या कंटेनर को टनल के ज़रिए सेवा तक पहुँचना है, तो उस विशिष्ट इंटरफ़ेस से बाँधें जिसका वह उपयोग करेगा और उस पोर्ट को जानबूझकर अनुमति दें। अगर केवल आपकी अपनी मशीन को इसकी ज़रूरत है, तो संकीर्ण बाइंड रखें और सर्वर चौड़ा करने के बजाय क्लाइंट ठीक करें। पोर्ट फ़ॉरवर्डिंग या टनल की परत दोनों को जोड़ सकती है, लेकिन हर एक ऐसा घटक जोड़ती है जिसे बाद में अपनी डिबगिंग चाहिए होगी।

जहाँ डिबगिंग टूल LAN की अपेक्षा करता है

डिबगिंग टूल अपने साथ ऐसी धारणाएँ लाते हैं जिन्हें टनल चुपचाप तोड़ देता है। फ़ोन डिबगिंग ब्रिज अपना उपकरण खो देता है जब VPN उपकरण का सबनेट पकड़ लेता है, इसलिए LAN पते या केबल से दोबारा जुड़ना टकराव से बचाता है। ब्राउज़र ऑटोमेशन हब तब समय-सीमा पार करता है जब हब केवल प्रॉक्सी से पहुँच योग्य हो, या जब स्थानीय फ़ायरवॉल उसका नियंत्रण पोर्ट गिरा दे। रिमोट डिबगर को एलिवेशन और लूपबैक पता चाहिए हो सकता है जहाँ क्लाइंट ने रूट फिर से लिख दिया हो।

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

पहले विफल चरण पर रुकें

तीन चरणों से नीचे उतरें: नाम हल करें, शाब्दिक पते के लिए सॉकेट खोलें, फिर टूल को अपना कनेक्शन बनाने दें। हर चरण एक परत हटाता है, इसलिए पहली विफलता ठीक करने वाली परत का नाम बताती है और उसके बाद का सब कुछ अपरीक्षित रहता है। कुछ भी बदलने से पहले परिणाम लिख लें, क्योंकि माप से पहले लागू किया गया सुधार भाग्य से अलग नहीं पहचाना जा सकता। अगर पहली कोशिश विफल हो और दोबारा प्रयास काम करे, तो टूल शुरू होने के समय टनल शायद तैयार नहीं था।

स्थिर प्रतीक्षा को रूट की प्रतीक्षा करने वाली सीमित तैयारी-जाँच से बदलें, और विफल होने वाले चरण को लॉग में रखें ताकि अगला व्यक्ति देख सके कि कहाँ रुका। जो टूल खुद ठीक हो जाता है वह ठीक नहीं हुआ, वह भाग्यशाली है, और भाग्य किसी और की मशीन पर खत्म होता है। टनल को सबसे अंत में बदलें, और केवल उस चरण के लिए जो वास्तव में विफल हुआ। यही क्रम काम करने वाले बिल्ड तक लौटने का सबसे छोटा रास्ता भी है, क्योंकि यह आपको ऐसे घटक को फिर से बनाने से रोकता है जो कभी शामिल ही नहीं था।