Always-on VPN, թե՞ kill switch. ո՞րն եք իրականում միացրել

Always-on-ը և kill switch-ը նույն կարգավորումների էկրանում երկու տող հեռավորության վրա են, դրա համար մարդիկ դրանք կարդում են որպես մեկ գործառույթի երկու անուն։ Դրանք այդպիսին չեն։ Always-on-ը վերամիացման քաղաքականություն է. թունելը գործարկել բեռնման պահին, վերադարձնել այն խափանումից կամ ցանցի փոփոխությունից հետո և շարունակել փորձել, քանի դեռ այն ձախողվում է։ Kill switch-ը տրաֆիկի քաղաքականություն է. այն նշում է, թե որ փաթեթները դեռ կարող են լքել մեքենան, երբ թունելն անջատված է։ Կարող եք միացնել առաջինը՝ առանց երկրորդի, և պլատֿորմների մեծ մասում լռելյայն արդյունքը դեռ բաց է թողնում տրաֆիկը այդ ընդմիջման ընթացքում։

Ստուգում 1. արգելափակումն առանձին անջատիչ է՞

Android 10-ից և ավելի նոր տարբերակներում պահված VPN պրոֆիլը բացում է երկու անկախ անջատիչ՝ ատամնանիվի պատկերակի հետևում. Always-on VPN և Block connections without VPN։ Միայն երկրորդն է kill switch-ը։ Միայն always-on-ի դեպքում թունելը իսկապես վերադառնում է անկումից հետո, և հարցումի մեջ գտնվող ցանկացած հավելված կարող է ցանց հասնել Wi-Fi-ի կամ բջջային տվյալների միջոցով, քանի դեռ դա չի եղել։

Կառավարվող սարքերը պահում են նույն բաժանումը քաղաքականության API-ում։ setAlwaysOnVpnPackage()-ը վերցնում է փաթեթի անունը և lockdownEnabled դրոշիչը. ադմինիստրատորը, որը սահմանում է փաթեթը և դրոշիչը թողնում false, կառուցել է մշտական թունել, ոչ թե փակ սարք։ Վահանակի ձևակերպումը հազվադեպ է տեսանելի դարձնում այդ տարբերությունը։

Վիճակը կարդացեք սարքից, ոչ թե վահանակից. adb shell settings get global always_on_vpn_app և adb shell settings get global always_on_vpn_lockdown։ Եթե առաջինը վերադարձնում է null, պլատֿորմի մակարդակում ոչ մի փաթեթ չի պարտադրվում. եթե երկրորդը վերադարձնում է 0, պլատֿորմը ոչինչ չի արգելափակում։ Android VPN-ի ուղեցույցը դրանք նկարագրում է որպես առանձին հնարավորություններ, ոչ որպես մեկ ռեժիմ։

Ստուգում 2. ո՞ր շերտն է տիրում արգելափակմանը

Պիտակները ապրում են հաճախորդում, իսկ արգելափակումները սովորաբար՝ firewall-ում, դրա համար էլ նույն բառը տարբեր իմաստ ունի յուրաքանչյուր պլատֿորմում։ Ներքևի տողերն այն են, որոնք արժե հաստատել նախքան դրանցից որևէ մեկին վստահելը։

Windows-ը ամենապարզ օրինակն է պիտակի, որը չի արգելափակում։ Այնտեղ Always On-ը նկարագրում է թունելի կայունությունը. սարքի թունել՝ մեքենայի նույնականացման համար, օգտվողի թունել՝ մուտք գործած հաշվի համար, կարգավորված պրոֆիլի XML-ով կամ Add-VpnConnection-ով։ Այդ պրոֆիլում ոչինչ չի կանգնեցնում ելքային փաթեթը, երբ թունելը բացակայում է, և ելքային զտումը լռելյայն միացված չէ, ուստի Wi-Fi-ի վրա գտնվող նոութբուքը շարունակում է աշխատել, երբ VPN-ն անջատված է։

WireGuard-ը բաժանվում է նույն ձևով, բայց ըստ հաճախորդի։ WireGuard for Windows-ն ունի Block untunneled traffic տարբերակ յուրաքանչյուր թունելի համար, որը տեղադրում է զտիչ կանոններ. Linux-ի գործիքները նման անջատիչ չունեն։ wg-quick-ը ավելացնում է երթուղի յուրաքանչյուր AllowedIPs գրառման համար և fwmark կանոն, իսկ wg-quick down-ը հեռացնում է երկուսն էլ, ուստի ֆիզիկական լռելյայն երթուղին նորից ստանձնում է աշխատանքը՝ առանց մեկ փաթեթ կորցնելու։

Apple-ի պլատֿորմներում always-on-ը գալիս է որպես կառավարման պրոֆիլի գործառույթ հսկվող սարքերի համար և արտահայտվում է on-demand կանոններով, ոչ թե նշիչով։ Հարցը, որին պետք է պատասխանել բեռնվածքից, այն է՝ ձախողված թունելը արգելում է տրաֆիկը, թե միայն նոր միացում է խնդրում։ Ընտրացանկի վերնագիրը դա չի ասի։

