VPN fastnar på Connecting i flygplansläge: hitta upplänken
En klient som blir kvar på Connecting i flygplansläge har kanske helt enkelt ingen upplänk. Skilj på radiostatus, anslutning, portalinloggning och blockeringsprincipen.
Telefonen visar flygplansikonen, VPN-klienten har stått på Connecting i två minuter och profilen är korrekt. Det fungerade för en timme sedan i samma byggnad. Inget är trasigt: en VPN är en anslutning som bärs av ett annat nätverk, och flygplansläget tog just bort nätverket som bar den. Klienten fortsätter försöka, för det är vad den gör utan en upplänk.
Det förvirrande är att flygplanssymbolen inte säger om Wi-Fi är tillgängligt, och Connecting säger inte om klienten autentiserar eller bara väntar. Skilj på dessa två avläsningar och diagnosen tar en minut.
Flygplanssymbolen är ingen radiorapport
På Android-enheter som stöds kan Wi-Fi och Bluetooth vara på i flygplansläge, och enheten kommer ihåg valet du gjorde förra gången. Googles vägledning för flygplansläge på Pixel beskriver precis det beteendet. Ikonen kan alltså bara betyda att mobilnätet är av, och inget mer.
Kontrollera det faktiska tillståndet i stället för glyfen. adb shell settings get global airplane_mode_on returnerar 0 eller 1 för själva läget, och adb shell dumpsys connectivity listar nätverken enheten har just nu, med deras valideringsstatus. Dessa två utdata svarar tillsammans på frågan som ikonen inte kan.
Om Wi-Fi är av, eller på men inte anslutet till något, finns ingen väg till VPN-slutpunkten och ingen mängd återanslutningar skapar en. Det är fallet som är värt att utesluta först, eftersom det är det enda där den rätta åtgärden ligger utanför VPN-appen.
Vad Connecting egentligen betyder
En klient kan hålla en sparad profil, visa dess namn och snurra en indikator utan att ha kontaktat något. Konfigurationen är lokal. Att bygga en tunnel kräver en nåbar server, ett slutfört handskakning och ett gränssnitt att routa genom. Bara den sista delen behöver ett fungerande nätverk, och därför kan de två första se lyckade ut med radion av.
Så indikatorn stämmer med minst tre olika situationer: ingen upplänk alls, en upplänk som inte når slutpunkten, och en upplänk som når den men misslyckas med autentiseringen. De ser identiska ut på skärmen och helt olika ut i en logg. Därför är den första användbara artefakten i alla dessa fall loggen, inte ett nytt försök.
Androids egen VPN-dokumentation drar samma gräns mellan att upprätta anslutningen och de separata principerna alltid-på och blockering. Den uppdelningen är anledningen till att en telefon kan se skyddad ut när den är offline och ändå inte ha någon tunnel.
Fyra tillstånd som är värda att skilja på
De fyra tillstånden nedan är de som är värda att namnge, eftersom skärmen visar dem likadant.
| 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 fångar de flesta på hotell och flygplatser. Anslutning är inte tillträde: en portal som inte har släppt igenom telefonen tar gärna emot Wi-Fi-lösenordet och vägrar sedan släppa igenom trafik till VPN-slutpunkten. Att logga in via webbläsaren först, med tunneln av, är oftast den enda vägen igenom.
Varför blockering får det att se värre ut
Om både alltid-på-VPN och blockera anslutningar utan VPN är på, blockeras varje täckt app när tunneln inte är uppe. Det är funktionen som arbetar, inte ett andra fel. Symtomet ändras från en app som misslyckas till att allt misslyckas, vilket läses som ett mycket större problem.
Det förklarar också sekvensen folk läser fel: flygplansläge på, ingen upplänk, appar blockerade, VPN säger connecting. Blockeringen var principen som gjorde sitt jobb. Att stänga av principen för att testa upplänken tar bort det skydd du förmodligen ville ha och lär dig ingenting.
Kontrollera i stället omfattningen. Vilka appar som täcks, vilka som undantas och om profilen är per användare eller för hela enheten. En uppgift som startar VPN-appen så snart Wi-Fi dyker upp är en utlösare, inte en garanti för att inget paket gick ut innan den kördes.
En diagnostisk ordning som avslutar gissandet
Arbeta nedifrån och upp. Bekräfta läget, bekräfta att ett nätverk finns, att det är validerat, att det kan nå något utanför det lokala subnätet, och titta först då på klienten. adb shell ping -c 3 1.1.1.1 är ett grovt test, men det skiljer en saknad väg från en väg som finns medan tunneln är missnöjd.
Om ping misslyckas medan ett nätverk listas ligger problemet ovanför VPN:n och ingen klientinställning åtgärdar det. Om ping lyckas och tunneln ändå inte upprättas, fånga klientens logg i det ögonblicket: felet skiljer en tidsgräns från en avvisad autentisering, och de två har inget gemensamt.
Avsluta med att återställa det avsedda tillståndet: Wi-Fi tillåtet i flygplansläge om det är din vanliga uppsättning, portalen slutförd och blockeringsprincipen på igen. Anslut sedan en gång och bekräfta att tunneln kommer upp av sig själv, eftersom en konfiguration som bara fungerar efter manuella försök kommer att misslyckas igen vid nästa start.