Zwei Windows-Setups sehen in den Einstellungen gleich aus und verhalten sich völlig anders. Das eine ist ein kopiertes VPN-Profil mit einem Anwendungstrigger, sodass der Start einer ausführbaren Datei den Tunnel aufbaut. Das andere ist ein Split-Tunneling-Profil, dessen Routenliste zufällig das abdeckt, womit diese Anwendung spricht. Das erste beantwortet, wann der Tunnel existiert. Das zweite beantwortet, welche Pakete hineingehen, und nur das zweite lässt den Rest des Rechners auf dem physischen Link, während die App verbunden bleibt.

Der Trigger ist eine Lebenszyklusregel, keine Routingregel

Add-VpnConnectionTriggerApplication bindet einen ausführbaren Pfad an einen Profilnamen. Wenn dieser Prozess startet, wählt der Verbindungs-Manager für den Remotezugriff das Profil, und wenn die Triggerbedingung endet, kann die Verbindung abbrechen. Nichts in diesem Austausch prüft Sockets. Das Cmdlet braucht eine erhöhte Shell, den vollständigen Pfad zur Binärdatei und -Force wenn Sie einen vorhandenen Eintrag ersetzen. Bestätigen Sie, dass die Zuordnung erhalten blieb, mit Get-VpnConnectionTrigger statt sich auf die Eingabeaufforderung zu verlassen; Microsofts Referenz zu Add-VpnConnectionTriggerApplication listet die Parameter und die Beispiele auf.

Zwei Grenzen erklären die meisten Meldungen, der Trigger tue nichts. Trigger sind um Profile für alle Benutzer herum gebaut, also ist der Profilbereich das Erste, was zu klären ist, und der Anwendungspfad muss zur tatsächlich laufenden Binärdatei passen, nicht zu einer Verknüpfung oder einem Launcher, der einen zweiten Prozess startet. Die andere Grenze ist gewollt: In einem Netz, das Windows als vertrauenswürdig einstuft, bleibt der Trigger untätig, weil das Profil für den Einsatz außerhalb des Büros gedacht ist.

Add-VpnConnectionTriggerApplication -Name "APP_VPN" -ApplicationID "C:\Program Files\Vendor\app.exe" -Force
Get-VpnConnectionTrigger -Name "APP_VPN" | Format-List *
Get-VpnConnection -Name "APP_VPN" | Format-List Name,ConnectionStatus,SplitTunneling,AllUserConnection

Split-Tunneling entscheidet, was den Tunnel überquert

Mit ausgeschaltetem Split-Tunneling installiert Windows eine klassenbasierte Standardroute mit niedriger Metrik auf der VPN-Schnittstelle. Jeder Socket folgt ihr, auch der Browser und der Updatedienst, sodass ein Trigger in dieser Konfiguration den ganzen Rechner verschiebt, solange das Profil verbunden ist. Der Trigger bleibt nur eine Lebenszyklusregel; der Wirkungsradius kam von der Route.

Mit eingeschaltetem Split-Tunneling trägt das Profil nur die Präfixe, die das Gateway schiebt oder die Sie der VPN-Schnittstelle hinzufügen. Alles andere nutzt weiter die physische Standardroute. Das ist die Anordnung, die Leute normalerweise mit einer App über einen getrennten Ausgang meinen, und sie ist durch und durch eine Routingentscheidung.

Set-VpnConnection -Name "APP_VPN" -SplitTunneling $true
Get-VpnConnection -Name "APP_VPN" | Select-Object SplitTunneling
Get-NetRoute -InterfaceAlias "APP_VPN" | Sort-Object DestinationPrefix

Wo ein geroutetes Split die App nicht mehr isoliert

Der häufige Fehler ist ein Ziel, das nie in der Routenliste des Tunnels auftaucht. Eine App, die sich gegen eine Adresse anmeldet und dann von einem CDN streamt oder ein Dutzend wechselnde Endpunkte auflöst, legt einige Verbindungen auf die VPN-Schnittstelle und den Rest auf WLAN. IPv6 ist eine eigene Tabelle, sodass ein Profil, das nur IPv4-Präfixe schiebt, korrekt aussehen kann, während der IPv6-Verkehr der App lokal bleibt.

Zwei kleinere Effekte zählen genauso viel. Der längste Präfix gewinnt, sodass eine spezifischere On-Link-Route, ein /32 für einen Verwaltungshost oder das Subnetz eines zweiten Adapters den Tunnel genau für die Adresse schlagen kann, die Sie interessiert. Auch die Namensauflösung passiert vor dem Routing: Wenn nicht die DNS-Server des Profils oder eine NRPT-Regel den Namen abdecken, kann die App über den physischen Adapter auflösen und dann eine Adresse wählen, die nie in den getunnelten Präfixen lag.

