Niliunganisha mteja wa VPN kwenye kompyuta ya mkononi ya Windows 11, kigae kilikwenda Connected, ushirikiano wa faili wa ndani ulifunguka, na tovuti ya umma ilikuwa bado inapakia moja kwa moja kutoka Wi-Fi ya ofisi. Mchanganyiko huu unaonekana kama handaki iliyovunjika. Ni matokeo ya kawaida ya wasifu unaotuma trafiki fulani kupitia VPN na kuacha iliyobaki kwenye adapta halisi. Uelekezaji wa kulazimishwa hubadilisha njia gani ya chaguo-msingi Windows inapendelea; haifuti njia maalum zaidi na haitoi ahadi kwamba trafiki itasimama mvutano unapokatika. Yafuatayo ni mpangilio ninaofuata mteja anapodai ufikiaji: hali ya mteja, wasifu uliohifadhiwa, njia zilizotumika, kitatuzi, kisha mtiririko halisi.

Anza kwa mteja, kisha acha kumwamini

Mteja ni mahali sahihi pa kuanzia kwa sababu tu anakuambia wasifu gani unaotumika. Fungua sifa za muunganisho na uandike jina kamili la wasifu, ikiwa uliundwa kwa mtumiaji wa sasa au kwa kila mtu kwenye mashine, na adapta gani inaonekana katika ncpa.cpl baada ya kuunganisha. Kwenye kompyuta yangu ya jaribio adapta ilibeba jina la wasifu, jambo ambalo lilifanya matokeo ya njia kuwa rahisi kusoma. Kwenye mashine nyingine inaonekana kama ingizo la WAN Miniport na jina hakikuambii chochote.

Kile mteja asichoweza kukuambia ni ufikiaji. Kigae kilichounganishwa kinaeleza hali ya handaki, si orodha ya maeneo. Wateja wa wahusika wengine pia huhifadhi usanidi wao wenyewe, kwa hivyo wasifu asilia wa Windows, na kila sifa utakayoisona kutoka kwake, huenda hazina uhusiano wowote na kile mteja huyo alisakinisha. Ikiwa VPN ilikuja kupitia AnyConnect, OpenVPN GUI, WireGuard au wakala wa msambazaji, ukaguzi wa PowerShell hapa chini mara nyingi hautumiki na badala yake unapaswa kusoma mipangilio ya split-tunnel na uelekezaji ya mteja huyo.

Soma wasifu uliohifadhiwa, si kigae

Kwa wasifu asilia wa Windows (IKEv2, L2TP, SSTP au ule unaosukumwa na MDM) uamuzi wa split-tunnel uliohifadhiwa ni sifa moja:

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

Ongeza -AllUserConnection wakati wasifu uliundwa kwa kila mtu kwenye kifaa. Bila hiyo unasoma orodha ya mtumiaji wa sasa, ambayo inaweza kuwa tupu au kuwa na ingizo lingine lenye jina linalofanana. Thamani False katika SplitTunneling inamaanisha wasifu ulihifadhiwa kama handaki kamili: Windows husakinisha njia ya chaguo-msingi kupitia adapta ya VPN. True inamaanisha split tunnel, na ufikiaji hutegemea kabisa njia na kanuni za utatuzi wa majina ambazo wasifu huo husukuma.

Chukulia thamani hiyo kama usanidi, si uchunguzi. Inarekodi kile wasifu uliomba wakati wa kuunganisha. Windows inaweza kuishia na njia zilizotumika tofauti, kwa sababu ya njia maalum zaidi ya kiolesura kingine, mpangilio wa sera au ingizo lililobaki kutoka muunganisho uliopita, kwa hivyo thamani ya Boolean haitatui swali peke yake.

Linganisha thamani iliyohifadhiwa na jedwali la njia lililotumika

Baada ya kuunganisha, orodhesha njia kwenye adapta ya handaki badala ya kusogeza jedwali lote:

$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

Find-NetRoute ni nusu yenye manufaa. Inajibu swali ambalo mteja hajibu kamwe: kwa lengo hili, kiolesura kipi na anwani ipi ya chanzo Windows itatumia kwa kweli? Iendeshe kwa mwenyeji wa ndani, mwenyeji wa umma na kila kitu unachofikiria ni ubaguzi wa kusudi. Wasifu wa handaki kamili unapaswa kuonyesha kiolesura cha handaki kwa anwani ya umma. Wasifu wa split tunnel kwa kawaida huonyesha adapta halisi hapo wakati viambishi vya ndani bado vinatatuliwa kwa VPN.

