Paano suriin kung ano talaga ang niruruta ng VPN sa Windows sa PowerShell

Kinonekta ko ang kliyente ng VPN sa isang laptop na Windows 11, naging Connected ang tile, bumukas ang isang panloob na file share, at ang isang pampublikong site ay direktang naglo-load pa rin mula sa Wi-Fi ng opisina. Ang pinagsamang ito ay mukhang sirang tunnel. Ngunit ito ang normal na output ng isang profile na nagpapadala ng bahagi ng trapiko sa VPN at iniiwan ang natitira sa pisikal na adapter. Binabago ng sapilitang tunneling kung aling default na ruta ang pinipili ng Windows; hindi nito binubura ang mas tiyak na ruta at hindi ito nangangako na hihinto ang trapiko kapag bumagsak ang koneksyon. Ang sumusunod ay ang pagkakasunod-sunod na sinusunod ko kapag nagsasabing may saklaw ang isang kliyente: estado ng kliyente, naka-save na profile, inilapat na ruta, resolver, at pagkatapos ang tunay na daloy.

Magsimula sa kliyente, pagkatapos ay tigilan ang pagtitiwala dito

Ang kliyente ang tamang simulan dahil lang sinasabi nito kung aling profile ang aktibo. Buksan ang mga katangian ng koneksyon at itala ang eksaktong pangalan ng profile, kung ginawa ito para sa kasalukuyang user o para sa lahat sa makina, at kung aling adapter ang lumilitaw sa ncpa.cpl pagkatapos kumonekta. Sa aking test laptop, dala ng adapter ang pangalan ng profile, kaya madaling basahin ang output ng ruta. Sa ibang makina, lumilitaw ito bilang entry ng WAN Miniport at wala kang makukuhang impormasyon sa pangalan.

Ang hindi masasabi ng kliyente ay ang saklaw. Ang konektadong tile ay naglalarawan ng estado ng tunnel, hindi ng imbentaryo ng mga destinasyon. Ang mga third-party na kliyente ay may sariling configuration, kaya ang native na profile ng Windows, at bawat property na babasahin mo mula rito, ay maaaring walang kinalaman sa ininstall ng kliyenteng iyon. Kung dumating ang VPN sa pamamagitan ng AnyConnect, OpenVPN GUI, WireGuard o agent ng vendor, karamihan sa mga pagsusuri ng PowerShell sa ibaba ay hindi naaangkop at dapat mong basahin ang sariling split-tunnel at routing settings ng kliyenteng iyon.

Basahin ang naka-save na profile, hindi ang tile

Para sa native na profile ng Windows (IKEv2, L2TP, SSTP o isang itinutulak ng MDM), ang naka-save na desisyon sa split-tunnel ay isang property lamang:

Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffix

Idagdag ang -AllUserConnection kapag ginawa ang profile para sa lahat sa device. Kung wala ito, binabasa mo ang listahan ng kasalukuyang user, na maaaring walang laman o may ibang entry na may katulad na pangalan. Ang value na False sa SplitTunneling ay nangangahulugang na-save ang profile bilang buong tunnel: nag-iinstall ang Windows ng default na ruta sa pamamagitan ng VPN adapter. Ang True ay nangangahulugang split tunnel, at ang saklaw ay ganap na nakadepende sa mga ruta at panuntunan sa paglutas ng pangalan na itinutulak ng profile.

Ituring ang value na iyon bilang configuration, hindi bilang obserbasyon. Itinatala nito ang hiningi ng profile noong kumonekta. Maaaring magtapos ang Windows sa iba't ibang inilapat na ruta dahil sa mas tiyak na ruta ng ibang interface, setting ng patakaran o natirang entry mula sa nakaraang koneksyon, kaya hindi nito nagagawang sagutin nang mag-isa ang tanong.

Ihambing ang naka-save na value sa inilapat na talahanayan ng ruta

Pagkatapos kumonekta, ilista ang mga ruta sa tunnel adapter sa halip na i-scroll ang buong talahanayan:

$vpn = Get-NetAdapter | Where-Object InterfaceDescription -match 'VPN|WAN Miniport'
Get-NetRoute -InterfaceIndex $vpn.ifIndex | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.20.4.15 | Select-Object -First 1

Ang Find-NetRoute ang kapaki-pakinabang na kalahati. Sinasagot nito ang tanong na hindi sinasagot ng kliyente: para sa destinasyong ito, aling interface at aling source address ang talagang gagamitin ng Windows? Patakbuhin ito para sa panloob na host, pampublikong host at anumang itinuturing mong sadyang eksepsyon. Ang profile ng buong tunnel ay dapat magpakita ng tunnel interface para sa pampublikong address. Ang split tunnel na profile ay karaniwang nagpapakita ng pisikal na adapter doon habang ang mga panloob na prefix ay niresolba pa rin sa VPN.