Drei Formen und was jede bringt

Die Tabelle ist der Teil, den ich an die Wand kleben würde, denn die Entscheidung betrifft den Wirkungsradius, nicht die Funktionen. Wenn die Ziele der App stabile Präfixe sind, die Sie auflisten können, liefert das geroutete Split Isolation mit dem kleinsten Fußabdruck. Wenn nicht, hält ein Standardroutenprofil hinter einer VM oder einem zweiten Gerät die Trennung ehrlich, zum Preis, mehr als einen Prozess zu verschieben.

ShapeWhat starts the tunnelWhat enters itPick it when
Trigger plus routed splitProcess startOnly pushed or added prefixesThe app's endpoints are stable prefixes and the host should stay direct
Trigger plus default routeProcess startEverything, machine-wideYou need one exit for all traffic and accept the wider scope
Separate VM or deviceGuest boot or loginEverything inside that guestThe app's destinations rotate, or the host must keep its own public address

Was keine dieser Optionen bietet, ist Bindung auf Socket-Ebene auf dem Host. Der klassische Windows-VPN-Client hat keine Regel, die sagt, dieser Prozess müsse jenen Adapter nutzen; Trigger und Routenfilter leben in verschiedenen Schichten, und die Schicht, die eine Schnittstelle auswählt, ist die Routentabelle. Wenn ein Ratgeber Durchsetzung pro App allein aus einem kopierten Profil verspricht, fragen Sie, welche Route oder welcher Filter die Arbeit macht.

Prüfen Sie das Paar in einem Durchgang

Testen Sie Lebenszyklus und Routing getrennt, in dieser Reihenfolge. Schließen Sie die App, bestätigen Sie, dass das Profil Disconnected meldet, starten Sie dann die App und prüfen Sie, ob sich der Status geändert hat. Erst wenn der Tunnel steht, sollten Sie fragen, wohin ein bestimmtes Ziel geht, und Sie sollten die Adresse verwenden, die die App tatsächlich wählt, statt einer Vermutung.

$app = Get-Process app | Select-Object -First 1
Get-VpnConnection -Name "APP_VPN" | Select-Object ConnectionStatus
Get-NetTCPConnection -OwningProcess $app.Id -State Established | Select-Object RemoteAddress,RemotePort
Find-NetRoute -RemoteIPAddress 203.0.113.10

Find-NetRoute nennt die Schnittstelle und den nächsten Hop, der dieses Ziel tragen würde. Ein physischer Alias dort bedeutet, dass der Tunnel steht und für diesen Fluss irrelevant ist: Prüfen Sie die geschobenen Präfixe, dann die spezifischeren Routen, dann IPv6. Wenn sich der Status gar nicht ändert, hat der Trigger nicht ausgelöst, und der Pfad zur ausführbaren Datei, der Profilbereich und das Betriebsprotokoll des VPN-Clients sind die drei Stellen zum Nachsehen.

Räumen Sie sauber auf, damit der nächste Test ehrlich ist

Entfernen Sie in umgekehrter Reihenfolge, in der Sie gebaut haben: zuerst den Anwendungstrigger, dann das Profil. Das Profil zu löschen, während der Trigger bleibt, hinterlässt eine hängende Zuordnung, die den nächsten Versuch verwirrend macht, und Remove-VpnConnection -Force löscht nicht immer einen Telefonbucheintrag, der außerhalb der Cmdlets angelegt wurde.

Einträge pro Benutzer liegen im rasphone.pbk des Benutzers unter dem Roaming-Profil; Einträge für alle Benutzer liegen unter ProgramData. Prüfen Sie den Store, der zum Profilbereich passt, verbinden Sie das behaltene Profil erneut und bestätigen Sie, dass seine Routen und DNS noch funktionieren, damit ein späterer Test die vorgenommene Änderung misst und nicht übrig gebliebenen Zustand.

  • Der Tunnel startet beim Prozessstart, nicht bei der Anmeldung.
  • Nur die beabsichtigten Präfixe erscheinen auf der VPN-Schnittstelle.
  • Die echte Remote-Adresse der App löst sich auf den VPN-Alias auf.
  • Nach dem Entfernen des Profils bleibt kein hängender Trigger zurück.

Ähnliche Artikel