Mitego miwili inaeleza ripoti nyingi za «inaelekeza upande usiofaa». Kiambishi maalum zaidi hushinda kila wakati, kwa hivyo /24 kwenye adapta halisi hushinda njia ya chaguo-msingi kwenye VPN hata kipimo cha handaki kiwe chini kiasi gani. Kipimo hutatua tu sare kati ya njia za kiambishi kimoja. Na IPv4 na IPv6 huamuliwa kando: wasifu unaofunika 0.0.0.0/0 unaweza kuacha IPv6 kwenye kiungo cha ndani, jambo linalofanya tovuti ya tabaka mbili ionekane nusu-handaki. Kagua Get-NetRoute -AddressFamily IPv6 kabla ya kuhitimisha kwamba handaki ni sawa.

What you seeMost likely causeCheck next
Public traffic leaves the physical adapter while SplitTunneling reads FalseA more specific route on that adapter wins over the tunnel defaultFind-NetRoute for the exact destination, then look for a /24 or host route on the physical interface
Internal name fails, internal IP worksNo NRPT rule for that namespace, or a broader rule matches firstGet-DnsClientNrptPolicy and the namespace order
A dual-stack site opens directly while IPv4 uses the tunnelThe profile covers only the IPv4 default routeThe IPv6 route table on both interfaces
Routes look right but one app still goes directThe app uses its own proxy, or the client keeps a per-app listThe app's proxy settings and the client's application list

Kagua utatuzi wa majina kando kwa NRPT

Majina ya ndani yanayoshindikana wakati anwani za IP za ndani zinafanya kazi yanaelekeza kwenye sera ya kitatuzi, si uelekezaji. Windows huamua DNS kwa kila nafasi ya jina kupitia jedwali la sera ya utatuzi wa majina, ambalo halitegemei jedwali la njia:

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

Kanuni inapolingana na *.corp.example, maulizo ya nafasi hiyo ya jina huenda kwa seva za DNS za handaki hata kama njia ya data kwa seva hizo inabaki kwenye adapta halisi katika hali ya split tunnel. Ndio muundo, na ndiyo sababu jaribio la kivinjari linalofungua tovuti ya umma haliambii chochote kuhusu majina ya ndani. Ikiwa adapta inaorodhesha seva zinazotarajiwa lakini utafutaji bado unaenda mahali pengine, linganisha mpangilio wa kanuni za NRPT na kagua ikiwa nafasi maalum zaidi ya jina inalingana kwanza.

Thibitisha mitiririko, kisha amua ulichoomba kwa kweli

Pitia maeneo kwa mpangilio maalum ili matokeo yalinganishwe kati ya mashine: anwani ya umma, anwani ya ndani, jina la ndani na ubaguzi mmoja wa kusudi kama printa ya ndani au simu ya video. Andika kiolesura na anwani ya chanzo ambazo Find-NetRoute hurudisha kwa kila moja. Baada ya mabadiliko yoyote ya sera, unganisha tena na urudie ukaguzi huo huo wa nne; jedwali la njia baada ya kuunganisha tena ndilo ushahidi pekee kwamba wasifu mpya ulianza kutumika.

Kisha tenganisha uelekezaji na utekelezaji. Uelekezaji wa kulazimishwa hupendelea handaki kwa trafiki iliyofunikwa wakati handaki iko juu. Si kill switch. Ikiwa hitaji ni kwamba hakuna kitu kinachotoka kwenye mashine handaki inapoanguka, hilo linapaswa kutoka kwa muundo wa kuzuia: wasifu wa firewall uliofungwa na hali ya handaki, wasifu wa kila wakati-uwasilishaji wenye vichujio vya trafiki au chaguo la mteja wa msambazaji la kufunga-wakati-wa-kushindwa. Uelekezaji wa kulazimishwa pia unapaswa kuacha anwani ya seva ya VPN yenyewe ifikike nje ya handaki, na kuizuia kwa jina la «kulazimisha kila kitu» ni njia ya kuaminika ya kujifungia nje ya muunganisho unaojaribu kutekeleza.

Kabla ya kubadilisha chochote, pitia orodha hii. Kila kipengele kinachoshindikana hupunguza mahali tatizo halisi lilipo.

  • Jina na wigo wa wasifu vimethibitishwa, -AllUserConnection ikitumika kwa wasifu wa mashine nzima.
  • SplitTunneling imesomwa na kuchukuliwa kama usanidi, si ushahidi wa ufikiaji.
  • Njia za adapta ya handaki zimeorodheshwa kando kwa IPv4 na IPv6.
  • Find-NetRoute imeendeshwa kwa lengo moja la umma, moja la ndani na moja la ubaguzi.
  • Kanuni za NRPT zilikaguliwa kabla ya kulaumu njia kwa kushindikana kwa jina.
  • Hitaji la kuzuia lilisomwa tena: uelekezaji unaopendelewa si sawa na uzuiaji uliotekelezwa.

Uamuzi wa handaki kamili au split ni wa mmiliki wa wasifu, na maelezo ya uelekezaji ya Microsoft yanaeleza tabia ambayo Windows hutekeleza wasifu unapoiweka. Microsoft: uelekezaji wa kulazimishwa na split ni rejea ninayoiweka wazi ninaposoma matokeo.

Makala zinazohusiana