Hvilket macOS-værktøj kan tvinge én app gennem VPN’en og intet andet?

Én linje i et kravdokument — „denne app må bruge VPN’en og intet andet“ — beder stille om to mekanismer, som ingen enkelt kontakt leverer. Trafikken skal have en vej gennem den tilsigtede tunnel, og trafik, der ellers ville gå direkte ud, skal afvises. Værktøjer, der gør det ene godt og det andet slet ikke, er almindelige, og derfor svarer en sammenligning, der kun spørger, om noget kan blokere, selvbevidst på den halve del af spørgsmålet. Skriv først grænsen ned, og vælg derefter de komponenter, der dækker begge dens halvdele.

To krav, der gemmer sig i én sætning

Styring er den del, der lægger en forbindelse i tunnelen eller proxyserveren. Afvisning er den del, der forhindrer den samme forbindelse i at forlade systemet ad enhver anden rute. Forskellige komponenter implementerer dem, de fejler på forskellige måder, og et produkt kan være fremragende til det ene og intet sige om det andet:

Læs tabellen som en tjekliste og ikke som en rangliste. Ingen række udfylder begge de midterste kolonner, og de rækker, der dækker dem, er to komponenter, der samarbejder: den ene ejer vejen, den anden ejer afvisningen. Identitetskolonnen er vigtig af en anden grund, fordi en regel, der ikke kan navngive appen, ikke kan håndhæve en regel om den app. Uanset hvad du udruller, skal det svare på alle tre, ellers er grænsen i kravdokumentet ikke grænsen på maskinen.

Styring alene efterlader en udvej

Indstillingen for applikationsproxy er det tydeligste eksempel på styring uden afvisning. Den kan styre anmodninger fra en app, der respekterer systemproxyn, og dækker intet andet: en hjælpeproces, en opdatering, en baggrundstjeneste eller en anden protokol kan rejse ad sin egen vej uden nogensinde at læse den indstilling. At vælge et SOCKS-endepunkt i én rude skaber derfor ikke en politik om ingen direkte udgang for applikationen. Hvis kravet handler om appen som helhed, så spørg, hvilke komponenter reglen reelt identificerer.

En VPN-profil pr. app styrer bedre end en proxy, fordi platformen bestemmer, hvilke apps der kommer ind i tunnelen i stedet for at hver app bestemmer det selv. Alligevel afviser den intet: profilen leverer en vej, og trafik, der ikke passer på den, tager den almindelige rute. Det hul er netop stedet, hvor en anden komponent gør sig fortjent til sin plads, og derfor er produkter, der ligner én kontakt, som regel to.

Afvisning alene ødelægger appen

Apples dokumentation om indholdsfiltre beskriver en tillad-eller-bloker-dom om trafik, mens den passerer netværksstakken. Den dom er hverken en tunnel eller en proxyforbindelse, fordi den afgør, om noget må fortsætte, og ikke hvor det skal hen. Et filter alene håndhæver afvisningen perfekt og efterlader applikationen ubrugelig, med rene logfiler og ingen forklaring. En filterdom kan stoppe en forbindelse, men leverer aldrig tunnelen, så at parre den med styring er designbeslutningen og ikke en ekstra valgmulighed.

Et lokalt administreret PF-regelsæt ligger i den anden ende af spektret. Det er en legitim supportbeslutning på en maskine, som en administrator ejer, og det er ikke automatisk grundlaget for et produkt, der kan distribueres, fordi den, der ejer regelsættet, også ejer dets samspil med andre firewallbrugere, dets opgraderingsvej og dets gendannelse, når en regel er forkert. At tilføje PF til et produkt fjerner ikke det ejerskabsspørgsmål; det definerer det.

Udrulningen afgør, om reglen stadig findes i morgen

Hvordan en Network Extension udrulles på Apples platforme, afhænger af udbydertypen, pakningen og den OS-version, du står med. En appudvidelse på macOS kører i en brugerkontekst og slutter, når den bruger logger ud, mens en systemudvidelse har en global kontekst, der ikke afhænger af sessionen. Hvis beskyttelsen skal overleve en logud, er den forskel hele designet og ikke en fodnote. Bekræft udrulningsvejen, før du lover adfærden, fordi den samme kode lander forskelligt alt efter, hvilken udvidelsestype der sendes ud.

Kildetilgængelighed er en anden sag end håndhævelse. At læse et lager fortæller dig, hvordan noget er implementeret, ikke hvad den installerede binærfil må gøre på denne maskine. Signering, installation og autorisation gælder stadig, og instruktioner bygget omkring en forældet kerneludvidelse eller et biblioteksinjektionstrick beskriver en anden platform og en anden risikoprofil, uanset hvor godt de engang virkede.

En accepttest, der navngiver appen

Vælg en enkelt handling, som applikationen udfører af sig selv, noter den adresse, den bør nå, og om den adresse er IPv4 eller IPv6, og gentag så den samme handling i den godkendte tilstand uden tunnel. Den anden kørsel skal frembringe den erklærede afvisning og ikke et stille direkte genforsøg. Det er den halvdel, folk lader stå uspecificeret, og den eneste halvdel, der beviser, at afvisning overhovedet findes. Kør det først med tunnelen tilgængelig, så en forskel mellem de to resultater kun kan komme fra den manglende tunnel.

Gå derefter gennem de overgange, som kravet nævner: genstart af appen, en hjælpeproces, der udløses, tunnelen, der genopretter forbindelsen, maskinen, der skifter netværk, og en logud eller genstart, hvor det gælder. En browsers side med offentlig IP er ikke en test af en anden applikations sockets, så den kan ikke erstatte denne. Hvor ingen understøttet udrulning dækker appens faktiske adfærd, er et autoriseret isoleret miljø med en eksplicit gateway og ingen alternativ udgang en inddæmningsbeslutning med sine egne administrationsomkostninger, ikke en erstatning for et afkrydsningsfelt.

Afslut med at skrive fire poster ned: hvilke komponenter appen består af, hvem der ejer styringen, hvem der ejer afvisningen, og de tilstande, hvor reglen stadig skal gælde. Et offentligt lager kan være et udvælgelseskriterium, men det er ikke en af de fire, og de poster er det, der afgør, om et givet værktøj opfylder netværkskravet.