Vilket macOS-verktyg kan tvinga en enda app att gå enbart via VPN?

En rad i ett kravdokument — ”den här appen får använda VPN:et och ingenting annat” — ber tyst om två mekanismer som ingen enskild brytare levererar. Trafiken behöver en väg genom den avsedda tunneln, och trafik som annars skulle gå direkt ut måste avvisas. Verktyg som gör det ena bra och det andra inte alls är vanliga, därför svarar en jämförelse som bara frågar om något kan blockera självsäkert på halva frågan. Skriv först ner gränsen och välj sedan de komponenter som täcker båda dess halvor.

Två krav gömda i en enda mening

Styrning är den del som sätter en anslutning i tunneln eller proxyn. Vägran är den del som hindrar samma anslutning från att gå ut via någon annan väg. Olika komponenter implementerar dem, de misslyckas på olika sätt, och en produkt kan vara utmärkt i det ena utan att säga något om det andra:

Läs tabellen som en checklista och inte som en rangordning. Ingen rad fyller båda de mittersta kolumnerna, och de rader som täcker dem är två komponenter som samarbetar: den ena äger vägen, den andra äger vägran. Identitetskolumnen spelar roll av en annan anledning, eftersom en regel som inte kan namnge appen inte kan verkställa en regel om den appen. Vad du än rullar ut måste det svara på alla tre, annars är gränsen i kravdokumentet inte gränsen på maskinen.

Enbart styrning lämnar en väg ut

Inställningen för applikationsproxy är det tydligaste exemplet på styrning utan vägran. Den kan styra förfrågningar från en app som respekterar systemproxyn, och den täcker ingenting annat: en hjälpprocess, en uppdaterare, en bakgrundstjänst eller ett annat protokoll kan ta sin egen väg utan att någonsin läsa den inställningen. Att välja en SOCKS-slutpunkt i en panel skapar därför ingen policy mot direkt utgång för applikationen. Om kravet gäller appen som helhet, fråga vilka komponenter regeln faktiskt identifierar.

En VPN-profil per app styr bättre än en proxy, eftersom plattformen avgör vilka appar som kommer in i tunneln i stället för att varje app avgör det själv. Ändå vägrar den ingenting: profilen ger en väg, och trafik som inte passar in tar den vanliga vägen. Just det gapet är platsen där en andra komponent förtjänar sin plats, och därför är produkter som ser ut som en enda brytare oftast två.

Enbart vägran förstör appen

Apples dokumentation om innehållsfilter beskriver en tillåt-eller-blockera-dom om trafik medan den passerar nätverksstacken. Den domen är varken en tunnel eller en proxyanslutning, eftersom den avgör om något får fortsätta, inte vart det tar vägen. Ett filter ensamt verkställer vägran perfekt och lämnar applikationen oanvändbar, med rena loggar och ingen förklaring. En filterdom kan stoppa en anslutning men levererar aldrig tunneln, så att para den med styrning är designbeslutet och inte ett extra tillval.

En lokalt administrerad PF-regeluppsättning står i andra änden av spektrumet. Det är ett legitimt supportbeslut på en maskin som en administratör äger, och det är inte automatiskt grunden för en produkt som kan distribueras, eftersom den som äger regeluppsättningen också äger dess samspel med andra brandväggsanvändare, dess uppgraderingsväg och dess återställning när en regel är fel. Att lägga till PF i en produkt tar inte bort den ägarfrågan; det definierar den.

Utrullningen avgör om regeln finns kvar i morgon

Hur en Network Extension rullas ut på Apples plattformar beror på leverantörstypen, paketeringen och den OS-version du har framför dig. En apputökning på macOS körs i en användarkontext och slutar när den användaren loggar ut, medan en systemutökning har en global kontext som inte beror på sessionen. Om skyddet måste överleva en utloggning är den skillnaden hela designen och inte en fotnot. Bekräfta utrullningsvägen innan du lovar beteendet, eftersom samma kod landar olika beroende på vilken utökningstyp som levereras.

Tillgången på källkod är en annan sak än verkställighet. Att läsa ett arkiv berättar hur något är implementerat, inte vad den installerade binärfilen får göra på den här maskinen. Signering, installation och auktorisering gäller fortfarande, och instruktioner byggda kring en föråldrad kärnutökning eller ett biblioteksinjektionstrick beskriver en annan plattform och en annan riskhållning, hur bra de än fungerade en gång.

Ett acceptansfall som namnger appen

Välj en enda handling som applikationen utför själv, notera adressen den ska nå och om den adressen är IPv4 eller IPv6, och upprepa sedan samma handling i det godkända tillståndet utan tunnel. Den andra körningen måste producera den deklarerade vägran och inte ett tyst direkt nytt försök. Det är den halva folk lämnar ospecificerad, och den enda halvan som bevisar att vägran alls finns. Kör den först med tunneln tillgänglig, så att en skillnad mellan de två resultaten bara kan komma från den saknade tunneln.

Gå sedan igenom de övergångar kravet nämner: omstart av appen, en hjälpprocess som utlöses, tunneln som återansluter, maskinen som byter nätverk, och en utloggning eller omstart där det gäller. En webbläsares sida med offentlig IP är inte ett test av en annan applikations sockets, så den kan inte ersätta den här. Där ingen stödd utrullning täcker appens faktiska beteende är en auktoriserad isolerad miljö med en explicit gateway och utan alternativ utgång ett inneslutningsbeslut med sina egna administrationskostnader, inte en ersättning för en kryssruta.

Avsluta med att skriva ner fyra punkter: vilka komponenter appen består av, vem som äger styrningen, vem som äger vägran, och de tillstånd där regeln fortfarande måste gälla. Ett offentligt arkiv kan vara ett urvalskriterium, men det är inte en av de fyra, och de punkterna är det som avgör om ett givet verktyg uppfyller nätverkskravet.