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 дозволен во авионски режим ако тоа е вашата вообичаена поставка, порталот завршен и политиката за блокирање повторно вклучена. Потоа поврзете се еднаш повторно и потврдете дека тунелот се подига сам, зашто конфигурација што работи само по рачни обиди повторно ќе падне при следното подигање.