Անջատիչը շարունակում է արգելափակել թրաֆիկը VPN-ի անջատումից հետո

Թունելը գնացել է, ցանցի պատկերակը սովորական է թվում, և ոչինչ չի բեռնվում։ Դուք անջատել եք VPN-ը, կամ ջնջել եք այն, կամ վերագործարկել եք սարքը, և այն արգելափակումը, որը պետք է պաշտպաներ ձեզ ընդհատման ժամանակ, դեռ կանգնած է։ Կլիենտի պատուհանը չի կարող դա բացատրել, որովհետև ձեզ արգելափակողը կլիենտը չէ․ որոշումը գրվել է միջուկում ձեր անունով, և ոչինչ չի մնացել այն հեռացնելու համար։ Windows-ում այդ վիճակը գտնվում է Windows Filtering Platform-ում․ Linux-ում դա iptables-ի կամ nftables-ի կանոնների հավաքածու է, հաճախ պատկերով, որը վերարտադրվում է բեռնման ժամանակ։ Հետևյալը իմ օգտագործած կարգն է․ կարդացեք վիճակը, ջնջեք ամենանեղ օբյեկտը, որը բացատրում է խափանումը, և հետո գտեք այն ամենը, ինչ անընդհատ վերադարձնում է այն։

Անջատիչը միջուկի վիճակ է, ոչ կարգավորում

Սեղանային կլիենտները արգելափակումն իրականացնում են զտիչներ ավելացնելով, որոնք մերժում են թրաֆիկը թունելից դուրս։ Windows-ում դրանք WFP զտիչներ են կապի վերահասցեավորման և տրանսպորտի շերտերում, և դրանցից մի քանիսը մշտական են․ դրանք գրանցվում են Base Filtering Engine-ի քաղաքականության պահոցում և վերականգնվում մեքենայի բեռնման ժամանակ, նախքան որևէ VPN ծրագրաշար կաշխատի։ Կլիենտները տարբերվում են նրանով, թե երբ են մաքրում։ Ոմանք զտիչները հեռացնում են անջատման ժամանակ, ոմանք միայն մաքուր ելքի ժամանակ, իսկ ոմանք միայն այն դեպքում, երբ նախ անջատվում է անջատիչը։ Ջնջեք, քանի դեռ արգելափակումը գործում է, կամ սպանեք գործընթացը, և զտիչները մնում են։

Linux-ում համարժեքը ելքային ուղու drop կամ reject կանոնն է, երբեմն փոխանցման կանոն, երբեմն փոփոխված շղթայի քաղաքականություն։ Այդ կանոնները ապրում են դրանք ավելացրած գործընթացից ավելի երկար, որովհետև միջուկի վիճակ են․ սպանեք կլիենտին, վթարի ենթարկեք այն կամ անջատեք հոսանքը, և միջուկը շարունակում է գցել փաթեթները, և ոչինչ չի մնում այն հետարկելու համար։ Կայունության փաթեթը ավելացնում է մշտականության երկրորդ շերտ՝ վերցնելով ընթացիկ կանոնների հավաքածուի պատկերը և վերականգնելով այն բեռնման ժամանակ, այնպես որ հաջորդ սկիզբը սկսվում է արդեն տեղադրված արգելափակմամբ։

Կարդացեք WFP վիճակը նախքան որևէ բան ջնջելը

Windows-ը տալիս է անհրաժեշտ գործիքները։ Գործարկեք բարձրացված հրամանի տող և արտածեք հարթակի վիճակը․ արտածումը հայտնվում է որպես wfpstate.xml աշխատանքային պանակում։

netsh wfp show state
netsh wfp show filters
Get-Service bfe

XML-ում փնտրեք հեռացած մատակարարի անունը, Block գործողությունը և շերտը։ Կապի վերահասցեավորման և տրանսպորտի զտիչներն են, որ կոտրում են սովորական թրաֆիկը․ ընդունման շերտի զտիչը սովորաբար ձեր պատճառը չէ։ Եթե Base Filtering Engine-ն ընդհանրապես չի աշխատում, փնտրեք այլ տեղ, որովհետև ոչինչ այլ չի կարող կիրառել այդ զտիչները։

Ստուգեք նաև հրակայուն պատի սովորական տեսքը, որովհետև մարդկանց մեծ մասը դիտում է երկուսից միայն մեկը՝

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Երբ ներկառուցված պրոֆիլները միացված են և ոչ մի կանոն չի համապատասխանում խափանվող թրաֆիկին, արգելափակումը գալիս է երրորդ կողմի մատակարարից, ոչ թե Windows-ի հրակայուն պատից։ Այդ տարբերությունն է որոշում, թե վերանորոգման համար որ գործիքը կօգտագործեք։

Կարդացեք Linux-ի կանոնները այն շարահյուսությամբ, որով կջնջեք

iptables -S տպում է կանոնները նույն ձևով, որով դրանք ավելացվում են, ինչը ելքը դարձնում է ուղղակիորեն կրկին օգտագործելի ջնջման համար։ iptables -L -v -n ավելացնում է փաթեթների հաշվիչներ, և այդ հաշվիչները ասում են՝ արդյոք կանոնն իսկապես համապատասխանում է ձեր ձախողված հարցումներին, թե պարզապես նստած է շղթայում։

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

