Android VpnService-ren baimen-zerrenda: zergatik blokeatzen diren oraindik baimendutako orriak

Domeinu bat baimen-zerrendan gehitu duzu, kontsultak zure aplikaziora iristen dira, konparatzaileak baimenduta itzultzen du, eta orriak ez du inoiz kargatzen. Puntu horretan jende gehiena konparatzailea berridazten hasten da eta komodin-konparaketak gehitzen. Nire esperientziaren arabera, konparatzailea normalean zuzena da, eta hutsa geruza bat beherago dago: sintetizatu duzun DNS erantzunean, instalatu duzun ibilbidean edo kontsulta birbidaltzeko erabili duzun socketean. Zerrenda zati erraza da; paketearen ibilbidea da baimen-zerrendak hausten diren tokia.

Konparatzailea gutxitan da erruduna

Lehenik bereizi behar dena blokeatuta eta hautsita daude. Izen blokeatu batek azkar eta modu ikusgarrian huts egin beharko luke, nabigatzaileak izena ez dela existitzen dioen erantzuna jasotzen baitu eta gelditzen da. Izen hautsi bat blokeatzen da, IPv6 bidez berriro saiatzen da, beste garraio batera erortzen da, eta biraka ari den adierazle batekin uzten zaitu. Biraka ari den adierazle bat ikusten baduzu, zure baimen-zerrendak seguruenik bezeroak erabili ezin duen zerbait erantzuten du.

A erregistro hutsa akats klasikoa da. Zero erantzunekin NOERROR itzultzeak baliozko erantzuna dirudi, beraz stub resolverrak onartu egiten du, nabigatzaileak berriro saiatzen da, AAAA probatzen du, beste resolver bat probatzen du eta askoz geroago ematen dio amore. 3 erantzun-kodea, NXDOMAIN, galdera atala errepikatuta eta transakzio IDa kopiatuta, elkarrizketa berehala amaitzen du. Erabili nahita ukatzen duzun izen bakoitzerako.

IPv6k erabaki bera merezi du, ez lehenetsitako balio bat. A-rako NXDOMAIN erantzuten baduzu eta AAAA pasatzen uzten baduzu, bezeroak izen blokeatura IPv6 bidez irits daiteke eta iragazkiak ihes egiten du. Inplementazio batzuek AAAA kontsulta blokeatuei loopback helbide batekin erantzuten diete, konexioak berehala huts egin dezan, alternatiba batera erori beharrean. Aukeratu politika bat, aplikatu bi erregistro motetara, eta erregistratu biak.

Dena harrapatzen duen ibilbideak dena du

Bakarrik DNSan oinarritutako diseinuak ez du inoiz addRoute("0.0.0.0", 0) gehitzen, beraz kontsultak bakarrik sartzen dira TUN interfazean eta gainerako guztiak azpiko sarea erabiltzen jarraitzen du. Hori da forma segurua, eta horrek azaltzen du zergatik diruditen baimen-zerrenda batzuek Wi-Fi sarean funtzionatzen eta sare mugikorrean huts egiten duten.

Lehenetsitako ibilbide bat dagoen unean, fluxu bakoitza zurea da. Interfazera iristen den eta ez birbidaltzen ez erantzuten ez zaion TCP pakete bat ilaran geratzen da bezeroaren denbora agortu arte, eta ez dago erregistratzeko errorerik, ezerk huts egin ez duelako. Ikusi dut norbait arratsalde oso bat igaro zuela hautsitako baimen-zerrenda batean, benetan 443 porturako falta zen birbidaltzaile bat zenean. Erregistratu botaztea erabakitzen duzun pakete bakoitzaren protokoloa eta helburua.

Resolver socketak tunela utzi behar du

Birbidaltzea da hurrengo tranpa dagoen tokia. Operadorearen resolverrak maiz tunelak iristen ez duen helbide pribatu batean bizi dira, beraz birbidaltzen duzun kontsulta inora ez doa eta aplikazioak irakurketa-denborazko gainditzea jakinarazten du. Bidali onartutako kontsultak iristeko modukoa dela dakizun resolver batera, eta eman socket hori lehenik VpnService.protect()-i. Babestu gabeko socket batek kontsulta zure tunelera itzultzen du, han aplikaziora berriro iristen da eta biraka ibiltzen da denborazko muga aktibatu arte.

