Միայն Windows-ի բրենդմաուերը որպես VPN անջատիչ. դիմանում է
Միջերեսի տիպի կանոնները կարող են արգելափակել ֆիզիկական ադապտերները, սակայն երրորդ կողմի թունելը հաճախ երևում է որպես լարով։ Ստուգեք դասակարգումը, վերջնակետի ուղին, ապա DNS-ը։
Windows-ի բրենդմաուերը միայնությամբ կարո՞ղ է աշխատել որպես վթարային անջատիչ և ստանում եք երկու ինքնավստահ ու անհամատեղելի պատասխան։ Պատասխաններից մեկն ասում է, որ միջերեսի տիպի կանոնը կատարում է ամբողջ աշխատանքը. մյուսը՝ որ այն չի աշխատում առանց սցենարների։ Երկուսն էլ նկարագրում են նույն մեխանիզմի կեսը։ Բրենդմաուերը կարող է արտահայտել արգելափակումը, իսկ թե արդյունքն իսկապես փակ վիճակում ձախողվում է, կախված է երեք բանից. ինչպես է Windows-ը դասակարգում թունելի ադապտերը, պահպանվում է արդյոք վերջնակետի բացառությունը, և արդյոք ծածկված են անվան լուծումը և IPv6-ը։ Սխալվեք դրանցից որևէ մեկում, և մեքենան կա՛մ արտահոսում է, կա՛մ կորցնում է ամբողջ կապը։
Երեք պայման՝ այս հերթականությամբ
Առաջին պայմանը դասակարգումն է, և այն որոշում է՝ արդյոք ցանկալի կանոնը ընդհանրապես արտահայտելի է։ Windows-ի բրենդմաուերի կանոնները կարելի է սահմանափակել ըստ միջերեսի տիպի. լարով, անլար կամ հեռավոր մուտք։ Այն քաղաքականությունը, որը արգելափակում է ելքային երթևեկությունը ֆիզիկական տիպերի վրա և թույլատրում թունելը, աշխատում է միայն այն դեպքում, երբ Windows-ը թունելը ճանաչում է որպես հեռավոր մուտք։
Երկրորդ պայմանը վերջնակետի բացառությունն է։ Ցանկացած թունելից առաջ հաճախորդը պետք է հասնի VPN սերվերին ֆիզիկական ադապտերի միջոցով, ուստի այդ ադապտերի վրա ամբողջական արգելափակումը խոչընդոտում է հենց այն կապին, որը արգելափակումը կդարձներ ավելորդ։ Բացառությունը պետք է նշի սերվերն ու նրա պորտը, և փաթեթը պետք է դուրս գա ֆիզիկական դարպասով, այլ ոչ թե դեռ չբացված թունելի մեջ։
Երրորդը ծածկույթն է։ Կանոնների այն հավաքածուն, որը արգելափակում է IPv4-ը և մոռանում IPv6-ը, կամ թույլատրում է տեղական լուծիչին վերջնակետի որոնումը և դրանով թույլատրում ցանկացած այլ որոնում, բաց վիճակում ձախողվում է հենց այն պատուհանում, որի համար գոյություն ունի վթարային անջատիչը։ Դա նախագծման բաց է, ոչ թե բրենդմաուերի սխալ։ Դա նաև այն բացն է, որը վերապրում է սեղանի վրա արված ամեն փորձարկում։
Դասակարգումը առաջին դարպասն է
Տեսեք, թե ինչ է Windows-ը մտածում ադապտերների մասին, նախքան մեկ կանոն գրելը։ Windows-ի սեփական VPN կապը սովորաբար երևում է որպես հեռավոր մուտք։ Երրորդ կողմի հաճախորդը, որը ստեղծում է իր սեփական վիրտուալ ադապտերը, հաճախ երևում է որպես լարով, ինչը նշանակում է, որ լարով ադապտերներով սահմանափակված արգելափակումը արգելափակում է նաև թունելը։
Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundActionԵրրորդ հրամանը ձեզ ասում է՝ արդյոք լռելյայն ելքային արգելափակումն արդեն ուժի մեջ է, ինչը փոխում է նախագծի ամբողջ ձևը։ Եթե լռելյայնն արդեն արգելափակում է, դուք թույլատրող կանոններ եք գրում, այլ ոչ թե բացառություններ թույլատրող հիմքի համար, և դա շատ ավելի հեշտ դիրքորոշում է մտածելու համար։
Եթե ձեր թունելի ադապտերը հաղորդում է որպես լարով, ապա միայն բրենդմաուերը ճիշտ գործիք չէ փակ ձախողման նախագծի համար, և կանոնների ոչ մի կարգավորում դա չի փոխի։ Սա այն դեպքն է, երբ յուրաքանչյուր ֆորումի թեմայի երկրորդ կարծիքը ճիշտ է։
Վերջնակետի բացառությունը կանոնից բացի ուղի էլ է պահանջում
Ենթադրենք՝ դասակարգումն աշխատում է։ Բացառությունը երկու մասից է, և դրանք ապրում են տարբեր ենթահամակարգերում։ Բրենդմաուերի կանոնը թույլատրում է երթևեկությունը. հոսթի ուղին այն դուրս է հանում ճիշտ միջերեսով, քանի դեռ թունելը ցած է։
New-NetFirewallRule -DisplayName "VPN endpoint allow" -Direction Outbound -Action Allow \
-Protocol TCP -RemoteAddress 203.0.113.9 -RemotePort 443 -InterfaceType Wired,Wireless
New-NetRoute -DestinationPrefix 203.0.113.9/32 -InterfaceIndex 12 -NextHop 192.168.1.1
Get-NetRoute -DestinationPrefix 203.0.113.9/32Առանց ուղու՝ բացառությունն օգնում է միայն այնքան ժամանակ, քանի դեռ լռելյայն ուղին դեռ ցույց է տալիս ֆիզիկական դարպասին։ Հենց հաճախորդը տեղադրում է իր լռելյայն ուղին և հետո մեռնում, թույլատրված փաթեթները տրամաբանական տեղ չունեն գնալու, և կապը հնարավոր չէ վերականգնել։ Այդ ձախողումը կոտրված հաճախորդի տեսք ունի և իրականում բացակայող ուղի է։
Բացառությունը պահեք այնքան նեղ, որքան թույլատրում է հաճախորդը։ Մեկ հասցե և մեկ պորտ վերանայելի է. մատակարարի ամբողջ ցանցը ծածկող միջակայքը՝ ոչ։ Այդ ավելի լայն կանոնը թույլատրում է նաև նույն մատակարարի մոտ տեղակայված մնացած ամեն ինչ, ինչը սովորաբար ավելին է, քան դուք նկատի ունեիք։
DNS-ը և IPv6-ը հենց այնտեղ են, որտեղ այն բաց ձախողվում է
Անվան լուծումը դասական արտահոսքն է։ Եթե վերջնակետը հոսթի անուն է, հաճախորդը պետք է լուծի այն մինչև թունելի գոյությունը, ինչը նշանակում է, որ ֆիզիկական ադապտերին պետք է թույլատրվի հասնել լուծիչին։ Նույն թույլտվությունը դուրս է թողնում ցանկացած այլ որոնում, քանի դեռ թունելը ցած է, և մեկ որոնումը բավական է բացահայտելու, թե ինչ էիք պատրաստվում այցելել։
IPv6-ը երկրորդն է։ IPv4-ի համար գրված կանոնները չեն ծածկում մյուս ընտանիքը, և շատ հաճախորդներ տեղադրում են միայն IPv4 ուղիներ։ Այսպիսով՝ սեփական IPv6 կապով մեքենան կարող է շարունակել խոսել ինտերնետի հետ, մինչ IPv4 կողմը հաստատ արգելափակված է, և վթարային անջատիչը ողջ ընթացքում հաջողություն է հայտնում։
| Gap | What leaks | Control |
|---|---|---|
| Resolver permitted for endpoint lookup | Every name queried while down | Pin the endpoint as an address, or block non-tunnel DNS |
| Rules only for IPv4 | Full IPv6 connectivity | Add the same rules for the other family |
| Application bound to physical interface | Its own traffic | Firewall cannot fix this; change the binding |
Երրորդ տողը արժե հասկանալ, ոչ թե շրջանցել։ Բրենդմաուերը որոշում է փաթեթների մասին, ոչ թե այն մասին, թե որ միջերեսն է հավելվածը խնդրել օգտագործել, և բացահայտ կապվող ծրագիրը կարող է դժվար զսպվող լինել։ Սա փաստարկ է հօգուտ հաճախորդի կողմի անջատիչի, որը աշխատում է հավելվածից ներքև, ոչ թե ավելի շատ կանոնների։
Փորձարկեք հաճախորդը կանգնեցնելով, ոչ թե մալուխը քաշելով
Միակ իմաստալից փորձարկումն այն է, որը նմանակում է այն ձախողմանը, որից պաշտպանվում եք։ Կանգնեցրեք ծառայությունը, սպանեք գործընթացը կամ անջատեք հաճախորդի ստեղծած ադապտերը, ապա փորձեք հասնել ինտերնետին և անվանը.
Stop-Service -Name "YourVpnService" -Force
Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Resolve-DnsName example.com
Test-NetConnection -ComputerName 2606:4700:4700::1111 -Port 443Երեքն էլ պետք է ձախողվեն։ Եթե առաջինը հաջողվի, արգելափակումն ուժի մեջ չէ. եթե երկրորդը հաջողվի այնտեղ, որտեղ առաջինը ձախողվել է, դուք ունեք DNS արտահոսք. եթե երրորդը հաջողվի, IPv6-ը ծածկված չէ։ Յուրաքանչյուր արդյունք մատնանշում է վերևի բացերից ուղիղ մեկին։
Կրկնեք փորձարկումը քնից և արթնանալուց հետո, որովհետև բրենդմաուերի պրոֆիլը կարող է փոխվել, երբ Windows-ը որոշում է, որ ցանցը հանրային է կամ մասնավոր, և պրոֆիլին սահմանափակված կանոնները հետևում են դրան։ Այն նախագիծը, որը դիմանում է սեղանի վրա և ձախողվում գնացքում, մեկ անգամ փորձարկված նախագիծ է։
Եթե դասակարգման դարպասը կամ DNS-ի պահանջը միայն-բրենդմաուեր մոտեցումը դարձնում են անկիրառելի, հաճախորդի կողմի անջատիչը ազնիվ պատասխանն է։ Եթե թունելը փոխարենը ավարտվում է երթուղիչի վրա, քաղաքականությունը պետք է պատկանի երթուղիչին, որովհետև այնտեղ մեկ կանոն ծածկում է նրա հետևում գտնվող յուրաքանչյուր սարք և կախված չէ նրանից, թե Windows-ը ինչպես է անվանում ադապտերը։