Kumokonekta ka sa VPN ng opisina at bawat pahina sa browser ay nagsisimulang dumaan sa network na iyon: mabilis ang file server, lahat ng iba ay mabagal, nasala o wala na. Hindi nagkakamali ang client; humingi ang profile ng buong tunnel. Ang switch na pumipigil dito ay isang checkbox sa isang dialog na hindi ipinapakita ng modernong Settings app, at may say muli ang gateway sa bawat koneksyon. Sinusundan ng gabay na ito ang pagkakasunod-sunod na talagang ipinapakita ng interface ng Windows, pagkatapos ay sinasaklaw ang mga pagsusuring nabibigo pa rin kapag mukhang tama ang talahanayan ng ruta.

Magsimula sa mga katangian ng adapter, hindi sa Settings

Inililista ng Settings app ang profile sa ilalim ng Network at Internet, pagkatapos ay VPN, ngunit nagpapakita lamang ng mga pangkalahatang opsyon. Ang desisyon sa default na gateway ay nasa adapter. Buksan ang klasikong listahan ng adapter gamit ang Win+R at ncpa.cpl, i-right-click ang koneksyon ng VPN, piliin ang Properties, piliin ang Internet Protocol bersyon 4, piliin muli ang Properties at pagkatapos ay Advanced. I-uncheck ang Gamitin ang default na gateway sa remote network at kumpirmahin ang paglabas sa lahat ng tatlong dialog.

Kumonekta muli bago mag-test, dahil inilalapat ang checkbox kapag naitatag ang tunnel at pinapanatili ng umiiral na session ang talahanayang binuo nito. Kung nawawala ang adapter habang naka-disconnect ang client, kumonekta nang isang beses at buksan muli ang window. Ang client ng vendor na nag-iinstall ng TAP o Wintun adapter na walang pahina ng katangian ng IPv4 ay wala talagang dialog na ito; para sa kanila, ang parehong desisyon ay opsyon ng split tunnel sa sariling settings ng client, at ang checkbox ng adapter ang maling lugar na hahanapin.

Ang parehong pagbabago mula sa PowerShell

Para sa profile na ginawa sa Windows VPN store, ang setting ay maiskrip, na siyang kailangan mo kung madalas muling buuin ang makina:

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

Ang cmdlet na iyon ay umaabot lamang sa mga profile sa store na iyon. Ang koneksyong idinagdag ng third-party client ay hindi lalabas, at nabibigo ang command sa error sa pangalan na parang typo. Pansinin din ang hindi ginagawa ng switch: pinipigilan nito ang client na mag-install ng default na ruta, ngunit hindi nito inaalis ang mga rutang itinutulak ng gateway sa oras ng koneksyon, kaya kailangan pa rin ang susunod na seksyon sa maraming network.

Kapag itinulak muli ng gateway ang default

Basahin muna ang talahanayan. Ang dalawang default na entry na may magkaibang metric ay nangangahulugang gumana ang pagbabago sa profile at pinalitan pa rin ito ng itinulak na ruta:

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

Alisin ang default na rutang pag-aari ng tunnel at itago ang pisikal. Gamitin ang index ng interface mula sa ikatlong command, hindi ang alias ng adapter, dahil ang mga script na nagpapasa ng alias ay nasisira sa sandaling magbago ang display name:

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

Dinadala ng pag-alis ang opisina, kaya idagdag muli ang mga corporate prefix sa pamamagitan ng gateway ng tunnel. Ito ang linyang nilalaktawan ng mga tao, at ito ang dahilan kung bakit «tumigil sa paggana ang VPN» ay sumusunod sa matagumpay na pagbabago ng split tunnel:

route add 10.0.0.0 mask 255.0.0.0 10.8.0.1 metric 5 if 21

Wala sa mga ito ang nakakaligtas sa muling pagkonekta, na tapat na pag-uugali at hindi bug: muling binubuo ang adapter at muling inilalapat ng client ang napagkasunduan ng profile at gateway. Kung bumabalik ang default tuwing nakakonekta, naka-configure ang gateway na tanggihan ang split tunnel at patuloy itong itutulak, o papatayin ang session. Iyon ay patakaran ng operator ng network, at doon nararapat ang kahilingan, hindi sa lokal na script na nakikipaglaban dito isang beses kada koneksyon.

I-check muli ang DNS, IPv6 at ang mga metric pagkatapos ng isang muling pagkonekta

Ang pag-alis ng default na rutang IPv4 ay walang pinatutunayan tungkol sa kabilang pamilya o sa paglutas ng pangalan. Maaaring magdala ng IPv6 ang tunnel habang nananatiling lokal ang default na IPv4, at ang itinulak na listahan ng resolver ay maaaring magpanatili ng mga panloob na pangalan na gumagana habang ang mga query na gumagamit nito ay dumadaan sa ibang landas. Suriin ang tatlo bago sabihing tapos:

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

Kung bumabalik ang estado sa bawat koneksyon, ilipat ang mga command sa aksyon kada koneksyon sa halip na mano-manong i-edit ang talahanayan: isang naka-iskedyul na gawain na sinisimulan ng kaganapan ng koneksyon, o ang sariling setting ng split tunnel ng client kung mayroon. Itago ang index ng interface sa isang variable at hanapin ito sa oras ng pagtakbo, dahil maaari itong magbago kapag nagdagdag o nagtanggal ng adapter.

Magpasya kung ano ang isinuko mo

Hindi na sinusuri o sinasala ng opisina ang lokal na trapiko sa internet, at ang anumang inilathala lamang sa pamamagitan ng tunnel ay kailangan na ngayon ng sariling ruta. Itinuturing ng ilang organisasyon ang split tunnel na paglabag sa patakaran, kaya kumpirmahin iyon bago baguhin ang pinamamahalaang device; ang itinulak na default ay minsan ang mekanismo ng pagpapatupad at hindi aksidente. Inililista ng dokumentasyon ng Set-VpnConnection ang parameter ng split tunnel at ang mga uri ng profile na saklaw nito.

Pagkatapos ay i-verify sa takdang pagkakasunod-sunod: sino ang may-ari ng default na ruta, ordinaryong pagba-browse, isang corporate host sa pamamagitan ng address, isang panloob na pangalan, at ang parehong apat pagkatapos ng isang muling pagkonekta. Kung gumagana ang pagba-browse at nabibigo ang corporate host, ang nawawala ay ang prefix route at hindi ang default na inalis mo, at mas murang ayusin iyon kaysa muling buuin ang profile.

Kaugnay na mga artikulo