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 मा, एउटा लापरवाह तालिका सम्पादनले मेसिनसम्म फर्कने बाटो नै खोस्न सक्छ, र निदान पूरा गर्न कोही बाँकी रहँदैन। सही रुट कुन हो निर्णय गर्नुहोस्, परिवर्तन कसरी रद्द गर्ने लेख्नुहोस्, र त्यसपछि मात्र चलाउनुहोस्। जाँचको त्यस्तो पुच्छर हुँदैन।

पहिलो कदमका रूपमा क्यास खाली गर्ने र नेटवर्क सेवाहरू पुनः सुरु गर्नेमा पनि त्यही सावधानी लागू हुन्छ, किनकि दुवैले तपाईं पढ्न लागेको प्रमाण नष्ट गर्छन्। पढ्ने-मात्र जाँचहरू सस्तो, दोहोर्याउन योग्य र कुनै पनि क्रममा सुरक्षित हुन्छन्। तिनलाई पूर्वनिर्धारित कदम बनाउनुहोस्, र प्रमाणले देखाएको बेला मात्र परिवर्तनतर्फ हात बढाउनुहोस्।