Split-tunnel op Windows: het gateway-vakje en de ontbrekende prefix

De tunnel meldt verbonden en de wiki laadt nog. Dan stokt een download en de share op de plank antwoordt niet meer. De tunnel deed zijn werk, en het profiel claimde simpelweg elke bestemming.

Windows behandelt een VPN-verbinding als een routeringsbeslissing. Tot die beslissing wordt vernauwd, gedraagt de machine zich alsof hij naar kantoor is verhuisd.

Waarom een werkende tunnel als een storing voelt

Een profiel dat de externe gateway mag gebruiken, installeert een standaardroute door de tunnel. Elke bestemming die niet op de lokale link ligt, verlaat het netwerk dan via de firewall van kantoor. Lokale shares antwoorden niet meer omdat hun verkeer nu naar een ander continent reist en terug. Niets in de clientstatus weerspiegelt dat.

De symptomen zijn met opzet verwarrend. Naamresolutie kan nog werken terwijl de share een time-out krijgt, of andersom. Een gebruiker meldt de VPN als kapot, de client meldt zichzelf als in orde, en beide uitspraken zijn juist.

Het vinkje dat zich in het IPv4-dialoog verstopt

De instelling zit meerdere dialoogvensters diep. Open ncpa.cpl, rechtsklik op de verbinding, dan IPv4-eigenschappen, dan Geavanceerd, en wis de optie waardoor de verbinding de externe standaardgateway wordt. Dat ene vakje bepaalt of het profiel een volledige tunnel is. Al het andere in het profiel geldt nog steeds.

Vergelijk route print -4 voor en na het opnieuw verbinden. De 0.0.0.0-vermelding die eerder naar de tunnel wees, zou weg moeten zijn, en de bedrijfsprefixen zouden er nog moeten staan.

route print -4 | findstr /c:"0.0.0.0"
Get-VpnConnection -Name 'Work VPN' | Select-Object Name, SplitTunneling, Routes

De metriek van de interface wijzigen is geen vervanging. Een metriek beslist alleen tussen twee concurrerende standaardroutes, en een client die bij elke verbinding zijn eigen standaardroute opnieuw installeert, wint die strijd ongeacht welk getal is ingesteld.

De prefix die niemand vermeldde

Split-tunneling legt precies de prefixen vast die in het profiel zijn vastgelegd bloot. Een kantoor-subnet dat na het schrijven van het profiel is toegevoegd, blijft onbereikbaar terwijl de tunnel volledig gezond is. Het rapport komt dan binnen als een kapotte server in plaats van een kapotte VPN.

Een met de hand toegevoegde route overbrugt de kloof tot het gateway-adres verandert. De prefix in de verbinding vastleggen is steviger, omdat de prefix dan de verbinding volgt in plaats van een geraden adres.

route -p add 172.20.8.0 mask 255.255.255.0 10.8.0.1
Add-VpnConnectionRoute -ConnectionName 'Work VPN' -DestinationPrefix 172.20.8.0/24
Get-VpnConnection -Name 'Work VPN' | Select-Object -ExpandProperty Routes

Lees de opgeslagen lijst en de live tabel samen. Een opgeslagen prefix kan bestaan terwijl de tabel hem nooit ontvangt, wat gebeurt wanneer een beheeragent routes filtert nadat de verbinding omhoog komt. Het omgekeerde gebeurt ook, met een registerroute die naar een adapter wijst die uit staat. Geen van beide weergaven alleen vertelt het hele verhaal.

Het resultaat bewijzen na een herstart

Traceer in beide richtingen en los op naam op. Een publieke trace hoort via de provider naar buiten te gaan, een interne trace hoort de tunnel in te gaan, en een interne host hoort op naam te antwoorden en niet alleen op adres.

tracert -4 www.example.com
tracert -4 wiki.corp.example
ping -4 fileserver.corp.example
ping -4 172.20.8.20

Herhaal dit na een verbreking, een herverbinding en een herstart. Een prefix die een handmatige herverbinding overleeft en na een herstart verdwijnt, is nooit in het profiel opgeslagen.

Houd ook de printer en de NAS in de test, want een split-tunnel die de apparaten naast de laptop afsnijdt, heeft een probleem opgelost door een kleiner en irritanter probleem te scheppen. Microsofts referentie voor Add-VpnConnectionRoute is de plek om de spelling van parameters tegen je moduleversie te controleren.