Pse tuneli juaj Android VpnService ndalon së drejtuari trafikun

Katër supozime për Android VpnService më kushtuan një herë pjesën më të madhe të një jave, dhe asnjëra nuk kishte të bënte me protokollin e rrjetit. Aplikacioni thoshte i lidhur, ikona e çelësit rrinte në shiritin e statusit dhe trafiku vazhdonte të dilte përmes rrugës normale. Vazhdoja të supozoja se tuneli ishte imi derisa ta ndal, se rrugët që shtoja ishin rrugët që merrja dhe se thirrja e stopSelf do të nxirrte ndërfaqen bashkë me të. Shërbimi sillete saktësisht siç është dokumentuar. Pjesa e thyer ishte modeli im mendor.

Miti 1: tuneli qëndron në këmbë derisa ta ndalni

Android mban një ndërfaqe VPN në një kohë. Vendosni një të dytë dhe platforma nuk e vë në radhë: çaktivizon tuajën dhe thërret onRevoke() në shërbimin tuaj. Nëse kodi juaj shemb gjithçka vetëm kur shtypet një buton, një marrje kontrolli lë pas një përshkrues dhe një fije leximi, dhe nisja tjetër trashëgon të dyja.

Referenca e VpnService thotë shprehimisht se prepare() kthen null kur aplikacioni ka tashmë pëlqimin dhe një Intent kur përdoruesi duhet ende ta miratojë. Ky pëlqim arrin vetëm nëse e dorëzoni qëllimin përmes startActivityForResult(). Kalo dorëzimin dhe establish() kthen null, që lexohet si dështim i heshtur dhe jo si problem leje.

Always-on VPN shton një pronar që ju nuk e kontrolloni. Sistemi mund ta kthejë tunelin pas nisjes ose pas një rrëzimi, dhe i kalon përpara një aplikacioni VPN që përdoruesi e nisi me dorë. Ndërtojeni onRevoke() të mbyllë të njëjtat burime si mbyllja juaj normale, dhe trajtojeni si rrugë kryesore ndalimi dhe jo si rast qoshe. Përdoruesit ndryshojnë aplikacione VPN; kodi juaj duhet t'i rezistojë kësaj.

Miti 2: addRoute kap saktësisht atë që keni listuar

Rrugët vendosin cilat paketa arrijnë në përshkruesin tuaj, dhe një gabim në shtrirje prodhon rastin e tërbuar ku një pjesë e trafikut kalon nëpër tunel dhe një pjesë jo. addRoute("0.0.0.0", 0) merr të gjithë IPv4, që do të thotë se çdo paketë tani vjen te ju dhe duhet të përcillet ose të hidhet. Një /32 për një host të vetëm nuk merr pothuajse asgjë, dhe gjithçka tjetër sillet sikur VPN-ja juaj nuk është instaluar kurrë.

Familjet numërohen veçmas. Një rrugë vetëm IPv4 e lë IPv6 në rrjetin themelor, kështu që një host me dy stiva mund ende të zgjidhë dhe të lidhet jashtë tunelit ndërsa brenda duket plotësisht i lidhur.

DNS ndjek të njëjtën logjikë. Serverët e shtuar me addDnsServer() shkojnë te aplikacionet që përdorin zgjidhësin e tunelit, ndërsa një aplikacion me pikë fundore DNS të kriptuar të vetën ose Private DNS të vendosur në një emër hosti i injoron plotësisht. Kur emrat dështojnë për një aplikacion dhe funksionojnë për një tjetër, kontrolloni rrugën e zgjidhësit përpara se të prekni qoftë një rrugë.

Miti 3: rregullat për aplikacion janë një çelës që mund ta ktheni në çdo drejtim

addDisallowedApplication() dhe addAllowedApplication() janë dy mënyra, jo dy filtra. Ndërtuesi pranon një model për tunel, kështu që një aplikacion që do gjithçka përveç tre paketave përdor listën e ndaluar dhe e lë listën e lejuar bosh. Të dyja përjashtojnë njëra-tjetrën, dhe njerëzit e zbulojnë këtë në kohë ekzekutimi pasi ekrani i cilësimeve ka ofruar tashmë të dy çelësat.

Dukshmëria e paketave gjithashtu kafshon. Në Android 11 e tutje mund të emërtoni vetëm paketa që i shihni, kështu që një listë përjashtimesh e ndërtuar nga një pyetje që aplikacioni juaj nuk lejohet ta ekzekutojë do të humbasë zëra në heshtje. Krahasoni listën me atë që menaxheri i paketave kthen vërtet përpara se t'i besoni.

Profilet e punës e ndajnë përsëri audiencën. Një tunel i nisur brenda profilit mbulon atë profil dhe aplikacionet e tij, ndërsa ana personale mban lidhjen e vet. Ky është një vendim shtrirjeje i marrë një herë, dhe vendi i tij është në ndërfaqe, jo në një biletë suporti.

Miti 4: stopSelf e përfundon tunelin

Jo. Ndërfaqja jeton në përshkruesin që kthen establish(), dhe objekti i shërbimit mund të vdesë ndërsa ai përshkrues mbetet i hapur. Mbyllni së pari ParcelFileDescriptor, lëshoni referencën, bashkoni ose ndërpritni fijet e leximit dhe shkrimit, pastaj thirrni stopForeground(true) dhe stopSelf() në atë rend.

Një përshkrues i harruar është arsyeja e zakonshme pse një shërbim duket se i mbijeton kërkesës së vet për ndalim, dhe shpjegon një rrugë të vjetruar që jeton më gjatë se aplikacioni që e shtoi.

Gabimi i kundërt është po aq i zakonshëm: mbyllja e përshkruesit ndërsa një fije leximi është në mes të leximit, dhe pastaj lënia e asaj fije të merret me një përjashtim për të cilin askush nuk shkroi kod. Mbani sekuencën e mbylljes në një vend dhe lërini si veprimin e përdoruesit ashtu edhe onRevoke() të thërrasin atje.

Çfarë të kontrolloni kur tuneli duket i vdekur

Mbrojini prizat jetëgjatë me protect() përpara se tuneli të ngrihet. Pa të, transporti i vetë tunelit ridrejtohet përsëri brenda tunelit dhe lidhja ngec në një mënyrë që duket saktësisht si defekt serveri. Testoni kundër një adrese që ekziston vetëm prapa rrjetit të largët, jo kundër një faqe publike që përgjigjet nga kafja ose nga rruga themelore.

Regjistroni rezultatin e establish(), rrugët, paketat e përjashtuara dhe arsyen e mbylljes. Ato katër rreshta ndajnë një problem pëlqimi nga një problem shtrirjeje dhe nga një problem cikli jetësor pa kapur paketa.