Android IKEv2 VPN profili ir pēc lietotāja, nevis pēc ierīces

Termins iebūvēts VPN Android ietver divas nesaistītas lietas: protokola ieviešanu, ko platforma izpilda jūsu vietā, un to iestatījumu formu, ko ražotājs nolēma rādīt. Tie nav viens un tas pats objekts, un neviens no tiem negarantē, ka tunelis pieder lietotājam, kura lietotnēm tas nepieciešams. Izveide notiek konkrētā lietotājā ar konkrētu izsaucošo pakotni, un viss turpmākais manto šo kontekstu. Izlasiet īpašumtiesību ķēdi pirms iestatījumu ekrāna.

Ko platforma būvē jūsu vietā

Kopš Android 11 platforma nodrošina VPN izveidi ar VpnManager starpniecību. Apstiprināta lietotne apraksta IKEv2 profilu, un platforma pati veic IPsec un IKE apmaiņu, tāpēc lietotne nekad neaiztiek paketes. Tā ir būtiskā atšķirība no pašas VPN lietotnes, kas ievieš VpnService un būvē tuneli savā procesā.

val profile = Ikev2VpnProfile.Builder(serverAddress, identity)
    .setAuthUsernamePassword(user, secret, rootCa)
    .build()
getSystemService(VpnManager::class.java).provisionVpnProfile(profile)

Iepriekš minētais izsaukums ir formas skice, nevis kopējams bloks: konstruktoram ir vairāki autentifikācijas varianti, tie atšķiras pēc API līmeņa, un profils nes arī servera sertifikāta uzticības materiālu. Īpašumtiesību jautājumā svarīgais ir šaurāks par sintaksi.

No šī dizaina izriet divas īpašības. Profils ir dati, tāpēc administrators to var izveidot, nevis ievadīt ar roku. Un tunelis ir platformas tīkls, tāpēc lietotnes to redz kā tīklu ar VPN transportu, nevis kā citas lietotnes ligzdu.

Īpašnieks ir lietotājs, pēc tam pakotne

Android daudzlietotāju režīms ir reāla atdalīšana, nevis birka. Darba profils ir atsevišķs lietotājs ar savām instalētajām pakotnēm, lietotņu datiem, atslēgu krātuvi un uzticības enkuriem. Viens un tas pats produkts abās vietās ir divi eksemplāri ar atšķirīgiem lietotāja identifikatoriem, pat ja ikonas un nosaukumi ir vienādi.

Izveide tiek reģistrēta pret izsaucošo pakotni šajā lietotājā. Tāpēc izveides lietotne personīgajā profilā rada personīgu tuneli, un darba profila darba lietotnes no tā neko neredz. Ir arī pretēji, tāpēc darba profila tunelis personīgajām lietotnēm ir neredzams bez skaidras politikas, kas nosaka citādi.

Ierīces politikas kontrolieris var izveidot pārvaldīta profila vārdā, kas izskaidro ierakstu, kuru birojā neviens neatceras esam izveidojis. Ja veicat tālruņa auditu, tas ir iespējamais pelēkā profila īpašnieks, un dzēst to kā eksperimentu nav jūsu darīšana.

Trīs vārti, pirms pakotne kustas

Pirmie vārti ir pilnvaras: pārvaldībai vispār jāatļauj VPN, un daži ieviešanas gadījumi ierobežo gan veidu, gan pastāvēšanu. Otrie ir identitāte: klienta sertifikātam vai akreditācijas datiem jābūt pieejamiem lietotājā, kuram pieder profils, jo personīgajā atslēgu krātuvē importēts sertifikāts darba profilam nav redzams.

Trešie ir piekrišana un politika. Lietotājs parasti apstiprina savienojumu pirmajā lietošanas reizē, un administrators to var papildus piespraust kā vienmēr ieslēgtu, pēc izvēles ar bloķēšanu, lai trafiks nevarētu iziet ārpus tuneļa. Šie iestatījumi nosaka, kas notiek, kad tunelis atkrīt, un tieši to lietotāji pamana.

Tvērums ir vieta, kur satiekas visi trīs. Profils nosaka vārteju un identitāti, bet politikas slānis nosaka, kuras lietotnes drīkst izmantot tuneli un vai trafiks tiek spiests caur to. Tāpēc divi tālruņi ar vienādām vārtejas adresēm var uzvesties ļoti atšķirīgi.

Kāpēc personīgs savienojums neaptver darba lietotnes

Trafiks no darba lietotnes rodas darba lietotājā, un piemērojamā tīkla politika ir tā, kas ir šajā lietotājā. Personīgajā profilā izveidots tunelis to nenes, lai cik veselīgs izskatītos indikators. Šis viens fakts izskaidro lielāko daļu ziņojumu, kuros lietotājs zvēr, ka VPN ir savienots, bet konkrēta lietotne joprojām nesasniedz iekšējo pakalpojumu.

Nosaukumu izšķiršana seko tai pašai robežai. Privātie DNS sufiksi un uzticības enkuri ir katram lietotājam, tāpēc iekšējs resursdatora nosaukums, kas atrisinās personīgajā profilā, var neizdoties darba profilā pat ar līdzvērtīgi izskatāmu tuneli, jo atrisinātāja politika un CA krātuve ir dažādi objekti.

Pārbaudiet reālā reģistrācijā, nevis laboratorijas tālrunī

Ierīcē vispirms nosakiet ieraksta īpašnieku: kurš lietotājs, kura pakotne un vai profils nāca no platformas izveidotāja vai no lietotnes ar savu VPN pakalpojumu. Pēc tam apstipriniet, ka identitāte, ko profils sagaida, patiešām ir šī lietotāja atslēgu krātuvē.

Pārbaudiet dzīves ciklu, ne tikai savienojumu. Piesakieties, atslēdziet akreditācijas datu krātuvi, ļaujiet darba profilam vakarā apturēties, pēc tam atgrieziet to un pārbaudiet, vai tunelis atgriežas bez manuāla pieskāriena. Darba profils, kas izslēdzas pēc darba laika, paņem līdzi savu tuneli, un tā ir gaidīta uzvedība, nevis kļūda, ja gaidītais nepieejamības stāvoklis ir pierakstīts.

Visbeidzot pārbaudiet pašu darba lietotni pret zināmu iekšējo galapunktu un salīdziniet ar personīgā profila rezultātu. Abi drīkst atšķirties; atšķirties nedrīkst īpašumtiesību modelis. Ja tunelis pieder nepareizajam lietotājam, sertifikātu atkārtota izsniegšana to nelabos.

Neuzspiediet jautājumu, palaižot slēptas iestatījumu darbības, lai atklātu izvēlni, un nekopējiet privātās atslēgas starp profiliem, lai savienojums parādītos. VpnManager atsauce dokumentē, ko izsaucējs drīkst izveidot; ja apstiprinātais ceļš neietver jūsu gadījumu, tas ir administratora lēmums, nevis iestatījumu problēma.