Per-app-VPN of split tunneling? Wat een Mac-route kan beslissen

Twee applicaties openen verbindingen naar dezelfde kantoorserver, en slechts één ervan mag de tunnel gebruiken. Een route kan die wens niet uitdrukken, omdat routetabellen op bestemmingen zijn gebaseerd en geen begrip hebben van welk proces de socket heeft geopend. Wat mensen vragen en wat ze nodig hebben, zijn vaak verschillende dingen. Scheid de twee voordat u welke configuratie dan ook wijzigt.

De selector is een bestemming, nooit een proces

Elke routingbeslissing begint met een bestemmingsadres en eindigt met een interface. De kernel vraagt nooit welk programma het pakket heeft verstuurd, en op macOS routeert pf ook niet op proces, dus een firewallregel kan één applicatie niet op een ander pad zetten. Daarom neemt dezelfde server, bereikt via een browser of via een rapportagetool, voor beide één pad. Scheiding op applicatieniveau moet daarom van iets anders dan een route komen: een VPN-plugin die de socket bezit, een proxy die de verbinding namens de applicatie overneemt, of een aparte netwerkstack. Geen daarvan is een routingwijziging.

Twee applicaties die met één adres praten, zijn de schoonste test van een ontwerp. Als het antwoord tussen beide niet kan verschillen, is het ontwerp bestemmingsgebaseerd, hoe het ook heet.

Wat een gewone split tunnel werkelijk oplevert

Een split tunnel installeert routes voor de privéprefixen en laat al het overige op het fysieke pad. Dat is meestal wat het verzoek betekent: de kantoorserver via de tunnel bereiken, openbaar browsen direct houden. Het is eenvoudig, elke gangbare client ondersteunt het, en het wordt afgedwongen door hetzelfde mechanisme als elke andere route. Controleer de specifieke bestemming met route -n get in plaats van de standaardroute te lezen, want een split tunnel laat de standaardroute vaak ongemoeid.

De standaardroute met de hand bewerken is geen overstap naar wat dan ook. Het vecht tegen het eigen herstel van routes door de client en kan, bij clients die een beveiligingsbeleid installeren, de machine achterlaten in een staat die noch u noch de client verwacht. Configureer de split tunnel in plaats daarvan in de ondersteunde instellingen van de client.

Wat per-app-VPN op macOS vereist

Echte per-app-VPN op macOS is een Network Extension-functie die door een configuratieprofiel wordt aangestuurd. Een beheerpayload koppelt gekozen applicaties aan een VPN-configuratie, en het systeem leidt het verkeer van die applicaties vervolgens daarheen. Het is een beheerde uitrol, wat een MDM, een ondertekend profiel en een beheerder betekent die beide bezit.

De client met de hand installeren maakt die koppeling niet, en het gewone instellingenpaneel maakt applicaties niet afzonderlijk selecteerbaar. Een leverancier kan eigen applicatieregels aanbieden, en die volgen zijn documentatie in plaats van een algemene regel.

Drie wegen naar scheiding per applicatie zonder MDM

Waar beheer niet beschikbaar is, is een proxy het praktische antwoord. Stel de eigen proxyconfiguratie van de applicatie in, of gebruik een PAC-bestand dat alleen voor die applicatie op bestemming en protocol selecteert.

Een lokale proxy beëindigt de verbinding en start haar opnieuw door de tunnel, zodat de applicatie nooit een route nodig heeft. De tweede optie is een aparte netwerkstack: een virtuele machine of container met een eigen standaardroute, die de applicatie via een lokaal adres bereikt. De derde is bestemmingsgebaseerd routeren te accepteren en de eis te laten vallen, wat eerlijk is wanneer beide applicaties de tunnel mogen gebruiken. Alle drie zijn testbaar, en geen ervan doet alsof een route processen kent.

Formuleer het verzoek zodat het antwoord ondubbelzinnig is

Beschrijf de werkwijze in plaats van het mechanisme: welke applicatie welke dienst nodig heeft, of een andere applicatie van diezelfde dienst weggehouden moet worden, en wat er moet gebeuren terwijl de tunnel niet beschikbaar is. Die drie antwoorden kiezen het ontwerp. Ze vertellen de beheerder ook of het verzoek een routingwijziging of een uitrolproject is.

Neem het geval van de uitgesloten applicatie expliciet op. Een client die een applicatie stopt wanneer haar beschermde pad niet beschikbaar is, gedraagt zich anders dan een die haar laat terugvallen op de fysieke interface, en gebruikers merken dat verschil meteen. Benoem de verwachting in het ticket. Controleer daarna op de echte machine, want hetzelfde product gedraagt zich op macOS vaak anders dan op Windows, en de macOS-documentatie is de enige betrouwbare bron voor wat de instellingen doen.