कुनै डिप्लोय स्क्रिप्टमा प्रतिलिपि सुरु हुनुअघि सुरुङ सक्रिय छ कि भनी जाँच हुन्छ। तीन उत्तर उपलब्ध छन्, र ती एउटै अर्थ लाग्दैनन्: scutil ले जानकारी दिने सेवा स्थिति, कर्नेलले छानेको मार्ग, र अर्को छेउले साँच्चै जवाफ दिन्छ कि दिँदैन। तिनको तुलना नै प्रतिलिपिको पूर्वानुमान गर्ने जाँच र लग मात्र सजाउने जाँचबीचको फरक हो।

VPN सक्रिय छ कि भन्ने प्रश्नका तीन उत्तर

सेवाको स्थिति नियन्त्रण तहको तथ्य हो। macOS लाई कन्फिगरेसन जोडिएको छ भन्ने थाहा छ किनभने यसको क्लाइन्ट प्रक्रियाले त्यसो भन्यो। मार्ग डेटा तहको तथ्य हो: कर्नेलले यो गन्तव्य त्यो इन्टरफेसबाट पठाउनेछ। पहुँचयोग्यता एक छेउदेखि अर्को छेउसम्मको तथ्य हो, र अन्य दुईमध्ये कसैले नदेख्ने कारणले असफल हुन सक्छ।

SignalAnswersBlind spot
scutil --nc statusIs the service connected?Third-party clients, wrong routes
route -n getWhere would this go?The peer may be down
A request to the far sideDoes it work now?Slow, and it changes state

उपयोगी जाँचले पहिलो दुईलाई जोड्छ र तेस्रोलाई बाँकी दुईले झूट बोलेनन् भन्ने पुष्टिका रूपमा प्रयोग गर्छ। कुनै पनि एउटा मात्र समय-छाप भएको अनुमान हो।

पहिचानकर्ता पढ्नुहोस्, देखाइने नाम होइन

scutil --nc list
scutil --nc status "Office"

सूचीले प्रत्येक सेवाका लागि एक लाइन छाप्छ, र प्रत्येक लाइनमा कोष्ठकमा स्थिति, त्यसपछि सेवा पहिचानकर्ता, प्रकार र देखाइने नाम हुन्छ। पहिचानकर्तामा आधारित स्क्रिप्ट लेख्नुहोस्, किनभने देखाइने नाम भनेको कसैले सिस्टम सेटिङमा टाइप गरेको हो र सूचना बिना बदलिन सक्छ। स्थिति आदेशले एउटा शब्द छाप्छ र केही सेवा प्रकारका लागि त्यसपछि तथ्याङ्क; पूरै आउटपुटमा नाम खोज्नुको सट्टा त्यही पहिलो शब्द मिलाउनुहोस्, किनभने नाम अन्यत्र पनि देखिन्छ।

सेवा सुरु गर्दा अधिकारको अनुरोध आउन सक्छ वा प्रोफाइल व्यवस्थित भएमा सिधै अस्वीकार गरिन सक्छ। त्यो अस्वीकार सुरुङको खराबी होइन; यो कसले यो खडा गर्न पाउँछ भन्ने नीतिको घोषणा हो।

तेस्रो-पक्ष क्लाइन्ट सूचीबाट लुक्छ

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

सूची खाली हुँदा पनि ट्राफिक स्पष्ट रूपमा इन्क्रिप्ट भएको छ भने इन्टरफेस खोज्नुहोस्: अपेक्षित दायरामा ठेगाना भएको utun वा ppp उपकरण कुनै कुराले सुरुङ स्थापना गरेको प्रमाण हो। यो सेवा स्थितिभन्दा कमजोर सङ्केत हो, त्यसैले इन्टरफेसलाई पहिचानको प्रमाण मान्नुको सट्टा मार्ग जाँचसँग जोड्नुहोस्। धेरै क्लाइन्टले धेरै यस्ता इन्टरफेस बनाउन सक्छन्, र तीमध्ये एउटा मात्र तपाईंले भन्नुभएको सुरुङको हो।

स्थिति मार्गनिर्देशन होइन

जोडिएको सेवाले सुरुङ अवस्थित छ भन्छ। तपाईंको गन्तव्यले यसलाई प्रयोग गर्छ भन्ने भन्दैन। ठेगानाहरू पढ्नुहोस्, त्यसपछि कर्नेललाई सिधै सोध्नुहोस्:

ifconfig | grep -A4 utun
netstat -rn -f inet
route -n get 10.40.0.20

पूर्ण सुरुङको क्लाइन्टले सुरुङबाट पूर्वनिर्धारित मार्ग राख्छ; विभाजित सुरुङको क्लाइन्टले निश्चित निजी प्रिफिक्स राख्छ। दुवैले Connected भन्छन्, र स्थिति मात्र जाँच्ने स्क्रिप्ट सजिलै गलत बाटोमा दौडिन्छ। सुरुङ रोक्दा अर्को क्लाइन्टले राखेका मार्ग हट्छन् भन्ने छैन, र यो एउटै समयमा जोडिएको सेवा र पुरानो मार्ग हुने एउटा बाटो हो। तपाईंलाई महत्त्वपूर्ण गन्तव्य हेर्नुहोस्, पूरै मार्ग तालिका होइन।

नामकरण छुट्टै समस्या हो

अन्य मेसिनले Mac मा नामबाट पुग्न सक्दैनन् जबकि यसको ठेगाना काम गर्छ, र यसलाई VPN को खराबी भनी जानकारी दिइन्छ। स्थानीय होस्ट नाम, होस्ट नाम र DNS रेकर्ड तीन फरक कुरा हुन्। scutil --get LocalHostName ले Bonjour नाम देखाउँछ; sudo scutil --set HostName mac-office ले सिस्टमले जानकारी दिने नाम सेट गर्छ।

यीमध्ये कुनै पनि सेटिङले कार्यालय जोनमा रेकर्ड बनाउँदैन। यदि अन्य होस्टले नाम DNS मार्फत समाधान गर्नुपर्छ भने जोनको मालिकले थप्नुपर्छ, वा स्क्रिप्टले सट्टा ठेगाना प्रयोग गर्नुपर्छ। स्थिर नाम सेट गर्दा घोषणाहरू एकरूप हुन्छन्; यसले रिजोल्भरलाई जवाफ दिन लगाउँदैन।

स्क्रिप्टमा सेवा पहिचानकर्ता र अपेक्षित मार्गको आकार सँगै लेख्नुहोस्, र प्रतिलिपि अघि दुवै जाँच्नुहोस्। सक्रिय तर गलत दिशामा मार्गनिर्देशित सुरुङ सुरुङ नभएजस्तै असफल हुन्छ, र Connected भन्ने लग लाइनले अर्को व्यक्तिलाई गलत ठाउँमा खोज्न पठाउनेछ।

सम्बन्धित लेखहरू