VPN pe aplicație în Android: excluderea unei aplicații nu o blochează

Două persoane pun aceeași întrebare și primesc răspunsuri incompatibile, pentru că stau în locuri diferite. Una are deschis ecranul setărilor VPN ale sistemului și editează o listă de aplicații. Cealaltă scrie VpnService.Builder.addDisallowedApplication() într-un editor. Ambele o numesc filtru VPN pe aplicație. Doar una dintre ele deține controlul pe care îl descrie, și niciuna nu blochează nimic.

Începe de la ecranul pe care îl vede utilizatorul

Deschide Setări, găsește intrarea VPN și uită-te la conexiunea care este cu adevărat activă. Dacă clientul oferă o listă pe aplicație, acea listă aparține tunelului propriu al clientului. Platforma nu publică un API general prin care o aplicație neînrudită să poată citi sau edita selecția de aplicații a altui VPN, așa că o a doua aplicație nu poate repara lista în locul utilizatorului.

Aceasta este prima bifurcație a parcursului. Dacă VPN-ul instalat nu are această setare, nu e nimic de ocolit prin cod: funcția lipsește din produsul care deține tunelul. Dacă o are, corecția potrivită este pe acel ecran, făcută de persoana care îl poate deschide.

Urmează pachetul într-un tunel

Când propria aplicație construiește un tunel, creează o interfață TUN și declară ale căror aplicații trafic intră în ea. Apelurile de apartenență au loc înainte de stabilirea interfeței, iar după aceea setul de reguli este fix pentru acea sesiune:

val builder = VpnService.Builder()
builder.addAddress("10.8.0.2", 32)
builder.addRoute("0.0.0.0", 0)
builder.addDisallowedApplication("com.example.bypass")
val tun = builder.establish()   // membership decided here

Acele apeluri se aplică doar tunelului pe care aplicația ta tocmai l-a creat și nimic altceva. Nu sunt o politică la nivelul întregului dispozitiv, nu persistă pentru alți clienți și nu pot ajunge în VPN-ul altcuiva. Când un apel al constructorului aruncă o excepție pentru că pachetul nu poate fi rezolvat, interfața nu este niciodată stabilită, ceea ce este un eșec curat, nu unul silențios.

De ce excluderea părea o blocare

O aplicație exclusă este direcționată în jurul tunelului tău către rețeaua de dedesubt. Este opusul blocării: traficul părăsește în continuare dispozitivul, doar în afara interfeței pe care o controlezi. O aplicație în stil firewall face inversul. Admite traficul aplicației în tunelul propriu și apoi aruncă pachetele, sau refuză să le transmită, așa că interfața este aceeași, iar direcția politicii este inversată.

Munca din spatele acelei inversări nu este un fanion de configurare. Citești pachete IP din descriptorul tunelului, decizi pe flux și apoi le transmiți printr-un socket protejat sau le arunci. Tot ce nu tratezi pur și simplu se oprește, și de aceea un tunel pe jumătate pare o rețea stricată, nu un filtru care funcționează. Dacă scopul este blocarea, bugetează tratarea pachetelor, un serviciu în prim-plan și o politică scrisă pentru traficul pe care nu îl poți clasifica.

Ce se strică atunci când îl construiești singur

Android permite în general un singur VPN activ odată, așa că tunelul tău de filtrare și un tunel de confidențialitate concurează pentru același loc, dacă produsele nu acceptă înlănțuire. VPN-ul mereu activ cu blocarea conexiunilor schimbă modul de eșec într-un fel care contează aici: traficul care nu poate intra în tunel este aruncat în loc să fie trimis direct, ceea ce vrea un design de prevenire a scurgerilor și ceea ce o sesiune de depanare rareori așteaptă.

Vizibilitatea pachetelor este a doua capcană. Rezolvarea numelui de pachet al unei aplicații poate eșua cu NameNotFoundException, iar pe versiunile mai noi de Android setul de pachete pe care îl poți vedea depinde de interogările pe care le-ai declarat. Tratează excepția în loc să presupui că fiecare nume se rezolvă și recitește lista când aplicațiile sunt instalate sau eliminate, în loc să o ții în cache pentru totdeauna.

Dispozitivele gestionate adaugă un al treilea proprietar. O politică de mobilitate de întreprindere poate stabili un VPN pe aplicație sau un profil mereu activ, iar o aplicație obișnuită nu îl poate suprascrie. Verifică dacă dispozitivul este gestionat înainte de a-ți depana propriul cod, pentru că în acel caz lista pe care încerci să o schimbi poate să nu fie editabilă de nimeni care ține telefonul.

Testează cu o aplicație pe care o controlezi

Nu testa cu aplicația pe care încerci să o filtrezi. Folosește o a doua aplicație al cărei comportament de rețea îl poți observa și verifică dacă traficul ei iese prin tunelul tău, în timp ce al țintei nu iese. Dacă ambele rămân înăuntru, politica funcționează și ținta este exclusă; dacă niciuna nu iese, tunelul în sine este greșit, iar lista de aplicații nu este problema.

Apoi decide care dintre trei lucruri construiești de fapt. Un tunel pe aplicație este API-ul constructorului, cu lista ca parte a profilului tău. Un firewall de dispozitiv este tratarea pachetelor plus un ciclu de viață pe care îl poți apăra. Schimbarea VPN-ului altcuiva nu este deloc o cale susținută, iar răspunsul onest acolo este că setarea aparține acelui produs.