VPN ჰოსტზე თუ კლიენტი Genymotion-ის შიგნით: გადაწყვიტეთ, ვის ეკუთვნის გვირაბი

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

ორი გზა ერთ მანქანაზე

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

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

შეინარჩუნეთ მართვის კავშირი ცოცხალი

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

VBoxManage list hostonlyifs

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

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

ვარიანტი პირველი: დაე, ჰოსტმა ატაროს ტრაფიკი

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

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

ვარიანტი მეორე: გაუშვით მხარდაჭერილი კლიენტი Android-ის შიგნით

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

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

შეამოწმეთ აპიდან და ჩაწერეთ განლაგება

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

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