Welke macOS-tool kan één app dwingen alleen via de VPN te gaan?

Eén regel in een eisenpakket — „deze app mag de VPN gebruiken, en niets anders” — vraagt om twee mechanismen die geen enkele schakelaar levert. Verkeer heeft een pad door de bedoelde tunnel nodig, en verkeer dat er direct uit zou gaan moet worden geweigerd. Gereedschap dat het ene goed doet en het andere helemaal niet komt vaak voor, daarom beantwoordt een vergelijking die alleen vraagt of iets kan blokkeren met vertrouwen de helft van de vraag. Schrijf eerst de grens op en kies dan de onderdelen die beide helften daarvan dekken.

Twee eisen verscholen in één zin

Sturing is het deel dat een verbinding in de tunnel of de proxy zet. Weigering is het deel dat dezelfde verbinding tegenhoudt om via een andere route naar buiten te gaan. Verschillende onderdelen implementeren ze, ze falen op verschillende manieren, en een product kan in het ene uitblinken en over het andere niets zeggen:

Lees de tabel als een checklist en niet als een ranglijst. Geen enkele rij vult beide middelste kolommen, en de rijen die ze dekken zijn twee samenwerkende onderdelen: het ene bezit het pad, het andere de weigering. De identiteitskolom is om een andere reden belangrijk, want een regel die de app niet kan benoemen kan geen regel over die app handhaven. Wat u ook uitrolt, het moet alle drie beantwoorden, anders is de grens in het eisenpakket niet de grens op de machine.

Sturing alleen laat een uitweg

De instelling voor applicatieproxy is het duidelijkste voorbeeld van sturing zonder weigering. Het kan verzoeken sturen van een app die de systeemproxy respecteert, en het dekt niets anders: een hulpproces, een updater, een achtergronddienst of een ander protocol kan zijn eigen pad volgen zonder die instelling ooit te lezen. Een SOCKS-eindpunt in één venster kiezen maakt dus geen beleid van geen directe uitgang voor de applicatie. Als de eis over de app als geheel gaat, vraag dan welke onderdelen de regel werkelijk identificeert.

Een VPN-profiel per app stuurt beter dan een proxy, omdat het platform bepaalt welke apps de tunnel in gaan in plaats van dat elke app dat zelf bepaalt. Toch weigert het niets: het profiel levert een pad, en verkeer dat daar niet bij past neemt de gewone route. Juist die kloof is de plek waar een tweede onderdeel zijn plaats verdient, en daarom zijn producten die op één schakelaar lijken meestal twee.

Weigering alleen breekt de app

Apple’s documentatie over inhoudsfilters beschrijft een toestaan-of-blokkeren-oordeel over verkeer terwijl het door de netwerkstack gaat. Dat oordeel is geen tunnel en geen proxyverbinding, omdat het beslist of iets mag doorgaan, niet waar het heen gaat. Een filter alleen handhaaft de weigering perfect en laat de applicatie onbruikbaar achter, met schone logboeken en zonder uitleg. Een filteroordeel kan een verbinding stoppen maar levert nooit de tunnel, dus het paren met sturing is de ontwerpbeslissing en niet een optionele extra.

Een lokaal beheerde PF-regelset staat aan de andere kant van dat spectrum. Het is een legitieme ondersteuningsbeslissing op een machine die een beheerder bezit, en het is niet automatisch de basis van een distribueerbaar product, omdat wie de regelset bezit ook de interacties met andere firewallgebruikers, het upgradepad en het herstel bezit wanneer een regel fout is. PF aan een product toevoegen haalt die eigendomsvraag niet weg; het definieert die.

De uitrol bepaalt of de regel er morgen nog is

Hoe een Network Extension op Apple-platforms wordt uitgerold hangt af van het providertype, de verpakking en de OS-versie voor u. Een appextensie op macOS draait in een gebruikerscontext en eindigt wanneer die gebruiker uitlogt, terwijl een systeemextensie een globale context heeft die niet van de sessie afhangt. Als de bescherming een uitlog moet overleven, is dat verschil het hele ontwerp en geen voetnoot. Bevestig de uitrolroute voordat u het gedrag belooft, want dezelfde code landt anders afhankelijk van welk extensietype wordt geleverd.

De beschikbaarheid van broncode is een aparte kwestie van handhaving. Een repository lezen vertelt u hoe iets is geïmplementeerd, niet wat de geïnstalleerde binary op deze machine mag doen. Ondertekening, installatie en autorisatie gelden nog steeds, en instructies rond een verouderde kernel-extensie of een bibliotheekinjectietruc beschrijven een ander platform en een andere risicohouding, hoe goed ze ooit ook werkten.

Een acceptatiegeval dat de app bij naam noemt

Kies één handeling die de applicatie zelf uitvoert, noteer het adres dat ze zou moeten bereiken en of dat adres IPv4 of IPv6 is, en herhaal dan dezelfde handeling in de goedgekeurde toestand zonder tunnel. De tweede run moet de verklaarde weigering opleveren en niet een stille directe hernieuwde poging. Dat is de helft die mensen ongespecificeerd laten, en de enige helft die bewijst dat weigering überhaupt bestaat. Voer het eerst uit met de tunnel beschikbaar, zodat een verschil tussen de twee resultaten alleen van de ontbrekende tunnel kan komen.

Loop daarna de overgangen door die de eis noemt: de app herstarten, een hulpproces dat afgaat, de tunnel die opnieuw verbindt, de machine die van netwerk wisselt, en een uitlog of herstart waar die gelden. Een openbare-IP-pagina in een browser is geen test van de sockets van een andere applicatie, dus kan deze niet vervangen. Waar geen ondersteunde uitrol het werkelijke gedrag van de app dekt, is een geautoriseerde geïsoleerde omgeving met een expliciete gateway en zonder alternatieve uitgang een beperkingsbeslissing met eigen beheerkosten, geen vervanging van een selectievakje.

Sluit af met vier punten: uit welke onderdelen de app bestaat, wie de sturing bezit, wie de weigering bezit, en de toestanden waarin de regel nog moet gelden. Een openbare repository kan één selectiecriterium zijn, maar het is niet een van de vier, en die punten bepalen of een bepaald gereedschap aan de netwerkeis voldoet.