VPN blijft hangen op Connecting in vliegtuigmodus: vind de uplink
Een client die in vliegtuigmodus op Connecting blijft staan, heeft misschien simpelweg geen uplink. Scheid de radiostatus, de associatie, de portaal-login en het blokkeringsbeleid.
De telefoon toont het vliegtuigpictogram, de VPN-client staat al twee minuten op Connecting en het profiel klopt. Een uur geleden werkte het in hetzelfde gebouw. Er is niets stuk: een VPN is een verbinding die door een ander netwerk wordt gedragen, en de vliegtuigmodus heeft net het netwerk weggehaald dat hem droeg. De client blijft het proberen, want dat is wat hij doet zonder uplink.
Verwarrend is dat het vliegtuigsymbool niet zegt of Wi-Fi beschikbaar is, en Connecting niet zegt of de client authenticeert of alleen wacht. Scheid die twee lezingen en de diagnose kost een minuut.
Het vliegtuigsymbool is geen radioverslag
Op ondersteunde Android-apparaten kunnen Wi-Fi en Bluetooth in vliegtuigmodus aanblijven, en het apparaat onthoudt de keuze die je de vorige keer maakte. De richtlijnen van Google over vliegtuigmodus op Pixel beschrijven precies dat gedrag. Het pictogram kan dus alleen betekenen dat mobiel uit staat, en niets meer.
Controleer de werkelijke toestand in plaats van de glyph. adb shell settings get global airplane_mode_on geeft 0 of 1 voor de modus zelf, en adb shell dumpsys connectivity somt de netwerken op die het apparaat nu heeft, met hun validatiestatus. Die twee uitvoer samen beantwoordt de vraag die het pictogram niet kan.
Staat Wi-Fi uit, of aan maar nergens aan gekoppeld, dan is er geen pad naar het VPN-eindpunt en geen enkele hoeveelheid opnieuw verbinden maakt er een. Dat is het geval dat je het eerst wilt uitsluiten, want het is het enige waarbij de juiste oplossing buiten de VPN-app ligt.
Wat Connecting werkelijk betekent
Een client kan een opgeslagen profiel vasthouden, de naam tonen en een spinner laten draaien zonder iets te hebben benaderd. De configuratie is lokaal. Een tunnel opzetten vereist een bereikbare server, een voltooide handshake en een interface om doorheen te routeren. Alleen dat laatste deel heeft een werkend netwerk nodig, daarom kunnen de eerste twee er geslaagd uitzien terwijl de radio uit staat.
De spinner past dus bij minstens drie verschillende situaties: helemaal geen uplink, een uplink die het eindpunt niet bereikt, en een uplink die het wel bereikt maar faalt op authenticatie. Op het scherm zien ze er identiek uit en in een log volledig anders. Daarom is het eerste nuttige artefact in al deze gevallen het log, niet nog een poging.
De eigen VPN-documentatie van Android trekt dezelfde grens tussen het opzetten van de verbinding en de aparte beleidsregels voor altijd-aan en blokkeren. Die scheiding is de reden dat een telefoon beschermd kan lijken terwijl hij offline is en toch geen tunnel heeft.
Vier toestanden die het waard zijn te onderscheiden
De vier toestanden hieronder zijn degene die het waard zijn te benoemen, omdat het scherm ze identiek weergeeft.
| 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 |
De derde rij vangt de meeste mensen in hotels en op luchthavens. Associatie is geen toegang: een portaal dat de telefoon niet heeft doorgelaten, accepteert graag het Wi-Fi-wachtwoord en weigert daarna verkeer naar het VPN-eindpunt door te laten. Eerst via de browser inloggen, terwijl de tunnel uit staat, is meestal de enige weg erdoor.
Waarom blokkeren het erger laat lijken
Als altijd-aan-VPN en verbindingen zonder VPN blokkeren beide aan staan, wordt elke gedekte app geblokkeerd zodra de tunnel niet staat. Dat is de functie die werkt, niet een tweede storing. Het symptoom verandert van één app die faalt naar alles wat faalt, wat als een veel groter probleem leest.
Het verklaart ook de volgorde die mensen verkeerd lezen: vliegtuigmodus aan, geen uplink, apps geblokkeerd, VPN zegt connecting. De blokkade was het beleid dat zijn werk deed. Het beleid uitzetten om de uplink te testen haalt de bescherming weg die je vermoedelijk wilde en leert je niets.
Controleer in plaats daarvan de reikwijdte. Welke apps zijn gedekt, welke uitgesloten, en of het profiel per gebruiker of apparaatbreed is. Een taak die de VPN-app start zodra Wi-Fi verschijnt, is een trigger, geen garantie dat er geen pakket naar buiten ging voordat hij liep.
Een diagnosevolgorde die het gissen beëindigt
Werk van onderaf. Bevestig de modus, bevestig dat er een netwerk is, dat het gevalideerd is, dat het iets buiten het lokale subnet kan bereiken, en kijk pas dan naar de client. adb shell ping -c 3 1.1.1.1 is een grove test, maar hij scheidt een ontbrekend pad van een pad dat bestaat terwijl de tunnel ontevreden is.
Mislukt de ping terwijl er een netwerk in de lijst staat, dan zit het probleem boven de VPN en geen enkele clientinstelling lost dat op. Lukt de ping en komt de tunnel toch niet op, leg dan op dat moment het log van de client vast: de fout onderscheidt een time-out van een weigering van authenticatie, en die twee hebben niets gemeen.
Sluit af door de bedoelde toestand te herstellen: Wi-Fi toegestaan in vliegtuigmodus als dat je normale opzet is, het portaal voltooid en het blokkeringsbeleid weer aan. Verbind daarna één keer opnieuw en bevestig dat de tunnel vanzelf omhoogkomt, want een configuratie die pas na handmatige pogingen werkt, faalt bij de volgende start weer.