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വിന്യാസത്തിനാണ്, പരിശോധനയ്ക്കല്ല, ഡോക്യുമെന്റ് ചെയ്ത പാത പേരുള്ള സ്കീമയുള്ള മാനേജ്ഡ് പ്രൊഫൈൽ ക്രമീകരണമാണ്, ടെക്സ്റ്റ് അല്ലെങ്കിൽ ബൈനറി ബ്ലോബിനുള്ളിലെ സംഖ്യാ എഡിറ്റിംഗല്ല. പ്രൊഫൈൽ നിർവചനം പിന്തുണയുള്ള ക്രമീകരണങ്ങൾ വിവരിക്കുന്നു; പ്രൊഫൈൽ ആശ്രയിക്കുന്ന സർട്ടിഫിക്കറ്റുകളും സ്വകാര്യ കീകളും അത് നൽകുന്നില്ല. രജിസ്ട്രേഷൻ സ്വന്തം അധികാരമുള്ള വേറെ പ്രക്രിയയാണ്, ഫോൺ ബുക്ക് കീ മനസ്സിലാക്കുന്നത് ഒരിക്കലും സ്വകാര്യ കീ വിതരണം ചെയ്തിട്ടില്ല. രണ്ട് പാതകളും വെവ്വേറെ ആസൂത്രണം ചെയ്യുക, അല്ലെങ്കിൽ ആദ്യ സർട്ടിഫിക്കറ്റ് വിന്യാസം തന്നെ രണ്ടാം സംഭവമാകും.
ഒരു സവിശേഷത, പിന്നെ അതിന് ചുറ്റുമുള്ള ജീവിതചക്രം
സംഭരിച്ച മൂല്യം പ്രയോഗിച്ച മൂല്യമല്ല. അംഗീകരിച്ച മാറ്റത്തിന് ശേഷം പുതിയ കണക്ഷൻ തുറന്ന് പ്രൊഫൈൽ ഇൻസ്റ്റാൾ ചെയ്യുന്ന റൂട്ടുകളും അത് പാരമ്പര്യമായി ലഭിക്കുന്ന പരിഹാരക നയവും അത് പ്രവർത്തനക്ഷമമാക്കേണ്ടിയിരുന്ന പ്രവർത്തനവും പരിശോധിക്കുക. ഇതിനകം ഉയർന്ന സെഷൻ വീണ്ടും ഉപയോഗിക്കുന്നത് പഴയ ക്രമീകരണങ്ങൾ പരീക്ഷിക്കുകയും തെറ്റായ നെഗറ്റീവ് ഫലം നൽകുകയും ചെയ്യുന്നു.
ഏതെങ്കിലും അസംസ്കൃത ഫയൽ ജോലിക്ക് മുൻപ് ഫയൽ ഒരു വശത്തേക്ക് പകർത്തുക, കാരണം നിരവധി എൻട്രികളുള്ള ഫോൺ ബുക്ക് പങ്കിട്ട കലാസൃഷ്ടിയാണ്, മുഴുവൻ ഫയലും വീണ്ടും എഴുതുന്ന ലക്ഷ്യബോധമുള്ള എഡിറ്റിംഗിന് മാറ്റത്തെക്കാൾ വലിയ സ്വാധീന വ്യാസമുണ്ട്. ബന്ധമില്ലാത്ത എൻട്രികൾ അതേപടി നിലനിർത്തുക, പുതിയത് പരിശോധിക്കുന്നതുവരെ യഥാർത്ഥ സംരക്ഷിത കോൺഫിഗറേഷൻ സൂക്ഷിക്കുക. നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ ഉള്ള ഉടമയ്ക്കും പതിപ്പിനും ഒരു നിർബന്ധിത ഫീൽഡ് ഡോക്യുമെന്റ് ചെയ്തിട്ടില്ലെങ്കിൽ അത് തുറന്ന പിന്തുണാ ചോദ്യമായി രേഖപ്പെടുത്തുക. മറ്റൊരു മെഷീന്റെ ഫയലിൽ നിന്ന് എൻകോഡിംഗ് കെട്ടിച്ചമയ്ക്കുന്നതാണ് പ്രവർത്തിക്കുന്ന പ്രൊഫൈൽ ഒരു റഫറൻസ് പോയിന്റുമില്ലാത്ത ഡീബഗ്ഗിംഗ് പ്രോജക്റ്റ് ആകുന്ന വഴി.
ഓരോ ചുവടിലും അച്ചടക്കം ഒന്നുതന്നെ: ഉടമയെ പേരിടുക, വിഭാഗത്തെ പേരിടുക, പിന്നീട് പിന്തുണയുള്ള പ്രവർത്തനത്തെ പേരിടുക. ബാക്കിയെല്ലാം ഒരു ഉദ്ധരണി പതിപ്പിച്ച ഊഹമാണ്.