VPN henger på Connecting i flymodus: finn oppkoblingen
En klient som blir stående på Connecting i flymodus har kanskje rett og slett ingen oppkobling. Skill radiostatus, tilknytning, portallogging og blokkeringspolicyen.
Telefonen viser flyikonet, VPN-klienten har stått på Connecting i to minutter, og profilen er riktig. Det virket for en time siden i samme bygning. Ingenting er ødelagt: en VPN er en forbindelse som bæres av et annet nettverk, og flymodus fjernet nettopp nettverket som bar den. Klienten fortsetter å prøve, fordi det er det den gjør uten en oppkobling.
Det forvirrende er at flysymbolet ikke forteller om Wi-Fi er tilgjengelig, og Connecting forteller ikke om klienten autentiserer eller bare venter. Skill disse to avlesningene, og diagnosen tar et minutt.
Flysymbolet er ikke en radiorapport
På støttede Android-enheter kan Wi-Fi og Bluetooth være på i flymodus, og enheten husker valget du tok sist. Googles veiledning for flymodus på Pixel beskriver nettopp denne oppførselen. Så ikonet kan bety at mobilnettet er av, og ikke noe mer.
Kontroller den faktiske tilstanden i stedet for glyfen. adb shell settings get global airplane_mode_on returnerer 0 eller 1 for selve modusen, og adb shell dumpsys connectivity lister opp nettverkene enheten har nå, med valideringsstatus. Disse to utdataene svarer sammen på spørsmålet ikonet ikke kan.
Hvis Wi-Fi er av, eller på men ikke tilknyttet noe, finnes det ingen vei til VPN-endepunktet, og ingen mengde gjenoppkobling vil skape en. Det er tilfellet som er verdt å utelukke først, fordi det er det eneste der den riktige løsningen ligger utenfor VPN-appen.
Hva Connecting egentlig betyr
En klient kan holde en lagret profil, vise navnet og spinne en indikator uten å ha kontaktet noe. Konfigurasjonen er lokal. Å bygge en tunnel krever en nåbar server, en fullført håndtrykk og et grensesnitt å rute gjennom. Bare den siste delen trenger et fungerende nettverk, og derfor kan de to første se vellykkede ut med radioen av.
Så indikatoren passer med minst tre forskjellige situasjoner: ingen oppkobling i det hele tatt, en oppkobling som ikke når endepunktet, og en oppkobling som når det men feiler på autentisering. De ser identiske ut på skjermen og helt forskjellige ut i en logg. Derfor er det første nyttige artefaktet i alle disse tilfellene loggen, ikke et nytt forsøk.
Androids egen VPN-dokumentasjon trekker samme grense mellom etablering av forbindelsen og de separate retningslinjene for alltid-på og blokkering. Denne delingen er grunnen til at en telefon kan se beskyttet ut mens den er frakoblet og likevel ikke ha noen tunnel.
Fire tilstander det er verdt å skille
De fire tilstandene nedenfor er de som er verdt å navngi, fordi skjermen viser dem 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 raden fanger de fleste på hoteller og flyplasser. Tilknytning er ikke adgang: en portal som ikke har sluppet telefonen gjennom, godtar gjerne Wi-Fi-passordet og nekter deretter å slippe trafikk gjennom til VPN-endepunktet. Å logge på via nettleseren først, mens tunnelen er av, er vanligvis den eneste veien gjennom.
Hvorfor blokkering får det til å se verre ut
Hvis både alltid-på VPN og blokker tilkoblinger uten VPN er slått på, blokkeres hver dekkede app når tunnelen ikke er oppe. Det er funksjonen som virker, ikke en annen feil. Symptomet endres fra én app som feiler til at alt feiler, noe som leses som et mye større problem.
Det forklarer også sekvensen folk leser feil: flymodus på, ingen oppkobling, apper blokkert, VPN sier connecting. Blokkeringen var policyen som gjorde jobben sin. Å slå av policyen for å teste oppkoblingen fjerner beskyttelsen du antakelig ville ha, og lærer deg ingenting.
Kontroller i stedet omfanget. Hvilke apper er dekket, hvilke er unntatt, og om profilen er per bruker eller for hele enheten. En oppgave som starter VPN-appen når Wi-Fi dukker opp, er en utløser, ikke en garanti for at ingen pakke gikk ut før den kjørte.
En diagnostisk rekkefølge som avslutter gjettingen
Arbeid nedenfra og opp. Bekreft modusen, bekreft at det finnes et nettverk, at det er validert, at det kan nå noe utenfor det lokale subnettet, og se først da på klienten. adb shell ping -c 3 1.1.1.1 er en grov test, men den skiller en manglende vei fra en vei som finnes mens tunnelen er misfornøyd.
Hvis ping feiler mens et nettverk er oppført, ligger problemet oppstrøms for VPN-en, og ingen klientinnstilling retter det. Hvis ping lykkes og tunnelen fortsatt ikke etableres, ta loggen fra klienten i det øyeblikket: feilen vil skille en tidsavbrudd fra en avvist autentisering, og de to har ingenting til felles.
Avslutt med å gjenopprette den tiltenkte tilstanden: Wi-Fi tillatt i flymodus hvis det er din vanlige oppsett, portalen fullført og blokkeringspolicyen på igjen. Koble så til én gang og bekreft at tunnelen kommer opp av seg selv, fordi en konfigurasjon som bare virker etter manuelle forsøk, vil feile igjen ved neste oppstart.