Виключений застосунок усе ще онлайн? Правила для застосунків і маршрутів різні

Виключення пакета — це вказівка маршрутизації, а не блокування, тому сторінки, які завантажуються після підключення 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 і таблиці, а останнім перевірте другий застосунок на тому самому призначенні. Другий застосунок розділяє вибір процесу й вибір призначення в одному запиті.

Запишіть результат як застосунок, призначення й номер таблиці. Саме цю трійку має зберегти наступна зміна.