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

लेबल टोपणनाव आहे, प्रकार पेलोड घोषित करतो

macOS VPN सेवा म्हणजे दाखवलेले नाव, मालक क्लायंट आणि टाइप केलेल्या सेटिंग्जचा संच असलेली सिस्टम कॉन्फिगरेशन नोंद। दाखवलेले नाव मोकळा मजकूर आहे, नोंद तयार करणारा कोणीही ते संपादित करू शकतो, आणि वापरकर्ते मेनू बारमध्ये जो भाग पाहतात तो हाच। सेटिंग्ज तथ्ये वाहतात: कोणता कनेक्शन प्रकार, कोणता गेटवे, कोणती प्रमाणीकरण रचना। दोन्हींना सुसंगत ठेवणारे काहीही नाही, म्हणून „L2TP ऑफिस“ नावाचे प्रोफाइल IKEv2 सेवा असू शकते।

वैयक्तिकरित्या तयार केलेल्या कनेक्शनसाठी, मालक अनुप्रयोग किंवा सिस्टमचे स्वतःचे VPN पॅनेल ती सेटिंग्ज दाखवते। व्यवस्थापित Mac वर प्रोफाइल प्रशासकाचे असते, आणि योग्य पाऊल म्हणजे व्यवस्थापित पेलोड संपादित करण्याऐवजी गुप्त नसलेला सारांश मागणे। दोन्ही प्रकरणे मेनू बारमध्ये सारखी दिसतात आणि आतून पूर्णपणे वेगळी वागतात। एक तुमचे तपासण्यासाठी आणि बदलण्यासाठी; दुसरे तैनात आहे आणि पुढील तपासणीत पुनर्संचयित होईल।

हा फरक महत्त्वाचा आहे कारण व्यवस्थापित आणि वैयक्तिक कॉन्फिगरेशन वेगळ्या पद्धतीने नियंत्रित होतात। व्यवस्थापनाने स्थापित केलेले प्रोफाइल बदलले जाईल किंवा पुन्हा लागू केले जाईल, त्यामुळे स्थानिक संपादन एकतर अयशस्वी होते किंवा शांतपणे परत जाते। ज्या फाइलवर तुमचे नियंत्रण नाही तिची रिव्हर्स इंजिनिअरिंग करण्याऐवजी मालकाकडून प्रकार, गेटवे ओळख आणि प्रमाणीकरण पद्धत मागा।

पेलोडमधील इतर कशाहीपेक्षा आधी VPNType वाचा

Apple ची व्यवस्थापित VPN पेलोड स्कीमा तिचा कनेक्शन प्रकार VPNType की मध्ये घोषित करते, ज्याचा PayloadType com.apple.vpn.managed असलेल्या शब्दकोशाच्या आत। मूल्य हे IKEv2, IPsec, L2TP किंवा VPN सारखे लहान टोकन आहे, आणि पेलोडमधील बाकी सर्व त्या टोकननुसार अर्थ लावले जाते।

<key>PayloadType</key>
<string>com.apple.vpn.managed</string>
<key>VPNType</key>
<string>IKEv2</string>
<key>IKEv2</key>
<dict>
  <key>RemoteAddress</key>
  <string>vpn.head-office.example</string>
  <key>RemoteIdentifier</key>
  <string>ikev2.head-office.example</string>
</dict>

हा तुकडा उदाहरणात्मक आहे, स्थापित करण्यायोग्य नाही: ही पेलोड अॅरेमधील एक नोंद आहे, ज्यातून खऱ्या तैनातीस आवश्यक प्रोफाइल मेटाडेटा आणि क्रेडेन्शियल्स काढून टाकले आहेत। तो आकारासाठी वाचा, सामग्रीसाठी नाही। हेदेखील लक्षात घ्या की RemoteAddress आणि RemoteIdentifier वेगवेगळ्या कामांची वेगवेगळी फील्ड आहेत, तैनातीने त्यांना एकच स्ट्रिंग दिली तरी।

जुने मूल्य, जसे PPTP, जुन्या फाइलमध्ये अजूनही दिसू शकते, पण सध्याचे macOS नवीन कॉन्फिगरेशनसाठी ते पर्याय म्हणून देत नाही। जतन केलेल्या प्रोफाइलमध्ये टोकन सापडणे हे काय लिहिले होते हे सिद्ध करते, ऑपरेटिंग सिस्टम अजून काय स्वीकारेल ते नाही।

सानुकूल प्रकारांना VPNSubType आणि मालक अनुप्रयोग लागतो

