Android VPN երթուղավորում. քաղաքականության կանոնները main աղյուսակից առաջ
Android-ը երթուղային աղյուսակն ընտրում է uid-ի և նշումների կանոններով ցանկացած նպատակակետի որոնումից առաջ, ուստի main-ին ավելացված երթուղին կարող է ընդհանրապես չօգտագործվել:
Android-ում main աղյուսակին ավելացված երթուղին ցանկացած ցանկում ճիշտ է երևում և այնուամենայնիվ չի կրում թրաֆիկը: Պատճառն այն է, որ main աղյուսակը մի քանի տարբերակներից մեկն է, և առաջին հերթին դրան չեն դիմում: Android-ի ցանցային ծառայությունը կառուցում է քաղաքականության կանոններ, որոնք երթուղային աղյուսակն ընտրում են տվյալով, որը նպատակակետ հասցեն չի պարունակում — հավելվածի uid-ը, փաթեթի վրա դրված նշումը, այն ինտերֆեյսը, որով այն ժամանել է — և նպատակակետի որոնումը տեղի է ունենում դրանից հետո, այն աղյուսակի ներսում, որը ընտրել են այդ կանոնները:
Երեք որոշում հաստատուն հերթականությամբ
Ելքային փաթեթը կայացնում է երեք առանձին որոշում: Առաջինը՝ քաղաքականության կանոնը որոշում է, թե որ երթուղային աղյուսակն է գործում: Երկրորդը՝ այդ աղյուսակի ներսում եղած երթուղին որոշում է հաջորդ ցատկը և ելքային ինտերֆեյսը: Երրորդը՝ netfilter կեռիկները որոշում են՝ փաթեթը գոյատևում է, ձևափոխվում, թե վերաուղղորդվում:
Հերթականությունը կարևոր է, որովհետև յուրաքանչյուր փուլ կարող է պատասխանել միայն իր հարցին: Փաթեթն ընդունող firewall-ի կանոնը աղյուսակ չի ընտրում, և այն աղյուսակին ավելացված երթուղին, որը ոչ մի կանոն չի ընտրում, անգործուն է: Android VPN-ների շուրջ շփոթության մեծ մասը գալիս է նրանից, որ ուղղում են երեքից մեկը և փոփոխություն չեն տեսնում, որովհետև խափանումը մյուսում էր:
| Stage | Selector | What it cannot decide |
|---|---|---|
| Policy rule | uid range, mark, incoming interface | Which route exists inside the table |
| Route lookup | Destination prefix, longest match | Whether the packet is allowed out |
| Netfilter hook | Chain position, match conditions | Which table was selected |
Նշումները փաթեթավորված դաշտ են, ոչ թե ձեր սեփական պիտակը
Android-ը մի քանի փաստ փաթեթավորում է նույն նշման արժեքի մեջ՝ որ ցանցն է ընտրվել, արդյոք հավելվածը բացահայտ ընտրել է ցանց, արդյոք socket-ը պաշտպանված է VPN-ից, և թույլտվությունների հետ կապված բիթերը: AOSP-ի fwmark վերնագիրը սահմանում է այդ դասավորությունը ընթացիկ ծառի համար, և դասավորությունը հարթակի ներքին մանրամասն է, որը փոխվում է թողարկումների միջև:
Այդ պատճառով Android-ում վտանգավոր է ամբողջ նշման արժեքը գրելը iptables -j MARK --set-mark -ով: Այն պիտակ չի ավելացնում. այն փոխարինում է ցանցի այն ընտրությունը, որն արդեն կատարել է համակարգը: Այնուհետև փաթեթը համապատասխանում է այլ կանոնների, ինչը կարող է թվալ, թե VPN-ը սկսել է աշխատել, կամ թե անկապ հավելվածը կորցրել է կապը՝ կախված նրանից, թե որ բիթերն են վերագրվել:
Եթե պետք է դիպչել նշումներին, նախ կարդացեք ընթացիկ արժեքը և օգտագործեք դիմակ, որպեսզի փոխվեն միայն ձեր հասկացած բիթերը:
ip rule show
ip route show table all | head -40
ip route get 10.20.4.11Կապի նշումը առանձին օբյեկտ է փաթեթի նշումից, և ոչ մեկը երթուղի չէ: Պատասխան փաթեթների վրա նշումը վերականգնելը առանձին քայլ է ելքի պահին աղյուսակ ընտրելուց, այդ պատճառով միակողմանի ուղղումները ստեղծում են կապեր, որոնք բացվում են և հետո կախվում:
Ում են պատկանում կանոններն ու աղյուսակները
Android-ի ցանցային ծառայությունը՝ netd-ն, ստեղծում է կանոնները և ցանցային աղյուսակները: AOSP RouteController այն տեղն է, որտեղ այդ կանոնները հավաքվում են VPN-ների, ֆիզիկական ցանցերի և uid միջակայքերի համար, և նրա կյանքի ցիկլը կապված է ցանցային իրադարձությունների, ոչ թե կոնֆիգուրացիայի ֆայլի հետ:
Երկու հետևանք կա: Առաջինը՝ մեկ սարքում գտած առաջնահերթություններն ու աղյուսակների համարները կառուցման ներքին մանրամասներ են, ոչ ինտերֆեյս. նույն տեսք ունեցող համարները Android-ի այլ տարբերակում կարող են բոլորովին այլ բան նշանակել: Երկրորդը՝ ցանցերի փոփոխության ժամանակ վիճակը նորից կառուցվում է, ուստի այսօր root shell-ից ավելացված կանոնը կարող է անհետանալ հաջորդ Wi-Fi անցումից հետո:
Այդ անհետացումը հաճախ ներկայացվում է որպես համակարգի կողմից երթուղու անտեսում: Իրականում տեղի է ունեցել այն, որ աղյուսակն ընտրող կանոնն այլևս գոյություն չունի, և աղյուսակի ներսում եղած երթուղին այժմ անհասանելի է փաթեթի տեսանկյունից: Երբ աշխատող կոնֆիգուրացիան դադարում է աշխատել վերամիացումից հետո, ստուգեք կանոնների ցանկը, ոչ թե երթուղիների ցանկը:
Կեռիկների հերթականության հարցերը համընդհանուր պատասխան չունեն
«Արդյոք iptables-ը աշխատում է VPN երթուղավորումից առաջ» հարցին հնարավոր չէ պատասխանել առանց փաթեթի ուղին նշելու: Տեղականորեն ստեղծված փաթեթն անցնում է output կեռիկով, որտեղ նշման փոփոխությունը հարուցում է վերաերթուղավորման ստուգում՝ երկրորդ որոնում, ոչ թե առաջինի հետադարձ խմբագրում: tether-ով միացած հաճախորդից եկող փաթեթն անցնում է prerouting ուղիով և փոխարենը փոխանցվում է, և այն տեսնող շղթաները այլ են:
Այսպիսով՝ նույն կանոնը կարող է արդյունավետ լինել հավելվածի թրաֆիկի համար և անտեսանելի tether թրաֆիկի համար, և զրոյի վրա մնացող հաշվիչը ձեզ ասում է, թե փաթեթն որ ուղին է գնացել, ոչ թե՝ կանոնը սխալ է: Օգտագործեք հաշվիչներ՝ ուղին հաստատելու համար, նախքան որևէ համապատասխանության պայման փոխելը:
Սա նաև այն փուլն է, որտեղ քաղաքականության երթուղավորման սխալը դժվար տեսանելի է դառնում: Գոյություն ունեցող, բայց նպատակակետը չպարունակող աղյուսակ երթուղավորելը տալիս է «ցանցն անհասանելի է», որը նման է firewall-ի կողմից մերժմանը, մինչդեռ firewall-ի մերժումը տալիս է ժամանակի սպառում, որը նման է երթուղավորման սև խոռոչի:
Ախտորոշեք համակարգի ներսում, կամ ձեռք չտաք դրան
Լիազորված վերանայման համար նախքան որևէ բանի դիպչելը հաստատեք չորս փաստ՝ հավելվածի uid-ը և պրոֆիլը, այն ցանցը, որը Android-ն ընտրել է դրա համար, արդյոք VPN-ը ընդհանրապես ներառում է այդ հավելվածը, և արդյոք խնդիրը գոյություն ունի հասցեների երկու ընտանիքներում էլ: Հավելվածով բացառումը բացատրում է «VPN-ը չի աշխատում» հաշվետվությունների մեծ մասը՝ առանց որևէ երթուղավորման խափանման:
Ապա կարդացեք փաստացի գործող կանոնները, դիմակները և աղյուսակները, և ցանցի փոխարկումը պահեք դիտարկման պատուհանի ներսում: Եթե վարքը փոխվում է վերամիացման ընթացքում, դուք նայում եք կառավարվող կյանքի ցիկլին, ոչ թե բացակայող երթուղուն:
Սովորական պահանջների համար օգտագործեք աջակցվող կառավարման միջոցները՝ հավելվածով ներառում և բացառում VPN հավելվածում, և հարթակի սեփական ցանցի ընտրությունը այն ամենի համար, ինչին պետք է որոշակի ուղի: Եթե արտոնյալ ինտեգրումն իսկապես պետք է համագործակցի երթուղավորման մեքենայի հետ, թիրախավորեք ձեր աջակցած Android-ի ճշգրիտ տարբերակի իրականացումը և պահպանեք նրա կյանքի ցիկլը այն բաղադրիչի միջոցով, որին այն պատկանում է: Հարթակի շղթաները մաքրելը կամ բարձր առաջնահերթության կանոն ներդնելը ախտորոշումը վերածում է երկրորդ ցանցային կառավարչի, և հեռախոսը կվարվի համապատասխանաբար: