Ĉu la Windows-VPN prenas ĉiun vian trafikon? Forigu ĝian defaŭltan itineron

Vi konektiĝas al la oficeja VPN kaj ĉiu paĝo en la retumilo komencas iri tra tiu reto: la dosieruja servilo rapidas, ĉio alia malrapidas, estas filtrita aŭ malaperis. La kliento ne miskondutas; la profilo petis plenan tunelon. La ŝaltilo, kiu haltigas ĝin, estas unu markobutono en dialogo, kiun la moderna programo Agordoj ne montras, kaj la enirejo denove havas vorton ĉe ĉiu konekto. Ĉi tiu gvidilo sekvas la ordon, kiun la Windows-interfaco efektive prezentas, poste kovras la kontrolojn, kiuj ankoraŭ malsukcesas post kiam la itinertabelo aspektas ĝusta.

Komencu en la adaptilaj ecoj, ne en Agordoj

La programo Agordoj listigas la profilon sub Reto kaj Interreto, poste VPN, sed ĝi montras nur ĝeneralajn opciojn. La decido pri la defaŭlta enirejo loĝas sur la adaptilo. Malfermu la klasikan adaptilliston per Win+R kaj ncpa.cpl, dekstre alklaku la VPN-konekton, elektu Ecoj, elektu Interreta protokolo versio 4, elektu denove Ecoj kaj poste Detala. Forigu la markon ĉe Uzi defaŭltan enirejon en la fora reto kaj konfirmu vian eliron el ĉiuj tri dialogoj.

Rekonektiĝu antaŭ ol testi, ĉar la markobutono aplikiĝas kiam la tunelo estiĝas kaj ekzistanta sesio konservas la tabelon, kiun ĝi konstruis. Se la adaptilo mankas dum la kliento estas malkonektita, konektiĝu unufoje kaj remalfermu la fenestron. Vendista kliento, kiu instalas TAP aŭ Wintun adaptilon sen IPv4-ecpaĝo, tute ne havas ĉi tiun dialogon; por ili la sama decido estas opcio de dividita tunelo en la propraj agordoj de la kliento, kaj la markobutono de la adaptilo estas la malĝusta loko por serĉi.

La sama ŝanĝo per PowerShell

Por profilo kreita en la Windows VPN-tenejo, la agordo estas skriptebla, kion vi volas se la maŝino ofte rekonstruiĝas:

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

Tiu cmdlet atingas nur profilon en tiu tenejo. Konekto aldonita de triaparta kliento ne aperos, kaj la komando malsukcesas per noma eraro, kiu aspektas kiel tajperaro. Rimarku ankaŭ, kion la ŝaltilo ne faras: ĝi malhelpas la klienton instali defaŭltan itineron, sed ĝi ne forigas itinerojn, kiujn la enirejo puŝas ĉe konekto, do la sekva sekcio ankoraŭ necesas en multaj retoj.

Kiam la enirejo repuŝas la defaŭltan itineron

Unue legu la tabelon. Du defaŭltaj enskriboj kun malsamaj metrikoj signifas, ke la profila ŝanĝo efikis kaj ke la puŝita itinero tamen anstataŭigis ĝin:

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

Forigu la defaŭltan itineron, kiu apartenas al la tunelo, kaj konservu la fizikan. Uzu la interfacan indekson el la tria komando, ne la adaptilan alnomon, ĉar skriptoj, kiuj pasas alnomon, rompiĝas tuj kiam la montra nomo ŝanĝiĝas:

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

La forigo forprenas la oficejon kun si, do reenmetu la korporaciajn prefiksojn tra la tunela enirejo. Tio estas la linio, kiun homoj preterlasas, kaj tio estas la kialo, ke «la VPN ĉesis funkcii» sekvas sukcesan ŝanĝon de dividita tunelo:

route add 10.0.0.0 mask 255.0.0.0 10.8.0.1 metric 5 if 21

Nenio el tio postvivas rekonekton, kio estas honesta konduto, ne cimo: la adaptilo rekonstruiĝas kaj la kliento reaplikas tion, pri kio interkonsentis la profilo kaj la enirejo. Se la defaŭlta itinero reaperas ĉiufoje, la enirejo estas agordita rifuzi dividitan tuneladon kaj daŭre puŝos ĝin, aŭ faligos la sesion. Tio estas la politiko de la reta operatoro, kaj la peto apartenas tien, ne en lokan skripton, kiu kontraŭbatalas ĝin unufoje po konekto.

Rekontrolu DNS, IPv6 kaj la metrikojn post unu rekonekto

Forigi defaŭltan itineron IPv4 pruvas nenion pri la alia familio aŭ pri nomresolvo. Tunelo povas porti IPv6 dum la IPv4-defaŭlto restas loka, kaj puŝita resolvila listo povas teni internajn nomojn funkciantaj dum la demandoj, kiuj uzas ĝin, iras alian vojon. Kontrolu ĉiujn tri antaŭ ol nomi ĝin finita:

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

Se la stato revenas ĉe ĉiu konekto, movu la komandojn en agon po konekto anstataŭ permane redakti la tabelon: planita tasko ekigita de la konekta evento, aŭ la propra agordo de dividita tunelo de la kliento, kie ĝi ekzistas. Tenu la interfacan indekson en variablo kaj serĉu ĝin dum plenumo, ĉar ĝi povas ŝanĝiĝi kiam adaptiloj aldoniĝas aŭ foriĝas.

Decidu, kion vi rezignis

Loka interreta trafiko ne plu estas inspektata aŭ filtrita de la oficejo, kaj ĉio publikigita nur tra la tunelo nun bezonas sian propran itineron. Iuj organizoj rigardas dividitan tuneladon kiel politikan malobservon, do konfirmu tion antaŭ ol ŝanĝi administritan aparaton; puŝita defaŭlto foje estas la deviga mekanismo, ne akcidento. La dokumentaro de Set-VpnConnection listigas la parametron de dividita tunelado kaj la profilajn tipojn, al kiuj ĝi aplikiĝas.

Poste kontrolu laŭ fiksa ordo: kiu posedas la defaŭltan itineron, ordinara retumado, unu korporacia gastiganto laŭ adreso, unu interna nomo, kaj la samaj kvar post unu sola rekonekto. Se retumado funkcias kaj la korporacia gastiganto malsukcesas, mankas la prefiksa itinero, ne la defaŭlto, kiun vi forigis, kaj tio multe pli malmultekostas ripari ol rekonstrui la profilon.