VPN heng på Connecting i flymodus: finn oppkoblinga
Ein klient som blir ståande på Connecting i flymodus har kanskje rett og slett inga oppkobling. Skil radiostatus, tilknyting, portallogg inn og blokkeringspolicyen.
Telefonen viser flyikonet, VPN-klienten har stått på Connecting i to minutt, og profilen er riktig. Det virka for ein time sidan i same bygget. Ingenting er øydelagt: ein VPN er ei tilkopling som blir boren av eit anna nettverk, og flymodus fjerna nettopp nettverket som bar henne. Klienten held fram med å prøve, fordi det er det han gjer utan oppkobling.
Det forvirrande er at flysymbolet ikkje fortel om Wi-Fi er tilgjengeleg, og Connecting fortel ikkje om klienten autentiserer eller berre ventar. Skil desse to avlesingane, og diagnosen tek eit minutt.
Flysymbolet er ikkje ein radiorapport
På støtta Android-einingar kan Wi-Fi og Bluetooth stå på i flymodus, og eininga hugsar valet du tok sist. Googles rettleiing for flymodus på Pixel skildrar nettopp denne åtferda. Så ikonet kan berre bety at mobilnettet er av, og ikkje noko meir.
Kontroller den faktiske tilstanden i staden for glyfen. adb shell settings get global airplane_mode_on returnerer 0 eller 1 for sjølve modusen, og adb shell dumpsys connectivity listar opp nettverka eininga har no, med valideringsstatus. Desse to utdataa svarar saman på spørsmålet ikonet ikkje kan.
Er Wi-Fi av, eller på men ikkje tilknytt noko, finst det ingen veg til VPN-endepunktet, og inga mengd gjenoppkopling skaper ein. Det er tilfellet som er verdt å utelukke først, fordi det er det einaste der den rette løysinga ligg utanfor VPN-appen.
Kva Connecting eigentleg betyr
Ein klient kan halde ein lagra profil, vise namnet og spinne ein indikator utan å ha kontakta noko. Konfigurasjonen er lokal. Å byggje ein tunnel krev ein nåbar tenar, eit fullført handtrykk og eit grensesnitt å rute gjennom. Berre den siste delen treng eit fungerande nettverk, og difor kan dei to første sjå vellukka ut med radioen av.
Så indikatoren passar med minst tre ulike situasjonar: inga oppkobling i det heile, ei oppkobling som ikkje når endepunktet, og ei oppkobling som når det men feilar på autentisering. Dei ser identiske ut på skjermen og heilt ulike ut i ein logg. Difor er det første nyttige artefaktet i alle desse tilfella loggen, ikkje eit nytt forsøk.
Androids eigen VPN-dokumentasjon dreg same grensa mellom etablering av tilkoplinga og dei separate retningslinjene for alltid-på og blokkering. Denne delinga er grunnen til at ein telefon kan sjå verna ut medan han er fråkopla og likevel ikkje ha nokon tunnel.
Fire tilstandar det er verdt å skilje
Dei fire tilstandane nedanfor er dei som er verdt å namngje, fordi skjermen viser dei likt.
| 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 |
Den tredje rada fangar dei fleste på hotell og flyplassar. Tilknyting er ikkje tilgang: ein portal som ikkje har sleppt telefonen gjennom, godtek gjerne Wi-Fi-passordet og nektar deretter å sleppe trafikk gjennom til VPN-endepunktet. Å logge på via nettlesaren først, medan tunnelen er av, er vanlegvis den einaste vegen gjennom.
Kvifor blokkering får det til å sjå verre ut
Viss både alltid-på VPN og blokker tilkoplingar utan VPN er slått på, blir kvar dekte app blokkert når tunnelen ikkje er oppe. Det er funksjonen som verkar, ikkje ein annan feil. Symptomet endrar seg frå éin app som feilar til at alt feilar, noko som blir lese som eit mykje større problem.
Det forklarar òg sekvensen folk les feil: flymodus på, inga oppkobling, appane blokkerte, VPN seier connecting. Blokkeringa var policyen som gjorde jobben sin. Å slå av policyen for å teste oppkoblinga fjernar vernet du truleg ville ha, og lærer deg ingenting.
Kontroller i staden omfanget. Kva appane er dekte, kva som er unnateke, og om profilen er per brukar eller for heile eininga. Ei oppgåve som startar VPN-appen når Wi-Fi dukkar opp, er ein utløysar, ikkje ei garanti for at ingen pakke gjekk ut før han køyrde.
Ein diagnostisk rekkjefølgje som avsluttar gjettinga
Arbeid nedanfrå og opp. Stadfest modusen, stadfest at det finst eit nettverk, at det er validert, at det kan nå noko utanfor det lokale subnettet, og sjå først då på klienten. adb shell ping -c 3 1.1.1.1 er ein grov test, men han skil ein manglande veg frå ein veg som finst medan tunnelen er misnøgd.
Viss ping feilar medan eit nettverk er oppført, ligg problemet oppstraums for VPN-en, og inga klientinnstilling rettar det. Viss ping lukkast og tunnelen framleis ikkje blir etablert, ta loggen frå klienten i det augneblikket: feilen vil skilje ein tidsavbrot frå ei avvist autentisering, og dei to har ingenting til felles.
Avslutt med å gjenopprette den tiltenkte tilstanden: Wi-Fi tillate i flymodus viss det er din vanlege oppsett, portalen fullført og blokkeringspolicyen på igjen. Kopla så til éin gong og stadfest at tunnelen kjem opp av seg sjølv, fordi ein konfigurasjon som berre verkar etter manuelle forsøk, vil feile igjen ved neste oppstart.