Защо трафикът на безжичното отстраняване на грешки не доказва изтичане през VPN

Включихте безжично отстраняване на грешки, свързахте лаптоп и сесията продължи да работи, докато VPN беше активен. Това изглежда така, сякаш нещо се е промъкнало покрай тунела. Почти сигурно не е. Сесията за отстраняване на грешки и заявката на приложение към уебсайт са различни мрежови връзки и само една от тях трябва да преминава през тунела.

Сблъсквал съм се с това погрешно четене два пъти: веднъж с телефона и лаптопа в една и съща Wi-Fi мрежа и веднъж след рестарт, при който сдвояването беше запазено. И в двата случая VPN вършеше точно това, за което беше настроен.

Назовавайте наблюдението, преди да назовавате дефекта

Преди твърдение за изтичане могат да се случат три събития и те не са взаимозаменяеми. Инструмент може да открие услуга, устройството може да одобри работна станция или оторизирана сесия може действително да пренася команди и байтове. Запишете кое точно сте видели, защото всяко от тях доказва по-малко, отколкото хората предполагат.

Откриването обикновено е mDNS или сканиране на портове. Сдвояването е решение за регистрация, взето на телефона и потвърдено с код, който потребителят въвежда. Живата сесия означава, че трафикът е преминал между две сдвоени крайни точки. Нищо от това не описва накъде отива HTTPS заявката на приложението.

Дръжте дестинацията, интерфейса, семейството адреси, времевата марка и потребителския профил прикрепени към събитието. Без тези подробности наблюдението не може да се сравни с предвидената политика за локалната мрежа или с версията на VPN, която е работела тогава.

Защо двата пътя никога не се срещат

Безжичното отстраняване на грешки е входяща връзка към устройството. adbd слуша на порт, обвързан с Wi-Fi интерфейса, и работната станция се свързва с него след сдвояване. Посоката е важна: лаптопът достига до телефона, а не обратното. Това е обратното на изтичане на изход.

Интернет трафикът на приложението излиза през тунелния интерфейс, който VpnService инсталира, съпоставен по UID и правила за маршрутизиране. adbd е системен демон, работещ като потребител shell, а не приложение в този набор от маршрути. Той остава на подлежащата Wi-Fi връзка дори когато всяко приложение е закрепено към тунела.

Режимът на заключване налага тунела за обхванатите приложения. Той не превръща слушащия сокет в път за изход.

Затова работеща сесия на ADB и работещ превключвател за убиване съществуват заедно без противоречие. За да докажете изтичане, трябва да наблюдавате посоката, която би трябвало да е блокирана.

Как всъщност изглежда тест за изход

Тествайте обхванатото приложение, а не канала за отстраняване на грешки. Създайте умишлено условието за отказ, след което направете една нова заявка и запишете какво се случи.

1. Потвърдете, че VPN е единственият път: включете постоянно включен VPN със блокиране на връзките без VPN.
2. Спрете VPN по поддържания начин и потвърдете, че приложението съобщава липса на свързаност.
3. Изпратете една безвредна заявка от това приложение и отбележете дали се проваля, или успява.
4. Повторете с включено, после изключено безжично отстраняване на грешки, за да изолирате променливата.

Блокирана заявка при тези условия е доказателство. Успешна сесия на ADB не е, както и един ping от терминално приложение.

Ако заявката все пак успее, докато заключването е включено, запишете UID на приложението и разрешението му за VPN, активната мрежа и версията на клиента. Тази комбинация е истинска находка.

Сдвояването надживява сесията

Сдвояването е трайно състояние, а не ръкостискане, за което може да забравите след теста с кабела. Документацията на Android за отстраняване на грешки описва безжичния работен процес и отбелязва, че връзката продължава, докато не бъде изрично забравена или оторизациите не бъдат отменени.

Проверете какво все още е оторизирано, преди да обвинявате тунела. Отворете Безжично отстраняване на грешки, погледнете Сдвоени устройства и забравете всичко, което вече не разпознавате. Изпълнете adb devices от работната станция, за да видите кои записи още отговарят, и adb disconnect, за да изхвърлите остарял. Изключването на безжичното отстраняване на грешки затваря изцяло слушащия порт.

В споделена или ненадеждна мрежа го оставете изключено. Трайна оторизация в мрежа, която не контролирате, е по-голям проблем от хипотетично заобикаляне на TUN.

Преди да докладвате този дефект

Полезният доклад назовава точната граница, която се е провалила. Включете модела на устройството и версията на Android, VPN клиента и версията, дали заключването е било включено, пакета на приложението и UID, както и мрежата, в която е бил телефонът. Добавете командата или заявката, предизвикала наблюдението, плюс времето, когато се е случило. Без това никой не може да възпроизведе границата, която твърдите, че е счупена.

Не изключвайте налагането и не излагайте отстраняването на грешки в ненадеждна мрежа, за да направите теста по-драматичен. Това променя системата, която измервате, и оставя доказателства, които никой не може да повтори.

Ако единственото ви доказателство е, че ADB се е свързал, докато VPN е бил включен, сте измерили грешния път. Първо повторете теста на ниво приложение; отговорът обикновено идва там.