Firwat Android VpnService en Deel vum Traffic fänkt an net alles

Näischt a VpnService fänkt Traffic vun sech aus of. Et freet de System ëm eng tun-Interface, gëtt där Interface eng Rei Adressen a Routen, a vun deem Moment un kopéiert de Kernel all Paket, dat zu dëse Route passt, an en Dateideskriptor, den d'App liese kann. Den Code vun der App gesäit ni d'Paketen, déi d'Route net ausgewielt hunn, also ass de Beräich vun engem Tunnel eng Fro vun der Routingtabell, éier et eng Fro vum Programméiere gëtt. Dofir kann déi selwecht Servisimplementéierung op engem Telefon all Flux schlécken an op engem aneren nëmmen en Deel, an dofir reparéiert eng zousätzlech Route heiansdo en Tunnel, dee gebrach ausgesinn huet. Dir kritt dat, wat Dir deklaréiert hutt, minus alles, wat de Builder stëll refuséiert huet.

D'Route entscheeden, wéi eng Paketen ukommen

Builder.addRoute(prefix, prefixLength) installéiert e Prefix an der Routingtabell vum VPN-Netz. De System behandelt dëst Netz als Standard fir d'Appen am Beräich, dofir ginn seng Anträg virun der Standardroute vum physeschen Netz gekuckt an e passende Prefix duergeet, fir e Flux ëmzeleeden. Dofir hëlt eng Route fir 0.0.0.0/0 IPv4 ganz, inklusiv den Drécker, d'Cast-Zil an d'Administratiounssäit vum Router.

Clienten, déi dës Deckung wëllen, ouni de physeschen Standardantrag ze läschen, benotze stattdessen d'Paar 0.0.0.0/1 an 128.0.0.0/1. Zwou méi spezifesch Route gewannen géint eng Standardroute, zesummen decke si de ganzen Adressraum of, an den eegenen Standardantrag vum Telefon bleift an der Tabell fir d'Sockelen, déi nach un d'physescht Netz gebonnen sinn.

Adressen an DNS-Anträg kommen vum selwechte Builder a beäntweren eng aner Fro. addAddress gëtt der Interface eng Adress mat enger Prefixlängt, an addDnsServer installéiert en Opléiser, deen d'Appen am Beräich iwwer d'Interface froen. Béid Famillje kënnen op enger Interface sëtzen, dofir ass en Ensembel nëmme IPv4-Routen nieft enger IPv6-Adress eng Konfiguratioun, déi sech richteg liese léisst an dennoch leckt. Wann Dir eng Famill rout, an där d'Interface keng Adress huet, huet de Kernel keng Quelladress fir déi Paketen a si erschéngen ni um Deskriptor.

Wat establish() zréckgëtt

establish() gëtt en ParcelFileDescriptor zréck, oder null wann d'App net autoriséiert ass. Null ass en Zouestemmungszoustand an net e Netzwierkfeeler: VpnService.prepare() muss schonn null zréckginn hunn, oder de Benotzer muss den Systemdialog virum Opruff akzeptéiert hunn. D'Zouestimmung ka widderruff ginn, während de Servis leeft, an d'Interface geet ënner Äre Féiss zou, ouni een Rückruff an Äre Lieskrees.

Den Deskriptor blockéiert net, ausser Dir sot anescht, dofir kënnt e Liesen direkt ouni Daten zréck, amplaz den Thread ze parken. E Krees, deen fir eng blockéierend Sockel geschriwwe gouf, verbrennt eng Kär, an e Krees, deen e leet Liesen als fatal behandelt, räisst den Tunnel an enger ideler Sekonn of. Builder.setBlocking(true) ännert dëst Verhalen, an de Präis ass en Thread, deen am Liesen waart.

Route- an Adressargumenter ginn als LinkAddress-Wäerter validéiert, an Multicast-Ziler wéi 224.0.0.0/4 ginn direkt ofgeleent. Eng Punkt-zu-Punkt tun-Interface huet och keng Broadcast-Domän, dofir brauch d'Multicast-Entdeckung duerch si en anere Design amplaz nach eng Route. D'Referenz VpnService.Builder ass d'Lëscht, déi Dir kontrolléiere sollt, éier Dir schéisst, datt en Opruff ignoréiert gouf.

De Beräich pro App verengt den Ensembel, net den Tunnel

