Lista e lejuar e Android VpnService: pse faqet e lejuara varen ende

Keni shtuar një domain në listën e lejuar, kërkesa arrin në aplikacionin tuaj, përputhësi kthen lejuar, dhe faqja ende nuk ngarkohet kurrë. Në atë pikë shumica fillojnë të rishkruajnë përputhësin dhe të shtojnë krahasime me karaktere të gjera. Sipas përvojës sime përputhësi zakonisht është i saktë, dhe dështimi qëndron një shtresë më poshtë: në përgjigjen DNS që keni sintetizuar, në rrugën që keni instaluar, ose në socketin që keni përdorur për të përcjellë kërkesën. Lista është pjesa e lehtë; rruga e paketës është vendi ku listat e lejuara thyhen.

Përputhësi rrallë është fajtori

Gjëja e parë që duhet ndarë është e bllokuar nga e prishur. Një emër i bllokuar duhet të dështojë shpejt dhe dukshëm, sepse shfletuesi merr një përgjigje se emri nuk ekziston dhe ndalon. Një emër i prishur varet, provon përsëri përmes IPv6, kalon në një transport tjetër dhe ju lë me një tregues që rrotullohet. Nëse shihni një tregues që rrotullohet, lista juaj e lejuar ndoshta po përgjigjet me diçka me të cilën klienti nuk mund të bëjë asgjë.

Regjistri A bosh është gabimi klasik. Kthimi i NOERROR me zero përgjigje duket si përgjigje e vlefshme, kështu që zgjidhësi stub e pranon, shfletuesi provon përsëri, provon AAAA, provon një zgjidhës tjetër dhe dorëzohet shumë më vonë. Kodi i përgjigjes 3, domethënë NXDOMAIN, me seksionin e pyetjes të përsëritur dhe ID-në e transaksionit të kopjuar, e përfundon bisedën menjëherë. Përdoreni për çdo emër që refuzoni me qëllim.

IPv6 meriton të njëjtin vendim dhe jo një vlerë të paracaktuar. Nëse përgjigjeni NXDOMAIN për A dhe lini AAAA të kalojë, klienti mund të arrijë emrin e bllokuar përmes IPv6 dhe filtri rrjedh. Disa implementime u përgjigjen kërkesave AAAA të bllokuara me një adresë loopback, që lidhja të dështojë menjëherë në vend që të kalojë në alternativë. Zgjidhni një politikë, zbatoni atë në të dy llojet e regjistrave dhe regjistroni të dyja.

Një rrugë që kap gjithçka zotëron gjithçka

Një projekt vetëm me DNS nuk shton kurrë addRoute("0.0.0.0", 0), kështu që vetëm kërkesat hyjnë në ndërfaqen TUN dhe gjithçka tjetër vazhdon të përdorë rrjetin themelor. Kjo është forma e sigurt, dhe shpjegon gjithashtu pse disa lista të lejuara duken se funksionojnë në Wi-Fi dhe dështojnë në rrjetin celular.

Në momentin që ekziston një rrugë e paracaktuar, çdo rrjedhë është e jotja. Një paketë TCP që arrin në ndërfaqe dhe as përcillet as përgjigjet qëndron në radhë derisa klientit t'i mbarojë koha, dhe nuk ka gabim për të regjistruar sepse asgjë nuk dështoi. Kam parë dikë të kalojë një pasdite në një listë të lejuar të prishur që në të vërtetë ishte një përcjellës që mungonte për portën 443. Regjistroni protokollin dhe destinacionin e çdo pakete që vendosni të hidhni.

Socketi i zgjidhësit duhet të dalë nga tuneli

Përcjellja është vendi i kurthit të radhës. Zgjidhësit e operatorit shpesh jetojnë në një adresë private që tuneli nuk e arrin, kështu që kërkesa që përcillni nuk shkon askund dhe aplikacioni raporton skadim të kohës së leximit. Dërgoni kërkesat e miratuara te një zgjidhës që e dini se është i arritshëm dhe jepni së pari atë socket te VpnService.protect(). Një socket i pambrojtur e kthen kërkesën në tunelin tuaj, ku ajo arrin përsëri në aplikacion dhe rrotullohet derisa të aktivizohet koha e skadimit.

Dështimi duket identik me një ndërprerje rrjeti, dhe për këtë arsye mbijeton kaq gjatë në raportet e gabimeve. Mbani numërues për kërkesat e dërguara dhe përgjigjet e marra: nëse numri i parë rritet dhe i dyti mbetet zero, po shikoni socketin, jo listën.

