VpnService protect() apo përjashtimi i aplikacionit: cila rregullon drejtimin

Ka dy mënyra për t'i mbajtur paketat e vetë tunelit jashtë tunelit: mbroni socket-in e transportit, ose nxirrni të gjithë aplikacionin nga VPN-ja. Zgjidhin probleme të ndryshme, dhe zgjedhja e më të gjerës vetëm sepse lidhet më lehtë është pikërisht ajo që u bën aplikacioneve të humbin pa e vënë re aksesin në rrjetin lokal dhe DNS-në e ndarë. Filloni nga ajo që duhet të mbetet jashtë tunelit, pastaj zgjidhni shtrirjen më të vogël që e arrin atë.

Çfarë heq protect() nga tuneli

VpnService.protect() është një thirrje për socket të vetëm. I jepni socket-in ose deskriptorin që mbart tunelin, dhe Android e shënon atë socket që trafiku i tij të përdorë rrjetin bazë në vend të ndërfaqes VPN. Çdo gjë tjetër që dërgon aplikacioni vazhdon të ndjekë rrugën normale të VPN-së.

Pikërisht kjo shtrirje e ngushtë është qëllimi. Një socket i mbrojtur nuk ndryshon mënyrën se si klienti juaj HTTP i zgjidh emrat, cilën ndërfaqe përdorin thirrjet tuaja analitike, as çfarë ndodh me një lidhje të dytë që hapet më vonë.

Tre kushtet që përcaktojnë shtrirjen

Kushti i parë është nëse duhet të dalë vetëm transporti i tunelit. Nëse trafiku tjetër i aplikacionit duhet të vazhdojë të kalojë nëpër VPN, mbrojtja e socket-it është shtrirja e saktë. Kushti i dytë është nëse krijimi i socket-ave është nën kontrollin tuaj. Një bibliotekë që hap socket-in e vet thellë brenda nuk ju lë vend të thërrisni protect(), përveçse nëse ofron një grep ose pranon një socket të parandërtuar. Kushti i tretë është nëse aplikacioni duhet të arrijë drejtpërdrejt rrjetin lokal ose portalin e hyrjes së detyruar, që është kërkesë tjetër nga mbajtja gjallë e tunelit.

Përjashtimi i aplikacionit me addDisallowedApplication() është mjeti i pagdhendur. Heq nga VPN-ja çdo lidhje që krijon aplikacioni, përfshirë ato që donit t'i inspektonit, dhe në disa pajisje ndryshon edhe sjelljen e zbulimit lokal.

Opsioni i tretë është lidhja e transportit me një rrjet të zgjedhur me bindProcessToNetwork() ose me një dorezë rrjeti në nivel socket-i. Kjo është e dobishme kur pajisja ka njëkohësisht Wi-Fi dhe celular dhe doni që tuneli të kalojë në një lidhje të caktuar.

Thirreni gjatë krijimit të transportit

Thirrni protect() në të njëjtin bllok që krijon transportin, përpara connect() ose send(). Nëse thirrja kthen false, mbyllni socket-in dhe dështoni konfigurimin; vazhdimi ju lë me një transport, paketat e të cilit mund të rihyjnë në ndërfaqen tuaj.

Forma është mjaft e vogël për ta mbajtur në një vend:

DatagramSocket transport = new DatagramSocket();
if (!protect(transport)) {
    transport.close();
    throw new IOException("transport not protected");
}
transport.connect(serverAddress);

Tre detaje kafshojnë këtu. Së pari, vlera boolean është sinjali i vetëm që merrni, prandaj regjistroni dështimin me kontekst të mjaftueshëm për të dalluar një pëlqim të revokuar nga një thirrje e refuzuar. Së dyti, protect() mbulon socket-in, jo numrin e deskriptorit: nëse mbyllni socket-in dhe më vonë ripërdorni të njëjtin numër të plotë për një socket tjetër, socket-i i ri nuk mbrohet. Së treti, kur një bibliotekë native hap transportin, mbroni deskriptorin përpara se kodi native të lidhet, përndryshe rruga mund të jetë zgjedhur tashmë. Referenca e VpnService është vendi për të konfirmuar mbingarkesat që ofron në të vërtetë niveli juaj i synuar API.

Provoni rrugën e bllokuar, jo vetëm atë të suksesshmen

Verifikoni me tunelin të ngritur, sepse kjo është e vetmja gjendje në të cilën dy rrugët mund të ndryshojnë. Dërgoni një kërkesë përmes transportit të mbrojtur dhe një nga një rrugë kodi që nuk thirri kurrë protect(), pastaj krahasoni atë që sheh skaji i largët: lidhja e mbrojtur duhet të mbërrijë me rrjetin bazë si burim, ndërsa ajo e pambrojtur tregon adresën e vetë tunelit dhe lëviz numëruesit e bajtave të tunelit. Në pajisje, ss ose netstat tregon të njëjtën ndarje përpara se diçka të largohet nga radioja.

Provoni revokimin veçmas, sepse një ndryshim pëlqimi shemb ndërfaqen pa prekur kodin tuaj të socket-it. Revokoni pëlqimin e VPN-së ose ndaloni shërbimin, rindërtoni transportin dhe konfirmoni që protect() kthen ende true dhe që transporti rilidhet sapo pëlqimi jepet përsëri.

Nëse kërkesa e mbrojtur ndjek tunelin gjithsesi, thirrja e mbrojtjes ndodh me gjasë pasi socket-i është drejtuar tashmë. Zhvendoseni më herët dhe provoni përsëri.

Mbajeni vendimin të shkruar pranë konfigurimit të transportit: cilat socket-a janë të mbrojtur, cili trafik aplikacioni përjashtohet dhe çfarë bën aplikacioni kur mbrojtja dështon. Pikërisht ajo rresht ndalon që një ristrukturim i mëvonshëm të zgjerojë përjashtimin në të gjithë aplikacionin sepse një test i vetëm dështonte. I jep gjithashtu personit të radhës një mënyrë për të kontrolluar qëllimin pa rikonstruktuar manifestin.