Mac VPN सेटिंग्ज सर्व्हर सुरू करत नाहीत: गेटवे कुठे राहतो

macOS मध्ये VPN हे नाव दोन वेगवेगळ्या कामांना आहे, आणि सेटिंग्ज पॅनेल त्यातल्या फक्त एकाला हाताळते। या Mac चा रहदारी एखाद्या प्रदात्यातून किंवा दूरच्या गेटवेमधून बाहेर जावी असे वाटत असेल, तर क्लायंट नोंद पुरेशी आहे। हॉटेलच्या खोलीतून तुमच्या घरच्या नेटवर्कवरील प्रिंटर, NAS किंवा प्रशासकीय पृष्ठ गाठायचे असेल, तर त्या नेटवर्कवरच्या एखाद्या गोष्टीने बाहेरून येणारी जोडणी स्वीकारली पाहिजे, आणि आजचा Mac डीफॉल्टने ती गोष्ट नाही। तीन प्रश्न तुम्ही कोणत्या स्थितीत आहात हे ठरवतात, आणि फील्डमध्ये पत्ता टाइप करण्यापूर्वी त्यांना उत्तर देणे योग्य आहे।

क्लायंट नोंद गंतव्यस्थान सांगते, लिसनर नाही

macOS Ventura आणि नंतरच्या आवृत्त्यांमधील सिस्टम सेटिंग्ज > नेटवर्क > VPN मध्ये, जुनी आवृत्ती नेटवर्क प्राधान्यांमध्ये ठेवतात ती फील्डे दुसऱ्याच्या एंडपॉइंटपर्यंत कसे पोहोचायचे हे वर्णन करतात: सर्व्हर पत्ता, दूरचा ID, खाते किंवा प्रमाणपत्र, आणि ऐच्छिक मागणीनुसार जोडणीचे नियम। ती नोंद जतन केल्यावर तुमच्या Mac च्या नेटवर्क संरचनेत जोडणी साठवली जाते। या प्रक्रियेत काहीही पोर्ट बांधत नाही, लिसनर उघडत नाही किंवा दूरच्या वापरकर्त्याची नोंदणी करत नाही।

हे तुम्ही शेलमधून तपासू शकता। सेवा देत असल्याची शंका असलेल्या Mac वर sudo lsof -nP -iUDP चालवा आणि तुमचा प्रोटोकॉल वापरतो ते पोर्ट पाहा: IKEv2 साठी 500 आणि 4500, OpenVPN च्या डीफॉल्टसाठी 1194, WireGuard साठी 51820। फक्त क्लायंट असलेले यंत्र दूरच्या पत्त्या आणि पोर्टशी जोडलेले सॉकेट दाखवते, इंटरनेटवरील कोणतीही गोष्ट गाठू शकेल असे वाइल्डकार्ड बंधन नाही। Network Extension मध्ये चालणारे बोगदे lsof पासून लपू शकतात, म्हणून कोणत्याही परिस्थितीत ॲपचे स्थिती पॅनेलही तपासा; जे तुम्हाला सापडणार नाही ते म्हणजे हा Mac गेटवे बनवणारी Apple प्राधान्य।

तीन प्रश्न दोन भूमिका वेगळे करतात

ते क्रमाने हाताळा। पहिला सहसा बाकीचे ठरवतो, आणि तिसरा म्हणजे Mac-विशिष्ट नियोजन सर्वात जास्त चुकते ते ठिकाण।

1. संभाषण कोण सुरू करते? तुमचा Mac बाहेर डायल करतो आणि दुसरी बाजू उत्तर देते, तर तुम्हाला क्लायंट हवा। इंटरनेटवरील उपकरणांनी तुमचे नेटवर्क गाठण्यासाठी आत डायल करावे लागत असेल, तर सार्वजनिक प्रवेशबिंदू असलेला गेटवे हवा, आणि Mac त्या गेटवेचा क्लायंट राहू शकतो।

2. बोगदा सुरू असताना काय पोहोचण्यायोग्य असले पाहिजे? एका होस्टवरची एक सेवा हा पोर्ट फॉरवर्डिंगचा निर्णय। नाव निराकरणासह संपूर्ण सबनेट हा मार्गनिर्देशन आणि DNS चा निर्णय, आणि तो गेटवेने काय पुढे पाठवायचे हे बदलतो, क्लायंट नोंद काय सांगते ते नाही।

3. स्वीकारणारे टोक कोणती OS आवृत्ती चालवते? Mac साठी त्या प्रश्नाचे कडक उत्तर आहे। Apple ने VPN macOS Server 5.7.1 मधून काढले असे नमूद केले आहे, आणि macOS Server ॲपच 21 एप्रिल 2022 रोजी बंद करण्यात आले; सेवा इतिहासाची सूचना हे असे पृष्ठ आहे जे आता अस्तित्वात नसलेल्या VPN सेवेच्या चेकबॉक्समधून जुने प्रशिक्षण तुम्हाला घेऊन जाते तेव्हा वाचावे।

पहिले उत्तर “बाहेरचे कोणी सुरू करते” असे असेल, तर Mac च्या क्लायंट पॅनेलमध्ये स्विच शोधणे थांबवा आणि बोगदा संपवणारा होस्ट निवडायला जा।

