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 का निरीक्षण करें, क्योंकि नाम समाधान एक अलग नीति है और काम करने वाला रूट यह साबित नहीं करता कि निजी नाम हल होते हैं।