Зваротны тэтэрынг 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:V
Запіс сеткі VPN у дампе злучэнняў паказвае, што служба перахопу актыўная; уласны журнал рэлея паказвае, ці прыходзяць патокі. Адсутнасць у адным з іх чыста раздзяляе праблему: няма перахопу — бок тэлефона, няма патокаў — бок хоста.
Браўзер, які працуе на хасце, даказвае шлях браўзера хоста, а не шлях працэсу рэлея. Параўнайце адрасы, якія паведамляе кожны з іх, і праверце прыватны рэсурс, а таксама публічную старонку, бо тунель толькі для прыватных сетак можа маршрутызаваць адно і не маршрутызаваць другое.
Згарніце ўстаноўку і выберыце паводзіны пры збоі
Адкат — частка інструкцыі. Спыніце і выдаліце рэлей, выдаліце кліент перахопу і адклічце аўтарызацыю адладкі хоста ў параметрах распрацоўніка на тэлефоне, калі задача завершана.
gnirehtet stop
gnirehtet uninstall
adb kill-server
Вырашыце, што тэлефон павінен рабіць, калі рэлей знікае. Без яўнага выбару ён можа перайсці на мабільныя даныя і зліць трафік, які вы спрабавалі накіраваць, таму свядома наладзьце паводзіны блакавання злучэнняў ці палітыку VPN і праверце згортванне, перш чым спадзявацца на яго.
Запішыце хост, які быў аўтарызаваны, версію рэлея, палітыку тунеля хоста і крокі згортвання. Менавіта гэты запіс робіць наступную ўстаноўку зваротнага тэтэрынгу паўторнай замест чарговага паўдня, выдаткаванага на паўторнае адкрыццё.