Telefon näitab lennuki ikooni, VPN-klient on olnud Connectingul kaks minutit ja profiil on õige. Tund aega tagasi töötas see samas hoones. Miski pole katki: VPN on ühendus, mida kannab teine võrk, ja lennurežiim eemaldas just selle võrgu, mis seda kandis. Klient proovib edasi, sest seda ta ilma ülesvoolu ühenduseta teeb.

Segadust tekitab see, et lennuki sümbol ei ütle, kas Wi-Fi on saadaval, ja Connecting ei ütle, kas klient autendib või ainult ootab. Eraldage need kaks näitu ja diagnoos võtab minuti.

Lennuki sümbol ei ole raadioaruanne

Toetatud Androidi seadmetes võivad Wi-Fi ja Bluetooth lennurežiimis sisse jääda ning seade mäletab valikut, mille tegite eelmisel korral. Google'i Pixel'i lennurežiimi juhend kirjeldab täpselt sellist käitumist. Ikoon võib seega tähendada, et mobiilside on väljas, ja mitte midagi muud.

Kontrollige tegelikku olekut, mitte glüüfi. adb shell settings get global airplane_mode_on tagastab režiimi enda kohta 0 või 1 ning adb shell dumpsys connectivity loetleb võrgud, mis seadmel praegu on, koos nende valideerimise olekuga. Need kaks väljundit vastavad koos küsimusele, millele ikoon ei suuda.

Kui Wi-Fi on väljas või sisse lülitatud, kuid millegagi assotsieerimata, pole VPN-i lõpp-punkti viivat teed ja ükski ühendamiskordade hulk ei loo seda. Just see juhtum tasub esimesena välistada, sest see on ainus, kus õige parandus on väljaspool VPN-rakendust.

Mida Connecting tegelikult tähendab

Klient võib hoida salvestatud profiili, kuvada selle nime ja näidata pöörlevat indikaatorit, ilma et oleks millegagi ühendust võtnud. Konfiguratsioon on kohalik. Tunneli loomiseks on vaja kättesaadavat serverit, lõpetatud kätlust ja liidest, mille kaudu marsruutida. Ainult viimane osa vajab töötavat võrku, mistõttu kaks esimest võivad raadio väljas olles edukad paista.

Seega sobib indikaator vähemalt kolme erineva olukorraga: ülesvoolu ühendust pole üldse, ülesvoolu ühendus ei jõua lõpp-punkti, ja ülesvoolu ühendus jõuab sinna, kuid autentimine ebaõnnestub. Ekraanil näevad need identsed välja ja logis täiesti erinevad. Seetõttu on esimene kasulik artefakt kõigil neil juhtudel logi, mitte uus katse.

Androidi enda VPN-dokumentatsioon tõmbab sama piiri ühenduse loomise ning eraldi pidevalt sisse ja blokeerimise poliitikate vahele. Just see eraldamine on põhjus, miks telefon võib võrguühenduseta olles kaitstud paista ja siiski tunnelit mitte omada.

Neli olekut, mida tasub eristada

Allpool olevad neli olekut tasub nimetada, sest ekraan kuvab neid ühtemoodi.

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

Kolmas rida püüab kinni enamiku inimestest hotellides ja lennujaamades. Assotsiatsioon ei ole luba: portaal, mis pole telefoni läbi lasknud, võtab Wi-Fi parooli hea meelega vastu ja keeldub seejärel liiklust VPN-i lõpp-punkti suunas läbi laskmast. Kõigepealt brauseri kaudu sisselogimine, kui tunnel on väljas, on tavaliselt ainus tee läbi.

Miks blokeerimine paneb selle hullemini paistma

Kui pidev VPN ja ilma VPN-ita ühenduste blokeerimine on mõlemad sisse lülitatud, blokeeritakse iga hõlmatud rakendus alati, kui tunnel üleval pole. See on funktsioon töötamas, mitte teine rike. Sümptom muutub ühe rakenduse ebaõnnestumisest kõige ebaõnnestumiseks, mis loetakse palju suuremaks probleemiks.

See selgitab ka järjestust, mida inimesed valesti loevad: lennurežiim sees, ülesvoolu ühendust pole, rakendused blokeeritud, VPN ütleb connecting. Blokeering oli poliitika oma tööd tegemas. Poliitika väljalülitamine ülesvoolu ühenduse testimiseks eemaldab kaitse, mida te tõenäoliselt soovisite, ja ei õpeta teile midagi.

Kontrollige hoopis ulatust. Millised rakendused on hõlmatud, millised välja jäetud ja kas profiil on kasutajapõhine või seadmepõhine. Ülesanne, mis käivitab VPN-rakenduse kohe, kui Wi-Fi ilmub, on päästik, mitte garantii, et enne selle käivitumist ei lahkunud ükski pakett.

Diagnostiline järjekord, mis lõpetab oletamise

Töötage alt üles. Kinnitage režiim, kinnitage, et võrk on olemas, et see on valideeritud, et see jõuab milleni iganes väljapoole kohalikku alavõrku, ja alles siis vaadake klienti. adb shell ping -c 3 1.1.1.1 on toores test, kuid see eraldab puuduva tee teest, mis on olemas, samal ajal kui tunnel on rahulolematu.

Kui ping ebaõnnestub, samal ajal kui võrk on loetletud, on probleem VPN-ist ülesvoolu ja ükski kliendi säte ei paranda seda. Kui ping õnnestub ja tunnel ikkagi ei loomestu, jäädvustage kliendi logi just sel hetkel: viga eristab aegumise autentimise tagasilükkamisest ja neil kahel pole midagi ühist.

Lõpetage soovitud oleku taastamisega: Wi-Fi lubatud lennurežiimis, kui see on teie tavaline seadistus, portaal läbitud ja blokeerimispoliitika uuesti sees. Seejärel ühenduge korra uuesti ja kinnitage, et tunnel tõuseb ise, sest konfiguratsioon, mis töötab alles pärast käsitsi korduskatseid, ebaõnnestub järgmisel käivitamisel uuesti.

Seotud artiklid