Արդյո՞ք VPN-ի անջատիչը դիմանում է վերագործարկմանը։ Ինչպես ստուգել

Վերագործարկումը մարդկանց կողմից անջատիչը փորձարկելու ամենատարածված ձևն է, և հենց այդ փորձարկումն է ամենից հաճախ ստում։ Հաճախորդի նշիչը միայն նախապատվություն է, կարևորն այն է, թե արդյոք ինչ-որ բան արգելափակում է պարտադրում ցանցային կույտի բարձրանալու պահի և թունելի իրականում հաստատվելու պահի միջև։ Windows-ում այդ ինչ-որ բանը սովորաբար Windows Filtering Platform-ի զտիչ է, Linux-ում միավորի կողմից բեռնված կանոնների հավաքածու, macOS-ում pf-խարիսխ, Android-ում համակարգի սեփական միշտ-միացված և արգելափակման դրոշները։ Այս կարգավորումները վերագործարկման ընթացքում շատ տարբեր կերպ են վարվում, և միայն հարթակի մակարդակի կարգավորումներն են տեղում մինչև որևէ մեկի մուտք գործելը։

Վերագործարկումը երեք առանձին հարց է դնում

Բաժանեք հարցը։ Առաջին՝ գոյություն ունի՞ քաղաքականությունը սկավառակի վրա այնպիսի ձևով, որը բեռնման պահին ինչ-որ բան կարդում է։ Երկրորդ՝ արդյո՞ք այդ ընթերցիչը գործարկվում է նախքան որևէ երթևեկության դուրս գալը։ Երրորդ՝ արդյո՞ք քաղաքականությունը ծածկում է ձեզ հետաքրքրող երթևեկությունը, այսինքն՝ յուրաքանչյուր գործընթաց, երկու հասցեային ընտանիքները և DNS-ը։ Առաջինին «այո» և երկրորդին «ոչ» պատասխանները ստեղծում են հենց այն խափանումը, որը մարդիկ նկարագրում են որպես վերագործարկումը չդիմացող անջատիչ՝ երթևեկությունը գործարկման պահին մի քանի վայրկյան դուրս է սլանում, և ոչ ոք չի նկատում, մինչև ինչ-որ մեկը չգնա ստուգելու։

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

Գտեք այն օբյեկտը, որը վերականգնում է արգելափակումը

Linux-ում netfilter-ի կանոններն ապրում են միջուկում։ Ոչինչ դրանք հետ չի գրում բեռնման պահին, եթե դուք դա չեք կազմակերպել՝ iptables-save գումարած netfilter-persistent, nftables.service-ը բեռնում է /etc/nftables.conf-ը, կամ systemd-ի միավոր, որը գործարկում է ձեր սեփական սկրիպտը։ Ստուգեք, թե ինչ է միացված, այն բանի փոխարեն, ինչ հիշում եք, թե կարգավորել եք։

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

Բեռնումից մի քանի վայրկյան անց դատարկ կանոնների հավաքածուն վերնագրի հարցի պատասխանն է։ Windows-ում հարցրեք հաճախորդի ծառայությանը, թե ինչպես է այն սկսվում, ապա արտահանեք հարթակի զտիչի վիճակը, մինչ թունելը ներքևում է։

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

Երկրորդ հրամանը wfpstate.xml-ը գրում է ընթացիկ պանակում։ Փնտրեք արգելափակող գործողությամբ զտիչներ, որոնք արդեն գոյություն ունեն նախքան հաճախորդի միանալը։ Base Filtering Engine-ը սկսվում է բեռնման վաղ փուլում և վերականգնում է մշտական դրոշով ավելացված զտիչները, դրա համար էլ որոշ անջատիչներ արգելափակում են երթևեկությունը նախքան որևէ հաճախորդի պատուհանի գոյությունը, իսկ մյուսները՝ ոչ։ macOS-ում sudo pfctl -s info-ը հայտնում է՝ արդյոք pf-ը միացված է, sudo pfctl -s rules-ը ցույց է տալիս, թե ինչ է բեռնված, և VPN հաճախորդները սովորաբար իրենց կանոնները կցում են խարիսխին, այլ ոչ հիմնական հավաքածուին։ Կանոնը, որը նշում է utun3-ը, հաջորդ բեռնումից հետո կարող է ցույց տալ այլ ինտերֆեյսի, որովհետև այդ համարը տրվում է գործարկման ընթացքում։

