VPN blokiĝas ĉe Connecting en aviadila reĝimo: trovu la suprenligon
Kliento, kiu restas ĉe Connecting en aviadila reĝimo, eble simple ne havas suprenligon. Apartigu la radian staton, la asociiĝon, la portalan ensaluton kaj la blokadan politikon.
La telefono montras la aviadilan ikonon, la VPN-kliento jam du minutojn estas ĉe Connecting, kaj la profilo estas ĝusta. Ĝi funkciis antaŭ unu horo en la sama konstruaĵo. Nenio estas rompita: VPN estas konekto portata de alia reto, kaj la aviadila reĝimo ĵus forigis la reton, kiu portis ĝin. La kliento daŭre reprovas, ĉar tion ĝi faras sen suprenligo.
Konfuzas tion, ke la aviadila simbolo ne diras al vi, ĉu Wi-Fi estas disponebla, kaj Connecting ne diras, ĉu la kliento aŭtentikigas aŭ nur atendas. Apartigu tiujn du legaĵojn kaj la diagnozo daŭras unu minuton.
La aviadila simbolo ne estas raporto pri la radio
Sur subtenataj Android-aparatoj, Wi-Fi kaj Bluetooth povas resti ŝaltitaj en aviadila reĝimo, kaj la aparato memoras la elekton, kiun vi faris lastfoje. La gvidilo de Google pri aviadila reĝimo en Pixel priskribas ĝuste tiun konduton. Do la ikono povas signifi, ke la poŝtelefona reto estas malŝaltita, kaj nenion alian.
Kontrolu la faktan staton anstataŭ la glifon. adb shell settings get global airplane_mode_on redonas 0 aŭ 1 por la reĝimo mem, kaj adb shell dumpsys connectivity listigas la retojn, kiujn la aparato nun havas, kun ilia validiga stato. Tiuj du eligoj kune respondas la demandon, kiun la ikono ne povas.
Se Wi-Fi estas malŝaltita, aŭ ŝaltita sed asociita kun nenio, ne ekzistas vojo al la finpunkto de VPN kaj neniu kvanto da rekonektado kreos ĝin. Tiu kazo indas esti unue ekskludita, ĉar ĝi estas la sola, kie la ĝusta solvo troviĝas ekster la VPN-aplikaĵo.
Kion Connecting efektive signifas
Kliento povas teni konservitan profilon, montri ĝian nomon kaj turni indikilon sen esti kontaktinta ion ajn. La agordo estas loka. Konstrui tunelon postulas atingeblan servilon, finitan manpremon kaj interfacon por enkursigi. Nur la lasta parto bezonas funkciantan reton, kaj tial la du unuaj povas ŝajni sukcesaj kun la radio malŝaltita.
Do la indikilo kongruas kun almenaŭ tri malsamaj situacioj: tute neniu suprenligo, suprenligo kiu ne povas atingi la finpunkton, kaj suprenligo kiu atingas ĝin sed malsukcesas ĉe aŭtentikigo. Sur la ekrano ili aspektas idente kaj en protokolo tute malsame. Tial la unua utila artefakto en ĉiu el tiuj kazoj estas la protokolo, ne plia reprovo.
La propra VPN-dokumentaro de Android desegnas la saman limon inter starigo de konekto kaj la apartaj politikoj de ĉiam-ŝaltita kaj blokado. Tiu apartigo estas la kialo, ke telefono povas ŝajni protektita dum ĝi estas senrete kaj tamen ne havi tunelon.
Kvar statoj indaj je distingo
La kvar subaj statoj indas esti nomitaj, ĉar la ekrano bildigas ilin idente.
| 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 |
La tria vico kaptas la plej multajn homojn en hoteloj kaj flughavenoj. Asociiĝo ne estas enlaso: portalo, kiu ne lasis la telefonon tra, volonte akceptos la Wi-Fi-pasvorton kaj poste rifuzos pasigi trafikon al la finpunkto de VPN. Ensaluti unue per la retumilo, dum la tunelo estas malŝaltita, kutime estas la sola vojo tra.
Kial blokado igas ĝin aspekti pli malbone
Se kaj ĉiam-ŝaltita VPN kaj blokado de konektoj sen VPN estas ŝaltitaj, ĉiu kovrita aplikaĵo estas blokata ĉiam, kiam la tunelo ne staras. Tio estas la funkcio laboranta, ne dua paneo. La simptomo ŝanĝiĝas de unu aplikaĵo malsukcesanta al ĉio malsukcesanta, kio legiĝas kiel multe pli granda problemo.
Ĝi ankaŭ klarigas la sinsekvon, kiun homoj mislegas: aviadila reĝimo ŝaltita, neniu suprenligo, aplikaĵoj blokitaj, VPN diras connecting. La blokado estis la politiko faranta sian laboron. Malŝalti la politikon por testi la suprenligon forigas la protekton, kiun vi supozeble volis, kaj instruas al vi nenion.
Anstataŭe kontrolu la amplekson. Kiuj aplikaĵoj estas kovritaj, kiuj ekskluditaj, kaj ĉu la profilo estas po-uzanto aŭ por la tuta aparato. Tasko, kiu lanĉas la VPN-aplikaĵon tuj kiam Wi-Fi aperas, estas ellaso, ne garantio, ke neniu pako foriris antaŭ ol ĝi ekfunkciis.
Diagnoza ordo, kiu finas la konjektadon
Laboru de malsupre supren. Konfirmu la reĝimon, konfirmu ke reto ekzistas, konfirmu ke ĝi estas validigita, konfirmu ke ĝi povas atingi ion ekster la loka subreto, kaj nur poste rigardu la klienton. adb shell ping -c 3 1.1.1.1 estas kruda provo, sed ĝi apartigas mankan vojon de vojo, kiu ekzistas dum la tunelo estas malfeliĉa.
Se la ping malsukcesas dum reto estas listigita, la problemo estas supre de la VPN kaj neniu klienta agordo riparos ĝin. Se la ping sukcesas kaj la tunelo tamen ne stariĝas, kaptu la protokolon de la kliento en tiu momento: la eraro distingos tempolimon de malakcepto de aŭtentikigo, kaj tiuj du havas nenion komunan.
Finu restarigante la celitan staton: Wi-Fi permesita en aviadila reĝimo se tio estas via normala agordo, la portalo finita, kaj la blokada politiko denove ŝaltita. Poste rekonektu unufoje kaj konfirmu, ke la tunelo leviĝas memstare, ĉar agordo, kiu funkcias nur post manaj reprovoj, denove malsukcesos ĉe la sekva lanĉo.