Waar ’n Android-brandmuurreël moet bly wanneer ’n VPN aan is
Net een VpnService kan aktief wees, so ’n brandmuurprogram en ’n VPN-program stapel nie. Volg een werkversoek en plaas elke reël waar sy verkeer werklik verbykom.
Jy het een sin beleid: hierdie program mag die werkdiens bereik, en niks anders nie. Die volgende vraag lyk na ’n produkkeuse, maar dit is ’n liggingsvraag, want elke moontlike punt waar die beleid afgedwing word, sien ’n ander deel van die foon se verkeer. ’n gateway sien net wat die tonnel binnegaan. ’n filter aan die foonkant sien net wat dit toegelaat word om te sien. Om een versoek deur albei te laat loop, maak die antwoord duidelik.
Begin met die sin, nie die produk nie
Brei die vereiste uit voordat jy enigiets kies. Dit beteken die pakket en die profiel waarin dit loop, want ’n program in die werkprofiel is ’n ander gebruiker as dieselfde program in die persoonlike profiel. Dit beteken die bestemming: gasheer, poort en protokol, nie ’n diensnaam nie. Dit beteken die DNS-pad wat daardie naam oplos, en dit beteken wat moet gebeur wanneer die tonnel nie beskikbaar is nie.
Uitgeskryf is die beleid vir die voorbeeld vier reëls: die werkprogram mag die werkdiens bereik; die werkprogram mag niks anders bereik nie; ander programme bly onveranderd; sonder ’n tonnel word die werkprogram geweier eerder as om terug te val. Elke reël het ’n eienaar, en dit is nie almal dieselfde eienaar nie.
Stap 1: wat die foon self kan afdwing
’n Android-brandmuur sonder root is ’n VpnService wat verkeer plaaslik vasvang, selfs wanneer daar geen afstandstonnel agter is nie. Android laat een aktiewe VPN-diens per gebruikerprofiel toe, so ’n tweede brandmuurprogram skakel nie agter die eerste in nie. Dit vervang dit, en die koppelvlak wat die eerste program gefilter het, verdwyn.
Daarom lewer die installering van ’n brandmuur langs ’n VPN-kliënt selde die kombinasie wat mense verwag. As die brandmuur begin en die VPN ontkoppel, is niks gekombineer nie; die twee het plekke geruil. ’n Vervanging van die koppelvlak is nie samewerking nie, en die simptoom is ’n tonnel wat aanhoudend val elke keer wanneer die ander program oopgemaak word.
Ondersteunde reëlings bestaan wel: filtering ingebou in die VPN-kliënt wat jy reeds gebruik, bestuurde platformbeheer deur ’n toestelbeleidbeheerder of werkprofiel, of ’n argitektuur wat die verskaffer dokumenteer. Enigiets anders is ’n eksperiment wat na elke programopdatering weer geverifieer moet word.
Stap 2: wat die gateway kan afdwing
Sodra verkeer aan die ander kant ontsleutel is, kan die gateway deurgestuurde pakkette beperk tot goedgekeurde adresse, dienste of geauthentiseerde VPN-identiteite. Dit is werklike afdwinging vir alles wat daar deur uitgaan, en dit is die regte plek om toegang tot private subnetwerke te beperk.
Wat dit nie ontvang nie, is die foon se programidentiteit wat aan elke gewone IP-pakket geheg is. Verskeie programme wat een tonneladres deel, is een subjek vir die gateway, tensy die ontwerp hulle aparte adresse of aparte geauthentiseerde identiteite gee. ’n Reël per gebruiker by die gateway is dus nie ’n reël per program op die foon nie, hoe die bestuurkonsol dit ook al noem.
Stap 3: lys wat nooit aankom nie
’n Program wat van die VPN uitgesluit is en ’n nabye toestel kontak, bereik nooit die gateway nie, so ’n uitgangsbrandmuur kan nie ’n pakket weier wat dit nooit ontvang nie. Dieselfde geld vir ’n onbedoelde direkte roete tydens ’n onderbreking en vir inkomende blootstelling op die plaaslike toegangsnetwerk. Dit is plaaslike grense per definisie.
Die omgekeerde geld ook: ’n plaaslike reël wat ’n verbinding toelaat, gee nie toegang deur die gateway se private-netwerk-ACL nie. Een versoek kan aan albei grense onderwerp wees, en om een te bevredig sê niks oor die ander nie.
Stap 4: wys elke reël aan ’n pad toe
Sit die besluit in ’n tabel voordat jy enigiets opstel, want die oop selle is waar ontwerpe misluk.
| Pad | Wie dit kan afdwing | Blindevlek |
|---|---|---|
| Werkprogram na die werkdiens, tonnel op | Gateway-ACL op adres en diens, plus ’n plaaslike blok op ander paaie | Die gateway kan nie sien watter program die pakket gestuur het nie |
| Werkprogram na ander bestemmings, tonnel op | Plaaslike programbewuste filter, of die gateway as daardie bestemmings daar geadresseer is | Die plaaslike filter moet die aktiewe VpnService wees |
| Werkprogram sonder tonnel | Plaaslike weiering, sodat die program nie ’n direkte pad kan neem nie | Vereis dat die filter die verdwyning van die tonnel oorleef |
| Nabye LAN-toestel | Slegs plaaslike beleid | Die gateway sien dit nooit |
Die werkbare vorm is twee grense met twee take. ’n Plaaslike programbewuste grens beheer foongedrag, insluitend die direkte terugval, en ’n gateway-grens beheer afstandhulpbronne. Die gateway-kant kan die werkdiens toelaat en elke ander private subnet weier, terwyl die foonkantbeleid sy eie besluit oor ’n direkte pad neem wat die program andersins sou neem.
Stap 5: hou die vervoer lewendig en verifieer dan
Watter plaaslike beleid jy ook al kies, dit moet die vervoer toelaat wat die VPN opstel en instandhou. Om daardie vervoer te blokkeer, laat die foon sonder tonnel en sonder beleid, wat niks samehangend afdwing nie en moeilik is om te diagnoseer, want die program het eenvoudig geen netwerk nie.
Verifieer dan elke reël van die oorspronklike sin eerder as die algemene indruk: die werkprogram bereik die werkdiens, dieselfde program word by ’n ander bestemming geweier, ’n nie-werkprogram gedra hom soos voorheen, en met die tonnel gestop val die werkprogram nie terug op ’n direkte verbinding nie. Kontroleer die DNS-pad afsonderlik, want private DNS of ’n geënkripteerde oplosser kan ’n filter omseil wat net adresse inspekteer.
As een van daardie stappe nie op die foon bevredig kan word nie, is die vereiste ’n argitektuurvraag en nie ’n brandmuurinstelling nie. Om die beleid te verdeel tussen ’n toestel wat jy beheer en ’n gateway wat jy beheer, is gewoonlik die eerlike antwoord, en die Android VPN-verbindingdocumentasie is die plek om te bevestig wat die platform ’n enkele diens sal en nie sal laat doen nie.