Android-program weier om oor VPN te werk: watter laag besluit

Wanneer ’n Android-program stop om te werk op die oomblik dat die tonnel opkom, kan drie verskillende dinge verantwoordelik wees, en hulle lewer soortgelyke mislukkings. Die program kan die foon se eie netwerktoestand lees en plaaslik weier. Die bediener kan die adres waarvan jy kom klassifiseer en dit verwerp. Of die weiering kan heeltemal niks met die VPN te doen hê nie. Die orde hieronder versamel bewyse voordat dit iets verander, want om die uitgang te verander is die duurste stap en die een wat die minste waarskynlik sal help as die kontrole plaaslik is.

Stap 1: vind uit wanneer die program weier

Tydsberekening is die eerste onderskeider. Maak die logbuffer skoon, reproduseer die fout en kyk wat die program gedoen het voordat dit gekla het:

adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60

As die program weier voordat enige uitgaande versoek probeer word, kyk jy na ’n plaaslike besluit. As dit verbind, iets stuur en dan ’n fout wys, het die verwerping van die ander kant gekom. As die program identies misluk met die tonnel af, was die VPN nooit die veranderlike nie.

Behandel daardie tydsberekening as bewys eerder as bevestiging. ’n Program kan ’n gekaste antwoord herspeel, en agtergrondversoeke kon voor of na jou kyk geslaag of misluk het. Let op die tydstempels van die laaste suksesvolle versoek en die fout, nie net die oomblik toe die boodskap verskyn het nie.

Stap 2: lees die foon se eie siening van die netwerk

Android stel die VPN-toestand as ’n netwerkeienskap bloot, so ’n program het nie ’n lys kommersiële verskaffers nodig om te merk dat ’n tonnel aktief is nie. Dit vra die konnektiwiteitsdiens wat die huidige netwerk is, en die antwoord sluit ’n VPN-vervoerbis in:

val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true

Daardie kontrole is plaaslik en goedkoop, en dit verduidelik ’n hele klas verslae van “hierdie program werk nie oor VPN nie” sonder enige afstandklassifikasie. Wat die program kan sien, hang steeds van sy eie netwerkkonteks af, so moenie aanneem elke program ondersoek elke profiel op die toestel nie.

Vanaf ’n werkstasie kan jy dieselfde toestand op ’n toestoestel sien met adb shell dumpsys connectivity en deur te soek na die VPN-netwerkinskrywing. Vergelyk ’n lopie met die tonnel op teen een met dit af, en hou beide uitsette.

Stap 3: lees wat die bediener werklik sien

Die ander waarnemer is die diens. Dit sien die bronadres wat aankom, en dit kan optree op die adres, die gasheernetwerk daaragter, die streek, die diensverskaffer of seine wat aan die rekening en toestel gekoppel is. Nie een daarvan is ’n unieke identiteit nie, en gedeelde adressering maak kollaterale blokke normaal: een beperkte adres kan onverwante gebruikers agter dieselfde vertaling uitskakel.

Kry die adres uit dieselfde pad wat die program gebruik, nie uit ’n blaaier op ’n skootrekenaar nie. Op die foon wys ’n gewone versoek aan ’n adreseggodiens wat die verre kant ontvang, en om dit met ’n versoek oor selfoon te vergelyk, sê vir jou of die adres hoegenaamd verander het.

As die program oor selfoon werk en oor die tonnel misluk met ’n identiese rekening, is die verwerping aan die verre kant of in die program se eie beleid. As dit op beide misluk, is die VPN nie die onderskeier nie en moet jy ophou om eindpunte te toets.

Stap 4: pas die bewyse by een van drie uitsprake

Drie kombinasies dek byna elke verslag. ’n Weiering sonder enige uitgaande poging terwyl ’n tonnel aktief is, dui op ’n plaaslike vervoerkontrole. ’n Versoek wat uitgaan en met ’n fout terugkom, ’n tydverloop op ’n spesifieke gasheer of ’n streekboodskap dui op die verre kant. ’n Mislukking wat oor selfoon sonder ’n tonnel herhaal, dui op die rekening, die programweergawe of die diens se eie beleid, en geen VPN-verandering sal dit beweeg nie.

Skryf die uitspraak neer saam met die bewyse wat dit opgelewer het. Die waarde van hierdie stap is dat dit die lus stop waar iemand vier keer uitgangsnodes verander om ’n kontrole reg te maak wat op die handstel loop.

Dit hou ook die bewerings eerlik. Self-hosting verander die eindpunt en sy internetuitgang; dit maak nie dat Android vergeet dat ’n VPN-netwerk aktief is nie, en dit waarborg nie aanvaarding deur ’n diens wat adresse klassifiseer nie. ’n Plaaslike filter kan net so maklik op ’n VPN-netwerk wat jy besit reageer as op ’n kommersiële een.

Stap 5: neem die ondersteunde pad en verifieer dit

Begin met die produk se gedokumenteerde beleid en sy ondersteuningseienaar. Stuur die kliëntweergawe, die presiese boodskap en ’n smal foutvenster; moenie volle verkeersopnames of geloofsbriewe stuur net om te bewys dat ’n fout bestaan nie.

As die diens direkte toegang toelaat en toestelbeleid dit toelaat, is ’n uitsluiting per program die ondersteunde meganisme, en dit verwyder doelbewus daardie program uit die tonnel eerder as om die tonnel te versteek. Die program se verkeer verlaat dan op sy eie pad, wat ’n beleidsbesluit is wat iemand moet besit. Onder ’n opstelling wat sonder VPN blokkeer, kan ’n uitgeslote program bloot konnektiwiteit verloor, so toets daardie kombinasie voordat jy belowe dit werk.

Herhaal ná enige verandering die tydtoets van stap een, bevestig dat die program werk en bevestig dat elke ander program steeds die tonnel gebruik. Herstel dan die vorige opstelling en kyk of die fout terugkeer, want ’n regstelling wat jy nie kan reproduseer nie, is ’n toeval wat jy weer sal teëkom.