Hutsak sare-etena ematen du, eta horregatik bizirik irauten du hain luze errore-txostenetan. Mantendu kontagailuak bidalitako kontsultetarako eta jasotako erantzunetarako: lehen zenbakia igotzen bada eta bigarrena zeroan geratzen bada, socketea ikusten ari zara, ez zerrenda.

Tamainak eta egiaztapen-batuketek mezurik gabe huts egiten dute

Isildu gabeko baztertzeak tamainagatik ere etortzen dira. Erantzun-multzo handiko DNS erantzun bat edo aukera zabaleko TCP eskualdaketa bat inoiz espresuki ezarri ez duzun bide-MTU bat gaindi dezake; zatia gora desagertzen da eta bezeroak txikiagoan berriro saiatzen da edo saiatzeari uzten dio. Interfazearen MTU 1280an ezartzea aukera kontserbadorea da, bide mugikor gehienetan irauten duena, eta espresuki aritzea inork neurtu ez duen lehenetsitako balio bat oinordetzea baino hobea da.

Paketeak zuk zeuk eraikitzen badituzu, egiaztapen-batuketa da beste hiltzaile isila. UDP luzera edo protokolo eremua kanpo uzten duen pseudo-goiburuan kalkulatutako UDP egiaztapen-batuketak zure aldean ondo osatuta dirudien eta hartzaileak arrastorik gabe baztertzen duen paketea sortzen du. Alderatu zure pseudo-goiburua zehaztapenarekin eremuz eremu, eta inprimatu kalkulatutako egiaztapen-batuketa fluxu ezagun batentzat arazketa egiten duzun bitartean.

Zer ez duen VpnService-k zuretzat egingo

Bi muga merezi du ezagutzea haien inguruan diseinatu aurretik. Aplikazio arrunt batek ezin du Wi-Fi-tik kanpo sistema osoko proxy edo PAC fitxategirik instalatu, eta zati hori ez da aldatu. Aplikazio bakarrerako bidea bai: API 29 baino lehen VpnService.Builder-k ezin zuen proxyrarik eraman, eta API 29tik aurrera setHttpProxy(ProxyInfo.buildPacProxy(uri))-k PAC script bat ematen dio plataformari VPN sarearentzat ebaluatzeko. Ebaluatu arauak zure kodean API zaharragoak helburu dituzunean edo PAC ereduak araua adieraz ezin dezanean. UDP ere ez da doakoa: nabigatzaileek SOCKS proxy bidez TCP bakarrik bidaltzen dute, eta SOCKS5 bezero gehienek ez dute inoiz UDP ASSOCIATE inplementatzen, beraz proxyan oinarritutako diseinu batek UDP botatzen edo ihes egiten du TCP osasuntsu dirudien bitartean.

Bigarren muga hori da UDPan oinarritutako protokolo batek sare arruntean funtziona dezakeen eta zure VPN konektatzen den unean huts egiten duen arrazoia. Tunelak UDP eraman behar badu, birbidaltzaileak horretarako birbidaltze-ibilbidea inplementatu behar du, ez soilik beste socket mota bateko TCP ibilbidea.

Egiaztatu ordena honetan

Egin zerrenda ordenan eta gelditu huts egiten duen lehen etapan, ondorengo egiaztapen bakoitza zarata baita aurrekoa mantendu arte.

1. Zerrendatu instalatutako ibilbideak eta egiaztatu DNS ez diren paketeak TUN interfazera sartzen diren ala ez.
2. Erregistratu kontsultaren izena, erabakia eta erantzun-kodea izen blokeatu batentzat eta onartu batentzat.
3. Egiaztatu resolver socketaren babesa eta aukeratutako resolverrak tunelaren barrualdetik erantzuten duela.
4. Egiaztatu interfazearen MTUa eta eskuz eraikitako erantzun baten egiaztapen-batuketa.
5. Errepikatu orri bera Wi-Fi sarean eta sare mugikorrean, operadorearen resolverrak eta bide-MTUa desberdinak baitira.

Bostak betetzen badira eta orriak oraindik blokeatzen badu, hurrengo susmagarria birbidaltzailea bera da: alderatu harrapatutako eskaera bat harrapatutako erantzun batekin eta bilatu falta den byte-kopurua edo erdi itxitako socketea. VpnService.Builder erreferentzia ibilbide, DNS eta MTU kontratuak estaltzen ditu, eta protect() VpnService deialdi bereizia da, ez builder aukera; konektatutako interfazeak lehen kontratua bete dela esan nahi du bakarrik.