Mac-ის VPN ნებართვის მოთხოვნები: რომელს ამტკიცებთ?
ქსელის კონფიგურაციის თანხმობა, Keychain-ზე წვდომა, firewall და სრული დისკის წვდომა ოთხი განსხვავებული ნებართვაა. დაამტკიცეთ ის, რომელსაც დოკუმენტირებული მიზანი აქვს.
თქვენი VPN კლიენტი ნებართვას ითხოვს და თქვენ აჭერთ დაშვებას, რადგან ალტერნატივა ის კავშირია, რომელიც არ დგება. სწორედ ამ ჩვევის გამო რჩება მანქანაზე ფართო ნებართვები, რომლებსაც ვერავინ ხსნის. მოთხოვნები ურთიერთშემცვლელი არ არის: თითოეული სხვა შესაძლებლობას ამტკიცებს და ერთი და იმავე აპის სახელი შეიძლება ყველა მათგანის წინ გამოჩნდეს. გადაწყვეტილების მიღებამდე წაიკითხეთ წინადადება ხატულის ქვეშ.
ოთხი ნებართვა ჩვეულებრივი მოთხოვნების მიღმა
VPN კონფიგურაციის შენახვა პირველია. macOS-ზე, აპს, რომელიც მშობლიურ Personal VPN API-ს იყენებს, კონფიგურაციის პირველ შენახვაზე მკაფიო ავტორიზაცია სჭირდება, ამიტომ დიალოგი ინსტალაციის დროს ჩნდება და არა დაკავშირებისას. უარი მას დაყენებულს ტოვებს, მაგრამ პროფილის შენახვას ვერ ახერხებს, და ეს აღდგენადი მდგომარეობაა.
Keychain მეორეა. კონკრეტული ერთეულის შენახული პაროლის მიღება ცალკე გადაწყვეტილებაა იმ სერვერის ნდობისგან, რომელიც მას მიიღებს. Firewall მესამეა და მისი აპის კონტროლი შემომავალ კავშირებს არეგულირებს, არა იმას, თუ რომელი ინტერფეისიდან გადის თქვენი ტრაფიკი. სრული დისკის წვდომა მეოთხეა და სწორედ ის გაიცემა არასწორი მიზეზებით.
| Prompt | What you are approving | What it does not prove |
|---|---|---|
| Save a VPN configuration | The configuration operation itself | That the gateway is legitimate or that the account works |
| Access a Keychain item | This component reading this credential | Trust in the server or access for other apps |
| Allow incoming connections | Traffic reaching the app from the network | That outgoing traffic uses the tunnel |
| Full Disk Access | Broad access to protected data | Anything about VPN configuration or login |
სრული დისკის წვდომა არასდროს არის VPN-ის შეკეთება
Apple-ის კონფიდენციალურობის ცნობარი სრულ დისკის წვდომას აღწერს როგორც ფართო წვდომას, რომელიც მოიცავს სხვა აპების მონაცემებს, სარეზერვო ასლებს და გარკვეულ ადმინისტრაციულ პარამეტრებს. Files & Folders უფრო ვიწრო, მდებარეობაზე დაფუძნებული კონტროლია, რომელიც ფაილების ლეგიტიმურ მოთხოვნილებათა უმეტესობას ფარავს.
ზოგიერთი უსაფრთხოების პროდუქტი ნამდვილად აღწერს ფუნქციას, რომელსაც ფართო წვდომა სჭირდება, და როცა ასეა, მოთხოვნამ კომპონენტი და გამოშვება უნდა დაასახელოს. რაც არ უნდა მიიღოთ, არის ქსელის კონფიგურაციის დიალოგზე დისკის ნებართვით პასუხი იმიტომ, რომ პირველი დიალოგი მუდამ ბრუნდებოდა.
ამ ორ ნებართვას ერთმანეთთან არაფერი აქვს. ერთის მიცემა მეორის ჩასახშობად გიტოვებთ მეტ გაცემულ წვდომას და იმავე გადაუჭრელ პრობლემას.
სახელმძღვანელო: რა ვქნათ მოულოდნელ მოთხოვნაზე
დაიწყეთ ზუსტი ფორმულირებისა და კომპონენტის სახელის ჩაწერით, და გადაიღეთ ეკრანის სურათი გადმოთქმის ნაცვლად. ფორმულირება გამოშვებებს შორის იცვლება და ზუსტი წინადადებაა ის, რასაც მომწოდებელი ან ადმინისტრატორი იცნობს. ეკრანის სურათი ასევე წყვეტს კამათს იმაზე, თუ რა თქვა დიალოგმა სინამდვილეში.
შემდეგ დაადგინეთ, რა ითხოვს. შეამოწმეთ აპის ვერსია და ვინ მოაწერა ხელი, და დაადასტურეთ, რომ ეს ის კლიენტია, რომელიც გგონიათ დაყენებული, და არა დამხმარე, განახლების პროგრამა ან წაშლილი პროდუქტის ნარჩენი.
გადაწყვიტეთ ერთი კითხვით: აქვს თუ არა ამ კომპონენტს ამ ვერსიაში ამ შესაძლებლობის დოკუმენტირებული საჭიროება? თუ მომწოდებლის დოკუმენტაცია ამას არ ამბობს, უარყავით მოთხოვნა და გაარკვიეთ, რატომ გამოჩნდა, რადგან აუხსნელი მოთხოვნა ინფორმაციაა და არა დაბრკოლება.
გადაწყვეტილების შემდეგ გაიმეორეთ ერთი ჩვეულებრივი დაკავშირების მცდელობა და ჩაიწერეთ, შეიცვალა თუ არა რამე. დაუკავშირებელი პრობლემის შუაგულში მიცემული ნებართვა მოგვიანებით ძნელი შესაფასებელია, ამიტომ თანმიმდევრობა ისეთივე მნიშვნელოვანია, როგორც პასუხი.
რატომ ბრუნდება იგივე მოთხოვნა
განმეორებადი ავტორიზაცია ჩვეულებრივ ნიშნავს, რომ გადაწყვეტილება არ ინახება იქ, სადაც კომპონენტი მას ელოდება, ერთეული გადაყენებამ ხელახლა შექმნა, ან მართვის პოლიტიკა აბრუნებს მას. ჩაიწერეთ, როდის ჩნდება: გაშვებისას, დაკავშირებისას, გათიშვისას ან გადატვირთვის შემდეგ. ეს დრო მიზეზს უფრო სწრაფად ავიწროებს, ვიდრე ნებისმიერი ჟურნალი, რომელსაც შემდეგ წაიკითხავთ.
მართულ Mac-ზე ფაქტობრივი პასუხი შეიძლება კონფიგურაციის პროფილიდან მოვიდეს და არა თქვენი დაწკაპუნებიდან; ამ შემთხვევაში დაშვების ხელახლა დაჭერა ვერაფერს გადაწყვეტს. ჰკითხეთ ადმინისტრატორს, რომელი პოლიტიკა მართავს ამ კომპონენტს, სანამ იმავე ღილაკს გააგრძელებთ დაჭერას.
თუ მოთხოვნა საიმედოდ მიჰყვება კონკრეტულ მოქმედებას, ეს გამოსადეგი შეცდომის მოხსენებაა. თუ შემთხვევით ჩნდება, ჩაწერეთ დროის ნიშნები ერთი დღის განმავლობაში და მოძებნეთ ნიმუში იმაში, თუ კიდევ რას აკეთებდა მანქანა.
დატოვეთ ჩანაწერი, რომელსაც სხვა გამოიყენებს
ჩაწერეთ კომპონენტი, შესაძლებლობა, მიზეზი და თარიღი იმავე ადგილას, სადაც კონფიგურაციის დანარჩენ ნაწილს ინახავთ. თქვენი მომავალი მე არ გაიხსენებს, რომელი დიალოგი რისთვის დამტკიცდა. ერთი სტრიქონი თითო ნებართვაზე საკმარისია; ინვენტარი, რომელსაც არავინ ინახავს, უარესია, ვიდრე არაფერი.
კარგი გადაწყვეტილების ტესტი აქ მარტივია: შეგიძლიათ ახსნათ, რატომ არსებობს ეს ნებართვა აპის გახსნის გარეშე? თუ არა, ეს გადასინჯვის კანდიდატია, და Apple-ის კონფიდენციალურობისა და უსაფრთხოების პარამეტრების ცნობარი არის ადგილი, საიდანაც დაიწყოთ კითხვა, თუ თითოეული მათგანი რას ფარავს სინამდვილეში.