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 फाइल संपादित करणे सर्वात वाईट प्रमाणात वाढते आणि सर्वात आधी विसरले जाते। प्रोफाइलसोबत राहणारी आणि बोगदा असलेल्या कोणालाही पुनरावलोकन करता येणारी सेटिंग निवडा।

अयशस्वी होणाऱ्या पहिल्या टप्प्यावर थांबा

तीन टप्प्यांतून खाली जा: नाव सोडवा, शब्दशः पत्त्यासाठी सॉकेट उघडा, नंतर साधनाने स्वतःचे कनेक्शन करू द्या। प्रत्येक टप्पा एक थर काढतो, म्हणून पहिले अपयश दुरुस्त करायच्या थराचे नाव सांगते आणि त्यानंतरचे सर्व तपासल्याशिवाय राहते। काहीही बदलण्यापूर्वी निकाल लिहून ठेवा, कारण मोजमापापूर्वी लागू केलेली दुरुस्ती नशिबापासून वेगळी करता येत नाही। पहिला प्रयत्न अयशस्वी होऊन पुनर्प्रयत्न चालला तर साधन सुरू झाल्यावर बोगदा तयार नव्हता।

स्थिर प्रतीक्षेऐवजी मार्गाची वाट पाहणारी मर्यादित तयारी तपासणी ठेवा, आणि अयशस्वी टप्पा लॉगमध्ये ठेवा जेणेकरून पुढील व्यक्तीला कुठे थांबले ते दिसेल। स्वतःहून सावरणारे साधन दुरुस्त झालेले नाही, ते नशीबवान आहे, आणि नशीब दुसऱ्याच्या मशीनवर संपते। बोगदा सर्वात शेवटी बदला, आणि फक्त खरोखर अयशस्वी झालेल्या टप्प्यासाठी। तो क्रम चालणाऱ्या बिल्डकडे परतण्याचा सर्वात लहान मार्गही आहे, कारण कधीही सहभागी न झालेला घटक पुन्हा बांधण्यापासून तो तुम्हाला थांबवतो।