Թույլատրվածների ցանկը Android VpnService-ում. ինչու թույլատրված էջերը դեռ կախվում են

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

Համեմատիչը հազվադեպ է մեղավոր

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

Դատարկ A գրառումը դասական սխալն է։ Զրո պատասխանով NOERROR վերադարձնելը վավեր պատասխան է թվում, ուստի stub լուծիչը ընդունում է այն, զննարկիչը նորից փորձում է, փորձում AAAA, փորձում այլ լուծիչ և շատ ավելի ուշ հանձնվում։ 3 պատասխանի կոդը, այսինքն NXDOMAIN-ը, հարցման բաժնի կրկնությամբ և գործարքի ID-ի պատճենմամբ, անմիջապես ավարտում է զրույցը։ Օգտագործեք այն յուրաքանչյուր անվան համար, որը դիտավորյալ մերժում եք։

IPv6-ը նույնպես արժանի է նույն որոշմանը, այլ ոչ թե լռելյայն արժեքի։ Եթե A-ի համար պատասխանում եք NXDOMAIN-ով և բաց թողնում AAAA-ն, հաճախորդը կարող է արգելափակված անվանը հասնել IPv6-ով, և զտիչը արտահոսում է։ Որոշ իրականացումներ արգելափակված AAAA հարցումներին պատասխանում են loopback հասցեով, որպեսզի կապը անմիջապես ձախողվի՝ այլընտրանքի անցնելու փոխարեն։ Ընտրեք մեկ քաղաքականություն, կիրառեք այն երկու գրառումների տեսակների վրա և գրանցեք երկուսն էլ։

Երթուղին, որը գրավում է ամեն ինչ, տիրում է ամեն ինչին

Միայն DNS-ի վրա հիմնված ձևավորումը երբեք չի ավելացնում addRoute("0.0.0.0", 0), ուստի TUN ինտերֆեյս են մտնում միայն հարցումները, իսկ մնացածը շարունակում է օգտվել հիմնական ցանցից։ Սա անվտանգ ձևն է, և դա նաև բացատրում է, թե ինչու որոշ թույլատրվածների ցանկեր աշխատում են Wi-Fi-ում և ձախողվում բջջային ցանցում։

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

Լուծիչի socket-ը պետք է դուրս գա թունելից

Փոխանցումը այն տեղն է, որտեղ նստում է հաջորդ թակարդը։ Օպերատորի լուծիչները հաճախ ապրում են մասնավոր հասցեում, որին թունելը չի հասնում, ուստի փոխանցված հարցումը ոչ մի տեղ չի գնում, և հավելվածը հաղորդում է ընթերցման ժամանակի սպառման մասին։ Ուղարկեք հաստատված հարցումները լուծիչի, որի հասանելիության մասին գիտեք, և նախ այդ socket-ը տվեք VpnService.protect()-ին։ Չպաշտպանված socket-ը հարցումը հետ է ուղարկում ձեր սեփական թունել, որտեղ այն նորից հասնում է հավելվածին և պտտվում այնքան, մինչև ժամանակի սահմանափակումը գործարկվի։

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

Չափը և ստուգիչ գումարները ձախողվում են առանց հաղորդագրության

Լուռ դեն նետումները գալիս են նաև չափից։ Մեծ պատասխանների հավաքածուով DNS պատասխանը կամ առատ պարամետրերով TCP ձեռքսեղմումը կարող է գերազանցել ուղու MTU-ն, որը երբեք բացահայտ չեք սահմանել. բեկորը անհետանում է վերևում, և հաճախորդը կա՛մ ավելի փոքրով նորից փորձում է, կա՛մ դադարում փորձել։ Ինտերֆեյսի MTU-ն 1280-ի վրա դնելը պահպանողական ընտրություն է, որը դիմանում է բջջային ուղիների մեծ մասին, և բացահայտ լինելը ավելի լավ է, քան ժառանգել լռելյայն արժեք, որը ոչ ոք չի չափել։

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

Ինչ VpnService-ը չի անի ձեզ համար

Երկու սահման արժե իմանալ նախքան դրանց շուրջ ձևավորելը։ Ոչ մի սովորական հավելված չի կարող Wi-Fi-ից դուրս տեղադրել համակարգային proxy կամ PAC ֆայլ, և այդ մասը չի փոխվել։ Հավելված առ հավելված ուղին փոխվել է. API 29-ից առաջ VpnService.Builder ընդհանրապես չէր կարող proxy կրել, իսկ API 29-ից setHttpProxy(ProxyInfo.buildPacProxy(uri))-ը հարթակին տալիս է PAC սկրիպտ՝ VPN ցանցի համար գնահատելու։ Գնահատեք կանոնները ձեր սեփական կոդում, երբ թիրախում եք ավելի հին API-ներ կամ երբ PAC մոդելը չի կարող արտահայտել կանոնը։ UDP-ն նույնպես անվճար չէ. զննարկիչները SOCKS proxy-ով ուղարկում են միայն TCP, և SOCKS5 հաճախորդների մեծ մասը երբեք չի իրականացնում UDP ASSOCIATE, ուստի proxy-ի վրա հիմնված ձևավորումը դեն է նետում կամ արտահոսում UDP, մինչ TCP-ն առողջ է թվում։

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

Ստուգեք այս հերթականությամբ

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

1. Թվարկեք տեղադրված երթուղիները և հաստատեք՝ արդյոք ոչ DNS փաթեթները ընդհանրապես մտնում են TUN ինտերֆեյս։
2. Գրանցեք հարցման անունը, որոշումը և պատասխանի կոդը մեկ արգելափակված և մեկ հաստատված անվան համար։
3. Հաստատեք, որ լուծիչի socket-ը պաշտպանված է, և ընտրված լուծիչը պատասխանում է թունելի ներսից։
4. Հաստատեք ինտերֆեյսի MTU-ն և ձեռքով կառուցված մեկ պատասխանի ստուգիչ գումարը։
5. Կրկնեք նույն էջը Wi-Fi-ում և բջջային ցանցում, որովհետև օպերատորի լուծիչները և ուղու MTU-ն տարբերվում են։

Եթե բոլոր հինգը դիմանում են, իսկ էջը դեռ կախվում է, հաջորդ կասկածյալը հենց փոխանցիչն է. համեմատեք որսված հարցումը որսված պատասխանի հետ և փնտրեք բացակայող բայթերի քանակ կամ կիսափակ socket։ VpnService.Builder-ի տեղեկատուն ընդգրկում է երթուղու, DNS-ի և MTU-ի պայմանագրերը, և protect()-ը առանձին VpnService կանչ է, ոչ թե builder-ի ընտրանք. միացված ինտերֆեյսը միայն նշանակում է, որ առաջին պայմանագիրը կատարվել է։