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 से छिप सकती हैं, इसलिए ऐप का स्टेटस पैनल भी जाँचें; जो आपको नहीं मिलेगा वह है ऐसी Apple प्राथमिकता जो इस Mac को गेटवे बना दे।

तीन सवाल दोनों भूमिकाओं को अलग करते हैं

इन्हें क्रम से हल करें। पहला आमतौर पर बाकी तय कर देता है, और तीसरा वह जगह है जहाँ Mac-विशिष्ट योजना सबसे ज़्यादा गड़बड़ाती है।

1. बातचीत कौन शुरू करता है? अगर आपका Mac बाहर डायल करता है और दूसरी तरफ़ जवाब देती है, तो आपको क्लाइंट चाहिए। अगर इंटरनेट पर मौजूद डिवाइसों को आपके नेटवर्क तक पहुँचने के लिए अंदर डायल करना है, तो आपको सार्वजनिक प्रवेश बिंदु वाला गेटवे चाहिए, और Mac उसी गेटवे का क्लाइंट बना रह सकता है।

2. सुरंग चालू रहने पर क्या पहुँच में होना चाहिए? एक मेज़बान पर एक सेवा पोर्ट-फ़ॉरवर्डिंग का फ़ैसला है। पूरा सबनेट, नाम-विश्लेषण सहित, रूटिंग और DNS का फ़ैसला है, और यह बदलता है कि गेटवे को क्या आगे भेजना है, यह नहीं कि क्लाइंट प्रविष्टि क्या कहती है।

3. स्वीकार करने वाला सिरा कौन-सा OS रिलीज़ चलाता है? Mac के लिए उस सवाल का सख़्त जवाब है। Apple ने VPN को macOS Server 5.7.1 से हटाया हुआ बताया है, और macOS Server ऐप ही 21 अप्रैल 2022 को बंद कर दिया गया; सेवा इतिहास की सूचना वह पेज है जिसे पढ़ना चाहिए जब कोई पुराना ट्यूटोरियल आपको VPN सेवा के उस चेकबॉक्स से गुज़ारे जो अब मौजूद नहीं है।

जब पहला जवाब “कोई बाहरी व्यक्ति शुरू करता है” हो, तो Mac के क्लाइंट पैनल में स्विच ढूँढ़ना बंद करें और वह होस्ट चुनने जाएँ जो सुरंग समाप्त करेगा।

इसके बजाय गेटवे कहाँ रह सकता है

चार व्यवस्थाएँ अधिकतर घरेलू और छोटे-दफ़्तर मामलों को कवर करती हैं। असली सर्वर मोड वाला राउटर, अलग लेबल वाले क्लाइंट मोड के विपरीत, सुरंग को किनारे पर समाप्त करता है और होस्ट की संख्या कम रखता है, पर उस फ़र्मवेयर के प्रोटोकॉल समर्थन से बँध जाता है। NAS या हमेशा चालू रहने वाला मिनी PC विक्रेता का सर्वर पैकेज चलाता है और आपको पढ़ने योग्य लॉग छोड़ता है। छोटा क्लाउड VM आपको अपने नियंत्रण वाला सार्वजनिक पता देता है और दूसरी सुरंग से घर पहुँचता है। WireGuard पर बना mesh ओवरले, या साथियों के बीच रिले करने वाली प्रबंधित सेवा, दोनों सिरों को बाहर डायल कराकर आवक पोर्ट-फ़ॉरवर्डिंग को टाल देती है।

उन विकल्पों के बीच की सीमा आमतौर पर आपका इंटरनेट कनेक्शन होती है, सॉफ़्टवेयर नहीं। अगर ISP आपको कैरियर-ग्रेड NAT के पीछे रखता है, तो राउटर पोर्ट-फ़ॉरवर्डिंग की कोई भी मात्रा पहुँचने योग्य प्रवेश बिंदु नहीं बनाती, और रिले या mesh व्यवस्था ही ईमानदार जवाब है। आपका राउटर जो WAN पता बताता है उसकी तुलना बाहरी दुनिया जो पता देखती है उससे करें; अगर वे अलग हैं और राउटर का मान निजी या साझा श्रेणी में है, तो रिले स्थिति की योजना बनाएँ।

आप जो भी होस्ट चुनें, श्रेणी के बजाय एक पोर्ट पर एक प्रोटोकॉल आगे भेजें, और Mac को आवक रास्ते से बाहर रखें, जब तक कि वह विशिष्ट उत्पाद आपके चलाए जा रहे macOS रिलीज़ के लिए सर्वर भूमिका प्रलेखित न करे।

प्रोफ़ाइल बाँटने से पहले भूमिका की पुष्टि करें

संभावित गेटवे पर यह साबित करें कि लिसनर मौजूद है, बजाय इसके कि इंस्टॉलर ने एक बना दिया होगा। macOS पर इसका मतलब है ऊपर के पोर्ट तक फ़िल्टर किया गया sudo lsof -nP -iUDP, और अगर पैकेट फ़िल्टर नियम डिज़ाइन का हिस्सा हैं तो sudo pfctl -s nat भी। Linux पर ss -lunp वही तथ्य बिना अस्पष्टता के दिखाता है।

फिर नेटवर्क के बाहर से, प्रोटोकॉल का ही उपयोग करके परीक्षण करें। Ping बहुत कम साबित करता है: ICMP आमतौर पर फ़िल्टर होता है और UDP 51820 के बारे में कुछ नहीं कहता। विस्तृत लॉगिंग के साथ क्लाइंट हैंडशेक, सेल्युलर डेटा पर फ़ोन से चलाया गया, सबसे सस्ता असली परीक्षण है क्योंकि वह उसी रास्ते से गुज़रता है जिससे कोई दूरस्थ सहकर्मी गुज़रेगा।

उसके बाद ही आप क्लाइंट प्रोफ़ाइल को छूएँ। Mac पर scutil --nc list उन VPN सेवाओं को छापता है जिन्हें सिस्टम जानता है; अगर अभी बनाया गया गेटवे उनमें नहीं है, तो आप उस मशीन से अलग मशीन कॉन्फ़िगर कर रहे हैं जिसका आपने परीक्षण किया। अगर हैंडशेक LAN पर सफल होता है पर बाहर से विफल होता है, तो दोष आवक रास्ते में है: NAT नियम, प्रदाता का CGNAT, या गेटवे पर फ़ायरवॉल, उसी क्रम में।

कुछ भी बनाने से पहले चार बातें तय करें:

• कनेक्शन कौन-सा पक्ष शुरू करता है, आपका Mac या कोई दूरस्थ डिवाइस।
• क्या स्वीकार करने वाले होस्ट का OS रिलीज़ और उत्पाद वास्तव में सर्वर भूमिका का समर्थन करते हैं।
• क्या आपका ISP आपको पहुँचने योग्य सार्वजनिक पता देता ही है।
• गेटवे कौन-सा एकल पोर्ट और प्रोटोकॉल स्वीकार करेगा, और उसके पीछे कौन-सी सेवा जवाब देती है।

अगला कदम ठोस है: गेटवे होस्ट चुनें, बाहर से उसका लिसनर पुष्ट करें, और तभी Mac पर उसकी ओर इशारा करती क्लाइंट प्रविष्टि बनाएँ।