Tunnelen rapporterer at den er tilkoblet, og wikien lastes fortsatt. Så stopper en nedlasting, og delingen på hyllen slutter å svare. Tunnelen gjorde jobben sin, og profilen gjorde rett og slett krav på hver destinasjon.

Windows behandler en VPN-tilkobling som en rutebeslutning. Inntil den beslutningen innsnevres, oppfører maskinen seg som om den hadde flyttet til kontoret.

Hvorfor en fungerende tunnel føles som et utfall

En profil som har lov til å bruke den eksterne gatewayen, installerer en standardrute gjennom tunnelen. Hver destinasjon som ikke ligger på den lokale lenken, forlater da nettverket gjennom kontorets brannmur. Lokale delinger slutter å svare fordi trafikken deres nå reiser til et annet kontinent og tilbake. Ingenting i klientstatusen gjenspeiler det.

Symptomene er forvirrende med vilje. Navneoppslag kan fortsatt virke mens delingen timer ut, eller omvendt. En bruker rapporterer at VPN-en er ødelagt, klienten rapporterer at den er i orden, og begge utsagnene er nøyaktige.

Avmerkingsboksen som gjemmer seg i IPv4-dialogen

Innstillingen ligger flere dialoger dypt. Åpne ncpa.cpl, høyreklikk på tilkoblingen, deretter IPv4-egenskaper, deretter Avansert, og fjern alternativet som lar tilkoblingen bli den eksterne standardgatewayen. Den ene boksen avgjør om profilen er en full tunnel. Alt annet i profilen gjelder fortsatt.

Sammenlign route print -4 før og etter gjenoppkoblingen. Oppføringen 0.0.0.0 som før pekte på tunnelen, bør være borte, og bedriftens prefikser bør fortsatt være der.

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

Å endre grensesnittets metrikk er ingen erstatning. En metrikk avgjør bare mellom to konkurrerende standardruter, og en klient som installerer sin egen standardrute på nytt ved hver tilkobling, vinner den konkurransen uansett hvilket tall som er satt.

Prefikset som ingen listet opp

Delt tunnellering eksponerer nøyaktig de prefiksene som er registrert i profilen. Et kontorsubnett som ble lagt til etter at profilen ble skrevet, forblir utilgjengelig mens tunnelen er helt sunn. Rapporten kommer da inn som én ødelagt server i stedet for en ødelagt VPN.

En håndlagt rute dekker gapet til gateway-adressen endres. Å registrere prefikset i tilkoblingen er mer solid, fordi prefikset da følger tilkoblingen i stedet for en gjettet adresse.

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

Les den lagrede listen og den levende tabellen sammen. Et lagret prefiks kan finnes mens tabellen aldri mottar det, noe som skjer når en administrasjonsagent filtrerer ruter etter at tilkoblingen kommer opp. Det motsatte skjer også, med en registerrute som peker på en adapter som er nede. Ingen av de to visningene alene forteller hele historien.

Bevise resultatet etter en omstart

Spor i begge retninger og løs opp ved navn. Et offentlig spor bør gå ut gjennom leverandøren, et internt spor bør gå inn i tunnelen, og en intern vert bør svare ved navn og ikke bare ved adresse.

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

Gjenta etter en frakobling, en gjenoppkobling og én omstart. Et prefiks som overlever en manuell gjenoppkobling og forsvinner etter en omstart, ble aldri lagret i profilen.

Behold også skriveren og NAS-en i testen, fordi en delt tunnel som kutter av enhetene ved siden av den bærbare, har løst ett problem ved å skape et mindre og mer irriterende. Microsofts referanse for Add-VpnConnectionRoute er stedet der du sjekker parameteres stavemåte mot modulversjonen din.

Relaterte artikler