Vun API 21 un akzeptéiert de Builder addAllowedApplication an addDisallowedApplication, an déi zwou Lëschte schléissen sech géigesäiteg aus bannent engem Builder. Eng Erlaabneslëscht mécht den Tunnel fir déi Paketen existent, während alles anescht d'physescht Netz behält; eng Verbuetslëscht fänkt alles ausser de genannte Paketen, wat e Client als opgedeilten Tunnel ubitt. Virun API 21 gëtt et guer keen Plattformmechanismus, an d'Verhalen pro App koum vu Clienten Drëtter, déi no UID bannent hirem eegene Weiderleider filteréiert hunn. Den Ënnerscheed zielt beim Debuggen, well en App-Tunnel mat enger Erlaabneslëscht vun engem eenzege Paket bal keen Traffic produzéiert an dat ass korrekt Verhalen, keng gebrache Route.

Wéi de Beräich och ass, d'Sockel, déi Är App op de VPN-Server opmécht, däerf net duerch den Tunnel goen, deen se baut. VpnService.protect(socket) bind dës Sockel un d'ënnerläit Netz, sou datt hir Paketen den tun-Apparat iwwersprangen. Wann Dir den Opruff ewechloosst, gëtt de Handshake vun der Interface geschléckt, déi en hätt solle setzen.

VpnService.setUnderlyingNetworks schléisst de Krees, andeem e dem System seet, wéi ee physescht Netz den Tunnel dréit. Dee Wäert bestëmmt, wéi de VPN d'Konnektivitéit un aner Appen mellt, an en null- oder veraltete Wäert ass eng üblech Ursaach fir en verbonnenen Tunnel, deen de Rescht vum Telefon als offline behandelt. Aktualiséiert en, wann dat ënnerläit Netz sech ännert, net nëmme beim Start.

Checksummen an MTU: wou eng korrekt Route nach ëmmer feelschléit

Wann d'Paketen ukommen, entscheeden zwee Detailer op Paketniveau, ob eppes vun Enn zu Enn funktionéiert. Dat éischt ass d'Quelladress: bei méi Interfaceadressen kann de Kernel Paketen austelle, déi déi éischt droen, dofir muss en Weiderleider, deen Headeren ëmschreift, d'Adress an d'Checksumm, déi se deckt, flécken.

Dat zweet ass de Beräich vun der Checksumm. Wann d'App TCP- oder UDP-Pakete selwer baut, deckt d'Checksumm en Pseudohärebild mat der Quelladress, der Ziladress, der Protokollnummer an der Transportlängt, an eng dovun ewech ze loossen gëtt Paketen, déi ukommen an déi ee fält. Dee Feeler gesäit aus wéi en Timeout no enger Äntwert, déi ni kënnt, wat déi meescht Leit zréck op d'Route schéckt. setMtu setzt d'MTU vun der Interface fest, an all Liesen gëtt genee ee vollstännegt IP-Paket zréck, dofir fragmentéiert en Buffer, dee fir en Byteflux geschriwwe gouf, Är Analys amplaz d'Paket.

Eng Verifikatiounsronn, déi d'Schichte trennt

Fir ze fannen, wou de Beräich schief gaangen ass, test d'Schichten an der Rei. Frot den Apparat, wéi eng Routen de VPN-Netz tatsächlech hält, kontrolléiert dann, ob e Flux op eng bekannt Adress als Liesen um Deskriptor erschéngt, a kontrolléiert dann, ob d'Paket, dat Äre Weiderleider ausgëtt, gutt geformt ass. E Routeproblem weist näischt um Deskriptor, während e Checksummproblem e Paket weist, dat ukommt a verschwënnt.

Wann näischt den Deskriptor erreecht, ass den Ensembel vun de Route verdächteg an net de Lieser: bestätegt d'Prefixen, bestätegt, datt et eng Adress an der selwechter Famill gëtt, a bestätegt, datt d'App bannent dem Beräich ass, deen Dir gesat hutt. Wann d'Paketen den Deskriptor erreechen, awer näischt zréckkënnt, kontrolléiert protect() an de Wäert vum ënnerläiten Netz, éier Dir nach eng Kéier eng Route beréiert. Wann déi wäit Säit defekt Pakete mellt, sinn d'Checksumm an d'MTU d'Plazen, wou een nokuckt. Een Test pro Schicht spuert en Nomëtteg Raten.