რატომ უსადენო გამართვის ტრაფიკი VPN-ის გაჟონვის მტკიცებულება არ არის

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

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

დაასახელეთ დაკვირვება, სანამ შეცდომას დაასახელებთ

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

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

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

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

უსადენო გამართვა მოწყობილობაში შემავალი კავშირია. adbd უსმენს Wi-Fi ინტერფეისზე მიბმულ პორტს და სამუშაო სადგური დაწყვილების შემდეგ უკავშირდება მას. მიმართულებას მნიშვნელობა აქვს: თქვენი ლეპტოპი ტელეფონში შედის და არა პირიქით. ეს გასვლითი გაჟონვის საპირისპიროა.

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

ჩაკეტვის რეჟიმი გვირაბს ავალდებულებს დაფარული აპებისთვის. ის მოსმენის სოკეტს გასვლის გზად არ აქცევს.

ამიტომ სამუშაო ADB სესია და სამუშაო გამომრთველი წინააღმდეგობის გარეშე თანაარსებობენ. გაჟონვის დასამტკიცებლად უნდა დააკვირდეთ იმ მიმართულებას, რომელიც უნდა იყოს დაბლოკილი.

როგორ გამოიყურება სინამდვილეში გასვლის ტესტი

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

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

დაბლოკილი მოთხოვნა ამ პირობებში მტკიცებულებაა. წარმატებული ADB სესია არა, და ერთი ping ტერმინალის აპიდანაც არა.

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

დაწყვილება სესიაზე დიდხანს ცოცხლობს

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

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

საზიარო ან არასანდო ქსელში გამორთული დატოვეთ. მუდმივი ავტორიზაცია ქსელში, რომელსაც არ აკონტროლებთ, უფრო დიდი პრობლემაა, ვიდრე ჰიპოთეტური TUN-ის გვერდის ავლა.

სანამ ამ შეცდომას შეატყობინებთ

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

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

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