Per-app-VPN eller split tunnel? Vad en Mac-rutt kan avgöra

Två program öppnar anslutningar till samma kontorsserver, och bara ett av dem bör använda tunneln. En rutt kan inte uttrycka den önskan, eftersom routingtabeller bygger på destinationer och inte har något begrepp om vilken process som öppnade socketen. Vad människor ber om och vad de behöver är ofta olika saker. Skilj på de två innan du ändrar någon konfiguration.

Väljaren är en destination, aldrig en process

Varje routingbeslut börjar med en destinationsadress och slutar med ett gränssnitt. Kärnan frågar aldrig vilket program som skickade paketet, och på macOS routar pf inte heller efter process, så en brandväggsregel kan inte sätta ett program på en annan väg. Därför tar samma server, nådd från en webbläsare och från ett rapporteringsverktyg, en väg för båda. Separering på programnivå måste därför komma från något annat än en rutt: ett VPN-plugin som äger socketen, en proxy som tar anslutningen på programmets vägnar, eller en separat nätverksstack. Ingen av dem är en routingändring.

Två program som talar med en adress är det renaste testet av en design. Om svaret inte kan skilja sig mellan dem är designen destinationsbaserad, vad den än kallas.

Vad en vanlig split tunnel faktiskt ger

En split tunnel installerar rutter för de privata prefixen och lämnar allt annat på den fysiska vägen. Det är oftast vad begäran betyder: nå kontorsservern genom tunneln, håll offentligt surfande direkt. Det är enkelt, varje vanlig klient stöder det, och det upprätthålls av samma mekanism som vilken annan rutt som helst. Kontrollera den specifika destinationen med route -n get i stället för att läsa standardrutten, eftersom en split tunnel ofta lämnar standardrutten orörd.

Att redigera standardrutten för hand är ingen omställning till något. Det slåss mot klientens egen återställning av rutter och kan, i klienter som installerar en skyddspolicy, lämna maskinen i ett tillstånd som varken du eller klienten förväntar sig. Konfigurera i stället split tunneln i klientens inställningar som stöds.

Vad per-app-VPN på macOS kräver

Äkta per-app-VPN på macOS är en Network Extension-funktion som drivs av en konfigurationsprofil. En hanteringsnyttolast mappar valda program till en VPN-konfiguration, och systemet dirigerar sedan dessa programs trafik därefter. Det är en hanterad utrullning, vilket betyder en MDM, en signerad profil och en administratör som äger båda.

Att installera klienten för hand skapar inte den mappningen, och panelen med vanliga inställningar gör inte program individuellt valbara. En leverantör kan exponera sina egna programregler, och de följer leverantörens dokumentation i stället för en allmän regel.

Tre vägar till separering per program utan MDM

Där hantering inte är tillgänglig är en proxy det praktiska svaret. Ställ in programmets egen proxykonfiguration, eller använd en PAC-fil som väljer efter destination och protokoll bara för det programmet.

En lokal proxy avslutar anslutningen och återupprättar den genom tunneln, så programmet behöver aldrig en rutt. Det andra alternativet är en separat nätverksstack: en virtuell maskin eller container med egen standardrutt, som programmet når över en lokal adress. Det tredje är att acceptera destinationsbaserad routing och släppa kravet, vilket är ärligt när båda programmen får använda tunneln. Alla tre går att testa, och ingen av dem låtsas att en rutt känner till processer.

Skriv begäran så att svaret är entydigt

Beskriv arbetsflödet i stället för mekanismen: vilket program som behöver vilken tjänst, om ett annat program måste hållas borta från samma tjänst, och vad som ska hända medan tunneln är nere. De tre svaren väljer designen. De berättar också för administratören om begäran är en routingändring eller ett utrullningsprojekt.

Ta uttryckligen med fallet med det undantagna programmet. En klient som stoppar ett program när dess skyddade väg inte är tillgänglig beter sig annorlunda än en som låter det falla tillbaka till det fysiska gränssnittet, och användare märker skillnaden direkt. Namnge förväntan i ärendet. Verifiera sedan på den faktiska maskinen, för samma produkt beter sig ofta annorlunda på macOS än på Windows, och dess macOS-dokumentation är den enda pålitliga källan till vad inställningarna gör.