Jo hawwe twa manieren om de eigen pakketten fan 'e tunnel bûten de tunnel te hâlden: beskermje de transport-socket, of helje de hiele app út 'e VPN. Se lossen ferskillende problemen op, en de bredere kieze om't it makliker oan te sluten is, is krekt hoe't apps tagong ta it lokale netwurk en splitst DNS ferlieze sûnder it te fernimmen. Begjin by wat bûten de tunnel bliuwe moat, en kies dan it lytste berik dat dat berikt.

Wat protect() út 'e tunnel hellet

VpnService.protect() is in oprop per socket. Jo jouwe it de socket of deskriptor dy't de tunnel draacht, en Android markearret dy socket sadat syn ferkear it ûnderlizzende netwurk brûkt ynstee fan 'e VPN-ynterface. Al it oare dat de app stjoert, folget noch altyd de normale VPN-route.

Krekt dat smelle berik is it punt. In beskerme socket feroaret net hoe't jo HTTP-klant nammen oplost, hokker ynterface jo analyzepetysjes brûke, of wat der bart mei in twadde ferbining dy't letter iepene wurdt.

Trije betingsten dy't it berik bepale

De earste betingst is oft allinnich it transport fan 'e tunnel ûntkomme moat. As it oare ferkear fan 'e app noch troch de VPN gean moat, is socketbeskerming it goede berik. De twadde betingst is oft jo it meitsjen fan 'e socket behearskje. In bibleteek dy't syn eigen socket djip binnen iepenet, lit jo gjin plak om protect() op te roppen, of it moat in hook biede of in klear socket akseptearje. De tredde betingst is oft de app it lokale netwurk as in captive portal direkt berikke moat, wat in oare eask is as de tunnel libben hâlde.

De app útslute mei addDisallowedApplication() is it rûge ark. It hellet elke ferbining dy't de app makket út 'e VPN, ek dy't jo besjen woene, en op guon apparaten feroaret it ek hoe't lokale ûntdekking him hâldt en draacht.

In tredde opsje is it transport oan in keazen netwurk te binen mei bindProcessToNetwork() of in netwurkhantfet op socketnivo. Dat is nuttich as it apparaat tagelyk Wi-Fi en mobyl hat en jo wolle dat de tunnel oer in spesifike uplink giet.

Rop it op wylst it transport makke wurdt

Rop protect() op yn itselde blok dat it transport makket, foar connect() of send(). As de oprop false weromjout, slút dan de socket en lit de opset mislearje; trochgean lit jo efter mei in transport wêrfan't de pakketten wer yn jo eigen ynterface komme kinne.

De foarm is lyts genôch om op ien plak te hâlden:

DatagramSocket transport = new DatagramSocket();
if (!protect(transport)) {
    transport.close();
    throw new IOException("transport not protected");
}
transport.connect(serverAddress);

Trije details bite hjir. Earst,de boolean is it ienige sinjaal dat jo krije, dus log de mislearring mei genôch kontekst om in ynlutsen tastimming fan in wegere oprop te ûnderskieden. Twad,protect() dekt de socket, net it deskriptornûmer: as jo de socket slute en letter itselde hielgetal foar in oare socket werbrûke, is de nije socket net beskerme. Tred, as in native bibleteek it transport iepenet, beskermje de deskriptor foardat de native koade ferbynt, oars is de route miskien al keazen.De VpnService-referinsje is it plak om te befêstigjen hokker oerlêsten jo doel-API-nivo eins biedt.

Test it blokkearre paad, net allinnich it lokkige paad

Ferifiearje mei de tunnel omheech, want dat is de iennichste steat wêryn't de twa paden ferskille kinne. Stjoer ien fersyk troch it beskerme transport en ien fan in koadepaad dat nea protect() oproppen hat, en fergelykje dan wat de fiere kant sjocht: de beskerme ferbining heart mei it ûnderlizzende netwurk as boarne te kommen, wylst de ûnbeskerme de eigen adres fan 'e tunnel sjen lit en de byte-tellers fan 'e tunnel beweecht. Op it apparaat lit ss of netstat deselde splitsing sjen foardat eat it radio ferlit.

Test it ynlûken apart, want in tastimmingsferoaring sloopt de ynterface ôf sûnder jo socketkoade oan te reitsjen. Lûk de VPN-tastimming yn of stop de tsjinst, bou it transport opnij en befêstigje dat protect() noch altyd true weromjout en dat it transport wer ferbynt sadree't tastimming wer jûn wurdt.

As it beskerme fersyk dochs de tunnel folget, bart de beskermingsoprop wierskynlik neidat de socket al rûte is. Ferpleats it earder en test opnij.

Hâld de beslissing opskreaun njonken de transport-opset: hokker sockets beskerme binne, hokker appferkear útsletten is, en wat de app docht as beskerming mislearret. Krekt dy rigel hâldt in lettere refaktor tsjin om de útsluting nei de hiele app te ferbreedzjen om't ien test mislearre. It jout de folgjende persoan ek in manier om de bedoeling te kontrolearjen sûnder it manifest werom te ûntwerpen.

Relatearre artikelen