VPN zaglavljen na Connecting u avionskom načinu rada: pronađite uzlaznu vezu
Klijent koji u avionskom načinu rada stoji na Connecting možda jednostavno nema uzlaznu vezu. Razdvojite stanje radija, pridruživanje, prijavu na portal i politiku blokiranja.
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 način rada upravo je 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 načinu rada, a uređaj pamti izbor koji ste napravili prošli put. Googleove smjernice za avionski način rada na Pixelu opisuju upravo takvo ponašanje. Dakle, 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 način rada, a adb shell dumpsys connectivity navodi mreže koje uređaj trenutačno ima, s njihovim statusom provjere. 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.
Što Connecting zapravo znači
Klijent može držati spremljenu profil, prikazati njezino ime i vrtjeti indikator bez da je s bilo čim kontaktirao. Konfiguracija je lokalna. Uspostavljanje tunela zahtijeva dostupan poslužitelj, završeno rukovanje i sučelje 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 zaslonu izgledaju identično, a u zapisu posve 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čivanja i blokiranja. To razdvajanje razlog je 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 u nastavku vrijedi imenovati, jer ih zaslon prikazuje jednako.
| 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 |
Treći red pogađa većinu ljudi u hotelima i zračnim lukama. Pridruživanje nije propuštanje: portal koji nije pustio telefon rado će prihvatiti Wi-Fi lozinku i zatim odbiti propustiti promet do VPN odredišta. Prijava najprije 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 blokirana je kad god tunel nije podignut. To je značajka 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 način rada 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 jamstvo da nijedan paket nije otišao prije nego što se pokrenuo.
Redoslijed dijagnostike koji prekida nagađanje
Radite odozdo prema gore. Potvrdite način rada, potvrdite da mreža postoji, potvrdite da je provjerena, 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 načinu rada ako je to vaša uobičajena postavka, portal završen i politika blokiranja ponovno uključena. Zatim se jednom ponovno 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.