A VPN beragad a Connecting állapotba repülőgép-módban: keresse meg a felső kapcsolatot
A repülőgép-módban a Connecting állapotban ragadó kliensnek lehet, hogy egyszerűen nincs felső kapcsolata. Válassza szét a rádió állapotát, a társítást, a portál bejelentkezést és a blokkolási szabályt.
A telefon a repülőgép ikonját mutatja, a VPN kliens két perce a Connecting állapotban van, és a profil helyes. Egy órával ezelőtt ugyanabban az épületben működött. Semmi sem romlott el: a VPN olyan kapcsolat, amelyet egy másik hálózat hordoz, és a repülőgép-mód éppen azt a hálózatot vette el, amely hordozta. A kliens újra és újra próbálkozik, mert felső kapcsolat nélkül ezt teszi.
Az a zavaró, hogy a repülőgép szimbólum nem mondja meg, elérhető-e a Wi-Fi, és a Connecting nem mondja meg, hitelesít-e a kliens, vagy csak vár. Válassza szét ezt a két olvasatot, és a diagnózis egy percet vesz igénybe.
A repülőgép szimbólum nem rádiójelentés
A támogatott Android-eszközökön a Wi-Fi és a Bluetooth bekapcsolva maradhat repülőgép-módban, és az eszköz emlékszik a legutóbbi választására. A Google Pixel repülőgép-mód útmutatója pontosan ezt a viselkedést írja le. Tehát az ikon csak azt jelentheti, hogy a mobilhálózat ki van kapcsolva, és semmi mást.
A tényleges állapotot ellenőrizze, ne a glifet. A adb shell settings get global airplane_mode_on 0 vagy 1 értéket ad magára a módra, a adb shell dumpsys connectivity pedig felsorolja az eszköz jelenlegi hálózatait az érvényesítési állapotukkal. Ez a két kimenet együtt válaszol arra a kérdésre, amelyre az ikon nem képes.
Ha a Wi-Fi ki van kapcsolva, vagy be van kapcsolva, de semmihez nincs társítva, nincs útvonal a VPN végpontjához, és bármennyi újracsatlakozás sem hoz létre egyet. Ezt az esetet érdemes először kizárni, mert ez az egyetlen, ahol a helyes javítás a VPN-alkalmazáson kívül van.
Mit jelent valójában a Connecting
A kliens tarthat elmentett profilt, megjelenítheti a nevét, és pörgő jelzőt mutathat anélkül, hogy bármivel kapcsolatba lépett volna. A konfiguráció helyi. Az alagút létrehozásához elérhető kiszolgáló, befejezett kézfogás és útválasztásra alkalmas interfész kell. Csak az utolsó résznek kell működő hálózat, ezért az első kettő sikeresnek tűnhet kikapcsolt rádió mellett is.
A jelző tehát legalább három különböző helyzethez illik: egyáltalán nincs felső kapcsolat, a felső kapcsolat nem éri el a végpontot, és a felső kapcsolat eléri, de a hitelesítés meghiúsul. A képernyőn azonosnak látszanak, a naplóban teljesen különböznek. Ezért ezekben az esetekben az első hasznos nyom a napló, nem egy újabb próbálkozás.
Az Android saját VPN-dokumentációja ugyanazt a határvonalat húzza meg a kapcsolat létrehozása és a külön mindig bekapcsolt, illetve blokkoló szabályok között. Ez a szétválasztás az oka, hogy a telefon offline állapotban védettnek tűnhet, és mégis lehet alagút nélkül.
Négy állapot, amelyet érdemes megkülönböztetni
Az alábbi négy állapot az, amelyet érdemes megnevezni, mert a képernyő azonos módon jeleníti meg őket.
| 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 |
A harmadik sor fogja meg a legtöbb embert szállodákban és repülőtereken. A társítás nem bebocsátás: a portál, amely nem engedte át a telefont, szívesen elfogadja a Wi-Fi jelszót, majd megtagadja a forgalom továbbítását a VPN végpontja felé. Ha először a böngészőn keresztül jelentkezik be, amíg az alagút ki van kapcsolva, általában ez az egyetlen út.
Miért tűnik tőle rosszabbnak a blokkolás
Ha a mindig bekapcsolt VPN és a VPN nélküli kapcsolatok blokkolása is aktív, minden lefedett alkalmazás blokkolva van, amikor az alagút nem áll fel. Ez a funkció működése, nem második hiba. A tünet átvált attól, hogy egy alkalmazás hibázik, addig, hogy minden hibázik, ami sokkal nagyobb problémának tűnik.
Ez magyarázza azt a sorrendet is, amelyet az emberek félreolvasnak: repülőgép-mód be, nincs felső kapcsolat, alkalmazások blokkolva, a VPN connectinget mond. A blokkolás a szabály volt, amely a dolgát végezte. A szabály kikapcsolása a felső kapcsolat teszteléséhez eltávolítja a védelmet, amelyet feltehetően szeretett volna, és semmire nem tanítja.
Ehelyett a hatókört ellenőrizze. Mely alkalmazások lefedettek, melyek kizártak, és a profil felhasználónként vagy az egész eszközre szól. Az a feladat, amely a Wi-Fi megjelenésekor elindítja a VPN-alkalmazást, kiváltó, nem garancia arra, hogy előtte nem ment ki egyetlen csomag sem.
Diagnosztikai sorrend, amely véget vet a találgatásnak
Alulról felfelé haladjon. Erősítse meg a módot, hogy létezik hálózat, hogy érvényesítve van, hogy el ér valamit a helyi alhálózaton kívül, és csak ezután nézze a klienst. A adb shell ping -c 3 1.1.1.1 durva teszt, de elválasztja a hiányzó útvonalat attól az útvonaltól, amely létezik, miközben az alagút elégedetlen.
Ha a ping meghiúsul, miközben egy hálózat szerepel a listán, a probléma a VPN fölött van, és egyetlen kliensbeállítás sem javítja meg. Ha a ping sikerül, és az alagút mégsem jön létre, rögzítse a kliens naplóját abban a pillanatban: a hiba megkülönbözteti az időtúllépést a hitelesítés elutasításától, és ennek a kettőnek semmi köze egymáshoz.
Fejezze be a kívánt állapot visszaállításával: a Wi-Fi engedélyezve repülőgép-módban, ha ez a szokásos beállítása, a portál befejezve, és a blokkolási szabály ismét bekapcsolva. Ezután egyszer csatlakozzon újra, és erősítse meg, hogy az alagút magától feláll, mert a csak kézi próbálkozások után működő konfiguráció a következő indításkor ismét meghiúsul.