Hvilket macOS-verktøy kan tvinge én app gjennom VPN-et og ingenting annet?

Én linje i et kravdokument — «denne appen kan bruke VPN-et, og ingenting annet» — ber stille om to mekanismer som ingen enkelt bryter leverer. Trafikken trenger en vei gjennom den tiltenkte tunnelen, og trafikk som ellers ville gå direkte ut, må avvises. Verktøy som gjør det ene godt og det andre ikke i det hele tatt, er vanlige, og derfor svarer en sammenligning som bare spør om noe kan blokkere, selvsikkert på halvparten av spørsmålet. Skriv først grensen ned, og velg deretter komponentene som dekker begge halvdelene av den.

To krav som gjemmer seg i én setning

Styring er delen som setter en forbindelse inn i tunnelen eller proxyen. Avvisning er delen som hindrer den samme forbindelsen i å gå ut via noen annen rute. Ulike komponenter implementerer dem, de svikter på ulike måter, og et produkt kan være utmerket i det ene uten å si noe om det andre:

Les tabellen som en sjekkliste og ikke som en rangering. Ingen rad fyller begge de midterste kolonnene, og radene som dekker dem, er to komponenter som samarbeider: den ene eier veien, den andre eier avvisningen. Identitetskolonnen betyr noe av en annen grunn, fordi en regel som ikke kan navngi appen, ikke kan håndheve en regel om den appen. Uansett hva du ruller ut, må det svare på alle tre, ellers er grensen i kravdokumentet ikke grensen på maskinen.

Styring alene etterlater en utvei

Innstillingen for applikasjonsproxy er det tydeligste eksempelet på styring uten avvisning. Den kan styre forespørsler fra en app som respekterer systemproxyen, og dekker ingenting annet: en hjelpeprosess, en oppdatering, en bakgrunnstjeneste eller en annen protokoll kan reise sin egen vei uten å noen gang lese den innstillingen. Å velge et SOCKS-endepunkt i ett panel skaper derfor ikke en policy om ingen direkte utgang for applikasjonen. Hvis kravet handler om appen som helhet, spør hvilke komponenter regelen faktisk identifiserer.

En VPN-profil per app styrer bedre enn en proxy, fordi plattformen bestemmer hvilke apper som kommer inn i tunnelen i stedet for at hver app bestemmer det selv. Likevel avviser den ingenting: profilen gir en vei, og trafikk som ikke passer til den, tar den vanlige ruten. Det hullet er nettopp stedet der en andre komponent fortjener plassen sin, og derfor er produkter som ser ut som én bryter, som regel to.

Avvisning alene ødelegger appen

Apples dokumentasjon om innholdsfiltre beskriver en tillat-eller-blokker-dom over trafikk mens den passerer nettverksstakken. Den dommen er verken en tunnel eller en proxyforbindelse, fordi den avgjør om noe kan fortsette, og ikke hvor det går. Et filter alene håndhever avvisningen perfekt og etterlater applikasjonen ubrukelig, med rene logger og ingen forklaring. En filterdom kan stoppe en forbindelse, men leverer aldri tunnelen, så å pare den med styring er designbeslutningen og ikke et ekstra valg.

Et lokalt administrert PF-regelsett ligger i den andre enden av spekteret. Det er en legitim støttebeslutning på en maskin en administrator eier, og det er ikke automatisk grunnlaget for et produkt som kan distribueres, fordi den som eier regelsettet, også eier samspillet med andre brannmur-brukere, oppgraderingsveien og gjenopprettingen når en regel er feil. Å legge PF til et produkt fjerner ikke det eierskapsspørsmålet; det definerer det.

Utrullingen avgjør om regelen fortsatt finnes i morgen

Hvordan en Network Extension rulles ut på Apples plattformer, avhenger av tilbydertypen, pakkingen og OS-versjonen foran deg. En apputvidelse på macOS kjører i en brukerkontekst og avsluttes når den brukeren logger ut, mens en systemutvidelse har en global kontekst som ikke avhenger av økten. Hvis beskyttelsen skal overleve en utlogging, er den forskjellen hele designet og ikke en fotnote. Bekreft utrullingsveien før du lover atferden, fordi den samme koden lander ulikt avhengig av hvilken utvidelsestype som sendes ut.

Tilgjengelighet av kildekode er en annen sak enn håndheving. Å lese et depot forteller deg hvordan noe er implementert, ikke hva den installerte binærfilen har lov til å gjøre på denne maskinen. Signering, installasjon og autorisasjon gjelder fortsatt, og instruksjoner bygget rundt en utdatert kjerneutvidelse eller et bibliotekinjeksjonstriks beskriver en annen plattform og en annen risikoholdning, uansett hvor godt de en gang virket.

En aksepttest som navngir appen

Velg én enkelt handling som applikasjonen utfører av seg selv, noter adressen den skal nå, og om den adressen er IPv4 eller IPv6, og gjenta deretter den samme handlingen i den godkjente tilstanden uten tunnel. Den andre kjøringen må produsere den erklærte avvisningen og ikke et stille direkte nytt forsøk. Det er den halvdelen folk lar stå uspesifisert, og den eneste halvdelen som beviser at avvisning i det hele tatt finnes. Kjør den først med tunnelen tilgjengelig, slik at en forskjell mellom de to resultatene bare kan komme fra den manglende tunnelen.

Gå deretter gjennom overgangene kravet nevner: omstart av appen, en hjelpeprosess som utløses, tunnelen som kobler til igjen, maskinen som bytter nettverk, og en utlogging eller omstart der det gjelder. En nettlesers side med offentlig IP er ikke en test av en annen applikasjons sockets, så den kan ikke erstatte denne. Der ingen støttet utrulling dekker appens faktiske atferd, er et autorisert isolert miljø med en eksplisitt gateway og ingen alternativ utgang en inndemmingsbeslutning med sine egne administrasjonskostnader, ikke en erstatning for en avkrysningsboks.

Avslutt med å skrive ned fire punkter: hvilke komponenter appen består av, hvem som eier styringen, hvem som eier avvisningen, og tilstandene der regelen fortsatt må gjelde. Et offentlig depot kan være ett utvalgskriterium, men det er ikke ett av de fire, og de punktene er det som avgjør om et gitt verktøy oppfyller nettverkskravet.