Android VpnService konektatu egiten da, baina paketeak ez dira sarera iristen

Tunela altxatzen da, giltzaren ikonoa agertzen da, eta nabigatzaileko eskaera bakoitzak denbora-muga gainditzen du oraindik. VpnService aplikazio batean konbinazio horrek esan nahi du irakurketa begizta bizirik dagoela eta irteerako erdia hautsita dagoela, ez zerbitzariak esku-ematea ukatu duenik. Androidek interfazea sortu du, aplikazioaren trafikoa bertara eraman du eta zure prozesuari fitxategi-deskriptore bat eman dio. Deskriptore horren ondorengo guztia zure kodea da, eta falta den dei bakar bat nahikoa da korronte osoa irentsizteko.

Sistemak ematen dizuna eta ematen ez duena

establish() funtzioak ParcelFileDescriptor bat itzultzen du tun interfaze baterako. Sistemak irteerako IP paketeak bertan idazten ditu eta zure prozesuak irakurtzea, nora doazen erabakitzea eta socket arrunt baten bidez bidaltzea espero du. Azpian ez dago kernel bidezko birbidalketarik, beraz inork irakurtzen ez duenean paketeak baztertu egiten dira eta interfazearen kontagailuak ez dira inoiz mugitzen.

Hasi asmatu beharrean zenbatzen. Gehitu kontagailu bat irakurketa arrakastatsu bakoitzean eta erregistratu lehen paketeen helmuga eta protokoloa. Kontagailua zeran geratzen bada trafikoa sortzen ari den bitartean, hutsegitea zure birbidalketa-kodearen gainetik dago, eta horrek bilaketa builder konfiguraziora eta irakurketa modura murrizten du. Kontagailua mugitzen bada eta nabigatzaileak oraindik huts egiten badu, hutsegitea bidaltze-bidean edo itzultze-bidean dago.

Irakurketa blokeatzaileak erabakitzen du begizta mugitzen den

setBlocking(true) deskriptorea modu blokeatzailean jartzen du eta API 21etik dago. Bertsio zaharretan konponbidea JNI laguntzaile txiki bat da, O_NONBLOCK ezabatzen duena fcntl bidez deskriptore gordinean. Moduak garrantzia du, paketerik zain ez duen irakurketa batek zer egin dezakeen erabakitzen duelako.

Modu ez-blokeatzailean irakurketa hori berehala itzultzen da balio negatibo batekin, eta emaitza alde batera uzten duen begizta batek nukleo bat biratzen du trafikorik mugitu gabe. Modu blokeatzailean irakurketa itxaroten du, birbidaltze hari batek nahi duena, baina orduan haria ezin da eten. Deskriptorea ixtea da irakurketa huts egiteko modu onartua, begiztak irten ahal izateko. Prozesua hiltzeak edo haria eteteak hurrengo hasiera interfazearekin bat ez datorren deskriptore batekin utz dezake.

Irakurri pakete bat deialdi bakoitzeko, interfazearen MTU tamainako buffer batean, eta hartu zeroa edo itzulera negatiboa errore gisa, pakete huts gisa beharrean.

protect() lehen bidalketa baino lehen, ez ondoren

Pakete kapsulatu bat daraman socket bakoitza lehenengo babestu behar da. Babestu gabeko socket batek oraintxe instalatutako bideratze-arau berberak obeditzen ditu, beraz bere paketeak tunelera itzultzen dira eta zure irakurketa begiztak berriro jasotzen ditu. Orduan tunelak bere irteera amaigabe birbidaltzen du, eta kanpotik irekitzen den eta inoiz erantzuten ez duen konexio baten itxura du.

Ordena honakoa da: protect, gero connect edo bind, gero send. connect ondoren protect deitzeak aurreko ibilbide-erabakia lekuan utz dezake, beraz socketak bide okerra erabiltzen jarraitzen du deialdiak true itzuli arren. Egiaztatu itzultzen duen boolearra eta huts egin ozen false denean, funtziona dezaken bidalketa batera sartu beharrean.

protect() inoiz ukitu ez duen socket batean sendto-tik datorren baimen-errorea da akats honen sinadura ohikoa.

UDP laginak ez du HTTPS eramaten

Tutorial gehienek kopiatzen duten birbidaltze-laginak UDP soilik lantzen du. TCPk esku-ematea, segida-zenbakiak, berrespenak eta berbidalketa behar ditu, eta tun deskriptore eta socket baten artean karga kopiatzen duen begiztak ez du horietako bat ere ematen. Horregatik UDP DNS kontsulta bat pasa daiteke HTTPS eskaera guztiak trabatzen diren bitartean. Edo exekutatu TCP pila bat erabiltzaile-espazioan edo eman konexioak gailuan TCP amaitzen duen eta korrontea birbidaltzen duen proxy lokal bati.

Probatu banaketa ezer berridatzi aurretik: bidali UDP kontsulta bat eta ireki TCP konexio bat host berberera. UDP bideak funtzionatzen badu eta TCP bideak lehen SYN-ean zintzilik geratzen bada, arazoa birbidaltze-kodea da eta ez zerbitzaria. Konparazio bakar horrek denbora asko aurrezten du, erabilgarririk ez duten zerbitzari-erregistroak irakurtzen.

Ibilbide zerrendak eta aplikazioen iragazkiek mugatzen dute ikusten duzuna

addAddress, addRoute eta addDns funtzioek zehazten dute sistemak tunelera zer bidaltzen duen. Ibilbide zerrendatik kanpoko helmuga bat ez da inoiz iristen zure deskriptorera, beraz birbidaltze-logikaren kopuruak ez du konponduko. Erregistratu egiten dituzun builder deialdiak eta alderatu aplikazioak benetan lortu nahi dituen helbideekin.

Aplikazioen araberako hautaketak bere muga du: addAllowedApplication eta addDisallowedApplication API 21 behar dute, eta bertsio zaharretan metodoak ez daude. Paketearen arabera iragazten duen diseinuak ez dezake han funtzionatu.

Berriz ezartzeak deskriptore zaharkituak uzten ditu

establish() berriro deitzeak deskriptore berri bat itzultzen du eta aurreko interfazea ixten du. Deskriptore zaharra baliogabea da orain, beraz haren gainean oraindik blokeatuta dagoen hari batek errore bat jasotzen du, eta bide zaharreko socketak ordezkatu behar izan daitezke. onRevoke erabiltzaileak edo sistemak kendutako tunel baten callback-a da. Bizi-zikloa jabe bakarrean mantentzeak, irakurgailua berriz ezarri aurretik gelditzen duenak, konektatuta-baina-hilda egoera gehienak saihesten ditu.

Irakurri errore bakoitza dagokion urratsaren arabera. recvfrom-etik datorren konexio-berrezarpenak urruneko muturra itxi zela esan nahi du zure kodea oraindik irakurtzen ari zen bitartean. Helbide okerreko erroreak goiburuaren analisira edo desplazamendu-errore batera jotzen du, ez sarera.

Lan-ordena: modu blokeatzailea piztuta, irakurketa bakoitzeko pakete bat, goiburua analizatuta, socketa babestuta, karga bidalita, itxiera garbia eskualdatzean eta helmuga estaltzen duen ibilbide zerrenda.