Per-app-VPN eller split tunnel? Hvad en Mac-rute kan afgøre

To programmer åbner forbindelser til den samme kontorserver, og kun ét af dem bør bruge tunnelen. En rute kan ikke udtrykke det ønske, fordi routingtabeller er baseret på destinationer og ikke har noget begreb om, hvilken proces der åbnede socketen. Hvad folk beder om, og hvad de har brug for, er ofte forskellige ting. Skil de to ad, før du ændrer nogen konfiguration.

Vælgeren er en destination, aldrig en proces

Enhver routingbeslutning starter med en destinationsadresse og slutter med en grænseflade. Kernen spørger aldrig, hvilket program der sendte pakken, og på macOS router pf heller ikke efter proces, så en firewallregel kan ikke sætte ét program på en anden vej. Derfor tager den samme server, nået fra en browser og fra et rapporteringsværktøj, én vej for begge. Adskillelse på programniveau skal derfor komme fra noget andet end en rute: et VPN-plugin, der ejer socketen, en proxy, der tager forbindelsen på programmets vegne, eller en separat netværksstak. Ingen af dem er en routingændring.

To programmer, der taler med én adresse, er den reneste test af et design. Hvis svaret ikke kan være forskelligt for dem, er designet destinationsbaseret, hvad det så end kaldes.

Hvad en almindelig split tunnel faktisk giver

En split tunnel installerer ruter til de private præfikser og lader alt andet blive på den fysiske vej. Det er normalt det, anmodningen betyder: nå kontorserveren gennem tunnelen, hold offentlig browsing direkte. Det er enkelt, enhver almindelig klient understøtter det, og det håndhæves af den samme mekanisme som enhver anden rute. Kontroller den specifikke destination med route -n get i stedet for at læse standardruten, da en split tunnel ofte lader standardruten være urørt.

At redigere standardruten i hånden er ikke en konvertering til noget. Det kæmper mod klientens egen gendannelse af ruter og kan, i klienter der installerer en beskyttelsespolitik, efterlade maskinen i en tilstand, som hverken du eller klienten forventer. Konfigurer i stedet split tunnelen i klientens understøttede indstillinger.

Hvad per-app-VPN på macOS kræver

Ægte per-app-VPN på macOS er en Network Extension-funktion, der styres af en konfigurationsprofil. En administrationsnyttelast knytter udvalgte programmer til en VPN-konfiguration, og systemet sender derefter disse programmers trafik den vej. Det er en administreret udrulning, hvilket betyder en MDM, en signeret profil og en administrator, der ejer begge.

At installere klienten i hånden opretter ikke den kobling, og det almindelige indstillingspanel gør ikke programmer individuelt valgbare. En leverandør kan udstille sine egne programregler, og de følger leverandørens dokumentation i stedet for en generel regel.

Tre veje til adskillelse på programniveau uden MDM

Hvor administration ikke er tilgængelig, er en proxy det praktiske svar. Indstil programmets egen proxykonfiguration, eller brug en PAC-fil, der kun for det program vælger efter destination og protokol.

En lokal proxy afslutter forbindelsen og genopretter den gennem tunnelen, så programmet aldrig har brug for en rute. Den anden mulighed er en separat netværksstak: en virtuel maskine eller container med sin egen standardrute, som programmet når over en lokal adresse. Den tredje er at acceptere destinationsbaseret routing og droppe kravet, hvilket er ærligt, når begge programmer må bruge tunnelen. Alle tre kan testes, og ingen af dem lader som om en rute kender til processer.

Skriv anmodningen, så svaret er entydigt

Beskriv arbejdsgangen i stedet for mekanismen: hvilket program der har brug for hvilken tjeneste, om et andet program skal holdes væk fra samme tjeneste, og hvad der skal ske, mens tunnelen er nede. De tre svar vælger designet. De fortæller også administratoren, om anmodningen er en routingændring eller et udrulningsprojekt.

Medtag tilfældet med det udelukkede program eksplicit. En klient, der stopper et program, når dets beskyttede vej ikke er tilgængelig, opfører sig anderledes end en, der lader det falde tilbage til den fysiske grænseflade, og brugerne bemærker forskellen med det samme. Navngiv forventningen i sagen. Verificér derefter på den faktiske maskine, for det samme produkt opfører sig ofte anderledes på macOS end på Windows, og dets macOS-dokumentation er den eneste pålidelige kilde til, hvad indstillingerne gør.