Ինչու VPN վիճակին կապված firewall դարպասը միայն ping-ի կանոն չէ

Պատկերացրեք firewall-ի կանոն, որը միացնում է ICMP echo-ն սերվերի հանրային հասցեի համար ամեն անգամ, երբ անվանված VPN պրոֆիլը միացված է։ Այն կարդացվում է որպես «ping միայն թունելով», և այդ ընթերցումը սխալ է այնպես, որ կարևոր է։ Կանոնը չի սահմանափակում, թե ով կարող է հասնել հոսթին, այլ փոխում է այն, ինչին պատասխանում է հանրային ինտերֆեյսը, քանի դեռ մեկ այլ կապ պատահաբար ակտիվ է։ Սրանք երկու տարբեր քաղաքականություններ են, և դրանցից մեկը հանգիստ լայնացնում է ազդեցությունը։

Այն կանոնը, որը կարծում եք՝ գրել եք

Նախատեսված պահանջը սովորաբար նեղ է՝ մոնիտորինգի համակարգը կամ VPN-ի միակ ադմինիստրատորը պետք է կարողանա հաստատել, որ սերվերը կենդանի է։ Որպես նախադասություն գրված՝ այն հնչում է որպես թունելի հասանելիության վերահսկում։ Որպես firewall-ի օբյեկտ գրված՝ այն դառնում է պայման հանրային պրոֆիլի վրա, քանի որ echo-ի հարցումը հենց այնտեղ է հասնում։

Երբ պայմանը դառնում է կապի վիճակ, այլ ոչ թե աղբյուրի հասցե, թույլատրված ուղարկողների բազմությունը այլևս VPN-ի գործընկերների բազմությունը չէ։ Ցանկացած ոք, ով կարող է հասնել հանրային հասցեին, կարող է echo-ի հարցում ուղարկել, քանի դեռ դարպասը բաց է։ Թունելը չդարձավ ուղին, թունելը դարձավ անջատիչը։

Այս գաղափարը քարոզողները սովորաբար չեն ստում ցանկալի ազդեցության մասին։ Նրանց պետք էր ստուգում, որը պատասխանում է միայն այն ժամանակ, երբ կապը առողջ է, և կապի առողջությունը ամենահեշտն էր դիտել VPN-ի միջոցով։ Սխալն այն է, որ հասանելիության ազդանշանը դիտարկվի որպես մուտքի որոշում, ապա այն ավտոմատացվի։

Ինչ է դարպասը իրականում կառավարում

Այս ձևավորումը միավորում է երկու անկախ բան, և դրանք բաժանելը ուղղման մեծ մասն է։ Առաջինը ծավալն է՝ որ տեղական հասցեն, որ հեռավոր հասցեները, որ արձանագրությունը և որ ICMP տեսակը։ Երկրորդը պայմանն է՝ արդյոք կանոնի օբյեկտը միացված է այս պահին։ Ծավալն այն է, ինչ firewall-ը գնահատում է յուրաքանչյուր փաթեթի համար, պայմանն այն է, ինչ script-ը գրում է քաղաքականության պահոցում, և երկուսը համաձայնեցվում են բոլորովին տարբեր ժամացույցներով։

Եթե պահանջը իսկապես միայն VPN-ի գործընկերներն են, ծավալը պատասխանում է դրան առանց կապի վիճակի որևէ տրամաբանության՝ կապեք կանոնը թունելի ինտերֆեյսին կամ թունելի հասցեների միջակայքին, սահմանափակեք հեռավոր հասցեները հաճախորդների լողավազանով և նշեք echo-ի տեսակը «ICMP»-ի փոխարեն։ Այդ կանոնը ճիշտ է մնում, երբ ոչ մի VPN միացված չէ, և անկապ պրոֆիլը չի կարող բացել այն։

Եթե պահանջը իսկապես հանրային դարպաս է, ասեք դա քաղաքականության տեքստում, որովհետև ընդունման չափանիշները փոխվում են։ Հանրային դարպասը պետք է անվանի ճշգրիտ պրոֆիլը, սահմանի, թե ինչ է նշանակում «միացված», և հայտարարի, որ հանրային ուղարկողները ձևավորմամբ ծավալի մեջ են։ Շփոթմունքի մեծ մասը անհետանում է այն պահին, երբ ինչ-որ մեկը ստիպված է գրել այդ նախադասությունը։

