Watter macOS-hulpmiddel kan ’n enkele app slegs deur die VPN dwing?

Een reël in ’n vereistesdokument, “hierdie app mag die VPN gebruik, en niks anders nie”, vra stilweg vir twee meganismes wat geen enkele skakelaar bied. Verkeer het ’n pad deur die beoogde tonnel nodig, en verkeer wat direk sou vertrek, moet geweier word. Gereedskap wat een van dié dinge goed doen en die ander glad nie, is algemeen, en daarom beantwoord ’n vergelyking wat net vra of iets kan blokkeer, die helfte van die vraag met selfvertroue. Skryf eers die grens neer, en kies dan die komponente wat albei helftes daarvan dek.

Twee vereistes wat in een sin versteek is

Sturing is die deel wat ’n verbinding in die tonnel of die proxy plaas. Weiering is die deel wat keer dat dieselfde verbinding op enige ander roete vertrek. Verskillende komponente implementeer hulle, hulle misluk op verskillende maniere, en ’n produk kan uitstekend wees in die een terwyl dit niks oor die ander sê nie:

Lees die tabel as ’n kontrolelys eerder as ’n ranglys. Geen enkele ry vul albei middelste kolomme nie, en die rye wat hulle wel dek, is twee komponente wat saamwerk: een besit die pad, die ander besit die weiering. Die identiteitskolom maak om ’n ander rede saak, want ’n reël wat nie die app kan noem nie, kan nie ’n reël oor daardie app afdwing nie. Wat jy ook al ontplooi, moet al drie antwoord, anders is die grens in die vereistesdokument nie die grens op die masjien nie.

Sturing alleen laat ’n uitweg oop

’n Toepassing-proxy-instelling is die duidelikste voorbeeld van sturing sonder weiering. Dit kan versoeke van ’n app wat die stelselproxy respekteer, stuur, en dit dek niks anders nie: ’n helperproses, ’n opdateerder, ’n agtergronddiens of ’n ander protokol kan op sy eie pad reis sonder om ooit daardie voorkeur te lees. Om ’n SOCKS-eindpunt in een paneel te kies, skep dus nie ’n geen-direkte-uitgang-beleid vir die toepassing nie. As die vereiste oor die app as geheel gaan, vra watter komponente die reël werklik identifiseer.

’n VPN-profiel per app stuur beter as ’n proxy, want die platform besluit watter apps die tonnel binnegaan in plaas daarvan dat elke app self besluit. Dit weier steeds niks: die profiel verskaf ’n pad, en verkeer wat nie daarby pas nie, neem die gewone roete. Daardie gaping is presies waar ’n tweede komponent sy plek verdien, en dit is waarom produkte wat soos een skakelaar lyk, gewoonlik twee is.

Weiering op sy eie breek die app

Apple se dokumentasie oor inhoudfilters beskryf ’n toelaat-of-blokkeer-uitspraak oor verkeer soos dit deur die netwerkstapel beweeg. Daardie uitspraak is nie ’n tonnel en nie ’n proxyverbinding nie, want dit besluit of iets mag voortgaan eerder as waarheen dit gaan. ’n Filter op sy eie dwing die weiering perfek af en laat die toepassing onbruikbaar, met skoon logboeke en geen verduideliking nie. ’n Filteruitspraak kan ’n verbinding stop maar verskaf nooit die tonnel nie, so om dit met sturing te pas, is die ontwerpbesluit eerder as ’n bykomende opsie.

’n Plaaslik geadministreerde PF-reëlversameling sit aan die verre einde van daardie spektrum. Dit is ’n wettige ondersteuningsbesluit op ’n masjien wat ’n administrateur besit, en dit is nie outomaties die grondslag van ’n verspreibare produk nie, want wie die reëlversameling besit, besit ook die interaksies daarvan met ander firewallgebruikers, sy opgraderingspad en sy herstel wanneer ’n reël verkeerd is. Om PF by ’n produk te voeg, verwyder nie daardie eienaarskapvraag nie; dit definieer dit.

Ontplooiing besluit of die reël môre nog bestaan

Hoe ’n Network Extension op Apple-platforms ontplooi word, hang af van die verskaftertipe, die verpakking en die bedryfstelselweergawe voor jou. ’n App-uitbreiding op macOS loop in ’n gebruikerskonteks en eindig wanneer daardie gebruiker afteken, terwyl ’n stelseluitbreiding ’n globale konteks het wat nie van die sessie afhang nie. As beskerming ’n aftekening moet oorleef, is daardie verskil die hele ontwerp eerder as ’n voetnoot. Bevestig die ontplooiingsroete voordat jy die gedrag belowe, want dieselfde kode land anders afhangend van watter uitbreidingtipe gestuur word.

Bronbeskikbaarheid is ’n aparte saak van afdwinging. Om ’n bewaarplek te lees, vertel jou hoe iets geïmplementeer is, nie wat die geïnstalleerde program op hierdie masjien mag doen nie. Ondertekening, installasie en magtiging geld steeds, en instruksies wat rondom ’n verouderde kernuitbreiding of ’n biblioteekinspuiting-truuk gebou is, beskryf ’n ander platform en ’n ander risikohouding, hoe goed dit ook al eens gewerk het.

’n Aanvaardingsgeval wat die app by die naam noem

Kies ’n enkele aksie wat die toepassing self uitvoer, let op die adres wat dit behoort te bereik en of daardie adres IPv4 of IPv6 is, en herhaal dan dieselfde aksie in die goedgekeurde geen-tonnel-toestand. Die tweede loop moet die verklaarde weiering lewer eerder as ’n stille direkte herprobeerslag. Dit is die helfte wat mense ongespesifiseer laat, en die enigste helfte wat bewys dat weiering hoegenaamd bestaan. Voer dit eers uit met die tonnel beskikbaar, sodat ’n verskil tussen die twee resultate net van die ontbrekende tonnel kan kom.

Stap dan deur die oorgange wat die vereiste noem: die app herbegin, ’n helper wat vuur, die tonnel wat weer koppel, die masjien wat netwerke verander, en ’n aftekening of herbegin waar dit van toepassing is. ’n Blaaier se openbare-IP-bladsy is nie ’n toets van ’n ander toepassing se sokkels nie, so dit kan nie hierdie een vervang nie. Waar geen ondersteunde ontplooiing die app se werklike gedrag dek nie, is ’n gemagtigde geïsoleerde omgewing met ’n eksplisiete gateway en geen alternatiewe uitgang nie ’n insperringsbesluit met sy eie bestuurskoste, nie ’n vervanging vir ’n merkie nie.

Sluit af deur vier inskrywings neer te skryf: watter komponente die app uitmaak, wie sturing besit, wie weiering besit, en die toestande waarin die reël nog moet geld. ’n Openbare bewaarplek kan een keuringskriterium wees, maar dit is nie een van die vier nie, en daardie inskrywings is wat besluit of ’n gegewe hulpmiddel aan die netwerkvereiste voldoen.