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 फाइल सम्पादन गर्नु सबैभन्दा खराब रूपमा स्केल हुन्छ र पहिले बिर्सिन्छ। प्रोफाइलसँगै बाँच्ने र सुरुङ हुने जोसुकैले समीक्षा गर्न सक्ने सेटिङलाई प्राथमिकता दिनुहोस्।

विफल हुने पहिलो चरणमा रोकिनुहोस्

तीन चरणमा तल झर्नुहोस्: नाम समाधान गर्नुहोस्, शाब्दिक ठेगानामा सकेट खोल्नुहोस्, त्यसपछि उपकरणले आफ्नै जडान बनाओस्। हरेक चरणले एउटा तह हटाउँछ, त्यसैले पहिलो विफलताले सुधार्नुपर्ने तहको नाम बताउँछ र त्यसपछिका सबै परीक्षण नगरिएका रहन्छन्। केही परिवर्तन गर्नुअघि नतिजा लेख्नुहोस्, किनकि मापनअघि लगाइएको सुधारलाई भाग्यबाट छुट्याउन सकिँदैन। पहिलो प्रयास विफल भई पुनः प्रयास चल्यो भने उपकरण सुरु हुँदा सुरुङ तयार थिएन।

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