Կառուցեք օբյեկտը մեկ անգամ, ապա միացրեք այն

Նախապես ստեղծեք մեկ կանոն կայուն ինքնությամբ, անջատված, և թողեք կարգավորիչը փոխի միայն դրա միացվածության վիճակը։ Յուրաքանչյուր գործարկման ժամանակ ցուցադրվող անունով կանոններ ստեղծելը այն ուղին է, որով քաղաքականության պահոցը վերջանում է հինգ գրեթե նույնական օբյեկտով և դրանք հեռացնելու վստահելի միջոց չունենալով։

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

Անունը կայուն նույնացուցիչն է, ցուցադրվող անունը՝ փաստաթղթավորում, որը մարդը կարող է խմբագրել։ Համաձայնեցրեք -Name-ով և script-ը կդադարի կրկնօրինակներ ստեղծել։ Նույն հրամանի ձևը ծածկում է IPv6 դեպքը -Protocol ICMPv6 -IcmpType 128-ով, սակայն դա առանձին կանոն է, քանի որ echo-ի տեսակի համարները տարբերվում են երկու ընտանիքների միջև։

Պահեք հասցեների ընտանիքը և ICMP տեսակը բացահայտ նաև երկրորդ պատճառով՝ -Protocol ICMPv4 առանց տեսակի թույլ է տալիս յուրաքանչյուր ICMPv4 հաղորդագրություն, որը պրոֆիլը թույլ է տալիս, ներառյալ նրանք, որոնք երբեք չեք նախատեսել ընդունել։ 8-րդ տեսակը անվանելը նեղացնում է կանոնը մինչև echo-ի հարցում, և դա միակն է, ինչ ուղարկում է հասանելիության ստուգումը։

Որտեղ ավտոմատացումը հակասում է մտադրությանը

Հաճախորդի պրոֆիլը մի քանի րոպեն մեկ հարցնելը չի կարող անմիջական սահման ստեղծել։ Կապի անկումից մինչև հաջորդ հարցումը կանոնը դեռ պատասխանում է հանրային հասցեով, կապի բարձրացումից մինչև հաջորդ հարցումը՝ ոչ։ Այդ ուշացումը խոստովանելը ազնիվ է, իսկ այն պնդելը, թե ձևավորումը պարտադրում է խիստ ինվարիանտ, ազնիվ չէ։

Վիճակի ստուգման մեջ ինքնին ծավալի թակարդ կա։ Get-VpnConnection-ը հաղորդում է մեքենայի վրա կազմաձևված հաճախորդի պրոֆիլների մասին՝ լռելյայն ընթացիկ օգտվողի համար և բոլոր օգտվողների համար -AllUserConnection-ով։ Այն չի հաղորդում այն հեռավոր օգտվողների մասին, ովքեր այս պահին միացած են RRAS սերվերին, դա այլ դիտարկում է այլ հրամանով։ Սխալի վրա կառուցված դարպասը ոչ մի բանի հետ կապված չէ։

Ապա ծածկեք այն վիճակները, որոնք ոչ ոք չի script-ավորում՝ գործարկում արդեն միացված կանոնով նախորդ գործարկումից, կարգավորիչի խափանում բաց դարպասով և ջնջված պրոֆիլ, մինչ դրա կանոնը կենդանի է մնում։ Յուրաքանչյուրին պետք է սահմանված լռելյայն, և հանրային թույլտվության համար անվտանգ լռելյայնը անջատվածն է։ Եթե պահանջը իսկապես չի հանդուրժում հարցման պատուհանը, վիճակին կապված կանոնը սխալ գործիք է, և կիրառումը պատկանում է թունելին, ոչ թե հանրային ինտերֆեյսին։

Վերջապես, փորձարկեք հանրային հարցումը երկու անգամ՝ մեկ անգամ ընտրված կապը միացված, մեկ անգամ՝ անջատված, VPN-ում չգտնվող հոսթից։ Թունելի ներսից հաջող ping-ը ոչինչ չի ապացուցում այս քաղաքականության մասին, և հենց այդ չափումն են բաց թողնում տեղակայումների մեծ մասը։