როგორ რთავს Apple VPN On Demand-ის დომენური წესები გვირაბს
დომენური წესი მხოლოდ იმას წყვეტს, როდის იხსნება გვირაბი. როგორ მუშაობს connect-if-needed DNS პრობა, რატომ ირჩევს მარშრუტები ტრაფიკს და როგორ შევამოწმოთ პროფილი.
გვირაბი იხსნება, როცა ითხოვთ ერთ შიდა სახელს, და დახურული რჩება, როცა შემდეგ აპლიკაციას ის ისევე სჭირდება. ეს აპლიკაციის შეცდომა არ არის; ეს დომენური წესის ფორმაა. Apple-ის on-demand კონფიგურაცია აღწერს კავშირის დამყარების პირობებს, და ამ პირობების დომენური ფორმა სისტემის რეზოლვერს კითხვას უსვამს სანამ ერთი პაკეტიც კი გაიმოძრავებს. ორი კითხვა მუდმივად ერევა ერთმანეთს: როდის უნდა ამოვიდეს გვირაბი და რას ატარებს გვირაბი, როცა უკვე არსებობს. პირველი ტრიგერია, მეორე — მარშრუტებისა და რეზოლვერის პოლიტიკა, და ერთი პროფილი ჩვეულებრივ ორივეს ერთსა და იმავე payload-ში აყენებს, ამიტომ სწორ დომენურ წესს მაინც შეუძლია არასწორ ქსელში დაგტოვოს.
ტრიგერი და ტრაფიკის შერჩევა სხვადასხვა შრეშია
on-demand წესი ცხოვრობს VPN payload-ის on-demand ლექსიკონში: წესების დალაგებული სია, თითოეული მოქმედებითა და შესაბამისობის პირობების ნაკრებით. სისტემა აფასებს მათ, როცა კავშირი იცვლება ან როცა რაღაც ცდილობს ქსელამდე მისვლას, და მოქმედება წყვეტს, გვირაბი ამოვიდეს, შეფასდეს, გაითიშოს თუ უგულებელყოფილი იქნას. ეს ყველაფერი ხდება პლატფორმის ქსელურ შრეში, სანამ თქვენს აპლიკაციას socket ექნება.
რაც ამის შემდეგ ხდება, გასაღებების ცალკე ჯგუფია: გვირაბის IPv4 და IPv6 პარამეტრები, მისი ჩართული და გამორიცხული მარშრუტები, DNS სერვერების მისამართები და iOS-სა და iPadOS-ზე თითო აპლიკაციის რუკა, რომელიც წყვეტს, რომელ აპლიკაციებს შეუძლიათ გვირაბის გამოყენება. პროფილს შეუძლია ფართო ტრიგერი ვიწრო მარშრუტს შეუწყვილოს, ან ვიწრო ტრიგერი ნაგულისხმევ მარშრუტს. წაიკითხეთ მხოლოდ ერთი ნახევარი და მეორე ნახევარი გაუმართაობად გამოჩნდება.
მე მაქვს ლაბორატორიული პროფილი, რომელიც ერთვება, როცა შიდა დომენის ქვეშ რაღაც მოითხოვება, მაგრამ გვირაბში მხოლოდ ერთ /16-ს მიმართავს. ის აკეთებს ზუსტად იმას, რასაც მისი payload ამბობს, და ეს ისეთი პროფილია, რომელიც ბილეთებს წარმოშობს: ადამიანები ფიქრობენ, რომ დაკავშირებული გვირაბი ნიშნავს, რომ მათი ტრაფიკი მის შიგნითაა.
რას ეკითხება დომენური წესი რეზოლვერს
წესის დომენური ფორმა, რომელსაც ხშირად connect-if-needed-ს უწოდებენ, არ ამოწმებს პაკეტების payload-ს და არ აკვირდება URL-ებს. როცა სახელი იხსნება, სისტემა ადარებს მას წესში არსებულ დომენებს და შესაბამისობისას კითხულობს, შეიძლება თუ არა ამ სახელის ამოხსნა გვირაბის მიერ მოწოდებული DNS სერვერებით. თუ გვირაბის რეზოლვერი პასუხობს, სახელი შიდად ითვლება და კავშირი იწყება. თუ სამაგიეროდ ლოკალური რეზოლვერი პასუხობს, სახელი გარედ განიხილება და გვირაბი არ ჩნდება. Apple-ის განთავსების მიმოხილვა ამას აღწერს როგორც ქსელის აღმოჩენას და შემდეგ კავშირის შეფასებას.
ორი შედეგი გამომდინარეობს. პროფილმა უნდა დაასახელოს DNS სერვერები გვირაბის შიგნით; გვირაბის რეზოლვერის გარეშე დომენურ წესს შესადარებელი არაფერი აქვს, ამიტომ შეფასება ვერ მოგვცემს მოსალოდნელ შესაბამისობას. და ძიებამ სისტემის რეზოლვერამდე უნდა მიაღწიოს. აპლიკაცია ან ბრაუზერი, რომელიც საკუთარ დაშიფრულ DNS-ს უშვებს, ლოკალურად პასუხისმგებელი გაფართოება ან ლიტერალურ მისამართზე კავშირი არასოდეს წარმოქმნის იმ სახელის ამოხსნას, რომელსაც წესი ელოდა. ჩემი ერთ-ერთი ყველაზე გრძელი შუადღე დასრულდა, როცა აღმოვაჩინე, რომ გვირაბის წინა კლიენტი DNS over HTTPS-ს იყენებდა.
ქეშიც აშორებს ტრიგერს. უკვე ქეშში არსებულ სახელს შეიძლება უპასუხონ იმ პრობის გარეშე, რომელიც გვირაბს ამოიყვანდა, ამიტომ გუშინ მომუშავე წესი ვერ ხერხდება გადატვირთვის შემდეგ, ან მას შემდეგ, რაც გვირაბი ცოტა ხანი ზემოთ იყო. macOS-ზე sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder მდგომარეობას აბრუნებს; iOS-ზე თვითმფრინავის რეჟიმის ჩართვა-გამორთვა ან მოწყობილობის გადატვირთვა მოგცემთ შედარებით სუფთა დასაწყისს.
შესაბამისობის არე: სახელები, აპლიკაციები და ქსელები
დომენური შესაბამისობა ერთ-ერთი ტიპია რამდენიმედან. წესი შეიძლება შეესაბამებოდეს ინტერფეისის ტიპს (Wi-Fi, მობილური, Ethernet) და კონკრეტულ SSID-ს, ხოლო თითო აპლიკაციის ან Safari დომენის ჩანაწერები გვირაბს ერთ სამუშაო ნაკადს აბამს. ეს კავშირი ხსნის უცნაურ გამოცდილებას, როცა მხოლოდ ერთი აპლიკაცია იქცევა სხვაგვარად, ვიდრე ყველა დანარჩენი: სხვა აპლიკაციები გვირაბის არეს გარეთ არიან, ამიტომ აგრძელებენ ლოკალური გზის გამოყენებას მაშინაც, როცა გვირაბის ხატულა ამბობს, რომ დაკავშირებულია.
თანმიმდევრობა უფრო მნიშვნელოვანია, ვიდრე ადამიანები ელიან. წესები თანმიმდევრულად ფასდება და პირველი შესაბამისი იძლევა მოქმედებას, ამიტომ ვიწრო დომენური წესის ზემოთ მოთავსებული ფართო „დაუკავშირდი ნებისმიერ Wi-Fi-ს“ წესი ჩუმად გაიმარჯვებს და დომენურ წესს შეუმოწმებელს გახდის. სანამ დომენების სიას გადაწერთ, დაადასტურეთ, რომ არცერთ ადრინდელ წესს უკვე არ შეუსაბამია.
ამიტომ always-on მხოლოდ უფრო მკაცრი on-demand წესი არ არის. always-on-ის აღსრულება განთავსების ცალკე რეჟიმია საკუთარი ზედამხედველობისა და მართვის მოთხოვნებით; ის გვირაბს ღიად ინახავს და არ რეაგირებს სახელზე. თუ გჭირდებათ გვირაბი, რომელიც არასოდეს ვარდება, დომენური წესი არასწორი იარაღია.
გაუმართაობები, რომლებიც გატეხილ წესს ბაძავს
დომენური წესის არმუშაობის შესახებ შეტყობინებების უმეტესობა ხუთი ადგილიდან ერთ-ერთზე ხვდება, და მათგან მხოლოდ უკანასკნელია წესის ტექსტი.
| What you see | Layer | First check |
|---|---|---|
| Tunnel comes up, internal site still fails | route or resolver after connect | netstat -rn, scutil --dns |
| Tunnel never comes up for that name | trigger path | fresh lookup, cache flush, private DNS |
| Tunnel comes up for every app | scope, or an earlier rule | rule order, per-app mapping |
| Tunnel drops and will not return on the same Wi-Fi | interface or SSID match, admission | captive portal, SSID string, auth prompt |
| Tunnel returns after you disconnect it | profile ownership | profiles show |
Captive პორტალები ცალკე სტრიქონს იმსახურებენ, რადგან სასტუმროებისა და აეროპორტების Wi-Fi ზუსტად იმ ძიებას იჭერს, რომელზეც წესია დამოკიდებული. სანამ პორტალი მოწყობილობას შეუშვებს, გვირაბის DNS სერვერი მიუწვდომელია, პრობა ვერ ხერხდება, და გაუმართაობა არასწორად დაწერილ დომენს ჰგავს. აუთენტიფიკაცია მეორე ჩუმი შემთხვევაა: წესი შეიძლება ამოქმედდეს, გვირაბმა დაიწყოს დაკავშირება, და კავშირი მოკვდეს ვადაგასულ სერტიფიკატზე ან სხვა ეკრანზე გამოჩენილ მოთხოვნაზე.
IPv6 ქმნის ვარიანტს, რომლის არასწორი დიაგნოზი მარტივია. ორივე მისამართის ოჯახის მქონე სახელს შეიძლება პირველად AAAA ჩანაწერიდან უპასუხონ, მაშინ როცა გვირაბის მარშრუტების სია მხოლოდ IPv4-ს ატარებს. ერთი ბრაუზერი წარმატებით სრულდება, მეორე ვერ ხერხდება, და დომენების სია სრულიად უდანაშაულოა.
გამოსცადეთ რეალური მოთხოვნით, ამ თანმიმდევრობით
წაიკითხეთ პოლიტიკა სანამ გამოიცნობთ. macOS-ზე sudo profiles show -type configuration ბეჭდავს დაყენებულ პროფილებს VPN payload-ის ჩათვლით, scutil --nc list აჩვენებს სერვისის მდგომარეობას, და scutil --nc show <service> ბეჭდავს on-demand ლექსიკონს, რომელსაც სისტემა იყენებს. მართულ iPhone-სა ან iPad-ზე იგივე payload მოდის მართვის კონსოლიდან ან MDM ანგარიშიდან. ქსელური ჟურნალები ხელმისაწვდომია log stream --predicate 'subsystem == "com.apple.networkextension"'-ით macOS-ზე, და მოწყობილობის კონსოლის მეშვეობით, როცა ტელეფონი მიერთებულია.
შემდეგ გამოსცადეთ ჰოსტის სახელით, რომელიც სესიაში ადრე არ გამოგიკითხავთ. აირჩიეთ სახელი გვირაბის DNS ზონაში, რომელიც იცით, რომ შიდად იხსნება, მოითხოვეთ ერთხელ და დააკვირდით, გამოჩნდება თუ არა გვირაბი. გაუშვით იგივე ძიება ორჯერ: მეორე ცდა ქეშის გზას ვარჯიშობს, და ორივეს შორის სხვაობა გეტყვით, ტრიგერი ამოხსნაა თუ მარშრუტიზაცია.
მას შემდეგ რაც გვირაბი ამოვა, გადაამოწმეთ ორი შრე ცალ-ცალკე. netstat -rn -f inet და netstat -rn -f inet6 აჩვენებენ, საით მიუთითებს თითოეული პრეფიქსი, scutil --dns აჩვენებს რეზოლვერების რიგს და რომელი ინტერფეისი ფლობს თითოეულ რეზოლვერს, ხოლო nettop -m route აჩვენებს, რომელმა ინტერფეისმა გადაიტანა ბაიტები. თუ გვირაბი ზემოთაა და რეზოლვერი სწორია, მაგრამ რესურსი მაინც ვერ ხერხდება, შეწყვიტეთ წესის რედაქტირება; შეამოწმეთ სერვერის მხრიდან ავტორიზაცია და დაბრუნების მარშრუტი.
როცა წესი სხვას ეკუთვნის
თუ გვირაბი გათიშვის შემდეგ ისევ ჩნდება, წესი ჩვეულებრივ პროფილს ეკუთვნის და არა აპლიკაციას: MDM-ით გაგზავნილი კონფიგურაცია, დარჩენილი პირადი პროფილი ან სხვა კლიენტის მიერ დაყენებული პროფილი. sudo profiles show -type configuration და on-demand გასაღებების ძიება შეავიწროებს მას, და მოხსნის გზა პროფილია, და არა მენიუს ზოლის გადამრთველი. სერვისის ჩანაწერის ან აპლიკაციის წაშლა წესს ტოვებს, და შემდეგი ინსტალაცია ისევ მემკვიდრეობით იღებს.
ერთი ტესტი წყვეტს მფლობელობას: გათიშეთ, დაელოდეთ, კვლავ მოითხოვეთ შიდა სახელი. თუ გვირაბი დაბრუნდა, ტრიგერი დიზაინისამებრ მუშაობს და ღია კითხვაა, ვინ მართავს მას და არის თუ არა ეს არე ის, რაც გსურთ.
სანამ ამას შეცდომად შეატყობინებთ, გაიარეთ იგივე ხუთი შემოწმება: გვირაბის რეზოლვერის მისამართები payload-ში არსებობს, სახელი ქეშში არ იყო, არცერთ ადრინდელ წესს უკვე არ შეუსაბამია, მარშრუტების სია ფარავს AAAA გზას, და აპლიკაცია გვირაბის არეშია. როცა ხუთივე სწორია, წესი თავის საქმეს აკეთებს და ხარვეზი გზაზე უფრო შორსაა.