Windows-VPN neemt al je verkeer over? Verwijder de standaardroute

Je maakt verbinding met de VPN van kantoor en elke pagina in de browser gaat ineens via dat netwerk: de fileserver is snel, al het andere is traag, gefilterd of weg. De client doet niets verkeerd; het profiel vroeg om een volledige tunnel. De schakelaar die dat stopt, is één selectievakje in een dialoog die de moderne Instellingen-app niet toont, en de gateway heeft bij elke verbinding weer een stem. Deze uitleg volgt de volgorde die de Windows-interface werkelijk aanbiedt en behandelt daarna de controles die nog steeds mislukken als de routetabel er goed uitziet.

Begin bij de adapteigenschappen, niet bij Instellingen

De Instellingen-app vermeldt het profiel onder Netwerk en internet en dan VPN, maar toont alleen algemene opties. De beslissing over de standaardgateway zit op de adapter. Open de klassieke adapterlijst met Win+R en ncpa.cpl, klik met rechts op de VPN-verbinding, kies Eigenschappen, selecteer Internetprotocol versie 4, kies nogmaals Eigenschappen en dan Geavanceerd. Haal het vinkje weg bij Standaardgateway op extern netwerk gebruiken en bevestig je weg uit alle drie de dialogen.

Maak opnieuw verbinding voordat je test, want het selectievakje wordt toegepast wanneer de tunnel tot stand komt en een bestaande sessie houdt de tabel die hij heeft opgebouwd. Ontbreekt de adapter terwijl de client losgekoppeld is, maak dan één keer verbinding en open het venster opnieuw. Een leveranciersclient die een TAP- of Wintun-adapter installeert zonder IPv4-eigenschappenpagina heeft deze dialoog helemaal niet; daarvoor is dezelfde beslissing een split-tunneloptie in de eigen instellingen van de client, en het selectievakje van de adapter is de verkeerde plek om te zoeken.

Dezelfde wijziging vanuit PowerShell

Voor een profiel dat in het Windows VPN-archief is gemaakt, is de instelling scriptbaar, wat je wilt als de machine vaak opnieuw wordt ingericht:

Set-VpnConnection -Name "Office" -SplitTunneling $true
Get-VpnConnection -Name "Office" | Select-Object Name,SplitTunneling

Die cmdlet bereikt alleen profielen in dat archief. Een verbinding die door een client van derden is toegevoegd, verschijnt niet, en de opdracht mislukt met een naamfout die als een typefout leest. Let ook op wat de schakelaar niet doet: hij voorkomt dat de client een standaardroute installeert, maar hij verwijdert geen routes die de gateway bij het verbinden opdringt, dus de volgende sectie is op veel netwerken nog steeds nodig.

Wanneer de gateway de standaardroute terugduwt

Lees eerst de tabel. Twee standaardvermeldingen met verschillende metrische waarden betekenen dat de profielwijziging werkte en dat de opgedrongen route die toch verving:

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-NetAdapter | Select-Object Name,ifIndex

Verwijder de standaardroute die bij de tunnel hoort en houd de fysieke. Gebruik de interface-index uit de derde opdracht, niet de adapteralias, want scripts die een alias doorgeven breken zodra de weergavenaam verandert:

Remove-NetRoute -DestinationPrefix 0.0.0.0/0 -InterfaceIndex 21 -Confirm:$false
route delete 0.0.0.0 10.8.0.1

Het verwijderen neemt kantoor mee, dus voeg de bedrijfsprefixen weer toe via de gateway van de tunnel. Dit is de regel die mensen overslaan, en daarom volgt «de VPN werkte niet meer» op een geslaagde split-tunnelwijziging:

route add 10.0.0.0 mask 255.0.0.0 10.8.0.1 metric 5 if 21

Niets hiervan overleeft een nieuwe verbinding, wat eerlijk gedrag is en geen bug: de adapter wordt opnieuw opgebouwd en de client past opnieuw toe wat het profiel en de gateway zijn overeengekomen. Als de standaardroute elke keer terugkomt, is de gateway zo ingesteld dat hij split-tunneling weigert en blijft hij die opdringen, of verbreekt hij de sessie. Dat is het beleid van de netwerkbeheerder, en het verzoek hoort daar, niet in een lokaal script dat er één keer per verbinding tegen vecht.

Controleer DNS, IPv6 en de metrische waarden opnieuw na één nieuwe verbinding

Het verwijderen van een IPv4-standaardroute bewijst niets over de andere familie of over naamresolutie. Een tunnel kan IPv6 dragen terwijl de IPv4-standaard lokaal blijft, en een opgedrongen resolverlijst kan interne namen aan de praat houden terwijl de query's die hem gebruiken een andere weg nemen. Controleer alle drie voordat je het af noemt:

Get-NetRoute -DestinationPrefix ::/0
Get-DnsClientServerAddress -InterfaceAlias "Office"
Get-DnsClientNrptPolicy

Als de toestand bij elke verbinding terugkeert, verplaats de opdrachten dan naar een actie per verbinding in plaats van de tabel met de hand te bewerken: een geplande taak die op het verbindingsgebeurtenis start, of de eigen split-tunnelinstelling van de client waar die bestaat. Houd de interface-index in een variabele en zoek hem op tijdens het uitvoeren, want hij kan veranderen wanneer adapters worden toegevoegd of verwijderd.

Bepaal wat je hebt opgegeven

Lokaal internetverkeer wordt niet langer door kantoor geïnspecteerd of gefilterd, en alles wat alleen via de tunnel wordt gepubliceerd, heeft nu een eigen route nodig. Sommige organisaties beschouwen split-tunneling als een beleidsschending, dus bevestig dat voordat je een beheerd apparaat wijzigt; een opgedrongen standaard is soms het handhavingsmechanisme en geen ongeluk. De documentatie van Set-VpnConnection noemt de split-tunnelingparameter en de profieltypen waarvoor die geldt.

Verifieer daarna in een vaste volgorde: wie de standaardroute bezit, gewoon browsen, één bedrijfshost op adres, één interne naam, en dezelfde vier na één nieuwe verbinding. Als browsen werkt en de bedrijfshost faalt, ontbreekt de prefixroute en niet de standaard die je hebt verwijderd, en dat is veel goedkoper te repareren dan het profiel opnieuw opbouwen.