Միացրի VPN հաճախորդը Windows 11 նոթբուքում, սալիկը դարձավ 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 1

Find-NetRoute-ը օգտակար կեսն է։ Այն պատասխանում է հարցին, որին հաճախորդը երբեք չի պատասխանում՝ այս նպատակակետի համար ո՞ր ինտերֆեյսը և ո՞ր աղբյուր հասցեն կօգտագործի Windows-ը իրականում։ Գործարկեք այն ներքին հոսթի, հանրային հոսթի և այն ամենի համար, ինչ դուք համարում եք դիտավորյալ բացառություն։ Ամբողջական թունելի պրոֆիլը պետք է ցույց տա թունելի ինտերֆեյսը հանրային հասցեի համար։ Split-tunnel պրոֆիլը սովորաբար այնտեղ ցույց է տալիս ֆիզիկական ադապտերը, մինչ ներքին նախածանցները դեռ լուծվում են VPN-ով։

Երկու թակարդ բացատրում են «սխալ ուղղությամբ է երթուղավորում» հաղորդումների մեծ մասը։ Ամենակոնկրետ նախածանցը միշտ հաղթում է, ուստի ֆիզիկական ադապտերի /24-ը հաղթում է VPN-ի լռելյայն երթուղուն, որքան էլ ցածր լինի թունելի մետրիկան։ Մետրիկան միայն հավասարություն է լուծում նույն նախածանցի երթուղիների միջև։ Իսկ IPv4-ը և IPv6-ը որոշվում են առանձին՝ 0.0.0.0/0 ծածկող պրոֆիլը կարող է IPv6-ը թողնել տեղական կապի վրա, ինչը երկկույտ կայքը կիսաթունելավորված է ցույց տալիս։ Ստուգեք Get-NetRoute -AddressFamily IPv6-ը նախքան եզրակացնելը, որ թունելը կարգին է։

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

Ստուգեք անունների լուծումը առանձին՝ NRPT-ով

Ներքին անունները, որոնք ձախողվում են, մինչ ներքին IP հասցեները աշխատում են, ցույց են տալիս լուծիչի քաղաքականությանը, ոչ թե երթուղավորմանը։ 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 թունելավորում-ը այն հղումն է, որը բաց եմ պահում ելքը կարդալիս։

Առնչվող հոդվածներ