VPN засяда на Connecting в режим „самолет“: намерете връзката нагоре
Клиент, който в режим „самолет“ остава на Connecting, може просто да няма връзка нагоре. Разделете състоянието на радиото, асоциирането, влизането през портала и блокиращата политика.
Телефонът показва иконата на самолет, VPN клиентът е на Connecting от две минути, а профилът е правилен. Преди час работеше в същата сграда. Нищо не е счупено: VPN е връзка, пренасяна от друга мрежа, а режимът „самолет“ просто премахна мрежата, която я пренасяше. Клиентът продължава да опитва, защото това прави без връзка нагоре.
Объркващото е, че иконата на самолет не ви казва дали Wi-Fi е наличен, а Connecting не ви казва дали клиентът се автентикира, или само чака. Разделете тези две четения и диагностиката отнема минута.
Иконата на самолет не е отчет за радиото
На поддържаните устройства с Android Wi-Fi и Bluetooth могат да останат включени в режим „самолет“, а устройството помни избора, който сте направили последния път. Указанията на Google за режим „самолет“ на Pixel описват точно това поведение. Така че иконата може да означава, че клетъчната мрежа е изключена, и нищо друго.
Проверете действителното състояние, а не глифа. adb shell settings get global airplane_mode_on връща 0 или 1 за самия режим, а adb shell dumpsys connectivity изброява мрежите, които устройството има в момента, със статуса им за валидиране. Тези два изхода заедно отговарят на въпроса, на който иконата не може.
Ако Wi-Fi е изключен или е включен, но не е асоцииран с нищо, няма път до крайната точка на VPN и никакво пресвързване няма да го създаде. Този случай си струва да се изключи първи, защото е единственият, при който правилното решение е извън VPN приложението.
Какво всъщност означава Connecting
Клиентът може да държи запазен профил, да показва името му и да върти индикатор, без да се е свързал с нищо. Конфигурацията е локална. Изграждането на тунел изисква достъпен сървър, завършено ръкостискане и интерфейс за маршрутизиране. Само последната част се нуждае от работеща мрежа, поради което първите две могат да изглеждат успешни при изключено радио.
Затова индикаторът е съвместим с поне три различни ситуации: никаква връзка нагоре, връзка нагоре, която не може да достигне крайната точка, и връзка нагоре, която я достига, но се проваля при автентикация. На екрана изглеждат еднакво, а в журнала — напълно различно. Затова първият полезен артефакт във всеки от тези случаи е журналът, а не нов опит.
Собствената документация на Android за VPN прави същото разграничение между установяването на връзка и отделните политики за постоянна връзка и блокиране. Това разделение е причината телефонът да изглежда защитен, докато е офлайн, и въпреки това да няма тунел.
Четири състояния, които си струва да различавате
Четирите състояния по-долу си струва да бъдат назовани, защото екранът ги показва по един и същ начин.
| State | What you will see | What to do |
|---|---|---|
| Airplane mode, Wi-Fi off | No networks in dumpsys, VPN retries forever | Turn Wi-Fi on, or accept that the tunnel cannot exist |
| Wi-Fi on, not associated | Interface exists, no default network | Join the access point |
| Associated, not validated | Network listed, captive-portal flag set | Complete the portal sign-in, then reconnect |
| Validated, tunnel down | Internet works, VPN fails or blocks | Debug the tunnel, not the radio |
Третият ред хваща повечето хора в хотели и летища. Асоциирането не е допускане: портал, който не е пуснал телефона, с удоволствие ще приеме паролата за Wi-Fi и след това ще откаже да пропусне трафик към крайната точка на VPN. Влизането първо през браузъра, докато тунелът е изключен, обикновено е единственият път.
Защо блокирането го прави по-лошо
Ако постоянният VPN и блокирането на връзки без VPN са включени едновременно, всяко обхванато приложение се блокира, когато тунелът не е вдигнат. Това е функцията, която работи, а не втора повреда. Симптомът се променя от провал на едно приложение до провал на всичко, което се чете като много по-голям проблем.
Това също обяснява последователността, която хората разчитат погрешно: режим „самолет“ включен, няма връзка нагоре, приложенията са блокирани, VPN казва connecting. Блокирането беше политиката, която си върши работата. Изключването на политиката, за да тествате връзката нагоре, премахва защитата, която вероятно сте искали, и не ви учи на нищо.
Вместо това проверете обхвата. Кои приложения са обхванати, кои са изключени и дали профилът е за потребител или за цялото устройство. Задача, която стартира VPN приложението, щом се появи Wi-Fi, е тригер, а не гаранция, че преди да се задейства не е излязъл нито един пакет.
Диагностичен ред, който прекратява гаданията
Работете отдолу нагоре. Потвърдете режима, потвърдете, че има мрежа, потвърдете, че е валидирана, потвърдете, че може да достигне нещо извън локалната подмрежа, и само след това погледнете клиента. adb shell ping -c 3 1.1.1.1 е груб тест, но той отделя липсващия път от път, който съществува, докато тунелът е недоволен.
Ако ping се провали, докато мрежа е в списъка, проблемът е преди VPN и никоя настройка на клиента няма да го поправи. Ако ping успее, а тунелът все още не се установява, запишете журнала на клиента в този момент: грешката ще различи изтичане на времето от отказ при автентикация, а тези две не си приличат по нищо.
Завършете, като възстановите желаното състояние: Wi-Fi разрешен в режим „самолет“, ако това е обичайната ви настройка, порталът е преминат, а блокиращата политика е отново включена. След това се свържете отново веднъж и потвърдете, че тунелът се вдига сам, защото конфигурация, която работи само след ръчни повторни опити, ще се провали отново при следващото зареждане.