Delad tunnel i Windows: gateway-rutan och det saknade prefixet

Windows skickar allt genom tunneln tills du rensar en kryssruta, och sedan för lite tills du lägger till subnätet. Båda hör till samma ändring.

Tunneln rapporterar ansluten och wikin laddas fortfarande. Sedan fastnar en nedladdning och delningen på hyllan slutar svara. Tunneln gjorde sitt jobb, och profilen gjorde helt enkelt anspråk på varje destination.

Windows behandlar en VPN-anslutning som ett routingbeslut. Tills beslutet har snävats in beter sig maskinen som om den hade flyttat till kontoret.

Varför en fungerande tunnel känns som ett avbrott

En profil som får använda den fjärranslutna gatewayen installerar en standardrutt genom tunneln. Varje destination som inte ligger på den lokala länken lämnar då nätverket genom kontorets brandvägg. Lokala delningar slutar svara eftersom deras trafik nu reser till en annan kontinent och tillbaka. Inget i klientens status speglar det.

Symtomen är förvirrande med avsikt. Namnuppslagning kan fortfarande fungera medan delningen får timeout, eller tvärtom. En användare rapporterar att VPN:et är trasigt, klienten rapporterar att den är okej, och båda påståendena är korrekta.

Kryssrutan som gömmer sig i IPv4-dialogen

Inställningen ligger flera dialoger djupt. Öppna ncpa.cpl, högerklicka på anslutningen, sedan IPv4-egenskaper, sedan Avancerat, och rensa alternativet som låter anslutningen bli den fjärranslutna standardgatewayen. Den enda rutan avgör om profilen är en full tunnel. Allt annat i profilen gäller fortfarande.

Jämför route print -4 före och efter återanslutningen. Posten 0.0.0.0 som tidigare pekade på tunneln bör vara borta, och företagets prefix bör fortfarande finnas där.

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

Att ändra gränssnittets metrik är ingen ersättning. En metrik avgör bara mellan två konkurrerande standardrutter, och en klient som installerar om sin egen standardrutt vid varje anslutning vinner den tävlingen oavsett vilket tal som är satt.

Prefixet som ingen listade

Delad tunnling exponerar exakt de prefix som är registrerade i profilen. Ett kontorssubnät som lades till efter att profilen skrevs förblir oåtkomligt medan tunneln är helt frisk. Rapporten kommer då in som en trasig server i stället för ett trasigt VPN.

En handpålagd rutt täcker gapet tills gateway-adressen ändras. Att registrera prefixet i anslutningen är stadigare, eftersom prefixet då följer anslutningen i stället för en gissad adress.

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

Läs den sparade listan och den levande tabellen tillsammans. Ett sparat prefix kan finnas medan tabellen aldrig tar emot det, vilket händer när en hanteringsagent filtrerar rutter efter att anslutningen kommit upp. Det omvända händer också, med en registerrutt som pekar på en adapter som är nere. Ingen av de två vyerna berättar hela historien ensam.

Bevisa resultatet efter en omstart

Spåra i båda riktningarna och lös upp med namn. Ett offentligt spår bör gå ut via leverantören, ett internt spår bör gå in i tunneln, och en intern värd bör svara med namn och inte bara med adress.

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

Upprepa efter en frånkoppling, en återanslutning och en omstart. Ett prefix som överlever en manuell återanslutning och försvinner efter en omstart sparades aldrig i profilen.

Behåll även skrivaren och NAS:en i testet, eftersom en delad tunnel som skär av enheterna bredvid den bärbara har löst ett problem genom att skapa ett mindre och mer irriterande. Microsofts referens för Add-VpnConnectionRoute är platsen där du kontrollerar parametrarnas stavning mot din modulversion.

Relaterade artiklar