टनेल सुरू आहे, तर खाजगी नाव अजून का अयशस्वी होते?

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

विनंती कोणत्या रिझॉल्व्हरपर्यंत पोहोचली?

टनेलकडे पाहण्यापूर्वी प्रत्येक लिंकला जोडलेला रिझॉल्व्हर शोधा। Linux रिझॉल्व्हर स्थिती आदेशाने प्रत्येक लिंकचे सर्व्हर दाखवते, आणि macOS त्याच्या DNS कॉन्फिगरेशन डंपमध्ये व्याप्ती असलेले रिझॉल्व्हर दाखवते। उत्तर अजूनही घरच्या राउटरकडून येत असेल, तर टनेल लिंकची कधीही चौकशी झाली नाही।

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

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

क्लाउड नेटवर्क खरोखर उत्तर देते अशा पत्त्याचा वापर करा

क्लाउड नेटवर्क सहसा श्रेणीच्या पायापासून दोन पुढे असलेल्या राखीव पत्त्याद्वारे खाजगी नावांना उत्तर देतात, त्यामुळे 10.0.0.0 पासून सुरू होणारे नेटवर्क 10.0.0.2 वर उत्तर देते। काही प्रदाते श्रेणी न जाणता काम करणारा लिंक-स्थानिक रिझॉल्व्हरही प्रकाशित करतात, जे नेटवर्क दुसऱ्याने बांधले असेल तेव्हा उपयोगी ठरते। उमेदवार पत्त्याला कोणालाही ढकलण्यापूर्वी थेट विचारा। जो पत्ता रिझॉल्व्हर नाही तो फायरवॉल ड्रॉपसारखाच दिसतो, कारण विनंतीला कधीच उत्तर मिळत नाही।

थेट विनंती नेटवर्कच्या आतून उत्तर देते पण टनेलमधून नाही, तर रिझॉल्व्हर ठीक आहे आणि दोन बिंदूंमधला मार्ग नाही। तो निकाल तपासणी क्लायंट प्रोफाइलकडे नाही, तर राउट, फॉरवर्डिंग आणि प्रवेश नियमांकडे वळवतो।

टनेल नावांची जागा वाहून नेते नाही

पॅकेट पार जातात; नावे जात नाहीत। प्रत्येक बाजूला कोणती नावांची जागा दुसऱ्याची आहे हे सांगावे लागते, आणि ती झोन असलेल्याच्या मालकीची वेगळी वस्तू आहे। नेहमीचा आकार म्हणजे एका नावांच्या जागेसाठी फॉरवर्ड, टनेलमधून पोहोचण्याजोग्या रिझॉल्व्हरकडे निर्देशित।

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

सीमा क्रमाने ओलांडा

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

कोणते पाऊल अयशस्वी झाले ते लिहा। तीच एक ओळ पुढच्या व्यक्तीला हवी असते, आणि ती नोंदवायला दहा सेकंद लागतात।

साखळी पुढच्या व्यक्तीला सापडेल तिथे ठेवा

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

नोंद अचूक राहण्याइतकी लहान ठेवा: चार ओळी, एक तारीख, आणि प्रत्येक भागाचा मालक कोण आहे त्याचे नाव। जुनी नोंद नसण्यापेक्षा वाईट आहे, कारण ती चुकीची असूनही अधिकृत दिसते।