უკუ დაკავშირება Android-ისთვის USB-ით: ბრძანებები, შემოწმებები, დაბრუნება
უკუ დაკავშირება ტელეფონის ტრაფიკს ჰოსტის რელეზე გადასცემს. ააგეთ გზა ტელეფონიდან ჰოსტამდე, შეინარჩუნეთ ჰოსტის VPN მარყუჟში და შეამოწმეთ ყოველი ნახტომი.
უკუ დაკავშირება ტელეფონის ტრაფიკს კომპიუტერზე გადააქვს და იქიდან გამოჰყავს კომპიუტერის კავშირით. მხოლოდ USB კაბელი ამას არ აკეთებს: ტელეფონს სჭირდება დაჭერის სერვისი, რომელიც მის მარშრუტიზაციას იღებს, ხოლო კომპიუტერს — რელე, რომელიც ამ პაკეტებს შემდგომ მიიტანს. გზას ოთხი ნახტომი აქვს: აპლიკაცია, დაჭერა ტელეფონში, USB რელე და ჰოსტის გასასვლელი, და თითოეულს განსხვავებული მფლობელი ჰყავს. ეს სახელმძღვანელო ამ გზას აშენებს, ჰოსტის VPN-ს სათანადო ადგილას აყენებს და ყოველ ნახტომს ამოწმებს, სანამ შედეგს დაეყრდნობით.
რაიმეს გაშვებამდე ნახტომები რუკაზე დაიტანეთ
ყოველი ნახტომი თავის პოლიტიკას იყენებს, ამიტომ ერთ ბოლოში მომუშავე შედეგი მეორეზე არაფერს ამბობს. აპლიკაცია ირჩევს დანიშნულებას და გადამწყვეტს, დაჭერის სერვისი წყვეტს, რომელი ტრაფიკი შევა რელეში, რელე გადასცემს ჰოსტის სოკეტებს, ხოლო ჰოსტის მარშრუტიზაცია და VPN განსაზღვრავს მისამართს, რომელსაც დანიშნულება საბოლოოდ ხედავს.
| Hop | Owner | What it decides |
|---|---|---|
| Application request | The app | Destination, resolver, address family |
| Capture service | Phone VpnService app | Which traffic enters the relay at all |
| ADB relay | Host process | Forwarding phone flows to host sockets |
| Host egress | Host routing and VPN | Exit address and host policy |
ტელეფონის დაჭერის როლი ერთდროულად მხოლოდ ერთ VPN სერვისის კლიენტს შეიძლება ჰქონდეს, ამიტომ მეორე ჩვეულებრივი VPN აპი რელეზე არ ფენოვდება. თუ VPN კომპიუტერს ეკუთვნის, დაჭერის სერვისი ამ კომპიუტერისკენ მიმავალი წვდომის რგოლია და არა მტკიცება, რომ დისტანციური გვირაბი უკვე იცავს შედეგს.
რელე მოამზადეთ ტელეფონზე შეხებამდე
Gnirehtet ამ არქიტექტურის დოკუმენტირებული მაგალითია: VPN სერვისის კლიენტი root-ის გარეშე ტელეფონში და ADB-ით ჰოსტზე გადატანილი რელე, TCP-ისა და UDP-ის მხარდაჭერით IPv4-ზე. მისი საცავი ასევე ამბობს, რომ პროექტი აღარ აქტიურად მუშავდება, ამიტომ მას მიმართეთ როგორც საცნობარო დიზაინსა და ლაბორატორიისთვის მომუშავე ხელსაწყოს, და არა როგორც მხარდაჭერილ პროდუქტს, რომელიც მართულ პარკზე უნდა სტანდარტდეს.
adb devices
adb shell getprop ro.build.version.release
gnirehtet runჯერ adb devices გაუშვით. ტელეფონი, რომელსაც ჰოსტის გამართვის გასაღები არ მიუღია, არაუფლებამოსილად მოხსენდება და რელე არ შეერთდება, სანამ მოწყობილობაზე მოთხოვნა არ მიიღება. gnirehtet run აყენებს კლიენტს, უშვებს რელეს და რთავს დაჭერას; იმ ვერსიაში, სადაც ნაბიჯები გაყოფილია, ამის ნაცვლად გამოიყენეთ დოკუმენტირებული install, relay და start ქვებრძანებები.
ADB წვდომა მოწყობილობის კონტროლის ურთიერთობაა და არა ქსელის პარამეტრი. უფლება მიეცით მხოლოდ თქვენ მიერ კონტროლირებულ კომპიუტერს და დაგეგმეთ ამ უფლების გაუქმება დავალების დასრულებისას.
ჰოსტის VPN დააბრუნეთ გზაზე
რელე ჰოსტის ჩვეულებრივი პროცესია, ამიტომ მისი შემდგომი კავშირები ჰოსტის მარშრუტიზაციის ცხრილს მიჰყვება. სრული გვირაბის პროფილი მათ ატანს; გაყოფილი გვირაბი შეიძლება ვერა. თუ ჰოსტის VPN აპლიკაციების მიხედვით კონტროლს იყენებს, დაამატეთ რელეს ბინარი ნებადართულ სიმრავლეს, თორემ რელე განაგრძობს ფიზიკური ინტერფეისის გამოყენებას, სანამ ბრაუზერი დაცულად გამოიყურება.
ip route get 1.1.1.1
curl -4 https://ifconfig.me
sudo ss -tnp | grep -i relayგაუშვით პირველი ორი ბრძანება ჰოსტის VPN-ის მიერთებამდე და შემდეგ. თუ მისამართი არ იცვლება, რელე გვირაბზე არ არის, რაც არ უნდა თქვას კლიენტის ფანჯარამ. მხოლოდ კერძო გვირაბი საჯარო დანიშნულებებს ჰოსტის ჩვეულებრივ გასასვლელზე ტოვებს, რაც გაჟონვას ჰგავს, მაგრამ თქვენ მიერ დაყენებული პოლიტიკაა.
რელეზე გამავალი ტრაფიკისთვის DNS ჰოსტზე წყდება, ამიტომ ჰოსტის გადამწყვეტი განსაზღვრავს, რომელი სერვერი ხედავს სახელებს. ტელეფონზე კერძო DNS პარამეტრი რელეზე არ გადადის და ტელეფონის მხარეს გადამწყვეტის ტესტი ჰოსტის მოთხოვნებს არ აღწერს.
ყოველი ნახტომი ცალკე შეამოწმეთ
სამი შემოწმება ამ თანმიმდევრობით: ტელეფონი აღწევს რელეს, რელე აღწევს დანიშნულებას ჰოსტის პოლიტიკით, და აპლიკაცია სწორად წყვეტს და იყენებს ამ დანიშნულებას. გაჩერდით პირველ წარუმატებლობაზე, ნაცვლად გვერდების განახლებისა და გამოცნობისა.
adb shell dumpsys connectivity | grep -i -A3 vpn
adb logcat -s GnirehtetRelay:V Gnirehtet:VVPN ქსელის ჩანაწერი კავშირების გამონაბეჭდში აჩვენებს, რომ დაჭერის სერვისი აქტიურია; თავად რელეს ჟურნალი აჩვენებს, მოდის თუ არა ნაკადები. ერთ-ერთში არქონა პრობლემას სუფთად ჰყოფს: დაჭერა არ არის — ტელეფონის მხარე, ნაკადები არ არის — ჰოსტის მხარე.
ჰოსტზე მომუშავე ბრაუზერი ამტკიცებს ჰოსტის ბრაუზერის გზას და არა რელეს პროცესის გზას. შეადარეთ მისამართები, რომლებსაც თითოეული აცნობს, და გამოსცადეთ როგორც კერძო რესურსი, ისე საჯარო გვერდი, რადგან მხოლოდ კერძო გვირაბმა შეიძლება ერთი მარშრუტიზაცია და მეორე — არა.
დაშალეთ და აირჩიეთ წარუმატებლობის ქცევა
უკან დაბრუნება სახელმძღვანელოს ნაწილია. შეაჩერეთ და მოაცილეთ რელე, წაშალეთ დაჭერის კლიენტი და გააუქმეთ ჰოსტის გამართვის უფლება ტელეფონის დეველოპერის პარამეტრებიდან, როცა დავალება დასრულდება.
gnirehtet stop
gnirehtet uninstall
adb kill-serverგადაწყვიტეთ, რა უნდა გააკეთოს ტელეფონმა, როცა რელე გაქრება. გამოკვეთილი არჩევანის გარეშე მან შეიძლება მობილურ მონაცემებზე დაბრუნდეს და გააჟონოს ის ტრაფიკი, რომლის მარშრუტიზაციასაც ცდილობდით, ამიტომ კავშირების დაბლოკვის ქცევა ან VPN პოლიტიკა განზრახ დააყენეთ და დაშლა გამოსცადეთ, სანამ მას დაეყრდნობით.
ჩაწერეთ, რომელი ჰოსტი იქნა უფლებამოსილი, რელეს ვერსია, ჰოსტის გვირაბის პოლიტიკა და დაშლის ნაბიჯები. სწორედ ეს ჩანაწერი ხდის შემდეგ უკუ დაკავშირების კონფიგურაციას განმეორებადს, ნაცვლად კიდევ ერთი ხელახალი აღმოჩენის შუადღისა.