Android-ի OpenVPN-ը թունելի հասցեի բացակայությամբ երթուղի չի ավելացնում

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

Կարդացեք ձախողումը այն հերթականությամբ, որով հաճախորդը կատարում է այն

Android-ի VpnService.Builder-ը առանձին է պահում երկու հասկացությունները. addAddress()-ը հասցե է դնում այն ինտերֆեյսի վրա, որը հավելվածը կառուցում է, addRoute()-ը ավելացնում է նպատակակետ նախածանց, իսկ establish()-ը հրաժարվում է ստեղծել ինտերֆեյսը, քանի դեռ գոնե մեկ հասցե չի ավելացվել։ OpenVPN հաճախորդը պրոֆիլը և սերվերի ուղարկած ընտրանքները քարտեզագրում է հենց այդ կանչերին, ուստի այն կապը, որը երբեք չի վերլուծում հասցե, ընդհանրապես չի կարող կառուցել ինտերֆեյսը։

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

Ստուգում 1. սերվերը հասցե դնո՞ւմ է պատասխանի մեջ

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

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Այդ ձևով սերվերը ուղարկում է մի բան, ինչպիսին է ifconfig 10.8.0.6 255.255.255.0-ը։ Ավելի հին topology net30 տեղադրումը փոխարենը ուղարկում է զուգընկերոջ հասցե, օրինակ ifconfig 10.8.0.6 10.8.0.5-ը, ուստի երկու մոդելների միջև տեղափոխված պրոֆիլը կարող է ճիշտ թվալ, մինչդեռ կրում է սխալ ցանցային դիմակ։

Հաճախորդի միացման մատյանում փնտրեք ուղարկված ընտրանքների հավաքածուն։ Եթե այն ընդհանրապես ifconfig տող չունի, սերվերը երբեք հասցե չի ուղարկել կամ հաճախորդը մերժել է ընտրանքը։ Այն սերվերի վրա, որն օգտագործում է client-config-dir, վկայագրի common name-ով անվանված ֆայլը պետք է գոյություն ունենա և կրի հատկացումը.

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Ստուգում 2. հաճախորդը պահպանո՞ւմ է ստացած հասցեն

Չափազանց լայն զտիչը երկրորդ սովորական պատճառն է։ pull-filter-ը գոյություն ունի OpenVPN 2.4 և ավելի նոր տարբերակներում, և երբ մի քանի զտիչներ համընկնում են նույն ընտրանքի հետ, հաղթում է վերջին համընկնողը, ուստի վերջում դրված catch-all-ը հեռացնում է հասցեն առանց սխալի.

# removes every pushed option, including the address
pull-filter ignore "ifconfig"
pull-filter ignore "route"

Նեղացրեք զտիչը մինչև այն ընտրանքը, որից իրոք ուզում եք ազատվել, և հասցեն թողեք անփոփոխ.

# keeps the pushed address, drops one unwanted LAN route
pull-filter ignore "route 10.60.0.0"

Բոլոր pull-երը անջատելու խորհուրդը սովորաբար գալիս է նրանից, ով ուզում է ազատվել մեկ երթուղուց։ route-nopull-ը ավելի նեղ անջատիչ է. այն պահում է ifconfig-ը և մյուս ուղարկված ընտրանքները՝ միաժամանակ մերժելով ուղարկված երթուղիներն ու DHCP-անման ընտրանքները։ Օգտագործեք այն, երբ դա իսկապես այն է, ինչ ուզում եք, և հասցեի հարցին պատասխանեք առանձին.

Ստուգում 3. հասցեն ձե՞րն է մուտքագրելու

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

Երթուղու մեջ հեռավոր LAN-ի նախածանցը նպատակակետ է, երբեք հեռախոսի ինքնությունը։ 10.60.0.0/24-ի համար նախատեսված երթուղին ասում է հասնել այդ ցանցին թունելով. այն ոչինչ չի ասում, թե որ 10.60.0.x հասցեն պետք է ունենա հեռախոսը, և հեռախոսը դրանցից ոչ մեկը չպետք է ունենա։ Ստատիկ հատկացումները պատկանում են սերվերի կողմին, որտեղ չեն կարող բախվել դինամիկ լողավազանի հետ։

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

Ստուգում 4. արդյո՞ք այլ բան է զբաղեցնում թունելի տեղը

Android-ը միաժամանակ թույլ է տալիս միայն մեկ ակտիվ VPN ծառայություն։ Մեկ այլ VPN հավելված կամ մշտապես միացված VPN գրառում, որը միացված է մնացել այլևս չաշխատող պրոֆիլի համար, կարող է զբաղեցնել այդ տեղը նախքան ձեր OpenVPN հաճախորդը կկանչի establish()-ը։ Այդ դեպքում ինտերֆեյսը երբեք չի հայտնվում, թեև պրոֆիլը վավեր է, ուստի անջատեք մյուս VPN-ը, անջատեք մշտապես միացված կարգավորումը և նորից միացեք նախքան պրոֆիլին դիպչելը։

Ethernet-ի կամրջում պահանջող ծառայությունը մյուս փակուղին է։ Առանց root-ի Android հավելվածը կարող է ստեղծել IP թունել, ոչ թե կամրջված Ethernet հատված, ուստի ձեր մուտքագրած ոչ մի հասցե չի ստիպի dev tap սերվերին աշխատել. օպերատորը պետք է առաջարկի երթուղավորված ծառայություն։ Խնդիրը հաղորդելիս ներառեք հաճախորդի անունն ու տարբերակը, ուղարկված ընտրանքների հավաքածուն, տոպոլոգիան և այն ստույգ քայլը, որտեղ հասցեն պետք է հայտնվեր։

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