Изключено приложение все още онлайн? Правилата за приложения и маршрути се различават

Изключването на пакет е инструкция за маршрутизиране, а не блокиране, затова страниците, които се зареждат след свързване на 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 правила и таблици, и накрая тествайте второ приложение към същата дестинация. Второто приложение разделя избора на процес от избора на дестинация в една заявка.

Запишете резултата като приложение, дестинация и номер на таблица. Тази тройка е това, което следващата промяна трябва да запази.