რას ეკუთვნის 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
გაშლისთვის და არა შემოწმებისთვის დოკუმენტირებული გზა არის მართული პროფილის პარამეტრი დასახელებული სქემით და არა რიცხვითი რედაქტირება ტექსტურ ან ორობით ბლოკში. პროფილის განმარტება აღწერს მხარდაჭერილ პარამეტრებს; ის არ ამარაგებს სერთიფიკატებსა და პირად გასაღებებს, რომლებზეც პროფილია დამოკიდებული. რეგისტრაცია ცალკე პროცესია საკუთარი უფლებამოსილებით და სატელეფონო წიგნის გასაღების გაგებას არასდროს გაუვრცელებია პირადი გასაღები. დაგეგმეთ ორი გზა ცალ-ცალკე, თორემ სერთიფიკატების პირველი გაშლა მეორე ინციდენტად იქცევა.
ერთი თვისება, შემდეგ სასიცოცხლო ციკლი მის გარშემო
შენახული მნიშვნელობა არ არის გამოყენებული მნიშვნელობა. დამტკიცებული ცვლილების შემდეგ გახსენით ახალი კავშირი და შეამოწმეთ მარშრუტები, რომლებსაც პროფილი აყენებს, მის მიერ მემკვიდრეობით მიღებული გადამწყვეტის პოლიტიკა და ოპერაცია, რომლის ჩასართავადაც იყო განკუთვნილი. უკვე აწეული სესიის ხელახლა გამოყენება ძველ პარამეტრებს ამოწმებს და ცრუ უარყოფით შედეგს იძლევა.
ნებისმიერ ნედლ ფაილთან მუშაობამდე დააკოპირეთ ფაილი გვერდზე, რადგან რამდენიმე ჩანაწერის მქონე სატელეფონო წიგნი საერთო არტეფაქტია და მთელი ფაილის გადამწერ მიზანმიმართულ რედაქტირებას ცვლილებაზე დიდი ზემოქმედების რადიუსი აქვს. დაუკავშირებელი ჩანაწერები ხელუხლებლად დატოვეთ და შეინახეთ თავდაპირველი დაცული კონფიგურაცია, სანამ ახალი არ დადასტურდება. თუ სავალდებულო ველი არ არის დოკუმენტირებული იმ მფლობელისა და გამოშვებისთვის, რომელიც ნამდვილად გაქვთ, ჩაწერეთ ეს როგორც ღია მხარდაჭერის კითხვა. სხვა მანქანის ფაილიდან კოდირების გამოგონება სწორედ ის გზაა, რომლითაც მომუშავე პროფილი ერთი საცნობი წერტილის გარეშე გამართვის პროექტად იქცევა.
დისციპლინა ყოველ ნაბიჯზე ერთია: დაასახელეთ მფლობელი, დაასახელეთ სექცია, შემდეგ დაასახელეთ მხარდაჭერილი ოპერაცია. ყველაფერი დანარჩენი ვარაუდია მიმაგრებული ციტატით.