VPN vashaak op Connecting in vliegtuigmodus: vind die opstroom
’n Kliënt wat in vliegtuigmodus op Connecting bly hang, het dalk eenvoudig geen opstroom nie. Skei radiostasie, assosiasie, portaal-aanmelding en die blokkeringsbeleid van mekaar.
Die foon wys die vliegtuigikoon, die VPN-kliënt staan al twee minute op Connecting, en die profiel is korrek. Dit het ’n uur gelede in dieselfde gebou gewerk. Niks is stukkend nie: ’n VPN is ’n verbinding wat deur ’n ander netwerk gedra word, en vliegtuigmodus het net die netwerk verwyder wat dit gedra het. Die kliënt hou aan probeer omdat dit is wat dit sonder ’n opstroom doen.
Wat dit verwarrend maak, is dat die vliegtuigsimbool jou nie sê of Wi-Fi beskikbaar is nie, en Connecting sê nie of die kliënt besig is om te verifieer of net wag nie. Skei daardie twee lesings en die diagnose neem ’n minuut.
Die vliegtuigsimbool is nie ’n radioverslag nie
Op ondersteunde Android-toestelle kan Wi-Fi en Bluetooth in vliegtuigmodus aan bly, en die toestel onthou die keuse wat jy laas gemaak het. Google se riglyne vir vliegtuigmodus op Pixel beskryf presies daardie gedrag. Dus kan die ikoon beteken dat sellulêr af is en niks anders nie.
Kontroleer die werklike toestand eerder as die glief. adb shell settings get global airplane_mode_on gee 0 of 1 vir die modus self, en adb shell dumpsys connectivity lys die netwerke wat die toestel tans het, met hul valideringstatus. Daardie twee uitsette saam beantwoord die vraag wat die ikoon nie kan nie.
As Wi-Fi af is, of aan maar nie aan iets geassosieer nie, is daar geen pad na die VPN-eindpunt nie en geen hoeveelheid herverbinding sal een skep nie. Dit is die geval wat eerste uitgeskakel moet word, want dit is die enigste een waar die regte oplossing buite die VPN-program is.
Wat Connecting eintlik beteken
’n Kliënt kan ’n gestoorde profiel hou, die naam daarvan wys en ’n draaier vertoon sonder dat dit enigiets gekontak het. Konfigurasie is plaaslik. Om ’n tonnel te bou vereis ’n bereikbare bediener, ’n voltooide handdruk en ’n koppelvlak om deur te rug. Net daardie laaste deel het ’n werkende netwerk nodig, en daarom kan die eerste twee suksesvol lyk terwyl die radio af is.
Dus pas die draaier by ten minste drie verskillende situasies: geen opstroom hoegenaamd nie, ’n opstroom wat nie die eindpunt kan bereik nie, en ’n opstroom wat dit bereik maar verifikasie faal. Hulle lyk identies op die skerm en heeltemal anders in ’n log. Daarom is die eerste nuttige artefak in enige van hierdie gevalle die log, nie nog ’n herprobeerslag nie.
Android se eie VPN-dokumentasie trek dieselfde lyn tussen die tot stand bring van ’n verbinding en die aparte altyd-aan- en blokkeringsbeleide. Daardie skeiding is die rede waarom ’n foon beskermd kan lyk terwyl dit vanlyn is en steeds geen tonnel het nie.
Vier toestande wat die moeite werd is om te onderskei
Die vier toestande hieronder is diegene wat dit werd is om te benoem, want die skerm beeld hulle identies uit.
| 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 |
Die derde ry vang die meeste mense in hotelle en lughawens. Assosiasie is nie toelating nie: ’n portaal wat nie die foon deurgelaat het nie, sal die Wi-Fi-wagwoord graag aanvaar en dan weier om verkeer na die VPN-eindpunt deur te stuur. Om eers deur die blaaier aan te meld, terwyl die tonnel af is, is gewoonlik die enigste manier deur.
Waarom blokkering dit erger laat lyk
As altyd-aan-VPN en blokkeer verbindings sonder VPN albei geaktiveer is, word elke gedekte program geblokkeer wanneer die tonnel nie op is nie. Dit is die funksie wat werk, nie ’n tweede fout nie. Die simptoom verander van een program wat misluk na alles wat misluk, wat soos ’n baie groter probleem lees.
Dit verduidelik ook die volgorde wat mense verkeerd lees: vliegtuigmodus aan, geen opstroom, programme geblokkeer, VPN sê connecting. Die blokkering was die beleid wat sy werk doen. Om die beleid af te skakel om die opstroom te toets, verwyder die beskerming wat jy vermoedelik wou gehad het en leer jou niks.
Kontroleer eerder die omvang. Watter programme is gedek, watter is uitgesluit, en of die profiel per gebruiker of toestelwyd is. ’n Taak wat die VPN-program begin sodra Wi-Fi verskyn, is ’n sneller, nie ’n waarborg dat geen pakkie voor dit begin het nie uitgegaan het nie.
’n Diagnosevolgorde wat die raaiery beëindig
Werk van onder af op. Bevestig die modus, bevestig dat ’n netwerk bestaan, bevestig dat dit gevalideer is, bevestig dat dit iets buite die plaaslike subnet kan bereik, en kyk eers dan na die kliënt. adb shell ping -c 3 1.1.1.1 is ’n bot toets, maar dit skei ’n ontbrekende pad van ’n pad wat bestaan terwyl die tonnel ongelukkig is.
As die ping misluk terwyl ’n netwerk gelys is, is die probleem opstroom van die VPN en geen kliëntinstelling sal dit regmaak nie. As die ping slaag en die tonnel steeds nie tot stand kom nie, neem die kliënt se log op daardie oomblik: die fout sal ’n tydverstryking van ’n verifikasieverwerping onderskei, en daardie twee het niks in gemeen nie.
Eindig deur die bedoelde toestand te herstel: Wi-Fi toegelaat in vliegtuigmodus as dit jou normale opstelling is, die portaal voltooi, en die blokkeringsbeleid weer aan. Herverbind dan een keer en bevestig dat die tonnel vanself opkom, want ’n konfigurasie wat net na handmatige herprobeerslae werk, sal weer misluk by die volgende opstart.