खाजगी एंडपॉइंट अजूनही सार्वजनिक पत्त्याने का उत्तर देतो

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

क्लायंटच्या रिझॉल्व्हरपासून सुरुवात करा

टनेल सुरू असताना क्लायंट कोणत्या सर्व्हरला क्वेरी करतो ते विचारा। पॉइंट-टू-साइट प्रोफाइल तो पत्ता पुरवते, आणि जे प्रोफाइल काहीही पुरवत नाही ते ऑपरेटिंग सिस्टमला अॅडॉप्टरच्या डीफॉल्टवर परत जाऊ देते।

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

उत्तर प्रत्यक्षात काय आहे ते वाचा

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

ही दोन्ही परिणाम सारख्याच अनुप्रयोग त्रुटी निर्माण करतात आणि वेगवेगळ्या मालकांचे आहेत। एक रिझॉल्व्हर निवडीची समस्या आहे, दुसरी गहाळ झोन लिंक आहे।

hosts नोंद मार्ग सिद्ध करते, मग खोटे बोलते

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

तो दुसऱ्या खात्याला, दुसऱ्या एंडपॉइंटला किंवा सहकाऱ्याला मदत करत नाही, आणि एंडपॉइंट नवीन पत्त्यावर पुन्हा तयार झाल्यावर इशारा न देता तुटतो।

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

झोन जोडा आणि रिझॉल्व्हर वाटा

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

आधीच असलेला ऑन-प्रिमायसेस रिझॉल्व्हर झोनकडे निर्देशित सशर्त फॉरवर्डर द्वारे तोच निकाल मिळवू शकतो।

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

नाव, पोर्ट आणि ओळख क्रमाने तपासा

क्रमाने काम करा: नाव सोडवा, उत्तर खाजगी असल्याची खात्री करा, पोर्ट उघडा, नंतर प्रमाणित विनंती करा। प्रत्येक टप्प्याचा स्वतःचा मालक आणि स्वतःची अयशस्वीतेची सही असते।

खाजगी उत्तरानंतर वेळ संपणे मार्ग किंवा फायरवॉलकडे निर्देश करते। सार्वजनिक उत्तर रिझॉल्व्हरकडे निर्देश करते। ओळखीची त्रुटी परत देणारे पूर्ण झालेले कनेक्शन सेवेचे आहे।

आणखी एक अयशस्वीता या यादीत येते। क्लायंट पत्त्याला परवानगी देणारा सेवा फायरवॉल, पुन्हा कनेक्ट झाल्यावर पूल तो पत्ता दुसऱ्या सत्राला देतो तेव्हा जुळणे थांबवतो। क्लायंटला स्वतःकडे आहे असे वाटणाऱ्या पत्त्याऐवजी सेवेने नोंदवलेला कॉलर पत्ता वाचा। दोन्ही लोक अपेक्षा करतात त्यापेक्षा जास्त वेळा जुळत नाहीत। Azure DNS Private Resolver मार्गदर्शन झोन लिंक आणि फॉरवर्डिंग व्यवस्था समाविष्ट करते।