Выключаны дадатак усё яшчэ ў сетцы? Правілы для дадаткаў і маршрутаў розныя

Выключэнне пакета — гэта ўказанне маршрутызацыі, а не блакаванне, таму старонкі, якія загружаюцца пасля падключэння VPN, — гэта чаканае, а не доказ збою. Выключэнне прыбірае дадатак з тунэля замест таго, каб блакаваць яго, і звычайная сетка нясе яго трафік. Тут сустракаюцца дзве асобныя палітыкі: адна выбірае працэсы, другая — прызначэнні. Чытанне іх у гэтым парадку тлумачыць, чаму падключаная іконка і працуючы дадатак не з'яўляюцца супярэчнасцю.

Чаму выключэнне пакідае сетку адкрытай

VpnService.Builder прымае альбо белы спіс, альбо чорны спіс, ніколі абодва. Пакеты з белага спісу — адзіныя, што ідуць праз тунэль. Чорны спіс перавяртае гэта: кожны пакет, акрамя пазначаных, выкарыстоўвае тунэль, а пазначаныя захоўваюць фізічны шлях. Пакет, не пазначаны ў белым спісе, таксама па-за тунэлем, таму выключэнне — звычайны стан для большасці дадаткаў у гэтым рэжыме.

Гэта робіць лакальны запіс у чорным спісе рашэннем маршрутызацыі, а не правілам файрвола. Калі патрабаванне — спыніць доступ дадатка да хоста, тунэль павінен ахапіць яго, а сервер або лакальная палітыка — адхіліць трафік. Выдаленне дадатка з тунэля змяняе толькі тое, які інтэрфейс нясе яго пакеты.

Выпадак Play Store — звычайны наўмысны прыклад. Выключэнне пакета крамы дазваляе загрузкам выкарыстоўваць базавае злучэнне, калі выхад VPN замінае перадачы, і паказвае, што выключэнне азначае абыход, а не блакаванне.

Адзін профіль — адзін спіс

Канструктар выдае памылку, калі выкарыстаны абодва выклікі, таму профіль перад вамі — альбо белы, альбо чорны спіс. Гэты адзіны факт вызначае, як чытаць кожнае наступнае назіранне. Праверце код або кіраваную канфігурацыю перад табліцай маршрутызацыі, бо спіс вырашае, што значыць астатні вывад. Гібрыдны профіль — не той стан, які можна назіраць.

Адрозненне таксама прадказвае, што зробіць нядаўна ўсталяваны дадатак. У белым спісе ён застаецца звонку, пакуль хтосьці яго не дадасць, а ў чорным — далучаецца да тунэля па змаўчанні.

Кіраваныя канфігурацыі паказваюць той жа выбар пад рознымі назвамі ключоў, і некаторыя кансолі апісваюць яго як рэжым VPN для кожнага дадатка, а не як спіс. Паводзіны ўсё роўна зводзяцца да тых двух выклікаў, таму прасачыце наладку назад да спісу пакетаў, а не давярайце этыкетцы. Калі этыкетка і спіс супярэчаць, перамагае спіс.

Ідзіце ад правіла UID да табліцы тунэля

Android дае кожнаму дадатку ўласны Linux-ідэнтыфікатар карыстальніка, а служба VPN усталёўвае правілы палітыкі, што адпавядаюць дыяпазонам UID. Адпаведны трафік накіроўваецца ў табліцу маршрутызацыі, маршрут па змаўчанні якой паказвае на прыладу tun. Нумар табліцы выдзяляецца для кожнага асобніка VPN, таму ён змяняецца пасля перападключэння або стварэння другога профілю VPN.

Вывад правілаў — гэта карта. Кожны радок называе табліцу пошуку, і гэтая табліца ўтрымлівае маршрут па змаўчанні, які вырашае, ці ўваходзяць адпаведныя пакеты ў тунэль.

adb shell ip rule show
adb shell ip route show table all
adb shell cmd package list packages -U | grep <package>

Спачатку выканайце трэцюю каманду, каб атрымаць UID, потым знайдзіце правіла, дыяпазон якога ўтрымлівае яго. Гэтае правіла паказвае на нумар табліцы, і ip route show table <n> з гэтым нумарам пакажа, ці існуе маршрут па змаўчанні праз прыладу tun. Калі ў табліцы няма маршруту па змаўчанні, дадатак выбраны, але не мае шляху, а гэта іншы збой.

Гэтыя каманды патрабуюць зборкі з магчымасцю адладкі або прылады, дзе adb shell можа чытаць стан сеткі. На серыйным тэлефоне менеджэр пакетаў усё яшчэ адказвае, але праверка маршрутызацыі можа быць адхілена, таму запішыце тое, што можаце, і лічыце астатняе неправераным.

Маршрут заяўляе прэфікс, а не дадатак

Builder.addRoute заяўляе прэфіксы прызначэння для тунэля. Профіль, які дадае толькі 10.0.0.0/8 накіроўвае гэты прэфікс праз тунэль і пакідае кожнае іншае прызначэнне на фізічным шляху. Гэта звычайнае раздзеленае тунэляванне, і яно не залежыць ад таго, якія дадаткі выбралі правілы.

Канфігурацыя, прасунутая серверам, адлюстроўвае тую ж мадэль. Асобныя прасоўванні маршрутаў дадаюць прэфіксы, а дырэктыва redirect-gateway замяняе маршрут па змаўчанні і захоплівае ўсё для дадаткаў, якія ахоплівае тунэль. Выдаленне гэтай дырэктывы можа сціснуць працоўны тунэль да адной падсеткі без змен на прыладзе.

Прасунуты маршрут з незвычайным шлюзам або метрычным удакладняльнікам таксама можа не ўсталявацца. Аддайце перавагу звычайнай форме прэфікса і дазвольце серверу займацца перасылкай і NAT.

Прачытайце перасячэнне, перш чым змяніць наладку

Тунэль нясе перасячэнне ахопленых працэсаў і заяўленых прызначэнняў. Ахоплены дадатак, які запытвае адрас па-за апублікаванымі прэфіксамі, выходзіць праз фізічную сетку. Забаронены пакет застаецца звонку, нават калі запытвае адрас унутры гэтых прэфіксаў. Ні адзін выпадак не з'яўляецца памылкай; абодва — гэта дзве палітыкі, што робяць сваю працу.

VPN для кожнага дадатка таксама можа пакінуць злучаны дадатак без сувязі. Калі on-demand выключаны, а тунэль не працуе, дадатак застаецца прывязаным да VPN для асобнага дадатка і не мае запаснога шляху, што выглядае як зламаны дадатак, а не як стан палітыкі. Уключэнне on-demand або выдаленне сувязі праз кіраванне змяняе гэта.

Дыягнастуйце па адной восі за раз. Спачатку пацвердзіце дазвол або забарону, другім — прачытайце ўсталяваныя правілы UID і табліцы, апошнім — праверце другі дадатак на тым жа прызначэнні. Другі дадатак аддзяляе выбар працэсу ад выбару прызначэння ў адным запыце.

Запішыце вынік як дадатак, прызначэнне і нумар табліцы. Менавіта гэты картэж павінна захаваць наступная змена.