Telefon prikazuje ikonu aviona, VPN klijent je već dvije minute na Connecting, a profil je ispravan. Prije sat vremena radio je u istoj zgradi. Ništa nije pokvareno: VPN je veza koju prenosi druga mreža, a avionski režim je upravo uklonio mrežu koja ju je prenosila. Klijent stalno pokušava jer to i radi bez uzlazne veze.

Zbunjuje to što ikona aviona ne govori je li Wi-Fi dostupan, a Connecting ne govori autentificira li se klijent ili samo čeka. Razdvojite ta dva čitanja i dijagnoza traje minutu.

Ikona aviona nije izvještaj o radiju

Na podržanim Android uređajima Wi-Fi i Bluetooth mogu ostati uključeni u avionskom režimu, a uređaj pamti izbor koji ste napravili prošli put. Googleove smjernice za avionski režim na Pixelu opisuju upravo takvo ponašanje. Znači, ikona može značiti da je mobilna mreža isključena i ništa drugo.

Provjerite stvarno stanje, a ne glif. adb shell settings get global airplane_mode_on vraća 0 ili 1 za sam režim, a adb shell dumpsys connectivity navodi mreže koje uređaj trenutno ima, s njihovim statusom validacije. Ta dva izlaza zajedno odgovaraju na pitanje na koje ikona ne može.

Ako je Wi-Fi isključen ili uključen ali ni s čim povezan, nema puta do VPN odredišta i nikakvo ponovno povezivanje ga neće stvoriti. Taj slučaj vrijedi prvo isključiti, jer je to jedini slučaj u kojem je ispravno rješenje izvan VPN aplikacije.

Šta Connecting zapravo znači

Klijent može držati sačuvani profil, prikazati njegovo ime i vrtjeti indikator bez da je s bilo čim kontaktirao. Konfiguracija je lokalna. Uspostavljanje tunela zahtijeva dostupan server, završeno rukovanje i interfejs za usmjeravanje. Samo zadnji dio treba mrežu koja radi, zato prva dva mogu izgledati uspješno i kad je radio isključen.

Zato je indikator u skladu s najmanje tri različite situacije: nema uzlazne veze uopće, uzlazna veza ne može dosegnuti odredište, i uzlazna veza ga dosegne ali autentifikacija ne uspije. Na ekranu izgledaju identično, a u zapisu potpuno različito. Zato je prvi koristan artefakt u svakom od tih slučajeva zapis, a ne još jedan pokušaj.

Androidova vlastita VPN dokumentacija povlači istu granicu između uspostavljanja veze i odvojenih politika stalnog uključenja i blokiranja. To razdvajanje je razlog zašto telefon može izgledati zaštićeno dok je izvan mreže i pritom nemati tunel.

Četiri stanja koja vrijedi razlikovati

Četiri stanja ispod vrijedi imenovati, jer ih ekran prikazuje jednako.

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

Treći red pogađa većinu ljudi u hotelima i aerodromima. Asocijacija nije propuštanje: portal koji nije pustio telefon rado će prihvatiti Wi-Fi lozinku i zatim odbiti propustiti saobraćaj do VPN odredišta. Prijava prvo kroz preglednik, dok je tunel isključen, obično je jedini put.

Zašto blokiranje izgleda gore

Ako su stalni VPN i blokiranje veza bez VPN-a oboje uključeni, svaka obuhvaćena aplikacija je blokirana kad god tunel nije podignut. To je funkcija koja radi, a ne druga greška. Simptom se mijenja od toga da jedna aplikacija ne radi do toga da ništa ne radi, što se čita kao mnogo veći problem.

To objašnjava i slijed koji ljudi pogrešno čitaju: avionski režim uključen, nema uzlazne veze, aplikacije blokirane, VPN kaže connecting. Blokada je bila politika koja radi svoj posao. Isključivanje politike da biste testirali uzlaznu vezu uklanja zaštitu koju ste vjerojatno htjeli i ne uči vas ničemu.

Umjesto toga provjerite obuhvat. Koje su aplikacije obuhvaćene, koje isključene i je li profil po korisniku ili na razini uređaja. Zadatak koji pokrene VPN aplikaciju kad se pojavi Wi-Fi je okidač, a ne garancija da nijedan paket nije otišao prije nego što se pokrenuo.

Redoslijed dijagnostike koji prekida nagađanje

Radite odozdo prema gore. Potvrdite režim, potvrdite da mreža postoji, potvrdite da je validirana, potvrdite da može dosegnuti nešto izvan lokalne podmreže i tek onda pogledajte klijent. adb shell ping -c 3 1.1.1.1 je grub test, ali razdvaja put koji nedostaje od puta koji postoji dok je tunel nezadovoljan.

Ako ping ne uspije dok je mreža na popisu, problem je uzvodno od VPN-a i nijedna klijentska postavka ga neće popraviti. Ako ping uspije a tunel se ipak ne uspostavi, zabilježite zapis klijenta u tom trenutku: greška će razlikovati istek vremena od odbijanja autentifikacije, a to dvoje nema ništa zajedničko.

Završite vraćanjem željenog stanja: Wi-Fi dopušten u avionskom režimu ako je to vaša uobičajena postavka, portal završen i politika blokiranja ponovno uključena. Zatim se jednom ponovo povežite i potvrdite da se tunel sam podiže, jer konfiguracija koja radi samo nakon ručnih pokušaja ponovno će pasti pri sljedećem podizanju.

Povezani članci