Windows की .pbk फ़ाइल किसकी होती है (और किसकी नहीं)
.pbk फ़ाइल एक प्रोफ़ाइल या RRAS सर्वर की फ़ोन बुक है, कोई पोर्टेबल VPN स्कीमा नहीं। मालिक, अनुभाग और उजागर संपत्ति पढ़ें।
खोज परिणाम आपको एक .pbk फ़ाइल देते हैं, कुंजी के नाम परिचित लगते हैं, और स्पष्ट कदम यह है कि इसे किसी भी Windows VPN के लिए पोर्टेबल स्कीमा मान लिया जाए। ऐसा नहीं है। फ़ॉर्मैट किसी मालिक का होता है, और वही कुंजी इस पर निर्भर करती है कि उसे किस मालिक ने लिखा है। पहले दायरा पढ़ना ही दस्तावेज़ीकरण के अभ्यास को असहाय संपादन में बदलने से रोकता है।
चार मालिक, चार अलग पाठक
चार अलग मालिक एक जैसी दिखने वाली फ़ाइलें लिखते हैं। प्रति-उपयोगकर्ता मूल कनेक्शन वर्तमान उपयोगकर्ता की फ़ोन बुक में जाता है, जबकि सभी-उपयोगकर्ता कनेक्शन मशीन-व्यापी भंडार में जाता है जिसे होस्ट पर हर खाता पढ़ सकता है। RRAS सर्वर अपनी ही राउटिंग भूमिका के लिए मांग-पर-डायल कॉन्फ़िगरेशन रखता है, और तीसरे पक्ष का क्लाइंट अपना फ़ॉर्मैट रख सकता है जो केवल एक्सटेंशन साझा करता है। वही एक्सटेंशन, चार पाठक, नियमों के चार सेट।
मिलता-जुलता प्रदर्शित नाम दो ऐसी प्रविष्टियों को एक नहीं बनाता, और उनके बीच कुंजी की प्रतिलिपि यह मानती है कि कोई प्रबंधक ऐसी बात का सम्मान करेगा जिसे उसने कभी दस्तावेज़ित नहीं किया। मालिक यह भी तय करता है कि फ़ाइल कौन बदल सकता है: प्रति-उपयोगकर्ता प्रोफ़ाइल उपयोगकर्ता की पसंद है, मशीन-व्यापी प्रोफ़ाइल प्रशासनिक निर्णय है, और सर्वर पर मांग-पर-डायल प्रविष्टि अपने स्वयं के परिवर्तन नियंत्रण के अधीन राउटिंग कॉन्फ़िगरेशन है। इससे स्वामित्व की गलती फ़ॉर्मैट की समस्या बनने से पहले अनुमति की समस्या बन जाती है।
मालिक उस घटक को देखकर तय करें जो कनेक्शन का प्रबंधन करता है, फ़ाइल को नहीं। फ़ाइल एक कलाकृति है; प्रबंधक घटक तय करता है कि कौन-सी कुंजियाँ और कब पढ़ी जाएँ। पहले कलाकृति और बाद में प्रबंधक पढ़ना ही वह रास्ता है जिससे लोग ऐसे क्षेत्र का संपादन करने लगते हैं जिससे कुछ भी नहीं पूछता।
प्रकाशित फ़ॉर्मैट कहाँ आपकी फ़ाइल का वर्णन करना बंद करता है
RRAS प्रबंधन प्रोटोकॉल में फ़ोन बुक सादा पाठ है जिसे प्रबंधन क्लाइंट लिखता है और राउटिंग सेवा पढ़ती है, इसीलिए MS-RRASM विशिष्टि सर्वर के लिए मांग-पर-डायल सेटिंग्स का वर्णन करता है, डेस्कटॉप प्रोफ़ाइल के लिए नहीं। संरचना वह हिस्सा है जिसे सपाट पठन नष्ट कर देता है। एक प्रविष्टि में कई मीडिया ब्लॉक हो सकते हैं, हर एक में डिवाइस ब्लॉक होते हैं जो बदले में अलग-अलग नंबरों के ब्लॉक रखते हैं। इसलिए वही कुंजी एक से अधिक स्थानों पर अलग अर्थ के साथ दिख सकती है।
कुंजी को उसके अनुभाग और उसके संस्करण-नोट के साथ पढ़ें, और डेस्कटॉप इंटरफ़ेस में समान नाम वाले चेकबॉक्स से कोई मान न लें। दस्तावेज़ में परिचित कुंजियाँ मिलना यह सिद्ध नहीं करता कि वह किसी असंबंधित मूल प्रोफ़ाइल के हर क्षेत्र को कवर करता है। अनुभाग के नियम भी डेस्कटॉप फ़ोन बुक को सर्वर फ़ॉर्मैट में फिर से लिखने की अनुमति नहीं हैं।
| Owner | What reads the file | What a key means there |
|---|---|---|
| Per-user native connection | The user's own connection manager | A property of that user profile |
| All-user native connection | The machine-wide connection store | A property shared by everyone on the host |
| RRAS demand-dial | The RRAS service, using the documented hierarchy | A field inside a media, device or number section |
| Third-party client | That vendor's own parser | Whatever that vendor documents, if anything |
तालिका विशिष्टि नहीं, पठन-सहायता है: यह बताती है कि किस पाठक से पूछें, और पाठक बताता है कि क्षेत्र का अर्थ क्या है। जब वह पाठक तीसरे पक्ष का पार्सर हो, तो ईमानदार उत्तर यह हो सकता है कि कोई सार्वजनिक दस्तावेज़ इस क्षेत्र को बिल्कुल दस्तावेज़ित नहीं करता।
Windows से पूछें, फ़ाइल से नहीं
मूल कनेक्शन के लिए फ़ाइल पढ़ने के बजाय Windows से प्रोफ़ाइल माँगें, क्योंकि टाइप की गई संपत्तियाँ ही दस्तावेज़ित सतह हैं और समर्थित परिवर्तन केवल उन्हीं को बदलता है। नीचे दो आदेश दो मूल भंडार को अलग-अलग पढ़ते हैं। यदि प्रोफ़ाइल दोनों में से किसी भंडार में नहीं है, तो उसे प्रबंधित करने वाला क्लाइंट मूल तंत्र का उपयोग नहीं कर रहा और कोई मूल cmdlet उसका वर्णन नहीं करेगा।
Get-VpnConnection -Name 'Field Ops'
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress, TunnelTypeतैनाती के लिए और निरीक्षण के लिए नहीं, दस्तावेज़ित मार्ग नामित स्कीमा वाली प्रबंधित प्रोफ़ाइल सेटिंग है, पाठ या बाइनरी ब्लॉब के भीतर संख्यात्मक संपादन नहीं। प्रोफ़ाइल परिभाषा समर्थित सेटिंग्स का वर्णन करती है; यह वे प्रमाणपत्र और निजी कुंजियाँ प्रदान नहीं करती जिन पर प्रोफ़ाइल निर्भर है। नामांकन अपने अधिकार वाली अलग प्रक्रिया है, और फ़ोन-बुक कुंजी को समझना कभी निजी कुंजी वितरित नहीं करता। दोनों मार्ग अलग योजना बनाएँ, वरना पहली प्रमाणपत्र तैनाती दूसरी घटना बन जाएगी।
एक संपत्ति, फिर उसके आसपास जीवनचक्र
सहेजा गया मान लागू किया गया मान नहीं है। स्वीकृत परिवर्तन के बाद नया कनेक्शन खोलें और वे रूट जाँचें जो प्रोफ़ाइल स्थापित करता है, वह रिज़ॉल्वर नीति जो उसे विरासत में मिलती है, और वह क्रिया जिसे वह सक्षम करने के लिए था। पहले से चालू सत्र का पुन: उपयोग पुरानी सेटिंग्स की परीक्षा करता है और झूठा नकारात्मक परिणाम देता है।
किसी भी कच्ची-फ़ाइल कार्य से पहले फ़ाइल की प्रतिलिपि किनारे पर करें, क्योंकि कई प्रविष्टियों वाली फ़ोन बुक साझा कलाकृति है, और पूरी फ़ाइल फिर से लिखने वाला लक्षित संपादन परिवर्तन से बड़ी प्रभाव-त्रिज्या रखता है। असंबंधित प्रविष्टियाँ अक्षुण्ण रखें, और नया सत्यापित होने तक मूल संरक्षित कॉन्फ़िगरेशन रखें। यदि कोई आवश्यक क्षेत्र उस मालिक और संस्करण के लिए दस्तावेज़ित नहीं है जो आपके पास वास्तव में है, तो उसे खुला सहायता प्रश्न दर्ज करें। दूसरी मशीन की फ़ाइल से एन्कोडिंग गढ़ना ही वह तरीका है जिससे काम करने वाली प्रोफ़ाइल बिना किसी संदर्भ बिंदु के डिबगिंग परियोजना बन जाती है।
अनुशासन हर कदम पर एक ही है: मालिक का नाम लें, अनुभाग का नाम लें, फिर समर्थित क्रिया का नाम लें। बाकी सब ऐसी अनुमान है जिस पर उद्धरण चिपका है।