Per-app-VPN eller split tunnel? Hva en Mac-rute kan avgjøre

To programmer åpner forbindelser til den samme kontorserveren, og bare ett av dem bør bruke tunnelen. En rute kan ikke uttrykke det ønsket, fordi rutetabeller er bygget på destinasjoner og ikke har noe begrep om hvilken prosess som åpnet socketen. Hva folk ber om og hva de trenger, er ofte forskjellige ting. Skill de to før du endrer noen konfigurasjon.

Velgeren er en destinasjon, aldri en prosess

Hver rutingsbeslutning starter med en destinasjonsadresse og ender med et grensesnitt. Kjernen spør aldri hvilket program som sendte pakken, og på macOS ruter pf heller ikke etter prosess, så en brannmurregel kan ikke sette ett program på en annen vei. Derfor tar den samme serveren, nådd fra en nettleser og fra et rapporteringsverktøy, én vei for begge. Skille på programnivå må derfor komme fra noe annet enn en rute: et VPN-plugin som eier socketen, en proxy som tar forbindelsen på programmets vegne, eller en separat nettverksstakk. Ingen av dem er en rutingsendring.

To programmer som snakker med én adresse, er den reneste testen av et design. Hvis svaret ikke kan være forskjellig for dem, er designet destinasjonsbasert, uansett hva det kalles.

Hva en vanlig split tunnel faktisk gir

En split tunnel installerer ruter for de private prefiksene og lar alt annet bli på den fysiske veien. Det er vanligvis det forespørselen betyr: nå kontorserveren gjennom tunnelen, holde offentlig surfing direkte. Det er enkelt, enhver vanlig klient støtter det, og det håndheves av samme mekanisme som enhver annen rute. Kontroller den spesifikke destinasjonen med route -n get i stedet for å lese standardruten, siden en split tunnel ofte lar standardruten være urørt.

Å redigere standardruten for hånd er ikke en konvertering til noe. Det kjemper mot klientens egen gjenoppretting av ruter og kan, i klienter som installerer en beskyttelsespolitikk, etterlate maskinen i en tilstand som verken du eller klienten forventer. Konfigurer i stedet split tunnelen i klientens støttede innstillinger.

Hva per-app-VPN på macOS krever

Ekte per-app-VPN på macOS er en Network Extension-funksjon som styres av en konfigurasjonsprofil. En administrasjonsnyttelast kobler utvalgte programmer til en VPN-konfigurasjon, og systemet ruter deretter disse programmenes trafikk dit. Det er en administrert utrulling, som betyr en MDM, en signert profil og en administrator som eier begge.

Å installere klienten for hånd lager ikke den koblingen, og det vanlige innstillingspanelet gjør ikke programmer individuelt valgbare. En leverandør kan eksponere sine egne programregler, og de følger leverandørens dokumentasjon i stedet for en generell regel.

Tre veier til skille per program uten MDM

Der administrasjon ikke er tilgjengelig, er en proxy det praktiske svaret. Sett programmets egen proxykonfigurasjon, eller bruk en PAC-fil som velger etter destinasjon og protokoll bare for det programmet.

En lokal proxy avslutter forbindelsen og gjenoppretter den gjennom tunnelen, slik at programmet aldri trenger en rute. Det andre alternativet er en separat nettverksstakk: en virtuell maskin eller container med egen standardrute, som programmet når over en lokal adresse. Det tredje er å godta destinasjonsbasert ruting og droppe kravet, noe som er ærlig når begge programmene kan bruke tunnelen. Alle tre kan testes, og ingen av dem later som en rute kjenner til prosesser.

Skriv forespørselen slik at svaret er entydig

Beskriv arbeidsflyten i stedet for mekanismen: hvilket program som trenger hvilken tjeneste, om et annet program må holdes borte fra samme tjeneste, og hva som skal skje mens tunnelen er nede. De tre svarene velger designet. De forteller også administratoren om forespørselen er en rutingsendring eller et utrullingsprosjekt.

Ta eksplisitt med tilfellet med det utelukkede programmet. En klient som stopper et program når den beskyttede veien ikke er tilgjengelig, oppfører seg annerledes enn en som lar det falle tilbake til det fysiske grensesnittet, og brukere merker forskjellen med en gang. Navngi forventningen i saken. Verifiser deretter på den faktiske maskinen, for det samme produktet oppfører seg ofte annerledes på macOS enn på Windows, og macOS-dokumentasjonen er den eneste pålitelige kilden til hva innstillingene gjør.