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 वर, एक निष्काळजी टेबल संपादन मशीनकडे परत जाणारा मार्गच काढून टाकू शकते, आणि निदान पूर्ण करायला कोणीच उरणार नाही. योग्य रूट कोणता हे ठरवा, बदल कसा रद्द करायचा ते लिहा, आणि मगच तो चालवा. तपासणीला अशी शेपटी नसते.

पहिल्या पावलीत कॅशे साफ करणे आणि नेटवर्क सेवा पुन्हा सुरू करणे यांनाही तीच सावधानी लागू होते, कारण दोन्ही तुम्ही वाचणार असलेला पुरावा नष्ट करतात. फक्त-वाचन तपासण्या स्वस्त, पुनरावृत्तीयोग्य आणि कोणत्याही क्रमाने सुरक्षित असतात. त्यांना डीफॉल्ट पाऊल करा, आणि पुरावा दाखवत असेल तेव्हाच बदलाकडे वळा.