जेव्हा VPNType VPN असतो, तेव्हा पेलोडने VPNSubType देखील वाहिले पाहिजे, जे कनेक्शन अंमलात आणणारे प्लग-इन किंवा Network Extension पुरवठादार ओळखते। हेच ओळखचिन्ह कनेक्शनला विशिष्ट क्लायंटकडे नेतो, त्यामुळे चुकीचा उपप्रकार अशी प्रोफाइल तयार करतो जी स्थापित होते आणि नंतर सुरू होण्यास नकार देते।

अॅप-एक्स्टेंशन आधारित पुरवठादारांमध्ये, ओळखचिन्ह अंदाज लावलेल्या एक्स्टेंशन नावाचे नसून ते सामावणाऱ्या अॅपचे असते, आणि प्रोफाइल हाताने संपादित करताना लोक सामान्यतः हाच तपशील चुकतात। योग्य उपप्रकारही क्लायंटचे वर्णन करतो, वायर प्रोटोकॉल, प्रमाणीकरण पद्धत किंवा तो क्लायंट वापरणार असलेल्या दूरस्थ प्रवेश धोरणाचे नाही।

त्यामुळे सानुकूल पेलोड तुम्हाला सांगते की कोणते सॉफ्टवेअर कनेक्शनचे मालक आहे आणि थोडे अधिक नाही। ते कशावर वाटाघाटी करते हे जाणून घेण्यासाठी त्या पुरवठादाराचे स्वतःचे दस्तऐवज आणि त्याच्या कॉन्फिगर केलेल्या सेटिंग्ज वाचा। दुसऱ्या संस्थेच्या प्रोफाइलमधून उपप्रकार कॉपी करणे हे कॉन्फिगरेशन तंत्र नाही; तो एक अंदाज आहे जो योगायोगाने पार्स होतो।

Mac ने प्रत्यक्षात काय कॉन्फिगर केले याची यादी करा

कोणतीही फाइल वाचण्यापूर्वी, सिस्टमला विचारा की कोणत्या सेवा आहेत आणि त्या कोणत्या स्थितीत आहेत। कमांड-लाइन दृश्य पॅनेलमध्ये क्लिक करण्यापेक्षा वेगवान आहे आणि प्रत्येक नोंदीच्या शेजारी प्रकार छापते।

scutil --nc list
scutil --nc show "Office VPN"

पहिला कमांड कॉन्फिगर केलेल्या VPN सेवा त्यांच्या सध्याच्या स्थितीसह सूचीबद्ध करतो, आणि दुसरा निवडलेल्या सेवेची सेटिंग्ज छापतो, त्यात प्रकार आणि ती संपर्क करणारा सर्व्हर पत्ता समाविष्ट आहे। त्या पत्त्याची तुम्हाला अपेक्षा असलेल्या गेटवेशी तुलना करा, कारण निवृत्त होस्टकडे निर्देश करणारी जुनी नोंद ही सामान्य वारसा समस्या आहे।

हे कमांड कॉन्फिगरेशन आणि स्थिती दाखवतात; बोगदा रहदारी वाहतो हे ते सिद्ध करत नाहीत। सेवा डिस्कनेक्ट केलेली असल्यास, आउटपुट कार्यरत सत्राऐवजी हेतूचे वर्णन करते। रहदारीशिवाय जोडलेली सेवा पुन्हा दुसरी समस्या आहे, सामान्यतः राउटिंग किंवा DNS, प्रोटोकॉल प्रकार नाही। या तीन निरीक्षणे वेगळी ठेवा, अन्यथा निदान पुन्हा अंदाजात पडेल।

जतन केलेल्या सेटिंग्ज जिवंत सत्रापासून वेगळ्या ठेवा

जतन केलेले प्रोफाइल हे हेतूचे विधान आहे। गेटवे ती सेवा अजूनही देतो, हे प्रोफाइल सक्रिय आहे, किंवा सत्राने यशस्वीपणे वाटाघाटी केली हे ते दाखवत नाही। हे तीन वेगळे प्रश्न आहेत आणि प्रत्येकाचा स्वतःचा पुरावा आहे।

सक्रिय कनेक्शन आणि गेटवेने सादर केलेली ओळख ओळखण्यासाठी मालकाचे स्थिती दृश्य किंवा निदान साधने वापरा। पोर्ट स्कॅन किंवा असंबंधित साइटवर पाहिलेले प्रमाणपत्र दोन्हीपैकी कोणत्याही प्रश्नाचे उत्तर देत नाही, आणि प्रमाणपत्राचे सामान्य नाव अपेक्षित दूरस्थ ओळखचिन्हासारखे नसते।

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

संबंधित लेख