D’VpnService-Schutz schlägt fehl, wann en aneren VPN schonn aktiv ass
Android erlaabt eng VPN-Interface pro Benotzer. Féiert d’Kontroller prepare, establish, protect an Proprietéit an der Rei aus a wielt duerno Widderruff oder Ausnam pro App.
Är App rifft VpnService.prepare op, kritt null zréck, baut en Tunnel, an den Deskriptor gesäit valabel aus, awer näischt erreecht de Server. Oder prepare gëtt en Intent zréck, de Benotzer stëmmt zou, an establish schlägt nach ëmmer fehl. Béid Resultater bedeiten normalerweis datselwecht: eng aner App besëtzt schonn d’VPN-Interface fir dëse Benotzer, an är protect-Opruffer markéieren Sockets, déi ären Tunnel net ka benotzen. Gitt d’Kontrollen hei drënner an der Rei duerch a stoppt bei der éischter, déi fehlschléit, well e spéidere Schrëtt en éischten net ka reparéieren.
Kontrolléiert de VPN-Plaz, ier Dir protect beréiert
Android gëtt all Benotzer genee eng aktiv VPN-Interface. Dat ass eng Plattformreegel, keng Erlaabnis, déi är App ka fuerderen, dofir kënnen zwéi Clienten, déi allebéid den Tunnel wëlle sinn, net niewenteneen existéieren.
En ëmmer aktive VPN, dee fir eng aner App agestallt ass, ass de schwéiersten Fall, well de System déi App verbonne hält an eng Iwwernahm ofleent. En Trafikfilter wéi AdGuard, en Entrepriseclient oder en Endverbraucher-VPN kann de Plaz halen, während de Benotzer vergiess huet, datt e installéiert ass. Frot de Benotzer, d’Astellungen opzemaachen an den Antrag ënner VPN ze liesen; den Numm do ass de Proprietär, mat deem Dir konkurréiert. Bis deen Antrag getrennt oder d’Astellung ëmmer aktiv geläscht gëtt, kann är VpnService net d’Interface ginn.
Schrëtt 1: liest, wat prepare zréckgëtt
VpnService.prepare äntwert op eng eenzeg Fro: däerf dës App de VPN ginn? Et gëtt null zréck, wann d’Zoustëmmung schonn do ass, an en Intent, wann de Benotzer se nach muss approuvéieren, deen Dir mat startActivityForResult musst starten. Behandelt en null-Zréck als Erlaabnis weiderzemaachen, net als Beweis, datt establish wäert geléngen.
Intent intent = VpnService.prepare(context);
if (intent != null) {
startActivityForResult(intent, REQUEST_VPN);
}Wann de Intent-Wee zréckkënnt an de Benotzer ofgeleent huet, wäert prepare beim nächsten Versuch weider en Intent zréckginn. Loggt de Resultatcode amplaz an enger Schleif nach eng Kéier ze probéieren, well eng ofgeleentte Zoustëmmung eng Entscheedung vum Benotzer ass, keen temporäre Fehler.
Schrëtt 2: bestätegt, datt d’Interface ärer App gehéiert
No establish ass de ParcelFileDescriptor, deen Dir kritt, är Beweis vun der Proprietéit, an et ass derwäert, en virun alle Socket-Aarbechten ze kontrolléieren. En Deskriptor, deen null ass oder schonn zou ass, heescht, datt d’Interface ni erstallt gouf, och wann keng Ausnam opgetrueden ass. Vergläicht den Interface-Numm aus dem Builder mat deem, deen de System fir den aktive VPN mellt, mat dumpsys op engem Testapparat. Wa se sech ënnerscheeden, ass den Tunnel, deen Dir gebaut hutt, net den Tunnel, deen den Trafik dréit.
adb shell dumpsys connectivityDéiselwecht Onstëmmegkeet erkläert eng verbonnen Ikon mat doutem Trafik. De System weist den Tunnel vun der anerer App, während äre Code en Deskriptor fir eng Interface hält, déi en net besëtzt.
Schrëtt 3: rufft protect virun connect op
Soubal d’Interface existéiert, ginn Sockets, déi är App opmécht, standardméisseg an den Tunnel geleet. Den äusseren Transport kann déi Reegel net befollegen, soss géif de verkapselte Pak zréck an d’Interface lafen, dofir VpnService protect markéiert e Socket, fir de VPN z’ëmginn an dat Netz ënner ärem Tunnel ze benotzen. Den Opruff gëtt e boolean zréck, an en ze ignoréieren ass de Wee, wéi Dir mat engem Socket ophalen, deen gesond ausgesäit an näischt dréit.
Rufft protect virun connect oder bind op, ni duerno. De Schutz muss do sinn, ier de Socket verbonne oder gebonnen gëtt, well e verbonne Socket seng Route schonn ausgewielt huet an e spéidere protect en net zouverlässeg réckelt. Wa protect false zréckgëtt, stoppt a kontrolléiert d’Proprietéit nach eng Kéier: et schléit fehl, wann d’Interface net ärer App gehéiert, wat genee dee Zoustand ass, deen en aneren VPN hannerléisst. En false-Zréck ass en Zeechen, fir op Schrëtt 1 zréckzegoen, net fir dee selwechte Socket nach eng Kéier ze probéieren.
DatagramSocket socket = new DatagramSocket();
if (!vpnService.protect(socket)) {
return;
}
socket.connect(serverAddress, serverPort);Schrëtt 4: bind e Prozess, wann e Socket onbequem ass
E puer Transporten sinn net een Socket: eng Bibliothéik kann e puer opmaachen, oder Dir wëllt, datt all Verbindung an engem Hëllefsprozess déiselwecht Ausgang benotzt. ConnectivityManager.bindProcessToNetwork bindt de Prozess un en ausgewielten Netz, an dat méi al setProcessDefaultNetwork huet datselwecht gemaach, ier et veraltert ass. Frot d’Verbindung ënner ärem Tunnel mat NET_CAPABILITY_NOT_VPN un, sou datt d’Bindung d’Netz ënner ärem Tunnel auswielt an net den Tunnel selwer.
NetworkRequest request = new NetworkRequest.Builder()
.addCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
.addCapability(NetworkCapabilities.NET_CAPABILITY_NOT_VPN)
.build();E Prozess binden ass keen zweete VPN. Et wielt en Ausgang fir dee Prozess, wat fir ären Transport nëtzlech an fir zwee Tunnellen gläichzäiteg ze bedreiwen onnëtzlech ass.
Reparéiert den Apparat vum Benotzer, net de Codewee
Et gëtt keng API, déi zwou Appen de VPN-Plaz deele léisst, dofir gehéiert d’Reparatur zum Zoustand vum Apparat. Bitt dem Benotzer zwee konkret Weeër: trennt oder läscht den ëmmer aktiv fir déi aner App, sou datt äre prepare iwwerhuele kann, oder maacht d’Astellunge pro App vun där App op an schléisst är App aus hirem Tunnel aus. D’Ausnam hält de Filter fir alles anescht um Lafen an erlaabt ärer App, déi gewéinlech Verbindung ze benotzen, wat dacks d’Resultat ass, dat de Benotzer tatsächlech wëllt.
Schreift béid Weeër an är Support-Dokumentatioun, well Benotzer seele wëssen, wéi eng App de VPN besëtzt. Frot se, den Numm vum aktive VPN aus den Astellungen an d’Resultater vu prepare, establish a protect aus äre Loggen ze schécken, an Dir kënnt bannent enger Minutt soen, wéi ee Schrëtt fehlgeschloen ass. Da verifizéiert mat richtegem Trafik: eng Numm-Opléisung, eng TCP-Verbindung an eng Ufro duerch den Tunnel, net just eng verbonnen Ikon. En valabelen Deskriptor an eng gréng Ukzeechen beweisen héchstens d’Proprietéit, ni, datt den Transport d’Routingregelen iwwerlieft huet.
Wa béid véier Kontrollen duerchginn an den Trafik nach ëmmer stierft, ass d’Proprietéit net méi är Probleem. Gitt weider op Routing an Erreechbarkeet vum Server, a testt déiselwecht Umeldungsinformatiounen vun engem Apparat ouni installéiert VPN-App.