Windows හි VPN ඇත්ත වශයෙන්ම කුමක් රවුට් කරයිදැයි PowerShell හි පරීක්ෂා කරන ආකාරය
සම්බන්ධිත VPN ටයිලය ආවරණය සනාථ නොකරයි. සුරකින ලද පැතිකඩ ධජය, සක්‍රීය මාර්ග වගුව සහ NRPT නීති මෙම අනුපිළිවෙලින් කියවන්න.
මම Windows 11 ලැප්ටොප් එකේ VPN සේවාදායකය සම්බන්ධ කළා, ටයිලය Connected වුණා, අභ්‍යන්තර ගොනු බෙදාගැනීමක් විවෘත වුණා, සහ පොදු අඩවියක් තවමත් කාර්යාල Wi-Fi එකෙන් කෙලින්ම පූරණය වුණා. මේ මිශ්‍රණය කැඩුණු උමං මාර්ගයක් වගේ පෙනෙනවා. ඒත් මෙය ට්‍රැෆික් කොටසක් VPN හරහා යවා ඉතිරිය භෞතික අඩප්ටරයේ තබන පැතිකඩක සාමාන්‍ය ප්‍රතිදානයයි. බලහත්කාර උමංකරණය Windows කුමන පෙරනිමි මාර්ගයට මුල්‍තැන දෙයිද යන්න වෙනස් කරයි; එය වඩාත් නිශ්චිත මාර්ග මකන්නේ නැති අතර සම්බන්ධතාවය බිඳවැටුණු විට ට්‍රැෆික් නවතින බවට පොරොන්දුවක් ද නොදේ. පහත දැක්වෙන්නේ සේවාදායකයෙකු ආවරණය යැයි පවසන විට මම අනුගමනය කරන අනුපිළිවෙලයි: සේවාදායක තත්ත්වය, සුරකින ලද පැතිකඩ, යෙදූ මාර්ග, විසඳන්නා, පසුව සැබෑ ප්‍රවාහ.
සේවාදායකයෙන් පටන් ගෙන, පසුව එය විශ්වාස කිරීම නවත්වන්න
සේවාදායකය ආරම්භ කිරීමට නිවැරදි තැන වන්නේ එය කුමන පැතිකඩ සක්‍රීයදැයි කියන නිසා පමණි. සම්බන්ධතාවයේ ගුණාංග විවෘත කර නිශ්චිත පැතිකඩ නාමය, එය වර්තමාන පරිශීලකයා සඳහාද යන්ත්‍රයේ සියලු දෙනා සඳහාද යන්න, සහ සම්බන්ධ වූ පසු ncpa.cpl තුළ කුමන අඩප්ටරය දිස්වේද යන්න සටහන් කරන්න. මගේ පරීක්ෂණ ලැප්ටොප් එකේ අඩප්ටරය පැතිකඩ නාමය දැරුවා, එය මාර්ග ප්‍රතිදානය කියවීම පහසු කළා. වෙනත් යන්ත්‍රවල එය WAN Miniport සටහනක් ලෙස දිස්වන අතර නාමය ඔබට කිසිවක් නොකියයි.
සේවාදායකයට කියන්නට නොහැකි දෙය ආවරණයයි. සම්බන්ධිත ටයිලයක් උමං මාර්ගයේ තත්ත්වය විස්තර කරයි, ගමනාන්ත ලැයිස්තුවක් නොවේ. තෙවන පාර්ශ්ව සේවාදායකයන්ද තමන්ගේම වින්‍යාසය රඳවා ගනී, එබැවින් මුල් Windows පැතිකඩ සහ එයින් ඔබ කියවන සෑම ගුණාංගයක්ම එම සේවාදායකය ස්ථාපනය කළ දෙයට සම්බන්ධ නොවිය හැක. VPN එක AnyConnect, OpenVPN GUI, WireGuard හෝ විකුණුම්කරුගේ නියෝජිතයෙකු හරහා පැමිණ ඇත්නම්, පහත PowerShell පරීක්ෂණ බොහෝ දුරට අදාළ නොවන අතර ඒ වෙනුවට එම සේවාදායකයේම split-tunnel සහ මාර්ගකරණ සැකසුම් කියවිය යුතුය.
සුරකින ලද පැතිකඩ කියවන්න, ටයිලය නොවේ
මුල් Windows පැතිකඩක් සඳහා (IKEv2, L2TP, SSTP හෝ MDM විසින් තල්ලු කරන ලද) සුරකින ලද split-tunnel තීරණය එකම ගුණාංගයකි:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixපැතිකඩ උපාංගයේ සියලු දෙනා සඳහා සාදා ඇත්නම් -AllUserConnection එක් කරන්න. එය නොමැතිව ඔබ වර්තමාන පරිශීලකයාගේ ලැයිස්තුව කියවයි, එය හිස් විය හැකිය හෝ සමාන නාමයක් සහිත වෙනත් සටහනක් තිබිය හැක. False අගය SplitTunneling තුළ තිබීමෙන් අදහස් වන්නේ පැතිකඩ සම්පූර්ණ උමං මාර්ගයක් ලෙස සුරකින ලද බවයි: Windows VPN අඩප්ටරය හරහා පෙරනිමි මාර්ගයක් ස්ථාපනය කරයි. True යනු split tunnel යන්නයි, එවිට ආවරණය සම්පූර්ණයෙන්ම එම පැතිකඩ තල්ලු කරන මාර්ග සහ නාම විසඳුම් නීති මත රඳා පවතී.
එම අගය වින්‍යාසයක් ලෙස සලකන්න, නිරීක්ෂණයක් ලෙස නොවේ. එය සම්බන්ධ වන විට පැතිකඩ ඉල්ලා සිටි දෙය සටහන් කරයි. Windows වෙනත් අතුරුමුහුණතක වඩාත් නිශ්චිත මාර්ගයක්, ප්‍රතිපත්ති සැකසුමක් හෝ පෙර සම්බන්ධතාවයක ඉතිරි සටහනක් නිසා වෙනස් යෙදූ මාර්ග සමඟ අවසන් විය හැක, එබැවින් බූලීය අගය පමණක් ප්‍රශ්නය විසඳන්නේ නැත.
සුරකින ලද අගය යෙදූ මාර්ග වගුව සමඟ සසඳන්න
සම්බන්ධ වූ පසු මුළු වගුවම ස්ක්‍රෝල් කරනවා වෙනුවට උමං අඩප්ටරයේ මාර්ග ලැයිස්තුගත කරන්න:
$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 1Find-NetRoute ප්‍රයෝජනවත් අර්ධයයි. සේවාදායකය කිසිදා පිළිතුරු නොදෙන ප්‍රශ්නයට එය පිළිතුරු දෙයි: මෙම ගමනාන්තය සඳහා Windows ඇත්ත වශයෙන්ම කුමන අතුරුමුහුණත සහ කුමන මූලාශ්‍ර ලිපිනය භාවිත කරයිද? අභ්‍යන්තර සත්කාරකයක්, පොදු සත්කාරකයක් සහ ඔබ හිතාමතා කළ ව්‍යතිරේකයක් ලෙස සලකන සියල්ල සඳහා එය ධාවනය කරන්න. සම්පූර්ණ උමං පැතිකඩක් පොදු ලිපිනය සඳහා උමං අතුරුමුහුණත පෙන්විය යුතුය. split tunnel පැතිකඩක් සාමාන්‍යයෙන් එහි භෞතික අඩප්ටරය පෙන්වන අතර අභ්‍යන්තර උපසර්ග තවමත් VPN වෙත විසඳේ.
«එය වැරදි දිශාවට රවුට් කරයි» යන වාර්තා බොහොමයක් උගුල් දෙකකින් පැහැදිලි වේ. වඩාත් නිශ්චිත උපසර්ගය සැමවිටම ජය ගනී, එබැවින් භෞතික අඩප්ටරයේ /24 උමං මාර්ගයේ මෙට්‍රිකය කොතරම් අඩු වුවත් VPN හි පෙරනිමි මාර්ගය පරාජය කරයි. මෙට්‍රිකය එකම උපසර්ගය සඳහා මාර්ග අතර සමබරතාව පමණක් තීරණය කරයි. තවද IPv4 සහ IPv6 වෙන් වෙන්ව තීරණය වේ: 0.0.0.0/0 ආවරණය කරන පැතිකඩක් IPv6 දේශීය සබැඳියේ තැබිය හැකි අතර එය ද්වි-ස්ටැක් අඩවියක් අඩක් උමංකරණය වූ ලෙස පෙන්වයි. උමං මාර්ගය හොඳයැයි නිගමනය කිරීමට පෙර Get-NetRoute -AddressFamily IPv6 පරීක්ෂා කරන්න.
| What you see | Most likely cause | Check next |
|---|---|---|
| Public traffic leaves the physical adapter while SplitTunneling reads False | A more specific route on that adapter wins over the tunnel default | Find-NetRoute for the exact destination, then look for a /24 or host route on the physical interface |
| Internal name fails, internal IP works | No NRPT rule for that namespace, or a broader rule matches first | Get-DnsClientNrptPolicy and the namespace order |
| A dual-stack site opens directly while IPv4 uses the tunnel | The profile covers only the IPv4 default route | The IPv6 route table on both interfaces |
| Routes look right but one app still goes direct | The app uses its own proxy, or the client keeps a per-app list | The app's proxy settings and the client's application list |
NRPT සමඟ නාම විසඳුම වෙන් වෙන්ව පරීක්ෂා කරන්න
අභ්‍යන්තර ලිපින ක්‍රියා කරද්දී අභ්‍යන්තර නාම අසාර්ථක වන්නේ නම් එය මාර්ගකරණයට නොව විසඳන්නාගේ ප්‍රතිපත්තියට යොමු වේ. Windows සෑම නාම අවකාශයකටම DNS නාම විසඳුම් ප්‍රතිපත්ති වගුව හරහා තීරණය කරයි, එය මාර්ග වගුවෙන් ස්වාධීනය:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexනියමයක් *.corp.example සමඟ ගැලපෙන විට, එම නාම අවකාශය සඳහා විමසුම් උමං මාර්ගයේ DNS සේවාදායක වෙත යයි, split tunnel ආකාරයේදී එම සේවාදායක දක්වා දත්ත මාර්ගය භෞතික අඩප්ටරයේ රැඳී තිබුණත්. එයයි නිර්මාණය, ඒ නිසාම පොදු අඩවියක් විවෘත කරන බ්‍රවුසර පරීක්ෂණයක් අභ්‍යන්තර නාම ගැන කිසිවක් නොකියයි. අඩප්ටරය අපේක්ෂිත සේවාදායක ලැයිස්තුගත කරන නමුත් සෙවීම් තවමත් වෙනත් තැනකට යන්නේ නම්, NRPT නීති අනුපිළිවෙල සසඳා වඩාත් නිශ්චිත නාම අවකාශයක් පළමුව ගැලපෙන්නේදැයි පරීක්ෂා කරන්න.
ප්‍රවාහ සත්‍යාපනය කරන්න, පසුව ඔබ ඇත්ත වශයෙන්ම ඉල්ලා සිටි දෙය තීරණය කරන්න
ප්‍රතිඵල යන්ත්‍ර අතර සැසඳිය හැකි වන පරිදි ගමනාන්ත නිශ්චිත අනුපිළිවෙලකින් බලන්න: පොදු ලිපිනයක්, අභ්‍යන්තර ලිපිනයක්, අභ්‍යන්තර නාමයක් සහ දේශීය මුද්‍රණ යන්ත්‍රයක් හෝ වීඩියෝ ඇමතුමක් වැනි හිතාමතා කළ ව්‍යතිරේකයක්. එක් එක් අයට Find-NetRoute ලබා දෙන අතුරුමුහුණත සහ මූලාශ්‍ර ලිපිනය සටහන් කරන්න. ඕනෑම ප්‍රතිපත්ති වෙනසකට පසු නැවත සම්බන්ධ වී එම පරීක්ෂණ හතරම නැවත කරන්න; නැවත සම්බන්ධ වූ පසු මාර්ග වගුව පමණක් නව පැතිකඩ බලාත්මක වූ බවට එකම සාක්ෂියයි.
පසුව මාර්ගකරණය බලාත්මක කිරීමෙන් වෙන් කරන්න. බලහත්කාර උමංකරණය උමං මාර්ගය ඉහළ තිබියදී ආවරණය වූ ට්‍රැෆික් සඳහා උමං මාර්ගයට මුල්‍තැන දෙයි. එය kill switch එකක් නොවේ. උමං මාර්ගය වැටෙන විට යන්ත්‍රයෙන් කිසිවක් පිට නොයා යුතු යැයි අවශ්‍යතාවයක් නම්, එය අවහිර කරන නිර්මාණයකින් පැමිණිය යුතුය: උමං තත්ත්වයට බැඳුණු firewall පැතිකඩක්, ට්‍රැෆික් පෙරහන් සහිත සැමවිටම-ක්‍රියාත්මක පැතිකඩක් හෝ විකුණුම්කරුගේ සේවාදායකයේම අසාර්ථක විට වැසෙන විකල්පය. බලහත්කාර උමංකරණය VPN සේවාදායකයේම ලිපිනය උමං මාර්ගයෙන් පිටතට ළඟා විය හැකි ලෙස තැබිය යුතු අතර, «සියල්ල බලකිරීම» නමින් එය අවහිර කිරීම ඔබ බලාත්මක කිරීමට උත්සාහ කරන සම්බන්ධතාවයෙන් ඔබවම අගුළු දැමීමේ විශ්වාසදායක ක්‍රමයකි.
කිසිවක් වෙනස් කිරීමට පෙර මෙම ලැයිස්තුව හරහා යන්න. අසාර්ථක වන සෑම අයිතමයක්ම සැබෑ ගැටලුව කොහේද යන්න පටු කරයි.
- පැතිකඩ නාමය සහ විෂය පථය තහවුරු කර ඇත, යන්ත්‍ර-ව්‍යාප්ත පැතිකඩ සඳහා
-AllUserConnectionභාවිත කර ඇත. SplitTunnelingකියවා ඇති අතර ආවරණයේ සාක්ෂියක් නොව වින්‍යාසයක් ලෙස සලකා ඇත.- උමං අඩප්ටරයේ මාර්ග IPv4 සහ IPv6 සඳහා වෙන් වෙන්ව ලැයිස්තුගත කර ඇත.
- එක් පොදු, එක් අභ්‍යන්තර සහ එක් ව්‍යතිරේක ගමනාන්තයක් සඳහා
Find-NetRouteධාවනය කර ඇත. - නාම අසාර්ථකත්වය සඳහා මාර්ගවලට දොස් පැවරීමට පෙර NRPT නීති පරීක්ෂා කර ඇත.
- අවහිර කිරීමේ අවශ්‍යතාව නැවත කියවා ඇත: මනාප මාර්ගකරණය යනු බලාත්මක කළ අවහිර කිරීමම නොවේ.
සම්පූර්ණ හෝ split උමං තීරණය පැතිකඩ හිමිකරුට අයත් වන අතර, Microsoft හි මාර්ගකරණ සටහන් පැතිකඩක් එය සකසන විට Windows ක්‍රියාත්මක කරන හැසිරීම විස්තර කරයි. Microsoft: බලහත්කාර සහ split උමංකරණය ප්‍රතිදානය කියවන විට මම විවෘතව තබා ගන්නා යොමුවයි.