Ստուգում 3. չափեք ընդմիջումը, ոչ թե պատկերակը

Չորս անցում կարևոր է, և դրանք տարբեր կերպ են ձախողվում. բեռնում մինչև որևէ մեկի մուտք գործելը, քունը և արթնացումը, Wi-Fi-ից բջջային տվյալների անցումը և հաճախորդի խափանում, որը թունելի ինտերֆեյսը թողնում է կիսով չափ կարգավորված։ Դրանցից մեկի մաքուր վերամիացումը ոչինչ չի ապացուցում մյուս երեքի մասին։

Ամենաէժան փորձարկումը դիտավորությամբ կանգնեցնում է թունելը և հետո փորձում դուրս գալ։ Երբ թունելն անջատված է, curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com-ի վերադարձրած 200-ը նշանակում է, որ քաղաքականությունը fail-open է. ժամանակի սպառումը կամ մերժված միացումը նշանակում է, որ ինչ-որ բան դեռ արգելափակում է։ ip route get 1.1.1.1-ը նշում է ինտերֿֆեյսը, որը կտաներ փաթեթը, ինչը սովորաբար ավելի տեղեկատվական է, քան սկուտեղի պատկերակը, իսկ systemctl status wg-quick@wg0-ը ցույց է տալիս՝ ինտերֿֆեյսը մաքուր հեռացվել է արդյոք։

Նույն ստուգումը գործարկեք երկրորդ պատուհանում, մինչ ցանցը փոխվում է, ոչ միայն այն հաստատվելուց հետո։ Անկման և կրկնափորձի միջև ընկած միջակայքն է կարևորը, և անվան լուծումը ամենաարագ ձևն է նկատելու, որ տրաֆիկը դուրս է սլացել. եթե տեղական լուծիչը պատասխանում է, երբ թունելն անջատված է, արգելափակումը ամբողջական չէ։

Ստուգում 4. բացառությունները որոշեք նախքան կողպելը

Երկու բացառություն կառուցվածքային են։ Հաճախորդը պետք է հասնի հենց VPN սերվերին, ուստի ամեն ինչ գցող կանոնների հավաքածուն նաև կանխում է վերամիացումը, որը կվերականգնի պաշտպանությունը։ Captive portal-ին նույնպես հնարավոր չէ հասնել թունելով, որը միացված չէ, ուստի հյուրանոցի Wi-Fi-ում կողպված սարքին պետք է փաստաթղթավորված եղանակ՝ պորտալը բացելու համար, ոչ թե իմպրովիզացված։

Նվազագույն ձև. վերջնակետը թույլատրված է, մնացածը՝ գցված.

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

Այդ վերջնակետի տողին վերաբերվեք որպես փոփոխական, ոչ թե հաստատուն։ Մատակարարները փոխում են հասցեները, և հնացած բացառությունը սովորական պատճառն է, թե ինչու աշխատող kill switch-ը դառնում է սարք, որը չի կարող վերամիանալ։ Տեղական տպիչները, NAS-ի համօգտագործումները և մշակման ծառայությունները պատկանում են նույն գրավոր ցանկին, հակառակ դեպքում դրանք բացահայտվում են մեկ առ մեկ՝ աջակցության հարցումներով։

Ստուգում 5. գրանցեք, թե իրականում ինչ եք ապացուցել

Պահեք չորս սյունակներով աղյուսակ և լրացրեք այն փորձարկումներով. վիճակ, սպասվող վարքագիծ, դիտարկված վարքագիծ, ապացույց։ Տողերը ստուգում 3-ի անցումներն են գումարած մեկ դիտավորյալ ձախողում։ Այն տողը, որը չեք կարող լրացնել հրամանի ելքով, այն տողն է, որը չեք փորձարկել, և այն սարքը, որն անցնում է վերամիացման տողով և ձախողվում է բեռնման տողում, բավական հաճախ է հանդիպում, որ արժե լրացուցիչ տասը րոպեն։

Նախքան այն ավարտված համարելը.

• Հաստատեք, որ արգելափակող կարգավորումը առանձին է վերամիացման կարգավորումից, և կարդացեք դրա արժեքը սարքում։
• Իմացեք, թե որ շերտն է կիրառում արգելափակումը՝ հաճախորդի տարբերակ, սարքի քաղաքականություն թե firewall, և որտեղ է այդ շերտը կարգավորվում։
• Պահեք մեկ ստուգող հրաման, որն ապացուցում է արգելափակումը, և գործարկեք այն անցման ընթացքում, ոչ թե հետո։
• Գրեք բացառությունների ցանկը՝ ներառյալ վերջնակետը, և նշեք, թե ով է թարմացնում այն։
• Կառավարվող սարքավորումների վրա պարտադրված քաղաքականությունը թողեք անփոփոխ. արգելափակումը հանելը փոխում է պահանջը՝ թունելը վերանորոգելու փոխարեն։