VPN hænger på Connecting i flytilstand: find forbindelsen opad
En klient, der bliver stående på Connecting i flytilstand, har måske simpelthen intet uplink. Skil radiostatus, associering, portallogin og blokeringspolitikken ad.
Telefonen viser flyikonet, VPN-klienten har stået på Connecting i to minutter, og profilen er korrekt. Det virkede for en time siden i samme bygning. Intet er i stykker: en VPN er en forbindelse, der bæres af et andet netværk, og flytilstand fjernede netop det netværk, der bar den. Klienten bliver ved med at prøve, fordi det er, hvad den gør uden et uplink.
Det forvirrede er, at flysymbolet ikke fortæller, om Wi-Fi er tilgængeligt, og Connecting fortæller ikke, om klienten godkender eller blot venter. Skil de to aflæsninger ad, og diagnosen tager et minut.
Flysymbolet er ikke en radioreport
På understøttede Android-enheder kan Wi-Fi og Bluetooth forblive slået til i flytilstand, og enheden husker det valg, du traf sidst. Googles vejledning til flytilstand på Pixel beskriver netop den adfærd. Så ikonet kan betyde, at mobildata er slået fra, og intet andet.
Kontroller den faktiske tilstand i stedet for glyffen. adb shell settings get global airplane_mode_on returnerer 0 eller 1 for selve tilstanden, og adb shell dumpsys connectivity viser de netværk, enheden har i øjeblikket, med deres valideringsstatus. De to output svarer tilsammen på det spørgsmål, ikonet ikke kan.
Hvis Wi-Fi er slået fra, eller slået til men ikke associeret med noget, er der ingen vej til VPN-endepunktet, og ingen mængde genopkobling skaber en. Det er det tilfælde, der er værd at udelukke først, fordi det er det eneste, hvor den rigtige løsning ligger uden for VPN-appen.
Hvad Connecting egentlig betyder
En klient kan holde en gemt profil, vise dens navn og dreje en spinner uden at have kontaktet noget. Konfigurationen er lokal. At etablere en tunnel kræver en nåbar server, et fuldført handshake og et interface at route gennem. Kun den sidste del kræver et fungerende netværk, og derfor kan de to første se vellykkede ud med radioen slukket.
Så spinneren passer til mindst tre forskellige situationer: intet uplink overhovedet, et uplink der ikke kan nå endepunktet, og et uplink der når det men fejler godkendelse. De ser identiske ud på skærmen og helt forskellige ud i en log. Derfor er den første nyttige artefakt i alle disse tilfælde loggen, ikke et nyt forsøg.
Androids egen VPN-dokumentation drager samme grænse mellem etablering af forbindelsen og de separate politikker for altid-til og blokering. Den adskillelse er grunden til, at en telefon kan se beskyttet ud, mens den er offline, og stadig ikke have nogen tunnel.
Fire tilstande, der er værd at skelne
De fire tilstande nedenfor er dem, der er værd at navngive, fordi skærmen viser dem ens.
| 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 række fanger de fleste på hoteller og i lufthavne. Associering er ikke adgang: en portal, der ikke har lukket telefonen igennem, accepterer gerne Wi-Fi-adgangskoden og nægter derefter at sende trafik til VPN-endepunktet. At logge ind via browseren først, mens tunnelen er slukket, er normalt den eneste vej igennem.
Hvorfor blokering får det til at se værre ud
Hvis både altid-til VPN og bloker forbindelser uden VPN er slået til, blokeres hver omfattet app, når tunnelen ikke er oppe. Det er funktionen, der virker, ikke en anden fejl. Symptomet skifter fra én app, der fejler, til alt, der fejler, hvilket læses som et meget større problem.
Det forklarer også den sekvens, folk læser forkert: flytilstand til, intet uplink, apps blokeret, VPN siger connecting. Blokeringen var politikken, der gjorde sit arbejde. At slå politikken fra for at teste uplinket fjerner den beskyttelse, du formodentlig ville have, og lærer dig intet.
Kontroller i stedet omfanget. Hvilke apps er omfattet, hvilke er undtaget, og om profilen er per bruger eller for hele enheden. En opgave, der starter VPN-appen, når Wi-Fi dukker op, er en trigger, ikke en garanti for, at ingen pakke forlod enheden, før den kørte.
En diagnostisk rækkefølge, der stopper gætteriet
Arbejd nedefra og op. Bekræft tilstanden, bekræft at der findes et netværk, bekræft at det er valideret, bekræft at det kan nå noget uden for det lokale subnet, og se først derefter på klienten. adb shell ping -c 3 1.1.1.1 er en grov test, men den skiller en manglende vej fra en vej, der findes, mens tunnelen er utilfreds.
Hvis ping fejler, mens et netværk er opført, ligger problemet opstrøms for VPN'en, og ingen klientindstilling retter det. Hvis ping lykkes, og tunnelen stadig ikke etableres, skal du tage klientens log netop da: fejlen vil skelne en timeout fra en afvisning af godkendelse, og de to har intet til fælles.
Slut af med at genskabe den tilsigtede tilstand: Wi-Fi tilladt i flytilstand, hvis det er din normale opsætning, portalen gennemført, og blokeringspolitikken slået til igen. Genopret derefter forbindelsen én gang og bekræft, at tunnelen kommer op af sig selv, fordi en konfiguration, der kun virker efter manuelle forsøg, vil fejle igen ved næste opstart.