macOS पर VPN रूट जाँच: बिना कुछ बदले route get

एक उपयोगकर्ता ऑफ़िस नेटवर्क पर इंट्रानेट तक पहुँचता है और टनल से नहीं, जबकि सेटिंग्स अभी भी VPN को कनेक्टेड दिखाती हैं। उस समय रूट तालिका संपादित करने से निदान के लिए उपयोग किया जा रहा रिमोट सत्र टूटने का जोखिम है। इसके बजाय कर्नेल से पूछें कि विफल होस्ट के लिए वह कौन-सा मार्ग चुनेगा। macOS की route उपयोगिता में get ऑपरेशन है जो एक गंतव्य के लिए ठीक यही उत्तर देता है, बिना कुछ बदले।

विफल होस्ट से पूछें, डिफ़ॉल्ट से नहीं

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

रूप है route -n get के बाद पता: route -n get 203.0.113.10, जहाँ दस्तावेज़ी पता आपके लक्ष्य का प्रतिनिधित्व करता है। अधिकृत गंतव्य और मेल खाने वाला पता-परिवार उपयोग करें, क्योंकि IPv4 उत्तर केवल IPv6 संसाधन के बारे में कुछ नहीं कहता। route उपयोगिता का दस्तावेज़ get ऑपरेशन और उसके द्वारा छापे जाने वाले फ़ील्ड का वर्णन करता है।

इंटरफ़ेस और गेटवे को साक्ष्य के रूप में पढ़ें

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

निष्कर्ष निकालने से पहले गंतव्य, इंटरफ़ेस, गेटवे और क्वेरी का समय दर्ज करें। आउटपुट साक्ष्य है, निदान नहीं: स्प्लिट टनल शामिल होने पर वही इंटरफ़ेस एक होस्ट के लिए सही और दूसरे के लिए गलत हो सकता है।

सही रूट का अर्थ काम करने वाला अनुरोध नहीं

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

रूटिंग तालिका की सूची का अभी भी स्थान है: इसी तरह आप अप्रत्याशित डिफ़ॉल्ट नोटिस करते हैं। बचा हुआ सामान्य डिफ़ॉल्ट यह साबित नहीं करता कि VPN अप्रयुक्त है, क्योंकि अधिक विशिष्ट प्रविष्टियाँ उस पर जीत जाती हैं।

एंडपॉइंट और संसाधन को अलग रखें

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

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

पहले पढ़ें, बाद में बदलें

route add और route delete को पहले दौर से बाहर रखें। जिस Mac को आप दूर से प्रबंधित करते हैं, उस पर एक लापरवाह तालिका संपादन मशीन तक वापसी का रास्ता ही छीन सकता है और निदान पूरा करने वाला कोई नहीं बचेगा। तय करें कि सही रूट क्या है, बदलाव को कैसे पूर्ववत करें लिखें, और तभी उसे चलाएँ। निरीक्षण की ऐसी पूँछ नहीं होती।

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