Թեժ կետի հաճախորդների համար թունելի բաժանումը հավելվածով բացառում չէ
Հավելվածը VPN-ից բացառելը փոխում է միայն հեռախոսը։ Միացված նոթբուքին պետք է իր սեփական փոխանցման կանոնը՝ համադրված աղբյուրի, նպատակակետի և NAT-ի վրա։
Երկու պահանջ, որոնք նույնն են հնչում, նույնը չեն՝ «բացառիր այս հավելվածը VPN-ից» և «ուղարկիր այս մեկ նպատակակետը VPN-ից դուրս իմ թեժ կետի նոթբուքի համար»։ Առաջինը փոխում է, թե ինչպես է հեռախոսի սոքեթը ցանց ընտրում։ Երկրորդը պետք է փոխի փոխանցման որոշումը մի փաթեթի համար, որը եկել է այլ սարքից այն բանից հետո, երբ հեռախոսն արդեն ընդունել է այն։ Երկուսը շփոթելը հանգեցնում է նրան, որ թեժ կետի հաճախորդի մոտ մնում է բացառություն, որը միշտ վերաբերել է միայն հեռախոսի սեփական զննարկիչին։
Երկու ենթահամակարգեր են տիրապետում երկու հարցերին
Android-ը հավելվածների ցանցավորումը և թեթերինգը առանձին է պահում։ Հավելվածների սոքեթները կապակցման կույտը վերագրում է ցանցին, և VPN հավելվածը որոշում է, թե իր սեփական սոքեթներից որոնք են մտնում թունել։ Միացված հաճախորդից փոխանցված փաթեթները մշակում է թեթերինգի ենթահամակարգը, որը netd-ից հարցնում է երթուղիներ, քաղաքականության կանոններ և թարգմանություն ներքևի միջերեսում։
Հավելվածով բացառումը գնահատվում է, երբ հավելվածը բացում է սոքեթ։ Փոխանցված փաթեթը երբեք չի հասնում այդ ստուգմանը, որովհետև այն չի ծագել այս սարքի հավելվածի սոքեթից։ Սա է ամբողջ պատճառը, թե ինչու երկու կարգավորումները չեն կարող փոխարինել միմյանց, և դա սխալ չէ դրանցից ոչ մեկում։
Ինչ է իրականում փոխում հավելվածով բացառումը
VpnService-ի կառուցիչը կարող է addDisallowedApplication-ով անվանել թունելից դուրս մնացող փաթեթները, կամ addAllowedApplication-ով անվանել ներսում թույլատրված միակ փաթեթները։ Այդ հավելվածներն այնուհետև սոքեթներ են բացում հիմքում ընկած ցանցում, մինչ VPN-ը շարունակում է տիրել լռելյայն երթուղին մնացած ամեն ինչի համար։
Ծավալը ճշգրիտ է՝ փաթեթի սեփական սոքեթները, այս սարքում, քանի դեռ թունելը բարձրացված է։ Այն ոչինչ չի ասում փոխանցված թրաֆիկի մասին, ոչինչ երկրորդ սարքի մասին և ոչինչ այն փաթեթների մասին, որ համակարգը ուղարկում է թեթերինգի անունից։
Սա նաև նպատակակետի կառավարում չէ։ Զննարկիչը բացառելը բացառում է ամեն հասցե, որին հասնում է այդ զննարկիչը, ներառյալ այն, ինչ ուզում էիք թողնել թունելի ներսում։ Երբ պահանջը հավելվածի փոխարեն նշում է նպատակակետ, ապա հավելվածի ընտրիչը կառուցվածքով արդեն սխալ գործիք է։
Ինչպիսին է փոխանցված փաթեթը հեռախոսի համար
Հաճախորդի փաթեթը հասնում է թեժ կետի միջերես՝ հեռախոսի տրամադրած մասնավոր աղբյուրի հասցեով, ասենք 192.168.43.20, և հանրային նպատակակետով։ Փոխանցելու համար հեռախոսին պետք է երթուղի դեպի վերին կապուղի և թարգմանության կանոն, որպեսզի պատասխանները գտնեն վերադարձի ճանապարհը, որովհետև հաճախորդի մասնավոր հասցեն անիմաստ է բջջային ցանցում։
Android-ը դա արտահայտում է քաղաքականության կանոններով, որոնք ընտրում են երթուղավորման աղյուսակ, և netd-ը վերակառուցում է համապատասխան աղյուսակներն ու կանոնները, երբ ցանցերն ու VPN-ները փոխվում են։ Ֆորումի գրառումից կամ նույն մոդելի ավելի հին թողարկումից պատճենված աղյուսակի համարը, կանոնի առաջնահերթությունը կամ միջերեսի անունը կայուն սեփականություն չեն հաստատում։ Այդ վերակառուցումն է նաև պատճառը, թե ինչու ձեռքով գրված կանոնը կարող է մեկ ժամ աշխատել և դադարել հաջորդ վերամիացումից հետո։
Ինչ քաղաքականություն է իրականում պետք թեժ կետի բացառությանը
Գրեք որոշումը որպես աղբյուր, նպատակակետ և նախատեսված ուղի, նախքան որևէ կանոնի դիպչելը։ Մեկ հաստատված նպատակակետի նվազագույն ձևը այսպիսին է՝
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
Երկու ուղղություններն էլ պետք է ամբողջական լինեն։ Ուղիղ ճյուղին պետք է օգտագործելի երթուղի ընթացիկ բջջային վերին կապուղով, որը պատահաբար հենց հիմա գործում է. VPN ճյուղին պետք է թունելի երթուղին գումարած փոխանցման թույլտվություն։ Ցանկացած աղբյուրի թարգմանություն պետք է համապատասխանի ձեր ընտրած ելքին, որովհետև թունելի միջերեսի վրա կիրառված NAT-ը ցույց է տալիս թունելի հասցեն, ոչ բջջայինը, և այդ դեպքում վերադարձի ուղին չի համընկնում ելքի ուղու հետ։
Պատասխանները պետք է հասնեն նույն ներքևի հաճախորդին հետևվող վիճակի կամ բացահայտ երթուղու միջոցով, և ելքային փաթեթների հաշվիչը դրանից ոչինչ չի ապացուցում։ Պահեք նաև VPN-ի սեփական արտաքին տրանսպորտը բացառության ծավալից դուրս, այլապես թունելի կրիչ փաթեթները ժառանգում են հաճախորդի վեբ հարցման համար գրված քաղաքականությունը։
Գրավված մեկ հասցեն նպատակակետ չէ
Զննարկիչից կարդացված մեկ IPv4 հասցեն ակնթարթային պատկեր է։ Խոշոր ծառայությունները պատասխանում են anycast-ից կամ ծայրային հասցեների պտտվող հավաքածուից, շատերը երկհարթ են, և մուտքի հոսքը կարող է դիպչել նույնականացման և հեռաչափության հոսթերի, որոնք էջը երբեք չի ցուցադրում։ Ձեր պատահաբար տեսած հասցեի շուրջ կառուցված բացառությունը կոտրվում է հաջորդ անգամ, երբ ծառայությունը վերաբաշխում է բեռը։
Օգտագործեք ծառայության սեփականատիրոջ փաստաթղթավորված հասցեները կամ նրա հրապարակած տիրույթը և հաշվի առեք հասցեների երկու ընտանիքները։ Եթե պահանջը հնարավոր չէ արտահայտել որպես կայուն հավաքածու, դա, հավանաբար, ծառայության քաղաքականության հարց է, այլ ոչ թե հեռախոսի երթուղավորման հնարք։
Ստուգեք ներքևի կողմից
Երեք ստուգում, այս հերթականությամբ՝ ընտրված ծառայությունը նոթբուքից, սովորական նպատակակետ, որը պետք է մնա VPN-ի ներսում, և հեռախոսի հավելված, որը պետք է մնա անփոփոխ։ Այնուհետև կրկնեք վերամիացումից և վերին կապուղու փոփոխությունից հետո, որովհետև հենց այդ ժամանակ են վերակառուցվում քաղաքականության աղյուսակները։
Եթե հեռախոսի համօգտագործման իրականացումը չի կարող պահել այդ պայմանագիրը վերամիացման ընթացքում, տեղափոխեք ընտրովի քաղաքականությունը աջակցվող ներքևի երթուղիչ, փոխարենը սարքում root կանոններ կուտակելու։ Երթուղիչը կարող է արտահայտել աղբյուրի և նպատակակետի համապատասխանությունը կայուն սեփականատիրոջ հետ, և թեթերինգի մոդուլի փաստաթղթերը ճիշտ հղումն են այն բանի, ինչ հեռախոսը իրականում անում է։