რატომ წყდება Mac-ის VPN, როცა iPhone-ს USB-ით აერთებთ

თქვენ აერთებთ iPhone-ს დასატენად და ერთი წუთის შემდეგ Mac-ის VPN წყვეტს ტრაფიკის გატარებას. სისტემის პარამეტრები აჩვენებს ახალ სერვისს სახელით iPhone USB და აშკარა ნაბიჯია მისი წაშლა. ეს ნაბიჯი ხშირად მცდარია. სერვისი შეიძლება იყოს ტელეფონის პირადი ჰოთსპოტი, ან ბმული, რომელსაც Xcode და მოწყობილობის ხელსაწყოები იყენებენ ტელეფონთან სასაუბროდ, და ორივე საკმარისად განსხვავებულად იქცევა, რომ იდენტიფიკაცია წაშლამდე უნდა მოხდეს.

ნაბიჯი 1: წაიკითხეთ სერვისი, რომელიც ტელეფონმა რეალურად შექმნა

გახსენით სისტემის პარამეტრები, შემდეგ ქსელი და შეადარეთ სერვისების სია ტელეფონის გათიშული და მიერთებული მდგომარეობით. მიმდინარე macOS-ში სერვისი ჩამოთვლილია როგორც iPhone USB. დააკვირდით, არის თუ არა ის აქტიური, სად დგას სერვისების რიგში და იყენებს თუ არა Mac მას ნაგულისხმევი მარშრუტისთვის. სერვისების რიგს მნიშვნელობა აქვს, რადგან macOS ირჩევს უმაღლეს აქტიურ სერვისს, რომელსაც შეუძლია დანიშნულების ადგილამდე მისვლა, და არა იმას, რომლის სახელსაც იცნობთ.

Apple-ის პირადი ჰოთსპოტის სახელმძღვანელო აღწერს მექანიზმს: სანამ ტელეფონზე პირადი ჰოთსპოტი ჩართულია, USB-ით მიერთებამ შეიძლება აიძულოს Mac გამოიყენოს ტელეფონის მობილური კავშირი, მაშინაც კი, როცა მხოლოდ დატენვა გსურდათ. ეს VPN-კლიენტის ხარვეზი არ არის; მარშრუტიზაციის ცხრილი მიჰყვება სერვისს, რომელიც Wi-Fi-მდე აიწია.

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

ნაბიჯი 2: შეამოწმეთ, რომელ მარშრუტს იყენებს VPN-ის ბოლო წერტილი

წაიკითხეთ მარშრუტი VPN სერვერის ამოხსნილ მისამართამდე და არა ვებსაიტამდე. route -n get მხოლოდ-კითხვადია და ბეჭდავს ინტერფეისსა და კარიბჭეს, რომელსაც ბირთვი გამოიყენებდა, და ორივე სტრიქონი მნიშვნელოვანია.

scutil --dns | head -20
route -n get 203.0.113.10

ზემოთ მოცემული მისამართი დოკუმენტაციის ჩანაცვლებითია. შეცვალეთ იგი იმ ბოლო წერტილით, რომელსაც თქვენი კლიენტი აჩვენებს, და გამოიყენეთ route -n get -inet6 IPv6-ის ბოლო წერტილისთვის. შეადარეთ გამომავალი ტელეფონის გათიშული და მიერთებული მდგომარეობით და ორ წაკითხვას შორის მარშრუტები არ დაამატოთ და არ წაშალოთ. თუ ინტერფეისი en0-იდან iPhone USB-ის ინტერფეისში შეიცვალა, ჰოთსპოტის გზამ მოიგო ძებნა და VPN-ის გარე კავშირი ახლა მობილურ ქსელზე მიდის.

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

ნაბიჯი 3: გამოყავით ჰოთსპოტი მოწყობილობის კავშირის ბმულისგან

Xcode 15 და უფრო ახალი ვერსიები USB-ით მიერთებულ მოწყობილობას ესაუბრებიან ქსელურ არხზე, რომელიც მოიცავს ბმულ-ლოკალურ IPv6-ს, ამიტომ განვითარების Mac-მა შეიძლება აჩვენოს დამატებითი ინტერფეისი, რომელსაც ინტერნეტზე წვდომასთან კავშირი არ აქვს. Apple-ის ტექნიკური ჩანაწერი TN3158 ადასტურებს ამ ქცევას და აფრთხილებს, რომ VPN-მა ან უსაფრთხოების ფილტრაციამ შეიძლება ხელი შეუშალოს მას. ეს ჰოთსპოტის პრობლემის საპირისპიროა: VPN არ ფუჭდება იმიტომ, რომ ტელეფონი ინტერნეტს გვთავაზობს; მოწყობილობის კავშირი ფუჭდება იმიტომ, რომ VPN მას იჭერს.

ორი დაკვირვება ანაწილებს შემთხვევებს პაკეტების დაჭერის გარეშე. პირველ რიგში, შეამოწმეთ, აქვს თუ არა ინტერფეისს მარშრუტიზებადი მისამართი და ნაგულისხმევი მარშრუტი, თუ მხოლოდ ბმულ-ლოკალური fe80:: მისამართი; მხოლოდ ბმულ-ლოკალური ნიშნავს, რომ ინტერნეტის გზა არ არსებობს. მეორე, დახურეთ VPN და ნახეთ, შეუძლია თუ არა Xcode-ს კვლავ მოწყობილობამდე მისვლა. თუ შეუძლია, VPN-ის მარშრუტები ან შიგთავსის ფილტრი იჭერს ბმულ-ლოკალურ ტრაფიკს და შესწორება განეკუთვნება გაყოფილი გვირაბის ან ფილტრის კონფიგურაციას და არა ქსელის პანელს.

ifconfig | grep -A4 -E '^en[0-9]+:'
netstat -rn -f inet6 | head

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

ნაბიჯი 4: გაამეორეთ წარუმატებლობა ერთდროულად ერთი ცვლადით

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

თუ VPN მარცხდება მხოლოდ ჰოთსპოტის მდგომარეობაში, მოარიდეთ ტელეფონი ამ გზას: გამორთეთ პირადი ჰოთსპოტი დატენვის დროს, ან გადაიტანეთ iPhone USB სერვისი Wi-Fi-ის ქვემოთ სერვისების რიგში. თუ ის მარცხდება ყველა მიერთებულ მდგომარეობაში, ჰოთსპოტის გამორთვის შემთხვევაშიც, შეხედეთ, როგორ ამუშავებს კლიენტი ქსელის გადასვლას. ზოგი კლიენტი გვირაბს შლის, როცა ძირითადი სერვისი იცვლება და ხელახალი მიერთება სჭირდება; ეს კლიენტის ქცევაა და არა ტელეფონის ხარვეზი.

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

ნაბიჯი 5: გადაწყვიტეთ, რა შეინარჩუნოთ და რა გადაამოწმოთ

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

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

შემდეგ დაახარისხეთ წარუმატებლობა, რომელიც რეალურად ნახეთ. ხელის ჩამორთმევის დროის ამოწურვა, MTU-ის გაჩერება გვირაბის აწევის შემდეგ და ოპერატორისგან მომავალი DNS პასუხები სამი განსხვავებული პრობლემაა სამი განსხვავებული შესწორებით. USB სერვისი სამივეში გამომწვევია; მიზეზი იშვიათად.