गेटवे त्याऐवजी कुठे राहू शकतो

चार रचना बहुतेक घरगुती आणि लहान कार्यालयीन प्रकरणे व्यापतात। वेगळ्या लेबलाच्या क्लायंट मोडऐवजी खऱ्या सर्व्हर मोडचा राउटर बोगदा काठावर संपवतो आणि होस्टची संख्या कमी ठेवतो, पण त्या फर्मवेअरच्या प्रोटोकॉल आधारावर बांधला जातो। NAS किंवा नेहमी सुरू असलेला मिनी संगणक विक्रेत्याचे सर्व्हर पॅकेज चालवतो आणि वाचता येतील अशा नोंदी ठेवतो। छोटा क्लाउड VM तुम्हाला तुमच्या नियंत्रणातील सार्वजनिक पत्ता देतो आणि दुसऱ्या बोगद्यातून घर गाठतो। WireGuard वर बांधलेले mesh आच्छादन, किंवा सहकाऱ्यांमध्ये रिले करणारी व्यवस्थापित सेवा, दोन्ही टोके बाहेर डायल करू देऊन आतील पोर्ट फॉरवर्डिंग टाळते।

त्या पर्यायांमधली सीमा सहसा सॉफ्टवेअर नसून तुमची इंटरनेट जोडणी असते। ISP तुम्हाला वाहक-स्तरीय NAT मागे ठेवत असेल, तर राउटरवरील पोर्ट फॉरवर्डिंगच्या कितीही प्रमाणात पोहोचण्यायोग्य प्रवेशबिंदू तयार होत नाही, आणि रिले किंवा mesh रचनाच प्रामाणिक उत्तर आहे। तुमचा राउटर जो WAN पत्ता सांगतो आणि बाहेरील जग जो पत्ता पाहतो त्याची तुलना करा; ते वेगळे असतील आणि राउटरचे मूल्य खाजगी किंवा सामायिक श्रेणीत असेल, तर रिले प्रकरणासाठी नियोजन करा।

कोणताही होस्ट निवडला तरी श्रेणीऐवजी एका पोर्टवर एक प्रोटोकॉल पुढे पाठवा, आणि तुम्ही चालवत असलेल्या macOS आवृत्तीसाठी ते विशिष्ट उत्पादन सर्व्हर भूमिका नमूद करत नसेल तर Mac ला आतील मार्गाबाहेर ठेवा।

प्रोफाइल वाटण्यापूर्वी भूमिका निश्चित करा

उमेदवार गेटवेवर, इंस्टॉलरने एक तयार केला असेल असे मानण्याऐवजी लिसनर अस्तित्वात आहे हे सिद्ध करा। macOS वर याचा अर्थ वरील पोर्टपर्यंत गाळलेले sudo lsof -nP -iUDP, आणि पॅकेट गाळणीचे नियम रचनेचा भाग असतील तर sudo pfctl -s nat सुद्धा। Linux वर ss -lunp तीच तथ्ये कोणत्याही संदिग्धतेशिवाय दाखवते।

मग नेटवर्कबाहेरून, प्रोटोकॉलच वापरून चाचणी करा। Ping फारसे सिद्ध करत नाही: ICMP सहसा गाळले जाते आणि UDP 51820 बद्दल काहीही सांगत नाही। तपशीलवार नोंदीसह क्लायंट हँडशेक, सेल्युलर डेटावरील फोनवरून चालवलेला, सर्वात स्वस्त खरी चाचणी आहे कारण तो दूरचा सहकारी जाईल त्याच मार्गाने जातो।

त्यानंतरच तुम्ही क्लायंट प्रोफाइलना हात लावता। Mac वर scutil --nc list सिस्टमला माहीत असलेल्या VPN सेवा छापते; नुकताच बांधलेला गेटवे त्यात नसेल, तर तुम्ही चाचणी केलेल्या यंत्रापेक्षा वेगळे यंत्र संरचित करत आहात। हँडशेक LAN वर यशस्वी होऊन बाहेरून अयशस्वी होत असेल, तर दोष आतील मार्गात आहे: NAT नियम, प्रदात्याचा CGNAT, किंवा गेटवेवरील firewall, त्या क्रमाने।

काहीही बांधण्यापूर्वी चार मुद्दे ठरवा:

• जोडणी कोणती बाजू सुरू करते, तुमचा Mac की दूरचे उपकरण।
• स्वीकारणाऱ्या होस्टची OS आवृत्ती आणि उत्पादन खरोखर सर्व्हर भूमिका टेकतात का।
• तुमचा ISP तुम्हाला पोहोचण्यायोग्य सार्वजनिक पत्ता देतोच का।
• गेटवे कोणता एकच पोर्ट आणि प्रोटोकॉल स्वीकारेल, आणि त्याच्या मागे कोणती सेवा उत्तर देते।

पुढचे पाऊल ठोस आहे: गेटवे होस्ट निवडा, बाहेरून त्याचा लिसनर निश्चित करा, आणि मगच Mac वर त्याकडे बोट दाखवणारी क्लायंट नोंद तयार करा।