VPN blocat pe Connecting în modul avion: găsiți legătura ascendentă
Un client care rămâne pe Connecting în modul avion poate pur și simplu să nu aibă legătură ascendentă. Separați starea radioului, asocierea, autentificarea în portal și politica de blocare.
Telefonul afișează pictograma avionului, clientul VPN stă pe Connecting de două minute, iar profilul este corect. Acum o oră funcționa în aceeași clădire. Nimic nu este stricat: un VPN este o conexiune purtată de o altă rețea, iar modul avion tocmai a eliminat rețeaua care o purta. Clientul încearcă în continuare, pentru că asta face fără o legătură ascendentă.
Derutant este că simbolul avionului nu vă spune dacă Wi-Fi este disponibil, iar Connecting nu vă spune dacă clientul se autentifică sau doar așteaptă. Separați aceste două citiri și diagnosticul durează un minut.
Simbolul avionului nu este un raport radio
Pe dispozitivele Android compatibile, Wi-Fi și Bluetooth pot rămâne pornite în modul avion, iar dispozitivul reține alegerea făcută ultima dată. Ghidul Google despre modul avion pe Pixel descrie exact acest comportament. Deci pictograma poate însemna doar că celularul este oprit, și nimic altceva.
Verificați starea reală, nu glifa. adb shell settings get global airplane_mode_on returnează 0 sau 1 pentru modul în sine, iar adb shell dumpsys connectivity listează rețelele pe care dispozitivul le are acum, împreună cu starea lor de validare. Aceste două ieșiri împreună răspund la întrebarea la care pictograma nu poate.
Dacă Wi-Fi este oprit, sau pornit dar neasociat cu nimic, nu există cale către punctul final al VPN și nicio cantitate de reconectări nu o va crea. Acesta este cazul care merită exclus primul, pentru că este singurul în care remedierea corectă este în afara aplicației VPN.
Ce înseamnă de fapt Connecting
Un client poate păstra un profil salvat, îi poate afișa numele și poate roti un indicator fără să fi contactat nimic. Configurația este locală. Stabilirea unui tunel necesită un server accesibil, un handshake finalizat și o interfață prin care să dirijeze. Doar ultima parte are nevoie de o rețea funcțională, de aceea primele două pot părea reușite cu radioul oprit.
Deci indicatorul este compatibil cu cel puțin trei situații diferite: nicio legătură ascendentă, o legătură care nu ajunge la punctul final și una care ajunge dar eșuează la autentificare. Pe ecran arată identic, iar într-un jurnal complet diferit. De aceea primul artefact util în toate aceste cazuri este jurnalul, nu o altă încercare.
Documentația VPN a Androidului trasează aceeași graniță între stabilirea conexiunii și politicile separate de mereu activ și blocare. Această separare este motivul pentru care un telefon poate părea protejat fiind offline și totuși să nu aibă tunel.
Patru stări care merită distinse
Cele patru stări de mai jos sunt cele care merită numite, pentru că ecranul le afișează identic.
| 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 |
Al treilea rând prinde majoritatea oamenilor în hoteluri și aeroporturi. Asocierea nu este admitere: un portal care nu a lăsat telefonul să treacă va accepta bucuros parola Wi-Fi și apoi va refuza să treacă traficul către punctul final al VPN. Autentificarea mai întâi prin browser, cu tunelul oprit, este de obicei singura cale.
De ce blocarea face totul să pară mai rău
Dacă VPN-ul mereu activ și blocarea conexiunilor fără VPN sunt ambele activate, fiecare aplicație acoperită este blocată ori de câte ori tunelul nu este ridicat. Aceasta este funcția care lucrează, nu o a doua defecțiune. Simptomul se schimbă de la o aplicație care eșuează la totul care eșuează, ceea ce se citește ca o problemă mult mai mare.
Explică și secvența pe care oamenii o citesc greșit: modul avion pornit, nicio legătură ascendentă, aplicații blocate, VPN-ul spune connecting. Blocarea era politica făcându-și treaba. Oprirea politicii pentru a testa legătura ascendentă elimină protecția pe care probabil o doreați și nu vă învață nimic.
Verificați în schimb aria de acoperire. Ce aplicații sunt acoperite, care sunt excluse și dacă profilul este pe utilizator sau pe întregul dispozitiv. O sarcină care pornește aplicația VPN imediat ce apare Wi-Fi este un declanșator, nu o garanție că niciun pachet nu a ieșit înainte de a rula.
O ordine de diagnostic care pune capăt presupunerilor
Lucrați de jos în sus. Confirmați modul, confirmați că există o rețea, că este validată, că poate ajunge la ceva din afara subrețelei locale, și abia apoi priviți clientul. adb shell ping -c 3 1.1.1.1 este un test grosier, dar separă o cale lipsă de o cale care există în timp ce tunelul este nemulțumit.
Dacă ping-ul eșuează în timp ce o rețea este listată, problema este deasupra VPN-ului și nicio setare a clientului nu o repară. Dacă ping-ul reușește și tunelul tot nu se stabilește, capturați jurnalul clientului în acel moment: eroarea va distinge un timeout de o respingere a autentificării, iar acestea două nu au nimic în comun.
Încheiați restabilind starea dorită: Wi-Fi permis în modul avion dacă aceasta este configurația obișnuită, portalul finalizat și politica de blocare din nou activă. Apoi reconectați o dată și confirmați că tunelul urcă singur, pentru că o configurație care funcționează doar după încercări manuale va eșua din nou la următoarea pornire.