Per-app-VPN eller split tunnel? Kva ein Mac-rute kan avgjere

To program opnar samband til den same kontorserveren, og berre eitt av dei bør bruke tunnelen. Ei rute kan ikkje uttrykkje det ønsket, fordi rutetabellar er bygde på destinasjonar og ikkje har noko omgrep om kva prosess som opna socketen. Kva folk ber om og kva dei treng, er ofte ulike ting. Skil dei to før du endrar nokon konfigurasjon.

Veljaren er ein destinasjon, aldri ein prosess

Kvar rutingsavgjerd byrjar med ein destinasjonsadresse og endar med eit grensesnitt. Kjernen spør aldri kva program som sende pakken, og på macOS rutar pf heller ikkje etter prosess, så ein brannmurregel kan ikkje setje eitt program på ein annan veg. Derfor tek den same serveren, nådd frå ein nettlesar og frå eit rapporteringsverktøy, ein veg for begge. Skilje på programnivå må derfor kome frå noko anna enn ei rute: eit VPN-plugin som eig socketen, ein proxy som tek sambandet på vegner av programmet, eller ein separat nettverksstakk. Ingen av dei er ei rutingsendring.

To program som snakkar med éi adresse, er den reinaste testen av eit design. Viss svaret ikkje kan vere ulikt for dei, er designet destinasjonsbasert, uansett kva det blir kalla.

Kva ein vanleg split tunnel faktisk gir

Ein split tunnel installerer ruter for dei private prefiksa og lèt alt anna bli på den fysiske vegen. Det er vanlegvis det førespurnaden meiner: nå kontorserveren gjennom tunnelen, halde offentleg surfing direkte. Det er enkelt, kvar vanlege klient støttar det, og det blir handheva av same mekanisme som kvar annan rute. Kontroller den spesifikke destinasjonen med route -n get i staden for å lese standardruta, sidan ein split tunnel ofte lèt standardruta vere urørt.

Å redigere standardruta for hand er ikkje ei konvertering til noko. Det kjempar mot klienten si eiga gjenoppretting av ruter og kan, i klientar som installerar ein beskyttelsespolitikk, etterlate maskinen i ein tilstand som korkje du eller klienten ventar. Konfigurer i staden split tunnelen i dei støtta innstillingane til klienten.

Kva per-app-VPN på macOS krev

Ekte per-app-VPN på macOS er ein Network Extension-funksjon som blir styrt av ein konfigurasjonsprofil. Ei administrasjonsnyttelast koplar utvalde program til ein VPN-konfigurasjon, og systemet ruter deretter trafikken til desse programma dit. Det er ei administrert utrulling, som betyr ein MDM, ein signert profil og ein administrator som eig begge.

Å installere klienten for hand lagar ikkje den koplinga, og det vanlege innstillingspanelet gjer ikkje program individuelt valbare. Ein leverandør kan eksponere sine eigne programreglar, og dei følgjer dokumentasjonen til leverandøren i staden for ein generell regel.

Tre vegar til skilje per program utan MDM

Der administrasjon ikkje er tilgjengeleg, er ein proxy det praktiske svaret. Set eigen proxykonfigurasjon for programmet, eller bruk ei PAC-fil som vel etter destinasjon og protokoll berre for det programmet.

Ein lokal proxy avsluttar sambandet og gjenopprettar det gjennom tunnelen, slik at programmet aldri treng ei rute. Det andre alternativet er ein separat nettverksstakk: ein virtuell maskin eller container med eigen standardrute, som programmet når over ei lokal adresse. Det tredje er å godta destinasjonsbasert ruting og droppe kravet, noko som er ærleg når begge programma kan bruke tunnelen. Alle tre kan testast, og ingen av dei lèt som om ei rute kjenner prosessar.

Skriv førespurnaden slik at svaret er eintydig

Beskriv arbeidsflyten i staden for mekanismen: kva program som treng kva teneste, om eit anna program må haldast borte frå same teneste, og kva som skal skje medan tunnelen er nede. Dei tre svara vel designet. Dei fortel også administratoren om førespurnaden er ei rutingsendring eller eit utrullingsprosjekt.

Ta eksplisitt med tilfellet med det utelukka programmet. Ein klient som stoppar eit program når den beskytta vegen ikkje er tilgjengeleg, oppfører seg annleis enn ein som lèt det falle tilbake til det fysiske grensesnittet, og brukarar merkjer skilnaden med ein gong. Namngi forventninga i saka. Verifiser deretter på den faktiske maskinen, for det same produktet oppfører seg ofte annleis på macOS enn på Windows, og macOS-dokumentasjonen er den einaste pålitelege kjelda til kva innstillingane gjer.