Firewall-ի պրոֆիլները ընդդեմ VPN ելքի. ինչու հանրայինը ուղի չէ
Firewall-ի պրոֆիլը ընտրում է, թե որ կանոնախումբն է գործում։ Այն ոչինչ չի ասում այն մասին, թե որ ինտերֆեյսն է տարել փաթեթը, և բացահայտ արգելափակումը գերազանցում է ավելի նեղ թույլտվությանը։
Կանոնը հնչում է ճշգրիտ. թույլատրել տեղական երթևեկությունը մասնավոր պրոֆիլում և միայն VPN երթևեկությունը հանրայինում։ Բայց այդպես չէ, որովհետև ցանցային պրոֆիլը ընտրում է, թե որ firewall կանոնախումբն է գործում, և ոչինչ չի ասում այն մասին, թե որ ադապտերն է տարել փաթեթը։ Պրոֆիլի անվանը վերաբերվել որպես ուղու պահանջի՝ այն սխալն է, որի պատճառով սահմանափակ ելքով նախագիծը երևում է ավարտված, երբ այդպիսին չէ։
Նախ գրի առեք հոսքերը, ապա որոշեք, թե որ մեխանիզմը կարող է իսկապես պարտադրել դրանցից յուրաքանչյուրը։ Այդ հոսքերի ցանկը միակ արտեֆակտն է, որը վերապրում է հաջորդ կանոնափոխությունը։
Կատեգորիան ընտրում է կանոններ, ոչ ուղիներ
Երբ Windows-ը ցանցը դասակարգում է որպես հանրային կամ մասնավոր, firewall-ը կիրառում է այդ պրոֆիլի համար կազմաձևված կանոնախումբը։ Դասակարգումը հետևում է այն ցանցին, որին միացել է ադապտերը, իսկ կանոնախումբը որոշում է, թե ինչ է դրանում թույլատրված։ Այս փաստերից ոչ մեկը կախված չէ նրանից, թե արդյոք հավելվածի երթևեկությունն օգտագործել է թունելը։ Հենց այդ անկախությունն է ամբողջ դժվարությունը։
Ուղու ընտրությունը կատարում է երթուղավորումը՝ ինտերֆեյսի մետրիկայի և այն նախածանցի միջոցով, որը տեղադրում է թունելը։ Ուստի պրոֆիլը կարող է հանրային պիտակավորված լինել, մինչ հավելվածի կապը գնում է ֆիզիկական ուղով, և firewall-ը դեռ կհայտնի, որ կիրառվել է հանրային կանոնախումբը։
Այդ պատճառով պրոֆիլով սահմանափակված կանոնը չի կարող նշանակել միայն թունել։ Երկու հատկությունները որոշում են տարբեր բաղադրիչներ, և մեկը չի կարող փոխարինել մյուսին։
| Flow | What decides it | What a rule can enforce |
|---|---|---|
| VPN client to its endpoint | Routing plus the outer transport | Allow the client process before the tunnel exists |
| Application to an internet host | Interface metric and prefix length | Block the process unless the tunnel interface is up |
| Application to a LAN host | Local subnet route | Allow one destination, not the whole category |
Բացահայտ արգելափակումը գերազանցում է ավելի նեղ թույլտվությանը
Microsoft-ի firewall կանոնների ուղեցույցը տարբերում է լռելյայն արգելափակող գործողության թույլտվություն-բացառությունը բացահայտ արգելափակումից, որը հակասում է թույլտվությանը։ Բացահայտ արգելափակումները հաղթում են այդ հակասությանը, և ելքային կանոնները ենթարկվում են նույն գերակայությանը։
Այսպիսով՝ ամեն ինչ արգելափակող կանոն ավելացնելու և դրա վրա դրված ավելի նեղ թույլտվության վրա հույս դնելու հանրաճանաչ բաղադրատոմսը չի անում այն, ինչ ակնկալում է հեղինակը։ Windows Firewall-ը հակասությունը չի լուծում ադմինիստրատորի նշանակած կանոնների հերթականությամբ։ Արգելափակումը պարզապես գործում է, և միացող հավելվածը հաղորդում է ժամկետի լրանալու մասին։ Բացառության նմանվող կանոնը երբեք խաղի մեջ չի եղել։
Աջակցվող ձևը լռելյայն մերժման քաղաքականությունն է հաստատված թույլտվության կանոններով, որտեղ յուրաքանչյուր թույլտվություն նշում է ծրագիր, ծառայություն կամ նպատակակետ բավական ճշգրիտ՝ վերանայելի լինելու համար։ Այդ նախագիծը դիմանում է աուդիտին, որովհետև յուրաքանչյուր բացառություն տեսանելի է, և դրանցից ոչ մեկը կախված չէ ստեղծման հերթականությունից։
Իրար հակասող երկու կանոնները ավելի վատն են, քան մեկ կանոնը, որովհետև արդյունք վարքագիծը միաժամանակ ճիշտ է և անբացատրելի։
Ելքային քաղաքականությանը տվեք մեկ սեփականատեր
Աջակցվող VPN հաճախորդն արդեն իսկ պահպանում է իր արգելափակման վարքագիծը և իր վերջնակետային բացառությունները։ Չհամակարգված ձեռքով կանոններ ավելացնելը կարող է այդ հաճախորդին թողնել կարգավորման համար անհրաժեշտ թունելից դուրս, կամ բաց թողնել երկրորդ ուղի, որը ոչ ոք չնկատեց։
Որոշեք, թե ով է տիրապետում ելքային քաղաքականությանը, նախքան կանոններ գրելը. հաճախորդի սեփական կազմաձևը, կառավարվող firewall քաղաքականությունը կամ սեփականատիրոջով փաստաթղթավորված տեղական բացառությունների ցանկը։ Ապա համաձայնեցրեք շերտերը՝ փորձերը կուտակելու փոխարեն, մինչև ինչ-որ բան միանա։ Անվանված սեփականատերը նաև այն մարդն է, ում հարցնում եք, երբ երկու շերտեր չեն համաձայնում։
Պահպանեք վերականգնման ուղի նախքան որևէ բան փոխելը։ Իր իսկ կառավարման ուղուց դուրս կողպված հեռավոր մեքենան ավելի վատ արդյունք է, քան այն քաղաքականության ճեղքը, որը փակում էիք։ Վերականգնման կանոնը ավելի հեշտ հիմնավորելի է, երբ նախապես գրված է, և ավելի հեշտ գտնելի, երբ փոփոխությունը սխալ է ընթանում մի ժամի, որը ոչ ոք չի սիրում։
Փորձարկեք չորս արդյունք՝ պիտակը կարդալու փոխարեն
Քաղաքականությունը լավ է այնքանով, որքանով տարբերում է դեպքերը, ուստի պրոֆիլի պիտակը դիտեք որպես մեկնարկային կետ, ոչ որպես արդյունք։ Չորս արդյունք ասում են՝ արդյոք այն աշխատում է. նախատեսված LAN հարցումը հաջողվում է, ծածկված ինտերնետ հարցումը հաջողվում է, արգելված ուղիղ հարցումը ձախողվում է, և թունելի խափանման դեպքը վարվում է ըստ նախագծի, այլ ոչ թե լուռ հետընթաց է անում։ Գրեք չորս արդյունքները կանոնափոխության կողքին։ Չորս անվանված դեպքերով փորձարկման պլանը բավական կարճ է ամեն անգամ գործարկելու համար և բավական կոնկրետ՝ բարձր ձայնով ձախողվելու համար։
Get-NetConnectionProfile | Select-Object Name,NetworkCategory,InterfaceAlias Get-NetFirewallProfile | Select-Object Name,DefaultOutboundAction Get-NetFirewallRule -Direction Outbound -Enabled True | Where-Object Action -eq Block | Select-Object DisplayName,Profile
Առաջին հրամանը ցույց է տալիս, թե ինչպես է դասակարգված յուրաքանչյուր միացված ցանց, ինչը հաճախ այն չէ, ինչ ենթադրել է կանոնը գրող մարդը։ Երկրորդը ցույց է տալիս լռելյայն գործողությունը յուրաքանչյուր պրոֆիլի համար, իսկ երրորդը թվարկում է միացված ելքային արգելափակումները, ներառյալ նրանք, որոնք լուռ կչեղարկեն ավելի նեղ թույլտվությունը։
Ցանցի փոփոխությունից հետո նորից անցեք չորս դեպքերը, որովհետև պրոֆիլը կարող է վերադասակարգվել, երբ մեքենան միանում է այլ ցանցի։ Համապատասխան պրոֆիլային պիտակը ապացույց չէ, որ ուղին այն էր, ինչ նախատեսում էիք։