Հետևեք ցանցի բարձրացման և թունելի բարձրացման միջև եղած բացին

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

systemd հոսթերում կարդացեք հերթականությունը, այլ ոչ թե գուշակեք։ Գործարկեք systemctl cat-ը VPN-ի և հրապատի միավորների վրա և փնտրեք After= կամ Before=՝ network-pre.target-ի և network-online.target-ի նկատմամբ։ Հրապատի միավորը, որը հերթականությամբ գալիս է network-online.target-ից հետո, պարտվում է ինտերֆեյսին, իսկ այն, որը network-pre.target-ն է պահանջում և դասավորված է դրանից առաջ, հաղթում է։ Windows-ում համարժեք հարցերն են ծառայության մեկնարկի տեսակը և դրա կախվածությունները, որովհետև Manual-ի վրա դրված ծառայությունը չի կարող արգելափակել բեռնման պահի գործընթացը։ Եթե ձեր պահանջը ներառում է երթևեկություն մինչև մուտքը, ապա դրան բավարարում է միայն սարքի մակարդակի կարգավորումը. Always On VPN սարքի թունելը նույնականացվում է մեքենայի վկայականով և միանում է նախքան օգտատիրոջ մուտքը, և Microsoft-ը փաստաթղթավորում է սարքի թունելի կոնֆիգուրացիան օգտատիրոջ թունելից առանձին։ Android-ը գնում է մյուս ճանապարհով՝ պարտադրում է միշտ-միացված VPN և արգելափակում է առանց դրա կապերը համակարգից, այլ ոչ հավելվածի գործընթացից։

Գործարկեք փորձարկումը, ապա համեմատեք երկու ժամանակագրություն

Վերագործարկեք մի նպատակակետով, որը ոչինչ չարժե, եթե արտահոսի, և վիճակը գրանցեք բացի ընթացքում, այլ ոչ դրանից հետո։ Ամենամաքուր մեթոդը բեռնման պահի զոնդն է. oneshot միավոր կամ պլանավորված առաջադրանք, որը սկսվում է հարթակի թույլատրած ամենավաղ պահին, գրանցում է լռելյայն երթուղին և հրապատի վիճակը, փորձում է մեկ հարցում կարճ ժամկետով և տող ավելացնում տեղական ֆայլում։ Համեմատեք այդ գրառումը journalctl -b -u-ից կամ համակարգի մատյանի VPN ծառայության մեկնարկի ժամի հետ։

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

Փակեք բացը առանց ձեր վերադարձի ճանապարհը կտրելու

Եթե բեռնման պահին արգելափակումը բացակայում է, պարտադրումը տեղափոխեք մեկ շերտ ներքև՝ երկրորդ հաճախորդային կանոն ավելացնելու փոխարեն։ Պահեք կանոնների հավաքածուն և բեռնեք այն միավորից, որը դասավորված է նախքան ցանցի օգտագործելի դառնալը, և համոզվեք, որ այդ միավորին պետք չեն DNS հարցում կամ ցանցային միացում, որը նա պետք է պաշտպանի։ Ընդգրկույթը նույնքան կարևոր է, որքան ժամանակը. օգտատիրոջ ID-ով կամ cgroup-ով համընկնող կանոնները ցանկացած համակարգային դեմոն թողնում են արգելափակումից դուրս, և միայն IPv4-ը մշակող հավաքածուն IPv6-ն ու DNS-ը թողնում է հասանելի։

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

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