Apple IncludeAllNetworks: რა მაინც გვივლის VPN-ს

თქვენ ხსნით პროფილს MDM-ის კონსოლში, ხედავთ მონიშნულ IncludeAllNetworks-ს და ვარაუდობთ, რომ ამ მოწყობილობის ყოველი პაკეტი ახლა გვირაბში შედის. Apple-ის საკუთარი სქემა ამას არ გვპირდება. პარამეტრი ტრაფიკს VPN-ის გავლით მართავს გამონაკლისებით, რომელთაგან ზოგი არასავალდებულო გადამრთველია, ზოგი კი აუცილებელია, რომ სისტემა საერთოდ მუშაობდეს. ქვემოთ მოცემული განხილვა ამ დოკუმენტს პროფილიდან გარეთ მიჰყვება, ასე რომ, პირველი, რასაც კითხულობთ, თავად პარამეტრია და არა ჩანაწერი მოწყობილობიდან, რომელიც ჯერ არავის ამოუცნია.

ამ გამონაკლისებიდან ორი ხსნის არეულობის უმეტეს ნაწილს და ორივე უჯრედულ სერვისს ეხება.

დაიწყეთ მართული პროფილიდან და არა ჩანაწერიდან

გახსენით მართული VPN პროფილის სქემა და წაიკითხეთ თვისების აღწერა, სანამ რომელიმე პაკეტის ჟურნალს წაიკითხავთ. გაითვალისწინეთ, რომ აღწერა გამონაკლისებით მარშრუტიზაციას ეხება და არა სრული გვირაბის გარანტიას. სწორედ ეს ერთი წინადადება წყვეტს, როგორ განმარტავთ ყველაფერს, რასაც შემდეგ ნახავთ.

კონსოლში ყოფნისას ჩაიწერეთ სამი რამ: პარამეტრის მატარებელი დატვირთვის იდენტიფიკატორი, მოწყობილობაზე მართული ოპერაციული სისტემის ვერსია და რომელი VPN-ის იმპლემენტაციაა რეალურად დაყენებული. ის, რომ გასაღები დოკუმენტაციაშია აღწერილი, არაფერს ამბობს იმაზე, აჩვენებს თუ არა მესამე მხარის კლიენტი მას საკუთარ კონფიგურაციის ინტერფეისში.

უჯრედული გამონაკლისი წაიკითხეთ როგორც ორი განსხვავებული შემთხვევა

მხარდაჭერილ კონფიგურაციებში ExcludeCellularServices გამორიცხავს ინტერნეტით მარშრუტიზებად უჯრედულ სერვისულ ტრაფიკს, მაგრამ მხოლოდ მაშინ, როცა ის IncludeAllNetworks-თან ერთად არის ჩართული. სქემა ამ კატეგორიის მაგალითებად ასახელებს Wi-Fi Calling-ს, IMS-ს და შეტყობინებებთან დაკავშირებულ სერვისებს. ეს ნაკადები დიზაინის მიხედვით შეიძლება გვირაბიდან გავიდეს და პროფილის არც ერთი გადახედვა არ გაატარებს მათ მასში, სანამ გამონაკლისი ჩართულია.

მეორე შემთხვევა ცალკეა და არც ერთ გადამრთველზე არ არის დამოკიდებული. ზოგიერთი ოპერატორი უჯრედულ სერვისებს პირდაპირ საკუთარი ქსელით აწვდის და არა ინტერნეტით, და Apple ამ კატეგორიას დოკუმენტირებს როგორც გვირაბიდან ყოველთვის გამორიცხულს. ეს არ არის ზემოთ აღწერილი პირობითი ინტერნეტით მარშრუტიზებადი შემთხვევა, ამიტომ ყველა გამონაკლისის უჯრის გასუფთავებული პროფილიც კი ვერ დაიჭერს მას. ორივეს ერთ თვისებად მოპყრობა ის ადგილია, საიდანაც იწყება დავა გაჟონვაზე.

თუ თქვენი მოთხოვნა სიტყვასიტყვით არის, რომ არც ერთი პაკეტი არასოდეს დატოვოს გვირაბი, ეს მეორე შემთხვევა უკვე შეუძლებელს ხდის ამ მოთხოვნას უჯრედულ მოწყობილობაზე. ეს უნდა იცოდეთ დიზაინის გადახედვამდე და არა შემდეგ.