Կարդացեք շղթաների քաղաքականությունները, ոչ միայն կանոնները․ -P OUTPUT DROP արգելափակում է թրաֆիկը նույնիսկ երբ ոչ մի կանոն չի համապատասխանում։ Ստուգեք IPv6-ը առանձին, որովհետև երկու ընտանիքներն էլ տեղադրող կլիենտը կարող է IPv6 արգելափակումը թողնել տեղում այն բանից հետո, երբ IPv4 կանոնները գնացել են, և ախտանիշն այդ դեպքում կախված է նրանից, թե որ ընտանիքն է հավանում հավելվածը։ Որտեղ օգտագործվում է nftables, գործարկեք նաև nft list ruleset․ երկու գործիքները գոյակցում են համատեղելիության շերտով, և մեկ ցանկը պարտադիր չէ, որ ցույց տա յուրաքանչյուր կանոն, որը կարող է փաթեթ գցել։

Ջնջեք ամենանեղ օբյեկտը, որը բացատրում է խափանումը

Windows-ում առաջին քայլը դեռ մատակարարի սեփական հեռացման ուղին է․ նորից գործարկեք տեղադրիչը և օգտագործեք վերանորոգում կամ ջնջում, կամ գործարկեք մաքրող գործիքը, եթե մատակարարը հրապարակում է այն։ Մնացած ծառայություններն ու պլանավորված առաջադրանքները սովորական են, և մուտքի պահին կլիենտը գործարկող առաջադրանքը հաջորդ բեռնման ժամանակ նորից տեղադրում է նրա զտիչները։ Կլիենտի ռեեստրի բանալին կարդալիս ձախողվող ջնջումը սովորաբար նշանակում է, որ ծառայությունը կամ առաջադրանքը դեռ պահում է այն, ոչ թե որ ռեեստրը վնասված է։

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

Մշտական զտիչները վերջին միջոցն են։ Դրանք ապրում են HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter-ի տակ՝ յուրաքանչյուր զտիչի համար մեկ արժեք GUID բանալիով։ Նախ արտահանեք բանալին, գրանցեք հեռացվող GUID-ները, ջնջեք միայն հեռացած կլիենտին պատկանող արժեքները, ապա վերագործարկեք, որպեսզի շարժիչը վերակառուցի իր վիճակը։ Մի՛ ջնջեք ամբողջ բանալին և մի՛ անջատեք Base Filtering Engine-ը․ Windows-ի հրակայուն պատը և Defender-ը կախված են դրանից, և դուք մեկ ընդհատում կփոխանակեիք ավելի վատով։

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

Linux-ում վերցրեք iptables -S-ի տպած տողը և -A-ը փոխարինեք -D-ով։ Ձեր հայտնաբերած մեկ կանոնը ջնջելը լավ է, քան շղթան դատարկելը, որովհետև այն անձեռնմխելի է թողնում ձեր սեփական քաղաքականությունը։

sudo iptables -D OUTPUT -p udp -j REJECT

Եթե drop-ը գտնվում է օգտագործողի կողմից սահմանված շղթայում, նախ ջնջեք դեպի այդ շղթան ցատկը, ապա հեռացրեք շղթան -X-ով։ Շղթայի քաղաքականությունը ACCEPT դնելը, քանի դեռ drop կանոնները դեռ կան, օգնում է միայն այն փաթեթներին, որոնք ընդհանրապես հասնում են քաղաքականության որոշմանը։ Բոլոր աղյուսակները դատարկելը վերջին միջոցն է․ այն հեռացնում է նաև այլ պատճառներով ավելացված կանոնները, և ufw-ը միացված վիճակում ծառայությանը թողնում է հավատալ, որ տիրապետում է շղթաների, որոնք արդեն չկան։

Գտեք տիրոջը, որը վերադարձնում է այն

Անմիջական վերանորոգումից հետո փնտրեք ամեն ինչ, ինչը կարող է վերականգնել վիճակը։ Linux-ում ստուգեք՝ արդյոք միացված է կայունության միավոր, արդյոք կլիենտն ունի մուտքի պահին հրակայուն պատի վերականգնման կարգավորում, և արդյոք /etc-ի տակ պահված կանոնների ֆայլ կա։ Windows-ում կրկին ստուգեք մեկնարկային գրառումները, ծառայությունները և պլանավորված առաջադրանքները, ապա վերագործարկեք և նույն հրամաններով նորից կարդացեք վիճակը։

Եթե արգելափակումը վերադառնում է, ջնջումը լուծումը չէր․ տերն էր։ Գրանցեք, թե որ կլիենտը կամ ծառայությունն է տեղադրում այն, և այնտեղ անջատեք հատկությունը՝ ամեն անջատումից հետո հրակայուն պատի շերտում դրա դեմ պայքարելու փոխարեն։

Ստուգեք իրական թրաֆիկով, ոչ թե մեկ ping-ով

Փորձարկեք անվան որոնում, TCP միացում և նոր բրաուզերի նստաշրջան, ապա վերագործարկեք և կրկնեք նույն երեք ստուգումները։ Ping-ը, որն աշխատում է, մինչ HTTPS-ը ձախողվում է, մատնանշում է տրանսպորտային շերտի զտիչ, ոչ թե ցանցը, իսկ արգելափակումը, որ վերադառնում է միայն վերագործարկումից հետո, մատնանշում է տեր, որին դեռ չեք գտել։

Պահեք ապացույցները․ արտահանված BFE բանալին կամ մինչ փոփոխությունը գրավված iptables -S ելքը։ Նախքան այն շտկված անվանելը, հաստատեք այն շերտը, որից հեռացրել եք օբյեկտը, տիրոջը, որը կարող էր նորից տեղադրել այն, մեկ մաքուր վերագործարկումից հետո եղած վիճակը, և որ սովորական զննարկումն աշխատում է առանց VPN գործընթացի։ iptables(8) ձեռնարկի էջում կա ջնջման և քաղաքականության ճշգրիտ շարահյուսությունը, եթե մաքրումը սկրիպտավորում եք։