Որտեղ պետք է ապրի Android firewall-ի կանոնը, երբ VPN-ը միացված է

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

Սկսեք նախադասությունից, ոչ ապրանքից

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

Գրավոր ձևով օրինակի քաղաքականությունը չորս տող է. աշխատանքային հավելվածը կարող է հասնել աշխատանքային ծառայությանը. այն չի կարող հասնել ուրիշ ոչնչի. այլ հավելվածները մնում են անփոփոխ. առանց թունելի աշխատանքային հավելվածը մերժվում է՝ ուղիղ ուղու վրա ընկնելու փոխարեն։ Յուրաքանչյուր տող ունի տեր, և ոչ բոլորն են նույն տերը։

Քայլ 1. ինչ կարող է կիրառել հենց հեռախոսը

Android-ի firewall-ը առանց root-ի VpnService է, որը թրաֆիկը բռնում է տեղում, նույնիսկ երբ հետևում հեռավոր թունել չկա։ Android-ը թույլատրում է մեկ ակտիվ VPN ծառայություն մեկ օգտատիրոջ պրոֆիլի համար, ուստի երկրորդ firewall հավելվածը չի շղթայվում առաջինի հետևում։ Այն փոխարինում է նրան, և այն ինտերֆեյսը, որը զտում էր առաջին հավելվածը, անհետանում է։

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

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

Քայլ 2. ինչ կարող է կիրառել դարպասը

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

Այն, ինչ նա չի ստանում, հեռախոսի հավելվածի ինքնությունն է՝ կցված յուրաքանչյուր սովորական IP փաթեթին։ Մեկ թունելային հասցե կիսող մի քանի հավելվածներ դարպասի համար մեկ սուբյեկտ են, եթե նախագիծը նրանց առանձին հասցեներ կամ առանձին նույնականացված ինքնություններ չի տալիս։ Ուստի դարպասի վրա օգտատիրոջ համար կանոնը հեռախոսի վրա հավելվածի համար կանոն չէ, ինչպես էլ այն անվանվի կառավարման կոնսոլում։

Քայլ 3. թվարկեք այն, ինչ երբեք չի հասնում

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

Հակառակն էլ է ճիշտ. կապը թույլատրող տեղական կանոնը հասանելիություն չի տալիս դարպասի մասնավոր ցանցի ACL-ի միջով։ Մեկ հարցումը կարող է ենթարկվել երկու սահմաններին, և մեկը բավարարելը ոչինչ չի ասում մյուսի մասին։

Քայլ 4. յուրաքանչյուր կանոն նշանակեք ուղու

Որոշումը դրեք աղյուսակում, նախքան ինչ-որ բան կարգավորելը, որովհետև դատարկ վանդակներն են այն տեղը, որտեղ նախագծերը ձախողվում են։

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

Քայլ 5. պահեք տրանսպորտը կենդանի, ապա ստուգեք

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

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

Եթե այդ քայլերից մեկը հնարավոր չէ կատարել հեռախոսում, պահանջը ճարտարապետության հարց է, ոչ firewall-ի կարգավորում։ Քաղաքականությունը ձեր վերահսկած սարքի և ձեր վերահսկած դարպասի միջև բաժանելը սովորաբար ազնիվ պատասխանն է, և Android VPN կապակցվածության փաստաթղթերը այն տեղն են, որտեղ հաստատում եք, թե պլատֆորմը ինչ կթույլատրի և ինչ չի թույլատրի մեկ ծառայության։