Dalawang bitag ang nagpapaliwanag sa karamihan ng ulat na «mali ang direksyon ng ruta». Laging nananalo ang pinakatiyak na prefix, kaya ang /24 sa pisikal na adapter ay tinalo ang default na ruta sa VPN gaano man kababa ang metric ng tunnel. Ang metric ay nagtatakda lamang ng pagkakapantay-pantay sa pagitan ng mga ruta para sa parehong prefix. At ang IPv4 at IPv6 ay hiwalay na pinagpapasyahan: ang profile na sumasaklaw sa 0.0.0.0/0 ay maaaring mag-iwan ng IPv6 sa lokal na link, na nagpapakita ng dual-stack na site na kalahating naka-tunnel. Suriin ang Get-NetRoute -AddressFamily IPv6 bago magpasya na maayos ang tunnel.

Suriin ang paglutas ng pangalan nang hiwalay gamit ang NRPT

Ang mga panloob na pangalan na nabigo habang gumagana ang mga panloob na IP address ay tumuturo sa patakaran ng resolver, hindi sa routing. Pinagpapasyahan ng Windows ang DNS bawat namespace sa pamamagitan ng talahanayan ng patakaran sa paglutas ng pangalan, na independiyente sa talahanayan ng ruta:

Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndex

Kapag tumugma ang isang panuntunan sa *.corp.example, ang mga query para sa namespace na iyon ay pupunta sa mga DNS server ng tunnel kahit na ang landas ng data patungo sa mga server na iyon ay manatili sa pisikal na adapter sa split tunnel mode. Iyon ang disenyo, at iyon ang dahilan kung bakit ang pagsubok ng browser na nagbubukas ng pampublikong site ay walang sinasabi tungkol sa mga panloob na pangalan. Kung inililista ng adapter ang inaasahang server ngunit sa ibang lugar pa rin pumupunta ang paghahanap, ihambing ang pagkakasunod-sunod ng mga patakaran ng NRPT at suriin kung ang mas tiyak na namespace ang unang tumutugma.

I-verify ang mga daloy, pagkatapos ay magpasya kung ano talaga ang hiningi mo

Daanan ang mga destinasyon sa takdang pagkakasunod-sunod upang maihambing ang mga resulta sa iba't ibang makina: pampublikong address, panloob na address, panloob na pangalan at isang sadyang eksepsyon tulad ng lokal na printer o video call. Itala ang interface at source address na ibinabalik ng Find-NetRoute para sa bawat isa. Pagkatapos ng anumang pagbabago sa patakaran, kumonekta muli at ulitin ang parehong apat na pagsusuri; ang talahanayan ng ruta pagkatapos ng muling pagkonekta ang tanging ebidensya na nagkabisa ang bagong profile.

Pagkatapos, paghiwalayin ang routing sa pagpapatupad. Mas pinipili ng sapilitang tunneling ang tunnel para sa sakop na trapiko habang nakaupo ito. Hindi ito kill switch. Kung ang pangangailangan ay walang lumabas sa makina kapag bumagsak ang tunnel, kailangan itong magmula sa isang disenyong humahadlang: profile ng firewall na nakatali sa estado ng tunnel, palaging-naka-on na profile na may mga filter ng trapiko o ang sariling opsyon ng vendor client na magsara kapag nabigo. Kailangan ding iwanan ng sapilitang tunneling na maabot ang sariling address ng VPN server sa labas ng tunnel, at ang pagharang dito sa ngalan ng «sapilitin ang lahat» ay isang mapagkakatiwalaang paraan upang mai-lock ang sarili mo sa labas ng koneksyong sinusubukan mong ipatupad.

Bago baguhin ang anuman, daanan ang listahang ito. Bawat item na nabigo ay nagpapakitid kung saan ang tunay na problema.

• Nakumpirma ang pangalan at saklaw ng profile, gamit ang -AllUserConnection para sa mga profile sa buong makina.
• Binasa ang SplitTunneling at itinuring na configuration, hindi bilang patunay ng saklaw.
• Nakalista nang hiwalay ang mga ruta ng tunnel adapter para sa IPv4 at IPv6.
• Pinatakbo ang Find-NetRoute para sa isang pampublikong, isang panloob at isang eksepsyon na destinasyon.
• Sinuri ang mga patakaran ng NRPT bago sisihin ang mga ruta sa pagkabigo ng pangalan.
• Binasa muli ang pangangailangan sa pagharang: ang ginustong routing ay hindi katulad ng ipinatupad na pagharang.

Ang desisyon sa buong o split tunnel ay pag-aari ng nagmamay-ari ng profile, at inilalarawan ng mga tala ng Microsoft sa routing ang pag-uugali na ipinapatupad ng Windows kapag itinakda ito ng profile. Microsoft: sapilitan at split tunneling ang sangguniang binubuksan ko habang binabasa ang output.