Mac VPN का लागि स्थायी रुट: networksetup वा कनेक्ट हुक?

प्रत्येक जडानपछि टाइप गरिएको रुटले क्षण समाधान गर्छ, हप्ता होइन। macOS मा, टिकाउ विकल्प सामान्यतया VPN सेवासँग भण्डारण गरिएको प्रिफिक्स हो, किनकि सेवाले यसलाई प्रत्येक जडानमा पुनः स्थापना गर्छ र सेवा बन्द हुँदा हटाउँछ। विकल्पहरू परीक्षणका लागि अस्थायी route add र वार्तापछि मात्र थाहा हुने ठेगानाका लागि कनेक्ट हुक हुन्।

रुट सेवाको हो वा सत्रको हो निर्णय गर्नुहोस्

प्रिफिक्स केमा निर्भर छ सोध्नुहोस्। यदि यो स्थानीय VPN सेवापछाडिको स्थिर निजी सञ्जाल हो भने, रुट त्यही सेवाको हो। यदि यो प्रत्येक जडानमा परिवर्तन हुने पियर ठेगानामा निर्भर छ भने, हुक वा अवस्था-चालित कार्य राम्रो मालिक हुन सक्छ। यदि तपाईं अर्को पाँच मिनेटका लागि मात्र मार्ग जाँच्दै हुनुहुन्छ भने, अस्थायी रुट पर्याप्त छ।

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

सत्रसँग बाँधिएको रुट इन्टरफेसको हो, र त्यो सङ्ख्या सूचना बिना परिवर्तन हुन्छ। पुनःजडानले सुरुङलाई अघिल्लो सत्रले प्रयोग गरेको भन्दा फरक utun नाम दिन सक्छ, जसले हार्डकोड गरिएको आदेशलाई कतै नसङ्केत गर्ने वा, अझ नराम्रो, अर्को सुरुङतर्फ सङ्केत गर्ने रुटमा बदल्छ।

वर्तमान रुट र सेवा अवस्था पढ्नुहोस्

प्रणालीले वास्तवमै प्रयोग गर्ने नामहरूबाट सुरु गर्नुहोस्। नेटवर्क सेटिङमा सेवाको नाम तलका आदेशहरूका लागि पहिचानकर्ता हो, र वर्तमान रुट तालिकाले जोडिएको क्लाइन्टले के स्थापना गरेको छ देखाउँछ। सुरुङ चालु हुँदा दुवै पढ्नुहोस्।

scutil --nc list
networksetup -listnetworkserviceorder
netstat -rn | head -30
route get 10.20.5.5

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

जोडिएको बेला पियर ठेगाना नोट गर्नुहोस्। त्यो सेवासँग बाँधिएको रुटमा गेटवे मान बन्छ, र सामान्यतया netstat -rn मा सुरुङको पूर्वनिर्धारित रुटका लागि देखाइने गन्तव्य त्यही हो।

networksetup ले प्रिफिक्स भण्डारण गर्नुहोस्

networksetup उपकरणले सञ्जाल सेवामा थप रुटहरू जोड्छ। OfficeVPN नामको सेवा र सुरुङको पियरमार्फत पुग्ने निजी प्रिफिक्सका लागि, ढाँचा यो हो:

sudo networksetup -setadditionalroutes OfficeVPN 10.20.0.0 255.255.0.0 10.8.0.6
networksetup -getadditionalroutes OfficeVPN

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

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

route add केवल परीक्षणका लागि प्रयोग गर्नुहोस्

सीधा रुटले प्रिफिक्स स्थायी बनाउनुअघि काम गर्छ भनी प्रमाणित गर्न उपयोगी हुन्छ। इन्टरफेस ढाँचाले गेटवे खोजीबाट बच्छ:

sudo route -n add -net 10.20.0.0/16 -interface utun4

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

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

ठेगाना वार्ता हुँदा मात्र हुक छान्नुहोस्

PPP-आधारित लिङ्कका लागि, जस्तै L2TP, macOS लिङ्क स्थापित भएपछि /etc/ppp/ip-up चलाउँछ। स्क्रिप्टले इन्टरफेसको नाम र वार्ता भएका स्थानीय तथा टाढाका ठेगाना पाउँछ, त्यसैले सर्भरले तोकेको पियरमा निर्भर रुट थप्न सक्छ। स्थिर सेवा रुटले व्यक्त गर्न नसक्ने ठ्याक्कै त्यही अवस्था हो।

IKEv2 र विक्रेताका क्लाइन्टले त्यो PPP मार्ग बिल्कुलै प्रयोग नगर्न सक्छन्, जसको अर्थ स्क्रिप्ट पूरै सत्रमा चुप बस्न सक्छ। त्यस्तो हुँदा, scutil --nc status सोध्ने र अवस्था परिवर्तनमा कार्य गर्ने launchd कार्य समानान्तर संयन्त्र हो, थोरै ढिलाइसहित।

तपाईंले जुनसुकै हुक प्रयोग गर्नुहोस्, यसलाई इडेम्पोटेन्ट बनाउनुहोस् र यसले आफैँले बनाएका रुट मात्र हटाओस्। जुन स्क्रिप्टले सुरुङको उल्लेख गर्ने हरेक रुट मेटाउँछ, त्यसले अन्ततः VPN सर्भर पुग्नयोग्य राख्ने रुट पनि मेटाउनेछ, र जडान सफल हुनासाथ टुट्नेछ।

निजी गन्तव्य, सामान्य ब्राउजिङ र पुनःजडान वा निद्रा चक्र जाँचेर अन्त्य गर्नुहोस्। त्यसपछि scutil --dns जाँच्नुहोस्, किनकि नाम समाधान छुट्टै नीति हो र चल्ने रुटले निजी नाम समाधान हुन्छन् भनी प्रमाणित गर्दैन।