შეამოწმეთ, რომელ გასაღებებს ამჟღავნებს თქვენი პლატფორმა

სქემა ასევე აღწერს საჭირო ქსელური კავშირისა და captive ქსელების ტრაფიკს, ასევე ცალკე კონტროლს სხვა კატეგორიებისთვის, როგორიცაა ლოკალური ქსელები და მოწყობილობათა შორის კავშირი. ეს დოკუმენტირებული კონფიგურაციის ურთიერთობებია და არა თქვენი მოწყობილობის დაკვირვებები. დაადასტურეთ თითოეული თქვენს მიერ მართულ ოპერაციული სისტემის ვერსიასთან, რადგან ხელმისაწვდომობა ვერსიებს შორის იცვლება და ჩუმად უგულებელყოფილი პროფილის გასაღები ზუსტად ისე გამოიყურება, როგორც საკუთარ საქმეს ასრულებელი გასაღები.

ამ გადაწყვეტილების მინიმალური დატვირთვა ჩვეულებრივ ასე გამოიყურება, უჯრედული დროშის ცხადად მითითებით და არა შაბლონიდან მემკვიდრეობით:

<key>IncludeAllNetworks</key><true/>
<key>ExcludeCellularServices</key><true/>
<key>ExcludeLocalNetworks</key><true/>

თუ მიწოდებულ პროფილში რომელიმე გასაღები აკლია, მოწყობილობა უბრუნდება ამ გასაღების ნაგულისხმევ მნიშვნელობას, რომელიც შესაძლოა არ იყოს ის მნიშვნელობა, რაც შაბლონის ავტორს ჰქონდა მხედველობაში. შეადარეთ მიწოდებული დატვირთვა შაბლონს და ნუ წაიკითხავთ მხოლოდ შაბლონს.

გაარკვიეთ, რა არის უცნობი ჰოსტის სახელი

როცა საეჭვო სახელი ჩნდება, დაადგინეთ, რას წარმოადგენს დაკვირვება სინამდვილეში: სისტემის მოთხოვნილი სახელი, პასუხისმგებელი გადამწყვეტი, კავშირის დანიშნულება თუ ხელსაწყოს მიერ დაბეჭდილი იარლიყი. ოპერატორთან დაკავშირებული სახელი თავისთავად არ განსაზღვრავს არც წყარო პროცესს და არც გამოყენებულ გამონაკლისს. მისი დევნა გვერდის ავლის მტკიცებულებად არის ის გზა, რომლითაც მხარდაჭერის თემა კვირას არასწორ ფენაზე ატარებს.

გამოიყენეთ მხარდაჭერილი დიაგნოსტიკა და ესაუბრეთ პროფილის მფლობელ ადმინისტრატორს, შემდეგ შეადარეთ ნაკადი განზრახ პოლიტიკას. სწორედ ეს შედარება და არა ჰოსტის სახელი გეუბნებათ, მოსალოდნელი იყო თუ არა ტრაფიკი.

მოაგვარეთ მოთხოვნა და ნუ დაასუსტებთ სისტემას

ნუ დააყენებთ აუხსნელ ძირეულ სერტიფიკატს და ნუ გამორთავთ სისტემურ სერვისებს მხოლოდ იმისთვის, რომ ჩანაწერი უფრო წყნარი გახდეს. ჩანაწერის დაწყნარება აშორებს მტკიცებულებას და გამონაკლისს ადგილზე ტოვებს, რაც უარესი დასასრულია, ვიდრე თავდაპირველი კითხვა. თუ შესაბამისობის წესი კრძალავს კატეგორიას, რომელსაც პლატფორმა განზრახ გამორიცხავს, ეს კონფლიქტი მიიტანეთ მოწყობილობისა და ქსელის მფლობელებთან სქემის განყოფილების ხელში.

დახურეთ განხილვა იმის ჩაწერით, რომელმა გამონაკლისმა ახსნა ტრაფიკი, რომელ ოპერაციული სისტემის ვერსიას ეხება და რომელმა პროფილის მნიშვნელობამ შექმნა ის. კავშირის ხატულა ვერ შეარიგებს ორ შეუთავსებელ ვარაუდს იმის შესახებ, რამდენად ვრცელდება ოპერაციული სისტემის ტრაფიკის არეალი.