भौगोलिक DNS और एनिकास्ट: मिलने वाली VPN प्रविष्टि की जाँच

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

जाँचें कि रिज़ॉल्वर वास्तव में किसका स्थान बताता है

टोपोलॉजी-संवेदी क्वेरी का उत्तर देने वाला प्राधिकृत सर्वर आम तौर पर पूछने वाले पुनरावर्ती रिज़ॉल्वर का पता देखता है, न कि नाम टाइप करने वाले व्यक्ति का पता। केंद्रीकृत रिज़ॉल्वर अपने ग्राहकों से दूर हो सकता है, और उत्तर उनके बजाय रिज़ॉल्वर को दर्शाता है। यह दोष नहीं है; अतिरिक्त जानकारी दिए बिना प्रोटोकॉल ऐसे ही व्यवहार करता है। EDNS क्लाइंट सबनेट विनिर्देश सीमा और वैकल्पिक उपाय दोनों का वर्णन करता है।

EDNS क्लाइंट सबनेट मूल नेटवर्क की जानकारी ले जा सकता है, जब हर भागीदार उसका समर्थन करे और उसे सक्षम करे। यह वैकल्पिक है, इसके गोपनीयता और कैश पर परिणाम हैं, और यह मानने की अनुमति नहीं है कि कोई भी सार्वजनिक रिज़ॉल्वर उपयोगकर्ता का सटीक स्थान बताता है। इसके आसपास डिज़ाइन करने से पहले रिज़ॉल्वर ऑपरेटरों से पूछें।

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

जाँचें कि एनिकास्ट राउटिंग ने क्या तय किया

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

सेवा स्थान की पुष्टि सेवा पक्ष से, या ऐसे उत्तर से करें जो उसका नाम लेता हो, केवल DNS उत्तर से नहीं। traceroute -n 198.51.100.20 आपके लिए गए पथ को दिखाता है और फिर भी उसके अंत में मेज़बान का नाम नहीं बताता, इसलिए इसे पथ के रूप में पढ़ें, उत्तर के रूप में नहीं।

जाँचें कि सत्र नोड परिवर्तन सहता है

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

बदलाव को मानने के बजाय देखें। sudo tcpdump -ni any -c 20 esp पथ बदलते समय बाहरी पैकेट दिखाता है, और पीयर पते में अचानक परिवर्तन ही वह बदलाव है। आप जो कार्यान्वयन चलाते हैं उसके लिए इच्छित व्यवहार स्पष्ट रूप से परिभाषित करें, फिर पथ परिवर्तन थोपकर उसका परीक्षण करें। यदि डिज़ाइन सत्र प्रतिकृति मानता है, तो तंत्र का नाम दें और उस विफलता का नाम दें जिसे वह कवर नहीं करता।

जाँचें कि पहचान अब भी मेल खाती है

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

इसे ऐसे क्लाइंट से जाँचें जो असामान्य नोड तक पहुँचा हो, क्योंकि वही वह स्थिति है जहाँ प्रति-नोड प्रमाणपत्र दिखाई देता है। openssl s_client -connect vpn.example.com:443 -servername vpn.example.com श्रृंखला और नाम छापता है, और क्लाइंट ठीक वही तुलना करता है। फिर तय करें कि प्रोफ़ाइल संकीर्ण करनी चाहिए या प्रमाणपत्र मॉडल बदलना चाहिए।

रिकॉर्ड जाँचें, केवल पहला उत्तर नहीं

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

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

परिदृश्यों को केवल कार्यालय से नहीं, प्रतिनिधि एक्सेस नेटवर्क से चलाएँ, क्योंकि पूरा प्रश्न यह है कि अलग-अलग क्लाइंट वास्तव में किस प्रविष्टि बिंदु तक पहुँचते हैं। एक नेटवर्क एक का नमूना है।