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 तपासा, कारण नाव निराकरण हे वेगळे धोरण आहे आणि चालणारा रूट खाजगी नावे सुटतात हे सिद्ध करत नाही।