Madhësia dhe shumat e kontrollit dështojnë pa mesazh

Hedhjet e qeta vijnë edhe nga madhësia. Një përgjigje DNS me një grup të madh përgjigjesh, ose një shtrëngim duarsh TCP me opsione bujare, mund të tejkalojë një MTU rrugë që nuk e keni vendosur kurrë në mënyrë eksplicite; fragmenti zhduket në rrjedhën e sipërme dhe klienti ose provon përsëri më i vogël ose ndalon së provuari. Vendosja e MTU-së së ndërfaqes në 1280 është një zgjedhje konservatore që i reziston shumicës së rrugëve celulare, dhe të qenit eksplicit është më mirë sesa të trashëgosh një vlerë të paracaktuar që askush nuk e mati.

Nëse ndërtoni vetë paketat, shuma e kontrollit është vrasësi tjetër i qetë. Një shumë kontrolli UDP e llogaritur mbi një pseudo-kokë që lë jashtë gjatësinë UDP ose fushën e protokollit prodhon një paketë që në anën tuaj duket e formuar mirë dhe që marrësi e hedh pa gjurmë. Krahasoni pseudo-kokën tuaj me specifikimin fushë për fushë dhe shtypni shumën e llogaritur për një rrjedhë të njohur ndërsa korrigjoni.

Çfarë nuk bën një VpnService për ju

Dy kufij ia vlen të njihen përpara se të projektoni rreth tyre. Asnjë aplikacion i zakonshëm nuk mund të instalojë një proxy në nivel sistemi ose një skedar PAC jashtë Wi-Fi, dhe ajo pjesë nuk ka ndryshuar. Rruga për çdo aplikacion ka ndryshuar: përpara API 29, VpnService.Builder nuk mund të mbante fare proxy, dhe nga API 29, setHttpProxy(ProxyInfo.buildPacProxy(uri)) i jep platformës një skript PAC për t'u vlerësuar për rrjetin VPN. Vlerësoni rregullat në kodin tuaj kur synoni API më të vjetra ose kur modeli PAC nuk mund ta shprehë rregullin. Edhe UDP nuk është falas: shfletuesit dërgojnë vetëm TCP përmes një proxy SOCKS, dhe shumica e klientëve SOCKS5 nuk implementojnë kurrë UDP ASSOCIATE, kështu që një projekt i bazuar në proxy hedh ose rrjedh UDP ndërsa TCP duket i shëndetshëm.

Ky kufi i dytë është arsyeja pse një protokoll i bazuar në UDP mund të funksionojë në një rrjet të zakonshëm dhe të dështojë në momentin që lidhet VPN-i juaj. Nëse pritet që tuneli të mbajë UDP, përcjellësi duhet të implementojë rrugën e përcjelljes për të, jo vetëm rrugën TCP me një lloj tjetër socketi.

Kontrolloni në këtë rend

Punoni listën me radhë dhe ndaloni në fazën e parë që dështon, sepse çdo kontroll i mëpasshëm është zhurmë derisa ai i mëparshmi të mbajë.

1. Listoni rrugët e instaluara dhe konfirmoni nëse paketat që nuk janë DNS hyjnë fare në ndërfaqen TUN.
2. Regjistroni emrin e kërkesës, vendimin dhe kodin e përgjigjes për një emër të bllokuar dhe një të miratuar.
3. Konfirmoni se socketi i zgjidhësit është i mbrojtur dhe se zgjidhësi i zgjedhur përgjigjet nga brenda tunelit.
4. Konfirmoni MTU-në e ndërfaqes dhe shumën e kontrollit të një përgjigjeje të ndërtuar me dorë.
5. Përsëritni të njëjtën faqe në Wi-Fi dhe në rrjetin celular, sepse zgjidhësit e operatorit dhe MTU e rrugës ndryshojnë.

Nëse të pesta mbajnë dhe faqja ende varet, i dyshuari tjetër është vetë përcjellësi: krahasoni një kërkesë të kapur me një përgjigje të kapur dhe kërkoni një numërim bajtësh që mungon ose një socket gjysmë të mbyllur. Referenca e VpnService.Builder mbulon kontratat e rrugës, DNS dhe MTU, dhe protect() është një thirrje VpnService e veçantë dhe jo një opsion i builder-it; një ndërfaqe e lidhur do të thotë vetëm se kontrata e parë është përmbushur.