Telefon zobrazuje ikonu letadla, klient VPN je už dvě minuty na Connecting a profil je správný. Před hodinou to fungovalo ve stejné budově. Nic není rozbité: VPN je spojení přenášené jinou sítí a režim letadla právě odstranil síť, která ho přenášela. Klient zkouší dál, protože to bez vzestupného spojení dělá.

Máte to zmatečné, protože ikona letadla neříká, zda je k dispozici Wi-Fi, a Connecting neříká, zda se klient autentizuje, nebo jen čeká. Oddělte obě čtení a diagnostika zabere minutu.

Ikona letadla není zpráva o rádiu

Na podporovaných zařízeních Android mohou Wi-Fi a Bluetooth zůstat v režimu letadla zapnuté a zařízení si pamatuje volbu, kterou jste udělali minule. Příručka Google k režimu letadla na Pixelu popisuje přesně toto chování. Ikona tedy může znamenat jen to, že je vypnutá mobilní síť, a nic víc.

Kontrolujte skutečný stav, ne glyf. adb shell settings get global airplane_mode_on vrací 0 nebo 1 pro samotný režim a adb shell dumpsys connectivity vypisuje sítě, které zařízení právě má, včetně stavu ověření. Tyto dva výstupy společně odpovídají na otázku, na kterou ikona nedokáže odpovědět.

Pokud je Wi-Fi vypnutá, nebo zapnutá, ale k ničemu nepřipojená, nevede k VPN koncovému bodu žádná cesta a žádné opakované připojování ji nevytvoří. Tento případ stojí za to vyloučit jako první, protože je jediný, kde správná oprava leží mimo aplikaci VPN.

Co Connecting skutečně znamená

Klient může držet uložený profil, zobrazit jeho název a točit indikátor, aniž by s čímkoli komunikoval. Konfigurace je lokální. Vytvoření tunelu vyžaduje dostupný server, dokončený handshake a rozhraní pro směrování. Jen poslední část potřebuje fungující síť, a proto první dvě mohou vypadat úspěšně i s vypnutým rádiem.

Indikátor tedy odpovídá nejméně třem různým situacím: žádné vzestupné spojení, vzestupné spojení, které nedosáhne na koncový bod, a vzestupné spojení, které ho dosáhne, ale selže autentizace. Na obrazovce vypadají stejně a v logu úplně jinak. Proto je prvním užitečným artefaktem v každém z těchto případů log, ne další pokus.

Vlastní dokumentace Androidu k VPN vede stejnou hranici mezi navázáním spojení a oddělenými politikami trvalého zapnutí a blokování. Právě toto oddělení je důvod, proč telefon může vypadat chráněně, i když je offline, a přesto nemá tunel.

Čtyři stavy, které stojí za rozlišení

Níže uvedené čtyři stavy stojí za pojmenování, protože je obrazovka vykresluje stejně.

StateWhat you will seeWhat to do
Airplane mode, Wi-Fi offNo networks in dumpsys, VPN retries foreverTurn Wi-Fi on, or accept that the tunnel cannot exist
Wi-Fi on, not associatedInterface exists, no default networkJoin the access point
Associated, not validatedNetwork listed, captive-portal flag setComplete the portal sign-in, then reconnect
Validated, tunnel downInternet works, VPN fails or blocksDebug the tunnel, not the radio

Třetí řádek chytá většinu lidí v hotelích a na letištích. Asociace není vpuštění: portál, který telefon nepustil, ochotně přijme heslo k Wi-Fi a pak odmítne propustit provoz ke koncovému bodu VPN. Přihlásit se nejdřív v prohlížeči, zatímco je tunel vypnutý, je obvykle jediná cesta.

Proč to blokování dělá horším

Pokud jsou zapnuté trvalá VPN i blokování připojení bez VPN, každá pokrytá aplikace je zablokovaná, kdykoli tunel neběží. To je funkce, která pracuje, ne druhá závada. Symptom se mění ze selhání jedné aplikace na selhání všeho, což se čte jako mnohem větší problém.

Vysvětluje to i sled, který lidé čtou špatně: režim letadla zapnutý, žádné vzestupné spojení, aplikace zablokované, VPN hlásí connecting. Blokování byla politika, která dělala svou práci. Vypnutí politiky kvůli testu vzestupného spojení odstraní ochranu, kterou jste pravděpodobně chtěli, a nic vás nenaučí.

Zkontrolujte místo toho rozsah. Které aplikace jsou pokryté, které vyloučené a zda je profil na uživatele, nebo na celé zařízení. Úloha, která spustí aplikaci VPN, jakmile se objeví Wi-Fi, je spouštěč, ne záruka, že před jejím spuštěním neodešel žádný paket.

Diagnostický postup, který ukončí hádání

Postupujte zdola nahoru. Potvrďte režim, potvrďte, že existuje síť, potvrďte, že je ověřená, potvrďte, že dosáhne na něco mimo místní podsíť, a teprve pak se podívejte na klienta. adb shell ping -c 3 1.1.1.1 je hrubý test, ale odděluje chybějící cestu od cesty, která existuje, zatímco tunel je nespokojený.

Pokud ping selže, zatímco je síť v seznamu, problém je výš než VPN a žádné nastavení klienta ho neopraví. Pokud ping uspěje a tunel se přesto nenaváže, zachyťte v tu chvíli log klienta: chyba rozliší vypršení časového limitu od odmítnutí autentizace a ty dvě nemají nic společného.

Skončete obnovením zamýšleného stavu: Wi-Fi povolená v režimu letadla, pokud je to vaše obvyklé nastavení, portál dokončený a blokovací politika znovu zapnutá. Pak se jednou připojte a potvrďte, že tunel naskočí sám, protože konfigurace, která funguje jen po ručních opakováních, znovu selže při příštím startu.

Související články